wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] V2 Schema and WSDL Issues
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 7 Apr 2005 07:57:02 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]