Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does a JAX-WS client access the WSDL at run-time?

Tags:

wsdl

jax-ws

After generating JAX-WS client using the wsimport

wsimport -keep WebService.wsdl

What reason does JAX-WS have to look for the wsdl location at run time?
Is this a bug?

I found this great post: JAX-WS client : what's the correct path to access the local WSDL?

but it doesn't say why do we need the wsdl at runtime

like image 966
JavaSheriff Avatar asked Nov 20 '13 16:11

JavaSheriff


People also ask

What is a service endpoint interface for a JAX-WS SOAP web service?

A service endpoint interface or service endpoint implementation (SEI) is a Java interface or class, respectively, that declares the methods that a client can invoke on the service. An interface is not required when building a JAX-WS endpoint. The web service implementation class implicitly defines an SEI.

Where do I put WSDL files?

The files referenced by the <wsdl-file> element in the webservices. xml might import other WSDL or XML Schema Definition (XSD) files. Typically, all WSDL or XSD files are initially placed into the META-INF/wsdl directory when using Enterprise JavaBeans (EJB) or the WEB-INF/wsdl directory when using Java™.


1 Answers

Is this a bug?

No, this is not a bug, but reasonable from a conceptual point of view.

What reason does JAX-WS have to look for the wsdl location at run time?

At build-time, you generate classes from the WSDL which means you need to know what kind of operations the service supports and what structure the messages have (aka portTypes, types, messages).

At run-time a whole lot of different information comes into play. For instance, the actual address the service runs on might have changed. The bindings become relevant: Should messages be sent in SOAP 1.1 or 1.2 or are both formats ok? Futhermore, all sorts of policies (security, reliable messaging, etc.) might be attached to the service. All these things are dynamic and mostly irrelevant at build time. Ideally, you should be able to point your client at a different service that uses the same structure and it should work out of the box.

I'd like to answer another question I think you might have:

Isn't this a total overhead in cases where there is just one service that never changes?

Yes, it is. In cases where there is single service with a particular WSDL that never ever changes from its build-time state, reloading the WSDL at run-time is unnecessary and a waste of ressources. But JAX-WS would do a terrible job if it wouldn't allow for more complicated scenarios where information such as bindings or policies do change or where there is more than a single endpoint for the service.

Nonetheless, most JAX-WS implementations do allow for some mechanism to store the WSDL locally and not load it for invocations at runtime. In the RI, simply pointing the wsdlLocation in your @WebServiceClient to the file on the classpath should do the trick.

like image 109
joergl Avatar answered Sep 27 '22 19:09

joergl