James Taylor's Decision Management

One of the interesting questions about decision services is the extent to which they should be able to gather their own data. Opinions on this range from a limitation of decision services being that they must be passed all the data they require to one in which even long running requests for data, say those involving a human, can be accommodated. Even if we take the position, as I do, that decision services are fundamentally synchronous, we still have a number of options:

1. Pass all the data available into a decision service and force it to either decide or to pass back some reason why it could not decide (to do with a lack of data, say) so that the calling application can assemble the additional data required and try again.
2. Pass the data available to the decision service but allow it to call external services and/or databases to gather the data it needs to complete the decision. Only synchronous calls are allowed as the service remains synchronous.
3. Pass the data available to the decision service and allow it to call external services and to request additional data from a user interface. The decision is still synchronous in that it continues to run/use a thread until the data is provided through the user interface or the request for a decision is cancelled.
4. Pass the data available to the decision service and allow it to gather the data it needs in any way. While the decision remains synchronous, in that the calling service is waiting for an answer, the decision service may be passivated or otherwise put “on ice” while waiting for the necessary data.

If synchronous behavior is not required then clearly a decision service can be invoked asynchronously, allowed to gather the data it needs to make a decision and then return its result, typically through transmission of an event. This kind of service is common in event-based architectures.