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" <[EMAIL PROTECTED]>
To: <tuscany-dev@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to