[mobicents-public] Should there be a Configuration Facility in the JSLEE specification?

[aayush bhatnagar]

Hello experts and community,

I was wondering whether the JAIN SLEE spec should have also defined a
configuration facility for the SBB and other components, on the lines
of tracers and timer facilities which also act as wrappers?

At the moment, the SBB either uses MBeans to manage configuration
data, or it may store it in a DB.

There is no cross vendor standardized solution to manage configuration
state for SBBs in such a way that changes to this data are persistant
across a cluster. For persisting changes, the application needs to put
it in a DB /common repository etc.

We can use profiles, but I feel that profiles also use an underlying
datasource to maintain data, so rather than going through a profile
table, I can directly insert the data in the DB.

Moreover, not all data might be bulky enough to be kept in a DB. The
application may have configuration flags or small integer values which
should be maintained in-memory. Or the data could be READ intensive
with occasional WRITES. Using a DB to store such data is an overkill.

Maybe, if the spec defines a config facility, as a wrapper over the
MBean standard, we can have a standard solution to maintain config
data and sync it across the cluster efficiently.

Thoughts?

Best Regards
aayush

[Naresh Ramani]

hi aayush-ji.

i think it makes sense to have something like this. why is it not there in the specification, when it has timers, alarms, usage paramteres etc ???? 

configuration facility is basic thing, and it should be there.

[aayush bhatnagar]

There are ways to store config data. We can always store it in some DB and sync with it or persist changes to it (but storing flags etc may not justify DB storage always).

However, it would be better if configuration data (for the SBBs) is stored in a standard manner (using a facility or a standard API), to make it portable across JSLEE implementations and also to make changes to this config data HA across the cluster. 

Eg: flag-X was set on node-1...node-1 crashed...flag-1 is unset on node-2 by default. This should never happen. 

HA philosophy is vendor dependent, but if the data is maintained in a standard manner as part of the container, the HA philosophy can include persistence of this configuration data as well. 

If you look at the JAIN SLEE Resource Adapter API, you would see that JSR 240 covers the configuration changes/callbacks on updates of the RA:

In the resource management MBean, there is an operation named --> updateConfigurationProperties ( ) 

If the configuration properties are verified without error as determined by the raVerifyConfiguration(ConfigProperties properties) method, configuration update callbacks are fired to the Resource Adapter --> raConfigurationUpdate(ConfigProperties properties);

Similarly, JAIN SLEE profiles also have standard APIs for provisioning profiles and configuration.

No reason, why a similar API (or a facility) should not be defined for the SBB (the business logic may also want to store config data).

These are just my personal thoughts, as I see this as something that JSR 240 should have covered. 

Expert opinion may of course differ.

--
aayush
http://in.linkedin.com/in/abhatnagar19
======

[Dominique Gallot]

Why not reuse the sbb environment for that purpose?

Somehow they are meant to be use for the general configuration of the sbb.

And clearly the container should provide a way to override the value of it ( the value is optional in the deployment descriptor )

 

<!--

The env-entry element declares a constant that should be bound into the SBB's

JNDI environment.  It contains an optional description, the name and type of

the constant, and an optional value.  If a value is not specified, one must be

supplied during deployment.

 

Used in: sbb

-->

 

However these environment properties

 

• Are constant so this branch of the jndi tree is readonly ( java:comp/env )
• They are linked to a sbb and not a service
• They only allows basic types ( String, Integer, Byte, … ).

 

 

 

Best Regards,

Dominque Gallot

[aayush bhatnagar]

Yeah.env entries are constant.

Maybe a MBean driven API is more appropriate, which allows get/set
operations and can also integrate with SNMP.

On 19/05/2010, Dominique Gallot <dominiqu...@gmail.com> wrote:
> Why not reuse the sbb environment for that purpose?
>
> Somehow they are meant to be use for the general configuration of the sbb.
>
> And clearly the container should provide a way to override the value of it (
> the value is optional in the deployment descriptor )
>
>
>
> <!--
>
> The env-entry element declares a constant that should be bound into the
> SBB's
>
> JNDI environment. It contains an optional description, the name and type of
>
> the constant, and an optional value. If a value is not specified, one must
> be
>
> supplied during deployment.
>
>
>
> Used in: sbb
>
> -->
>
>
>
> However these environment properties
>
>
>

> - Are constant so this branch of the jndi tree is readonly (
> java:comp/env
> )
> - They are linked to a sbb and not a service
> - They only allows basic types ( String, Integer, Byte, … ).

[Eduardo Martins]

I vote for a configuration similar to RA entities, exposed through JMX :)

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco



On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar

[aayush bhatnagar]

Yep..me too. Unfortunately, the spec does not have it in this form.
The config API of the RA is exactly what will add value to the sbb.

[Dominique Gallot]

My opinion is that the sbb should not be the owner of this configuration.

When compared with the ra entity, the main difference is that the Sbb in not singleton!

And even more the Sbbs may be shared in different services.

 

Why not set the owner of this configuration to the service, and using the ServiceManagementMBean jmx interface to set these configurations parameters?

 

Why not do something like the following

 

-         Add some service configurations entry in the service descriptor.

o        Add also a Boolean stating if this service support re-configuration

-         Allows to change it using the ServiceManagementMBean

-         Provide the configuration data to the sbb using the jndi

o        Why not java:comp/conf ?

