Discovering a Service Interaction Specification
example working directory: ExamplesEx07FindServiceInterface
example working directory: ExamplesEx08FindService
example working directory: ExamplesEx09FindBusiness
Inquiries to the UDDI registry may be Web browser-based; however, the UDDI registry is designed to support programmatic inquiries as well. Much of the focus on modeling is a result of needing to be able to ensure that resources are easily locatable within the registry. Classifying the business entity and its services appropriately aids service consumers in the discovery process. Had browser-based inquiry been the only supported mechanism, modeling would not be so critical because manual review of the registry would allow the service consumer to locate the service. However, in order for an application to discover a particular service with minimal manual intervention, it is important for a structure to be in place that supports the path to the service(s) desired. The classification and service interaction specifications provide just that structure. Business entities and services are classified within this framework and the inquiry process navigates this structure during the modeling phase described in Chapter 6. Figure 9.1 depicts this framework.
The process of finding a service depends on the information available regarding the type or class of services to be discovered. The UDDI specification provides several APIs to discover various resources registered within the registry. We discuss the following types of queries in this chapter:
Find service interface (tModel)
Find service
Find business entity
Recall from Chapter 8 that many details are published along with the main resource (whether that resource be a service, business entity, or a tModel). Many of these details are searchable, including:
Name
Category key
Unique identifier key
tModel complied with
Parent resource
A service consumer application can be designed to search on any number or combination of these types of details. However, the UDDI registry is designed ideally for use in an ecosystem paradigm. As discussed in Chapter 3, an ecosystem is usually powered by a governing body. This governing body helps to set up the structure that business entities participate in. The most typical scenario that a service consumer application would design for is as follows:
Find all the relevant service interaction specifications
Choose one which seems to suit your needs
Find all the services that comply with that particular service interaction specification
Choose a service that is most suitable
Find the responsible business entities for the discovered services
Figure 9.2 depicts this typical sequence.
It is possible that a service consumer has an existing relationship with a service provider and wants to search for all of its services. In this case, the inquiry process may simply include searching for all services provided by business entity. This sequence is depicted in Figure 9.3.
Financial Interactions and Transactions Standardization Organization (FITSO) is the consortium that mandates use of a service interaction specification for 401(k) services as described in Chapter 8. FITSO is recognized not only for its diligent financial policies but also its use of leading-edge software technologies.
FITSO is a strong consortium with the top tier 401(k) providers in the industry. Because of its adoption of the Web services paradigm, FITSO service consumer applications can query the UDDI registry for pension service providers that are FITSO-compliant. FITSO ensures that its mandates are well-known so that enterprise customers understand how to engage FITSO-compliant pension service providers.
American Corporation, Inc. (ACI) is a company with a sizeable workforce. Having recently decided to offer its employees 401(k) plans, ACI researches the pension fund industry and comes to the conclusion that FITSO compliancy is an important criteria in selection. ACI has determined it will work with only FITSO-compliant 401(k) service providers.
In the next three sections, we explain the electronic inquiry process supported by the UDDI registry and the UDDI-compliant APIs (UDDI .NET SDK and UDDI4J).
In Figure 9.2, we depict a typical inquiry sequence a service consumer would go through. Usually that starts with only knowing that you are looking for services that abide by a certain interaction specification. In this example, ACI is looking for services that comply with the specification TM401k that FITSO published to the UDDI registry. Recall that this specification provides guidance on what features FITSO-compliant 401(k) service providers should include. Both UDDI .NET and UDDI4J provide APIs for constructing a query with a UDDI registry.
The logic for finding a service interaction specification is found in FindSvcIntfForm.cs. Calls made to the inquiry URL are not secured because no authentication is required to interact with it — especially in the case of the UBR we use in the examples. The main configuration that is required is to denote the inquiry URL to communicate with. As in Chapter 8, we use Microsoft’s UBR for the inquiry examples.
FindSvcIntfForm.cs
inquireURL.Items.Add("http://uddi.rte.microsoft.com/inquire"); The class FindTModel is the starting point to find a tModel. It provides several methods to construct queries on the registry to search tModels. Queries can be designed to handle a broad-based search of interaction specifications and classification schemes as well as a more refined search where more information about the interaction specification is known. In our example, the broader case simply uses a wildcard search and searches for characters in the name of the specification tModels published in the registry; whereas the refined search is category-based.
A broad-based search is not always sufficient. One of the goals of XML-based registries is to assist in the electronic decision-making process. Simply doing a wildcard search of this nature would require a manual decision process as to which of the found interaction specifications to continue with. Given no other guidance, a manual decision process would be the only option. Entities such as consortiums and governing bodies should provide more details as to how to reach the exact interaction specification. Ideally, they would provide the following:
Interaction specification name
Classification scheme and details
FITSO provides this information in their specification. Using these guidelines, ACI can refine its search to locate interaction specifications with a specific name and classification type. Recall that in Chapter 8, the TM401k specification was published within the general_keyword taxonomy. The keyword provided was 401k. Using this additional information, the inquiry can be refined. Behind the scenes, a CategoryBag structure is constructed to store the additional information and prepare the appropriate inquiry XML to run on the UDDI registry. The Send method communicates the query to the UDDI registry.
Example . FindSvcIntfForm.cs
//Add category bag conditionally
if (tModelUUIDBox.Text != "")
{
ftm.CategoryBag.Add();
ftm.CategoryBag[0].TModelKey = tModelUUIDBox.Text;
ftm.CategoryBag[0].KeyName = classificationNameBox.Text;
ftm.CategoryBag[0].KeyValue = classificationValueBox.Text;
}
TModelList tml = ftm.Send();
foreach( TModelInfo tmi in tml.TModelInfos )
{
searchResults.Nodes.Add(tmi.Name);
searchResults.Nodes[tml.TModelInfos.IndexOf( tmi )].Tag =
tmi.TModelKey;
} Notice the last portion of code in the preceding code segment. While rendering the Graphical User Interface (GUI) on the screen with the discovered tModel information, it also stores each tModel’s unique identifier key in the Tag attribute. This is a direct link to each of the discovered tModels. Observe that we use the Tag attribute when requesting more details on each tModel. The following code segment uses the unique identifier and the class GetTModelDetail to display the description and overview documents associated with each tModel.
Example . FindSvcIntfForm.cs
private void get_tmodelDetail()
{
// Get tModel details
GetTModelDetail gtmd = new GetTModelDetail();
gtmd.TModelKeys.Add( searchResults.SelectedNode.Tag.ToString());
TModelDetail tmd = gtmd.Send();
... The results can be rendered in a hierarchical Graphical User Interface (GUI) view. The following code makes that possible.
Run the file FindSvcIntf.exe and enter the values pertaining to the tModel you are looking for. In our example, we continue with FITSO’s tModel and search for tModels that satisfy the criteria in Table 9.1.
Table 9.1. FITSO Compliance-Based Prudentially 401(k) Modeling
|
Model |
UDDI representation |
|---|---|
|
tModel Name |
Name includes characters “401k” |
|
Category tModel Key |
Key for general_tModel |
|
Classification Name |
KEYWORD |
|
Classification Value |
401k |
Figure 9.4 displays the results of the broad-based wildcard-based search. Figure 9.5 displays the results of the refined search. Notice that the results are much more in line with what ACI was looking for — i.e., the FITSO tModel.
The file FindSvcIntf.java contains the application logic to find the FITSO tModel using the UDDI4J APIs. All the information pertinent to what is being searched for is located in the property file findTModel.prop.
Example . findTModel.prop
#A partial name string to be used during search. #Note that % is used as a wildcard TMSearchName=%401%k% # Taxonomy to classify. # uddi-org:general_keywords CategoryTModelKey=uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549 ClassificationName=KEYWORD ClassificationValue=401(k)
In the UDDI .NET SDK example, we demonstrated how a simple wildcard search could lead to a chaotic set of results. In this UDDI4J-based example, we simply execute a refined search from the start. The first step to searching the UDDI registry remains similar to the .NET discussion. We need to specify the inquiry URL.
Now we need to construct the query object using the properties in the property file and the UDDI4J APIs. After obtaining the tModel name and category information to search with, the UDDIProxy.find_tModel API generates the appropriate UDDI XML messages and executes the query on the registry via the inquiry URL. Notice that there is an artificial upper limit of 5 placed on the maximum number of returned tModels. The choice of number 5 is completely arbitrary. When developing a real-world solution, other appropriate upper limits, commensurate with expected results, should be specified.
Example . FindSvcIntf.java
String searchName = TMp.getProperty("TMSearchName");
//Add category bag conditionally. Other parameters can be added
// conditionally in a similar manner.
CategoryBag cb = null;
if(TMp.getProperty("CategoryTModelKey") != null);
{
cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(TMp));
}
TModelList tl = proxy.find_tModel(searchName, cb, null,null,5); The find_tModel method returns information on all the tModels that match the search criteria. It is important to note that the default behavior for the find APIs is that the search criteria are logically ANDed; thus, any resource found satisfies all the search criteria. Later in the Section 9.6, we discuss how this behavior can be modified using search qualifiers.
To display the details associated with each tModel, methods like getNameString, getTModelKey, and other such get* methods are used as in the following code section. The method UDDIProxy.get_tModelDetail is used to get more details about the found tModels. Using the vector of these tModel objects, more details such as the description and overview document for each tModel can be found.
Example . FindSvcIntf.java
System.out.println("tModel Name:"+tmi.getNameString());
System.out.println("tModel Key:"+tmi.getTModelKey());
TModelDetail tmd = proxy.get_tModelDetail(tmi.getTModelKey());
Vector tmv = tmd.getTModelVector();
//Get Description and overviewDoc for the tModel
if(tmv.size()>0)
{
TModel tm = (TModel) tmv.elementAt(0);
System.out.println("Default Description: " +
tm.getDefaultDescriptionString());
System.out.println("Overview URL: " +
tm.getOverviewDoc().getOverviewURLString());
} Finding the right tModel and traversing through the details (description, name, overview document) can ensure that the appropriate tModel key is obtained. This tModel key will propagate through the find process to locate a service or set of services that ultimately solves the business problem at hand. In our example, the ultimate goal is to locate the set of FITSO-compliant 401(k) services.
To run the Java example for finding a service interaction specification, use the following command:
C:>java FindSvcIntf FindTModel.prop
When the application is successful, a set of tModels is returned. We show a sample of the results in the following segment:
----------------------------------------------- tModel Name: TM401k tModel Key: uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4 Default Description: tModel defined by FITSO for 401(k) interactions Overview URL: http://www.insideWebServices/FITSO/TM401k.wsdl ----------------------------------------------- tModel Name: TM401k_dotnet tModel Key: uuid:3b7ad07a-ef53-48c0-a1c0-a93ea7a48125 Default Description: tModel defined by FITSO for 401(k) interactions Overview URL: http://www.insideWebServices/FITSO/TM401k.wsdl -----------------------------------------------
The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for finding a tModel in the UDDI registry are as follows:
Request body:
<find_tModel generic="2.0" maxRows="5"
xmlns="urn:uddi-org:api_v2">
<name>%401%k%</name>
<categoryBag>
<keyedReference keyName="KEYWORD" keyValue="401(k)"
tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/>
</categoryBag>
</find_tModel> Response body:
<tModelList generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<tModelInfos>
<tModelInfo
tModelKey="uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4">
<name>TM401k</name>
</tModelInfo>
...
</tModelInfos>
</tModelList> Request body:
<get_tModelDetail generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelKey>
uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4
</tModelKey>
</get_tModelDetail> Response body:
<tModelDetail generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<tModel authorizedName="Inside Webservices"
operator="Microsoft Corporation"
tModelKey="uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4">
<name>TM401k</name>
<description xml:lang="en">
tModel defined by FITSO for 401(k) interactions
</description>
<overviewDoc>
<overviewURL>
http://www.insideWebServices/FITSO/TM401k.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="KEYWORD" keyValue="401(k)"
tModelKey="uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
</categoryBag>
</tModel>
</tModelDetail> After reviewing the results, the FITSO TM401k tmodel key is obtained. In our case, that tModel key is uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4. This key will be different when the reader runs the example.
After obtaining the appropriate tModel key for the service interface specification, we can find the services that comply with that specific tModel. For the sake of explanation, we call this the compliance tModel. In this example, the FITSO TM401(k) tmodel is the compliance tModel. Discovering a service is very similar to the process for discovering a tModel (or even a business). It requires constructing a query with the help of the UDDI .NET SDK and UDDI4J APIs.
FindServiceForm.cs contains the logic for finding a service. Constructing the search query is fairly similar to that of the query for finding a tModel. Note that we now have the compliance tModel key from tModel discovery as discussed previously in this chapter. Using the service name and the compliance tModel key, we can locate one or more of the services that comply with the FITSO tModel.
Example . FindService.cs
FindService fs = new FindService();
fs.Names.Add(serviceNameBox.Text);
if(tModelUUIDBox.Text != "")
{
fs.TModelKeys.Add(tModelUUIDBox.Text);
}
appendToMessageWindow(fs.ToString());
ServiceList sl = fs.Send(); While we have not constructed a query based on the CategoryBag structure as we did for tModels, a similar approach can be used. Queries based on categories would be useful if we were searching for a genre of services rather than a set of services that complied with a specific service interaction specification. Such a capability is very useful in situations where there is no consortium or governing body standards. In such cases, searching for a class of services might help to refine the search to some extent. For example, if FITSO had not defined a service interaction specification, a search could have been constructed to search for services classified under the NAICS classification with the pension fund classification code.
The results of the query return the service name as well as the service identification keys. These keys are useful because they provide direct access to the service for future use. In Chapter 10, we discuss the concept of service reference import and export.
Example . FindService.cs
GetServiceDetail gsd = new GetServiceDetail(); gsd.ServiceKeys.Add(searchResults.SelectedNode.Tag.ToString()); ServiceDetail sd = gsd.Send(); ... TreeNode tn1 = new TreeNode( "Responsible Business" ); GetBusinessDetail gbd = new GetBusinessDetail(); gbd.BusinessKeys.Add(bs.BusinessKey); BusinessDetail bd = gbd.Send(); foreach( BusinessEntity be in bd.BusinessEntities ) tn1.Nodes.Add(be.Names[0].Text);
Additional service details may be obtained for the services that result from the posed query, with the registry using the GetServiceDetail class. Most notable in these details is the business key and the business entity name of the responsible business entity that is returned. Using this business key, it is possible to obtain further information on the business entity that is responsible for the service.
The find service example is the FindService.exe application. Run it to see the we provide two options: name and compliance tModel identification key. Using GUI provided for constructing a query with the UDDI registry. In this example, a blank or very broad range of wildcards for the service name will broaden the search within the compliance category. In this example, we search for any services with 401(k) in the name complying with the compliance tModel key for the FITSO tModel. Figure 9.6 depicts the results of running this search.
Providing a specific name and the compliance tModel key will result in only one service returned. This would be useful if an exact pointer to a specific service is desired as described earlier.
UDDI4J provides APIs similar to the UDDI .NET SDK APIs for discovering a service. The service search parameters are located in the property file, FindSer-vice.prop, as is the case in other examples as well. We search for all services with 401(k) in the name that comply with the FITSO tModel, as can be seen by the property file.
The method UDDIProxy.find_service takes the search parameters and returns the list of matching services. Recall that the default AND behavior can be overridden using search qualifiers, as discussed in Section 9.6.
Example . FindService.java
TModelBag tmb = new TModelBag();
tmb.setTModelKeyVector(createTModelVector(Svcp));
Vector names = new Vector();
names.add(new Name(Svcp.getProperty("ServiceSearchName")));
ServiceList sl = proxy.find_service(null,names,null,tmb,null,5); As was the case in the UDDI .NET example, it is possible to get more details about the services returned using the get* methods. Important among the returned details is the business entity information.
Example . FindService.java
Vector sinfv = sl.getServiceInfos().getServiceInfoVector();
System.out.println("Service Name:"+si.getNameString());
System.out.println("Service Key:"+si.getServiceKey());
BusinessDetail bd =
proxy.get_businessDetail(si.getBusinessKey());
BusinessEntity be =
(BusinessEntity) bd.getBusinessEntityVector().elementAt(0);
System.out.println("Business Name: "+
be.getDefaultNameString()); It is possible to go one step further and also get a binding template associated with the discovered service. This binding template can provide information about the service access point, which can be used to communicate with the service.
To run the Java example for finding a service, use the following command:
C:>java FindService FindService.prop
When the application is successful, a set of services that match the search criteria is returned. We show a sample of the results in the following segment:
----------------------------------------------- Service Name: P401kService_DOTNET Service Key: fcc48a77-8f8c-4bd3-a1d1-17a599648705 Business Name: Prudentially401k, Inc. -----------------------------------------------
The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for finding a service in the UDDI registry are as follows.
Request body:
<find_service generic="2.0" maxRows="5"
xmlns="urn:uddi-org:api_v2">
<name>%401%k%</name>
<tModelBag>
<tModelKey>
uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549
</tModelKey>
</tModelBag>
</find_service> Response body:
<serviceList generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<serviceInfos>
<serviceInfo
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
<name xml:lang="en">
P401kService_DOTNET
</name>
</serviceInfo>
</serviceInfos>
</serviceList> Request body:
<get_businessDetail generic="2.0" xmlns="urn:uddi-org:api_v2">
<businessKey>
954eb479-cdbd-445b-b7a2-de33625ac015
</businessKey>
</get_businessDetail> Response body:
<businessDetail generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<businessEntity authorizedName="Inside Webservices"
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
operator="Microsoft Corporation">
<discoveryURLs>
<discoveryURLuseType="">
http://www.insidewebservices.com/Prudentially401k
</discoveryURL>
...
</discoveryURLs>
<name xml:lang="en">
Prudentially401k, Inc.
</name>
...
<businessServices>
<businessService
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
<name xml:lang="en">
P401kService
</name>
<description xml:lang="en">
401(k) management service by Prudentially401(k), Inc.
abiding by the FITSO TM401k tModel
</description>
<bindingTemplates>
<bindingTemplate
bindingKey="bfacc9f8-c636-4f41-9596-e4e0f8db98ec"
serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
<accessPoint URLType="http">
http://www.insidewebservices.com/Prudentially401k/P401kService
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549"/>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference keyName="KEYWORD" keyValue="401(k)"
tModelKey=
"uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
</categoryBag>
</businessService>
</businessServices>
...
</businessEntity>
</businessDetail> The discovered services can either be used as discussed in Section 9.7 or the responsible business entities can be reviewed to help make the decision on which service to use.
At this point, we have traversed through a complete discovery pattern, where we discovered a tModel based on certain keywords, discovered a set of services that complied with the specific tModel, and obtained more information about the business entity that owned the service.
Another discovery pattern is also possible when a potential service user has an idea about which business entities to work with, e.g., existing partners. In such a situation, the discovery that would happen is in reverse order — i.e., the business entity would be discovered first, followed by the services it offers. In this section, we discuss this discovery pattern. While it is possible to search a business using a variety of criteria, we demonstrate discovery based on a category tModel.
The file FindBusinessForm.cs contains the code for discovering a business entity. The class FindBusiness acts as the central point, where the search criteria are provided. In this example, it includes a taxonomy under which the business entity is classified.
Example . FindBusinessForm.cs
FindBusiness fb = new FindBusiness(); //Add taxonomy KeyedReference kr = new KeyedReference(); kr.TModelKey = tModelUUIDBox.Text; kr.KeyName = classificationNameBox.Text; kr.KeyValue = classificationNumberBox.Text; fb.CategoryBag.Add(kr); ... BusinessList bl = fb.Send();
Once a search is successful, the results are rendered in tree format used in earlier examples in this chapter. Upon clicking on a specific business name, the object GetBusinessDetail gets detailed information about the chosen business entity.
Run the application FindBusinessFile.exe. Recall from Chapter 8 that the business entities were categorized under the NAICS taxonomy with code 524292. Enter the data such as the classification name and code. The tModel for the NAICS classification system is uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2. Click the Find Business button to initiate search. Figure 9.7 shows the successful discovery.
In the UDDI4J APIs, the method UDDIProxy.find_business provides the necessary functionality as used in FindBusiness.java. As with the UDDI .NET SDK example, the search is based on the category in which a business entity is classified. The class KeyedReference is used to populate the category information.
Example . FindBusinessForm.cs
KeyedReference kr = new KeyedReference(
p.getProperty("ClassificationName"),
p.getProperty("ClassificationValue"));
kr.setTModelKey(p.getProperty("TModelKey")); Once the search criteria are prepared, the search can be initiated using the UDDI proxy.
Example . FindBusinessForm.cs
//Search the business on the registry BusinessList bl = proxy.find_business(null, null, null, cb,null,null,5);
A successful discovery returns the business entity information in BusinessList class. A Vector form of this object is used to get information about the business entity such as the company name, primary contact, and phone number.
To run the Java example for finding a business, use the following command:
C:>java FindBusiness FindBusiness.prop
Successful execution will show an output similar to:
----------------------------------------------- Company: Prudentially401k, Inc. Primary contact: John Doe Phone: 212-555-1212 -----------------------------------------------
The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for discovering a business entity to the UDDI registry are as follows:
Request body:
<find_business generic="2.0" maxRows="5"
xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference keyName="Pension fund,
third party administrative services"
keyValue="524292"
tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/>
</categoryBag>
</find_business> Response body:
<businessList generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<businessInfos>
<businessInfo
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015">
<name xml:lang="en">Prudentially401k, Inc.</name>
<description xml:lang="en">Prudentially401k, Inc.
is known for outstanding sevrice to its customers
for their 401(k) needs.
</description>
<serviceInfos>
...
</serviceInfos>
</businessInfo>
</businessInfos>
</businessList> Request body: <get_businessDetail generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessKey> 954eb479-cdbd-445b-b7a2-de33625ac015 </businessKey> </get_businessDetail>
Response body:
<businessDetail generic="2.0" operator="Microsoft Corporation"
truncated="false" xmlns="urn:uddi-org:api_v2">
<businessEntity authorizedName="Inside Webservices"
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
operator="Microsoft Corporation">
<discoveryURLs>
<discoveryURLuseType="">
http://www.insidewebservices.com/Prudentially401k
</discoveryURL>
...
</discoveryURLs>
<name xml:lang="en">
Prudentially401k, Inc.
</name>
<businessServices>
<businessService
businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
<name xml:lang="en">
P401kService
</name>
<description xml:lang="en">
401(k) management service by Prudentially401(k), Inc.
abiding by the FITSO TM401k tModel
</description>
<bindingTemplates>
<bindingTemplate
bindingKey="bfacc9f8-c636-4f41-9596-e4e0f8db98ec"
serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
<accessPoint URLType="http">
http://www.insidewebservices.com/Prudentially401k/P401kService
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549"/>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference keyName="KEYWORD" keyValue="401(k)"
tModelKey=
"uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
</categoryBag>
</businessService>
</businessServices>
</businessEntity>
</businessDetail> The inquiry APIs including those for finding businesses, services, and tModels have a default behavior, described earlier, to execute queries with a ANDed set of search criteria. However, this behavior can be modified using an optional element named findQualifiers. The UDDI specification supports six findQualifier values. Table 9.2 summarizes the various qualifiers and their functions. For a detailed discussion on each of these qualifiers, please refer to the UDDI specification.
Table 9.2. Search Qualifiers for Find and Get APIs
|
Search Qualifiers |
Description |
|---|---|
|
|
Returns only those that exactly match |
|
|
Returns results whose value and case match |
|
|
Sorts results in ascending order by Name attribute |
|
|
Sorts results in descending order by Name attribute |
|
|
Sorts results in by date last updated, returning earliest first |
|
|
Sorts results in by date last updated, returning earliest first |
|
|
Multiple search elements from same namespace are ORed together rather than ANDed |
|
|
Returns results whose value match ANY search criteria |
|
|
Returns a business entity for which the categories of services, contained or referenced within, are also searched for matches |
|
|
Returns a business entity for which only the categories of services, contained or referenced within, are searched for matches |
|
|
Default behavior; returns results that match ALL search criteria |
While these are the built-in search qualifiers, the UDDI specification can be enhanced to support a wider range of search qualifiers. UDDI deployers can add additional search qualifiers they see appropriate for their environment. This is especially useful in a private registry deployment, where specialized searches might be desired. Private registries are discussed in more detail in Chapter 10.
Once the decision is made on which service to use in the Web service solution being developed, an application can be written to interact with the discovered service. Recall from Chapter 8 that, when a service is published to the registry, the service binding is also provided. The service binding provides the service entry point and protocols supported. Using this information, an application can be written to communicate using the appropriate protocol to communicate to the service entry point.
In the UDDI .NET SDK environment, the class GetBindingDetail can be used to retrieve information about the service including the access point for the service using a specific protocol. The method UDDIProxy.get_bindingDetail can be used in UDDI4J for this purpose. Once the access point is retrieved, messages can be exchanged between the user and the application discovering the service. Provided there is domain knowledge built into the application, this process can be done automatically.
We have explained how basic interactions with a UDDI registry can be performed. However, UDDI supports a rich set of advanced interactions that allow UDDI to be incorporated into a sophisticated solution. These solutions are discussed in the next chapter.