If you're looking to deploy a UDDI registry that provides strong standards support, a capable API, and security and management capabilities, look no further than Systinet's WASP UDDI version 4.6. WASP UDDI is a UDDI server that supports UDDI specification versions 1 and 2 as well as the version 3 subscription API. Systinet has also added extensions to the core UDDI specification to provide additional functionality around management, security, inquiries, and other operations. The server can run on top of a number of databases, including Oracle, SQL Server, DB2, PostgreSQL, Sybase, Cloudscape, PointBase, and Hypersonic SQL (included).

Working with UDDI
Along with a full-featured Web interface, Systinet's WASP UDDI provides a rich, open-source client API written in Java that developers may leverage to create applications that interact with the UDDI repository. For this review, I will be focusing on the supplied Java API and exploring various pieces of the UDDI server's functionality.

Publishing and Categorizing Services
Both the Web interface and the Java API for the UDDI registry allow elements to be published to the registry. Out of the box, the UDDI registry is populated with sample data and a set of common taxonomies to support the tutorials and exercises in the documentation and allow services to be classified with existing industry standards. For this review, I'll use a new business entity to store all of the information for this article.

Using the Web interface shown in Figure 1, I've created a new business entity. The entity's profile is divided across the tabs representing various data structures within the UDDI specification. To provide the best possible data for searching, the new entity includes a contact, discovery URLs, and category information taken from the set of prepopulated taxonomies in the UDDI registry. Now that the business entity is available, additional objects will be published via the API interface to the registry.

 

In terms of Web services, publishing information into the WASP UDDI registry is extremely easy. As shown in Listing 1, it takes a mere four lines of code to publish a WSDL document into the registry.

Essentially, the developer provides a WSDL specification located at a particular URL and the business key to which it should be attached. In this example, the business key is the key that was generated when the business entity was added from the Web interface. Behind the scenes, WASP UDDI publishes the WSDL document according to the OASIS Technical Note "Using WSDL in a UDDI Registry, Version 2.0" (www.oasis-open.org/committees/uddi-spec/ doc/tn/uddi-spec-tc-tn-wsdl-v2.htm). The result is a new business service that corresponds to the Service element in the WSDL under the specified business entity, and the Port Type and Binding information created as tModels.

Once information has been published to the UDDI registry, it is easily categorized using either the preconfigured taxonomies or custom taxonomies provided by a server administrator. Custom taxonomies may be added to the registry using the Web interface or the Java API. When working with the Web interface, a taxonomy structure may be defined manually. Alternatively, both the Web interface and the Java API support the upload of a taxonomy structure from an XML file that adheres to a specific Schema definition. Conversely, any taxonomy may be exported to XML for storage or transfer to another registry.

Finding What's Out There
The WASP UDDI server provides inquiry capabilities that adhere to the UDDI version 1 and 2 standards as well as a "SuperInquiry" interface that adds search options to the standard interface. Similar to the WSDL publishing process, it's easy to search a WASP UDDI registry using the Java API. Listing 2 is an example of searching for the service that was published using the previous code example. The result is a ServiceList object from which the binding information may be retrieved.

Systinet also provides a custom API for looking up and invoking Web services that are stored in any UDDI registry adhering to the OASIS Technical Note referenced earlier. The ServiceClient object accepts a specialized URL that locates a Web service in a UDDI registry by its binding key. For example, systinet-uddi:http://localhost:8080/uddi/inquiry?bindingKey=ee2b38a0-0f06-11d8-9ed6-b8a03c50a862. Once a handle to the service has been acquired, it may be executed using a generic WASP proxy or a specialized proxy that was generated from the WSDL using WASP tools.

Debugging Applications
Systinet provides the SoapSpy utility to assist with the debugging process when working with its UDDI registry. SoapSpy acts as a proxy that intercepts incoming requests and forwards them to the registry host. In Figure 2, an instance of SoapSpy has captured the inquiry message of a request to look up the WorkoutService. Messages that have been captured may be modified and re-sent to correct processing errors or perform tests on specific data conditions.

 

Administration and Security
Systinet has provided several administration and security features in the registry. One of the major pieces of administrative functionality is the approval process for new registry data. In this scenario, two UDDI registries are configured: staging and production. The staging repository is the endpoint for new services while the production repository is accessible in a read-only mode and contains only those services that have been approved by an administrator. When a service is published into the staging repository, the developer may mark the information as Ready-for-Approval. Once marked, an approval request is generated and the administrator is notified by e-mail. Once approved by an administrator, the service is automatically published to the production environment.

Security is a major component to the WASP UDDI product. WASP UDDI allows the assignment of users and groups to each UDDI element to control who can search for, retrieve, create, update, or delete any element within the registry. In addition to providing its own internal security mechanism, WASP UDDI may be integrated with LDAP, Microsoft Active Directory, and Kerberos. Access Control Lists within the UDDI registry may be administered from these external systems.

Summary
Systinet's WASP UDDI server is an easy-to-use, full-featured UDDI registry. In addition to providing support for versions 1 and 2, as well as parts of the version 3 UDDI specification, several enhancements have been provided. The Java API is full featured and does an excellent job of hiding the communications details of interacting with the registry. The additional security and administrative functions provide unique management capabilities for the product. Overall, Systinet's WASP UDDI server is a very solid product.

Systinet
Company Info
Systinet Corporation
5 Cambridge Center
8th Floor
Cambridge, MA 02142
Phone: 617 868 2224
Sales: 617 868-2224

Requirements
Supports Java 1.3.x and higher; RedHat Linux 7.1 & 7.2; Debian GNU/Linux, Sun Solaris 2.8; HP-UX; and Windows 2000/XP; all popular databases. Browser support for Internet Explorer 5.0/5.5/6.0,Netscape 7.0, Mozilla, and Opera

Pricing
Free for development and test.
Pricing starts at $10,000 per CPU.

• Source Code