JAIN SLEE for uninitiated announcement (May 10, 2008)

I have spent several days in Moscow during the long holidays, and had several discussions about this website with my friends. Despite that most of them are of computer science breed, really few do understand what this blog is about! My goal is to focus myself more clearly on the topics I discuss â€” writing thoughts down helps, â€” as well as promoting JAIN SLEE technologies.

Therefore I announce the series of posts dedicated to the very basics of SLEE. I hope that non-SLEE technicians, though advanced in programming in general, should find the matter understandable. First discussed topic will be related to SBBs, activities, ACIs and events. Stay tuned.

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.

A chance for Nokia again (April 14, 2008)

Megafon, the third biggest mobile operator in Russia, and the only operator that has deployed 3G base stations (around 30 in St. Petersburg’s city center and several more in big airports) reported a five-fold decrease in net profit after Q1 2008 (the link is in Russian only). The reason is usual for operator deploying 3G network: equipment costs increase.

Probably, new deployments will be stalled for some time.

A piece of advice for Nokia: start selling N810 WiMAX Edition not only in the U.S., see what’s happening.

SDP vs. IMS (April 11, 2008)

While browsing through some telecom-related blogs, I can see that there’s a fair amount of authors still believing that the age of SDPs, or service delivery platforms (what you could call any JAIN SLEE-based application server, for example), is just a transition phase before operators will roll out IMS. Unbelievable.

These two architectures are so deeply interweaved into each other, and so widely misunderstood, that one could give several answers to the question Is IMS architecture a successor to SDPs architecture? without being false even once. Like this:

• Yes; when IMS will be rolled out, SDP will become unnecessary. IMS will require IP-based infrastructure as well as support from the device manufacturers; when both will be in place, a new way will be invented to develop services and deliver them over SIP inside IMS
• No; IMS does not offer anything new in services delivery in comparison with SDP. IMS will serve as an infrastructure convergence point, unifying all communications inside the operator’s network. SDP should by its definition include the network abstraction layer. With IMS and its pure SIP infrastructure this layer becomes not necessary any more, whereas all other parts of SDP could be reused
• The question is meaningless; they already working together. Operators have to demonstrate new services to the customers. Too many of these services require at least IMS-like network â€” think of parallel ringing. The shift is happening smoothly, platforms coexist.

My opinion is a combination of three. Operators still could not invent a reliable profit stream from pure services, and SDPs is a good place for operators to get service development experience. Here I am talking not only about JAIN SLEE approach to SDP, but about all others, like BT’s Connected Services Sandbox based on Microsoft CSF. These are good lessons to learn, and they all could be applied to IMS â€” without any conflict of interests between architectures.

On JAIN SLEE is a Unix modeled in Java (April 5, 2008)

My ex-colleague, jNetX’s Konstantin Matveev recently posted an excellent entry in his blog about the similarities between Unix and JAIN SLEE programming models. Very interesting observation, though, and the post (as well, as Konstantin’s blog in its entirety) definitely worth reading. As a short remark that this similarity is probably not incidental, I’ll quote here the very first chapter of Eric S. Raymond’s book “The Art of Unix Programming”

[…] Unix has a culture; it has a distinctive art of programming; and it carries with it a powerful design philosophy. Understanding these traditions will help you build better software, even if you’re developing for a non-Unix platform. […] Unix programmers have accumulated decades of experience while pioneering operating-system features we now take for granted. Even non-Unix programmers can benefit from studying that Unix experience. Because Unix makes it relatively easy to apply good design principles and development methods, it is an excellent place to learn them.

← Later entries | Earlier entries →