JAIN SLEE for uninitiated pt. 1

Who am I?

What I do

Projects

Contact

JAIN SLEE for uninitiated pt. 1 (May 18, 2008)

This is the first tutorial in JAIN SLEE for uninitiated series. As promised, we will cover today the very basics of our subject.

So, what is SLEE? It is the event-driven component architecture. This means that developer working with SLEE usually deals with entities acting as event receivers, event senders, event channels and events itself. They are:

Service Building Blocks (SBB) serve as event receivers. These are essentially the components in the SLEE component architecture. SLEE container takes care of their lifecycle and sets up the environment for them. SBB is where the service logic code goes, and upon event reception it does all the work. Event-based approach makes them different from EJB. EJBs usually act as a server components and require a client doing something like “connect / JNDI lookup / creation / execution.” SBBs are created and invoked by SLEE when the event arrives. That is, “event delivery” is essentially an invocation of the method on SBB’s Java object
Resource Adaptors (RA) serve as event senders. Their lifecycle is also managed by container. RA could interact with SBB in both directions: SBB could invoke a Java method on RA’s public API, and RA could fire an event which later could be delivered to some SBB (or to none of them, if no SBB expressed interest in particular event).
What is the condition for firing an event? External resource determines this. E.g. SIP RA “adapts” SIP endpoint (UDP socket listening to port 5060) to the SLEE. SIP RA fires an event when this resource interacts with anything, for example, the event could be fired upon reception of INVITE request.
Note that the set of events fired by RA or received/fired by SBB is described in RA’s and SBB’s deployment descriptors, i.e. assigned to the components in a declarative manner
SLEE Events are, hmmm, events. An event is represented by the Java object passed to the event handling method on SBB, when this event is delivered to this SBB. All necessary information from the resource level, like network message content, etc, is encapsulated there. To avoid events mess, events are distributed over the channels called activities, which are in turn linked to the next discussed entity
Activity Context Interface (ACI) is a SLEE representation of the activity, or stream of related events. Considering the example of SIP RA, we may surely say that it could receive hundreds of INVITE requests, and each of them is fired as an event to the SLEE, but some of them (re-INVITEs, for example) relate to another events already fired. How RA distinguishes this? Easily: most of the network protocols have a notion of session (SIP not being an exception) — and protocol-aware RA could group messages belonging to one session together.
But SLEE is universal framework, therefore it should not know about any type of sessions, that’s why it deals with the following relation of entities.

Activity represents related stream of events. This is not a Java object, but a logical entity. It is bound one-to-one to the domain-specific Java object representing this activity — to activity object. Activity has its logical representation in the SLEE world — which in turn bound one-to-one to the Java object, the Activity Context Interface.
Why we need this? To determine which events are delivered to particular SBB. SBB only getting the events of the activity, the ACI of which this SBB is attached to (developer has the control over SBB attachment).

Suming this up: SLEE is all about the events. Events are fired by RAs in response to some external interaction, and delivered over activities to the SBBs, which are interested in this event and attached to the corresponding ACI.

Next time we’ll talk a little bit about the deployment, SLEE services and SBB trees. Stay tuned.

Sergey Mikhanov

Who am I? What I do Projects Contact	JAIN SLEE for uninitiated pt. 1 (May 18, 2008) This is the first tutorial in JAIN SLEE for uninitiated series. As promised, we will cover today the very basics of our subject. So, what is SLEE? It is the event-driven component architecture. This means that developer working with SLEE usually deals with entities acting as event receivers, event senders, event channels and events itself. They are: Service Building Blocks (SBB) serve as event receivers. These are essentially the components in the SLEE component architecture. SLEE container takes care of their lifecycle and sets up the environment for them. SBB is where the service logic code goes, and upon event reception it does all the work. Event-based approach makes them different from EJB. EJBs usually act as a server components and require a client doing something like “connect / JNDI lookup / creation / execution.” SBBs are created and invoked by SLEE when the event arrives. That is, “event delivery” is essentially an invocation of the method on SBB’s Java object Resource Adaptors (RA) serve as event senders. Their lifecycle is also managed by container. RA could interact with SBB in both directions: SBB could invoke a Java method on RA’s public API, and RA could fire an event which later could be delivered to some SBB (or to none of them, if no SBB expressed interest in particular event). What is the condition for firing an event? External resource determines this. E.g. SIP RA “adapts” SIP endpoint (UDP socket listening to port 5060) to the SLEE. SIP RA fires an event when this resource interacts with anything, for example, the event could be fired upon reception of INVITE request. Note that the set of events fired by RA or received/fired by SBB is described in RA’s and SBB’s deployment descriptors, i.e. assigned to the components in a declarative manner SLEE Events are, hmmm, events. An event is represented by the Java object passed to the event handling method on SBB, when this event is delivered to this SBB. All necessary information from the resource level, like network message content, etc, is encapsulated there. To avoid events mess, events are distributed over the channels called activities, which are in turn linked to the next discussed entity Activity Context Interface (ACI) is a SLEE representation of the activity, or stream of related events. Considering the example of SIP RA, we may surely say that it could receive hundreds of INVITE requests, and each of them is fired as an event to the SLEE, but some of them (re-INVITEs, for example) relate to another events already fired. How RA distinguishes this? Easily: most of the network protocols have a notion of session (SIP not being an exception) — and protocol-aware RA could group messages belonging to one session together. But SLEE is universal framework, therefore it should not know about any type of sessions, that’s why it deals with the following relation of entities. Activity represents related stream of events. This is not a Java object, but a logical entity. It is bound one-to-one to the domain-specific Java object representing this activity — to activity object. Activity has its logical representation in the SLEE world — which in turn bound one-to-one to the Java object, the Activity Context Interface. Why we need this? To determine which events are delivered to particular SBB. SBB only getting the events of the activity, the ACI of which this SBB is attached to (developer has the control over SBB attachment). Suming this up: SLEE is all about the events. Events are fired by RAs in response to some external interaction, and delivered over activities to the SBBs, which are interested in this event and attached to the corresponding ACI. Next time we’ll talk a little bit about the deployment, SLEE services and SBB trees. Stay tuned.
© 2007–2025 Sergey Mikhanov