Suppose you've created a Web services interface to a legacy application. Later, you decide to restrict access to this Web service to a certain collection of trading partners. You could modify the Web service itself, but this makes it less general and thus harder to reuse in some other capacity. Instead, an active intermediary can sit in front of your Web service and perform the authentication and authorization using LDAP, SAML (Security Assertion Markup Language), or another system.Ê Of course, programmers have been writing wrappers -- programs that sit outside another program and serve as its proxy -- for years. Whatâs different with active intermediaries is that thereâs no program -- at least not one that has to be written. Web services are based on the standardized interface protocol SOAP; SOAP interfaces are described using WSDL. The authentication service in our example could use the Web service's WSDL document to discover specific details of the SOAP-based API and wrap the Web service in an authentication and authorization proxy without anyone having to write any code. [Full story at InfoWorld...]

We set off to write this feature to provide an umbrella for the reviews of active intermediaries we've done and continue to do (I've got one of Blue Titan I'm working on right now). The goal was to explain some concepts and to create some classifying terminology for the various products. This article is accompanied by a sidebar by Jon Udell on how active intermediaries can halt the finger-pointing. I wrote a glossary of active intermediary terms to accompany the article:

Active Intermediary: a proxy or other program that sits in between two web services and acts on the message flow between them to add some new functionality.

Message Store and Forward: ensures that messages are delivered once and only once and, for some applications, ensures that theyâre delivered in order.

Service Call Switching balances server load, shuttles potentially high load jobs to specific servers, or moves a new version of a service into production.

Context Sensitive Message Filtering: filters messages based on their content or the message meta-information. Probably the most obvious example of context sensitive filtering is authorization.

Event Monitoring: places monitors, alerts and triggers on a message flow. Alert recipients can be other programs or people.

Message Logging: stores messages and message meta-information for traffic analysis or auditing.

Service Facades: adapts one Web service to another or to an industry or corporate standard.

Rule-based Routing: scripts Web service interactions and routes messages to intermediaries based on message content and meta-information.

I also created a table, which is referenced in the online version as "Selecting the Right Pipes." I can't find it online at the InfoWorld site, but I've made a version of it available on my site. I'll continue to fill it in as I review active intermediary products.