Rafal, Thanks for your comment. I'm waiting for LogService...
Here is some background information about JMX.
JMX has evolved from a hardware related need to be able to manage thousands
of different devices using different protocols in a telecommunications
network. JMX solves the problem with Java so well that the same framework
can be used for managing software components as well. The idea is to have a
centralized object registry server, through which clients can ask for
service objects they need. The registry fully hides the implementation of
the objects and even their physical location. The registry provides a kind
of handle, an ObjectName instance, with which to access the properties and
methods of the implementing object. The handle makes it possible to change
the implementation during run-time without disturbing any of the clients.
The objects can be any Java objects either implementing an interface based
on a certain naming rule or providing a dynamic description object about
their exposed functionality. So it's easy to convert existing objects to
managed ones. Sun considers JMX as a pre-implementation of Jini. The idea is
the same, but JMX supports more clearly centralized management in one
machine while Jini is a fully decentralized approach managing services
dynamically around the net.
The JMX framework contains also a web-based management view, based on
reflection, to the registry and all of the registered objects. This view
makes it possible to monitor the run-time status of the system, change the
configuration and even load new objects into the system.
We're using JMX both for its original purpose, for managing devices with
SNMP, and for managing the components of the device management server
itself, like connectors, containers, sessions, processors, socket factories,
thread factories and pools, loggers, Turbine services and modules, etc.
We've applied many design principles from the Apache Avalon project, but
used JMX in implementation as it provides most of the required functionality
readily available. We've added some glue between our system and JMX to be
able to access registered objects also directly in order to achieve fast
performance in request processing. The extension listens to registration
events updating the direct references automatically when needed so that we
don't lose any of the original dynamics of the framework. Combining JMX with
IBM's BML (Bean Markup Language) makes configuration and management of
complicated client/server systems easier than any other approach I know
about.
http://java.sun.com/products/JavaManagement/index.html
http://www.alphaworks.ibm.com/tech/bml
-- Ilkka
--
Nokia Networks
http://www.nokia.com/networks
mail: [EMAIL PROTECTED]
> -----Original Message-----
> From: ext Rafal Krzewski [mailto:[EMAIL PROTECTED]]
> Sent: 23. January 2001 19:33
> To: Turbine
> Subject: Re: JMX integration issues
>
>
> [EMAIL PROTECTED] wrote:
>
> > We have started an attemt to integrate Turbine to our JMX
> (Java Management
> > eXtensions from Sun) based network agent framework. The
> framework includes
> > its own server and doesn't support servlets directly but a
> somewaht lighter
> > concept that we call request processors. It was a
> straightforward task to
> > convert the Turbine servlet into a processor and get the
> system running.
> > However, two static classes caused some problems.
>
> I find this very interesting. Can you point me some resources
> regarding
> JMX?
> (I have a vague idea that this is the backbone of jBoss and Enhydra
> application
> servers, I'd like to find out more)
>
> > 1) It would be useful if the static Log supported
> customizable instances
> > that could redirect log messages to whatever logging system
> is used in the
> > integrating environment.
>
> This is issue will be resolved shortly. I'm going to commit
> LoggingService
> very soon.
>
> > 2) TurbineServices implements nicely the ServiceBroker interface and
> > provides protected constructors. However, the instance
> member is private and
> > the getInstance method returns a reference to the class
> instance, not to the
> > implemented interface, although the getService method of
> the interface is
> > almost the only one needed outside the class. A possibility
> to extend and
> > customize the TurbineServices instance would make it
> possible to support
> > other service construction methods than Class.forName and
> additional broker
> > mechanisms.
>
> Yes, there are quite a few dependences on TurbineServices
> implementation
> througouth
> Turbine code, which is bad. I'm interested in addressing these issues,
> but I'm
> awfuly busy right now.
>
> > Other components of Turbine, like assembler factories, seemed to be
> > extremely well configurable and customizable. The need to
> modify some of the
> > base classes arise from our JMX based object management and
> broker system
> > that we'd like to use for Turbine based objects also. One
> benefit of a
> > separate broker system is a possibility to use different
> instances of the
> > same Turbine module class depending on the context, e.g.
> pages maintaining
> > state of a group of users and supporting several
> simultaneous groups.
>
> Yep, strong componentization is one of design goals of Turbine.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
