[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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" <costello@mitre.org>
To: xml-dev@lists.xml.org
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