Comments inline.
Vamsavardhana Reddy wrote:
Hi,
Myself and Manu have done some work (a small PoC) on Geronimo Tuscany
integration. As a first step, we have created a plugin for Geronimo
that will let the user to deploy standalone tuscany modules into
Geronimo and use the deployed services by looking up in JNDI. I have
put the code in Geronimo Sandbox at
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/.
Great! I started to look at it, I'll try to get it running but it may
take a few days before I get to it.
Which version of Geronimo should I use? M6 or Trunk? the full J2EE
server or is Little-G sufficient?
Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.
More on this below in my answer to your question (2).
B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo
Will the datasources be used internally by a Data Access component
runtime (like the Tuscany DAS extension) or an ODE/BPEL component
integration runtime (which I think uses a database) for example?
Or are you thinking about exposing the datasources to application code,
and if it's the case, what will an application developer have to write
to use them?
Some of the questions we have are:
1. Should we use this plugin approach and host the plugin separatley
or intergrate Tuscany to be bundled as part of the Geronimo
distribution?
The plugin approach looks OK to me, but maybe somebody from the Geronimo
project could give a more educated opinion?
2. Should we have support for bundling Tuscany composites in WAR,
EJB-JAR and EAR? Or should we provide for adding a separate Tuscany
module in EAR?
This is similar to a question you had in a previous thread, see question
(1) in [1].
I had the following scenarios in mind, with my application developer hat on:
(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.
(b) I'm assembling SCA components, some of them developed using the SCA
programming model (Java components, BPEL components or composite
components for example) and I want to re-use an EJB module in my
assembly, allowing other SCA components to talk to its session beans
using the SCA programming model. That EJB module does not know anything
about SCA, it only uses the EJB programming model.
(c) I want to use a Web app in my SCA assembly and call SCA components
from it. I should be able to declare an SCA component representing my
Web app, wire that component to other SCA components in the assembly,
and then magically the wired references will be available as proxies for
use in my JSPs, allowing me to call an SCA component using a simple
jsp:useBean tag.
(d) I want to bundle SCA components directly inside the Web app. IMO
this scenario raises a number of issues as it introduces a mixed Webapp
/ SCA programming model which is not really specified, limits the
ability of components to expose services through non-Webapp-friendly
bindings (I'm not sure how a component in a Webapp could expose a JMS
service for example), and does not give a clear status to individual
JSPs, I'm not sure if they would be declared as components or not for
example...
To summarize:
(a) is about running SCA components on Geronimo
(b) is about using EJB modules as SCA components, it is described in an
OSOA white paper at [2]
(c) is about providing access to SCA components to Web apps, described
in [2] as well
(d) I'm not sure what this one is about :), "Assembly of Enterprise
applications" in [2] briefly touches on it, maybe others on the list can
help clarify this one.
I would suggest to start with scenarios (a) and (c) which, if I
understand correctly, would not need to bundle SCA composites in J2EE
archives, at least not in a way visible to the application developer.
[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg19312.html
[2] http://www.osoa.org/pages/viewpage.action?pageId=3980
3. Where should we maintain the integration code?
I'd suggest to continue at
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/
for now.
Thoughts?
Your comments and suggestions will be very helpful in taking it further.
Thanks and best regards,
Vamsi
--
Jean-Sebastien
