M ULTIAGENT SYSTEMS WITH WORKFLOWS

1. MULTIAGENTSYSTEMS WITH WORKFLOWS José M. Vidal University of South Carolina Paul Buhler College of Charleston Christian Stahl Humboldt University, Berlin Presented By: Hande ZIRTILOĞLU - 2004721309

2. OUTLINE • MOTIVATION • INTRODUCTION • APPROACH • CONCLUSION • FUTURE WORK • COMMENTS • QUESTIONS

3. MOTIVATION • Future of Webservices: • Two different visions: • Industry wants to capitalize on Web service technology to “automate business processes via centralized workflow enactment”. • Researchers are interested in the “dynamic composition of Web services”. • Bridging the gap between: • the centralized mindset on currentWeb service platforms • andresearchers’ vision of distributed, dynamicWeb service composition.

4. INTRODUCTION

5. Workflows • A workflow: • a series of actions performedby a series of actors. • Some examples: • Fulfillment of a purchase order. • Handling an request for admissions at a University. • Handling an insurance claim. • Diagnosis and treatment of a patient. • Workflow experts: • develop the workflows that thebusiness implements. • Forexample, an insurance agency might have experts thatdetermine how aclaim is to be handled.

6. Example: A Purchase Order Workflow

7. Why Workflows? • Workflows are wide-spread in the business world • Offerpredictable performance • Can be analyzed and modified • Have some degree of fault tolerance • Have supported tools: • IBM WebSphere MQ Workflow3. • Lotus Workflow4. • Microsoft BizTalk Server5. • SAP6 workflow systems (ERP).

8. Why MAS with Workflows? • Replace the people with web services • Fully automated workflow. • Put together individual web services into a coherent whole.

9. STATIC WORKFLOW SPECIFICATIONS

10. Workflow Description Language • Differentagents • can do many of the actionsin the workflow in parallel, • but someactions have temporal or conditionaldependencies among them. • Workflow description language unambiguouslydeclare all these dependencies.

11. The Business Process Execution Languagefor Web Services (BPEL4WS) • XML-based de facto standard for workflowdescription. • Jointly proposed by Microsoft and IBM. • Meant to replace their proprietary formats for storing workflow descriptions. • to be able to express most of the constructs that could be implemented with both tools, so that one could save a workflow with one one vendor’s tool and read it back with another vendor’s tool. • Details the flow of control and any data dependencies among a collection of Web services being composed. • Assumes all web services are described using WSDL*. • Domain experts write workflow descriptions encoded in BPEL4WS, so these workflows won’t change until the experts that wrote them decide to modify them. *WSDL: Web Services Definition Language

12. BPEL4WS Language Structure • A BPEL4WS workflow description is a structured XML document; • a collection of tags defines the BPEL4WS language’s vocabulary. • A BPEL4WS document is divided into several parts:

13. A Part of the BPEL4WS for the Purchase Order Workflow Example

14. DYNAMIC COMPOSITION VIA DAML-S

15. DAML-based Web Service Ontology (DAML-S) and Dynamic Web Service Composition • DAML-S • DAML*-based Web service ontology, • supplies Web service providers with a core set of markup language constructs for describing: • the properties and capabilities of their Web services in unambiguous, computer-interpretable form. • DAML-S markup of Web services will facilitate the automation of Web service tasks, including: • automated Web service discovery, • execution, • composition and interoperation. • Every Webservice be described with DAML-S’s inputs, outputs,preconditions, and effects (IOPEs). • Dynamiccompositionbecomes feasible only when already-available Webservices describethemselves with DAML-S’s IOPEsand use the same ontologies. *DAML: DARPA Agent Markup Language DARPA: Defense Advanced Research Projects Agency

16. MULTIAGENT WORKFLOW ENACTMENT

17. Multiagent Workflow Enactment • Decentralized, multiagent workflow-enactmenttechniques: • can bridge the gap between static workflow enactment and dynamic Web service composition. • Static workflows • rigid, • computationallycheap. • Dynamic composition • flexible • computationally expensive. • Multiagentworkflow enactment • in the middle, • has many implementation options, • eachof which lands at a different point in the spectrum.

