RE: Action 2003-01-21 for Umit

Umit,

I've not read your mail in detail yet ( I will ) but the answer to your
last two questions:

  "How does your mapping scheme account for mapping parts to headers?
Are they accounted for in the schema as well?"

is that we decided in Virginia that SOAP headers are declared in a
binding by direct reference to either a global element declaration or a
complex type definition. In the latter case, a local name and namespace
name are provided in the binding to specify the [localname] and
[namespace name] properties of the header EII. So the status quo is that
SOAP headers are NEVER parts of a WSDL message.

Gudge

> -----Original Message-----
> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] 
> Sent: 05 February 2003 00:39
> To: Don Mullen
> Cc: www-ws-desc@w3.org
> Subject: Re: Action 2003-01-21 for Umit
> 
> 
> 
> 
> 
> Don Mullen wrote:
> 
> >
> >Thanks for the post, Umit.  You've obviously put a lot of 
> thought into 
> >this, and I'm convinced from your description that it will be very 
> >difficult to map arbitrarily complex schemas to parts.
> >
> >That said: why would one want to be able to do that?  What 
> is the use 
> >case here?
> >
> >
> >I can understand Gudge/Roberto's argument: we can take complex 
> >message/part descriptions and map them to schema and define 
> a binding 
> >for them.  In addition, we can have more complex descriptions of the 
> >message/part combination (cardinality, etc), and leverage 
> schema to do 
> >that.
> >
> >However, why would a web service designer need to take an arbitrary 
> >schema type and map that back to message/part?  If I have a 
> complex XML type that I
> >need to send, then I can send that as a single type, right?  
>  Why do I need
> >to split it into parts?  If I have a complex java signature or other 
> >service, it is pretty easy to map that to schema, but not 
> the reverse 
> >(as you've shown).
> >
> >What am I missing?
> >
> >Don
> >
> Don,
> 
> Let me clarify my use case a bit.
> 
> Today operations have several parts. As a result, this 
> designates them 
> as distinctive interactions and this abstract distinction is 
> also used 
> for designating on the wire signatures. For RPC style 
> interactions, it 
> is very natural to design such interactions with multiple 
> parts at the 
> abstract level and use this definition in the binding. 
> 
> When we remove message/parts by taking away takes away RPC 
> style design 
> and interactions from the web services definition level, what 
> we will be 
> left instead is one schema type and an operation (lets forget about 
> attachments for a moment). There will be no Part concept at the 
> abstraction level. Now, this did not eliminate the fact that certain 
> operations are meaningful with a set of parts. The folks who 
> need parts 
> in their design need to do something. What the proposal will 
> force is to 
> still design with parts and always use the proposed mapping route to 
> arrive at a single schema and as well as to parts at the 
> binding level. 
> That is, the parts did not go away in theory and the design 
> *still* has 
> to account for them. This is suitable for bottom up cases 
> where a WSDL 
> may be generated from a well defined interface.
> 
> However, looking at an arbitrary WSDL document alone, how one can 
> determine that the schema and the binding are valid with 
> respect to each 
> other? This is the use case I had in mind. A WSDL document MAY have 
> binding mappings but there is no guarantee that the resulting WSDL 
> document is derived by following Roberto/Gudge proposal. This 
> is because 
> there is no Part definition in the abstract to relate to and 
> we have one 
> schema at hand. Therefore, we need to do the analysis of the 
> schema (and 
> WSDL) since looking at the WSDL document alone does not 
> reveal how it is 
> generated. This means that we either have a very sound way of 
> allowing 
> part mappings from arbitrary schemas (which are illustrated to be 
>  complex in my previous message) or WSDL restricts the usage 
> of multiple 
> part binding to a very well defined type of schema(s) so that 
> a tool can 
> do this verification.
> 
> I tried to illustrate that the problem is very hard to solve in the 
> general case. I am glad we agree. If we take the latter 
> approach, rules 
> need to be defined to verify that the schema that is mapped 
> to multiple 
> parts belongs to a restricted schema definition.
> 
> The question at large is whether people will *always* follow this 
> transformation routine or not?
> 
> Given the background, let's look at the cases how WSDL may be 
> generated 
> for RPC cases. When a WSDL document needs to be generated from an 
> implementation, it is easy to generate a schema and part mapping 
> conceptually as parts already exist at an implementation 
> level for RPC 
> style interactions. However, when one is designing a web service 
> interface before the implementation is generated, we have created a 
> funny dilemma as there is no part to talk about at the 
> abstract level, 
> but we need to ensure that folks STILL need to think with parts 
> conceptually, do the mapping, binding etc. while we are allowing them 
> one schema only. It may be easy to fall into the trap of just 
> taking a 
> schema and start writing your own mapping to parts. This is 
> problematic 
> for the reasons explained (hopefully) above.
> 
> As a result, I find it quite unnatural as parts still exist at the 
> conceptual level but are not accesible at the abstract level. 
> They are 
> the same thing. A WSDL designer is forced to think with this 
> concept in 
> mind in order to go through a set of  transformations to reintroduce 
> them at the concrete binding level. In reality,  we will need to 
> acknowledge their existence at a conceptual level in order to 
> refer to 
> them for defining the rules of transformation, verification, etc  in 
> our  specification!.  If they are needed at the conceptual level, why 
> remove them? The need to design as well as expose a web service 
> functionality with multiple parts will not go away, but 
> simplicity will.
> 
> We have not discussed this in the meeting but I also request 
> Gudge/Roberto to clarify the following. How does your mapping scheme 
> account for mapping parts to headers? Are they accounted for in the 
> schema as well?
> 
> Hope this explained things a bit and not created unintended confusion,
> 
> --umit
> 
> 
> 
>  
> 
> -- 
> Umit Yalcinalp					
> Consulting Member of Technical Staff            400 Oracle Parkway
> Oracle
> Phone: +1 650 607 6154                          Redwood Shores,
> Email: umit.yalcinalp@oracle.com                CA 94065, USA
> 
> 
> 
> 
> 
>

Received on Wednesday, 5 February 2003 06:15:52 UTC