Service Registry with Advanced Search Capability, Part 3: Configurations and controller

Learn how to combine the four core components in a single or multiple applications

In the first installment, part 1, of this series you learned the reasons for needing advanced search capability in a services registry. In the second installment, part 2 of this series, you learned how to implement the four core components of this advanced registry. In this installment, part 3 of this series you will learn the various practical configurations that are possible for combining these four core components either in a single application or multiple applications. You will also learn about a fifth auxiliary component, called controller, which is required for some configurations. In the next installment you will learn how to handle the case of multiple matches in advanced registry.

Dr. Waseem Roshen, Master IT Architect, IBM  

Waseem RoshenDr. 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 62 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.



01 November 2010

Introduction

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.


Controller

There are many reasons for a needing a fifth auxiliary component called the Controller. Some of these reasons are

  1. 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.
  2. 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.
  3. 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.
  4. 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
Controller Schematic

A typical sequence of steps involved in the operation of the Controller function is:

  1. Receive a request from the client application with a service name as the input.
  2. Using Classic Registry component, check if a service description with the exact input name of the service exists in the Classic Registry.
  3. If any exact match is found, return the service information/description to the client application, otherwise go to step 4.
  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.
  5. For each word in the constituent words list, use the Dictionary component to develop a list of synonyms.
  6. Send the lists of synonyms to the Name Composer component and receive a list of equivalent service names.
  7. For each name in the list of equivalent service names, check the Classic Registry for a match.
  8. For the first match that occurs, receive the service description from the Classic Registry.
  9. Return the service description or information to the user of the advanced registry applications.
  10. 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
Configuration 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
Configuration 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
Configuration 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
Configuration 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
Configuration 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
Configuration 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
Configuration 7

Conclusion

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.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=558661
ArticleTitle=Service Registry with Advanced Search Capability, Part 3: Configurations and controller
publish-date=11012010