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
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.
> > 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..
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 :)).
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.
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.
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]
