The amount of re-use will still be smallish
with such limited sharing. (Given nature of XML Schema and WSDL and our quite
comprehensive changes above v1).
Also, a simple developer/tool re-factoring
of generated classes can allow an implementation to support multiple versions,
even if doc schemas use strictly versioned namespaces. E.g. Given a v1 & v2
situation, like we have for WSRP, I typically: generate classes for v1; make
classes that will not change in v2 version independent (just a renaming
typically); (re)generate v1 and v2 classes; edit these to both make use of the
version independent classes (i.e. both v1 and v2 extend these as a common base
with only v2 adding fields). Obviously, this should only be done (hopefully
once) on relatively stable interfaces, post-prototyping v2 say. Note, this
tactic allows for controlled and possibly more sharing to be achieved.
As Rich’s reply states, we will not
really be providing backwards compatible ports (expose version specific v1
& v2 ports, each with their own messages).
Given
the above, should we not go for the cleanest versioning approach, which is to
use strict namespacing for all types and messages (separate namespace(s) used per
version)? That will be simplest for developers to understand (also see Subbu’s
advantages).
Having said that, limited schema type
sharing such as Rich suggests is not impossible to live with. But I believe
many standards and protocols (SAML, UDDI, ?) have gone for the strict namespace
per version separation.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 07 April 2005 12:57
To: wsrp
Subject: Re: [wsrp] V2 Schema and
WSDL Issues
The current draft v2 schema file leverages the v1 types
(no duplicate defines and using extension where possible).
I
find laudable the goal of a v1 Consumer sending a v1 message to a v2 Producer,
however, the nature of wsdl requires a match between the SOAPaction a message
targets and a port offered by the recipient. This requirement would translate
into keeping the QNames of the bound v1 operations unchanged as we release v2
(i.e. place them in the v1 bindings namespace). To do so while making signature
changes (we add parameters and fields) would violate, at minimum, wsdl best
practices and likely invalidate a statement in the services section of the wsdl
1.1 note which allows consumers to make decisions based on the QName of a
portType.
I
think the more reasonable goal is simplifying how a v2 Producer can offer both
v1 and v2 ports. We certainly have been keeping this as a goal in front us
during the work on v2, but should now review carefully how we cast the v2 wsdl
so that the goal is actually realized.
Rich
Subbu Allamaraju
<subbu@bea.com>
04/06/05 10:51 PM
|
To
|
wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
|
[wsrp] V2 Schema and WSDL Issues
|
|
Looking
at the draft xsd and wsdl files, I would like to bring up a few
points.
The current wsrp_v2_types.xsd redefines all V1
types in a new V2
namespace URI, and then makes modifications to it.
On the positive side,
this makes it easy for certain implementations
- those that only offer V2
- those that would like to maintain separate V1
and V2 implementations
with minimal code sharing.
- those that use generic programming (such as DOM,
SAAJ etc.).
For those implementations that generate types from
the schema (e.g.
JAX-RPC), this approach makes type-sharing
impossible since V1 and V2
types have no association (e.g. xs:extension).
AFAIK, none of the web
service stacks support any namespace mapping
between compatible versions.
Another issue is that V1 Consumers cannot send a
V1-compliant message to
a V2 Producer, unless the Producer offers V1 port
that accepts a V1
message, which goes back to code sharing.
Rich - I know you mentioned this earlier, do you
still have a V2 xsd
that extends V1 xsd? If required, I can explore
this further.
On the otherhand, extensions don't completely
solve the problem,
particularly when we change deeply nested types
(I've examples, if
anyone is interested). So, as long as the
additions we make are
immediately under the root of a message, we should
be able to reuse
sub-types.
Any thoughts?
Subbu
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave
the OASIS TC that
generates this mail. You may a link to this
group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php