My background: I joined DERI one year ago, ome from a different field. Worked in application of Logic Programming techniques for planning, and analyzing theory/complexity of Planning. Currently: Involved in WSMO/WSML efforts where we build up a framework for semantically describing all relevant aspects of Web Services.
AI Planning for Semantic Web Service Composition? Survey of current approaches, challenges and open questions presented by Axel Polleres [email_address]
I would point out that the mapping of web services to compositions has largely been done in the past, even in the best work in
this area, with some simplifications that generally "twist" web services into a planning framework -- there's huge parts of the
web service world that need to be explored before we can really say AI planning has shown a success in web services other
than as an evocative idea -- the reason is that a real web services engine will need to deal with (at least):
scaling issues way beyond anything we've seen in planning to date (there may be thousands of services each with multiple ports, optional arguments, etc.)
the issues Dana mentioned ( side effects, change in the world , etc.) that make Strips-operators planning an approximation at best (the assumption that change occurs only through the operators under the control of this planner is clearly wrong)
issues of interaction with users - web service planning better be more mixed-initiative
issues of preferences v. constraints
issues of interaction between planning agents out there (you buy the book I'm in the process of planning to buy)
knowledge engineering issues (when planners take ebXML and WSDL as inputs, instead of requiring specialized planning-like languages like
OWL-S, then we'll see a lot more excitement on the outside - OWL-S is an interesting starting place, but we fool ourselves if we think it really is going to be widely used for process specification in its current form)
In fact, I'll wager that it will be absolutely trivial to prove that web services planning, even w/simplifications, is inherently
undecidable, so we'll need to explore a lot of the issues from the old " dynamic planning " world as well. All this, by the way, I
see as good news - it means this is a fertile and exciting research area for those of us in planning, with good heuristic solutions
being transitionable. That said, in the past I have tried to get AI planning people to think outside the box and failed miserably,
and I'll be surprised if the web services planning stuff doesn't become an "applied" area being ignored by the bulk of the
research community (who, if you'll apologize my saying so, still have their heads up their you-know-whats worrying about
scaling simple problems in all the wrong ways)
Forgive my pessimism, but the planning community has spent many years resisting change - I don't see why just because we
have a new and potentially revolutionary problem that could expand the field greatly, the leopards will change their spots...
Jim Hendler's opinion: 01/02/2004 email@example.com:
Domain description uses a fixed terminology , mostly a finite set of state variables (often called fluents)
A B C A B C move(a,table) move(c,a) move(b,c) "Given a set of actions, their preconditions and positive and negative effects, a complete description of the initial state and a user goal find a sequence of actions achieving the goal".
( shallow and broad search space vs. narrow and deep search space for which most planning algorithms are tailored)
… and results possibly unknown, only the type
(need for typing, conceptual reasoning over types, ontologies, take information gathering into account, selection step for sets of information)
Services might expose complex interfaces with complex message exchange patterns… (choreography, multi-agent collaboration rather than single-agent planning)
… but without full insight
(incomplete knowledge, non-determinism)
Need to compose complex services (i.e., " pre-defined plans " orchestration, cf. OWL-S process models)
Non-classical Planning: Loosen the restrictions to complete knowledge, and deterministic actions:
Conditional Planning [Peot,Smith,92]: construct a branching plan(-tree) taking all possible contingencies into account .
Conformant Planning [Goldman,Boddy,96]:
find a plan which works in any initial situation even under incomplete knowledge or when non-deterministic effects .
Hierarchical Task Network Planning (HTN) [Erol et al. 1994]: views a plan as a hierarchical network of tasks (however, mostly only simple sequences, no complex control structures like in OWL-S, BPEL4WS, etc.)!
Dealing with Non-classical Goals : Maintainance goals, preferences, etc.
suggests extension of PDDL with a polymorphic typing system for information gathering actions as a representation language for planning
Sketches how classical goal-regression planner can be extended to create conditional plans "on demand" (scalability not touched, assume number of branches is low).
Description of interface as a set of planning operations instead of a process definition! Extension to multiple-agents then of course trivial! Does not (yet?) assume but mention that ontological differences have to be resolved first
[Pistore, et al.,2004]:
Based on planning as model-checking
Automatic composition of BPEL4WS processes given a desired user process
Also leaves ontological differences out
Currently reported performance not usable for complex protocols
[Wu, et al. 2003]:
Translating DAML-S to HTN, and use HTN planner SHOP2 for plan generation
approach to integrate SemWeb technologies (particularly OWL-S) on top of BPEL4WS+BPWS4J to enable dynamic binding in BPEL4WS
First approach to integrate semantic mismatches
Mentions prototype at http://ksl.stanford.edu/sds however not (yet?) provided
In principle only discovery for dynamic binding, but propose a simple recursive search algorithm similar to planning for creating chains of missing services.
[Heflin,Mu ñ oz-Avila,2002]:
Use HTN planning for information gathering exploiting LCW information.
Tackles the problem of unbounded search by trying to exploit LCW information
Not really "planning for Web Services", but interesting application of planning techniques for SemWeb information gathering.
primarily on information discovery, extraction and integration,
Query planning for information gathering. Not really comparable with classical planning but uses similar techniques, services described in terms of LAV views, modified inverse rule algorithm which allows to consider binding patterns and optimize wrt. LCW information.
fully automated vs. semi-automated (approximation might help for the latter)
Interleaving planning and execution:
assuming the same context at plan time than et execution time might cause problems
planning neglects exogeneous events
preconditions vs. outputs.
Selection step from a set of outputs instead of conditions on all outputs (e.g. picking a flight)
Maybe no negative effects, but non-deterministic effects!
As opposed to planning: often many services available which basically offer the same, but at different costs. This is not the case for the usual planning examples.
Synthesis is ideally less frequent than access: So, composite services, if stored have special necessities on persistence of the service, availability needs to be checked and/or HOW LONG are the descriptions valid?
dynamic object generation: web services create new objects "at run-time", It is unlikely that this can be adequately modeled with the current planning techniques.
How to connect SWS and real services?
Partly own ideas, [McIlraith,Son,2002], [Srivatava,Koehler,2003]
Current focus in Discovery, define different levels of abstraction for discovery [WSMO D5.1]: different levels of abstraction shall filter the number of relevant (approximately matching) services before detailed checking, similar applies to composition
Discovery is to be solved before we can compose and execute SWS!
Grounding , Orchestration and Choreography under development. Need to have a clear formal semantics in order to enable (semi-)automatic composition and execution/verification of composed services (which e.g. BPEL4WS, OWL-S do not provide (yet?)).