UDDI 3.0.2 规范：Web服务与注册表行为详解

需积分: 10 47 浏览量更新于2024-07-30 1 收藏 2.68MB PDF 举报

"UDDI Version 3.0.2 规范是一个由UDDI Spec Technical Committee编写的草案，详细阐述了Web服务、数据结构和所有UDDI注册表实例的行为。该规范的当前版本是http://uddi.org/pubs/uddi-v3.0.2-20041019.htm，最新的版本则可在http://uddi.org/pubs/uddi_v3.htm找到，之前的一个版本是http://uddi.org/pubs/uddi-v3.0.1-20031014.htm。该文档的主要编辑者包括Luc Clement（Systinet）、Andrew Hately（IBM）、Claus von Riegen（SAP AG）和Tony Rogers（Computer Associates）等，还有一系列贡献者名单。UDDI Version 3.0.2规范的目标是定义一个通用的目录服务，用于发布、发现和管理Web服务的信息。" **UDDI（Universal Description, Discovery, and Integration）是一种基于Web的标准，旨在提供一种机制，使得企业可以注册其Web服务，并让其他企业发现和使用这些服务。** 在UDDI Version 3.0.2规范中，以下几个关键知识点值得深入理解： 1. **Web服务接口**：UDDI定义了一套API，允许服务提供商注册他们的服务，而服务消费者则可以搜索和访问这些服务。这些接口通常通过SOAP（Simple Object Access Protocol）进行通信。 2. **数据结构**：规范定义了一系列数据结构，如业务实体（Business Entity）、服务绑定（Service Binding）和业务类别（Business Category），它们共同构成了描述Web服务的基本元素。 3. **行为**：UDDI注册表的行为包括服务的发布、查询、订阅和管理。发布允许服务提供者将其服务信息录入到UDDI目录中；查询功能使得服务消费者可以寻找特定的服务；订阅功能允许用户跟踪服务的变化；而管理则是对已发布信息的更新和删除。 4. **版本管理**：UDDI Version 3.0.2相对于之前的版本可能进行了改进和修正，以提升性能、稳定性和兼容性。 5. **安全性**：UDDI规范也涉及到了安全性方面，如身份验证、授权和隐私保护，确保服务信息的安全交换。 6. **多语言支持**：UDDI设计时考虑了全球化，因此它支持多种语言的元数据，以适应不同地区的服务描述。 7. **社区参与**：UDDI Spec Technical Committee的成员和贡献者列表显示了业界对UDDI标准的关注和参与，这有助于推动规范的持续改进和发展。 UDDI Version 3.0.2规范是一个重要的技术文档，它为Web服务的发现、集成和交互提供了统一的框架，对于理解和实现基于Web服务的系统至关重要。

1.3 Diagrams Used in this document

1.3.1 Attributes and elements

UDDI uses the XML Schema Language (See http://www.w3.org/TR/xmlschema-0/,

http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/) and its

terminology, such as "sequence" and "choice" to formally describe its data structures. The

diagrams

[1]

used in this specification show the structure and cardinality of the elements used in

these structures. Attributes are not shown in the diagrams, but explained in the corresponding

documentation.

1.3.2 Element structure

1.3.2.1 Sequence

The octagonal symbol with the horizontal "dotted" line indicates "sequence of." This diagram

says the element registeredInfo consists of elements businessInfos and tModelInfos. All three

elements are defined in the namespace whose prefix is "uddi".

The fact that businessInfos and tModelInfos have a box with a "+" in it at their right-hand end

indicates that there is more structure to them than is shown in the diagram.

1.3.2.2 Choice

The switch-like symbol indicates a choice. In this case, a choice between the elements

businessKey, fromKey, and toKey.

None of these has more structure than is given in the diagram (there are no boxes with a "+" in

them at their right-hand ends). That they are adorned with a small series of horizontal lines in

their upper left corners indicates that each is a non-empty element.

