[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
David Booz wrote:
> 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.
>
Taking myapp1 from the previous example and extending it to add this,
we get:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
name="myapp1">
<reference name="MyReference1" promote="MyReferenceComponent1,
MyReferenceComponent2" target="MyService1" />
<component name="MyReferenceComponent1">
<implementation.java class="myclient.MyClientImpl1" />
<reference name="myService1">
<interface.java interface="myserver.MyService1" />
</reference>
</component>
<component name="MyReferenceComponent2">
<implementation.java class="myclient.MyClientImpl2" />
<reference name="myService2">
<interface.java interface="myserver.MyService2" />
</reference>
</component>
</composite>
After deployment, this would be equivalent to the following:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mynamespace";
name="myapp1">
<component name="MyReferenceComponent1">
<implementation.java class="myclient.MyClientImpl1" />
<reference name="myService1" target="MyServiceComponent/MyService/MyService1">
<interface.java interface="myserver.MyService1" />
</reference>
</component>
<component name="MyReferenceComponent2">
<implementation.java class="myclient.MyClientImpl2" />
<reference name="myService2" target="MyServiceComponent/MyService/MyService1">
<interface.java interface="myserver.MyService2" />
</reference>
</component>
</composite>
> 2) How does this work for properties?
>
I would like to defer this until we have some consensus that this approach
is worth pursuing for services and references.
> 3) I presume the policy FW attributes (requires and policySet) would
> also be merged following the rules for implementation hierarchy in the
> policy spec?
>
This sounds reasonable, though I'm not familiar with the policy rules
for implementation hierarchy. Can you provide a pointer to the relevant
section of 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?
>
In this case, the target could not be resolved until myapp is deployed.
This would be similar to deploying a domain-level component A with a
reference to some other domain-level component service B/C, where
component B has not yet been deployed.
> 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.
>
Please see my earlier response to Anish for the use case that I believe
is enabled by this capability.
Simon
>
> 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
>
> Inactive hide details for Simon Nash ---09/23/2008 10:30:04 AM---This is
> not a formal proposal. It outlines a possible approacSimon 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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]