Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi, We have made some progress. See the details in the wiki page http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationunder Current status. Code is in Geronimo Sandbox. Thanks and regards, Vamsi On 7/7/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I created an empty WIKI page @ http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration . We should try to capture the key points for the discussions. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2007 2:42 PM Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists) Hi Simon, Comments inline. On 7/5/07, Simon Laws [EMAIL PROTECTED] wrote: Hi Manu more comments in line On 7/4/07, Manu George [EMAIL PROTECTED] wrote: Hi Simon, In one of the previous mails Sebastien proposed two ways of how the SCADomain should exist in geronimo (a) one instance of SCADomain per component running on the server, loaded with a subset of the distributed SCA domain composite representing that component and enough information about its peer components for it to locate and wire to them. (b) a single SCADomain object per Geronimo server, loaded with all the components running on the server. This will save a little bit of memory, at the expense of more synchronization work. I'd suggest to start with option (a) as it's the model that needs to be supported when SCA components run on different physical machines as well, and I'm actually not sure that we'll get any real performance gain with (b) over (a) if we do (a) right. Point (a) looks very similar to the distributed domain concept you explained. First it should be distributed across different apps/classloaders. There will be different instances of SCADomain containing parts of the whole and the different domain instances should constitute a single domain, which is capable of wiring together the components in the different instances they should be able to wire. Yes , that's the intent . It's not clear to me exactly what Sebastien meant when he said one instance of SCADomain per component running on the server, i.e. did he mean SCA component here or is component a Geronimo term in this case. The distributed domain implementation to date allows each part of the distributed domain (node) to run one or more components but it doesn't limit you to just one. What I initially thought was that the same distributed domain analogy can be applied to applications exposed as SCA components. i.e. Each application will be a composite and since they run in different classloaders and are isolated, there will be a part of the SCADomain running in each classloader.in the same JVM This looks exactly like the scenario u mentioned but only locally. Is this supported as of now. It's supported now in the svn truck but the transport protocol used across remote parts of the domain is JMS. I'm looking now to add web services in also. What do you mean by locally? Is this about multiple jvms running within Geronimo? Geronimo runs on a single JVM. I meant the scenario i mentioned above. Thats what i thought Sebastien mentioned. Now I think my understanding maybe wrong. Seeing your mail my understanding has changed to there being a server wide runtime and there can be multiple domains in it. Also in case of disrtibuted runtime it can span server instances. As Raymond says, we do have limited support for the distributed SCADomain now. The APIs for driving it are not sorted out yet though. What happens now is that you provide all contributed resources to each node in the domain and then tell each node which component from a contribution it is responsible and it does the rest creating remote connections where appropriate. I am interested to understand how you might use a distributed domain in the Geronimo integration exercise, even if you use the single EmbeddedSCADomain in the first instance, as it could inform the design of the API. I didn't give much thought to this but at the high level two possibilities. a) If we have a single domain per server. Then that domain can span over multiple Geronimo instances and do wiring between JEE apps exposed as SCA services on both the server instances. Sounds like the right sort of scenario. Certainly the sort that I had envisaged. b) If we have multiple domains in each server, then each of them can span over multiple instances. Yes. The tuscany code in distributed domain guise should be able to handle more than one distributed domain. c) If in one server itself there are many instances constituting one domain
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
I had a long discussion with js delphino at oscon today and I'd like to write down some of what we talked about before I forget it all :-) I haven't looked at the sandbox work so I don't really know how it relates to what we were discussing. Here's what I would recommend to start integrating tuscany and provide sca wrappers around ejbs: 1. write a gbean that wraps and starts the tuscany runtime server that registers the components and composites and hooks up the wiring. Deploy this in a service configuration together with the tuscany jar(s). 2. write a gbean that represents a bunch of pojo components in a jar together with a sca plan. The code should be in the previous config. The gbean has a reference to the tuscany runtime service and knows where the jar is, maybe where the sca plan(s) are etc etc. When it starts, it tells the sca runtime gbean to activate and start the sca stuff described in the jar (+ plans) 3. write a gbean that exposes ejbs to the tuscany wiring mechanism. The idea here is that you can add this gbean to a geronimo plan for an ejb module, and when it starts it will call the tuscany runtime gbean with tuscany wire ends that hook up to the ejbs in the ejb module. The tuscany wiring framework can then hook up the appropriate wires to the ejbs. This more or less handles the in end of exposing an ejb as a sca component. There's also the out end of a sca component. This is relevant to servlets and ejbs that may want to call an sca component. It seems like the easiest way to model this in javaee is probably to model this end of the sca wire as an injected ejb3 stateless session bean instance. This may not handle conversational scope, but perhaps this can be hidden inside the sca wire. I think this should let us demonstrate some tuscany/sca functionality pretty quickly without spending a lot of time writing deployers, by letting humans be the deployers (adding the gbeans by hand to geronimo plans). Later on we may want ModuleBuilderExtensions that can add these gbeans to for instance ejb apps automatically when they recognize sca plans. Also I think we will need some kind of TuscanyConfigurationBuilder that can deploy an entire contribution at once. I think getting stuff to run with manual deployment first would be a good idea. Hopefully I will be able to find out how this relates to what is in the sandbox soon :-) thanks david jencks On Jul 26, 2007, at 5:46 AM, Vamsavardhana Reddy wrote: Hi, We have made some progress. See the details in the wiki page http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany +Geronimo+Integration under Current status. Code is in Geronimo Sandbox. Thanks and regards, Vamsi On 7/7/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I created an empty WIKI page @ http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany +Geronimo+Integration. We should try to capture the key points for the discussions. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2007 2:42 PM Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists) Hi Simon, Comments inline. On 7/5/07, Simon Laws [EMAIL PROTECTED] wrote: Hi Manu more comments in line On 7/4/07, Manu George [EMAIL PROTECTED] wrote: Hi Simon, In one of the previous mails Sebastien proposed two ways of how the SCADomain should exist in geronimo (a) one instance of SCADomain per component running on the server, loaded with a subset of the distributed SCA domain composite representing that component and enough information about its peer components for it to locate and wire to them. (b) a single SCADomain object per Geronimo server, loaded with all the components running on the server. This will save a little bit of memory, at the expense of more synchronization work. I'd suggest to start with option (a) as it's the model that needs to be supported when SCA components run on different physical machines as well, and I'm actually not sure that we'll get any real performance gain with (b) over (a) if we do (a) right. Point (a) looks very similar to the distributed domain concept you explained. First it should be distributed across different apps/classloaders. There will be different instances of SCADomain containing parts of the whole and the different domain instances should constitute a single domain, which is capable of wiring together the components in the different instances they should be able to wire. Yes , that's the intent . It's not clear to me exactly what Sebastien meant when he said one instance of SCADomain per component running on the server, i.e. did he mean SCA component here or is component a Geronimo term in this case. The distributed domain
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Jacek, Comments inline On 7/5/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 7/4/07, Manu George [EMAIL PROTECTED] wrote: 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. Hi Manu, Let's see what's in the spec - (1.10.2 Contributions page 64): 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 a recommendation only. I guess Tuscany looks for the file and if it's found it makes composities available at runtime. I'd like to find out what's the rules to discover composities in Tuscany are. How does it search for composite file (only in the top-level directory or jar file?). Yes only in top level jar file. In case of directory contributions , in all the nested directories. and i think it doesn't search inside any jar in the directory(not 100% sure here). Just need to check the FolderContributionProcessor class in tuscany for this info. For jar files there is a JarContributionProcessor. 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. That's the idea. Run Tuscany and install Geronimo services as composities that export services or if it's possible map Geronimo services to SCA services directly with no need to wrap'em as composities. (a) enable deployment of tuscany artifacts in geronimo. (b) Enable usage of tuscany related annotations like @Reference in web components likeservlets 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. It looks as a good approach to Tuscany-Geronimo integration. Glad you approve. It will evolve as we progress through the integration I guess. P.S. I am putting the tuscany dev list in cc, so that they can also participate in this discussion. I think it should only go to Tuscany as there's lots of SCA info and eventually send summary reports here once per week or so. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Regards Manu
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Comments in-line... On 7/6/07, Manu George [EMAIL PROTECTED] wrote: Hi Jacek, Comments inline On 7/5/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 7/4/07, Manu George [EMAIL PROTECTED] wrote: 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. Hi Manu, Let's see what's in the spec - (1.10.2 Contributions page 64): 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 a recommendation only. I guess Tuscany looks for the file and if it's found it makes composities available at runtime. I'd like to find out what's the rules to discover composities in Tuscany are. How does it search for composite file (only in the top-level directory or jar file?). Yes only in top level jar file. In case of directory contributions , in all the nested directories. and i think it doesn't search inside any jar in the directory(not 100% sure here). Just need to check the FolderContributionProcessor class in tuscany for this info. For jar files there is a JarContributionProcessor. Tuscany contribution service does not look for contribution metadata files inside other jar files, it only considers META-INF/sca-contribution.xml or META-INF/sca-contribution-generated.xml. As for using these files to identify a Tuscany contribution, note that Tuscany also have implemented support for having a META-INF/sca-deployables directory where the runnable composites would be placed. More info is available in [1]. If none of these are available, Tuscany runtime would throw an exception saying it can't determine contribution deployables. Also, currently web applications are handled by the folder processor, do we need a war package processor ? would this help the integration ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Web+Application+Integration+Story 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. That's the idea. Run Tuscany and install Geronimo services as composities that export services or if it's possible map Geronimo services to SCA services directly with no need to wrap'em as composities. (a) enable deployment of tuscany artifacts in geronimo. (b) Enable usage of tuscany related annotations like @Reference in web components likeservlets 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. It looks as a good approach to Tuscany-Geronimo integration. Glad you approve. It will evolve as we progress through the integration I guess. P.S. I am putting the tuscany dev list in cc, so that they can also participate in this discussion. I think it should only go to Tuscany as there's lots of SCA info and eventually send summary reports here once per week or so. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Regards Manu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
On 7/4/07, Manu George [EMAIL PROTECTED] wrote: 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. Hi Manu, Let's see what's in the spec - (1.10.2 Contributions page 64): 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 a recommendation only. I guess Tuscany looks for the file and if it's found it makes composities available at runtime. I'd like to find out what's the rules to discover composities in Tuscany are. How does it search for composite file (only in the top-level directory or jar file?). 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. That's the idea. Run Tuscany and install Geronimo services as composities that export services or if it's possible map Geronimo services to SCA services directly with no need to wrap'em as composities. (a) enable deployment of tuscany artifacts in geronimo. (b) Enable usage of tuscany related annotations like @Reference in web components likeservlets 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. It looks as a good approach to Tuscany-Geronimo integration. P.S. I am putting the tuscany dev list in cc, so that they can also participate in this discussion. I think it should only go to Tuscany as there's lots of SCA info and eventually send summary reports here once per week or so. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Sorry for jumping on this thread a little late, but I would like to cover your question around data sources and connection pools you had in item B). Comments inline... On 6/29/07, Manu George [EMAIL PROTECTED] wrote: 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. Tuscany DAS has support for data sources. You can use it's configuration side file to specify witch data source to use, and it would do the properly JNDI lookup to it, you can find more details on how to configure data sources in DAS on this post [1]. Note that, when integrated with SCA, there is also the option to configure the data source access trough the composite file. Based on this, I don't think that SCA x Geronimo integration code need to do anything special here. [1] http://lresende.blogspot.com/2006/11/configuring-mysql-datasource-in-tomcat.html 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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
On 7/3/07, Manu George [EMAIL PROTECTED] 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 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 -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
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 [EMAIL PROTECTED] wrote: On 7/3/07, Manu George [EMAIL PROTECTED] 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 likeservlets 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 http://www.JacekLaskowski.pl 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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Raymond, Comments Inline On 7/4/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: dev@geronimo.apache.org Cc: [EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 7:53 AM Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists) Hi , From Paul's mail I guess a Geronimo plugin would be the way forward. I am going to list down a few more questions on the scenarios that Sebastien has explained. The scenarios are given first and then my understanding, approach and issues. I would be just listing two of the scenarios and trying to implement them initially. (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'm not a geronimo expert. My understanding is that the Tuscany deployer needs a way to recognize the archive is a SCA contribution. It could be an external deployment plan such as genronimo-tuscany.xml. If the deployment plan is not present, then a SCA deployment descriptor will be checked. The SCA assembly spec doesn't define a mandatory deployment descriptor. We might be able to use META-INF/sca-contributions.xml as a starting point. See Jaceks Mail in this mail chain This will mean that if the deployer finds this file then it will handle the module as a tuscany module and if not found relinquish control to other deployers. The SCA contribution itself can be an EAR. I assume an archive can be processed by multiple deployers. I think the module can be processed only by a single builder that implements the ConfigurationBuilder interface. We cannot chain ConfigurationBuilder instances. We can have references to ModuleBuilders in our builder but i think that is not the approach to follow. So in case of a plugin approach i think we will need to write a deployment watcher i.e a gbean that implements the org.apache.geronimo.kernel.config.DeploymentWatcher interface. The interface has two methods void deployed(Artifact id); void undeployed(Artifact id); So whenever any module is deployed this will get called after deployment. And u can access and modify the configuration. This approach too has some disadvantages The biggest one is since serialized gbeans cannot be edited we will need to recreate the configuration. We can use also use some methods in EditableConfigurationManager but again its functionality is limited and also adds the info to config.xml Now we come to the question of the Domain. This has been a vexing question for me. I think that going for a single SCADomain for the entire server would be a good place to start. All the applications will have an application composite and that composite will be deployed on the server wide SCADomain. What the server wide SCADomain should provide is the ability to add and remove composites at runtime. If I am not mistaken this will be supported by the EmbeddedSCADomain. Can someone in the know comment on this. We can start with a local SCA domain for the Geronimo server. EmbeddedSCADomain is the right class and it can be extended to support the Geronimo host. The other logical approach would be to go for different partial SCADomain instances per contribution. These different instances will still have information about the other instances and will do the wiring across the instances that constitute a complete SCADomain. From what I could find, this type of an SCADomain is not supported currently. There is work on an SCADomain spanning multiple runtimes. This would be a simpler case of an SCADomain spanning multiple classloaders or (configurations in Geronimo). SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the support of distributed SCADomain. I'm a bit confused by the statement different partial SCADomain instances per contribution. Can you clarify? I will be responding to Simon on this. Please see that mail. The reason for not going with the second approach is that it is not available in tuscany as of today. Please correct me if I am wrong. (b) This was point (c) in Sebastien's mail. I
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Simon, In one of the previous mails Sebastien proposed two ways of how the SCADomain should exist in geronimo (a) one instance of SCADomain per component running on the server, loaded with a subset of the distributed SCA domain composite representing that component and enough information about its peer components for it to locate and wire to them. (b) a single SCADomain object per Geronimo server, loaded with all the components running on the server. This will save a little bit of memory, at the expense of more synchronization work. I'd suggest to start with option (a) as it's the model that needs to be supported when SCA components run on different physical machines as well, and I'm actually not sure that we'll get any real performance gain with (b) over (a) if we do (a) right. Point (a) looks very similar to the distributed domain concept you explained. First it should be distributed across different apps/classloaders. There will be different instances of SCADomain containing parts of the whole and the different domain instances should constitute a single domain, which is capable of wiring together the components in the different instances they should be able to wire. This looks exactly like the scenario u mentioned but only locally. Is this supported as of now. As Raymond says, we do have limited support for the distributed SCADomain now. The APIs for driving it are not sorted out yet though. What happens now is that you provide all contributed resources to each node in the domain and then tell each node which component from a contribution it is responsible and it does the rest creating remote connections where appropriate. I am interested to understand how you might use a distributed domain in the Geronimo integration exercise, even if you use the single EmbeddedSCADomain in the first instance, as it could inform the design of the API. I didn't give much thought to this but at the high level two possibilities. a) If we have a single domain per server. Then that domain can span over multiple Geronimo instances and do wiring between JEE apps exposed as SCA services on both the server instances. b) If we have multiple domains in each server, then each of them can span over multiple instances. c) If in one server itself there are many instances constituting one domain, then there is a possibility that there are multiple instances in another server as well which also will be part of the same domain. d) What to do when we cluster geronimo instances? Will SCADomains be clustered too? I am not sure how much sense i am making and whatever I am saying is very general. This is all i can think off now. If there is anything else someone can think off pls jump in. Regards Manu Regards Simon
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Jacek, The spec also says in 1.10.2.2. 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 :(. Regards Manu On 7/4/07, Manu George [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 7/3/07, Manu George [EMAIL PROTECTED] 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 likeservlets 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 http://www.JacekLaskowski.pl 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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi , From Paul's mail I guess a Geronimo plugin would be the way forward. I am going to list down a few more questions on the scenarios that Sebastien has explained. The scenarios are given first and then my understanding, approach and issues. I would be just listing two of the scenarios and trying to implement them initially. (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. This will mean that if the deployer finds this file then it will handle the module as a tuscany module and if not found relinquish control to other deployers. Now we come to the question of the Domain. This has been a vexing question for me. I think that going for a single SCADomain for the entire server would be a good place to start. All the applications will have an application composite and that composite will be deployed on the server wide SCADomain. What the server wide SCADomain should provide is the ability to add and remove composites at runtime. If I am not mistaken this will be supported by the EmbeddedSCADomain. Can someone in the know comment on this. The other logical approach would be to go for different partial SCADomain instances per contribution. These different instances will still have information about the other instances and will do the wiring across the instances that constitute a complete SCADomain. From what I could find, this type of an SCADomain is not supported currently. There is work on an SCADomain spanning multiple runtimes. This would be a simpler case of an SCADomain spanning multiple classloaders or (configurations in Geronimo). The reason for not going with the second approach is that it is not available in tuscany as of today. Please correct me if I am wrong. (b) This was point (c) in Sebastien's mail. 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. In addition to this the J2EE integration whitepaper at the OSOA site mentions abt being able to annotate Web artifacts(servlets,filters etc) with the SCA Annotations and get services injected into servlets/filters etc for usage. The wiring will be done by the SCA runtime. The whitepaper is here http://www.osoa.org/pages/viewpage.action?pageId=3980. The things to be done for achieving this functionality are, 1) Create a new implementation type in Tuscany namely implementation.web. 2) Declare in a .composite file in the war that the war is an implementation.web type 3) The implementation.web tuscany extension will have functionality to introspect the web module classes for SCA specific annotations and build up information. Since there is a single SCADomain instance per server and all the services that we are going to reference are already deployed there, the implementation.web extension will take care of wiring and creating service proxies. These proxies will be bound to jndi. The injection into geronimo managed objects cannot be done by tuscany runtime. I am not 100% sure but I think that if I can populate the injectionMap in the Holder object in the TomcatWebAppContext GBean for that war with the right information then the injection will be taken care of by Geronimo. Can someone confirm this? This will take care of the integration in these two cases. As of now we are assuming all the services to of scope stateless. All the stuff in the second case will be done in a deployment watcher after a war has been deployed. This is the approach that myself and Vamsi are planning to use. If there is any problem with this approach that you can see or a better way to do things or something in the mail is not clear, please fell free to point it out. Regards Manu On 6/29/07, Paul McMahan [EMAIL PROTECTED] wrote: On Jun 29, 2007, at 3:11 AM, Manu George wrote: Some of the questions we have are: 1. Should we use this plugin approach and host the plugin separatley or
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: dev@geronimo.apache.org Cc: [EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 7:53 AM Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists) Hi , From Paul's mail I guess a Geronimo plugin would be the way forward. I am going to list down a few more questions on the scenarios that Sebastien has explained. The scenarios are given first and then my understanding, approach and issues. I would be just listing two of the scenarios and trying to implement them initially. (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'm not a geronimo expert. My understanding is that the Tuscany deployer needs a way to recognize the archive is a SCA contribution. It could be an external deployment plan such as genronimo-tuscany.xml. If the deployment plan is not present, then a SCA deployment descriptor will be checked. The SCA assembly spec doesn't define a mandatory deployment descriptor. We might be able to use META-INF/sca-contributions.xml as a starting point. This will mean that if the deployer finds this file then it will handle the module as a tuscany module and if not found relinquish control to other deployers. The SCA contribution itself can be an EAR. I assume an archive can be processed by multiple deployers. Now we come to the question of the Domain. This has been a vexing question for me. I think that going for a single SCADomain for the entire server would be a good place to start. All the applications will have an application composite and that composite will be deployed on the server wide SCADomain. What the server wide SCADomain should provide is the ability to add and remove composites at runtime. If I am not mistaken this will be supported by the EmbeddedSCADomain. Can someone in the know comment on this. We can start with a local SCA domain for the Geronimo server. EmbeddedSCADomain is the right class and it can be extended to support the Geronimo host. The other logical approach would be to go for different partial SCADomain instances per contribution. These different instances will still have information about the other instances and will do the wiring across the instances that constitute a complete SCADomain. From what I could find, this type of an SCADomain is not supported currently. There is work on an SCADomain spanning multiple runtimes. This would be a simpler case of an SCADomain spanning multiple classloaders or (configurations in Geronimo). SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the support of distributed SCADomain. I'm a bit confused by the statement different partial SCADomain instances per contribution. Can you clarify? The reason for not going with the second approach is that it is not available in tuscany as of today. Please correct me if I am wrong. (b) This was point (c) in Sebastien's mail. 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. In addition to this the J2EE integration whitepaper at the OSOA site mentions abt being able to annotate Web artifacts(servlets,filters etc) with the SCA Annotations and get services injected into servlets/filters etc for usage. The wiring will be done by the SCA runtime. The whitepaper is here http://www.osoa.org/pages/viewpage.action?pageId=3980. The things to be done for achieving this functionality are, 1) Create a new implementation type in Tuscany namely implementation.web. 2) Declare in a .composite file in the war that the war is an implementation.web type 3) The implementation.web tuscany extension will have functionality to introspect the web module classes for SCA specific annotations and build up information. Since there is a single SCADomain
Re: [DISCUSS] Geronimo-Tuscany integration
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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
On Jun 29, 2007, at 3:11 AM, Manu George wrote: 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. Implementing as a plugin should not affect the technical design of this component. I don't know of anything you can do in a component integrated into Geronimo at assembly time that you cannot do in a plugin integrated after installation. A plugin is really just a component that has been preconfigured for rapid deployment and dependency downloading. It's a packaging decision. IMO new components created for Geronimo that are not required by the JEE specification should be implemented as plugins. This is a rule of thumb, and in some cases there may be justification for an exception. Like for example if we believed that almost every Geronimo user will need SOA then we should discuss full fledged integration. Another type of exception would be if we think that the component would provide useful services to Geronimo's native components. Best wishes, Paul
Re: [DISCUSS] Geronimo-Tuscany integration
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
