- UDDI 教程
- UDDI - 首页
- UDDI - 概述
- UDDI - 元素
- UDDI - 技术架构
- UDDI - 数据模型
- UDDI - 接口
- UDDI - 使用示例
- UDDI 与 WSDL
- UDDI - 实现
- UDDI - 规范
- UDDI - 总结
- UDDI API 参考
- UDDI - API 快速参考
- UDDI 有用资源
- UDDI - 快速指南
- UDDI - 有用资源
- UDDI - 讨论
UDDI - 快速指南
UDDI - 概述
UDDI 是一种基于 XML 的标准,用于描述、发布和查找 Web 服务。
UDDI 代表 **通用描述、发现和集成**。
UDDI 是 Web 服务分布式注册表的规范。
UDDI 是一个平台无关的开放框架。
UDDI 可以通过 SOAP、CORBA、Java RMI 协议进行通信。
UDDI 使用 Web 服务定义语言 (WSDL) 来描述 Web 服务的接口。
UDDI 与 SOAP 和 WSDL 一起被视为 Web 服务的三大基础标准之一。
UDDI 是一项开放的行业倡议,使企业能够相互发现并定义如何在互联网上进行交互。
UDDI 包含两个部分:
所有 Web 服务元数据的注册表,包括指向服务 WSDL 描述的指针。
用于操作和搜索该注册表的一组 WSDL 端口类型定义。
UDDI 的历史
UDDI 1.0 最初由微软、IBM 和 Ariba 于 2000 年 9 月宣布。
自最初宣布以来,UDDI 倡议已发展到包括 300 多家公司,包括戴尔、富士通、惠普、日立、IBM、英特尔、微软、甲骨文、SAP 和 Sun。
2001 年 5 月,微软和 IBM 启动了第一个 UDDI 运营商站点,并使 UDDI 注册表上线。
2001 年 6 月,UDDI 宣布了 2.0 版。
在撰写本教程时,微软和 IBM 站点已实施了 1.0 规范,并计划在不久的将来支持 2.0。
目前 UDDI 由 OASIS 赞助。
合作伙伴接口流程
合作伙伴接口流程 (PIP) 是基于 XML 的接口,使两个贸易伙伴能够交换数据。已经存在数十个 PIP。其中一些列出如下:
**PIP2A2** - 使合作伙伴能够查询另一个合作伙伴的产品信息。
**PIP3A2** - 使合作伙伴能够查询特定产品的价格和可用性。
**PIP3A4** - 使合作伙伴能够提交电子采购订单并接收订单确认。
**PIP3A3** - 使合作伙伴能够传输电子购物车的内容。
**PIP3B4** - 使合作伙伴能够查询特定货件的状态。
私有 UDDI 注册表
作为使用互联网上可用的 UDDI 注册表公共联合网络的替代方案,公司或行业集团可以选择实施自己的私有 UDDI 注册表。
这些独家服务旨在用于允许公司或行业集团的成员相互共享和宣传服务。
无论 UDDI 注册表是全球联合网络的一部分还是私有注册表,将它们联系在一起的一件事是发布和定位 UDDI 注册表中宣传的企业和服务的通用 Web 服务 API。
UDDI - 元素
企业或公司可以将三种类型的信息注册到 UDDI 注册表中。此信息包含在 UDDI 的三个元素中。
这三个元素是:
- 白页,
- 黄页,以及
- 绿页。
白页
白页包含:
有关公司及其业务的基本信息。
基本联系信息,包括公司名称、地址、联系电话等。
公司的唯一标识符,例如税务 ID。此信息允许其他人根据您的业务标识发现您的 Web 服务。
黄页
黄页包含有关公司的更多详细信息。它们包括对公司可以向任何想要与其开展业务的人提供的电子功能的描述。
黄页使用普遍接受的行业分类方案、行业代码、产品代码、业务识别代码等,使公司更容易搜索列表并准确找到他们想要的内容。
绿页
绿页包含有关 Web 服务的技术信息。绿页允许在找到 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 架构,用于描述以下数据结构:
- businessEntity
- businessService
- bindingTemplate
- tModel
- publisherAssertion
businessEntity 数据结构
业务实体结构表示 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>
businessService 数据结构
业务服务结构表示业务实体提供的单个 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 唯一标识。
bindingTemplate 数据结构
绑定模板是业务服务结构表示的 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">https://:8080</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
<instanceDetails>
<overviewDoc>
<description>
references the description of the WSDL service definition
</description>
<overviewURL>
https:///helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
由于业务服务可能有多个绑定模板,因此服务可以指定相同服务的不同实现,每个实现都绑定到一组不同的协议或不同的网络地址。
tModel 数据结构
tModel 是最后一个核心数据类型,但可能是最难理解的。tModel 代表技术模型。
tModel 是一种描述存储在 UDDI 注册表中的各种业务、服务和模板结构的方法。任何抽象概念都可以作为 tModel 注册到 UDDI 中。例如,如果您定义了一个新的 WSDL 端口类型,则可以定义一个表示 UDDI 中该端口类型的 tModel。然后,您可以通过将 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>
https:///helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>
publisherAssertion 数据结构
这是一种关系结构,根据特定类型的关系(例如子公司或部门)将两个或多个 businessEntity 结构关联起来。
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 数据类型。
发布者接口
发布者接口定义了 16 个操作,供服务提供者管理其在 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_relatedBusinesses − 发现通过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消息。密钥元素为空白,因为操作员会自动为数据结构生成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>
UDDI与WSDL
UDDI数据模型定义了一个用于存储有关业务及其发布的Web服务的信息的通用结构。UDDI数据模型是完全可扩展的,包括多个重复的信息序列结构。
但是,WSDL用于描述Web服务的接口。WSDL在UDDI中使用起来相当简单。
WSDL在UDDI中使用businessService、bindingTemplate和tModel信息的组合来表示。
与在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(Java的UDDI) − 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 - 规范
UDDI项目还定义了一组XML Schema定义,用于描述各种规范API使用的数据格式。所有这些文档都可以在www.uddi.org上下载。所有规范组的当前版本为2.0版。
规范包括以下内容 -
- UDDI复制,
- UDDI操作员,
- UDDI程序员API,以及
- UDDI数据结构
UDDI复制
本文档描述了注册中心操作员必须符合的数据复制流程和接口,以实现站点之间的数据复制。此规范不是程序员API;它定义了UBR节点之间使用的复制机制。
UDDI操作员
本文档概述了UDDI节点操作员所需的运行行为和操作参数。此规范定义了操作员必须遵守的数据管理要求。
UDDI程序员API
本规范定义了一组所有 UDDI 注册中心都支持的功能,这些功能用于查询注册中心中托管的服务,以及将有关业务或服务的信息发布到注册中心。本规范定义了一系列包含 XML 文档的 SOAP 消息,UDDI 注册中心接受、解析并响应这些消息。本规范连同 UDDI XML API 架构和 UDDI 数据结构规范一起构成了 UDDI 注册中心的完整编程接口。
UDDI数据结构
本规范涵盖了 UDDI 程序员 API 定义的 SOAP 消息中包含的 XML 结构的具体细节。本规范定义了五个核心数据结构及其相互关系。
UDDI XML API 架构未包含在规范中;相反,它存储为一个 XML 架构文档,该文档定义了 UDDI 数据结构的结构和数据类型。
UDDI - 总结
本教程中介绍了 UDDI 及其元素,并且还了解了 UDDI 的完整架构和数据模型。
我们已经学习了两个 UDDI 接口:发布者接口和查询接口。我们还学习了如何使用 UDDI 注册和搜索 Web 服务。
下一步是什么?
下一步是了解 SOAP、WSDL 和 Web 服务。
SOAP
SOAP 是一种简单的基于 XML 的协议,允许应用程序通过 HTTP 交换信息。
如果您想了解更多关于 SOAP 的信息,请访问我们的 SOAP 教程。
WSDL
WSDL 是用 XML 格式描述 Web 服务的标准格式。
WSDL 是 UDDI 不可或缺的一部分。
如果您想了解更多关于 WSDL 的信息,请访问我们的 WSDL 教程。
Web 服务
Web 服务可以将您的应用程序转换为 Web 应用程序。
如果您想了解更多关于 Web 服务的信息,请访问我们的 Web 服务教程。
UDDI - API 快速参考
以下是 UDDI 查询 API 和 UDDI 发布 API 的完整参考。
UDDI 查询 API
| API 名称 | 描述 | V1.0 | V2.0 |
|---|---|---|---|
| find_binding | 搜索与指定服务关联的模板绑定。 | 是 | 是 |
| find_business | 搜索与指定条件匹配的业务。 | 是 | 是 |
| find_relatedBusinesses | 发现通过 uddi-org:relationships 模型关联的业务。 | 是 | |
| find_service | 搜索与指定业务关联的服务。 | 是 | 是 |
| find_tModel | 搜索与指定条件匹配的 tModel 记录。 | 是 | 是 |
| get_bindingDetail | 检索每个指定 bindingKey 的完整 bindingTemplate。 | 是 | 是 |
| get_businessDetail | 检索每个指定 businessKey 的完整 businessEntity。 | 是 | 是 |
| get_businessDetailExt | 检索每个指定 businessKey 的扩展 businessEntity。 | 是 | 是 |
| get_serviceDetail | 检索每个指定 serviceKey 的 businessService 记录。 | 是 | 是 |
| get_tModelDetail | 检索每个指定 tModelKey 的 tModel 记录。 | 是 | 是 |
UDDI 发布 API
| API 名称 | 描述 | V1.0 | V2.0 |
|---|---|---|---|
| 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 API 返回的错误代码的完整参考如下所示: