>> void addContribution(URL url); >> void removeContribution(URL url);
For the contribution management side, how contributions URI are handled ? The spec says that contributions are identified by URI, is a internal URI created and maintained internaly based on the URL ? Or we should add that to the calls ? void addContribution(URI uri, URL location); void removeContribution(URI uri); Also, what should I expect when I add a contribution ? will it be ready to be used ? or do I need to build/start each deployable and component as we do today using EmbeddedSCADomain ? On 9/27/07, Simon Laws <[EMAIL PROTECTED]> wrote: > On 9/27/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > > > Same thoughts translated into interface speak.... > > public abstract class SCADomainFactory > public static SCADomainFactory newInstance() > -$1 public abstract SCADomain createSCADomain(String domainURI); > public abstract SCADomain getSCADomain(String domainURI); > > +$1 public class SCADomainImplFactoryImpl implements SCADomainFactory > +$1 public class SCADomainProxyFactoryImpl implements SCADomainFactory > > public interface SCADomain > public void start(); > public void stop(); > public String getURI(); > $4 void addContribution(URL url); > void removeContribution(URL url); > void addComposite(QName qname); > void removeComposite(QName qname); > void startComposite(QName qname); > void stopComposite(QName qname); > +$2 void startComponent(Qname qname); > +$2 void stopComponent(Qname qname); > public <B, R extends CallableReference<B>> R cast(B target) throws > IllegalArgumentException; > public <B> B getService(Class<B> businessInterface, String serviceName); > public <B> ServiceReference<B> getServiceReference(Class<B> > businessInterface, String referenceName); > > > public abstract class SCANodeFactory > public static SCANodeFactory newInstance() > $5 public abstract SCANode createSCANode(String nodeURI, String domainURI) > > public interface SCANode > public void start(); > $6 public void stop(); > $3 public void configure(QName composite, URL... contributions); > public String getURI(); > $7 public SCADomain getSCADomain(); > void startComposite(); > void stopComposite(); > +$2 void startComponent(Qname qname); > +$2 void stopComponent(Qname qname); > > > Specific but rather random comments. > > $1 Not sure about createDomain. It adds potential confusion. People will > have > to decide when to create and when to get a domain. In out model of > having a central representation of the domain > it works quite well in that in one place you "create" and everywhere > else you "get" but doesn't work so well > in other models, e.g if there is no central manager and that each > domain object holds references to all other domain > objects and nodes. Do you "create" or do you "get". How about we take > this out and assume there is a different SCADomainFactory > impl instantiated (via newInstance) in the case where we want to do the > creation step? > > $2 The fundamental operation is starting/stopping components. > Starting/stopping composites is a useful shortcut > > > $3 The same effect be achieved with the familiar pattern > void addContribution(URL url); > void addComposite(QName qname); > void startComposite(QName qname); > I see that this is a useful device in our desire to differentiate the > operation of a node from that of a domain. > I actually don't mind them having very similar interfaces. The > difference in my mind is one of scope. Dealing with a node > you are just deling with that > one runtime (a common pattern we use in out samples/tests). Dealing > with a domain you don't care where the contributed > artifacts run. > > $4 We haven't explored and magic domain to node allocation algorithms to > date. How about we start with picking he next > node that doesn't yet have a contribution. If you run out of nodes its > bad luck, i.e. implies no magic node provisioning so if you want more nodes > you have to start them manually. > > $5 Can you pass null in here (or some special constant if you want an > association with a domain > that will only every have this one node in it? This is a special case as > there are potentially several economies that can be made in terms of > starting or > trying to connect to domain services. > > $6 Has the effect of removing all configuration. > > $7 Wondering if this should return the domain URL so that you get the > domain object manually. Possibly a neater solution to $5 in that a different > domain > factory (and domain implementation) can be introduced in the case that you > know an application is only going to have domain with a single node > > 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]
