RE: HTML version of operation name proposal

Sanjiva,

Hopefully answering some of your questions:

Firstly, this is not my proposal. This proposal was worked out by the
WG, based on a suggestion from Roberto, at the face-to-face in Phoenix.
I just offered to write it up. I note that we discussed various
solutions at the face-to-face, including all the ones mentioned so far
in this thread. This proposal was the only one that got any real support
( the only other mildly popular option was 'status quo' ). I agree that
it is not perfect for the GGF use-case but it was considered to meet the
80/20 point by the GGF representative and the wider WG. It was also a
minimal change from the status quo.

There has been much discussion of language bindings in this thread, I
fail to understand the problems:

Given the following operation names

	{target namespace}       {name}
	http://example.org/foo   op1
	http://example.org/foo   op2
	http://example.org/bar   op3

I would define a class/interface with methods called op1, op2, op3 ( I
would ignore the {target namespace} property ). I would probably name
the class after the port type.

Given the following operation names

	{target namespace}       {name}
	http://example.org/foo   op1
	http://example.org/foo   op2
	http://example.org/bar   op1

then if I had a language that supported method overloading and the
messages that the two op1 operations were sufficiently different then 
I would define a class/interface with methods called op1, op2, op1 (
again ignoring the {target namespace} property ).

If my language did not support method overloading and/or the messages
that the two op1 operations were not sufficiently different then
I would mangle one of the op1 names. Of the top of my head, here are
three ways I might do that mangling, I'm sure there are others:

A) included some piece of the {target namespace} property in the method
name
B) include the {name} of the port type in the method name
C) Append an ordinal to the method name

So it seems to me that I only need to do name mangling if I end up in
the last situation. I would also note that there is no need to include
the {target namespace} property of the operation in the method name.

