[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] Raw chat log for April 3 SCA-J TC call
Bryan Aupperle wrote: > > What about the case where a component has a Java implementation but the > interface for the service needs to be defined using WSDL, i.e. the > <service/> element of the component uses <interfrace.wsdl/>? Any > intents from the implementation, or the Java interface of the > componentType for that matter, have to be reflected in the WSDL. > I originally thought this too. If it were true, the Assembly definitions of compatible [subset|superset] would need to also require that the same intents are present on both interfaces. The ASSEEMBLY-117 proposal doesn't say that, and I think that's correct. This is because the policy spec requires AIUI that any intents specified at a lower level of the implementation hierarchy propagate upwards through the implementation hierarchy. This means that intents on interfaces would automatically propagate through componentType service -> component service -> promoted composite service -> implementation.composite service without needing to be repeated on any compatible subset interfaces specified at higher levels. If my interpretation of the policy rules is wrong, then we would either need to amend the draft resolution for ASSEMBLY-117 to include intents in the compatibility rules, or amend the policy rules to require propagation as stated above. Simon > Bryan Aupperle, Ph.D. > STSM, WebSphere Enterprise Platform Software Solution Architect > > Research Triangle Park, NC > +1 919-254-7508 (T/L 444-7508) > Internet Address: aupperle@us.ibm.com > > > *Simon Nash <oasis@cjnash.com>* > > 04/06/2009 06:23 AM > > > To > OASIS Java <sca-j@lists.oasis-open.org> > cc > > Subject > Re: [sca-j] Raw chat log for April 3 SCA-J TC call > > > > > > > > > On further reflection, I'm not convinced that we even need to specify > this intent mapping for the java->wsdl direction. This is because the > interface mapping from java->wsdl for interface compatibility checking > doesn't use these intent annotations in the WSDL as part of the > compatibility algorithm. > > For example, a reference could have interface.java and be autowired > in a composite that has various services with interface.wsdl. The > autowiring algorithm would perform the following steps: > 1. Look for service interfaces that are compatible with the java->wsdl > mapping of the reference interface. > 2. Select the subset of those services that are policy compatible with > the reference. > > For step 1, intents don't participate in the selection algorithm. > > For step 2, the reference polices would be computed using the > reference's Java interface and the service policies would be computed > using the service's WSDL interface. There would be no need for any > java->wsdl interface mapping as part of this computation. > > Simon > > Simon Nash wrote: > > Anish Karmarkar wrote: > >> Bryan, > >> > >> I have been thinking about this issue of intents and independence of > >> interface language. Unless I missed an issue resolution, section 11 of > >> CAA spec relegates the wsdl->java and java->wsdl mapping to JAX-WS. I > >> don't think this is sufficient. We'll have to specify that for intents > >> specified using @Requires, @Authentication etc annotations get mapped > >> to @requires WSDL attribute (in both directions). > >> > > I think we only need to say this normatively for the java->wsdl > direction, > > assuming that the current draft proposal for ASSEMBLY-116 is accepted. > > This is because the SCA runtime would never perform any wsdl->java > mapping. > > > > For the wsdl->java direction, the requirement for these intents to match > > between WSDL interfaces and Java interfaces is a consequence of other > > normative statements and does not need to be a normative statement in > > its own right. For example, when wiring a reference with interface.wsdl > > to a service with interface.java, the Java interface used by the service > > would need to have intents that are compatible with the intents on the > > WSDL portType used by the reference. However, if the roles are reversed > > so the service has interface.wsdl and the reference has interface.java, > > I believe the wiring would still be allowed even if the Java interface > > for the reference didn't have any of the intents from the WSDL service. > > > > Side note: The preceding paragraph is written with the assumption that > > reference intents describe the requirements of a reference rather than > > the capabilities of the reference's implementation. The Policy spec > > doesn't seem very clear on this point (I found words that seemed to > > support both interpretations). Can any of the policy folks clarify this? > > > > Simon > > > >> -Anish > >> -- > >> > >> Bryan Aupperle wrote: > >>> > >>> This is not a comment about the minutes but some additional thoughts > >>> on Anish's comment that impl methods should be required to have the > >>> same interaction intents as the interfaces that they implement. > >>> > >>> This should be true independent of the interface language and needs > >>> to be applied to the other implementation languages as well. > >>> > >>> Bryan Aupperle, Ph.D. > >>> STSM, WebSphere Enterprise Platform Software Solution Architect > >>> > >>> Research Triangle Park, NC > >>> +1 919-254-7508 (T/L 444-7508) > >>> Internet Address: aupperle@us.ibm.com > >>> > >>> > >>> *Simon Nash <oasis@cjnash.com>* > >>> > >>> 04/03/2009 11:28 AM > >>> > >>> To > >>> OASIS Java <sca-j@lists.oasis-open.org> > >>> cc > >>> Subject > >>> [sca-j] Raw chat log for April 3 SCA-J TC call > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > > > > --------------------------------------------------------------------- > 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]