Re: [sca-j] Raw chat log for April 3 SCA-J TC call

[Bryan Aupperle <aupperle@us.ibm.com>]

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.

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