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

Compatibility

Expand Messages
  • Bit-Man?=
    Hi all, 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
    Message 1 of 4 , Sep 24, 2003
    • 0 Attachment
      Hi all,

      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.).

      Mainly I want to minimize the portability related issues.

      Hope to read from you all.
      Best wishes.
      --
      Víctor A. Rodríguez (http://www.bit-man.com.ar)
      El bit Fantasma (bit-man)
    • 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 2 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 3 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 4 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.