140 likes | 241 Views
Using Goals for Flexible Service Orchestration A First Step M. Birna van Riemsdijk Martin Wirsing Ludwig-Maximilians-University Munich Dagstuhl – February 2007. GOAL 2. Acknowledgements. John-Jules Ch. Meyer - Utrecht University
E N D
Using Goals for Flexible Service OrchestrationA First StepM. Birna van RiemsdijkMartin WirsingLudwig-Maximilians-University MunichDagstuhl – February 2007
GOAL 2 Acknowledgements • John-Jules Ch. Meyer - Utrecht University • Frank de Boer - CWI Amsterdam, LIACS Leiden, Utrecht University • Mehdi Dastani - Utrecht University
GOAL 3 Ingredients • Goal-based agent programming • Orchestration • Semantic matchmaking towards.... a goal-based orchestration language that makes use of semantic matchmaking
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 agentsprogram flexible agents • Cognitive agent programming
GOAL 5 Cognitive Agent Programming (1) Plan A 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) language constructs?
GOAL 6 Cognitive Agent Programming (2) • Goals: flexibility in handling failure - goals describe a desired state - goals are not dropped until they are reached => if plan has failed, goal is still there, try another plan • Agent - beliefs, goals, plan selection rules • Plan selection rules - goal | belief => plan - plan: sequence of actions and subgoals haveBirthdayCake;placeCandles haveBirthdayCake | notRaining => goIntoTown;buyCake haveBirthdayCake | => bakeCake
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
GOAL 8 Syntax: Service Description • Service description - IOPE (inputs, outputs, preconditions, effects) - don’t 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?
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
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
GOAL 11 Example: Car Repair (1) • Service descriptions - garageAppInfo input = {possAppGarageMonday,...,possAppGarageFriday} output = {possAppGarageMonday,...,possAppGarageFriday,¬possAppGarageMonday,..., ¬possAppGarageFriday, failure} - garageAppMaker input = {appGarageMonday,...,appGarageFriday} output = {appGarageMonday,...,appGarageFriday, failure} effect = {appGarageMonday,...,appGarageFriday}
GOAL 12 Example: Car Repair (2) • Plan selection rules !carRepaired | repOnSpot => .....!carRepaired | ¬repOnSpot => dp(!appGarage) >> dp(!appTowTruck) >> monitorp(?carRepaired) !appGarage | true => dnp(?(possAppGarageM v ... v possAppGarageF)) >poss> chooseAppnp(poss,?(appGarageM v ... v appGarageF)) >app> dp(!app) (Q) do we need the additional info “poss” in chooseApp? is there a distinction between algorithmic and info providing service?
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)
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,....?