[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 Karmarkar wrote: > > 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. > For the pure "survival" case, this might be acceptable, especially if some means of auto-wrapping could be provided. > 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. > Same comment as above if pure survival is the goal. > 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 haven't thought about the property case in depth yet. > 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. > The autowrap facility only helps if the requirement is pure survival. It doesn't handle the cases where domain-level promotion is used to add configuration to a lower-level service or reference. Simon > -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]