[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 37: proposed approach for discussion andcomment
Anish,
See comments inline.
Simon
Anish Karmarkar wrote:
> 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?
>
The advantage is that the promotion configuration can be specified
separately from the definition of the underlying components and
their services and references.
This allows me to have a deployment composite like the following:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
xmlns:tns="http://mynamespace";
name="myapp">
<service name="MyService1" promote="MyServiceComponent">
<binding.ws uri="http://localhost:8086/MyServiceComponent"; />
</service>
<service name="MyService2" promote="MyServiceComponent">
<binding.jms uri="jms:MyServiceQueue?
activationSpecName=MyActivationSpec&..." />
</service>
<include name="tns:myapp2" />
</composite>
where the included composite is defined as follows:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
name="myapp2">
<component name="MyServiceComponent">
<implementation.java class="myserver.MyServiceImpl" />
<service name="MyService">
<interface.java interface="myserver.MyService" />
</service>
</component>
</composite>
I think this is a very useful pattern. It allows components to be
developed and tested with a default configuration (using binding.sca
for all services and references). These conmponents can then be
deployed using an external configuration with real bindings (and
potentially multiple endpoints for the same service), without the
need to modify the components themselves.
It's fair to point out that this example could be written using
implementation.composite instead of inclusion (effectively another
variation on the wrapper pattern). This requires the introduction
of an additional wrapper composite myapp3, written as follows:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
xmlns:tns="http://mynamespace";
name="myapp3">
<service name="MyService1" promote="MyServiceComponent" />
<service name="MyService2" promote="MyServiceComponent" />
<include name="tns:myapp2" />
</composite>
There's no change to myapp2. We need to rewrite myapp as follows:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
xmlns:tns="http://mynamespace";
name="myapp">
<component name="MyDeploymentComponent">
<implementation.composite name="tns:myapp3" />
<service name="MyService1">
<binding.ws uri="http://localhost:8086/MyServiceComponent"; />
</service>
<service name="MyService2">
<binding.jms uri="jms:MyServiceQueue?
activationSpecName=MyActivationSpec&..." />
</service>
</component>
</composite>
This works, but it's very cumbersome to have to construct the additional
wrapper composite myapp3 and to define MyService1 and MyService2 in both
myapp3 and myapp. I believe the increase in complexity for this simple
pattern is significant and we should do our best to avoid it.
> 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?
>
I think you are describing a slightly different case here, where
promotions are used purely as a means of controlling visibility of
services and references rather than as a means of applying external
configuration to services and references. This visibility case can
be handled with some kind of auto-wrapper (as we have discussed in
off-list emails). However, the case I have decribed above can't be
automated, because of the way promotion is used to create multiple
configuarations/endpoints for the same service.
> How common do you think this particular use case is?
>
I think the case I described above is a common case and is one of the
patterns that SCA should support and promote (pun not deliberate :-)
Simon
> 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
>
> ---------------------------------------------------------------------
> 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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]