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