1.3.3 Cardinality

1.3.3.1 Optional, one

The dashed line indicates that the element listDescription is optional. The fact that it is not

adorned with some other cardinality indicator (see below) says there can be at most one of

them.

 businessService: Describes a collection of related Web services offered by an organization

described by a businessEntity.

 bindingTemplate: Describes the technical information necessary to use a particular Web service.

 tModel: Describes a "technical model" representing a reusable concept, such as a Web service

type, a protocol used by Web services, or a category system.

 publisherAssertion: Describes, in the view of one businessEntity, the relationship that the

businessEntity has with another businessEntity.

[2]

 subscription: Describes a standing request to keep track of changes to the entities described by

the subscription.

1.5.2 UDDI Services and API Sets

This specification presents APIs that standardize behavior and communication with and

between implementations of UDDI for the purposes of manipulating UDDI data stored within

those implementations. The API’s are grouped into the following API sets.

1.5.2.1 Node API Sets

 UDDI Inquiry

 UDDI Publication

 UDDI Security

 UDDI Custody Transfer

 UDDI Subscription

 UDDI Replication

1.5.2.2 Client API Sets

 UDDI Subscription Listener

 UDDI Value Set

1.5.3 UDDI Nodes

A set of Web services supporting at least one of the Node API sets is referred to as a UDDI

node. A UDDI node has these defining characteristics:

1. A UDDI node supports interaction with UDDI data through one or more UDDI API sets

2. A UDDI node is a member of exactly one UDDI registry.

3. A UDDI node conceptually has access to and manipulates a complete logical copy of the UDDI

data managed by the registry of which it is a part. Moreover, it is this data which is manipulated by any

query and publish APIs supported by the node. Typically, UDDI replication occurs between UDDI

nodes which reside on different systems in order to manifest this logical copy in the node.

The physical realization of a UDDI node is not mandated by this specification.

1.5.4 UDDI Registries

One or more UDDI nodes may be combined to form a UDDI Registry. The nodes in a UDDI

registry collectively manage a particular set of UDDI data. This data is distinguished by the

visible behavior associated with the entities contained in it.

A UDDI Registry has these defining characteristics.

1. A registry is comprised of one or more UDDI nodes.

2. The nodes of a registry collectively manage a well-defined set of UDDI data. Typically, this is

supported by the use of UDDI replication between the nodes in the registry which reside on different

systems.

3. A registry MUST make a policy decision for each policy decision point. It MAY choose to delegate

policy decisions to nodes. See Chapter 9 Policy for details.

The physical realization of a UDDI Registry is not mandated by this specification.

1.5.5 Affiliations of Registries

The entities businessEntity, businessService, bindingTemplate, tModel form the core data

structures of UDDI. Within a registry, each instance of the core data structures is uniquely

identified by a UDDI key. By choosing appropriate policies, multiple registries may form a

group, known as an "affiliation", whose purpose is to permit controlled copying of core data

structures among them. A UDDI registry affiliation has these defining characteristics.

1. The registries share a common namespace for entity keys.

2. The registries have compatible policies for assigning keys to entities.

3. The policies of the registries permit publishers to assign keys

1.5.6 Person, Publisher and Owner

When publishing information in a UDDI registry the information becomes part of the published

content of the registry. During publication of an item of UDDI information, a relationship is

established between the publisher, the item published and the node at which the publish

operation takes place. The glossary contains definitions of the terms person, publisher and

owner.

This specification defines a relationship between these three terms and leaves the binding of

these abstract relationships to be determined by the policies of the registry and its nodes at

implementation. It is important to review Chapter 9 on policy to understand how different

implementations can define different policies but remain consistent with the UDDI specification.

1.5.7 Transfer of ownership

As the owner of datum, a person can initiate the transfer of ownership of the datum to another

publisher within the registry. Section 5.4 Custody and Ownership Transfer API describes the

transfer of ownership within UDDI.

1.5.8 Data Custody

