JAIN SLEE for uninitiated pt. 3 (June 19, 2008)

A curious reader might ask himself after reading the previous part in JAIN SLEE for uninitiated series: it seems that one SBB could create other SBBs and control their attachment to ACIs, fine. But if these SBBs are components of the bigger application — a service — how could they communicate?

Chapter I. Local interfaces

This curious reader may even suppose that if one SBB could fire event, and another one could receive it, then this would be some cumbersome, but valid way of doing this (this approach is used when two SBBs need to communicate asynchronously). He or she would be absolutely correct, but for more elegant and effective inter-SBB communication we have something better.

EJB specification starting from the version 2.0 of it introduces the notion of local interface, or interface used for local, intra-container invocations, when one EJB instance invokes another. Local interfaces for SLEE components (they also have them) display more significant difference: they not only do not require expensive serialization operations, as event routing does, but also are synchronous. From where SBB may have some other SBB’s local interface? One of these:

• Creation methods for child SBBs return exactly the local interface of the newly created SBB
• SBB may always obtain its own local interface
• Local interfaces of any SBBs could be passed to the synchronously invoked methods on any other SBBs, and used further

The very typical scenario for SBB tree is thus the following:

• Event is fired by Resource Adaptor with regards to the state of some external resource (e.g. incoming message to initiate a call)
• This event is initial for some SBB, which is a root SBB of one of the deployed services (let this be a prepaid service, implementing also private ring-back tone functionality). SLEE creates an instance of this SBB, and delivers the event to it (attaches the SBB to the call ACI, and invokes event handler method)
• SBB performs the necessary internal job (checks balance; at this moment another event exchange would take place, but we will omit it for simplicity), and decides to continue the call. The rest of the job should be done by the child SBB. Root SBB creates it, and obtains a local interface reference
• Parent SBB attaches child SBB to the call ACI, detaches itself, and passes the necessary information to the child SBB (say, a ring-back tone tune name for the particular user’s balance)
• The event processing in the parent is finished. The next event arriving to the child will be processed by it (say, ALERTING event may result in establishing a call to the media server to play the specified tune). Parent SBB never invoked again in this call, as it is not attached to anything
• We’ve got hierarchy and component orchestration!

The only fundamentally new thing we’ve up to now learned today is the existence of the local interfaces and synchronous calls between SBBs. Not by accident.

Chapter II. Persistence

The same curious reader might notice that SBB always doing it’s job in small chunks. Business logic is concentrated in the event handler methods, and while writing these methods we do not want to block invoking thread for the long time — therefore, event handler method tries to return as soon as possible. What happens to the SBB instance in between the calls?

The instance is passivated. For efficiency, JAIN SLEE container maintains the pool of the Java objects which potentially may become SBB entities. Passivating is returning the Java object to this pool. Specification warns us: it is very likely that for handling of two sequential events by one SBB instance, two different Java objects would be taken from the pool. The current state of the SBB entity (or the set of data Java developer would normally put to the fields of the class) therefore should be persisted in SLEE CMP fields.

Every CMP field is ultimately a pair of abstract methods (setter and getter), plus the entry in the SBB’s deployment descriptor. The actual implementation of the methods is generated by SLEE at deploy time, and SBB code uses this getter and setter for persisted data, working with this methods as with “virtual fields”. CMP allows storing of anything that is serializable, and the only exception are local interface references.

They are not required to be serializable, but are essential for SBBs. Local interfaces are stored in the special CMP fields (with the CMP type javax.slee.SbbLocalObject, and, optionally, containing the reference to the corresponding SBB type in the CMP fields deployment descriptor). So when the instance is activated (taken from the pool), SBB entities of all referenced SBBs could be reconstructed via the specially handled CMP fields.

For storing globally accessible data, another mechanism exists: SLEE profiles.

I am noticing that every next entry in JAIN SLEE for uninitiated series become longer: this is an interesting topic to cover. I’ll pause the series for now; new entries would be based on some special topics in SLEE specification that I would discover, or your feedback (very welcome).