- UDDI Tutorial
- UDDI - Home
- UDDI - Overview
- UDDI - Elements
- UDDI - Technical Architecture
- UDDI - Data Model
- UDDI - Interfaces
- UDDI - Usage Example
- UDDI with WSDL
- UDDI - Implementations
- UDDI - Specifications
- UDDI - Summary
- UDDI API References
- UDDI - API Quick References
- UDDI Useful Resources
- UDDI - Quick Guide
- UDDI - Useful Resources
- UDDI - Discussion
UDDI - 快速指南
UDDI - 概述
UDDI 是一种基于 XML 的标准,用于描述、发布和查找 Web 服务。
UDDI 代表通用描述、发现和集成。
UDDI 是 Web 服务的分布式注册规范。
UDDI 是一个独立于平台的开放框架。
UDDI可以通过SOAP、CORBA、Java RMI协议进行通信。
UDDI 使用 Web 服务定义语言 (WSDL) 来描述 Web 服务的接口。
UDDI 与 SOAP 和 WSDL 一起被视为 Web 服务的三大基础标准之一。
UDDI 是一项开放的行业计划,使企业能够发现彼此并定义它们如何通过 Internet 进行交互。
UDDI 有两个部分 -
所有 Web 服务元数据的注册表,包括指向服务 WSDL 描述的指针。
用于操作和搜索该注册表的一组 WSDL 端口类型定义。
UDDI 的历史
UDDI 1.0 最初由 Microsoft、IBM 和 Ariba 于 2000 年 9 月发布。
自最初宣布以来,UDDI 计划已发展到包括戴尔、富士通、惠普、日立、IBM、英特尔、微软、甲骨文、SAP 和 Sun 等 300 多家公司。
2001 年 5 月,Microsoft 和 IBM 推出了第一个 UDDI 运营商站点,并启用了 UDDI 注册中心。
2001 年 6 月,UDDI 发布了 2.0 版。
在撰写本教程时,Microsoft 和 IBM 站点已经实现了 1.0 规范,并计划在不久的将来支持 2.0。
目前UDDI 由OASIS 赞助。
合作伙伴接口流程
合作伙伴接口流程 (PIP) 是基于 XML 的接口,使两个贸易伙伴能够交换数据。已有数十个 PIP。其中一些列在这里 -
PIP2A2 - 使合作伙伴能够查询另一个合作伙伴的产品信息。
PIP3A2 - 使合作伙伴能够查询特定产品的价格和可用性。
PIP3A4 - 使合作伙伴能够提交电子采购订单并接收订单确认。
PIP3A3 - 使合作伙伴能够传输电子购物车的内容。
PIP3B4 - 使合作伙伴能够查询特定货件的状态。
私有 UDDI 注册中心
作为使用 Internet 上可用的 UDDI 注册中心公共联合网络的替代方案,公司或行业团体可以选择实施自己的私有 UDDI 注册中心。
这些专有服务的唯一目的是允许公司或行业团体的成员在彼此之间共享和宣传服务。
无论 UDDI 注册中心是全球联合网络的一部分还是私有和运营的注册中心,将它们联系在一起的一件事就是用于发布和定位 UDDI 注册中心内广告的企业和服务的通用 Web 服务 API。
UDDI - 元素
企业或公司可以将三种类型的信息注册到 UDDI 注册表中。该信息包含在 UDDI 的三个元素中。
这三个要素是 -
- 白页,
- 黄页,以及
- 绿页。
白页
白页包含 -
有关公司及其业务的基本信息。
基本联系信息包括企业名称、地址、联系电话等。
A 公司税号的唯一标识符。此信息允许其他人根据您的企业标识发现您的网络服务。
黄页
黄页包含有关该公司的更多详细信息。其中包括该公司可以向任何想要与之开展业务的人提供的电子功能类型的描述。
黄页使用普遍接受的工业分类方案、行业代码、产品代码、企业识别代码等,使公司更容易搜索列表并准确找到他们想要的东西。
绿页
绿页包含有关 Web 服务的技术信息。绿页允许某人在发现 Web 服务后绑定到该服务。它包括 -
- 各种接口
- URL 位置
- 查找和运行 Web 服务所需的发现信息和类似数据。
注:UDDI 不限于描述基于 SOAP 的 Web 服务。相反,UDDI 可用于描述任何服务,从单个网页或电子邮件地址一直到 SOAP、CORBA 和 Java RMI 服务。
UDDI——技术架构
UDDI 技术架构由三部分组成 -
UDDI数据模型
UDDI 数据模型是用于描述业务和 Web 服务的 XML 模式。该数据模型在“UDDI 数据模型”一章中有详细描述。
UDDI API 规范
它是用于搜索和发布UDDI数据的API规范。
UDDI云服务
这些运营商站点提供 UDDI 规范的实现并按计划同步所有数据。
UDDI 商业注册中心 (UBR) 也称为公共云,概念上是一个由多个节点构建的单一系统,这些节点的数据通过复制进行同步。
当前的云服务提供逻辑上集中但物理上分布式的目录。这意味着提交到一个根节点的数据将自动复制到所有其他根节点。目前,数据复制每 24 小时进行一次。
UDDI云服务目前由微软和IBM提供。Ariba 最初还计划提供运营商,但后来放弃了这一承诺。计划在不久的将来增加来自其他公司(包括惠普)的运营商。
还可以设置私有 UDDI 注册中心。例如,一家大公司可能会建立自己的私有 UDDI 注册中心来注册所有内部 Web 服务。由于这些注册中心不会自动与根 UDDI 节点同步,因此它们不被视为 UDDI 云的一部分。
UDDI-数据模型
UDDI 包括描述以下数据结构的 XML 模式 -
- 商业实体
- 商业服务
- 绑定模板
- 模型
- 发布者断言
业务实体数据结构
业务实体结构代表Web服务的提供者。在 UDDI 注册中心中,该结构包含有关公司本身的信息,包括联系信息、行业类别、业务标识符以及提供的服务列表。
以下是虚构企业 UDDI 注册表项的示例 -
<businessEntity businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40" operator = "http://www.ibm.com" authorizedName = "John Doe"> <name>Acme Company</name> <description> We create cool Web services </description> <contacts> <contact useType = "general info"> <description>General Information</description> <personName>John Doe</personName> <phone>(123) 123-1234</phone> <email>jdoe@acme.com</email> </contact> </contacts> <businessServices> ... </businessServices> <identifierBag> <keyedReference tModelKey = "UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" name = "D-U-N-S" value = "123456789" /> </identifierBag> <categoryBag> <keyedReference tModelKey = "UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" name = "NAICS" value = "111336" /> </categoryBag> </businessEntity>
业务服务数据结构
业务服务结构代表业务实体提供的单独的Web服务。其描述包括有关如何绑定到 Web 服务、Web 服务是什么类型以及它属于什么分类类别的信息。
以下是 Hello World Web 服务的业务服务结构示例。
<businessService serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A" businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <name>Hello World Web Service</name> <description>A friendly Web service</description> <bindingTemplates> ... </bindingTemplates> <categoryBag /> </businessService>
请注意BusinessKey和serviceKey属性中通用唯一标识符 (UUID) 的使用。每个业务实体和业务服务在所有 UDDI 注册中心中都通过首次输入信息时注册中心分配的 UUID 进行唯一标识。
绑定模板数据结构
绑定模板是对业务服务结构所代表的Web服务的技术描述。单个业务服务可能有多个绑定模板。绑定模板代表 Web 服务的实际实现。
以下是 Hello World 的绑定模板示例。
<bindingTemplate serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A" bindingKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <description>Hello World SOAP Binding</description> <accessPoint URLType = "http">http://localhost:8080</accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904"> <instanceDetails> <overviewDoc> <description> references the description of the WSDL service definition </description> <overviewURL> http://localhost/helloworld.wsdl </overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate>
由于业务服务可能具有多个绑定模板,因此该服务可以指定同一服务的不同实现,每个实现绑定到不同的协议集或不同的网络地址。
tModel 数据结构
tModel 是最后一个核心数据类型,但可能是最难掌握的。tModel 代表技术模型。
tModel 是一种描述存储在 UDDI 注册中心内的各种业务、服务和模板结构的方法。任何抽象概念都可以在 UDDI 中注册为 tModel。例如,如果您定义一个新的 WSDL 端口类型,则可以定义一个 tModel 来表示 UDDI 中的该端口类型。然后,您可以通过将 tModel 与该业务服务的绑定模板之一关联来指定给定的业务服务实现该端口类型。
以下是表示 Hello World 接口端口类型的 tModel 示例。
<tModel tModelKey = "uuid:xyz987..." operator = "http://www.ibm.com" authorizedName = "John Doe"> <name>HelloWorldInterface Port Type</name> <description> An interface for a friendly Web service </description> <overviewDoc> <overviewURL> http://localhost/helloworld.wsdl </overviewURL> </overviewDoc> </tModel>
publisher断言数据结构
这是根据特定关系类型(例如子公司或部门)将两个或多个业务实体结构关联起来的关系结构。
publisherAssertion 结构由三个元素组成:fromKey(第一个businessKey)、toKey(第二个businessKey)和keyedReference。
keyedReference 根据 tModel 中的 keyName keyValue 对指定断言的关系类型,由 tModelKey 唯一引用。
<element name = "publisherAssertion" type = "uddi:publisherAssertion" /> <complexType name = "publisherAssertion"> <sequence> <element ref = "uddi:fromKey" /> <element ref = "uddi:toKey" /> <element ref = "uddi:keyedReference" /> </sequence> </complexType>
UDDI - 接口
如果没有某种方式访问注册表,那么它就毫无用处。UDDI 标准2.0 版指定了两个接口,供服务使用者和服务提供者与注册中心进行交互。
服务消费者使用查询接口来查找服务,服务提供者使用发布者接口来列出服务。
UDDI 接口的核心是UDDI XML 模式定义。它们定义了所有信息流经的基本 UDDI 数据类型。
发布者界面
发布者接口为服务提供商定义了十六种操作来管理其在 UDDI 注册表中的条目 -
get_authToken - 检索授权令牌。所有发布者接口操作都要求随请求提交有效的授权令牌。
Discard_authToken - 告诉 UDDI 注册中心不再接受给定的授权令牌。此步骤相当于退出系统。
save_business - 创建或更新 UDDI 注册表中包含的业务实体信息。
save_service - 创建或更新有关业务实体提供的 Web 服务的信息。
save_binding - 创建或更新有关 Web 服务实现的技术信息。
save_tModel - 创建或更新由 UDDI 注册表管理的抽象概念的注册。
delete_business - 从 UDDI 注册表中完全删除给定的业务实体。
delete_service - 从 UDDI 注册表中完全删除给定的 Web 服务。
delete_binding - 从 UDDI 注册表中删除给定的 Web 服务技术详细信息。
delete_tModel - 从 UDDI 注册表中删除指定的 tModel。
get_registeredInfo - 返回 UDDI 注册中心当前为用户跟踪的所有内容的摘要,包括所有业务、所有服务和所有 tModel。
set_publisherAssertions - 管理与单个发布者帐户关联的所有跟踪关系断言。
add_publisherAssertions - 导致一个或多个publisherAssertions 添加到单个发布者的断言集合中。
delete_publisherAssertions - 导致从发布者的断言集合中删除一个或多个publisherAssertion 元素。
get_assertionStatusReport - 提供管理支持,以确定当前和未决的发布者断言的状态,这些断言涉及由单个发布者帐户管理的任何商业注册。
get_publisherAssertions - 获取与单个发布者帐户关联的完整发布者断言集。
查询界面
查询接口定义了十个操作,用于搜索 UDDI 注册中心并检索有关特定注册的详细信息 -
find_binding - 返回基于技术绑定信息匹配一组特定条件的 Web 服务列表。
find_business - 返回匹配一组特定条件的业务实体的列表。
find_ltservice - 返回匹配一组特定条件的 Web 服务列表。
find_tModel - 返回匹配一组特定条件的 tModel 列表。
get_bindingDetail - 返回特定 Web 服务绑定模板的完整注册信息。
get_businessDetail - 返回业务实体的注册信息,包括实体提供的所有服务。
get_businessDetailExt - 返回商业实体的完整注册信息。
get_serviceDetail - 返回 Web 服务的完整注册信息。
get_tModelDetail - 返回 tModel 的完整注册信息。
find_latedBusinesses - 发现通过 uddi-org:relationships 模型相关的企业。
UDDI - 使用示例
假设某公司 XYZ 想要向 UDDI 注册其联系信息、服务描述和在线服务访问信息。以下步骤是必要的 -
选择与之合作的运营商。每个运营商都有不同的条款和条件来授权访问其注册表副本。
构建或以其他方式获取 UDDI 客户端,例如运营商提供的客户端。
从运营商处获取身份验证令牌。
登记有关业务的信息。包含尽可能多的信息,这些信息可能对搜索匹配的人有帮助。
释放身份验证令牌。
使用查询 API 测试信息的检索,包括绑定模板信息,以确保获取信息的人可以成功使用它与您的服务进行交互。
填写 tModel 信息,以防有人想要搜索给定服务并找到您的企业作为服务提供商之一。
根据需要更新信息以反映不断变化的业务联系信息和新的服务详细信息,每次从运营商获取和发布新的身份验证令牌。每当您需要更新或修改您已注册的数据时,您必须返回到您输入数据的运营商处。
以下示例将展示 XYZ 公司如何注册其信息,以及对销售 XYZ 产品线感兴趣的分销商如何使用 XYZ.com Web 服务查找有关如何联系该公司并下订单的信息。
创建注册表
例如,在从 Microsoft 运营商之一获取身份验证令牌后,XYZ.com 开发人员决定将哪些信息发布到注册表并使用 Microsoft 提供的 UDDI 工具之一。如果需要,开发人员还可以编写 Java、C# 或 VB.NET 程序来生成适当的 SOAP 消息。这是一个例子。
POST /save_business HTTP/1.1 Host: www.XYZ.com Content-Type: text/xml; charset = "utf-8" Content-Length: nnnn SOAPAction: "save_business" <?xml version = "1.0" encoding = "UTF-8" ?> <Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/"> <Body> <save_business generic = "2.0" xmlns = "urn:uddi-org:api_v2"> <businessKey = ""> </businessKey> <name> XYZ, Pvt Ltd. </name> <description> Company is involved in giving Stat-of-the-art.... </description> <identifierBag> ... </identifierBag> ... </save_business> </Body> </Envelope>
此示例说明了请求为 XYZ 公司注册 UDDI 业务实体的 SOAP 消息。key 元素为空,因为操作符会自动生成数据结构的 UUID 键。为了显示一个简单的示例,省略了大多数字段。
公司 XYZ 始终可以执行另一个 save_business 操作来添加创建业务实体所需的基本信息。
检索信息
XYZ 公司用相关信息更新其 UDDI 条目后,想要成为 XYZ 分销商的公司可以在 UDDI 注册表中查找联系信息,并获取 XYZ.com 在线发布的两个 Web 服务的服务描述和访问点订单输入:季前批量订单和旺季补货订单。
此示例说明了获取有关 XYZ 公司的业务详细信息的示例 SOAP 请求。一旦您知道已注册的特定企业的 UUID 或密钥,您就可以在 get_businessDetail API 中使用它来返回有关该企业的特定信息。
POST /get_businessDetail HTTP/1.1 Host: www.XYZ.com Content-Type: text/xml; charset = "utf-8" Content-Length: nnnn SOAPAction: "get_businessDetail" <?xml version = "1.0" encoding = "UTF-8" ?> <Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/"> <Body> <get_businessDetail generic = "2.0" xmlns = "urn:uddi-org:api_v2"> <businessKey = "C90D731D-772HSH-4130-9DE3-5303371170C2"> </businessKey> </get_businessDetail> </Body> </Envelope>
带有 WSDL 的 UDDI
UDDI 数据模型定义了用于存储有关业务及其发布的 Web 服务的信息的通用结构。UDDI数据模型是完全可扩展的,包括多个重复的信息序列结构。
然而,WSDL 用于描述 Web 服务的接口。WSDL 与 UDDI 一起使用相当简单。
WSDL 使用businessService、bindingTemplate和tModel信息的组合在UDDI 中表示。
与在 UDDI 中注册的任何服务一样,有关服务的一般信息存储在BusinessService数据结构中,而特定于访问服务的方式和位置的信息则存储在一个或多个关联的BindingTemplate结构中。每个BindingTemplate结构都包含一个元素,该元素包含服务的网络地址,并具有与其关联的一个或多个描述和唯一标识服务的tModel结构。
当 UDDI 用于存储 WSDL 信息或指向 WSDL 文件的指针时,按照惯例, tModel应称为wsdlSpec类型,这意味着overviewDoc元素被明确标识为指向 WSDL 服务接口定义。
对于 UDDI,WSDL 内容分为两个主要元素:接口文件和实现文件。
Hertz 预订系统 Web 服务提供了 UDDI 和 WSDL 如何协同工作的具体示例。这是此 Web 服务的 <tModel> -
<tModel authorizedName = "..." operator = "..." tModelKey = "..."> <name>HertzReserveService</name> <description xml:lang = "en"> WSDL description of the Hertz reservation service interface </description> <overviewDoc> <description xml:lang = "en"> WSDL source document. </description> <overviewURL> http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey = "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName = "uddi-org:types" keyValue = "wsdlSpec"/> </categoryBag> </tModel>
关键点是 -
overviewURL 元素给出了可以找到服务接口定义 WSDL 文件的 URL。这使得人类和 UDDI/WSDL 感知工具能够定位服务接口定义。
categoryBag 中 keyedReference 元素的用途是确保此 tModel 被分类为 WSDL 规范文档。
UDDI - 实施
当前有多种 UDDI 实现可用。这些实现使搜索或发布 UDDI 数据变得更加容易,而不会陷入 UDDI API 的复杂性之中。以下是可用的主要 UDDI 实现的简要概述。
Java 实现
Java 有两种 UDDI 实现。
UDDI4J(UDDI for Java) - UDDI4J 最初由 IBM 创建。2001 年 1 月,IBM 将代码移交给自己的开源网站。UDDI4J 是一个 Java 类库,提供与 UDDI 交互的 API。
jUDDI - jUDDI 是 UDDI 注册表的开源 Java 实现和用于访问 UDDI 服务的工具包。
Perl 实现
UDDI::Lite - 它提供了用于查询和发布的基本 UDDI 客户端。
Ruby实施
UDDI4r - 它提供了一个用于查询和发布的基本 UDDI 客户端。
Python实现
UDDI4Py - UDDI4Py 是一个 Python 包,允许向 UDDI 版本 2 API 发送请求并处理来自 UDDI 版本 2 API 的响应。
UDDI - 规范
UDDI 项目还定义了一组 XML 模式定义,用于描述各种规范 API 使用的数据格式。这些文件均可在www.uddi.org上下载。所有规范组的当前版本是版本2.0。
规格包括以下内容 -
- UDDI 复制,
- UDDI 运营商,
- UDDI 程序员的 API,以及
- UDDI数据结构
UDDI复制
本文档描述了注册管理运行机构必须遵守的数据复制流程和接口,以实现站点之间的数据复制。本规范不是程序员的 API;它定义了UBR节点之间使用的复制机制。
UDDI运营商
本文档概述了 UDDI 节点操作员所需的Behave和操作参数。该规范定义了操作员必须遵守的数据管理要求。
UDDI 程序员的 API
该规范定义了所有 UDDI 注册中心都支持的一组函数,用于查询注册中心中托管的服务以及向注册中心发布有关业务或服务的信息。该规范定义了一系列 SOAP 消息,其中包含 UDDI 注册中心接受、解析和响应的 XML 文档。该规范与 UDDI XML API 模式和 UDDI 数据结构规范一起构成了 UDDI 注册中心的完整编程接口。
UDDI数据结构
该规范涵盖了由 UDDI 程序员的 API 定义的 SOAP 消息中包含的 XML 结构的细节。该规范定义了五种核心数据结构及其相互关系。
UDDI XML API 模式不包含在规范中;相反,它存储为定义 UDDI 数据结构的结构和数据类型的 XML 模式文档。
UDDI - 摘要
在本教程中,您还了解了 UDDI 及其元素,并了解了 UDDI 的完整体系结构和数据模型。
我们已经了解了两个UDDI接口:发布者接口和查询接口。我们还学习了如何使用 UDDI 注册和搜索 Web 服务。
下一步是什么?
下一步是了解 SOAP、WSDL 和 Web 服务。
肥皂
SOAP 是一种简单的基于 XML 的协议,允许应用程序通过 HTTP 交换信息。
如果您想了解有关 SOAP 的更多信息,请访问我们的SOAP 教程。
WSDL
WSDL 是用于以 XML 格式描述 Web 服务的标准格式。
WSDL 是 UDDI 的一个组成部分。
如果您想了解有关 WSDL 的更多信息,请访问我们的WSDL 教程。
网页服务
Web 服务可以将您的应用程序转换为 Web 应用程序。
如果您想了解有关 Web 服务的更多信息,请访问我们的Web 服务教程。
UDDI - API 快速参考
以下是 UDDI 查询 API 和 UDDI 发布 API 的完整参考。
UDDI 查询 API
API名称 | 描述 | V1.0 | V2.0 |
---|---|---|---|
查找绑定 | 搜索与指定服务关联的模板绑定。 | 是 | 是 |
查找业务 | 搜索符合指定条件的企业。 | 是 | 是 |
查找相关企业 | 发现通过 uddi-org:relationships 模型关联的业务。 | 是 | |
查找服务 | 搜索与指定企业关联的服务。 | 是 | 是 |
查找模型 | 搜索与指定条件匹配的 tModel 记录。 | 是 | 是 |
获取绑定详细信息 | 检索每个指定的绑定密钥的完整绑定模板。 | 是 | 是 |
获取业务详细信息 | 检索每个指定的businessKey 的完整businessEntity。 | 是 | 是 |
获取业务详细信息Ext | 检索每个指定的businessKey 的扩展businessEntity。 | 是 | 是 |
获取服务详细信息 | 检索每个指定 serviceKey 的businessService 记录。 | 是 | 是 |
获取模型详细信息 | 检索每个指定 tModelKey 的 tModel 记录。 | 是 | 是 |
UDDI 发布 API
API名称 | 描述 | V1.0 | V2.0 |
---|---|---|---|
获取authToken | 检索授权令牌。所有发布者接口操作都要求随请求提交有效的授权令牌。 | 是 | 是 |
丢弃_authToken | 告诉 UDDI 注册中心不再接受给定的授权令牌。此步骤相当于退出系统。 | 是 | 是 |
保存业务 | 创建或更新 UDDI 注册表中包含的业务实体信息。 | 是 | 是 |
保存服务 | 创建或更新有关业务实体提供的 Web 服务的信息。 | 是 | 是 |
保存绑定 | 创建或更新有关 Web 服务实施的技术信息。 | 是 | 是 |
保存模型 | 创建或更新由 UDDI 注册中心管理的抽象概念的注册。 | 是 | 是 |
删除_业务 | 从 UDDI 注册表中完全删除给定的业务实体。 | 是 | 是 |
删除服务 | 从 UDDI 注册表中完全删除给定的 Web 服务。 | 是 | 是 |
删除绑定 | 从 UDDI 注册表中删除给定的 Web 服务技术详细信息。 | 是 | 是 |
删除_t模型 | 从 UDDI 注册表中删除指定的 tModel。 | 是 | 是 |
获取注册信息 | 返回 UDDI 注册中心当前为用户跟踪的所有内容的摘要,包括所有业务、所有服务和所有 tModel。 | 是 | 是 |
set_publisher断言 | 管理与单个发布者帐户关联的所有跟踪关系断言。 | 是 | |
add_publisher断言 | 导致将一个或多个publisherAssertions 添加到单个发布者的断言集合中。 | 是 | |
删除_publisher断言 | 导致从发布者的断言集合中删除一个或多个publisherAssertion 元素。 | 是 | |
get_assertionStatusReport | 提供管理支持,以确定当前和未决的发布者声明的状态,这些声明涉及由单个发布者帐户管理的任何商业注册。 | 是 | |
获取发布者断言 | 获取与单个发布者帐户关联的完整发布者断言集。 | 是 |
错误码参考
UDDI API 返回的错误代码的完整参考如下: