Muhammed J. Al-Muhammed is a PhD student working with Dr. David Embley in the Data Engineering Laboratory. One of the objectives of his research is to use ontologies along with the long-standing notion of ontology-based data extraction to declaratively create services (using only static knowledge not code). These services have the characteristic that they allow people to specify their service requests using only free-form service specification.

Web services are proliferating, and their number can reach hundreds of thousands in a few years. They are changing the web from a place to post and consume information to a place to do tasks such as scheduling appointments, buying and selling all kinds of goods, querying weather information, and much more. Service requesters still, however, need to do a lot of manual work to use them. To use a web service, a service requester must discover a service of interest and synchronously communicate with it. Synchronous communication causes a requester to stay connected with a web service until it returns; otherwise the communication fails. This coupling caused by the need to discover and synchronously communicate with a web service is a weakness in the web-service paradigm. A requester must also comply with service-specified data formats and data-exchange protocols. This means that web services do not handle data heterogeneity. For a successful invocation, requesters must resolve data heterogeneity by knowing in advance the service-specified data and comply with it. Specifically, requesters must a priori know inputs and outputs of a web service, order of its input parameters, the type of each input parameter, and the formats of the values that should be passed to it. To emphasize, web services require strong coupling between communicating applications and they lack the mechanism to handle data heterogeneity.

To overcome the coupling and heterogeneity problems, researches have suggested basing web services more fundamentally on web principles. Web services that are based on web principles should use the web as a place for information publication and access rather than just using it as a transport medium. This means that both service requesters and providers use the web to exchange data. Requesters post their service requests on the web and service providers check the web for requests that they can service. Thus, theoretically, there is no coupling between service requesters and providers in the sense that requesters do not have to discover services nor to directly communicate with them.

In our research, we take the vision of web-principled services a step further by providing an ontological approach that (1) creates services (called ontology-based web services or OBWSs for short) that decouple service requesters and services and resolve the data heterogeneity problem and (2) turns web services to OBWSs. To meet the decoupling requirement, our approach provides a request-oriented architecture. This architecture allows requesters to specify their requests to a broker. The broker finds the capable OBWSs and lets requesters choose which OBWS to use for servicing a request based on the characteristics of the OBWS such as fees it charges, the quality of the service it provides, and so on. The chosen OBWS takes the request, services it, and provides a response by creating a communication link with the requester. This architecture decouples OBWSs and requesters in the sense that requesters do not have to discover the capable OBWSs nor do they have to reference or invoke them. The requesting application does not stay coupled with the OBWS as the OBWS establishes the communication link only when the response is ready to be returned to the requesters.

In addition, service requesters do not have to make their data in a request comply with the data required by the OBWSs. Due to their ontological bases, the OBWSs themselves are capable of handling data heterogeneity using their underlying ontologies. Any required vales for the invocation of an OBWS can be extracted from the service request, can be made to comply with the OBWS’s internal data types and formats using the ontologies operations, and can be mapped to their respective input parameters independently of how these values appear in the request. Requests also need not be complete. OBWSs can use their underlying ontologies to provide default values or to request specific values from users for input parameters for which requests provided no values.

The OBWS approach can also turn traditional web services to OBWS services so that traditional web services not only can be invoked in the same way as OBWSs, but also, and perhaps more importantly, they exploit the data heterogeneity resolution capabilities of the OBWSs. All that is required to turn a tradition web service into an OBWS is to create an ontology that describes the semantics of the web service interface (name of the service, its input and output parameters along with their types and data formats). No change to the traditional web service’s actual interface or internal implementation is required.

Based on its capabilities, the OBWS approach can be a significant forward. Requesters are able to specify only the services they want without having to worry about idiosyncrasies of the applications that service their request. The OBWS approach can satisfy this requirement.