140 likes | 246 Vues
This paper explores the innovative concept of goal-based service orchestration, which leverages semantic matchmaking to enhance the flexibility and autonomy of agents in dynamic environments. By integrating orchestration features with a goal-oriented programming paradigm, the proposed framework allows agents to select appropriate services to achieve subgoals, adapt to failures, and employ plan selection rules. This research emphasizes the significance of beliefs, desires, and intentions in agent behavior while focusing on developing a robust orchestrational language that dynamically accommodates various service needs.
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,....?