Tackling complexity with crayons
11/04/06 17:19 |
Work
ur team has just finished implementing a large
workflow system using jBPM as a BPM engine. It
was, for all of us I think, our first brush with
Graph Oriented Programming (GOP) and a couple of
interesting things fell out of it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.
|