-
1. Re: SOAPProcessor followed by other actions
viniciuscarvalho Jan 7, 2008 8:38 AM (in response to hauch)Hello there Hauch! Yes the SOAPProcessor just put the response from your endpoint into the default entry. I'm having the exactly same problem as you. I don't see the SOAPProcessor as an gateway like jms,jbr,fs. As you said the 1st is easy to overcome by just putting the request in other location, you can provide another location for the response but the request parameters are lost on the process.
We have some problems with soap processor ourselves and we just overwritten it by our own implementation ;) (I love opensource :D ).
If I understood you correctly, you just need the request parameters on the payload right? Even the SOAPProcessor wraps the response before, you can still manipulate it right?
The only issue I have with soap processor is the fact the client needs to wait for the entire action chain to get a response, we needed an quick response from the ws, and have the action chain called in another separate process (we used the ServiceInvoker for that)
regards -
2. Re: SOAPProcessor followed by other actions
tfennelly Jan 7, 2008 9:00 AM (in response to hauch)So are you guys saying that if you set the "set-payload-location" property on a SOAPProcessor action config to e.g. "mySOAPResponse", the response response is not in Message.Body.get("mySOAPResponse"), and the original SOAP request message is still not available in the default Body location??? If this is what ye're saying, then there's a bug! If it's not what ye're saying and ye haven't tried this, then....
"viniciuscarvalho" wrote:
The only issue I have with soap processor is the fact the client needs to wait for the entire action chain to get a response, we needed an quick response from the ws, and have the action chain called in another separate process (we used the ServiceInvoker for that)
That's the case for all ESB actions/services/action-pipelines. That's the model!!! The action pipeline is a composite. You can achieve what you want by splitting the pipeline into 2 separate services... 1st to receive the SOAP message, process it (SOAPProcessor), route to the 2nd asynch and then respond... the 2nd service to perform the rest of the processing asynchronously. I'm certain I've said this to you in the past!! -
3. Re: SOAPProcessor followed by other actions
tfennelly Jan 7, 2008 9:32 AM (in response to hauch)There's also the WireTap action and I'm sure it could be used to route a response between the SOAPProcessor and subsequent actions. By any chance have ye tried that?
-
4. Re: SOAPProcessor followed by other actions
hauch Jan 7, 2008 9:40 AM (in response to hauch)So are you guys saying that if you set the "set-payload-location" property on a SOAPProcessor action config to e.g. "mySOAPResponse", the response response is not in Message.Body.get("mySOAPResponse"), and the original SOAP request message is still not available in the default Body location??? If this is what ye're saying, then there's a bug! If it's not what ye're saying and ye haven't tried this, then....
I had not specified the "set-payload-location" on the SOAPProcessor - my mistake, did not know it was there (maybe the quickstart ws-producer should use this property - so that other could avoid my mistake?).
My real problem, however, is how to use the SOAPProcessor with other actions. What I really would like, was to be able to use it as a gateway followed by other actions without having to worry about soap.
But it seems to me that what subsequent actions read is the soap request, and what that have to reply with is a soap response.
In that way I have to choose either to:
Invoke further services from the webservice method body (no actions...)
or
Handle soap.
If that is correct, that is fair enough - I would just like to get it confirmed before I give up on it (and I would be gratefull if anybody could give me a hint on how to let an action perform the "soap work" for me...). -
5. Re: SOAPProcessor followed by other actions
tfennelly Jan 7, 2008 10:13 AM (in response to hauch)Sorry, all of the ESB actions use what's called a MessagePayloadProxy to get/set the message payload.
So your Webservice impl class (e.g. your jsr181 impl) has access to the current pipeline message via the SOAPProcessor static methods get/setMessage. So, you can set whatever you like on the Message from within the WS impl class and you can control where the SOAPProcessor sets what's returned from the webservice endpoint using the "set-payload-location" property. So (for example), the WS operation impl might set your FooBar object instance on the default message Body location (for use in a subsequent action), and you can divert the SOAPProcessor from overwriting this by setting the "set-payload-location" property to somewhere other than the default location. -
6. Re: SOAPProcessor followed by other actions
viniciuscarvalho Jan 7, 2008 10:43 AM (in response to hauch)"tfennelly" wrote:
That's the case for all ESB actions/services/action-pipelines. That's the model!!! The action pipeline is a composite. You can achieve what you want by splitting the pipeline into 2 separate services... 1st to receive the SOAP message, process it (SOAPProcessor), route to the 2nd asynch and then respond... the 2nd service to perform the rest of the processing asynchronously. I'm certain I've said this to you in the past!!
Yes Tom you did :) Sorry, did not want to raise an issue here, I'm basically just passing on some experience gained here :) -
7. Re: SOAPProcessor followed by other actions
hauch Jan 8, 2008 3:03 AM (in response to hauch)
So, you can set whatever you like on the Message from within the WS impl class and you can control where the SOAPProcessor sets what's returned from the webservice endpoint using the "set-payload-location" property. So (for example), the WS operation impl might set your FooBar object instance on the default message Body location (for use in a subsequent action), and you can divert the SOAPProcessor from overwriting this by setting the "set-payload-location" property to somewhere other than the default location.
Yes, and that solves the overwriting part.
It is no problem to set the response from a subsequent action. The problem is, that it makes me handle the soap part myself.
So, I would still like to know, whether it is correct that I have to choose between:
1. Invoke other services from the webservice method body. If no subsequent actions overwrites the response, the client receives a soap enveloped response.
or
2. Handle soap "by hand" - if subsequent actions should influence the response. -
8. Re: SOAPProcessor followed by other actions
tfennelly Jan 8, 2008 6:37 AM (in response to hauch)Sure... at the moment (if you have follow-on actions in the pipeline), you have to handle creation of the SOAP response by hand.
-
9. Re: SOAPProcessor followed by other actions
hauch Jan 8, 2008 8:14 AM (in response to hauch)Thanks for the reply!
Does "at the moment" by any chance indicate, that there are plans of changing this...? -
10. Re: SOAPProcessor followed by other actions
tfennelly Jan 8, 2008 8:45 AM (in response to hauch)Ultimately, we'd like to be able to auto generate and deploy the WS endpoint and drive the action pipeline from within the context of the SOAP operation, allowing you to feed the pipeline response/result into the SOAP response and back to the client. The current pipelining model doesn't really support this. Add to that the fact that it's quite a chunk of work.
Jeff Delong has just been talking about this in a separate thread (email). We should start a Design Forum thread on it at some point. -
11. Re: SOAPProcessor followed by other actions
hauch Jan 8, 2008 9:12 AM (in response to hauch)Could you point me to that thread?
-
12. Re: SOAPProcessor followed by other actions
tfennelly Jan 8, 2008 9:51 AM (in response to hauch)Th email thread was on email, the forum thread doesn't exist yet.