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 Tuesday, 4 February 2003 19:40:16 UTC