Joel,

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?

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 :)

Ta
Meeraj


From: "Hawkins, Joel" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: <[email protected]>
Subject: RE: Standalone server
Date: Thu, 28 Dec 2006 14:15:00 -0500

>>How that description is done is really part of the component
>>programming
>>model so I would suggest moving that to the appropriate  container
>>extensions (primarily the java and system containers for  now - it's
>>probably common to both).
>Would the components annotate the ops and properties as part of the
>management interface? Wouldn't that be a bit too intrusive? An
alternative
>would be to use model mbeans and extrenalized descriptors?

Gee, I kinda like the annotation approach, as it shows intent within the
interface declaration. I've started trying to come up with a common
annotation set that will support JMX and WSDM (it's a slow day at
work!). So far as I can tell right now, it looks like properties,
operations, events and relationships will map reasonably well between
the two technologies.

My approach is to create a common set of annotations, which can be
reasonably defaulted between JMX and WSDM (for things like resource
name/id, generated WSDL namespace and port name, etc.), and then create
specialization annotations specifically for WSDM and JMX to override the
default annotation behavior.

So, for instance, a

@ManagedResource(description="a sample management interface")
public class TestResource {

        @ManagedProperty
        private String name;

        @ManagedRelation(type="test_relationship")
        private Object reference;

...

Could be bound to whatever management services are installed. If WSDM is
required, and the implementer wants to override the default WSDM binding
behavior, the default annotations could be specialized for WSDM by
something like

@ManagedResource(description="a sample management interface")
@WSDMResource(wsdl="path to wsdl", ...
public class TestResource {

        @ManagedProperty(description="blah blah")
      @WSDMProperty(namespace="some ns", name="Name",...
        private String name;

        @ManagedRelation(type="test_relationship")
        private Object reference;

...

I'm assuming that for real-world applications, the management-oriented
components would be separate from the components being managed, or the
management aspects of a given components would be reasonably orthogonal
to the application-oriented aspects, such that the end result of all
this annotating wouldn't be too incomprehensible!

Does this seem reasonable? Shall I continue, or would I be better of
surfing /. for the rest of the day?

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]

Reply via email to