Hi Venkat Some comments in line.
Regards Simon On 9/27/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Simon thanks for starting this and its really useful discussion for me - > it > just about deals with things that I had 'vowed' to clear up in my mind > post > Rel 1.0 ;-) > > +1 for the proposal to prune down to have a single SCADomain > abstraction. I > am more in line with Sebastien's suggestion of .... > > "I don't care about nodes, I go to the domain, contribute > contributions, declare composites, then just ask the domain do start my > composite, however it wants, wherever it wants. To do that the domain > will have to create one or more nodes under the covers, configure them > with the composite and contributions, start it etc. But as a user of the > domain, I'm not exposed to nodes at all." > > I really don't want to have nodes to deal with Composites or > Contributions. > The Node is to be a handle that an SCADomain can use to identify an > instance > of a SCA runtime. +0.5 the node has to be configurable in terms of the components that it runs and this involves providing contribution artifacts also. I'd imagine that or every logical SCADomain there is a > NodeRegistry that runs in a well known location, which an SCADomain can > look > up to find the list of nodes which run SCADomain instances that are a part > of the same logical SCADomain. This is certainly how the implementation works today but it's not the only way of doing it. For example, you could run a peer system where each node has a notion of the domain and has a reference to all other nodes in the domain, i.e. no central manager, and state is replicated amongst all peers. By default, in the absence of any node > specific information all operations are perform on the local SCADomain > instance i.e. the local SCA runtime. Where operations have node specific > info, the NodeRegistry is consulted, the remote SCADomain instance > associated with the given Node is contacted and operations delegated over > to that remote SCADomain instance. Not sure if I understand you here. Let me try and replay... 1/ if you operate on a node them you operate on that node specifically, e.g. to configure it with contributions, composites etc 2/ If you operate on a domain then you operate on the domain and have no knowledge of specific nodes Is that right? These are some intial thoughts that occur... let me take a look at > Sebastien's sandbox and get back.. maybe with better clarity ;-) > > thanks > > - Venkat > > > On 9/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Comments inline. > > > > Simon Laws 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/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 > > >>> > > >>> > > >> +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. > > > > +1 for making SCADomain an interface > > > > +1 for having a factory > > > > So instead of: > > SCADomain domain = SCADomain.newInstance(...) > > > > We'll have: > > SCADomainFactory domainFactory; > > SCADomain domain = domainFactory.createSCADomain(domainURI) > > > > Now how do people would like to the get factory? a pretty common pattern > > is: > > SCADomainFactory domainFactory = SCADomainFactory.newInstance(...) > > > > Is there a better pattern? > > > > Does that answer the question about "why the static and abstract > > methods"? :) > > > > > 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 think we need to distinguish: > > - creating a domain... createDomain(domainURI) > > - getting a handle to an existing domain... getDomain(domainURI) > > > > > 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) > > >> > > > > > > > > > > It's not the first time we bump into this. Having a method take a > > contribution location makes a lot of sense. The problem is figuring that > > location... > > a) in Eclipse or another IDE > > b) with a JAR produced by Maven > > c) with classes under test/classes > > > > With the API you're proposing you're going to have to write the > following: > > URL contributionLocation = <magic code>; > > Whatever whateverFactory = createWhatever(contributionLocation); > > > > Any good idea on how to write the <magic code> that works with [a], [b] > > and [c]? > > > > > 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. > > +1 to separate the two: > > - Domain - you go to a domain to declare contributions and domain > > composites > > - Node - you go to a node to run components (to simplify let's say that > > a node runs a composite containing components) > > > > > 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. > > > > +1 and I'd like to start with the following simplifying assumptions: > > > > - A node belongs to a domain, you specify the domain when you create the > > node, the node does not migrate from one domain to another > > > > - A node does not have complicated lifecycle operations, a node is > > created, configured with a composite and the contributions needed by the > > composite, runs off of that, then dies or gets recycled. In other words > > a node is immutable. > > > > > 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. > > > > > > > Well, I think we have two use cases: > > > > - I want to deal with the node myself, I create a node, configure it > > with a composite and contributions, start it etc. > > > > - I don't care about nodes, I go to the domain, contribute > > contributions, declare composites, then just ask the domain do start my > > composite, however it wants, wherever it wants. To do that the domain > > will have to create one or more nodes under the covers, configure them > > with the composite and contributions, start it etc. But as a user of the > > domain, I'm not exposed to nodes at all. > > > > > 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. > > > > > > > We will need management interfaces, but I think we should know where > > we're going with the basic concepts and experiment with simpler APIs - > > just two interfaces Domain and Node - before adding more APIs. > > > > > ...ant > > > > > > > > > Simon > > > > > > > To help with the discussion, I put my thoughts around domain and node in > > code there: > > > > Samples showing node and domain use cases: > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/ > > > > Strawman node and domain interfaces: > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/org/apache/tuscany/sca/node/ > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/org/apache/tuscany/sca/domain/ > > > > Thoughts? > > > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
