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.

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.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

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

Dr. Waseem Roshen (waroshen@us.ibm.com), IT Architect, IBM　　

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.

Summary: 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.

View more content in this series

Date: 08 Mar 2011
Level: Intermediate
PDF: A4 and Letter (397KB | 9 pages)Get Adobe® Reader®

Activity: 18820 views
Comments:

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:

to decouple the development of service provider from that of service consumer
to allow for locale independence and internationalization
to avoid delay in the development of the consumer applications
to promote portability of client applications
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:

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.
Parse the input service name into constituent words using the Name Parser component. The Name Parser Component is described in the previous three installments.
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.
For each constituent word in the input service name, look up the synonyms in the database.
By default, assign a much smaller integer to all the synonyms. For example this smaller integer could be 0.
Using the synonyms, construct all the equivalent service names using the Name Composer component as described in the previous two patent applications.
Determine the ranking of each constructed equivalent service name by adding all the assigned integers corresponding to the words/synonyms in the constructed name.
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.
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.
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

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 Word	get	Car	Price
Synonym 1	Obtain	Automobile	Cost
Synonym 2	Fetch	Vehicle	Charge
...	...	...	...

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 Word	get(103)	Car(102)	Price(101)
Synonym 1	Obtain(0)	Automobile(0)	Cost(0)
Synonym 2	Fetch(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

Name	Calculation	Rank
getCarPrice	103+102+101	306
getCarCost	103+102+0	205
getCarCharge	103+102+0	205
getAutomobilePrice	103+0+101	204
getVehiclePrice	103+0+101	204
getAutomobileCost	103+0+0	103
...	...	...

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 Name	Ranking
getCarPrice	306
getCarCharge	205
getCarCost	205
getAutomobilePrice	204
getVehiclePrice	204
...	...

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

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,

About the author

Close [x]

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.

Close [x]

Report abuse help

Report abuse

Report abuse submission failed. Please try again later.

Close [x]

developerWorks: Sign in

All information submitted is secure.

Close [x]

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.

All information submitted is secure.

Rate this article

Comments

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

Introduction
Problem
Solution outline
Solution details
Illustrative example
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.