SEDA, is a design for highly-concurrent servers based on a hybrid of event-driven and thread-driven concurrency. The idea is to break the server logic into a series of stages connected with queues; each stage has a (small and dynamically-sized) thread pool to process incoming events, and passes events to other stages. http://matt-welsh.blogspot.com/2010/07/retrospective-on-seda.html
- Your system processing could be model as ansynchronous processing.
- You'd better not expect the SEDA model could give your reliable return results (No directly return value).
- You system processing could be break into several stages/states. And the transition of each stage/state could have dependencies or just state transitions.
- Each stage/state could be repeatable if the input was same. (That will reduce a lot of complexity on the recovery part)
- Performance is not your highest priority in your mind
- State transition need to be visible and manageable. And multiple versions request may be facing in most situations
- Cannot find feasible data communication channel for data transfering when stage/state swapping.
- You cannot find out one feasible, lightweight, portable multiple thread exectuion components.
- Recovery will be even more harder as the execution logic manually break-up
- JBPM 3.2.7 or later. I would rather more expect the JBPM 3.2.9 version with improvements with sql change and fork/join improvement
- HornetQ 2.0 or later. The reliable asynchronous messaging processing system.
- CommonJ pattern + Command Pattern. The pattern support muli-threading system and replaying features
- IFINISPAN jboss version data grid cache solutions.
- JBPM performance issue, please refer my blog for new way scale up/out jbpm ref: http://community.jboss.org/people/andy.song/blog/2010/08/06/new-way-scale-upout-the-jbpm-without-jbpm-clustering-jbpm-sharding
- Seralization issue please use MapMessage or TextMessage when you want transfer data using message protocol. JSON or JAXB was good solutions for that.
- Reliable Multi-Thread components:
- CommonJ pattern.
- Data Grid
- Computing Grid
- Recovery may need pre-persist the input for each stage/state execution. Then Command pattern (REDO) part could help that recovery.
- Parellelism will be largely put inside the SEDA models. So your system could survive in huge load or small load
- Scalability already be built-in. So add more servers will help you a lot or upgrade your single machine power may also good. (Scale-up/Scale-out)
- JBPM help you on the state transition visible and manageable, versioning already be build-in
- INFINISPAN will help you on data grid part, so very soon it will provide much reliable data grid execution platform for you.
- Plug-in and extension will be easily, like Drools, etc.