RE: Intermediary Text

Jean-Jacques,

Thanks for the comments. A few notes:

 - The intermediary text will be inserted at different points in the 
spec document. So the ordering of the text in the email was adhoc rather 
than intentional. Sorry for the confusion this caused - this should
have been explicit in the intro..

 - Your points about leading off the list of intermediaries with gateways, 
along with classifying gateways as intermediaries at all is well taken. I 
think either removing the text or saying what gateways are and what they 
are not is the correct action. Another comment on this towards the end.

 - I think that 'forwarding intermediary' is redundant. If a intermediary 
is not 'forwarding' the message, then it is by definition the ultimate 
receiver. Furthermore, 'active intermediaries' are a specialization 
of forwarding intemediaries, rather than being mutally independent. Thus I 
find that the qualification 'forwarding' is of low value. That said, I do
realize the value of staying consistent with the 1.2 spec though.

 - It seems that SOAP 1.2 active intermediaries may even act on the 
message body - not just 'untargeted' headers. However, my understanding 
may be erroneous, and is based on the text in the active intermediaries 
section:

"The potential set of services provided by an active SOAP intermediary 
includes, but is not limited to: security services, annotation services, 
and content manipulation services."

For instance, if a SOAP processor encrpts a SOAP message body and relays 
the encrypted message to another processor, is it an active intermediary, 
or no longer an intermediary by definition (thou shall not touch the message
body...)? Would it then be an ultimate receiver who just so happened to 
relay the contained infoset to another SOAP processor?

 - I think functional and optimizing is a different dimension than 
forwarding and active. This categorization was harvested from a source 
that predated SOAP 1.2 spec. I think our text can better support both 
categorizations and dig into clarifying the space with some examples. 
The WSA editors have an AI to do this.

 - I will have to revisit my notes on store/forward, partial messaging,
and aggregation. I had thought that these were not gateways, but I shall 
have to do some extra research before re-establishing a position. I agree 
that orchestrator is a gateway pattern rather than an intermediary. 

 - Note: I wonder if it would add value to the arch spec if it also iterated 
these valid system patterns even though they are strictly not SOAP 
intermediaries? I think no is a valid answer here, but it would be helpful to
our audience to describe common system architectural patterns used in the 
deployment of web services (gateways, proxies, composing gateways, workflow).
Anyways, this feels like valuable system arch work.

 - SOAP 1.2 says: "While SOAP does not itself define any routing or forwarding 
semantics, it is anticipated that such functionality can be described as one or 
more SOAP features". Question: has the WSD group discussed how these features 
could be described by WSDL? Is WS-Routing the only attempt at defining explicit 
routing or forwarding semantics? It seems like WS-Addressing does define 'next 
hop' forwarding semantics, but that is all. Maybe that is all that is needed.

r, MikeM