-         Send an event to verify the configuration. How can we get the result of the validation?
The event object would contain the configuration.
We may add a method in the ServiceActivity interface? Any other options?

-         Send an event to the service activity when the configuration is changed.

 

By using a ServiceConfigued event, will allows the current Sbb entity to know that the service configuration changed. It is similar to the way than Sbb if informed when the service is started ( ServiceStartedEvent ).

 

What do you thing? If we come with a more or less standard solution, I will glad to add it to our implementation as well ( Alcatel-Lucent ).

 

Since we are talking about new feature in the jsr240, there is also no standard way for a resource adaptor to add a management bean to the container.

Of course you can write a mlet, but then you need two deliverables, and the MBean is somehow isolated, and cannot get a direct instance of the running ra.

 

What do you thinks? Should it be like now, each vendors implementing its own solution ?

 

 

Brs,

Dominique Gallot

[aayush bhatnagar]

There are 3 things that need consideration carefully here:

1. If every sbb (root sbb and child sbbs) becomes the owner of the its
configuration, and the sbb is part of more than one service, then any
changes to the sbb's configs will apply across all services it is a
part of. This should not happen.

This could lead to wrong behavior in some services.

2. To avoid the situation above, we have to either allow configs at a
service level like Dominique said,or only at the root sbb level of a
given service.

The problem with having configs at the service level is, that if there
is a reusable sbb which is common to 2 services, and we need that sbb
to read some configurations for correct behavior, then these configs
will need to be duplicated for both services.

This is because the root sbb of service A can be a child sbb of
Service B. This kind of parent child relations are allowed.

3. Config changes need to be applied only to that service which has
that sbb at its root and not to other services where this sbb is a
child. This is because every service is characterized by its root sbb.

Hence, i propose that JMX based configuration should be allowed only
for root sbbs of a given service. This is a middle path, where neither
are we allowing any conflicts across services, nor are we duplicating
data.

[Dominique Gallot]

>2. To avoid the situation above, we have to either allow configs at a
>service level like Dominique said,or only at the root sbb level of a
>given service.

 

Having two services which are sharing the same root sbb is also possible.
Some the moment such service have to load it configuration using the ServiceID as key.

 

> The problem with having configs at the service level is, that if there
>is a reusable sbb which is common to 2 services, and we need that sbb
>to read some configurations for correct behavior, then these configs
>will need to be duplicated for both services.

 

It makes sense, like for the ra. When you are create 2 ra entity, you also need to provide the configuration for both ra.

I also think that it is odd that only the root Sbb is able to access the configuration ( is it what mean configured in this case ? ).

The root sbb, is a sbb like any other one. The is nothing that prevent any sbb from being root of a service.

>This is because the root sbb of service A can be a child sbb of
>Service B. This kind of parent child relations are allowed.

 

And nothing prevents the child sbb of service B to be root of service A.

 

>Hence, i propose that JMX based configuration should be allowed only
>for root sbbs of a given service. This is a middle path, where neither
>are we allowing any conflicts across services, nor are we duplicating
>data.

 

I do not see where the conflict is. There is already service dependent information in any sbb ( root or child or neither )

 - In the Sbb Context ( getServiceId )

 - In the jndi view of the sbb ( ServiceFactory for instance )

 

Brs,

Dominique

[aayush bhatnagar]

>2. To avoid the situation above, we have to either allow configs at a
>service level like Dominique said,or only at the root sbb level of a
>given service.

 

Having two services which are sharing the same root sbb is also possible.
Some the moment such service have to load it configuration using the ServiceID as key.

This is possible theoretically. 2 services can reference a common root-sbb. Even though this is not the best of designs. It can be used for those services that differ in event delivery priority and wish to consume the same even in a particular sequence.  In this case, changes made to the configuration properties of this root sbb will be applicable to both services. 

 

> The problem with having configs at the service level is, that if there
>is a reusable sbb which is common to 2 services, and we need that sbb
>to read some configurations for correct behavior, then these configs
>will need to be duplicated for both services.

 

It makes sense, like for the ra. When you are create 2 ra entity, you also need to provide the configuration for both ra.

I also think that it is odd that only the root Sbb is able to access the configuration ( is it what mean configured in this case ? ).

The root sbb, is a sbb like any other one. The is nothing that prevent any sbb from being root of a service.

We cannot equate RA entities with SBBs/ SBB entities when it comes to configuration. SBB entities are created based on user preference (if he wishes to control creation) or for initial events as defined in the descriptor. 

RA entities are a representation of a resource adapter in the SLEE container and represent a unique instance of the underlying resource being adapted.

Now, we may have 2 resource adapters which might be adapting an underlying resource (say the JAIN SIP stack) in a different manner. 

My application acts either as a B2BUA or a UAS and I know this in advance. So I customize the SIP RA into 2 separate RAs to only keep the logic which is needed and remove the other logic which i feel is an overhead (SIP RA non-dialog activities, proxy logic, forking logic etc).

RA-1 is a B2BUA helper RA and RA-2 is a UAS helper RA.

RA entity-1 represents B2BUA RA in the SLEE and is responsible for a unique instantiation of the JAIN SIP stack

RA entity-2 represents UAS helper RA in the SLEE and is responsible for a unique instantiation of the JAIN SIP stack

