Re: SCA and mbeans

Fri, 13 Jan 2006 13:11:04 -0800 


On Jan 11, 2006, at 4:21 PM, Sakala, Adinarayana wrote:


Jim thanks for the feedback.
On your point 1, It makes sense to me that Tuscany will influence the SCA spec around defining management API's. How do you see Tuscany specific API's fit with our proposed common management model design? Do you see any overlap that can be consolidated?
I need to understand your specific use cases better (btw, are they documented somewhere I can access them?). In order for me to do that, it may help lay out some initial thoughts I had of how things may work.
As background, in Tuscany we are attempting to build runtime extensibility on top of the core component and injection infrastructure. We have the notion of a "system" component implementation type (a POJO with special capabilities) which is used to create components that provide some type of infrastructure capability (e.g. transport interaction such as an HTTP engine, transaction manager, etc). These components are contributed to the runtime as a system module. In a runtime instance, there is one "master" system module component that may contain other child system module components (usually grouped by functional area). Entry points are used to expose system services for consumption at the parent module component layer (which could then expose that entry point to its parent and so on). We have a special type of system binding that allows us to wire to those entry points from other modules through external services. This binding tells the runtime to "autowire" an entry point from the system module to the external service based on interface.
So, if I want to contribute a new "Foo" system type component, I could add it to an existing child system module (editing the sca.module file or adding another fragment to the module archive) or create a new child system module. The runtime is bootstrapped this way. For example, the artifacts that implement support for the SCA Java client and implementation model are system components. This should allow us to create an extensibility model that involves just writing and configuring SCA modules/components. Also, since almost everything in Tuscany will be some form of SCA component, we get the simplification of being able to build generic component management infrastructure that can manage user and Tuscany artifacts. For example, if I want to monitor all of my transports and they are configured in a child system module component "transports", I could just point the management client at "system/transports/FooTransport".
For instrumentation, I was thinking that we would do the same thing; instrumentation artifacts would be system implementation type components. I imagine a lot of the instrumentation will involve some type of request interception or ability to query the health of a particular artifact. Since all runtime code (both Tuscany system components and application components) is managed by an implementation of o.a.t.core.context.Context or a subinterface, the instrumentation code could introspect or query them as well as the logical model which contains a representation of the SCDL configuration. They also have a listener interface that I'm not quite happy with but could serve as a basis for receiving notifications once it is generalized and cleaned up. In terms of request interception, we could have the ability for proxies to have handlers introduced that provide some form of instrumentation. Proxy generation is done in two phases. First, we walk the logical model (parsed from SCA SCDL) and created an in-memory graph. that graph then traversed by "builders" which decorate it with proxy factories configured to create the correct proxy/interceptor for a given wire. The builders are themselves "system" components which we could configure to insert instrumentation components in the proxy interceptor chain.
I liked the idea in Celtix of separating management from runtime artifacts and the above approach seems to be consistent with that. I imagine there would be few individual management entities - maybe ones for entry point context, aggregate component context, simple component context and external service context. These entities could also have sub management entities (configured and wired to them through SCA) for dealing with specific implementation types such as BPEL, SCA Java, etc. For instrumentation, we may need to introduce a specific subtype of system binding - "system.instrumentable" - since the current system binding always returns a direct reference and not a proxy.
I imagine this may be the inverse to what you were thinking but perhaps Celtix could create the management pieces as SCA components in the manner described above?
On point 2, we will take a look at the code and comment on it as soon as it becomes available. 


I checked it in a few days ago.
Regarding Celtix and Tuscany integration, i agree with your initial thoughts. Obviously there are lot of details to be nailed out around this which we intend to start looking into very soon. 


Does Celtix support multiple databinding approaches?
Yes, Celtix databinding layer is pluggable, we should certainly be able to leverage that into tuscany as part of the integration. 

regards,
Adi



-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006 10:25 AM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: SCA and mbeans


Hi Carl,

I did a quick read of the Wiki and here are some thoughts to start
off with:

1. As was mentioned, SCA doesn't yet have a specific management API.
Speaking from a spec perspective, that is one of the
important things
we do want to do. While there is the ModuleContext API, that will
probably not give you what is needed and it will likely
change. So, I
would recommend sticking with Tuscany specific APIs for now
(hopefully Tuscany will influence the spec in this respect).

