Service delivery platforms in the age of liberal telecom (February 15, 2009)

This year’s MWC is only one night away. The article below was about to appear as sponsored editorial of MWC Daily, but at the last moment it was decided not to put this material into the paper. I am willing to share it with my readers.

One of the central topics discussed on many telecom conferences during this year was the tremendous success of Web 2.0. The main trend in these discussions usually is the mutual integration of telecom and Web 2.0, or to be more precise how (and if) this integration is possible at all. For service delivery companies, the issue of Web 2.0 on the rise could be considered under another angle by looking at the reasons of its success. There is one of them we are going to discuss here: very low cost of entering the market.

During the last years, a significant increase in the production of cheaper telecommunication equipment has been seen. This includes production of small access base stations, or femtocells. Usually backed by Ethernet cable, they could serve as the access point at places where the coverage suffers, or as a replacement for the sockets of traditional telephony, for example in new residential areas.

The entry cost for the small telecom company willing to use femtocells is very low, a mere thousands euro, which resembles web landscape that gained its popularity and critical mass of attracted people in part because of the same reason. There are established business models for these small companies: serving the communication needs of the business centre, reducing the load of the main cells and gaining the profit in densely populated areas like airports, or providing coverage of rural areas.

However, femtocell users might like to use not only the communication capabilities of the access point, but also the telecommunication services they got used to â€” voicemail and flexible billing for intra-residential calls to name just a few. The owner of the femtocells will need a service delivery platform providing the same low level of costs like equipment does. The company will also require simplicity, prevalence, and ubiquity of the technology stack this platform is based on. In the situation of liberal telecom market JAIN SLEE platform is the obvious choice.

Just as prevalence of free and open products, development tools, frameworks and technologies made Web 2.0 a success, JAIN SLEE may change the landscape of the telecom in the nearest future. Based on the ubiquitous Java technology, the platform may run almost anywhere, and enjoy the expertise of the developers around the globe. Every time a new company will install femtocell anywhere, JAIN SLEE will provide a missing part in the chain consisting of hardware equipment and software platform. We are committed to the wider distribution and adoption of the JAIN SLEE standard, and looking forward to having a telecom landscape a more liberal place.

4th Fraunhofer FOKUS IMS Workshop 2008 (November 16, 2008)

Last week I visited the Fraunhofer FOKUS institute in Berlin, as they were holding annual IMS workshop. This is the biggest IMS event in the industry — this year it has attracted around 300 participants and speakers, including decision makers from the top tier companies like BT or Deutsche Telekom. It was great to witness the event run by an organization so well recognized, and participate in discussions led by people so well informed.

My impressions of the workshop are two-fold. On one hand, the telecom industry keeps being depressive: operators are being more and more pushed out of the service (and revenue) delivery chain; numerous innovations of Web 2.0 are turning out to be impossible to reproduce in the telcos, and so on. On the other hand, FOKUS institute itself has always been very consistent with delivering the real result in the form of innovative software (the most obvious examples could be Open IMS Core, Open SOA Playground including a very rich set of components, and Monster client platform, all of which were impressively demostrated at the workshop), and seeing this progress over last few year could be more than inspiring.

When talking about operators, it is clear that they are aiming at having the developers community around their set of APIs — the lessons of Web 2.0 were learned very well. Telefónica’s Luís Ángel Galindo presented an interesting list of resources traditionally owned by telcos (advanced voice-based capabilitites, messaging, location), which now slowly shifts away from them (for example, with location-aware phones becoming more and more ubiquitous, Skype and SIP providers on the rise, etc). In Spain, Telefónica launched the developer’s portal (Spanish only), and playground for convergent applications as part of their open APIs initiative. Just as well as Deutsche Telekom did. Their Senior Vice President, Thomas Mörsdorf pointed that one of the business models they see with APIs exposed is having their services injected in Web 2.0 applications. The example was real estate agency web site with the built-in “Dial” links; pressing the link would mean more minutes sold by the operator and more real estate sold by agency.

Despite all this, real-world demonstrations held by FOKUS institute during the whole workshop left no doubts that IMS is not a failure. Using only the XPOSER rule engine bundled with their Open SOA product, Fraunhofer team demostrated implementation of three different business models. Three “operators” were deployed: the budget one with advertisements, the business-oriented one with advanced conference facilities, and the third one, providing location-aware services. Services were impressive. For example, location was used to locate the shared media on the map using already mentioned Monster; video captured by the phone were uploaded to the media server and streamed to the buddies on demand; YouTube links were sent to the IMS core, resulting in on-the-fly video transcoding and streaming in a newly opened video sessions.

In short, the event was fascinating and I am looking forward to visit it again next year.

JAIN SLEE for uninitiated companion (September 24, 2008)

When writing tutorials in my JAIN SLEE for uninitiated series, I was trying to avoid any particular platform details where possible. This resulted in not having a single line of example code, which could be confusing for the very beginners.

