Universal Description, Discovery, and Integration (UDDI) registries were designed to be dynamic, rather than static. A static UDDI registry would be no more compelling than an installation CD-ROM. If a registry's contents are dynamic, then people and applications using that registry will want to know when changes are available. With UDDI 3.0, client computers and applications can subscribe to a UDDI registry and receive notification—either through email or a Web service—of registry changes or updates as the changes occur. For example, subscribers would be notified when new businesses or services are added to a UDDI registry, or could learn about changes to existing businesses and services (including whether they disappear from the registry). Someone running a private UDDI registry could subscribe to a public registry to learn about changes to the public registry, then replicate the changes to the private registry. A portal to several registries could subscribe to those registries to keep the portal's subscribers informed about new developments.
In other words, subscription can be a handy capability. The UDDI 3.0 specification outlines how subscription services can work and describes the structures that must be in place to support them. Subscribers aren't required to subscribe to an entire registry but can choose among the businesses, services, technical descriptions, or related businesses that the registry contains. If a subscriber owns a business that a registry contains, the subscriber can be notified of changes or additions to "publisher assertions," a UDDI feature that links business entities in a registry by relationship. Subscribers to a registry typically are authorized clients for the node that houses the registry. Therefore, subscribers typically must authenticate with the node before saving subscription requests. Individual nodes, including those in the UDDI Business Registry, can establish subscription policies (e.g., supporting only a subset of subscription APIs, thus limiting the power of the subscription; charging for subscriptions; requiring authentication to subscribe).
UDDI 3.0 supports two kinds of subscription. Asynchronous subscription informs subscribers of registry changes either through email or a separate Web service called a "subscription listener." Because registries can change frequently, asynchronous subscription notifies subscribers of changes not when the changes happen but at intervals that the subscriber specifies. (However, a registry's manager can set a mandatory interval by applying a policy to the nodes that host the registry.) Asynchronous subscription keeps subscribers from drowning in information overload. Synchronous subscription, rather than relying on email or a separate service, uses an API to return registry changes to the subscriber. A subscriber might have more than one subscription, each with its own settings defined in a subscription filter structure. This subscription filter controls the information that a subscription returns and the way that the information is presented.
For more details about subscription services in UDDI 3.0, including the names of the APIs and structures that define a subscription's settings, check out the UDDI 3.0 specification at
http://uddi.org/pubs/uddi_v3.htm