Generally speaking, data is replicated between nodes of a UDDI registry using a replication

protocol. Registries that choose to use the replication protocol defined in Section 7.4

Replication API Set MUST enforce the following data custody policy. (Registries which choose

otherwise incur no such requirement.)

Each node has custody of a portion of the aggregate data managed by the registry of which it

is a part. Each datum is by definition in the custody of exactly one such node. A datum in this

context can be a businessEntity, a businessService, a bindingTemplate, a tModel, or a

publisherAssertion. Changes to a datum in the registry MUST originate at the node which is

the custodian of the datum. The registry defines the policy for data custody and, if allowed, the

custodian node for a given datum can be changed; such custody transfer processes are

discussed in Section 5.4 Custody and Ownership Transfer API.

1.6 Representing Information within UDDI

For Web services to be meaningful there is a need to provide information about them beyond

the technical specifications of the service itself. Central to UDDI’s purpose is the

representation of data and metadata about Web services. A UDDI registry, either for use in

the public domain or behind the firewall, offers a standard mechanism to classify, catalog and

manage Web services, so that they can be discovered and consumed. Whether for the

purpose of electronic commerce or alternate purposes, businesses and providers can use

UDDI to represent information about Web services in a standard way such that queries can

then be issued to a UDDI Registry – at design-time or run-time – that address the following

scenarios:

 Find Web services implementations that are based on a common abstract interface definition.

 Find Web services providers that are classified according to a known classification scheme or

identifier system.

 Determine the security and transport protocols supported by a given Web service.

 Issue a search for services based on a general keyword.

 Cache the technical information about a Web service and then update that information at run-time.

These scenarios and many more are enabled by the combination of the UDDI information

model and the UDDI API set. Because the information model is extremely normalized, it can

accommodate many different types of models, scenarios and technologies. The specification

has been written to be flexible so that it can absorb a diverse set of services and not be tied to

any one particular technology. While a UDDI Node exposes its information as an XML Web

service, it does not restrict the technologies of the services about which it stores information or

the ways in which that information is decorated with metadata.

1.6.1 Representing Businesses and Providers with "businessEntity"

One top-level data structure within UDDI is the businessEntity structure, used to represent

businesses and providers within UDDI. It contains descriptive information about the business

or provider and about the services it offers. This would include information such as names and

descriptions in multiple languages, contact information and classification information. Service

descriptions and technical information are expressed within a businessEntity by contained

businessService and bindingTemplate structures.

While the name of XML entity itself has the word business embedded in it, the structure can be

used to model more than simply a "business" in its common usage. As the top-level entity,

businessEntity can be used to model any "parent" service provider, such as a department, an

application or even a server. Depending on the context of the data in the entire registry, the

appropriate modeling decisions to represent different service providers can vary.

1.6.2 Representing Services with "businessService"

Each businessService structure represents a logical grouping of Web services. At the service

level, there is still no technical information provided about those services; rather, this structure

allows the ability to assemble a set of services under a common rubric. Each businessService

is the logical child of a single businessEntity. Each businessService contains descriptive

information – again, names, descriptions and classification information -- outlining the purpose

of the individual Web services found within it. For example, a businessService structure could

contain a set of Purchase Order Web services (submission, confirmation and notification) that

are provided by a business.

Similar to the businessEntity structure, the term business is embedded within the name

businessService. However, a suite of services need not be tied to a business per se, but can

剩余439页未读，继续阅读

小风0092

粉丝: 1
资源: 31

UDDI 3.0.2 规范：Web服务与注册表行为详解

uddi使用说明v3

uddi注册中心uddi资料

UDDI.rar_UDDI

理解UDDI

采用WebLogic UDDI客户端API示例.rar_UDDI_uddi weblogic_weblogic

什么是UDDI-web与UDDI的差别

Microsoft UDDI SDK

Open UDDI Spec

uddi4j

UDDI扩展相关资料

最新资源