For the SIP B2BUA RA I might have a configurable property which lets me decide one of the following roles: Initiating B2BUA or normal B2BUA. For the UAS RA, I have a config property that asks me to play a particular music file after creating a dialog. Properties of both these RAs may change independently of each other.

Hence, the container needs to maintain different configurations of both RA entities uniquely, as the configuration parameters will differ (as both RAs are adapting the SIP stack in their own unique way). 

Coming to Root SBBs and the logic behind the root sbb being the owner of the configuration:

A root SBB completely represents the service. The business logic of the service is contained in the event handlers, from where we may create any number of child SBBs to delegate responsibility or to take advantage of some common logic present in a child sbb. 

So, how the service will behave, which activities will it attach/detach from, which events will it consume etc are all determined by the Root sbb. 

Configuration changes are aimed at making this behavior configurable

Eg: do not attach to the dialog activity if a flag is set, proxy the request OR create childsbb-1 if flag is true else create childsbb-2.

Hence, I proposed that configurations must be associated with the root sbb. 

But, if this particular child sbb was a root sbb of service-X, and we changed the configuration wrt service-X, it will also affect the behavior of this child sbb in service-Y, as it is a common sbb. This cascading effect should not happen. However, if we really need to change some config of this child sbb in Service-Y, we can always define just that property in the root sbb and read it from there.

Having configs at the service level would mean, that all the config properties of the child sbb will be duplicated for Services X and Y

Some properties might be of no use to a given service Y as they may only be applicable to Service-X. For example --

I have a child SBB called MessagingChildSbb. It acts as the root sbb of the GSMMessagingService, where by default it sends and receives SMS messages and persists them to a database for deferred delivery. This sbb has the following configs: SMSC address and SMSC port which are defined at the Service level.

The same SBB acts as a child sbb of IMSMessagingService, where it is created ONLY for persisting SIP message content to the Database to provide deferred delivery in IMS and its SMS logic is unused. In this case, I will need to re-define the SMSC port and SMSC address properties at the Service level of the IMSMessagingService, even though they have no use in IMS. 

To avoid this duplication of SMSC properties in the IMS service, I will define IMS-specific properties in the root sbb of the IMSMessagingService while still retaining the SMSC specific child sbb properties nicely separated from the IMS root-SBB

Tomorrow, when I need to deliver SIP messages as SMS messages, I can re-use the existing SMSC properties already configured in the MessagingChildSbb.

[Dominique Gallot]

>This is possible theoretically. 2 services can reference a common root-sbb. Even >though this is not the best of designs. It can be used for those services that differ in >event delivery priority and wish to consume the same even in a particular sequence.  >In this case, changes made to the configuration properties of this root sbb will be >applicable to both services. 

Not only, may you also change the Address Profile Table. By using different “Address Profile Table” you may chose which service handles which call.

 

The spec clearly states that it is a possible design:

Two Services may reference the same root SBB, but the Services may provide different event dispatch priorities, reference different Address Profile Tables ( and Resource Info Profile Tables deprecated )..

 

The purpose of such design is clearly to allow the service to behave differently based for example of the MSISDN of the caller, don't you thing ?

 

>Some properties might be of no use to a given service Y as they may only be >applicable to Service-X.

 

I am not sure to understand this. If some configuration parameters are not needed for the service Y, we do not need to provide the configuration. It is up to the child Sbb to support non mandatory parameter are not there are not available.

 

>To avoid this duplication of SMSC properties in the IMS service, I will define IMS->specific properties in the root sbb of the IMSMessagingService while still retaining the >SMSC specific child sbb properties nicely separated from the IMS root-SBB

 

If only the root Sbb have a view on the configuration, how the child sbb will be able to get the configuration? How will be informed about a configuration changes?

Do not forget that a child Sbb can be connected to an ACI while a root sbb is not anymore, and so will not drive anything anymore.

 

Based on you comments, may be configuration properties should allows

 

-          configuration specific for the Sbb

-          configuration specific for the Service

-          And may be allows to override for a particular Sbb in a Service some configurations parameter

 

This will add the maximum level of flexibility, the sbb view on the configuration properties would be the merged view of these configurations.

Brs,

Dominique

[aayush bhatnagar]

Not only, may you also change the Address Profile Table. By using different “Address Profile Table” you may chose which service handles which call.

The spec clearly states that it is a possible design:

Two Services may reference the same root SBB, but the Services may provide different event dispatch priorities, reference different Address Profile Tables ( and Resource Info Profile Tables deprecated )..

The purpose of such design is clearly to allow the service to behave differently based for example of the MSISDN of the caller, don't you thing ?

I am not saying it is not possible. I was only listing one of the possible needs of this design. 

The purpose of this flexibility is for 2 JSLEE services to be able to share a common root sbb (as quoted above), but different addresses (addresses belonging to different MSISDN ranges let us suppose).

If the design requires the a single service to behave differently based on address, I would rather have one root sbb and one JSLEE service (and not 2 services sharing a root sbb as mentioned above).

I would inspect the MSISDN in the initial event selector of the root sbb to control root sbb entity creation if the MSISDN is in the range I need to handle.

Once the SBB entity is present, and the MSISDN is in Range X-to-Y, i will handle the business logic in the root sbb itself. 

If the MSISDN is in another range, say A-to-B and I wish to take further decisions, I can spawn the appropriate child sbb's to implement the specific behavior required : all as part of a single JSLEE service. 

I do not need to have 2 services as quoted in the spec above. 

 

>Some properties might be of no use to a given service Y as they may only be >applicable to Service-X.

 

I am not sure to understand this. If some configuration parameters are not needed for the service Y, we do not need to provide the configuration. It is up to the child Sbb to support non mandatory parameter are not there are not available.

Suppose a given sbb is common and re-usable to services X and Y. 

The sbb has 2 responsibilities: To send/receive a SMS in Service-X acting as a root sbb and to persist "messages encoded as Strings" in the database for Services X and Y, where it acts as a child sbb for service-Y. 

Both services use the DB logic of this sbb to persist messages as strings (SMS or Instant Messages etc). This makes it a re-usable sbb across services.

For this purpose, the child sbb defines the SMSC address and port as config parameters (to satisfy the requirements of service-X only). Service-Y has no specific configuration needs for this child sbb.

If you define config parameters on a JSLEE service level then these parameters will need to be defined for Services X and Y, even if they are not required for service-Y.  

Whether a parameter is mandatory or not is another issue. It may be mandatory for Service-X and optional for Service-Y. 

So, defining configurations on a Service level will also need to manage this issue. 

 

>To avoid this duplication of SMSC properties in the IMS service, I will define IMS->specific properties in the root sbb of the IMSMessagingService while still retaining the >SMSC specific child sbb properties nicely separated from the IMS root-SBB

 

If only the root Sbb have a view on the configuration, how the child sbb will be able to get the configuration? How will be informed about a configuration changes?

Do not forget that a child Sbb can be connected to an ACI while a root sbb is not anymore, and so will not drive anything anymore.

As i mentioned above, the IMS service specific configs are part of the root sbb, and the SMS related configs are still associated with the child sbb...and hence available to it. The only difference in my approach is, that the IMS specific configs are defined on the level of the Root Sbb and not the service. 

This means, that if somebody changes the SMSC port in the GSMMessagingService (where the MessagingChildSbb happens to be the root sbb), this particular change will not be cascaded to the IMSMessagingService (where the MessagingChildSbb is the child sbb).

Now regarding the child sbb getting a view of the parent sbb configs:

It is possible for the child sbb to read the configs from the parent sbb. As far as cascading removal of SBB entity trees is concerned, it has to be controlled by the business logic on the basis of ACI attach/detach and this is a separate issue.

Child sbb to parent sbb invocation can be done by passing the parent sbb local object callback reference to the child, and the child sbb will store it. It will happen like this: 

1. Parent sbb creates child sbb.

2. childSbb.setParentSbb((CallbackParentSbbLocalObject) this.sbbContext.getSbbLocalObject()); // child sbb will store parent reference in the CMP field.

See this sbb local object as an example for callback sbb local object interface: http://mobicents.googlecode.com/svn/trunk/servers/sip-presence/xdm/client/sbb-local-object/src/main/java/org/mobicents/slee/xdm/server/XDMClientControlParentSbbLocalObject.java

3. Now in the child sbb, use this callback interface towards the parent sbb to access configuration data 'owned' by the root sbb.

 

Based on you comments, may be configuration properties should allows

 

-          configuration specific for the Sbb

-          configuration specific for the Service

-          And may be allows to override for a particular Sbb in a Service some configurations parameter

 

Exactly. Just that the configuration specific for a service is being represented by the RootSbb in my viewpoint (Every service will need to have a root sbb). 

Configuration specific to the sbb can be a subset of this (root sbb configs + child sbb configs etc).

This will add the maximum level of flexibility, the sbb view on the configuration properties would be the merged view of these configurations.

Agreed. So, what should be the next steps? Should this be proposed as a value added (non-standard) feature or proposed as a possible enhancement in the spec for kind consideration of the JSR-240 expert group ? A possible API can be made with the help of our Mobicents experts as tabled as a roadmap issue.

[Dominique Gallot]

>I do not need to have 2 services as quoted in the spec above.

It is just a possible implementation, the spec is really flexible.

>Now regarding the child sbb getting a view of the parent sbb configs:
I aggree that in your case, you have a view on the parent local interface.
But in most case doing this, simply mean the the child sbb can only used by a well know parent ( implementing this interface ).

>Agreed. So, what should be the next steps? Should this be proposed as a value added (non-standard) feature or proposed as a >possible enhancement in the spec for kind consideration of the JSR-240 expert group ? A possible API can be made with the help >of our Mobicents experts as tabled as a roadmap issue.

The JSR-240 is now the the final state, I do not belive that they can add new feature to the spec now.

Brs,
Dominique Gallot

[Eduardo Martins]

On current form the SBB configuration is the same for all services,
and in my humble opinion that makes sense to exist, the idea of the
SBB is to be independent logic reusable by different services. Now,
the same way as one can modify the default behavior for a root sbb,
through different priority or different profile data, I believe it
should be possible for a service to redefine the root sbb
configuration. What do you guys think of it?

Dominique, JSR 240 ended long time ago, but this can be implemented
through extensions, on top of the env-entry concept, while a new
revision of the spec is not on the works.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

[Dominique Gallot]

I quickly check your implementation of the jndi tree binding, it seems that like us, you only contruct a jndi tree by sbb type.
However having the service configuration property would mean that somehow, the sbb jndi tree will now also depends on the service data.
In this case, we may encounter a problem when the Sbb is root for multiple service, but we probably can live with this.

