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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xml-dev] Web Service: SOAP or {HTML + Servlets}?

Great question and very thought provoking answers so far. Here is my
perspective as someone who has been strongly recommending SOAP to my clients
for a year.

Firstly, it does, as was said, have remarkably good framework support both
in .NET and in the IBM Web Services Toolkit. This is a big help for my
clients.

Secondly, and more importantly, I always stress that I am not recommending
Section 5 of the SOAP specification and that I am not recommending using it
for RPC. As was also pointed out, that is just one way of using SOAP.

Thirdly, I recommend binding SOAP to transactional messaging, not to HTTP
(until something like HTTPR comes along).

So what do I recommend it for? The use case is passing a complete
transaction from one application to another. This is key to achieving
integration without tightly coupling applications. It also ties the use of
the protocol into the key application concept of an ACID transaction.

When the application commits, part of what it does (or the middleware should
do for it) is serialize the state of the transaction (the context, the
references and the event name) into an XML document, wrap it in SOAP (do you
wrap or wash messages with SOAP?) and put it on the queue.

Note that the interpretation of the transaction is up to the receiver -
another example of XML providing beautiful support for loose coupling.

John Schlesinger
SysCore Solutions

-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]
Sent: Tuesday, October 09, 2001 5:17 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Web Service: SOAP or {HTML + Servlets}?


Hi Folks,

I have been looking at SOAP recently.  Although its great fun to play
with new technologies, I am struggling to see why I should recommend to
my clients that they use SOAP rather than, say, HTML plus Java Servlets
(or CGI, JSP, ASP, etc) to implement Web Services.

Here are a couple of thoughts:

1. SOAP -> API-based architecture
   HTML + Servlets -> Document-based architecture

SOAP is about enabling one application to invoke a method in another
application by passing arguments.  It's basically about enabling a
(remote) subroutine call.  Hidden behind the scenes is the construction
of a SOAP XML document, and the passing of that XML document.  From a
document-based architecture point of view, the fact that the transport
is an XML document is immaterial.  Contrast this with the HTML + Servlet
technology where an application creates an HTML document, which is sent
to an application (servlet) for processing.  This is a document-based
architecture.  I am dismayed that SOAP has gone the API-based
architecture approach.  I would have thought that the progression would
be from
   HTML + Servlets (or CGI, JSP, ASP, etc)
to
   XML + Servlets (or CGI, JSP, ASP, etc)

A long time ago I saw the enormous benefits of document-based
architectures.  I switched from using API-based architectures to
document-based architectures.  I am extremely reluctant to regress back
to an API-based framework.

2. SOAP provides a (very) loose framework for sending data/requests to a
server. Basically, it leaves a bunch of "empty space" in the framework
where you can put stuff:

   <Envelope>
       <Header>
          - put anything here
       </Header>
       <Body>
          - put anything here
       </Body>
   </Envelope>

That's about the extent of the semantics of SOAP.  Presumably, each
vendor must define what elements can go in the Header element, and the
semantics of those elements.  Not a very attractive prospect from a
cross-vendor point of view.

On the other hand, if I were to implement Web Services using HTML +
Servlets then the semantics of all the HTML elements are concretely
defined.  There is rich (standard, non-vendor-specific) support for
things such as HTTP sessions, authentication, security, etc.  None of
this exists with SOAP.

My vision of next generation Web Services is an XML-document-based
architecture, with a well-defined set of elements.  I envision the XML
documents conforming to an XML Schema.  I envision schema validation of
the documents.  I don't see any of this in SOAP.

I'd like to use SOAP for implementing Web Services.  It seems to be a
fun technology to play with.  But, in good conscience, I am real hard
pressed to see any advantage to it over HTML plus Servlets (or XML plus
Servlets).  I am eager to be convinced otherwise, however.  What are
your thoughts on this?  /Roger


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>