Ontology Web Language for Services (OWL-S)
The Ontology Web Language for Services (OWL-S) is a “core set of markup language constructs for describing the properties and capabilities of Web Services in unambiguous, computer-interpretable form.” When fully realized, OWL-S will allow service providers or brokers to define their services based on agreed upon ontologies that describe the “real world” functions they provide. OWL-S was originally called DARPA Agent Markup Language for Services (DAML-S), and was created as part of the DARPA Agent Markup Language (DAML) project.
The goals of OWL-S are to provide
- Strong ontological description of Web Services
- Dynamic discovery of services based on ontological queries
- Transparent invocation of those services
The Ontology Web Language for Services (OWL-S) provides developers with a strong ontological language to describe the properties and capabilities of their Web Services in such a way that the descriptions can be interpreted by a computer system in an automated manner. The information provided by an OWL-S description of a Web Service includes an ontological description of the inputs required by the service, the outputs it provides, and the pre- and post-conditions of each invocation.
At its core, OWL-S is based on ontologies of objects and concepts defined using the Ontology Web Language (OWL). OWL ontologies describe the hierarchical organization of ideas in a domain in a way that can be parsed and understood by a software program. OWL ontologies are similar to object-oriented classes in a software program (without the runtime functional components). In an ontology of fruits and vegetables, the classification of Berry could be considered a subclassification of Fruit, and the Blueberry could be introduced in the ontology as an instance of the Berry classification with the characteristics of its color being blue and of its taste being sweet. The ontology could further be extended to make Fruits and Vegetables a subclassification of Food. A graphical example of this ontology is presented in Figure 1.
Figure 1. An Incomplete Example of an Ontology of Foods
In addition to description of services, OWL-S includes the OWL-S
Matchmaker and the OWL-S Virtual Machine. The OWL-S Matchmaker
serves as a “catalog” of services defined using OWL-S. OWL-S
descriptions of services are registered with the matchmaker. Client
applications can then “query” the matchmaker with an ontological
description of the inputs and outputs they desire. The matchmaker then matches
the request against its catalog of services and returns a ranked list of
services that most closely match the request sent by the client application.
The client application then uses the OWL-S Virtual Machine to actually invoke
services using OWL-S. The client application formulates its request using the
format specified by the OWL ontology of the input and sends the request to the
OWL-S Virtual Machine. Services defined in OWL-S are mapped to the actual Web
Services they represent by way of the OWL-S grounding. Using XSLT
transformations present in the grounding, the Virtual Machine reformats the
request to match with the format required by the service, and then invokes the
services on behalf of the client. When the response is received by the virtual
machine, it uses another XSLT transformation in the grounding to reformat it
into a format matching that of the output ontology and forwards it back to the
client application. In this manner, the client application does not need to
know anything about how to interact with the actual web service; the OWL-S
Virtual Machine acts as a mediator for the request. This somewhat complicated
process is depicted in Figure 2.
Figure 2. Runtime Architecture for an Application that uses OWL-S to
locate and invoke services
State of the Practice
OWL-S is still at its very early stages of development. The OWL-S community is small and the technology is rather immature. Nonetheless, the Intelligent Software Agents Lab at Carnegie Mellon University has played a critical role in the development of OWL-S from its very conception. In addition, the Softagent Group also has developed the most complete and integrated set of OWL-S development tools, the OWL-S IDE.
Service Discovery
OWL-S allows the dynamic discovery of services based on the ontological classifications of their expected input and output. Given a collection of properly defined OWL-S service groundings and a profile describing the classifications of the desired inputs and outputs, an OWL-S Matchmaker can return an ordered list of services that most closely match the desired service. A client application can then select the service that provides the capabilities it desires. However, OWL-S does not yet provide support for querying for services based on their “service description.” Although the OWL-S standard can be extended to include the capability to define the “category” of a service in its profile, the OWL-S Matchmaker does not yet take advantage of this part of the profile while performing a match.
In OWL-S, services are matched based on the ontological classifications of their inputs and outputs. In order to correctly classify services for use with OWL-S, an ontology must be established that sufficiently covers all of the types of inputs and outputs that might be available in the domain. Small variations in the types of input or output that a service provides can change drastically their ontological meanings. Ontolologies must be deep enough to cover these variations without sacrificing the quality of the “fit” of an ontological classification to the interface of a service. In order to find a common match between services with different interfaces but common ontological meanings, the OWL-S profiles of the service must share a common ontology. For example, a collection of mapping services should all share the same “Map” ontology. By sharing a common ontology, services with common ontological inputs and outputs can be discovered with the same queries, even if they have different interfaces.
Additionally, simply classifying services by type alone will not allow applications to effectively use OWL-S to perform dynamic service discovery. Within a single type or classification of service, there are a vast number of different combinations of input and output types that must be dealt with. For example, an application cannot expect to simply to query for “Map Provider” services and expect to find a perfect fit for their particular need. What type of map? What quality, scale, and resolution? What type of input can be provided? If the only “Map Provider” service that was discovered took an address as input and the only knowledge available in is a latitude/longitude coordinate, that service is certainly not a good fit. In order to find effective matches using OWL-S as a discovery mechanism, the ontological classifications of the input and output still need to be taken into consideration. Service description can be used as an additional qualifier to improve the results of a service query, but they cannot stand alone as a way to discover services.
Service Composition
Using OWL-S, a client application could discover a sequence of independent services that could ultimately help it to satisfy its information goal. However, this dynamic composition of services is not provided by OWL-S—it is a capability that must be implemented at the client level. OWL-S simply provides for the discovery of services, not their automatic composition. Automatic composition would require more planning logic at the application layer in order to enable the applications themselves to compose collections of services into a more complicated operation. However, OWL-S does support the manual composition of services into composite processes. When defining the profile of a service, composite services that perform multiple operations in a predefined logical order can be created, including sequential execution and branching. “Dataflows”can also be created, which define the transfer of some or all of the data from one operation to the next. In this manner, distinct services can be manually composed into complex sequences of operations to solve a predefined goal.
Service Invocation
An application using OWL-S for dynamically locating services will be able to invoke the highest ranked service as long as it is capable of providing all of the necessary information in terms of the ontology. For example, a client application wants to find a mapping service that takes a latitude/longitude coordinate as input and provides a weather map as output. If there are no perfect matches to this request, the best match might actually be a service that requires both a latitude/longitude coordinate and a desired forecast time as input. If the client application is unable to respond to this slightly different input, or does not have access to this additional information, it will not be able to invoke the service automatically.
In order to invoke a Web Service, a client application must have at its disposal the information that it needs to provide to the service or the means by which to acquire that information. This need becomes more important with OWL-S services. In order to invoke an OWL-S service, the application must not only have access to that data, but it also must be able to format it in the proper OWL format before querying the service. Although this task can be done in a static way, much like what is currently done for Web Services, a better way is to make applications aware of the data they have access to and its ontological meaning. If this is done properly, applications will be able to access services that were not available when they were originally developed, since they will be able to format new types of queries to access new services. In addition, through goal-based planning, services could compose simple services into more complex sequences of services on the fly in order to work towards a particular information goal.
Impact for Systems of Systems
Service-oriented architectures (SOAs) take a different view on software development than the traditional application-centric methods. Rather than creating dozens of monolithic, stove-pipe applications that perform specific end-to-end tasks, SOAs build dynamic environments of services that provide support for finer-grain tasks such as checking the inventory status of a particular item or the current location of a package. Developers can then build simple applications that take advantage of these services in new ways. This reduces duplication of applications and makes it simple to modify the internal behavior of a service without affecting existing applications.
However, in a services-oriented environment, services are constantly being added and removed. Application developers often do not have control over the services that are utilized. What would happen if a service required by an application was removed from the environment or its interface was changed? What if a new and better service was introduced that an application might be able to utilize? Existing service-oriented frameworks do not protect application developers against these contingencies.
Dynamic service discovery and composition is one potential solution to this problem. By allowing applications to discover new services based on the functionality they require, they are no longer restricted to the particular services or interfaces they were originally developed to work with. As new services are introduced they will automatically be discovered and made available, even if they are different. Dynamic service composition will allow applications to automatically chain together diverse services based on the goal they plan to achieve rather than simply following a predefined process. The goal of OWL-S is precisely to allow applications to dynamically discover, invoke, and compose Web services “on the fly”.
Open Issues
Successful Integration Using OWL-S Will Require a Change in Development Paradigms
Currently, remote-procedure-call Web Service implementations are often a direct result of their local procedure call counterparts. Developers have a capability that is present in an application or service provided at the local level and they wish to make it available for use as a service for distributed applications. Services are usually developed from the ground up. That is, interfaces and data models are developed in an application-specific manner and only later do they get turned into Web Services. Later on, if the Web Services are to be described using OWL-S, a process model is fitted to the Web Service interfaces and eventually an ontology is created to represent the information services that are provided.
This process is tedious and fraught with errors. Because the Web Service interfaces were created without consideration of an ontology or the way in which the services might be used, the task of mapping service inputs and outputs to their counterparts in the ontology is extremely difficult. The mappings are also often very fragile, and depend on assumptions about the expected data. In addition, there are often parameters, such as user names and passwords, that do not fit with the rest of the ontology. This leaves a developer with few options—either sacrifice the quality of the ontology by modifying it to include the new information or hard-code the values into the service grounding.
Moving to a more semantic representation of services requires thinking and working in the opposite direction. First developers must work with domain experts to create an ontology of the knowledge domain in which the services will reside. Then a process model can be created that describes how clients will interact with the service. Only then can the programmatic interfaces for the Web Service be defined, as indicated in Figure 3.
Figure 3. New Development Paradigm for Applications and Web Services that
use OWL-S
By working in this direction, Web Service interfaces can be designed that map more directly to the ontologies of their OWL-S descriptions. A deep, complete, and extensible ontology can be created that accurately represents the knowledge space in which the service resides rather than simply the interface of the service. This will allow not only for better matches to service queries, but will also make it easier to add new services in the future.
Tool Support for OWL-S is Immature
OWL-S is no longer an infant, but it is still growing. Although many tools are currently under development, they are for the most part still immature. Most are designed primarily as “proof of concept” research tools and are not meant for production use. With the exception of the OWL-S IDE, there is not a single cohesive “toolset” for OWL-S development. With time and industry support, it is likely that this situation will improve. But at the current moment, OWL-S tool support is lacking in both depth and quality.
OWL-S is not a “Drop-In” Solution
OWL-S is not a “layer” that can be placed on top of Web Services to enable dynamic discovery and interoperability. To the contrary, it requires client applications and services to be designed with OWL-S and the service ontology in mind. A significant amount of effort would be expended in converting a service-oriented architecture to use OWL-S. Before pursuing a OWL-S as a solution for interoperability, an examination of whether or not the use of OWL-S is warranted is required. OWL-S is best for systems which need diverse services to be dynamically added, removed, and discovered. Introducing OWL-S will require significant resources to be expended in the conversion of client applications, development of ontologies, and mapping of services to OWL-S. In order to completely and correctly implement an OWL-S infrastructure, it will likely be necessary to completely recreate entire applications and services. Therefore, OWL-S is not an “integration layer” that can simply be placed on top of existing applications and services.
OWL-S Has Great Potential If Allowed to Grow
Despite its problems and its growing pains, OWL-S has a tremendous amount of potential if given the resources and opportunity it needs to grow. OWL-S could enable applications to dynamically discover, compose, and invoke new services on the fly in order to solve problems and gain information in ways that were not available when the applications were created. OWL-S has the capability to embed semantic meaning into the collections of services available in service-oriented computing environments, which will allow applications to be developed without knowledge of specific services that may or may not be available. It could also make service-oriented architectures more robust and flexible. Collections of services that are defined using OWL-S would allow applications to be tolerant of faults in a dynamic and transparent way by simply accessing other services with similar semantic meanings. OWL-S could also enable services to be dynamically registered and removed at runtime without causing downtime in client applications.
But in order to achieve these goals, more research and development must be done to make OWL-S ready for production use. OWL-S is not yet mature, but given time and money, its potential is very large.