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.
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.
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.
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
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
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
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
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
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.
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.
- 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,
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.