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 06:15:53 UTC