Re: [wsrp] V2 Schema and WSDL Issues

[Rich Thompson <richt2@us.ibm.com>]

Most of the types that are defined in
the latest schema resulted from one of two cases (which do not involve
real v2 changes):

1. Switching to using the Handle, ID
and Key types rather than string. This acknowledges that stacks can now
handle these, but impacts many core types.

2. The need for any type which includes
a changed type to also be defined. My testing said that if this was now
done, the changes in included types would not be reflected.

Rich

Subbu Allamaraju <subbu@bea.com>

04/07/05 09:35 AM

To	wsrp <wsrp@lists.oasis-open.org>
cc
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).

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


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