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

Re: [soaplite] Compatibility

Expand Messages
  • 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 1 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 2 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.