RE: Intermediaries text for stakeholders section

Here is the revised text.

Ugo

===================================================

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

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.

In fact, the emerging SOAP-aware networking infrastructure products such as firewalls and routers are examples of Web service intermediaries. Intermediaries include 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. Intermediary hubs are increasingly becoming useful sources of business intelligence both in terms of business activities and service quality. 

In the Web services context, intermediaries are agents that can act on the messages they transport. An intermediary can reliably forward received messages and, along the way, it can filter, transform, log, and analyze the message flow. 

Messages can be routed to an intermediary using various mechanisms. The intermediary address can be available at the application level, so that the requester can explicitly send messages to that address (possibly also specifying addresses for the following hops). Or messages can just be intercepted ("highjacked") at lower levels of the network stack and forwarded to the intermediary without the initial sender and ultimate receiver even being aware of its existence.

An intermediary can act on behalf of the initial sender (e.g. to encrypt a message), of the ultimate receiver (e.g. to check access credentials), or of a third part (e.g. to monitor network traffic). While in the first two cases intermediaries are usually part of the design of the Web services system, in the last case intermediaries are typically inserted at Web service deployment time.

Yet another way to conceptually categorize intermediaries is by classifying them 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:

Message processing:
Servers can offload processing by including processing instructions to intermediaries in their messages. Additionally, message processing intermediaries may be able to incorporate local information unavailable at the server, to provide localized, value-added services. The SOAP "role" attribute can be used to specify which intermediary node should perform which type of processing.

Caching:
Caching may be thought of as a limited form of message processing; based on message semantics, an intermediary may choose to store a copy of a message to use again. Caching is primarily used to reduce perceived network latency. It can also support partial messaging: only part of a message is sent - where there are to be changes to a cache.

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

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

Decoupling:
Store-and-forward intermediaries allow a requester to communicate with the provider even when the provider is temporarily unavailable. They also help smoothing out service load peaks by creating a buffer of requests that the provider can process at its own pace.

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

When comparing SOAP intermediaries with other preexisting intermediary models, it is worth noticing that they offer features which make them less general but at the same time give them richer  capabilities. For example, SOAP intermediaries cannot model the concept of a gateway, which is seen in SOAP as a message-terminating node (ultimate receiver). On the other hand, SOAP intermediaries support features like protocol independence, mandatory extensions (mustUnderstand), versioning (envelope namespace), header block targeting/scoping (role/relay) and a rigorously defined processing model, which give them more power and flexibility when compared with other types of intermediaries.

In addition to all the benefits mentioned so far, it should be mentioned that intermediaries also have drawbacks, and designers have to be aware of them. Besides introducing additional points of failure, from a security point of view intermediaries offer extra points of attack and complicate trust models and key distribution models. And few Web services standards, besides SOAP, currently provide adequate support for them.

Received on Wednesday, 3 December 2003 16:56:32 UTC