As described above, DAML-S is mute about the application, therefore any type of application could in principle take this place. Nevertheless, the application level is responsible for many of the decisions that have to be made while using DAML-S. For instance, the application level is responsible for the use of the information extracted from the messages received from other Web Services or to decide what information to send to other Web Services. In order to take advantage of the flexibility supported by DAML-S, the application level should support a decision system that makes non-deterministic choices while maintaining efficiency and control on the behavior of the Web Service.
The Service is also responsible of the non-deterministic decisions that have to be made during the interaction with other Web services. The DAML-S Process Model describes a workflow that may contain conditionals as well as non-deterministic choices. The DAML-S VM can find these selection points, but it is up to the Service to decide which choices to make in those situations; since they requires the Service to analyze which branch of a choice would lead to the goals it wants to achieve. It is therefore essential that the Service include a decision system that can make non-deterministic choices while maintaining efficiency and control on the behavior of the Web Service.
In addition, the Service is also responsible for Web services composition during the solution of a problem. Specifically, the Service module is responsible for the decision of what goals to subcontract to other Web services, and as a consequence of compiling capability descriptions of potential providers to submit to a DAML-S/UDDI Registry; furthermore, it is responsible of the selection of the most appropriate provider among the providers located by the Registry. As a consequence, the neat and modular picture shown in Figure 2 is only partially true, a Service that wants to take advantage of the DAML-S VM should also have access to its DAML inference layer and possibly to the whole DAML-S virtual machine to reason about the Process Model, decide how to deal with non-deterministic decisions or how to react to unexpected decisions of the other parties.
Ultimately, the programmer has two choices, either hardcodes many of the decisions that the Web services has to make during its interaction with other Web services, or it employs a computational mechanism that supports the non-deterministic decision making that the Web service requires. In our implementation, we followed the second path, we employed the RETSINA planner [13] to control the application level. The RETSINA planner is based on the HTN planning paradigm [6] which provides a reliable as well as efficient planning scheme. The advantage of HTN planning over other planning schemes is that HTN plans by decomposition introducing set of actions in the plan where other planners would introduce only one action at a time. Furthermore, while HTN planning has in principle the same complexity of planners from first principles, in practice it reduces the number of decisions that the planner has to make resulting in an overarching efficiency gain.
The RETSINA planner extends HTN planning by adding interleaving of planning and execution which basically allows the Web Service to execute before a plan is completely formed. Interleaving of planning and execution has a number of advantages over traditional planning. For one it allows the Web Service to discover what providers are available and plan its course of actions as a function of those features. The second advantage is that it allows to replan to react to unexpected situations. For instance, if one of the providers fails to respond, the requester may look for an alternative provider to interact with.