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/[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.
+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