Jon Udell writes about proxying SOAP traffic providing other analogies:
Service-oriented architectures (SOA) will exploit another kind of openness: the ability to inject proxies into communication paths. HTTP and SMTP are inherently capable of proxying. We’re familiar with server-side proxies that cache Web pages, monitor access, and rewrite mail messages. Less familiar but equally powerful are the client-side versions of these proxies. For years, I’ve used a local Web proxy called Proxomitron to monitor and filter my connections to Web sites. I’ve also experimented with Zoe, a local e-mail proxy that creates a searchable index of your e-mail and builds categorized views.
SOA vendors emphasize the notion of proxying SOAP traffic. But when push comes to shove, they’ll work with what you’ve got. The first version of Confluent Software’s Core — a Web services monitoring and management platform — enforced security policies and guaranteed service levels only for services that presented SOAP interfaces. The new Version 3.0 is more promiscuous. Now, even if your legacy system uses FTP to ship data, you can still use Confluent’s overlay network to declare that transmitted files must use WS-Security encryption, and that transmissions must meet a service-level agreement.
