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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>> 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 <[EMAIL PROTECTED]> >>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM >>>>> *To:* [email protected] >>>>> *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 <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <[EMAIL PROTECTED]> >>>>>> 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 >>>>> >>>> >>>> >>> >> >