Let's be pragramic, and use your proposition, allows the environment variable for root sbb to be overriden / added? by the service configuration ?
And add a method to update this configuration in the ServiceManagmentMBean. Of course these parameters would have to be persisted by the container.

Let's also send a event on the service activity, to notify the sbb that the configuration changed.

Dominique

[Eduardo Martins]

On Thu, May 20, 2010 at 12:25 AM, Dominique Gallot
<dominiqu...@gmail.com> wrote:
>
> I quickly check your implementation of the jndi tree binding, it seems that
> like us, you only contruct a jndi tree by sbb type.
> However having the service configuration property would mean that somehow,
> the sbb jndi tree will now also depends on the service data.
> In this case, we may encounter a problem when the Sbb is root for multiple
> service, but we probably can live with this.

Building a JNDI tree per service + sbb would not be a big problem, but
for containers using sbb object pools - like mobicents - this would
mean that after an update all existent objects must be invalidated,
cause those could have local resources (fields) built using the env
entries values.

Anyway, an alternative which I prefer, would be to add configuration
related lifecycle callbacks on an extension of the Sbb interface,
similar to ResourceAdaptor, leaving the env entries with the sbb xml
values as the specs define.

Well, why not go beyond this and approach the SBB API with the simpler
to use (and understand) RA API, going completely around JNDI on the
spec, using instead the SbbContext the way ResourceAdaptorContext is
used to retrieve facilities or anything else... But still keeping JNDI
standard ways working...

> Let's be pragramic, and use your proposition, allows the environment
> variable for root sbb to be overriden / added? by the service configuration
> ?
> And add a method to update this configuration in the ServiceManagmentMBean.
> Of course these parameters would have to be persisted by the container.
> Let's also send a event on the service activity, to notify the sbb that the
> configuration changed.

Not sure about this event, cause events target Sbb entities and this
is more a Sbb object notification.

[aayush bhatnagar]

One of the approaches I was thinking in attached document.

(not pasting answer here, google groups messes up the formatting !!).

[Dominique Gallot]

I like this design even it is probably the one which imply the more development.
It allows to set the configuraiton from the sbb, but I am not sure that this will be usefull in real live application.

In order to get the configuraiton local interface
 - we may either define a abstract method like for the usage, or the old way of accessing the profile. It will be typed
 - or get it from the sbb Context, then we can only return an Object, and the developer will have to cast it

Brs;

[Dominique Gallot]

[Dominique Gallot]

Anyway, an alternative which I prefer, would be to add configuration
related lifecycle callbacks on an extension of the Sbb interface,
similar to ResourceAdaptor, leaving the env entries with the sbb xml
values as the specs define.

Adding this will not add some performances impact ?
The sbb will have to be configured during the creating of each entity, and store it for futur use.

Well, why not go beyond this and approach the SBB API with the simpler
to use (and understand) RA API, going completely around JNDI on the
spec, using instead the SbbContext the way ResourceAdaptorContext is
used to retrieve facilities or anything else... But still keeping JNDI
standard ways working...

Yes, it is an even simplier solution. Just add a getConfigProperties() in the SbbContext.

[Dominique Gallot]

Not sure about this event, cause events target Sbb entities and this
is more a Sbb object notification.

It will add flexibility, allowing a sbb developer to attach to the service activity context interface to get notification about the configuration changes.
It see this to allows long running activity to get notify about configuraiton change, to alter the current activity behavour.

Dominique

[aayush bhatnagar]

Maybe, we can have a onConfigurationStarted () initial event, which is
delivered to the sbb entity the first time the container installs the
ConfigurationSpecification.

This event can be fired on a SLEE owned configActivity to those sbbs
which have mentioned this event in their descriptor.

The sbb developer has a choice to attach to the configActivity in this
event to receive callbacks on config changes in the future:
onConfigUpdated() on every change, onConfigStopped() during graceful
shutdown of SLEE etc.

[Eduardo Martins]

On Thu, May 20, 2010 at 1:49 PM, Dominique Gallot
<dominiqu...@gmail.com> wrote:
>
>> Anyway, an alternative which I prefer, would be to add configuration
>> related lifecycle callbacks on an extension of the Sbb interface,
>> similar to ResourceAdaptor, leaving the env entries with the sbb xml
>> values as the specs define.
>>
>
> Adding this will not add some performances impact ?
> The sbb will have to be configured during the creating of each entity, and
> store it for futur use.

It's just another lifecycle method called in the sbb object, not the
sbb entity, but this would be just to mimic the ResourceAdaptor API,
keeping consistency, it could also be exposed by SbbContext like you
say below.

Regarding storing configuration, this is only done when using it to
setup some local resources shared by all sbb entities that use the
object, I guess this will continue to happen in those cases, to
optimize processing the "generic" config properties.

>> Well, why not go beyond this and approach the SBB API with the simpler
>> to use (and understand) RA API, going completely around JNDI on the
>> spec, using instead the SbbContext the way ResourceAdaptorContext is
>> used to retrieve facilities or anything else... But still keeping JNDI
>> standard ways working...
>
> Yes, it is an even simplier solution. Just add a getConfigProperties() in
> the SbbContext.

What about going around JNDI for everything, would this be a good change?

[Eduardo Martins]

Like I said this notification is needed only at sbb object level, not
sbb entity. It is the sbb object that needs to be notified if it's
pooled and is going to be reused. Remember that configuration is
shared by all sbb entities.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

