UDDI Specifications XML

To implement the UDDI initiative, UDDI specifications are developed. UDDI specifications consist of a set of XSD documents.

XSD documents in the UDDI specifications define the format of the data in the UDDI specifications. Since its evolution, several versions of the UDDI specifications have been issued, with version 2.0 being the latest. These versions of the UDDI specifications are available as freely downloadable.

  • UDDI replication
  • UDDI operators
  • UDDI programmer's APIs
  • UDDI data structures

We will discuss these documents in detail.

The UDDI Replication Document

When UDDI data is transferred across a network, the data is replicated from one operator site to another. The process of replication of data is defined in the UDDI replication document. In addition, to allow replication of data, the UDDI registry must adhere to the interfaces as specified in the UDDI replication document.

To understand the data that is stored in the UDDI replication document, you first need to understand the replication process. Consider a situation in which a business organization exposes a Web service. The information about this Web service will then be available in the UDDI directory. Several operator sites, called nodes, manage this directory. Therefore, if the organization makes some changes to the Web service, these changes need to be reflected in the UDDI directory. In addition, the changes need to be replicated across all operator sites.

Now, consider that the changes need to be replicated from operator node A to operator node B. In this case, operator node A specifies a unique number to the changes made to the UDDI data. This unique number is called Update Sequence Number (USN), and the operator site maintains it in a register called the USN register.

In addition, operator node A creates a record specifying the changes made to the UDDI data. This record is called a change record. This record contains information such as the UUID of operator node A, the USN of the changes made at node A, and the semantics of the changes.

After creating the change record, the operator node A transfers the change record to operator node B. When node B receives the change record, it assigns a local USN to the change record. Node B then replicates changes that are specified in the change record based on the ascending order of the local USN. The next time that node B receives a change record from node A, the change record will be assigned a USN number greater than the previously assigned USN. This process of replication is explained in Figure.

The Replication Process

The Replication Process

The UDDI Operators Document

To implement a Web service, you need to register it. The UDDI node operators provide the information about registering a Web service. The behavioral and operational information about these node operators is available in the UDDI operators document. The following list discusses the operations that an operator node performs:

  • Storing information. An operator node allows a business organization or a user who registers a Web service with the UDDI registry to update or delete the UDDI data. When you store information about a Web service in the UDDI registry, the operator node assigns and maintains an e-mail address of the business organization that hosts the Web service. The operator node also secures this e-mail address so that the address is not accessible outside the operator node.
  • Maintaining the integrity of data. The information about a Web service is stored at multiple locations in the registry. Therefore, when you make changes to this information, the operator nodes must replicate the changes to all locations to maintain the integrity of data.
  • Making backups of the UDDI data. The main function of an operator node is to make backups of the data that is stored in the UDDI registry.

The UDDI Programmer's API Document

As discussed earlier, you can register a Web service or find information about a Web service in a UDDI directory. The UDDI programmer's API document specifies the functions that UDDI supports to allow you to publish or find information about a Web service. These functions are categorized as inquiry API functions and publish API functions. The following list discusses these functions in detail:

  • Inquiry API functions. These include the messages that inquire about operator nodes. These messages are synchronous in nature and are exposed using HTTPPOST statements.
  • Publish API functions. These include messages that are used to publish or update information in a UDDI directory. These messages are also synchronous in nature and are posted using HTTP-POST statements.

In addition to providing the inquiry and publish API functions, the UDDI programmer's API document forms the programming interface of a UDDI registry by specifying a set of SOAP messages. The UDDI registry receives and responds to a request in the form of SOAP messages.

Note?/td>
The UDDI programmer's API document contains nearly 40 inquiry and publish API functions.

The UDDI Data Structures Document

The SOAP messages that are defined in the UDDI programmer's API consist of XML structures. The UDDI data structures document contains information about these XML structures. Based on the type of information, these data structures are divided into five types. You will learn about the data structures later in this section.

The data structures, defined in the UDDI data structures document, consist of the UDDI data model, which in turn consists of five data structures. These data structures contain elements called data fields. The data fields provide information about the Web service that is registered with the UDDI registry. Each data structure in the UDDI data model is assigned a UUID.

In this section, we will discuss the type of information that is stored in the data structures.

The businessEntity Data Structure

The businessEntity data structure contains information about the business organization that publishes a Web service with the UDDI registry. This information includes the UUID, name, address, and other contact numbers of the business organization. In addition, the businessEntity data structure might contain the business descriptions and references to the businessService data structure. The businessEntity data structure allows a business organization to establish a business relationship with partner organizations.

For example, two organizations whose details are present in the businessEntity data structure can establish a partnership. The details of this partnership are maintained in the businessEntity data structure as well.

When a business organization exposes a service with the UDDI registry, the operator node assigns a discovery URL to the business organization. This discovery URL is unique for operator sites, and it enables users to access the content that is stored in the businessEntity data structure.

The businessService Data Structure

A businessEntity data structure contains references to one or more businessService data structures. These data structures store the UUID of the businessEntity structure that contains a reference to these structures. In addition, the businessService data structure contains descriptive information about the services that the business organization provides. Each businessService is assigned a unique serviceKey, which is a UUID number. The businessService data structure might also contain a reference to the bindingTemplate data structures. You will learn about the bindingTemplate data structures in the following section.

A businessService data structure is a reusable component. This implies that one businessService data structure can be used by one or more businessEntity data structures. For example, a business organization can develop a Web service to expose the inventory database. The information about this Web service is contained in the businessService data structure. Now, several divisions of the organization, such as production, sales, and marketing, can use this data structure.

The tModel Data Structure

Consider a situation in which an organization needs to share its sales data with its customers. To allow sharing or exchanging of data between two organizations, the organizations need to agree on the design goals and the technical specifications. The tModel data structure contains descriptive information about these specifications. You can use the tModel data structure to retrieve information about the technical concepts and the interfaces that the design of the service uses. However, the tModel data structure does not contain these specifications directly. Instead, the data structure contains pointers or references toURLs of the specifications.

The tModel data structure provides you with the information about how you can interact with a Web service. For example, a business organization plans to develop a service that allows its customers or partner organizations to place online orders for their goods. The technical specifications and the information about the manner in which the customers can use the service are available in the tModel data structure. Each tModel data structure is assigned a unique key, called the tModelKey, which is a UUID number.

The bindingTemplate Data Structure

After a tModel data structure is created, you need to associate it with the service. The mechanism for associating a tModel with the service is defined in the bindingTemplate data structure. To define the mechanism, the bindingTemplate data structure contains pointers to the technical descriptions and not the service itself. In addition, the bindingTemplate data structure includes a text description of the Web service, its URL, and references to the tModel data structures.

The unique key that is assigned to the bindingTemplate data structure is called bindingKey. This key is contained in the bindingTemplate data structure in addition to the service Key of the service.

The publisherAssertion Data Structure

The publisherAssertion data structure contains information about the relationships between two businessEntity data structures. However, to make this information public, the business organizations need to assert the information. This assertion is included in different publisherAssertion data structures, one for each businessEntity data structure.
Figure shows the UDDI data model.

The UDDI Data Model.

The UDDI Data Model.

Having looked at UDDI in detail, you will now look at the scenarios in which you can use the UDDI registry.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

XML Topics