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

RE: Web Service: SOAP or {HTML + Servlets}?

  • From: Manoj Dhooria <manojd@g...>
  • To: "Roger L. Costello" <costello@m...>, xml-dev@l...
  • Date: Wed, 10 Oct 2001 19:30:16 +0530

web service html form
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@m...]
Sent: Wednesday, October 10, 2001 2:47 AM
To: xml-dev@l...
Subject:  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>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.