How does a wsimport generated client work?

Question

Before anything else, I want you to know that I can already connect to the web service server. I\'m asking this question because I want to gain a deeper knowledge on how a w

Answer 1

Before I answer the questions, some clarification: JAX-WS is a specification for implementing web services in Java. It describes how WSDL artifacts can be mapped to Java classes and how this mapping can be applied using annotations. You can download the specification here. The tool wsimport is part of the reference implementation of this specification and the reference implementation is part of the Java class library. There are several alternative implementations, such as Axis2, CXF or Metro, that enhance the basic JAX-WS support with support for additional standards such as WS-ReliableMessaging or WS-Security.

Now to your questions:

Am I correct with my assumptions above?

Yes, you are.

What are the function of the other classes?

The package-info exists to map the XML namespace used in the web service to the package in which your implementation classes reside. The namespace normally looks different from a Java package name (normally, it is a URL) and this makes the mapping necessary.

The ObjectFactory allows you to create any of the messages sent and received by the service. You need this if you want to hook in code in front of your stub class, provide modified messages or similar things.

I can't see the content of your classes, but if I understand it right MyWebServicePortType is an interface that resembles the portType in your WSDL. That is, it maps the operations and their signatures in the WSDL to Java methods. If you want to provide the service (which you don't, you are asking about the client), you would need to implement this interface. As you implement the client, you simply use it.

Finally, the class MyWebService contains the client stub you need if you want to invoke the web service.

I inspected MyWebService and it contains an annotation referring to the absolute location of the WSDL I used to generate the client. What is the relevance of specifying the wsdllocation in the client? How does the client use that info?

The interface you generated contains the signature of the portType of the service, but it does not explain how you can talk to the service. This is part of the binding in the WSDL. The most basic setting is a document/literal style for the messages using SOAP over HTTP. Other configurations, such as SOAP over JMS, are possible and your client needs to know what protocol to use. Therefore it needs the binding WSDL. Also, as you state later, there is no endpoint address in your Java files. This address is also read from the WSDL.

I noticed that the actual URL of the web service is not declared in any of the classes generated. How does the client know where it needs to connect to?

It reads the address from the port of the service in the WSDL. This is located of the end of the WSDL.

Was the WSDL file annotated so that the client can read the URL on the WSDL file upon connection?

No, the port is a typical element of a concrete web service endpoint. There's nothing special needed here.

If so, then does it mean that the WSDL file is always read when a new connection must be established?

Well, there could be caching at the client side (I don't know about the details of the reference implementation on this one). From a conceptual point of view: yes, it is.

What if I need to connect to an HTTPS. How can I set the server certificate

This can be tricky, I can't give you an out-of-the-box answer. I would suggest to read through questions on this topic, such as this one.

Is there any difference when I generate my client using wsimport and when I generate it using Axis2 or Apache CXF

Yes, there is. wsimport is better, don't use wsdl2java. Here is a description, why.

Answer 2

You asked: I noticed that the actual URL of the web service is not declared in any of the classes generated. How does the client know where it needs to connect to?

If the WSDL was downloaded using a browser and passed as input to wsimport, then the local wsdl file location is embedded into the generated code. That is why you don't see the actual service location in the generated code. It also means if you deleted the local copy of the wsdl file the generated code will not work (when inovked using a main method) .

If the URL of the wsdl was passed as input to wsimport then that URL is embedded in the generated code, which is further used to get the actual service location. The idea is that the WSDL locations are fixed. They are expected to be in a UDDI or as a local file. This allows the actual services to move around and if they do move, you just have to modify the local copy of the wsdl file alone or update the wsdl in the UDDI. [mostly this does not happen as service locations are never IP but DNS names]

This is why it is never a good idea to publish the wsdl in the same server where your webservice is running