Hi Manu, I'm away this week but here are a few more thoughts for now.
On 7/6/07, Manu George <[EMAIL PROTECTED]> wrote:
Hi Simon,
Comments inline.
On 7/5/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi Manu
>
> more comments in line....
>
> On 7/4/07, Manu George <[EMAIL PROTECTED]> wrote:
> >
> > Hi Simon,
> > In one of the previous mails Sebastien proposed two
> > ways of how the SCADomain should exist in geronimo
> >
> > >(a) one instance of SCADomain per component running on the server,
> > >loaded with a subset of the distributed SCA domain composite
> > >representing that component and enough information about its peer
> > >components for it to locate and wire to them.
> >
> > >(b) a single SCADomain object per Geronimo server, loaded with all
the
> > >components running on the server. This will save a little bit of
memory,
> > >at the expense of more synchronization work.
> >
> > >I'd suggest to start with option (a) as it's the model that needs to
be
> > >supported when SCA components run on different physical machines as
> > >well, and I'm actually not sure that we'll get any real performance
gain
> > >with (b) over (a) if we do (a) right.
> >
> > Point (a) looks very similar to the distributed domain concept you
> > explained. First it should be distributed across different
> > apps/classloaders. There will be different instances of SCADomain
> > containing parts of the whole and the different domain instances
> > should constitute a single domain, which is capable of wiring together
> > the components in the different instances they should be able to wire.
>
>
> Yes , that's the intent . It's not clear to me exactly what Sebastien
meant
> when he said "one instance of SCADomain per component running on the
> server", i.e. did he mean SCA component here or is component a Geronimo
term
> in this case. The distributed domain implementation to date allows each
part
> of the distributed domain (node) to run one or more components but it
> doesn't limit you to just one.
>
What I initially thought was that the same distributed domain analogy
can be applied to applications exposed as SCA components. i.e. Each
application will be a composite and since they run in different
classloaders and are isolated, there will be a part of the SCADomain
running in each classloader.in the same JVM
It depends how closely related the applications are. From the assembly spec
"A single SCA domain defines the boundary of visibility for all SCA
mechanisms.". In the case that the applications are intentionally isolated
from one another and sepcifically must not share components or try to create
local wires between components from different applications then I would
expect to see each application in separate domains. Remote wires could of
course be included to cross a domain boundary using explicity
services/reference with remote bindings.
I think Sebastien was suggesting we start with this model where each
deployed application (set of related composites) runs in a separate
(distributed) domain. I put distributed in brackets there as an application
running in a domain in geronimo server A might we part of the same
distributed domain as an application running in geronimo server B.
This looks exactly like the scenario u mentioned but only locally. Is
> > this supported as of now.
>
>
> It's supported now in the svn truck but the transport protocol used
across
> remote parts of the domain is JMS. I'm looking now to add web services
in
> also. What do you mean by locally? Is this about multiple jvms running
> within Geronimo?
>
Geronimo runs on a single JVM. I meant the scenario i mentioned above.
Thats what i thought Sebastien mentioned. Now I think my
understanding maybe wrong. Seeing your mail my understanding has
changed to there being a server wide runtime and there can be multiple
domains in it. Also in case of disrtibuted runtime it can span server
instances.
Yes, I think you are correct. Within a single VM there can be multiple
domains. The notion of a distributed domain spans multiple VMs. In the
distributed domain case the Tuscany runtime is smat enough to create remote
bindings in the right places to ensure that communications across VMs is
handled appropriately.
> > As Raymond says, we do have limited support for the distributed
> > SCADomain
> > > now. The APIs for driving it are not sorted out yet though. What
happens
> > now
> > > is that you provide all contributed resources to each node in the
domain
> > and
> > > then tell each node which component from a contribution it is
> > responsible
> > > and it does the rest creating remote connections where appropriate.
> >
> > > I am
> > > interested to understand how you might use a distributed domain in
the
> > > Geronimo integration exercise, even if you use the single
> > EmbeddedSCADomain
> > > in the first instance, as it could inform the design of the API.
> > >
> > I didn't give much thought to this but at the high level two
> > possibilities.
> >
> > a) If we have a single domain per server. Then that domain can span
> > over multiple Geronimo instances and do wiring between JEE apps
> > exposed as SCA services on both the server instances.
>
>
> Sounds like the right sort of scenario. Certainly the sort that I had
> envisaged.
>
> b) If we have multiple domains in each server, then each of them can
> > span over multiple instances.
>
>
> Yes. The tuscany code in distributed domain guise should be able to
handle
> more than one distributed domain.
>
> c) If in one server itself there are many instances constituting one
> > domain, then there is a possibility that there are multiple instances
> > in another server as well which also will be part of the same domain.
>
>
> Do you mean component instances or geronimo instances here? Assuming
you
> mean Geronimo instances then yes regardless of how Geronino is started,
i.e.
> many instances on one box or main instances across boxes we would expect
a
> domain to be able to span these instances.
>
> d) What to do when we cluster geronimo instances? Will SCADomains be
> > clustered too?
>
>
> Interesting question. To date I have modelled the distributed domain as
a
> set of distributed nodes where each node provides service endpoints for
the
> services it contains. This does not explain how a node is implemented.
It
> could be a JVM running tuscany or it could be a cluster spreading the
load
> out across many JVMs. The thing is that there is the notion of a node
> exposing the endpoints for the part of the distributed domain it runs.
I.e.
> my emphasis has been on how to represent a widely distributed set of
> services in a distributed domain rather than how to represent a
performance
> or HA solution, such as a cluster. Having said this it would be good to
> understand how you would implement a node in a distributed domain as a
> cluster of Geronimo servers so I'm keen to help out on that if I can.
>
I guess we can think of it at a later stage. If the domain is
distributed, it is like a cluster I guess. But my concern was that
when we clone server nodes the SCADomains will also get cloned for
both local and distributed domains and we need to handle that
scenario..
Yes. We can consider the cluser in two ways.
1/ It is hidden behind a single SCA node (one part of the distirbuted
domain). In this case Tuscany SCA is not aware of how the clustering is
achieved and a component is only assigned to one node. Some special plubming
is required in the Tuscany runtime to ensure that component services are
started on all servers in the cluser. The load balanced of the cluster would
then be responsible for spraying work to the running services as is normally
the case with clusters.
2/ The topology that Tuscany is aware of includes all of the clustered
servers. The implication of this is that a component can be assigned to
multiple nodes. In this case Tuscany's SCA binding implementation (the thing
that is delivering messages to component instances has to be cluster aware.
I am not sure how much sense i am making and whatever I am saying is
> > very general. This is all i can think off now. If there is anything
> > else someone can think off pls jump in.
>
>
> As you can tell I'm not a Geronimo expert and It's easy to get lost when
we
> all start talking about servers, instances, nodes, components etc. What
we
> could do with is a set of terms that we agree the meaning of to help our
> conversation along. To date I have been thinking of the distributed
domain
> in this way....
>
> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ----
n
> SCA Component Instance
>
Ok here I am not getting why there are n instances of the SCA
Component? I understand from your previous mails that for the
distributed runtime each node needs all contributed resources to be
provided. So that results in 1 instance of the SCA Component per node.
Doesn't that defeat the purpose of the distributed runtime? Or is it
the initial step, or am i missing something (most likely :)).
I was just saying here that any node in the distributed domain might have 1
or more SCA components assigned to it.
In the Tuscany runtime It is normally the case that a component will give
rise to one or more components instances (Java objects when the component
has a java implementation) as the SCA application runs. The actual number
created depends on how the component is scoped. So the "n" SCA component
instances was just capturing this.
When I said previously that currently each distributed runtime reads all
components I should have added that each node then throws away all but the
ones that are assigned to it to run. As you may have guessed it reads all of
the components in the first instance so that it can work out where all the
components are and create remote bindings as appropriate. If a node finds it
has to run component A but component A is wired to component B that is
running in another node then a remote binding will be creates to connect
component A to component B
In the application scenario where each app is a composite I was
envisaging only a single component instance or more accurate 1 SCA
composite instance per application.
I think its fair to say that there will only be one domain level composite
per application but that that may be made up of a number of other
composites/components.
So a (distributed)SCA domain runs on logical runtime. This runtime doesn't
> really exist in any physical sense and is just the collection of nodes
that
> runt artefacts belonging to the domain. Now where does Geronimo come in?
>
> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
>
> Where server is some physical computer/processor and the Geronimo
instance
> is a JVM containing a running instance of Geronimo. Can you say
something
> about how Geronimo instances would be related to one another?
>
> Would it be the case that there is a one to one relationship between
> Geronimo instance and Node?
>
As per my understanding yes that makes the most sense. I am assuming
that there can be multiple nodes per server/machine just like there
can be multiple geronimo instances in the same machine.
Yes, with the java runtime the node equates to a Jvm. So maybe we can extend
the diagram a little.
Physical Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance 1 ---- 1 Node n
---- n SCA Domain 1 ---- n SCA Component
I've missed a few relationships out here and not represented runtime or
component instance but you get the idea. If we wanted to cluster the
Geronimo instance then we would clone the node. The question that we would
then have to ask is does SCA know about the cloned nodes. I don't know the
answer to that just yet and maybe both approaches are viable. I'll think
more about this while I'm away this week.
> Regards
> > Manu
> >
> >
> > > Regards
> > >
> > > Simon
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
Regards
Manu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
