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.
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.
On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <abhatnagar192...@gmail.com
> 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.
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.
On Mon, May 17, 2010 at 22:28, Naresh Ramani <naresh.ramani...@gmail.com>wrote:
> 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.
> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
> abhatnagar192...@gmail.com> wrote:
>> 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.
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
On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
abhatnagar192...@gmail.com> wrote:
> 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.
> On Mon, May 17, 2010 at 22:28, Naresh Ramani <naresh.ramani...@gmail.com>wrote:
>> 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.
>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
>> abhatnagar192...@gmail.com> wrote:
>>> 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.
> 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
> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
> abhatnagar192...@gmail.com> wrote:
>> 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.
>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
>> <naresh.ramani...@gmail.com>wrote:
>>> 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.
>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
>>> abhatnagar192...@gmail.com> wrote:
>>>> 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.
<abhatnagar192...@gmail.com> wrote:
> 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 <dominique.gal...@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, … ).
>> Best Regards,
>> Dominque Gallot
>> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
>> abhatnagar192...@gmail.com> wrote:
>>> 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.
>>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
>>> <naresh.ramani...@gmail.com>wrote:
>>>> 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.
>>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
>>>> abhatnagar192...@gmail.com> wrote:
>>>>> 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.
> On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar
> <abhatnagar192...@gmail.com> wrote:
>> 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 <dominique.gal...@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, … ).
>>> Best Regards,
>>> Dominque Gallot
>>> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
>>> abhatnagar192...@gmail.com> wrote:
>>>> 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.
>>>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
>>>> <naresh.ramani...@gmail.com>wrote:
>>>>> 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.
>>>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
>>>>> abhatnagar192...@gmail.com> wrote:
>>>>>> 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.
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
On Wed, May 19, 2010 at 12:55 PM, aayush bhatnagar <
abhatnagar192...@gmail.com> wrote:
> 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.
> On 19/05/2010, Eduardo Martins <emmart...@gmail.com> wrote:
> > I vote for a configuration similar to RA entities, exposed through JMX :)
> > On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar
> > <abhatnagar192...@gmail.com> wrote:
> >> 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 <dominique.gal...@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, … ).
> >>> Best Regards,
> >>> Dominque Gallot
> >>> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
> >>> abhatnagar192...@gmail.com> wrote:
> >>>> 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.
> >>>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
> >>>> <naresh.ramani...@gmail.com>wrote:
> >>>>> 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.
> >>>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
> >>>>> abhatnagar192...@gmail.com> wrote:
> >>>>>> 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.
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.
On 19/05/2010, Dominique Gallot <dominique.gal...@gmail.com> wrote:
> 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
> On Wed, May 19, 2010 at 12:55 PM, aayush bhatnagar <
> abhatnagar192...@gmail.com> wrote:
>> 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.
>> On 19/05/2010, Eduardo Martins <emmart...@gmail.com> wrote:
>> > I vote for a configuration similar to RA entities, exposed through JMX
>> > :)
>> > On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar
>> > <abhatnagar192...@gmail.com> wrote:
>> >> 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 <dominique.gal...@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, … ).
>> >>> Best Regards,
>> >>> Dominque Gallot
>> >>> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
>> >>> abhatnagar192...@gmail.com> wrote:
>> >>>> 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.
>> >>>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
>> >>>> <naresh.ramani...@gmail.com>wrote:
>> >>>>> 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.
>> >>>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
>> >>>>> abhatnagar192...@gmail.com> wrote:
>> >>>>>> 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.
*>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 )
> On 19/05/2010, Dominique Gallot <dominique.gal...@gmail.com> wrote:
> > 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
> > On Wed, May 19, 2010 at 12:55 PM, aayush bhatnagar <
> > abhatnagar192...@gmail.com> wrote:
> >> 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.
> >> On 19/05/2010, Eduardo Martins <emmart...@gmail.com> wrote:
> >> > I vote for a configuration similar to RA entities, exposed through JMX
> >> > :)
> >> > On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar
> >> > <abhatnagar192...@gmail.com> wrote:
> >> >> 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 <dominique.gal...@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, … ).
> >> >>> Best Regards,
> >> >>> Dominque Gallot
> >> >>> On Wed, May 19, 2010 at 9:16 AM, aayush bhatnagar <
> >> >>> abhatnagar192...@gmail.com> wrote:
> >> >>>> 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.
> >> >>>> On Mon, May 17, 2010 at 22:28, Naresh Ramani
> >> >>>> <naresh.ramani...@gmail.com>wrote:
> >> >>>>> 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.
> >> >>>>> On Wed, May 5, 2010 at 8:18 AM, aayush bhatnagar <
> >> >>>>> abhatnagar192...@gmail.com> wrote:
> >> >>>>>> 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
> *>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.
>> On 19/05/2010, Dominique Gallot <dominique.gal...@gmail.com> wrote:
>> > 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
>> > On Wed, May 19, 2010 at 12:55 PM, aayush bhatnagar <
>> > abhatnagar192...@gmail.com> wrote:
>> >> 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.
>> >> On 19/05/2010, Eduardo Martins <emmart...@gmail.com> wrote:
>> >> > I vote for a configuration similar to RA entities, exposed through
>> JMX
>> >> > :)
>> >> > On Wed, May 19, 2010 at 9:48 AM, aayush bhatnagar
>> >> > <abhatnagar192...@gmail.com> wrote:
>> >> >> 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 <dominique.gal...@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
>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
On Wed, May 19, 2010 at 5:35 PM, 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.
>> Brs,
>> Dominique
>>> On 19/05/2010, Dominique Gallot <dominique.gal...@gmail.com> wrote:
>>> > 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 ).
> 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.
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.
> On Wed, May 19, 2010 at 5:35 PM, aayush bhatnagar <
> abhatnagar192...@gmail.com> wrote:
>> *>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
>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
On Wed, May 19, 2010 at 8:01 PM, 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.
> 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.
>> Brs,
>> Dominique
>> On Wed, May 19, 2010 at 5:35 PM, aayush bhatnagar <
>> abhatnagar192...@gmail.com> wrote:
>>> *>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
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.
<dominique.gal...@gmail.com> wrote:
>>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
> On Wed, May 19, 2010 at 8:01 PM, aayush bhatnagar
> <abhatnagar192...@gmail.com> wrote:
>>> 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/cl... >> 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.
>>> Brs,
>>> Dominique
>>> On Wed, May 19, 2010 at 5:35 PM, aayush bhatnagar
>>> <abhatnagar192...@gmail.com> wrote:
>>>>> >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
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
On Thu, May 20, 2010 at 12:29 AM, Eduardo Martins <emmart...@gmail.com>wrote:
> 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.
> On Wed, May 19, 2010 at 8:37 PM, Dominique Gallot
> <dominique.gal...@gmail.com> wrote:
> >>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
> > On Wed, May 19, 2010 at 8:01 PM, aayush bhatnagar
> > <abhatnagar192...@gmail.com> wrote:
> >>> 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:
> >>> 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.
> 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.
On Thu, May 20, 2010 at 17:07, Eduardo Martins <emmart...@gmail.com> wrote:
> On Thu, May 20, 2010 at 12:25 AM, Dominique Gallot
> <dominique.gal...@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.
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;
On Thu, May 20, 2010 at 2:09 PM, aayush bhatnagar <
abhatnagar192...@gmail.com> wrote:
> One of the approaches I was thinking in attached document.
> (not pasting answer here, google groups messes up the formatting !!).
> On Thu, May 20, 2010 at 17:07, Eduardo Martins <emmart...@gmail.com>wrote:
>> On Thu, May 20, 2010 at 12:25 AM, Dominique Gallot
>> <dominique.gal...@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.
> On Thu, May 20, 2010 at 12:25 AM, Dominique Gallot
> <dominique.gal...@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.
> 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.
> > 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.
> 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.
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.
On 20/05/2010, Dominique Gallot <dominique.gal...@gmail.com> wrote:
>> 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.
>> 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?
>> > 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.
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.
>> 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.
