The Dispatch mechanism operates at a very low level and when you invoke a service using Dispatch, you have to construct either the entire request message (message mode) or the payload that is enclosed in the SOAP body of the request (payload mode).
When you use generated client artifacts, you invoke a method on a proxy object. JAX-WS then helps you, based on the method invoked, the parameters enclosed etc., to create the appropriate request message to send to the service.
Remember that all that is transferred to the service is a SOAP message and its contents.
Thus, when using Dispatch YOU are responsible for creating the appropriate request messages and the data in the message includes data about which operation that is to be invoked. This is more apparent if you use RPC, when the operation names are actually present in the message.
If you want hard, cold, proof, then I suggest you implement the service with two operations as above. Then use some packet sniffer or TCP monitoring tool to see what the requests look like "on the wire".
does not this indicate which operation is going to be called? my guess is that in wsdl url, you are giving operation name requestOrder. so this will go to requestOrder operation given in WSDL. if you want to call the other operation "requestSecureOrder" wsdlURL should look like
or does this url uniquely represent one wsdl without distinguishing at operation level? I didnot get what Ivan was trying to say in the above post.
SCJP 1.4, SCWCD 1.5
Joined: Jun 28, 2007
I guess i missed out that detail, I think that's how it works not sure , will have to try it out , Is there some one who has tried such an example out ?
I think Ivan is saying that when using Dispatch , the resultant soap message will include all details required for the invoke including the operation/method name.
Thus he is suggesting that i implement the service and have a peek at the soap message , that way not much would be left to the imagination !
It would be a happier (feeling a little lazy) thing if some one has done it and can confirm our understanding
You are reading SOA using Java Webservices. Please, have a look at Page 151. 4.3 Dispatching: How JAX-WS 2.0 Maps WSDL/SOAP to Java Invocation.
"...Once the dispatching process has determined the soap:address, and therefore the wsdl:port, the wsdlperation needs to be determined. For this, you need to look at the SOAP body, and the interpretation of SOAP body's contents depends on style of WSDL being used."
So, in my opinion 2 factors are important to determine operation by JAX-WS mechanism: "SOAP body's contents" and "style of WSDL being used"
For document/literal wrapped style, name of the operation being transferred on wire originates from name of input wrapper element.
So, contents of your "xmlSource" is important in this case.
SCJP, SCWCD, SCBCD, SCDJWS
Joined: Jun 28, 2007
Thanks for pointing it out to me and that pretty much explains which operation would be invoked given a soap envelope.
I was also wanting to know that if the service had two operations and the client was using dispatch then how would the client be able to specify that he wants to invoke operation A and not operation B.
To which venkat replied with , where
specifies the operation name.
I am guessing everyone agrees with it , I have not tested it out. If i do will post my findings here
Joined: Apr 15, 2009
I don't agree. I don't know whether it works fine. Maybe, but I think it is rather not interoperable and portable solution. Could you point to me some specification of the url and parameters structure and relation to the operation name ?
As I mentioned in my previous post - SOAP binding in WSDL gives us location of a port. Pure and simple. Contents construction of the SOAP Body and style of WSDL document are important; the both factors can say something about the name of an operation.
Please, look at my example:
Response(shortened for brevity):
Joined: Jun 28, 2007
I got your point , I will write down my understanding if you could just confirm it, it'll be great.
In case of document/literal wrapped , The request message holds the key, like in your example
pl : op1
specifies which operation will be invoked.
I then went and looked up the request XML for the example posted , here specifies the operation name.
If i wanted to invoke requestsecureorder the XML would have to be instead of requestOrder
I think this pretty much sums up what all of us where trying to say.
Correct me if i am wrong.