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 02:44:19 UTC