OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]
  • To: "Paul Prescod" <paul@prescod.net>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] What does SOAP really add?
  • From: "Joshua Allen" <joshuaa@microsoft.com>
  • Date: Sun, 21 Apr 2002 20:56:50 -0700
  • Thread-index: AcHpl7ZSq4LwfNJiQwupRKHfhLijrwAGJ86w
  • Thread-topic: [xml-dev] 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,
> > so on.  This doesn't negate the value of loose-coupling -- it is
> > 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
> 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
> 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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS