UEU-co logo

UDDI Registries

Previous Section  < Free Open Study >  Next Section

UDDI Registries

If you intend to deploy a private UDDI registry, you should go through the same evaluation process as you do for your Web services platform. You should always select a product based on your requirements. In this situation, though, there are fewer options to evaluate. As of this writing, there are only 10 product-quality UDDI registries on the market.[3]

[3] By “product-quality,” I mean that a version 1.0 or later is available. I expect SAP to release a product-quality registry in 2003.

Acumen, IBM, Select, and Systinet sell their UDDI registries as separate commercial products. Microsoft includes its registry with Windows Server 2003. Cape Clear, IONA, Oracle, and The Mind Electric bundle their registries with their Web services platforms, and they are not available as separate products. BEA and Pramati include Acumen AUDDI with their respective platforms. Sun provides a UDDI registry as part of JWSDP, although Sun’s license prohibits you from using it for commercial purposes. Two open source registries are available, including Novell Nsure UDDI server (product quality) and jUDDI (not product quality).

Platform Considerations

As with a Web services platform, I suggest you start your selection process based on platform considerations. A UDDI registry server is an infrastructure-level Web service. It is an application that runs within a specific Web services platform on a specific operating system. It manages and provides access to UDDI registry information, which it stores in some type of data storage facility. The registry’s underlying platform influences its performance and scalability. For optimum performance, you want to select a registry based on a fast Web services platform and an industrial-grade database.

Operating System

Most UDDI registries are implemented in Java, and they can run on Windows, Linux, and UNIX. Novell Nsure also runs on NetWare. Two products are limited to Windows: Microsoft’s Enterprise UDDI Services is implemented using .NET and runs only on Windows Server 2003, and Select UDDIServer is implemented using Visual Basic and C++ and runs on all Windows platforms.

Web Services Platform

Acumen, Novell, Select, and Systinet built their products as stand-alone applications. For the most part, you don’t really see the Web services platform if you don’t want to. Systinet gives you the option of deploying WASP UDDI in a wide choice of application servers if you prefer. IBM sells its registry separately from the WebSphere platform, but you must deploy it in WebSphere. Obviously, the embedded registries from Cape Clear, IONA, Oracle, and The Mind Electric are designed to run in their associated Web services platforms.

Data Store

A UDDI registry uses some type of data store to manage and maintain the registry data. Because of the relational nature of the UDDI registry information, most implementations use a relational database management system (RDBMS). IBM requires that you use DB2. Oracle requires that you use Oracle 9i. Microsoft lets you use the Microsoft Data Engine or SQL Server. Cape Clear, jUDDI, and Systinet let you use any JDBC-compatible RDBMS. Select uses an object repository. Sun JWSDP and The Mind Electric GLUE use an XML database. Novell Nsure uses an LDAP directory. IONA can use either Cloudscape or LDAP.

Some folks argue that it makes sense to consolidate UDDI with LDAP because both are directories of resources. But this idea makes about as much sense as storing your HR data in LDAP because they are both directories of employees.

A UDDI registry is much more than a directory. It is a complex, multidimensional index of information about businesses, services, and service types. It contains a tremendous amount of relational information.

LDAP is a hierarchical directory and thus is not especially suited to this relational information. LDAP doesn’t provide some of the basic capabilities that you need to manage relational data, such as multistep transactions, referential integrity, and query joins. You can make LDAP host this information, but I don’t see the point. It’s not as if you are really integrating the information. You still need to use two different programming APIs and two different browsing utilities to see UDDI data versus LDAP data. I see no advantage to consolidating the information.

Some argue that LDAP provides better retrieval performance than a relational database, but this argument doesn’t hold water in this situation. Many UDDI queries involve complex joins, and LDAP doesn’t support joins. The registry application must implement this functionality, and its performance can’t compare to that of a relational database.

I also caution you against overburdening your production LDAP directory with this much relational work. I do think that it’s a good idea to use LDAP (or Active Directory) to manage the security aspects of your UDDI registry and your Web services. For more on this idea, see the section on security later in this chapter.

Standards Support

All the UDDI registries that I’ve mentioned support UDDI V2 or later. I suggest that you not even consider a UDDI V1 registry. The UDDI V2 specifications define two programming APIs (inquiry and publication), an operators specification, and a replication specification. All UDDI registry servers should fully support the UDDI V2 inquiry and publication APIs.

The operators specification defines the behavior and operational parameters required of node operators in the public UDDI Business Registry (UBR). It doesn’t apply to private registries. The replication specification describes the data replication process and programmatic interface used to replicate data across nodes in the UBR. You could use the replication specification to implement a replicated multinode private registry, but there are much more efficient ways to manage a replicated registry. (My first choice would be to use the database replication services supplied by a commercial database system.) You cannot use the replication specification to replicate data from the UBR to a private registry. UDDI V2 does not support this capability. To my knowledge, no private UDDI implementations support replication.

