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

 

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

 

   
<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

 

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

 

   
<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

 

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

 

   
<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

 

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

 

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

 

   
<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

 

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 |