On 9/26/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > 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.xmlto > > > 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] > > Hi Luciano
Yes. I think so. having a contribution manager interface allowing AddContribution RemoveContribution Alongside any constructor convenience methods helps us with this Regards Simon
