[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
> 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. As I mentioned in my previous email, I also prefer the model of ignoring promotions: 1) service promotions: if you wanted to survive deployment at domain-level, wrap it up. 2) reference promotion: this is interesting only for the case where you have several component reference promoted as a single reference. Again, the way to make this survive is to wrap it in a higher composite. I would point out that this problem occurs because SCA promotion conflates two things: visibility and configuration/override. 3) properties: this is slightly different. It could be used to provide values for component properties in the deployment composite or it could be used to provide values for component properties for domain-level components that are contributed from different deployment composites. The first one makes sense to me, the second one doesn't because I don't know what would happen if the composite which contributed the property got undeployed. Just seems to add complexity. For the first case, one can again create a wrapper to get what is needed. I know creating a wrapper may be a pain (may be we can provide an 'autowrap' mode for deployment), but not special-casing deployment composites wrt promotion provides for a simpler model IMHO. -Anish -- 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. > > 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 > > 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]