Re: Asynchronous Web Services!

> According to Gartner and other market reseatch agencies, the future of web
> service lie in *Asynchronous Web Services* using transport protocols like
> BEEP, SMTP etc.

> SOAP1.1 and WSDL1.1 donot talk about the asynchrony anywhere.
>
> Are these standards *complete* in terms of supporting ASYNCHRONOUS web
> services?
>
> If not, do SOAP1.2 and WSDL1.2 support asynchronous web services.

This is a feeling I've held for some time. The XML Protocol documents have 
been working toward addressing asynchronous protocols for a while, but the 
SOAP specification has unfortunately been migrating increasingly into a 
synchronous model where XML has primarily been used as a convenient stopgap 
for the limitations of COM or CORBA as brokering agents.

There is a growing movement of developers and engineers, however, who are 
becoming uncomfortable with this model by itself -- it preserves the letter 
of the law (the XML specification) while violating the spirit of it (the 
creation of syncronous RPCs, XML solely as a means of expressing data 
structure without its consideration as a meta-document definition, etc., the 
complexification of both transport and processing, etc.). 

Both SOAP and WSDL can, in theory, be used in an asynchronous manner, but 
whether that remains the case into the future is dubious. SOAP was originally 
developed (and has consequently been pushed primarily) by Microsoft as a way 
of extending the brokered COM model out onto the Internet, and it's primary 
emphasis has always been on stateful, synchronous, strongly connected 
applications. Compare this with the asynchronous, disconnected models that 
form the basis for most of the successful protocols on the web -- HTTP and 
SMTP, to name two -- and look at the success that Microsoft has had in the 
past with getting closed, connected networks in place (such as MSN, which 
after a decade of service is still a loss leader for them) and you begin to 
realize where a synchronous, connected SOAP will lead.

I am not arguing here that there is no place for XML-based RPCs; it's just a 
datapoint in the totality of XML based applications. I worry, however, that 
much of the significant development in the last decade toward extending the 
asynchronous model (most of the XML specifications on the W3C) are threatened 
when government officials, software developers and business leaders associate 
XML with, and only with, synchronous SOAP, especially since it does not 
figure in any way with any XML specification built before or since (think, 
for instance, of XML Forms, which would seem to be the one place where a 
logical fit with SOAP would make sense; there is no mention of SOAP in that 
document). I see SOAP as being a lot like DOM -- it is necessary in the 
interim as the web moves increasingly to an XML basis, but the DOM 
interactions will become thinner and thinner as XML becomes more prevalant 
and much of the functionality gets taken over by declarative forms of 
expression. Worked right, SOAP could be seen as a bridge technology between 
existing invested COM development until such development can be shifted into 
a functional mode; however, it can also be a crutch that will lock out the 
development of simpler, asynchronous protocols that have no depency upon a 
given company's software products or programming language versions.

-- Kurt Cagle, in his usual rant mode

Received on Saturday, 6 July 2002 11:35:49 UTC