Some comments in line... On 7/16/07, ant elder <[EMAIL PROTECTED]> wrote:
On 7/2/07, Simon Laws (JIRA) <tuscany-dev@ws.apache.org> wrote: > > > [ > https://issues.apache.org/jira/browse/TUSCANY-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509538 ] > > Simon Laws commented on TUSCANY-1379: > ------------------------------------- > > As part of the distributed runtime there is an implementation of a node > (somewhere where Tuscany applications can run) that contains a NodeSCADomain > instance which is provided to run a composite containing management > components. The node looks for a file called nodename.node which is > actually just a normal composite file. I have only created one management > component to date, ComponentRegistry, but of course it's easy to create new > ones and use all of the facilities to expose them to the outside world. > > The node can also contain 1 or more DistributedSCADomains. These are > pretty similar to the embedded domain with a few small exceptions. Once > change is that the DistributedSCADomain holds a reference to the > NodeSCADomain and in this way various parts of the runtime can get hold of > local references to management components as required. > > One thing that worries me about this is that the .node file is expected to > hold a specific set of management components for the node to work and I > haven't included specific validation to ensure that this is the case yet. I'm not sure I completely understand this (please bare with me, i've not really looked at any of the distributed runtime stuff before). Is the NodeSCADomain a completely separate SCADomain?
Yes. A domain just to hold the management components for a node. I did originally put them in the application domain but created a separate domain for two reasons - The application domain in this case is distributed and I want management components per node. I could have achived this by having management components in the application domain and assigning instances to each node but that seemed a little complicated. - I want one set of management components regardless of how many domains a node is running. There may be management components that have to sit in the application domain but I haven't come across those yet. As you see from the code I haven't really done much at all with the management components so am keen to discuss this with you to make this work generally. And if so is it used just as
a way to enable writing management applications using SCA?
Yes. I want to be able to write management components without having to worry have the will be exposed as services. Or indeed how they will reference other services. Or is the
NodeSCADomain only really necessary for the distributed runtime? - so in the non-distributed case if there's some way for applications to get at some runtime object implementing the management interface could a management application just be a regular composite/contribution deployed into the existing SCADomain?
In the non-distributed case I think the management composite could potentially be deployed into the application domain but If we can reduced the differences between stand alone that would be good IMO. Also the question of handling multiple domains comes up again. How do the components in the .node composites running in
the NodeSCADomain get hold of the runtime things to do management functions
In the code today the node domain is referenced by each application domain. It's the responsibility of the application domain to register any information required by the management components. I.e there is no wiring between management components and application components at the SCDL level. In the start/stop/query scenario we need management component(s) to have access to the list of components for a domain (for a node in the distributed case). At the moment the application domain has a components list that is populated when the domain is activated. It would be relatively straighforward to make this list and/or the application domain itself known to the management components that require it. The problem I have with this approach for using SCA to describe management components is that the SCDL file describing these components is only half the story and some internal configuration is required to tie it all together. This gives the impression that you can change the management composite at will which is not strictly true (at least in the sense of adding or removing components). It does however allow us to rely on SCA for binding support. This is why I went with the ".node" file instead of just using a ".composite" file, i.e. to try and point out that it's different. - is there any samples showing its being used? The only sample at present is calculator-distributed which uses the component registry management component to manage assignment of components to nodes. This management component is accessed by the modified component activator and hence the sample does not really demostrate anything directly relevent to the start/stop/qurey scenario. ...ant
