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.
Regards
Simon
