You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Nash <na...@hursley.ibm.com> on 2007/10/21 21:13:52 UTC
Fixing TUSCANY-1849 without breaking interoperabliity
I have been thinking about how to fix TUSCANY-1849 without breaking
interoperability with Tuscany SCA 1.0, and how in future we could
make other protocol changes without breaking interoperability.
I have the outline of a proposal. Some details are not finalized.
At this stage I would welcome comments on the general principle.
Tuscany SCA currently puts callback and conversation information on
the wire using Tuscany-specific protocol elements in the Tuscany SCA
namespace, which is currently
http://tuscany.apache.org/xmlns/sca/1.0
If an incompatible change to this protocol is needed for any reason,
then a new version of the Tuscany SCA namespace would be created.
For example, if we were to fix TUSCANY-1849 in Tuscany SCA 1.1 by
changing the protocol for callbacks and conversations, we would
create a new namespace
http://tuscany.apache.org/xmlns/sca/1.1
We would also add a Tuscany-specific element or attribute somewhere
within the WSDL <binding> element to indicate that Tuscany-specific
protocol extensions are being used for callbacks and conversations.
For example, we could define an empty marker element
<tuscany:SOAPExtensions/>. The WSDL would then look like:
<wsdl:binding name="...." type="...." xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<tuscany:SOAPExtensions/>
<wsdl:operation name="....">
....
</wsdl:operation>
</wsdl:binding>
These extension elements are effectively part of the binding and
it seems appropriate to specify the use of them there.
When Tuscany SCA generates WSDL either statically or dyanmically,
it would add the necessary marker element to all bindings that
require these extensions (i.e., all bindings for port types that
represent conversational interfaces or interfaces with callbacks).
Now we have the information needed to make future protocol changes
without breaking interoperability. Suppose the Tuscany-specific
protocol extensions change between Tuscany SCA 1.1 and Tuscany SCA 1.2.
If a Tuscany SCA 1.2 client sees WSDL containing:
<wsdl:binding name="...." type="...." xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<tuscany:SOAPExtensions/>
<wsdl:operation name="....">
....
</wsdl:operation>
</wsdl:binding>
it would look at the namespace version for <tuscany:SOAPExtensions/>
to find the highest extension protocol that the service can understand.
This namespace is 1.1, so it sends the old 1.1 protocol.
Conversely, if a Tuscany SCA 1.1 client sees WSDL containing:
<wsdl:binding name="...." type="...." xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.2">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<tuscany:SOAPExtensions/>
<wsdl:operation name="....">
....
</wsdl:operation>
</wsdl:binding>
it knows the service understands all Tuscany SCA extension protocols
up to and including 1.2, so it sends the 1.1 protocol and the service
will be able to handle this.
This works as long as both of the following are true:
1. A client can send its current version protocol and any older
version required by a down-level service.
2. A service can understand its current version protocol and any
older version sent by a down-level client.
As we don't have this version marker on the WSDL binding in
Tuscany SCA 1.0, we will need to assume a default version of 1.0
if the binding does not specify a Tuscany SCA extensions version.
Comments, questions?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Fixing TUSCANY-1849 without breaking interoperabliity
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks for these comments. My responses are inline below.
Simon
Raymond Feng wrote:
> Hi,
>
> I have a few comments:
>
> 1) I think it's out of 1.0.1 release considering TUSCANY-1849 is too big
> for a point release.
>
OK.
> 2) Can you explain why we need to have <tuscany:SOAPExtensions/> in the
> WSDL? I'm not keen on requiring extensions on WSDLs as it doesn't work
> with existing WSDLs and other tools/runtime cannot understand them.
>
I thought all WSDL tools would ignore extensions that they don't
understand, just like proprietary extensions in SCDL will be ignored.
Perhaps I need some help in understanding if this is really the case
in practice.
The reason we need this or something like it is that we have added a
Tucsany-specific protocol to the binding for converations and callbacks.
In this case, a Tuscany client can't just talk to a regular Web service
that has regular WSDL, because the service won't understand the
Tuscany-specific protocol elements that we are sending. Conversely,
a Tuscany service that supports conversations or callbacks needs the
Tuscany-specific extensions to the protocol to be sent, or it won't
work correctly. A generic Web services client won't be able to do this.
Since WSDL defines the interface between client and service, we should
have something in the WSDL that indicates the need for the additional
protocol. This is like the <wsa:UsingAddressing> binding element,
which says that the service uses addressing and needs addressing headers
to be sent.
This element provides a marker that Tuscany protocol extensions are
needed. Because it uses the Tuscany namespace, it also includes a
version number that can be used to identify which form of the extensions
should be used. This is important if this form ever changes in order to
add new capabilities or to fix a bug (as in this case).
> 3) Implementing a versioning mechanism might be too early before we see
> a direction on the SCA spec on how to version SCA artifacts.
>
These discussions are currently in progress. The versioning scheme
proposed in OASIS uses a year/month version indicator, not a release
number. In the case of Tuscany artifacts I believe a release number
is simpler for our users to understand, and fits better with the
well-defined release process that we have.
Simon
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
> To: <tu...@ws.apache.org>
> Sent: Sunday, October 21, 2007 12:13 PM
> Subject: Fixing TUSCANY-1849 without breaking interoperabliity
>
>
>> I have been thinking about how to fix TUSCANY-1849 without breaking
>> interoperability with Tuscany SCA 1.0, and how in future we could
>> make other protocol changes without breaking interoperability.
>>
>> I have the outline of a proposal. Some details are not finalized.
>> At this stage I would welcome comments on the general principle.
>>
>> Tuscany SCA currently puts callback and conversation information on
>> the wire using Tuscany-specific protocol elements in the Tuscany SCA
>> namespace, which is currently
>> http://tuscany.apache.org/xmlns/sca/1.0
>>
>> If an incompatible change to this protocol is needed for any reason,
>> then a new version of the Tuscany SCA namespace would be created.
>> For example, if we were to fix TUSCANY-1849 in Tuscany SCA 1.1 by
>> changing the protocol for callbacks and conversations, we would
>> create a new namespace
>> http://tuscany.apache.org/xmlns/sca/1.1
>>
>> We would also add a Tuscany-specific element or attribute somewhere
>> within the WSDL <binding> element to indicate that Tuscany-specific
>> protocol extensions are being used for callbacks and conversations.
>> For example, we could define an empty marker element
>> <tuscany:SOAPExtensions/>. The WSDL would then look like:
>> <wsdl:binding name="...." type="...."
>> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
>> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
>> style="document"/>
>> <tuscany:SOAPExtensions/>
>> <wsdl:operation name="....">
>> ....
>> </wsdl:operation>
>> </wsdl:binding>
>> These extension elements are effectively part of the binding and
>> it seems appropriate to specify the use of them there.
>>
>> When Tuscany SCA generates WSDL either statically or dyanmically,
>> it would add the necessary marker element to all bindings that
>> require these extensions (i.e., all bindings for port types that
>> represent conversational interfaces or interfaces with callbacks).
>>
>> Now we have the information needed to make future protocol changes
>> without breaking interoperability. Suppose the Tuscany-specific
>> protocol extensions change between Tuscany SCA 1.1 and Tuscany SCA 1.2.
>> If a Tuscany SCA 1.2 client sees WSDL containing:
>> <wsdl:binding name="...." type="...."
>> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
>> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
>> style="document"/>
>> <tuscany:SOAPExtensions/>
>> <wsdl:operation name="....">
>> ....
>> </wsdl:operation>
>> </wsdl:binding>
>> it would look at the namespace version for <tuscany:SOAPExtensions/>
>> to find the highest extension protocol that the service can understand.
>> This namespace is 1.1, so it sends the old 1.1 protocol.
>>
>> Conversely, if a Tuscany SCA 1.1 client sees WSDL containing:
>> <wsdl:binding name="...." type="...."
>> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.2">
>> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
>> style="document"/>
>> <tuscany:SOAPExtensions/>
>> <wsdl:operation name="....">
>> ....
>> </wsdl:operation>
>> </wsdl:binding>
>> it knows the service understands all Tuscany SCA extension protocols
>> up to and including 1.2, so it sends the 1.1 protocol and the service
>> will be able to handle this.
>>
>> This works as long as both of the following are true:
>> 1. A client can send its current version protocol and any older
>> version required by a down-level service.
>> 2. A service can understand its current version protocol and any
>> older version sent by a down-level client.
>>
>> As we don't have this version marker on the WSDL binding in
>> Tuscany SCA 1.0, we will need to assume a default version of 1.0
>> if the binding does not specify a Tuscany SCA extensions version.
>>
>> Comments, questions?
>>
>> Simon
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Fixing TUSCANY-1849 without breaking interoperabliity
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have a few comments:
1) I think it's out of 1.0.1 release considering TUSCANY-1849 is too big for
a point release.
2) Can you explain why we need to have <tuscany:SOAPExtensions/> in the
WSDL? I'm not keen on requiring extensions on WSDLs as it doesn't work with
existing WSDLs and other tools/runtime cannot understand them.
3) Implementing a versioning mechanism might be too early before we see a
direction on the SCA spec on how to version SCA artifacts.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Sunday, October 21, 2007 12:13 PM
Subject: Fixing TUSCANY-1849 without breaking interoperabliity
>I have been thinking about how to fix TUSCANY-1849 without breaking
> interoperability with Tuscany SCA 1.0, and how in future we could
> make other protocol changes without breaking interoperability.
>
> I have the outline of a proposal. Some details are not finalized.
> At this stage I would welcome comments on the general principle.
>
> Tuscany SCA currently puts callback and conversation information on
> the wire using Tuscany-specific protocol elements in the Tuscany SCA
> namespace, which is currently
> http://tuscany.apache.org/xmlns/sca/1.0
>
> If an incompatible change to this protocol is needed for any reason,
> then a new version of the Tuscany SCA namespace would be created.
> For example, if we were to fix TUSCANY-1849 in Tuscany SCA 1.1 by
> changing the protocol for callbacks and conversations, we would
> create a new namespace
> http://tuscany.apache.org/xmlns/sca/1.1
>
> We would also add a Tuscany-specific element or attribute somewhere
> within the WSDL <binding> element to indicate that Tuscany-specific
> protocol extensions are being used for callbacks and conversations.
> For example, we could define an empty marker element
> <tuscany:SOAPExtensions/>. The WSDL would then look like:
> <wsdl:binding name="...." type="...."
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
> style="document"/>
> <tuscany:SOAPExtensions/>
> <wsdl:operation name="....">
> ....
> </wsdl:operation>
> </wsdl:binding>
> These extension elements are effectively part of the binding and
> it seems appropriate to specify the use of them there.
>
> When Tuscany SCA generates WSDL either statically or dyanmically,
> it would add the necessary marker element to all bindings that
> require these extensions (i.e., all bindings for port types that
> represent conversational interfaces or interfaces with callbacks).
>
> Now we have the information needed to make future protocol changes
> without breaking interoperability. Suppose the Tuscany-specific
> protocol extensions change between Tuscany SCA 1.1 and Tuscany SCA 1.2.
> If a Tuscany SCA 1.2 client sees WSDL containing:
> <wsdl:binding name="...." type="...."
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
> style="document"/>
> <tuscany:SOAPExtensions/>
> <wsdl:operation name="....">
> ....
> </wsdl:operation>
> </wsdl:binding>
> it would look at the namespace version for <tuscany:SOAPExtensions/>
> to find the highest extension protocol that the service can understand.
> This namespace is 1.1, so it sends the old 1.1 protocol.
>
> Conversely, if a Tuscany SCA 1.1 client sees WSDL containing:
> <wsdl:binding name="...." type="...."
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.2">
> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
> style="document"/>
> <tuscany:SOAPExtensions/>
> <wsdl:operation name="....">
> ....
> </wsdl:operation>
> </wsdl:binding>
> it knows the service understands all Tuscany SCA extension protocols
> up to and including 1.2, so it sends the 1.1 protocol and the service
> will be able to handle this.
>
> This works as long as both of the following are true:
> 1. A client can send its current version protocol and any older
> version required by a down-level service.
> 2. A service can understand its current version protocol and any
> older version sent by a down-level client.
>
> As we don't have this version marker on the WSDL binding in
> Tuscany SCA 1.0, we will need to assume a default version of 1.0
> if the binding does not specify a Tuscany SCA extensions version.
>
> Comments, questions?
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org