>-----Original Message-----
>From: ext Jean-Jacques Moreau [mailto:jean-jacques.moreau@crf.canon.fr]
>Sent: September 26, 2003 06:15 AM
>To: Mahan Michael (NRC/Boston)
>Cc: www-ws-arch@w3.org
>Subject: Re: Intermediary Text
>
>
>Hi Mike,
>
>Excellent categorization! It will certainly help people understand 
>intermediaries. Comments interspersed below.
>
>Jean-Jacques.
>
>michael.mahan@nokia.com wrote:
>
>> MikeM and MikeC have come up with the following text on
>> intermediaries for consideration in today's agenda....
>> 
>> 
>> 
>> BACKGROUND/MOTIVATION
>> 
>> [Ed Note: Some history on the role of intermediaries in the evolution
>> of the SOAP spec would be helpful.]
>> 
>> 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.
>> 
>> In fact, the emerging SOAP-aware networking infrastructure products
>> such as firewalls, routers, ... are examples of Web service
>> intermediaries.
>> 
>> Intermediaries also support Web services applications that are
>> designed as asynchronous processing pipelines rather than synchronous
>> remote procedure calls.In this model, a sequence of intermediaries
>> act as filters, and supply the pipes that direct the flow of data,
>> much as in the classic Unix tool model.
>> 
>> In the Web services context, the intermediaries are active agents 
>> that can act on the messages they transport.
>
>Yes, as per your ednote, I wonder as well if we need to 
>qualify the word 
>agent with "active".
>
> > An active intermediary
>> reliably stores and forwards messages from one Web service to
>> another.
>
>The adjectif "active" is more problematic here. SOAP defines 
>to types of 
>intermediaries: forwarding intermediaries[1] and active[2] 
>intermediaries. Forwarding intermediaries are intermediaries that obey 
>the rules, i.e. they process only the header blocks targeted to them. 
>Active intermediaries are the bad guys; they also process 
>header blocks 
>*not* targeted to them (and worse, they may not even tell you what 
>processing they've performed, although the spec strongly 
>encourages them 
>to do so). This is the only difference between the two types of 
>intermediaries. In view of this, I think you should remove the word 
>"active" above.
>
>[1] <http://www.w3.org/TR/soap12-part1/#forwardinter>
>[2] <http://www.w3.org/TR/soap12-part1/#activeinter>
>
> > Along the way, it can filter, transform, log, and analyze
>> the message flow.
>> 
>> <Ed Note - why qualify the word agent with 'active' above? I admit
>> getting somewhat confused by the SOAP 1.2 primer distinction between
>> active and forwarding intermediaries - and the below distinction
>> between func. and optimizing>
>> 
>> Intermediaries can be categorized as being either functional or
>> optimizing.
>
>I think you need to be careful with the terminology here. 
>Whilst I don't 
>disagree with your possible caracterization, I think we need to be 
>explicit this is new (albeit valid) terminology, i.e. terminology not 
>present in the SOAP 1.2 spec. SOAP 1.2 only talks about forwarding and 
>active intermediaries, not functional or optimizing intermediaries.
>
> > Functional intermediaries provide some functional
>> processing that is required for the application to work. Optimizing
>> intermediaries enhances application yet are not required to exist for
>> application to work. Optimizing intermediaries can often be
>> introduced at runtime rather than at design time - a significant
>> capability to enable a provider to 'tune' the service
>> post-deployment. Optimizing intermediaries typically enhance
>> scalability, reliability, or perceived performance of the provided 
>> service.
>> 
>> Intermediaries are often arranged in common configurations, or
>> deployment patterns, in order to address a technical or business
>> problem. Common deployment patterns of Web services intermediaries
>> include:
>> 
>> - Gateways. These are intermediaries deployed by which reside at the
>> trust boundary of web services provider. Gateways enable an
>> enterprise to provide a single point of contact to all requesters
>> outside its trust domain for all the Web services that it hosts.
>> Gateways may implement some business logic such as authentication,
>> authorization and privacy handling. Gateways can assume the role of
>> ultimate receiver of the message, or can be a true intermediary. -
>> Proxies/Adapters. These are intermediaries which assume the roles of
>> requester and provider respectively, in order to enable legacy
>> systems to participate in a web services application. (These are not
>> intermediaries in the strict sense of the SOAP processing model).
>
>Yes, gateways are not SOAP intermediaries (there was a discussion 
>earlier on this list; see for example [3]). So it's a bit odd to start 
>with an introduction on intermediaries and then expand to non-SOAP 
>intermediaries, apparently only for this paragraph. Maybe it should be 
>dropped entirely, or at least be toned down and come last?
>
>[3] <http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0180.html>
>
>> - Router. A Web service message can follow a particular 
>"path" through
>> an arbitrary number of intermediaries where each Web service
>> intermediaries would provide a value-added services to the message
>> and hence to the application. Note that for a request-response MEP,
>> the message may traverse through different intermediaries on it
>> request and response paths. Routing intermediaries could belong to
>> the trust domain of the requester, the provider, or some third party.
>
>Maybe add a link to WS-Routing?
>
>>  - Dispatchers. These intermediaries allows a Web service request
>> message to be routed to one of several instances of a Web service
>> provider based on some "filter" criteria applied to the message's
>> contents/data. The dispatcher typically belongs to the trust domain
>> of the web services provider. Dispatchers may perform some form of
>> "load sharing" or "data partitioning" so that requests for a
>> particular Web service may be filtered on the presence and/or value
>> of certain data elements in a request and diverted to an appropriate
>> provider that hosts the resource to which the data in question is
>> relevant. Dispatching intermediaries may be used to filter Web
>> service messages on namespaces used within the message and direct
>> requests for different versions of an interface to the appropriate
>> implementation.
>> - Orchestrator/Composition. This intermediary offers
>> a composite service interface built from the coordination of a set of
>> individual Web services. Requesters see the composed service, not the
>> component services. (This probably is not a SOAP intermediary - but 
>> represents more of a deployment pattern)
>
>Yes, it's not an intermediary, as it looks like the message 
>path for the 
>incoming message would terminate at the orchestrator, and a new, 
>separate SOAP would be sent by the orchestrator to the node 
>effectively 
>providing the service.
>
>> Some of the implementation techniques of optimizing intermediaries
>> are:
>> 
>> - Caching. Reuse responses from previous information requests.
>> Caching intermediaries should occur in network where there is
>> economic balance between # of requesters and localized requests.
>> - Store-and-Forward. For large or frequent transfers where acks are
>> required but are not functional
>
>Again, is this really a SOAP intermediary, or a gateway, as per the 
>distinction in [3]?
>
>> - Partial Messaging. Only part of a
>> message should be sent -- where there are to be changes to a cache.
>
>This would be an active SOAP intermediary, if it omits from 
>the outbound 
>message header blocks targeted to a node other than itself. Your 
>description is a little short, though, and I may have misundertstood.
>
>> - Aggregation. Exploits locality in multiple incoming 
>messages, to one
>> single message. Messages should has a common endpoint - or at least
>> one. (not sure about this one).
>
>This also looks like a gateway, not a SOAP intermediary.
>
>> CONCEPT
>> 
>> Web services intermediary is an entity positioned anywhere within a
>> Web services message path that performs a value-added function on
>> behalf of the initial message sender, the ultimate message receiver,
>> or both
>> 
>> A Web service intermediary is a software agent acts as a node in
>> message path that performs a SERVICE on behalf of the message sender,
>> receiver, or both. An intermediary acts as both a message SENDER and
>> RECEIVER. Intermediaries may work with information in message bodies
>> and / or message headers, and can add or remove headers as
>> appropriate.
>> 
>> 
>> RELATIONSHIPS
>> 
>> An INTERMEDIARY IS-A SOAP PROCESSING NODE [not sure if that is one of
>> our concepts!]. An INTERMEDIARY is explicitly targeted by a MESSAGE.
>> 
>> An INTERMEDIARY optionally adds or removes MESSAGE HEADERS
>> 
>> A SERVICE PROVIDER MAY use one or more INTERMEDIARIES to partition a
>> SERVICE across multiple NODES and/or to provide additional services
>> that are transparent to the SERVICE REQUESTER.
>> 
>> A SERVICE PROVIDER MAY use one or more INTERMEDIARIES to provide
>> POLICY enforcement.
>> 
>> 
>> 
>> DISCUSSION
>> 
>> includes entities ranging from software applications and network
>> appliances that function as part of an organization's physical
>> messaging infrastructure through third party Web services networks,
>> traditional VANs, carriers and vertical hubs. The concept of an
>> insourced intermediary platform under the control of the benefactor
>> is rapidly becoming a popular method for managing and enriching a
>> service-oriented architecture.
>> 
>> 
>> [Ed Note: Intermediaries can provide trust functionality .. ]
>> 
>> 
>> <Ed Note: I think we should remove the below para ... or beef it up,
>> but I am sure where to take it...>
>
>Agree.
>
>> Intermediary hubs are increasingly becoming useful sources of
>> business intelligence both in terms of business activities and
>> service quality.
>
>

Received on Friday, 26 September 2003 16:32:33 UTC