The New Infrastructure

The biggest problem with Instant Messaging isn't that AOL wants to dominate the category. It's that most of the world only knows what AOL means by the term.

Instant messaging (IM) first showed up in early 1984 as a real-time text chat feature in bulletin board systems (BBSes). "Chat rooms" soon became standard features of AOL, Compuserve and other online services. In 1988, AOL rolled out a 'buddy list' in its own client software and later broke that off into a standalone client called AIM (AOL Instant Messenger). Other buddy/chat systems showed up in the late 90s. Excite, Yahoo and Microsoft (among many others) began to offer featured free IM clients for download, and arranged communications over the Net by way of their own proprietary systems. For a while the most successful of these was Marabilis' ICQ, which quickly became a paradigm case of success with "viral" marketing. Nearly all Mirabilis' promotion was by word of mouth. Mirabilis is now part of AOL, which is why AOL dominates conversation about the topic, if not the category.

That category includes just about all text-based live communications over the Net — between any body and any thing. That begins to put our AIM/ICQ-level of IM understanding in perspective.

Technically, IM is about two functions: presence and messaging. The first involves detecting and revealing the availability of another identity on the network. The second involves one-to-one (or one-to-few) live text exchanges with one or more present members of a list.

In enterprises where IM is widely adopted, life isn't the same for other technologies. "It changes the sociology of telephony," says Udi Shapiro, an instant messaging pioneer whose company created Lotus' Sametime IM software. Live text exchanges can invite or replace phone calls. Groups of people can get together and come to quick agreements. Naturally, IM is expected by many to play a key role in Voice over IP (VoIP) and wireless communications between handheld devices.

It's not hard to imagine what IM can do for communications between humans. The dark or gray area is communications between humans and remote machines, or among machines themselves, on an ad hoc basis — the distributed computing dream.

Combination of IM and embedded

When combined, Embedded Linux works as the device driver in the API, and instant messaging provides the framework for registration and lookup. Through the instant messenger, the client says to the server "I'm online," and the server notifies other clients of that fact, providing the path for direct communications. Thus instant messaging becomes an ideal way to set up point-to-point communications between two unknown entities.

The best working example of this arrangement is cellular telephony. The problem with that example, however, is that cell phones are physical devices. The system doesn't know the identity of the user — only the phone number and the unique identity of the phone it is assigned to. With IM you can locate the person or the identity of the device. In either case, it's a logical connection and not just a physical one.

IM is also similar to cellular telephony in its real-time nature. If you think of embedded messaging as a service, it makes no sense to have a store & forward, because you are working mostly in real time. A special purpose device doesn't have the peripheral support that a general purpose device will. Including, say, storage. There's no point to it. So in live communications, a real time connection can be established through IM.

Enter XML

XML was created to package and exchange structured data — files, blocks of text, drawings, transactions, settings, whatever — on its own terms, outside the context of the programs that produce them, and (most importantly) outside the API and protocol walls that keep services from interoperating over the Net. XML provides the basic rules for organizing content, but not for identifying it. So, while XML resembles HTML in its use of tags, it differs radically from HTML by not forcing a meaning for those tags on the data itself. Those agreements are up to those communicating within an XML framework.

A caveat. "XML doesn't provide independence by itself," Craig Burton says, "but ratehr the framework for independence. XML doesn't provide independence by itself. It provides the framework for independence. The people designing both the requestor and the responder need to have a specific agreement on how XML will be used to generate independence. This independence is not a given just because XML exists." But because XML exists, developers can design communications independently of static protocols.

This puts XML in the position of serving as a framework for dynamic protocols. A parser has to be present on both sides of any device dialog, or any element that participates in that infrastructual framework, but outside those parsers, at the ends of the communication line, is where the action happens. We begin to see the possibilities in the obvious conversation that can take place between a browser and an embedded Web server. This is what the Cobalt Qube provides through both embedded Linux and embedded Apache.

Now combine XML and IM on EL

Instant messaging takes dynamic communication to the next level — especially in the context of ubiquitous Embedded Linux.

Instant messaging allows real time (or real-enough time) registration, connection and point-to-point information exchange between logical entities.

To simplify this, let's look at four conceptual layers (see graphic). Everything below the application layer is infrastructure, much of which is logical.

But the fact that it's logical doesn't make it dynamic. In a distributed real time world, logical entities need to establish connections on an ad hoc basis. For that you need a framework for dynamic relationships. That framework needs to allow the identities to register themselves so they can be found, and so they can find other registered identities.

