An Identity Based Network: Jabber

James and I had a briefing with Jabber this morning. I hadn’t dug deep into their tech, so it was great to get my fill. Their style was very breezy: they didn’t have a PowerPoint because, frankly, they didn’t need one. Instead, they had a solid story: Jabber XCP is a for pay server that gives you a platform for realtime XML transfer. Throw in some XMPP standardization, and you’ve got an IM network. And there’s one in a box if you’re into that.

There’s plenty of discussion we could have about the business side of Jabber, but this post is focused on the technology side of things.

IM

Ostensibly, Jabber the company is an IM network provider. An IM network can be boiled down to:

• a way of identifying and authenticating users so that you know and can trust you know who you’re talking with,
• keeping track of the locating and “presence” of those users so that you know where to send IM messages and if the person is even there
• the mechanisms for data to get sent from one node in the network to another so that people can chat, send pictures, audio, etc.

Identity Networks

IM is a great technology: even the simple data of knowing when someone is available is valuable in the workplace, not to mention being able to securely chat with anyone on the net. What caught my attention, however, were the non-IM uses for the networks Jabber creates. You might call them “identity networks” in the sense that a node’s ability (a person, program, etc.) to attach to the network is tied to that node identifying itself and providing some degree of information about it’s ongoing state. On top of this, you use XML as the container for data to send over the network: the metaphor is that the nodes send enevlopes of XML to each other, where the envelopes have basic routing and descriptive information about the contents of the envelope.

Sidenote: Webservices and The Web 2.0 Monoarchitecture

This simple notion of sending XML in envelopes that the network is intentionally too stupid to understand or care about was the early promise of web services…which has expanded into spending too much time worrying about what’s in the envelopes, how the envelopes could “talk” to each other, and…well, you get the idea: it got complicated. Commities were formed. And the KISS people forked the whole thing into REST and simpler XML over HTTP patterns.

What that group of good enough programming people realized was that you could either (a.) spend a lot of time coordinating with people (outside and inside your organization) about what the XML would look like and how you were going to tranfer it, or, (b.) you could just use HTTP GET and POST to send over simple XML and get your product out the door immeditly. Of course, this results in a lot of non-standard data formats. But, the formats are kept so simple that figuring them out takes very little time without any fuss about programatic-level, semantic compatibility. Thus, the concept of a mashup was born and thrives.

So, when it comes to XML over HTTP: problem solved (in the sense that people are working on solving the problem ;>). Indeed, after considering the use of a Jabber network as a way to shuttle XML from point to point, I realized that the Web 2.0/AJAX crowd is terribly monoarchitectural when it comes to HTTP. For much of that thinking, HTTP is all that exists as a protocol and network. Having one protocol whose ports are “always” open on firewalls and is implemented by one of the most solid pieces of middleware ever is nothing to get all snarky about. Nonetheless, it’s still one protocol.

Using the Identity Network

The features that an identity network provides could enhance many existing applications and create several new ones. Once your system can establish authenticated connections between nodes, transfer XML between those nodes, and then federate that network with other networks (enabling nodes in network A to talk with nodes in network B), you have a mini-Internet with identity built in to the core API.

Presence: From the Simple to the Pie-in-the-sky

On top of that you have presence. Presence is really 3 pieces of information about a node in the network (with more possible, of course):

1. Is the node available?
2. How is the node available? (Busy, Idle, In a Meeting, etc.)
3. For how long has the node been in the current state.

(Arguably, the 3rd isn’t such a big deal, but I’d rather have a list of 3 things than 2 ;>)

Though presence is a a simple piece of information, it makes possible many interesting and even complex person-computer interactions because it creates a richer context. Presence is something of a missing component when it comes to making the computer be smart. Not “smart” in the AI sense, but in the sense of, “why didn’t the damn computer do the obvious thing? why do I have to tell it what to do?”

For example, if I haven’t touch my computer in two days, chances are I’m on vacation or sick, so why can’t my email client auto-reply to people that I’m not currently answering emails. Or, to use a better example that Jabber gave us, if I set myself as Do Not Distrub in my IM client, why doesn’t my phone go into DoD mode as well?

What presence lets you do is better communicate to software the current disposition of the user: the binary here/not here and the more complex and declarative “Busy,” “Happy,” or “Idle.” This makes it possible to have a two way conversation between a the computer and the user, allowing the computer to be less reactive (users tell it what it wants) and become more active (“I see you’re in a ‘bad mood,’ Dave. Shall I play some uplifting music?”)

Systems Management

Dreams of “computers that finally do stuff for us” aside, there are some very practical applications for an identity network in the present. As many of you, dear readers, will recall, I was quite enamered of JXTA a couple years ago. Granted, I never actually did anything with it, but the idea of an abstract peer-to-peer network with auto-discovered and coordinating nodes seems like an obvious fit for much of the agentless monitoring work I was working on at the time.

A Ready Made Network Layer

Aside from the self-orginizing aspects (which were the most interesting for applying JXTA to systems management), the kind of identity network that Jabber enables evokes in me much of the same excitment that JXTA did in the area of systems management. (Yes, that’s how dorky I am: I get excited about systems management.)

In low-level systems management apps, you’re obssed with getting chunks of data from point A to point B, across firewalls, hetrogenous systems, at different intervals, levels of reliablity (depending on how much customers pay ;>), and scale. Allowing as many different types of data into your system is key to enterprise-level success in systems management: you can’t exclusively monitor Windows, Cisco, or even Linux. You need everything.

