Geronimo/Tuscany integration

[Raymond Feng <en...@gmail.com>]

Hi, Geronimo community.

As you may know, Tuscany is an Apache project under incubation to provide an 
open source SOA infrastructure. For more information, you can visit 
http://cwiki.apache.org/TUSCANY/.

Tuscany implements the SCA specification (http://www.osoa.org) and allows 
you to develop and run SCA components in various hosting environments. We 
currently integrate with Tomcat and Jetty and would like to try to integrate 
with Geronimo as well. I would like to start some discussions here to figure 
out the best way to do that.

After some preliminary investigations of Geronimo, I feel that there are two 
options on the table so far.

1) Shallow integration: Package SCA applications together with the Tuscany 
runtime as WARs and deploy them Geronimo as Web applications. It's basically 
the integration with a Web container. We register a TuscanyContextListner 
(which implements javax.servlet.ServletContextListener) in web.xml to 
start/stop the Tuscany runtime when the web application is started/stopped.

This will allow us to support the following use cases:
* A Web application hosted by Geronimo with business logic written as SCA 
components
* Expose one or more SCA components as Web services over HTTP as supported 
by the Web container.

2) Deep integration: We package the Tuscany runtime and its dependencies as 
Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat 
is integrated as the Web container for Geronimo). We can then create a 
Tuscany plugin (a collection of modules) so that it can be added to 
Geronimo. The Tuscany container will then handle SCA-specific deployment 
plans to install SCA applications and provide runtime infrastructure for 
them.

On top of Option 2, we could further integrate Geronimo's J2EE capabilities 
such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be 
able to access JEE services (using SCA composite references) and SCA 
components will be able to expose services (SCA composite services) over JEE 
protocols as well.

This will allow us to support the following use cases:
* Any J2EE application hosted by Geronimo would be able to take advantage of 
SCA programming model
* Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
* Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web 
Services) from SCA components

Any thoughts?

Thanks,
Raymond
Apache Tuscany committer 

Re: Geronimo/Tuscany integration

[Vamsavardhana Reddy <c1...@gmail.com>]

Hi,

Myself and Manu have been working on the integration thing.  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/.

Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.
B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo

Some of the questions we have are:
1.  Should we use this plugin approach or intergrate Tuscany to be
bundled as part of the Geronimo distribution?
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?
3.  Where should we maintain the integration code?

Your comments and suggestions will be very helpful.

Thanks and best regards,
Vamsi

On 5/10/07, Manu George <ma...@gmail.com> wrote:
> Hi Raymond/Jay,
>
>       I would like to join this effort. I would like to discuss what
> is expected of the deep integration. I will just list down my
> understanding of both the current and proposed integrations
>
> Understanding of the Current Integration
>
> 1) TuscanyContextListener creates an SCA domain when the servlet is
> created and then destroys it when the servlet is destroyed.
> 2) During SCA domain creation it looks up the composites and deploys
> them in the domain
> Creates a webapp module activator for registering servlet hosts.
> 3) Finally we have a servlet that forwards requests to the servlet
> registered with the Tuscany Servlet Host.
> 4) An SCADomain is created for each application and we can lookup the
> services from the SCADomain.
> 5) During SCADomain creation a runtime is also created for the DefaultSCADomain.
> 7) All tuscany classes are loaded repeatedly for each application in
> separate classloaders.
> 8) A runtime is created per application
>
> Understanding/Doubts about the proposed Integration.
>
> 1) Each SCA application will have an SCA module which will be a jar
> with an SCDL in META-INF. This jar can also be part of an EAR. . There
> will be a Tuscany deployer that will take care of deploying the SCA
> modules. Should WAR files be also able to contain SCA jars?
> 2) Each App will have an SCA Domain which will be instantiated when
> the application starts. Is this assumption correct or can there be
> multiple SCADomains per app?
> 3) The Tuscany classes are loaded only once and then shared between
> the different SCA applications.
> 4) There will be multiple domains instantiated from different
> applications and there should be a server wide domain registry where
> applications can look up and invoke different composites from domains
> different from their own. (Can this be Global JNDI/Gbean refs or is
> there something specific in tuscany).
> 5) There should be only a single Tuscany Runtime for the entire
> geronimo instance.
> 6) How can we lookup the services running in one geronimo instance
> from an app in another geronimo instance. Is this supported in Tuscany
>
> These are just the initial set of points/questions that hit me when I
> thought about the integration. Jay /Raymond I guess you guys will be
> aware of many other points as well. Can you reply with your analysis
> so that we can flesh out the requirements completely in the mailing
> list. That way both the communities can contribute their thoughts. If
> you have already started can you just point me to where I can catch up
> on what has happened?
>
> Thanks
> Manu
>
> On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> > Hi, Geronimo community.
> >
> > As you may know, Tuscany is an Apache project under incubation to provide an
> > open source SOA infrastructure. For more information, you can visit
> > http://cwiki.apache.org/TUSCANY/.
> >
> > Tuscany implements the SCA specification (http://www.osoa.org) and allows
> > you to develop and run SCA components in various hosting environments. We
> > currently integrate with Tomcat and Jetty and would like to try to integrate
> > with Geronimo as well. I would like to start some discussions here to figure
> > out the best way to do that.
> >
> > After some preliminary investigations of Geronimo, I feel that there are two
> > options on the table so far.
> >
> > 1) Shallow integration: Package SCA applications together with the Tuscany
> > runtime as WARs and deploy them Geronimo as Web applications. It's basically
> > the integration with a Web container. We register a TuscanyContextListner
> > (which implements javax.servlet.ServletContextListener) in web.xml to
> > start/stop the Tuscany runtime when the web application is started/stopped.
> >
> > This will allow us to support the following use cases:
> > * A Web application hosted by Geronimo with business logic written as SCA
> > components
> > * Expose one or more SCA components as Web services over HTTP as supported
> > by the Web container.
> >
> > 2) Deep integration: We package the Tuscany runtime and its dependencies as
> > Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat
> > is integrated as the Web container for Geronimo). We can then create a
> > Tuscany plugin (a collection of modules) so that it can be added to
> > Geronimo. The Tuscany container will then handle SCA-specific deployment
> > plans to install SCA applications and provide runtime infrastructure for
> > them.
> >
> > On top of Option 2, we could further integrate Geronimo's J2EE capabilities
> > such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be
> > able to access JEE services (using SCA composite references) and SCA
> > components will be able to expose services (SCA composite services) over JEE
> > protocols as well.
> >
> > This will allow us to support the following use cases:
> > * Any J2EE application hosted by Geronimo would be able to take advantage of
> > SCA programming model
> > * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
> > * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web
> > Services) from SCA components
> >
> > Any thoughts?
> >
> > Thanks,
> > Raymond
> > Apache Tuscany committer
> >
> >
>

Re: Geronimo/Tuscany integration

[Manu George <ma...@gmail.com>]

Hi Jean-Sebastien,
                  Thank you for the very detailed responses and links.
I am still in the process of going through the SCA specs. With my
current understanding I have put in responses inline

On 6/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Raymond is away for one more week, so I'll try to answer some of these
> questions.
>
>
> Manu George wrote:
> > Hi Raymond/Jay,
> >
> >      I would like to join this effort. I would like to discuss what
> > is expected of the deep integration. I will just list down my
> > understanding of both the current and proposed integrations
> >
> > Understanding of the Current Integration
> >
> > 1) TuscanyContextListener creates an SCA domain when the servlet is
> > created and then destroys it when the servlet is destroyed.
> > 2) During SCA domain creation it looks up the composites and deploys
> > them in the domain
> > Creates a webapp module activator for registering servlet hosts.
> > 3) Finally we have a servlet that forwards requests to the servlet
> > registered with the Tuscany Servlet Host.
> > 4) An SCADomain is created for each application and we can lookup the
> > services from the SCADomain.
> > 5) During SCADomain creation a runtime is also created for the
> > DefaultSCADomain.
> > 7) All tuscany classes are loaded repeatedly for each application in
> > separate classloaders.
> > 8) A runtime is created per application
>
> Correct. I'm assuming that you're talking about the current Webapp
> integration.
>
Thanks for the clarification

> As a heads up the SCADomain class is probably going to change a bit to
> load a subset of components deployed to an actual SCA domain. The idea
> is to distribute an SCA domain across runtimes, each runtime running one
> or more domain level SCA components (and components nested in their
> composites).
>

I believe there is functionality being added to even add composites to
already initialized Domains. Probably we need to leverage that also in
the future.

> >
> > Understanding/Doubts about the proposed Integration.
> >
> > 1) Each SCA application will have an SCA module which will be a jar
> > with an SCDL in META-INF. This jar can also be part of an EAR. . There
> > will be a Tuscany deployer that will take care of deploying the SCA
> > modules. Should WAR files be also able to contain SCA jars?
>
> Will the application developer be exposed to this? If it's the case then
> it looks like a new programming / packaging  model, different from SCA :)
>
We changed that approach :) but still we have a geronimo-tuscany.xml
file in META-INF.xml.

