Friday, November 30, 2007

Inter Process Orchestration

In this white paper I am thinking, infact had starting making the framework, that will enable inter process orchestration, with due respect to BPEL of the world. I have named this framework as "Process Choreographer"
Note :- Process can be any Java Object.

Process Choreographer is a lightweight Java framework for building workflows using java beans to orchestrate events. You can think of Process Choreographer as a simple alternative to BPEL where the workflows are all specified and implemented using Java code rather than declarative XML.

When building highly concurrent or distributed applications (like insurance claim processing) it is very common for there to be many events happening; often asynchronously and in different threads and its very common to need to perform kinds of workflow or orchestration across these events.

Off course one can certainly use things like BPEL to solve these kinds of problems. However often this is a bit heavy weight & complex and you just want to have a bean based workflow using regular Java code to represent the activities involved in the workflow. Further more, BPEL will always comes with the cost of performance. I have heard many times where my client/patners have asked me, we want to run atleast 10 transaction per second, Process Choreographer framework will be answer to these problems.

One of the main goals of Process Choreographer is to reuse what the Java platform is good for in the workflow space; then supplement it with missing abstractions rather than re inventing the wheel. Hence
1) Write a plain old java class (from where every things begins)
2) Use normal java code construct like if - else, while etc
3) Use regular Java fields in your workflow class, then use JDBC/DAO/JPA to deal with
persistence

While working with various client and their concurrent or distributed applications there are many use cases for needing to orchestrate among multiple concurrent events.

1) starting dependent services that is where a parent component is dependent on the child components starting; where the start process may be asynchronous in different threads. e.g. there may be a recovery process on startup which you need to wait for.
2) implementing master-slave type protocols where you need to monitor the state of the master and slave to make decisions on what to do; together with dealing with transitions from Started to Recovering to Running then maybe to FailingOver etc.
3) implementing message orchestration. You may want to implement some simple orchestrations, waiting for either a response to arrive or a timeout to fire etc

Process Choreographer aim to solve to over come above problem by providing the ability to do the following

1. Execute Process In Sequence

2. Execute Process In Parallel Split

3. Process Synchronization : Synchronize two parallel threads of execution.

4. Process Exclusive choice: Choose one execution path from many alternatives

5. Simple Process Merge: Merge two alternative execution paths

Soon I will update you with design of this framework.

1 comment:

Unknown said...

hi Gaurav,

the framework and the idea behind it looks cool. But do we intend to simulate the entire workflow/process engine using Java.

Cannot we have an alternate Workflow and/or BPEL engine which would give performance and cost benefits as well?

The Claims process is quite complex and a good example, which can be used to bench mark.

Please let me know if any further details required. And further do you have this in form of white paper so that people can furnish it by illustrating with real world scenarios encountered.

cheers.
d.santosh