Browse DevX
Sign up for e-mail newsletters from DevX


Creating Your Own Private UDDI Registry : Page 3

You don't have to rely on some huge public UDDI repository to expose your Web services to developers and automated processes. Instead, find out how to set up a UDDI registry on your own server.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

The UDDI Data Model
Registries are themselves implemented as Web services. A typical UDDI registry supports interactions surrounding the following components:

  • Registry clients: programs or services that interact with a registry in order to browse or search for registered businesses and services.
  • Registry entries: content residing inside a registry about a business or service.
  • Entry metadata: content describing a registry entry and how to find the registry entry.
Registry entries and metadata are exposed as the following structures:

  • businessEntity—this structure encapsulates information describing one or more business services, including their name, category, geographic location, contact information, etc
  • businessService—this structure contains descriptive information about a group of related technical services including the group name, description, and category information. A businessService structure acts as a container for one or more bindingTemplates
  • bindingTemplate—this structure contains information needed to invoke or bind to a specific service. This information includes the service URL, routing and load balancing facilities, and references to interface specifications contained in a corresponding tModel structure
  • tModel—this structure encapsulates information about interfaces and other technical concepts for a given service
Figure 2 illustrates the relationships between these structures.

Figure 2. Relationships Between UDDI Structures: The figure illustrates the relationships between the various structures exposed in a UDDI repository.
The UDDI Invocation Model
To invoke a specific Web service using information from a UDDI registry a caller typically follows these steps:

  1. Locates the businessEntity information registered for the business exposing the Web service.
  2. Discovers additional details about the Web service by accessing the businessService structure contained within the businessEntity structure. From there, the caller selects the appropriate bindingTemplate to use.
  3. Uses the technical information contained in the tModel corresponding to the selected bindingTemplate to build the client that will access the Web service.
The UDDI Inquiry API
The UDDI inquiry API consists of operations that enable you to browse a registry and to traverse a registry in order to obtain information about specific businesses and services. Table 2 shows the inquiry API calls that a UDDI registry must support.

Table 2: Required Inquiry API Methods: The table lists the inquiry methods that a UDDI registry must support.




Used to locate bindings within or across one or more registered businessServices.


Used to locate information about one or more businesses.


Used to locate information about businessEntity registrations that are related to a specific business entity whose key is passed in an inquiry.


Used to locate specific services within registered business entities.


Used to locate one or more tModel information structures.


Used to get bindingTemplate information suitable for making service requests.


Used to get the businessEntity information for one or more businesses or organizations.


Used to get extended businessEntity information.


Used to get full details for a given set of registered businessService data.


Used to get full details for a given set of registered tModel data.

The following sections discuss a particular framework—jUDDI— used to represent the structures of a UDDI registry and how you can use it to implement a private registry.

Thanks for your registration, follow us on our social networks to keep up-to-date