> An SCA application developer normally packages application artifacts in
> an SCA contribution (a form of archive described in the SCA assembly
> spec) and the .composite (SCDL) files are not necessarily under
> META-INF. in fact usually we place them with the other development
> artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application
> developer wouldn't have to learn a different packaging model to run his
> SCA components on Geronimo. Will there be a way to deploy an SCA
> contribution to Geronimo "natively" without having to repackage it in a
> J2EE archive?

>From what I understood from the SCA Assembly spec, a jar can be one of
the ways an SCA Contribution can be packaged. So ideally a jar which
has tuscany artifacts should be deployable in Geronimo. There are
other contributions like folder contribution etc. But I guess
initially we can build in support for jar/zip file contribution. In
the current POC we have a geronimo-tuscany.xml in META-INF. The SCDLs
are packaged as per SCA assembly specs. The geronimo-tuscany.xml was
used to specify the jndi name to which the SCA Domain was bound to as
well as the Domain URI. We were not sure how to generate the Domain
URI for an SCADomain deployed in Geronimo. Some suggestions here would
be welcome. I guess we may be able to remove the geronimo-tuscany.xml
if we need not bind the domain in JNDI. Now on reading the integration
whitepaper, JEE artifacts will be able to access the services by
exposing the JEE module as a contribution and declaring the services
as references in the JEE artifacts. So probably the proxies to
services can be bound in jndi.

>
> > 2) Each App will have an SCA Domain which will be instantiated when
> > the application starts. Is this assumption correct or can there be
> > multiple SCADomains per app?
>
> The objects deployed to an SCA domain and which run on an SCA runtime
> are SCA components. There is no concept of an App like a J2EE App in SCA
> at the moment.
>
> Components can be implemented by a simple Java class, a BPEL process, a
> script, etc. or a Composite. A Composite describes an assembly of
> Components, allowing for nested composition of components. An SCA domain
> is described by a composite, describing the assembly of top level
> components in an administration domain. The SCA domain composite does
> not necessarily have to written to a single .composite file since it has
> to be distributed, but it is effectively modeled as a composite.
>
> So to go back to your question, objects that run on an SCA runtime are
> SCA components, and each component belongs to a single SCA Domain composite.
>
> Now with respect to instances of the SCADomain class, I was thinking
> about two options:
>
> (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.
>

By option (a) Do you mean One SCA Domain per Contribution? Since a
number of components can be there in a contribution and they can all
be in the same SCADomain.
For eg: If i deploy a jar containing a few composites, a new SCADomain
is created and they are added to the SCADomain. This is the status of
the POC as it is now.
As per the whitepaper each application will have a corresponding
application composite. Nothing is mentioned about domains and so i
guess there is no correlation between domains and applications. i.e. n
applications may be exposed as application composites in an SCADomain
and another m applications in another SCADomain. Is this assumption
correct?

Regarding information about the peer composites won't that be provided
in the scdl files of the composites?

> > 3) The Tuscany classes are loaded only once and then shared between
> > the different SCA applications.
>
> +1
>
> > 4) There will be multiple domains instantiated from different
> > applications and there should be a server wide domain registry where
> > applications can look up and invoke different composites from domains
> > different from their own. (Can this be Global JNDI/Gbean refs or is
> > there something specific in tuscany).
>
> An SCA domain is a domain of administration typically containing
> multiple servers. Wiring and lookups are assumed to work within the
> context of a single domain. We could imagine a Geronimo server hosting
> components from multiple SCA administration domains, but I'm not sure
> that it's going to be a very common scenario.
>
What I meant here was how will a JEE artifact, say a jsp, access the
SCADomain and hence the services inside. Can we store SCADomain
references in jndi for lookup by JEE artifacts? The J2EE integration
whitepaper gives an approach for this for webmodules and ejb modules
and so we will go with that approach.

> > 5) There should be only a single Tuscany Runtime for the entire
> > geronimo instance.
>
> It if helps, sure. If on the other hand it complicates things we can
> also have multiple runtime instances. Multiple lightweight runtime
> instances may be easier to handle than a single more complicated one.
>
It will be simpler to go with multiple runtimes for now. Once we get
the functionality working we can think about further refinement.

> > 6) How can we lookup the services running in one geronimo instance
> > from an app in another geronimo instance. Is this supported in Tuscany
> >
>
> This looks like the distributed domain deployment that we need to
> support in Tuscany in general. Two runtimes R1 and R2, running on two
> different machines, access the SCA composite model describing an SCA
> domain. Runtime R1 runs component CA, runtime R2 runs component CB. CA
> has an SCA reference wired to CB.
>
> We are starting to work on this in Tuscany, along the lines of what I've
> described above in my answer to your question (2).
>
> Here are some pointers to related discussions on the Tuscany wiki and
> the tuscany-dev list:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18879.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19105.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18954.html
>

Thanks I will have a look at this.

> > These are just the initial set of points/questions that hit me when I
> > thought about the integration. Jay /Raymond I guess you guys will be
> > aware of many other points as well. Can you reply with your analysis
> > so that we can flesh out the requirements completely in the mailing
> > list. That way both the communities can contribute their thoughts. If
> > you have already started can you just point me to where I can catch up
> > on what has happened?
> >
> > Thanks
> > Manu
> >
> > On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> >> Hi, Geronimo community.
> >>
> >> As you may know, Tuscany is an Apache project under incubation to
> >> provide an
> >> open source SOA infrastructure. For more information, you can visit
> >> http://cwiki.apache.org/TUSCANY/.
> >>
> >> Tuscany implements the SCA specification (http://www.osoa.org) and
> >> allows
> >> you to develop and run SCA components in various hosting
> >> environments. We
> >> currently integrate with Tomcat and Jetty and would like to try to
> >> integrate
> >> with Geronimo as well. I would like to start some discussions here to
> >> figure
> >> out the best way to do that.
> >>
> >> After some preliminary investigations of Geronimo, I feel that there
> >> are two
> >> options on the table so far.
> >>
> >> 1) Shallow integration: Package SCA applications together with the
> >> Tuscany
> >> runtime as WARs and deploy them Geronimo as Web applications. It's
> >> basically
> >> the integration with a Web container. We register a
> >> TuscanyContextListner
> >> (which implements javax.servlet.ServletContextListener) in web.xml to
> >> start/stop the Tuscany runtime when the web application is
> >> started/stopped.
> >>
> >> This will allow us to support the following use cases:
> >> * A Web application hosted by Geronimo with business logic written as
> >> SCA
> >> components
> >> * Expose one or more SCA components as Web services over HTTP as
> >> supported
> >> by the Web container.
> >>
> >> 2) Deep integration: We package the Tuscany runtime and its
> >> dependencies as
> >> Geronimo modules and deploy them to Geronimo (which is similar to how
> >> Tomcat
> >> is integrated as the Web container for Geronimo). We can then create a
> >> Tuscany plugin (a collection of modules) so that it can be added to
> >> Geronimo. The Tuscany container will then handle SCA-specific deployment
> >> plans to install SCA applications and provide runtime infrastructure for
> >> them.
> >>
> >> On top of Option 2, we could further integrate Geronimo's J2EE
> >> capabilities
> >> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components
> >> will be
> >> able to access JEE services (using SCA composite references) and SCA
> >> components will be able to expose services (SCA composite services)
> >> over JEE
> >> protocols as well.
> >>
> >> This will allow us to support the following use cases:
> >> * Any J2EE application hosted by Geronimo would be able to take
> >> advantage of
> >> SCA programming model
> >> * Provide SCA services over various protocols such as RMI/IIOP, JMS
> >> and JCA
> >> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS
> >> or Web
> >> Services) from SCA components
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Raymond
> >> Apache Tuscany committer
> >>
> >>
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


Thanks again Jean-Sebastien.

Regards
Manu

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Geronimo/Tuscany integration

[Manu George <ma...@gmail.com>]

Hi Jean-Sebastien,
                  Thank you for the very detailed responses and links.
I am still in the process of going through the SCA specs. With my
current understanding I have put in responses inline

On 6/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Raymond is away for one more week, so I'll try to answer some of these
> questions.
>
>
> Manu George wrote:
> > Hi Raymond/Jay,
> >
> >      I would like to join this effort. I would like to discuss what
> > is expected of the deep integration. I will just list down my
> > understanding of both the current and proposed integrations
> >
> > Understanding of the Current Integration
> >
> > 1) TuscanyContextListener creates an SCA domain when the servlet is
> > created and then destroys it when the servlet is destroyed.
> > 2) During SCA domain creation it looks up the composites and deploys
> > them in the domain
> > Creates a webapp module activator for registering servlet hosts.
> > 3) Finally we have a servlet that forwards requests to the servlet
> > registered with the Tuscany Servlet Host.
> > 4) An SCADomain is created for each application and we can lookup the
> > services from the SCADomain.
> > 5) During SCADomain creation a runtime is also created for the
> > DefaultSCADomain.
> > 7) All tuscany classes are loaded repeatedly for each application in
> > separate classloaders.
> > 8) A runtime is created per application
>
> Correct. I'm assuming that you're talking about the current Webapp
> integration.
>
Thanks for the clarification

> As a heads up the SCADomain class is probably going to change a bit to
> load a subset of components deployed to an actual SCA domain. The idea
> is to distribute an SCA domain across runtimes, each runtime running one
> or more domain level SCA components (and components nested in their
> composites).
>

