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 Mon, 30 Jul 2007 14:56:36 GMT
The stuff in sandbox covers points 1 and 2 below to some extent.  Apart from
this, we have a GeronimoServletHost implementation so that Geronimo's tomcat
server is used when a service is exposed as webservice.  We have got the
calculator, simple-bigbank and helloworld-ws-service samples  from tuscany
samples working in Geronimo.  More details inline.


On 7/27/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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).

We have an EmbeddedSCADomainGBean that wraps an EmbeddedSCADomain tuscany
class.  We have a TuscanyBuilder to deploy standalone tuscany jars into
Geronimo.  Both these GBeans are part of a configuration that runs as a
"tuscany-plugin" for Geronimo.


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)


The TuscanyBuilder GBean, as part of deploying a tuscany jar, creates a
configuration and adds an "EmbeddedRuntimeGBean" to the configuration and
copies the jar to repository.  When the configuration is started, the
EmbeddedRuntimeGBean computes the contribution from the tuscany jar, adds
the contribution to EmbeddedSCADomain wrapped by the EmbeddedSCADomainGBean
and starts the components.  When the configuration is stopped, it stops the
components and removes the contribution from EmbeddedSCADomain.  Apart from
this the EmbeddedRuntimeGBean is starting all components (components from
other tuscany jars as well) as a work around for some problems we have come
across in EmbeddedSCADomain class.


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



thanks
> david jencks
>
> On Jul 26, 2007, at 5:46 AM, Vamsavardhana Reddy wrote:
>
> > 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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> 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