On Dec 29, 2006, at 5:28 AM, Hawkins, Joel wrote:
Hi Meeraj,
Nice summation - thanks!
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,
...
5. TuscanyServer will use JMX for management
I'd really like to make this configurable. I agree that for the java
implementation, JMX will be the easiest to do initially, but that
won't
help the C++ implementation. If we use some of the same machinery for
supporting multiple management mechanisms that the runtimes will use,
then we can leave a path for C++ and Java implementations to
participate
in the same "management fabric".
We need to think about how to support events raised by managed
resources
and relationships between managed resources. The focus in JMX seems to
be on properties and operations (although JMX does support an event
model and a relationship service), but for WSDM, WS-Notification is a
big part of the spec, and the ability to script automatic management
behavior using something like BPEL is an important aspect of the
vision.
I think that's a good goal but I'd also be concerned about footprint
bloat. The TuscanyServer here is really just the agent that allows
remote start/stop of runtimes. I think its important to keep that
minimalist to reduce fragility as it is a critical point in the
operation of the server. From that perspective JMX seems the right
choice to me: we get it as part of the JVM (which in principle should
be stable), our server is written in Java so it meshes well, and it
does support multiple remote protocols so a user could choose a
heavier protocol than RMI if desired.
Moreover, each runtime can choose whether it piggybacks the framework
used by TuscanyServer or not. Components in the runtime don't use
TuscanyServer directly but through the ManagementService abstraction
and the runtime determines which implementation is used. So in a
simple case it can piggyback on JMX, in a larger environment it could
use a different framework such as WSDM.
What are your thoughts on multiple concurrent management mechanisms? I
can imagine a case where operations may want jmx and web-services
based
management access to the same SCA instance, which means events and
relationships would need to propagate between the two implementations.
Can we auto-wire multiple management service implementations?
Multiple, independent management mechanisms should be fairly easily.
There would be two implementations of ManagementService present and a
component would choose which to use through the intent mechanism
(intended (if you pardon the pun) but not yet supported :-) ).
I think cooperating mechanisms would be a much harder problem
particularly with relationships. I don't think we should force
components to deal with that themselves and might be better with a
ManagementService implementation that delegated to other
implementations in some manner.
This leads into another area where I'm a little uncomfortable which
is the relationship between this kind of management and the concept
of SCA Assembly and changes to it.
For example, SCA components have configuration properties that can be
set by the user. It also has a mechanism where values can be derived
from properties of the containing composite through XPath
expressions. I think it would be very useful from a management
perspective to be able to view the actual value of any property on
any component. However, is a user able to change the value of that
property through the management interface? If they are, how does that
impact the value tree in the assembly?
I don't have a good answer for that. The best I have so far is that
we consider changes through management as local and transient whereas
changes through the assembly are global and persistent. However, that
seems to fit better with a large-scale view where application
assembler and server admin are distinct roles rather than a small-
scale view where one person does it all and the differences between
the two types of change would just be confusing.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
