[Introduction]

 

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

 

[Pre-conditions]

 

  1. Your system processing could be model as ansynchronous processing.
  2. You'd better not expect the SEDA model could give your reliable return results (No directly return value).
  3. You  system processing could be break into several stages/states. And the  transition of each stage/state could have dependencies or just state  transitions.
  4. Each stage/state could be repeatable if the input was same. (That will reduce a lot of complexity on the recovery part)
  5. Performance is not your highest priority in your mind

 

[Chanllenges]

 

  1. State transition need to be visible and manageable. And multiple versions request may be facing in most situations
  2. Cannot find feasible data communication channel for data transfering when stage/state swapping.
  3. You cannot find out one feasible, lightweight, portable multiple thread exectuion components.
  4. Recovery will be even more harder as the execution logic manually break-up

 

[Solutions]

 

SEDA.PNG

 

  1. 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
  2. HornetQ 2.0 or later. The reliable asynchronous messaging processing system.
  3. CommonJ pattern + Command Pattern. The pattern support muli-threading system and replaying features
  4. IFINISPAN jboss version data grid cache solutions.

[Need Consideration]

 

  1. 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
  2. Seralization issue please use MapMessage or TextMessage when you want transfer data using message protocol. JSON or JAXB was good solutions for that.
  3. Reliable Multi-Thread components:
    • CommonJ pattern.
    • Data Grid
    • Computing Grid
  4. Recovery may need pre-persist the input for each stage/state execution. Then Command pattern (REDO) part could help that recovery.

[Benefitical]

  1. Parellelism will be largely put inside the SEDA models. So your system could survive in huge load or small load
  2. 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)
  3. JBPM help you on the state transition visible and manageable, versioning already be build-in
  4. INFINISPAN will help you on data grid part, so very soon it will provide much reliable data grid execution platform for you.
  5. Plug-in and extension will be easily, like Drools, etc.