ISSUE 37: proposed approach for discussion and comment

[Simon Nash <oasis@cjnash.com>]

This is not a formal proposal.  It outlines a possible approach that
might be used for resolving this issue.  I'll illustrate this approach
using the following example composites myapp and myapp1:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp">

     <service name="MyService1" promote="MyServiceComponent" />

     <service name="MyService2" promote="MyServiceComponent">
         <binding.ws uri="http://localhost:8086/MyServiceComponent"; />
     </service>

     <component name="MyServiceComponent">
         <implementation.java class="myserver.MyServiceImpl" />
         <service name="MyService">
             <interface.java interface="myserver.MyService" />
         </service>
     </component>
</composite>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp1">

     <reference name="MyReference1" promote="MyReferenceComponent" target="MyService1" />

     <component name="MyReferenceComponent">
         <implementation.java class="myclient.MyClientImpl" />
         <reference name="myService">
             <interface.java interface="myserver.MyService" />
         </reference>
     </component>
</composite>

The question we need to address to resolve issue 37 is what does it mean to
use these as deployment composites and deploy them into the domain by inclusion.
I would like to propose that the composite services and references within
these deployment composites are used to create additional bindings on the
underlying promoted component services and references.

This means that deploying myapp is equivalent to deploying the following:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp">

     <component name="MyServiceComponent">
         <implementation.java class="myserver.MyServiceImpl" />
         <service name="MyService">
             <interface.java interface="myserver.MyService" />
             <binding.sca name="MyService" />
             <binding.sca name="MyService1" />
             <binding.ws name="MyService2" uri="http://localhost:8086/MyServiceComponent"; />
         </service>
     </component>
</composite>

Similarly, deploying myapp1 is equivalent to deploying the following:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp1">

     <component name="MyReferenceComponent">
         <implementation.java class="myclient.MyClientImpl" />
         <reference name="myService" target="MyServiceComponent/MyService/MyService1" >
             <interface.java interface="myserver.MyService" />
         </reference>
     </component>
</composite>

I believe this approach works in a fairly straightforward manner when
promoted services or reference override bindings without overriding interfaces.
However, consider the case of myapp2, defined as follows:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp2">

     <service name="MyService1" promote="MyServiceComponent" />

     <service name="MyService2" promote="MyServiceComponent">
         <binding.ws uri="http://localhost:8086/MyServiceComponent"; />
         <interface.wsdl interface="http://example.org/#wsdl.interface(MyWsdlService)" />
     </service>

     <component name="MyServiceComponent">
         <implementation.java class="myserver.MyServiceImpl" />
         <service name="MyService">
             <interface.java interface="myserver.MyService" />
         </service>
     </component>
</composite>

Because MyService2 defines a different interface from MyService, we would
need to preserve both of these interfaces in the deployed component
MyServiceComponent.  This would require adding the ability to attach an
interface to a binding as well as to a service or reference.  In SCDL,
this would look like the following.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
         targetNamespace="http://mynamespace";
         name="myapp">

     <component name="MyServiceComponent">
         <implementation.java class="myserver.MyServiceImpl" />
         <service name="MyService">
             <interface.java interface="myserver.MyService" />
             <binding.sca name="MyService" />
             <binding.sca name="MyService1" />
             <binding.ws name="MyService2" uri="http://localhost:8086/MyServiceComponent";>
                 <interface.wsdl interface="http://example.org/#wsdl.interface(MyWsdlService)" />
             </binding.ws>
         </service>
     </component>
</composite>

A binding interface would need to be compatible with the underlying
service or reference interface, following the same rules as for
interfaces on promoted services or references.  Specifically, a
binding interface on a service must be a compatible subset of the
service interface, and a binding interface on a reference must be
a compatible superset of the reference interface.

Adding the ability to specify interfaces on bindings has other uses
outside of the specific context of this issue.  For example, the
same SCA service might be exposed as two Web services, one using a
doc-lit-wrapped binding and one using a doc-lit-bare binding.
The interfaces (portTypes) for these are not the same.  Allowing
a binding to provide a customized interface that is compatible
with the service or reference solves this problem.

   Simon