Re: [wsrp] V2 Schema and WSDL Issues

[Subbu Allamaraju <subbu@bea.com>]

Rich Thompson wrote:
> 
> 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.

May we should revisit changing these most commonly used inner types. If 
we avoid changes to those types, we could improve our reuse.

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

True. I was referring to the same when I mentioned changing nested types.

Subbu

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