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

If your application is better modeled in a document-centric way, you will do
well to stick to that model, & not worry about SOAP.

Some applications are simply not modeled this way, & *need* "remote API
calls". Even there, my own preference has always been to use a HTML form to
send "API call arguments", & my own format to receive the results. Biggest
drawback of SOAP is I need to write a client before I can begin to test my
server; with HTML form based stuff, I can test these things from browser.

I am open to be convinced that third-party toolkits for SOAP are a help - I
find them more work then they are worth. What is the value they are giving?
Envelop parsing - must be < 0.01% of any non-trivial application! And you
are *forced* to use XML Schema. Or have I missed something central?

-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]
Sent: Wednesday, October 10, 2001 2:47 AM
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>