Re: [sca-assembly] ISSUE 37: proposed approach for discussion and comment

[David Booz <booz@us.ibm.com>]

We touched on some of these points in the telecon today, but it would be useful to expand in email.

My two questions are:
1) What does this solution look like for the composite reference promoting multiple component references case? I think this is simple, but extending the example would be helpful.

2) How does this work for properties?

3) I presume the policy FW attributes (requires and policySet) would also be merged following the rules for implementation hierarchy in the policy spec?

4) Suppose myapp1 is deployed first, before myapp, what does the component reference for MyReferenceComponent look like? How did you know to add /MyService/ to the target URI?

I still don't prefer this model over simply ignoring the composite services and references in deployment composites, but this is certainly better than other alternative proposals I've seen. This magic merge makes me nervous. Since it is possible to directly code the end result of the merge, it would be simpler to show the pattern for domain level components and then let the author (assembler/developer) decide what to do.


Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Simon Nash ---09/23/2008 10:30:04 AM---This is not a formal proposal. It outlines a possible approach that might be used for resolving thi

From:	Simon Nash <oasis@cjnash.com>
To:	sca-assembly@lists.oasis-open.org
Date:	09/23/2008 10:30 AM
Subject:	[sca-assembly] ISSUE 37: proposed approach for discussion and comment

---

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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php