Service Integration through Structure-Preserving Semantic Matching

Service Integration through Structure-Preserving Semantic Matching

Fiona McNeill (University of Edinburgh, Scotland), Paolo Besana (University of Edinburgh, Scotland), Juan Pane (University of Trento, Italy) and Fausto Giunchiglia (University of Trento, Italy)
Copyright: © 2009 |Pages: 21
DOI: 10.4018/jcit.2009072102
OnDemand PDF Download:
No Current Special Offers


The problem of integrating services is becoming increasingly pressing. In large, open environments such as the Semantic Web, huge numbers of services are developed by vast numbers of different users. Imposing strict semantics standards in such an environment is useless; fully predicting in advance which services one will interact with is not always possible as services may be temporarily or permanently unreachable, may be updated or may be superseded by better services. In some situations, characterised by unpredictability, such as the emergency response scenario described in this case, the best solution is to enable decisions about which services to interact with to be made on-the-fly. We propose a method of doing this using matching technique to map the anticipated call to the input that the service is actually expecting. To be practical, this must be done during run-time. In this case, we present our structure-preserving semantic matching algorithm (SPSM), which performs this matching task both for perfect and approximate matches between calls. In addition, we introduce the OpenKnowledge system for service interaction which, using the SPSM algorithm, along with many other features, facilitates on-the-fly interaction between services in an arbitrarily large network without any global agreements or pre-run-time knowledge of who to interact with or how interactions will proceed. We provide a preliminary evaluation of the SPSM algorithm within the OpenKnowledge framework.
Article Preview


The problem of automated integration of services is key to the successful realisation of the Semantic Web, or any other system where services interact with one another. So far, this has proved difficult. Global ontologies allow different services to be expressed using the same terms, which are thus understandable to all. But there are significant difficulties with the notion of a global ontology: both the relevance of terms and appropriate categorisation of those terms is very context dependent. An ontology that included all terms that could be relevant to any situation would be impossible to build, impossible to reason with and would allow no flexibility for different interpretations of situations.

However, integration of services using different ontologies is difficult. The difficulties arise at two levels: in the structure of the invocation to the service and in the values passed with the invocation. A service will expect some input parameters and will return an output. Consider for example, the web service measurement, whose WSDL description is shown in Figure 1. Its purpose it to provide the level of water registered by a particular sensor on a grid of sensors on a particular river-side area, which can be used during an emergency to assess the conditions. It expects as the input message the location, defined as the node identifier in the grid, and the id of the sensor, and returns in the output message the measured water level and the timestamp of the measurement.

Figure 1.

WSDL code for a web service returning the water level measured by a sensor in a grid of sensor for preventing flooding


The structure, or signature, provided by input parameters and output values must be respected by a process invoking the service. However, the invoking process may have a different signature for the caller function (parameters may have different names or

they may have a different structure). For example, a caller process could be a BPEL workflow, originally developed to invoke a service called reading, that does not have the concept of location, but only of the reporter and node identities, and expects the level to be named differently. The invocation needs to be adapted to the new called service.

Even after the structural adaptation has been performed, the terminology used in the parameters may be defined in different ontologies in the caller process and in the service. This may cause misunderstandings or failure: for example, the water level may be returned in meters when the caller expected feet. Translation is required.

This case focuses on the problem of matching the signature of service invocation with that of the service when they are expressed in different ontologies. It is perfectly possible to solve this problem by manually matching the expected inputs and outputs of two services – the one that the caller expected and the one that is actually called – prior to interaction. For example, Altova MapForce1 is a system which facilitates this manual mapping. However, performing this is time consuming and not scalable. Additionally, this presupposes that one knows in advance what calls will be necessary. This is perhaps feasible in a small, static system, but in a large, dynamic system where services may be temporary, may be updated, may suffer from occasional communication breakdown, and so on, we do not wish to limit the number of services with which it is possible to interact. A better solution in this sort of environment is to automatically integrate services on-the-fly as the need becomes apparent.

Using our matching approach we are able to map between the invocation of the service, written in the ontology of the caller, and the call the service is expecting, written in the ontology of the service. The goal of the matching is two-fold:

  • to establish whether these services (the expected and the called) are similar enough: if the service is being asked to perform an action that is too different to the function it is equipped to perform, then the correct response is to refuse to interact;

  • if the call is judged to be similar enough, then an adaptor is generated to bridge beween the caller and the invoked service .

Complete Article List

Search this Journal:
Volume 24: 4 Issues (2022): Forthcoming, Available for Pre-Order
Volume 23: 4 Issues (2021): 2 Released, 2 Forthcoming
Volume 22: 4 Issues (2020)
Volume 21: 4 Issues (2019)
Volume 20: 4 Issues (2018)
Volume 19: 4 Issues (2017)
Volume 18: 4 Issues (2016)
Volume 17: 4 Issues (2015)
Volume 16: 4 Issues (2014)
Volume 15: 4 Issues (2013)
Volume 14: 4 Issues (2012)
Volume 13: 4 Issues (2011)
Volume 12: 4 Issues (2010)
Volume 11: 4 Issues (2009)
Volume 10: 4 Issues (2008)
Volume 9: 4 Issues (2007)
Volume 8: 4 Issues (2006)
Volume 7: 4 Issues (2005)
Volume 6: 1 Issue (2004)
Volume 5: 1 Issue (2003)
Volume 4: 1 Issue (2002)
Volume 3: 1 Issue (2001)
Volume 2: 1 Issue (2000)
Volume 1: 1 Issue (1999)
View Complete Journal Contents Listing