the recommended way is to "recreate" RuntimeManager same way console does so you have same execution semantics but won't be tightly coupled to the console so you can scale both systems independently. in 6.1 we plan to provide deployment descriptors that should simplify configuration of runtime manager based on kjar.
Thank you for suggestion, Macej, but my requirement is to start new process instances from my REST web service, and monitor their execution on jBPM console - so after a second thought, i doubt recreating the RuntimeManager will work - it will probably execute processes independently of the jBPM console...
I think the only way is to get hold of the jBPM runtime or session (like mentioned here [JBPM-3724] Configurable sessions in jbpm console - JBoss Issue Tracker, i need a shared session in my app).
I know this is not quite 'clean'; the initial design was to use jBPM REST API - but due to the limitations in the REST API (i posted a different question on that) we decided to develop a REST web service to extend on the jBPM REST API.
as long as you configure it with the same data source (or persistence in general) you will get all what's needed to use your REST service for execution and still use console for monitoring and management. This is how clustered setup works, each cluster member has its own instance of RuntimeManagers that are configured consistently and use same data base.