You can think of jBPM as a 'sophisticated' state machine. In most cases a workflow has the need to keep track of what is going on at a particular moment in time (i.e. manage state). OTOH pure state machines cannot deal with e.g. multiple concurrent paths of execution and automatically processed activities. This is the domain where workflow engines such as jBPM pop up.
Thanks for your reply. The question was meant to be rhetorical!
No serious. A workflow is about process state. A state machine in its minimalist form is an object state. The state of the object is changed according to the type of event that occurs. Say the object is in state s1. On event e2 the object switches to s2, on e3 the object switches to s3, on e4 nothing happens, because this is not allowed.
Let me give an example. Say someone wants to update an order. This proces can involve a workflow: after the update of the order maybe financial approval needs to be asked. After an selectForUpdate request the invoice switches to the state selectForUpdate. No other event is allowed except the update event. If someone wants to ship the order: nope! Not now.
One could model the invoice state in the invoice object: but it doesn't really belong there.
Managing object state and process state is different. Both are required in order to implement a robust services system. For as far as I could see JBpm is not intended to manage object state.