UDDI (Universal Description, Discovery, and Integration) is widely accepted as the standard for Web services publishing, querying, and discovery. A UDDI registry allows you to publish and browse Web service references via SOAP (Simple Object Access Protocol) and HTTP interfaces. The structure of the UDDI specification allows the possibility of private UDDI nodes or a private UDDI registry. A private UDDI node can implement all the UDDI APIs (Inquiry and Publish) as defined by the UDDI specification, but it doesn't participate in the replication scheme, nor does it reside within intranets, extranets, or private networks on the Internet. In this article, I'll show you how to develop a private UDDI registry using the Java API for XML Messaging (JAXM).
UDDI defines the following major data structures, along with two sets of APIs, to publish and discover Web services:
businessEntity: Describes a business or other organization that typically provides Web services
businessService: Describes a collection of related Web services offered by an organization described by a businessEntity
bindingTemplate: Describes the technical information necessary to use a particular Web service
tModel: Describes a "technical model" representing a reusable concept, such as a Web service type, a protocol used by Web services, or a category system
Why JAXM?
JAXM enables applications to send and receive document-oriented XML messages using a pure Java API. JAXM implements SOAP 1.1 with Attachments messaging so developers can focus on building, sending, receiving, and decomposing messages for their applications instead of programming low-level XML communications routines (see "XML Messaging with Jaxm," XML Journal, Vol. 3, issue 3).
Development of a UDDI Registry
This section explains how to develop a private UDDI registry, illustrating a tModel data structure using the following publish and inquiry APIs:
get_authToken: Used to obtain an authentication token. Authentication tokens are opaque values required for all publish API calls; they're optional for inquiry APIs
save_tModel: Used to add or update one or more registered tModel elements
find_tModel: Used for locating a list of tModel entries that match a set of specific criteria
To develop the UDDI registry, follow these steps:
- Analyze the UDDI data structures
- Create the database schema for the data structures
- Develop the servlets for inquiry and publish requests
- Deploy the servlets
- Test the private registry using client applications
Analyze the UDDI Data Structures
UDDI defines the XML schemas for each data structure. The tModel schema is shown in Listing 1 (listings for this article are available for download at www.sys-con.com/webservices/sourcec.cfm).
tModel consists of a key, a name, and optional elements such as URL, categoryBag, and IdentifierBag, and it may have zero or more descriptions.
tModelKey is the unique key for a tModel structure. Service providers pass an empty tModel key while publishing the Web services, and UDDI registries generate a Universal Unique Identifier (UUID) value using one of the UUID algorithms
(www.opennc.org/onlinepubs/9629399/apdxa.htm) and prefix it with a URN qualifier in the format "uuid:", followed by the UUID value. This will be assigned to the tModelKey. Operator is the name of the operator who provides the UDDI registry.
Create the Database Schema for the Data Structures
After analysis of the data structure, one design option is to represent the tModel name and key in one table (as shown below), the tModel descriptions in another table, and categoryBag and identifierBag in different tables.
CREATE TABLE TModel (
tModelKey VARCHAR(255) NOT NULL,
name VARCHAR(255) NOT NULL,
datestamp TIMESTAMP NOT NULL,
authorizedName VARCHAR (255) NOT NULL,
CONSTRAINT PK_TM PRIMARY KEY (tModelKey)
);
Develop the Servlets for Inquiry and Publish Requests
UDDI defines the APIs to publish and discover Web services. Develop the servlets for each type of request, namely InquiryServlet and PublishServlet, in order to process the inquiry (e.g., find_tModel) and publish the APIs (e.g., save_tModel).
PublishServlet
PublishServlet handles the following UDDI requests:
get_AuthToken: Authentication request
save_tModel: Publish request
UDDI_PublishServlet extends the JAXM Servlet and implements the ReqRespListener interface in order to receive and send SOAP messages. This servlet receives a UDDI publish request as a SOAP message and then passes the SOAP message to onMessage () method.
onMessage(SOAPMessage message) is the main entry and exit point for processing the SOAP messages. This method receives the UDDI request as a JAXM SOAP message and returns the SOAP message to the client.
Processing Authentication Requests
The PublishServlet receives the following SOAP message for the get_authToken API:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<get_authToken generic="2.0" xmlns="urn:uddi-org:api_v2"
userID="usename" cred="password" />
</Body>
</Envelope>
Retrieve the body of the SOAP message using JAXM APIs to find the UDDI request (i.e., get_AuthToken, save_tModel, etc.). Find the other elements and attributes required for processing the UDDI API. For instance, get_AuthToken requires user name and credentials to generate the authtoken. Retrieve the user ID and credentials from the SOAP message and generate the authtoken using your own algorithm as explained in the genAuthToken() method shown in Listing 2. Create a SOAP message with authtoken details and send the response to the client as explained in the sendResponse( ) method shown in Listing 2.
The response SOAP message for the get_authToken API looks like the following:
<Envelope xmlns =http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<authToken generic="2.0" operator="'yourcompanyname'
" xmlns="urn:uddi-org:api">
<authInfo>authtokenxyz</authInfo>
</authToken>
</Body>
</Envelope>
Processing Publish Requests
The PublishServlet receives the following SOAP message for save_tModel and passes this message to onMessage() method:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<save_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<authInfo>authtokenxyz</authInfo>
<tModel tModelKey="">
<name>Geography</name>
</tModel>
</save_tModel>
</Body>
</Envelope>
Retrieve and validate the authInfo element. Once the authInfo is valid, retrieve the tModel details, such as name, description, and so on, to save the tModel in the registry.
To save the tModel, construct the SQL query, pass the parameters, and execute the query (see Listing 2).
Create a SOAP response with the generated tModelKey and other details, such as name, operator, and so on, and send the response back to the client. The created SOAP response looks like the following:
<tModelDetail generic="2.0" operator="yourcompanyname"
truncated="false" xmlns="urn:uddi-org:api_v2">
<tModel tModelKey=" uuid:c1acf26d-9672-4404-9de0-39b756e62abc "
operator="yourcompanyname" authorizedName="aravilli">
<name>Geography</name>
</tModelDetail>
InquiryServlet
InquiryServlet handles the inquiry API requests only. It extends the JAXMServlet and implements the ReqRespListener interface to receive and send SOAP messages. It receives a SOAP message then passes it to onMessage () method. The received SOAP message for the find_ tModel is as follows:
<Body>
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<name>Geography</name>
</find_tModel>
</Body>
Retrieve the body of the SOAP message using JAXM APIs to find the UDDI request (it could be find_tModel, find_business, etc.). In this case the request is find_ tModel.
To process the find request, construct the SQL query with find details and execute it to fetch results from the registry (see Listing 3).
Create the tModelDetail response as follows, with the result of the find_tModel query as a SOAP message, and send the response back to the client.
<tModelDetail generic="2.0" operator='yourcompanyname'
truncated="false" xmlns="urn:uddi-org:api_v2">
<tModel tModelKey=" uuid:c1acf26d-9672-4404-9de0-39b756e62abc"
operator='yourcompanyname' authorizedName='aravilli'>
<name>Geography</name>
</tModelDetail>
Deploy the Servlets
Deploy these servlets in any servlet container with URL mappings (/uddi/in quire = InquiryServlet, /uddi/publish = PublishServ let).
Test the Private Registry Using Client Applications
The UDDI registry can be tested with the following:
GUI tools
Client applications: UDDI4J and JAXR
To test the registry, publish various tModels using the publish URL (http:// webserverhost:port/uddi/publish) and discover the tModel using the inquiry URL (http://webserverhost:port/uddi/in quire) using UDDI4J or JAXR library.
Summary
I used the Java servlets, HSQL database, and JAXM client libraries to develop a private UDDI registry. The UDDI specification doesn't dictate implementation details; it defines an XML-based data model and a set of SOAP APIs to access and manipulate that data model. The SOAP APIs define the behavior a UDDI registry must exhibit.
A UDDI implementation can be built using any language or any directory structure, as long as it conforms to the specified behavior.
Resources
Universal Description, Discovery, and Integration:
www.uddi.org
Universal Unique Identifier:
www.opennc.org/onlinepubs/9629399/apdxa.htm
HSQL Database Engine Project:
http://hsqldb.sourceforge.net/
Java: http://java.sun.com
Simple Object Access Protocol 1.1 (SOAP): www.w3.org/TR/SOAP
Java API for XML Messaging: http://java.sun.com/xml/jaxm
Java API for XML Registries: http://java.sun.com/xml/jaxr
UDDI4J: www.uddi4j.org
The new widgetry features multi-cluster suppo...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
