1 / 20

Hierarchical Task Network (HTN) Planning for Grid/Web Services Composition and Workflow

Hierarchical Task Network (HTN) Planning for Grid/Web Services Composition and Workflow Austin Tate AIAI, University of Edinburgh. Simple Messages. HTN Planning could be a useful paradigm Compose workflows from requirements and component/template libraries

nailah
Download Presentation

Hierarchical Task Network (HTN) Planning for Grid/Web Services Composition and Workflow

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hierarchical Task Network (HTN) Planning for Grid/Web Services Composition and Workflow Austin Tate AIAI, University of Edinburgh

  2. Simple Messages • HTN Planning could be a useful paradigm • Compose workflows from requirements and component/template libraries • Covers simple through to very complex (pre-planned) components • Allows for execution support, reactive repair, recovery, etc. • Simple extendable underlying “plan” representation from our work on <I-N-C-A> • Activities • Constraints • Extendable framework from <I-N-C-A> could be useful • Issues • Annotations • Could be complementary component technology in many other projects described at this workshop

  3. Plan Library Augment to describe Grid/web requirements Augment to describe Grid/web services A2 Refinement “Final” Plan “Initial” Plan Refine A2 S1 S2 A4 A1 A5 A2.1 A2.2 A3 A4 A1 A5 A3 HTN PlanningActivity Composition Introduce activities to achieve preconditions Resolve interactions between conditions and effects Handle constraints (e.g. world state, resource, spatial, etc.)

  4. Plan Library Ax Refinement P “Initial” Plan “Refined” Plan P Refine A1.1 A1.2 S1 S2 Q P & Q HTN PlanningInitial Plan Stated as “Goals” Initial Plan can be any combination of Activities and Constraints

  5. Relevant AIAI Work to Date • O-Plan • On-line web service exposing API via CGI scripts since 1994 • HTTP interface since 1997 • Simple - single user single-shot plan generator • More comprehensive - multiple users with multiple roles, long transactions, collaborative planning, execution and plan repair on failure • Air Campaign Planning Workflow Aid - people and systems • I-X • I-X supports the construction of mixed-initiative agents and systems which are intelligible to their users and to other systems and agents • Dynamic workflow generation and reactive execution support • I-Q query adaptor for OWL, OWL-S lookups via CMU Matchmaker, Semantic Web Queries via RDF, DAML, OWL and RDQL (AKTive Portal) • I-Plan planning aid (to be packaged as a web service composition tool) • CoAX and CoSAR-TS • Coalition Command and Control/Search and Rescue Task Support • Use on CoABS Grid and with KAoS Domain and Policy Management

  6. O-Plan Unix SysAdmin Aid

  7. O-Plan MOUT Task Description,Planning and Workflow Aids

  8. O-Plan as a Workflow Planner • Air Campaign Planning (ACP) Workflow – 1996 • Real ACP Process Models utilised • Composes workflow Process from a range of system and user capability descriptions • Models the creation and modification of “Process Products” by effects and conditions on process steps. Values of attributes of each product/object changed during process. E.g. status of documents. • Supports planning, execution monitoring and plan repair on failure.

  9. 2 I -DE I -P Domain Process Editor Panels Cooperation and Communication Other I-Plan Agents & Planning Services Aid I-Technology I-Q Adaptor CoABS Grid, KAoS, AKTBus, XML Sockets, Jabber, [Globus GT3]

  10. <I-N-C-A> Ontology for Synthesised Artifacts • Issues • Nodes • E.g. activities in a process or parts in a physical artifact • Constraints • Critical Constraints (shared across multiple components) • Auxiliary Constraints (localised to a single component) • Annotations • E.g. decision rationale and other notes Used for Processes and Process Products

  11. Issues Issues or Implied Constraints I Nodes Node Constraints (e.g. include activity) N Constraints Detailed Constraints C Space of Legitimate Bahaviours A=Annotations <I-N-C-A>

  12. Issues Choose (IH) Issues or Implied Constraints I Nodes Do (IH) Node Constraints N Constraints Detailed Constraints Propagate Constraints C IH=Issue Handler (Agent Functional Capability) Space of Legitimate Behaviours A=Annotations I-X and <I-N-C-A>

  13. I-X Aim is a Workflow and Messaging “Catch All” • Can take ANY requirement to: • Handle an issue • Perform an activity • Respect a constraint • Note an annotation • Deals with these via: • Manual activity • Internal capabilities • External capabilities • Reroute or delegate to other panels or agents • Plan and execute a composite of these capabilities • Receives reports and interprets them to: • Understand current status of issues, activities and constraints • Understand current world state, especially status of process products • Help user control the situation • Copes with partial knowledge

  14. CoSAR-TS Demo Architecture

  15. I-Plan (Planning Service) Enforcement (e.g. via KAoS) Enactment (e.g. via I-P2) I-CE I-CE and I-K-CEI-X/KAoS Composer & Enactor

  16. Further Information • http://i-x.info • http://www.aiai.ed.ac.uk/project/ix • . . . coax • . . . cosar-ts • . . . coakting • http://www.swsi.org • Thanks to my co-workers on the I-X and CoSAR-TS projects: • Jeff Dalton, Stephen Potter, Stuart Aitken, Jessica Chen-Burger, John Levine, Natasha Lino, Clauirton Siebra • IHMC: Jeff Bradshaw, Andrzej Uszok

  17. User User Role 2 Role 1 O-Plan Web Planner Other Agents Shared Task and Activity Model Shared Task Model – Mixed initiative model of “mutually constraining the space of products”. Shared Space of Options – for the product. Shared Model of Agent Capabilities - handlers for issues, functional capabilities and constraint managers. Shared Understanding of Authority – management of the authority to handle issues and act which may take into account options. Shared Product Model – using constraints on the space of products (<I-N-CA>).

  18. Version N Version N+1 Activity Document/ Product of Collaboration Document/ Product of Collaboration ? Issues I Properties Properties * Nodes N | Options (Alternative Activities) : Constraints C Evaluations + - = Make Choice Record Rationale ~ Preferences # Evaluation Criteria “ Annotation, Statements, Arguments, Reports A Options for the Activity to be performed may be evaluated against evaluation criteria. The result of evaluations may be a Pro (+), Con (-), or neutral (=). Product Model Refinement Step Using <I-N-C-A> Framework

More Related