Intermediary Text

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. An active intermediary reliably
stores and forwards messages from one Web service to another. 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. 
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).
 - 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.
 - 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)


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
 - Partial Messaging. Only part of a message should be sent -- where there are to be changes to a cache.
 - 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).  



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...>

Intermediary hubs are increasingly becoming useful sources of business
intelligence both in terms of business activities and service quality.

Received on Thursday, 25 September 2003 11:40:28 UTC