[ACCEPTED]-Using a workflow engine, state machine engine or rolling my own?-activiti

The main value of a Workflow engine is that 70 it makes it possible to customize the flows 69 through some workflow definition DSL. If 68 you don't need to allow users to define 67 their own arbitrary workflows, they you 66 are better off just building your own.

Also 65 workflow engines usually give you the ability 64 to define business transactions & rules 63 that are very long running. For example, you 62 can have a workflow for authorizing purchase 61 orders, where the first step is to enter 60 some information about what needs to be 59 purchased, then you have rules along the 58 lines if the purchase is for less $100 okay 57 it right away, if its between $100 & $2000 56 line manager can okay, if it's more then 55 send it to some one else for approval ... etc. These 54 types of business rules tend to change over 53 the years as the amounts get increased, or 52 the business policies for a company change. So 51 it makes sense to use a workflow engine 50 in those scenarios. Other good examples 49 of complex business transactions that can 48 benefit from a workflow engine are making 47 an insurance claim, authorizing a loan or 46 a mortgage, assessing a credit application 45 from a customer ... etc. These business 44 transactions tend to go through several 43 people / departments and take several hours 42 to days or weeks to complete.

Rule engines 41 are good for extracting complex but changing 40 rules from an application. Lets say you 39 are an online retailer that ships to customer 38 in the USA, Canada, UK, Germany, and France. You 37 are required to charge taxes on the products 36 you sell on your online shop but the rules 35 for calculating taxes are different from 34 country to country and from province to 33 province within a country. Also some things 32 are exempt from tax in one province but 31 not in other provinces. Rule engines are 30 great for these types of complex business 29 rules that can change whenever the government 28 changes their tax policy. Rules engines 27 can give you an answer right way you just 26 have to go to the rule engine say I want 25 to run rule #10 and here are the inputs 24 for rule #10 x,y,z and you get back an answer.

Main 23 differences between a rule engine and a 22 workflow engine, is that rule engine does 21 not track the state of the transaction, it 20 should be stateless working only on the 19 inputs you provide it. Workflow engine is 18 statefull, it must know what current state 17 is the workflow in and must save that state 16 to a database. Workflow engines also wait 15 for input from external sources such as 14 people or systems.

From what you are describing 13 about your app I would just write some groovy 12 classes to compute the next state of a ticket 11 and make sure that the class is well documented 10 and easy to update in a few years. I think 9 rule engines and workflow engines are overkill 8 for your situation, the amount of time it 7 would take you to set them up and use them 6 is much bigger that it would take you to 5 write the code in groovy. If over time you 4 discover you need the complexity of rule 3 engines and workflow engines, I would pay 2 the price then rather than now, keeping 1 it simple is always the best choice.

I can't agree more with above AMS' answer, and 13 one more thing i want to add is for most 12 scenarios, using workflow/rule engine is 11 overkill and unnecessary. KISS（Keep It Simple and Stupid）is always the best choice. and Occam's Razor also says "Entities should not be multiplied unnecessarily"

Per my own 10 working experience in Alibaba, most workflow/rule-engine equipped applications are putting the maintainance into nightmare, and people 9 comes to project later will appreciate you 8 if you use simplified impl rather than blindly 7 choose workflow/rule engine.

So, is there 6 a guideline telling when to use workflow 5 or not? frankly i don't know, but what i 4 know is it's definitely not we should use 3 workflow whenever the biz logic is in a 2 flow. because if you will, every biz logic 1 can be presented in a flow chart.

Lastly, one of my most correct thing i did last year is redesign an application to replace Drools by groovy script, which makes the whole system much more straightforward, simpler and faster.

'State machine' is common design pattern, so what drools 65 actually gives you? I personally value drools 64 for its 'query language', this is what makes 63 it shine. You practically have something 62 like 'SQL to query objects from your heap'. Just 61 like SQL gives you 'declarative' way of 60 programming, drools when block describes 59 when to start state transition in declarative 58 way. Drools was designed to be statefull by default and state 57 is all facts (POJOs) which were inserted 56 into drools session.

Let me propose you simple 55 usecase. You have to write application for 54 cellular phone company to manage phone calls:
If caller 1 is calling to callee 2 and he is not 'busy' at that MOMENT, connect them.
If callee is busy, continue calling for 7 seconds and if the callee dismiss his original call DURING that period of time, connect them at once.
if callee will not disconnect during 7 seconds, drop the caller with the message 'callee is busy'.

Simple 53 triple-if statement business method quickly 52 became quite complex and error prone technical 51 task. I imagine background Timers' I've seen 50 a lot 5 to 10 years ago or some newer, like 49 ScheduledThreadPoolExecutor. And what if state changed DURING scheduled 48 delay? Will you still wait until the end 47 to recalculate the condition? If such condition 46 is relatively often in your application 45 or the period is relatively long will you 44 keep 'context' in the memory? You would 43 need to keep track of Futures and cancel 42 them or use some BlockingQueue. One would need to maintain 41 queue for each person for such cases because 40 each person can be potentially called by 39 somebody. Traditional OOP says 'you should 38 keep behavior attached to your domain entities'. With 37 this approach you'll start clutter your 36 business entities with quite complex technical 35 stuff even if you would use some patterns 34 to simplify (encapsulate) complexity your 33 'state machine' start to spread between 32 multiple components, it will be even worse 31 if you'll use 'layered style' because you 30 will start to produce data structures for 29 the state stuff, like Map<Callee, BlockingQueue<Caller>>. Next day your customer 28 come to you and say, 'hey, I have another 27 simple use case for you around phone calls'.

Drools 26 solves such problems 'naturally' because 25 it uses totally different approach. It keeps 24 track of all objects in the working memory 23 (it keeps track of the rule condition) and 22 when time comes, drools is just able to 21 say whether your rule is eligible to be 20 executed or not (rete algorithm back to 19 1979). If state changes, drools re-evaluates 18 when condition for each rule in efficient 17 way and put or remove respective rules from 16 'agenda' (execution queue). All objects 15 you've inserted into 'working memory' form 14 a 'state' which any rule can relay on. You 13 can find some diagrams and tests for the 12 usecase described above and actual drools 11 rule implementation here

Use right tools for 10 your tasks. If you need for loop on collection 9 of entities with State object inside with 8 3-5 fields, don't put 'state machine' in 7 the title. If you really face problems like 6 'continuous behavior change' or complex 5 cause-effect dependencies between events 4 in your system, then drools is good and 3 time-proven open source rete algorithm implementation. Don't 2 try to use everything advertised, dig into 1 details, understand what suit your needs.