[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What does SOAP really add?

• To: Joshua Allen <joshuaa@m...>, xml-dev@l...
• Subject: Re: What does SOAP really add?
• From: Paul Prescod <paul@p...>
• Date: Sun, 21 Apr 2002 17:52:55 -0700
• References: <4F4182C71C1FDD4BA0937A7EB7B8B4C104F0543F@r...>

Joshua Allen wrote:
> 
>...
> 
> The basic answer is that it allows out-of-box interop (well, usually) so
> things like VS.NET can work with BEA, and BEA can work with Apache, and
> so on.  This doesn't negate the value of loose-coupling -- it is still
> beneficial to do loose-coupled async architectures even if the
> message/document format is not SOAP.  

Is this true? Can I take a WSDL for an asynchronous application, pump it
through Visual Studio.NET and ask for an asynchronous binding (whether
JMS or SMTP or response-less HTTP) and then expect it to work out of the
box with BEA or Apache's toolkit? And if so, based upon what draft or
completed standards?

> .... But the fact that 90% of clients
> and servers support automatic SOAP mappings mean that SOAP is a safe bet
> for an XML novice trying to whip up a loosely coupled architecture in a
> hurry.

As clients move to *XML Schema* mappings, the SOAP mappings will become
less and less interesting. Already, Microsoft's GET and POST bindings
demonstrate that you can get *exactly the same* XML type mappings
without using SOAP. And if you aren't interested in pre-declared types,
XML-RPC is more reliably interoperable in my experience than SOAP.

 Paul Prescod

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: Francis Norton <francis@r...>

• References:
  • RE: What does SOAP really add?
    • From: "Joshua Allen" <joshuaa@m...>

• Prev by Date: Re: Can you stand yet another SOAP-RPC vs HTTP GET question?
• Next by Date: Re: What does SOAP really add?
• Previous by thread: RE: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread