Java middleware for telecom: JSLEE vs. SIP Servlets

I’ve read enough marketing bullshit on this topic. Now I want to reveal technical details. Everything here is purely my opinion.

That’s a natural process: then you develop a network server, you start with stand-alone monolitic application architecture, then you turn it into application server. That’s natural: you want to sell your product to companies which will build on top of it, and you want to control as much base as possible: application server is a solution. Java is so popular with middleware vendors because it is very suitable for dynamic code manipulation.

Middleware could be specific and generic. Examples of first type there are specific Servlet containers. EJB containers and JAIN SLEE belong to second type.

Then clueless people hear about “servlets”, they think that it is something very complex. Truth is that it is an abstract class with just three methods: init(), service() and destroy(). To be honest, all HTTP servlet stuff is very simple, all you have to do is not servlet-related: to understand from context what kind of link user has clicked, to interact with database, and produce tons of  boring HTML. Very much the same as in PHP. People have noticed that HTML/Java ratio is 100:1, and invented JSP on top of servlets.

The worst thing about HTTP servlets is that they are stateless. You have to restore state from context then handling every request. 

Now let’s move into telecom area. The guy who invented SIP servlets thought in this way: HTTP and SIP are similar in syntax of messages, HTTP has servlets, so let’s SIP also have servlets! They even proposed hybrid HTTP/SIP servlet applications (useless thing, IMO). Everything worked almost well, except one thing: SIP is not asymmetric protocol like HTTP, so servers need to send requests themselves, and need to answer on requests later. As result, there are method send(), which, in my point of view, completelly breaks “passive servlet” model.

Now I’m switching to very different topic, but it will eventually meet with servlets.

Let’s take a look on architecture for scalable network applications. It must handle lots of protocol messages for lots of simultaneous protocol sessions over lots of connections. How to implement it ? For only one connection you can handle incoming messages sequentally, but this is not fair: if first message requires lots of time for processing, then second message should wait, even if it will take very fast time to process it. This is called “bad latency”. So, it seems that messages should be processed in parallel. Some developers prefer to create a separate thread for each message, but truly pre-emptive threads are very inefficient in large amounts. So, recommended approach today is to use a pool of threads to process messages, resulting in half-parallel-half-sequental approach. To make it closer to parallel processing, some people invented “SEDA”: they proposed to break processing of messages into “stages” and ask thread pool to process each stage, thus preventing resource-demanding messages from blocking threads for long periods. In fact, this is just step back from preemptive threading to cooperative threading because of scalability problems. Yes, if you are developer, then you need to be human compiler and divide your code into pieces. And waiting between stages increases the average latency. But this is most “fair” solution.

SLEE is a middleware based on SEDA approach. They have noticed that logic at some stages is re-usable. For example, message parsing is required part, and it is independent of message processing logic. So, SLEE made this asynchronious communication as its core. Logical group of stages is a “service”. SEDA is just the one way to look at approach of SLEE, another possible point of view is a co-routine model of asynchronious invocation and response. But, independently of how you as a developer look at things, technical reason behind a SLEE is a better latency.

Back to SIP servlets. Does SIP container implements SEDA or not ? It doesn’t matter, because servlets don’t have state, and they must not depend on threading model. Almost. There is one thing which kills scalability. Method send() is synchronious. If message can’t be sent, container must throw an exception. This means that there could be no “stages” inside send(). Another bad thing is that SIP servlets specify only SIP part. If you need to make a query to database, you’ll make it synchronious, and thread of container will be blocked. If you make a multi-protocol application, you need also to adopt to threading model of other protocols. It gives a strange picture: all SIP stuff is specified very well, with threads, lifecycle and replication handled by stack, but all non-SIP related stuff is not specified and very unsafe.

So, what do we have ?

On one hand, we have SIP Servlets: a protocol-specific approach, with aim to cover as much functionality as possible. In order to hide transaction layer it implements proxy facility for you. It is good for beginners and for simple applications. But it demands that your servlets are stateless, it makes send() call as synchronious, it requires you to synchronize your critical sections yourself, and it doesn’t control any other network protocols you use. I don’t believe in HTTP/SIP/e-mail convergence, it is a bullshit.

On the other hand, there is a big protocol-independent SLEE, a cooperative threading framework for Java. You don’t need to synchronize your code: it is guaranteed that only one “stage” of single session will be processed at time, so common data of stages are safe. You can fork separate “streams”, and process something in parallel, then join them. Quite big framework, indeed, and you have lots of control over it. But beware: SLEE has only this model covered: protocol-processing stages you need to buy separately, or develop on your own, and there are no common standard here yet.

Can you mix SIP servlets and JAIN SLEE ? Not really. They both are complete application servers, with their own component models. What can you do ? Turn SIP servlet container into just SIP stack, and attach it to JAIN SLEE. In this way, you’ll have best of both worlds. Working a lot with HTTP and SIP servlets I have an opinion that their APIs are good, but AS model just bad.