"kukeltje" wrote : Signing messages and/or encrypting overcomes this, but is difficult to enforce when responding. That is one of the reasons I think all this belongs outside jBPM. | "aapthorp" wrote : Yes, that was what I was referring to. I agree that the channel specific handling is not a jBPM responsibility. However, the mapping to alternative standard forms or a canonical definition of data (i.e. not just java class definitions) for exchange over an ESB etc is something that might be included as helper functions. So client binding can be at the java API level or at the level of services exposed via an ESB etc... I agree that it is not part of the core business of jBPM. But if we add such capabilities, then our users will be much more productive, and the solution that we offer will be much more attractive. Building in those channels into jBPM doesn't mean that you *must* use them. It only means that developers can save that time when selecting jBPM. All those addons have to be related to our core business, which is state management. But they can really give the project a big boost, I think. I meet much more shops that have a hard time in getting technology to work, then companies like yours that know what they're doing. For the former type of companies, having such addons out of the box is a big deal (literally:-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137961#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...