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:[EMAIL PROTECTED]
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Mark Combellack"
<[EMAIL PROTECTED]
a.com> To
<[EMAIL PROTECTED]>
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 |
[EMAIL PROTECTED]
