Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Build a Client Application to Access a UDDI Registry : Page 5

Now that you've seen how to set up a UDDI registry on your server, it's time to learn how to use it from a client application.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

Testing the Sample Application
The sample application uses a simple driver class called "Test" to illustrate how to obtain an authentication token and how to search for particular businesses:

import org.apache.juddi.datatype.response.AuthToken; import java.util.Enumeration; public class Test { public static void main(String[] args) { Test app = new Test(); } public Test() { GetAuthToken getAuthToken = new GetAuthToken(); AuthToken token = getAuthToken.getToken(); if (token == null) { System.err.println( "Unable to obtain authToken"); return; } FindBusinesses findBusinesses = new FindBusinesses(); Enumeration enum = findBusinesses.find(); while (enum.hasMoreElements()) { org.apache.juddi.datatype.Name businessName = (org.apache.juddi.datatype.Name) enum.nextElement(); System.out.println("Found business: " + businessName.getValue()); } getAuthToken.discardToken(token); } }

Sample Application Test Results
To run the sample application, you will need to:

Figure 1. jUDDI "Happiness" Page: The figure shows the result of running the link The figure shows the result of running the link http://<hostname>:<port>/juddi/happyjuddi.jsp, which displays jUDDI information.
  1. Start the UDDI registry Web application. Refer to the previous article in this series to learn how to start the Web application.
  2. Populate the business_entity database with one record having a publisher_id of "Sun."
  3. Populate the business_name database with one record having a name of "Sun."
With the Web application started, the link http://<hostname>:<port>/juddi/happyjuddi.jsp will reveal a jUDDI happiness page similar to the page in Figure 1.

After starting the UDDI registry Web application and populating it with a business named "Sun," you can run the test application. The resulting output should look like Figure 2.

Identifying and Calling Alternate Services
Figure 2. Sample Application Output: Here's what the sample application's output should look like after starting the UDDI registry Web application and populating it with a single business, named "Sun."
UDDI allows for multiple bindings or URLs to be associated with the actual physical endpoints to Web services, thus allowing you to provide a failover mechanism in the event that your primary service choice is not available. These endpoints are designated in the tModel data structure of a registry entry.

To review, tModel entries represent technical information about a service or services. This information is embodied within interface specifications such as WSDL documents, XSD files, XML files, etc.

You can also use a businessEntity structure for service failover, because that structure represents all known information about a business and the services that it offers. The following example illustrates a typical businessEntity structure:

<element name="businessEntity" type="uddi:businessEntity" /> <complexType name="businessEntity"> <sequence> <element ref="uddi:discoveryURLs" minOccurs="0" /> <element ref="uddi:name" maxOccurs="unbounded" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:contacts" minOccurs="0" /> <element ref="uddi:businessServices" minOccurs="0" /> <element ref="uddi:identifierBag" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="businessKey" type="uddi:businessKey" use="required" /> <attribute name="operator" type="string" use="optional" /> <attribute name="authorizedName" type="string" use="optional" /> </complexType>

The discoveryURLs element of a businessEntity structure is optional. However, this element contains a list of Uniform Resource Locators (URLs) that can point to alternate document-based service discovery mechanisms.

The discoveryURLs structure holds pointers (a list of discoveryURL elements) to URL-addressable discovery documents that you can retrieve via an HTTP/GET method call. Each discoveryURL element holds a 255-character-length string that represents a Web-addressable discovery document.

UDDI automatically assigns each recorded businessEntity structure a URL that returns the individual businessEntity structure. You conduct a URL search via the find_business call.

For example, here's a discoveryURL list for a particular businessEntity:

<discoveryURLs> <discoveryURL useType="businessEntity"> http://www.mycompany?businessKey= BE3D2F08-CEB3-11D3-849F-0050DA1803C0 </discoveryURL> <discoveryURLs>

Finally, because a UDDI registry acts as an abstract layer between Web service clients and each particular Web service, the registry itself inherently provides a framework for failover and redundancy.

Refer to this DevX Special Report article, "Winning with Web Services" for a detailed look at tModels, discoveryURLs, and the find_business message.

The Universal Description, Discovery, and Integration (UDDI) specification and protocol work together to form one of the primary components of a complete Web services infrastructure. By following the steps shown in the article, you can use your private UDDI registry to find businesses, services, and alternate services.

Jeff Hanson has more than 18 years of experience in the software industry. He has worked as senior engineer for the Windows OpenDoc port and as lead architect for the Route 66 framework at Novell. He is currently Chief Architect for eReinsure, which specializes in providing frameworks and platforms for J2EE-based reinsurance systems. Jeff has also authored numerous articles and books.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date