Matthew Peters wrote:
I am trying to understand how a contribution that contains a mix of
artifacts, including JEE artifacts, should be handled by Tuscany and the
runtime into which it is being deployed.
SCA-enabling of a JEE runtime and the scenarios that this will address
are introduced in a whitepaper at:
http://www.osoa.org/pages/viewpage.action?pageId=3980
Tuscany currently supports what's described in this whitepaper as
"Single Module Assembly": A Web module is used as an SCA contribution
containing component implementations. Components are assembled inside
the Web module using SCA composites. The whitepaper mentions a single
META-INF/web.composite, right now in Tuscany we allow you to name your
composite however you want.
I'd like to tacke the main other scenarios described in the whitepaper
in the next releases, as mentioned in the Tuscany Roadmap discussion at:
http://marc.info/?l=tuscany-user&m=119203494411767&w=2
Some of this work has already started in the context of the Tuscany -
Geronimo plugin at
http://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk.
Here's a scenario just to make it concrete. Imagine I have a contribution
that includes some JEE UI components like some servlets or JSPs, some Java
SCA components, and just to make it tricky an EJB that is also an SCA
component (if that's not possible yet then I am guessing it will be in the
future).
If I understand correctly, this will probably translate to something
like follows (using the terminology from the whitepaper):
<composite>
<component name="MyUI">
<implementation.web module="ui.war"/>
<reference name="myBackendService" target="MyBackend/MyService"/>
</component>
<component name="MyBackend">
<implementation.ejb ejb="backend.jar"/>
</component>
</component>
</composite>
As a first step, I think we could just represent Web modules and EJB
modules as component implementations and not necessary try to boil the
ocean right away with individual EJBs as component implementations,
maybe later...
And suppose, to be specific, that I want to deploy this onto
Websphere Application Server (WAS).
In this scenario I really want to understand things like what should
happen during deployment and runtime, and how Tuscany and WAS should
cooperate during class loading and instantiation and do any dependency
injection.
I can think of two different approaches.
The first is to put Tuscany firmly in charge
[snip]
The other approach is to leave WAS in charge as far as possible.
[snip]
Tuscany is not trying to reinvent a JEE container. It seems that the JEE
container should be running the JEE artifacts and Tuscany would just
inspect the JEE artifacts and derive their SCA ComponentType from it
would find in them.
[snip]
Essentially it seems to me that Tuscany and WAS are both meaty runtimes
that are used to being in charge by themselves, especially WRT class
loading and instantiation. Has anyone thought this all through and can
tell me how it ought to work?
We only started to discuss the JEE integration in the roadmap this
week... so it's a little too early to say how it ought to work :).
I don't think that Tuscany should impose its own classloading and
instantiation mechanism.
I think that Classloading is a function of the hosting environment.
Tuscany needs to use the ClassLoader provided by your particular J2SE /
OSGi / Tomcat / Geronimo / WebSphere / WebLogic / JBoss / Glassfish /
etc hosting environment. If it doesn't, then it's a bug which ought to
be fixed. It looks like there's active discussions on our dev list and
people working on it to help Tuscany play well with OSGi as we speak :).
IMO instantiation of an implementation is a function of the particular
implementation type container:
- An <implementation.java> is instantiated by the Tuscany
implementation-java container, according to the rules in the SCA Java
C&I spec.
- An <implementation.bpel> is instantiated by Apache ODE (the BPEL
engine integrated with Tuscany).
- An <implementation.web> is instantiated by the Web container in which
it is deployed.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
