The web services electronic marketplace that UDDI was originally developed to address is looking increasingly far-off, but this emerging technology can still be useful in the near term as a way to help internal developers find and take advantage of far-flung corporate applications in new code.
eWeek Labs tested two recently released Universal, Discovery, Description and Integration directories—Systinet Corp.s WASP (Web Applications and Services Platform) UDDI Standard 3.1 and IBMs WebSphere UDDI Registry 1.1.
Both products work in similar ways and have similar architectures: They take HTTP requests, look up corresponding data in a database and return information. Both implement a user interface for searching and adding UDDI directory entries, as well as a programmatic interface using SOAP (Simple Object Access Protocol) so programs can do the same.
WASP UDDI Standard has a complete set of administration features that will pay off for organizations needing to maintain UDDI directories in production environments.
When we added a new user, for example, the software automatically sent the user an e-mail with a generated link back to the UDDI Standard server, thus confirming the users e-mail address. (Users cannot publish items in the directory until they confirm their identity this way.)
The Systinet product allows directory entries to be transferred from one person to another and supports PublisherAssertions to create links between directory entries.
We would have liked to have a way to search for services directly. UDDI Standard required us to search for businesses in the directory first, and only when businesses were found could we see the services they offered.
The IBM WebSphere UDDI Registrys interface was simpler than WASP UDDI Standards, making quick work of name searches on a business or service. UDDI Registry also allowed us to create a basic business or service with a single click.
One thing that annoyed us about the IBM product was that the software didnt turn service access points into hyperlinks when we viewed a services details. This made it much harder to see if our test Web service was working. We also didnt have the option to browse classification hierarchies when adding a service to a business, although we were able to do this when adding the business itself.
Systinets UDDI Standard works with more products and implements more of the UDDI 2.0 specification than IBMs offering, including advanced features such as PublisherAssertions and checked taxonomies. WebSphere UDDI Registry had only nonclickable text place holders in its user interface to add UDDI 2.0 service aliases, create PublisherAssertions links between businesses and transfer a business between owners.
The Systinet product was also better documented, particularly in terms of programming information and developer tutorials.
However, UDDI Registry was more tightly integrated with the WebSphere application server than UDDI Standard was with the application server it ran on. (We tested UDDI Standard with the Apache Software Foundations Tomcat application server, which is bundled with the Systinet system.) For example, WebSphere UDDI Registry directly integrated into WebSpheres user and group security layer, while WASP UDDI Standard implemented its own security system on top of the application server.
WASP UDDI Standard 3.1 (www. systinet.com/products/wasp_uddi/ index.html) is priced starting at $10,000 per CPU and runs on Windows 2000, Solaris and Linux. In addition to Tomcat, UDDI Standard can be used with BEA Systems Inc.s WebLogic application server. (WebSphere and other application servers are not currently supported.) It can use any of the major databases as its repository.
Systinet is also creating a high-end version of UDDI Standard called WASP UDDI Enterprise, currently in beta. UDDI Enterprise has the same UDDI Version 2.0 registry features as UDDI Standard but adds an expanded set of search features and supports ACLs (access control lists) to limit access to the directory based on user identities.
ACLs are a key feature for private UDDI directories because organizations will need to provide different levels of access to business partners depending on the nature of the business relationship. The everyone-sees-everything model used in public UDDI directories wont work in the private space.
WebSphere UDDI Registry 1.1 (www7b.software.ibm.com/wsdd/downloads/UDDIregistry.html) is tied to the licensing of WebSphere Application Server Advanced Edition 4.0. Companies using this application server can deploy a supported version of UDDI Registry in production. Since UDDI Registry requires WebSphere Advanced Edition 4.0.2 (and DB2 7.2 with FixPack 5), UDDI Registry becomes a free add-on to WebSphere. UDDI Registry runs on Windows NT 4.0, Windows 2000 and Linux.
One important factor when considering using UDDI as part of a Web services infrastructure is that your partners UDDI directories will not necessarily provide Web services information—that is, a WSDL (Web Services Description Language) file.
UDDI service directory entries might point to a Web site with a WSDL file, but they could also point to a page with a simple text description not meant for automatic processing. Entries could also return an e-mail address, a phone number, a fax number or an FTP site address with more information on that service. What the UDDI directory provides is completely up to the creator of the entry.
Organizations should work out protocols ahead of time with internal or external customers so they can interpret returned data correctly.
Other UDDI directory options include the open-source project SOAP UDDI (soapuddi.sourceforge.net) and Hewlett-Packard Co.s Web Services Registry 2.0. Microsoft Corp. plans to include a UDDI server with its Windows .Net Server, slated to ship later this year.
West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ziffdavis.com.
Links to other stories in this package
- Web Directories Dial In
- UDDI 2.0 Provides Ties That Bind
