Introduction

Service Registry is an important component of Service-Oriented Architecture (SOA). Registry is used to publish new services and to discover existing services. The information that can be published and discovered includes service interface information as well as specific service implementation information such as the address (URL) of the specific implementation. Service interface information includes signatures of the various operations of the service, the message type such as SOAP, and the communication protocol such as HTTP.

Universal Description and Discovery Integration (UDDI) is an industry standard on which a Registry can be based as it describes standards for publishing and discovering services. In addition to other facilities, UDDI includes two APIs for publishing and discovering service information. In this article our focus is on the discovery function of the Registry. The discovery API provided by the UDDI includes methods like getServiceDetails, which returns details of the service interface and implementation with the input of a service ID.

However, unlike other Web services standards such as XML, WSDL, and SOAP, UDDI has not been adopted as widely in the industry. This is mostly because the APIs included in the UDDI have been found to be too cumbersome to use. In particular, IBM has adopted a different path. IBMs registry product, WebSphere Registry and Repository (WSRR), does not use the UDDI APIs for publishing and discovery of services. Instead WSRR employs XPath expressions for finding the services which have previously been published. The XPath inquiry takes as input the service name. An example of the XPath is shown in Listing 1. The XPath inquiry in Listing 1 is used for finding the service description of a service named TickerService.

/WSRR/WSDLService[@name='TickerService'] 

Back to top

Need for advanced search capability

In both of these approaches (UDDI and WSRR) the name or the ID of the service used in the inquiry (or search) as input must exactly match the name or ID of the service in the service registry. It is highly desirable that this restriction should be relaxed for the following reasons:

• A goal of the Web services and service oriented architecture (SOA) is to decouple as much as is possible the services provider with the service consumer. For the development time binding, the service consumer is usually a programmer/developer writing a client application while a service provider is another programmer/developer who develops a service. Since the consumer programmer/developer can only discover a service description (including service interface and details of specific implementation) through a registry, if he/she knows the exact name or key, he/she usually would need to have a direct/indirect communication with the provider programmer/developer, thus forcing a strong coupling between the service provider and the service consumer developers.
• One possible way to address the issue is for the service consumer programmer/developer to try to guess the name of the service. However, guessing the exact name or key of a service with out a direct communication with the service provider is made difficult by the fact that the word usage is different in different locations. For example, the word elevator commonly used in the US, is replaced by the word lift in the UK. In addition, even within the same locale, different words with the same meaning can be used alternatively. For example, for the commonly used word get one can also use the word fetch or the word obtain. Similarly, instead of the commonly used word car, one can also use the word , automobile or the word vehicle.
• The inability to guess the name or key, and therefore to discover the service definition, usually means that the service consumer programmer cannot incorporate the service in his/her code until the service provider programmer completes his/her work on the service and informs directly or indirectly the programmer for client side on the specific name or key he/she has chosen for the service to register the service into a registry. This will usually result in delay of the development of consumer or client applications for a given service.
• The ability to discover a service definition without knowing the exact name or key will also promote portability of the client or consumer applications. As an illustration, consider car dealerships of different brands such as GM, Ford, Toyota, Mazda, etc. Suppose each of these brands develops a service to get the price of a car. Each of them names this same service in an obvious manner but slightly differently, using names like getCarPrice, getVehiclePrice, getAutomobilePrice, obtainCarPrice, etc. These different names for essentially the same service means that separate consumer applications would be needed for each of the brand name dealerships using the present registries. However, if the registry is able to recognize that all of these names refer to the same service, it would be able to return the service definition, even though the name in the registry and the client application do not match exactly, thus only one consumer application need be developed with any one of the obvious names and it will be able to serve all the brand dealership.
• It is also important to realize that, in regard to inquiry for the runtime service information such as IP address and port number, there may be multiple service provider for a given service. Each of these service provider may name the same service slightly differently. In this case the ability to discover the service without knowing the exact name of the service will come in handy

Back to top

Method and process

Having convinced ourselves for the need for a service registry with advanced search capability so that it can recognize similar names of a given service; we now describe the method which can be used to allow a registry such a capability.