I believe there is functionality being added to even add composites to
already initialized Domains. Probably we need to leverage that also in
the future.

> >
> > Understanding/Doubts about the proposed Integration.
> >
> > 1) Each SCA application will have an SCA module which will be a jar
> > with an SCDL in META-INF. This jar can also be part of an EAR. . There
> > will be a Tuscany deployer that will take care of deploying the SCA
> > modules. Should WAR files be also able to contain SCA jars?
>
> Will the application developer be exposed to this? If it's the case then
> it looks like a new programming / packaging  model, different from SCA :)
>
We changed that approach :) but still we have a geronimo-tuscany.xml
file in META-INF.xml.

> An SCA application developer normally packages application artifacts in
> an SCA contribution (a form of archive described in the SCA assembly
> spec) and the .composite (SCDL) files are not necessarily under
> META-INF. in fact usually we place them with the other development
> artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application
> developer wouldn't have to learn a different packaging model to run his
> SCA components on Geronimo. Will there be a way to deploy an SCA
> contribution to Geronimo "natively" without having to repackage it in a
> J2EE archive?

>From what I understood from the SCA Assembly spec, a jar can be one of
the ways an SCA Contribution can be packaged. So ideally a jar which
has tuscany artifacts should be deployable in Geronimo. There are
other contributions like folder contribution etc. But I guess
initially we can build in support for jar/zip file contribution. In
the current POC we have a geronimo-tuscany.xml in META-INF. The SCDLs
are packaged as per SCA assembly specs. The geronimo-tuscany.xml was
used to specify the jndi name to which the SCA Domain was bound to as
well as the Domain URI. We were not sure how to generate the Domain
URI for an SCADomain deployed in Geronimo. Some suggestions here would
be welcome. I guess we may be able to remove the geronimo-tuscany.xml
if we need not bind the domain in JNDI. Now on reading the integration
whitepaper, JEE artifacts will be able to access the services by
exposing the JEE module as a contribution and declaring the services
as references in the JEE artifacts. So probably the proxies to
services can be bound in jndi.

>
> > 2) Each App will have an SCA Domain which will be instantiated when
> > the application starts. Is this assumption correct or can there be
> > multiple SCADomains per app?
>
> The objects deployed to an SCA domain and which run on an SCA runtime
> are SCA components. There is no concept of an App like a J2EE App in SCA
> at the moment.
>
> Components can be implemented by a simple Java class, a BPEL process, a
> script, etc. or a Composite. A Composite describes an assembly of
> Components, allowing for nested composition of components. An SCA domain
> is described by a composite, describing the assembly of top level
> components in an administration domain. The SCA domain composite does
> not necessarily have to written to a single .composite file since it has
> to be distributed, but it is effectively modeled as a composite.
>
> So to go back to your question, objects that run on an SCA runtime are
> SCA components, and each component belongs to a single SCA Domain composite.
>
> Now with respect to instances of the SCADomain class, I was thinking
> about two options:
>
> (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.
>

By option (a) Do you mean One SCA Domain per Contribution? Since a
number of components can be there in a contribution and they can all
be in the same SCADomain.
For eg: If i deploy a jar containing a few composites, a new SCADomain
is created and they are added to the SCADomain. This is the status of
the POC as it is now.
As per the whitepaper each application will have a corresponding
application composite. Nothing is mentioned about domains and so i
guess there is no correlation between domains and applications. i.e. n
applications may be exposed as application composites in an SCADomain
and another m applications in another SCADomain. Is this assumption
correct?

Regarding information about the peer composites won't that be provided
in the scdl files of the composites?

> > 3) The Tuscany classes are loaded only once and then shared between
> > the different SCA applications.
>
> +1
>
> > 4) There will be multiple domains instantiated from different
> > applications and there should be a server wide domain registry where
> > applications can look up and invoke different composites from domains
> > different from their own. (Can this be Global JNDI/Gbean refs or is
> > there something specific in tuscany).
>
> An SCA domain is a domain of administration typically containing
> multiple servers. Wiring and lookups are assumed to work within the
> context of a single domain. We could imagine a Geronimo server hosting
> components from multiple SCA administration domains, but I'm not sure
> that it's going to be a very common scenario.
>
What I meant here was how will a JEE artifact, say a jsp, access the
SCADomain and hence the services inside. Can we store SCADomain
references in jndi for lookup by JEE artifacts? The J2EE integration
whitepaper gives an approach for this for webmodules and ejb modules
and so we will go with that approach.

> > 5) There should be only a single Tuscany Runtime for the entire
> > geronimo instance.
>
> It if helps, sure. If on the other hand it complicates things we can
> also have multiple runtime instances. Multiple lightweight runtime
> instances may be easier to handle than a single more complicated one.
>
It will be simpler to go with multiple runtimes for now. Once we get
the functionality working we can think about further refinement.

> > 6) How can we lookup the services running in one geronimo instance
> > from an app in another geronimo instance. Is this supported in Tuscany
> >
>
> This looks like the distributed domain deployment that we need to
> support in Tuscany in general. Two runtimes R1 and R2, running on two
> different machines, access the SCA composite model describing an SCA
> domain. Runtime R1 runs component CA, runtime R2 runs component CB. CA
> has an SCA reference wired to CB.
>
> We are starting to work on this in Tuscany, along the lines of what I've
> described above in my answer to your question (2).
>
> Here are some pointers to related discussions on the Tuscany wiki and
> the tuscany-dev list:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18879.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19105.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18954.html
>

Thanks I will have a look at this.

> > These are just the initial set of points/questions that hit me when I
> > thought about the integration. Jay /Raymond I guess you guys will be
> > aware of many other points as well. Can you reply with your analysis
> > so that we can flesh out the requirements completely in the mailing
> > list. That way both the communities can contribute their thoughts. If
> > you have already started can you just point me to where I can catch up
> > on what has happened?
> >
> > Thanks
> > Manu
> >
> > On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> >> Hi, Geronimo community.
> >>
> >> As you may know, Tuscany is an Apache project under incubation to
> >> provide an
> >> open source SOA infrastructure. For more information, you can visit
> >> http://cwiki.apache.org/TUSCANY/.
> >>
> >> Tuscany implements the SCA specification (http://www.osoa.org) and
> >> allows
> >> you to develop and run SCA components in various hosting
> >> environments. We
> >> currently integrate with Tomcat and Jetty and would like to try to
> >> integrate
> >> with Geronimo as well. I would like to start some discussions here to
> >> figure
> >> out the best way to do that.
> >>
> >> After some preliminary investigations of Geronimo, I feel that there
> >> are two
> >> options on the table so far.
> >>
> >> 1) Shallow integration: Package SCA applications together with the
> >> Tuscany
> >> runtime as WARs and deploy them Geronimo as Web applications. It's
> >> basically
> >> the integration with a Web container. We register a
> >> TuscanyContextListner
> >> (which implements javax.servlet.ServletContextListener) in web.xml to
> >> start/stop the Tuscany runtime when the web application is
> >> started/stopped.
> >>
> >> This will allow us to support the following use cases:
> >> * A Web application hosted by Geronimo with business logic written as
> >> SCA
> >> components
> >> * Expose one or more SCA components as Web services over HTTP as
> >> supported
> >> by the Web container.
> >>
> >> 2) Deep integration: We package the Tuscany runtime and its
> >> dependencies as
> >> Geronimo modules and deploy them to Geronimo (which is similar to how
> >> Tomcat
> >> is integrated as the Web container for Geronimo). We can then create a
> >> Tuscany plugin (a collection of modules) so that it can be added to
> >> Geronimo. The Tuscany container will then handle SCA-specific deployment
> >> plans to install SCA applications and provide runtime infrastructure for
> >> them.
> >>
> >> On top of Option 2, we could further integrate Geronimo's J2EE
> >> capabilities
> >> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components
> >> will be
> >> able to access JEE services (using SCA composite references) and SCA
> >> components will be able to expose services (SCA composite services)
> >> over JEE
> >> protocols as well.
> >>
> >> This will allow us to support the following use cases:
> >> * Any J2EE application hosted by Geronimo would be able to take
> >> advantage of
> >> SCA programming model
> >> * Provide SCA services over various protocols such as RMI/IIOP, JMS
> >> and JCA
> >> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS
> >> or Web
> >> Services) from SCA components
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Raymond
> >> Apache Tuscany committer
> >>
> >>
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


Thanks again Jean-Sebastien.

Regards
Manu

Re: Geronimo/Tuscany integration

[Jean-Sebastien Delfino <js...@apache.org>]

Raymond is away for one more week, so I'll try to answer some of these 
questions.


Manu George wrote:
> Hi Raymond/Jay,
>
>      I would like to join this effort. I would like to discuss what
> is expected of the deep integration. I will just list down my
> understanding of both the current and proposed integrations
>
> Understanding of the Current Integration
>
> 1) TuscanyContextListener creates an SCA domain when the servlet is
> created and then destroys it when the servlet is destroyed.
> 2) During SCA domain creation it looks up the composites and deploys
> them in the domain
> Creates a webapp module activator for registering servlet hosts.
> 3) Finally we have a servlet that forwards requests to the servlet
> registered with the Tuscany Servlet Host.
> 4) An SCADomain is created for each application and we can lookup the
> services from the SCADomain.
> 5) During SCADomain creation a runtime is also created for the 
> DefaultSCADomain.
> 7) All tuscany classes are loaded repeatedly for each application in
> separate classloaders.
> 8) A runtime is created per application

