In the sButler project (Semantic Web Butler) at Linköpings universitet, Sweden, we examine the modeling and instantiation of workflows based on Web services (services described in a rule-based language). The aim of the project, which is part of the Swedish Semantic Web initiative [11], is to support on-the fly creation of workflows and their subsequent maintenance. Our sButler agent will manage workflows and Web services modeled as Petri Nets, use the language facilities provided by the Semantic Web, and employ a new push-and-pull protocol to handle communication with other sButlers.
Semantic Web, Web services, agents, workflow, ontology.
This project concerns workflows that use Web services. Such workflows are executed in a Semantic Web environment and must cope with some practical characteristics of Web services. For example, Web services are not always available, and they can sporadically be replaces by new ones. Also, Web services will not always match the complex needs of a user, so composition [2][3] is necessary, in addition to locating and comparing Web services. Given a specialised workflow described in a composition language, the sButler agent will allow the user to delegate some part of the workflow for external execution as a Web service. Moreover, whenever a Web service that is part of a workflow appears, disappears, or changes its interface to the Web, the sButler will react to ensure that the workflow is always correctly instantiated. We are examining the modelling of the agent behaviour in this context, and also the communication protocol needed between agents, and between agents and services/workflows. Our goal is to develop a practical tool. For this purpose we are collaborating with the industry [8], striving for the use of standard protocols and frameworks as much as possible.
The sButler functions are useful in many different contexts. The sButler helps the user to manage her workflow. It can suggest changes to the workflow ("You need to update your EDI") and even perform the change for the user ("Do you want me to update it?").
The sButler helps the user to keep contact with some specific Web services. For example, the user has a contract with a provider of office supplies and needs support to deal with the possible workflow adjustments this implies. On request from the user (her personalized needs), the sButler searches for appropriate Web Services ("fastest", "cheapest", etc.) to plug in to the workflow of the user. Parts of the user's workflow can be flexible with regard to who owns the Web service that is to be included. For example, if the Web service changed the credit card from Master Card to Visa, the user can accept to change its workflow's input (the credit card) to fit this change.
The sButler maintains a "best instantiation" of the delegated part of the workflow by constantly checking the Web services available according to the user's requirements. For example, when ordering new supplies for the office, the sButler can ensure that each order will be sent to the provider that currently offers the best price for these goods. To summarise, the sButler can:
Figure 1 below illlustrates the usage of the sButler: The user wants to delegate a task from her workflow to an external Web service. She invokes the sButler via a Web browser and specifies the task and additional requirements that she has on the Web service(s). The sButler initiates its service discovery function and returns the "best" matching service. It then establishes a connection to the service provider's sButler so as to be notified of any future changes in the service profile. The Semantic Web capabilities (and domain-specific ontologies developed for the sButler) are employed in the description of the user's requirements and the task, and communication with other sButlers and service providers. If a service disappears, the sButler is notified and restarts its service discovery. It can also receive messages from other sButlers about new services, which can be compared to existing ones and also possibly replace them (if "better" match).
Figure 1: The sButler components.
We need the following sButler components (underlined in figure):
We have identified two ontologies needed in sButler: one for describing workflows, and one for changes in Web services.
We have decided to use the DAML+OIL [4] framework to implement the ontologies because it has a rich development environment. DAML+OIL is also close to a Web standard for Semantic Web services. To our knowledge there is no previous DAML+OIL ontology for describing a workflow. We consider DAML-S [4] concepts of process composition to be expressive enough for describing simple workflow structures. We use it as a prototype language to understand which concepts are important for describing user requirements (modelled as workflows) in sButler.
We have defined a first version of an ontology for changes in Web services (see Figure 2). The ontology refers to Web services that have been described with an existing Web service ontology; DAML-S is used in the figure. One of the preconditions of the Web service specifying the category of the credit card used to pay for the service has suddenly changed from Master Card to Visa, which affects the functionality of the service.
The example describes the change in one of the service properties (DAML-S profiles consist of a number of input, output, precondition and effect properties). Other types of changes can occur: Our ontology can also describe changes to the structure of the service (in DAML-S terms, the change affects the process composition description), and changes affecting the whole service (appearing/disappearing).
Figure 2: An ontology for service changes.
We have described the ongoing sButler project at Linköpings universitet, aimed at supporting and maintaining the relation between the workflows of companies/users and existing Web services/providers. The project is in a starting phase and includes the development of a base ontology for Web service workflows, a Petri Net-based Web service workflow specification techniques, and a Web service push-and-pull protocol for use in an agent-based infrastructure. We are currently implementing a prototype based on a standard platform [9], and also analysing the design space of protocol specifications and workflow descriptions. The project lasts until summer 2005.
We thank Vinnova [13] for supporting this project, and the anonymous reviewers for their feedback.