JAIN SLEE vs. SIP Servlets: Asynchronicity is not the cure (April 24, 2008)

The first public draft version of the SIP Servlets API specification have been developed in the end of 2002, just a few months after the draft version of JAIN SLEE 1.0 API, and since then up to this very day technical decision makers in telecom companies try to make hard choice between the two.

I get requests to evaluate the applicability of these technologies often, so I have developed a generic answer for them (will come to that below). In this light the opinion of another person would become even more interesting; I heard a few of them. Now there’s one more, from my ex-colleague Kostya Matveev (I strongly encourage you to read the whole entry), and here is my comment on it.

Basically, Kostya writes that SIP servlets are stateless, which is, on one hand, is bad (this is aligned to my vision presented below), and on the other hand is good, because this allows container developer to choose any threading model of his preference. HTTP servlets containers less restricted by latency requirements enjoyed this freedom in its entirety. However, claims Kostya, send() method breaks this freedom (details are in the original post), because API requires it to be synchronous to be able to throw java.io.IOException in the case if transport error occurs.

I have to say that I am also a big proponent of JAIN SLEE approach when it comes to SIP servlets vs. JAIN SLEE debate. And basically, I do not see any problem in implementing send() method in asynchronous way, so that java.io.IOException is never thrown by its underlying implementation (we may report transport errors in another way), and the SIP message is only placed to the queue in this method. The point here is that if we’ll compare this approach to one selected in SIP Resource Adaptor for any JAIN SLEE implementation, the difference will be virtual, and using only these arguments are not enough to claim that JAIN SLEE approach is more elegant (after all, there is always a danger that some BEA developer will appear here chatting about SIP messages being masterly queued in WebLogic).

The fact that all SIP servlet’s interaction with the outer world should be made synchronous is also not forcible argument. JAIN SLEE only offers a generic messaging model, and if developers are able to implement, say, JDBC Resource Adaptor for SLEE using this model, then they could as easy develop an asynchronous JDBC framework for SIP servlets-based application (and I bet there are already some).

My opinion is that synchronicity issues could be covered by the SIP servlet container implementation. Let us not underestimate container vendors; they are also fighting with bad latency. However, the fact that servlets are stateless is something that could not be covered by sophisticated internals. Nobody in JEE world is using HTTP servlets directly, otherwise every servlet should suck all the application data out of the session object in the beginning of service(), and flush the modified data back to the session in the end of it. Frameworks like Struts significantly simplify this process, but there’s no anything like Struts for SIP servlets.

And SLEE does not even need anything like this. SBBs have CMP to maintain its state, ACI attributes for inter-SBB data exchange, and SBB tree model for activity orchestration. These are things visible for developer, influencing the end product, and, therefore, the operator’s business in general. And this is a good point where JAIN SLEE performs better.