Gudge

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: 31 January 2003 07:41
> To: Roberto Chinnici
> Cc: Martin Gudgin; www-ws-desc@w3.org
> Subject: Re: HTML version of operation name proposal
> 
> 
> "Roberto Chinnici" <roberto.chinnici@sun.com> writes:
> > >
> > >In effect, if we accept this proposal we would have made 
> operations 
> > >top level components!
> > >
> > Not at all. Operation names must be unique only within a 
> portType, not 
> > globally, so this proposal is very different from making operations 
> > top-level components. The only
> > similarity is that operation names would be QNames in both cases.
> 
> Oh I see. Sorry for missing that.
> 
> Hmm. Why bother doing that and introducing all this weirdness 
> of it looking like a QName, feeling like one but its not. 
> Instead, I suggest we tell the Grid guys that they should 
> just encode the type name into the operation name and 
> basically handle things on their own. That is, if they want 
> foo (int) and foo (float), they can plan ahead and do:
>     portType p1 {
>         operation foo_int (..)
>     }
> 
>     portType p2 extends p1 {
>         operation foo_float (...)
>     }
> 
> They can do what they want and no weirdness for WSDL.
> 
> Why am I suggesting this? Because all we're doing is creating
> a way to make operation names be QNames. The old way of just 
> letting them be NCNames works fine except for this little 
> overloading problem. Do the above and it goes away. Otherwise 
> everyone is burdened with QNames for operation names.
> 
> > At the F2F Steve Graham thought the grid needs were addressed, and 
> > from
> his
> > explanation of what those needs were, I agree with him. If 
> you want to
> leave
> > the option to derive from your portType completely open, 
> all you need 
> > to
> do
> > is to place it in its own namespace, and that's going to be 
> documented 
> > as a best practice. For everybody else, life goes on just 
> as before, 
> > they don't need to
> > learn any new concepts.
> 
> Note that planning ahead and putting your portType into its 
> own namespace so that someone else can derive from it is 
> essentially what I suggested too - except that the operations 
> themselves are encoded under user control rather than via a namespace.
> 
> Incidentally, if you say best practice is that each portType 
> be in its own namespace and that the operation is named by a 
> tuple consisting of {its name, containing portType's TNS} and 
> if these are unique within the portType's TNS, then you have 
> effectively said best practice is to make them be globally 
> unique because every portType should be in its own namespace anyway.
> 
> > >====
> > >package com.sun.www.services.s1;
> > >
> > >public interface pt1 {
> > >  public typeX1 www_sun_com_services_s1_o1 (...);
> > >  public typeX2 www_sun_com_services_s1_o2 (...);
> > >}
> > >====
> > >
> > >====
> > >package com.microsoft.com.services.s2;
> > >import com.sun.www.services.s1.pt1;
> > >
> > >public interface pt2 extends pt1 {
> > >  public typeX3 www_microsoft_com_services_s2_o3 (...);
> > >}
> > >====
> > >
> > >How can that be considered user-friendly and acceptable? 
> The user of 
> > >this interface in effect must know exactly which super portType 
> > >defined every single operation in order to figure out the 
> name of the 
> > >operation.
> > >
> > It doesn't have to be that bad. In most cases, no mangling 
> will occur.
> 
> How is that possible?? How does a WSDL language binder know 
> when to mangle and when not to mangle? It seems to me that if 
> the portType may be extended further down the road then 
> mangling is required. So unless we introduce a "final" 
> concept (does even Java have final interfaces??) then there's 
> no way to not mangle.
> 
> > >No, humans cannot override the JAX-RPC defined mapping; otherwise 
> > >that mapping is no longer a contract I can rely on. That 
> is, if I do 
> > >dynamic lookup of a proxy, then that better not have changed the 
> > >names or all hell will break loose. Do you not agree??
> > >
> > In J2EE 1.4, the mapping can be overriden using a 
> jaxrpc-mapping-info 
> > file and I expect development tools to make it usable in practice 
> > (read: don't force you to
> > write a mapping file by hand).
> 
> The J2EE 1.4 rule is useful for the server side - i.e., I can 
> indicate mapping info when I'm providing an implementation 
> for a WSDL. I'm more concerned about the client side: I pick 
> up a WSDL and want to use it. I use the JAX-RPC binding rules 
> and generate and interface and then do a JNDI lookup to find 
> an implementation class. Two or more apps in my enterprise 
> may do the same for a given WSDL. Where do I get to tell the 
> client "no, no just forget the JAX-RPC rules just use these 
> handy mapping table instead"?
> 
> > >Yes of course this problem exists today. However, I hope 
> that you'd 
> > >agree that that is an entirely different level of the problem than 
> > >the one we are considering creating.
> > >
> > Just because URIs are longer than the typical NCNames?
> 
> No, because NCNames are not hierarchical. URIs are 
> hierachical and will generate very long and cumbersome names.
> 
> > >Finally, given that this proposal does not solve the 
> original problem 
> > >(that of wanting a subtype to define an operation with the same 
> > >name), what problem does this solve?
> > >
> > >
> > >
> > It does solve the problem quite nicely at the WSDL level.
> 
> I disagree.
> 
> > Language bindings will have to deal with some potential naming 
> > conflicts, but they should already be equipped to deal with them.
> 
> Where did you get naming conflicts? I don't undertand this comment.
> 
> > Overloading, on the other
> > hand, would have the same problems and on top of that it would add 
> > typing conflicts *and* force wsdl bindings to become more complex.
> 
> Overloading undoubtedly makes things more complicated. 
> However, that's what's really needed to solve the problem. 
> What this proposal is advocating is a name mangling hack.
> 
> Yes, WSDL bindings are more complex with overloading. 
> However, its only more complex for the person with overloaded 
> stuff. With this proposal, every operation needs to be 
> referred to by QName; thereby affecting ALL users.
> 
> Here's an example binding for {nsuri-3}pt3 (see my original post):
> 
> <definitions targetNamespace="nsuri-3" xmlns:tns="nsuri-3" 
> xmlns:y="nsuri-1"
>              xmlns="wsdl namespace">
>   <portType name="pt3" extends="y:pt1">
>     <operation name="o1"> .. </operation>
>   </portType>
> 
>   <binding name="b1" type="x:pt3" xmlns:x="nsuri-3">
>     <!-- anything common to all operations is fine and it 
> goes here -->
>     <operation name="y:o1"> .. stuff for inherited o1 .. </operation>
>     <operation name="y:o2"> .. stuff for inherited o2 .. </operation>
>     <operation name="x:o3"> .. stuff for my operation o1 .. 
> </operation>
>   </binding>
> 
> Notice that operation names in binding/operation/@name now 
> end up being QNames. (Yes yes we can use two attributes 
> namespace + name instead but you still need to specify the namespace.)
> 
> I fail to see how this is better than overloading .. all it 
> required was a name on a message and for it to be referred to 
> in the binding.
> 
> Sanjiva.
> 
> 
>

Received on Friday, 31 January 2003 11:46:20 UTC