Hi Jean-Sebastien,
I have put the 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?
We had tried it out with Trunk. M6 will not work as we fixed a JIRA
with geronimo to get this to work. I think the JIRA is not in M6. The
JIRA is GERONIMO-3242. Not sure abt Little G but don't see any reason
it shouldn't work.
>
> 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?
What we were thinking was to expose datasources to application code.
An application developer will have to use InitialContext.lookup to
access the datasource. We were thinking of a JEE style of programming.
If the component implementation is Java inside the implementation he
can lookup datasources and use them thereby leveraging the connection
pooling infrastructure of Geronimo.
I am not familiar with the Tuscany DAS extension but I guess we can
get it to use the Geronimo Datasource. The basic idea was to leverage
the connection pooling functionality of Geronimo for sca services that
use data from databases. But from what i see an SCA component
developer will be using the Tuscany DAS extension and so it will be of
more value if that can utilize the server connection pooling. Please
correct me if I am wrong. I am yet to read up the DAS stuff.
>
> 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?
I believe we can start with a plugin approach but if we run into some
problems with implementation as a plugin then probably we can think of
full fledged integration.
Can someone from the Geronimo community with expertise here, please
give their opinions on this.
> 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:
Ok the below scenarios clear up a lot of questions. And first as you
have mentioned we can start with (a) and (c)
(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.
I think we can get this working first. Probably if there is no
deployment descriptors I can give the JAR to the tuscany runtime and
let it decide whether it is a valid tuscany contribution. The only
issue is without (c) there is no way we can use the services in JEE
artifacts.
(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.
AFAIK this may require some extensions to tuscany as well to support
implementation.web. Probably referenced service proxies should be
available in the application context.
(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...
Yes this is a grey area. Even the whitepapers don't talk much abt it.
So better leave it for last :)
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
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/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.
+1
Thoughts?
> Your comments and suggestions will be very helpful in taking it further.
>
> Thanks and best regards,
> Vamsi
>
--
Jean-Sebastien
Thanks Jean-Sebastien. Anyone please feel free to comment on these so
we can have a healthy discussion.
Regards
Manu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