Today AIM and ICQ are doing this, but they use their own protocol, not anyone else's. And they have no interest in having anybody else play in their game, which is about holding eyeballs still for advertising, not any other kind of service. It's also why they have such a hard time opening up.

In fact, it shouldn't matter much whether AOL opens its IM protocols. What we need to do is get past the need to see static protocols as a gating issue. XML gives us that vision, because it gives us the basis for a dynamic protocol framework, because it lets us carry out dynamic relationships outside the boundaries of static protocols.

Enter Jabber

Jabber is an open-source Instant Messaging platform that is deployed in much the same way as email. Core messaging functionality is at the server, which passes messages between clients either on the server or on other servers.

What makes Jabber potentially explosive is its XML framework, because it opens the possibility of creating dynamic relationships outside static barriers. Its structure supports the ability to discover and establish a relationship between two independent entities, and the natures of those two entities, in real time, dynamically.

Jabber provides an additional set of XML based services that are not available in any other service set. One no longer needs to establish a fixed protocol to access services like file, print, security and directory.

Burton adds, "With a fixed protocol the consumer and the provider have to freeze themselves in time and wait for the next innovation — and then they might not match. Independence while maintaining a relationship is the virtue here, and XML provides that. And it makes IM sweet because it invites additional and more advanced IM services emerge. XML provides the framework for access to all of those, independently of each other."

In walks Jabber, a new open-source movement that just might become an entire new layer of Internet infrastructure for providing near-real time messaging. The world has store-and-forward messaging, its email, how Jabber differs is that it combines the concepts of ‘presence and availability detection’ with an engine for XML message routing. "Jabber’s use ofXML as a technology which encapsulates all Jabber messages is significant because it is an open-standards way of accommodating a dynamic protocol, one which can evolve or morph in ways not even today imagined. " says Andre Durand, General Manager of Jabber.com. 'XML is inherently dynamic and is quickly becoming one of the main building blocks of interoperability on the net."
In some respects, we’re entering unchartered territory, but let’s just assume for a moment that we have an explosion of net aware ‘smart devices’. Many of these devices are going to have a need to communicate with other devices, or send messages of status, as well as receive instructions or configurations from a PC on the net, or another device. What better way to do this than via XML documents. XML provides a dynamic, standards based framework for all of these devices to start talking. Almost by definition, if these devices were XML aware, they would be interoperable with nearly everything being built on the Internet.
With Jabber, XML messages become a standards based ‘envelope’ or container that the Internet is increasingly able to understand. The contents of that envelope are infinitely flexible, and contain the passports by which the envelope passes protocol bottlenecks — including the complete absence of protocols. By building a framework in XML for your messaging architecture, what you do is define a standards and open way to send messages.

XML is designed to carry "structured" data. But that data can change constantly, and — by design — can define the terms by which it is understood. When communications become "instant" (which in practical terms means near real time), there is nothing to stop relationships from being defined and changed whenever necessary. Including any incumbent protocols.
With Jabber, any two identities, whether human or machine, can send and receive realtime messages that contain pretty much anything, and do so in a structured way, thanks to XML. Although Jabber was originally envisioned as a distributed, XML aware instant messaging platform, its simplistic and fundamental view of how to combine presence with XML document routing has it in an ideal position to become much more than just another instant messaging system, instead, it could become infrastructure for messaging enabled embedded applications. It becomes the way they communicate through the Net — whether with each other or with apps on the PC (which are already talking to each other).

This illustration depicts a purpose-built Jabber client/server platform for routing XML data in realtime. Note that the underlying messaging infrastructure and protocol is XML, and not a proprietary messaging protocol. Messages can be sent from device-to-device, device-to-PC or translated from any of the above to other networks and protocols. The dynamic, self-determining nature of XML makes this infrastructure dynamic: in other words, to accommodate constantly changing relationships between logical entities on the Net.

Think of Jabber as an instant messaging platform with the ability to packetize messages in XML documents — in effect, data transport. You can instantly communicate with all of the infrastructure on the Net that's able of parse and act on XML. Think about the new XML databases that are designed to parse XML and store structured data or documents. Anywhere XML is the preferred way to receive and send information, we have infrastructure already conformed to instant messaging.

An example.
I can envision a day when all of our devices and appliances will be accessible from PCs or more likely, a wireless net enabled device.. One application we’ve been contemplating recently would connect Jabber with X10 and their API’s for controlling power to devices in the home.

Basically, all we would need to do is build a ‘bridge’ between Jabber and the X10 server (which controls power to appliances etc.). Then, using a slightly modified Jabber client, or perhaps even the same client I use to send instant messages to friends, I would be able to see if my lights at home were on or off, and control them right from my PC desktop.

