On 9/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Comments at the bottom > > > Simon Laws wrote: > > On 9/4/07, Simon Laws <[EMAIL PROTECTED] > wrote: > > > >> > >> On 8/31/07, Simon Laws < [EMAIL PROTECTED]> wrote: > >> > >>> > >>> On 8/31/07, Raymond Feng < [EMAIL PROTECTED]> wrote: > >>> > >>>> In the same JVM, we now use a singleton object to keep all the > >>>> metadata for > >>>> the deployable composites running on the node. This has been proven > to > >>>> be > >>>> problematic, especially in the case of Tomcat or Geronimo integration > >>>> where > >>>> applications are running in isolated address spaces. The partition is > >>>> the > >>>> portion of SCA domain visible to a given address space and its > >>>> lifecycle is > >>>> the same as an Web/JEE application (or some other modules). > >>>> > >>>> Then we have the following hierarchy: > >>>> > >>>> SCA domain (accross multiple nodes on the network) > >>>> --- SCA node (I assume one node per JVM and one JVM per node) > >>>> --- SCA partition (I assume one partition per address space > in > >>>> the > >>>> JVM) > >>>> > >>>> Thanks, > >>>> Raymond > >>>> > >>>> ----- Original Message ----- > >>>> From: "Simon Laws" < [EMAIL PROTECTED]> > >>>> To: < [email protected]> > >>>> Sent: Friday, August 31, 2007 9:46 AM > >>>> Subject: Re: Rationalizing SCA Domain implementations > >>>> > >>>> > >>>> > >>>>> On 8/31/07, Raymond Feng < [EMAIL PROTECTED] > wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Comments inline. > >>>>>> > >>>>>> Thanks, > >>>>>> Raymond > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> From: "Simon Laws" < [EMAIL PROTECTED]> > >>>>>> To: "tuscany-dev" < [email protected]> > >>>>>> Sent: Thursday, August 30, 2007 9:13 AM > >>>>>> Subject: Rationalizing SCA Domain implementations > >>>>>> > >>>>>> > >>>>>> > >>>>>>> We now have a number of domain implementations in Tuscany Java > >>>>>>> > >>>> SCA > >>>> > >>>>>>> including > >>>>>>> > >>>>>>> - The SCADomain interface > >>>>>>> - DefaultSCADomain > >>>>>>> - EmbeddedSCADomain > >>>>>>> - HotUpdatableSCADomain > >>>>>>> - DistributedDomain/Node > >>>>>>> > >>>>>>> Covering a number of scenarios > >>>>>>> > >>>>>>> - running a domain in a single node > >>>>>>> - running a domain across multiple nodes > >>>>>>> - Adding, removing, updating the contributions of a domain > >>>>>>> > >>>> through the > >>>> > >>>>>> API > >>>>>> > >>>>>>> and automatically > >>>>>>> - Activating/deactivating, starting/stopping deployable > >>>>>>> > >>>> composites > >>>> > >>>>>> through > >>>>>> > >>>>>>> the API > >>>>>>> - Starting, stopping components through the API > >>>>>>> - Locating service in the domain through the API > >>>>>>> etc. > >>>>>>> > >>>>>>> There are some scenarios that we don't cover at the moment > >>>>>>> > >>>>>>> - running multiple domains in a VM > >>>>>>> > >>>>>> Why does one JVM want to join multiple SCA domains? IMHO, it might > >>>>>> > >>>> be > >>>> > >>>>>> over-engineered. > >>>>>> > >>>>> I think this depends on the answers to you second point. > >>>>> > >>>>> > >>>>>> What else? > >>>>>> > >>>>>>> I would like to propose that we rationalize these various > >>>>>>> > >>>>>> implementations > >>>>>> > >>>>>>> down to a more manageable number. I have a simple model in my > >>>>>>> > >>>> mind of > >>>> > >>>>>> the > >>>>>> > >>>>>>> building blocks we have to deal with. > >>>>>>> > >>>>>>> 1/ The node. > >>>>>>> Is responsible for running segregated domains in a VM > >>>>>>> Associated with zero or more domains. > >>>>>>> > >>>>>> I think we probably miss another layer here, the 'partition's in > >>>>>> > >>>> the same > >>>> > >>>>>> node. In a typical server hosting environment such as Tomcat or > >>>>>> > >>>> Geronimo, > >>>> > >>>>>> applications are isolated by address spaces (such as ClassLoader > >>>>>> > >>>> for java > >>>> > >>>>>> classes). The list of deployable composites coming from the same > >>>>>> > >>>> address > >>>> > >>>>>> space will form a partition. With this layer, we can better embed > >>>>>> > >>>> Tuscany > >>>> > >>>>>> to > >>>>>> the various hosting environment and provide the flexibility for > >>>>>> > >>>> dynamic > >>>> > >>>>>> updates. > >>>>>> > >>>>>> With this in mind, the node will have an aggregate view of all the > >>>>>> partitions within the node. > >>>>>> > >>>>> Can you say some more about what a "partition" is in the context of > >>>>> > >>>> SCA? > >>>> > >>>>> Asking the question in a different way, what is the implication of > >>>>> > >>>> having > >>>> > >>>>> multiple "partitions" in the same domain? Is this like having > >>>>> > >>>> separate > >>>> > >>>>> nodes > >>>>> but with more efficient cross node comms mechaninsm, i.e. within the > >>>>> > >>>> same > >>>> > >>>>> JVM? > >>>>> > >>>>> > >>>>>> 2/ The domain. > >>>>>> > >>>>>>> Logically knows about all of the artifacts of a domain. > >>>>>>> Associated with one or more (in the distributed case) nodes. > >>>>>>> A local representation of the domain (the SCADomain object) > >>>>>>> > >>>> provides > >>>> > >>>>>> the > >>>>>> > >>>>>>> interface to wider domain > >>>>>>> > >>>>>>> There are some subtleties here about the timing of associating a > >>>>>>> > >>>> domain > >>>> > >>>>>>> with > >>>>>>> a node(s) but the simple case, which we implement at the moment, > >>>>>>> is if you start a domain, start a node, associate the two > >>>>>>> > >>>> together and > >>>> > >>>>>>> then > >>>>>>> add contributions. The contributed components run on the node > >>>>>>> > >>>> with > >>>> > >>>>>>> which > >>>>>>> the local domain object is associated (more complex > >>>>>>> > >>>> node/component > >>>> > >>>>>>> selection > >>>>>>> algorithms can be imagined but we don't do this at present). > >>>>>>> > >>>>>>> Here are some suggestions based on the interfaces from the list > >>>>>>> > >>>> of > >>>> > >>>>>>> existing > >>>>>>> domain classes above, of the kind of things we need to be able to > >>>>>>> > >>>> do; > >>>> > >>>>>>> Domain > >>>>>>> Create/destroy the domain based on its URI > >>>>>>> Act of creating a domain object with a globally unique URI > >>>>>>> > >>>> means > >>>> > >>>>>>> that > >>>>>>> it > >>>>>>> becomes part of that domain and can scope comonent invocations in > >>>>>>> > >>>>>>> the context of that domain. > >>>>>>> There should be a default hot update location if we want to > >>>>>>> > >>>> maintain > >>>> > >>>>>>> that feature. > >>>>>>> Contribution management > >>>>>>> Add/remove contributions > >>>>>>> Resulting composites/components sit ready to be started > >>>>>>> Composite Management > >>>>>>> Start/stop composite > >>>>>>> Akin to adding a composite to the domain composite and > >>>>>>> > >>>> activating > >>>> > >>>>>> it > >>>>>> > >>>>>>> Not sure how we identify a composite to be activated - by > >>>>>>> composite > >>>>>>> name? Currently it's done with a reference to the composite > >>>>>>> > >>>> object > >>>> > >>>>>>> Do we need to expose separate activation operations? > >>>>>>> Component Management > >>>>>>> Start/stop component > >>>>>>> Add.Remove listener > >>>>>>> Not sure how the listener from the current interface is > >>>>>>> > >>>> going to > >>>> > >>>>>>> be > >>>>>>> used > >>>>>>> getComponentInfo > >>>>>>> There are some existng related component management interfaces > >>>>>>> > >>>> here > >>>> > >>>>>>> also > >>>>>>> LocateService > >>>>>>> public abstract <B, R extends CallableReference<B>> R cast(B > >>>>>>> > >>>>>> target) > >>>>>> > >>>>>>> public abstract <B> B getService(Class<B> businessInterface, > >>>>>>> String > >>>>>>> serviceName); > >>>>>>> service name -> component name / service name > >>>>>>> public abstract <B> ServiceReference<B> > >>>>>>> > >>>>>> getServiceReference(Class<B> > >>>>>> > >>>>>>> businessInterface, String referenceName); > >>>>>>> > >>>>>>> We also need the domain to provide some systematic interfaces to > >>>>>>> > >>>>>> support > >>>>>> > >>>>>>> distributed operation, for example, > >>>>>>> > >>>>>>> ServiceDiscovery > >>>>>>> register/find service endpoint > >>>>>>> > >>>>>>> Node > >>>>>>> Create/destroy the node based on its URI > >>>>>>> Add/remove an association with a domain > >>>>>>> start/stop a nodes activity > >>>>>>> > >>>>>>> Currently we have an approach, with the EmbeddedSCADomain, where > >>>>>>> > >>>> the > >>>> > >>>>>> class > >>>>>> > >>>>>>> vends a series of management interfaces, contribution, model > >>>>>>> > >>>> building > >>>> > >>>>>> etc. > >>>>>> > >>>>>>> for performing actions on the domain. This is useful as it allows > >>>>>>> flexibility in how these management actions are implemented > >>>>>>> > >>>> without > >>>> > >>>>>>> changing > >>>>>>> all > >>>>>>> of the domain implementation. It would also be appropriate, in > >>>>>>> > >>>> the > >>>> > >>>>>> future, > >>>>>> > >>>>>>> to expose some of these interfaces as services to allow for > >>>>>>> > >>>> remote > >>>> > >>>>>>> management of the > >>>>>>> domain at a node. > >>>>>>> > >>>>>>> Would welcome thoughts about this generally. Also specifically do > >>>>>>> > >>>> we > >>>> > >>>>>> need > >>>>>> > >>>>>>> to > >>>>>>> maintain the detailed interfaces provided with EmbeddedSCADomain > >>>>>>> > >>>>>> alongside > >>>>>> > >>>>>>> this. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Simon > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>> --------------------------------------------------------------------- > >>>> > >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>>> > >>>>>> > >>>>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> Hi Raymond > >>>> > >>> I agree that the singleton is problematic. > >>> > >>> Can you explain what you mean by "address space" in the JVM. Is > it the > >>> namespace isolation afforded to classes by their class loader? > >>> > >>> Why would each "address space" not have a separate node? (of course > this > >>> depends on our definition of node :-) > >>> > >>> Maybe you could say a little about how you expect the classloader > >>> hierarchy to work in Tuscany in this situation. I note that a number > of > >>> APIs take a class loader in Tuscany but I haven't spotted of any > >>> samples/tests that demonstrate when this faility would be used. > >>> > >>> I will take a look at the Geronimo integration code to try and get a > >>> better understanding of this in the morning. > >>> > >>> Simon > >>> > >>> Hi Raymond > >>> > >> I spent yesterday morning running up the Geronimo implementation. I > think > >> I understand what you are saying now. It seems that as jars (containing > >> composites) are deployed to Geronimo then in the current integration > >> approach a new model resolver is created with a separate class loader > and > >> the jar is contributed to the single domain that Geronimo knows about > (as > >> defined by the plan). Will a Geronimo instance only ever know about a > single > >> domain? > >> > >> So I believe what you refer to as the partition is created by virtue of > >> the separate class loader that is use to resolve the resource for each > >> contribution. > >> > >> I'm trying to work this into the interfaces I have in mind but I've > been > >> round the houses a bit as I didn't think about this originally. I'll > post > >> some more thoughts shortly when I can joint the dots up. > >> > >> Simon > >> > >> > > > > >From an implementation point of view I can enforce the restriction that > one > > node only deals with one domain. In the logical world the concept of a > > domain spanning many runtime environments and of a physical compute > engine > > (JVM, process, cluster etc) supporting many domains leads to > > > > Logical Domain n --- n Physical Compute Engine (could be JVM) > > > > from a java implementation point of view, with this restriction, this > > resolves to > > > > Domain 1 --- 1 Node > > > > Where Domain is the object representing a domain running on a node which > is > > able to find out about the other parts of the domain > > and Node provides the runtime resources to this part of the domain. I > still > > contend that any number of Domain/Node pairs can be started within a JVM > > > > Logical Domain 1 ---- n Domain 1 ---- 1 Node n --- n Physical Compute > > Engine (could be JVM) > > > > I think I understand what Raymond means by a partition of a node now. > The > > implication being that, in Java, a contribution is added to a domain > with > > information about not only what node it will run on but also what part > of > > that node. This information is currently a classpath which is used to > > construct a resolver under the covers. Not sure if there is a more > general > > defintion of a partition key. > > > > Domain 1 ---- 1 Node 1 --- n "Partition" > > > > So I have changed the new domain representation as follows > > > > A new domain implementation is based on the SCADomain interface without > the > > static creation methods > > The node model is now internalized inside of this domain object. > > It is effectively the really small runtime but with the addition of > > being able to record contributions against partition keys. > > The node can have a name with is used, as before, when the domain is > > deployed on more than one node. > > As per the first post, the Domain will vend out managers for Components, > > Composites, Contributions > > > > So if you want to create a stand alone domain, i.e a domain that relies > on a > > single node, as we do in many of our samples you can do. > > > > myDomain= new DomainImpl("SomeDomainName"); > > myDomain.start(); > > myDomain.getContributionManager > > ("SomeContributionUrl").startContribution(); > > > > If you want to add a contribution into a partition you would do > > > > myDomain.getContributionManager("SomeContributionUrl", > > classLoader).startContribution(); > > > > In the previous case no node name was give so a default node is created > for > > you but it can't talk to anything else. If you want the domain to be > part of > > a collection of nodes you give the domain representation a node name > > > > // Create the first domain node > > domainNodeA = new DomainImpl("SomeDomainName", "nodeA"); > > domainNodeA.start(); > > domainNodeA.getContributionManager > ("nodeA/").startContribution(); > > > > // Create the second domain node > > domainNodeB = new DomainImpl("SomeDomainName", "nodeB"); > > domainNodeB.start (); > > domainNodeB.getContributionManager > ("nodeB/").startContribution(); > > > > > > The managers allow us to control the various aspects of the domain, > > e.gcontributions, composites, components (I'm effectively using the > > existing > > component manager for the last bit). It gives us something to hang the > hot > > updateable behaviour from also but I haven't added that bit in yet. > > > > I have code for this but it doesn't work quite yet. So any comments > welcome. > > > > > > Simon > > > > [1] > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22665.html > > > > > > Some thoughts: > > An SCA domain is a domain of administration. I imagine an administrator > administering an SCA domain.
A domain includes multiple nodes. A node runs software. Let's make a node small enough to not have to be shared by two > administrators, small enough to keep it simple :) > > The administrator creates/deletes nodes, installs contributions on a > node, allocates composites to a node, starts/stops/monitors a node. The > administrator gets a list of nodes in the domain and browses their > configuration. > > Disclaimer: I understand that people will want to "install a > contribution on a domain and have the domain automatically find a node > or create one if necessary and download the contribution to the node and > start the node and monitor it and page me in the middle of the night if > the node is about the fail and no other node was found to take over, and > much more...". I believe that we can do all that later, once the basic > admin task building blocks I tried to list here are working. > > A domain is going to be implemented as a set of Java objects, a node as > another set of Java objects. How about implementing these Java objects > without statics, singletons, threadLocals, or whatever other maps keyed > by classloaders ... then we won't have to worry about the > machine/process/JVM/partition/classloader/thread debate :) > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Hi Jean-Sebastien I agree with all of the above. On the last point there are no static, singletons, threadLocals etc. involved. I have tried very hard to distance myself from the specifics of how one of these things actually maps to processess/hardware as I'm just as interested in the case where it's not Java or where a node have many JVMs to play with (but not yet:-) The classLoader thing is not a big part of it, it's Java specific and would not appear on the service interfaces that would control this. I just wanted to think about it as Raymond brought it up in the context of the Geronimo integration and I wasn't familiar with what they were doing. Hopefully this will be running tomorrow and we can kick the tyres a bit. Simon
