UDDI—the registry's specification

In order to understand how the registry works, and how you can better exploit its capabilities, it's important to understand the underlying specification on which the registry is built. That specification is UDDI. For JBoss ESB, UDDI defines an XML-based registry within the bus.

In a nutshell, the UDDI specification is a standard that defines an XML-based registry, that supports means to define (register) and find (discover) services.

UDDI (Universal Description, Discovery, and Integration) was developed under the sponsorship of OASIS (the Organization for the Advancement of Structured Information Standards , more information can be found at http://www.oasis-open.org) with the goal of providing universal public web service registries that anyone in the world could access to locate specific businesses and services. This goal was never really reached, and in 2008, the UDDI public registry was taken down (http://www.webservicessummit.com/News/UDDI2006.htm).

But still, UDDI registries are widely used privately or at an organizational level.

The UDDI specification (you can find it at http://www.oasis-open.org/standards#uddiv3.0.2) provides for the definition (http://www.uddi.org/pubs/uddi-tech-wp.pdf) of the three building blocks of a UDDI registry, theyare:

  • Services
  • Servers
  • APIs

Note

Note that these are abstract definitions. The actual implementations are provided by the specific UDDI providers and APIs that we'll review later in this chapter.

Services are based on the follwing:

  • Business entities: These are the groups, companies, or organizations that publish the services. Each business entity can include one or more business sevices.
  • Business services: These are the services. Each service definition includes the service name and a description. Each business service can include one or more binding teplates.
  • Binding templates: A binding template defines the service's access points (typically URLs) and includes references to the service's technial data.
  • Technical data models: Called as tModels, these define the specific interfaces to the service, and include information such as the transports through which the service can b invoked.

Servers are based on the following:

  • Nodes: This is a single UDDI server. What qualifies a "server" to be a "UDDI server"? It has to be running at least a subset of the features defined in the UDDI standard.
  • Registries: A registry is a grouping of one or more than one node that supports the full set of features defined in the UDDI standard. A registry can function on its own or it can also operate in a hierarchical group of "affiliated"registries.
  • Affiliate registries: One type of grouping of registries is the "federation". In this context the federation refers to the division of service definition and access. For example, services can be divided into registries such that all groups in a company can access the company's employee benefits services, while a subset of those groups can access a company's payroll services.

Additionally, there are definitions of sets of APIs that enable the use and administration of the registry. There are Node API set, as follows:

  • Inquiry API set: The name says it all. This API supports performing inquiries of a registry, in order to find a service.
  • Publication API set: A service cannot be found until it's first published. This API supports the publicaton of services.
  • Replication API set: This API enables the copying of information about services beween UDDI nodes.
  • Security Policy API set: This API governs the use of authentication tokens for acessing services.
  • Custody and Ownership Transfer API set: This API supports transferring custody of businessEntities or tModels betwen registry nodes.
  • Subscription API set: This API enables subscribers (in other words, clients) to "subscribe" to a UDDI registry, so that they will receive information on changes mae to the registry.
  • Value Set Validation API set: This API enables the validation of a tModel service's keyedReference which is the relationship between two publishers. The validation ensures that both publishers actually have the authorization to pblish the service.

Ad Client API sets:

  • UDDI Subscription Listener API set: This is the counterpart to the Subscription API set. It enables the sending of the changes in a UDDI regitry to subscribers.
  • UDDI Value Set Caching API set: This API supports caching a set of values to be returned to clients performing a keyedReference validation.

That was a quick, and somewhat abstract view of UDDI. Next, we'll switch to a more concrete mode and look at a real implementation. We'll review how JBoss ESB operates with the registry that it is configured with, by default, Apache jUDDI (http://juddi.apache.org/).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.129.247.196