On Dec 6, 2007 3:26 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > 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 > > > I've started to do a little bit of tidying on the distributed store sample. I've taken the catalog-jee.composite and the associated type file out of the EJB jar as they are not processed by Geronimo which is running the jar. For now I've put them in the cloud so that when the cloud is run the catalog-jee.compoiste is started on one of the nodes. The only affect of this is that the domain is notified of the location of the EJB running on Geronimo. SCA has no ability to try and run the EJB itself. I've removed the ImportComposite method from the Domain for now as now the EJB composite is just added along with all the other composites. The tutorial relies on the fact that implementation.ejb doesn't actually do anything yet other than contribute the meta data. It maybe that a better thing to do is having a way of deploying specific composites to nodes rather than having different mechanisms for adding composites. Anyhow not sure about this point yet so more on this later. In the vein of creating scenarios we need management user scenarios (I'll have a stab at making some).
I've changed the port number for Tomcat so that it doesn't clash with Geronimo so that the tutorial can use both at once. I added the tuscany.properties file that I'm using to the cloud module as an example. I also added a very brief README about the distributed sample to the top level tutorial. There should be a PDF like the standard store tutorial PDF but I want to finish my doman changes before getting onto that. Regards Simon
