geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Date Thu, 26 Jul 2007 12:46:22 GMT
Hi,

We have made some progress.  See the details in the wiki page
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationunder
Current status.  Code is in Geronimo Sandbox.

Thanks and regards,
Vamsi

On 7/7/07, Raymond Feng <enjoyjava@gmail.com> wrote:
>
> Hi,
>
> I created an empty WIKI page @
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration
> .
> We should try to capture the key points for the discussions.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Manu George" <manu.t.george@gmail.com>
> To: <tuscany-dev@ws.apache.org>
> Sent: Friday, July 06, 2007 2:42 PM
> Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
>
>
> > Hi Simon,
> >                    Comments inline.
> >
> > On 7/5/07, Simon Laws <simonslaws@googlemail.com> wrote:
> >> Hi Manu
> >>
> >> more comments in line....
> >>
> >> On 7/4/07, Manu George <manu.t.george@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
> > Regards
> > Manu
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Mime
View raw message