You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/07/01 01:57:28 UTC
Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Hi,
I would like to extend the discussion a bit to help us better understand
what user experience we would like to bring to Geronimo developers/users
with Tuscany/SCA.
I suggest that we use a usage scenario-driven approach to create a list of
tasks/features and mark them either it's common to SCA independent of the
hosting environment or it's specific to Geronimo.
Here is a few roles a Geronimo instance can play in the SCA domain:
1) Geronimo is a member of a SCA domain to deploy/run SCA applications
* Connect to the SCA domain admin app to get the image of a resolved
composite application
* Be able to deploy the resolved composite application in the VM of
Geronimo, either as JEE application or standalone [Specific to Geronimo]
* Run the resolved composite application
* Provide the binding/implementation/policy extensions to realize SCA
binding/implementation/policy types.[[Specific to Geronimo]
* Hook with the other containers in Geronimo to provide various
bindings, such as HTTP connectors with Tomcat
* Hook with the QoSs such Transaction and Security provided by Geronimo
to implement the SCA policies
* Create/manage related resources for some bindings, such as JMS connection
factories and queues [Specific to Geronimo]
2) Geronimo hosts the SCA domain admin application
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain
[Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites
[Common to SCA]
* Deploy the resolved composite image to a in-process or remote host [A
Geronimo or JSR88 Deployer may be specific to Geronimo]
3) Geronimo hosts (some) contributions for a SCA domain
* Expose them as URLs to the SCA domain admin application. In this case, It
functions as a repo for SCA contributions. [Specific to Geronimo]
I think we should only try to implement a feature in a geronimo-specific way
only if it's specific to Geronimo.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Thursday, June 19, 2008 6:31 AM
To: <de...@tuscany.apache.org>
Subject: Re: GSoC Project - Tuscany SCA support in the Geronimo admin
Console
> Thilina Buddhika wrote:
>> Hi,
>> Yes, these modules are available. But earlier there was a web app under
>> this
>> package which made use of these modules to provide with SCA domain admin
>> functionality. This was only working with a local SCA domain. So as I
>> feel,
>> it would be good, if we can get this web app to run with an ACE as the
>> first
>> phase, and then extend its functionality.
>>
>> This web app was available under org.apache.tuscany.sca.workspace.admin.*
>> .
>>
>> If this has been removed, then we can start it from the scratch by using
>> the available workspace modules. As an alternative to this, Ant has
>> suggested to bring the available tuscany-geronimo intergration code to
>> work
>> with latest geronimo versions.
>>
> As I understand it, there are different aspects to this project:
>
> 1. The visual integration of Tuscany/SCA admin into the Geronimo
> console, in a way that looks natural to the Geronimo user.
>
> 2. The ability to include Geronimo runtime componments (WARs,
> EJBs, etc.) in the Tuscany domain and administer them.
>
> For each of these, there are two options:
>
> 1a. There is a browser-based admin console as part of the
> new workspace code. It would be possible to repackage the
> visual presentation that this uses (HTML rendering) into a
> plugin within the Geronimo admin console.
>
> 1b. There are lower-level APIs into the new node/domain code that
> could be used to extract and manipulate the admin information
> and render it in the Geronimo console in a way that's more
> consistent with how the Geronimo console does things.
>
> These options 1a and 1b should be evaluated so that we can
> understand the difference between them and decide which approach
> is best for the short term and for the long term.
>
> 2a. This could be based on the new domain code. Currently there
> is not a clear understanding on how to integrate this with
> Geronimo components. However, it can be used to administer
> non-Geronimo components.
>
> 2b. This could be based on the old domain code, which doesn't
> work with Geronimo currently. We could get this integration
> working again, but it doesn't take us forward in the right
> direction.
>
> To decide between these pairs of options, the following questions
> need to be answered:
>
> What is the main focus of this project? Is it 1 or 2? If we
> agree it's 1, and there is significant challenge and creativity
> in doing that part, we could go with a less ambitious version
> of 2, or vice versa.
>
> How hard is it to do 1a/1b/2a/2b? We should not combine a hard
> flavour of 1 with a hard flavour of 2, as this would make the
> project too difficult to accomplish in the time available.
>
> Does 1b have significant value above 1a?
>
> For the scope of the GSoC project, if we choose 2a, is it a
> requirement that Geronimo-based components can be administered,
> or is it OK as a first step to only be able to administer other
> SCA components?
>
> I have probably missed a few points. Could others more familiar
> than me with Geronimo please share their thoughts on the above,
> and add anything else that I may have missed.
>
> Simon
>
>> In the mean time as Ant has suggested, it is better if we can set up an
>> svn
>> location to place my workings, so that everyone can see it.
>>
>> Any thoughts ?
>>
>> Thank You.
>>
>> regards,
>> / thilina
>>
>>
>> On Wed, May 28, 2008 at 7:49 PM, Luciano Resende <lu...@gmail.com>
>> wrote:
>>
>>> The tuscany-workspace-xxx modules are still available :
>>>
>>> Directory of .....\java\sca\modules
>>>
>>> 05/27/2008 09:12 PM <DIR> workspace
>>> 05/27/2008 09:13 PM <DIR> workspace-impl
>>> 05/27/2008 09:12 PM <DIR> workspace-xml
>>>
>>> On Wed, May 28, 2008 at 1:08 AM, Thilina Buddhika <th...@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> I started coding phase on Monday. As the first step, I took a svn
>>>> update
>>> and
>>>> successfully built it. As discussed earlier in the mailing list (when
>>>> preparing the proposal), it was decided to bring up the
>>> tuscany-workspace-
>>>> admin as a regular web application and run it inside Geronimo as the
>>> first
>>>> step.
>>>>
>>>>
>>>> But I could not find this class and other related classes in my copy of
>>> the
>>>> Tuscany SCA source.
>>>>
>>>> org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>>>>
>>>> Has the workspace-admin been moved to a different package ?
>>>>
>>>> Thank You.
>>>>
>>>> regs,
>>>> / thilina
>>>>
>>>>
>>>>
>>>> On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <th...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I thought of briefing my work within last few days to Tuscany-dev, so
>>> that
>>>>> community can give feedback on it. The wiki page[1] will also be
>>>>> updated
>>>>> along with this.
>>>>>
>>>>> Nowadays I am reading about ACEs and Portlets. I was able to implement
>>>>> a
>>>>> simple ACE and deploy it in Geronimo. Also it was possible to call
>>> some
>>>>> JSPs and Servlets within that ACE. I am digging more into this and
>>> planning
>>>>> to look at available web based SCA domain admin tool in Tuscany.
>>>>>
>>>>> thanks!
>>>>>
>>>>> best regards,
>>>>> / thilina
>>>>>
>>>>> [1] -
>>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>>>>> On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika
>>>>> <th...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Thanks Luciano for creating that wiki page. It is really easy to work
>>> with
>>>>>> confluence wiki. I created a child page[1] and moved my content to
>>>>>> it,
>>> from
>>>>>> my earlier wiki page. I'll be use this new wiki page from now
>>>>>> onwards.
>>>>>>
>>>>>> thanks!
>>>>>>
>>>>>> best regards,
>>>>>> / thilina
>>>>>>
>>>>>> [1] -
>>>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>>>>>>
>>>>>> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende
>>>>>> <luckbr1975@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Thilina
>>>>>>>
>>>>>>> Thanks for taking the initiative and creating the wiki page. I
>>>>>>> just
>>>>>>> created a wiki page/section to be used for GSoC 2008 [1], at the
>>>>>>> Tuscany Wiki, maybe you and all other students create child pages
>>>>>>> and
>>>>>>> use that one.
>>>>>>>
>>>>>>> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
>>>>>>>
>>>>>>> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <
>>> thilinamb@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> I started working on my project. According to the Google time
>>> line[1],
>>>>>>> now
>>>>>>>> it is the community bonding period. These days I am going through
>>> the
>>>>>>>> documentations again, and getting more familiar with the project.
>>>>>>>> I
>>>>>>> started
>>>>>>>> a wiki page[2] to display the current status of the project. I
>>> will
>>>>>>> be
>>>>>>>> frequently updating that wiki page. I will be using this thread to
>>> for
>>>>>>> the
>>>>>>>> discussions with the community.
>>>>>>>>
>>>>>>>> thanks!
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>> / thilina
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] -
>>>>>>> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
>>>>>>>> [2] -
>>>>>>> http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Luciano Resende
>>>>>>> Apache Tuscany Committer
>>>>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>> <http://people.apache.org/%7Elresende>
>>>>>>> http://lresende.blogspot.com/
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> E-Mail : thilinamb@gmail.com
>>>>> I blog here : http://thilinamb.blogspot.com
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail : thilinamb@gmail.com
>>>> I blog here : http://thilinamb.blogspot.com
>>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany Committer
>>> http://people.apache.org/~lresende
>>> <http://people.apache.org/%7Elresende>
>>> http://lresende.blogspot.com/
>>>
>>
>>
>>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by haleh mahbod <hm...@gmail.com>.
would it be possible to draw this on the wiki and state how the user can
benefit from this?
On 6/30/08, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I would like to extend the discussion a bit to help us better understand
> what user experience we would like to bring to Geronimo developers/users
> with Tuscany/SCA.
>
> I suggest that we use a usage scenario-driven approach to create a list of
> tasks/features and mark them either it's common to SCA independent of the
> hosting environment or it's specific to Geronimo.
>
> Here is a few roles a Geronimo instance can play in the SCA domain:
>
> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>
> * Connect to the SCA domain admin app to get the image of a resolved
> composite application
> * Be able to deploy the resolved composite application in the VM of
> Geronimo, either as JEE application or standalone [Specific to Geronimo]
> * Run the resolved composite application
> * Provide the binding/implementation/policy extensions to realize SCA
> binding/implementation/policy types.[[Specific to Geronimo]
> * Hook with the other containers in Geronimo to provide various bindings,
> such as HTTP connectors with Tomcat
> * Hook with the QoSs such Transaction and Security provided by Geronimo
> to implement the SCA policies
> * Create/manage related resources for some bindings, such as JMS connection
> factories and queues [Specific to Geronimo]
>
> 2) Geronimo hosts the SCA domain admin application
>
> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
> domain [Common to SCA]
> * Resolve the wirings at SCA domain level for the top-level composites
> [Common to SCA]
> * Deploy the resolved composite image to a in-process or remote host [A
> Geronimo or JSR88 Deployer may be specific to Geronimo]
>
> 3) Geronimo hosts (some) contributions for a SCA domain
> * Expose them as URLs to the SCA domain admin application. In this case, It
> functions as a repo for SCA contributions. [Specific to Geronimo]
>
> I think we should only try to implement a feature in a geronimo-specific
> way only if it's specific to Geronimo.
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Simon Nash" <na...@apache.org>
> Sent: Thursday, June 19, 2008 6:31 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: GSoC Project - Tuscany SCA support in the Geronimo admin
> Console
>
> Thilina Buddhika wrote:
>>
>>> Hi,
>>> Yes, these modules are available. But earlier there was a web app under
>>> this
>>> package which made use of these modules to provide with SCA domain admin
>>> functionality. This was only working with a local SCA domain. So as I
>>> feel,
>>> it would be good, if we can get this web app to run with an ACE as the
>>> first
>>> phase, and then extend its functionality.
>>>
>>> This web app was available under org.apache.tuscany.sca.workspace.admin.*
>>> .
>>>
>>> If this has been removed, then we can start it from the scratch by using
>>> the available workspace modules. As an alternative to this, Ant has
>>> suggested to bring the available tuscany-geronimo intergration code to
>>> work
>>> with latest geronimo versions.
>>>
>>> As I understand it, there are different aspects to this project:
>>
>> 1. The visual integration of Tuscany/SCA admin into the Geronimo
>> console, in a way that looks natural to the Geronimo user.
>>
>> 2. The ability to include Geronimo runtime componments (WARs,
>> EJBs, etc.) in the Tuscany domain and administer them.
>>
>> For each of these, there are two options:
>>
>> 1a. There is a browser-based admin console as part of the
>> new workspace code. It would be possible to repackage the
>> visual presentation that this uses (HTML rendering) into a
>> plugin within the Geronimo admin console.
>>
>> 1b. There are lower-level APIs into the new node/domain code that
>> could be used to extract and manipulate the admin information
>> and render it in the Geronimo console in a way that's more
>> consistent with how the Geronimo console does things.
>>
>> These options 1a and 1b should be evaluated so that we can
>> understand the difference between them and decide which approach
>> is best for the short term and for the long term.
>>
>> 2a. This could be based on the new domain code. Currently there
>> is not a clear understanding on how to integrate this with
>> Geronimo components. However, it can be used to administer
>> non-Geronimo components.
>>
>> 2b. This could be based on the old domain code, which doesn't
>> work with Geronimo currently. We could get this integration
>> working again, but it doesn't take us forward in the right
>> direction.
>>
>> To decide between these pairs of options, the following questions
>> need to be answered:
>>
>> What is the main focus of this project? Is it 1 or 2? If we
>> agree it's 1, and there is significant challenge and creativity
>> in doing that part, we could go with a less ambitious version
>> of 2, or vice versa.
>>
>> How hard is it to do 1a/1b/2a/2b? We should not combine a hard
>> flavour of 1 with a hard flavour of 2, as this would make the
>> project too difficult to accomplish in the time available.
>>
>> Does 1b have significant value above 1a?
>>
>> For the scope of the GSoC project, if we choose 2a, is it a
>> requirement that Geronimo-based components can be administered,
>> or is it OK as a first step to only be able to administer other
>> SCA components?
>>
>> I have probably missed a few points. Could others more familiar
>> than me with Geronimo please share their thoughts on the above,
>> and add anything else that I may have missed.
>>
>> Simon
>>
>> In the mean time as Ant has suggested, it is better if we can set up an
>>> svn
>>> location to place my workings, so that everyone can see it.
>>>
>>> Any thoughts ?
>>>
>>> Thank You.
>>>
>>> regards,
>>> / thilina
>>>
>>>
>>> On Wed, May 28, 2008 at 7:49 PM, Luciano Resende <lu...@gmail.com>
>>> wrote:
>>>
>>> The tuscany-workspace-xxx modules are still available :
>>>>
>>>> Directory of .....\java\sca\modules
>>>>
>>>> 05/27/2008 09:12 PM <DIR> workspace
>>>> 05/27/2008 09:13 PM <DIR> workspace-impl
>>>> 05/27/2008 09:12 PM <DIR> workspace-xml
>>>>
>>>> On Wed, May 28, 2008 at 1:08 AM, Thilina Buddhika <th...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I started coding phase on Monday. As the first step, I took a svn
>>>>> update
>>>>>
>>>> and
>>>>
>>>>> successfully built it. As discussed earlier in the mailing list (when
>>>>> preparing the proposal), it was decided to bring up the
>>>>>
>>>> tuscany-workspace-
>>>>
>>>>> admin as a regular web application and run it inside Geronimo as the
>>>>>
>>>> first
>>>>
>>>>> step.
>>>>>
>>>>>
>>>>> But I could not find this class and other related classes in my copy of
>>>>>
>>>> the
>>>>
>>>>> Tuscany SCA source.
>>>>>
>>>>> org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>>>>>
>>>>> Has the workspace-admin been moved to a different package ?
>>>>>
>>>>> Thank You.
>>>>>
>>>>> regs,
>>>>> / thilina
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <thilinamb@gmail.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I thought of briefing my work within last few days to Tuscany-dev, so
>>>>>>
>>>>> that
>>>>
>>>>> community can give feedback on it. The wiki page[1] will also be
>>>>>> updated
>>>>>> along with this.
>>>>>>
>>>>>> Nowadays I am reading about ACEs and Portlets. I was able to implement
>>>>>> a
>>>>>> simple ACE and deploy it in Geronimo. Also it was possible to call
>>>>>>
>>>>> some
>>>>
>>>>> JSPs and Servlets within that ACE. I am digging more into this and
>>>>>>
>>>>> planning
>>>>
>>>>> to look at available web based SCA domain admin tool in Tuscany.
>>>>>>
>>>>>> thanks!
>>>>>>
>>>>>> best regards,
>>>>>> / thilina
>>>>>>
>>>>>> [1] -
>>>>>>
>>>>>>
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>>>>
>>>>> On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika <thilinamb@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>> Thanks Luciano for creating that wiki page. It is really easy to work
>>>>>>>
>>>>>> with
>>>>
>>>>> confluence wiki. I created a child page[1] and moved my content to
>>>>>>> it,
>>>>>>>
>>>>>> from
>>>>
>>>>> my earlier wiki page. I'll be use this new wiki page from now
>>>>>>> onwards.
>>>>>>>
>>>>>>> thanks!
>>>>>>>
>>>>>>> best regards,
>>>>>>> / thilina
>>>>>>>
>>>>>>> [1] -
>>>>>>>
>>>>>>>
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>>>>
>>>>>
>>>>>>> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <
>>>>>>> luckbr1975@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Thilina
>>>>>>>>
>>>>>>>> Thanks for taking the initiative and creating the wiki page. I just
>>>>>>>> created a wiki page/section to be used for GSoC 2008 [1], at the
>>>>>>>> Tuscany Wiki, maybe you and all other students create child pages
>>>>>>>> and
>>>>>>>> use that one.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
>>>>>>>>
>>>>>>>> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <
>>>>>>>>
>>>>>>> thilinamb@gmail.com>
>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> I started working on my project. According to the Google time
>>>>>>>>>
>>>>>>>> line[1],
>>>>
>>>>> now
>>>>>>>>
>>>>>>>>> it is the community bonding period. These days I am going through
>>>>>>>>>
>>>>>>>> the
>>>>
>>>>> documentations again, and getting more familiar with the project. I
>>>>>>>>>
>>>>>>>> started
>>>>>>>>
>>>>>>>>> a wiki page[2] to display the current status of the project. I
>>>>>>>>>
>>>>>>>> will
>>>>
>>>>> be
>>>>>>>>
>>>>>>>>> frequently updating that wiki page. I will be using this thread to
>>>>>>>>>
>>>>>>>> for
>>>>
>>>>> the
>>>>>>>>
>>>>>>>>> discussions with the community.
>>>>>>>>>
>>>>>>>>> thanks!
>>>>>>>>>
>>>>>>>>> best regards,
>>>>>>>>> / thilina
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] -
>>>>>>>>>
>>>>>>>> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
>>>>>>>>
>>>>>>>>> [2] -
>>>>>>>>>
>>>>>>>> http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Luciano Resende
>>>>>>>> Apache Tuscany Committer
>>>>>>>> http://people.apache.org/~lresende<
>>>>>>>> http://people.apache.org/%7Elresende>
>>>>>>>>
>>>>>>> <http://people.apache.org/%7Elresende>
>>>>
>>>>> http://lresende.blogspot.com/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> E-Mail : thilinamb@gmail.com
>>>>>> I blog here : http://thilinamb.blogspot.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail : thilinamb@gmail.com
>>>>> I blog here : http://thilinamb.blogspot.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> Luciano Resende
>>>> Apache Tuscany Committer
>>>> http://people.apache.org/~lresende <
>>>> http://people.apache.org/%7Elresende>
>>>> http://lresende.blogspot.com/
>>>>
>>>>
>>>
>>>
>>>
>>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
I am reading through the spec. I will post my comments soon.
++Vamsi
On Wed, Jul 9, 2008 at 1:26 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to extend the discussion a bit to help us better understand
>>> what user experience we would like to bring to Geronimo developers/users
>>> with Tuscany/SCA.
>>>
>>> I suggest that we use a usage scenario-driven approach to create a list
>>> of tasks/features and mark them either it's common to SCA independent of the
>>> hosting environment or it's specific to Geronimo.
>>>
>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>
>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>
>>> * Connect to the SCA domain admin app to get the image of a resolved
>>> composite application
>>> * Be able to deploy the resolved composite application in the VM of
>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>> * Run the resolved composite application
>>> * Provide the binding/implementation/policy extensions to realize SCA
>>> binding/implementation/policy types.[[Specific to Geronimo]
>>> * Hook with the other containers in Geronimo to provide various
>>> bindings, such as HTTP connectors with Tomcat
>>> * Hook with the QoSs such Transaction and Security provided by Geronimo
>>> to implement the SCA policies
>>> * Create/manage related resources for some bindings, such as JMS
>>> connection factories and queues [Specific to Geronimo]
>>>
>>> 2) Geronimo hosts the SCA domain admin application
>>>
>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>> domain [Common to SCA]
>>> * Resolve the wirings at SCA domain level for the top-level composites
>>> [Common to SCA]
>>> * Deploy the resolved composite image to a in-process or remote host [A
>>> Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>
>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>> * Expose them as URLs to the SCA domain admin application. In this case,
>>> It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>
>>> I think we should only try to implement a feature in a geronimo-specific
>>> way only if it's specific to Geronimo.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>>>
>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>> several concrete use cases and scenarios we can use to define the tasks and
>> features we need. For example, how about one goal be running in Geronimo the
>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>> SCA JEE spec.
>>
>> ...ant
>>
>> [1]
>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>
>
> Any comments on this or does silence mean that example from the JEE spec is
> an ok use case to be working towards for our first try at the new Geronimo
> integration?
>
> ...ant
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's
sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the
Geronimo admin Console
Posted by Dan Becker <da...@gmail.com>.
ant elder wrote:
> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
>>> I suggest that we use a usage scenario-driven approach to create a list of
>>> tasks/features and mark them either it's common to SCA independent of the
>>> hosting environment or it's specific to Geronimo.
>>>
>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>
>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>
>>> 2) Geronimo hosts the SCA domain admin application
>>>
>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>
>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>> several concrete use cases and scenarios we can use to define the tasks and
>> features we need. For example, how about one goal be running in Geronimo the
>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>> SCA JEE spec.
>>
>> [1]
>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>
> Any comments on this or does silence mean that example from the JEE spec is
> an ok use case to be working towards for our first try at the new Geronimo
> integration?
I think the use cases suggested by Raymond and the use cases in Appendix
A of the SCA Java EE spec suggested by you are all excellent starting
points to validate Tuscany integration with Geronimo. It seems the roles
Raymond suggests are larger in scope and might touch more bindings and
data bindings than more specific Java EE integration.
--
Thanks, Dan Becker
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Hi Ant,
So far the implementationweb code is only used in constructing the
application composite when modelling a web application as an SCA
contribution.
++Vamsi
On Thu, Aug 14, 2008 at 12:08 PM, ant elder <an...@gmail.com> wrote:
> FYI, there is now some doc on the current state of implementation.web at
> http://tuscany.apache.org/sca-java-implementationweb.html and samples
> demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and
> helloworld-web.
>
> Would be great to start trying to integrate this with some of the JEE
> introspection code thats been added recently, is there any doc on that or
> explanations of how it could be used?
>
> ...ant
>
>
> On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
>
>> While thats being done I'd like to do some more work on implementation.web
>> and section 5.4 of the sca jee spec. I'd already started on this a while
>> back but now i'd like to getting it going properly intergrated in to the
>> build and our existing runtime support. Eventually i'd like webapps and
>> implementation.web to support using the Tuscany distributed domain but it
>> will take some smaller steps before it gets to there.
>>
>> ...ant
>>
>> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <c1vamsi1c@gmail.com
>> > wrote:
>>
>>> As a first step towards the integration, here are some items that I have
>>> identified with Raymond and Sebastien's help (Raymond, Sebastien, please
>>> correct me if I failed to capture the essence):
>>>
>>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given
>>> a Java EE archive (non-SCA-enhanced for now), compute by introspecting the
>>> archive, the SCA composite that represents the archive as an SCA
>>> contribution as per SCA JEE Integration Spec [1]. In this step, all the
>>> business interfaces implemented by session beans result in SCA services and
>>> all the EJB references (used in session beans, MDBs and web components)
>>> result in SCA references.
>>>
>>> 2. Get binding.ejb work with services. Currently binding.ejb works only
>>> with references. Once binding.ejb works with services, the references
>>> computed in step 1 above can be wired to the services in the domain using
>>> ejb binding.
>>>
>>> 3. Common Administration view. Once a JEE contribution is added to a
>>> domain, it should be administrable like any other SCA contribution. The
>>> fact that the contribution may actually be run as a Java EE application on a
>>> Java EE server should be transparent to the administrator.
>>>
>>> These three items should enable the coverage of scenarios 2.1-2.3 in
>>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
>>> this.
>>>
>>> I have done a little bit of experimentation with EJB jars. Using
>>> openejb-core and openejb-jee modules, it seems fairly simple to introspect
>>> EJB3 jars (even though I already ran into some glitches with the interface
>>> definitions). Will post to the list soon on my findings.
>>>
>>> ++Vamsi
>>>
>>> [1]
>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>
>>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
>>>
>>>> Ok, from the initial email there were only two points labelled [Common
>>>> to SCA]:
>>>>
>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>> domain [Common to SCA]
>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>> [Common to SCA]
>>>>
>>>> and all the other points are labelled [Specific to Geronimo]. I guess on
>>>> the surface of it that all sounds fine to me as long as [Common to SCA]
>>>> means its the APIs and code behind the APIs which are provided in a common
>>>> way by Tuscany. For something like the GSoC project doing the Geronimo
>>>> console management plugin that still needs to elements to be specific to
>>>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>>>
>>>> ...ant
>>>>
>>>>
>>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's good to add the use cases from SCA/JEE spec into this discussion.
>>>>> But I want to make sure the purpose of this thread is to identify what's
>>>>> common to SCA in all hosting environment and what's specific to Geronimo.
>>>>> Base on the classification, we should implement the common features in a
>>>>> generic way and specific things in a Geronimo way.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> *From:* ant elder <an...@gmail.com>
>>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>>>> *To:* dev@tuscany.apache.org
>>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>>>>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>>>> support in the Geronimo admin Console
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to extend the discussion a bit to help us better
>>>>>>> understand what user experience we would like to bring to Geronimo
>>>>>>> developers/users with Tuscany/SCA.
>>>>>>>
>>>>>>> I suggest that we use a usage scenario-driven approach to create a
>>>>>>> list of tasks/features and mark them either it's common to SCA independent
>>>>>>> of the hosting environment or it's specific to Geronimo.
>>>>>>>
>>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>>>
>>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA
>>>>>>> applications
>>>>>>>
>>>>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>>>>> composite application
>>>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>>>> * Run the resolved composite application
>>>>>>> * Provide the binding/implementation/policy extensions to realize SCA
>>>>>>> binding/implementation/policy types.[[Specific to Geronimo]
>>>>>>> * Hook with the other containers in Geronimo to provide various
>>>>>>> bindings, such as HTTP connectors with Tomcat
>>>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>>>> Geronimo to implement the SCA policies
>>>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>>>> connection factories and queues [Specific to Geronimo]
>>>>>>>
>>>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>>>
>>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>>>> domain [Common to SCA]
>>>>>>> * Resolve the wirings at SCA domain level for the top-level
>>>>>>> composites [Common to SCA]
>>>>>>> * Deploy the resolved composite image to a in-process or remote host
>>>>>>> [A Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>>>
>>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>>>
>>>>>>> I think we should only try to implement a feature in a
>>>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raymond
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>>>> features we need. For example, how about one goal be running in Geronimo the
>>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>>>> SCA JEE spec.
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>> [1]
>>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>>
>>>>>
>>>>> Any comments on this or does silence mean that example from the JEE
>>>>> spec is an ok use case to be working towards for our first try at the new
>>>>> Geronimo integration?
>>>>>
>>>>> ...ant
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 19, 2008 at 4:37 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Sat, Aug 16, 2008 at 8:42 AM, ant elder <an...@apache.org> wrote:
>
>> One thing I think could be better is the way applications get hold of the
>> ComponentContext. Currently its done using a context attribute but I think
>> it may be better to have something like a static method
>> o.a.t.s.api.ComponentContext.getComponentContext() that returns the
>> ComponentContext for the current thread. We could implement that by having
>> the Tuscany Servlet Filter put the current ComponentContext in a thread
>> local for the getComponentContext to use. That also has the advantage as
>> conversational services would work transparently to the user code whereas
>> right now (if conversational webapps worked) they'd have to know to pull the
>> ComponentContext from the Servlet request instead of the Servlet context.
>>
>> ...ant
>>
>> On Sat, Aug 16, 2008 at 1:57 AM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> Nice document. I'll try a few samples before I can give any feedback.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> *From:* ant elder <an...@gmail.com>
>>> *Sent:* Wednesday, August 13, 2008 11:38 PM
>>> *To:* dev@tuscany.apache.org
>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>> support in the Geronimo admin Console
>>>
>>> FYI, there is now some doc on the current state of implementation.web at
>>> http://tuscany.apache.org/sca-java-implementationweb.html and samples
>>> demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and
>>> helloworld-web.
>>>
>>> Would be great to start trying to integrate this with some of the JEE
>>> introspection code thats been added recently, is there any doc on that or
>>> explanations of how it could be used?
>>>
>>> ...ant
>>>
>>> On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
>>>
>>>> While thats being done I'd like to do some more work on
>>>> implementation.web and section 5.4 of the sca jee spec. I'd already started
>>>> on this a while back but now i'd like to getting it going properly
>>>> intergrated in to the build and our existing runtime support. Eventually i'd
>>>> like webapps and implementation.web to support using the Tuscany distributed
>>>> domain but it will take some smaller steps before it gets to there.
>>>>
>>>> ...ant
>>>>
>>>> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <
>>>> c1vamsi1c@gmail.com> wrote:
>>>>
>>>>> As a first step towards the integration, here are some items that I
>>>>> have identified with Raymond and Sebastien's help (Raymond, Sebastien,
>>>>> please correct me if I failed to capture the essence):
>>>>>
>>>>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean,
>>>>> given a Java EE archive (non-SCA-enhanced for now), compute by introspecting
>>>>> the archive, the SCA composite that represents the archive as an SCA
>>>>> contribution as per SCA JEE Integration Spec [1]. In this step, all the
>>>>> business interfaces implemented by session beans result in SCA services and
>>>>> all the EJB references (used in session beans, MDBs and web components)
>>>>> result in SCA references.
>>>>>
>>>>> 2. Get binding.ejb work with services. Currently binding.ejb works only
>>>>> with references. Once binding.ejb works with services, the references
>>>>> computed in step 1 above can be wired to the services in the domain using
>>>>> ejb binding.
>>>>>
>>>>> 3. Common Administration view. Once a JEE contribution is added to a
>>>>> domain, it should be administrable like any other SCA contribution. The
>>>>> fact that the contribution may actually be run as a Java EE application on a
>>>>> Java EE server should be transparent to the administrator.
>>>>>
>>>>> These three items should enable the coverage of scenarios 2.1-2.3 in
>>>>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
>>>>> this.
>>>>>
>>>>> I have done a little bit of experimentation with EJB jars. Using
>>>>> openejb-core and openejb-jee modules, it seems fairly simple to introspect
>>>>> EJB3 jars (even though I already ran into some glitches with the interface
>>>>> definitions). Will post to the list soon on my findings.
>>>>>
>>>>> ++Vamsi
>>>>>
>>>>> [1]
>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>
>>>>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Ok, from the initial email there were only two points labelled [Common
>>>>>> to SCA]:
>>>>>>
>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>>> domain [Common to SCA]
>>>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>>>> [Common to SCA]
>>>>>>
>>>>>> and all the other points are labelled [Specific to Geronimo]. I guess
>>>>>> on the surface of it that all sounds fine to me as long as [Common to SCA]
>>>>>> means its the APIs and code behind the APIs which are provided in a common
>>>>>> way by Tuscany. For something like the GSoC project doing the Geronimo
>>>>>> console management plugin that still needs to elements to be specific to
>>>>>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's good to add the use cases from SCA/JEE spec into this
>>>>>>> discussion. But I want to make sure the purpose of this thread is to
>>>>>>> identify what's common to SCA in all hosting environment and what's specific
>>>>>>> to Geronimo. Base on the classification, we should implement the common
>>>>>>> features in a generic way and specific things in a Geronimo way.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raymond
>>>>>>>
>>>>>>> *From:* ant elder <an...@gmail.com>
>>>>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>>>>>> *To:* dev@tuscany.apache.org
>>>>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to
>>>>>>> SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>>>>>> support in the Geronimo admin Console
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I would like to extend the discussion a bit to help us better
>>>>>>>>> understand what user experience we would like to bring to Geronimo
>>>>>>>>> developers/users with Tuscany/SCA.
>>>>>>>>>
>>>>>>>>> I suggest that we use a usage scenario-driven approach to create a
>>>>>>>>> list of tasks/features and mark them either it's common to SCA independent
>>>>>>>>> of the hosting environment or it's specific to Geronimo.
>>>>>>>>>
>>>>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>>>>>
>>>>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA
>>>>>>>>> applications
>>>>>>>>>
>>>>>>>>> * Connect to the SCA domain admin app to get the image of a
>>>>>>>>> resolved composite application
>>>>>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>>>>>> * Run the resolved composite application
>>>>>>>>> * Provide the binding/implementation/policy extensions to realize
>>>>>>>>> SCA binding/implementation/policy types.[[Specific to Geronimo]
>>>>>>>>> * Hook with the other containers in Geronimo to provide various
>>>>>>>>> bindings, such as HTTP connectors with Tomcat
>>>>>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>>>>>> Geronimo to implement the SCA policies
>>>>>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>>>>>> connection factories and queues [Specific to Geronimo]
>>>>>>>>>
>>>>>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>>>>>
>>>>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a
>>>>>>>>> SCA domain [Common to SCA]
>>>>>>>>> * Resolve the wirings at SCA domain level for the top-level
>>>>>>>>> composites [Common to SCA]
>>>>>>>>> * Deploy the resolved composite image to a in-process or remote
>>>>>>>>> host [A Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>>>>>
>>>>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>>>>>
>>>>>>>>> I think we should only try to implement a feature in a
>>>>>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Raymond
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>>>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>>>>>> features we need. For example, how about one goal be running in Geronimo the
>>>>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>>>>>> SCA JEE spec.
>>>>>>>>
>>>>>>>> ...ant
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>>>>
>>>>>>>
>>>>>>> Any comments on this or does silence mean that example from the JEE
>>>>>>> spec is an ok use case to be working towards for our first try at the new
>>>>>>> Geronimo integration?
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> Hi
>
> The SCA JEE spec [1] does say we have to support @Context for
> implementation.web although the first time it's mentioned it's not clear if
> it means ComponentContext or RequestContext. Your suggestion sounds like you
> are making the ComponentContext request specific. Is that becomming a
> RequestContext?
>
> Can you say a little more about how this might help with conversations?
> Each call to ComponetContext.getServiceReference() is intended to start a
> new conversation so regardless of where you get the component context from
> you are going to have to cache service references independently if you want
> to continue the conversation across HTTP servlet requests. Maybe that's not
> what you are getting at.
>
> The JEE spec does talk about threads and conversations but I've read it a
> couple of times and it doean't make sense to me either in the context of
> cross service request calls. Maybe they did this on purpose as they assume
> that service references are cached out of band in this situation.
>
> Simon
>
> [1]
> http://www.oasis-open.org/committees/download.php/28799/SCA_JAVAEE_Integration_V100.doc
>
We don't support conversations in webapp clients right now, and i agree the
spec isn't that clear, so i've not thought much at all about how we could
support it, we'll probably need a way to get at both the ComponentContext
and RequestContext. What i was asking about was if there is any preference
to use a method like getComponentContext()/getRequestContext() over using
the context attributes directly?
...ant
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Aug 16, 2008 at 8:42 AM, ant elder <an...@apache.org> wrote:
> One thing I think could be better is the way applications get hold of the
> ComponentContext. Currently its done using a context attribute but I think
> it may be better to have something like a static method
> o.a.t.s.api.ComponentContext.getComponentContext() that returns the
> ComponentContext for the current thread. We could implement that by having
> the Tuscany Servlet Filter put the current ComponentContext in a thread
> local for the getComponentContext to use. That also has the advantage as
> conversational services would work transparently to the user code whereas
> right now (if conversational webapps worked) they'd have to know to pull the
> ComponentContext from the Servlet request instead of the Servlet context.
>
> ...ant
>
> On Sat, Aug 16, 2008 at 1:57 AM, Raymond Feng <en...@gmail.com> wrote:
>
>> Nice document. I'll try a few samples before I can give any feedback.
>>
>> Thanks,
>> Raymond
>>
>> *From:* ant elder <an...@gmail.com>
>> *Sent:* Wednesday, August 13, 2008 11:38 PM
>> *To:* dev@tuscany.apache.org
>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>> support in the Geronimo admin Console
>>
>> FYI, there is now some doc on the current state of implementation.web at
>> http://tuscany.apache.org/sca-java-implementationweb.html and samples
>> demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and
>> helloworld-web.
>>
>> Would be great to start trying to integrate this with some of the JEE
>> introspection code thats been added recently, is there any doc on that or
>> explanations of how it could be used?
>>
>> ...ant
>>
>> On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
>>
>>> While thats being done I'd like to do some more work on
>>> implementation.web and section 5.4 of the sca jee spec. I'd already started
>>> on this a while back but now i'd like to getting it going properly
>>> intergrated in to the build and our existing runtime support. Eventually i'd
>>> like webapps and implementation.web to support using the Tuscany distributed
>>> domain but it will take some smaller steps before it gets to there.
>>>
>>> ...ant
>>>
>>> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <
>>> c1vamsi1c@gmail.com> wrote:
>>>
>>>> As a first step towards the integration, here are some items that I have
>>>> identified with Raymond and Sebastien's help (Raymond, Sebastien, please
>>>> correct me if I failed to capture the essence):
>>>>
>>>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean,
>>>> given a Java EE archive (non-SCA-enhanced for now), compute by introspecting
>>>> the archive, the SCA composite that represents the archive as an SCA
>>>> contribution as per SCA JEE Integration Spec [1]. In this step, all the
>>>> business interfaces implemented by session beans result in SCA services and
>>>> all the EJB references (used in session beans, MDBs and web components)
>>>> result in SCA references.
>>>>
>>>> 2. Get binding.ejb work with services. Currently binding.ejb works only
>>>> with references. Once binding.ejb works with services, the references
>>>> computed in step 1 above can be wired to the services in the domain using
>>>> ejb binding.
>>>>
>>>> 3. Common Administration view. Once a JEE contribution is added to a
>>>> domain, it should be administrable like any other SCA contribution. The
>>>> fact that the contribution may actually be run as a Java EE application on a
>>>> Java EE server should be transparent to the administrator.
>>>>
>>>> These three items should enable the coverage of scenarios 2.1-2.3 in
>>>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
>>>> this.
>>>>
>>>> I have done a little bit of experimentation with EJB jars. Using
>>>> openejb-core and openejb-jee modules, it seems fairly simple to introspect
>>>> EJB3 jars (even though I already ran into some glitches with the interface
>>>> definitions). Will post to the list soon on my findings.
>>>>
>>>> ++Vamsi
>>>>
>>>> [1]
>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>
>>>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org>
>>>> wrote:
>>>>
>>>>> Ok, from the initial email there were only two points labelled [Common
>>>>> to SCA]:
>>>>>
>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>> domain [Common to SCA]
>>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>>> [Common to SCA]
>>>>>
>>>>> and all the other points are labelled [Specific to Geronimo]. I guess
>>>>> on the surface of it that all sounds fine to me as long as [Common to SCA]
>>>>> means its the APIs and code behind the APIs which are provided in a common
>>>>> way by Tuscany. For something like the GSoC project doing the Geronimo
>>>>> console management plugin that still needs to elements to be specific to
>>>>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's good to add the use cases from SCA/JEE spec into this discussion.
>>>>>> But I want to make sure the purpose of this thread is to identify what's
>>>>>> common to SCA in all hosting environment and what's specific to Geronimo.
>>>>>> Base on the classification, we should implement the common features in a
>>>>>> generic way and specific things in a Geronimo way.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>> *From:* ant elder <an...@gmail.com>
>>>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>>>>> *To:* dev@tuscany.apache.org
>>>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to
>>>>>> SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>>>>> support in the Geronimo admin Console
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to extend the discussion a bit to help us better
>>>>>>>> understand what user experience we would like to bring to Geronimo
>>>>>>>> developers/users with Tuscany/SCA.
>>>>>>>>
>>>>>>>> I suggest that we use a usage scenario-driven approach to create a
>>>>>>>> list of tasks/features and mark them either it's common to SCA independent
>>>>>>>> of the hosting environment or it's specific to Geronimo.
>>>>>>>>
>>>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>>>>
>>>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA
>>>>>>>> applications
>>>>>>>>
>>>>>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>>>>>> composite application
>>>>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>>>>> * Run the resolved composite application
>>>>>>>> * Provide the binding/implementation/policy extensions to realize
>>>>>>>> SCA binding/implementation/policy types.[[Specific to Geronimo]
>>>>>>>> * Hook with the other containers in Geronimo to provide various
>>>>>>>> bindings, such as HTTP connectors with Tomcat
>>>>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>>>>> Geronimo to implement the SCA policies
>>>>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>>>>> connection factories and queues [Specific to Geronimo]
>>>>>>>>
>>>>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>>>>
>>>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a
>>>>>>>> SCA domain [Common to SCA]
>>>>>>>> * Resolve the wirings at SCA domain level for the top-level
>>>>>>>> composites [Common to SCA]
>>>>>>>> * Deploy the resolved composite image to a in-process or remote host
>>>>>>>> [A Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>>>>
>>>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>>>>
>>>>>>>> I think we should only try to implement a feature in a
>>>>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Raymond
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>>>>> features we need. For example, how about one goal be running in Geronimo the
>>>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>>>>> SCA JEE spec.
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>> [1]
>>>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>>>
>>>>>>
>>>>>> Any comments on this or does silence mean that example from the JEE
>>>>>> spec is an ok use case to be working towards for our first try at the new
>>>>>> Geronimo integration?
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Hi
The SCA JEE spec [1] does say we have to support @Context for
implementation.web although the first time it's mentioned it's not clear if
it means ComponentContext or RequestContext. Your suggestion sounds like you
are making the ComponentContext request specific. Is that becomming a
RequestContext?
Can you say a little more about how this might help with conversations? Each
call to ComponetContext.getServiceReference() is intended to start a new
conversation so regardless of where you get the component context from you
are going to have to cache service references independently if you want to
continue the conversation across HTTP servlet requests. Maybe that's not
what you are getting at.
The JEE spec does talk about threads and conversations but I've read it a
couple of times and it doean't make sense to me either in the context of
cross service request calls. Maybe they did this on purpose as they assume
that service references are cached out of band in this situation.
Simon
[1]
http://www.oasis-open.org/committees/download.php/28799/SCA_JAVAEE_Integration_V100.doc
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@apache.org>.
One thing I think could be better is the way applications get hold of the
ComponentContext. Currently its done using a context attribute but I think
it may be better to have something like a static method
o.a.t.s.api.ComponentContext.getComponentContext() that returns the
ComponentContext for the current thread. We could implement that by having
the Tuscany Servlet Filter put the current ComponentContext in a thread
local for the getComponentContext to use. That also has the advantage as
conversational services would work transparently to the user code whereas
right now (if conversational webapps worked) they'd have to know to pull the
ComponentContext from the Servlet request instead of the Servlet context.
...ant
On Sat, Aug 16, 2008 at 1:57 AM, Raymond Feng <en...@gmail.com> wrote:
> Nice document. I'll try a few samples before I can give any feedback.
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@gmail.com>
> *Sent:* Wednesday, August 13, 2008 11:38 PM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA and
> what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in
> the Geronimo admin Console
>
> FYI, there is now some doc on the current state of implementation.web at
> http://tuscany.apache.org/sca-java-implementationweb.html and samples
> demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and
> helloworld-web.
>
> Would be great to start trying to integrate this with some of the JEE
> introspection code thats been added recently, is there any doc on that or
> explanations of how it could be used?
>
> ...ant
>
> On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
>
>> While thats being done I'd like to do some more work on implementation.web
>> and section 5.4 of the sca jee spec. I'd already started on this a while
>> back but now i'd like to getting it going properly intergrated in to the
>> build and our existing runtime support. Eventually i'd like webapps and
>> implementation.web to support using the Tuscany distributed domain but it
>> will take some smaller steps before it gets to there.
>>
>> ...ant
>>
>> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <c1vamsi1c@gmail.com
>> > wrote:
>>
>>> As a first step towards the integration, here are some items that I have
>>> identified with Raymond and Sebastien's help (Raymond, Sebastien, please
>>> correct me if I failed to capture the essence):
>>>
>>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given
>>> a Java EE archive (non-SCA-enhanced for now), compute by introspecting the
>>> archive, the SCA composite that represents the archive as an SCA
>>> contribution as per SCA JEE Integration Spec [1]. In this step, all the
>>> business interfaces implemented by session beans result in SCA services and
>>> all the EJB references (used in session beans, MDBs and web components)
>>> result in SCA references.
>>>
>>> 2. Get binding.ejb work with services. Currently binding.ejb works only
>>> with references. Once binding.ejb works with services, the references
>>> computed in step 1 above can be wired to the services in the domain using
>>> ejb binding.
>>>
>>> 3. Common Administration view. Once a JEE contribution is added to a
>>> domain, it should be administrable like any other SCA contribution. The
>>> fact that the contribution may actually be run as a Java EE application on a
>>> Java EE server should be transparent to the administrator.
>>>
>>> These three items should enable the coverage of scenarios 2.1-2.3 in
>>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
>>> this.
>>>
>>> I have done a little bit of experimentation with EJB jars. Using
>>> openejb-core and openejb-jee modules, it seems fairly simple to introspect
>>> EJB3 jars (even though I already ran into some glitches with the interface
>>> definitions). Will post to the list soon on my findings.
>>>
>>> ++Vamsi
>>>
>>> [1]
>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>
>>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
>>>
>>>> Ok, from the initial email there were only two points labelled [Common
>>>> to SCA]:
>>>>
>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>> domain [Common to SCA]
>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>> [Common to SCA]
>>>>
>>>> and all the other points are labelled [Specific to Geronimo]. I guess on
>>>> the surface of it that all sounds fine to me as long as [Common to SCA]
>>>> means its the APIs and code behind the APIs which are provided in a common
>>>> way by Tuscany. For something like the GSoC project doing the Geronimo
>>>> console management plugin that still needs to elements to be specific to
>>>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>>>
>>>> ...ant
>>>>
>>>>
>>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's good to add the use cases from SCA/JEE spec into this discussion.
>>>>> But I want to make sure the purpose of this thread is to identify what's
>>>>> common to SCA in all hosting environment and what's specific to Geronimo.
>>>>> Base on the classification, we should implement the common features in a
>>>>> generic way and specific things in a Geronimo way.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> *From:* ant elder <an...@gmail.com>
>>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>>>> *To:* dev@tuscany.apache.org
>>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>>>>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>>>> support in the Geronimo admin Console
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to extend the discussion a bit to help us better
>>>>>>> understand what user experience we would like to bring to Geronimo
>>>>>>> developers/users with Tuscany/SCA.
>>>>>>>
>>>>>>> I suggest that we use a usage scenario-driven approach to create a
>>>>>>> list of tasks/features and mark them either it's common to SCA independent
>>>>>>> of the hosting environment or it's specific to Geronimo.
>>>>>>>
>>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>>>
>>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA
>>>>>>> applications
>>>>>>>
>>>>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>>>>> composite application
>>>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>>>> * Run the resolved composite application
>>>>>>> * Provide the binding/implementation/policy extensions to realize SCA
>>>>>>> binding/implementation/policy types.[[Specific to Geronimo]
>>>>>>> * Hook with the other containers in Geronimo to provide various
>>>>>>> bindings, such as HTTP connectors with Tomcat
>>>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>>>> Geronimo to implement the SCA policies
>>>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>>>> connection factories and queues [Specific to Geronimo]
>>>>>>>
>>>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>>>
>>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>>>> domain [Common to SCA]
>>>>>>> * Resolve the wirings at SCA domain level for the top-level
>>>>>>> composites [Common to SCA]
>>>>>>> * Deploy the resolved composite image to a in-process or remote host
>>>>>>> [A Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>>>
>>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>>>
>>>>>>> I think we should only try to implement a feature in a
>>>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raymond
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>>>> features we need. For example, how about one goal be running in Geronimo the
>>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>>>> SCA JEE spec.
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>> [1]
>>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>>
>>>>>
>>>>> Any comments on this or does silence mean that example from the JEE
>>>>> spec is an ok use case to be working towards for our first try at the new
>>>>> Geronimo integration?
>>>>>
>>>>> ...ant
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Raymond Feng <en...@gmail.com>.
Nice document. I'll try a few samples before I can give any feedback.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, August 13, 2008 11:38 PM
To: dev@tuscany.apache.org
Subject: Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
FYI, there is now some doc on the current state of implementation.web at http://tuscany.apache.org/sca-java-implementationweb.html and samples demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and helloworld-web.
Would be great to start trying to integrate this with some of the JEE introspection code thats been added recently, is there any doc on that or explanations of how it could be used?
...ant
On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
While thats being done I'd like to do some more work on implementation.web and section 5.4 of the sca jee spec. I'd already started on this a while back but now i'd like to getting it going properly intergrated in to the build and our existing runtime support. Eventually i'd like webapps and implementation.web to support using the Tuscany distributed domain but it will take some smaller steps before it gets to there.
...ant
On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <c1...@gmail.com> wrote:
As a first step towards the integration, here are some items that I have identified with Raymond and Sebastien's help (Raymond, Sebastien, please correct me if I failed to capture the essence):
1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given a Java EE archive (non-SCA-enhanced for now), compute by introspecting the archive, the SCA composite that represents the archive as an SCA contribution as per SCA JEE Integration Spec [1]. In this step, all the business interfaces implemented by session beans result in SCA services and all the EJB references (used in session beans, MDBs and web components) result in SCA references.
2. Get binding.ejb work with services. Currently binding.ejb works only with references. Once binding.ejb works with services, the references computed in step 1 above can be wired to the services in the domain using ejb binding.
3. Common Administration view. Once a JEE contribution is added to a domain, it should be administrable like any other SCA contribution. The fact that the contribution may actually be run as a Java EE application on a Java EE server should be transparent to the administrator.
These three items should enable the coverage of scenarios 2.1-2.3 in section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in this.
I have done a little bit of experimentation with EJB jars. Using openejb-core and openejb-jee modules, it seems fairly simple to introspect EJB3 jars (even though I already ran into some glitches with the interface definitions). Will post to the list soon on my findings.
++Vamsi
[1] http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
Ok, from the initial email there were only two points labelled [Common to SCA]:
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain [Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites [Common to SCA]
and all the other points are labelled [Specific to Geronimo]. I guess on the surface of it that all sounds fine to me as long as [Common to SCA] means its the APIs and code behind the APIs which are provided in a common way by Tuscany. For something like the GSoC project doing the Geronimo console management plugin that still needs to elements to be specific to Geronimo to be integrated as part of the Geronimo admin console doesn't it?
...ant
On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
It's good to add the use cases from SCA/JEE spec into this discussion. But I want to make sure the purpose of this thread is to identify what's common to SCA in all hosting environment and what's specific to Geronimo. Base on the classification, we should implement the common features in a generic way and specific things in a Geronimo way.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, July 09, 2008 12:56 AM
To: dev@tuscany.apache.org
Subject: Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I would like to extend the discussion a bit to help us better understand what user experience we would like to bring to Geronimo developers/users with Tuscany/SCA.
I suggest that we use a usage scenario-driven approach to create a list of tasks/features and mark them either it's common to SCA independent of the hosting environment or it's specific to Geronimo.
Here is a few roles a Geronimo instance can play in the SCA domain:
1) Geronimo is a member of a SCA domain to deploy/run SCA applications
* Connect to the SCA domain admin app to get the image of a resolved composite application
* Be able to deploy the resolved composite application in the VM of Geronimo, either as JEE application or standalone [Specific to Geronimo]
* Run the resolved composite application
* Provide the binding/implementation/policy extensions to realize SCA binding/implementation/policy types.[[Specific to Geronimo]
* Hook with the other containers in Geronimo to provide various bindings, such as HTTP connectors with Tomcat
* Hook with the QoSs such Transaction and Security provided by Geronimo to implement the SCA policies
* Create/manage related resources for some bindings, such as JMS connection factories and queues [Specific to Geronimo]
2) Geronimo hosts the SCA domain admin application
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain [Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites [Common to SCA]
* Deploy the resolved composite image to a in-process or remote host [A Geronimo or JSR88 Deployer may be specific to Geronimo]
3) Geronimo hosts (some) contributions for a SCA domain
* Expose them as URLs to the SCA domain admin application. In this case, It functions as a repo for SCA contributions. [Specific to Geronimo]
I think we should only try to implement a feature in a geronimo-specific way only if it's specific to Geronimo.
Thanks,
Raymond
Now that the 1.0 version of the SCA JEE spec [1] is out that defines several concrete use cases and scenarios we can use to define the tasks and features we need. For example, how about one goal be running in Geronimo the application.ear shown at line 1131 page 41 "Appendix A – use cases" of the SCA JEE spec.
...ant
[1] http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
Any comments on this or does silence mean that example from the JEE spec is an ok use case to be working towards for our first try at the new Geronimo integration?
...ant
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@gmail.com>.
FYI, there is now some doc on the current state of implementation.web at
http://tuscany.apache.org/sca-java-implementationweb.html and samples
demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and
helloworld-web.
Would be great to start trying to integrate this with some of the JEE
introspection code thats been added recently, is there any doc on that or
explanations of how it could be used?
...ant
On Mon, Jul 28, 2008 at 12:15 PM, ant elder <an...@gmail.com> wrote:
> While thats being done I'd like to do some more work on implementation.web
> and section 5.4 of the sca jee spec. I'd already started on this a while
> back but now i'd like to getting it going properly intergrated in to the
> build and our existing runtime support. Eventually i'd like webapps and
> implementation.web to support using the Tuscany distributed domain but it
> will take some smaller steps before it gets to there.
>
> ...ant
>
> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <c1...@gmail.com>wrote:
>
>> As a first step towards the integration, here are some items that I have
>> identified with Raymond and Sebastien's help (Raymond, Sebastien, please
>> correct me if I failed to capture the essence):
>>
>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given
>> a Java EE archive (non-SCA-enhanced for now), compute by introspecting the
>> archive, the SCA composite that represents the archive as an SCA
>> contribution as per SCA JEE Integration Spec [1]. In this step, all the
>> business interfaces implemented by session beans result in SCA services and
>> all the EJB references (used in session beans, MDBs and web components)
>> result in SCA references.
>>
>> 2. Get binding.ejb work with services. Currently binding.ejb works only
>> with references. Once binding.ejb works with services, the references
>> computed in step 1 above can be wired to the services in the domain using
>> ejb binding.
>>
>> 3. Common Administration view. Once a JEE contribution is added to a
>> domain, it should be administrable like any other SCA contribution. The
>> fact that the contribution may actually be run as a Java EE application on a
>> Java EE server should be transparent to the administrator.
>>
>> These three items should enable the coverage of scenarios 2.1-2.3 in
>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
>> this.
>>
>> I have done a little bit of experimentation with EJB jars. Using
>> openejb-core and openejb-jee modules, it seems fairly simple to introspect
>> EJB3 jars (even though I already ran into some glitches with the interface
>> definitions). Will post to the list soon on my findings.
>>
>> ++Vamsi
>>
>> [1]
>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>
>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
>>
>>> Ok, from the initial email there were only two points labelled [Common to
>>> SCA]:
>>>
>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>> domain [Common to SCA]
>>> * Resolve the wirings at SCA domain level for the top-level composites
>>> [Common to SCA]
>>>
>>> and all the other points are labelled [Specific to Geronimo]. I guess on
>>> the surface of it that all sounds fine to me as long as [Common to SCA]
>>> means its the APIs and code behind the APIs which are provided in a common
>>> way by Tuscany. For something like the GSoC project doing the Geronimo
>>> console management plugin that still needs to elements to be specific to
>>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>>
>>> ...ant
>>>
>>>
>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> It's good to add the use cases from SCA/JEE spec into this discussion.
>>>> But I want to make sure the purpose of this thread is to identify what's
>>>> common to SCA in all hosting environment and what's specific to Geronimo.
>>>> Base on the classification, we should implement the common features in a
>>>> generic way and specific things in a Geronimo way.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> *From:* ant elder <an...@gmail.com>
>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>>> *To:* dev@tuscany.apache.org
>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>>>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>>> support in the Geronimo admin Console
>>>>
>>>>
>>>>
>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to extend the discussion a bit to help us better
>>>>>> understand what user experience we would like to bring to Geronimo
>>>>>> developers/users with Tuscany/SCA.
>>>>>>
>>>>>> I suggest that we use a usage scenario-driven approach to create a
>>>>>> list of tasks/features and mark them either it's common to SCA independent
>>>>>> of the hosting environment or it's specific to Geronimo.
>>>>>>
>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>>
>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>>>>
>>>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>>>> composite application
>>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>>> * Run the resolved composite application
>>>>>> * Provide the binding/implementation/policy extensions to realize SCA
>>>>>> binding/implementation/policy types.[[Specific to Geronimo]
>>>>>> * Hook with the other containers in Geronimo to provide various
>>>>>> bindings, such as HTTP connectors with Tomcat
>>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>>> Geronimo to implement the SCA policies
>>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>>> connection factories and queues [Specific to Geronimo]
>>>>>>
>>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>>
>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>>> domain [Common to SCA]
>>>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>>>> [Common to SCA]
>>>>>> * Deploy the resolved composite image to a in-process or remote host
>>>>>> [A Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>>
>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>>
>>>>>> I think we should only try to implement a feature in a
>>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>>
>>>>>>
>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>>> features we need. For example, how about one goal be running in Geronimo the
>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>>> SCA JEE spec.
>>>>>
>>>>> ...ant
>>>>>
>>>>> [1]
>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>>
>>>>
>>>> Any comments on this or does silence mean that example from the JEE spec
>>>> is an ok use case to be working towards for our first try at the new
>>>> Geronimo integration?
>>>>
>>>> ...ant
>>>>
>>>
>>>
>>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@gmail.com>.
While thats being done I'd like to do some more work on implementation.web
and section 5.4 of the sca jee spec. I'd already started on this a while
back but now i'd like to getting it going properly intergrated in to the
build and our existing runtime support. Eventually i'd like webapps and
implementation.web to support using the Tuscany distributed domain but it
will take some smaller steps before it gets to there.
...ant
On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy <c1...@gmail.com>wrote:
> As a first step towards the integration, here are some items that I have
> identified with Raymond and Sebastien's help (Raymond, Sebastien, please
> correct me if I failed to capture the essence):
>
> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given a
> Java EE archive (non-SCA-enhanced for now), compute by introspecting the
> archive, the SCA composite that represents the archive as an SCA
> contribution as per SCA JEE Integration Spec [1]. In this step, all the
> business interfaces implemented by session beans result in SCA services and
> all the EJB references (used in session beans, MDBs and web components)
> result in SCA references.
>
> 2. Get binding.ejb work with services. Currently binding.ejb works only
> with references. Once binding.ejb works with services, the references
> computed in step 1 above can be wired to the services in the domain using
> ejb binding.
>
> 3. Common Administration view. Once a JEE contribution is added to a
> domain, it should be administrable like any other SCA contribution. The
> fact that the contribution may actually be run as a Java EE application on a
> Java EE server should be transparent to the administrator.
>
> These three items should enable the coverage of scenarios 2.1-2.3 in
> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in
> this.
>
> I have done a little bit of experimentation with EJB jars. Using
> openejb-core and openejb-jee modules, it seems fairly simple to introspect
> EJB3 jars (even though I already ran into some glitches with the interface
> definitions). Will post to the list soon on my findings.
>
> ++Vamsi
>
> [1]
> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>
> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
>
>> Ok, from the initial email there were only two points labelled [Common to
>> SCA]:
>>
>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>> domain [Common to SCA]
>> * Resolve the wirings at SCA domain level for the top-level composites
>> [Common to SCA]
>>
>> and all the other points are labelled [Specific to Geronimo]. I guess on
>> the surface of it that all sounds fine to me as long as [Common to SCA]
>> means its the APIs and code behind the APIs which are provided in a common
>> way by Tuscany. For something like the GSoC project doing the Geronimo
>> console management plugin that still needs to elements to be specific to
>> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>>
>> ...ant
>>
>>
>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> It's good to add the use cases from SCA/JEE spec into this discussion.
>>> But I want to make sure the purpose of this thread is to identify what's
>>> common to SCA in all hosting environment and what's specific to Geronimo.
>>> Base on the classification, we should implement the common features in a
>>> generic way and specific things in a Geronimo way.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> *From:* ant elder <an...@gmail.com>
>>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>>> *To:* dev@tuscany.apache.org
>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>>> support in the Geronimo admin Console
>>>
>>>
>>>
>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to extend the discussion a bit to help us better
>>>>> understand what user experience we would like to bring to Geronimo
>>>>> developers/users with Tuscany/SCA.
>>>>>
>>>>> I suggest that we use a usage scenario-driven approach to create a list
>>>>> of tasks/features and mark them either it's common to SCA independent of the
>>>>> hosting environment or it's specific to Geronimo.
>>>>>
>>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>>
>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>>>
>>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>>> composite application
>>>>> * Be able to deploy the resolved composite application in the VM of
>>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>>> * Run the resolved composite application
>>>>> * Provide the binding/implementation/policy extensions to realize SCA
>>>>> binding/implementation/policy types.[[Specific to Geronimo]
>>>>> * Hook with the other containers in Geronimo to provide various
>>>>> bindings, such as HTTP connectors with Tomcat
>>>>> * Hook with the QoSs such Transaction and Security provided by
>>>>> Geronimo to implement the SCA policies
>>>>> * Create/manage related resources for some bindings, such as JMS
>>>>> connection factories and queues [Specific to Geronimo]
>>>>>
>>>>> 2) Geronimo hosts the SCA domain admin application
>>>>>
>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>>> domain [Common to SCA]
>>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>>> [Common to SCA]
>>>>> * Deploy the resolved composite image to a in-process or remote host [A
>>>>> Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>>
>>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>>> * Expose them as URLs to the SCA domain admin application. In this
>>>>> case, It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>>
>>>>> I think we should only try to implement a feature in a
>>>>> geronimo-specific way only if it's specific to Geronimo.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>>
>>>>>
>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>>> several concrete use cases and scenarios we can use to define the tasks and
>>>> features we need. For example, how about one goal be running in Geronimo the
>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>>> SCA JEE spec.
>>>>
>>>> ...ant
>>>>
>>>> [1]
>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>>
>>>
>>> Any comments on this or does silence mean that example from the JEE spec
>>> is an ok use case to be working towards for our first try at the new
>>> Geronimo integration?
>>>
>>> ...ant
>>>
>>
>>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Raymond Feng <en...@gmail.com>.
Hi, Vamsi.
Have you been able to make progress in this area? A quick update will be appreciated.
Thanks,
Raymond
From: Vamsavardhana Reddy
Sent: Friday, July 18, 2008 7:55 AM
To: dev@tuscany.apache.org ; ant.elder@gmail.com
Subject: Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
As a first step towards the integration, here are some items that I have identified with Raymond and Sebastien's help (Raymond, Sebastien, please correct me if I failed to capture the essence):
1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given a Java EE archive (non-SCA-enhanced for now), compute by introspecting the archive, the SCA composite that represents the archive as an SCA contribution as per SCA JEE Integration Spec [1]. In this step, all the business interfaces implemented by session beans result in SCA services and all the EJB references (used in session beans, MDBs and web components) result in SCA references.
2. Get binding.ejb work with services. Currently binding.ejb works only with references. Once binding.ejb works with services, the references computed in step 1 above can be wired to the services in the domain using ejb binding.
3. Common Administration view. Once a JEE contribution is added to a domain, it should be administrable like any other SCA contribution. The fact that the contribution may actually be run as a Java EE application on a Java EE server should be transparent to the administrator.
These three items should enable the coverage of scenarios 2.1-2.3 in section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in this.
I have done a little bit of experimentation with EJB jars. Using openejb-core and openejb-jee modules, it seems fairly simple to introspect EJB3 jars (even though I already ran into some glitches with the interface definitions). Will post to the list soon on my findings.
++Vamsi
[1] http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
Ok, from the initial email there were only two points labelled [Common to SCA]:
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain [Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites [Common to SCA]
and all the other points are labelled [Specific to Geronimo]. I guess on the surface of it that all sounds fine to me as long as [Common to SCA] means its the APIs and code behind the APIs which are provided in a common way by Tuscany. For something like the GSoC project doing the Geronimo console management plugin that still needs to elements to be specific to Geronimo to be integrated as part of the Geronimo admin console doesn't it?
...ant
On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
It's good to add the use cases from SCA/JEE spec into this discussion. But I want to make sure the purpose of this thread is to identify what's common to SCA in all hosting environment and what's specific to Geronimo. Base on the classification, we should implement the common features in a generic way and specific things in a Geronimo way.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, July 09, 2008 12:56 AM
To: dev@tuscany.apache.org
Subject: Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I would like to extend the discussion a bit to help us better understand what user experience we would like to bring to Geronimo developers/users with Tuscany/SCA.
I suggest that we use a usage scenario-driven approach to create a list of tasks/features and mark them either it's common to SCA independent of the hosting environment or it's specific to Geronimo.
Here is a few roles a Geronimo instance can play in the SCA domain:
1) Geronimo is a member of a SCA domain to deploy/run SCA applications
* Connect to the SCA domain admin app to get the image of a resolved composite application
* Be able to deploy the resolved composite application in the VM of Geronimo, either as JEE application or standalone [Specific to Geronimo]
* Run the resolved composite application
* Provide the binding/implementation/policy extensions to realize SCA binding/implementation/policy types.[[Specific to Geronimo]
* Hook with the other containers in Geronimo to provide various bindings, such as HTTP connectors with Tomcat
* Hook with the QoSs such Transaction and Security provided by Geronimo to implement the SCA policies
* Create/manage related resources for some bindings, such as JMS connection factories and queues [Specific to Geronimo]
2) Geronimo hosts the SCA domain admin application
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain [Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites [Common to SCA]
* Deploy the resolved composite image to a in-process or remote host [A Geronimo or JSR88 Deployer may be specific to Geronimo]
3) Geronimo hosts (some) contributions for a SCA domain
* Expose them as URLs to the SCA domain admin application. In this case, It functions as a repo for SCA contributions. [Specific to Geronimo]
I think we should only try to implement a feature in a geronimo-specific way only if it's specific to Geronimo.
Thanks,
Raymond
Now that the 1.0 version of the SCA JEE spec [1] is out that defines several concrete use cases and scenarios we can use to define the tasks and features we need. For example, how about one goal be running in Geronimo the application.ear shown at line 1131 page 41 "Appendix A – use cases" of the SCA JEE spec.
...ant
[1] http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
Any comments on this or does silence mean that example from the JEE spec is an ok use case to be working towards for our first try at the new Geronimo integration?
...ant
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
As a first step towards the integration, here are some items that I have
identified with Raymond and Sebastien's help (Raymond, Sebastien, please
correct me if I failed to capture the essence):
1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, given a
Java EE archive (non-SCA-enhanced for now), compute by introspecting the
archive, the SCA composite that represents the archive as an SCA
contribution as per SCA JEE Integration Spec [1]. In this step, all the
business interfaces implemented by session beans result in SCA services and
all the EJB references (used in session beans, MDBs and web components)
result in SCA references.
2. Get binding.ejb work with services. Currently binding.ejb works only with
references. Once binding.ejb works with services, the references computed
in step 1 above can be wired to the services in the domain using ejb
binding.
3. Common Administration view. Once a JEE contribution is added to a
domain, it should be administrable like any other SCA contribution. The
fact that the contribution may actually be run as a Java EE application on a
Java EE server should be transparent to the administrator.
These three items should enable the coverage of scenarios 2.1-2.3 in section
2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in this.
I have done a little bit of experimentation with EJB jars. Using
openejb-core and openejb-jee modules, it seems fairly simple to introspect
EJB3 jars (even though I already ran into some glitches with the interface
definitions). Will post to the list soon on my findings.
++Vamsi
[1]
http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
On Wed, Jul 9, 2008 at 9:37 PM, ant elder <an...@apache.org> wrote:
> Ok, from the initial email there were only two points labelled [Common to
> SCA]:
>
> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
> domain [Common to SCA]
> * Resolve the wirings at SCA domain level for the top-level composites
> [Common to SCA]
>
> and all the other points are labelled [Specific to Geronimo]. I guess on
> the surface of it that all sounds fine to me as long as [Common to SCA]
> means its the APIs and code behind the APIs which are provided in a common
> way by Tuscany. For something like the GSoC project doing the Geronimo
> console management plugin that still needs to elements to be specific to
> Geronimo to be integrated as part of the Geronimo admin console doesn't it?
>
> ...ant
>
>
> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> It's good to add the use cases from SCA/JEE spec into this discussion. But
>> I want to make sure the purpose of this thread is to identify what's common
>> to SCA in all hosting environment and what's specific to Geronimo. Base on
>> the classification, we should implement the common features in a generic way
>> and specific things in a Geronimo way.
>>
>> Thanks,
>> Raymond
>>
>> *From:* ant elder <an...@gmail.com>
>> *Sent:* Wednesday, July 09, 2008 12:56 AM
>> *To:* dev@tuscany.apache.org
>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA
>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA
>> support in the Geronimo admin Console
>>
>>
>>
>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to extend the discussion a bit to help us better understand
>>>> what user experience we would like to bring to Geronimo developers/users
>>>> with Tuscany/SCA.
>>>>
>>>> I suggest that we use a usage scenario-driven approach to create a list
>>>> of tasks/features and mark them either it's common to SCA independent of the
>>>> hosting environment or it's specific to Geronimo.
>>>>
>>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>>
>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>>
>>>> * Connect to the SCA domain admin app to get the image of a resolved
>>>> composite application
>>>> * Be able to deploy the resolved composite application in the VM of
>>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>>> * Run the resolved composite application
>>>> * Provide the binding/implementation/policy extensions to realize SCA
>>>> binding/implementation/policy types.[[Specific to Geronimo]
>>>> * Hook with the other containers in Geronimo to provide various
>>>> bindings, such as HTTP connectors with Tomcat
>>>> * Hook with the QoSs such Transaction and Security provided by
>>>> Geronimo to implement the SCA policies
>>>> * Create/manage related resources for some bindings, such as JMS
>>>> connection factories and queues [Specific to Geronimo]
>>>>
>>>> 2) Geronimo hosts the SCA domain admin application
>>>>
>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>>> domain [Common to SCA]
>>>> * Resolve the wirings at SCA domain level for the top-level composites
>>>> [Common to SCA]
>>>> * Deploy the resolved composite image to a in-process or remote host [A
>>>> Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>>
>>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>>> * Expose them as URLs to the SCA domain admin application. In this case,
>>>> It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>>
>>>> I think we should only try to implement a feature in a geronimo-specific
>>>> way only if it's specific to Geronimo.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>>
>>>>
>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>>> several concrete use cases and scenarios we can use to define the tasks and
>>> features we need. For example, how about one goal be running in Geronimo the
>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>>> SCA JEE spec.
>>>
>>> ...ant
>>>
>>> [1]
>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>>
>>
>> Any comments on this or does silence mean that example from the JEE spec
>> is an ok use case to be working towards for our first try at the new
>> Geronimo integration?
>>
>> ...ant
>>
>
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@apache.org>.
Ok, from the initial email there were only two points labelled [Common to
SCA]:
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain
[Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites
[Common to SCA]
and all the other points are labelled [Specific to Geronimo]. I guess on the
surface of it that all sounds fine to me as long as [Common to SCA] means
its the APIs and code behind the APIs which are provided in a common way by
Tuscany. For something like the GSoC project doing the Geronimo console
management plugin that still needs to elements to be specific to Geronimo to
be integrated as part of the Geronimo admin console doesn't it?
...ant
On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> It's good to add the use cases from SCA/JEE spec into this discussion. But
> I want to make sure the purpose of this thread is to identify what's common
> to SCA in all hosting environment and what's specific to Geronimo. Base on
> the classification, we should implement the common features in a generic way
> and specific things in a Geronimo way.
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@gmail.com>
> *Sent:* Wednesday, July 09, 2008 12:56 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA and
> what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in
> the Geronimo admin Console
>
>
>
> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to extend the discussion a bit to help us better understand
>>> what user experience we would like to bring to Geronimo developers/users
>>> with Tuscany/SCA.
>>>
>>> I suggest that we use a usage scenario-driven approach to create a list
>>> of tasks/features and mark them either it's common to SCA independent of the
>>> hosting environment or it's specific to Geronimo.
>>>
>>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>>
>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>>
>>> * Connect to the SCA domain admin app to get the image of a resolved
>>> composite application
>>> * Be able to deploy the resolved composite application in the VM of
>>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>>> * Run the resolved composite application
>>> * Provide the binding/implementation/policy extensions to realize SCA
>>> binding/implementation/policy types.[[Specific to Geronimo]
>>> * Hook with the other containers in Geronimo to provide various
>>> bindings, such as HTTP connectors with Tomcat
>>> * Hook with the QoSs such Transaction and Security provided by Geronimo
>>> to implement the SCA policies
>>> * Create/manage related resources for some bindings, such as JMS
>>> connection factories and queues [Specific to Geronimo]
>>>
>>> 2) Geronimo hosts the SCA domain admin application
>>>
>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>>> domain [Common to SCA]
>>> * Resolve the wirings at SCA domain level for the top-level composites
>>> [Common to SCA]
>>> * Deploy the resolved composite image to a in-process or remote host [A
>>> Geronimo or JSR88 Deployer may be specific to Geronimo]
>>>
>>> 3) Geronimo hosts (some) contributions for a SCA domain
>>> * Expose them as URLs to the SCA domain admin application. In this case,
>>> It functions as a repo for SCA contributions. [Specific to Geronimo]
>>>
>>> I think we should only try to implement a feature in a geronimo-specific
>>> way only if it's specific to Geronimo.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>>>
>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
>> several concrete use cases and scenarios we can use to define the tasks and
>> features we need. For example, how about one goal be running in Geronimo the
>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
>> SCA JEE spec.
>>
>> ...ant
>>
>> [1]
>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>>
>
> Any comments on this or does silence mean that example from the JEE spec is
> an ok use case to be working towards for our first try at the new Geronimo
> integration?
>
> ...ant
>
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It's good to add the use cases from SCA/JEE spec into this discussion. But I want to make sure the purpose of this thread is to identify what's common to SCA in all hosting environment and what's specific to Geronimo. Base on the classification, we should implement the common features in a generic way and specific things in a Geronimo way.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, July 09, 2008 12:56 AM
To: dev@tuscany.apache.org
Subject: Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I would like to extend the discussion a bit to help us better understand what user experience we would like to bring to Geronimo developers/users with Tuscany/SCA.
I suggest that we use a usage scenario-driven approach to create a list of tasks/features and mark them either it's common to SCA independent of the hosting environment or it's specific to Geronimo.
Here is a few roles a Geronimo instance can play in the SCA domain:
1) Geronimo is a member of a SCA domain to deploy/run SCA applications
* Connect to the SCA domain admin app to get the image of a resolved composite application
* Be able to deploy the resolved composite application in the VM of Geronimo, either as JEE application or standalone [Specific to Geronimo]
* Run the resolved composite application
* Provide the binding/implementation/policy extensions to realize SCA binding/implementation/policy types.[[Specific to Geronimo]
* Hook with the other containers in Geronimo to provide various bindings, such as HTTP connectors with Tomcat
* Hook with the QoSs such Transaction and Security provided by Geronimo to implement the SCA policies
* Create/manage related resources for some bindings, such as JMS connection factories and queues [Specific to Geronimo]
2) Geronimo hosts the SCA domain admin application
* Manage the configuration (Contributions/Composites/Nodes) for a SCA domain [Common to SCA]
* Resolve the wirings at SCA domain level for the top-level composites [Common to SCA]
* Deploy the resolved composite image to a in-process or remote host [A Geronimo or JSR88 Deployer may be specific to Geronimo]
3) Geronimo hosts (some) contributions for a SCA domain
* Expose them as URLs to the SCA domain admin application. In this case, It functions as a repo for SCA contributions. [Specific to Geronimo]
I think we should only try to implement a feature in a geronimo-specific way only if it's specific to Geronimo.
Thanks,
Raymond
Now that the 1.0 version of the SCA JEE spec [1] is out that defines several concrete use cases and scenarios we can use to define the tasks and features we need. For example, how about one goal be running in Geronimo the application.ear shown at line 1131 page 41 "Appendix A – use cases" of the SCA JEE spec.
...ant
[1] http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
Any comments on this or does silence mean that example from the JEE spec is an ok use case to be working towards for our first try at the new Geronimo integration?
...ant
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 3, 2008 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> I would like to extend the discussion a bit to help us better understand
>> what user experience we would like to bring to Geronimo developers/users
>> with Tuscany/SCA.
>>
>> I suggest that we use a usage scenario-driven approach to create a list of
>> tasks/features and mark them either it's common to SCA independent of the
>> hosting environment or it's specific to Geronimo.
>>
>> Here is a few roles a Geronimo instance can play in the SCA domain:
>>
>> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>>
>> * Connect to the SCA domain admin app to get the image of a resolved
>> composite application
>> * Be able to deploy the resolved composite application in the VM of
>> Geronimo, either as JEE application or standalone [Specific to Geronimo]
>> * Run the resolved composite application
>> * Provide the binding/implementation/policy extensions to realize SCA
>> binding/implementation/policy types.[[Specific to Geronimo]
>> * Hook with the other containers in Geronimo to provide various
>> bindings, such as HTTP connectors with Tomcat
>> * Hook with the QoSs such Transaction and Security provided by Geronimo
>> to implement the SCA policies
>> * Create/manage related resources for some bindings, such as JMS
>> connection factories and queues [Specific to Geronimo]
>>
>> 2) Geronimo hosts the SCA domain admin application
>>
>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
>> domain [Common to SCA]
>> * Resolve the wirings at SCA domain level for the top-level composites
>> [Common to SCA]
>> * Deploy the resolved composite image to a in-process or remote host [A
>> Geronimo or JSR88 Deployer may be specific to Geronimo]
>>
>> 3) Geronimo hosts (some) contributions for a SCA domain
>> * Expose them as URLs to the SCA domain admin application. In this case,
>> It functions as a repo for SCA contributions. [Specific to Geronimo]
>>
>> I think we should only try to implement a feature in a geronimo-specific
>> way only if it's specific to Geronimo.
>>
>> Thanks,
>> Raymond
>>
>>
>>
> Now that the 1.0 version of the SCA JEE spec [1] is out that defines
> several concrete use cases and scenarios we can use to define the tasks and
> features we need. For example, how about one goal be running in Geronimo the
> application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
> SCA JEE spec.
>
> ...ant
>
> [1]
> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf
>
Any comments on this or does silence mean that example from the JEE spec is
an ok use case to be working towards for our first try at the new Geronimo
integration?
...ant
Re: Tuscany integration with Geronimo: What's common to SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I would like to extend the discussion a bit to help us better understand
> what user experience we would like to bring to Geronimo developers/users
> with Tuscany/SCA.
>
> I suggest that we use a usage scenario-driven approach to create a list of
> tasks/features and mark them either it's common to SCA independent of the
> hosting environment or it's specific to Geronimo.
>
> Here is a few roles a Geronimo instance can play in the SCA domain:
>
> 1) Geronimo is a member of a SCA domain to deploy/run SCA applications
>
> * Connect to the SCA domain admin app to get the image of a resolved
> composite application
> * Be able to deploy the resolved composite application in the VM of
> Geronimo, either as JEE application or standalone [Specific to Geronimo]
> * Run the resolved composite application
> * Provide the binding/implementation/policy extensions to realize SCA
> binding/implementation/policy types.[[Specific to Geronimo]
> * Hook with the other containers in Geronimo to provide various bindings,
> such as HTTP connectors with Tomcat
> * Hook with the QoSs such Transaction and Security provided by Geronimo
> to implement the SCA policies
> * Create/manage related resources for some bindings, such as JMS connection
> factories and queues [Specific to Geronimo]
>
> 2) Geronimo hosts the SCA domain admin application
>
> * Manage the configuration (Contributions/Composites/Nodes) for a SCA
> domain [Common to SCA]
> * Resolve the wirings at SCA domain level for the top-level composites
> [Common to SCA]
> * Deploy the resolved composite image to a in-process or remote host [A
> Geronimo or JSR88 Deployer may be specific to Geronimo]
>
> 3) Geronimo hosts (some) contributions for a SCA domain
> * Expose them as URLs to the SCA domain admin application. In this case, It
> functions as a repo for SCA contributions. [Specific to Geronimo]
>
> I think we should only try to implement a feature in a geronimo-specific
> way only if it's specific to Geronimo.
>
> Thanks,
> Raymond
>
>
>
Now that the 1.0 version of the SCA JEE spec [1] is out that defines several
concrete use cases and scenarios we can use to define the tasks and features
we need. For example, how about one goal be running in Geronimo the
application.ear shown at line 1131 page 41 "Appendix A – use cases" of the
SCA JEE spec.
...ant
[1]
http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf