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

Generic SOAP::Lite questions (semi-OT)

Expand Messages
  • Michael A Nachbaur
    Hello all, I don t have a specific issue I m seeking help on, but rather wish to tap into the collective wisdom of the mailing list s SOAP::Lite gurus. I ve
    Message 1 of 3 , Jun 18, 2003
    • 0 Attachment
      Hello all,

      I don't have a specific issue I'm seeking help on, but rather wish to tap into
      the collective wisdom of the mailing list's SOAP::Lite gurus. I've built some
      basic SOAP servers/clients but nothing large-scale.

      I'm re-designing an ISP billing and customer management infrastructure, and
      would like to separate the SQL/Perl code into business objects that access
      database information and present an object-oriented view of that data to the
      client interfaces.

      I'll also be integrating server management functionality in this system, so
      the business objects can talk to other SOAP servers (on the mail server, web
      server, etc) to make changes to the system (add/delete email accounts, create
      new virtual hosts, etc).

      Finally, I'd like to build a XUL application in Mozilla for interfacing with
      this whole mess, so I can have an interface to this that is more intelligent,
      and a bit more responsive, than a plain-vanilla web interface.

      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?

      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?

      --
      Michael A Nachbaur <mike@...>
    • Jason Taylor
      I m planning on a similar system, at least so far as the technologies involved are concerned--SQL for persistence, Perl business objects, and a XUL front end.
      Message 2 of 3 , Jun 18, 2003
      • 0 Attachment
        I'm planning on a similar system, at least so far as the technologies
        involved are concerned--SQL for persistence, Perl business objects, and
        a XUL front end.

        I'm fairly new to OO-Perl and very new to SOAP. My question is, is it
        possible to use objects as such from a language other than Perl? All
        the examples I've seen where the client was something other than Perl
        were basically function calls, not method calls.

        Michael A Nachbaur wrote:
        > Hello all,
        >
        > I don't have a specific issue I'm seeking help on, but rather wish to
        > tap into the collective wisdom of the mailing list's SOAP::Lite
        > gurus. I've built some basic SOAP servers/clients but nothing
        > large-scale.
        >
        > I'm re-designing an ISP billing and customer management
        > infrastructure, and would like to separate the SQL/Perl code into
        > business objects that access database information and present an
        > object-oriented view of that data to the client interfaces.
        >
        > I'll also be integrating server management functionality in this
        > system, so the business objects can talk to other SOAP servers (on
        > the mail server, web server, etc) to make changes to the system
        > (add/delete email accounts, create new virtual hosts, etc).
        >
        > Finally, I'd like to build a XUL application in Mozilla for
        > interfacing with this whole mess, so I can have an interface to this
        > that is more intelligent, and a bit more responsive, than a
        > plain-vanilla web interface.
        >
        > 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?
        >
        > 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
        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 3 of 3 , Jun 19, 2003
        • 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.