[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Multiple Contributions and the Domain-Level Composite -how does it all work together?
I think this is going to be a very valuable email thread....I'll imbed comments <dab> like this </dab> Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Mark Combellack" <mcombellack@avay a.com> To <sca-assembly@lists.oasis-open.org> 06/24/2008 08:23 cc AM Subject [sca-assembly] Multiple Contributions and the Domain-Level Composite - how does it all work together? Hi, First an apology - this is a rather long email. Thanks in advance for your time in reading it. I’ve been trying to understand how to work with multiple Contributions and how this fits with the Domain-Level Composite. I’ve been reading Chapter 11 of the Assembly specification Committee Draft 01 but this chapter contains no samples of how the Domain-Level Composite and Contributions work. (Perhaps I should raise a new issue for this?) As a result, I have to speculate how it is meant to work. I wanted to check whether I understood the concepts correctly. SCA Contribution This is a packaging artefact. I create SCA Contributions that contain the implementation of my Composites, Components, implementation code, etc. I can install SCA Contributions into my SCA Runtime. I understand this to mean: The SCA Contribution is made available to the SCA Runtime I cannot invoke Services in the SCA Contribution at this point because it has not been “started” yet since it is not part of the Domain-Level Composite <dab> terminology: we use the word 'deploy' to represent the action that places components into the Domain. Install and deploy are seperate concepts. As you said, install makes a contribution known to the runtime, but that's all it does. Start and stop is something that a runtime does to deployed components to make them ready/unready for dispatch. The most basic lifecycle as I see it is this: install contribution, deploy contribution, start components. There are many variants of this that are enabled by the spec. Also, it should be possible for an SCA runtime to provide an ease of use variant for its users that appears to collapse this lifecycle into fewer steps, but architecturally, these steps are still occurring. </dab> I can have a SCA Contribution that has a dependency on other SCA Contributions using import/export statements in the sca-contributions.xml or sca-contributions-generated.xml files. Domain-Level Composite This contains the “running” state of the SCA Runtime. It is a virtual Composite that is made up of the Composites that have been added to the SCA Domain <dab> I would have said "deployed" state as it represents configurations that have been deployed. The word "running" state could be confused with the state of an implementation instance when it's executing, which is something different. </dab> A Composite is added to the Domain-Level composite invoking the “add” method and specifying the URI of a SCA Contribution.<dab> The contribution has to specify which composites are the deployment composites through the sca-contribution.xml file. This is how the runtime knows what components are to be deployed into the domain. The add function (in 11.6.1 of cd01) adds a composite to the Domain, where the composite might be in a contribution or it might have been provided by the deployer. Section 11.4.2 describes valid ways to manipulate an installed contribution, but IMHO thoese operations have no effect on the Domain unless and until one of the composites in question is deployed to the Domain as in section 11.6.x. </dab> This will mean: The SCA Runtime will resolve the import/exports for the SCA Contribution. The SCA Contribution will be “started” and any Services it contains will be invokeable. <dab> Again, we need to seperate deploy from start and stop in the architecture. It is (or should be) possible to deploy components to the Domain without having any hosting runtimes running.</dab> Domain-Level Wiring This is not really covered in Chapter 11 but from our discussions, I understand our intent to be something along the lines of: Suppose I have two Contributions that are added to the Domain-Level Composite. <dab> I think you mean two deployment composites from two different contributions </dab> If one of the Contributions promotes a Service and the other Contribution promotes a Reference, it is possible to wire the Reference to the Service at the Domain-Level. <dab> This is a can of worms...there is an open issue asking whether or not composite level services and references have any meaning at the Domain level. If you change your example slightly we could get past this composite level serv/ref question and answer the question you're really asking. Let me change the example to be as follows. Contrib 1 contains composite1 which configures component1, where component1 has a reference. Contrib 2 contains composite2 which configures component2, where component2 has a service. Further suppose that both contribs are installed and that each of the composites is deployed. Your question is how to connect the ref to the service. This can be acheived by the methods you state below.</dab> This can be achieved by either: Installing <dab> and deploying </dab> another SCA Contribution that contains a <dab> composite with a </dab> Wire element that wires the Reference to the Service and adding that SCA <dab> composite </dab> Contribution to the Domain-Level Composite. The Domain-Level has “autowire = true” and the two are automatically wired together by the SCA Runtime Assuming that the above is roughly what is going on, I wanted to know whether I can do the following two Use Cases. They are based off the following SCA Application. I have 2 SCA Contributions: RestaurantService Contribution – Contains the RestaurantService that has a Reference to a BillingService BillingService Contribution – Contains the BillingService that is responsible for contacting an external Credit Card payment system. Use Case 1 : Building Application using a separate instance of each Contribution Aims: Implement Restaurant Services that have their own instance of the Billing Service Pre-requirements Empty Domain-Level Composite RestaurantService and BillingService Contributions installed in the SCA Runtime. Step 1 – Open first restaurant called “CoolFoodsRUs” To setup my first Restaurant called CoolFoodsRUs, I: Create a new SCA Contribution something like: <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.coolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name="coolfoodsrus">. <service name="CoolFoodsRUs" promote="RestaurantServiceComponent"> <interface.java interface="com.componentware.api.RestaurantService"/> <binding.rmi/> </service> <component name=" RestaurantServiceComponent "> <implementation.composite name="restaurantservice:restaurantservice"/> <reference name="billingService" target="BillingService"/> </component> <component name="BillingService"> <implementation.composite name="billingservice:billingservice"/> </component> </composite> Add appropriate imports to the sca-contribution.xml file. Package this all as a new SCA Contribution called “CoolFoodsRUs.zip” Install the CoolFoodsRUs.zip SCA Contribution in the SCA Runtime Add the http://com.coolfoodsrus URI to the Domain-Level Composite <dab> The deployer (or deployment tool) would add this to the service in the coolfoodrus composite during deployment. I'll note that the coolfoodrus composite looks a lot like a deployment composite.</dab> Once the above steps are completed, I will be able to invoke the CoolFoodsRUs Service over the RMI binding that it has been exposed over. <dab> Again, there is a debate in issue 37 over whether or not the composite level service is even necessary in your scenario. Ignoring that, your statement is correct. </dab> Step 2 – The food critics love it – Open a second restaurant called “SuperCoolFoodsRUs” To setup my second Restaurant called SuperCoolFoodsRUs, I: Create a new SCA Contribution something like (very similar to the previous one – marked changes in bold) <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.supercoolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name=".supercoolfoodsrus"> <service name="SuperCoolFoodsRUs" promote="RestaurantServiceComponent"> <interface.java interface="com.componentware.api.RestaurantService"/> <binding.rmi/> </service> <component name=" RestaurantServiceComponent "> <implementation.composite name="restaurantservice:restaurantservice"/> <reference name="billingService" target="BillingService"/> </component> <component name="BillingService"> <implementation.composite name="billingservice:billingservice"/> </component> </composite> Add appropriate imports to the sca-contribution.xml file. Package this all as a new SCA Contribution called “SuperCoolFoodsRUs.zip” Install the SuperCoolFoodsRUs.zip SCA Contribution in the SCA Runtime Add the http://com.supercoolfoodsrus URI to the Domain-Level Composite <dab> Now you've run aground. Deploying supercoolfoodrus into the same Domain as coolfoodrus will cause an error because of duplicate component names. </dab> Once the above steps are completed, I will be able to invoke both the original CoolFoodsRUs Service and the new SuperCoolFoodsRUs Service over the RMI binding that it has been exposed over. Observations: As far as I can tell, the two restaurants will be working independently. The will have their own instance of the Billing Service. <dab> In order to make your scenario work, you will need to either: 1) rename the components in supercoolfoodrus...which is not desireable.. 2) Create a deployment composite that looks like this (roughly): <composite name="someName"> <component name="coolfoodrus"> <service name="CoolFoodRUs"> <binding.rmi/> <service/>. <implementation.composite name="cz1:coolfoodrus" </component> You'd create another composite very similar to this for the supercoolfoodrus assembly and then deploy it. In the end, you'd end up with two components in your Domain, one for each restaurant. Obvioiusly, option 2 is the way to go, and this is exactly the reason why we enabled components to be implemented by composites.. </dab> Use Case 2 : Building Application using a shared instance of a Contribution Aims: Implement Restaurant Services that share a single instance of the Billing Service Pre-requirements Empty Domain-Level Composite RestaurantService and BillingService Contributions installed in the SCA Runtime. Domain-Level autowire = false Step 1 – Open first restaurant called “CoolFoodsRUs” To setup my first Restaurant called CoolFoodsRUs, I: Create a new SCA Contribution something like: <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.coolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name="coolfoodsrus">. <service name="CoolFoodsRUs" promote="RestaurantServiceComponent"> <interface.java interface="com.componentware.api.RestaurantService"/> <binding.rmi/> </service> <reference name="BillingService" promote="RestaurantServiceComponent/billingService"/> <component name=" RestaurantServiceComponent "> <implementation.composite name="restaurantservice:restaurantservice"/> <reference name="billingService"/> </component> </composite> Add appropriate imports to the sca-contribution.xml file.: Package this all as a new SCA Contribution called “CoolFoodsRUs.zip” Install the CoolFoodsRUs.zip SCA Contribution in the SCA Runtime Add the http://com.componentware.billingservice URI to the Domain-Level Composite Add the http://com.coolfoodsrus URI to the Domain-Level Composite <dab> Why didn't you wire the restaurant reference named billing service to the BillingService composite level reference? </dab>. Once the above steps are completed, I will be able to invoke the CoolFoodsRUs Service over the RMI binding that it has been exposed over. However, we have not wired the BillingService reference to anything. To do this, I would: · Define another SCA Contribution containing the wire something like: <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.coolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name="coolfoodsruswires"> <wire source="CoolFoodsRUs/BillingService" target="billingservice:BillingService/BillingService"/> </composite> Package this all as a new SCA Contribution called “CoolFoodsRUsWires.zip” Install the CoolFoodsRUsWires.zip SCA Contribution in the SCA Runtime Add the http://com.coolfoodsruswires URI to the Domain-Level Composite <dab> No, I wouldnt use wires to wire two things that are in the same deployment composite. I suppose you could, but what's the point? </dab> Once this wiring step is done, the Restaurant Service will be wired to the Billing Service and everything should function as expected.? <dab> Did the deployer add config to the BillingService composite level reference? If not, then you're not done because it doesn't point to anything. </dab> Step 2 – The food critics love it – Open a second restaurant called “SuperCoolFoodsRUs” To setup my second Restaurant called SuperCoolFoodsRUs, I: Create a new SCA Contribution something like (very similar to the previous one – marked changes in bold) <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.supercoolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name=".supercoolfoodsrus"> <service name="SuperCoolFoodsRUs" promote="RestaurantServiceComponent"> <interface.java interface="com.componentware.api.RestaurantService"/> <binding.rmi/> </service> <reference name="BillingService" promote="RestaurantServiceComponent/billingService"/> <component name=" RestaurantServiceComponent "> <implementation.composite name="restaurantservice:restaurantservice"/> <reference name="billingService"/> </component> </composite> Add appropriate imports to the sca-contribution.xml file.: Package this all as a new SCA Contribution called “SuperCoolFoodsRUs.zip” Install the SuperCoolFoodsRUs.zip SCA Contribution in the SCA Runtime Add the http://com.supercoolfoodsrus URI to the Domain-Level Composite <dab> See above, Again you will run aground with duplicate components in the same Domain. For this scenario, the solution is similar to what I described above. </dab> Once again, we have deployed the SuperCoolFoodsRUs RestaurantService but the Reference to the BillingService has not been wired. To do this wiring, I would: · Define another SCA Contribution containing the wire something like: <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://com.supercoolfoodsrus" xmlns:restaurantservice=" http://com.componentware.restaurantservice" xmlns:billingservice=" http://com.componentware.billingservice" name="supercoolfoodsruswires"> <wire source="SuperCoolFoodsRUs/BillingService" target="billingservice:BillingService/BillingService"/> </composite> Package this all as a new SCA Contribution called “SuperCoolFoodsRUsWires.zip” Install the SuperCoolFoodsRUsWires.zip SCA Contribution in the SCA Runtime Add the http://com.supercoolfoodsruswires URI to the Domain-Level Composite. Once this wiring step is done, the Restaurant Service will be wired to the Billing Service and everything should function as expected. Observations: As far as I can tell, the two restaurants will be sharing the one instance of the Billing Service. Does this make any sense to anyone? Are the above two use cases valid? Have I got the right idea?. Thanks for you help, Mark Mark Combellack| Software Developer| Avaya | Eastern Business Park | St. Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 | mcombellack@avaya.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]