JBI as a Convergent Communication Platform

I have a hard enough time keeping my mind straight as it is, maintaining multiple internet persona's only makes my life more difficult: a skype account, IRC, AOL, XMPP, Yahoo, email, PSTN, mobile, etc. Some clients have been doing a better job of bridging the networks from a user perspective, but this does nothing for capabilities development on the server side -- and the disparity between the networks still causes user headache.

For example, even using one of the multi-protocol chat clients, to coordinate a chat-room I need to get everyone to agree on a common protocol, everyone needs accounts, and everyone needs to be on the same "type of network". (ie. firewalls need to permit traffic to the agreed upon network)

Why?

Because there isn't a server out there capable of maintaining presence, and location information across the multiple protocols. Sure, there are lots of gateways being built (e.g. XMPP -> SIP and back), but this results in the need for nxn gateways. Any architect will tell you that you need a common normalized schema to reduce the number of necessary conversions. Then you only need to develop n gateways, each converting from the protocol specific format into the normalized message format.

Hmmmm, interesting - this sounds awfully familiar. Enter JBI.

The devil is in the details, but if we ignore them for a moment, this is exactly the concept behind binding components (BCs) and the normalized message router (NMR). Over the past six month, we've developed binding components for XMPP , SIP , UDDI , and RSS . The purpose of each of these is to convert between normalized messages and their protocol specific equivalents.

Since the BCs expose those disparate communications networks over a single "bus", this appears to be the perfect environment for convergent applications development. Thus, you could implement a single presence service, a single locations repository, etc. Finally, I'll be able to join a chat-room over SIP, while friends join over XMPP, with the entire conversation broadcast over RSS.

Now, back to the devilish details. In a previous life, I spent long hours working on SIP (registrar, presence and proxy) servers. More specifically a commercial derivative of the NIST JAIN-SIP-Presence-Proxy server. Recently we've formed a new project, Marlin to attempt the very idea described in this blog, implementing the same capabilities as the JAIN-SIP-Presence-Proxy project, but independent of the protocol.

We're putting use cases together here , and meeting to determine how all of this relates to Sailfin .

Its an exciting time to be in communications infrastructure. =)