Hi,

We have made some progress.  See the details in the wiki page  http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration under 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