tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Marino <jmar...@myroma.net>
Subject Re: SCA and mbeans
Date Mon, 09 Jan 2006 15:24:36 GMT
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.


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:jmarino@myroma.net]
> Sent: Tuesday, January 03, 2006 9:51 AM
> To: tuscany-dev@ws.apache.org
> 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:jboynes@apache.org]
>> Sent: Thursday, December 22, 2005 10:25 PM
>> To: tuscany-dev@ws.apache.org
>> 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

View raw message