Now, systems management folks have spent a long time solving, re-solving, and re-solving again that problem. The last, and still most wildly successful standard was SNMP, and that was way back in the 80’s. Needless to say, it’d be worth another go at the low level mechanism to get systems management data from point A to point B (perhaps routing through point C). A scheme that used a hefty dose of that Web 2.0 KISS attitude (which was present in SNMP, despite the complexity that ASN.1 and UDP have in hindsight compared to XML and HTTP) and something like a Jabber network (which is multiplatform, authenticated, and secure) would be very interesting.

The advantage of piggy-backing on those two concepts is that (a.) they exist, (b.) they’re simple, and, thus, (c.) they’re easier and quicker to use, both for the systems management developers and the developers who’re building on top of the platform.

Presence and Business Processes

One valuable systems management task that an identity network would enable would be feeding the presense and other declarative data into a CMDB. The identity behind the node doesn’t have to be a person: it could be a computer, an application, or that holy grail of systems management, a business process, aka, a transaction.

Everyone’s favorite transaction is buying a book on Amazon:

1. A person searches for a book.
2. The system looks through it’s catelogs to find books.
3. The person finds the book and adds it to the cart.
4. The system saves the book to it’s databases.
5. The person initiates buying the book.
6. …
7. The system gathers and verifying the credit card card info.
8. etc.

The end result is a very ephemeral idea of a business process that spans many systems and web requests, or “time” to generalize it. In other words: it’s hard to model and track a business process because there is rarely an “entity” in the system that represents the business process.

Systems management is very good at monitoring all those indepent things, but the next step is to stop caring (so much) about all those little things, like CPU, and start caring more about the business processes instead. Depending on how much customization you want to pay for and how much cultural change you want to go through, you can get very close to achieving that goal.

Something to Point At

Now, what’s interesting in this context is thinking of the business process as a node in an identity network. Once the business process begins, it “logs in” to the identity network, giving the business process a first order existence in the system. That is, where your system previously didn’t have “something” to point at as the business process, it now has the identity in the identity network in the same way that an IM system can point at each user as the “something” that backs the identity.

As the business process moves across systems — accessing data in the databases, verifying the credit card, all the way down to fullfillment in the warehouse — it (now that there is an it) — can log in to the identity network and update it’s precense: I’m doing OK here in the DB…I’ve been stuck in credit card verification for 5 seconds…now I’m down in the warehouse…

You Can’t Track What you Don’t Model

Not only have we used the identity network to create an entity to represent the transaction in the system, but now we have full tracking of that entity as it moves through the system. Indeed, we can even layer on simple performance monitoring tracking how long it spends (according to presence) in each part of the system. Then, of course, you have more data to feed into CMDBs, other reporting, and auditing systems. And with more data in those systems come more higher level functionality you can perform over and with your IT…which means more reasons to buy and sell CMDBs.

You can take this basic idea of using an identity network to create a tracked identity for an otherwise ephemerial thing and apply it to other cross-systems entities like help desk tickets, SLAs, business applications, and non-systems management concepts like the relationship a customer has with a company. To make it more interesting, you could mix in presence info from actual humans and get some interesting data mashups as a result (maybe too big brothery to be sellable and actually use, of course).

Events: Publish/Subscribe

On pattern of software design is to use “events” to coordinate among different systems or sub-systems. Events are messages that originate from some source and eventually are received and reacted to by some interested party. This is a publish/subcribe model, where the sources publish events and the consumer subscribe to those events.

The most interesting features on top of a publish/subscribe model are:

1. Does the event system guarantee that it will deliver messages to subscribers? Either it’s guaranteed delivery, or fire-and-forget.
2. Does the event system let you create transactions around events? If a subscriber receives and event, and then something goes wrong with processing that event, the event system will somehow react to that bad state. For example, if a credit card is invalid, the warehouse won’t ship the book.

Additional technical discussion aside, an identity network is almost a 1-1 map to an publish/subscribe system; really, you say that an identity network is a type of publish/subscribe system. Particular implementations can answer the two questions above differently, but the underlying concept of nodes “chatting” with each other (publish each line of chat to individuals or everyone in a chat room) fits well.

What’s encouraging about the Jabber model is the emphasis on keeping the client end as simple as possible and the low barriers to entry that having both an open source alternative and an open standard create.

Calandering

If the notion of presence is extended into the future tense, it could encompose the idea of “where I plan to be at such and such times in the future.” This is a direct route to solving the cross-platform calandaring problem, at least when it comes to knowing when someone is free or busy, which is required to coordinate scheduling people’s time.

This problem doesn’t exist if you and the person(s) you’re interested in use the same calandering system (Exchange/Outlook, iCal, etc), but it’s a nightmare if the parties involved aren’t silo’ed.

Some Assembly Required

None of the above is going to happen out of the box with Jabber (open source or commercial). There’s still plenty of programming that’d need to be done. However, success in software is always about delivering as soon as possible and, recently, delivering as open a system as possible. Using architectural strategies like XML over HTTP or something like Jabber as an identity network have the potentials to speed up development and are certainly two of the most transparent ways to program. Blending the two mindsets could prove to be even better than doing one or the other.

Companies like Jabber that are providing these components also have new revenue streams to pursue if they can convince the development community that they can take care of providing an identity network. Youthful coders enjoy building their own, but the more seasoned ones who have TiVo waiting at home are eager for free or affordable stacks that simplify the “boring” parts (like networking) of their software. As noted above, the Web 2.0 camp is fixated on using HTTP as the only protocol/network: a widening of that fixation to include things like XMPP would create a larger market for Jabber and others.

Disclaimer: Sun and Microsoft (some of whose product are mentioned above) are clients, while Jabber, Cisco, and Apple (iCal) are not. And, I might as well throw in that I used to work for BMC.