Publication: IBM Systems Journal
Publication Date: 01-DEC-05
Delivery: Immediate Online Access
Author: Vetere, G. ; Lenzerini, M.
Article Excerpt
Although service-oriented architectures go a long way toward providing interoperability in distributed, heterogeneous environments, managing semantic differences in such environments remains a challenge. We give an overview of the issue of semantic interoperability (integration), provide a semantic characterization of services, and discuss the role of ontologies. Then we analyze four basic models of semantic interoperability that differ in respect to their mapping between service descriptions and ontologies and in respect to where the evaluation of the integration logic is performed. We also provide some guidelines for selecting one of the possible interoperability models.
INTRODUCTION
Modern information technology (IT) systems based on service-oriented architectures (SOAs) consist of a network of service providers. Services are invoked by client applications (consumers) by means of messages that conform to descriptive schemas. Although typically service descriptions are exported by providers to registries (or directories), some service descriptions may also be supplied directly to consumers. What is crucial--and different from client/server architectures--is that, for each service, a schema defines its functionality and registries are available for lookup and binding of services without knowledge beforehand.
The services supported by a provider give access to the provider's state and allow making changes to that state. Here we use "state" in the classic way, as the actual values of a given set of attributes. For instance, a data service can be seen as a database management system whose state is the actual data in the database, and in which client applications can perform read and write operations through a set of services described in terms of the allowed get and set operations, along with a portion of the database schema exported in a suitable way. In summary, by using the service descriptions available, applications can access and manipulate the state of providers.
In order for client applications to use services effectively, it is crucial that the designers of these applications understand the service descriptions that correspond to the client's operations and data structures. Similarly, developers of distributed information systems that cooperate through services should have a good understanding of how service descriptions relate to one another. Methodologies, artifacts, and techniques aimed at the correct interpretation and implementation of service descriptions are generally referred to as the "semantic layer" of service-based infrastructures.
In a service-oriented environment, the semantic layer ensures that data embedded within messages are interpreted by providers and consumers as representing the same concepts, relations, or entities in a suitable abstraction of the real world. For instance, the semantic layer helps detect that the attribute tour-cost at www.grand-tour.com corresponds to ticket-price at www.railways.it. Rephrased in the "philosophical" jargon currently in use by the computer science community, the semantic layer is about how participants can interpret descriptions and data items in the system with respect to some ontology (1) of the business domain and how this interpretation can be shared and made transparent throughout the infrastructure.
The semantic layer also includes operational aspects, such as the definition of business transactions as presented in RosettaNet (2) standards. In fact, the semantic layer can be viewed to contain anything that can be entered in a data vocabulary with the purpose of characterizing the provider's service. In other words, it covers objects, events, states, and anything else that can be conceived, expressed, and exchanged over a communication network, which in fact amounts to the entire coverage of a standard linguistic dictionary. Designers--consciously or not--have to decide how to manage the semantic layer and have to make assumptions about it. The aim of this paper is to provide SOA developers with basic conceptual tools to better understand the semantic layer. Because handling semantics is not an easy task and important research issues are still under investigation, this paper aims at giving general guidelines rather than ready-for-use instructions.
Our interest in semantics is not primarily motivated by advanced functions such as intelligent service discovery or the composition and choreography of automatic services, but by the need to make heterogeneous information systems work in a networked world. For this reason, we focus here on the interoperability of services as is worked out by humans, and we do not survey the rich literature related to the use of semantic models for automating service integration tasks. (3)
Motivation
In current practices, semantics is usually relegated to the backstage of design and implementation activities and is not often given the place it deserves. Semantic correspondences are captured by message transformation rules that map names, values, and structures in these messages exchanged by services. In general, this approach can be seen as semantically neutral, in that it does not require the mappings to account for the way in which the source and the target refer to real entities. In other words, message transformation rules are written without accounting for the reason why the corresponding mapping holds. This strategy can be seen as a pragmatic way to address semantic interoperability in many common situations, when it is reasonable to assume that the interpretations given the service descriptions by cooperating participants are consistent. In many cases, this neutrality presupposes a sort of realism: the idea that attributes which shape the domain of the service infrastructure are given by nature, once and for all. Thus, because services implicitly use the very same ontology, the role of designers is just to "neutralize" a number of different naming and structural renderings of elements of a unique, universal, immanent conceptualization. This is probably why SOA technologies are mature in supporting rich-message mapping and transformation languages, but are "green" (immature) in providing standard means to drive the development of specific semantic-oriented artifacts, and are generally silent about the conditions that must be ensured in order for message transformations to be semantically sound. As a matter of fact, whereas current frameworks provide a fairly good basis to handle descriptive heterogeneity through a syntactic approach, the treatment of semantics is generally left to designers, if and when they feel the need to bring semantics to the foreground.
Being neutral with respect to semantics is reasonable in many situations, but it doesn't work in general. In fact, this approach assumes the reliability of some implicit agreement that lives outside the infrastructure, let us say, in the system's social surroundings. For instance, guessing that two attributes refer to the same entity if they have the same name is based on the assumption that labels are uniformly interpreted by all parties. This could be acceptable if service infrastructures were built, deployed, and managed within tight organizational boundaries, as in enterprise application integration scenarios, where naming policies can be enforced and controlled. But SOAs could be used to implement information systems in large and geographically distributed organizations, such as supply chains of cooperating but independent companies, or even to manage structured information exchanges across quite "anarchic" Web communities. In these cases, designers can hardly make reliable assumptions about the infrastructure's social surroundings. Actually, they cope with information providers that are only requested to sketch the kind of services they make available, mostly from a functional standpoint. Semantics, which is the way services fulfill what their descriptions promise, is embedded in the "black box" of service implementation. In these scenarios, the reach of semantic agreements is problematic: accurate derivation of meaning cannot be implicit, and therefore the semantic layer requires specific tools and methods.
Semantic interoperability between services in an SOA is not very different from linguistic understanding between humans. Linguists and philosophers have been engaged in studying the foundations of natural language semantics for centuries, and many authors have even been skeptical about our real capability to understand each other. (4) The attractive idea of realism, which maintains that humans understand each other because the language reflects a commonly understood world and that differences are only at the linguistic surface, has been strongly rejected by many philosophers, especially in the last century. Quine, for instance, claimed that "ontological commitments" are relative, and there is no way to tell whether an expression uttered by a foreign speaker in the presence of a rabbit denotes the entity (i.e., the rabbit) or the event (i.e., the presence of a rabbit), very different elements from an ontological standpoint. (5) Applied to SOAs, Quine's assertions would amount to the statement that there is no unique interpretation of a service specification, just based on the specification itself. Although we will not engage in a philosophical discussion here, if we approach semantic interoperability from a relativistic standpoint, there are no naturally safe semantic assumptions when dealing with cooperating services. Therefore, relativism requires much more focus on semantics than realism, and this maybe explains the reason why this discipline has gained popularity within the computer-science community since the Web became pervasive. (6)
We believe that awareness of semantic issues when designing interoperating services helps deliver better solutions, not only for the Web, but also in restricted environments such as e-government or large enterprises, in which designers can rely on stable semantic conventions. With this in mind, in the next section we provide some basic concepts for understanding semantic interoperability. Then, we classify the models for semantic interoperability in service-oriented infrastructures, and take into account whether they reflect a hub-based or endpoint-based structure, and whether they rely on business domain models. We also show how problems of semantic interoperability are close to many of the issues that have been studied for decades in data exchange and integration under the lens of logic, (7) and how some of the concepts developed in this field can be usefully applied when designing the new kind of IT infrastructures.
SEMANTICS OF SERVICE INFRASTRUCTURES
We have shown in the previous section how services allow accessing and changing the state of their providers, that is, the values of some exported attributes, and how this access and manipulation is carried out by sending and receiving messages. We have also informally introduced the...
NOTE: All illustrations and photos have been removed from this article.
More articles from
IBM Systems Journal
Beyond predictable workflows: enhancing productivity in artful business processes., 01-OCT-06
Following the sun: case studies in global software development., 01-OCT-06
Business activity patterns: a new model for collaborative business applications., 01-OCT-06
Looking for additional articles?
Click here to search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Click here to search our complete database of Industry & Market reports by text, subject, publication name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.
Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information. |
