Using Web Services and Workflow Ontology in Multi- Agent Systems

Transcription

1 Using s and Workflow Ontology in Multi- Agent Systems Jarmo Korhonen, Lasse Pajunen, and Juha Puustjärvi Helsinki University of Technology, Software Business and Engineering Institute, P.O. Box 9600, FIN 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. 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.

2 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] ( s Flow Language) that can be used to aggregate web services. 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

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

4 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]. 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.

5 Client Software Client Software Client Software Fig. 1 Single, multiple and hierarchical web service model Client Software Agent Client Software Agent Agent 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 service architecture 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

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

7 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 workflow architecture 4.1 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 Application / Agent Semantic Model SOAP WSDL WSFL Application semantics Unstructured model Formal semantics Semi-structured model Formal implementation Structured model ACL HTTP XML Executable protocols Structured comm. TCP/IP Unicode URI Binary coding Unstructured comm.

8 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 description description description description description Business Level Executable model 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

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

10 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>> Activity Action type Transaction type Optional Reverse operation 2 0..* 2 <<frame>> Control Link Link type Condition 0..* <<frame>> Data Link Translation 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

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

12 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 Go Start Transaction 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.

13 Reserve hotel Start transaction Fork Order flight tickets Join Select car Deselect car Book hotel Unreserve hotel Commit order 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

14 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] [3] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Nielsen, S. Thatte, D. Winer. Simple Object Access Protocol (SOAP) [4] Frank Leymann: s Flow Language (WSFL 1.0)

15 [5] Satish Thatte: XLANG - s for Business Process Design Microsoft 2001 [6] Workflow Management Coalition. Workflow Process Definition Interface XML Process Definition Language. [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 , [online] [8] DAML-S: Semantic Markup for s, in Proceedings of the International Semantic Working Symposium (SWWS). July 30-August 1, 2001 [online] [9] Joanna Bryson, David Martin, Sheila McIlraith, Lynn Andrea Stein: Agent-Based Composite s in DAML-S: The Behavior-Oriented Design of an Intelligent Semantic ftp://ftp.ai.mit.edu/pub/users/joanna/bryson-daml.pdf [10] Semantic web service architecture Evolving web service standards toward the semantic web [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, [13] J. Puustjärvi: Transactional Workflows, University of Helsinki, Finland, Doctoral thesis [14] Markku Syrjänen. BRIEFS - BRief driven Intelligence retrieval and Extraction For Strategy [online] [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, [16] V. Richard Benjamins, Enric Plaza,Enrico Motta, Dieter Fensel, Rudi Studer, Bob Wielinga, Guus Schreiber and Zdenek Zdrahal: - IBROW3 - An Intelligent Brokering for Knowledge-Component Reuse on the World Wide. In proceedings of KAW'98 [online]