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]

[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)
   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:

          - put anything here
          - put anything here

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