Service Registry with Advanced Search Capability, Part 4: Handling multiple matches

Learn how to manage multiple service names matches in the service registry with advanced search capability

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 the third installment, part 3, of this series you learned about the various practical configurations that are possible for combining these four core components either in a single application or multiple applications. In this last installment, part 4, you will learn how to handle multiple service names matches, which may occur in some rare cases.

Share:

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.



08 March 2011

Introduction

There are many reasons for requiring a service registry to provide advanced search capability so that the user of the registry does not need to know the exact name of the service. Some of these reasons are:

  1. to decouple the development of service provider from that of service consumer
  2. to allow for locale independence and internationalization
  3. to avoid delay in the development of the consumer applications
  4. to promote portability of client applications
  5. to easily support multiple providers for a given service

In previous three installments of this series, a SOA service registry with advanced search capability was described. This advanced search capability allows the user to obtain service description or information even when the exact name of the service is not known. The advanced search capability is obtained by first parsing the input service name into constituent words and then constructing all equivalent service names by replacing one or more constituent words by other words with the same or similar meanings (i.e. synonyms). After constructing equivalent names, the registry is checked again each of the service names to see if there is a match with any of service names registered previously in the registry. If a match is found, the service description including runtime and development service information is returned to the user.


Problem

In almost all cases, the solution described in the three previous installments is sufficient because the end result is a single match as is expected by the client/user application. However, in some rare cases, the end result may be more than one service name match but the client/user application is expecting a single result. In this case the client application may hang for a long time or otherwise encounter a serious problem with the registry.

For example consider an input service name of GetCarPrice, which consists of three constituent words: Get, Car, and Price. Using the synonym replacements, some of the equivalent names that can be constructed are ObtainCarPrice, FetchCarPrice, GetAutomobilePrice, GetVehiclePrice, ObtainAutomobilePrice, FetchAutomoblePrice, etc. Consider the situation where there are two providers of approximately the same service and that they register their two services using slightly different names. For example the two names could be ObtainCarPrice and FetchAutomobilePrice. In this case we will get two matches and the registry will not be able to determine which service description to return to the user or user application. In the absence of a way to determine which of these two service names more closely resemble the input service name, the registry will encounter a serious problem.

In this installment we describe a method and system to overcome the rare problem of multiple matches in a services registry with advanced search capability.


Solution outline

The solution to the problem described above is to provide a ranking system for the constructed service names based on how closely they resemble the input name of the service. This would greatly reduce the problem in the working/running of the client application because the only one (i.e. The one with the highest ranking) of the multiple matches will be returned to the client application . The resemblance is determined by how many words in the constructed name are exactly the same as the words in input service name. For example, if the input service name is GetCarPrice then the constructed name ObtainCarPrice has more resemblance to the input service name then the constructed service name of ObtainVehiclePrice. This is because the constructed name ObtainCarPrice has two of the original words while the constructed name ObtainVehiclePrice has one of the original words.

In this installment we provide such a ranking system for the constructed service names. In this ranking system, the words in the input/original service name are assigned large integers while the synonyms which are not part of the input service name are assigned much smaller integers. The ranking of a constructed name is then obtained by adding the integers corresponding to all the words in that constructed word. The constructed service names are then arranged in a descending order of the ranks. The remaining ambiguity in the ordering is resolved by using alphabetical order. The classical registry component (described in the first installment) is used to find the service name match. For the first name match that is found, service description consisting of development time and runtime information about the service is return to the client application.

Solution details

Here is the method/process for employing the ranking system:

  1. First determine if there is an exact match with the input service name in the registry. If an exact match is found, the service description is returned to the user/user application. If no match is found, go to step 2.
  2. Parse the input service name into constituent words using the Name Parser component. The Name Parser Component is described in the previous three installments.
  3. Assign a large integer to each of the constituent words of the input service name. For example this integer could be 100 for the first constituent word, 101 for the second constituent word and so on.
  4. For each constituent word in the input service name, look up the synonyms in the database.
  5. By default, assign a much smaller integer to all the synonyms. For example this smaller integer could be 0.
  6. Using the synonyms, construct all the equivalent service names using the Name Composer component as described in the previous two patent applications.
  7. Determine the ranking of each constructed equivalent service name by adding all the assigned integers corresponding to the words/synonyms in the constructed name.
  8. Arrange all the constructed service names in a list in the descending order of the ranking determined in step 7. Any remaining ambiguity in the order of names is resolved by arranging names in the alphabetical order.
  9. Starting from the top of the list determine if any of the constructed names matches a name in the Classic Registry. For the first match that is found, return the service description to the user/user application.
  10. If no match is found in step 9, return null to the user/user application.

The following Figure 1 summarizes these steps for easy visual read.

Figure 1. Process Summary
Process Summary

Click to see larger image

Figure 1. Process Summary

Process Summary

Illustrative example

We now provide an illustrative example for the ranking procedure and arrangement of ranked equivalent names.

Consider an input service name of GetCarPrice. The first step is to parse the input service name into constituent words using the Name Parser component. This will results in the following three constituent words: get, car, price. Next we assign large numbers to these constituent words: get (103), car (102), and price(101). The next step is to lookup synonyms of each word. The result of this step is shown in the following Table 1:

Table 1. Results after synonyms lookup
Constituent WordgetCarPrice
Synonym 1ObtainAutomobileCost
Synonym 2FetchVehicleCharge
............

The fourth step is to assign small numbers to each of the synonyms. The results for this step are shown in the following Table 2:

Table 2. Results after assigning ranks to the synonyms
Constituent Wordget(103)Car(102)Price(101)
Synonym 1Obtain(0)Automobile(0)Cost(0)
Synonym 2Fetch(0)Vehicle(0)Charge(0)
............

The next two steps are to construct all the equivalent services using the Name Composer component and the calculate ranks for each constructed service name. The results are shown in the following Table 3:

Table 3. Results of composing names from synonyms and calculating ranks for the constructed names
NameCalculationRank
getCarPrice103+102+101306
getCarCost103+102+0205
getCarCharge103+102+0205
getAutomobilePrice103+0+101204
getVehiclePrice103+0+101204
getAutomobileCost103+0+0103
.........

In one of the last steps, arrange the equivalent service names in the descending order of the ranks. Use alphabetical ordering as a last resort. The results of this ordering are shown in the following Table 4:

Table 4. List of ranked names, arranged in the descending order of ranks
Service NameRanking
getCarPrice306
getCarCharge205
getCarCost205
getAutomobilePrice204
getVehiclePrice204
......

As the last step in the process, use the Classic Registry component to the find the first match for equivalent service name, starting from the top of the list of service names. For the first match that is found, return the service description, which may include development time information and runtime information about the matched service, to the client application. If no match is found, return null to the client application.

Conclusion

In this installment, part 4, of the series you learned how to handle multiple service names matches in a service registry with advanced search capability. This functionality is needed to avoid the rare situations where the client application may hang for a long time because it is expecting, at the most, a single service match. This last installment concludes this series of papers. It is important to know that the method and process to handle multiple matches in service registry with advanced searched capability described here is covered by an IBM pending patent.

Resources

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. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. 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=629061
ArticleTitle=Service Registry with Advanced Search Capability, Part 4: Handling multiple matches
publish-date=03082011