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

From: Winkowski, Daniel <>
To: "Costello,Roger L." <>
Date: 2001-11-28T21:29:50Z
ID: <>
Thread: RE: [xml-dev] Web Service: SOAP or {HTML + Servlets}?
Roger,

I think you need to go back to the original "ebXML Transport Routing and
Packaging Overview and Requirements" document
http://www.ebxml.org/specdrafts/trpreq.pdf to examine the rational for
TRP/SOAP. Clearly their requirement is not RPC bases but message based.

- Dan

----------------------------------------------------------------------------
----
From: "Roger L. Costello" <> 
To:  
Date: Tue, 09 Oct 2001 17:17:22 -0400 


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
← Prev in month ← Prev in thread
Next in thread → Next in month →