Loading ...
Sorry, an error occurred while loading the content.

RE: [soaplite] Generic SOAP::Lite questions (semi-OT)

Expand Messages
  • Byrne Reese
    Wow... that was a mouth full. Let me see if I can t tackle some of these questions below: I guess what I m asking is, when implementing complex object-oriented
    Message 1 of 3 , Jun 19, 2003
    View Source
    • 0 Attachment
      Wow... that was a mouth full.
       
      Let me see if I can't tackle some of these questions below:
      I guess what I'm asking is, when implementing complex object-oriented data structures, having a bit of code talk to several SOAP servers simultaneously, keeping persistant data, and interoperability with other SOAP clients (e.g. Mozilla), what sort of recommendations would people have?
       
      [Byrne Reese]  Good question. There are several options here. If you are building it yourself, I don't know if I would recommend Perl, maybe mod_perl, but not simple and stateless CGI scripts. Java might be your best bet, and I would say so for the following reasons:

      * if you are using a lot of complex types and data structures, java which is inherently Object Oriented might speed up development time. Also, as it stands, SOAP::Lite's ability to serialize and deserialize complex types in an interoperable way is a bit limited without a lot of low-level XML document building.
      * There are plenty of free and good Java app servers out there which support session contexts, server contexts, etc. Given the number of transactions you will have, this may be a priority to you.

      Of course you could always go with Systinet WASP Server, WebSphere, or BEA WebLogic Workshop [or even .NET -- hisss]. All of these tools (assuming you can afford them) specialize in transaction and Web Services management. This too is a possibility.

      You can also go with a Web Services Network (like Grand Central Communications, for whom I work) that is capable of executing and managing complex business processes inside of a shared network. You could compose rules and routes that could move messages from one end-point to another in a highly-reliable manner... and it supports asynchronous messaging which is key to long-lived transactions. Additionally, the network will do all of the exception handling for you. You can try it for free, but eventually, you will have to pay: http://developer.grandcentral.com/

      For instance, would there be any benefit to not going with auto-dispatching? Is there any reason why I should serialize my own requests, or can SOAP::Lite more-or-less intelligently handle basic perl objects?
      [Byrne Reese]  It can, but Perl SOAP Structs are not very interoperable. It is great for connecting to Perl-based services together, but you will enter a world of hurt trying to get it to work with Axis, or the like. So serializing data-structures manually is currently the most reliable means of interop. Unfortunately. But this is all slated to change in the next year... but that is probably too late for you.

      --
      Michael A Nachbaur <mike@...>



      To unsubscribe from this group, send an email to:
      soaplite-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    Your message has been successfully submitted and would be delivered to recipients shortly.