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?
On point 2, we will take a look at the code and comment on it as soon as it becomes available. 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 > >> > >> > > > > > >
