MULTIAGENT SYSTEMS WITH WORKFLOWS

José M. VidalUniversity of South Carolina

Paul BuhlerCollege of Charleston

Christian StahlHumboldt University, Berlin

Presented By: Hande ZIRTILOĞLU - 2004721309

OUTLINE

• MOTIVATION• INTRODUCTION• APPROACH• CONCLUSION• FUTURE WORK• COMMENTS• QUESTIONS

MOTIVATION

• Future of Web services:– 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 current Web service

platforms – and researchers’ vision of distributed, dynamic

Web service composition.

INTRODUCTION

Workflows

• A workflow:– a series of actions performed by 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 the business implements. – For example, an insurance agency might have experts

that determine how a claim is to be handled.

Example: A Purchase Order Workflow

Why Workflows?

• Workflows are wide-spread in the business world• Offer predictable 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).

• Replace the people with web services – Fully automated workflow.

• Put together individual web services into a coherent whole.

Why MAS with Workflows?

STATIC WORKFLOW SPECIFICATIONS

• Different agents – can do many of the actions in the workflow in

parallel, • but some actions have temporal or

conditional dependencies among them. • Workflow description language

unambiguously declare all these dependencies.

Workflow Description Language

• XML-based de facto standard for workflow description. • 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.

The Business Process Execution Language for Web Services

(BPEL4WS)

*WSDL: Web Services Definition Language

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:Tag Meaning

<partners> contains a list of the web services invoked as part of the workflow.

<variables> contains the variables used in the workflow.

<correlationSets> specifies precedence constraints and correlations between Web Service invocations.

<faultHandlers> are the exception-handling routines.

<compensationHandler>

handles compensation actions.

<eventHandlers> for external (asynchronous) events.

A Part of the BPEL4WS for the Purchase Order Workflow Example

DYNAMIC COMPOSITION VIA DAML-S

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 Web service be described with DAML-S’s inputs, outputs, preconditions, and effects (IOPEs).

• Dynamic composition becomes feasible only when already-available Web services describe themselves with DAML-S’s IOPEs and use the same ontologies.

*DAML: DARPA Agent Markup LanguageDARPA: Defense Advanced Research

Projects Agency

MULTIAGENT WORKFLOW ENACTMENT

Multiagent Workflow Enactment

• Decentralized, multiagent workflow-enactment techniques:– can bridge the gap between static workflow enactment and

dynamic Web service composition.• Static workflows

– rigid, – computationally cheap.

• Dynamic composition – flexible – computationally expensive.

• Multiagent workflow enactment – in the middle, – has many implementation options,

• each of which lands at a different point in the spectrum.

BPEL4WS-to-multiagent-enactment Mapping

• Functional Equivalency– Decide how to allocate services among agents.

• How do we determine where an agent should next forward its results, or if we’ve attained the proper workflow?

• Give each agent explicit directions about what to do once it receives a service invocation.

• For example, if services A and B must run in sequence, then the agent responsible for A must invoke B right after it finishes its invocation.

– Transform a workflow into different Petri nets• Petri nets are well suited for modeling workflow processes. • The Petri nets can be tested using simulation tools:

– determine if the resulting workflow is functionally equivalent

– 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.

Petri Nets

– Petri nets • combine a precise mathematical formalism with an

intuitive graphical representation.

– A Petri net N = (P, T, F) consists of a set of transitions T (boxes), a set of places P (ellipses), and a flow relation F (arcs).

– A transition represents an active element– A place is a passive element.

Example: The Petri net pattern for the BPEL4WS receive construct

• Within control flow structures BPEL4WS defines tags that specify what activities to perform. For example:

– <receive> receives an invocation message.

XML-based Petri Net Markup Language (PNML)

• Petri net representation of the workflow:– analyze it by testing it on a simulator.

• Specifying the Petri net with a broadly accepted standard format – XML-based Petri Net Markup Language (PNML).

• PNML supports a module concept that lets modules reference one another using their well defined interfaces.

Transformation of BPEL4WS to the Petri Net Markup Language (PNML)

•The transformation from a BPEL4WS description to a PNML file:

•The BPEL4WS workflow process proc.bpel is the input to the parser,

•which is a collection of Extensible Stylesheet 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.

BEYOND FUNCTIONAL EQUIVALENCE

The spectrum of possible Web service composition scenarios:

Matching algorithms try to determine if two services are similar enough to substitute for each other.

More complex contextual substitutions look at the effects part of the service description to determine which effects serve as preconditions for other services. In general, this process strives to determine the minimal set of IOPEs necessary to replace a given service.

To dynamically adapt a workflow, we can thus combine the power of an ontology of services with existing techniques from recommender systems.

CONCLUSIONS

MAS with Workflows• In workflow-based multiagent systems:

– The service providers are agents themselves; • proactive, • autonomous, • and selfish characteristics that normally associated with agency.

– Not clear which workflow instances are currently active.– The agents:

• take actions that push possible workflow instances further without knowing which instances currently exist.

• make complex decisions about which actions to take to maximize the expected utility.

• Workflows:– less computationally 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.

• Unlike traditional multiagent systems based on joint plans and intentions, which require agents first to jointly commit to a plan and then to execute it:– The agents in this workflow-based system are completely

opportunistic and never commit to finishing a workflow.

– The designer must structure the payoffs in some way that creates the proper incentives for the agents to finish the work-flow.

– An advantage of this flexibility is that no synchronization bottlenecks crop up in which the agents needed to fulfill a particular workflow must all agree to participate.

– The workflow can get started even before all the required agents are available.

MAS with Workflows (cont.)

FUTURE WORK

• Developing tools:– for mapping BPEL4WS workflows into Petri nets

that can be used to generate multiagent instantiations of the workflow.

• Run tests on these Petri nets:– to determine various instantiation algorithms’

benefits and drawbacks.

• Development of algorithms:– effective similarity matching – contextual substitutions.