JBoss’ Eduardo Martins made a good work on writing the tutorial with the real examples related to JBoss’ child â€” Mobicents SLEE. Please consider this as an approved companion to the JAIN SLEE for uninitiated.

Thanks, Eduardo!

SBB hierarchies and SLEE transactions (September 23, 2008)

In addition to my previous entry on the potential dangers of using re-entrant SBBs, here is another one describing interesting issue I have faced when working with SBB hierarchies. It involves SLEE transactions and underlying implementation mechanisms.

In my current project, the SBB hierarchy consists of three levels:

• root SBB, used as dispatcher for all incoming events;
• factory SBB, the only descendant of root SBB, used as, â€” well, right â€” a component factory;
• component SBBs, incorporating the main portion of business logic, a direct descendants of factory SBB.

Lowest-level SBBs are responsibe for communicating with Resource Adaptors, so the common pattern for execution is the sequence consisting of initial event handled by root SBB, cascade creation, and event exchange between RAs and lowest-level SBBs.

Sometimes business logic requires creation of another component â€” for this purpose every component SBB holds a reference to the factory’s local interface, allowing them to trigger creation of “brothers and sisters”. Note that every creation process is taking place in the scope of another (in comparison with the previous event processing cycle) event handler, and since event handlers are mandatory transaction methods, in the scope of another transaction.

Transactions mechanism surely requires some locking to be implemented. In the SLEE platform I am currently working with, locks are associated with the SBB entities and the locking mechanism is pessimistic (i.e. resources are locked immediately upon request). As transaction associated with initial event is propagating, we acquiring (among others) the locks of these SBBs, in this order: root SBB → factory SBB → component SBB. After the component finishes its work (which in the most cases relates to placing the request to RA and waiting for an event), the transaction commits. Those of events delivered to the component SBBs which require creation of new components will initiate a transaction with these locks: component SBB → factory SBB → another component SBB.

And sometimes underlying Resource Adaptor process the request so quickly, that the initial transaction have not finished its commit yet, and â€” you guessed â€” have not released the locks. Boom!, deadlock is detected (deadlocks of that sort is pretty easy to detect, and my SLEE implementation does it).

SBB hierarchy is going to be reshuffled now, and this would be a lesson for me to take even more care of the possible platform implementation tricks.

On re-entrant SBBs safety (August 12, 2008)

I was always wondering what does “re-entrant” property of SBB mean. SLEE specification warns developer about potential problems related to multithreading (section 6.11):

An SBB Developer can specify that an SBB component is non-reentrant. If an SBB entity of a non-reentrant SBB component is executing in a given transaction context, and another method invocation with the same transaction context arrives for the same SBB entity, the SLEE will throw an exception to the second request. This rule allows the SBB Developer to program the SBB component as single-threaded nonreentrant code.

When one of our SBBs required the loopback call to be possible, I have investigated the different possibilities for the potential error here. It all boils down to the possibility for SBB to hold some custom state (for stateless objects re-entrant invocations from multiple threads are safe) and to the concurrency control of the event delivery. In our case the dependencies between two SBBs could be depicted as below. Note that I am using create stereotype everywhere, implying that SBB entity for SBB A is created during the process of initial event delivery, and SBB entity for SBB B is created after invocation of ChildRelation.create() method. We will see below that this simplification does not influence the final conclusion.

The actual details of the local method invocations (probably involving proxies) at steps 12 and 13 are omitted. Two questions arise here:

• Is the invocation at step 13 delivered to the same SBB object (remember the mentioned proxies)?
• Is the state of this object the same as before the invocation?

The answer for the first question is “we don’t actually care”. Section 2.2.7 of the SLEE specification says that “the SLEE may assign zero or more SBB objects to represent an SBB entity”, but 6.5.1 prohibits using of class fields for storing local object state. This means that even if the invocation 13 is delivered to another SBB object (and here we are coming to the answer for the second question), then its state would be the same.

But this is not all. A more complicated situation may occur if:

• SLEE delivers an event in another thread to the same SBB entity somewhere between steps 12 and 13
• …and has chosen for this delivery the same SBB object as for invocation 13
• …and this SBB object is different from the object used for delivery of event Foo (section 8.6.6 guarantees serial invocation order only for event handlers for events delivered in the same Activity Context).

In accordance with section 8.6.6, SLEE guarantees that invocations of any methods on the same SBB object are always serial (i.e. are never overlapping). Therefore, event handler will finish its work before step 13, thus (potentially) changing SBB entity state.

We could conclude the simple rules for re-entrant SBBs:

• Event handlers not changing SBB entity state are always safe for re-entrant SBBs (though local methods invocation could change state)
• If underlying resource (say, network) guarantees event firing order, and latter event handlers do not modify SBB entity state required by former, then this is also safe

I was unable to find any other possible problems with re-entrant SBBs, but readers from jNetX and OpenCloud (I know, there are some) are always welcome to prove me wrong.

← Later entries | Earlier entries →