aspose file tools*
The moose likes Web Services Certification (SCDJWS/OCEJWSD) and the fly likes Dispatch client works even if port QName is wrong Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Services Certification (SCDJWS/OCEJWSD)
Bookmark "Dispatch client works even if port QName is wrong" Watch "Dispatch client works even if port QName is wrong" New topic
Author

Dispatch client works even if port QName is wrong

a sarkar
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
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.


Abhijit
-------
SCJP 5, SCBCD 5, OCWCD 5, OCEWSD 6, CSM
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1675
    
  25

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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1675
    
  25

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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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:


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
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1675
    
  25

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.

Regards,
Frits
a sarkar
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
Frits Walraven wrote:


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
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1675
    
  25

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
Ranch Hand

Joined: Aug 05, 2010
Posts: 92
Thank you Frits.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Dispatch client works even if port QName is wrong