Posted by boneill42
on June 18, 2007 at 1:48 PM PDT
Java Business Integration (JBI) may prove the best environment in which to develop convergent communications applications that (once and for all) integrate the disparate networks (XMPP + SIP).
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)
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. =)