When I was first learning to program, I used Software Toolsby Kernighan and Plauger. The book describes a programming style that relies on creating simple, modular programs strung together using “pipes,” connections between one program’s output and another program’s input. Using these simple, reusable modules, it is possible to create a spelling checker in a single line of code.
Anyone who’s spent much time on Unix is familiar with pipes, a staple of shell programming in Unix where the small modular programs are sometimes called “filters.” Pipe and filter architectures are noteworthy for their inherent capability of exploiting concurrency and of providing real component reuse, making the structure very flexible.
It’s no surprise, then, that this same flexible architecture is finding its way onto the Web. Businesses are demanding that their IT infrastructure connect not only to other business units but to business partners and customers as well. The interconnected infrastructure also must easily change to match fluctuating business needs. That’s where a pipeline architecture shines, especially when combined with the standards-based, self-describing interfaces of Web services.
Active advantage
Web services naturally lend themselves to being arranged in pipelines. In this model, the Web services act as the filters, and vendors — such as Grand Central Communications, Sonic Software, and Confluent Software — supply the pipes that direct the flow of data. But these products are not just dumb pipes delivering data; they are active intermediaries that can intelligently 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 in just about any way you can imagine. Unlike the dumb-pipe model, active intermediaries can add security, reliability, availability, scalability, and interoperability without modifying the Web service itself.
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.
Not just pipes — networks!
