RE: Intermediaries text for stakeholders section

Hi Mark,
Thank you for your feedback, I'll integrate it into the text.

Regarding the comparison of intermediary models, which aspects of SOAP intermediaries would you like to point out as an example of what makes it a richer model than previous ones?

Ugo

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, December 02, 2003 9:25 PM
> To: Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: 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 11:35:25 UTC