Re: HTML version of operation name proposal

Sanjiva Weerawarana wrote:

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

That was indeed one of the options we discussed at the F2F.

Interestingly, I think that the "burden" argument works better
in reverse. Instead of forcing people to come up with funny
operation names, we implicitely qualify them with the target
namespace name (which they had to specify anyway) and
that takes care of most inheritance problems quite nicely.

Not to mention that it's easier for a tool to drop the namespace
name than unmangle an operation name, given that different
people/corporations/organizations would use different
mangling schemes.

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

But that's much worse!

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

Yes, if you follow the best practice you won't ever be in trouble.

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

Mangling is needed only when you'd otherwise run into conflicts. You can
certainly come up with scenarios in which the whole scheme breaks down,
but as I pointed out earlier, the potential for naming conflicts is always
present. So these seem more like arguments against inheritance than
against having qualified operation names.

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

J2EE client applications carry the mapping info with them, so there is
no problem there. On J2SE it's different, but then there is no pre-populated
JNDI and no JAX-RPC stub downloading either, so you'll package stubs
with your applications (or use DII).

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

The XML Name to Java identifier mapping is not 1-1, hence the
potential for conflicts when mapping operation names to method names.

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

I'll admit that it's a 80/20 solution, but it works quite well. Overloading
is a long, dark tunnel with no end in sight.

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

Yes, but how is that hard? We already use QNames to refer to things in so
many places, there's nothing new to learn.

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

Message? What message?  ;-)

Roberto

Received on Friday, 31 January 2003 14:28:47 UTC