Correct. I'm assuming that you're talking about the current Webapp 
integration.

As a heads up the SCADomain class is probably going to change a bit to 
load a subset of components deployed to an actual SCA domain. The idea 
is to distribute an SCA domain across runtimes, each runtime running one 
or more domain level SCA components (and components nested in their 
composites).

>
> Understanding/Doubts about the proposed Integration.
>
> 1) Each SCA application will have an SCA module which will be a jar
> with an SCDL in META-INF. This jar can also be part of an EAR. . There
> will be a Tuscany deployer that will take care of deploying the SCA
> modules. Should WAR files be also able to contain SCA jars?

Will the application developer be exposed to this? If it's the case then 
it looks like a new programming / packaging  model, different from SCA :)

An SCA application developer normally packages application artifacts in 
an SCA contribution (a form of archive described in the SCA assembly 
spec) and the .composite (SCDL) files are not necessarily under 
META-INF. in fact usually we place them with the other development 
artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application 
developer wouldn't have to learn a different packaging model to run his 
SCA components on Geronimo. Will there be a way to deploy an SCA 
contribution to Geronimo "natively" without having to repackage it in a 
J2EE archive?
 
> 2) Each App will have an SCA Domain which will be instantiated when
> the application starts. Is this assumption correct or can there be
> multiple SCADomains per app?

The objects deployed to an SCA domain and which run on an SCA runtime 
are SCA components. There is no concept of an App like a J2EE App in SCA 
at the moment.

Components can be implemented by a simple Java class, a BPEL process, a 
script, etc. or a Composite. A Composite describes an assembly of 
Components, allowing for nested composition of components. An SCA domain 
is described by a composite, describing the assembly of top level 
components in an administration domain. The SCA domain composite does 
not necessarily have to written to a single .composite file since it has 
to be distributed, but it is effectively modeled as a composite.

So to go back to your question, objects that run on an SCA runtime are 
SCA components, and each component belongs to a single SCA Domain composite.

Now with respect to instances of the SCADomain class, I was thinking 
about two options:

(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.

> 3) The Tuscany classes are loaded only once and then shared between
> the different SCA applications.

+1

> 4) There will be multiple domains instantiated from different
> applications and there should be a server wide domain registry where
> applications can look up and invoke different composites from domains
> different from their own. (Can this be Global JNDI/Gbean refs or is
> there something specific in tuscany).

An SCA domain is a domain of administration typically containing 
multiple servers. Wiring and lookups are assumed to work within the 
context of a single domain. We could imagine a Geronimo server hosting 
components from multiple SCA administration domains, but I'm not sure 
that it's going to be a very common scenario.

> 5) There should be only a single Tuscany Runtime for the entire
> geronimo instance.

It if helps, sure. If on the other hand it complicates things we can 
also have multiple runtime instances. Multiple lightweight runtime 
instances may be easier to handle than a single more complicated one.

> 6) How can we lookup the services running in one geronimo instance
> from an app in another geronimo instance. Is this supported in Tuscany
>

This looks like the distributed domain deployment that we need to 
support in Tuscany in general. Two runtimes R1 and R2, running on two 
different machines, access the SCA composite model describing an SCA 
domain. Runtime R1 runs component CA, runtime R2 runs component CB. CA 
has an SCA reference wired to CB.

We are starting to work on this in Tuscany, along the lines of what I've 
described above in my answer to your question (2).

Here are some pointers to related discussions on the Tuscany wiki and 
the tuscany-dev list:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18879.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19105.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18954.html

> These are just the initial set of points/questions that hit me when I
> thought about the integration. Jay /Raymond I guess you guys will be
> aware of many other points as well. Can you reply with your analysis
> so that we can flesh out the requirements completely in the mailing
> list. That way both the communities can contribute their thoughts. If
> you have already started can you just point me to where I can catch up
> on what has happened?
>
> Thanks
> Manu
>
> On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
>> Hi, Geronimo community.
>>
>> As you may know, Tuscany is an Apache project under incubation to 
>> provide an
>> open source SOA infrastructure. For more information, you can visit
>> http://cwiki.apache.org/TUSCANY/.
>>
>> Tuscany implements the SCA specification (http://www.osoa.org) and 
>> allows
>> you to develop and run SCA components in various hosting 
>> environments. We
>> currently integrate with Tomcat and Jetty and would like to try to 
>> integrate
>> with Geronimo as well. I would like to start some discussions here to 
>> figure
>> out the best way to do that.
>>
>> After some preliminary investigations of Geronimo, I feel that there 
>> are two
>> options on the table so far.
>>
>> 1) Shallow integration: Package SCA applications together with the 
>> Tuscany
>> runtime as WARs and deploy them Geronimo as Web applications. It's 
>> basically
>> the integration with a Web container. We register a 
>> TuscanyContextListner
>> (which implements javax.servlet.ServletContextListener) in web.xml to
>> start/stop the Tuscany runtime when the web application is 
>> started/stopped.
>>
>> This will allow us to support the following use cases:
>> * A Web application hosted by Geronimo with business logic written as 
>> SCA
>> components
>> * Expose one or more SCA components as Web services over HTTP as 
>> supported
>> by the Web container.
>>
>> 2) Deep integration: We package the Tuscany runtime and its 
>> dependencies as
>> Geronimo modules and deploy them to Geronimo (which is similar to how 
>> Tomcat
>> is integrated as the Web container for Geronimo). We can then create a
>> Tuscany plugin (a collection of modules) so that it can be added to
>> Geronimo. The Tuscany container will then handle SCA-specific deployment
>> plans to install SCA applications and provide runtime infrastructure for
>> them.
>>
>> On top of Option 2, we could further integrate Geronimo's J2EE 
>> capabilities
>> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components 
>> will be
>> able to access JEE services (using SCA composite references) and SCA
>> components will be able to expose services (SCA composite services) 
>> over JEE
>> protocols as well.
>>
>> This will allow us to support the following use cases:
>> * Any J2EE application hosted by Geronimo would be able to take 
>> advantage of
>> SCA programming model
>> * Provide SCA services over various protocols such as RMI/IIOP, JMS 
>> and JCA
>> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS 
>> or Web
>> Services) from SCA components
>>
>> Any thoughts?
>>
>> Thanks,
>> Raymond
>> Apache Tuscany committer
>>
>>
>


-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Geronimo/Tuscany integration

[Jean-Sebastien Delfino <js...@apache.org>]

Raymond is away for one more week, so I'll try to answer some of these 
questions.


Manu George wrote:
> Hi Raymond/Jay,
>
>      I would like to join this effort. I would like to discuss what
> is expected of the deep integration. I will just list down my
> understanding of both the current and proposed integrations
>
> Understanding of the Current Integration
>
> 1) TuscanyContextListener creates an SCA domain when the servlet is
> created and then destroys it when the servlet is destroyed.
> 2) During SCA domain creation it looks up the composites and deploys
> them in the domain
> Creates a webapp module activator for registering servlet hosts.
> 3) Finally we have a servlet that forwards requests to the servlet
> registered with the Tuscany Servlet Host.
> 4) An SCADomain is created for each application and we can lookup the
> services from the SCADomain.
> 5) During SCADomain creation a runtime is also created for the 
> DefaultSCADomain.
> 7) All tuscany classes are loaded repeatedly for each application in
> separate classloaders.
> 8) A runtime is created per application

Correct. I'm assuming that you're talking about the current Webapp 
integration.

As a heads up the SCADomain class is probably going to change a bit to 
load a subset of components deployed to an actual SCA domain. The idea 
is to distribute an SCA domain across runtimes, each runtime running one 
or more domain level SCA components (and components nested in their 
composites).

>
> Understanding/Doubts about the proposed Integration.
>
> 1) Each SCA application will have an SCA module which will be a jar
> with an SCDL in META-INF. This jar can also be part of an EAR. . There
> will be a Tuscany deployer that will take care of deploying the SCA
> modules. Should WAR files be also able to contain SCA jars?

Will the application developer be exposed to this? If it's the case then 
it looks like a new programming / packaging  model, different from SCA :)

An SCA application developer normally packages application artifacts in 
an SCA contribution (a form of archive described in the SCA assembly 
spec) and the .composite (SCDL) files are not necessarily under 
META-INF. in fact usually we place them with the other development 
artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application 
developer wouldn't have to learn a different packaging model to run his 
SCA components on Geronimo. Will there be a way to deploy an SCA 
contribution to Geronimo "natively" without having to repackage it in a 
J2EE archive?
 
> 2) Each App will have an SCA Domain which will be instantiated when
> the application starts. Is this assumption correct or can there be
> multiple SCADomains per app?

The objects deployed to an SCA domain and which run on an SCA runtime 
are SCA components. There is no concept of an App like a J2EE App in SCA 
at the moment.

Components can be implemented by a simple Java class, a BPEL process, a 
script, etc. or a Composite. A Composite describes an assembly of 
Components, allowing for nested composition of components. An SCA domain 
is described by a composite, describing the assembly of top level 
components in an administration domain. The SCA domain composite does 
not necessarily have to written to a single .composite file since it has 
to be distributed, but it is effectively modeled as a composite.

So to go back to your question, objects that run on an SCA runtime are 
SCA components, and each component belongs to a single SCA Domain composite.

Now with respect to instances of the SCADomain class, I was thinking 
about two options:

(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.

> 3) The Tuscany classes are loaded only once and then shared between
> the different SCA applications.

+1

> 4) There will be multiple domains instantiated from different
> applications and there should be a server wide domain registry where
> applications can look up and invoke different composites from domains
> different from their own. (Can this be Global JNDI/Gbean refs or is
> there something specific in tuscany).

An SCA domain is a domain of administration typically containing 
multiple servers. Wiring and lookups are assumed to work within the 
context of a single domain. We could imagine a Geronimo server hosting 
components from multiple SCA administration domains, but I'm not sure 
that it's going to be a very common scenario.

> 5) There should be only a single Tuscany Runtime for the entire
> geronimo instance.

It if helps, sure. If on the other hand it complicates things we can 
also have multiple runtime instances. Multiple lightweight runtime 
instances may be easier to handle than a single more complicated one.

> 6) How can we lookup the services running in one geronimo instance
> from an app in another geronimo instance. Is this supported in Tuscany
>

This looks like the distributed domain deployment that we need to 
support in Tuscany in general. Two runtimes R1 and R2, running on two 
different machines, access the SCA composite model describing an SCA 
domain. Runtime R1 runs component CA, runtime R2 runs component CB. CA 
has an SCA reference wired to CB.

We are starting to work on this in Tuscany, along the lines of what I've 
described above in my answer to your question (2).

Here are some pointers to related discussions on the Tuscany wiki and 
the tuscany-dev list:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18879.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19105.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18954.html

> These are just the initial set of points/questions that hit me when I
> thought about the integration. Jay /Raymond I guess you guys will be
> aware of many other points as well. Can you reply with your analysis
> so that we can flesh out the requirements completely in the mailing
> list. That way both the communities can contribute their thoughts. If
> you have already started can you just point me to where I can catch up
> on what has happened?
>
> Thanks
> Manu
>
> On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
>> Hi, Geronimo community.
>>
>> As you may know, Tuscany is an Apache project under incubation to 
>> provide an
>> open source SOA infrastructure. For more information, you can visit
>> http://cwiki.apache.org/TUSCANY/.
>>
>> Tuscany implements the SCA specification (http://www.osoa.org) and 
>> allows
>> you to develop and run SCA components in various hosting 
>> environments. We
>> currently integrate with Tomcat and Jetty and would like to try to 
>> integrate
>> with Geronimo as well. I would like to start some discussions here to 
>> figure
>> out the best way to do that.
>>
>> After some preliminary investigations of Geronimo, I feel that there 
>> are two
>> options on the table so far.
>>
>> 1) Shallow integration: Package SCA applications together with the 
>> Tuscany
>> runtime as WARs and deploy them Geronimo as Web applications. It's 
>> basically
>> the integration with a Web container. We register a 
>> TuscanyContextListner
>> (which implements javax.servlet.ServletContextListener) in web.xml to
>> start/stop the Tuscany runtime when the web application is 
>> started/stopped.
>>
>> This will allow us to support the following use cases:
>> * A Web application hosted by Geronimo with business logic written as 
>> SCA
>> components
>> * Expose one or more SCA components as Web services over HTTP as 
>> supported
>> by the Web container.
>>
>> 2) Deep integration: We package the Tuscany runtime and its 
>> dependencies as
>> Geronimo modules and deploy them to Geronimo (which is similar to how 
>> Tomcat
>> is integrated as the Web container for Geronimo). We can then create a
>> Tuscany plugin (a collection of modules) so that it can be added to
>> Geronimo. The Tuscany container will then handle SCA-specific deployment
>> plans to install SCA applications and provide runtime infrastructure for
>> them.
>>
>> On top of Option 2, we could further integrate Geronimo's J2EE 
>> capabilities
>> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components 
>> will be
>> able to access JEE services (using SCA composite references) and SCA
>> components will be able to expose services (SCA composite services) 
>> over JEE
>> protocols as well.
>>
>> This will allow us to support the following use cases:
>> * Any J2EE application hosted by Geronimo would be able to take 
>> advantage of
>> SCA programming model
>> * Provide SCA services over various protocols such as RMI/IIOP, JMS 
>> and JCA
>> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS 
>> or Web
>> Services) from SCA components
>>
>> Any thoughts?
>>
>> Thanks,
>> Raymond
>> Apache Tuscany committer
>>
>>
>


-- 
Jean-Sebastien

Re: Geronimo/Tuscany integration

[Vamsavardhana Reddy <c1...@gmail.com>]

Hi,

Myself and Manu have been working on the integration thing.  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/.

Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.
B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo

Some of the questions we have are:
1.  Should we use this plugin approach or intergrate Tuscany to be
bundled as part of the Geronimo distribution?
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?
3.  Where should we maintain the integration code?

Your comments and suggestions will be very helpful.

Thanks and best regards,
Vamsi

On 5/10/07, Manu George <ma...@gmail.com> wrote:
> Hi Raymond/Jay,
>
>       I would like to join this effort. I would like to discuss what
> is expected of the deep integration. I will just list down my
> understanding of both the current and proposed integrations
>
> Understanding of the Current Integration
>
> 1) TuscanyContextListener creates an SCA domain when the servlet is
> created and then destroys it when the servlet is destroyed.
> 2) During SCA domain creation it looks up the composites and deploys
> them in the domain
> Creates a webapp module activator for registering servlet hosts.
> 3) Finally we have a servlet that forwards requests to the servlet
> registered with the Tuscany Servlet Host.
> 4) An SCADomain is created for each application and we can lookup the
> services from the SCADomain.
> 5) During SCADomain creation a runtime is also created for the DefaultSCADomain.
> 7) All tuscany classes are loaded repeatedly for each application in
> separate classloaders.
> 8) A runtime is created per application
>
> Understanding/Doubts about the proposed Integration.
>
> 1) Each SCA application will have an SCA module which will be a jar
> with an SCDL in META-INF. This jar can also be part of an EAR. . There
> will be a Tuscany deployer that will take care of deploying the SCA
> modules. Should WAR files be also able to contain SCA jars?
> 2) Each App will have an SCA Domain which will be instantiated when
> the application starts. Is this assumption correct or can there be
> multiple SCADomains per app?
> 3) The Tuscany classes are loaded only once and then shared between
> the different SCA applications.
> 4) There will be multiple domains instantiated from different
> applications and there should be a server wide domain registry where
> applications can look up and invoke different composites from domains
> different from their own. (Can this be Global JNDI/Gbean refs or is
> there something specific in tuscany).
> 5) There should be only a single Tuscany Runtime for the entire
> geronimo instance.
> 6) How can we lookup the services running in one geronimo instance
> from an app in another geronimo instance. Is this supported in Tuscany
>
> These are just the initial set of points/questions that hit me when I
> thought about the integration. Jay /Raymond I guess you guys will be
> aware of many other points as well. Can you reply with your analysis
> so that we can flesh out the requirements completely in the mailing
> list. That way both the communities can contribute their thoughts. If
> you have already started can you just point me to where I can catch up
> on what has happened?
>
> Thanks
> Manu
>
> On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> > Hi, Geronimo community.
> >
> > As you may know, Tuscany is an Apache project under incubation to provide an
> > open source SOA infrastructure. For more information, you can visit
> > http://cwiki.apache.org/TUSCANY/.
> >
> > Tuscany implements the SCA specification (http://www.osoa.org) and allows
> > you to develop and run SCA components in various hosting environments. We
> > currently integrate with Tomcat and Jetty and would like to try to integrate
> > with Geronimo as well. I would like to start some discussions here to figure
> > out the best way to do that.
> >
> > After some preliminary investigations of Geronimo, I feel that there are two
> > options on the table so far.
> >
> > 1) Shallow integration: Package SCA applications together with the Tuscany
> > runtime as WARs and deploy them Geronimo as Web applications. It's basically
> > the integration with a Web container. We register a TuscanyContextListner
> > (which implements javax.servlet.ServletContextListener) in web.xml to
> > start/stop the Tuscany runtime when the web application is started/stopped.
> >
> > This will allow us to support the following use cases:
> > * A Web application hosted by Geronimo with business logic written as SCA
> > components
> > * Expose one or more SCA components as Web services over HTTP as supported
> > by the Web container.
> >
> > 2) Deep integration: We package the Tuscany runtime and its dependencies as
> > Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat
> > is integrated as the Web container for Geronimo). We can then create a
> > Tuscany plugin (a collection of modules) so that it can be added to
> > Geronimo. The Tuscany container will then handle SCA-specific deployment
> > plans to install SCA applications and provide runtime infrastructure for
> > them.
> >
> > On top of Option 2, we could further integrate Geronimo's J2EE capabilities
> > such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be
> > able to access JEE services (using SCA composite references) and SCA
> > components will be able to expose services (SCA composite services) over JEE
> > protocols as well.
> >
> > This will allow us to support the following use cases:
> > * Any J2EE application hosted by Geronimo would be able to take advantage of
> > SCA programming model
> > * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
> > * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web
> > Services) from SCA components
> >
> > Any thoughts?
> >
> > Thanks,
> > Raymond
> > Apache Tuscany committer
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Geronimo/Tuscany integration

