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

RE: What does SOAP really add?

• To: "Paul Prescod" <paul@p...>,<xml-dev@l...>
• Subject: RE: What does SOAP really add?
• From: "Joshua Allen" <joshuaa@m...>
• Date: Sun, 21 Apr 2002 20:56:50 -0700
• Thread-index: AcHpl7ZSq4LwfNJiQwupRKHfhLijrwAGJ86w
• Thread-topic: What does SOAP really add?

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

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: Paul Prescod <paul@p...>

• Prev by Date: RE: What does SOAP really add?
• Next by Date: RE: Patents
• Previous by thread: RE: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread