Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