2. On the Tuscany specific APIs, I just committed a number of
changes
into the old repository since the Apache one was not yet up at the
time.  I need to patch the Apache code contribution but will
probably
not be able to do so until Wednesday since I am traveling and
on dial-
up.  When the code goes in, can you have a look at
org.apache.tuscany.context.Context and its subclasses/interfaces,
notably AggregateContext? Contexts in Tuscany manage various runtime
"code units" such as component implementation instances. I was
thinking we would have these wrapped by some management technology
(e.g. JMX). We also maintain a copy of the logical assembly model
derived from SCDL (or some other source). Right now, each
AggregateContext maintains a pointer to one of these models in the
form of a "Module". Hence, it should be possible to view all of the
child of an aggregate context (some of which may be "leaf"
contexts -
SimpleComponentContext - that correspond to SCA components).
Also, it
should be possible to go from the runtime representation (the
contexts) to the logical representation contained in the Module.
Things are in the early stages so it would be good to get
feedback on
what we need to do.

3. In terms of integration with Celtix, I was thinking that Tuscany
would be dropped into the former runtime much as it would be placed
in another host such as an OSGi container.  Again, the
changes I just
committed should help with this although there will be a lot of work
that needs to be done. My initial thoughts are that this integration
would look something like:

     - Write bootstrap logic to get the Tuscany
RuntimeContextImpl up
and running. This involves creating a child system context with
whatever services Celtix provides for Tuscany (e.g. transaction
management, data binding, etc.). There are some Junit tests which
demonstrate this programmatically. One of the steps here would be
defining a deployment structure, artifacts, etc., parsing them, and
bootstraping the Tuscany runtime context with them.

- Creating binding and handler and handler components that are
configured as Tuscany  system components. We (Tuscany) still need to
do quite a bit of work to enable this but the idea is these
components would be aware of the underlying Celtix transport
technologies and would "interface" between it and the Tuscany
runtime. The Tuscany runtime will be "self-configuring" such that
extensions and system components are just a special form of SCA
component implementation contributed to the runtime as a module.

I've oversimplified point 3 and I imagine there will be a bunch of
issues that arise but early feedback will help us a lot. One issue
that may come up right away is with the data binding. Does Celtix
support multiple databinding approaches? Right now, Tuscany is
dependent on SDO, although the long-term goal is to make that
pluggable.

Jim



On Jan 6, 2006, at 8:32 AM, Trieloff, Carl wrote:




Jim,

Could you have a look at this and provide feedback, to help


us work


out
the SCA/Tuscany mgnt thoughts integration.

https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPlan

Carl.



-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 03, 2006 9:51 AM
To: [email protected]
Subject: Re: SCA and mbeans


Our mechanism is mostly a pluggable reader if I understand you
correctly. This is somewhat in a bit of flux at the moment but the
best place to start is the model project. There is an SDO
implementation currently which can be extended to allow for new
component types. I also have a fairly large patch that will need to
be applied once the repo is up which has the start of a POJO-based
mechanism (presumably some type of parser could generate the POJO
graph) and contains some significant refactoring of the code.

We have some documentation in the xdocs directory that is fairly
accurate on how the model is converted into a runtime representation
(builders and runtime configurations). The basic idea is we build an
object graph of the logical model (derived from SCDL) and then walk
it, decorating the graph with factories which can produce runtime
artifacts (contexts which manage component instances).  This way, we
can "precompute" as much as possible at load time and make various
optimizations (e.g. avoiding proxies for references that do not need
them).

As soon as the repo is in place, I will merge my patch. In the
meantime, have a look at the model project and docs. Feel free to
post questions once they come up.

Jim


On Jan 3, 2006, at 6:34 AM, Trieloff, Carl wrote:





Thanks,

One of the things I want to look at is how the dynamics of the
config would
work, as this will be key to the integration of Celtix with
Tuscany. Are
you planning to provide some dynamic mechanism here or plug-able
config reader
for the Model Assembly?

Carl.



-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 22, 2005 10:25 PM
To: [email protected]
Subject: Re: SCA and mbeans


Trieloff, Carl wrote:





How does SCA integrate with JMX/ and deal with dynamic
configuration? Does it define a model
or is it up to the implementer?






To my knowledge this is an area the spec has not yet addressed
although
a common management model would seem to be a good idea (not just
for JMX
but also WS-DM or SNMP). There is an API for the static model
metadata
through the ModuleContext but IMO it still needs some spec work.

In Tuscany we currently have the static model of the


configuration


(in
the model module) and the intent is to instrument the runtime
components
for a more dynamic model (e.g. service throughput). I


don't think we


would create a hard dependency on JMX (e.g. by extending MBean
classes)
but would use a bridge between the runtime and the MBeanServer.

--
Jeremy

Reply via email to