— Andre Durand, General Manager, Jabber.com
Think of Jabber as a ubiquitous XML router, streamlined for (and by) embedded Linux — or any other device-driving OS that supports XML-based messaging. While email is technically capable of routing XML documents, it lacks awareness of presence, which is key to Instant Messaging in general. This makes Jabber something of a new message transport breed.
The breed apart we're suggesting is expanded Internet infrastructure: just like the Internet we know today, but with a vast new range of real-time dynamic relationships, routed through XML.
In simplest terms Jabber can be seen as a framework that combines presence with XML routing, plus a whole suite of robust client-side libraries on multiple OSs including embedded Linux. Think of it as an SDK for connected messaging to the device world. This is why it is being adopted by embedded Linux companies such as Lineo (which is now working with Jabber.com to include Jabber in the Lineo's Embedix SDK).
Embedded Linux opens an avenue for countless developers to start imagining what can be done beyond applications on computers. It's an avenue leads to everything else. It's the avenue Linus has been pointing down ever since he led the way by joining Transmeta.
The next big step should be wireless, of course, because it removes the last of the physical hurdles to logical connections between everything.

This shows how new and emerging tools (like XML optimized databases) can be used to leverage XML communications streams, and to provide new services. The fact that all communication with Jabber is via XML documents means that emerging XML tools & services can be easily 'plugged' into the message stream carried by Jabber.
Extrapolate that, and you've got a device driving framework for the known world. Because it is now quite simple for you, or a contractor you hire, to program your home. You can operate, and receive notification about, all the home electronic conveniences you already have: your security system, your lighting, your sprinklers. You can also program the devices to tell you if they're on, functioning and ready to receive instructions. So the concept of presence applies in more than one direction. Two way conversation that includes presence is Jabber infrastructure on a common XML framework.

(THIS PARAGRAPH IS REDUNDANT)
The advantage of XML is that it's text, plus a structured dynamic framework for what you put in that text. So you can add an XML tag to control the light switch. A novel feature of XML is the DTD — the Document Type Definition. With DTDs, you get to specify what type of document this is, inside the document. This allows an infinite variety of tags. The real estate industry, for example, could create a tag called "price." Everybody in the real estate trade can know what that tag means, and program their applications accordingly. Anybody can build a DTD and publish it, which makes the framework especially flexible. Businesses and communities of interest and practice will develop repositories of DTDs, from which your XML application can employ whatever DTDs it requires. But the information defines itself.
This is a hard concept to understand in a world that has known nothing but rules since the beginning. When devices do this, it's very natural and simple. When you broaden your scope to all devices, computers included, talking to each other on their own terms, you begin to get the excitement we're starting to feel here.
For Linux developers, it opens the world in two directions: 1) linux now operates in, and drives, virtually any kind of device; and 2) protocol-free and dynamic relationships can be created and improved on a constant basis.
There is a lot left to be done. There are enormous directory and security issues left to resolve, and those are just two of the most obvious issues. But we are at least in a much better position to resolve them.
When we do, the distributed computing dream will be real. And we'll have a whole new world, in one swell bang.

In the plate tectonics of the industrial world, Jabber is the spreading center under the sea that raises up a whole new continent. It's not a large and ancient continent like PCs. Universal messaging in the PC world has all kinds of conceptual entailments (mainly, it's understood as email). But in the embedded device world, it's brand new. It also conceptually subsumes the world of devices we call PCs.

On a percentage basis, little in the traditional embedded world is Net-ready or Net-enabled. Most of it has been developed within an arcane technology, market, processor, OS platform or development environment. It was also developed inside the concept of protocols as a plain necessity.

"Jabber uses XML because it accommodates change," says Andre Durand, General Manager of Jabber.com. 'XML is inherently dynamic and interoperable."

If the real time device world, using embedded Linux — or any operating system, for that matter — using XML methodology for communications infrastructure by definition makes it interoperable with everything now being built on the internet.

This shows a complete picture of how the Jabber client/server system provides an end-to-end connected messaging infrastructure for people wishing to develop instant messaging applications or to provide IM services. Note that it is XML, and not any kind of protocol, that provides the basic infrastructure. The dynamic, self-determining nature of XML makes this infrastructure dynamic: in other words, to accommodate constantly changing relationships between logical entities on the Net.

With Jabber, any two identities, whether human or machine, can send and receive instant messages that contain pretty much anything, thanks to structured XML. Jabber is in an ideal position to become infrastructure for all embedded applications. It becomes the way they communicate through the Net — whether with each other or with apps on the PC (which are already talking to each other).

