SOAPProcessor followed by other actions

[hauch]

Is the SoapProcessor different from the other gateways (like jbr, fs, jms) in the sense, that it is not meant to be used with other actions in two-way calls?

The reason for my question is that after having deployed a webservice with a return value, it seems to me that
1. The SoapProcessor overwrites the request with the (soap) response (at org.jboss.soa.esb.message.defaultEntry) immediately after the service has been invoked. Making the request unavailable to subsequent actions.
2. The SoapProcessor returns the value of org.jboss.soa.esb.message.defaultEntry as it is.

The effect of 1. is not to hard to work around (letting the webservice copy the request to another location). But it indicates that this is not an intended use.
The effect of 2. is that you would have to do the soap packing of the request yourself, if the webservice is followed by another action that has an impact on the response.

What I would like was that the sequence: [Webservice (called by SoapProcessor) -> Action 1 -> ... -> Action n] would wrap the content of org.jboss.soa.esb.message.defaultEntry in a soap response after the actions were invoked.

[viniciuscarvalho]

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

[tfennelly]

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!!

[tfennelly]

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?

[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...).

[tfennelly]

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.

[viniciuscarvalho]

"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 :)

[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.

[tfennelly]

Sure... at the moment (if you have follow-on actions in the pipeline), you have to handle creation of the SOAP response by hand.

[hauch]

Thanks for the reply!

Does "at the moment" by any chance indicate, that there are plans of changing this...?

[tfennelly]

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.

[hauch]

Could you point me to that thread?

[tfennelly]

Th email thread was on email, the forum thread doesn't exist yet.