Americas

  • United States
by Joe Hildebrand, special to Network World

XMPP transports presence data

How-To
Mar 08, 20044 mins
Messaging AppsProgramming Languages

Businesses increasingly require real-time interaction among people, applications and devices that span many networks. Extensible Messaging and Presence Protocol offers a way to route context-sensitive data among a complex interconnection of nodes.

XMPP is an XML streaming protocol for presence and messaging routing. Recently ratified as an IETF standard, XMPP serves as the basis for the Jabber instant-messaging system and provides a secure but easily programmed language for linking diverse networks.

The core of XMPP routing is an internationalized logical addressing scheme that is best represented as node@domain/resource. In the Jabber IM system this scheme is referred to as the Jabber ID (JID). The domain portion can be looked up in the DNS, similarly to an e-mail address. As in Simple Mail Transfer Protocol, servers (the domain portion of an SMTP address) connect with one another on behalf of users (the node portion of an SMTP address). In XMPP, the node portion can denote an IM user, an application or a service. The resource portion is a connection identifier that lets a single user be logged on multiple times simultaneously.

When nodes connect to a server, they authenticate using credentials from the local directory system, specify a resource and tell to the server to announce their presence to subscribers (for example, the buddies on one user’s roster). Servers find, connect and authenticate to one another, letting any node connected to the community talk to any other node regardless of their home server (domain), as long as no privacy or business rules are violated.

Each XMPP stanza is a chunk of XML structured data that is addressed to a JID. Each stanza type can be extended with any properly name-spaced XML structured data. The Jabber Software Foundation (JSF) acts as a standards body for these extensions, much like the World Wide Web Consortium standardizes Web formats. But any organization or set of trading partners also can decide on de facto formats as needed.

XMPP serves as a universal transport layer for XML structured data. It embeds presence and context sensitivity into that data, which lets the data be routed efficiently to the most appropriate resource.

The protocol is layered in such a way that it allows maximum simplicity of implementation for clients. For example, one of the extensions the JSF provided is a specification for gateways to other IM systems. A client can use XMPP to talk to any IM vendor’s system for which such a gateway exists. This simplicity of implementation has fostered a large open source community and many interoperable commercial implementations of XMPP.

While IM interoperability is a hot topic, another useful benefit of XMPP is enabling real-time communication of presence information across applications.

For instance, a CRM or other enterprise application can appear as a client to an XMPP server. At the discretion of the administrator, other entities can know the presence and availability of that application to receive and process specific data. Using the XMPP network as the common transport mechanism, an application residing in one organization can – within the confines of the governing business rules and logic – efficiently communicate with an application or person residing outside that organization.

One example is a CRM application using XMPP to dynamically move data to the most appropriate and best available resource. This might be a customer approval form sent to a cell phone, or the data associated with an escalating trouble ticket moved from front-line support to an available support resource in real-time.

XMPP already has thousands of deployments. The standard has gained significant market traction because it is inherently open and clear. Native XML design also provides developers and architects with more options to build the interfaces, business rules and logic that will let their legacy and emerging applications communicate with each other.

Hildebrand is chief architect at Jabber. He can be reached at jhildebrand@jabber.com.