Translating between otherwise incompatible networks

This is the most common definition given of a gateway in the telecommunication context:

A gateway is node that translates between two otherwise incompatible networks or network segments. Gateways perform code and protocol conversion to facilitate traffic between different architectures.

On the ground of this definition, the application that IBM has built on its Websphere J2EE server for Sametime is effectively a gateway. For that exact same reason, I believe that a very substantial leap of faith is required to envisage that it could lead to a multi-protocol presence server.
Fom the information available, the gateway is an application build on the JSR-000116 SIP Servlet API. It is in its way following a similar architecture of what IBM tout as the Websphere Presence Server. The SIP Servlet API is an attempt at leveraging developers' knowledge of HTTP web containers and extending it to SIP. On paper this is a sensible idea. In practice it has a few drawbacks.

• First, it is entirely based on the SIP protocol, which means that applications built on top of this technology will be SIP applications. As such, the SIP servlets are designed to process SIP requests and return SIP responses.
  That somewhat restrict the scope, as each network protocol has very specific characteristics which are rarely though of as "universal". Moreover, not every presence protocol uses a request/response paradigm in the way SIP does. XMPP for example uses simple notification packets to signal modification in presence sates, without requiring these packets to be answered.  In that respect, it becomes more difficult to mold XMPP into a servlet paradigm in the way it was possible with SIP. Consequently, the advantages expected from a common programming paradigm become somewhat blurred.
• Second, it relies on a J2EE server to run. One can argue that it is a proven robust architecture. I would simply say that J2EE servers were not invented to provide solutions to real-time communications problems, but rather to bring solution to transactional application problems in the enterprise. The table herewith summarizes the differences between the two contexts.

All in all, if the IBM gateway had been implemented using a more appropriate application server such as a JSR 22 JAIN SLEE API implementation, I would have been tempted to take the leap of faith. Unfortunately, this gateway architecture prohibits any use beyond bridging between SIP and other protocols. To be fair, the same inability applies to the equally shortsighted approach taken by Jabber Inc. A solution that only sees the world through the eyes of a particular protocol will always leave us far from what is necessary to build a multi-protocol presence server. For the simple reason presence encompasses more than just protocols…

Technorati Tags: XMPP, SIP, Presence, Antecipate