I want to add that I'd like to use jBPM for orchestration. BPEL does not quite work for us as we'd like to orchestrate services that are not necessarily WS.
Is orchestration not a usage pattern for jBPM? Am I totally off-track?
jbpm manages long running processes. so the state of the process execution needs to be stored somewhere inbetween state transistions. the most common way to store the state is in a relational database.
so the process variables form the context of a process instance and need to be stored as part of the process execution (=ProcessInstance).
several options exist on how to make your "complex" objects persistable as part of the process instance: make it Serializable, define a hibernate mapping, ...
"Is orchestration not a usage pattern for jBPM?"
--> please, define orchestration.
Thanks, Tom for the reply.
I like the fact that BPM frameworks such as jBPM solves what I call orchestration issues (control-flow; handling asynchronous processing, via fork and join; and compensation). BPEL facilitates solves these "orchestration" problems as well but works only with web services. Our need is primarily for short-lived, high-volume transactions with quick turnaround requirement, and so do not need the ability to persist the execution state that jBPM requires.
Other than waiting for BPELJ, I wonder if there are other frameworks available for orchestrating services via Java APIs.
This is an interesting use-case that I had not previously considered. Short-lived jBPM process instances which do NOT have a business requirement for persistence.
Would this requirement be met by using an in-memory JDBC-enabled database (i.e. it does not actually persist to disk?)
Yes, sure... But it can also be addressed by completely building up your processdefinition and processinistances in memory, without using hibernate or a database. This is the mechanism that will be used by Seam to use jBPM as a pageflow engine. No need for persistency in a pageflow.