UDDI V3 adds a number of valuable features. In particular, it adds a subscription API, which allows a user (or registry) to subscribe to changes made in a UDDI registry. You can use the subscription API to keep two nodes synchronized. You can also use it to notify service users of any change to a service.

UDDI V3 also allows you to publish information across multiple registries. For example, a binding template in one registry can reference a tModel in another registry. You also can move a registry entry from one registry to another. For example, you can promote a business service from a test registry to a production registry.

Perhaps most important of all, UDDI V3 adds support for security policies. The security architecture permits you to define and enforce policies for authentication, access control, data integrity, publication limits, and more.

As of this writing, only Systinet WASP UDDI supports the UDDI V3 subscription API. Select UDDIServer supports the UDDI V3 inquiry and publish APIs. None of the implementations supports the UDDI V3 cross-registry publishing and security APIs. UDDI V3-compliant products should appear in 2003.

User Interfaces

Applications communicate with a UDDI registry using the UDDI inquiry and publication SOAP APIs. You can construct those SOAP messages using any SOAP implementation, but the UDDI SOAP APIs are fairly complex. Therefore most UDDI registries include a UDDI client programming interface that automatically generates the appropriate UDDI SOAP APIs on behalf of the client. Microsoft and Select provide APIs for COM and .NET clients. The other vendors provide APIs for Java. You’ll also find that many Web services platforms include a UDDI client API. Some vendors provide JAXR-compliant APIs. Most UDDI client APIs are free or open source. Because you can use any UDDI V1 or V2 client API to talk to any UDDI V2 registry, the client API isn’t a particularly important selection factor. Have your developers experiment with the various APIs to see which one they like best.

API Extensions

The only reason you might want to consider the client API is if the vendor provides proprietary extensions to the basic API to improve usability and performance. In all cases, these extensions are optional, so you are never forced to use them. Keep in mind, though, that the extensions work only with the associated UDDI registry. You must make a judgment call as to whether you’re willing to use proprietary extensions in order to take advantage of these features.

Visual Interfaces

Most UDDI registries provide a Web interface to support interactive access to the registry. You can use this interface to query or publish information to the registry. The UDDI browser should let you browse taxonomies. As mentioned earlier, many visual Web services development tools provide UDDI wizards to help developers browse the registry and publish services. These wizards don’t usually come with the UDDI registry, though.

Administration and Management

All registries should provide a set of administrative utilities. The UDDI specification does not define standards for UDDI administration, so each implementation will be unique. These administration utilities should let you manage the UDDI application, its database, and the Web services hosting environment.

Taxonomy Management

Custom taxonomies are a critical part of a private UDDI. You’ll want to develop a number of taxonomies to help you properly categorize your services and service types. Without taxonomies, your UDDI registry is really nothing more than a directory.

A private UDDI registry should give you administration tools to help you manage and maintain your taxonomies. A UDDI registry should let you define custom taxonomies and specify valid values for them. You should be able to maintain the taxonomies either within the registry or in an external taxonomy service. You also need a validation service that can perform validation checks at runtime.


The last area to evaluate in a UDDI registry is its support for security. All UDDI V2.0 registries must support transport-level security. According to the specification, the UDDI inquiry API communicates over HTTP, and the UDDI publication API communicates over HTTPS. If you are operating a private registry, though, you should be able to establish your own transport security policies. For example, you could require HTTPS for the inquiry API.[4]

[4] UDDI V3.0 gives you much more control over registry security options.

Every UDDI registry must also support authentication. The UDDI publication API requires that a user obtain an authentication token before storing any information to the database. The UDDI specification doesn’t mandate any particular mechanism to manage and maintain user information, though, so each implementation uses a different method. For example, Microsoft uses Active Directory, and Novell uses LDAP. Some systems maintain a simple user/password database. There are obvious advantages to a system that supports your existing user account management system.

Authentication gives you only the simplest form of access control. Either users are authorized to access the registry, or they aren’t. It gives you no control over what the user can do. Many registries permit you to assign users to user groups and then to assign privileges to those groups. You can use the groups to establish and enforce coarse-grained control policies. For example, you can say that members of a particular group can register no more than 10 services. Most UDDI registries give you this level of access control for administrative functions and the publication API. Acumen, Oracle, and Select give you more fine-grained control for update functions. These implementations permit you to define update rights by user for every element in the registry.

As of this writing, only two registry implementations provide granular access control facilities that apply to both update and query operations: Novell Nsure and Systinet WASP. These two products give you the ability to define specific access rights, by user or group, for every element in the registry. For example, suppose you want to set up a UDDI registry for your distributor network. You can offer different services to your different distributors based on geographic location, sales volume, or some other criteria. With inquiry-based access control facilities, you can segregate your services automatically. A user from one distributor would be able to find only the services that pertain to that distributor. When selecting a product, consider your access control requirements.

    Previous Section  < Free Open Study >  Next Section
    Tags:  , , ,

    Leave a Reply

    Time limit is exhausted. Please reload the CAPTCHA.


    apply_now Pepperstone Group Limited