Head's up on Intermediaries

Hi y'all
   Just thought that you may want to consider something in the 
choreography space.
   Recently the WSA has been wrestling with intermediaries.

  There are at least two camps here: those who wish that they didn't 
exist and those who think that there might be something interesting in 
them. (Personally I belong to the latter camp).

  An important note to clear up any potential misunderstanding: despite 
the name, intermediaries *do not* imply separate agents doing 
processing of messages.

  What follows is a mixture of speculation and rational reconstruction.

Intermediaries is an idea proposed in SOAP 1.2 (and therefore is a W3C 
recommendation)

1. One view of intermediaries is that they *are* separate processing 
entities that focus on messages' headers. A crucial property of this 
view of intermediaries is that the messages that they spit out are 
considered to be the *same* messages that they receive.
  I use the term considered judiciously: outgoing messages are, in 
effect, declared to be equivalent to corresponding input messages.

  This interpretation of intermediaries tends towards a `poor man's 
choreography'; may still be useful but limited in scope.

2. A second view, partly suggested by the SOAP 1.2 spec itself, paints 
a somewhat grander view. The best way I know of approaching this is via 
structured messages:

  A message has elements which are standardized separately and then 
combined into a whole document. A simple example of this is customer 
authentication: the tokens necessary are captured in a standard form, 
supported within SOAP by means of a standardized header. All customer 
authentications (whatever the purpose of the actual message is) are 
handled in the same way.
  This standardization permits a kind of factoring that is quite 
interesting: the different stakeholders in an organization may wish to 
inspect messages from their particular standpoint and standardized 
headers facilitate that.

  This leads to a kind of architecture for delivering Web services that 
might be called Document Centric Middleware: a Web service may be 
delivered via a collaboration of specialized processors that each 
process a particular aspect of a message/document. Many (all) of these 
specialized processors have relatively simple - and standardized across 
the Enterprise -- functions. The 'slave' processors may be called 
intermediaries and the 'master' processor may be called the ultimate 
recipient.

What does this mean for WS-CHOR?

1. Intermediaries should be taken seriously. They represent a powerful 
way for an enterprise to structure their services in a manageable way.
2. Services can not be regarded as simple monolithic lumps that have no 
internal structure. This is true whether you take the simple 
interpretation or the rich interpretation of intermediaries.
3. The layered approach to message structure implies that, whether we 
like it or not, we have to address service composition: a service 
involving intermediaries is a composite service.

Frank

P.S. Happy Thanksgiving!