On 8/30/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > We now have a number of domain implementations in Tuscany Java SCA > including > > - The SCADomain interface > - DefaultSCADomain > - EmbeddedSCADomain > - HotUpdatableSCADomain > - DistributedDomain/Node > > Covering a number of scenarios > > - running a domain in a single node > - running a domain across multiple nodes > - Adding, removing, updating the contributions of a domain through the API > and automatically > - Activating/deactivating, starting/stopping deployable composites through > the API > - Starting, stopping components through the API > - Locating service in the domain through the API > etc. > > There are some scenarios that we don't cover at the moment > > - running multiple domains in a VM > What else? > > I would like to propose that we rationalize these various implementations > down to a more manageable number. I have a simple model in my mind of the > building blocks we have to deal with. > > 1/ The node. > Is responsible for running segregated domains in a VM > Associated with zero or more domains. > 2/ The domain. > Logically knows about all of the artifacts of a domain. > Associated with one or more (in the distributed case) nodes. > A local representation of the domain (the SCADomain object) provides > the > interface to wider domain > > There are some subtleties here about the timing of associating a domain > with > a node(s) but the simple case, which we implement at the moment, > is if you start a domain, start a node, associate the two together and > then > add contributions. The contributed components run on the node with which > the local domain object is associated (more complex node/component > selection > algorithms can be imagined but we don't do this at present). > > Here are some suggestions based on the interfaces from the list of > existing > domain classes above, of the kind of things we need to be able to do; > > Domain > Create/destroy the domain based on its URI > Act of creating a domain object with a globally unique URI means that > it > becomes part of that domain and can scope comonent invocations in > the context of that domain. > There should be a default hot update location if we want to maintain > that feature. > Contribution management > Add/remove contributions > Resulting composites/components sit ready to be started > Composite Management > Start/stop composite > Akin to adding a composite to the domain composite and activating it > Not sure how we identify a composite to be activated - by composite > name? Currently it's done with a reference to the composite object > Do we need to expose separate activation operations? > Component Management > Start/stop component > Add.Remove listener > Not sure how the listener from the current interface is going to be > used > getComponentInfo > There are some existng related component management interfaces here > also > LocateService > public abstract <B, R extends CallableReference<B>> R cast(B target) > public abstract <B> B getService(Class<B> businessInterface, String > serviceName); > service name -> component name / service name > public abstract <B> ServiceReference<B> getServiceReference(Class<B> > businessInterface, String referenceName); > > We also need the domain to provide some systematic interfaces to support > distributed operation, for example, > > ServiceDiscovery > register/find service endpoint > > Node > Create/destroy the node based on its URI > Add/remove an association with a domain > start/stop a nodes activity > > Currently we have an approach, with the EmbeddedSCADomain, where the class > vends a series of management interfaces, contribution, model building etc. > for performing actions on the domain. This is useful as it allows > flexibility in how these management actions are implemented without > changing > all > of the domain implementation. It would also be appropriate, in the future, > to expose some of these interfaces as services to allow for remote > management of the > domain at a node. > > Would welcome thoughts about this generally. Also specifically do we need > to > maintain the detailed interfaces provided with EmbeddedSCADomain alongside > this.
Just to add to this that the Geronimo integration [1] also does very similar stuff to the HotUpdatableSCADomain (which is used by the webapp distro), and that neither of those work properly anymore, see TUSCANY-1555. Actually i'm not sure that the EmbeddedSCADomain works properly now either as it seems to have fallen behind a bit of some of the changes. Would be great to sort this out and have more of a proper SPI to bootstrap a runtime, and i'd help it even if nothing else by getting the webapp distro to work with it to help validate the interfaces work. ...ant [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/geronimo-tuscany/src/main/java/org/apache/geronimo/tuscany/EmbeddedRuntimeGBean.java
