Proxy power

My e-mail client pulls messages through a local proxy that checks RBLs (real-time blackhole lists) and tags offending messages with a special header. In Web services lingo we’d call that proxy a policy-driven intermediary. The protocol that’s intermediated, in this case, is POP3. The policy, set by me, is to check one or more RBLs. Because the proxy lives in the protocol layer, it works with any POP3 client and any POP3 server.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Web ad-blockers often use the same time-honored strategy. Here the protocol that’s intermediated is HTTP. You point your browser at a local Web proxy that scans incoming pages for the URL and HTML patterns that characterize ads. Neutering JavaScript pop-ups is another possibility. Your browser may or may not support these features, but a protocol-based proxy can always deliver them.

Although it’s remarkable that we can intercept and modify our e-mail and Web traffic to achieve these effects, few people do it. The benefits of local proxies can be gotten in other ways that feel less subversive.

It’s easier to see why the Web services fabric increasingly depends on proxies. Fault tolerance, service-level agreements, access control, and business activity monitoring are among the many things enabled by intermediaries that watch (and sometimes transform XML) message flows. When those message flows reach the desktop, intermediaries will flourish there too.

I outlined this idea last October in a column entitled "Personal SOA." When rich Internet clients converse with Web services using XML messages, intermediaries will be able to add value in ways that end points needn’t cooperate with or even know about. Today, for example, my Internet banking application runs in a browser and doesn’t integrate with my accounting software. In theory a local proxy could intervene. But the proxy would only see HTML pages coming in and URL-encoded HTML forms going out.

As an experiment, I built a simple Web proxy that converts incoming HTML to well-formed XHTML. It’s a cute trick that enables more powerful kinds of search and transformation than is possible with the regular-expression-based text patterns that the ad blockers use. But well-formedness, though necessary, isn’t sufficient. The data must also be self-describing, as Web pages mostly aren’t but SOAP messages are.

One of these years, my bank will upgrade to a new system that’s built around Web services. They’ll probably offer a basic “rich Internet application” — for Windows, Java, or Flash — that connects to those services. When the bank announces the upgrade, it will stress the richer user experience and choice of interchangeable clients.

Those will be crucial benefits indeed. What won’t be said, because it’s harder to explain, is that the system will also have become radically extensible. Suppose I want to trigger an alert when a transfer exceeds some limit or when a duplicate amount appears. Today, if the system doesn’t implement these rules, I’m stuck. In a services-oriented environment, though, I needn’t depend on either the bank or my client software. If neither delivers the features I want, I’ll inject an intermediary that does. Local proxies are geeky curiosities today, but someday we’ll wonder how we lived without them.