the command service in pvm will be a building block. it's up to the process languages or products to use that block and create public API's with it. products can choose to build a full session facade and still expose the CommandService's execute(Command) method. so in that context, command service can be both public and private. i realize that this leaves too many unresolved variables in the equation for it to be resolved. the risk is always there that we will try to build a web services solution that is too generic. in the solution that you work out, you'll have to make some choices anyway. but it would be good if you have an idea on how the solution fits this overall picture. for sure, the product specific session facades will have to be exposed as web services. if the generic command executor could be exposed as well, that would be nice to have, but i can see there are a lot of problems with that. maybe there is a ws technology in which commands can be extended to have a java-to-xml-and-back conversion. another approach is not to leverage the current domain model objects (ProcessInstance, Token, ProcessDefinition,...) but instead just to define a completely separate set of limited DTO's just for the web service publication. then the web service would be fixed (not very extensible). and it would be easy to implement with JAXB since the DTO's are under control of the web service. That would be the simplest solution that works. If we can find a solid alternative solution that is more generic, that is better. But it doesn't have to be more generic if it's going to be more complicated for the user or for the implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125026#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...