Re: [soaplite] Compatibility

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