MULTIAGENT SYSTEMS WITH WORKFLOWS

1
MULTIAGENT SYSTEMS WITH WORKFLOWS

• José M. Vidal
• University of South Carolina
• Paul Buhler
• College of Charleston
• Christian Stahl
• Humboldt University, Berlin

Presented By Hande ZIRTILOGLU - 2004721309
2
OUTLINE

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

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

4
INTRODUCTION
5
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.

6
Example A Purchase Order Workflow
7
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).

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

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

11
The Business Process Execution Language for Web
Services (BPEL4WS)

• 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 vendors tool
  and read it back with another vendors 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 wont
  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
  languages 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 Web service be described with DAML-Ss
  inputs, outputs, preconditions, and effects
  (IOPEs).
• Dynamic composition becomes feasible only when
  already-available Web services describe
  themselves with DAML-Ss IOPEs and 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-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.

18
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 weve 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.

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

20
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
• ltreceivegt receives an invocation message.

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

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

23
BEYOND FUNCTIONAL EQUIVALENCE
24
The spectrum of possible Web service composition
scenarios
25
CONCLUSIONS
26
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
  systems 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
  systems dynamics while still letting the agents
  exploit any opportunities that might arise.

27
MAS with Workflows (cont.)

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

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

29
(No Transcript)