I could not offer a stable API for activity implementations if it would have to cover all the jPDL functionality. That's why jPDL sometimes casts to implementation classes. Ideally the ActivityBehaviour interfaces would expose all necessary functionality. But time to get all that figured out and stable was not there. So I opted to start with an ActivityBehaviour API that only covers the basics. That gives us more time to explore our options before we promote that to supported API (read cast in stone). Same is true for parsing. We could offer a more limited API to build up the process model. But that is going to take more research to get it right. I don't think it is a big problem if implementing a new language for now requires the use of our internal PVM classes. I focussed first on the client API and the typical user pluggability like EventListeners and automatic activities. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248506#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...