A Web Service Architecture

The discussion above shows that DAML-S provides a promising framework to control Web Services interaction. It provides all the information that Web Services need to negotiate autonomously on the Internet, minimizing interventions of programmers while maintaining a very flexible and reliable connection with their providers. Still, it leaves open the problem of harvesting all the information available and make use of it in real implemented Web Services. This is the center of our work as we are trying to develop a Web Service architecture that can take advantage of the information available in DAML-S descriptions and to produce a DAML-S toolkit that facilitates the implementation of DAML-S enabled Web Services.

The first requirement of a DAML-S enabled Web Service is to understand the structure and the information contained in a DAML-S description. This requirement entails the ability of compiling correct requests for service, processing the descriptions of the services retrieved and finally, correctly following the workflow described in the process model as well as drawing the correct inferences on the preconditions and effects of the processes in the Process Model.

A precondition for the first requirement is that Web Services understand ontologies encoded in DAML. Dealing with DAML ontologies is fundamental because it allows the Web Service to derive inferences on the different statements included in a DAML-S description. Furthermore, it is required to extract the information included in the messages exchanged with other Web Services, as long as this information is compiled in DAML

Finally, the Web Service needs to include ways to use WSDL descriptions of the Grounding to send and receive messages correctly. This last module should be responsible for the exchange of messages with other Web Services managing not only the WSDL description, but also managing the network protocol and the transmission of information or the reception of such information.

The architecture that we adopted is displayed in figure . It shows that a DAML-S Web service can be divided in two main parts: a DAML-S Port which corresponds to the three modules in the center column, which is responsible for the management of the interaction with other Web services; and the actual Service, represented by the box on the right, which determines what the Web service does. Examples of services may include a stock reporting Web service, in which case the Service module would monitor the stock market, or an airline booking Web service, the Service module interacts with the airlines to book seats, gather information about airplanes and so on. Ultimately, DAML-S is silent about the application of the Web service, so we display it as a black box.

Figure: Description of DAML-S Web Service architecture

The DAML-S Port consists of three modules which are roughly used in a sequence. The DAML Parser is used to load DAML-S specifications of Web services, specifically their Process Model and Grounding, as well as loading other DAML ontologies from the Web. The DAML Parser transforms the DAML files into lists of predicates to be processed by the DAML-S Virtual Machine (DAML-S VM). The DAML-S VM defines a knowledge base that is based on the Jess Theorem [8], but it specializes with rules that implement the DAML axiomatic semantics [9, 7] as well as the semantics of the DAML-S Process Model and the semantics of the Grounding. Finally, the Web service Invocation module takes responsibility for transforming abstract information to the sent to other Web services, into concrete messages, or RPC calls, to be exchanged . During the interaction, Web services exchange information through the Web service invocation module, incoming messages are translated into DAML through the Grounding Rules and added to the Knowledge Base where the new knowledge can interact with the rest of the knowledge of the Web service.

The DAML-S VM is the core of the architecture and it controls the interaction with other Web services. The first task of the DAML-S VM is to follow the Process Model of the Provider, this is accomplished through the implementation of the Process Model semantic with the Process Model Rules. These rules set contains rules the location of the next process to execute, for the extraction of inputs and outputs of each process and for the management of non-deterministic choices. Similarly, the Grounding Rules specify the correspondence between atomic processes of the Process Model and the WSDL operations, and the mapping between the inputs and outputs of the atomic processes in the corresponding input and outputs of the process model.