ACTive Architectures

2009-09-01

The term REST is often used to describe the architecture of the World Wide Web, following chapter 5 of Roy Fielding's dissertation. Because this architectural style has a catchy name, it tends to receive quite a bit of attention. Indeed, some people seem to think that REST is the only legitimate architectural style for the Internet, despite the fact that technologies like email and XMPP have a very different architectural style (see RFC 5598). Since I can coin catchy acronyms with the best of them, I've decided to name XMPP's architectural style "Availability for Concurrent Transactions" or ACT. The ACTive style of XMPP is quite different from the RESTful style of HTTP; in fact, it is really a presence-aware extension of the architectural style used in email for decades now. I would describe the ACTive style as follows (this text is a bit dry and technical, but that's because I've copied it from my working copy of draft-ietf-xmpp-3920bis)...

XMPP provides a technology for the asynchronous, end-to-end exchange of structured data by means of direct, persistent XML streams among a distributed network of globally-addressable, presence-aware clients and servers. Because this architectural style involves ubiquitous knowledge of network availability and a conceptually unlimited number of concurrent information transactions in the context of a given client-to-server or server-to-server session, we label it "Availability for Concurrent Transactions" (ACT) to distinguish it from the "Representational State Transfer" (REST) architectural style familiar from the World Wide Web. Although the architecture of XMPP is similar in important ways to that of the email network, it introduces several modifications to facilitate near-real-time communication. The key features of this ACTive architectural style are as follows.

  1. Global Addresses

    As with email, XMPP uses globally-unique addresses (based on the Domain Name System) in order to route and deliver messages over the network. All XMPP entities are addressable on the network, most particularly clients and servers but also various additional services that can be accessed by clients and servers. In general, server addresses are of the form "domain.tld" (e.g., "im.example.com"), accounts hosted at a server are of the form "localpart@domain.tld" (e.g., "juliet@im.example.com"), and a particular connected device or resource that is currently authorized for interaction on behalf of an account is of the form "localpart@domain.tld/resource" (e.g., "juliet@im.example.com/balcony").

  2. Presence

    XMPP includes the ability for an entity to advertise its network availability or "presence" to other entities. Such availability for communication is signalled end-to-end via dedicated communication primitives in XMPP (the stanza). Although knowledge of network availability is not strictly necessary for the exchange of XMPP messages, it facilitates real-time interaction because the originator of a message can know before initiating communication that the intended recipient is online and available.

  3. Persistent Streams

    Availability for communication is also built into point-to-point connections (e.g., a discrete client-to-server or server-to-server connection) through the use of direct, persistent XML streams between the entity that initiated the connection (either a client or a server) and the entity that received the connection (a server). Thus either party to a stream knows that it can immediately push data to the other party for immediate routing or delivery.

  4. Structured Data

    The basic unit of meaning in XMPP is not an XML stream (which simply provides the transport for point-to-point communication) but an XML "stanza", which is essentially a fragment of XML that is sent over a stream. The root element of a stanza includes routing attributes (such as "from" and "to" addresses) and the child elements of the stanza contain a payload for delivery to the intended recipient.

  5. Distributed Network

    In practice, XMPP consists of a network of clients and servers that inter-communicate (however, communication between any two given deployed servers is strictly optional). Thus, for example, the user juliet@im.example.com associated with the server im.example.com might be able to exchange messages, presence, and other structured data with the user romeo@example.net associated with the server example.net. This pattern is familiar from messaging protocols that make use of global addresses, most commonly the email network. As a result, end-to-end communication is logically peer-to-peer but physically client-to-server-to-server-to-client.


Peter Saint-Andre > Journal