Using Web Services and Workflow Ontology in MultiAgent Systems
Jarmo Korhonen, Lasse Pajunen, and Juha Puustjärvi
Helsinki University of Technology, Software Business and Engineering Institute,
P.O. Box 9600, FIN-02015 HUT, Finland
{ Jarmo.Korhonen, Lasse.Pajunen, Juha.Puustjarvi}@hut.fi
Abstract - In this paper, we introduce a transactional workflow ontology for
multi-agent systems and web services. Both technologies use messaging,
service descriptions and directory services to implement the overall
architecture. As web services have already been extended with workflow
specifications by IBM, HP and Microsoft, it is natural to apply workflows to
agent systems as well. We detected a problem with inflexibility in
BriefsAgents, our FIPA standard multi-agent system prototype that uses
ontology for data transmission between agents. Ontology-based transaction and
workflow control enable agents and web services to use the ontology instances
to drive their internal state, instead of hardwired implementation. In addition,
they can communicate their workflow to other agents and services and enable
co-operation with parties that are not known at implementation time. The
proposed workflow ontology supports advances transaction models to improve
reliability in these distributed systems. We also cover the necessary tools for
using this transactional workflow ontology.
1
Introduction
Multi-agent systems (MAS) are composed of collaborative agents in a shared
platform that together implement more complex functionality. Agents in MAS have a
set of services, their descriptions, and protocols to use the services. Agents use the
services by sending messages to other agents. FIPA (Foundation for Intelligent
Physical Agents) standard [1] defines the architecture for an agent platform.
Interaction between agents is similar to object oriented methodology, but the agents
have a greater degree of autonomy. A software agent in MAS can for example initiate
a communication with other agent without explicit outside command to do so.
Communication between agents is formalized in a set of protocols, which the agents
must implement to be able to cooperate. The problem with this approach is that
system architecture is not very flexible.
Web services are a relatively new way to distribute component architecture across
network. Components offer a set of services, usable with SOAP protocol [3]. The
services are registered in a UDDI registry as WSDL-language service descriptions.
With three relatively simple standards it is possible to compose a new system out of
web services, with simple integration protocols and an integrating application.
However, using the web services requires a priori knowledge of their use. There have
been several efforts to define a workflow description language for enabling software
to use a web service without explicit beforehand knowledge how to use it. For
example, IBM has published WSFL [4] (Web Services Flow Language) that can be
used to aggregate web services.
Web services publish a set of operations to some central repository. This is quite
similar to a MAS architecture using FIPA standard. In this paper, we propose a
transactional workflow ontology that uses the concepts from recent publications of
web service workflow description languages. Workflow ontology serves two purposes
for an agent: it can be used as running instructions for the agent itself, and it can
communicate the workflow to other agents. The workflow ontology will be useful
only if there are tools that support it.
We implemented a prototype multi-agent system BriefsAgents that used
DAML+OIL ontology to communicate data between agents. Basically, the system has
two types of agents: query agents and data agents. The database was generated from
business press release information gathered in BRIEFS project [14]; each data agent
managed one concept in the BRIEFS ontology. The query agents used one or more
data agents to make queries. We used FIPA-OS, a Java reference implementation of
the FIPA standard as the agents platform.
The protocols we used in BriefsAgents were straightforward; there were no
negotiations and all protocols were between only two agents at a time. We noticed
that changing the protocols was difficult, as the agents became increasingly dependent
on each other.
Complex systems would benefit from better support for reliable transactions. We
have also implemented a prototype system called WorkMan [12] that combines
workflows and transactions using standard database constraints. We are researching
how this approach can be combined with multi-agent systems like in the BriefsAgents
prototype. We also research how web services workflow models can be adopted by
MAS agents.
In this paper, we propose a transactional workflow ontology that can be used in
MAS. Ontology here is a taxonomy of concepts and a set of relations between
concepts. The rest of the paper is organized as follows.
In Section 2, we analyze different description models for workflows. In Section 3,
we combine agent and web service architectures. In Section 4, we cover the semantic
of transactional workflow ontology. In Section 5, we present our transactional
workflow ontology. In Section 6, we provide an example of using the ontology.
Finally, in Section 7, we present tools that are necessary to use this kind of ontology
in practice.
2
Workflow description analysis
There are several commercial implementations of workflow engines, with their
own proprietary formats. None of them is yet focused on web services or multi-agent
systems. In this section we analyze three different approaches to workflow: web
services, semantic web and transactional workflow. Our workflow ontology for web
services combines features from all of these, so this is presented as background.
2.1
Web service workflow standards
A single web service offers a set of operations. WSDL can be used to describe
these operations, but it is not possible to tell for example the order of the operation
execution. Web service workflow can be automated using for example Microsoft’s
XLANG [5] specification. Workflow description is even more necessary when
composing a system from multiple web services, with multiple operations. IBM has
published a proposal called WSFL [4] that can be used to define separately the flow
model and the global composition model. WSFL focuses on the composition and
hierarchies and may offer more possibilities with its features. W3C has also received
a proposal from Hewlett-Packard Company for a Web Services Conversation
Language (WSCL). It focuses on protocols and document exchange and its support
for workflow concepts is the most restricted of the three.
XLANG is part of the Microsoft’s BizTalk infrastructure. XLANG supports
especially the automation of business processes between different companies. The
language focuses on messages (SOAP) and process instances, helping to enforce
protocol correctness in message flow. Services have a state for each interaction, and
XLANG can be used to map these states to incoming and sent messages.
WSFL considers two types of web service compositions. Flow model describes
how to use the functionality provided by the collection of composed web services.
Global model does not provide an execution sequence; instead it describes how the
composed web services interact. Web services may also be recursively composed of
other web services, in a hierarchy or peer-to-peer network of services.
The ontology in this paper presents a way to add support for heterogeneous
transaction models to these existing standards.
2.2
Workflow and semantic web
Semantic web initiative in W3C forum has been defining common tools for
describing information in machine-readable ways. RDF has been the most important
result from this initiative. DAML+OIL ontology standard uses RDF to represent the
ontology and inference rules. DAML+OIL has been used to define several ontologies
[8], but the tool support for it is still weak. Most tools support either DAML (e.g.
Protégé) or OIL (e.g. OILEdit), not DAML+OIL.
DAML-S [8] is a DAML+OIL-based ontology for describing the properties and
capabilities of Web services in computer-interpretable form. It overlaps with other
web service standards; service profile, model and grounding are quite similar to the
UDDI, WSDL and SOAP standards, extended with workflow concepts. The
comparisons in [10] show that semantic web services need higher level information
for agent-based automation. DAML-S is still work in progress, and [10] suggests
enhancing the web service standards rather than duplicate same features. We present
in this paper a way to add advanced transaction models to DAML-S, WSFL or
XLANG. The ontology is otherwise similar to those languages.
The Unified Problem-solving Method description Language UPML [15] is a
language for describing reusable components and architectures. It has been developed
as part of the IBROW project [16] to facilitate the semiautomatic reuse and adaptation
of knowledge-based components. UPML component model contains tasks that can be
combined to accomplish more complex tasks. The semiautomatic combination is
similar concept, but the ontology in this paper supports automatic transaction
reasoning for standard web services.
2.3 Workflow and transactions
There has been workflow research for a long time. Workflow Management
Coalition has also proposed a XML-based standard XPDL [6] for describing
workflows. A lot of research is concentrating on automating the business processes.
For this paper, the most interesting aspect of workflow research is the ability to do
distributed transactions.
Modeling a workflow as an extended transaction means that the sub-transactions
correspond to the tasks of the workflow and the execution structure of the extended
transaction corresponds to the control flow of the workflow [13]. Many advanced
transaction models have been proposed for modeling workflows, e.g. nested
transactions, multi-parent transactions, multi-level transactions, sagas and flexible
transactions. Different transaction models have different strengths, so a workflow
ontology should support multiple transaction models.
3
Agent and web services architecture
A software agent is a relatively autonomous actor with sets of goals, intentions,
beliefs and behaviors [9]. Web services and agents both are a modular way to develop
software. The main distinction between agents and web services is that web services
are user-driven; agents act on their own after user has given the necessary
instructions. They are not contradictory goals, but the information content of current
web service standards is not sufficient for autonomous agents [10]. With sufficient
semantic information, both human users and autonomous agents can use web services.
3.1
Agent and web service use cases
Combining web services and autonomous agents to a composite service requires
that we have common method for using the system [9]; there has to be standard client
software for the user, which will contact agents, web services, or both. Only user can
use agents, web services may contain a hierarchy of web services.
We assume here that we have found the necessary web services and agents from a
registry (e.g. UDDI). If there are several possibilities, selection is made by either the
user or the agent. The web services may actually form a network, instead of tree.
Client
Software
Web
Service
Web
Service
Web
Service
Client
Software
Client
Software
Web
Service
Web
Service
Web
Service
Web
Service
Web
Service
Web
Service
Web
Service
Fig. 1 Single, multiple and hierarchical web service model
Web
Service
Client
Software
Agent
Web
Service
Web
Service
Agent
Client
Software
Web
Service
Web
Service
Agent
Web
Service
Web
Service
Fig. 2 Agent model and heterogeneous model
These use cases are in increasing order of complexity. If the use case consists of
only web services used by a human user, web service standards are adequate. If
autonomous agent makes decisions, more information is needed.
3.2
Web service architecture
Web services currently consist of three standards: SOAP, WSDL and UDDI. All
these rely on XML and standard protocols for low-level implementation. In addition,
there are several proposals for service flow languages, including WSFL. The IBM
web service architecture is interesting because it defines a way to compose web
services from other services dynamically. This composition is a necessary
prerequisite for heterogeneous model where system may consist of both agents and
web services.
Fig. 3 IBM web service architecture
DAML-S is a web service ontology that can be used to web service discovery,
invocation, composition and monitoring. Although it overlaps with other web service
standards, DAML-S offers logical operation and dependencies that are otherwise
difficult to describe. DAML-S can also be used in connection with other standards
[10], especially SOAP.
3.3
Agent architecture
Multi-agent systems (MAS) use messaging protocols between agents to achieve
results comparable to web services. In FIPA standard agent platform (in figure 4), a
directory service is used to find agents (similar to UDDI), based on the description
agent has registered about itself. The main difference between agent-based system
and web services is that in MAS, all agents have internal states and goals, and may act
autonomously. Agent protocols can be modeled with AUML [7]. Different message
and state combinations must all be modeled for reliable implementation.
Web services are normally used by a human user, who directs the system at each
stage. Agent systems are used through client software that gives initial instructions to
an agent. The agent then proceeds to do the task, reporting either success or failure.
The agent may use other agents or even other software systems to do the work. These
agents may be as simple as web services, or they may have complex internal state and
own goals. Agent platform is usually required to run agent states and deliver
messages.
Fig. 4. FIPA abstract architecture
FIPA standard defines two special agents: agent management system (AMS) and
directory facilitator (DF). Common message transport system is used to call these
special agents. Application agents find each other by calling DF, and manage their
state with AMS. Most of the logic is either in communication protocols between
agents or inside the application agents. For example, one agent can act as database
interface, like in our BRIEFS database agent did.
3.4
Combined architecture
Multi-agent system is a flexible and modular way to develop complex systems.
Some agents do simple tasks, and the overhead for full agent communication
language protocol can be considerable. Combining multi-agent systems with web
services can be helpful to avoid this overhead. For this we need
− Common registry
− Common service description
− Common workflow model
Note that common protocols and framework cannot be required, as that would
make using existing web service infrastructure impossible. The easiest way to achieve
combined architecture is though wrapper agents, which forward FIPA messages to
web services and send the results back. The workflow model is more difficult, as it
requires combining the agent protocols and web service workflow. We therefore
propose a workflow ontology that can describe both agent and web service use.
4
4.1
Web workflow architecture
Framework
Workflow ontology is necessary for a software agent to run an internal state
machine and to communicate this to other agents. Combining web services and agents
requires a framework of different standards and models. Figure 5 shows a hierarchy
of semantics for such a framework.
FIPA
ACL
Application / Agent
Application semantics
Unstructured model
Semantic Model
Formal semantics
Semi-structured model
SOAP
HTTP
TCP/IP
WSDL
WSFL
Executable protocols
Structured comm.
XML
Unicode
Formal implementation
Structured model
URI
Binary coding
Unstructured comm.
Fig. 5. Framework semantics
At the application semantics level, a programmer implements an application or an
agent. The software represents knowledge coded by a programmer. This knowledge is
inherent in the implementation and can not be shared with other applications or
agents.
At the formal semantics level is a formal methodology to represent knowledge. It
contains formal statements about the system. These statements can be used by the
implementation in application/agent level, or they can be shared to other applications
or agents.
At the formal implementation level, web service standards such as SOAP, WSDL
and WSFL provide an execution environment for higher level models. These
standards can be used to describe individual services to be combined.
The executable protocols level describes how information is serialized and
communicated between agents and services. HTTP is a concrete protocol that is
widely used in web services. XML is used to serialize the content that is sent between
agents and web services. It is also used as language by all other web service
standards.
4.2
Semantic model
Workflow is a real-life concept which has a special meaning in computer science.
Therefore, there are two semantic levels for workflow. Business level has concepts
that are relevant to real life tasks; concepts are for example company, payment and
agreement. Computer level has concepts that automate and help with these tasks;
these are for example service, transaction and agent. Workflow ontology needs to
have a combination of these semantic levels and their concepts; computer level is
used to implement business level. Figure 6 shows how these two levels are used in
integrated architecture.
Application model
Service description
Service description
Service description
Service description
Service description
Executable model
Business Level
Computer Level
Fig. 6. Semantic model architecture
The application model is a white box model. Developer knows the model and is
able to edit it. On the other hand, service descriptions are black box models. Other
service providers provide them; developer is not able to change them. There is usually
enough information to use them (e.g. WSDL service descriptions), but
implementation details and semantic meanings are not known.
4.3
Agent workflow model
Agents have an internal state and a series of possible state transitions; this can be
modeled as a workflow. The proposed workflow ontology should include possibility
to manage agent’s internal state. In multi-agents systems (MAS) most states concern
the protocols and communication with other agents.
The MAS protocols are N-tier systems where N agents separately manage their
own state and send messages to each other. Agent’s internal state is most often a
reflection of the state in the protocol. There may even be multiple communication
sessions active at a time, so it is not usually possible to set a single state for the whole
agent. The MAS protocols in FIPA standard are modeled as AUML diagrams. Figure
7 shows one such protocol model; the protocol has three optional responses to
subscribe message.
Fig. 7. FIPA protocol example: subscribe interaction protocol
5
Transactional Workflow Ontology
Web services have several proposals for workflow description languages, e.g.
WSFL [4] and XLANG [5]. FIPA standard [1] defines a state and protocol model for
software agents. Different transaction models address the problems in distributed
transactions. We define a workflow ontology that extends these with transactional
concepts.
Workflow ontology has two levels; semantic level and implementation level. The
ontology has three semantic level concepts: task, control link, and data link. Figure 8
presents the basic structure of the workflow ontology. This ontology is intended to
work with web service workflow description languages, e.g. WSFL and DAML-S,
and uses similar concepts where applicable.
<<frame>>
<<frame>>
Activity
Control Link
2
0..*
Action type
Link type
Transaction type
Condition
2
Optional
Reverse operation
<<frame>>
Data Link
Translation
0..*
Fig. 8. Workflow ontology model
5.1
Task
Task is an atomic part of the workflow. On the semantic level, it may have
properties and parameters but no internal structure. On the implementation level, it
may have internal workflow or transactions. Task definitions reference the agent
internal state engine and its operations.
The task types are send message, receive message, request-response, solicitresponse, start transaction, end transaction, and notify error. First four of the task
types in Table I are based on WSDL port types. This defines how the particular task
will behave. For example, if the task type is receive message, that task will not
proceed unless the agent gets a message from another agent.
Table 1. Task types
Task type
Send message
Receive message
Request-response
Solicit-response
Start transaction
End transaction
Notify error
Description
Send a message to an agent, no response
Wait for a message from another agent
Wait for a message and send a response
Send a message and wait for response
Workflow engine transaction control
Workflow engine transaction control
Send an error message to other agents
Transaction type defines how that task should be used in case of success and
failure. For example, if transaction type is option, the commit operation will be called
after the workflow has succeeded. In case of failure, it is not called. ACID transaction
model will use both commit and abort operations, depending on the result. If the task
is optional, its failure will not affect the success of the whole workflow.
Protocol type property states what kind of messaging will be used. Possible values
include FIPA messaging [2] and SOAP [3].
Note that different transaction models in the tasks do not need to be scheduled by
the developer. By stating the transaction type and the needed operations, developer
can let the workflow engine do the ordering of the tasks needed only for transaction
management.
5.2
Control link
The control link is a semantic level concept based on WSFL; it does not have
corresponding implementation outside the workflow engine. Control links specify the
execution order for the tasks. The control link types are go, fork, join, start, end, loop,
commit transaction, and abort transaction. Start and end link are special cases that tell
the workflow engine which task to run first and when it should stop. Start collects all
workflow and transaction descriptions and combines them to a single master
workflow. The master workflow is then used by the workflow engine to drive the
agent. End transaction task is always followed by commit transaction and abort
transaction control links; those link types can not be used anywhere else.
Join is a synchronizing control link that must be preceded by a fork. Fork does not
require a join unless the concurrent flows must be synchronized.
Each control link can have a precondition that is evaluated to see if link is currently
enabled or disabled. The condition is a Boolean expression. For example, the
expression could be that exactly one out of two concurrent tasks must have been
successful. Loop links must have a condition. Commit and abort can not have a
condition, as they already have an implicit condition of successful/failed transaction.
5.3
Data link
The data links are used to describe how information flows during workflow. A data
link specifies that its source task passes some named data to the workflow engine. The
workflow engine will in turn pass that named data to the target tasks. Data links are
based on WSFL.
Data links may have a data translation to describe how information is formatted
during link transition. These translations are implementation level, and workflow
engine will call agents internal operations to do the translation. The translation can be
for example a XSL [15] template that is applied to some XML data to make it
uniform before sending it to the target task.
6
Using ontology in an example
This section uses our workflow ontology in a real life problem. We use a business
trip reservation as an example. The service user wants flight tickets, hotel room, and
optional car reservation. These work in different transaction models; e.g. flight ticket
agent is operating in ACID model. Figure 9 shows the workflow for flight ticket
reservation agent. It offers three operations outside: order, commit order, and abort
order. The workflow description contains only task Order Ticket, with the other
operations as properties.
Start
Go
Start
Transaction
Go
Order
Tickets
End
Transaction
Commit
Abort
Commit
Order
Abort
Order
End
Fig. 9. Flight ticket service workflow
Hotel room reservation uses option model [7]. The agent has two sequential
methods that are used when reserving rooms. Strictly speaking, it would not be
necessary to abort the room reservation, as the option would automatically expire.
Car reservation operates on saga model. Therefore, there is only one method
needed if everything goes well. The abort method is used if the transaction fails.
Figure 10 presents a combined workflow where tasks are defined in the workflow
description to be parallel.
Reserve
hotel
Start
transaction
Fork
Order flight
tickets
Join
Select car
Deselect car
Book
hotel
Commit
order
Unreserve
hotel
Abort order
End
transaction
Fig. 10. A complete service workflow
In this workflow, hotel reservation, ordering flight tickets, and booking a car are
done concurrently without any specific order. They are executed as a transaction. The
join operation is used to synchronize the concurrent tasks. After completing the
transaction in the end transaction task, the appropriate commit or abort methods are
called. In this example they are done in sequence, but the workflow generation tool
could also design a workflow model where they are executed in parallel.
7
Tools
Creating, reading and writing workflow descriptions based on ontology requires a
set of tools that work together. With the multiple published proposals, implementing
complete systems is a problem. In this section, we present some requirements for the
infrastructure to support this ontology. In figure 11 is an overview of the tool
hierarchy.
Editor
Engine
Description file
Writer
Parser
Fig. 11. Tool stack
Ontology editor is needed for editing the workflows. Each workflow is an instance
of the ontology and will be used by an agent. The workflow probably uses several
agents or web services, so the workflow will be used for both agent internal
functioning and agent protocols. The editor should also be able to write a workflow
description which can be read by the ontology parser.
Ontology parser will read the workflow description and verify it. The resulting data
structure will be used by workflow engine to direct the agents. This is done only once
at startup, if the ontology is made with editor. If the workflow description is generated
at runtime, this needs to be done regularly.
Ontology writer is needed when workflow description is generated at runtime.
Based on parameters, it generates an ontology description that can be given to
ontology parser.
Workflow engine is needed to run agent according to the workflow. Current FIPA
standard reference implementations use a state model that is hard-coded to the agents.
Using workflow ontology, agents can be more easily configured.
8
Conclusion
We have shown how similar workflow and transaction technologies can be used in
web services and multi-agent systems. There are advantages for this approach.
− one set of tools can be used for both agents and web services
− systems can co-operate without prior knowledge at implementation time
− transaction models are a proven method to add reliability to distributed systems
Transactions are poorly supported in current web service workflow specifications.
We propose here a method to add transaction models to existing workflow ontologies.
The ontology itself is lightweight and in other aspects similar to existing languages.
This ontology can be useful when there are tools that support it. Most importantly,
it will need a workflow engine that can use it. We will continue to research this
ontology in practical web service environment. Using existing tools for some of the
requirements, we intend to implement a prototype system to test the transaction
model.
References
[1] FIPA 97 Specification, Part 1: Agent Management. Foundation for Intelligent
Physical Agents, Version 1.2, 1997
[2] EURESCOM. The Application of Agent Technology to Workflow Management
in Telecommunications. [online] http://www.eurescom.de/~pubdeliverables/P800-series/P815/D2/p815d2.pdf
[3] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Nielsen, S.
Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1.
http://www.w3.org/TR/SOAP/.
[4] Frank Leymann: Web Services Flow Language (WSFL 1.0)
http://www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
[5] Satish Thatte: XLANG - Web Services for Business Process Design
http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm, Microsoft
2001
[6] Workflow Management Coalition. Workflow Process Definition Interface –
XML Process Definition Language.
http://www.wfmc.org/standards/docs/xpdl_010522..pdf
[7] James J. Odell, H. Van Dyke Parunak, Bernhard Bauer. Representing Agent
Interaction Protocols in UML. Agent-Oriented Software Engineering, Paolo
Ciancarini and Michael Wooldridge eds., Springer, Berlin, pp. 121-140, 2001.
[online] http://www.auml.org/auml/working/Odell-AOSE2000.pdf
[8] DAML-S: Semantic Markup for Web Services, in Proceedings of the
International Semantic Web Working Symposium (SWWS). July 30-August 1,
2001 [online] http://www.daml.org/services/SWWS.pdf
[9] Joanna Bryson, David Martin, Sheila McIlraith, Lynn Andrea Stein: Agent-Based
Composite Services in DAML-S: The Behavior-Oriented Design of an Intelligent
Semantic Web ftp://ftp.ai.mit.edu/pub/users/joanna/bryson-daml.pdf
[10] Semantic web service architecture – Evolving web service standards toward the
semantic web http://www.aifb.unikarlsruhe.de/WBS/sha/papers/swobis_flairs.pdf
[11] J. Puustjärvi. Workflow Concurrency Control. The Computer Journal, Vol. 44,
No. 1, 2001
[12] J. Puustjärvi. Options: a Way for Achieving Failure Atomicity in the WorkMan
System. In Proceedings of the Seventh International Conference on Database
Systems for Advanced Applications, 2001.
[13] J. Puustjärvi: Transactional Workflows, University of Helsinki, Finland, Doctoral
thesis 1999.
[14] Markku Syrjänen. BRIEFS - BRief driven Intelligence retrieval and Extraction
For Strategy [online] http://briefs.cs.hut.fi/
[15] Dieter Fensel, V. Richard Benjamins, Enrico Motta, and Bob Wielinga: UPML:
A Framework for knowledge system reuse. In Proceedings of the International
Joint Conference on AI (IJCAI-99), Stockholm, Sweden, July 31 - August 5,
1999.
[16] V. Richard Benjamins, Enric Plaza,Enrico Motta, Dieter Fensel, Rudi Studer,
Bob Wielinga, Guus Schreiber and Zdenek Zdrahal: - IBROW3 - An Intelligent
Brokering Service for Knowledge-Component Reuse on the World Wide Web. In
proceedings of KAW'98 [online]
http://www.swi.psy.uva.nl/projects/IBROW3/docs/papers/kaw-ibrow.ps