On 9/26/07, ant elder <[EMAIL PROTECTED] > wrote: > > On 9/26/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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/[email protected]/msg23008.html > > [2] http://www.mail-archive.com/[email protected]/msg18920.html > > [3] http://www.mail-archive.com/[email protected]/msg22589.html > > > > +1 to moving to one SCADomain. > > I've always found the SCADomain impls a bit confusing so i guess now is > the > chance to ask questions - >
Why all the static and abstract methods? Is there a reason SCADomain > couldn't just be an interface with a separate SCADomainFactory for > creating > instances? I don't know. A factory works for me. I think there is a lack of clarity about creating an SCA Domain vs creating an object in a JVM that represent an SCA Domain. IMHO A factory/new instance method doesn't create a new domain just creates a new object that is able to talk to a domain. Others may have different opinions. I've also found the contributionLocation and composites parameters of the > newInstance methods confusing as well. Why do we need the composites > parameter, contributions should use the meta-inf/sca-contribution.xml to > define the deployable composites shouldn't they? And I'm not sure what > is > really valid for contributionLocation as whatever you specify it seems to > go > off and discover all the composites in the path itself anyway. Could the > composites parameter be dropped and the contributionLocation point at any > one of these: > - a single .composite file in which case that will be the only composite > used and it will get deployed > - a single contribution jar with a meta-inf/sca-contribution.xml to say > what > composites get deployed > - a folder containing multiple contribution jars and/or subfolders > containing "un-jar'ed" contributions Me too. Has always confused me. I did some investigation to work out exactly what's going on here (see http://issues.apache.org/jira/browse/TUSCANY-1779). But I'm still suspicious of combining two notions (the location where contributions can be found and the contributions that will be loaded from there) into one method . This would be OK except that passing either a relative or null contribution location still works as the code invents a contribution location. I'd rather have a specific interface for this. So that would be something like: > > SCADomainFactory > SCADomain createSCADomain(contributionLocation) > SCADomain createSCADomain(domainName, contributionLocation) > SCADomain createSCADomain(domainName, nodeName, contributionLocation) I'm picking up on three things going on here in various combinations 1/ Creating an object that gives you an interface to a domain 2/ Associating a node with this domain 3/ Adding contributions to the domain I think we could simplify by reducing to 2 things 1/ Creating an object that gives you an interface to a domain 2/ Adding contributions to the domain SCADomain createSCADomain() I want to create a local domain object but the domain is not distributed outside this JVM so I'm not bothering with a domain name. I'll add some contributions later SCADomain createSCADomain(domainUri, nodeUri) I want to create a local domain object to represent the named domain and add this named node in the domain I'll add some contributions later SCADomain createSCADomain(contributionLocation) just start me a domain object which only knows about a single local node and a single contribution, i.e. the pattern we use in most of our tests SCADomain createSCADomain(domainUri, nodeUri, contributionLocation) I want to create a local domain object to represent the named domain and add the named node in the domain I want to load the contribution from the provided location The resulting SCADomain object represents both the local node and the interface to the domain. It still feels a bit strange to me that it's called SCADomain. I still have this feeling that we should have a domain thing that knows about the domain and a node thing that knows how to run contributions. I.e. you create a domain object and talk to the domain (locate a service etc.) and if you want to provide some runtime resources you create a node and add it to the domain. This of course is currently hidden by the SCADomain interface. This separate domain/node view is inconvenient and looks heavyweight if you want to write a quick sample so maybe having this convenience of single method construction is good but under the covers that is my mental model of what is going on. We also need management interfaces for adding contributions, controlling components etc. We did this before by providing operations that returned management objects, as the current SCADomain interface does, but there were objections to this approach. ...ant > Simon