[Manu George <ma...@gmail.com>]

Hi Raymond/Jay,

      I would like to join this effort. I would like to discuss what
is expected of the deep integration. I will just list down my
understanding of both the current and proposed integrations

Understanding of the Current Integration

1) TuscanyContextListener creates an SCA domain when the servlet is
created and then destroys it when the servlet is destroyed.
2) During SCA domain creation it looks up the composites and deploys
them in the domain
Creates a webapp module activator for registering servlet hosts.
3) Finally we have a servlet that forwards requests to the servlet
registered with the Tuscany Servlet Host.
4) An SCADomain is created for each application and we can lookup the
services from the SCADomain.
5) During SCADomain creation a runtime is also created for the DefaultSCADomain.
7) All tuscany classes are loaded repeatedly for each application in
separate classloaders.
8) A runtime is created per application

Understanding/Doubts about the proposed Integration.

1) Each SCA application will have an SCA module which will be a jar
with an SCDL in META-INF. This jar can also be part of an EAR. . There
will be a Tuscany deployer that will take care of deploying the SCA
modules. Should WAR files be also able to contain SCA jars?
2) Each App will have an SCA Domain which will be instantiated when
the application starts. Is this assumption correct or can there be
multiple SCADomains per app?
3) The Tuscany classes are loaded only once and then shared between
the different SCA applications.
4) There will be multiple domains instantiated from different
applications and there should be a server wide domain registry where
applications can look up and invoke different composites from domains
different from their own. (Can this be Global JNDI/Gbean refs or is
there something specific in tuscany).
5) There should be only a single Tuscany Runtime for the entire
geronimo instance.
6) How can we lookup the services running in one geronimo instance
from an app in another geronimo instance. Is this supported in Tuscany

These are just the initial set of points/questions that hit me when I
thought about the integration. Jay /Raymond I guess you guys will be
aware of many other points as well. Can you reply with your analysis
so that we can flesh out the requirements completely in the mailing
list. That way both the communities can contribute their thoughts. If
you have already started can you just point me to where I can catch up
on what has happened?

Thanks
Manu

On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> Hi, Geronimo community.
>
> As you may know, Tuscany is an Apache project under incubation to provide an
> open source SOA infrastructure. For more information, you can visit
> http://cwiki.apache.org/TUSCANY/.
>
> Tuscany implements the SCA specification (http://www.osoa.org) and allows
> you to develop and run SCA components in various hosting environments. We
> currently integrate with Tomcat and Jetty and would like to try to integrate
> with Geronimo as well. I would like to start some discussions here to figure
> out the best way to do that.
>
> After some preliminary investigations of Geronimo, I feel that there are two
> options on the table so far.
>
> 1) Shallow integration: Package SCA applications together with the Tuscany
> runtime as WARs and deploy them Geronimo as Web applications. It's basically
> the integration with a Web container. We register a TuscanyContextListner
> (which implements javax.servlet.ServletContextListener) in web.xml to
> start/stop the Tuscany runtime when the web application is started/stopped.
>
> This will allow us to support the following use cases:
> * A Web application hosted by Geronimo with business logic written as SCA
> components
> * Expose one or more SCA components as Web services over HTTP as supported
> by the Web container.
>
> 2) Deep integration: We package the Tuscany runtime and its dependencies as
> Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat
> is integrated as the Web container for Geronimo). We can then create a
> Tuscany plugin (a collection of modules) so that it can be added to
> Geronimo. The Tuscany container will then handle SCA-specific deployment
> plans to install SCA applications and provide runtime infrastructure for
> them.
>
> On top of Option 2, we could further integrate Geronimo's J2EE capabilities
> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be
> able to access JEE services (using SCA composite references) and SCA
> components will be able to expose services (SCA composite services) over JEE
> protocols as well.
>
> This will allow us to support the following use cases:
> * Any J2EE application hosted by Geronimo would be able to take advantage of
> SCA programming model
> * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web
> Services) from SCA components
>
> Any thoughts?
>
> Thanks,
> Raymond
> Apache Tuscany committer
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Geronimo/Tuscany integration

[Vamsavardhana Reddy <c1...@gmail.com>]

I agree with Dain.

Vamsi

On 4/26/07, Dain Sundstrom <da...@iq80.com> wrote:
> I suggest you get option 1 working before attempting option 2.  I
> suspect you will find lots of bugs and mismatched assumptions.  Once
> that is working, option 2 will be much easier to implement since you
> know it "Should Work".
>
> -dain
>
> On Apr 25, 2007, at 1:23 PM, Jay D. McHugh wrote:
>
> > Hello Raymond,
> >
> > I think it would almost be a shame if the only option for including
> > Tuscany in Geronimo was to package the runtime jar in individual
> > WAR files.
> >
> > Tuscany would make an excellent (I think) plugin.
> >
> > Option 2 definitely.
> >
> > Jay
> >
> > Raymond Feng wrote:
> >> Hi, Geronimo community.
> >>
> >> As you may know, Tuscany is an Apache project under incubation to
> >> provide an open source SOA infrastructure. For more information,
> >> you can visit http://cwiki.apache.org/TUSCANY/.
> >>
> >> Tuscany implements the SCA specification (http://www.osoa.org) and
> >> allows you to develop and run SCA components in various hosting
> >> environments. We currently integrate with Tomcat and Jetty and
> >> would like to try to integrate with Geronimo as well. I would like
> >> to start some discussions here to figure out the best way to do that.
> >>
> >> After some preliminary investigations of Geronimo, I feel that
> >> there are two options on the table so far.
> >>
> >> 1) Shallow integration: Package SCA applications together with the
> >> Tuscany runtime as WARs and deploy them Geronimo as Web
> >> applications. It's basically the integration with a Web container.
> >> We register a TuscanyContextListner (which implements
> >> javax.servlet.ServletContextListener) in web.xml to start/stop the
> >> Tuscany runtime when the web application is started/stopped.
> >>
> >> This will allow us to support the following use cases:
> >> * A Web application hosted by Geronimo with business logic written
> >> as SCA components
> >> * Expose one or more SCA components as Web services over HTTP as
> >> supported by the Web container.
> >>
> >> 2) Deep integration: We package the Tuscany runtime and its
> >> dependencies as Geronimo modules and deploy them to Geronimo
> >> (which is similar to how Tomcat is integrated as the Web container
> >> for Geronimo). We can then create a Tuscany plugin (a collection
> >> of modules) so that it can be added to Geronimo. The Tuscany
> >> container will then handle SCA-specific deployment plans to
> >> install SCA applications and provide runtime infrastructure for them.
> >>
> >> On top of Option 2, we could further integrate Geronimo's J2EE
> >> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically,
> >> SCA components will be able to access JEE services (using SCA
> >> composite references) and SCA components will be able to expose
> >> services (SCA composite services) over JEE protocols as well.
> >>
> >> This will allow us to support the following use cases:
> >> * Any J2EE application hosted by Geronimo would be able to take
> >> advantage of SCA programming model
> >> * Provide SCA services over various protocols such as RMI/IIOP,
> >> JMS and JCA
> >> * Invoke existing JEE applications (EJB, JMS backend, JCA-based
> >> EIS or Web Services) from SCA components
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Raymond
> >> Apache Tuscany committer
> >>
> >>
> >>
>
>

Re: Geronimo/Tuscany integration

["Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>]

Dain is right - Option 1 should probably be a stepping stone on the way 
to 2.

Jay

Dain Sundstrom wrote:
> I suggest you get option 1 working before attempting option 2.  I 
> suspect you will find lots of bugs and mismatched assumptions.  Once 
> that is working, option 2 will be much easier to implement since you 
> know it "Should Work".
>
> -dain
>
> On Apr 25, 2007, at 1:23 PM, Jay D. McHugh wrote:
>
>> Hello Raymond,
>>
>> I think it would almost be a shame if the only option for including 
>> Tuscany in Geronimo was to package the runtime jar in individual WAR 
>> files.
>>
>> Tuscany would make an excellent (I think) plugin.
>>
>> Option 2 definitely.
>>
>> Jay
>>
>> Raymond Feng wrote:
>>> Hi, Geronimo community.
>>>
>>> As you may know, Tuscany is an Apache project under incubation to 
>>> provide an open source SOA infrastructure. For more information, you 
>>> can visit http://cwiki.apache.org/TUSCANY/.
>>>
>>> Tuscany implements the SCA specification (http://www.osoa.org) and 
>>> allows you to develop and run SCA components in various hosting 
>>> environments. We currently integrate with Tomcat and Jetty and would 
>>> like to try to integrate with Geronimo as well. I would like to 
>>> start some discussions here to figure out the best way to do that.
>>>
>>> After some preliminary investigations of Geronimo, I feel that there 
>>> are two options on the table so far.
>>>
>>> 1) Shallow integration: Package SCA applications together with the 
>>> Tuscany runtime as WARs and deploy them Geronimo as Web 
>>> applications. It's basically the integration with a Web container. 
>>> We register a TuscanyContextListner (which implements 
>>> javax.servlet.ServletContextListener) in web.xml to start/stop the 
>>> Tuscany runtime when the web application is started/stopped.
>>>
>>> This will allow us to support the following use cases:
>>> * A Web application hosted by Geronimo with business logic written 
>>> as SCA components
>>> * Expose one or more SCA components as Web services over HTTP as 
>>> supported by the Web container.
>>>
>>> 2) Deep integration: We package the Tuscany runtime and its 
>>> dependencies as Geronimo modules and deploy them to Geronimo (which 
>>> is similar to how Tomcat is integrated as the Web container for 
>>> Geronimo). We can then create a Tuscany plugin (a collection of 
>>> modules) so that it can be added to Geronimo. The Tuscany container 
>>> will then handle SCA-specific deployment plans to install SCA 
>>> applications and provide runtime infrastructure for them.
>>>
>>> On top of Option 2, we could further integrate Geronimo's J2EE 
>>> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically, 
>>> SCA components will be able to access JEE services (using SCA 
>>> composite references) and SCA components will be able to expose 
>>> services (SCA composite services) over JEE protocols as well.
>>>
>>> This will allow us to support the following use cases:
>>> * Any J2EE application hosted by Geronimo would be able to take 
>>> advantage of SCA programming model
>>> * Provide SCA services over various protocols such as RMI/IIOP, JMS 
>>> and JCA
>>> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS 
>>> or Web Services) from SCA components
>>>
>>> Any thoughts?
>>>
>>> Thanks,
>>> Raymond
>>> Apache Tuscany committer
>>>
>>>
>>>
>
>
>
>

Re: Geronimo/Tuscany integration

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 4/27/07, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Thank you all for the comments and suggestions. I'll keep this list updated
> when we get option 1 working.

Where is it going to be done? Is it going to be done on the
dev@tuscany mailing list or here? Where's the place for the source
code?

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Geronimo/Tuscany integration

[Raymond Feng <en...@gmail.com>]

Hi,

Thank you all for the comments and suggestions. I'll keep this list updated 
when we get option 1 working.

Raymond

----- Original Message ----- 
From: "Matt Hogstrom" <ma...@hogstrom.org>
To: <de...@geronimo.apache.org>
Sent: Thursday, April 26, 2007 12:00 AM
Subject: Re: Geronimo/Tuscany integration


>
>
> On Apr 25, 2007, at 4:30 PM, Dain Sundstrom wrote:
>
>> I suggest you get option 1 working before attempting option 2.  I 
>> suspect you will find lots of bugs and mismatched assumptions.   Once 
>> that is working, option 2 will be much easier to implement  since you 
>> know it "Should Work".
>
> +1
>
> 

Re: Geronimo/Tuscany integration

[Matt Hogstrom <ma...@hogstrom.org>]

On Apr 25, 2007, at 4:30 PM, Dain Sundstrom wrote:

> I suggest you get option 1 working before attempting option 2.  I  
> suspect you will find lots of bugs and mismatched assumptions.   
> Once that is working, option 2 will be much easier to implement  
> since you know it "Should Work".

+1

Re: Geronimo/Tuscany integration

[Prasad Kashyap <go...@gmail.com>]

I support Dain's approach.

Think big, start small.

Cheers
Prasad

On 4/25/07, Dain Sundstrom <da...@iq80.com> wrote:
> I suggest you get option 1 working before attempting option 2.  I
> suspect you will find lots of bugs and mismatched assumptions.  Once
> that is working, option 2 will be much easier to implement since you
> know it "Should Work".
>
> -dain
>
> On Apr 25, 2007, at 1:23 PM, Jay D. McHugh wrote:
>
> > Hello Raymond,
> >
> > I think it would almost be a shame if the only option for including
> > Tuscany in Geronimo was to package the runtime jar in individual
> > WAR files.
> >
> > Tuscany would make an excellent (I think) plugin.
> >
> > Option 2 definitely.
> >
> > Jay
> >
> > Raymond Feng wrote:
> >> Hi, Geronimo community.
> >>
> >> As you may know, Tuscany is an Apache project under incubation to
> >> provide an open source SOA infrastructure. For more information,
> >> you can visit http://cwiki.apache.org/TUSCANY/.
> >>
> >> Tuscany implements the SCA specification (http://www.osoa.org) and
> >> allows you to develop and run SCA components in various hosting
> >> environments. We currently integrate with Tomcat and Jetty and
> >> would like to try to integrate with Geronimo as well. I would like
> >> to start some discussions here to figure out the best way to do that.
> >>
> >> After some preliminary investigations of Geronimo, I feel that
> >> there are two options on the table so far.
> >>
> >> 1) Shallow integration: Package SCA applications together with the
> >> Tuscany runtime as WARs and deploy them Geronimo as Web
> >> applications. It's basically the integration with a Web container.
> >> We register a TuscanyContextListner (which implements
> >> javax.servlet.ServletContextListener) in web.xml to start/stop the
> >> Tuscany runtime when the web application is started/stopped.
> >>
> >> This will allow us to support the following use cases:
> >> * A Web application hosted by Geronimo with business logic written
> >> as SCA components
> >> * Expose one or more SCA components as Web services over HTTP as
> >> supported by the Web container.
> >>
> >> 2) Deep integration: We package the Tuscany runtime and its
> >> dependencies as Geronimo modules and deploy them to Geronimo
> >> (which is similar to how Tomcat is integrated as the Web container
> >> for Geronimo). We can then create a Tuscany plugin (a collection
> >> of modules) so that it can be added to Geronimo. The Tuscany
> >> container will then handle SCA-specific deployment plans to
> >> install SCA applications and provide runtime infrastructure for them.
> >>
> >> On top of Option 2, we could further integrate Geronimo's J2EE
> >> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically,
> >> SCA components will be able to access JEE services (using SCA
> >> composite references) and SCA components will be able to expose
> >> services (SCA composite services) over JEE protocols as well.
> >>
> >> This will allow us to support the following use cases:
> >> * Any J2EE application hosted by Geronimo would be able to take
> >> advantage of SCA programming model
> >> * Provide SCA services over various protocols such as RMI/IIOP,
> >> JMS and JCA
> >> * Invoke existing JEE applications (EJB, JMS backend, JCA-based
> >> EIS or Web Services) from SCA components
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Raymond
> >> Apache Tuscany committer
> >>
> >>
> >>
>
>

Re: Geronimo/Tuscany integration

[Dain Sundstrom <da...@iq80.com>]

I suggest you get option 1 working before attempting option 2.  I  
suspect you will find lots of bugs and mismatched assumptions.  Once  
that is working, option 2 will be much easier to implement since you  
know it "Should Work".

-dain

On Apr 25, 2007, at 1:23 PM, Jay D. McHugh wrote:

> Hello Raymond,
>
> I think it would almost be a shame if the only option for including  
> Tuscany in Geronimo was to package the runtime jar in individual  
> WAR files.
>
> Tuscany would make an excellent (I think) plugin.
>
> Option 2 definitely.
>
> Jay
>
> Raymond Feng wrote:
>> Hi, Geronimo community.
>>
>> As you may know, Tuscany is an Apache project under incubation to  
>> provide an open source SOA infrastructure. For more information,  
>> you can visit http://cwiki.apache.org/TUSCANY/.
>>
>> Tuscany implements the SCA specification (http://www.osoa.org) and  
>> allows you to develop and run SCA components in various hosting  
>> environments. We currently integrate with Tomcat and Jetty and  
>> would like to try to integrate with Geronimo as well. I would like  
>> to start some discussions here to figure out the best way to do that.
>>
>> After some preliminary investigations of Geronimo, I feel that  
>> there are two options on the table so far.
>>
>> 1) Shallow integration: Package SCA applications together with the  
>> Tuscany runtime as WARs and deploy them Geronimo as Web  
>> applications. It's basically the integration with a Web container.  
>> We register a TuscanyContextListner (which implements  
>> javax.servlet.ServletContextListener) in web.xml to start/stop the  
>> Tuscany runtime when the web application is started/stopped.
>>
>> This will allow us to support the following use cases:
>> * A Web application hosted by Geronimo with business logic written  
>> as SCA components
>> * Expose one or more SCA components as Web services over HTTP as  
>> supported by the Web container.
>>
>> 2) Deep integration: We package the Tuscany runtime and its  
>> dependencies as Geronimo modules and deploy them to Geronimo  
>> (which is similar to how Tomcat is integrated as the Web container  
>> for Geronimo). We can then create a Tuscany plugin (a collection  
>> of modules) so that it can be added to Geronimo. The Tuscany  
>> container will then handle SCA-specific deployment plans to  
>> install SCA applications and provide runtime infrastructure for them.
>>
>> On top of Option 2, we could further integrate Geronimo's J2EE  
>> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically,  
>> SCA components will be able to access JEE services (using SCA  
>> composite references) and SCA components will be able to expose  
>> services (SCA composite services) over JEE protocols as well.
>>
>> This will allow us to support the following use cases:
>> * Any J2EE application hosted by Geronimo would be able to take  
>> advantage of SCA programming model
>> * Provide SCA services over various protocols such as RMI/IIOP,  
>> JMS and JCA
>> * Invoke existing JEE applications (EJB, JMS backend, JCA-based  
>> EIS or Web Services) from SCA components
>>
>> Any thoughts?
>>
>> Thanks,
>> Raymond
>> Apache Tuscany committer
>>
>>
>>