18. BPEL4WS-to-multiagent-enactment Mapping • Functional Equivalency • Decide how to allocate services among agents. • How do wedetermine where an agent should next forward itsresults, or if we’ve attained the proper workflow? • Give each agent explicitdirections about what to do once it receives aservice invocation. • For example, if services A andB must run in sequence, then the agent responsiblefor A must invoke B right after it finishes itsinvocation. • Transform aworkflow into different Petri nets • Petri nets are well suited for modeling workflowprocesses. • The Petri nets can be tested usingsimulation tools: • determineif the resulting workflow is functionallyequivalent • if any bottlenecks exist, and so on. • From BPEL4WS to Petri Nets • Build every process in a BPEL4WS workflow • plug language constructs together; • translate each construct of the language into a Petri net.

19. Petri Nets • Petri nets • combine a precise mathematicalformalism with an intuitive graphical representation. • A Petri net N = (P, T, F) consists of a setof transitions T (boxes), a set of places P (ellipses),and a flow relation F (arcs). • A transition representsan active element • A place is a passive element.

20. Example: The Petri net pattern for the BPEL4WS receiveconstruct • Within control flow structuresBPEL4WS defines tags that specify what activitiesto perform. For example: • <receive> receives an invocationmessage.

21. XML-based Petri Net Markup Language (PNML) • Petri net representation of theworkflow: • analyze it by testing it on a simulator. • Specifying the Petri net with a broadlyaccepted standard format • XML-based Petri Net Markup Language (PNML). • PNML supports a module concept that letsmodules reference one another using their welldefinedinterfaces.

22. Transformation of BPEL4WS to the Petri Net MarkupLanguage(PNML) • The transformation froma BPEL4WS description to a PNML file: • TheBPEL4WS workflow process proc.bpel is theinput to the parser, • which is a collection of ExtensibleStylesheet Language Transformations (XSLT)templates along with the PNML modules. • Using XSLT templates and the PNML modules, • the process is translated into a process proc.pnml in PNML format.

23. BEYOND FUNCTIONAL EQUIVALENCE

24. To dynamically adapt a workflow, we can thuscombine the power of an ontology of services withexisting techniques from recommender systems. More complex contextual substitutionslook at the effects part of the servicedescription to determine which effects serve aspreconditions for other services. In general, thisprocess strives to determine the minimal set ofIOPEs necessary to replace a given service. Matching algorithms try to determine if two servicesare similar enough to substitute for eachother. The spectrum of possible Web service compositionscenarios:

25. CONCLUSIONS

26. MAS with Workflows • In workflow-based multiagent systems: • The service providers areagents themselves; • proactive, • autonomous, • and selfish characteristics thatnormallyassociated with agency. • Not clear which workflowinstances arecurrently active. • The agents: • take actions that push possibleworkflow instances further without knowingwhich instances currently exist. • make complex decisions about whichactions to take to maximize the expected utility. • Workflows: • lesscomputationally expensive than the planning • can be used as blueprints for orchestrating the system’s dynamics. • Although the agents are free to diverge somewhat from the available workflows, they are not free to assemble entirely new workflows. • The designer maintains some control over the system’s dynamics while still letting the agents exploit any opportunities that might arise.

27. MAS with Workflows (cont.) • Unlike traditional multiagent systems based onjoint plans and intentions, which require agents firstto jointly commit to a plan and then to execute it: • The agents in this workflow-based system are completelyopportunistic and never commit to finishinga workflow. • The designer muststructure the payoffs in some way that creates theproper incentives for the agents to finish the work-flow. • An advantage of this flexibility is that no synchronizationbottlenecks crop up in which theagents needed to fulfill a particular workflow mustall agree to participate. • The workflow can get startedeven before all the required agents are available.

28. FUTURE WORK • Developing tools: • formapping BPEL4WS workflows into Petri nets thatcan be used to generate multiagent instantiations ofthe workflow. • Run tests onthese Petri nets: • to determine various instantiationalgorithms’ benefits and drawbacks. • Development of algorithms: • effective similarity matching • contextual substitutions.