Multiple Contributions and the Domain-Level Composite

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

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

A Composite is added to the Domain-Level composite invoking the “add” method and specifying the URI of a SCA Contribution. 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.

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. 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. This can be achieved by either:

Installing another SCA Contribution that contains a Wire element that wires the Reference to the Service and adding that SCA 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">

<interface.java interface="com.componentware.api.RestaurantService"/>

<binding.rmi/>

</service>

<implementation.composite name="restaurantservice:restaurantservice"/>

</component>

<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

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.

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">

<interface.java interface="com.componentware.api.RestaurantService"/>

<binding.rmi/>

</service>

<implementation.composite name="restaurantservice:restaurantservice"/>

</component>

<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

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.

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">

<interface.java interface="com.componentware.api.RestaurantService"/>

<binding.rmi/>

</service>

<implementation.composite name="restaurantservice:restaurantservice"/>

</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

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">

</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

Once this wiring step is done, the Restaurant Service will be wired to the Billing Service and everything should function as expected.

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">

<interface.java interface="com.componentware.api.RestaurantService"/>

<binding.rmi/>

</service>

<implementation.composite name="restaurantservice:restaurantservice"/>

</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

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">

</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

sca-assembly message