Introduction

Web services are defining a new paradigm for the Web in which a network of computer programs become the consumers of information. The growing infrastructure for Web Services is based on SOAP [20] and WSDL [2] assumes XML [19] as unifying language to guarantee Web Services interoperability. XML guarantees syntactic interoperability by providing a standard for a common syntax that is shared across the Web, with the result that Web Services can parse each other message, verify whether they adhere to the expected formats, and locate each piece of information within the message. Unfortunately, the two Web Services do not have any means to extract the meaning of the messages exchanged. The two Web Services are in the awkward position of understanding the structure of each other message, but not understanding the content of those messages. The limitation requires programmers to hardcode Web Services with information about their interaction partners, the messages that they exchange and the interpretation of the messages that they receive. The result is a set of rigid Web Services that cannot reconfigure dynamically to adapt to changes without direct human intervention.

Ideally, we would like Web Services to act autonomously, to require the minimal human intervention as possible. Web Services should be able to register autonomously with infrastructure Registries such as UDDI [17], in addition they should use the infrastructure Registries to locate providers of services that they need, and finally, they should be able to transact with these Web Services sending them information formatted in a way that they can understand, and be able to interpret the information that they receive as a response. Autonomous Web Services not only minimize the human intervention by automating interaction with other Web Services, allowing programmers to concentrate on application development, but also they should be able to recover from failures more efficiently by automatically reconfiguring their interaction patterns. For example, if one of their partners is failing or it is becoming unreliable, they may be able to find other more reliable partners, similarly, if a new and cheaper, or anyway better, provider comes on line, Web Services should be able to switch to work with the new provider.

Autonomous Web Services need to be able to find partner Web Services, in order to do that they need to be able to describe and register their own capabilities with public registries, as well as locate other Web Services with specified capabilities. Capability information is crucial for Web Services to locate each other on the bases of the services that they provide rather than on the bases of their name or of the name of the company that deploys the Web Service. In addition, a Web Service should have information on how to interact with the provider, which means that it should know the interaction protocol of the provider, and binding information. Most crucially, this information should allow the requesting Web Services as well as the provider to decode the information exchanged, so it should specify not only the format of the messages to exchange or the remote procedures to call, but also the semantic type of the information to exchange. This view is embraced by DAML-S [16] which defines a DAML [4] ontology for the description of Web Services that attempts to bridge the gap between an infrastructure of Web Services based essentially on WSDL [2] and SOAP [20], and the Semantic Web [1]. In other words, DAML-S bridges the gap between the specification of the format of the information to be exchanged and the specification of its meaning.

DAML-S assumes a view of Web Services that is wildly shared in the community. It assumes that a transaction between Web Services involves at least three parties: a provider of the service, a requester of the service, and some infrastructure component such as UDDI that facilitates the location of the provider and possibly facilitates the transaction between provider and requester. Furthermore, DAML-S allows for a flexible assignment of roles in which a Web Service can be both a the provider in a transaction and a requester in another, and also it allows for a role switch within the same transaction. DAML-S is constructed in three modules that provide a description of different aspects of Web Services. The first one, called Profile, is an abstract description of the Web Service and of the transformation it implements described as a transformation from the inputs the Web Service requires to the outputs it generates. The second module is the Process Model that characterizes the Web Service, specifically, it describes the interaction flow with the Web Service, what function is produced by each step. The third module, called Grounding, specifies how the input/outputs of each step are mapped on WSDL specifications of messages that the two Web Services exchange.

DAML-S provides all the information Web Services need to interact on the Web. DAML-S supports discovery by allowing Web Services to describe their capabilities in the Service Profile so that they can be matched with requests of capabilities. DAML-S capability description and the capability matching [12], extends the UDDI registry[11] allowing Web Services to register their own capabilities and to locate providers of the functionality they seek. Once the provider is located, the requesting agent can use the Process Model and the Grounding to interact with the provider. The Process Model describes the interaction workflow of the provider so the requester can derive what information the provider needs at any given time. Through the Grounding the requester compiles the messages to exchange with the provider.

We tested DAML-S in two applications that stress different aspects of DAML-S. The first system is a B2B application in which a hypothetical computer manufacturer looks for providers of computer parts. The goal of the computer manufacturer is to locate providers of parts of a computer, and negotiate prices of parts and a schedule of delivery. The second application is a variant of travel management application that is often used as use case of application of Web Services. In this latter application the goal of the requester is to locate a travel agent Web Service and book a flight to a meeting while synchronizing the schedule of the flight with the schedule of the user stored in MS Outlook.

In the remaining of the paper we will discuss in detail the architecture of the applications. Specifically, in section we discuss the challenges of automatic composition of Web Services; in section we discuss how DAML-S meets those challenges; in section we discuss the architecture of the Web Service; in section we discuss the computational requirements on a DAML-S Web service; in section we discuss details of the implementation; and finally in section we conclude.