Skip to main content

Why is the serviceName mandatory for, QName)?

Please note these forums are being decommissioned and use the new and improved forums at
3 replies [Last post]
Joined: 2011-12-05

Hi, i've spent a couple of yours in the Java community, was a spec lead for one of our JSRs a while back, also spent some time with Web-Services, and am teaching Java, distributed systems and the lot for over 10 years. So I'll probably not pass as a bloody novice, but still I cannot figure out one recurring and very nagging question when holding lectures about dynamic (i.e. bottom-up) web-service clients:

Why on earth isn't there a method, or alternatively, why doesn't, QName) accept null as a QName, in order to create a dynamic proxy from a WSDL that has exactly one service element, throwing an exception in case it finds more than one?

The method fetches the WSDL from the given location, and inside a WSDL there can be one or more service elements. Clearly, the normal case is that there is exactly one, with more than one service per WSDL being something for prefessionals. So why does the API force a-priori knowledge of something that it can figure out itself 99.9% of the time, i.e. every time a WSDL has exactly one service element? The Metro implementation even lists the valid service names for us in an exception when we pass an invalid name! So why not just choose automatically when there is only one service section in the WSDL whenever there is no contradictory service name specified?

Is this a kind of joke to see how many million hours of wasted beginner's time the API designer can pile up with a single NullPointerException? This one omission means that beginners have to deal uneccessarily with the following technologies, just to create a client for a HelloWorld Web-Service without applying a-priori knowledge about the internals of a WSDL file:

- WSDL basics, Service Names

- QNames and their mapping to qualified Java class names

- Java Reflection (to fetch a package name from a Java service interface, reverse it's components, and build the QName

- The serviceName attribute of the @WebService annotation to force the WebService name to equal the service interface's

All this seems totally unneccessary if there'd be a, or if, QName) would accept null to indicate single-service WSDL mode in dynamic proxy generation. Creating a dynamically created client proxy for a simple web-wervice could be as easy as this, with no special knowledge required except how to create a URL:

final Service proxyFactory = Service.create(serviceURL, null);

final MyServiceInterface proxy = proxyFactory.getPort(MyServiceInterface.class);

I understand that this is not a problem for professionals, everyone of us knows to how take a simple look into the WSDL. But we're not beginners. Beginners are drowned in technological detail, especially when it comes to web-services! And here they seem to be drowned for no reason I can figure out, and this at the end of the year 2011!

Does anyone of you have a good answer? I'd be very graceful not having to tell my students again and again that quite a number of Java-Designers was kinda braindead when this was designed and reworked over the years ...

Thanks in advance,

Sascha Baumeister, former spec-lead JSR086

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-19

I am sorry to read that a valid technical point would be obscured by such an unprofessional choice of words.

Joined: 2011-12-05

Probably difficult to understand why I feel angry ... maybe a little story helps. If you're not interested, plase don't read further, but this is how I feel the problem could have arisen, and this makes me very angry:

--- hypothetical story ----

Rob: Hi Steve!

Steve: You won't believe it, they just fired Mc Alister!!!

Rob: Mc Alister, the genius? The guy than consistently managed to make complex stuff look simple?

Steve: That guy exactly! His last work was marvelous, but after he was finished the replies were so enthusiastic that management decided his topic was easy, and he took too long to solve it!

Rob: Crazy! Look at Old Barnicle, the guy that never grasped anything but how to make simple stuff look complex. They never fired him, and they never will!

Steve: That's because mamangement knows they can't do without him. He's mangled up his projects so badly that it'd all have to be redesigned from scratch. Mc Alister on the other hand is totally expendable, because he's not required to rework his stuff (cool design, simple to manage), and he's neither required to train people in using his stuff, because he totally encapsulated the problem. Therefore, Mc Alister is expendable, and Old Barnicle is not. Was the same for the old S/390 guys at IBM, remember?

... silence ...

Rob: You know what I'm just thinking about?

Steve: I think so ... maybe our WSDL project is too simple, especially since it targets a "Simple Object Access Protocol"?

Rob: Yeah ... it's too simple. And it's simplicity will make us replaceable, too!

... silence ...

Rob: Maybe not! I heared about a guy a while back that put a riddle into one of his API calls. Only if the correct riddle answer was passed, users got results, totally crazy. Maybe we could do the same to "encomplexicate" WSDL a little? Make it just unwieldy enough so people can still marvel it, but need us and other "experts" to answer to complexity that we artificially generated?

Steve: Hmmm ... we already have multiple ports per service in the WSDL design, but that's natural. How about putting in multiple services per WSDL?

Rob: Yay, crazy! But API designers already think about shorting out the Multi-Port complexity in case there's only one port. Having multiple services will force APIs to choose one of them, and for that they need to know the WSDL-internal name for it. But how do we prevent people to simply shorten this complexity out too, in case a given WSDL has only one service?

Rob: Hmmm ... difficult. We could tell them that the WSDL is the most important thing in the world, that it's internals are the bible, and everything else has to follow it?

Steve: You think they'll buy THAT???

Rob: If we're careful, yes. After all we're riding the XML wave, and at times like these you can get through with a lot. Look at Java: We'll have to introduce a namespace mapping anyways, and we already agreed on reverse package names. As long as these names stay internal to a WSDL file, and noone needs to look into the file to get things up and running because everything is taken care of by runtime tools, we're obsolete! Does anyone visit hellishly expensive courses to learn the details of the Java RMI protocol?

Rob: No, they don't! But just think how cool it would be if all the programmers in the world, all the students, every programmer on the planet has to know about how to convert a class name into a namespace qualified WSDL Service-Identifier before they can even receive a single web-service transported "Hello" World". Of course, the Hello-World tutorial itself will work easily enough because we'll just place the WSDL-internal identifier hard-coded into the program. If someone asks, we'll just tell them that the WSDL identifiers are the deciding bit, and then we'll talk mumbo-jumbo about the need to have language independent unique names, which is true after all. If we manage to do that until they forget about the real question, which is why they need to know about the identifiers in the first place for simple setups, we've won!

Steve: We could hold lectures about this until we die, and if we're lucky noone will even notice how they've been humbugged! Heck, people might even feel sorry about the fools who notice and can't hide their anger professionally!

Steve: This so soooo cool! Lets do it!

And so it was done ...
--- end of hypothetical story ---

Joined: 2011-12-05

Then please forgive my anger, and stick to the technological point? :)