2008/1/31, Guillaume Nodet <[EMAIL PROTECTED]>: > How would you handle SOAP processing like WS-Addressing, WS-RM where > the creation of the ouput message needs some information about the > input message ? > We can't really rely on our users to set all those informations on the > output message ...
To be clear - I don't know those standards, so don't beat me if I say something stupid ;) But to answer your question - I believe that good old institution of local variable in your processor/endpoint is enough. You can remember your current message in local variable and create a new one you will respond with. I imagine this model to be composed of: * something similar to Exchange (I'll stick with this name for now) - it contains one message, and a set of properties - those properties contain business specific data, that we want to be available through the flow like transaction ID * Message - that contains body in the way it is now, and headers that contain some metadata, that are used in endpoints as protocol specific data (headers in HTTP, properties in JMS, METHOD_NAME to invoke in bean, ...) When you process the 'Exchange' (in endpoint/processor) you are free to change the message itself (like operation on 'in' message) or simply put a new one as a response (like operation on 'out' message). If you need both during your processing - simply keep the old one as your variable. It is like requiring a java function to return its own parameters. If you need them, just keep them. You just send the message (parameters and function name) to the object, and receive a message (the response) that doesn't have original parameters by default (but you can return them like when you return your original 'in' message) So (I believe) you are able to do it if you need, but this is processor specific need, and don't have to be exposed to general API. Roman