Think of Jabber as a way to packetize messages in XML documents — in effect, data transport. You can instantly communicate with all of the infrastructure on the Net that's able of parse and act on XML. Think about the new XML databases that are designed to parse XML and store structured data or documents. Anywhere XML is the preferred way to receive and send information, we have infrastructure already conformed to instant messaging.

With Jabber, the XML format becomes a standard envelope that the Internet understands. The contents of that envelope are infinitely flexible, and contain the passports by which the envelope passes protocol bottlenecks — including the complete absence of protocols. By building a framework in XML for your messaging architecture, what you do is define a standard way to send messages.

An example. You've got X10, an existing open API for controlling powered devices in the home. X10 has an open API. I can see Jabber developers writing an agent gateway to X10.
So let's say we've got a computer running X10 server running to a light on my desk. On my workstation I've got a Jabber client with five buddies, and a group called "My Home." Below my home I have "Light Switch/Living Room." I just sit there and turn my light on and off with a task bar on my desktop.

I just send an XML message from my workstation client (which doesn't have to be Jabber, but might as well be) to a Jabber server, which translates it into a native X10 message that says "power up that switch." In the course of this we've demonstrated XML's and Jabber's ability to bridge protocols, which both were born to do.

— Andre Durand, General Manager, Jabber.com

Think of Jabber as a ubiquitous XML router, streamlined for (and by) embedded Linux — or any other device-driving OS that supports XML-based messaging. While email is technically capable of routing XML documents, it lacks awareness of presence, which is key to Instant Messaging in general. This makes Jabber something of a new message transport breed.

The breed apart we're suggesting is expanded Internet infrastructure: just like the Internet we know today, but with a vast new range of real-time dynamic relationships, routed through XML.

In simplest terms Jabber can be seen as a framework that combines presence with XML routing, plus a whole suite of robust client-side libraries on multiple OSes including embedded Linux. Think of it as an SDK for connected messaging to the device world. This is why it is being adopted by embedded Linux companies such as Lineo (which is now working with Jabber.com to include Jabber in the Lineo's Embedix SDK).

Embedded Linux opens an avenue for countless developers to start imagining what can be done beyond applications on computers. It's an avenue leads to everything else. It's the avenue Linus has been pointing down ever since he led the way by joining Transmeta.

The next big step should be wireless, of course, because it removes the last of the physical hurdles to logical connections between everything.

This shows shows how new and emerging tools (like XML optimized databases) can be used to leverage XML communications streams, and to provide new services. The fact that all communication with Jabber is via XML documents means that all new XML tools/services etc. can be easily 'plugged' into the message stream carried by Jabber.

Extrapolate that, and you've got a device driving framework for the known world. Because it is now quite simple for you, or a contractor you hire, to program your home. You can operate, and receive notification about, all the home electronic conveniences you already have: your security system, your lighting, your sprinklers. You can also program the devices to tell you if they're on, functioning and ready to receive instructions. So the concept of presence applies in more than one direction. Two way conversation that includes presence is Jabber infrastructure on a common XML framework.

XML is designed to carry "structured" data. But that data can change constantly, and — by design — can define the terms by which it is understood. In essence this creates a standards-based framework for dynamic relationships between communicating entities on the Net. When those communications become "instant" (which in practical terms means near real time), there is nothing to stop relationships from being defined and changed whenever necessary. Including any incumbent protocols.

The advantage of XML is that it's text, plus a structured dynamic framework for what you put in that text. So you can add an XML tag to control the light switch. A novel feature of XML is the DTD — the Document Type Definition. With DTDs, you get to specify what type of document this is, inside the document. This allows an infinite variety of tags. The real estate industry, for example, could create a tag called "price." Everybody in the real estate trade can know what that tag means, and program their applications accordingly. Anybody can build a DTD and publish it, which makes the framework especially flexible. Businesses and communities of interest and practice will develop repositories of DTDs, from which your XML application can employ whatever DTDs it requires. But the information defines itself.

This is a hard concept to understand in a world that has known nothing but rules since the beginning. When devices do this, it's very natural and simple. When you broaden your scope to all devices, computers included, talking to each other on their own terms, you begin to get the excitement we're starting to feel here.

For Linux developers, it opens the world in two directions: 1) linux now operates in, and drives, virtually any kind of device; and 2) protocol-free and dynamic relationships can be created and improved on a constant basis.

There is a lot left to be done. There are enormous directory and security issues left to resolve, and those are just two of the most obvious issues. But we are at least in a much better position to resolve them.

When we do, the distributed computing dream will be real. And we'll have a whole new world, in one swell bang.