- Quick Review of UDDI
- Inquiry APIs
- UDDI4J APIs
- Establishing Connection
- The Inquiry Process
- Using Discovered Services
- For More Information
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Establishing Connection
Unlike publishing, inquiry is a simpler registry interaction and doesn't require a priori registration with the registry provider. This also means that no authorization token is needed when using inquiry APIs.
UDDI4J provides APIs for discovering resources (services, businesses, and tModels) that satisfy certain criteria. To demonstrate the use of UDDI inquiry APIs, let's consider the 401(k) service ecosystem in the UDDI publishing examples.
This example tests the inquiry URL to discover the uddi-org:inquiry_v2 tModel, using the find_tModel class. (There are several UDDI XML messages for different types of discovery, as discussed later in this article. Here, we focus on establishing connection with the inquiry URL.) A Java program segment used for establishing connection for inquiry might look like this:
// Search for the UDDI V2 Inquiry tModel.
// The tModel name is: uddi-org:inquiry_v2
TModelList tModelList = proxy.find_tModel("uddi-org:inquiry_v2",
null, null, null, 5);
Vector tModelInfoVector =
tModelList.getTModelInfos().getTModelInfoVector();
for (int i = 0; i < tModelInfoVector.size(); i++)
{
TModelInfo tModelInfo =
(TModelInfo)tModelInfoVector.elementAt(i);
// Print information for each tModel
System.out.println("\n\nThe TModel Name: " +
tModelInfo.getNameString());
System.out.println("The TModel Key : " +
tModelInfo.getTModelKey());
}
The UDDIProxy.find_tModel API formats the XML message for locating a list of tModel entries that match a set of specific criteria. This method returns the list of tModels that fit your criteria. This test application then displays the tModel name and key associated with it. A good test would be to match the returned tModel key with the uddi-org:inquiry_v2 key published in the UDDI specification. These two keys should match exactly.
The ecosystem used in the examples consists of two major players:
Prudentially 401(k), Inc., a subsidiary of a global financial services conglomerate
Financial Interactions and Transactions Standardization Organization (FITSO), a not-for-profit consortium of large financial institutions in North America, including pension fund providers
Prudentially specializes in providing pension fund management services to its clients. The company has established a large clientele through the years and is one of the founding members of FITSO.
FITSO publishes relevant business standards for its members. For the pension fund providers, FITSO has identified the classification scheme and a set of interactions that any compliant service provider must support. The classification scheme is provided by the North American Industry Classification System (NAICS). This taxonomy choice translates to using the NAICS tModel pre-loaded in the UDDI registry. The following interactions should be supported by a FITSO pension fund:
Get list of funds.
Get fund performance.
Add employee to a plan.
Get employee contribution data.
FITSO needs to register a tModel corresponding to this interaction specification. This tModel is called TM401k. Based on this requirement, Prudentially 401(k) registration information is as follows:
|
Model |
UDDI Representation |
|
Business |
Entity: Prudentially 401(k), Inc. |
|
Classification |
NAICS |
|
Subclassification |
524292 |
|
Service |
Prudentially401kInformationService |
|
Interface Specification |
TM401k |
The final category of participants in this ecosystem consists of the member companies that use Prudentially 401(k) service for their pension plans. The details on how to publish these entities and their services in a UDDI registry were discussed in part 3 of this series, "UDDI Publishing with Java." Let's see how a customer of Prudentially will use UDDI inquiry APIs to use the 401(k) service effectively.