Originating and terminating triggering in IMS (January 18, 2008)

Everyone making even a short insight into 3GPP’s IMS specifications could notice the significant amount of “free space” left by committee for considering different implementation approaches. Release 7’s 24.229, for example, says nothing about the way to detect originating and terminating triggering by SIP application server, when triggered by S-CSCF over ISC. Usually it is implemented using the parameters in the Route header and different IMS cores are doing this in different ways.

Fraunhofer FOKUS’ OpenIMS Core does simple:

and d here stands for “direction”: originating or terminating.

Huawei’s IMS Route headers look more sophisticated:

ORIGLGID points us to the originating leg here.

And Motorola’s IMS is my personal favorite:

Note that IMS core here informs application server, not itself about the triggering direction. This is what I call developer oriented approach.

WiMAX in Moscow — a 3G replacement? (January 11, 2008)

CNews reports that Orange Business Services and Synterra are going to install the Mobile WiMAX (802.16e) network in the Moscow region. Smart move, given the constant delays in 3G network deployment there (Russian military ministry owns the frequencies required for 3G, and their handover to telcos turns to be a never-ending story).

Despite being very spoiled with low broadband prices (starting at just €8,5/month for the unlimited Internet access), Muscovites are always eager to try new shiny advanced gadgets. Given that it make sense for the vendors to update their product lines soon. Motorola, Samsung, anyone?

JAIN SLEE profiles (December 24, 2007)

I promised to write a separate post about JAIN SLEE profiles recently. Basically, a profile specification is a separate deployable entity in SLEE, dedicated to deal with the wrinkles of the data provisioning, administration and retrieval. Data itself is represented with profile tables and profiles — one can think about these as about database tables and rows in them. In JEE world nowadays, really few applications deal with the persistence directly (be this database-based or any other); most of the solutions rely on O/R-mapping frameworks, like Hibernate, or universal persistence layers, like JDO. SLEE goes even further in this direction.

When profile is deployed, SLEE generates the actual implementation of the CMP data access methods (actually, not only these, but we’ll leave these details out). This operation is similar to load/compile-time instrumentation in most Java persistence frameworks, however is not completely the same. This is the point where SLEE application server benefits from the fact that it does not have to be as generic as JEE application server: generated implementations tightly bound to the internals of the SLEE; generic approach of the JEE is sacrified to the performance and throughput. At the moment of execution, SLEE does not actually query the profile tables in the sense as JDBC-based software does this. The data is already there, in the memory of the JVM, preloaded. Profile specification contains, along with the the CMP interfaces, the interfaces for data management. They could be JMX-based, and may represent different slices of data in comparison with the CMP interface itself (have a look at the section 10.16 of JAIN SLEE 1.1 specification to see how this done). Before the SLEE service is being activated, this management interface is used to populate the profiles, and this task is similar to the routine SQL INSERTs execution before activating JEE application.

So, in SLEE everything is getting done by SLEE itself. Components lifecycle is managed by SLEE. Transactions are demarcated by SLEE. Persistence is maintained by SLEE. This hyperspecialization allows SLEE to be this effective as it is.

At the end the story about my experience with profiles. In different times we were using different models for persistence of provisioned data in different projects. In one of them this was achieved by using in-memory TimesTen backed by the Oracle server. Performance was acceptable (TimesTen is capable in keeping millions of records in the memory and performing thousands of queries per second, as well as good SLEE profiles implementation), however JDBC driver was not flawless: stopping and restarting TimesTen during operation caused all the threads performing queries to be blocked for 30 seconds. Incoming calls were silently rejected. This is the thing that could never happen with native mechanism like SLEE profiles, and this is why I like it.

This is the last entry in 2007, see you later in new year!

OpenCloud tops share their JAIN SLEE experience (December 16, 2007)

My hosting company have been visited yesterday by two important people in JAIN SLEE world: OpenCloud’s Charlie Crighton and Dave Ferry. They made one-day workshop (wow, that was the first workshop with CTO in my life!) sharing their ideas and experience on building services and service frameworks in SLEE.

In two words: that was intense. When you meet people like them, you always got inspired by the energy which is spouting out of them. The overall result of the workshop is too wide to fit in one post, but I’ll try to summarize points which I consider to be the most important (and some of them were discussed during the coffee breaks!):

• SLEE specification is special in the Java world. The most commonly used parts of its nearest neighbour — the JEE specification — are JDBC and servlets, or around 20% of the specification volume, whereas JAIN SLEE specification are used by everyone almost in its entirety. A good sign of well thought-out framework. Because of that SLEE never needed anything like Spring, and there’s no such popular thing as stateless session bean in SLEE;
• SLEE profiles are by any means a great thing; I’ll dedicate a separate post to it later (UPDATE: done already);
• Generic service framework, which could be potentially developed using SLEE may take any form, e.g. it could be similar to Sun’s Collections API, to C++’s STL, or to Java Swing. Platform itself does not force any particular programming style;
• Service Building Blocks, or SBBs, being the ideal location for protocol state machines, along with SLEE infrastructure tying them together make SLEE-based application server an ideal candidate for working in IMS

Suming all this up: thank you guys and hope to see you again!

Administrativia (December 9, 2007)

My name is Sergey Mikhanov, I will be your host at this site.

My job is related to networks and how those are used to actually connect someone to somebody, while my work is essentially defining the meaning of all network technologies in people’s lives — not excluding mine. I started this blog to arrange the information bouncing around and inside me, first of all for myself, and second, to feed someone else’s eyes and head.

This food might be boring or provocative sometimes, and this is solely determined by the fact that it is a reflection of one person’s knowledge and opinions.

Welcome.

← Later entries