Rafal,
Sorry, I bacame too absorbed in my own problem to examine this general one.
But yes, your solution is of cource a more elegant and safer one and would
perfectly fulfil our needs.
We've defined a JMX bean, implementing a ServiceHolderMBean interface, which
is a generic holder of Turbine service implementations. It's the
responsibility of this holder class instances to instantiate their specific
services and read service properties to TurbineResourceService (we've split
the TurbineResources.properties file into a common property file and service
specific property files). As the goal of a JMX system is to be as dynamic as
possible supporting changes in its configuration during run-time without
shutdown/restart, this approach makes it possible to load new services and
reload existing services through this holder class without affecting the
clients of the services. As the holder class is a bean, it can be managed
with the JMX tools. As it instantiates its service implementation by calling
the instantiation tools of the JMX server, it can use other class loaders
than the default one to instatiate service implementations from outside the
system by using its protocol adapters. The default holder implementation can
instantiate any "ordinary" Turbine service, including all the current ones.
An extended version is a wrapper providing access for Turbine clients to
services implemented originally as beans. So this holder class is a two-way
bridge between Turbine services/clients and JMX services/clients. To make
this model work, an essential service is a new ServiceBroker getting service
instances from the holder beans through the JMX server instead of
instantiating them itself. Everything seems to work fine without any code
changes to existing TDK code except the TurbineServices hack (Log was the
other one before the Logging service, that works also fine now, thank you!).
In addition to the service broker service, we've implement as JMX beans our
own Logging service and an extension to the assembler broker service. The
idea is to provide the same kind of configurability and managebility for
assembler modules as for services. Instead of resolving the module instance
based on its class name, the assembler bean can be a holder of several
assembler implementations, from which it chooses the one to use based on its
own state information and run data. In addition to dynamic confuguration and
management, the benefit is to be able to make modules that are internal to a
specific bean having access to its internal state. This is useful when
implementing session oriented services for separate groups of users.
However, the original broker is used in most cases (the assembler broker
service nicely supports several brokers).
Our application bean services are related to management of network devices
including alarm polling, device configuration, retrieval of performance
data, route planning, etc. As the physical structure of the network changes
quite often, it's important to have a management system that can adapt
itself to these changes during run-time without shutdown and manual
configuration. The system polls the network and scans the above information
providing it to users or higher level management systems after refining it
into standardized form. In some cases, the device provides its own
configuration service that must be loaded to the system through some
communication channel. The original idea was to use Turbine mainly for
dynamically generated user interfaces, but as it seems to provide a nice
abstraction to services also, we have decided to try to adopt it for
accessing JMX services in a more developer friendly way (the generic holder
class can take care of most of the JMX stuff).
The key protocal adapters are HTTP and SNMP. In addition, we need to
implement a couple of more rare adapters for network management. Sun
provides two versions of the JMX server/agent framework. The reference
implementation (RI) is free under open license. A commercial version (JDMK)
provide some additional protocol adapters, namely the SNMP adapter that is
not included in RI. The only other JMX framework implementation I know about
is AdventNet's SNMP API. However, there are several applications that expose
some of their functionality as JMX instrumentation beans, which can then be
added to e.g. Sun's RI (you mentioned JBoss and Enhydra, which apply JMX in
web server management, most applications are in the network management
domain). The management layer is then on top of the JMX server layer.
Management applications should provide even higher level services on top of
several JMX server applications. I've heard from Sun that there are several
large projects going on in this area, but I don't know the details.
If you sometimes plan to include any JMX support to TDK, feel free to ask
more information about our approach. The Turbine related components are not
confidential in any way, although maybe not directly suitable to be detached
from their context.
-- Ilkka
--
Nokia Networks
http://www.nokia.com/networks
mail: [EMAIL PROTECTED]
> -----Original Message-----
> From: ext Rafal Krzewski [mailto:[EMAIL PROTECTED]]
> Sent: 31. January 2001 13:17
> To: Turbine
> Subject: Re: [WISH] Services
>
>
> [EMAIL PROTECTED] wrote:
>
> > Something like this:
>
> > if (instance == null)
> > {
> > synchronized(TurbineServices.class)
> > {
> > if (instance == null)
> > instance = new TurbineServices();
> > }
> > }
> > return instance;
>
> > Would allow subclasses to assign their own service broker
> implementation to
> > the static instance member before getInstance() is called.
>
> This was done exactly this way until revision 1.14 of the Broker. Jon
> changed
> that to fix doble locking pattern. He posted an URL to an article that
> gives
> rationale for that.
>
> I think that right now TurbineServices should be the only
> real singleton
> in
> the system (correct me if I'm wrong). It is not instantiated
> spontaneously
> (on first use by the application code) but in precisely controled
> conditions.
> It is instantiated in Turbine.init() method which is internally
> synchronized,
> then it is bootstraped with essential services, then real
> configuration
> is
> loaded and finally all services are initialzed (in so called
> early init
> phase).
>
> I think that it would be justifable to lift the double locking pattern
> from
> the BaseServiceBroker class in the following way:
>
> public class BaseServiceBroker
> extends BaseInitableBroker
> implements ServiceBroker
> {
> protected static ServiceBroker instance = null;
>
> public static ServiceBroker getInstance()
> {
> return instance;
> }
>
> protected static ServiceBroker newInstance()
> {
> return (ServiceBroker)BaseServiceBroker();
> }
>
> /**
> * This method creates new ServiceBroker instance for the system.
> *
> * If there is an instance of ServiceBroker running, it will be
> * shut down.
> *
> * @param data The implementation dependent data used to create
> * the essential services.
> */
> public static synchronized ServiceBroker bootstrap(Object data)
> {
> if(instance != null)
> {
> instance.shutdown();
> }
> instance = newInstance();
> instance.initPrimaryServices(data);
> return instance;
> }
>
> public void abstract initPrimaryServices(Object data);
>
> //...
> }
>
> Implementations would have to override newInstance() and
> initPrimaryServices(Object)
> methods. Does this solution adress your concenrs Ilkka?
>
> Rafal
>
> PS. Thank you for the information concerning JMX. What paricular
> services in Turine
> did you chose to instrument as MBeans? I'm also interested in what
> adapters/connectors
> are you using, and if threre are any JMX enabled management
> applications
> available,
> other than Sun's RI?
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:[EMAIL PROTECTED]
> +48 22 8534830 http://e-point.pl
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
