Article Preview
TopIntroduction
Service-Oriented Computing (SOC) is an emerging computing paradigm whose main goal is to support the development of distributed applications in heterogeneous environments (Erickson & Siau, 2008). SOC enables composing or assembling together distributed functionality to build software systems. This functionality comes in the form of basic building blocks called services. A service can be defined as a piece of functionality done by an external provider who is specialized in the management of this operation. Besides, a service is wrapped with a network-addressable interface that exposes its capabilities to the outer world while hiding implementation details that may constraint interoperability.
The most widespread process for building applications according to the SOC paradigm comprises replacing the development of specific software components with a combination of service discovery, selection and engagement. Providers publish their services in a service registry establishing: the terms of engagement, technical constraints, requirements and semantic information. On the other hand, service consumers discover published services through a registry, and in turn select and contract them.
SOC is mostly implemented by using Web Services technologies, because they are designed to support interoperable provider-to-consumer interaction over the Internet (Li et al., 2007). Broadband and ubiquitous connections enable accessing the Internet from everywhere and at every time. This has enabled global registries of services that have been deliberately designed as reusable components (Crasso et al., 2009b). Such registries, besides heavily encouraging software reuse, promote outsourcing of third-party components, which results in lower ongoing investments in the entire software engineering process (McConnell, 2006).
Because of the significance of service discovery for the SOC paradigm, both researchers and industry practitioners have been developing service discovery systems. Up to now, common materializations in the software industry for service inventories supply developers with keyword-based search engines and category browsing for services as Universal Description, Discovery and Integration (UDDI)1 does. UDDI is an open specification of a registry to publish and discover Web Services sponsored by the Organization for the Advancement of Structured Information Standards (OASIS). Similarly, the Common Object Request Broker Architecture (CORBA)2 offers the Naming Service, which allows developers to find services, or “objects” in CORBA terminology, based on alphanumeric identifiers, and the Trading Service, which lets programmers find services based on one or more <key, value> pairs. Recently, Web-based search engines (e.g., Google) have become a new source for finding Web Services (Song et al., 2007), because service descriptions usually reside on Web servers that are crawled and indexed by search engines.
On the other hand, by adapting existing Information Retrieval (IR) techniques, some researchers have proposed to treat descriptions of Web Services as documents, thus reducing the problem of discovering relevant services to the well-known problem of finding relevant documents (Garofalakis et al., 2006). Other academical approaches propose to annotate the service descriptions with meta-data, such as non-ambiguous concept definitions from shared ontologies –or sometimes simply referred as semantics–, which gave origin to the notion of Semantic Web Services (Paolucci & Sycara, 2003).
There are essential differences between the approaches to service discovery mentioned in last paragraphs. One of the main differences is what such approaches consider/require as service descriptions. For example, semantic approaches depend on shared ontologies and annotated resources, whereas IR-based ones depend on textual descriptions. Scalability, fault tolerance and standard conformance are important aspects of service registries, and of databases in general (Bouguettaya et al., 2004), in which service discovery approaches present differences as well. Therefore, though service discovery systems strive to solve the same problem, they may be very different from each other and one alternative may be appropriate in a particular environment but not in others. The variety of alternatives for discovering Web Services motivates the need for sound criteria to characterize them.