Service Registry: A Key Piece for Enhancing Reuse in SOA
Juan Pablo García-González
Dr. Claus Pahl
Summary: one of the promises of adopting a service-oriented approach in organizations is the potential cost savings that result from the reuse of existing services. A service registry is one of the fundamental pieces of service- oriented architecture (SOA) for achieving reuse. It refers to a place in which service providers can impart information about their offered services and potential clients can search for services. In this article, we provide advice for implementing an enterprise-wide service registry. We also discuss open issues in industry and academia that affect the management of service- repository information.
The reuse of services greatly depends on the ability to describe and publish the offered functionality of the services to potential consumers (clients). A service registry allows you to organize information about services and provide facilities to publish and discover services. Universal Description Discovery and Integration (UDDI) and the Web Services Description Language (WSDL)—together with SOAP— are standards for describing services and their providers, as well as how services can be consumed:
Figure 1 illustrates some relationships between a WSDL service description and information that is stored in a UDDI service registry.
Figure 1. Relationships between WSDL and UDDI (Click on the picture for a larger image)
Originally, UDDI was conceived to cover both publicly exposed services and services that were available within an organization. Currently, most existing implementations are internal to organizations. Service publication, discovery, and (finally) reuse of services is more complicated in an inter-organizational scenario; for example, additional legal and commercial agreements are often needed among parties.
Dedicated (public) UDDI service registries were criticized for their limitations (among other reasons) during service inquiry/ discovery. Recently, however, Web search engines—which could be crawling publicly available WSDL documents—have raised promising expectations for discovering publicly available services.
Designing an Enterprise Service Repository
This section proposes some design guidelines to develop an enhanced enterprise service repository. The focus is on improving the reuse of services over time in different IT projects. The aim is to increase service visibility to domain experts (often, this refers to a business-analyst role) and enhance service descriptions with practical information for architects. Business analysts, who have a less technical background but strong knowledge of the business domain, are frequently the early designers of new initiatives for incorporating or modifying the software support at companies; they play a key role with regard to the reuse of services.
Enterprise service–based solutions involve different types of service. Following the separation of concerns that is addressed by the service-virtualization pattern, services can act as an intermediate layer between the client and provider applications of the services. The virtualization pattern focuses on the abstraction of technical details—such as service-endpoint location, policy enforcement, service versioning, and dynamic service-management information from service consumers— which access an intermediate service level. Technical concerns are managed at an implementation level, at which the actual business logic is implemented.
Based on SOA initiatives in several companies, we can identify three types of service:
Figure 2 illustrates the main static relations among elements of an enterprise service–based solution, as well as their relationship to elements from the virtualization pattern. A service registry organizes the description of the three different types of service and their relationships. Client and provider applications interchange messages that are mediated by BS, BSE, and AS. The service registry manages (at the configuration level) the information that relates the different types of service. The information is persisted in a service repository and used at runtime by a BS to answer client requests.
Figure 2. Service-based architecture and its relation to virtualization-pattern roles (Click on the picture for a larger image)
Let us consider a simplified BS that is used for calculating the total sales that are related to the life-insurance and group-insurance products of an insurance company. The total sales that are associated with life-insurance products are obtained from a life-insurance legacy application. Analogously, the total sales that are associated with group-insurance products are obtained from the group-insurance legacy application. Each legacy application exposes an AS (lifeInsurance and groupInsurance, respectively) that provides the total sales for each type of insurance product. A BS receives requests from clients who are asking for the total sales; afterwards, it calls the service registry that has the information that is required to enforce specific policies on messages and dependencies to an AS and a BSE.
A BSE operates on the answers of an AS and provides a single answer to the BS that contains the total sales of the company. The BS, in turn, delivers this response to the client application.
Figure 3 illustrates the described interaction.
Figure 3. Main interaction among elements of the service-based solution from Example 1 (Click on the picture for a larger image)
Enterprise Service Registry
The enterprise service registry (ESR) is a core element that organizes service information and supports the interaction among enterprise applications that provide and consume services.
Basic functionalities of an UDDI-based ESR can be enhanced by using:
A service repository persists the information and documentation that are logically managed by the service registry. Figure 4 illustrates the main information that is organized in an ESR, persisted in a service repository, and provided to end users through a Web-based user interface.
Figure 4. Enterprise service registry (ESR) (Click on the picture for a larger image)
Services descriptions are core to the service registry. They determine how services can be discovered and subsequently reused:
Table 1 describes in more detail the information that is managed by the service registry:
Table 1. Main service information at the ESR (Click on the picture for a larger image)
Using the Enterprise Service Registry to Improve Reuse of Services
Based on our experience in a range of projects, providing simple descriptions about a BS, facilitating its access, and managing services dependencies have been key to improve reuse. For this purpose, an ESR was a core element.
Among the lessons that were learned from different projects, we can emphasize the following:
Open Issues in Industry and Academia
This section discusses a number of observations in industry and academia with regard to enhanced service descriptions, organization of service information in a service registry, and the role of such a registry to enhance the reuse of services.
Strategies for Organizing and Finding Services in Registries
If service information in an enterprise service registry is difficult to distinguish because of inadequate organization or ineffective search mechanisms, the value of that registry is reduced.
Services categorization can help to distinguish services and classify them according to one or more categories. UDDI registries support this through the tModel. The categorization schemas of UDDI refer to taxonomic classifications. Taxonomies organize concepts in a hierarchical structure; multiple taxonomies can apply to a single UDDI entity. Standard classification schemas are suggested, such as the United Nations Standard Products and Services Code (UNSPSC); however, other standards or internally created taxonomies can also be used. The UDDI Inquiry API supports different forms of query, such as browse pattern, drill-down pattern, and invocation pattern. Queries can refer directly to services, as well as to service categories.
Similarly to a Web search engine, the browse pattern allows one to find registry elements by matching keywords. Although this mechanism automates part of a service search, the results are limited to the coding system’s value set and direct value matching. Services whose description includes similar or related concepts, but different syntax, cannot be retrieved by using this approach. Also, during use of different categorization schemas, the management of overlapping categories can become expensive. Taxonomy maintenance is an added load that must be considered during the implementation of a service registry. Classification schemas that are not updated can affect the quality of the discovery results.
The semantic research community has proposed alternatives to enrich service descriptions semantically and enhance classification schemas in services registries. Basic taxonomies can be enriched or replaced by ontologies. Ontologies structure concepts within a domain and define their meaning. Axioms constrain possible interpretations of concepts and reasoning mechanisms that support inferences from existing data.
According to Küster et al., although semantic enrichment of services descriptions can improve service discovery, several issues still must be addressed, such as reducing the computational cost of reasoning, maintaining the ontologies, and refining search results to improve effectiveness.
Impact of Service Versioning on Service Registries
When a service has been implemented, changes can occur—from the implementation itself to parts of the service description in a service repository. Changes might aim to improve reuse:
Often, new service versions are replications of a previous version that have additional or modified elements. New versions are named differently (by using some naming convention), and their description is stored in the registry as a new entry. Juric et al. propose extensions to WSDL and UDDI for service versioning. The approach addresses run-time and development-time versioning. Efficiency at the code level is addressed by allowing multiple versions of a service to refer to the same codebase. Additionally, notifications about new and deprecated versions are communicated to consumers. Traceability support is provided to track changes. This academic research promotes the reuse of services and keeps the complexity of a service registry manageable.
Service-Usage Information for Enhancing Service Description and Discovery
The history of service usage can be an interesting source of information—not only to re-create the actual behavior, but also for service discovery. Stored service usage–history (logs) can help to categorize services according to the user or how services have behaved over time. Let us consider a service description that indicates a specific performance level in its contract; however, the actual measured performance in a given timeframe (extracted from logs) is lower. This information could be used during service discovery; a service that had lower-than-expected performance levels would be discarded from the search.
Statistically extracted information about how services behave against historic interactions can help to build less biased rankings and make service discovery more precise; however, an infrastructure for the constant monitoring of services and storing of the history information must be provided. Based on the service history, probabilities can be assigned to quantify uncertainty. Clark et al. consider uncertainty with regard to the configuration of a service- based system, the rate parameters of system components, and the duration of events. An uncertainty model is used to predict system performance under increased demand. This type of analysis is fundamental when one is dimensioning the service support infrastructure. Historical data about individual services helps to predict the performance of an entire system.
Offer and demand in an inter- organizational scenario are subject to how much parties trust one another. “Trust in others” is one of several criteria for assigning reputation—witness reputation —to publicly available services. If company X knows that a service is being used or was positively rated for company Y, whom X trusts, the reputation of that service would increase from the point of view of X. One associated problem is the eventual bias for positive ratings, unfair ratings, and the variations of quality between ratings.
Sufficiency of WSDL Descriptions to Find Services for Composition Efficiently
Services are reused not only by client applications, but also by other services in a service composition. A service composition can provide a more coarse-grained functionality and be closer to a business need. One problem when finding a service (useful in a service composition) is the need to verify if the services that are involved are able to “talk” to one another—that is, if the associated message-interchange protocol among them is compatible. A basic requirement for compatibility is deadlock-freeness. Moreover, the message syntax and semantics should be compatible.
Figure 5 illustrates a typical example of incompatibility at the protocol level between two parties. In the figure, a Buyer party offers a buyProduct service, and a Seller party offers a sellProduct service.
Figure 5. Example of incompatibility at protocol level between two parties (Click on the picture for a larger image)
To automate a hypothetical sale process, the message-interchange protocol between buyProduct and sellProduct should be compatible. However, Figure 5 illustrates that the Seller expects a payment before sending the product, and the Buyer expects the product before sending the payment.
When more and more services are offered and advertised in repositories, there are more chances of satisfying a service demand by composing existing services. However, mediation at the protocol level might be required. Matchmaking conflicts at the message and/or conversation level(s) can be solved—to a certain degree— by a mediator component.,  However, verifying and solving compatibility among services at the behavioral level is expensive; it involves the (expensive) exploration of possible states of the services during interaction. To increase reuse here, we need efficient mechanisms for finding compatible services.
For instance, instead of directly publishing the behavior of a service in a repository, a provider can publish a “summarized description” of the expected behavior of all compatible services to service (compatibility refers to deadlock-freeness). The “summarized description” is called an “operating guideline”and allows the hiding of implementation details, while exposing enough information to find compatible partners. Checking if a service can be composed with others is reduced to checking if a graph-based representation of the potential partner is a subgraph of the “operating guideline,” which is less expensive than exploring all possible states of the services.
To improve the reuse of services at the enterprise level, architects must define a strategy for publishing and providing facilities to access services information. For this purpose, an enterprise service registry is a key piece. Information about services can be organized at the registry, and basic functionality can be enhanced—including, for instance, functionality for service versioning, management of service dependencies, and enforcement of runtime policy. In this article, we have provided some design guidelines for enhancing an enterprise service registry to improve the reuse of enterprise services. We have also discussed some open issues in industry and academia with regard to the design and implementation of service registries and associated aspects that are required to describe and organize services information.
About the Authors
Juan Pablo García-González is a senior software developer and chief architect at DATCO Chile S.A. He has been involved in numerous software projects involving service-based solutions. In addition to their regular projects, he and his team are working on the creation of innovative service-centric mobile solutions for the banking industry.
Veronica Gacitua-Decar is a postgraduate researcher at the School of Computing, Dublin City University, and Lero - the Irish Software Engineering Research Centre. Her research is focused on the development of tools and methods for designing process-centric service architectures. Previously, she worked as an IT architect in a large mining company.
Dr. Claus Pahl is a senior lecturer at the School of Computing, Dublin City University, where he is leader of the Software and Systems Engineering group. He is also involved in Lero - the Irish Software Engineering Research Centre, as well as the Centre for Next Generation Location (CNGL).
Issue 21 Index