PowerPointpresentatie

1
Using Goals for Flexible Service OrchestrationA
First StepM. Birna van Riemsdijk Martin
WirsingLudwig-Maximilians-University
MunichDagstuhl February 2007

2
GOAL 2
Acknowledgements

• John-Jules Ch. Meyer - Utrecht University
• Frank de Boer - CWI Amsterdam, LIACS Leiden,
  Utrecht University
• Mehdi Dastani - Utrecht University

3
GOAL 3
Ingredients

• Goal-based agent programming
• Orchestration
• Semantic matchmaking

towards.... a goal-based orchestration
language that makes use of semantic matchmaking
4
GOAL 4
Introduction

• An agent is... ...an encapsulated computer
  system that is situated in some environment and
  that is capable of flexible, autonomous action
  in that environment in order to meet its design
  objectives.
• Flexible, autonomous.how??
• The BDI philosophy - concepts of beliefs,
  desires/goals and intentions/plans - used to
  explain/describe behaviour of rational
  agents program flexible agents
• Cognitive agent programming

5
GOAL 5
Cognitive Agent Programming (1)
A
Plan
C
B
A
B
C
Beliefs
Goal

• How to obtain the plan? - planning from first
  principles reasoning about actions
  (algorithmic, planning before execution) -
  programming programmer prespecifies plans
  (languages, planning during execution) langua
  ge constructs?

6
GOAL 6
Cognitive Agent Programming (2)

• Goals flexibility in handling failure - goals
  describe a desired state - goals are not dropped
  until they are reached gt if plan has failed,
  goal is still there, try another plan
• Agent - beliefs, goals, plan selection rules
• Plan selection rules - goal belief gt plan -
  plan sequence of actions and subgoals haveBirth
  dayCakeplaceCandles haveBirthdayCake
  notRaining gt goIntoTownbuyCake haveBirthdayCak
  e gt bakeCake

7
GOAL 7
Goal-Based Orchestration

• The general idea - observation goals fit well
  with semantic web services - goal-based language
  orchestration features (Orc) semantic
  matchmaking
• To be more specific - (sub)goals can be reached
  by services - use services for achieving
  subgoals if this fails use plan selection
  rules to select another plan
• Technical issues - what to do with results from
  service calls - how to check whether a goal is
  reached

8
GOAL 8
Syntax Service Description

• Service description - IOPE (inputs, outputs,
  preconditions, effects) - dont laugh
  are (sets of) propositional formulas -
  information providing services - world altering
  services (Q) other languages for describing
  IOPE? description logic, rule
  languages....? (Q) relation between/role of
  ? (Q) how is actual output related to output
  description?

9
GOAL 9
Syntax Orchestration Language

• Goals - propositional formula - test
  goal and achievement goal
• Actions - basic actions and service calls -
  is service name or for
  discovery - revision
  parameter
• Plans - sequential composition (Orc) pass
  result of service call to other service

10
GOAL 10
Syntax Agent

• Plan selection rules - plan may be
  executed in order to achieve goal if
  is the case - apply plan selection rule to
  service call create
  stack element
• Stacks -
• Agent - belief base, goal base, stack, plan
  selection rules, belief update function

11
GOAL 11
Example Car Repair (1)

• Service descriptions - garageAppInfo input
  possAppGarageMonday,...,possAppGarageFriday o
  utput possAppGarageMonday,...,possAppGarageFrid
  ay, possAppGarageMonday,...,
  possAppGarageFriday, failure -
  garageAppMaker input appGarageMonday,...,ap
  pGarageFriday output appGarageMonday,...,app
  GarageFriday, failure effect
  appGarageMonday,...,appGarageFriday

12
GOAL 12
Example Car Repair (2)

• Plan selection rules !carRepaired
  repOnSpot gt ..... !carRepaired repOnSpot
  gt dp(!appGarage) gtgt dp(!appTowTruck) gtgt
  monitorp(?carRepaired) !appGarage true
  gt dnp(?(possAppGarageM v ... v
  possAppGarageF)) gtpossgt chooseAppnp(poss,?(appG
  arageM v ... v appGarageF)) gtappgt dp(!app) (Q
  ) do we need the additional info poss in
  chooseApp? is there a distinction between
  algorithmic and info providing service?

13
GOAL 13
Adaptivity

• Kinds of flexibility/adaptation - semantic
  matchmaking flexibility in selecting
  services particular service does not have to be
  specified at design time - adaptation to failure
  of service to achieve goal try other matching
  service or apply plan selection rule -
  adaptation to failure of (sub)orchestration (or
  plan) multiple plan selection rules for a
  similar goal
• When and how to adapt? - when goal is not
  reached, call service or apply rule - but
  adaptation is built into normal execution
• Optimality metric - goals are reached
  (functional)

14
GOAL 14
Conclusion and Future Research

• Summary - goal-based orchestration language
  that uses semantic matchmaking advantage
  flexibility
• Future research - replace propositional
  logic description logic, rule
  languages,....? - extend plan language parallel
  composition,.... - interaction protocols -
  representation of goals soft constraints,....?