ok, from the discussions so far this is how I see it ..
There are two aspects we are discussing here,
1. How the management mechanism is implemented
2. How the management interface is extracted from managed components
On the first aspect this is how I see it,
1. ManagementService in SPI will define the technology-agnostic abstraction
for management
2. All runtimes will have an instance of ManagementService, which ever
implementation they choose, in the system.scdl
3. This instance is auto-wired into any CompositeComponent instance
4. When register is called on CompositeComponent, it calls
ManagementService.registerComponent
5. TuscanyServer will use JMX for management
6. TuscanyServer will have startRuntime and stopRuntime as the management
ops
7. When TuscanyServer is started it will create an MBeanServer and makes it
available through a protocol specific adaptor, RMI for example.
8. When a runtime is started through the management interface, TuscanyServer
will create a which will have a reference to the hosted MBeanServer
9. JMXRuntimeInfo be auto-wired into the newly started runtime's
ManagementService if it is a JMXManagementService
10. JMXManagedService will use the MBeanServer from JMXRuntimeInfo whenever
registerComponent is called in step 5.
On extracting the management information ..
All of the below three would use dynamic MBean in the JMX implementation of
ManagementService.
1. We can't use the reflection one that is available, as
ManagementService.registerComponent takes and spi.model.Component, which is
not the real instance and cannot be reflectively introspected, as far as I
know from my limitted understanding of core.
2. The JMX annotations we discussed earlier may not be a possibility
depending on whether they will get adopted as part of the osoa annotations
or not. We don't want the application services littered with Tuscany
annotations.
3. Extend the current spi model so that Component can bridge between the
instance for setting/getting properties and invoking ops. This is something
that is not available in the core yet. Also, functionally we are not sure
whether we want to expose application service ops for management. For
writable ops, there are also concerns regarding instance scopes, thread
safety etc. That leaves us with read-only props. To support this we can have
getProperty(String name) and getPropertyMetada() on the Component interface.
Since both composite and atomic components support props, i suggest a common
abstraction called AbstractComponent that will implement these methods and
the information reqd for realising these operations may be passed in from
the builder.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Standalone server
Date: Thu, 28 Dec 2006 15:10:56 -0800
Hang on guys, there's a difference between the "Server" part that clients
talk to and the ManagementService that bridges components into the
management space.
The TuscanyServer can start the "agent" for the management client. With
JMX, this would be the MBeanServer that we are using for all the managed
objects. It registers itself with that to provide clients with a means to
start/stop runtimes. It is performing the "host" role for the different
runtimes it spins up.
The system scdl for each runtime can define what implementation of
ManagementService it wants to use - it just defines a system component
that implements that service. A basic implementation could reuse the
MBeanServer from the TuscanyServer (getting it from the RuntimeInfo for
example) - a more complex implementation could do WSDM for example (which
probably prereqs a WS stack).
The important thing is that the containers do not know what management
protocol is being used - hence the need for an abstraction like
ManagementService rather than hooking them to JMX directly.
--
Jeremy
On Dec 28, 2006, at 2:34 PM, Meeraj Kunnumpurath wrote:
Joel,
This is what I am thinking as well, maybe tuscany server is started as
part of a bootstrap runtime that includes the management service and it
is made available to any other runtimes that is spawned there of.
Anyway, to start with I have added some stuff into core and spi
org.apache.tuscany.core.services.management.jmx and
org.apache.tuscany.spi.services.management respectively. Once we decide
on the management annotations, we can add meat into the
AnnotationDrivenDynamicMBean class. Also, we can look at how we can make
the ManagementService implementation available as a system service.
Ta
Meeraj
From: "Hawkins, Joel" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: <[email protected]>
Subject: RE: Standalone server
Date: Thu, 28 Dec 2006 16:27:00 -0500
Meeraj,
>I think it would be fairly straightforward to write a generic JMX
dynamic
>MBean based on introspecting the annotated members (ops, properties
etc),
>quite similar to the reflection one already in the source tree. I
think
one
>key question is would these annotations be specific to tuscany, or
would
>they be pushed into the core SCA spec some time. If they are tuscany
>specific, what are the implications on portability of service classes
>across different SCA implementations?
You'd hope they'd make it into the SCA spec. If not there, then at least
into org.apache.ws.commons. :-)
>Also, regarding what Jeremy mentioned about CompositeComponent having
a
>ManagementService injected in, which in turn is defined as a system
service,
>do we have a 'chicken-and-egg' situation here. Currently, tuscany
server
>exposes the management service for remote management. Management
clients >use this service to start and stop runtimes. All system
services are >associated with a runtime. However, if the management
service is defined as >a system service, we will have to start a runtime
to make the management >service available. However to start a runtime we
need a management >service :)
Oh dear, this does sound grim. So the bootstrap runtime is no more?
Perhaps the system service of the management service running inside the
individual runtimes could be 'spun off' of an already running instance?
Cheers,
Joel
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
