Raymond is away for one more week, so I'll try to answer some of these
questions.
Manu George wrote:
Hi Raymond/Jay,
I would like to join this effort. I would like to discuss what
is expected of the deep integration. I will just list down my
understanding of both the current and proposed integrations
Understanding of the Current Integration
1) TuscanyContextListener creates an SCA domain when the servlet is
created and then destroys it when the servlet is destroyed.
2) During SCA domain creation it looks up the composites and deploys
them in the domain
Creates a webapp module activator for registering servlet hosts.
3) Finally we have a servlet that forwards requests to the servlet
registered with the Tuscany Servlet Host.
4) An SCADomain is created for each application and we can lookup the
services from the SCADomain.
5) During SCADomain creation a runtime is also created for the
DefaultSCADomain.
7) All tuscany classes are loaded repeatedly for each application in
separate classloaders.
8) A runtime is created per application
Correct. I'm assuming that you're talking about the current Webapp
integration.
As a heads up the SCADomain class is probably going to change a bit to
load a subset of components deployed to an actual SCA domain. The idea
is to distribute an SCA domain across runtimes, each runtime running one
or more domain level SCA components (and components nested in their
composites).
Understanding/Doubts about the proposed Integration.
1) Each SCA application will have an SCA module which will be a jar
with an SCDL in META-INF. This jar can also be part of an EAR. . There
will be a Tuscany deployer that will take care of deploying the SCA
modules. Should WAR files be also able to contain SCA jars?
Will the application developer be exposed to this? If it's the case then
it looks like a new programming / packaging model, different from SCA :)
An SCA application developer normally packages application artifacts in
an SCA contribution (a form of archive described in the SCA assembly
spec) and the .composite (SCDL) files are not necessarily under
META-INF. in fact usually we place them with the other development
artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application
developer wouldn't have to learn a different packaging model to run his
SCA components on Geronimo. Will there be a way to deploy an SCA
contribution to Geronimo "natively" without having to repackage it in a
J2EE archive?
2) Each App will have an SCA Domain which will be instantiated when
the application starts. Is this assumption correct or can there be
multiple SCADomains per app?
The objects deployed to an SCA domain and which run on an SCA runtime
are SCA components. There is no concept of an App like a J2EE App in SCA
at the moment.
Components can be implemented by a simple Java class, a BPEL process, a
script, etc. or a Composite. A Composite describes an assembly of
Components, allowing for nested composition of components. An SCA domain
is described by a composite, describing the assembly of top level
components in an administration domain. The SCA domain composite does
not necessarily have to written to a single .composite file since it has
to be distributed, but it is effectively modeled as a composite.
So to go back to your question, objects that run on an SCA runtime are
SCA components, and each component belongs to a single SCA Domain composite.
Now with respect to instances of the SCADomain class, I was thinking
about two options:
(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.
3) The Tuscany classes are loaded only once and then shared between
the different SCA applications.
+1
4) There will be multiple domains instantiated from different
applications and there should be a server wide domain registry where
applications can look up and invoke different composites from domains
different from their own. (Can this be Global JNDI/Gbean refs or is
there something specific in tuscany).
An SCA domain is a domain of administration typically containing
multiple servers. Wiring and lookups are assumed to work within the
context of a single domain. We could imagine a Geronimo server hosting
components from multiple SCA administration domains, but I'm not sure
that it's going to be a very common scenario.
5) There should be only a single Tuscany Runtime for the entire
geronimo instance.
It if helps, sure. If on the other hand it complicates things we can
also have multiple runtime instances. Multiple lightweight runtime
instances may be easier to handle than a single more complicated one.
6) How can we lookup the services running in one geronimo instance
from an app in another geronimo instance. Is this supported in Tuscany
This looks like the distributed domain deployment that we need to
support in Tuscany in general. Two runtimes R1 and R2, running on two
different machines, access the SCA composite model describing an SCA
domain. Runtime R1 runs component CA, runtime R2 runs component CB. CA
has an SCA reference wired to CB.
We are starting to work on this in Tuscany, along the lines of what I've
described above in my answer to your question (2).
Here are some pointers to related discussions on the Tuscany wiki and
the tuscany-dev list:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
http://www.mail-archive.com/[EMAIL PROTECTED]/msg18879.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg19105.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg18954.html
These are just the initial set of points/questions that hit me when I
thought about the integration. Jay /Raymond I guess you guys will be
aware of many other points as well. Can you reply with your analysis
so that we can flesh out the requirements completely in the mailing
list. That way both the communities can contribute their thoughts. If
you have already started can you just point me to where I can catch up
on what has happened?
Thanks
Manu
On 4/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Geronimo community.
As you may know, Tuscany is an Apache project under incubation to
provide an
open source SOA infrastructure. For more information, you can visit
http://cwiki.apache.org/TUSCANY/.
Tuscany implements the SCA specification (http://www.osoa.org) and
allows
you to develop and run SCA components in various hosting
environments. We
currently integrate with Tomcat and Jetty and would like to try to
integrate
with Geronimo as well. I would like to start some discussions here to
figure
out the best way to do that.
After some preliminary investigations of Geronimo, I feel that there
are two
options on the table so far.
1) Shallow integration: Package SCA applications together with the
Tuscany
runtime as WARs and deploy them Geronimo as Web applications. It's
basically
the integration with a Web container. We register a
TuscanyContextListner
(which implements javax.servlet.ServletContextListener) in web.xml to
start/stop the Tuscany runtime when the web application is
started/stopped.
This will allow us to support the following use cases:
* A Web application hosted by Geronimo with business logic written as
SCA
components
* Expose one or more SCA components as Web services over HTTP as
supported
by the Web container.
2) Deep integration: We package the Tuscany runtime and its
dependencies as
Geronimo modules and deploy them to Geronimo (which is similar to how
Tomcat
is integrated as the Web container for Geronimo). We can then create a
Tuscany plugin (a collection of modules) so that it can be added to
Geronimo. The Tuscany container will then handle SCA-specific deployment
plans to install SCA applications and provide runtime infrastructure for
them.
On top of Option 2, we could further integrate Geronimo's J2EE
capabilities
such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components
will be
able to access JEE services (using SCA composite references) and SCA
components will be able to expose services (SCA composite services)
over JEE
protocols as well.
This will allow us to support the following use cases:
* Any J2EE application hosted by Geronimo would be able to take
advantage of
SCA programming model
* Provide SCA services over various protocols such as RMI/IIOP, JMS
and JCA
* Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS
or Web
Services) from SCA components
Any thoughts?
Thanks,
Raymond
Apache Tuscany committer
--
Jean-Sebastien
