Panlibus Blog

The New Breed of Web Service Clients director is an interesting service that has wide ramifications for the web service world.

It’s a javascript application that creates a new, interactive user interface for the service. It runs inside the web browser, not on a server. It’s significant because it demonstrates a technique for interfacing to web applications without using an intermediary web service broker. I think that we’re in the middle of a sea change in the way web services are brokered and consumed. The reliance on centralised, web service orchestration, proxying and coordination is diminishing already and director may herald their disappearance entirely.

The first indication that something big was happening was the release of Greasemonkey which demonstrated the ability to inject user-controlled Javascript into a web page. The big deal here is the demonstration of the dynamism of the browser DOM. Simply by adding a script node, new behaviour can be inserted, removed or updated at runtime. This has recently been simplified by the release of the behaviour library which allows Javascript to be added to a page declaretively. Over the past 5-6 years there have been many proposals for ways to separate behaviour from content and styling. This is the first I’ve seen that is useable right now without having to wait for the browser vendors to implement a new standard. Technically it needed the dynamic DOM but socially it needed GMail, AJAX and Greasemonkey all to have existed first.

The second indicator was Google’s in-browser XSLT engine which enables XSLT to be used client-side in browsers that don’t yet allow programmatic control of the in-built XSLT engine (Safari), those that reject XSLT on philosophical grounds (Opera) or those that are tied to unsafe technologies (IE + ActiveX). This engine is pure Javascript (but leverages native processors where possible) and unlocks a major barrier for self-contained web service clients such as director. I’m sure that Google have other tricks up their sleeves waiting to be released.

How are these techniques going to change the web service landscape?

The current landscape is a complex tangle of specifications concerning identity, authorisation, orchestration, transactions, messaging etc. (see here and here). The assumption is that all the pain of these specifications will be handled by the platform vendors who will build new platforms for new applications. The cost of entry into this world is high in both time and money.

The community of web developers who actually want to go ahead and build useful applications has largely ignored these standards and have instead forged ahead with an existing platform that supports existing applications: the web browser. The browser already has mechanisms for authentication and identity. It has rich UI capabilities and communications facilities. It runs in a trusted security context. A missing piece has been around orchestration and coordination. For this the developers turned to Javascript and now, with dynamic DOM and runtime Javascript injection, it’s become possible to externalise application behaviour.

The result has been a transition from data-mobility to code-mobility. Rather than submitting data to a web service and getting results, the model is to download the required behaviour and apply it to the data which may be local or remote. The data can be dispersed across any number of specialised stores. The informative diagram halfway down the director page illustrates this quite nicely: the coordination happens on the client, not on the server.

Leave a Reply