On Dec 5, 2007 6:54 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Dec 5, 2007 8:29 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > I've made a bit more progress on this. I'm taking the approach that the > contribution describing the EJB will be imported into the domain on the > understanding that it shouldn't be deployed but, as we don't really have EJB > implementation support yet, will just provide the information to the domain > about where to find the EJB that is known to be running in Geronimo. > > To support this I added an importContribution method to the domain impl (I > haven't commited to putting it in the API yet while we play with it). The > method parses the contribution and associates it with a special kind of node > model (and IMPORTED node) and then registers any service information it > finds in the domain for other references to find. > > I haven't checked the code in yet as I have to fix some code to allow > binding.ejb to be wired. > > Implementing this scenario has highlighted that It's also getting to the > stage with the domain that I can't put off implementing component updates > any longer. Giorgio has also been doing some work on this (TUSCANY-1907) so > I'll start a separate thread on this. > > Regards > > Simon > Ok So, I have the scenario running using the following services....
1/ tutorial/catalog-ejb. A jar containing an VegetablesCatalog EJB which is deployed to Geronimo. It happens to contain a composite file that describes the EJB but this is not read by Geronimo (see 2) 2/ tutorial/cloud/lauch.LaunchCloud . The SCA cloud application extended to load the jar from 1/ as a contribution. The composite file from the jar is as follows. <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="http://store"; name="catalog-jee"> <component name="JEEVegetablesCatalog"> <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/> <service name="Catalog"> <binding.ejb uri="java:VegetablesCatalogImplRemote"/> </service> </component> </composite> Only the component names and the binding URI are processed at the moment. They provide enough information to find the EJB. 3. tutorial/store/launch.LaunchStoreDistributed. The SCA store application modified to talk to the EJB at 1/ given the information registered in the domain at 2/. This is what the catalog part of the composite looks like (all else remains the same). <component name="Catalog"> <implementation.java class="services.merger.MergedCatalogImpl"/> <property name="currencyCode">USD</property> <service name="Catalog"> <t:binding.jsonrpc/> <binding.ws uri="/CatalogWebService"/> </service> <reference name="fruitsCatalog" target="CloudFruitsCatalog"/> <!--reference name="fruitsCatalog" target="JSEFruitsCatalog"--> <!--reference name="vegetablesCatalog" target="CloudVegetablesCatalog"--> <reference name="vegetablesCatalog" target="JEEVegetablesCatalog"> <!--binding.ejb uri="VegetablesCatalogImplRemote"--> <binding.ejb/> </reference> <reference name="currencyConverter" target="CurrencyConverter"/> </component> Note. I've left lines in but commented out so I can vary the scenario as I'm testing (the full scenario that we are going for has both Tomcat and Geronimo at the same time). The important lines here are <reference name="vegetablesCatalog" target="JEEVegetablesCatalog"> <binding.ejb/> Which causes the node running this component to ask the domain for the service called JEEVegetablesCatalog. This has previously been registered as we imported the composite at 2/ into the domain. The JEEVegetablesCatalog component has been carefully crafted with the following binding <binding.ejb uri="java:VegetablesCatalogImplRemote"/> This ensures that the uri of the ejb binding is absolute and hence is not reset by SCA uri generation rules. This URI matches the JNDI name of the EJB defined by the EJB implementation class as follows. @Stateless(name="VegetablesCatalogImpl") //@Stateless public class VegetablesCatalogImpl implements Catalog { ... } The @Stateless with the explicit name is not actually required (I was interested in what I could do with it). The result is that the catalog component in the store application gets the correct reference to the EJB. Anyhow I'm writing this as a full build runs with a view to checking this in. I have lots of refworking and tidying to do but I want to get the code checked in as a baseline so I can move on to fixing all the things that I know are wrong. The main things that I need to fix are as follows. Not specific to this scenario but will make running the scenario a more reliable experience. A/ The nodes are still working in a mode where they go and ask for information from the domain so the demo has to be brought up in the correct order. I want to flip this so that the domain notifies nodes as service information comes and goes. This also makes domain level wiring possible because as wires are added the domain can notify affected nodes. I will start a separate thread on this as promised yesterday. B/ The messages used to pass service information about need improving to include more information about a service/binding. e.g. required intents. The domain level wiring process takes no account of policy at the moment. C/ I've implemented an import method on the domain to get the EJB information in while not making the composite available for deployment. We need to review this. D/ Multiplicites for non SCA bindings don't look like they will work to me. In general the binding resolution process during the build and activate phases needs a review. I will raise a JIRA. Looking at how to apply the reference updates required as service details change will be a good opportunity to do this. Regards Simon
