anonymous wrote : Isn't the enterprise jar supposed to expose some functionality remotely? If so, the console would be a client of that functionality like any other component deployed on the container, like in fact a remote test case. If test cases could use the enterprise beans to deploy processes remotely, all that cactus stuff would not be needed, right? The enterprise jar exposes the command service remotely, and the jms messaging / ejb scheduler services locally. If test cases were written in terms of commands (the EjbSchedulerTest actually is) then Cactus would not be needed. Nevertheless, the web console is not written in terms of commands because it is meant to work either standalone or in tandem with the enterprise jar. Because (a) it relies on the local functionality and (b) it is the only client provided with the distribution, it is not like any other client component. anonymous wrote : So what is the actual benefit of using the ear packaging? From my perspective it only adds another level of component packaging. In fact, since the enterprise beans do not form an integral part with the console alone, it would be quite inappropriate to package them together with the console. It removes a duplicate set of environment references between the console and the enterprise jar. The console may not be the only possible client, but it is the only official client for sure. The ear packaging does not affect other clients: they bind their references to the JNDI names used by the jBPM enterprise beans and voila. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175188#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...