Hi,
There are two layers in play as you guys have already pointed out:
* The SCA runtime that supports the web application as the infrastructure to
deploy and run SCA composite applications
* The SCA contribution that is packaged and deployed as a WAR. The webapp has
been developed using the programming model defined by the JEE/SCA integration
spec
I'm seeing some usage scenarios as follows:
1) I develop a Calculator composite application using SCA. It consists of 4
java components, the Calculator service is configured with an HTTP-based
binding such as binding.ws or binding.jsonrpc. Now I want to deploy it to an
existing web container such as Tomcat so that the Calculator service can be
accessed from web service or jsonrpc protocols. The web container hasn't been
enhanced with SCA. I need some help to produce a WAR to contain the Calculator
and hook up Tuscany runtime to deal with the SCA constructs.
2) I develop a Calculator web application following the JEE/SCA integration
spec. The web application is then deployed to an SCA-enabled web container.
Let's focus on 1) for now. To come up a reasonable scheme, I think the
following questions have to be answered. I list some of the options in mind
under each of them.
1) Who is responsible for bootstrapping the SCA runtime for the webapp?
a) The SCA-enabled web container, such as the Geronimo/Tuscany plugin
b) A Servlet ContextListener or Filter that is configured in the web.xml
c) The web application code (such as JSP or Servlet) calls the Tuscany Node API
2) Where is the Tuscany runtime?
a) Packaged inside the web application
* under "lib" folder, the Tuscany jars will be loaded by the web container
and will be visible to the webapp classpath
* Under a different folder, the Tuscany jars will be loaded by the SCA
runtime through some sort of hooks to the webapp, such as the ContextListener
b) From the Tuscany distribution outside the webapp
c) From the SCA enabled web container
3) Where are the SCA contributions and the deployable composite?
a) The WAR itself is an SCA contribution, and the deployable composite is
either denoted by WEB-INF/web.composite or META-INF/sca-contribution.xml
b) The SCA contributions are packaged inside the WAR
* Under "lib" folder
* Under a different folder
c) The SCA contributions are placed outside the WAR
4) How do we make the SCA Node and/or services available to the application
code?
a) Bind the SCA objects (Node or service proxy) into a registry such as JNDI or
ServletContext attributes
b) Dependency Injection, for example, add @Reference to Java components, EJB or
JSP/Servlet
c) Via external protocols, for example, a non-SCA client calling into a Web
Service or JSONRPC service exposed by SCA components
Thanks,
Raymond
From: Simon Laws
Sent: Monday, January 26, 2009 11:33 AM
To: [email protected] ; [email protected]
Subject: Re: [2.x] Tuscany webapp support
On Mon, Jan 26, 2009 at 1:31 PM, ant elder <[email protected]> wrote:
On Mon, Jan 26, 2009 at 12:59 PM, Simon Laws <[email protected]>
wrote:
On Mon, Jan 26, 2009 at 12:20 PM, ant elder <[email protected]> wrote:
The current Tuscany Webapp support that we have in 1.x is described on
the wiki page at [1], I'd like to start bringing this up in the 2.x code base
so we need to decide what we want to support. Right now i'm focusing on similar
support as we have in 1.x where the webapp is a container for a Tuscany runtime
and not so much on the webapp as an SCA contribution which requires deep
integration into the servlet container (which we're working on separately with
the Tuscany-Geronimo plugin work).
So in 1.x we support three ways of defining the composites included in
the webapp:
- using a META-INF/sca-contributions.xml
- by including deployable composite files within a folder named
META-INF/sca-deployables
- by using an WEB-INF/web.composite application composite
How about dropping those first two and only supporting web.composite in
2.x?
...ant
[1]
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Web+Applications
I'd be happy to let 2 go, i.e META-INF/sca-deployables, as this is a
Tuscany extension. Why would we get rid of support for
META-INF/sca-contributions.xml?
Simon
I'm not sure about META-INF/sca-contributions.xml, was throwing it out there
to see what people thought :)
A META-INF/sca-contributions.xml file is really saying that the webapp .war
file is an SCA contribution that can be contributed to an SCA runtime, but the
way we run the webapps with Tuscany embedded thats not quite how we handle it.
So one thing we could do is just not support it and just support local assembly
within the webapp with the web.composite application composite (section 5.1.1
and 5.1.2 of the WD05 of the JEE spec). That simpler than supporting them both
but there's probably pro's and con's.
...ant
I think we are treating webapp.war as a contribution. Hence
sca-contributions.xml should at least be optional. I could live without it but
it may be more work to turn it off than use it to identfy which composite(s)
should run.
I added a host-webapp-calculator sample that might help to push support for
this. Fell free to use/abuse as you see fit.
Simon
