We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for
now)
1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node)
public static SCADomain newInstance()
public static SCADomain newInstance(String composite)
*A* public static SCADomain newInstance(String domainURI, String
contributionLocation, String... composites)
*A* public static void removeInstance(SCADomain domainInstance)
*A* public static SCADomain connect(String domainURI)
public void close()
public abstract String getURI()
public abstract <B, R extends CallableReference<B>> R cast(B target)
public abstract <B> B getService(Class<B> businessInterface, String
serviceName)
public abstract <B> ServiceReference<B> getServiceReference(Class<B>
businessInterface, String referenceName)
private static String getServiceName(ClassLoader classLoader, String
name)
static SCADomain createNewInstance(String domainURI, String
contributionLocation, String... composites)
*B* public ComponentManager getComponentManager()
2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes)
public static SCADomain newInstance()
public static SCADomain newInstance(String composite)
*A* public static SCADomain newInstance(String domainURI, String
nodeURI, String contributionLocation, String... composites)
public abstract void close()
public abstract String getURI()
public abstract <B, R extends CallableReference<B>> R cast(B target)
public abstract <B> B getService(Class<B> businessInterface, String
serviceName)
public abstract <B> ServiceReference<B> getServiceReference(Class<B>
businessInterface, String referenceName);
private static String getServiceName(ClassLoader classLoader, String
name)
static SCADomain createNewInstance(String domainURI, String nodeURI,
String contributionLocation, String... composites)
I propose we move to having one. I've marked the parts that differ with *?*.
There are two main points.
*A* The mechanism by which this local domain representation (the node) is
associated with a wider logical domain
*B* The mechanism by which the domain is managed (the components in the
domains single node in the case of 1 above)
Before we start re-positioning interfaces though we need to agree what we
mean by the words we use here as there has been some confusion. We've
discussed these issues before [1][2][3] etc. The result was a separation of
node and domain so that you could operate on a node and on a domain. This
approach/API is currently hidden behind SCADomain as there was no consensus
that this was the right approach. e.g. I've heard people saying things like
"a node shouldn't provide an interface for adding contributions as you add
contributions to a domain".
I want to push on the issue of how we expect users to deal with a domain and
the nodes in that domain before going back to look at the API. My starter
for 10 is...
- There are different types of users we must consider. Here are two
examples,
1/ the developer who uses the Tuscany APIs to build a node implementation
and makes contributions and manages components programmatically (see our
samples for an example of this approach)
2/ the user who manages one or more nodes as a domain, making
contributions and managing components through a GUI.
- Programmatically, to developer 1/, a node API provides sca runtime
support and has to implement all of the management interfaces for accepting
contributions, managing components etc, so that developer 1/ can wire
tuscany into whatever mechanism they have in their implementation and so
that, once the node is added to a domain, the domain can configure and
manage the node. The implication here is that the node is configured and
managed through contribution/component management interfaces that is a
superset of that of a domain (a superset as I would expect use of other
detailed Tuscany APIs to get the node to work)
- Programmatically, to developer 1/, there should also be a domain
representation so that they can include their node in a domain and perform
domain level operations like locating a service (or even adding
contributions, management components at a domain level). Developer 1/ would
associate their node implementation with a domain (within a single VM this
would be as easy as passing the node object into the domain interface).
- To the user of type 2/ all of these operations may be performed through a
GUI using some slick drag and drop management interface. However, they are
the same operations. We don't have a slick GUI interface currently so
contributions find their way directly to nodes because they are made
programmatically in the node in question. The implication though is that if
we do things at the domain level under the covers the real processing is
delegated to the nodes in the domain.
So opinions please on how you see domains and nodes working.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg23008.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18920.html
[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22589.html
