Jon Udell writes:
When rich Internet clients converse with Web services using XML messages, intermediaries will be able to add value in ways that end points neednt cooperate with or even know about. Today, for example, my Internet banking application runs in a browser and doesnt 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. Its 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, isnt sufficient. The data must also be self-describing, as Web pages mostly arent but SOAP messages are.
One of these years, my bank will upgrade to a new system thats built around Web services. Theyll 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 wont be said, because its 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 doesnt implement these rules, Im stuck. In a services-oriented environment, though, I neednt depend on either the bank or my client software. If neither delivers the features I want, Ill inject an intermediary that does. Local proxies are geeky curiosities today, but someday well wonder how we lived without them.
More on Jon’s blog: “We have a surplus of storage and processing power on the desktop, but never enough useful context. When more of our data flows are XML, local proxies will really shine.”