One of the questions I get regularly can be summarized like this: I see how a decision service works when it returns an answer but can it return multiple answers? As one reader put it:
Suppose we want to go from India to the USA. There are number of alternatives and many flights that are available. How can we generate these alternatives and how can we implement this in web service? What are the inputs to this service and what are the outputs? How can we store these alternatives in a web service?
At one level these kinds of decision services are the same as any other kind – they take data in, they make some kind of choice from available outcomes and they pass back the results of this choice. There are generally three reasons a service is being designed to return multiple answers:
- There are multiple answers that are acceptable and the calling application is going to present them to a human user who will then make a choice.
- While there is a “best” answer there are likely to be other answers that are not quite as good and it will be helpful to document the next best answers either to help a user understand what else was considered or to allow a fall-back strategy without having to re-invoke the decision service,.
- There is a ranked list of alternatives, from best to worse, that it makes sense to present in some circumstances. The calling application can decide to use only the best or to use some combination of them in order.
Obviously these are minor variations of each other.
The principles for building a decision service are the same – determine what data is going to be required when the service is invoked (so this data can be packaged up and used to call the service), determine what output is required (in this case a list of output records of identical format) and determine how to choose between them. If the decision service is going to be allowed to retrieve additional data to help make a decision then this will need to be defined also.
In the specific example we will probably pass in our requirements for the flights (choices about routing, schedule, price etc) and have the decision service reach out to get all the possible flights that meet the minimum defined criteria. The decision itself is likely to use some business rules that use our preferences to find acceptable and preferred flights as well as perhaps some analytic models that help us score each flight for acceptability (such a model having been developed by analyzing the data on what flights people actually booked and how happy they were with the choice, for instance). Each flight that is determined to be acceptable (passes the rules and some minimum prediction of acceptability) is assembled into the result set (which includes the score) and then this package is returned.
As far as the calling service or process is concerned it simply asked a question (“What are the acceptable flights for this set of criteria from most to least acceptable”) and got an answer. The complexity of the decision is encapsulated in the service and can be evolved, changed, improved as and when appropriate without impact on anyone else. All of this is essentially identical to the kind of decision service that returns a single answer.
