James Taylor's Decision Management

After my post on decision service design, Beth replied with a thoughtful post of her own. Beth raises the question of how many types of decision service there might be. I agree that there are several but there are many patterns within each type for specific decision making scenarios.

• Short-running, stateless, synchronous decision services are one type.
• The longer-running, wait for a human to intervene sometimes kind of decision service Beth identifies is interesting. I am not sure I would model this as a single decision service as it might make more sense to handle the long running pieces with a process while keeping the decision service very focused on trying to make the automated decision. Such a process, where a decision service attempts to take a decision and puts something on someone's worklist when it cannot is, indeed, a classic decision service / process pattern.
• Some models of decision services do not have the decision service requesting more information. Instead they expect the decision service to fail to make a decision and to reply to that effect while identifying the information it lacked. Another service would then fetch that information and call the decision service again. While this makes decision services highly reusable and very portable as well as simple to implement, it can also be a limiting factor to their usefulness.
• When talking to folks working in the event processing space, like my friend Paul who blogs over on the Tibco CEP blog, the management of state in decisions is critical to the event processing approach. Perhaps then there is another kind of decision service, one that is stateful and handling decisions that relate to event processing rather than process execution.
• Moving on to asynchronous execution one gets into classic publish/subscribe processing where a decision service might subscribe to an event, execute in response and then decide what events to publish as a result.