geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manu George" <>
Subject Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Date Wed, 04 Jul 2007 21:34:27 GMT
Hi Jacek,
              The spec also says in
The contribution optionally contains a document that declares runnable
composites, exported definitions and imported definitions. The
document is found at the path of META-INF/sca-contribution.xml
relative to the root of the contribution.I think that there are
contradictions here in the spec :(.


On 7/4/07, Manu George <> wrote:
> 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 <> wrote:
> > On 7/3/07, Manu George <> 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
> >
> >
> 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

View raw message