RE: [xml-dev] What does SOAP really add?

["Joshua Allen" <joshuaa@microsoft.com>]

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

Actually, it *is* possible to take a standard WSDL and hook up async
bindings in BEA and VS.NET and have it "just work".  Of course, you need
a competent admin to bridge the JMS and MSMQ, but otherwise it will
work.  The part where things fall down is when you try to hook up
bindings that tell what the expected response/request patterns are.
This is because the Microsoft and BEA ways of representing in WSDL rely
on non-standard extensions, and the standards haven't caught up.  So
orchestrating between these different systems requires a lot of manual
work on both ends.