Re: Geronimo/Tuscany integration

["Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>]

Hello Raymond,

I think it would almost be a shame if the only option for including 
Tuscany in Geronimo was to package the runtime jar in individual WAR files.

Tuscany would make an excellent (I think) plugin.

Option 2 definitely.

Jay

Raymond Feng wrote:
> Hi, Geronimo community.
>
> As you may know, Tuscany is an Apache project under incubation to 
> provide an open source SOA infrastructure. For more information, you 
> can visit http://cwiki.apache.org/TUSCANY/.
>
> Tuscany implements the SCA specification (http://www.osoa.org) and 
> allows you to develop and run SCA components in various hosting 
> environments. We currently integrate with Tomcat and Jetty and would 
> like to try to integrate with Geronimo as well. I would like to start 
> some discussions here to figure out the best way to do that.
>
> After some preliminary investigations of Geronimo, I feel that there 
> are two options on the table so far.
>
> 1) Shallow integration: Package SCA applications together with the 
> Tuscany runtime as WARs and deploy them Geronimo as Web applications. 
> It's basically the integration with a Web container. We register a 
> TuscanyContextListner (which implements 
> javax.servlet.ServletContextListener) in web.xml to start/stop the 
> Tuscany runtime when the web application is started/stopped.
>
> This will allow us to support the following use cases:
> * A Web application hosted by Geronimo with business logic written as 
> SCA components
> * Expose one or more SCA components as Web services over HTTP as 
> supported by the Web container.
>
> 2) Deep integration: We package the Tuscany runtime and its 
> dependencies as Geronimo modules and deploy them to Geronimo (which is 
> similar to how Tomcat is integrated as the Web container for 
> Geronimo). We can then create a Tuscany plugin (a collection of 
> modules) so that it can be added to Geronimo. The Tuscany container 
> will then handle SCA-specific deployment plans to install SCA 
> applications and provide runtime infrastructure for them.
>
> On top of Option 2, we could further integrate Geronimo's J2EE 
> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA 
> components will be able to access JEE services (using SCA composite 
> references) and SCA components will be able to expose services (SCA 
> composite services) over JEE protocols as well.
>
> This will allow us to support the following use cases:
> * Any J2EE application hosted by Geronimo would be able to take 
> advantage of SCA programming model
> * Provide SCA services over various protocols such as RMI/IIOP, JMS 
> and JCA
> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or 
> Web Services) from SCA components
>
> Any thoughts?
>
> Thanks,
> Raymond
> Apache Tuscany committer
>
>
>

Re: Geronimo/Tuscany integration

[Manu George <ma...@gmail.com>]

Hi Raymond/Jay,

      I would like to join this effort. I would like to discuss what
is expected of the deep integration. I will just list down my
understanding of both the current and proposed integrations

Understanding of the Current Integration

1) TuscanyContextListener creates an SCA domain when the servlet is
created and then destroys it when the servlet is destroyed.
2) During SCA domain creation it looks up the composites and deploys
them in the domain
Creates a webapp module activator for registering servlet hosts.
3) Finally we have a servlet that forwards requests to the servlet
registered with the Tuscany Servlet Host.
4) An SCADomain is created for each application and we can lookup the
services from the SCADomain.
5) During SCADomain creation a runtime is also created for the DefaultSCADomain.
7) All tuscany classes are loaded repeatedly for each application in
separate classloaders.
8) A runtime is created per application

Understanding/Doubts about the proposed Integration.

1) Each SCA application will have an SCA module which will be a jar
with an SCDL in META-INF. This jar can also be part of an EAR. . There
will be a Tuscany deployer that will take care of deploying the SCA
modules. Should WAR files be also able to contain SCA jars?
2) Each App will have an SCA Domain which will be instantiated when
the application starts. Is this assumption correct or can there be
multiple SCADomains per app?
3) The Tuscany classes are loaded only once and then shared between
the different SCA applications.
4) There will be multiple domains instantiated from different
applications and there should be a server wide domain registry where
applications can look up and invoke different composites from domains
different from their own. (Can this be Global JNDI/Gbean refs or is
there something specific in tuscany).
5) There should be only a single Tuscany Runtime for the entire
geronimo instance.
6) How can we lookup the services running in one geronimo instance
from an app in another geronimo instance. Is this supported in Tuscany

These are just the initial set of points/questions that hit me when I
thought about the integration. Jay /Raymond I guess you guys will be
aware of many other points as well. Can you reply with your analysis
so that we can flesh out the requirements completely in the mailing
list. That way both the communities can contribute their thoughts. If
you have already started can you just point me to where I can catch up
on what has happened?

Thanks
Manu

On 4/26/07, Raymond Feng <en...@gmail.com> wrote:
> Hi, Geronimo community.
>
> As you may know, Tuscany is an Apache project under incubation to provide an
> open source SOA infrastructure. For more information, you can visit
> http://cwiki.apache.org/TUSCANY/.
>
> Tuscany implements the SCA specification (http://www.osoa.org) and allows
> you to develop and run SCA components in various hosting environments. We
> currently integrate with Tomcat and Jetty and would like to try to integrate
> with Geronimo as well. I would like to start some discussions here to figure
> out the best way to do that.
>
> After some preliminary investigations of Geronimo, I feel that there are two
> options on the table so far.
>
> 1) Shallow integration: Package SCA applications together with the Tuscany
> runtime as WARs and deploy them Geronimo as Web applications. It's basically
> the integration with a Web container. We register a TuscanyContextListner
> (which implements javax.servlet.ServletContextListener) in web.xml to
> start/stop the Tuscany runtime when the web application is started/stopped.
>
> This will allow us to support the following use cases:
> * A Web application hosted by Geronimo with business logic written as SCA
> components
> * Expose one or more SCA components as Web services over HTTP as supported
> by the Web container.
>
> 2) Deep integration: We package the Tuscany runtime and its dependencies as
> Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat
> is integrated as the Web container for Geronimo). We can then create a
> Tuscany plugin (a collection of modules) so that it can be added to
> Geronimo. The Tuscany container will then handle SCA-specific deployment
> plans to install SCA applications and provide runtime infrastructure for
> them.
>
> On top of Option 2, we could further integrate Geronimo's J2EE capabilities
> such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be
> able to access JEE services (using SCA composite references) and SCA
> components will be able to expose services (SCA composite services) over JEE
> protocols as well.
>
> This will allow us to support the following use cases:
> * Any J2EE application hosted by Geronimo would be able to take advantage of
> SCA programming model
> * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web
> Services) from SCA components
>
> Any thoughts?
>
> Thanks,
> Raymond
> Apache Tuscany committer
>
>

Re: Geronimo/Tuscany integration

[Jeff Genender <jg...@apache.org>]

Hi Raymond,

I would like to see a deep integration.

Jeff

Raymond Feng wrote:
> Hi, Geronimo community.
> 
> As you may know, Tuscany is an Apache project under incubation to
> provide an open source SOA infrastructure. For more information, you can
> visit http://cwiki.apache.org/TUSCANY/.
> 
> Tuscany implements the SCA specification (http://www.osoa.org) and
> allows you to develop and run SCA components in various hosting
> environments. We currently integrate with Tomcat and Jetty and would
> like to try to integrate with Geronimo as well. I would like to start
> some discussions here to figure out the best way to do that.
> 
> After some preliminary investigations of Geronimo, I feel that there are
> two options on the table so far.
> 
> 1) Shallow integration: Package SCA applications together with the
> Tuscany runtime as WARs and deploy them Geronimo as Web applications.
> It's basically the integration with a Web container. We register a
> TuscanyContextListner (which implements
> javax.servlet.ServletContextListener) in web.xml to start/stop the
> Tuscany runtime when the web application is started/stopped.
> 
> This will allow us to support the following use cases:
> * A Web application hosted by Geronimo with business logic written as
> SCA components
> * Expose one or more SCA components as Web services over HTTP as
> supported by the Web container.
> 
> 2) Deep integration: We package the Tuscany runtime and its dependencies
> as Geronimo modules and deploy them to Geronimo (which is similar to how
> Tomcat is integrated as the Web container for Geronimo). We can then
> create a Tuscany plugin (a collection of modules) so that it can be
> added to Geronimo. The Tuscany container will then handle SCA-specific
> deployment plans to install SCA applications and provide runtime
> infrastructure for them.
> 
> On top of Option 2, we could further integrate Geronimo's J2EE
> capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA
> components will be able to access JEE services (using SCA composite
> references) and SCA components will be able to expose services (SCA
> composite services) over JEE protocols as well.
> 
> This will allow us to support the following use cases:
> * Any J2EE application hosted by Geronimo would be able to take
> advantage of SCA programming model
> * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA
> * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or
> Web Services) from SCA components
> 
> Any thoughts?
> 
> Thanks,
> Raymond
> Apache Tuscany committer