Re: Intermediaries text for stakeholders section

This is really quite excellent.

A handful of minor nits ..

On Tue, Dec 02, 2003 at 11:57:59AM -0800, Ugo Corda wrote:
> The concept of network intermediary has been around for quite a while in association with various protocols predating SOAP (e.g. SMTP store-and-forward nodes, HTTP proxies and gateways). Intermediaries are often used within protocols to allow message routing and control, as well as to obtain application performance and scaling improvements. By interposing intermediaries, an application can become more distributed, allowing the layering of services (e.g. message processing), as well as performance improvement (e.g. caching) and decoupling (e.g. store-and-forward).

One issue you should probably cover someplace, is that the word
"intermediary" in the context of SOAP is less general than elsewhere
(FWIW, I consider this a good thing), as it doesn't include the
notion of a gateway; a gateway in SOAP is an ultimate receiver, and
explicitly not an intermediary.

> SOAP intermediaries are a relatively poorly understood component of the Web services architecture.  One often hears the critique that SOAP offers little value over XML messages exchanged via HTTP.  This ignores the role of intermediaries in the SOAP processing model to provide additional services to enhance the security, reliability, scalability, etc. of a services infrastructure without requiring modifications to the ultimate Web service being provided or the application requesting the service.

Well, intermediaries have been around far longer than SOAP.  But what
SOAP did add was a richer, protocol-independent intermediary model.  I'd
suggest that be discussed instead.

> In the Web services context, intermediaries are agents that can act on the messages they transport. An intermediary can reliably forward messages from one Web service to another. Along the way, it can filter, transform, log, and analyze the message flow. 

"from one Web service to another" sounds as if the intermediary "pulls"
the message from one, and sends it to another.  How about simply
"forwards received messages"?

> Cross-transport interoperability:
> Messages can be received by an intermediary over a particular transport, and then relayed using a different transport. This way an intermediary can mediate between, for instance, an intranet transport and an Internet transport.

I'd suggest s/transport/protocol

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Wednesday, 3 December 2003 00:22:00 UTC