Adam Gartenberg's Blog

Business Analytics and Optimization, IBM and Social Marketing

More details on Sametime Gateway architecture


In my post the other day on Lotus Sametime Gateway, I promised to respond to the question on why we architected the solution the way we did.  Given the comments on that post, and discussions here and here and here, I thought it might be good to step back and take it from the top.

When creating requirements for the gateway, our primary objectives were to be able to deliver the following capabilities:

  • Federation among systems in different communities using different directories
  • Policy Management (allow/disallow domains, groups, services to users/groups)
  • Logging of interactions
  • Extensibility via plugin architecture for the creation of connectors to other protocols
  • Extensibility via plugin architecture for 3rd party management, security, and compliance tools
  • Intra-domain coexistence, among systems in the same domain (community), and using the same directory

(And I do want to note that not all of these objectives are being met in the first release - for example, intra-domain coexistence among systems using the same directory will be coming in a later release.)

A few things to note on the list of objectives.  First, the goal here is federation, which goes beyond simply allowing a user to type an IM into Sametime and have that message sent out over SIP or XMPP or a proprietary protocol.  It also goes beyond allowing individuals to surface buddies from multiple IM systems in a single buddy list.  While I know that for some companies (or more to the point, many individual users), that approach might have been sufficient, we have far more customers for whom the additional elements above - policy management, 3rd party management/compliance, etc. are critical.  But even more importantly, what businesses are looking for is a way to serve up the entire directory of their enterprise users (or just those who they want to have access), without requiring that those users go and register with the public IM networks individually.  This is an important distinction. It means that a financial broker is exchanging work-related IMs as Jim.Smith@bank.com instead of jimbo123@aol.com.  And again, I recognize this may not be a universal requirement, and that this can be a particularly sticky area as the needs of individual users ("I just want to consolidate my IM clients") may run counter to the desires of the company ("I want to make sure if my employee leaves he doesn't take those personal contacts with him" or even "I don't want people talking to their friends and family over IM on company time.")

Also, there are some things that aren't explicitly called out in the objectives, but that underlie some of the requirements above and that play a large role in the architecture.  The first is that it was important for us to build a solution and federation around the open SIP (and SIMPLE) standard.  Second, keeping in mind that SIP is used for much more than just IM, we wanted to be sure that we were building a solution that could allow for anything-to-anything connections (not just Sametime-to-something), and we also wanted to ensure that in developing Sametime Gateway we were levaraging the same work that could be used to meet other requirements, such as those of telcos, which could require carrier-grade solutions scaling to the millions of users.  The goal is to execute on a single strategy for this type of capability across IBM.

So, given those objectives, how did we arrive at the gateway implementation that we did?  The reason we chose to base the gateway on WAS is because we have spent the last 3+ years extending WAS to be a first-class SIP application server.  By building the gateway on this WAS-based SIP infrastructure, we simplify our overall development, and we get to take advantage of all improvements (both performance and functionality) that occur within that platform.  The result is that we have a scalable, componentized server with a built-in SIP stack, that is designed to sit separate from any specific server environment (in the DMZ), and that is easy to extend via connectors for additional protocols or 3rd party solutions.  This is actually the same architecture we are using within IMS, and we believe it will provide the best federation/interoperability going forward.  It's also the same platform that is being sold into the telcos as a carrier-grade Service Logic Execution Environment, so that's saying something.

I want to stress that this decision should not in any way be seen as a slight to Domino; WAS provides features that we need (i.e. SIP, protocol extensibility through the channel framework, clustering via HA manager, etc).  

To address some of the other questions that have been raised in the various discussions....

One question that's come up is why it takes such a "large" application to translate between protocols when there are plugins to Trillian, Gaim, or others that have fairly small footprints (with the question being if Trillian can build a small client plugin that "talks OSCAR" to AOL, for example, why isn't it possible to build a small plugin for a server gateway).  The truth is that the gateway is actually a relatively simple application (built on WAS). The reason it feels so big is because you need WAS underneath.  There is also some complexity added in by our goals to make it highly extensible through published APIs, to support clustering, etc. (which in part comes back to what I mentioned above about a strategic statement by IBM to unify our SIP-based offerings.)  As to the question of whether Cloudscape could be used instead of DB2, I am still looking into a definitive answer on that.  My understanding is it did not scale sufficiently for larger enterprises (and beyond); I'm still trying to understand whether it could be an option in the future for smaller deployments and whether we're facing technical issues or resource/testing/support issues.

Another area I'd like to address is whether we're just repurposing "Workplace IM" (or, for the more cynical of you - trying to recoup investment in Workplace IM).  The answer is that while both Workplace IM and Sametime Gateway are built on WAS-based SIP infrastructures, these are different applications.  The Workplace IM application was not reused, as the gateway provide different functionality.  Another key distinction is that Workplace IM was built on WAS 5, which does not have as full capabilities as WAS 6.1, which Sametime Gateway is built on.

I didn't want to finish this post without revisiting a topic raised in many of the comments, which is that as an SMB they either did not have the skills or did not want to devote the resources to deploy the gateway (as much as they expected to deploy it before seeing the architecture and requirements).  I did want to reiterate that in future releases, we will be working to simplify and streamline the installation process (and we are planning to have an update to the gateway available in 1Q next year), and are also investigating an appliance (or at least a software appliance) version that would reduce, if not eliminate, the need for WebSphere and DB2 configuration.

So, 1000 words later, where does that leave us?  Hopefully with a better understanding of why the gateway is architected the way it is, and what we're doing to make life easier for you going forward.  (And if I've missed anything I have no doubts that you'll let me know!  Let's keep the conversation flowing.)  I also recorded a podcast with Chris Miller tonight (look for it later this week - update: Podcast available here) covering many of these same topics, so hopefully if I did miss anything here you'll find it addressed there, as well.