Web Services, Synchronous Collaborations, and Solutions to 
Distributed Process Coordination Problems Reflecting Legacy 
Integration Latencies.

Dale Moberg, Sterling Commerce, subsidiary of SBC, W3C member. 

There are certain familiar similarities between B2b collaborations and web
services.
In either case, requests implementing the intitiation of business tasks
occur and are 
typically serviced by responses that advance or complete the initiated task.
When a 
collaboration "piggybacks" on HTTP, and POSTs an XML message to a servicing 
process, the line between collaborations and services becomes more blurred.
And when 
the collaboration response is sent in the HTTP reply entity body
("synchronously"), 
collaborations and services become nearly indistinguishable. 

In either case, however, the requirement of a "synchronous" response places
burdens on 
integration environments that are not always well-suited to provide services
or respond 
interactively. The legacy environments may be fundamentally geared toward
batch 
operations, with interfaces possibly involving polling directories to detect
arrival of 
processing tasks. How can the advantages of web services and collaborations
be 
smoothly grafted onto such legacy integration tasks? In particular, how can
there be 
indicators of forward progress, suggestions to retry again after some
interval, or proposals 
to retrieve the response by means of a follow-up query to a new URL,
possibly after 
some interval?

Such questions suggest that it might be useful to characterize some protocol
elements that 
could be used, either for services or collaborations, that would provide
more flexible 
means of coordination of distributed processes, besides the requesting
process just 
waiting for a response. In practice, waiting on responses is a perilous
process. While TCP 
connections in principle have no set time-out periods, in practice many
varied tricks-
from ioctl/socket options to web server timers-- have been adopted to
terminate a 
connection "guessed" to be hung. Because these timers are often set outside
the 
integration programmer's sphere of influence, various complex configurations
of 
software components need to be deployed. The misconfiguration opportunities
are 
growing, making it difficult to be certain to avoid unwanted connection
termination.
More reliable coordination constructs can be quite useful in working within
the 
constraints of various deeply embedded implementation decisions.

Some examples of protocol enhancement to better suppoft distributed process 
coordination,  based on the HTTP 1.1 pipeline opportunities, will be
provided with some 
scenarios illustrating their utility. Such construct will also be useful
when moving beyond 
"piggyback" transport bindings to make use of transport schemes defined
using BEEP.