[Eduardo Martins]

What would be the usage of those events?

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

[Eduardo Martins]

It's a good thought design but this goes against the simplification of
the SLEE specs. IMHO it is overkill, and that's why I'm not a fan of
Profiles too.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

[aayush bhatnagar]

We can refine it then..and expose a simpler contract to the sbb developer.

For any configuration module/api/facility, there can be 2 clients :
the sbb who wishes to store, update and read config data, and external
OSS agents who wish to get/set data from some management entity like
CLI or provisioning platform. These are the bare minimum requirements.

Sharing and re using config data across sbbs and services can be
skipped..if it adds complexity. So, if we dont have to re use the same
config data across sbbs, then these events are of no use.

[Dominique Gallot]

>Like I said this notification is needed only at sbb object level, not
>sbb entity. It is the sbb object that needs to be notified if it's
>pooled and is going to be reused. Remember that configuration is
>shared by all sbb entities.

It is odd that a life cyle method of the sbb will only be called on the root sbb.

>Regarding storing configuration, this is only done when using it to
>setup some local resources shared by all sbb entities that use the
>object, I guess this will continue to happen in those cases, to
>optimize processing the "generic" config properties.

As long as the sbb is only uses with the same service it is true.
Our pooling system, does not implements this for the moment. ( Just a pool of sbb, not sbb in a service, which perfectly match the current spec )

Let image 2 services which has both a Shared SBB uses to send SMS.

We cannot store the configuraiton in a member of the SendSmsSbb, because it belong to both service.
However we can for the RootSbb because it is not shared between differents service.
So each time a child sbb need the configuration parameter it need to request it to the rootSbb ( to get the current value ).

Do you thing that this is not a problem ?

>What would be the usage of those events?

That true that we only need to change the value of the current sbb object ( and not the current sbb entity ). Therefor a event is overkill.

Do not you thing that forcing the Child Sbb to have a link to the root sbb, in order to get the configuraiton is removing flexibility for the sbb developer ?

Dominque

[aayush bhatnagar]

Some other uses of these event callbacks:

If one sbb modifies config data..or some external provisioning agent
modifies this data over the mbean, this event would allow the sbbs to
get informed about these changes and to take some action over this
change:

Examples:

1. Create a sms child sbb that sends a sms to the administrator or an
email to inform of this change.

2. Raise a trap/alarm notification etc on this event,

3. A SLEE application can notify the customer of a new offer over a
SIP IM because the existing telco service offer was modified by the
config agent by the carrier, and a notification had to be sent to all
customers.

4. Increment a usage parameter that tracks the number of modifications
made to config data.

On 20/05/2010, Dominique Gallot <dominiqu...@gmail.com> wrote:

[aayush bhatnagar]

These events will be an overkill, if they are always fired. However,
if the application does not want them, it can choose not to listen to
them.

[aayush bhatnagar]

[Eduardo Martins]

My proposal is like this:

1) reuse RA xml descriptor config properties in the sbb xml descriptor

<config-property>
<description/>
<config-property-name/>
<config-property-type/>
<config-property-value/>
</config-property>

2) allow service xml descriptor to redefine a specific sbb config
properties (btw can't find a reason to limit this to root sbb)

<sbb-config-override>
<sbb-ref>
<description/>
<sbb-name/>
<sbb-vendor/>
<sbb-version/>
</sbb-ref>
<config-property>
<description/>
<config-property-name/>
<config-property-type/>
<config-property-value/>
</config-property>
</sbb-config-override>

3) expose getters/setters in a ServiceManagementExtMBean similar to
the ones in ResourceManagementMBean

public ConfigProperties getConfigurationProperties(ServiceID
serviceID, SbbID sbbID)
throws NullPointerException, UnrecognizedServiceException,
ManagementException;

public void updateConfigurationProperties(ServiceID serviceID, SbbID
sbbID, ConfigProperties properties)
throws NullPointerException, UnrecognizedServiceException,
InvalidStateException, InvalidConfigurationException,
ManagementException;

4) add to a SbbExt interface, with same reasoning as the related ones
in ResourceAdaptor interface.

public void sbbConfigure(ConfigProperties properties);
public void sbbVerifyConfiguration(ConfigProperties properties)
throws InvalidConfigurationException
public void sbbConfigurationUpdate(ConfigProperties properties)

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

On Thu, May 20, 2010 at 3:58 PM, aayush bhatnagar

[Eduardo Martins]

On Thu, May 20, 2010 at 4:15 PM, Dominique Gallot
<dominiqu...@gmail.com> wrote:
>>Like I said this notification is needed only at sbb object level, not
>>sbb entity. It is the sbb object that needs to be notified if it's
>>pooled and is going to be reused. Remember that configuration is
>>shared by all sbb entities.
>
> It is odd that a life cyle method of the sbb will only be called on the root
> sbb.

It's called on all sbb objects.

>>Regarding storing configuration, this is only done when using it to
>>setup some local resources shared by all sbb entities that use the
>>object, I guess this will continue to happen in those cases, to
>>optimize processing the "generic" config properties.
>
> As long as the sbb is only uses with the same service it is true.
> Our pooling system, does not implements this for the moment. ( Just a pool
> of sbb, not sbb in a service, which perfectly match the current spec )
> Let image 2 services which has both a Shared SBB uses to send SMS.
>
> We cannot store the configuraiton in a member of the SendSmsSbb, because it
> belong to both service.
> However we can for the RootSbb because it is not shared between differents
> service.
> So each time a child sbb need the configuration parameter it need to request
> it to the rootSbb ( to get the current value ).
>
> Do you thing that this is not a problem ?

