Re: [wsrp] V2 Schema and WSDL Issues

[Subbu Allamaraju <subbu@bea.com>]

> 
> The current draft v2 schema file leverages the v1 types (no duplicate 
> defines and using extension where possible).

Are we looking at the same XSD? Looking at 
http://www.oasis-open.org/apps/org/workgroup/wsrp/download.php/12078/wsrp_v2_types.xsd, 
it has a few types extended, but a number of types are redefined. For 
example SessionContext? How about PortletDescription?

> 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 understand the port SOAPAction issue, and given the nature of SOAP 
stacks, we cannot avoid that.

> 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.

Yes, a Producer should be able to offer both ports in its WSDL. But once 
it receives a message, it would be easier if a good chunk of the code 
path is shared (provided implementations make some right design 
choices), particulary for some of the more complex V1 operations.

Subbu

> 
> 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
> 
>