Think about, everything is a process, but there is a small problem on that, process can differ on type, scope, participants and objective. There are also other issues on "how the process will behave", which means is the process is agnostic (no transaction), is a transfer (assuring data delivery), is distributed, have human and machine participants, and the scope, like what is the objective of some execution. But what is interesting is that there are a point where "a draw" will not work, and some machine understand will be required. Main over is such "draw" will run on a J2EE like machine capable engine. JBPM has a nice name and a lot of study over it, it is called PVM or process virtual machine, it is different to think about "temp tables", memory allocation, slots, a process virtual machine is an abstraction over all of such "implementation particularities" but with a great advantage, a process can determine transaction points which means that "at certain point" if something fail, a "rollback" on data will be done. To do this the PVM uses a very sophisticated implementation "indeed" very abstract and complex but for the Process Designers is totally transparent and simple. The Designer is able to determine if the process is transactional or not. But all programs are process, but, the difference is that a PVM is designed for very critical and complex operations usually "such ones that involves" ACID characteristics and keeping human hands away of an interference that cannot be mapped into some auditing trail.
Also the process does not depends on a specific nomenclarture (XPDL, BPEL, JPDL, BPMN), the notation as noticed is just the DSL that will represent some sort of task or activity that will be executed by a machine(s), human(s) or machine(s)-human(s) duet. Considering this even the XML configuration of Spring is also a DSL indeed very sophisticated for such types of implementations and in my opinion the most complete notation for process definition (well it is the author opinion). Another aspect which is crucial is "assure transaction management" on all participants, like a email being resent, a database rollback, a manager call again someone, which means, back on the previous state of the automaton and execute the same task or activity until the task or activity being accomplished, also like a nasty promiscuous individual, reproduce the task many many times, indefinitely or until the database explodes. But the most important is the following, if you have a PVM running on a J2EE stack, always the PVM shall orchestrate a process that will interact with the PVM, does not make sense like a "other events orchestrate a process" on a PVM, if you notice, all "process drawing models" are like "activity diagrams" with stereotypes representing the start and the end of a process, and the reason is obvious, if the thing is not that way you have a process anti-pattern, which means a non defined participant of the process "participating of a process" that you are trying to design in your process tool. Since all antipattern need a name, let's baptize such anti-pattern of "stupid meetings" that means "when an external thing meets a process server and don't believe that the engine will works".
