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.

Link | Comments (1)

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!

Link | Leave a comment

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.

Link | Leave a comment

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.

Link | Comments (5)

Cellular-Internet convergency with quasi-femtocells (July 20, 2008)

There were recent news on BT and T-Mobile USA (at least these two) offering GSM/IP converged services with the additional access poit installed at the subscriber’s premises. I am talking about BT Fusion Mobile and T-Mobile at Home. First product takes advantage of connecting the users of Wi-Fi enabled handsets to the core network over broadband IP connection using UMA. Second one does nearly the same, but the access point contains its own SIM, thus rendering the Wi-Fi capabilities of the handset unnecessary. For the security reasons, T-Mobile at Home allows connection only from the wireline phones attached directly to the router.

These devices both are not pure femtocells, as Telco 2.0 thinks. However, what interesting here from the point of view of service delivery provider, is that Internet and phone line connections could be correlated (i.e. operator could associate the signaling connection with the one for Internet data, despite that they could be esablished from different devices). What about your incoming SMS popping in your Facebook window when you logged on?

Link | Leave a comment

← Later entries | Earlier entries →