JAIN SLEE for uninitiated pt. 2 (May 31, 2008)

This is part two of JAIN SLEE for uninitiated tutorial. We have been talking last time about the functions provided by different components, and now there’s a little more about the way components are treated in SLEE.

Like in JEE world, SLEE requires components to expose their deployment descriptor (DD) — an XML file of predefined structure located in the predefined place in the deployment JAR. Every entity in SLEE needs deployment descriptor, even if the entity does not define any custom Java classes in its JAR. The reason for that is necessity to have a global identification scheme for components — each component has its own SLEE type assigned. SLEE type is not exposed as an interface, but is declared in the DD as triple of component name, vendor, and version. This allows components to reference each other.

For example, RA exposes its type along with the types of the events being fired. SBB references this RA, as it is going to receive its events, and declares these events as expected for reception. Note that container checks dependencies at deploy time, so if SBB would be deploying before RA, the deployment will fail, as referenced SLEE types — ones of RA and the events — are not registered in SLEE yet. SBBs could also reference other SBBs and declare them as “children”. In this case parent SBB controls the creation of the child SBB.

Why is it important? Because we have reached the point where the orchestration of the components (or, more precisely, of SBBs) is defined. After all, SBB is just a unit of application logic, and is not the application itself. “Applications”, or services, how SLEE specification calls them, are standalone deployment entities, i.e. they do not hold any Java classes. Instead, they declare their SLEE type, and a reference to their root SBB. These SBBs could receive so called initial events.

It is clear from the previous entry, that SBB instances are receiving events, but how these instances are being created? SLEE specification defines a notion of initial event, which could potentially (with regards to the rules defined by the specification) trigger creation of new SBB instance. One of the defined rules is that at any moment, only the root SBBs of deployed services could be instantiated. All other SBBs are created later by their parent SBBs.

Service, therefore, is essentially a tree of SBBs. The root SBB is created by the initial event, and is used for this event processing. Later on, root SBB could create child SBBs, and — the next is extremely important in SLEE programming model — control child SBBs attachment to particular activities. This means that root SBB, for example, could be triggered by the initial call event, create the request to some charging subsystem, and, therefore, an ACI associated with this request, detach itself from the latter ACI, and attach to it a special charging child SBB, while staying attached to the ACI of the initial call. This way of orchestration when parent SBB controls the event flow received by the child allows controlling the execution in a very flexible manner. Remember that each participating component has its own lifecycle and is managed by the container — all this give SLEE architecture additional bonus.

The way how SBB instances are actually being managed by the container, how they persist their local data and how they access a shared data will be discussed in the next part of the tutorial. See you soon.