Skip to main content

communication between SBBs

3 replies [Last post]
anilh
Offline
Joined: 2006-10-25

Hi,

I have a question regarding communication between two SBBs. Lets say we have an SBB A which is created with an initial event A. Now another SBB B whose initial event is B is created when event B is fired. Is there any way of communicating between SBBs B and A?

Another question i have is regarding the longevity of SBBs. Once an SBB is created with an initial event, can it remain forever? For example, lets say we have a Registration SBB which is created during login request, and is removed when it gets the logout request. First of all, is this approach correct? What will happen if there are hundreds of logins(different users) and they never logout?

Thanks,
Anil

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
fram
Offline
Joined: 2004-05-13

The case that you're describing involves the communication between two different JAIN SLEE services. A JAIN SLEE Service can communicate with other services using the following options:
- firing events that are initial for other services. Please note that initial events can be used to attach already created Sbb Entities to an event activity.
- using the Naming Faciltiy inside the JAIN SLEE continer. First create a null activity and bound it's activity context interface to the naming facility using a name, once you do that all the services inside the container are able to retrieve the activity by looking up the name.

SBB are garbage collectected by the container when they are no longer attached to any activity. If you want that an SBB stays after the end of the activity to whom it's attached you have to:
- create a null activity, using the nullactiivityfactory,
- get the Null Activity Context Interface Factory, using the nullactivitycontextinterfacefactory
- attach the SBB to the newly crated activity.
You can also attach a timer to your activity context interface and set an expire time for the registration by doing this you have the opportunity to garbage collect the SBB after an expiration time and you'll not waste resources.
Hope this helps.
Francesco

anilh
Offline
Joined: 2006-10-25

Thanks fram, that answered my first question. I will rephrase my 2nd question: What i meant to ask was, are SBBs meant to be long-lived or do they exist just for the duration of an event, like for example in the case of a SIP message, the SBB exists only for the duration of the transaction.

I would like to get clarification on another question i have. In Section 8.6.2 (JSLEE Rel 1.0), for received event (non-initial events), the spec mentions that
--------------
The received event set of the SLEE changes when an operation that modifies the set of events that an SBB
entity can receive is invoked. These operations include:
· Attaching an SBB entity to an Activity Context.
When this occurs, the SLEE may have to expand the SLEE’s received event set to include events ...
· Detaching an SBB entity from an Activity Context.
This occurs implicitly after the SLEE delivers an Activity End Event to an SBB entity (see Section
7.3.3), when the SBB entity is removed (see Section 2.2.6), or explicitly when the detach
method is invoked (see Section 7.4.3). When this occurs, the SLEE may have to contract the
SLEE’s received event set to exclude events of the received event types of the SBB entity.

-------------------
Does this mean that if my SBB receives an initial event and the activity context on which it received the event ends, i will not be able to receive subsequent non-initial msgs on the same SBB. Let me reword that with an example:
In the case of SIP messages, if i have REGISTER msg as an initial event and lets say OPTIONS as a non-initial event for my SBB, then when i receive a REGISTER, my SBB is created and processes the REGISTER, and the SBB is removed after the transaction is complete. Now when an OPTIONS msg is received, since it is not the initial event and since my SBB has been removed, it is not goin to receive this msg.

Is my understanding correct? If so, is the only choice i have is to make the OPTIONS an initial event too.

Thanks,
Anil

fram
Offline
Joined: 2004-05-13

Your interpretation is correct. Even if OPTIONS is initial for you Sbb the Sbb Entity is going to be removed.
In order to receive the OPTIONS on the same SBB Entity you need to attach the SBB to an Activity Context created using the Null Activity factories.
Francesco