![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
A service registry is used to publish and discover services. In classic registry one needs to exactly match the name of the service with the name that exists in the registry in order to discover the service. In part 1, you learned many reasons why this restriction of exactly matching names must be removed and therefore there is a need for a registry with advanced search capability so that one does not need to know the exact name of the service in order to find the service in the registry.
In part 2, you learned how to implement the four core components of the advanced registry. These four core components were Classic Registry, Name Parser, Name Composer, and Dictionary. In the present context, the Classic Registry provides for searching for the service metadata if the exact name of the service is known. The Name Parser component parses the input name of the service into constituent words, while the Name Composer component takes as input lists of constituent words and returns a list of equivalent service names. Lastly, Dictionary component provides all the synonyms (words with same or similar meaning) of a given word.
These four core components can be combined in a number of different configurations to provide the advanced search capability. Some of the factors to consider while choosing a particular configuration are: performance and efficiency, maintainability and ease of updates, and whether or not the source code for the Classic Registry component is available for modifications.
The most common situation is when the source code for the Classic Registry component is not available. Instead this component is available as a product. In such a situation, it is essential to introduce an auxiliary component, which provides for interactions between the four core components and an interface for the client of the advanced registry. We call this component a Controller.
We start the discussion by first describing the Controller component and its various functions. Then we describe some of the configurations for developing advanced registry which are possible when the source code of the Classic Registry component is not available for modification and additions. Lastly, we describe some of the configurations which are possible when the source code for the Classic Registry component is available for enhancement and modifications. These later configurations include a configuration which yields the highest performance in terms of efficiency.
There are many reasons for a needing a fifth auxiliary component called the Controller. Some of these reasons are
- In some cases the source code for the Classic Registry and Dictionary components may not be available for additions and modifications. In such cases it would not be possible to develop the advanced search capability without using the fifth component for orchestrating interactions between the four core components.
- In order to provide the advanced search capability there is substantial amount of interactions involved between the four core components. These four core components are Classic Registry, Name Parser, Name Composer, and Dictionary. While it is possible to design and build these components so that they can directly interact with each other, it is somewhat complicated to perform this kind of design and development. In particular, it requires substantial additions to these four core components to allow them to interact properly. Use of the Controller component significantly reduces the complexity in design and development of Advanced Service Registry.
- An additional problem is that even when one is able to develop a service registry with advanced search capability using only four core components, there is a tight coupling between these four core components. This tight coupling will mean that it would be difficult to make changes or additions to these four components once they are developed.
- A related disadvantage of such using only four components is that it will be very difficult to replace an implementation of one or more of these core components with another implementation because of the tight coupling between these four core components.
Thus the primary purpose of this controller will be to orchestrate the interactions between four core components, namely, Classic Registry, Name Parser, Name Composer, and Dictionary. The Controller will also provide for the interaction with the user of the Service Registry with advanced search capability. This user interface can be an API or a web service interface or both. The working of this Controller component, along with the four core components is shown schematically in Figure 1. Actual use of this Controller component in various configurations will be discussed in the later sections.
Figure 1. Schematic representation of the Controller function
A typical sequence of steps involved in the operation of the Controller function is:
- Receive a request from the client application with a service name as the input.
- Using Classic Registry component, check if a service description with the exact input name of the service exists in the Classic Registry.
- If any exact match is found, return the service information/description to the client application, otherwise go to step 4.
- If there is not an exact match for the service input name in the Classic Registry, use the Name Parser component to parse the input service name and construct a list of constituent words.
- For each word in the constituent words list, use the Dictionary component to develop a list of synonyms.
- Send the lists of synonyms to the Name Composer component and receive a list of equivalent service names.
- For each name in the list of equivalent service names, check the Classic Registry for a match.
- For the first match that occurs, receive the service description from the Classic Registry.
- Return the service description or information to the user of the advanced registry applications.
- If no match is found return null to the client application.
Configurations when the source code for classic registry is unavailable
In many cases, the source code for the Classic Registry function is not available for modifications but the Classic Registry function is available as a commercial product. These commercial Classic Registry products typically provide programmatic access to their functionality through APIs as well as Web Services.
Now we describe some of the configurations that are possible for the SOA Service Registry with advanced search capability when Classic Registry source code is not available for modifications and additions, and one has to use the provided APIs or the Web Service interfaces for the Classic Registry products. All the configurations described in this section employ a Controller for orchestrating interaction between other components and to provide a user interface for the advanced registry.
Classic Registry Product and One Other Application
In this configuration, all functions of the advanced Registry, other than Classic Registry are combined in a single application. This single application then contains the Controller component, the Name Parser component, the Name Composer Component, and the Dictionary component as sub-programs. This application then communicates with the Classic Registry product either using the supplied APIs or through available web services. Note the Classic Registry can run on the same machine or a different machine. In addition, to the three core components, the new application also contains the Controller component, which mainly orchestrates the interactions between the core components. Figure 2 shows this option.
Figure 2. Configuration Number 1
Classic Registry Product and Two Other Applications
This configuration is similar to the last configuration, except that Dictionary function is separated out as second application. This configuration allows for the Dictionary component to run on a separate machine and is suitable when the size of the Dictionary is large which may be case for industry specific dictionary or a very general dictionary. One possible embodiment of this configuration is shown in Figure 3.
Figure 3. Configuration Number 2
Classic Registry Product and Three Other Applications
Another configuration which is theoretically possible consists of Classic Registry product and three other applications. In this configuration, the Dictionary forms one application, the Controller forms another application and the Name Parser and Name Composer components are combined as a third application. The Classic Registry and the three other applications can communicate by employing web services, or messaging. This configuration is shown in Figure 4.
Figure 4. Configuration Number 3
Configurations When the Source code for Classic Registry Is Available
In this section we describe configurations which are suitable when the source code for the Classic Registry function is available for modifications. These configurations include a configuration which yields the most performing SOA service Registry with advanced search capability.
Single Unified Application (Without the Controller)
In this option there is only a single application (i.e. computer program), in which various components are integrated as sub-programs as shown schematically in the Figure 5 below. This is one of the two the most efficient realizations of the system of a registry with advanced search capability. It is suitable when the source code of the Classic Registry core component is available because this option requires significant modifications to the Classic Registry code. These modifications include adding orchestration functionality which will allow the modified Classic Registry code to orchestrate the required interactions between it and remaining three core components. In addition, these modifications include changing the user interface of the Classic Registry so that it can serve as the user interface for the advanced search function also.
Figure 5. Configuration Number 4
Single Unified Application (With the Controller)
This option is similar to the last option in that all the components are integrated as sub-programs in a single application. This second option is shown schematically in Figure 6. In this option, a fifth component, called the Controller, is added for performing interaction orchestration between the four core components and to provide user interface with an external client. The use of this Controller component can significantly simplify the development and maintenance, by reducing the changes required in the Classic Registry function, and therefore reduces development and maintenance time and efforts.
Figure 6. Configuration Number 5
Dictionary As a Separate Application (Without the Controller)
This configuration is suitable when the Dictionary function either pre-exits as a separate computer program or the Dictionary is large (for example a general dictionary or industry specific dictionary). All other functions of the advanced registry are combined in a second application (computer program). These two computer programs communicate with each other either through a messaging system or through a web service. These two applications can either run on the same computer or, as is likely because of the size of the Dictionary application, to run on two separate machines. This configuration still requires access to the Classic Registry source code, since this source code must be integrated with source code for the Name Parser component and Name Composer Component. This option is shown schematically in Figure 7.
Figure 7. Configuration Number 6
Dictionary As a Separate Application (With a Controller)
This option is similar to the last option except the orchestration function is performed by the Controller subprogram. The Controller subprogram also contains the user interface to interact with the client software. Figure 8 shows, in a schematic manner, this option.
Figure 8. Configuration Number 7
In this installment you learned about the various configurations for combining the four core component into a single or multiple applications. In addition, you learned about the fifth auxiliary component, called Controller, which can accelerate the development of a service registry with advanced search capability as well as provide ease of maintainability. It is important to note that the configurations and controller described in this installment are covered in IBM two pending patents. In the last installment, part 4 of this series, you will learn about a method/system which the advanced service registry can use to handle the case of multiple service name matches.
Learn
- A recent book :
"SOA-Based Enterprise Integration"
is an excellent source for a step-by-step approach to SOA and Web Services.
- 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
- Check out
developerWorks
blogs and
get involved in the
developerWorks community.
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.
Table of contents
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
