This document briefly characterizes the relationship of OWL-S to selected Web service and Semantic Web technologies.
In this document, we comment briefly on the relationship of OWL-S to selected Web service and Semantic Web technologies. This is not an attempt at a comprehensive description of related work, and we emphasize that there are many relevant technologies that are beyond the scope of this document. The technologies discussed here are:
OWL-S has been under development since early 2001, and has been used by a substantial number of research efforts since that time. In some cases the efforts have proposed interesting extensions to OWL-S, which are not covered in this document. In addition, a number of prototype systems and system designs have been based on OWL-S, and a number of tools built to support its use, which are not covered here. Many of the research papers, systems, and tools related to OWL-S are listed on the OWL-S release site. Most of the listed items are available for download.
WSDL (Web Services Description Language) describes Web services as collections of "communication endpoints" or ports, which send and receive messages according to specified protocols, such as HTTP, or SOAP-RPC. WSDL aims to automate communication between Web services by distinguishing such abstract Web service descriptions from the concrete data formats and protocols that are used to implement the Web service. A WSDL binding maps between the abstract description of a Web service and its specific realization [3]. (We focus on WSDL 1.1 here, as WSDL 2.0 is still undergoing revision as of this writing.)
Web services are defined in WSDL as sets of ports, which are essentially network addresses associated with certain protocols and data format specifications. Each port is associated with a port type, which describes the message exchanges (operations) the port can take part in. Four basic kinds of operations are possible (again, in WSDL 1.1): a one-way message, a (two-way) request-response, a (two-way) solicit-response and a (one-way) notification message. Message definitions normally employ XML Schema types and thus support a broad range of type definitions. OWL-S, by contrast, implicitly defines message types (as input/output types of processes) of in terms of OWL classes, which allows for a richer, class-hierarchical semantic foundation underlying the type specifications. Port types are reusable and can be bound to multiple ports [4]. WSDL builds on SOAP by providing a binding for WSDL operations to SOAP messages and WSDL ports to SOAP endpoints.
WSDL assumes a stateless client-server model of synchronous or uncorrelated asynchronous interactions [7]. OWL-S, by contrast, supports a richer semantic description of Web services beyond their communication interfaces and assumes long-running stateful behaviour of the Web services, specifying, for instance, logical constraints between the input and output parameters of services.
OWL-S has a complementary relationship to WSDL, and OWL-S' Grounding ontology explicity provides the means by which they may be used together. OWL-S processes are viewed as abstract service specifications, in the sense that they contain no commitments regarding details of interoperation, such as message format and communication protocol. The Grounding ontology is used to specify these commitments, by mapping selected OWL-S ontology elements onto selected elements of a WSDL specification.
In brief, these mappings are based on several natural correspondences between OWL-S and WSDL:
In grounding an OWL-S atomic process to WSDL, one takes advantage of WSDL extensibility mechanisms, in accordance with the intentions of the WSDL design.
The relationship between OWL-S and WSDL, and the content of the Grounding ontology, are explained in greater detail in the technical overview document included with this release of OWL-S.
As of this writing, the OWL-S Grounding ontology ties in with WSDL 1.1. WSDL 2.0 is currently under development in the Web Services Description working group at W3C. Once WSDL 2.0 has been finalized, we expect to update the OWL-S Grounding, and this document, appropriately.
SOAP provides a basic messaging framework for Web services to exchange messages. SOAP defines an XML-based format for the specification of structured and typed messages that can be exchanged by Web services (also called SOAP endpoints) in a distributed environment. The message exchange mechanism is primarily one-way, although more complex mechanisms can be easily built on top of it. In addition, SOAP provides a way to describe the actions that an endpoint must take on receiving a particular SOAP message.
SOAP constitutes a basic building block for Web services and is therefore a common foundation for several Web services standards, in particular WSDL. The OWL-S Grounding supports SOAP message exchange between Web services by using WSDL to specify the format of the messages exchanged between Web services.
UDDI (Universal Description, Discovery and Integration) is an initiative to develop a standard for an online registry, to enable the publishing and dynamic discovery of Web services offered by businesses [1]. UDDI allows programmers and other representatives of a business to locate potential business partners and form business relationships on the basis of the services they provide. It thus facilitates the creation of new business relationships.
Each business description in UDDI consists of a businessEntity element, akin to a White Pages element describing the contact information for a business. A businessEntity describes a business by name, a key value, categorisation, services offered (businessService elements) and contact information for the business. A businessService element describes a service using a name, key value, categorisation and multiple bindingTemplate elements. This can be considered to be analogous to a Yellow Pages element that categorises a business. A bindingTemplate element in turn describes the kind of access the service requires (phone, mailto, http, ftp, fax etc.), key values and tModelInstances. tModelInstances are used to describe the protocols, interchange formats that the service comprehends, that is, the technical information required to access the service. It is also used to describe the namespaces for the classifications used in categorisation. Many of the elements are optional, including most of the ones that would be required for matchmaking or service composition purposes.
Using UDDI, a Web service provider registers its advertisements along with keywords for categorisation. A Web services user retrieves advertisements out of the registry based on keyword search. So far, the UDDI search mechanism relied on predefined categorisation through keywords, but more recently specifications to use OWL in UDDI are emerging as a uniform way to express taxonomies business taxonomies. Such use of OWL is expected to facilitate the service retrieval within the registry.
While the representation of Web services provided by UDDI and OWL-S are very different, there is a strong synergy between the two efforts since both of them aim at facilitating the discovery of Web services. One way to combine the two efforts has been provided in [2] which defines a mapping from OWL-S and UDDI. Exploiting such a mapping services defined in OWL-S can be registered with UDDI. Furthermore, such a mapping allows UDDI engines to exploit OWL-S semantic information to facilitate the retrieval of Web services.
BPEL4WS (Business Process Execution Language for Web Services) enables the specification of executable business processes (including Web services) and business process protocols in terms of their execution logic or control flow. Executable business processes specify the behaviour of individual participants within Web service interactions and can be invoked directly, whereas business process protocols (also called abstract processes) abstract from internal behaviour to describe the messages exchanged by the various Web services within an interaction.
Abstract processes only consider protocol-relevant data and ignore process-internal data and computation. The effects of such computation on the business protocol are then described using non-deterministic data values. Executable processes, on the other hand, are described using a rich process description language which deals with both protocol-relevant and process-internal data. Executable processes also reference port types contained in WSDL documents, which are used to define partner roles that can be filled by those Web services that meet the restrictions set for the partner role. These roles can thus be filled dynamically and the port-specific information of the partner bound at run-time. BPEL4WS also defines several mechanisms for recovery from faults, such as catching and handling of faults, and compensation handlers which specify compensatory activities in the event of actions that cannot be explicitly undone.
While there is overlap in the conceptual models of OWL-S and BPEL4WS, OWL-S truly complements BPEL4WS. Recent work has shown how BPEL4WS can leverage rich OWL-S descriptions of services to augment its functionality to include tasks such as dynamic partner binding and semantic integration, e.g., [25]. OWL-S aims to make Web services computer-interpretable -- described with sufficient information to enable automation of a variety of tasks including Web service discovery, invocation, and composition. BPEL4WS has no such objective. It provides a language for describing executable processes and protocols that are constructed manually.
At its core, BPEL4WS is a process modeling language that draws heavily from previous Web services specifications, such as XLANG [22] and WSFL [23]. As such, it relates most closely with the OWL-S Process Model. OWL-S leverages the rich expressive power of OWL together with its well-defined semantics to provide richer descriptions of Web services that include process preconditions and effects. This enables the encoding of service side-effects that are often important for automated selection and composition of Web services. OWL-S also provides for the description of non-functional service constraints that are useful for automated Web service discovery or partnership bindings. Finally, OWL-S enables rich typing of Web service parameters including properties of objects and complex constraints between them. At present the OWL-S process model differs from BPEL4WS in that it masks some execution details of Web services. Nevertheless, the OWL-S process model was designed with the objective of encompassing emerging process model standards such as BPEL4WS. OWL-S currently does not define recovery protocols but the formalised translations of OWL-S descriptions (as in [10, 9]) may be extended to support them.
ebXML addresses the broad problem of B2B interaction from a workflow perspective. Business interactions are described through two views: a Business Operational View (BOV) and a Functional Service View (FSV) [5, 6]. The BOV deals with the semantics of business data transactions, which include operational conventions, agreements, mutual obligations and the like between businesses. The FSV deals with the supporting services: their capabilities, interfaces and protocols. Although ebXML does not restrict the means of B2B interaction to Web services, their focus is essentially the same as that of OWL-S.
ebXML enables Web services to describe the business processes they support and the services they offer using Collaboration Protocol Profiles (CPP). A business process in ebXML is considered to be a set of business document exchanges between a set of Web services. This is akin to the Web services message exchange as commonly described in Web services standards. CPPs contain industry classification, contact information, supported business processes, interface requirements etc. They are registered within an ebXML registry (similar to a UDDI registry), in which other Web services and their business processes can be discovered. However, ebXML's scope does not extend to the format in which the business documents are specified. This is left to the interacting Web services to agree upon a priori by the creation of a Collaboration Protocol Agreement. Since OWL-S provides a language for the description of the behaviour of Web services, its scope is complementary to that of ebXML. In fact, OWL-S descriptions could themselves be used within ebXML to describe the business processes of interacting Web services.
The Web Service Choreography Description Language (CDL) describes Web services interactions in terms of their externally observable behavior, typically exposed though message exchanges. Each participant in an interaction specifies an interface, describing the temporal ordering and logical dependence of messages it sends and receives. In addition, a global model can be specified that describes the collective message exchange of interacting Web services. Unlike BPEL4WS, CDL does not describe the executable details of individual Web services. It focuses on the problem of collaboration (message exchange between distributed peers) rather than orchestration (creation of executable Web services). Consequently, it does not assume the presence of a central process managing the interactions between Web services. For the same reason, CDL control flow constructs are considerably simpler than those of BPEL4WS. CDL documents are formal specifications intended for explication, (automated) verification, and conformance testing, although they can be used to automatically generate code skeletons.
CDL corresponds most closely to the OWL-S Process Model. Both share the goals of describing the message exchange between participating Web services. However, unlike CDL, OWL-S markup is meant to support execution and the generation of executable service compositions (e.g., using planning techniques). Also, CDL specifically eschews any description of the significance, e.g., the business significance, of interactions whereas OWL-S is specifically intended to support the description of everything from the ``real world'' preconditions and effects of an invocation to the classification of services by their primary purpose.
OWL and SWRL are grouped together since both are languages that OWL-S uses in order to build on emerging language standards. The OWL Web Ontology Language [13] is a W3C recommendation for a web ontology language and is the representation language for OWL-S ontologies. One reason OWL was chosen as the representation language for OWL-S is that it is compatible with XML [19] and RDF [18] while providing additional expressiveness thus allowing users to formally describe more types of classes, properties, individuals, and relationships than XML or RDF. OWL also provides a formal semantics, thus terms defined using OWL are given a precise meaning and they can be used effectively in applications that require interoperability. OWL is a general purpose representation language that provides no special vocabulary for service applications. Thus anyone who needs to build a service application would need to find a service ontology or build their own. OWL-S is a set of several interrelated OWL ontologies that provide a set of well defined terms for use in service applications. The OWL-S ontologies define terms common in service profiles, process models, and service interoperations (groundings). The OWL-S ontologies provide semantic web users with an existing vocabulary of classes, relations, and instances for use in OWL, RDF, and XML-compatible applications.
OWL provides three increasingly expressive sublanguages: OWL Lite, OWL DL, and OWL Full. OWL Lite provides less expressive power than OWL DL and OWL Full and was not expressive enough for OWL-S needs. OWL DL provides maximum expressiveness while retaining computational completeness and decidability and thus is the choice implementers make when they are interested in efficient reasoning support. (OWL DL and OWL Full provide the same language constructs but OWL DL places some restrictions on usage in order to avoid problems with completeness and decidability.) OWL-S ontologies are written in OWL DL, thus are positioned well to support applications where computational guarantees are required on the reasoning components.
Since OWL-S is written in OWL, its users can utilize the many tools emerging for OWL such as validators, editors, browsers, ontology evolution environments, etc. Many of these tools can be found on the DAML web site [16] and SemWebCentral [17] . The SWRL Semantic Web Rule Language [14] is a rule language that combines OWL with the rule markup language [15] providing a rule language compatible with OWL. SWRL has been submitted to the W3C as a potential starting point for a new rules working group that could produce a W3C semantic web rule language. SWRL expressions may be used in OWL-S preconditions, process control conditions (such as if-then-else), and in effects expressions. SWRL expressions may also mention process inputs and outputs as variables thus linking the two languages together. The OWL-S use of SWRL remains in OWL DL (by quoting SWRL rules and thus considering them to be XML Literals). This connection with SWRL makes the OWL-S ontologies more powerful since it uses the expressive power of rules in a potential emerging standard. It also serves as an example of how one can use a rule language and stay within OWL DL, thus preserving efficient reasoning options.
A Grid is a system designed "to coordinate resources that are not subject to centralised control using standard, open, general purpose protocols and interfaces to deliver nontrivial quality of service" [20]. The resources available on a Grid are modelled as Grid serviceswith state. The Open Grid Services Infrastructure (OGSI) [21] uses extended WSDL constructs and XML schemas to introduce the notion of stateful Web services alongwith standard operations for creating and destroying Web services, for representing, querying, and updating metadata associated with a Web service. In addition, OGSI provides mechanisms for references to instances of Web services and asynchronous notification of Web service state changes. OGSI also defines an XML Schema for describing faults that take place during WSDL operations.
The OGSI framework has been recently refactored to define a family of related specifications that could be adopted on a piecemeal basis. This refactoring together with some extensions to keep pace with changes in Web services standards forms the WS-Resource Framework (WSRF) [24]. Although OGSI and WSRF go beyond WSDL with the specification of several kinds of specialised port types and fault messages, unlike OWL-S, they does not attempt to describe the behaviour of Grid or Web services. In this sense, OWL-S is complementary to both these specifications.
WSMO shares with OWL-S the vision that ontologies are essential to support automatic discovery, composition and interoperation of Web services. But despite sharing a unifying vision, OWL-S and WSMO differ greatly in the details and the approach to achieve these results. Whereas OWL-S explicitly defines a set of ontologies that support reasoning about Web services, WSMO defines a conceptual framework within which these ontologies will have to be created. Another difference between OWL-S and WSMO is that while OWL-S does not make any distinction between types of Web services, WSMO places a lot of stress in the specification of mediators: mapping programs that solve the interoperation problems between Web services.
In WSMO's vision, mediators perform tasks such as translation between ontologies, or between the messages that one Web service produces and those that another Web service expects. In the process of defining mediators, WSMO produces a taxonomy of possible mediators that helps to define and classify the different tasks that mediators are supposed to solve. However, it can be difficult to map this taxonomy onto the classical problems of Web service interoperation; i.e. discovery, composition and invocation. For example, it is unclear how mediators can help during discovery, since discovery is intrinsically a selection problem, while mediators attempt to reconcile the differences between goals of Web services.
The definition of mediators in WSMO calls attention to some very important translation tasks that Web services face. Not surprisingly, these same translation tasks are needed in support of OWL-S Web services in their interaction. However, rather than stipulating the existence of a new type of component in the Web services infrastructure, OWL-S provides to Web services and their clients the information that is needed to find existing mediators that can reconcile their mismatches, or perhaps to create mediators through the process of Web service composition.