You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/08/30 18:13:48 UTC
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
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.
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
Re: Rationalizing SCA Domain implementations
Posted by Simon Laws <si...@googlemail.com>.
On 9/4/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Comments at the bottom
>
>
> Simon Laws wrote:
> > On 9/4/07, Simon Laws <simonslaws@googlemail.com > wrote:
> >
> >>
> >> On 8/31/07, Simon Laws < simonslaws@googlemail.com> wrote:
> >>
> >>>
> >>> On 8/31/07, Raymond Feng < enjoyjava@gmail.com> 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" < simonslaws@googlemail.com>
> >>>> To: < tuscany-dev@ws.apache.org>
> >>>> Sent: Friday, August 31, 2007 9:46 AM
> >>>> Subject: Re: Rationalizing SCA Domain implementations
> >>>>
> >>>>
> >>>>
> >>>>> On 8/31/07, Raymond Feng < enjoyjava@gmail.com > wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Comments inline.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Raymond
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>> From: "Simon Laws" < simonslaws@googlemail.com>
> >>>>>> To: "tuscany-dev" < tuscany-dev@ws.apache.org>
> >>>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Re: Rationalizing SCA Domain implementations
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments at the bottom
Simon Laws wrote:
> On 9/4/07, Simon Laws <simonslaws@googlemail.com > wrote:
>
>>
>> On 8/31/07, Simon Laws < simonslaws@googlemail.com> wrote:
>>
>>>
>>> On 8/31/07, Raymond Feng < enjoyjava@gmail.com> 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" < simonslaws@googlemail.com>
>>>> To: < tuscany-dev@ws.apache.org>
>>>> Sent: Friday, August 31, 2007 9:46 AM
>>>> Subject: Re: Rationalizing SCA Domain implementations
>>>>
>>>>
>>>>
>>>>> On 8/31/07, Raymond Feng < enjoyjava@gmail.com > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Comments inline.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Simon Laws" < simonslaws@googlemail.com>
>>>>>> To: "tuscany-dev" < tuscany-dev@ws.apache.org>
>>>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rationalizing SCA Domain implementations
Posted by Simon Laws <si...@googlemail.com>.
On 9/4/07, Simon Laws <simonslaws@googlemail.com > wrote:
>
>
>
> On 8/31/07, Simon Laws < simonslaws@googlemail.com> wrote:
> >
> >
> >
> > On 8/31/07, Raymond Feng < enjoyjava@gmail.com> 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" < simonslaws@googlemail.com>
> > > To: < tuscany-dev@ws.apache.org>
> > > Sent: Friday, August 31, 2007 9:46 AM
> > > Subject: Re: Rationalizing SCA Domain implementations
> > >
> > >
> > > > On 8/31/07, Raymond Feng < enjoyjava@gmail.com > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> Comments inline.
> > > >>
> > > >> Thanks,
> > > >> Raymond
> > > >>
> > > >> ----- Original Message -----
> > > >> From: "Simon Laws" < simonslaws@googlemail.com>
> > > >> To: "tuscany-dev" < tuscany-dev@ws.apache.org>
> > > >> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > 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
Re: Rationalizing SCA Domain implementations
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/31/07, Raymond Feng <en...@gmail.com> 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" <si...@googlemail.com>
> > To: < tuscany-dev@ws.apache.org>
> > Sent: Friday, August 31, 2007 9:46 AM
> > Subject: Re: Rationalizing SCA Domain implementations
> >
> >
> > > On 8/31/07, Raymond Feng <enjoyjava@gmail.com > wrote:
> > >>
> > >> Hi,
> > >>
> > >> Comments inline.
> > >>
> > >> Thanks,
> > >> Raymond
> > >>
> > >> ----- Original Message -----
> > >> From: "Simon Laws" < simonslaws@googlemail.com>
> > >> To: "tuscany-dev" <tu...@ws.apache.org>
> > >> 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: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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
Re: Rationalizing SCA Domain implementations
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Raymond Feng <en...@gmail.com> 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" <si...@googlemail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, August 31, 2007 9:46 AM
> Subject: Re: Rationalizing SCA Domain implementations
>
>
> > On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> Comments inline.
> >>
> >> Thanks,
> >> Raymond
> >>
> >> ----- Original Message -----
> >> From: "Simon Laws" <si...@googlemail.com>
> >> To: "tuscany-dev" <tu...@ws.apache.org>
> >> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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
Re: Rationalizing SCA Domain implementations
Posted by Raymond Feng <en...@gmail.com>.
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" <si...@googlemail.com>
To: <tu...@ws.apache.org>
Sent: Friday, August 31, 2007 9:46 AM
Subject: Re: Rationalizing SCA Domain implementations
> On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> Comments inline.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Simon Laws" <si...@googlemail.com>
>> To: "tuscany-dev" <tu...@ws.apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rationalizing SCA Domain implementations
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> Comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Simon Laws" <si...@googlemail.com>
> To: "tuscany-dev" <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Rationalizing SCA Domain implementations
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: "tuscany-dev" <tu...@ws.apache.org>
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.
> 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.
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rationalizing SCA Domain implementations
Posted by ant elder <an...@gmail.com>.
On 8/30/07, Simon Laws <si...@googlemail.com> wrote:
>
> 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
> 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.
> 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.
Just to add to this that the Geronimo integration [1] also does very similar
stuff to the HotUpdatableSCADomain (which is used by the webapp distro), and
that neither of those work properly anymore, see TUSCANY-1555. Actually i'm
not sure that the EmbeddedSCADomain works properly now either as it seems to
have fallen behind a bit of some of the changes.
Would be great to sort this out and have more of a proper SPI to bootstrap a
runtime, and i'd help it even if nothing else by getting the webapp distro
to work with it to help validate the interfaces work.
...ant
[1]
https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/geronimo-tuscany/src/main/java/org/apache/geronimo/tuscany/EmbeddedRuntimeGBean.java