I had a long discussion with js delphino at oscon today and I'd like to write down some of what we talked about before I forget it all :-)
I haven't looked at the sandbox work so I don't really know how it relates to what we were discussing.

Here's what I would recommend to start integrating tuscany and provide sca "wrappers" around ejbs:

1. write a gbean that wraps and starts the tuscany runtime "server" that registers the components and composites and hooks up the wiring.  Deploy this in a service configuration together with the tuscany jar(s).

2. write a gbean that represents a bunch of pojo components in a jar together with a sca "plan".  The code should be in the previous config.  The gbean has a reference to the tuscany runtime service and knows where the jar is, maybe where the sca plan(s) are etc etc.  When it starts, it tells the sca runtime gbean to activate and start the sca stuff described in the jar (+ plans)

3. write a gbean that exposes ejbs to the tuscany wiring mechanism.  The idea here is that you can add this gbean to a geronimo plan for an ejb module, and when it starts it will call the tuscany runtime gbean with "tuscany wire ends" that hook up to the ejbs in the ejb module.  The tuscany wiring framework can then hook up the appropriate wires to the ejbs.

This more or less handles the "in" end of exposing an ejb as a sca component.

There's also the "out" end of a sca component.  This is relevant to servlets and ejbs that may want to call an sca component.  It seems like the easiest way to model this in javaee is probably to model this end of the sca wire as an injected ejb3 stateless session bean instance.  This may not handle "conversational" scope, but perhaps this can be hidden inside the sca wire.

I think this should let us demonstrate some tuscany/sca functionality pretty quickly without spending a lot of time writing deployers, by letting humans be the deployers (adding the gbeans by hand to geronimo plans).  Later on we may want ModuleBuilderExtensions that can add these gbeans to for instance ejb apps automatically when they recognize sca plans.  Also I think we will need some kind of TuscanyConfigurationBuilder that can deploy an entire contribution at once.  I think getting stuff to run with "manual deployment" first would be a good idea.

Hopefully I will be able to find out how this relates to what is in the sandbox soon :-)

david jencks

On Jul 26, 2007, at 5:46 AM, Vamsavardhana Reddy wrote:


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,

On 7/7/07, Raymond Feng < enjoyjava@gmail.com> wrote:

I created an empty WIKI page @
We should try to capture the key points for the discussions.


----- 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