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

Re: [soaplite] Compatibility

Expand Messages
  • Stephane Bortzmeyer
    On Wed, Sep 24, 2003 at 09:57:56PM -0000, =?iso-8859-1?q?V=EDctor_A._Rodr=EDguez_-_El_bit_Fantasma_ (Bit-Man) ?= wrote ... We are
    Message 1 of 4 , Sep 25, 2003
    • 0 Attachment
      On Wed, Sep 24, 2003 at 09:57:56PM -0000,
      =?iso-8859-1?q?V=EDctor_A._Rodr=EDguez_-_El_bit_Fantasma_ (Bit-Man) ?= <victor@...> wrote
      a message of 29 lines which said:

      > I'm working on some client/server SOAPing and just want to know what
      > to avoid, in SOAP terms, when speaking of clients and servers from
      > not-the-same-implementations (e.g. SOAP:Lite against SOAPpy, .NET,
      > etc.).

      We are currently discussing SOAP vs. XML-RPC for an application and I
      noticed that my message "Interoperability problem: Unrecognized type
      '{http://www.w3.org/1999/XMLSchema}str" received exactly zero reply
      from both mailing lists, which does not speak well for SOAP.
    • Byrne Reese
      ... Well, it certainly doesn t speak well for those newsgroups... :-/ Let me answer the original question of this thread... what to avoid in terms of
      Message 2 of 4 , Sep 25, 2003
      • 0 Attachment
        > We are currently discussing SOAP vs. XML-RPC for an application and I
        > noticed that my message "Interoperability problem: Unrecognized type
        > '{http://www.w3.org/1999/XMLSchema}str" received exactly zero reply
        > from both mailing lists, which does not speak well for SOAP.

        Well, it certainly doesn't speak well for those newsgroups... :-/

        Let me answer the original question of this thread... what to avoid in
        terms of compatibility:

        * if this is a commercial application I would first understand the needs
        of the customer as you often can't dictate how they will use your service.
        If their use case requires large amounts of data to transacted, then you
        may want to consider using attachments. But if they use .NET, then
        SOAP::Lite and .NET won't play well together (.NET speaks DIME, SOAP::Lite
        speak MIME).

        * that being said, here is what I would avoid - document/literal style
        encoding... toolkit support for this is coming, but is slow. for now stick
        with SOAP RPC encoding. What's the difference? RPC style deals with
        ArrayOf objects, doc-literal deals with sequences and choices and what
        not... this is more a function of your WSDL, but something to be aware of

        * avoid SOAP Encoding - especially in SOAP::Lite. it works great when
        creating two SOAP::Lite services to talk to one another, but other than
        that, it is more trouble than its worth. and I would say that about any
        toolkit.

        SOAP was designed to be interoperable to a certain extent... the issues
        with it are usually idiosyncratic based on the toolkit you are using. But
        most implementations are pretty baked at this point, and relatively
        reliable.

        XML-RPC is fine and dandy, but to be honest, SOAP is much more ubiquitous,
        and support for SOAP over XML-RPC is IMHO really indisputable - especially
        support for SOAP in commercial development platforms. That alone is reason
        enough for me to recommend SOAP over XML-RPC. But there are many other
        reasons to boot outlined in Programming Web Services in Perl...

        ^byrne :/
      • Víctor A. Rodríguez
        Byrne, thanks for your help. ... well, this is an open source initiative (TRex - http://trex.sf.net). The main use of SOAP here is to permit the usage of
        Message 3 of 4 , Sep 25, 2003
        • 0 Attachment
          Byrne,

          thanks for your help.

          > * if this is a commercial application I would first understand the needs
          > of the customer as you often can't dictate how they will use your service.

          well, this is an open source initiative (TRex - http://trex.sf.net).
          The main use of SOAP here is to permit the usage of software components
          built using other languages than Perl. Then with some glue code, that
          software component (just any piece of code that performs some defined
          function) could be converted to a SOAP server, using TRex as a client.

          That's why my question, because not only it needs to be language
          independent BUT, but also have some SOAP implementation independence.

          Thanks again for your help.
          --
          Víctor A. Rodríguez (http://www.bit-man.com.ar)
          El bit Fantasma (bit-man)
          Life hacker
        Your message has been successfully submitted and would be delivered to recipients shortly.