[jbpm-dev] jbpm5 RFQ

Hello all, I'm working now for 2.5 years in a telco project that is heavily based on jBPM 3.2.3. Since the very first steps we really enjoyed jBPM and introduced a couple of modifications and so I take the chance to give some feedback. What we love is the lean&mean approach of jBPM. Introducing new developers to the framework is of course not a matter of hours. But compared to i.e BPEL - which imo is a nightmare - it has a flat learning curve, is extendable and by usage of Java-ActionHandlers: Unit-testable. Basically this application is a order management system that besides its core task performs account/product suspensions, feature provisioning , inventory management, etc. So we have a wide mix of synchronous/asynchronous processes, Webservice and queue communication which additionally have different performance goals. The PVM-targets are pointing to the right direction - at least for our needs. We share the need for a integration layer, however modularity and extensibility should be primarily focused on the core task which is process. 1. saving Java objects as variables The standard mechanism supports saving of business java objects. However, jBPM serializes objects and saves it in chunks. Honestly this feels like a relict from long ago (Oracle 7) where one needed to avoid clobs for performance reasons. We've introduced another converter and Hibernate mapping to store JSON'ed objects in a clob column (on a per-process rather than per-token basis). 2. async node execution A async-marked node will cause JBPM's MessageServiceImpl to create a JMS job-message which in turn is consumed by a MDB/MDP in order to continue execution. Though this is a simple mechanism it has drawbacks. One needs local/sticky queues to remain on the same physical machine. This is to benefit from an already warm cache. Sure one could use a distributed cache. But from our experience there is nothing faster than to stick on the local machine. Moreover, using plain JMS for async nodes leads to an equal distribution of processes being started and the ones being continued. I'd prefer already started processes being executed with higher priority. Therefore we are internally using a thread-pool that gives a higher priority to running processes. 3. transaction management Currently there is no means to separate framework and business transactions. Therefore we have a strict all-or-nothing situation. In case of exceptions one can either commit the transaction in order to have a consistent process-state (and inconsistent business data) or the other (business data consistent but process-state lost because of rollback). All we came up with was to rollback the transaction and reconstructing necessary process-data given the java objects we still were able to access. Additionally jBPM logging is done in a separate transaction. Separating framework and business transactions by means of async actions is not really an option, because every async action runs in a separate transaction. 4. mixing persistent/not persisted processes Nearly all business processes in this application are modeled as jBPM processes (for documentation purposes). Some parts could have easily been replaced by plain java code. As an example think of "classic" orchestrated services bundled in a subprocess. In order to gain performance those sub-processes are not being persisted. Out of the box mixing persistent and not-persistent processes is not possible (think variable copying, subprocesses,...). Besides that we've targeted following points: 5. integration layer (not necessarily ESB) We strongly encourage the introduction of an integration layer. Having to talk to dozens other systems with not necessarily the same release cycles (unexpected API changes) urges for an integration layer. Another example: using WebServices with different security constraints depending on the context of the process. I think there will always be cases that prevent a clean migration path from let's say jBPM3 to jBPM5. Imagine millions of order processes hanging around in the db and waiting to be *properly* migrated... In the end companies will accept such additional investments if the benefits pay of. We are already now able to combine all fancy JBoss products to create a "workflow suite". I'm afraid that by spreading the goals and introducing new/newest technologies (OSGI/BPMN2/other langs/JPA/Drools/...) the focus will be lost. At least our company invests a whole lot of money in describing enterprise-processes, coding and optimizing that processes. I would be glad to see that these tasks were supported best of jBPM. jBPM should provide consistent means to tackle modeling, management and superior execution of processes before taking off for the Clouds. cheers, Zeljko