JAIN SLEE 1.1 defines that a sbb object cannot be shared between services.

>>What would be the usage of those events?
> That true that we only need to change the value of the current sbb object (
> and not the current sbb entity ). Therefor a event is overkill.
>
> Do not you thing that forcing the Child Sbb to have a link to the root sbb,
> in order to get the configuraiton is removing flexibility for the sbb
> developer ?

I think you misunderstood my proposal at some point, maybe my last
mail is clear?

> Dominque

[Eduardo Martins]

On Thu, May 20, 2010 at 4:20 PM, aayush bhatnagar
<abhatnag...@gmail.com> wrote:
> Some other uses of these event callbacks:
>
> If one sbb modifies config data..or some external provisioning agent
> modifies this data over the mbean, this event would allow the sbbs to
> get informed about these changes and to take some action over this
> change:
>
> Examples:
>
> 1. Create a sms child sbb that sends a sms to the administrator or an
> email to inform of this change.
>
> 2. Raise a trap/alarm notification etc on this event,

Sbbs do not change config data, only read it, config data would be
changed by container admin, through JMX, lets not mix roles. This
model is really the same as the one for ResourceAdaptor.

> 3. A SLEE application can notify the customer of a new offer over a
> SIP IM because the existing telco service offer was modified by the
> config agent by the carrier, and a notification had to be sent to all
> customers.

That's mixing service logic with configuration.

> 4. Increment a usage parameter that tracks the number of modifications
> made to config data.

I don't see why you could not use the sbb usage param to do that.

[aayush bhatnagar]

As decided, it can be stored at both levels..sbb and service. No limitation.

And as shown above, <config-property> of service.xml can override the
sbb specific configs for the sbb given in <sbb-ref>

On 20/05/2010, Eduardo Martins <emma...@gmail.com> wrote:

[Eduardo Martins]

To make it a bit more clear, sbb xml defines default config properties
values, which service xml may override, which in turn JMX may
override.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

On Thu, May 20, 2010 at 5:05 PM, aayush bhatnagar

[aayush bhatnagar]

For point 4, i will use the usage parameter facility only...but
increment it on config changes. This usage parameter will count the
number of config changes. Many telecom products maintain counters that
count administrative actions.

For point 3, this is a customer care type application, where some
actions have to be taken based on OSS actions made to config
data...like a discount notification, new offer, plan etc..are all made
configurable by operators.

However, if updateConfigurationProperties() method is available to the
sbb, then this logic can be executed there.

On 20/05/2010, aayush bhatnagar <abhatnag...@gmail.com> wrote:

[aayush bhatnagar]

[Eduardo Martins]

I believe those would be better implemented with service logic, but to
not shut the door perhaps those events on the service activity could
be used.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

On Thu, May 20, 2010 at 5:14 PM, aayush bhatnagar

[Dominique Gallot]

>I think you misunderstood my proposal at some point, maybe my last
>mail is clear?

You latest mail is perfect, I totaly aggree with the proposed solution.

But one point is really interessing ( at least for me )

> JAIN SLEE 1.1 defines that a sbb object cannot be shared between services.

I missed this one, your right it is clearly states in the spec ( been added in 1.1 ).
Thanks for this one, we passed all the tck test, but only have a pool of sbb Object shared beween services.
The tck does not check this.
 
Brs,
Dominique

[Naresh Ramani]

really complex discussion for beginner like me..all overhead transmission, but it sounds good if we have this feature.

thanks for bringing this up aayush, dominique, eduardo for discussing it in detail here and freezing it. 

so with this feature :

 

1. sbb has a placeholder to store configuration data of its own - sbb level

2. some external client can access this data (some management entity) - management level

3. service can override sbb configurations if needed - service level

sounds very good features and flexible too.

thanks for this.

[David Ferry]

From a historical perspective (JSLEE standard spec-lead view), we had
three systems for config data, in the standard.

a) Java attributes, constants (compile time only)
b) Environment entries (static, only really changing at deploy time,
could be read in setSbbContext() and saved into an SBB objects
attributes)
c) 1.0 Profiles (could be read by SBBs, could be changed by
administrators, so they were dynamic)

As a product company (OpenCloud) we recommended that people used 1.0
Profiles. We found that the "could be changed by administrators but
not by SBBs" was too rigid.

So in 1.1 we made Profiles read/write from the SBB as well as RA (SLEE
component view in terms of the spec). We also put a lot more features
into Profiles, based on use-cases from Operators. Some of these
features blur the boundary of what is an a "classical Database" and
what is in a "software framework" ... which has always been the way in
Telecom Call Processing systems.

So back to "just configuration" ... as a product company we recommend
that people use 1.1 Profiles for Configuration. It works well, for us
at least. Admins can view/change the configuration, SBBs can do that
too, and even be notified when changes occur (Profile Update Events)

What I don't understand is why there seems to be a view that something
new is needed, given that there are (at least in my view) three
standard systems you can use for configuration information.

[Eduardo Martins]

