and a 'do-it-yourself' (DIY) section of console commands you can use to check out the service in action.
This page assumes... ...an understand of the functionality of Telnet Resource Adaptor and how activities and events interact with the SLEE.
This service consists of an SBB that handles the event MessageEvent of the Telnet RA, and replies to the same message on the current telnet channel.
The service consists of one SBB component, EchoSbb, that receives the event MessageEvent with the message typed by the user. EchoSbb defines MessageEvent as an initial event, with the initial-event variable set to Activity Context. Then, when the resource adaptor receives the first message that the user typed, the SLEE creates a new EchoSbb entity and attaches the entity to the activity associated with the telnet channel.
The MessageEvent is routed to EchoSbb entity and the method onMessageEvent is executed by the SLEE. This method obtains the activity object (ConnectionActivity) for that activity context interface and uses the ConnectionActivity.sendMessage() method to echo the same message on the telnet channel (with the added prefix "Echo: "). Because the SLEE automatically attaches the SBB entity to the activity, this entity will receive all the consequent messages sent by the user.
When the user closes the telnet connection, the resource adaptor ends the activity and the SLEE garbage collector removes the SBB entity attached to the ACI associated with the activity.
Deploy the Telnet RA and the Echo service and telnet to port 9999. The Echo service will echo all the written messages.
If the SBB is the root of an SBB tree, the deployment descriptor has to define an initial event. In this case, the initial event is be the MessageEvent and the Sbb entity will be attached to the activity context of the activity created by the Telnet RA.
The project uses the Maven JAIN SLEE Plugin to manage dependencies and package the service. The files provided are the descriptors (service, sbb and library), the SBB class and a unit test example.
Below are excerpts from the JAIN SLEE specification relevant to the service:
JAIN SLEE Specification
2.2.1 SBB component
An SBB component defines:
Event types received and fired by the SBB component.
The per-instance state should be held in Container Managed Persistent (CMP) fields that can maintain persistent state that should persist across failures.
The SBB component provides an event handler method for each event type received by the SBB component. The event handler method contains application logic to process events of a specific event type. The SBB component also declares a fire event method for each event type fired by the SBB component.
2.2.3 SBB entities
An SBB entity is an instance of an SBB component. An SBB entity is a logical entity that represents the persistent per-instance state of the instance.
2.2.7 SBB object
An SBB object is an instance of the SLEE generated class that extends the SBB abstract class (see Section 3.1.4). The SBB abstract class is the SBB Developer provided Java class that contains the definitions and methods listed above.
The SLEE creates and manages a pool of SBB objects. At runtime, the SLEE may assign zero 3 or more SBB objects to represent an SBB entity. When an SBB object is assigned to represent an SBB entity, the SBB object is in the Ready state (see Section 6.3). It can receive and fire events, receive synchronous method invocations, and access and update the persistent state of the SBB entity. Another viewpoint is that the SBB object caches a copy of the persistent data of the SBB entity to provide transactional semantics (see Chapter 9).
A Service is a deployment and management artifact. It specifies a child relation from the SLEE (as the logical parent of all root SBBs) to a root SBB. Hence, it identifies the root SBB of the Service, the default event delivery priority of the Service, and provides other information needed by the SLEE to instantiate root SBB entities of the Service.
3.1.4 SBB abstract class
The SBB abstract class is mandatory. It contains the processing logic of the SBB. It implements the javax.slee.Sbb interface. The SBB Developer provides the following methods:
Event handler methods (see Section 8.5.2).
The SBB Developer implements an event handler method for each event type that may be received by the SBB. Each event handler method contains the application logic for processing events of a specific event type.
3.1.8 SBB deployment descriptor
The SBB Developer identifies the SBB's interfaces, classes, child relations, and Activity Context attribute aliases in an SBB deployment descriptor. References from the SBB to other components are also included in the deployment descriptor. These other components include libraries, profile specifications, resource adaptor types, events and other SBB components. The deployment descriptor also allows SBB component environment entries to be set.
3.1.9 SBB jar file
The SBB jar file is the standard format for packaging one or more SBBs. It must include the following:
An SBB jar deployment descriptor.
The SBB jar deployment descriptor is stored with the name META-INF/sbb-jar.xml in the SBB jar file.
The root element of the SBB jar deployment descriptor is an sbb-jar element. This element has the following sub-elements.
A description element.
This is an optional informational element.
One or more sbb elements.
Each of these elements is an SBB's deployment descriptor.
A security-permissions element.
This element is optional and contains sub-elements that identify additional security permissions that should be granted to the classes in SBB jar file.
Class files of the SBBs specified by the sbb elements of the sbb-jar element.
The SBB jar file must contain, either by inclusion or by reference, the class files of each SBB.
The SBB jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that the SBBs' classes and interfaces depend on, except J2SE classes, SLEE classes, classes included in the SBB jar files of referenced SBBs of the SBBs (see sbb-ref element), classes included in the event jar files of the event types referenced by the SBBs (through event-type-ref elements), classes included in the Profile Specification jar files of the Profile Specifications referenced by the SBBs (through profile-spec-ref elements), classes included in the resource adaptor type jar files referenced by the SBBs (through resource-adaptor-type-binding elements) , or classes included in the library jar files of the libraries referenced by the SBBs (through the library-ref elements). This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.
Do it yourself
Below are some console commands you can try, to observe what is happening in the Rhino SLEE container when the Echo service is running. After you deploy the resource adaptor and the service, start the Rhino command-line console and try the following, to:
If you close or open more telnet connections, you'll see more SBBs being created or removed by the SLEE.
Review the SBB lifecycle
You can see the SBB lifecycle in the Rhino log. The trace messages are written by the BaseSbb lifecycle methods that you didn't override.
When you start a new telnet channel, the resource adaptor listener establishes the new connection. When you send the first message on the telnet channel, Rhino creates an SBB entity to handle it. The sbbCreate and sbbPostCreate methods are performed. Moreover, you can see some traces that are generated in onMessageEvent method.
$ telnet localhost 9999
Connected to localhost.
Escape character is '^]'.
When you close the telnet connection, the resource adaptor connection handler detects that the connection has been closed by the remote host and ends the activity. Because the SBB is not attached to any other ACI, the SLEE removes the SBB entity