The method involves first disassembling the input service name into its constituent words using a parser component. For example the parser would disassemble the service name getCarPrice into individual words (get, Car, and Price). Next the registry uses a dictionary component (internal or external) to construct lists of synonyms for each constituent word. For the above example, three lists of synonyms would be constructed corresponding to the words get, car, and price. Corresponding to the word get the synonyms list may consist of the words get, obtain, and fetch. Similarly, corresponding to the car the synonyms list would consists of the words car, automobile, and vehicle. After constructing synonyms list, a service name composer component is employed to put these words together in the proper order to obtain all possible names of the service. In the case of the above example, these names will include getCarPrice, obtainCarPrice, fetchCarPrice, getAutomobilePrice, obtainAutomobilePrice, and fetchAutomobilePrice. As a next step, each composed service name is checked for a match in the service registry. If any one of the names matches a name in the registry, the description of that service is returned to the user, even though the service name does not match the original name supplied by the user of the registry. The process details of this method for an advanced registry system are shown in Figure 1.

Back to top

Required components

The process shown in Figure 1 requires four basic software components for the advanced registry system. These four components and their interactions are summarized in Figure 2.

The following are brief descriptions of the functions of each of these components:

Classic Registry

This component provides three functions (1) Publication of new services. This publication is equivalent to the entry of a new book in the library catalog at the time of arrival. (2) Searching for a service for a given name or id (3) Management of services after they are deployed. In the present context, the searching by name capability is the most important functionality that we going to use. In other words, the classic registry takes the name as an input and returns as output the description and other characteristics of a service, if a service by that exact name exists in the registry. In other words if a service by that exact name has been previously published in the registry. The WSSR currently has this functionality built-in.

Name parser

This component takes as input the name of service, which is usually composed of several words, and returns a list of words that constitute that name. For example, if the input name is getCarPrice, the output would be list containing the words get, car, and price.

Name composer

This component provides a functionality, which is the reverse that of a name parser component. It takes as input a list of words and combines them in proper order to provide a possible service name. For example, the input could be a list containing the words get, car, and price. Then the output would be the possible service name of getCarPrice.

Dictionary

Dictionary, in the present context, is a component which takes as input a word. The output of the dictionary is list of words which have same or similar meaning to the original word. As an example, if the input is the word get, then the output would be a list containing the words get, fetch, and obtain.

Back to top

Conclusion

You have learned the reasons why an advanced search capability in a SOA registry is needed. In particular, we want a SOA registry which can recognize simialr names of the services and then to return service's development and runtime information to the user even when the there is not an exact match for the service names in the registry. In addition, you learned the process which will be required to implement such advanced capability. Lastly, you learned about the four software components that we be needed. In the next installment, part II of this series you will learn how to implement these four components.

Resources

Learn

• A recent book : "SOA-Based Enterprise Integration" is an excellent source for a step-by-step approach to SOA and Web Services.
  
  
• "Services-based integration patterns made easy, Part 4: Enterprise Service Bus" (developerWorks, Dec 2008).
  
  
• In the SOA and Web Services area on developerWorks, you will find articles, tutorials, standards, and other technical resources for web services and SOA.
  
  
• Visit OASIS organization, for information on UDDI
  
  
• Learn UDDI by going through the UDDI Tutorial,
  
  
• A good source of information on WSRR is the IBM red book: WSRR Handbook,
  
  
• For more information on WSRR, visit WSRR Info Center,
  
  
• To learn the main ideas and functionalities of WSSR, read the developerworks paper: WSRR Main Concepts and Capabilities,
  
  
• Play in the: IBM SOA Sandbox,Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web Site, offers an overview of SOA and how IBM can help you get there.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Dr. Waseem Roshen has a PhD from The Ohio State University, Columbus, Ohio (USA) and has over 18 years of practical experience in the Information Technology (IT) field. Currently Dr. Roshen works as an IT Architect in the Enterprise Architecture and Technology Center of Excellence at the IBM Corporation. He has extensive experience with distributed computing, including Service-oriented Architecture (SOA). In addition, he has expertise in custom development, integration architecture and J2EE (now known as JEE). His currents interests include SOA and web services, Quantum Computers, and Cloud Computing. Dr. Roshen has over 60 publications and 37 patents and is a member of IEEE and the IEEE Computer Society. He is the sole author of the book: SOA-Based Enterprise Integration: A step-by-step guide to services-based application integration.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Need for advanced search capability
• Method and process
• Required components
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers