More comments in line
On 6/20/07, scabooz <[EMAIL PROTECTED]> wrote:
Hi,
I have a few comments embedded below.
Dave
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, June 18, 2007 9:55 PM
Subject: Re: Domains, runtimes, components and cardinality
> Hi,
>
> Please see my comments inline below.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Simon Laws" <[EMAIL PROTECTED]>
> To: "tuscany-dev" <[email protected]>
> Sent: Monday, June 18, 2007 5:25 AM
> Subject: Domains, runtimes, components and cardinality
>
>
>> Following on from recent discussion on the distributed binding (I've
been
>> putting notes here [1])... In a Tuscany SCA runtime what do we expect
the
>> cardinality between the various parts of it to be?
>>
>> A domain notionally runs on a runtime. In the case of a stand-alone
>> Tuscany
>> SCA runtime this will be a single process (C++ exe, Java VM etc.). In
the
>> case of a distributed Tuscany SCA runtime, the runtime is made up of
many
>> distributed nodes that each run parts of the domain.
>>
>> 1/ Can domains share runtimes/nodes?
>>
>> I.e can components from more than one domain be running inside a single
>> Tuscany SCA runtime or is the user expected to start up multiple
runtimes
>> to
>> run multiple domains.
>
> I think a single Tuscany SCA runtime can only join one SCA domain. For a
> single machine (node), we can have multiple runtimes. These runtimes
will
> have to share the resources, for example, using different ports for the
> http protocol. I'm not sure if we need to have the node
> concept between the SCA domain and runtime.
>
The definition of runtime is still not clear to me. It should be possible
to for
a single operating system process (like a JVM) host components running
in different domains. Is this scenario 1 runtime which supports multiple
domains, or is a runtime the process local instantiation of a domain?
In my mind (and using, I believe, Mike Edwards' terminology) the atomic
building block is the node.
1 node = 1 operating system process.
The term runtime has been mentioned as meaning the collection of nodes that,
together, are used by a distributed domain. To me this implies that there is
a relationship between the nodes, i,e, they are managed as one runtime,
brought up and down together etc. I doesn't imply to me that they can only
host one domain. It does imply that a domain is restricted to runinng on the
nodes in a runtime. I.e.
Runtime1
NodeA
NodeB
Runtime1
NodeC
NodeD
A domain can't run on NodeA and NodeC but it could run on NodeA and NodeB
IMO, hosting components from multiple domains involves creating multiple
domain (representatoin, containers, objects, not sure what the term is) in
the runtime node, for example, the main components of the node would be
NodeA
Node Management Features
DomainA
DomainB
NodeB
Node Management Features
DomainA
DomainB
The degenerate case is of course where there is only one domain represented
in a node.
I have to admit that in the code so far I have only allowed for one domain
in a node but this is not a physical restriction just a product of how I
implemented it to date (I was more worried about the lower level plumbing at
the time).
So generally the model I have in my mind is:
domain n ---- 1 runtime 1 ---- n node
n n
|-----------------------------------------|
The degenerate case being
domain 1 ---- 1 runtime 1 ---- n node
1 n
|-----------------------------------------|
Which, with input from this thread, is what I'm starting with. No
implication that this will be a restriction just that we have to start
somewhere :-)
>> 2/ How many nodes can a single component run on?.
>>
>> I.e. is the assignment of a component to multiple nodes, for
performance,
>> reliability etc. reasons, explicitly supported as part of the topology
>> description of a distributed domain. If so then the SCA binding
chooses
>> which node to use. If not then any distribution of workload is
considered
>> to
>> be a job for the node implementation.
>
> We might have different cases here:
> 1) For load-balancing, we can assign a component to multiple runtimes
> 2) For a singleton service, we may have to assign it to a single runtime
> (a backup runtime can be picked for HA).
>
Even further, consider recursive composition. Suppose CompA is
implemented by Composite Cz, which is an assembly of atomic components.
CompA's composite is deployed....the atomic components in Cz are
targetted to different hosting environments (I'm avoiding the use of the
word
runtime) because there isn't a single host that is capable of running all
of
them.
How many runtimes does CompA a run in?
That's a very good question. I can say that the atomic components in Cz
would, using the terminology from above, run in a single runtime but in
different nodes in that runtime.
CompA would run in the same runtime but its implementation is spread across
multiply nodes. I.e it is not associated with any particular node.
I actually hadn't considered CompA to be part of the assignement of
components to nodes process but it's an interesting question so let me think
aloud for a minute.
If I deploy a composite (Cy) which has a component (CompA) which in turn is
implemented by another composite (Cz) with atomic components in it (CompB,
CompC) then component (CompA) can't run until the composite implementation
(Cz) is also deployed.
If CompB and CompC have specific runtime requirements and I have to
described their specific association with nodes (because of the capabilities
of these nodes and the requirements of the components) then having some
notion of assigning CompA doesn't seem to make sense. Unless,
1/ I want to control the number of nodes to which the atomic components are
assigned as a group, i.e. at the CompA level
2/ I want to restrict the the set of nodes that CompB and CompC may be
assigned to to be a subset of the nodes in the runtime.
3/ ?
Sounds a bit complicated to me.
Now currently I just have a service of which, for each node, I ask the
question "does a component run on this node". It is just hardcoded at the
moment to provided the right answers but of course any level of function
could be implemented behind this interface including node matching
algorithms. The runtime uses this service to work out where to put the
runtime artifacts.
I have to admit that I've not tried a scenario with a composite
implementation but the answer at the moment is that CompA doesn't run on any
particular node because the real assignment question is asked of CompB and
CompC.
Sorry that's a bit of a ramble but interesting question.
Start simple, just don't want you to lose the big picture.
>>
>> I'd be interested to hear peoples views on this
>>
>> My starting point is...
>>
>> 1/ No, we will support multiple domains by starting multiple runtimes.
We
>> could add the extra function to support sharing of runtimes between
>> domains
>> in the future if it's found to be required.
>>
>> 2/ We shouldn't restrict whatever structure we use to describe the
>> component/node association to be 1-1. But we can assume 1 in the first
>> instance and consider adding more complex node selection features to
the
>> SCA
>> binding in the future.
>>
>> Regards
>>
>> Simon
>>
>> [1]
http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
