Should we also consider how this SCADomain would work in the context of multiple contributions ?
On 9/26/07, Simon Laws <[EMAIL PROTECTED]> wrote: > 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 > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
