Hi An update of where I'm up to...
Simon On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > [snip] > Simon Laws wrote: > >> > > > > To get me going on this I've experimented with moving the FruitsCatalog > out > > of the cloud and into a webapp. The web app relies on the evolving deep > > tomcat integration so starting the scenario requires the following > steps.... > > > > Unzip the distribution/tomcat zip over your tomcat installation > > Set the tomcat/sca-contributions/tuscany.properties file to include node > and > > domain URLs that are to your liking. > > Copy tutorial-catalog-jse.war to tomcat/webapps > > Run LaunchCloud > > Run LaunchStoreDistributed > > > > And you are set. > > Thanks a lot, I'll update and will try it. > > > > > It's all a bit fragile at the moment so lots of things to do, for > example, > > the domain is a pain as it doesn't track when things go away so it can > get > > confusing. However lets try and get the majority of the scenario working > and > > we can then look back and see where the holes are. > > > > I haven't done anything with the EJB code you made yet other than look > at > > it. I could start building the EJB for the vegetable catalog if you > like. > > Yes, here are the steps I was thinking about: > 1. develop the EJB code > 2. deploy it to Geronimo > 3. come up with a version of store.composite with the vegetablesCatalog > reference configured with the proper EJB binding > 4. figure what the business interface for that reference looks like (I'm > hoping that this will help shed some light on the "POJO and > databindings" discussion) > 5. get that working end to end I've done 1-5 but with very little thought about 4 other than take the VegetablesCatalog interface as it. There is a catalog-ejb project now under tutorial. This deploys to Geronimo and I've updated the distributed store to use a specifically configured binding. I had to change the domain to 9998 as Geronimo uses 9999 so some of the other bits of the tutorial may not work at the moment. > > > and in a second step: > 6. add a description of the EJB app to the domain > 7. on the vegetablesCatalog reference, replace the <binding.ejb > uri="..."/> by a wire with target="VegetableCatalog" > 8. get that working end to end > > > > > I'm assuming from what you say that we will deploy the EJB app to > Geronimo > > standalone as if it had existed before we came along with SCA. > > Yes > > Where will > > the composite that references this EJB be deployed to? I'm struggling > with > > how to satisfy "The idea is to be able to develop the scenario and > explore > > how to work with existing JEE apps and different containers in an SCA > domain > > without piling more runtime code into Tuscany." as it seems that we will > > need to deploy the composite that references the EJB to Geronimo which, > in > > turn, means bringing up the Geronimo/Tuscany integration code again. > > I think that "adding a composite to the domain" does not necessarily > imply "download that composite to the Tuscany-enabled container that > runs the components it describes". > > In other words I'm hoping that we can add to the domain a composite that > describes an application without having to install the Tuscany Java > runtime to the container that runs it. > > That's one of the reasons why I brought up that scenario: To help us > explore what a domain really is and the idea that an SCA domain is more > than a bunch of Tuscany-Java runtimes that use a Tuscany-specific > protocol to advertise/discover their services. I have been working on bringing the Geronimo plugin back up again with the code in trunk and that is almost done now so we have some options about how we want to ply this. We could add the ability to introduce service descriptions to the domain regardless of whether the service is running on a Tuscany enabled endpoint although I haven't done this yet. We need to agree how this would be achieved from the users point of view. For example, is this a specific interface for associating the domain with existing services or is it to use the existing contribution interfaces with composites marked in some way that indicates that they are not to be deployed for real but simply added to the domain. Generally we need the ability on the domain to view and manipulate component definitions so that the deployment process is more flexible for situations when the domain level composite is modified. The deployment of "virtual" components could be part of this. I'll have a play this morning and see if any inspiration comes. I have spent time bringing up the Geronimo plugin to work with the code in trunk so we can play with a number of different scenarios. > > > > > > Simon > > > > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
