The Planning Approach
There are two key novelties in the Synth approach(Agarwal et al. 2005; Srivastava 2006) for WSC: (a) it distinguishes between web service instances that are actually deployable, and web service types which represent a group of web services that have similar functionality, and (b) it composes in two stages representing what components are needed for the composite component and how the components should be connected together to realise the needed functionality. More specifically, the functional requirements of the new service are used by goal-driven planning to automatically generate abstract plans, and then, non-functional requirements are used for concretizing the plans by optimally selecting the available service instances. This is illustrated in Fig. 4. A Service Registry contains information about services available in-house as well as with participating 3rdparty providers. The capabilities of each available service type are described formally, using domain-specific terminology that is defined in a Domain Ontology.
When a new service needs to be created, the developer provides a Service Specification to the Logical Composer (LC) module. Driven by the specified requirements, the Logical Composer uses generative planning to create a composition of the available service types. Its goal is to explore qualitatively different choices and produce an abstract workflow (i.e., satisfiable plan) that meets the specified requirements. From a planning perspective, the planner needs to be efficient in this interactive and uncertain domain, the domain could be incompletely modeled, the user has hard and soft constraints, and the number of web service types could be large. We use a contingent planner that uses optional user inputs to efficiently finds plans that matter most to them (Mediratta and Srivastava 2006).
In order to turn the plan into a concrete workflow that can be deployed and executed, specific instances were chosen for the component services in the plan. The Physical Composer (PC) queries the services registry for deployed web service instances and uses scheduling and compilation techniques in selecting the optimal web service instances to produce an executable workflow(Agarwal et al. 2005). The focus is now on quantitatively exploring the available web service instances for workflow execution.
The workflow generated by the service creation environment is then deployed onto a runtime infrastructure, and executed in an efficient and scalable manner. The system used a commercial workflow engine for the purpose.
The Synthy system, instead of producing a single plan, generated multiple plans (workflows) at logical and physical stages. This allowed PC or execution engine to be flexible and try out alternative plans, without returning to the previous stage, if one of the plans failed for any operation reason. Thus, limited failure tolerance during WSC was unique to Synthy(Agarwal et al. 2005).
Licensing In Synthy, the planner was developed from scratch in the organization and hence, internal users had full freedom. External users needed a commercial license.
Software Development Ecosystem The development was in pure Java in Eclipse.
Knowledge engineering The planning model was manually created and debugged using the planner. For the purpose, in case the problem was unsolvable due to a possible bug, the planner could be asked to generate best k partial plans closest to the goal. The semantic description of services was also manually created in Protege tool and tested using Pellet reasoner integrated with it.
Visualisation We developed a composition environment in Synthy, which can be seen as an Integrated Development Environment (IDE), using Eclipse’s plugin framework – see Figure5. A user could perform logical and physical reasoning in the same environment, view the evolving workflow (abstract, physical) in text or as a graph and check the properties of its actions.
Benchmarking value of planning The evaluation of Synthy approach was qualitative. The alternatives were manual or automatic composition approaches, and relative efforts in composing new services were compared. The individual planner (Planner4J) was tested quantitatively for performance and it could easily handle common composition scenarios easily.
Plan execution and monitoring Synthy used an off-the-shelf workflow engines (BPEL4WS) for execution. The accompanying tools allowed execution monitoring and this helped implement a simple fault tolerance scheme relying on multiple workflows. Specifically, Synthy allowed multiple abstract and physical plans to be generated so that the executor, when faced with a failing plan, could switch to an alternative until all were exhausted and a re-planning had to be done. More details are in (Agarwal et al. 2005).
Any valued features Planner4J provided automatic parameter tuning(Srivastava and Mediratta 2005), generation of multiple plans and support for fault tolerance. While the user was developing a domain model, she could ask for partial plans to help in debugging PDDL model.
Table 1 gives a summary of the three case studies.We notice that all planners used were custom built to allow maximum freedom to the consuming organization. However, this is not practical for most developers who want software under other licenses as well. Hence, there is an opportunity to innovate on licenses including per-use licenses common with APIs.
Moving to software development process, the planners were written as monolithic software in a variety of languages but were not componentized for enhancements by users. For knowledge engineering, specific environments were created or suitable converters written to help the user build planning models. Synthy additionally provided programmatic interfaces to develop planning models. Further, custom visualisations were created to help the users understand generated plans. Thus all paid attention to support users with multiple ways for knowledge engineering and plan visualisation. This is an area needing more research.
The value of planning was assessed using custom evaluations. Considering this is required by all users, there is an opportunity to standardise planner evaluations so that a consumer can switch among different planning configurations (or different planners) easily. Given the success of planning competitions which evaluate planners on performance and to some extent, plan quality, planner evaluation approaches may be standardised for consumers and enabled.
The three applications diverged in how the plans were executed depending on their unique context. One had plans executed manually (journey recommendation) while others had automated execution possible. Execution monitoring becomes challenging unless a standard plan execution approach is adopted with clear semantics (like workflows).
Finally, all applications required special features from the planner. This indicates that if developers have to use planners, they need mechanisms to customise or extend planner behaviour.
This paper was motivated by the observation that although there has been tremendous progress in building efficient planners in the past years, planning-based applications are not as commonplace as other AI sub-fields like learning, constraints and (business) rules. We looked at three case studies of planning being used for mainstream applications and identified considerations that are important in practice. We argue that improvement in them by research community will help unleash mainstream adoption of planning by developers who are non-AI experts.