[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] BINDINGS-23: Proposed resolution
Here is an updated proposal for resolving BINDINGS-23. If this is
adopted, it will require adjustment to the wording for the BINDINGS-54
resolution. The URI matching algorithm for wsdl.service and wsdl.port
in the BINDINGS-54 words would need to include similar words about
portType compatibility with the service or reference interface.
There is also a slight discrepancy between the wording below and
the wording for the proposed BINDINGS-54 resolution. For an SCA
reference that uses a wsdl.service SCA binding, the words below
(based on the original text here) talk about the SCA runtime making
all compatible ports available to the reference. The BINDINGS-54
words say that the SCA runtime chooses any one of these ports.
If we want to bring the wording below into line with BINDINGS-54,
I would suggest changing the reference paragraph for wsdl.service
to replace "all the ports" by "any of the ports".
Proposed changes for BINDINGS-23:
In the first bullet (Service) under the /binding.ws/@wsdlElement
description, replace the current text by the following:
If the binding is for an SCA service, the SCA runtime MUST make
available to the SCA service all the ports in the WSDL Service that
have portTypes which are compatible with the SCA service.
A WSDL portType is compatible with an SCA service if and only if
it satisfies all of the following conditions:
1. The SCA service interface is remotable.
2. The operations on the portType are the same as the operations
on the SCA service interface, with the same operation name,
input types (taking order as significant), output types
(taking order as significant), and fault/exception types.
If the SCA service interface is not a WSDL portType, it is
mapped to a WSDL portType for the purposes of this comparison.
3. WSDL 1.1 message parts can point to an XML Schema element
declaration or an XML Schema type. When determining compatibility
between two WSDL operations, a message part that points to an
XML Schema element is considered to be incompatible with a
message part that points to an XML Schema type.
4. If either the portType or the SCA service interface declares
an SCA callback interface, then both the portType and the
SCA service interface declare callback interfaces and these
callback interfaces are compatible according to points
1 through 3 above.
The WSDL Service MUST have at least one port that is compatible
with the SCA service.
If the binding is for an SCA reference, the SCA runtime MUST make
available to the SCA reference all the ports in the WSDL Service that
have portTypes which are compatible supersets of the SCA reference.
The definition of compatible superset is that given in section 5.4 of
the SCA Assembly Model specification [SCA-Assembly]. The WSDL Service
MUST have at least one port that is a compatible superset of the
SCA reference.
In the second bullet (Port) under the /binding.ws/@wsdlElement
description, replace the first sentence of the current text by
the following:
If the binding is for an SCA service, the portType associated with
the port MUST be compatible with the SCA service interface.
If the binding is for an SCA reference, the portType associated with
the port MUST be a compatible superset of the SCA reference interface.
In the third bullet (Binding) under the /binding.ws/@wsdlElement
description, replace the first sentence of the current text by
the following:
If the binding is for an SCA service, the portType associated with the
WSDL binding MUST be compatible with the SCA service interface.
If the binding is for an SCA reference, the portType associated with the
WSDL binding MUST be a compatible superset of the SCA reference interface.
Simon
Anish Karmarkar wrote:
> I have a different view on this.
> When you promote, you get to set the CT of the composite and therefore
> can subset the service interface. WRT setting the binding, you don't get
> to subset the interface of the service.
>
> -Anish
> --
>
> Simon Nash wrote:
>> David Booz wrote:
>>> I'm confused. I read this a few times. You said:
>>>
>>> In the first bullet (Service) under the /binding.ws/@wsdlElement
>>> description, replace the current text by the following:
>>>
>>> If the binding is for an SCA service, the SCA runtime MUST make
>>> available to the SCA service all the ports in the WSDL Service that
>>> have portTypes which are compatible subsets of the SCA service.
>>> A WSDL portType is a compatible subset of an SCA reference if and
>>> only if it would be valid as an interface when promoting the
>>> SCA service as described in section 5.1 of the SCA Assembly Model
>>> specification [SCA-Assembly].
>>>
>>> First, I think you mean superset, not subset. Surely the WSDL service
>>> has to have at least as many methods as the SCA service interface,
>>> otherwise the SCA service is invalid.
>>>
>>> Second why does the second sentence talk about SCA references?
>>>
>>> I'll stop there to see if I've completely misunderstood.
>>>
>> If I'm exposing an SCA service through binding.ws with a WSDL binding,
>> the WSDL binding must support a subset of the methods of the
>> SCA service. If there are some methods in the SCA service that
>> aren't in the WSDL binding, it won't be possible to invoke those
>> methods through the WSDL binding, but that won't cause any problems
>> for the SCA service. It's similar to promoting an SCA service and
>> putting a subset interface on the promoted service.
>>
>> The WSDL binding couldn't have a superset of the SCA service's
>> methods because invocations of the extra methods through the
>> WSDL binding couldn't be passed on to the service.
>>
>> For references, the position is reversed. It's OK for the
>> reference's WSDL binding to support a superset of the methods
>> that the SCA reference can invoke, but it wouldn't be OK for the
>> reference's WSDL binding to only support a subset.
>>
>> 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 ---03/18/2009 07:36:49 AM---Here
>>> is my proposal for resolving BINDINGS-23. If this is adoSimon Nash
>>> ---03/18/2009 07:36:49 AM---Here is my proposal for resolving
>>> BINDINGS-23. If this is adopted, it will require adjustment to th
>>>
>>>
>>> From: Simon Nash <oasis@cjnash.com>
>>>
>>> To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
>>>
>>> Date: 03/18/2009 07:36 AM
>>>
>>> Subject: [sca-bindings] BINDINGS-23: Proposed resolution
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> Here is my proposal for resolving BINDINGS-23. If this is adopted,
>>> it will require adjustment to the wording for the BINDINGS-54
>>> resolution. The URI matching algorithm for wsdl.service and wsdl.port
>>> in the BINDINGS-54 words would need to include similar words about
>>> portType compatibility with the service or reference interface.
>>>
>>> There is also a slight discrepancy between the wording below and
>>> the wording for the proposed BINDINGS-54 resolution. For an SCA
>>> reference that uses a wsdl.service SCA binding, the words below
>>> (based on the original text here) talk about the SCA runtime making
>>> all compatible ports available to the reference. The BINDINGS-54
>>> words say that the SCA runtime chooses any one of these ports.
>>> If we want to bring the wording below into line with BINDINGS-54,
>>> I would suggest changing the reference paragraph for wsdl.service
>>> to replace "all the ports" by "any of the ports".
>>>
>>> Proposed changes for BINDINGS-23:
>>>
>>> In the first bullet (Service) under the /binding.ws/@wsdlElement
>>> description, replace the current text by the following:
>>>
>>> If the binding is for an SCA service, the SCA runtime MUST make
>>> available to the SCA service all the ports in the WSDL Service that
>>> have portTypes which are compatible subsets of the SCA service.
>>> A WSDL portType is a compatible subset of an SCA reference if and
>>> only if it would be valid as an interface when promoting the
>>> SCA service as described in section 5.1 of the SCA Assembly Model
>>> specification [SCA-Assembly].
>>>
>>> If the binding is for an SCA reference, the SCA runtime MUST make
>>> available to the SCA reference all the ports in the WSDL Service that
>>> have portTypes which are compatible supersets of the SCA reference.
>>> A WSDL portType is a compatible superset of an SCA reference if and
>>> only if it would be valid as an interface when promoting the
>>> SCA reference as described in section 5.2 of the SCA Assembly Model
>>> specification [SCA-Assembly].
>>>
>>> In the second bullet (Port) under the /binding.ws/@wsdlElement
>>> description, replace the first sentence of the current text by
>>> the following:
>>>
>>> If the binding is for an SCA service, the portType associated with
>>> the port MUST be a compatible subset of the SCA service interface.
>>> If the binding is for an SCA reference, the portType associated with
>>> the port MUST be a compatible superset of the SCA reference interface.
>>>
>>> In the third bullet (Binding) under the /binding.ws/@wsdlElement
>>> description, replace the first sentence of the current text by
>>> the following:
>>>
>>> If the binding is for an SCA service, the portType associated with the
>>> WSDL binding MUST be a compatible subset of the SCA service interface.
>>> If the binding is for an SCA reference, the portType associated with
>>> the
>>> WSDL binding MUST be a compatible superset of the SCA reference
>>> interface.
>>>
>>> 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
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]