- 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 返回的錯誤程式碼的完整參考如下所示: