You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Manu George <ma...@gmail.com> on 2007/06/29 09:11:05 UTC
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 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
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Luciano Resende <lu...@gmail.com>.
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 <ma...@gmail.com> 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 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
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Luciano Resende <lu...@gmail.com>.
Comments in-line...
On 7/6/07, Manu George <ma...@gmail.com> wrote:
> Hi Jacek,
>
> Comments inline
>
> On 7/5/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > On 7/4/07, Manu George <ma...@gmail.com> 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 like servlets 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)
Posted by Luciano Resende <lu...@gmail.com>.
Comments in-line...
On 7/6/07, Manu George <ma...@gmail.com> wrote:
> Hi Jacek,
>
> Comments inline
>
> On 7/5/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > On 7/4/07, Manu George <ma...@gmail.com> 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 like servlets 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/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
Hi Jacek,
Comments inline
On 7/5/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 7/4/07, Manu George <ma...@gmail.com> 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 like servlets 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)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/4/07, Manu George <ma...@gmail.com> 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 like servlets 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)
Posted by Manu George <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <ja...@laskowski.net.pl> wrote:
> > On 7/3/07, Manu George <ma...@gmail.com> 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 like servlets 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <ja...@laskowski.net.pl> wrote:
> > On 7/3/07, Manu George <ma...@gmail.com> 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 like servlets 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)
Posted by Manu George <ma...@gmail.com>.
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 <ja...@laskowski.net.pl> wrote:
> On 7/3/07, Manu George <ma...@gmail.com> 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 like servlets 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)
Posted by Manu George <ma...@gmail.com>.
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 <ja...@laskowski.net.pl> wrote:
> On 7/3/07, Manu George <ma...@gmail.com> 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 like servlets 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/3/07, Manu George <ma...@gmail.com> 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)
Posted by Manu George <ma...@gmail.com>.
Hi Raymond,
Comments Inline
On 7/4/07, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Manu George" <ma...@gmail.com>
> To: <de...@geronimo.apache.org>
> Cc: <tu...@ws.apache.org>
> 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 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.
> >
>
> I didn't do much investigation in this space but it seems that it's in line
> with the white paper.
>
> > 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 <pa...@gmail.com> 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 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
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Simon Laws <si...@googlemail.com>.
Hi Manu, I'm away this week but here are a few more thoughts for now.
On 7/6/07, Manu George <ma...@gmail.com> wrote:
>
> Hi Simon,
> Comments inline.
>
> On 7/5/07, Simon Laws <si...@googlemail.com> wrote:
> > Hi Manu
> >
> > more comments in line....
> >
> > On 7/4/07, Manu George <ma...@gmail.com> 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
It depends how closely related the applications are. From the assembly spec
"A single SCA domain defines the boundary of visibility for all SCA
mechanisms.". In the case that the applications are intentionally isolated
from one another and sepcifically must not share components or try to create
local wires between components from different applications then I would
expect to see each application in separate domains. Remote wires could of
course be included to cross a domain boundary using explicity
services/reference with remote bindings.
I think Sebastien was suggesting we start with this model where each
deployed application (set of related composites) runs in a separate
(distributed) domain. I put distributed in brackets there as an application
running in a domain in geronimo server A might we part of the same
distributed domain as an application running in geronimo server B.
> 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.
Yes, I think you are correct. Within a single VM there can be multiple
domains. The notion of a distributed domain spans multiple VMs. In the
distributed domain case the Tuscany runtime is smat enough to create remote
bindings in the right places to ensure that communications across VMs is
handled appropriately.
> > > 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, then there is a possibility that there are multiple instances
> > > in another server as well which also will be part of the same domain.
> >
> >
> > Do you mean component instances or geronimo instances here? Assuming
> you
> > mean Geronimo instances then yes regardless of how Geronino is started,
> i.e.
> > many instances on one box or main instances across boxes we would expect
> a
> > domain to be able to span these instances.
> >
> > d) What to do when we cluster geronimo instances? Will SCADomains be
> > > clustered too?
> >
> >
> > Interesting question. To date I have modelled the distributed domain as
> a
> > set of distributed nodes where each node provides service endpoints for
> the
> > services it contains. This does not explain how a node is implemented.
> It
> > could be a JVM running tuscany or it could be a cluster spreading the
> load
> > out across many JVMs. The thing is that there is the notion of a node
> > exposing the endpoints for the part of the distributed domain it runs.
> I.e.
> > my emphasis has been on how to represent a widely distributed set of
> > services in a distributed domain rather than how to represent a
> performance
> > or HA solution, such as a cluster. Having said this it would be good to
> > understand how you would implement a node in a distributed domain as a
> > cluster of Geronimo servers so I'm keen to help out on that if I can.
> >
>
> I guess we can think of it at a later stage. If the domain is
> distributed, it is like a cluster I guess. But my concern was that
> when we clone server nodes the SCADomains will also get cloned for
> both local and distributed domains and we need to handle that
> scenario..
Yes. We can consider the cluser in two ways.
1/ It is hidden behind a single SCA node (one part of the distirbuted
domain). In this case Tuscany SCA is not aware of how the clustering is
achieved and a component is only assigned to one node. Some special plubming
is required in the Tuscany runtime to ensure that component services are
started on all servers in the cluser. The load balanced of the cluster would
then be responsible for spraying work to the running services as is normally
the case with clusters.
2/ The topology that Tuscany is aware of includes all of the clustered
servers. The implication of this is that a component can be assigned to
multiple nodes. In this case Tuscany's SCA binding implementation (the thing
that is delivering messages to component instances has to be cluster aware.
> 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.
> >
> >
> > As you can tell I'm not a Geronimo expert and It's easy to get lost when
> we
> > all start talking about servers, instances, nodes, components etc. What
> we
> > could do with is a set of terms that we agree the meaning of to help our
> > conversation along. To date I have been thinking of the distributed
> domain
> > in this way....
> >
> > SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ----
> n
> > SCA Component Instance
> >
> Ok here I am not getting why there are n instances of the SCA
> Component? I understand from your previous mails that for the
> distributed runtime each node needs all contributed resources to be
> provided. So that results in 1 instance of the SCA Component per node.
> Doesn't that defeat the purpose of the distributed runtime? Or is it
> the initial step, or am i missing something (most likely :)).
I was just saying here that any node in the distributed domain might have 1
or more SCA components assigned to it.
In the Tuscany runtime It is normally the case that a component will give
rise to one or more components instances (Java objects when the component
has a java implementation) as the SCA application runs. The actual number
created depends on how the component is scoped. So the "n" SCA component
instances was just capturing this.
When I said previously that currently each distributed runtime reads all
components I should have added that each node then throws away all but the
ones that are assigned to it to run. As you may have guessed it reads all of
the components in the first instance so that it can work out where all the
components are and create remote bindings as appropriate. If a node finds it
has to run component A but component A is wired to component B that is
running in another node then a remote binding will be creates to connect
component A to component B
In the application scenario where each app is a composite I was
> envisaging only a single component instance or more accurate 1 SCA
> composite instance per application.
I think its fair to say that there will only be one domain level composite
per application but that that may be made up of a number of other
composites/components.
> So a (distributed)SCA domain runs on logical runtime. This runtime doesn't
> > really exist in any physical sense and is just the collection of nodes
> that
> > runt artefacts belonging to the domain. Now where does Geronimo come in?
> >
> > Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
>
> >
> > Where server is some physical computer/processor and the Geronimo
> instance
> > is a JVM containing a running instance of Geronimo. Can you say
> something
> > about how Geronimo instances would be related to one another?
> >
> > Would it be the case that there is a one to one relationship between
> > Geronimo instance and Node?
> >
> As per my understanding yes that makes the most sense. I am assuming
> that there can be multiple nodes per server/machine just like there
> can be multiple geronimo instances in the same machine.
Yes, with the java runtime the node equates to a Jvm. So maybe we can extend
the diagram a little.
Physical Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance 1 ---- 1 Node n
---- n SCA Domain 1 ---- n SCA Component
I've missed a few relationships out here and not represented runtime or
component instance but you get the idea. If we wanted to cluster the
Geronimo instance then we would clone the node. The question that we would
then have to ask is does SCA know about the cloned nodes. I don't know the
answer to that just yet and maybe both approaches are viable. I'll think
more about this while I'm away this week.
>
> > Regards
> > > Manu
> > >
> > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
> Regards
> Manu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by David Jencks <da...@yahoo.com>.
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 < enjoyjava@gmail.com> 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" < manu.t.george@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <si...@googlemail.com> wrote:
> >> Hi Manu
> >>
> >> more comments in line....
> >>
> >> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple
> instances
> >> > in another server as well which also will be part of the same
> domain.
> >>
> >>
> >> Do you mean component instances or geronimo instances here?
> Assuming
> >> you
> >> mean Geronimo instances then yes regardless of how Geronino is
> started,
> >> i.e.
> >> many instances on one box or main instances across boxes we
> would expect
> >> a
> >> domain to be able to span these instances.
> >>
> >> d) What to do when we cluster geronimo instances? Will
> SCADomains be
> >> > clustered too?
> >>
> >>
> >> Interesting question. To date I have modelled the distributed
> domain as a
> >> set of distributed nodes where each node provides service
> endpoints for
> >> the
> >> services it contains. This does not explain how a node is
> implemented. It
> >> could be a JVM running tuscany or it could be a cluster
> spreading the
> >> load
> >> out across many JVMs. The thing is that there is the notion of a
> node
> >> exposing the endpoints for the part of the distributed domain it
> runs.
> >> I.e.
> >> my emphasis has been on how to represent a widely distributed
> set of
> >> services in a distributed domain rather than how to represent a
> >> performance
> >> or HA solution, such as a cluster. Having said this it would be
> good to
> >> understand how you would implement a node in a distributed
> domain as a
> >> cluster of Geronimo servers so I'm keen to help out on that if I
> can.
> >>
> >
> > I guess we can think of it at a later stage. If the domain is
> > distributed, it is like a cluster I guess. But my concern was that
> > when we clone server nodes the SCADomains will also get cloned for
> > both local and distributed domains and we need to handle that
> > scenario..
> >
> >> 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.
> >>
> >>
> >> As you can tell I'm not a Geronimo expert and It's easy to get
> lost when
> >> we
> >> all start talking about servers, instances, nodes, components
> etc. What
> >> we
> >> could do with is a set of terms that we agree the meaning of to
> help our
> >> conversation along. To date I have been thinking of the distributed
> >> domain
> >> in this way....
> >>
> >> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component
> 1 ---- n
> >> SCA Component Instance
> >>
> > Ok here I am not getting why there are n instances of the SCA
> > Component? I understand from your previous mails that for the
> > distributed runtime each node needs all contributed resources to be
> > provided. So that results in 1 instance of the SCA Component per
> node.
> > Doesn't that defeat the purpose of the distributed runtime? Or is it
> > the initial step, or am i missing something (most likely :)).
> >
> > In the application scenario where each app is a composite I was
> > envisaging only a single component instance or more accurate 1 SCA
> > composite instance per application.
> >
> >> So a (distributed)SCA domain runs on logical runtime. This runtime
> >> doesn't
> >> really exist in any physical sense and is just the collection of
> nodes
> >> that
> >> runt artefacts belonging to the domain. Now where does Geronimo
> come in?
> >>
> >> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
> >
> >>
> >> Where server is some physical computer/processor and the Geronimo
> >> instance
> >> is a JVM containing a running instance of Geronimo. Can you say
> something
> >> about how Geronimo instances would be related to one another?
> >>
> >> Would it be the case that there is a one to one relationship
> between
> >> Geronimo instance and Node?
> >>
> > As per my understanding yes that makes the most sense. I am assuming
> > that there can be multiple nodes per server/machine just like there
> > can be multiple geronimo instances in the same machine.
> >
> >>
> >> Regards
> >> > Manu
> >> >
> >> >
> >> > > Regards
> >> > >
> >> > > Simon
> >> > >
> >> >
> >> >
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
> > Regards
> > Manu
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
The stuff in sandbox covers points 1 and 2 below to some extent. Apart from
this, we have a GeronimoServletHost implementation so that Geronimo's tomcat
server is used when a service is exposed as webservice. We have got the
calculator, simple-bigbank and helloworld-ws-service samples from tuscany
samples working in Geronimo. More details inline.
On 7/27/07, David Jencks <da...@yahoo.com> wrote:
>
> 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).
We have an EmbeddedSCADomainGBean that wraps an EmbeddedSCADomain tuscany
class. We have a TuscanyBuilder to deploy standalone tuscany jars into
Geronimo. Both these GBeans are part of a configuration that runs as a
"tuscany-plugin" for Geronimo.
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)
The TuscanyBuilder GBean, as part of deploying a tuscany jar, creates a
configuration and adds an "EmbeddedRuntimeGBean" to the configuration and
copies the jar to repository. When the configuration is started, the
EmbeddedRuntimeGBean computes the contribution from the tuscany jar, adds
the contribution to EmbeddedSCADomain wrapped by the EmbeddedSCADomainGBean
and starts the components. When the configuration is stopped, it stops the
components and removes the contribution from EmbeddedSCADomain. Apart from
this the EmbeddedRuntimeGBean is starting all components (components from
other tuscany jars as well) as a work around for some problems we have come
across in EmbeddedSCADomain class.
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+Integrationunder
> > Current status. Code is in Geronimo Sandbox.
> >
> > Thanks and regards,
> > Vamsi
> >
> > On 7/7/07, Raymond Feng <en...@gmail.com> 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" <ma...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> 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 <si...@googlemail.com> wrote:
> >>>> Hi Manu
> >>>>
> >>>> more comments in line....
> >>>>
> >>>> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple
> >>>>> instances
> >>>>> in another server as well which also will be part of the same
> >>>>> domain.
> >>>>
> >>>>
> >>>> Do you mean component instances or geronimo instances here?
> >>>> Assuming
> >>>> you
> >>>> mean Geronimo instances then yes regardless of how Geronino is
> >>>> started,
> >>>> i.e.
> >>>> many instances on one box or main instances across boxes we would
> >> expect
> >>>> a
> >>>> domain to be able to span these instances.
> >>>>
> >>>> d) What to do when we cluster geronimo instances? Will
> >>>> SCADomains be
> >>>>> clustered too?
> >>>>
> >>>>
> >>>> Interesting question. To date I have modelled the distributed
> >>>> domain as
> >> a
> >>>> set of distributed nodes where each node provides service
> >>>> endpoints for
> >>>> the
> >>>> services it contains. This does not explain how a node is
> >>>> implemented.
> >> It
> >>>> could be a JVM running tuscany or it could be a cluster
> >>>> spreading the
> >>>> load
> >>>> out across many JVMs. The thing is that there is the notion of a
> >>>> node
> >>>> exposing the endpoints for the part of the distributed domain it
> >>>> runs.
> >>>> I.e.
> >>>> my emphasis has been on how to represent a widely distributed
> >>>> set of
> >>>> services in a distributed domain rather than how to represent a
> >>>> performance
> >>>> or HA solution, such as a cluster. Having said this it would be
> >>>> good to
> >>>> understand how you would implement a node in a distributed
> >>>> domain as a
> >>>> cluster of Geronimo servers so I'm keen to help out on that if I
> >>>> can.
> >>>>
> >>>
> >>> I guess we can think of it at a later stage. If the domain is
> >>> distributed, it is like a cluster I guess. But my concern was that
> >>> when we clone server nodes the SCADomains will also get cloned for
> >>> both local and distributed domains and we need to handle that
> >>> scenario..
> >>>
> >>>> 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.
> >>>>
> >>>>
> >>>> As you can tell I'm not a Geronimo expert and It's easy to get lost
> >> when
> >>>> we
> >>>> all start talking about servers, instances, nodes, components etc.
> >> What
> >>>> we
> >>>> could do with is a set of terms that we agree the meaning of to
> >>>> help
> >> our
> >>>> conversation along. To date I have been thinking of the distributed
> >>>> domain
> >>>> in this way....
> >>>>
> >>>> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component
> >>>> 1 ----
> >> n
> >>>> SCA Component Instance
> >>>>
> >>> Ok here I am not getting why there are n instances of the SCA
> >>> Component? I understand from your previous mails that for the
> >>> distributed runtime each node needs all contributed resources to be
> >>> provided. So that results in 1 instance of the SCA Component per
> >>> node.
> >>> Doesn't that defeat the purpose of the distributed runtime? Or is it
> >>> the initial step, or am i missing something (most likely :)).
> >>>
> >>> In the application scenario where each app is a composite I was
> >>> envisaging only a single component instance or more accurate 1 SCA
> >>> composite instance per application.
> >>>
> >>>> So a (distributed)SCA domain runs on logical runtime. This runtime
> >>>> doesn't
> >>>> really exist in any physical sense and is just the collection of
> >>>> nodes
> >>>> that
> >>>> runt artefacts belonging to the domain. Now where does Geronimo
> >>>> come
> >> in?
> >>>>
> >>>> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
> >>>
> >>>>
> >>>> Where server is some physical computer/processor and the Geronimo
> >>>> instance
> >>>> is a JVM containing a running instance of Geronimo. Can you say
> >> something
> >>>> about how Geronimo instances would be related to one another?
> >>>>
> >>>> Would it be the case that there is a one to one relationship
> >>>> between
> >>>> Geronimo instance and Node?
> >>>>
> >>> As per my understanding yes that makes the most sense. I am assuming
> >>> that there can be multiple nodes per server/machine just like there
> >>> can be multiple geronimo instances in the same machine.
> >>>
> >>>>
> >>>> Regards
> >>>>> Manu
> >>>>>
> >>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> Simon
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> Regards
> >>> Manu
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
The stuff in sandbox covers points 1 and 2 below to some extent. Apart from
this, we have a GeronimoServletHost implementation so that Geronimo's tomcat
server is used when a service is exposed as webservice. We have got the
calculator, simple-bigbank and helloworld-ws-service samples from tuscany
samples working in Geronimo. More details inline.
On 7/27/07, David Jencks <da...@yahoo.com> wrote:
>
> 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).
We have an EmbeddedSCADomainGBean that wraps an EmbeddedSCADomain tuscany
class. We have a TuscanyBuilder to deploy standalone tuscany jars into
Geronimo. Both these GBeans are part of a configuration that runs as a
"tuscany-plugin" for Geronimo.
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)
The TuscanyBuilder GBean, as part of deploying a tuscany jar, creates a
configuration and adds an "EmbeddedRuntimeGBean" to the configuration and
copies the jar to repository. When the configuration is started, the
EmbeddedRuntimeGBean computes the contribution from the tuscany jar, adds
the contribution to EmbeddedSCADomain wrapped by the EmbeddedSCADomainGBean
and starts the components. When the configuration is stopped, it stops the
components and removes the contribution from EmbeddedSCADomain. Apart from
this the EmbeddedRuntimeGBean is starting all components (components from
other tuscany jars as well) as a work around for some problems we have come
across in EmbeddedSCADomain class.
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+Integrationunder
> > Current status. Code is in Geronimo Sandbox.
> >
> > Thanks and regards,
> > Vamsi
> >
> > On 7/7/07, Raymond Feng <en...@gmail.com> 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" <ma...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> 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 <si...@googlemail.com> wrote:
> >>>> Hi Manu
> >>>>
> >>>> more comments in line....
> >>>>
> >>>> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple
> >>>>> instances
> >>>>> in another server as well which also will be part of the same
> >>>>> domain.
> >>>>
> >>>>
> >>>> Do you mean component instances or geronimo instances here?
> >>>> Assuming
> >>>> you
> >>>> mean Geronimo instances then yes regardless of how Geronino is
> >>>> started,
> >>>> i.e.
> >>>> many instances on one box or main instances across boxes we would
> >> expect
> >>>> a
> >>>> domain to be able to span these instances.
> >>>>
> >>>> d) What to do when we cluster geronimo instances? Will
> >>>> SCADomains be
> >>>>> clustered too?
> >>>>
> >>>>
> >>>> Interesting question. To date I have modelled the distributed
> >>>> domain as
> >> a
> >>>> set of distributed nodes where each node provides service
> >>>> endpoints for
> >>>> the
> >>>> services it contains. This does not explain how a node is
> >>>> implemented.
> >> It
> >>>> could be a JVM running tuscany or it could be a cluster
> >>>> spreading the
> >>>> load
> >>>> out across many JVMs. The thing is that there is the notion of a
> >>>> node
> >>>> exposing the endpoints for the part of the distributed domain it
> >>>> runs.
> >>>> I.e.
> >>>> my emphasis has been on how to represent a widely distributed
> >>>> set of
> >>>> services in a distributed domain rather than how to represent a
> >>>> performance
> >>>> or HA solution, such as a cluster. Having said this it would be
> >>>> good to
> >>>> understand how you would implement a node in a distributed
> >>>> domain as a
> >>>> cluster of Geronimo servers so I'm keen to help out on that if I
> >>>> can.
> >>>>
> >>>
> >>> I guess we can think of it at a later stage. If the domain is
> >>> distributed, it is like a cluster I guess. But my concern was that
> >>> when we clone server nodes the SCADomains will also get cloned for
> >>> both local and distributed domains and we need to handle that
> >>> scenario..
> >>>
> >>>> 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.
> >>>>
> >>>>
> >>>> As you can tell I'm not a Geronimo expert and It's easy to get lost
> >> when
> >>>> we
> >>>> all start talking about servers, instances, nodes, components etc.
> >> What
> >>>> we
> >>>> could do with is a set of terms that we agree the meaning of to
> >>>> help
> >> our
> >>>> conversation along. To date I have been thinking of the distributed
> >>>> domain
> >>>> in this way....
> >>>>
> >>>> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component
> >>>> 1 ----
> >> n
> >>>> SCA Component Instance
> >>>>
> >>> Ok here I am not getting why there are n instances of the SCA
> >>> Component? I understand from your previous mails that for the
> >>> distributed runtime each node needs all contributed resources to be
> >>> provided. So that results in 1 instance of the SCA Component per
> >>> node.
> >>> Doesn't that defeat the purpose of the distributed runtime? Or is it
> >>> the initial step, or am i missing something (most likely :)).
> >>>
> >>> In the application scenario where each app is a composite I was
> >>> envisaging only a single component instance or more accurate 1 SCA
> >>> composite instance per application.
> >>>
> >>>> So a (distributed)SCA domain runs on logical runtime. This runtime
> >>>> doesn't
> >>>> really exist in any physical sense and is just the collection of
> >>>> nodes
> >>>> that
> >>>> runt artefacts belonging to the domain. Now where does Geronimo
> >>>> come
> >> in?
> >>>>
> >>>> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
> >>>
> >>>>
> >>>> Where server is some physical computer/processor and the Geronimo
> >>>> instance
> >>>> is a JVM containing a running instance of Geronimo. Can you say
> >> something
> >>>> about how Geronimo instances would be related to one another?
> >>>>
> >>>> Would it be the case that there is a one to one relationship
> >>>> between
> >>>> Geronimo instance and Node?
> >>>>
> >>> As per my understanding yes that makes the most sense. I am assuming
> >>> that there can be multiple nodes per server/machine just like there
> >>> can be multiple geronimo instances in the same machine.
> >>>
> >>>>
> >>>> Regards
> >>>>> Manu
> >>>>>
> >>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> Simon
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> Regards
> >>> Manu
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by David Jencks <da...@yahoo.com>.
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+Integrationunder
> Current status. Code is in Geronimo Sandbox.
>
> Thanks and regards,
> Vamsi
>
> On 7/7/07, Raymond Feng <en...@gmail.com> 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" <ma...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <si...@googlemail.com> wrote:
>>>> Hi Manu
>>>>
>>>> more comments in line....
>>>>
>>>> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple
>>>>> instances
>>>>> in another server as well which also will be part of the same
>>>>> domain.
>>>>
>>>>
>>>> Do you mean component instances or geronimo instances here?
>>>> Assuming
>>>> you
>>>> mean Geronimo instances then yes regardless of how Geronino is
>>>> started,
>>>> i.e.
>>>> many instances on one box or main instances across boxes we would
>> expect
>>>> a
>>>> domain to be able to span these instances.
>>>>
>>>> d) What to do when we cluster geronimo instances? Will
>>>> SCADomains be
>>>>> clustered too?
>>>>
>>>>
>>>> Interesting question. To date I have modelled the distributed
>>>> domain as
>> a
>>>> set of distributed nodes where each node provides service
>>>> endpoints for
>>>> the
>>>> services it contains. This does not explain how a node is
>>>> implemented.
>> It
>>>> could be a JVM running tuscany or it could be a cluster
>>>> spreading the
>>>> load
>>>> out across many JVMs. The thing is that there is the notion of a
>>>> node
>>>> exposing the endpoints for the part of the distributed domain it
>>>> runs.
>>>> I.e.
>>>> my emphasis has been on how to represent a widely distributed
>>>> set of
>>>> services in a distributed domain rather than how to represent a
>>>> performance
>>>> or HA solution, such as a cluster. Having said this it would be
>>>> good to
>>>> understand how you would implement a node in a distributed
>>>> domain as a
>>>> cluster of Geronimo servers so I'm keen to help out on that if I
>>>> can.
>>>>
>>>
>>> I guess we can think of it at a later stage. If the domain is
>>> distributed, it is like a cluster I guess. But my concern was that
>>> when we clone server nodes the SCADomains will also get cloned for
>>> both local and distributed domains and we need to handle that
>>> scenario..
>>>
>>>> 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.
>>>>
>>>>
>>>> As you can tell I'm not a Geronimo expert and It's easy to get lost
>> when
>>>> we
>>>> all start talking about servers, instances, nodes, components etc.
>> What
>>>> we
>>>> could do with is a set of terms that we agree the meaning of to
>>>> help
>> our
>>>> conversation along. To date I have been thinking of the distributed
>>>> domain
>>>> in this way....
>>>>
>>>> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component
>>>> 1 ----
>> n
>>>> SCA Component Instance
>>>>
>>> Ok here I am not getting why there are n instances of the SCA
>>> Component? I understand from your previous mails that for the
>>> distributed runtime each node needs all contributed resources to be
>>> provided. So that results in 1 instance of the SCA Component per
>>> node.
>>> Doesn't that defeat the purpose of the distributed runtime? Or is it
>>> the initial step, or am i missing something (most likely :)).
>>>
>>> In the application scenario where each app is a composite I was
>>> envisaging only a single component instance or more accurate 1 SCA
>>> composite instance per application.
>>>
>>>> So a (distributed)SCA domain runs on logical runtime. This runtime
>>>> doesn't
>>>> really exist in any physical sense and is just the collection of
>>>> nodes
>>>> that
>>>> runt artefacts belonging to the domain. Now where does Geronimo
>>>> come
>> in?
>>>>
>>>> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
>>>
>>>>
>>>> Where server is some physical computer/processor and the Geronimo
>>>> instance
>>>> is a JVM containing a running instance of Geronimo. Can you say
>> something
>>>> about how Geronimo instances would be related to one another?
>>>>
>>>> Would it be the case that there is a one to one relationship
>>>> between
>>>> Geronimo instance and Node?
>>>>
>>> As per my understanding yes that makes the most sense. I am assuming
>>> that there can be multiple nodes per server/machine just like there
>>> can be multiple geronimo instances in the same machine.
>>>
>>>>
>>>> Regards
>>>>> Manu
>>>>>
>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> Regards
>>> Manu
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <en...@gmail.com> 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" <ma...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <si...@googlemail.com> wrote:
> >> Hi Manu
> >>
> >> more comments in line....
> >>
> >> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple instances
> >> > in another server as well which also will be part of the same domain.
> >>
> >>
> >> Do you mean component instances or geronimo instances here? Assuming
> >> you
> >> mean Geronimo instances then yes regardless of how Geronino is started,
> >> i.e.
> >> many instances on one box or main instances across boxes we would
> expect
> >> a
> >> domain to be able to span these instances.
> >>
> >> d) What to do when we cluster geronimo instances? Will SCADomains be
> >> > clustered too?
> >>
> >>
> >> Interesting question. To date I have modelled the distributed domain as
> a
> >> set of distributed nodes where each node provides service endpoints for
> >> the
> >> services it contains. This does not explain how a node is implemented.
> It
> >> could be a JVM running tuscany or it could be a cluster spreading the
> >> load
> >> out across many JVMs. The thing is that there is the notion of a node
> >> exposing the endpoints for the part of the distributed domain it runs.
> >> I.e.
> >> my emphasis has been on how to represent a widely distributed set of
> >> services in a distributed domain rather than how to represent a
> >> performance
> >> or HA solution, such as a cluster. Having said this it would be good to
> >> understand how you would implement a node in a distributed domain as a
> >> cluster of Geronimo servers so I'm keen to help out on that if I can.
> >>
> >
> > I guess we can think of it at a later stage. If the domain is
> > distributed, it is like a cluster I guess. But my concern was that
> > when we clone server nodes the SCADomains will also get cloned for
> > both local and distributed domains and we need to handle that
> > scenario..
> >
> >> 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.
> >>
> >>
> >> As you can tell I'm not a Geronimo expert and It's easy to get lost
> when
> >> we
> >> all start talking about servers, instances, nodes, components etc.
> What
> >> we
> >> could do with is a set of terms that we agree the meaning of to help
> our
> >> conversation along. To date I have been thinking of the distributed
> >> domain
> >> in this way....
> >>
> >> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ----
> n
> >> SCA Component Instance
> >>
> > Ok here I am not getting why there are n instances of the SCA
> > Component? I understand from your previous mails that for the
> > distributed runtime each node needs all contributed resources to be
> > provided. So that results in 1 instance of the SCA Component per node.
> > Doesn't that defeat the purpose of the distributed runtime? Or is it
> > the initial step, or am i missing something (most likely :)).
> >
> > In the application scenario where each app is a composite I was
> > envisaging only a single component instance or more accurate 1 SCA
> > composite instance per application.
> >
> >> So a (distributed)SCA domain runs on logical runtime. This runtime
> >> doesn't
> >> really exist in any physical sense and is just the collection of nodes
> >> that
> >> runt artefacts belonging to the domain. Now where does Geronimo come
> in?
> >>
> >> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
> >
> >>
> >> Where server is some physical computer/processor and the Geronimo
> >> instance
> >> is a JVM containing a running instance of Geronimo. Can you say
> something
> >> about how Geronimo instances would be related to one another?
> >>
> >> Would it be the case that there is a one to one relationship between
> >> Geronimo instance and Node?
> >>
> > As per my understanding yes that makes the most sense. I am assuming
> > that there can be multiple nodes per server/machine just like there
> > can be multiple geronimo instances in the same machine.
> >
> >>
> >> Regards
> >> > Manu
> >> >
> >> >
> >> > > Regards
> >> > >
> >> > > Simon
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
> > Regards
> > Manu
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <en...@gmail.com> 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" <ma...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <si...@googlemail.com> wrote:
> >> Hi Manu
> >>
> >> more comments in line....
> >>
> >> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple instances
> >> > in another server as well which also will be part of the same domain.
> >>
> >>
> >> Do you mean component instances or geronimo instances here? Assuming
> >> you
> >> mean Geronimo instances then yes regardless of how Geronino is started,
> >> i.e.
> >> many instances on one box or main instances across boxes we would
> expect
> >> a
> >> domain to be able to span these instances.
> >>
> >> d) What to do when we cluster geronimo instances? Will SCADomains be
> >> > clustered too?
> >>
> >>
> >> Interesting question. To date I have modelled the distributed domain as
> a
> >> set of distributed nodes where each node provides service endpoints for
> >> the
> >> services it contains. This does not explain how a node is implemented.
> It
> >> could be a JVM running tuscany or it could be a cluster spreading the
> >> load
> >> out across many JVMs. The thing is that there is the notion of a node
> >> exposing the endpoints for the part of the distributed domain it runs.
> >> I.e.
> >> my emphasis has been on how to represent a widely distributed set of
> >> services in a distributed domain rather than how to represent a
> >> performance
> >> or HA solution, such as a cluster. Having said this it would be good to
> >> understand how you would implement a node in a distributed domain as a
> >> cluster of Geronimo servers so I'm keen to help out on that if I can.
> >>
> >
> > I guess we can think of it at a later stage. If the domain is
> > distributed, it is like a cluster I guess. But my concern was that
> > when we clone server nodes the SCADomains will also get cloned for
> > both local and distributed domains and we need to handle that
> > scenario..
> >
> >> 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.
> >>
> >>
> >> As you can tell I'm not a Geronimo expert and It's easy to get lost
> when
> >> we
> >> all start talking about servers, instances, nodes, components etc.
> What
> >> we
> >> could do with is a set of terms that we agree the meaning of to help
> our
> >> conversation along. To date I have been thinking of the distributed
> >> domain
> >> in this way....
> >>
> >> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ----
> n
> >> SCA Component Instance
> >>
> > Ok here I am not getting why there are n instances of the SCA
> > Component? I understand from your previous mails that for the
> > distributed runtime each node needs all contributed resources to be
> > provided. So that results in 1 instance of the SCA Component per node.
> > Doesn't that defeat the purpose of the distributed runtime? Or is it
> > the initial step, or am i missing something (most likely :)).
> >
> > In the application scenario where each app is a composite I was
> > envisaging only a single component instance or more accurate 1 SCA
> > composite instance per application.
> >
> >> So a (distributed)SCA domain runs on logical runtime. This runtime
> >> doesn't
> >> really exist in any physical sense and is just the collection of nodes
> >> that
> >> runt artefacts belonging to the domain. Now where does Geronimo come
> in?
> >>
> >> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
> >
> >>
> >> Where server is some physical computer/processor and the Geronimo
> >> instance
> >> is a JVM containing a running instance of Geronimo. Can you say
> something
> >> about how Geronimo instances would be related to one another?
> >>
> >> Would it be the case that there is a one to one relationship between
> >> Geronimo instance and Node?
> >>
> > As per my understanding yes that makes the most sense. I am assuming
> > that there can be multiple nodes per server/machine just like there
> > can be multiple geronimo instances in the same machine.
> >
> >>
> >> Regards
> >> > Manu
> >> >
> >> >
> >> > > Regards
> >> > >
> >> > > Simon
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
> > Regards
> > Manu
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Raymond Feng <en...@gmail.com>.
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" <ma...@gmail.com>
To: <tu...@ws.apache.org>
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 <si...@googlemail.com> wrote:
>> Hi Manu
>>
>> more comments in line....
>>
>> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple instances
>> > in another server as well which also will be part of the same domain.
>>
>>
>> Do you mean component instances or geronimo instances here? Assuming
>> you
>> mean Geronimo instances then yes regardless of how Geronino is started,
>> i.e.
>> many instances on one box or main instances across boxes we would expect
>> a
>> domain to be able to span these instances.
>>
>> d) What to do when we cluster geronimo instances? Will SCADomains be
>> > clustered too?
>>
>>
>> Interesting question. To date I have modelled the distributed domain as a
>> set of distributed nodes where each node provides service endpoints for
>> the
>> services it contains. This does not explain how a node is implemented. It
>> could be a JVM running tuscany or it could be a cluster spreading the
>> load
>> out across many JVMs. The thing is that there is the notion of a node
>> exposing the endpoints for the part of the distributed domain it runs.
>> I.e.
>> my emphasis has been on how to represent a widely distributed set of
>> services in a distributed domain rather than how to represent a
>> performance
>> or HA solution, such as a cluster. Having said this it would be good to
>> understand how you would implement a node in a distributed domain as a
>> cluster of Geronimo servers so I'm keen to help out on that if I can.
>>
>
> I guess we can think of it at a later stage. If the domain is
> distributed, it is like a cluster I guess. But my concern was that
> when we clone server nodes the SCADomains will also get cloned for
> both local and distributed domains and we need to handle that
> scenario..
>
>> 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.
>>
>>
>> As you can tell I'm not a Geronimo expert and It's easy to get lost when
>> we
>> all start talking about servers, instances, nodes, components etc. What
>> we
>> could do with is a set of terms that we agree the meaning of to help our
>> conversation along. To date I have been thinking of the distributed
>> domain
>> in this way....
>>
>> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ---- n
>> SCA Component Instance
>>
> Ok here I am not getting why there are n instances of the SCA
> Component? I understand from your previous mails that for the
> distributed runtime each node needs all contributed resources to be
> provided. So that results in 1 instance of the SCA Component per node.
> Doesn't that defeat the purpose of the distributed runtime? Or is it
> the initial step, or am i missing something (most likely :)).
>
> In the application scenario where each app is a composite I was
> envisaging only a single component instance or more accurate 1 SCA
> composite instance per application.
>
>> So a (distributed)SCA domain runs on logical runtime. This runtime
>> doesn't
>> really exist in any physical sense and is just the collection of nodes
>> that
>> runt artefacts belonging to the domain. Now where does Geronimo come in?
>>
>> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
>
>>
>> Where server is some physical computer/processor and the Geronimo
>> instance
>> is a JVM containing a running instance of Geronimo. Can you say something
>> about how Geronimo instances would be related to one another?
>>
>> Would it be the case that there is a one to one relationship between
>> Geronimo instance and Node?
>>
> As per my understanding yes that makes the most sense. I am assuming
> that there can be multiple nodes per server/machine just like there
> can be multiple geronimo instances in the same machine.
>
>>
>> Regards
>> > Manu
>> >
>> >
>> > > Regards
>> > >
>> > > Simon
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>
> Regards
> Manu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
Hi Simon,
Comments inline.
On 7/5/07, Simon Laws <si...@googlemail.com> wrote:
> Hi Manu
>
> more comments in line....
>
> On 7/4/07, Manu George <ma...@gmail.com> 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, then there is a possibility that there are multiple instances
> > in another server as well which also will be part of the same domain.
>
>
> Do you mean component instances or geronimo instances here? Assuming you
> mean Geronimo instances then yes regardless of how Geronino is started, i.e.
> many instances on one box or main instances across boxes we would expect a
> domain to be able to span these instances.
>
> d) What to do when we cluster geronimo instances? Will SCADomains be
> > clustered too?
>
>
> Interesting question. To date I have modelled the distributed domain as a
> set of distributed nodes where each node provides service endpoints for the
> services it contains. This does not explain how a node is implemented. It
> could be a JVM running tuscany or it could be a cluster spreading the load
> out across many JVMs. The thing is that there is the notion of a node
> exposing the endpoints for the part of the distributed domain it runs. I.e.
> my emphasis has been on how to represent a widely distributed set of
> services in a distributed domain rather than how to represent a performance
> or HA solution, such as a cluster. Having said this it would be good to
> understand how you would implement a node in a distributed domain as a
> cluster of Geronimo servers so I'm keen to help out on that if I can.
>
I guess we can think of it at a later stage. If the domain is
distributed, it is like a cluster I guess. But my concern was that
when we clone server nodes the SCADomains will also get cloned for
both local and distributed domains and we need to handle that
scenario..
> 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.
>
>
> As you can tell I'm not a Geronimo expert and It's easy to get lost when we
> all start talking about servers, instances, nodes, components etc. What we
> could do with is a set of terms that we agree the meaning of to help our
> conversation along. To date I have been thinking of the distributed domain
> in this way....
>
> SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ---- n
> SCA Component Instance
>
Ok here I am not getting why there are n instances of the SCA
Component? I understand from your previous mails that for the
distributed runtime each node needs all contributed resources to be
provided. So that results in 1 instance of the SCA Component per node.
Doesn't that defeat the purpose of the distributed runtime? Or is it
the initial step, or am i missing something (most likely :)).
In the application scenario where each app is a composite I was
envisaging only a single component instance or more accurate 1 SCA
composite instance per application.
> So a (distributed)SCA domain runs on logical runtime. This runtime doesn't
> really exist in any physical sense and is just the collection of nodes that
> runt artefacts belonging to the domain. Now where does Geronimo come in?
>
> Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
>
> Where server is some physical computer/processor and the Geronimo instance
> is a JVM containing a running instance of Geronimo. Can you say something
> about how Geronimo instances would be related to one another?
>
> Would it be the case that there is a one to one relationship between
> Geronimo instance and Node?
>
As per my understanding yes that makes the most sense. I am assuming
that there can be multiple nodes per server/machine just like there
can be multiple geronimo instances in the same machine.
>
> Regards
> > Manu
> >
> >
> > > Regards
> > >
> > > Simon
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Regards
Manu
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Simon Laws <si...@googlemail.com>.
Hi Manu
more comments in line....
On 7/4/07, Manu George <ma...@gmail.com> 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.
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?
> > 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, then there is a possibility that there are multiple instances
> in another server as well which also will be part of the same domain.
Do you mean component instances or geronimo instances here? Assuming you
mean Geronimo instances then yes regardless of how Geronino is started, i.e.
many instances on one box or main instances across boxes we would expect a
domain to be able to span these instances.
d) What to do when we cluster geronimo instances? Will SCADomains be
> clustered too?
Interesting question. To date I have modelled the distributed domain as a
set of distributed nodes where each node provides service endpoints for the
services it contains. This does not explain how a node is implemented. It
could be a JVM running tuscany or it could be a cluster spreading the load
out across many JVMs. The thing is that there is the notion of a node
exposing the endpoints for the part of the distributed domain it runs. I.e.
my emphasis has been on how to represent a widely distributed set of
services in a distributed domain rather than how to represent a performance
or HA solution, such as a cluster. Having said this it would be good to
understand how you would implement a node in a distributed domain as a
cluster of Geronimo servers so I'm keen to help out on that if I can.
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.
As you can tell I'm not a Geronimo expert and It's easy to get lost when we
all start talking about servers, instances, nodes, components etc. What we
could do with is a set of terms that we agree the meaning of to help our
conversation along. To date I have been thinking of the distributed domain
in this way....
SCADomain n ---- 1 Runtime 1 ----- n Node n ---- n SCA Component 1 ---- n
SCA Component Instance
So a (distributed)SCA domain runs on logical runtime. This runtime doesn't
really exist in any physical sense and is just the collection of nodes that
runt artefacts belonging to the domain. Now where does Geronimo come in?
Server 1 ----- n Jvm 1 ---- 1 Geronimo Instance
Where server is some physical computer/processor and the Geronimo instance
is a JVM containing a running instance of Geronimo. Can you say something
about how Geronimo instances would be related to one another?
Would it be the case that there is a one to one relationship between
Geronimo instance and Node?
Regards
> Manu
>
>
> > Regards
> >
> > Simon
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
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)
Posted by Simon Laws <si...@googlemail.com>.
On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Manu George" <ma...@gmail.com>
> To: <de...@geronimo.apache.org>
> Cc: <tu...@ws.apache.org>
> 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 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.
> >
>
> I didn't do much investigation in this space but it seems that it's in
> line
> with the white paper.
>
> > 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 <pa...@gmail.com> 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 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
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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.
Regards
Simon
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
Hi Raymond,
Comments Inline
On 7/4/07, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Manu George" <ma...@gmail.com>
> To: <de...@geronimo.apache.org>
> Cc: <tu...@ws.apache.org>
> 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 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.
> >
>
> I didn't do much investigation in this space but it seems that it's in line
> with the white paper.
>
> > 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 <pa...@gmail.com> 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 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
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Manu George" <ma...@gmail.com>
To: <de...@geronimo.apache.org>
Cc: <tu...@ws.apache.org>
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 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.
>
I didn't do much investigation in this space but it seems that it's in line
with the white paper.
> 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 <pa...@gmail.com> 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 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(Sending to both lists)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Manu George" <ma...@gmail.com>
To: <de...@geronimo.apache.org>
Cc: <tu...@ws.apache.org>
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 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.
>
I didn't do much investigation in this space but it seems that it's in line
with the white paper.
> 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 <pa...@gmail.com> 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 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
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
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 <pa...@gmail.com> 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 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(Sending to both lists)
Posted by Manu George <ma...@gmail.com>.
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 <pa...@gmail.com> 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 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Posted by Paul McMahan <pa...@gmail.com>.
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(Sending to both lists)
Posted by Luciano Resende <lu...@gmail.com>.
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 <ma...@gmail.com> 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 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
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/