Hi Jacek,
Glad that you could join this discussion. Welcome :). We
need more participants like you to join this dicussion to come out
with the best approach. I have added my comments inline on my
understanding on why we should be doing this. This is actually based
on the JEE SCA integration whitepaper at OSOA and Sebastiens comments.
On 7/4/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
On 7/3/07, Manu George <[EMAIL PROTECTED]> wrote:
> (a) I develop SCA components, assemble them in a composite, package them
> in an SCA contribution. I don't really know what a WAR or an EAR is, I'm
> just using the SCA programming model and packaging model. I deploy my
> SCA contribution to Geronimo and run it there.
>
> This will require a tuscany specific deployer that is installed as
> part of the plugin. Ususally deployers have access to a server
> specific deployment plan at some fixed path say
> (META-INF/geronimo-tuscany.xml). If this file is found then the
> deployer will know that the module that was supplied to it is a
> tuscany module. In case I am deploying a tuscany contribution using
> the sca packaging model then there will be a .composite file somewhere
> in the module and the deployer will have to search in the module for
> scdl files. For now the tuscany contributions will always be
> packaged as jars.
I've been reading the SCA Assembly Model 1.0 spec and according to it
(1.10.2 Contributions - page 63):
SCA expects certain characteristics of any packaging:
* A directory resource should exist at the root of the hierarchy named META-INF
* A document should exist directly under the META-INF directory named sca-
contribution.xml which lists the SCA Composites within the
contribution that are runnable.
So it's pretty clear that Geronimo should recognize SCA modules only
when the META-INF/sca-contribution.xml file exists, pass it to Tuscany
Yes you are right. But if you see the Tuscany samples it supports SCA
modules that don't have sca-contribution.xml and just a .composite
file. So I was on two minds here whether to mandate
sca-contribution.xml or not.
and...that leads to my next question below.
I can't understand what the value of such a simple integration
described in (a) would be. What would be the value of deploying
composities with no access to runtime environment other than Tuscany
itself? You can very easily do that with packaging sca modules as part
of war file with Tuscany listener attached.
Jacek
True with the Tuscany listener attached you can consume services in jsps easily
but the current Tuscany listener integration only supports the first scenario.
Another limitation with the listener based approach is that each
application needs its own SCADomain instantiation and there cannot be
cross consumption of application services atleast without considering
them as remote services.
Ultimately we should be able to have selected JEE artifacts exposed in
the SCADomain as composites so that there can be reuse of the
exisiting JEE components in SCA and SCA components should be usable in
JEE.
To enable this the first step would be
(a) enable deployment of tuscany artifacts in geronimo.
(b) Enable usage of tuscany related annotations like @Reference in web
components like servlets filters etc and expose the war as a
composite to the SCADomain so that SCA can do the wiring of these
references to other SCA services. Thus u can have DI of SCA services
in the web components and u can access them in jsps as well.
(c) Enable EJB modules and Enterprise applications to expose their
functionality as SCA services and also consume other SCA Services
deployed in the Tuscany runtimes.
(d) There is no concept of applications in SCA. So there could be
multiple applications that expose their services to one domain and
another set of applications that expose theirs to another domain.
(atleast thats my understanding as of now)
(e) Tuscany services can have different scopes like session etc. We
may need to map these scopes with the scopes of JEE artifacts when
they are exposed.
--
Jacek Laskowski
http://www.JacekLaskowski.pl
So what (a) and (b) are just the initial steps to a deeper integration.
Of course this is just one way of looking at the integration that is
based on the whitepaper. Since there are no specs I think we are in
uncharted waters so there may be better approaches. Please share your
thoughts and comments.
P.S. I am putting the tuscany dev list in cc, so that they can also
participate in this discussion.
Regards
Manu
