Download Why Workflows?

MULTIAGENT SYSTEMS
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
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).
Why MAS with Workflows?
• Replace the people with web services
– Fully automated workflow.
• Put together individual web services into a
coherent whole.
STATIC WORKFLOW
SPECIFICATIONS
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.
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 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
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-S markup of Web services will facilitate the automation of
Web service tasks, including:
•
•
– 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.
– 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 Language
DARPA: 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:
To dynamically adapt a
workflow, we can thus
combine the power of an
ontology of services with
existing techniques from
recommender systems.
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.
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.
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.
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.