Dispatch client works even if port QName is wrong

[a sarkar]

I noticed that a dispatch client works even if the port QName is wrong. This doesn't make sense. Here's a client that shows the aforementioned behavior:
https://github.com/abhijitsarkar/java-ee/blob/master/webservices/jax-ws/jaxws-deploy-desc/src/main/java/name/abhijitsarkar/webservices/jaxws/deploydesc/client/CalculatorClient.java

Note: Cross posted in the Enthuware forum but there're only 3 questions there so I don't think it's frequented much, by anybody.

[Himai Minh]

I noticed the WSDL in this page:
https://github.com/abhijitsarkar/java-ee/tree/master/webservices/jax-ws/jaxws-deploy-desc/src/main/resources/wsdl

The targetname space defined in the client code and the WSDL matches.

[a sarkar]

Himai Minh wrote:I noticed the WSDL in this page:
https://github.com/abhijitsarkar/java-ee/tree/master/webservices/jax-ws/jaxws-deploy-desc/src/main/resources/wsdl

The targetname space defined in the client code and the WSDL matches.

You're right, they match now. But the client seems to work even if the namespaces don't match, that's what I don't understand.

[Himai Minh]

When I read CalculatorClient, the service is created using this targetnamespace :http://abhijitsarkar.name/webservices/jaxws/deploy-desc/
Then, the service adds a new port with targetnamespace : http://deploydesc.jaxws.webservices.abhijitsarkar.name/
So, the dispatch is using this new port to invoke the method.

[a sarkar]

Himai Minh wrote:When I read CalculatorClient, the service is created using this targetnamespace :http://abhijitsarkar.name/webservices/jaxws/deploy-desc/
Then, the service adds a new port with targetnamespace : http://deploydesc.jaxws.webservices.abhijitsarkar.name/
So, the dispatch is using this new port to invoke the method.

That's not quite what happens. A webservices.xml deployment descriptor is used to override some of the annotated/default values. The namespace "http://abhijitsarkar.name/webservices/jaxws/deploy-desc/" is what the webservices.xml asks the port-component to use, which in turn, is what is used by the binding and service elements in the WSDL. There's no way to change the SEI namespace, at least not that I found in the webservices.xml, so the port still uses the default namespace "http://deploydesc.jaxws.webservices.abhijitsarkar.name/".
That being said, that's not the problem. The problem is that even if you change the namespace used by the Port, add it to a Service instance, create a Dispatch and then invoke using it, it still works.

[Himai Minh]

I noticed from your wsdls' that you have two CalculatorService with two different targetnamespaces. Maybe, you are calling either one of them. And it works.

[Frits Walraven]

a sarkar wrote:I noticed that a dispatch client works even if the port QName is wrong. This doesn't make sense. Here's a client that shows the aforementioned behavior:
https://github.com/abhijitsarkar/java-ee/blob/master/webservices/jax-ws/jaxws-deploy-desc/src/main/java/name/abhijitsarkar/webservices/jaxws/deploydesc/client/CalculatorClient.java

You are using the addPort() method to create a new port. When you use the addPort() method the WSDL information is not used. This can only be done from a Dispatch client.

However, when you use the getPort(...) method the portName has to match the portName published in the WSDL.

Regards,
Frits

[Himai Minh]

So, addport means to add a port that never exist in the corresponding WSDL?
That also means no matter the QName of the port is wrong or right, the dispatch client can still connect to the service as long as the endpoint address of the service is correct?

[Frits Walraven]

Himai Minh wrote:So, addport means to add a port that never exist in the corresponding WSDL?
That also means no matter the QName of the port is wrong or right, the dispatch client can still connect to the service as long as the endpoint address of the service is correct?

Yes, it can (also) be used when you don't know the portName or when no portName is involved (e.g. you can use a Dispatch client to invoke a JAX-RS service)

Regards,
Frits

[Himai Minh]

I think I can answer my own question.
Refer to the chapter 4 example in Java Web Service Up and Running, ch04 dispatch and dispatch client sample code.
There is a RabbitCounterProvider and there is a client.
The client does this:

   QName serviceName = new QName("rcService", "urn:fib");
   QName  port = new QName ("rcPort", "urn:fib");
   String endpoint = "http://localhost:8888/rc";
   Service service = Service.create(service_name);
   service.addPort(port, HTTPBinding.HTTP_BINDING, endpoint);

The endpoint is where the RabbitCounterProvider is published.
I can change the QName of port into "rcPort1234".
It still connects to the service provider.

But I think the payload of the dispatch client has to be converted into XML, not JAXBElement.
That means I the invoke method of the client has to take a SOAPMessage or StreamSource object, not JAXBElement.
What do you think about that?

[a sarkar]

Frits Walraven wrote:However, when you use the getPort(...) method the portName has to match the portName published in the WSDL.

The getPort methods require an SEI, which suggests to me that it is intended to be used with the dynamic proxy clients. For dispatch clients, there is no client side SEI, so addPort may be the only option.

[Himai Minh]

Correct me if I am wrong.
When the addPort is used, the WSDL is not used by the web service.
When the dispatch client calls the invoke method with Source parameter, the service has to convert the Source parameter from the client into XML.
The service won't know what request JAXBElement the client sends as the WSDL is not used.

[a sarkar]

Himai Minh wrote:The service won't know what request JAXBElement the client sends as the WSDL is not used.

The service never knows what request JAXBElement the client sends. Marshaling is part of the invocation process and is delegated to JAXB by JAX-WS runtime. Similarly, on the service side, the unmarshaling is done by JAXB before the service method invocation. All the service sees are Java objects.
addPort has nothing to do with this process.

[Himai Minh]

That is true. The addPort() method is used when the WSDL of a service is not available.
Since the WSDL is not available, the service won't know what JAXBElement the client sends. For example, using Ivan's StringProcessor as an example, the client sends JAXBElement<ReverseStringReq> during the dispatch.invoke() is called. But the StringProcessor service cannot recognize the JAXBElement<ReverseStringReq>.
It maybe because the service does not refer to the WSDL ,which shows that the input message is ReverseStringReq, as the port is not defined in the WSDL.

[Frits Walraven]

a sarkar wrote:The getPort methods require an SEI, which suggests to me that it is intended to be used with the dynamic proxy clients.

Yes, I agree, am not saying the getPort should be used by a Dispatch client.

a sarkar wrote:For dispatch clients, there is no client side SEI, so addPort may be the only option.

No, you can leave out the addPort() invocation, e.g.

...
Service service = Service.create(url, serviceName);
Dispatch<Source> dispatch = service.createDispatch(portName, Source.class, Service.Mode.PAYLOAD);			
Source response = dispatch.invoke(createSOAPcontents());
...

Regards,
Frits

[a sarkar]

Frits Walraven wrote:

...
Service service = Service.create(url, serviceName);
Dispatch<Source> dispatch = service.createDispatch(portName, Source.class, Service.Mode.PAYLOAD);			
Source response = dispatch.invoke(createSOAPcontents());
...

The portName in the code above, is it verified against the WSDL as in getPort or just about anything like addPort? Also, addPort is the only method that accepts a binding type, so without that, it might fallback to the default binding?

[Frits Walraven]

a sarkar wrote:
The portName in the code above, is it verified against the WSDL as in getPort or just about anything like addPort?

Yes, it is verified against the WSDL.

a sarkar wrote:
Also, addPort is the only method that accepts a binding type, so without that, it might fallback to the default binding?

Yes, which will be SOAP 1.1 over HTTP.

Regards,
Frits

[a sarkar]

Thank you Frits.