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 :-)
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
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 <[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
