Tools and Intermediaries
When I think of intermediaries I typically think of additional tools that I have in my tool box and can use. They are something I can use within my processes but are run and managed by someone else - in other words shared infrastructure.
A simple example of an intermediary would be a data transformation service. This service would accept any message in a specific wrapper (SOAP or REST) and a URL pointing to a definition of the transformation instructions and then return the result. Other services could be shipping calculators, tax calculators etc.
Whether the service returns the message to the sender or forwards it to another destination seems to determine whether the service is defined as an intermediate service or an end point. However the service should not really care, where the message goes next, it should be a capability of the service (does it support forwarding) and a decision made by the application developer - where do I want it to go.
Discovery of these shared services is a challenge today as I typically need a complete ecology working together before they are truly useful. The begining of an ecology does seem to require a common set of semantics and a way of transforming the semantics. This implies a common schema for the ecology and transformation services to move in and out of the common semantics. For the ecology to exist there must be sufficient agreement between all parties of common semantics. A good example of ommon semantics is in the retail industry where ARTS that has defined a set of XML Schemas under the heading of IXRetail. This provides the common semantics that enable parts of the ecology to communicate.
Once the semantics are defined and available to the community shared services can be created but how individual services interact and work together is still an issue as there is no really good way to build collaboration between service providers in the loosely coupled framework that is needed to foster collaboration and independant development.
To make interacting intermediaries a viable source of tools the ability to boot strap an ecology needs to be available - anyone got ideas?
2 Comments:
I think you're right on track. There definitely is a lot that can be done in intermediaries, and the client may or may not be aware of its existence. While intermediaries have typically been isolated to "horizontal" domains associated with the transport envelope, such as HTTP Proxies and Security gateways, it is only because of the lack of standards in the "vertical" domains, as you call out. Where I disagree slightly is in the emphasis on transformations. If everyone is following a standard, the need for transformation is lessened. What is true, however, is that if standards are used, we have far greater flexibility in where we choose to enforce policies associated with service execution.
Todd,
I agree with you about transformations - unfortunately they are a necessary evil as while standards are great they take time to be adopted and then they evolve. The chances of everyone being on the same version of the standard at the same time is vanishing small ;-).
John
Post a Comment
<< Home