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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Simon,

What is the advantage of adding binding-interfaces as opposed to two 
different services (with different interfaces) to the underlying 
component? Is the behavior any different?

But I have a more fundamental question:
Why enable this? What is the advantage over the complexity?

If you really wanted to do this, you have an option of wrapping each of 
your example composite inside another composite so that promotions 
survive the inclusion-unwrapping. Yes, it is slightly painful. But if 
that is what you wanted to do (that == exposing promoted services to 
peer components) then the current model provides you with the right 
encapsulation model with a way around it (wrap it another layer). No?

How common do you think this particular use case is?

Thanks.

-Anish
--

Simon Nash wrote:
> 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