“Browsers and Email programs are user agents

Introduction to Protocol Translating User Agents:

Robert J. DuWors, CSGroup, 10 August 2005

All materials original to this article can be found at http:www.csgroup.com

“Browsers and Email programs are user agents. This isn't just a formal long term for them, it is an important issue. They are programs which act on behalf of, and represent, the user.

The computer protocols such as HTTP are defined to carry a particular meaning, and it behooves a user agent to represent that meaning to the user, or the whole system of people and machines breaks.”

-- Tim Berners-Lee, Axioms of Web architecture

“Software is not treated as a medium, it is treated as a product, and this is the problem. The product is not the software, the product is the knowledge that goes into the software.”

-- Philip Amour, Communications of the ACM, Volume 43, Number 8 (2000), Pages 19-22

"The Medium is the Message"

-- Marshal McLuhan

Recently much attention has been given to the AJAX technologies: Asynchronous, Javascript, and XML related. While none of these are particularly new, AJAX defines a newer way of using them collectively. In a narrow sense, AJAX allows a web client to be more self contained by requiring fewer round trips to the server for screen updates. AJAX techniques have been independently discovered and developed over the last few years, for instance Pacific Edge Software in Bellevue has developed what now would be called AJAX clients over the last two years. Even more significantly, they also have used meta-levels of software to generate such clients.

In a way, raw AJAX complicates system design by tossing “yet another” option into the implementation basket. Taking a more abstract architectural approach, however, presents the chance to gain control through general guidelines of the opportunities obtainable by AJAX, and more importantly, to elucidate first principles of user agent design that will endure long after AJAX has been replaced by successor and assumedly superior technologies.

There are strong parallels to the origins of Structured Programming. In “GoTo considered Harmful” Djistra argued that human perception of static program structure in its textual layout should intuitively parallel the program’s dynamic behavior during execution. In Structured Programming, the human of interest is the programmer/developer. Towards this end, Djistra proposed, with great success as we now know, to restrict rather than increase the control features of programming languages. The motive was more than merely the aesthetics of minimalism; it aimed to increase human understanding of computer behavior.

The architecture of Protocol Translating User Agents, sometimes called Service Oriented User Agents, has similar motives as a means to gain greater clarity through the imposition of design constraints. And like Structured Programming before it, the Protocol Translating User Agents approach relentlessly emphasizes the correspondence between human understanding and the behavior of networked computer systems. In the case of Protocol Translating User Agents, the participating humans of interest are the developers and the end users who form communities of shared interest. Time will tell if Protocol Translating User Agents architecture comes to have importance similar to the emergence of Structured Programming, but it may well happen.

Protocol Translating User Agent architecture begins with the fundamental question: if user agents are the mediators between the user and the network, what do they really mediate? Simply put, they convey the knowledge contained in the application protocols spoken by the network into intelligible representations for the user and transform the knowledge content of user actions into application protocols. Thus, the user agent represents the network to user and the user to the network in keeping with Tim Berners-Lee’s axiom of web architecture. In a very real sense, the application level protocols play such a central role that they become the focus point of the very meaning of network computing applications in that they represent the knowledge exchanged in the most abstract and pure form.

It follows naturally that the prime design goal for user agents is to optimize the “goodness of fit” of the correspondence between the user agent’s human oriented representations and the underlying application protocols. This architectural approach for distributed systems closely parallels the adage of the much older art and science of large building architecture: “form follows function“. Of greater interest still, the seemingly endless see-sawing debate between client side and server side design philosophies can be brought to a single balance point that avoids the excesses of so-called “fat clients” and “thin clients”. To borrow one more well worn aphorism, it now becomes possible to define the boundaries of user agent design in keeping with Einstein’s dictum that “ everything should be as simple as it is, but not simpler“.

Much current focus on AJAX emphasizes the “how” of user agent design. Protocol Translating User Agent architecture, however, emphasizes the “what” in the form of application level protocols. This is possible largely because the “why” is answered generically: expose the application level protocol in both direction between the user and the network to the greatest degree of effectiveness possible. The “where” in cyberspace, the “who” and the “when” are addressed collaboratively in the design of the application protocol whose participants include the service providers as well as the user agent designers, and quite possibly even members of the user communities of shared interest.

As such, Protocol Translating User Agent architecture is compatible with the “how” of AJAX technologies but is not solely dependent upon them. The Protocol Translating User Agent approach should outlast AJAX well into the times of new technologies when AJAX yet again simply means a kind of cleaner, or Greek hero!

But Protocol Translating User Agents present thorny security problems. Among other things, they raise the possibility of tampering on the user end and the possible creation of bogus user agents and services. They must support a level of custom tailoring for end user communities that demands a highly level of “personalization”. This strains the current Access Control List (ACL) paradigm beyond the breaking point. Many also argue that distributed systems in general break the ACL model by their very nature. The Distributed Capabilities security model provides a way forward and should be considered carefully in tandem with adopting Protocol Translating User Agent architecture. Section 3 of the working notes addresses the Distributed Capability security model.

Lastly, Protocol Translating User Agent architecture and the Distributed Capabilities security model are parts of a much larger architecture. Even in the AJAX stage, they demonstrate tremendously increased levels of dynamic composition from all over the network, particularly through the standard web page use of URIs. Not too surprisingly, this larger architecture is called Compositional Architecture. Compositional architecture can co-exist with existing Object Oriented and Relation Data models but covers design territories previously unaddressed, or poorly addressed, by either one. Compositional Architecture much better describes what we already do on the web and how to do it more coherently. Section 1 of the working notes tackles the more general Compositional Architecture.