Sebastien Thank you for these thoughts. My comment in line below. I'll post separate, but hopfully consistent, comments on the code you made.
Simon 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? +1 allows us to abtract away the factory implementation 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 think we need to distiguish between these two but I would rather it were done through factory implementation rather than interface operation. I think having two operation causes potential confusion to the user about which to call. They potentially need to know how the domain has been implemented to make this decision. > 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 Do you mean that the problem is figuring out what the location is as we move between these environments. The code that we have in svn currently doesn't take account of these environments explicitly but follows an algorithms of either accepting the absolute location you provide or looking on the classpath for various files (.composite, sca-contribution.xml etc.) to determine where the contribution is. 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 don't think we have magic code at present. [a] we rely on the classpath [b] contributions can't appear inside other contributions so, at a push, we have the option of saying the whole jar must be the contribution. This is how it works no I believe. [c] we rely on the classpath > 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) Why not a contribution containing a composite containing components? The composite will need to artifacts of its containing contribution anyhow > 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 +1 - 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. +0.5 Immutable once it's started? > 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. +1 - 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 Or nodes are crated and added to the domain. Just saying it doesn't have to me some magic remote deployment mechanism. with the composite and contributions, start it etc. But as a user of the > domain, I'm not exposed to nodes at all. +1 > 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. By management I mean Add/remove contribution Add/remove composite Start/stop component Am completely happy to leave getNodeInfo getComponentInfo etc. Until later. > ...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] > >
