The UDDI XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only.
Diff for UDDI 101
Mon, 2006-08-14 15:54 by carolgeyer | Mon, 2006-08-14 18:12 by carolgeyer | ||
---|---|---|---|
Expanded detail in several subsections of page; added history table. (MBS 3/9/2006) | Expanded detail in several subsections of page; added history table. (MBS 3/9/2006) | ||
< previous diff | |||
Changes to Body | |||
Line 1 | Line 1 | ||
- | <p>The Universal Description, Discovery, and Integration (UDDI) protocol is a key member of the Web services stack. It defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). UDDI is managed by the OASIS UDDI Technical Committee.</p>
| + | <p>The Universal Description, Discovery, and Integration (UDDI) protocol is an approved OASIS Standard and a key member of the Web services stack. It defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). UDDI is advanced by the <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec">OASIS UDDI Specification Technical Committee</a>.</p>
|
<p><strong>UDDI in a Web Services World</strong></p>
| <p><strong>UDDI in a Web Services World</strong></p>
| ||
- | <p>The specification defines a group of Web services and programmatic interfaces for publishing, retrieving, and managing information about services. (In true SOA fashion, a UDDI registry is itself composed of web services!) UDDI builds upon several other established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The conceptual relationship between UDDI and other protocols in the web services stack is illustrated in the following figure:</p>
| + | <p>The specification defines a group of Web services and programmatic interfaces for publishing, retrieving, and managing information about services. (In true SOA fashion, a UDDI registry is itself composed of Web services!) UDDI builds upon several other established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The conceptual relationship between UDDI and other protocols in the Web services stack is illustrated in the following figure:</p>
|
<p><img width="400" height="364" src="http://uddi.xml.org/files/stack.gif" longdesc="Conceptual illustration of a typical web services stack" alt="Web Services Stack" /></p>
| <p><img width="400" height="364" src="http://uddi.xml.org/files/stack.gif" longdesc="Conceptual illustration of a typical web services stack" alt="Web Services Stack" /></p>
| ||
<p><strong>Key Functional Concepts in UDDI</strong></p>
| <p><strong>Key Functional Concepts in UDDI</strong></p>
| ||
Line 16 | Line 16 | ||
<li>Standing requests to track changes to a list of entities (subscription)</li>
| <li>Standing requests to track changes to a list of entities (subscription)</li>
| ||
</ul>
| </ul>
| ||
- | <p>• <strong>Defining UDDI Nodes and Registries.</strong> The UDDI specification includes a specific definition of the hierarchical relationship between a single instance of a UDDI implementation and others to which it is related. Technically, there are three major classifications of UDDI servers:</p>
| + | <p>• <strong>Defining UDDI Nodes and Registries.</strong> UDDI includes a specific definition of the hierarchical relationship between a single instance of a UDDI implementation and others to which it is related. Technically, there are three major classifications of UDDI servers:</p>
|
<ul>
| <ul>
| ||
<li>A <em>node</em> is a UDDI server that supports at least the minimum set of functionality defined in the specification. It may perform one or more functions on the UDDI data to which it has access. It is a member of exactly one UDDI registry.</li>
| <li>A <em>node</em> is a UDDI server that supports at least the minimum set of functionality defined in the specification. It may perform one or more functions on the UDDI data to which it has access. It is a member of exactly one UDDI registry.</li>
| ||
Line 27 | Line 27 | ||
<li>Searching a UDDI registry for information about a service</li>
| <li>Searching a UDDI registry for information about a service</li>
| ||
</ul>
| </ul>
| ||
- | <p>These inquiry and publishing functions represent the core data management tools of a UDDI registry. Additionally, we have described how multiple registries may form a group, known as an affiliation, to permit policy-based copying of core data structures among them. Some of the most important concepts that support registry interaction include:</p>
| + | <p>These inquiry and publishing functions represent the core data management tools of a UDDI registry. Additionally, UDDI describes how multiple registries may form a group, known as an affiliation, to permit policy-based copying of core data structures among them. Some of the most important concepts that support registry interaction include:</p>
|
<ul>
| <ul>
| ||
<li>Replicating and transferring custody of data about a service</li>
| <li>Replicating and transferring custody of data about a service</li>
| ||
Line 35 | Line 35 | ||
</ul>
| </ul>
| ||
<p>The UDDI specification divides these functions into “Node API Sets” that are supported by a UDDI server and “Client API Sets” that are supported (naturally enough) by a UDDI client.</p>
| <p>The UDDI specification divides these functions into “Node API Sets” that are supported by a UDDI server and “Client API Sets” that are supported (naturally enough) by a UDDI client.</p>
| ||
- | <p><strong>History of UDDI</strong></p>
| + | <p><strong>Learn More</strong></p>
|
- | <p>UDDI first was proposed in 2000; it currently stands at its third major revision. Over this time, it has evolvoed to reflect the need for manageability and federated control in enterprise operating scenarios, as well as to further integrate the standard with other elements of service-oriented infrastructure. Highlights of the standard's progess include:</p>
| + | <p>Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure. In particular, good next steps include:</p>
|
- | <table>
| + | |
- | <caption> History of the UDDI Specification </caption>
| + | |
- | <tbody>
| + | |
- | <tr>
| + | |
- | <th>UDDI VERSION</th> <th>YEAR RELEASED</th> <th>KEY OBJECTIVE</th>
| + | |
- | </tr>
| + | |
- | <tr>
| + | |
- | <td>1.0</td>
| + | |
- | <td>2000</td>
| + | |
- | <td>Create foundation for registry of Internet-based business services</td>
| + | |
- | </tr>
| + | |
- | <tr>
| + | |
- | <td>2.0</td>
| + | |
- | <td>2001</td>
| + | |
- | <td>Align specification with emerging Web services standards and provide flexible service taxonomy. Formally released under OASIS aegis in 2003</td>
| + | |
- | </tr>
| + | |
- | <tr>
| + | |
- | <td>3.0</td>
| + | |
- | <td>2004</td>
| + | |
- | <td>Support secure interaction of private and public implementations as major element of service-oriented infrastructure. Fully ratified by OASIS in 2005</td>
| + | |
- | </tr>
| + | |
- | </tbody>
| + | |
- | </table>
| + | |
- | <p><strong>Learning More</strong></p>
| + | |
- | <p>Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure. The left-hand navigation bar links to various in-depth resources. In particular, good next steps include:</p>
| + | |
<ul>
| <ul>
| ||
<li><a href="http://uddi.xml.org/files/uddi-tech-wp.pdf">Introduction to UDDI: Important Features and Functional Concepts (White Paper)</a></li>
| <li><a href="http://uddi.xml.org/files/uddi-tech-wp.pdf">Introduction to UDDI: Important Features and Functional Concepts (White Paper)</a></li>
|
UDDI 101
The Universal Description, Discovery, and Integration (UDDI) protocol is an approved OASIS Standard and a key member of the Web services stack. It defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). UDDI is advanced by the OASIS UDDI Specification Technical Committee.
UDDI in a Web Services World
The specification defines a group of Web services and programmatic interfaces for publishing, retrieving, and managing information about services. (In true SOA fashion, a UDDI registry is itself composed of Web services!) UDDI builds upon several other established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The conceptual relationship between UDDI and other protocols in the Web services stack is illustrated in the following figure:
Key Functional Concepts in UDDI
A UDDI registry's functional purpose is the representation of data and metadata about Web services. A registry, either for use on a public network or within an organization's internal infrastructure, offers a standards-based mechanism to classify, catalog, and manage Web services, so that they can be discovered and consumed by other applications.
Accordingly, the standard specifies protocols for accessing a registry for Web services, methods for controlling access to the registry, and a mechanism for distributing or delegating records to other registries. In other words, the standard provides a means to locate a software service, to invoke that service, and to manage metadata about that service.
To these ends, key functional concepts for working with UDDI include:
• The UDDI Data Model. The UDDI specification defines core data types that include a description of the service's business function, information about the service's publisher, the service's technical details and API, and other metadata. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:
- A description of a service’s business function (called the businessService)
- Information about the organization that published the service (businessEntity)
- The service’s technical details (bindingTemplate), including a reference to the service’s programmatic interface or API, and
- Various other attributes or metadata such as taxonomy, transports, digital signatures, etc. (tModels)
- Relationships among entities in the registry (publisherAssertion)
- Standing requests to track changes to a list of entities (subscription)
• Defining UDDI Nodes and Registries. UDDI includes a specific definition of the hierarchical relationship between a single instance of a UDDI implementation and others to which it is related. Technically, there are three major classifications of UDDI servers:
- A node is a UDDI server that supports at least the minimum set of functionality defined in the specification. It may perform one or more functions on the UDDI data to which it has access. It is a member of exactly one UDDI registry.
- A registry is composed of one or more nodes. A registry performs the complete set of functionality as defined in the specification.
- Affiliated registries are individual UDDI registries that implement policy-based sharing of information among them. The affiliated registries share a common namespace for UDDI keys that uniquely identify data records.
• Essential Programmatic Interfaces. A UDDI registry provides several key functions that include:
- Publishing information about a service to a registry
- Searching a UDDI registry for information about a service
These inquiry and publishing functions represent the core data management tools of a UDDI registry. Additionally, UDDI describes how multiple registries may form a group, known as an affiliation, to permit policy-based copying of core data structures among them. Some of the most important concepts that support registry interaction include:
- Replicating and transferring custody of data about a service
- Registration key generation and management
- Registration subscription API set
- Security and authorization
The UDDI specification divides these functions into “Node API Sets” that are supported by a UDDI server and “Client API Sets” that are supported (naturally enough) by a UDDI client.
Learn More
Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure. In particular, good next steps include: