Re: HTML version of operation name proposal

"Roberto Chinnici" <roberto.chinnici@sun.com> writes:
(other stuff deleted)
> > 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.

In summary, you are saying that the right thing to do is use global
operation names (where the operation name is now a QName).

I thought that's exactly the problem we were trying to solve?

[Other stuff removed]

> > 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 dibfferent, but then there is no
pre-populated

There is still a problem with J2EE clients: Let's say you are the service
author and you define a name mapping table and change some names. So the
SEI now has the mapped named.

Let's say I am writing another J2EE app in the same enterprise and want to
use your service. Now, when you publish that service, the only thing I
can find is its WSDL. Given that WSDL, if I generate the JAX-RPC
bindings and attempt to do a JNDI lookup for a stub impl it won't work
because the interfaces won't be the same. In fact, they will have the
same fully qualified names, but the classes won't match - leading to a
class mismatch exception. Am I getting this wrong?

> JNDI and no JAX-RPC stub downloading either, so you'll package stubs
> with your applications (or use DII).

I agree that there's no implicit sharing architecture in J2SE. However,
if someone has done any mappings then I can't arbitrarily pick up
that person's stub as there's no way to tell me that such mappings
have taken place; again I will get a class mismatch error.

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

I don't buy this comment: interface inheritance and overloading
have always gone hand-in-hand with OO languages. If we have interface
inheritance then we need to have overloading. Otherwise the only
solution is to have globally unique names; which is what the proposed
best practice suggests.

Why is it a long, dark tunnel with no end in sight? We had it WSDL 1.1 and
we didn't take it out because it was ultra complicated; we took it out
because we felt it was not necessary (I was in fact who pushed to have it
removed). Interface inheritance was added after we took out overloading
and now I'm asking that we put back what we had. (Or we can always
remove inheritance, but then I'll probably have to look for another
job ;-)).

Sanjiva.

Received on Thursday, 6 February 2003 00:07:33 UTC