David, in my humble opinion querying a database to get a simple sbb
configuration is a big penalty, imagine all sbb objects doing it, then
sbb entities attaching to profile table activity to get updates, etc.
Then the tools will grow in complexity too. The same reasoning applies
for RA entities, which have access to profiles but have the simple
config means.

Anyway, I don't see this as a replacement for Profiles in any way, I
see this as a replacement for env-entries in the future, simplifying
the spec, making the sbb/service config consistent with RA config.

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

[aayush bhatnagar]

Let us consider this discussion from a different perspective (a slightly non-technical view): 

In my view, any JSLEE application deployed on the telecom services tier would be maintaining 2 types of data:

1. Customer subscription data regarding the list of his/her subcribed services, current service status of the customer (active/inactive), tariff plan information on these services (to decide the amount of credits to reserve over DIAMETER Ro interface) and billing related pre-provisioned data (whether the customer is prepaid or postpaid)

2. Internal application configuration data which is consumed by the service logic captively and is not visible to the OSS:

Some Examples: hashTableSize, minTimerDuration, maxTimerDuration,isWildcardPSIsEnabled flag,defaultRegistrationTimerDuration,collectUsageParametersForRegistrations flag, isB2BUAModeEnabled flag etc. 

----

The data specified in point-1 is supplied by a OSS entity when the customer will be first provisioned to avail the services hosted on JAIN SLEE. In my opinion, profile tables should be used only to store data which is instrumentable by an Operation Support Subsystem.

This pre-provisioned data will help the application decide whether to carry out service delivery for a customer at all (based on his provisioned activation status) how to charge the customer over diameter (prepaid or postpaid) and the volume of credits to reserve for prepaid customers (based on his current Tariff plan) etc.

Usually to store, maintain, access and modify such "customer profile" data, we require a complex data model and data access semantics (in the form of static queries). Of course this is dependent on the application -- If we are implementing a HSS/HLR or an IN platform, then the data model will be huge. If we are implementing a simple Instant Messaging server,the data model will not be so challenging.

We may also need to take certain actions based on administrative commands that modify this data:

Eg: customer's services have been deactivated due to non-payment of bills..de-register him from the network immediately over SIP.

For such cases, we will need callbacks on changes to such data (which we have as Profile events).

Hence, such kind of data justifies the use of Profiles. Even though, nobody prevents us to bypass this layer and use a Database directly to meet our needs. But then, the application will be responsible to detect changes in this data.

-----

However, the nature of data in point-2 above is more relevant to an Element Management System (EMS). This kind of data is of relevance to the network entity itself, its internal functioning and is never exposed to the OSS. 

Moreover, this kind of data is also much more trivial when compared to a customer profile in terms of the complexity. It is either instrumented over SNMP get/set or from a CLI locally at runtime.

Maintaining such data in a Profile Table, in my view is an added complexity. We will need to hit the DB to get this simple data.

Even though it is technically feasible (as I wrote in the very first post in this thread), for maintaining simple data such as flags or default timer values, a simpler solution is desirable. 

We were trying to arrive at such a solution, so as to achieve the following: 

FCAPS data accessable to the EMS to be maintained in a configuration framework external to profiles, while still leaving the OSS specific provisioning data in the form of profile tables if needed.

Usually all OSS/BSS systems have a southbound interface towards the EMS/NMS. They can pull this data from there if it is really required.

[David Ferry]

Eduardo,

You seem to have the idea that querying a Profile == querying a
database.
I don't see that as the case. If Profiles are implemented in a heap-
resident cache (holding the entire set of data in JVM-heap) .. and the
data is persisted in a disk-based DB then we are querying the heap.
Then we don't need to worry about performance so much. This is what
Rhino does.
The attach-to-profile-table-activity to get an update isn't designed
for existing SBB entities, its more a case of kicking something off if
the config changes.

We tend to have a pattern in the SBB where we read any config from the
Profile in sbbPostCreate and then store it to the SBB's CMP. We don't
tend to look for configuration updates during a call/session.

I take the point about RA config properties being helpful compared to
JNDI.
One of the reasons to invent the RA config mechanism was due to
restrictions around JNDI (it was related to thread-context
classloaders).

Making the SBB config system have something more like RA Config
Properties is interesting.

Just thinking out loud ... the mechanism is a little bit easier in RAs
because the RA Object is not a pooled object, so we can just call a
method the RAO when the data changes.
With SBB Objects its not really suitable to do that, because you can
have many thousands of them in an object pool. So the SBB still needs
to look "somewhere" external to its own Object.
Perhaps this might be an Object that SBBs can access through their SBB
Context, or more magic methods on the SBB abstract class.

-David

On May 21, 3:37 pm, Eduardo Martins <emmart...@gmail.com> wrote:
> David, in my humble opinion querying a database to get a simple sbb
> configuration is a big penalty, imagine all sbb objects doing it, then
> sbb entities attaching to profile table activity to get updates, etc.
> Then the tools will grow in complexity too. The same reasoning applies
> for RA entities, which have access to profiles but have the simple
> config means.
>
> Anyway, I don't see this as a replacement for Profiles in any way, I
> see this as a replacement for env-entries in the future, simplifying
> the spec, making the sbb/service config consistent with RA config.
>
> -- Eduardo
>

> -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-http://emmartins.blogspot.comhttp://www.redhat.com/solutions/telco

[rajat]

so this feature will be imeplemeted in jain slee in the future ? should an issue be added for this feature on issue tracker?