From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
Subject: Profiles and SBB entities[Q: Andreas]
When it would be appropriate to instantiate a SBB/call and when to use
same SBB to process all calls coming from let say a special event or
activity context?
[A:Ranga]
We went through some discussion (essentially thought experiments) on this topic when we were trying to design some simple services for Mobicents and heres what I think -
If you instantiate one root sbb per call based on say the call ID of the call, then, you can amortize authentication. The activity in this case lasts for the entire length of the call and is identified by the Call ID. This would also make sense if you are building a stateless component such as a SIP Proxy server as an SBB
On the other hand if you instantiate an Sbb per event type such as say an SBB per INVITE then you are essentially associating the SBB with the SIP Transaction and the Entity lasts for only the length of the transaction. This would make sense if you are building a stateful service such as say an IVR service.
This is a good question however and I'd like to hear other opinions.
This also brings up several questions on how the SIP RA will work. I think this behavior should be standardized ( I am sure Ben Evans would agree) to achieve service portability. There is only a recommendation on the SIP RA type at present and this could be firmed up.
Regards
Ranga
Updating Profiles from SBBs
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q:Andreas Nilsson]
> I’m curious knowing what is the reason for not allowing SBB:s crating
> and updating profiles? For example if I have a telecommunications
> service which uses profiles to keep state of which addresses to
> process and how (blocking, forwarding, auto-reply and so on…) it would
> be nice to be able to update these profiles from for example a j2ee by
> passing events to a custom "profile update service". Off course I
> could use a JMX adaptor MLet but I still would like to hear the motivation. [A: Swee Lim}
The simple answer is that we did not have sufficiently well-defined requirements in this space to include it in 1.0. However, we did plan for it by including the set methods in the profile interface. To provide a little more background, our view of the SLEE profiles was that it was intended to be a cache of the data that needs to be provisioned to provide service. Hence, it was not the authoritative data source. If we allow update of the data, does this mean that the SLEE now becomes the authoritative source. We were very concerned that the SLEE becomes an authoritative source because we did not want to impose on the SLEE the requirements (persistency, consistency, stability, ... etc) associated with an authoritative source. We felt that this is the job for a database or some OSS system (with a database) and the SLEE is not intended to be a database or OSS system replacement. Given more time, we could have addressed some of these issues in 1.0. However, the community felt that it was not worth delaying 1.0 to add address and add profile updates.
Since 1.0, we have resolved many of the above considerations as part of the 1.1 work. The 1.1 spec will support updates to profiles. This brings
issues like how to validate updates (similar to Profile Management
classes) and how provide mechanism to export/synchronize updates with the back-end OSS/dataabase.
Regards,
Swee
SBB event priority and event delivery.
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q:Andreas Nilsson]
If two services (root SBBs) have different default-priority let say
SBB1 default-priority = 100
SBB2 default-priority = 50
Both SBB:s can receive event e. When does SBB2 get event e? Is it when
SBB1s event handler method returns or just some time after SBB1 have
received the event? As I see it the SLEE processes one event at the
time.
[A: Amaresh Kumar Ram}
As per the pseudo logic provided in the appendix, SBB2 will receive the
event e, when SBB1s event handler method returns.
[A: Ralf Siedow}
SBB2 receives the event when SBB1 has finished processing it. If it
would be "some time after" then this would result in unpredictable
behaviour of a service.
What is the right place to initialize SBBs with references to RAs?
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q:Ralf Siedow]
> Hello,
>
> my SBB has two event handler methods:
> - onEvent1() (initial)
> - onEvent2()
>
> The sbbCreate() method looks up another RA and stores the reference
to
> the provider interface in a private field.
>
> When event1 is fired a new activity plus SBB is created and the SBB
gets
> attached to this activity. The event1 method then does something
which
> results in event2 being received later by the event2 method. When the
> event2 method is called it tries to access the provider interface but
> fails because the field contains a null value. This is the case
because
> for this sbb object because sbbCreate() has never been called.
>
> When reading the 1.0 spec thouroughly it is not absolutely clear but
it
> seems that an SBB can transfer to the active state and handle an
event
> in this order:
> newInstance() > setSbbContext() > _Pooled > sbbActivate() > _Ready >
> onEventXY (non-initial)
> Is that true?
>
> If yes, where should I put functionality that initializes a sbb
object
> like provider and activity context interface factory lookup? These
might
> produce exceptions so I assumed to put them in sbbCreate(). Within
the
> constructor the lookups cannot performed because the context is not
> available and it does not allow exceptions to be thrown. The latter
> applies for the sbbActivate method.
> [A: Swee Lim]
You should have it in two places sbbCreate/sbbPostCreate and
sbbActivate. If you look at the lifecycle diagram (figure 5, pg 50),
if there is some function you need to perform when an Sbb transitions
from Pooled to Ready, you need to do it on all the arc's that go from
Pooled to Ready.
I suggest putting this initialization code in a method and call this
method from sbbCreate/sbbPostCreate and sbbActivate.
How to verify if an EventTypeID? is known to a SLEE container?
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q:Hareesh Ravindran]
I'm trying to implement a resource adapter which can be used to communicate between SLEE server and J2EE? server.
The resource adaptor has the concept of Events, EventTypeIDs?.
Given an EventTypeID? (created with the event name, vendor and version) how can I check whether the EventTypeID? is valid?
[A: Ralf Siedow]
see chapter 13.6 (Event Lookup Facility) or page 306 (BootstrapContext?) of the 1.1 specification draft. This is an issue that was not standardized in 1.0. Mobicents has a 1.1 RA integration possibly.
[A:Francesco Moggia]
Using the 1.0 spec there is no a standard way to check if an event type is known to the SLEE, you need to ask your JAIN SLEE container vendor how to do that. JAIN SLEE 1.1 will allow you to do that by using the standard interface EventLookupFacility? as Ralf pointed out.
When to use SLEE Profiles vs. JDBC or EJB persistence?
Answer provided by David Ferry, co-lead JSLEE 1.0 & 1.1
Profiles are guaranteed to be present in compliant SLEE implementations so that developers can get application portability in this area. Whilst other technology choices can exist (e.g. JDBC, EJB3, other/proprietary) they are not mandated by the specification and are not checked by the TCK.
If profiles cannot be used to provide an appropriate solution and another technology can then I would expect developers to use another technology.
In specific cases I further expect that developers building solutions look at least at combinations of:
1) suitability of the technology implementation
2) network architecture for accessing the data (e.g. IMS is going towards all subscriber data being in the HSS)
How are events handled if there is no consumer deployed?
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q: Peter Wenzl]
In case a Resource Adapter receives a Network Trigger (IDP in case of SS7) this Trigger
is converted to an Event and forwarded to the interested services (or the services pick them up).
If no service is deployed the event somhow ends up nowhere, meaning the network element that
originally initiated the trigger may still be waiting for an answer which of course will never come.
So the idea is to invoke some "default event handling method" on the RA that initiated the event.
Conceptually I don't see how the JAIN SLEE standards are dealing with that issue.
Actually I think the current standards do not consider this at all.
Technically the SLEE itself does not know how to interact with the Resource Adapter,
hence can not invoke any default response method on that RA.
Is there a possibility to deploy for each RA a sort of default handler service which is invoked only if no
other service has consumed that event?
Two things would be nice to achieve:
1.) to get an indication of such a situation (Alarm)
2.) to act in default manner for each resource adaptor deployed.
None of which is currently specified in the standards.
Will future JAIN SLEE specs consider this?
[A: David Ferry]
The RA architecture in 1.1 defines that an RA which submits an event
receives a callback related to info about how the SLEE processed that
event. The are invoked after the SLEE has delivered the event to any
interested SBBs and includes a status flag indicating whether or not an
SBB received the event.
This means that an RA provides the protocol specific default action if
no service consumed that event. Therefore it can raise an alarm, and it
can perform some appropriate action (perhaps send a continue+tc_end).
So I believe that this is already covered in 1.1.
How to include external JARs?
From: JAIN-SLEE-INTEREST@JAVA.SUN.COM archive
[Q: Kacper Mosienski]
I have a question on deploying a service with an external business logic
resource.
My intent is for the service to provide a business logic contained in an
external jar file. This business logic would be used in one of sbb
components. Any modifications made in classes included in this jar file
shouldn't imply changes in service deployment.
I've included this external jar file in a deployable service jar file.
However, during deploying it on a SLEE server, classes of this external
business logic are not visible. I get the following error:
Installation of deployable unit failed:
javax.slee.management.DeploymentException: Error(s) in deployable unit:
Verification error(s) in one or more components in sbb.jar:
Verification error(s) in sbb component OurService? 1.0, Vendor:
Cannot load SBB abstract class class pl.vendor.jain.service.control._Sbb
nested exception: java.lang.NoClassDefFoundError:
pl/vendor/service/database/DBInterface
How can I make classes from external jar file visible for the service?
Is it possible to add these classes without decompilation to the sbb.jar?
[A: Steven Adams]
If you want to reference classes in external jar files in your SBB, you
need to use the jar manifest Class-Path attribute. Section 3 of the
SLEE 1.0 spec mentions this in terms of including classes "by reference".
An as example, say your external jar is called "external.jar". In the
jar manifest of your SBB's component jar you would include the attribute:
Class-Path
library/external.jar
then include the library/external.jar in your SBB's deployable unit (not
the SBB component jar). As the classpath is a relative URL, you can put
the external jar anywhere in your deployable unit, so long as the
Class-Path matches with its location in the DU jar.
In SLEE 1.1 we have introduced a new library component type, which all
other component types may depend on. Library components supercede the
use of the manifest classpath, which is not particularly well defined
and also suffers from a number of problems when used in an environment
such as the SLEE (in particular different deployable units cannot share
a common library).
-- Main.ivelin - 23 Nov 2005