UDDI - Hướng dẫn nhanh
UDDI là một tiêu chuẩn dựa trên XML để mô tả, xuất bản và tìm kiếm các dịch vụ web.
UDDI là viết tắt của Universal Description, Discovery, and Integration.
UDDI là một đặc tả cho một đăng ký phân tán của các dịch vụ web.
UDDI là một khuôn khổ mở, độc lập với nền tảng.
UDDI có thể giao tiếp qua SOAP, CORBA, Java RMI Protocol.
UDDI sử dụng Ngôn ngữ Định nghĩa Dịch vụ Web (WSDL) để mô tả các giao diện với các dịch vụ web.
UDDI được xem cùng với SOAP và WSDL là một trong ba tiêu chuẩn nền tảng của các dịch vụ web.
UDDI là một sáng kiến trong ngành công nghiệp mở, cho phép các doanh nghiệp khám phá lẫn nhau và xác định cách họ tương tác qua Internet.
UDDI có hai phần -
Sổ đăng ký của tất cả siêu dữ liệu của dịch vụ web, bao gồm một con trỏ đến mô tả WSDL của một dịch vụ.
Một tập hợp các định nghĩa loại cổng WSDL để thao tác và tìm kiếm sổ đăng ký đó.
Lịch sử của UDDI
UDDI 1.0 ban đầu được Microsoft, IBM và Ariba công bố vào tháng 9 năm 2000.
Kể từ khi công bố ban đầu, sáng kiến UDDI đã phát triển bao gồm hơn 300 công ty bao gồm Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP và Sun.
Vào tháng 5 năm 2001, Microsoft và IBM đã khởi chạy các trang web điều hành UDDI đầu tiên và biến sổ đăng ký UDDI hoạt động.
Vào tháng 6 năm 2001, UDDI đã công bố Phiên bản 2.0.
Vào thời điểm viết hướng dẫn này, các trang của Microsoft và IBM đã triển khai đặc tả 1.0 và đang lên kế hoạch hỗ trợ 2.0 trong tương lai gần.
Hiện tại UDDI được tài trợ bởi OASIS.
Quy trình giao diện đối tác
Quy trình giao diện đối tác (PIP) là giao diện dựa trên XML cho phép hai đối tác thương mại trao đổi dữ liệu. Hàng chục PIP đã tồn tại. Một số trong số chúng được liệt kê ở đây -
PIP2A2 - Cho phép đối tác truy vấn đối tác khác về thông tin sản phẩm.
PIP3A2 - Cho phép đối tác truy vấn giá cả và tính khả dụng của các sản phẩm cụ thể.
PIP3A4 - Cho phép đối tác gửi đơn đặt hàng điện tử và nhận xác nhận đơn đặt hàng.
PIP3A3 - Cho phép đối tác chuyển nội dung của giỏ hàng điện tử.
PIP3B4 - Cho phép đối tác truy vấn trạng thái của một lô hàng cụ thể.
Đăng ký UDDI riêng
Để thay thế cho việc sử dụng mạng lưới đăng ký UDDI được liên kết công khai có sẵn trên Internet, các công ty hoặc nhóm ngành có thể chọn triển khai các đăng ký UDDI riêng của họ.
Các dịch vụ độc quyền này được thiết kế với mục đích duy nhất là cho phép các thành viên của công ty hoặc của nhóm ngành chia sẻ và quảng cáo các dịch vụ với nhau.
Bất kể sổ đăng ký UDDI là một phần của mạng liên kết toàn cầu hay cơ quan đăng ký do tư nhân sở hữu và điều hành, một thứ liên kết tất cả chúng lại với nhau là một API dịch vụ web chung để xuất bản và định vị các doanh nghiệp và dịch vụ được quảng cáo trong sổ đăng ký UDDI.
Một doanh nghiệp hoặc một công ty có thể đăng ký ba loại thông tin vào một cơ quan đăng ký UDDI. Thông tin này được chứa trong ba phần tử của UDDI.
Ba yếu tố này là -
- Trang trắng,
- Trang vàng và
- Trang xanh.
Trang trắng
Trang trắng chứa -
Thông tin cơ bản về công ty và hoạt động kinh doanh của công ty.
Thông tin liên hệ cơ bản bao gồm tên doanh nghiệp, địa chỉ, số điện thoại liên hệ, v.v.
Số nhận dạng duy nhất cho ID thuế của công ty. Thông tin này cho phép người khác khám phá dịch vụ web của bạn dựa trên nhận dạng doanh nghiệp của bạn.
Những trang vàng
Các trang màu vàng chứa nhiều thông tin chi tiết hơn về công ty. Chúng bao gồm các mô tả về loại khả năng điện tử mà công ty có thể cung cấp cho bất kỳ ai muốn kinh doanh với nó.
Các trang màu vàng sử dụng các sơ đồ phân loại công nghiệp, mã ngành, mã sản phẩm, mã nhận dạng doanh nghiệp và những thứ tương tự được chấp nhận phổ biến để giúp các công ty dễ dàng tìm kiếm trong danh sách và tìm thấy chính xác những gì họ muốn.
Trang xanh
Các trang màu xanh lá cây chứa thông tin kỹ thuật về một dịch vụ web. Một trang màu xanh lá cây cho phép ai đó liên kết với một dịch vụ Web sau khi nó được tìm thấy. Nó bao gồm -
- Các giao diện khác nhau
- Vị trí URL
- Thông tin khám phá và dữ liệu tương tự cần thiết để tìm và chạy dịch vụ Web.
NOTE- UDDI không bị giới hạn trong việc mô tả các dịch vụ web dựa trên SOAP. Đúng hơn, UDDI có thể được sử dụng để mô tả bất kỳ dịch vụ nào, từ một trang web hoặc địa chỉ email cho đến các dịch vụ SOAP, CORBA và Java RMI.
Kiến trúc kỹ thuật UDDI bao gồm ba phần:
Mô hình dữ liệu UDDI
Mô hình dữ liệu UDDI là một Lược đồ XML để mô tả các doanh nghiệp và dịch vụ web. Mô hình dữ liệu được mô tả chi tiết trong chương "Mô hình dữ liệu UDDI".
Đặc điểm kỹ thuật API UDDI
Nó là một đặc điểm kỹ thuật của API để tìm kiếm và xuất bản dữ liệu UDDI.
Dịch vụ đám mây UDDI
Đây là các trang web của nhà điều hành cung cấp triển khai đặc tả UDDI và đồng bộ hóa tất cả dữ liệu theo lịch trình.
Cơ quan đăng ký doanh nghiệp UDDI (UBR), còn được gọi là Đám mây công cộng, là một hệ thống đơn lẻ về mặt khái niệm được xây dựng từ nhiều nút có dữ liệu của chúng được đồng bộ hóa thông qua sao chép.
Các dịch vụ đám mây hiện tại cung cấp một thư mục tập trung về mặt vật lý, nhưng phân tán vật lý. Nó có nghĩa là dữ liệu được gửi đến một nút gốc sẽ tự động được sao chép trên tất cả các nút gốc khác. Hiện tại, việc sao chép dữ liệu diễn ra sau mỗi 24 giờ.
Các dịch vụ đám mây UDDI hiện được cung cấp bởi Microsoft và IBM. Ariba ban đầu cũng có kế hoạch cung cấp một nhà điều hành, nhưng kể từ đó đã từ chối cam kết. Các nhà khai thác bổ sung từ các công ty khác, bao gồm Hewlett-Packard, được lên kế hoạch cho tương lai gần.
Cũng có thể thiết lập các đăng ký UDDI riêng. Ví dụ, một công ty lớn có thể thiết lập sổ đăng ký UDDI riêng để đăng ký tất cả các dịch vụ web nội bộ. Vì các đăng ký này không được đồng bộ hóa tự động với các nút UDDI gốc, chúng không được coi là một phần của đám mây UDDI.
UDDI bao gồm một Lược đồ XML mô tả các cấu trúc dữ liệu sau:
- businessEntity
- businessService
- bindingTemplate
- tModel
- publisherAssertion
Cấu trúc dữ liệu businessEntity
Cấu trúc thực thể kinh doanh đại diện cho nhà cung cấp dịch vụ web. Trong sổ đăng ký UDDI, cấu trúc này chứa thông tin về chính công ty, bao gồm thông tin liên hệ, danh mục ngành, số nhận dạng doanh nghiệp và danh sách các dịch vụ được cung cấp.
Đây là một ví dụ về mục đăng ký UDDI của một doanh nghiệp hư cấu -
<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>[email protected]</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 Data Structure
Cấu trúc dịch vụ kinh doanh đại diện cho một dịch vụ web riêng lẻ do tổ chức kinh doanh cung cấp. Mô tả của nó bao gồm thông tin về cách liên kết với dịch vụ web, loại dịch vụ web đó là gì và nó thuộc về các danh mục phân loại nào.
Đây là ví dụ về cấu trúc dịch vụ kinh doanh cho dịch vụ web Hello World.
<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>
Lưu ý việc sử dụng Số nhận dạng duy nhất phổ biến (UUID) trong các thuộc tính businessKey và serviceKey . Mọi thực thể kinh doanh và dịch vụ kinh doanh được xác định duy nhất trong tất cả các đăng ký UDDI thông qua UUID được chỉ định bởi cơ quan đăng ký khi thông tin được nhập lần đầu tiên.
bindTemplate Data Structure
Các mẫu ràng buộc là các mô tả kỹ thuật của các dịch vụ web được đại diện bởi cấu trúc dịch vụ kinh doanh. Một dịch vụ kinh doanh duy nhất có thể có nhiều mẫu ràng buộc. Mẫu liên kết đại diện cho việc triển khai thực tế của dịch vụ web.
Đây là một ví dụ về mẫu ràng buộc cho 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>
Vì một dịch vụ kinh doanh có thể có nhiều mẫu ràng buộc, nên dịch vụ có thể chỉ định các cách triển khai khác nhau của cùng một dịch vụ, mỗi mẫu liên kết với một bộ giao thức khác nhau hoặc một địa chỉ mạng khác nhau.
Cấu trúc dữ liệu tModel
tModel là kiểu dữ liệu cốt lõi cuối cùng, nhưng có khả năng khó nắm bắt nhất. tModel là viết tắt của mô hình kỹ thuật.
tModel là một cách mô tả các cấu trúc kinh doanh, dịch vụ và mẫu khác nhau được lưu trữ trong sổ đăng ký UDDI. Bất kỳ khái niệm trừu tượng nào cũng có thể được đăng ký trong UDDI dưới dạng tModel. Ví dụ: nếu bạn xác định một loại cổng WSDL mới, bạn có thể xác định một tModel đại diện cho loại cổng đó trong UDDI. Sau đó, bạn có thể chỉ định rằng một dịch vụ kinh doanh nhất định sẽ triển khai loại cổng đó bằng cách liên kết tModel với một trong các mẫu ràng buộc của dịch vụ kinh doanh đó.
Đây là một ví dụ về tModel đại diện cho loại cổng Giao diện Hello World.
<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>
publisherAssertion Cấu trúc dữ liệu
Đây là một cấu trúc mối quan hệ đưa vào sự kết hợp hai hoặc nhiều cấu trúc businessEntity theo một loại mối quan hệ cụ thể, chẳng hạn như công ty con hoặc bộ phận.
Cấu trúc publisherAssertion bao gồm ba phần tử: fromKey (businessKey đầu tiên), toKey (businessKey thứ hai) và keyedReference.
KeyedReference chỉ định kiểu quan hệ được xác nhận theo cặp keyName keyValue trong tModel, được tham chiếu duy nhất bởi 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>
Sổ đăng ký sẽ vô ích nếu không có một số cách để truy cập nó. Phiên bản 2.0 tiêu chuẩn UDDI chỉ định hai giao diện để người tiêu dùng dịch vụ và nhà cung cấp dịch vụ tương tác với sổ đăng ký.
Dịch vụ mà người tiêu dùng sử dụng Inquiry Interface để tìm một dịch vụ và các nhà cung cấp dịch vụ sử dụng Publisher Interface để liệt kê một dịch vụ.
Cốt lõi của giao diện UDDI là định nghĩa Lược đồ XML UDDI. Chúng xác định các kiểu dữ liệu UDDI cơ bản mà qua đó tất cả các luồng thông tin.
Giao diện nhà xuất bản
Giao diện Nhà xuất bản xác định mười sáu hoạt động cho nhà cung cấp dịch vụ quản lý các mục nhập của họ trong sổ đăng ký UDDI -
get_authToken- Lấy mã thông báo ủy quyền. Tất cả các hoạt động của giao diện Nhà xuất bản yêu cầu phải gửi mã thông báo ủy quyền hợp lệ cùng với yêu cầu.
discard_authToken- Thông báo cho cơ quan đăng ký UDDI không còn chấp nhận mã thông báo ủy quyền đã cho. Bước này tương đương với việc đăng xuất khỏi hệ thống.
save_business - Tạo hoặc cập nhật thông tin của thực thể kinh doanh có trong sổ đăng ký UDDI.
save_service - Tạo hoặc cập nhật thông tin về các dịch vụ web mà một tổ chức kinh doanh cung cấp.
save_binding - Tạo hoặc cập nhật thông tin kỹ thuật về việc triển khai dịch vụ web.
save_tModel - Tạo hoặc cập nhật đăng ký các khái niệm trừu tượng do cơ quan đăng ký UDDI quản lý.
delete_business - Loại bỏ hoàn toàn các thực thể kinh doanh đã cho khỏi sổ đăng ký UDDI.
delete_service - Loại bỏ hoàn toàn các dịch vụ web đã cho khỏi sổ đăng ký UDDI.
delete_binding - Loại bỏ các chi tiết kỹ thuật của dịch vụ web nhất định khỏi sổ đăng ký UDDI.
delete_tModel - Loại bỏ các tModels được chỉ định khỏi sổ đăng ký UDDI.
get_registeredInfo - Trả về bản tóm tắt mọi thứ mà sổ đăng ký UDDI hiện đang theo dõi cho người dùng, bao gồm tất cả các doanh nghiệp, tất cả các dịch vụ và tất cả các tModels.
set_publisherAssertions - Quản lý tất cả các xác nhận mối quan hệ được theo dõi được liên kết với tài khoản nhà xuất bản cá nhân.
add_publisherAssertions - Khiến một hoặc nhiều publisherAssertions được thêm vào bộ sưu tập xác nhận của từng nhà xuất bản.
delete_publisherAssertions - Khiến một hoặc nhiều phần tử publisherAssertion bị xóa khỏi bộ sưu tập xác nhận của nhà xuất bản.
get_assertionStatusReport - Cung cấp hỗ trợ quản trị để xác định trạng thái của xác nhận nhà xuất bản hiện tại và chưa xuất hiện liên quan đến bất kỳ đăng ký kinh doanh nào được quản lý bởi tài khoản nhà xuất bản cá nhân.
get_publisherAssertions - Nhận toàn bộ xác nhận của nhà xuất bản được liên kết với tài khoản nhà xuất bản cá nhân.
Giao diện yêu cầu
Giao diện truy vấn xác định mười hoạt động để tìm kiếm sổ đăng ký UDDI và truy xuất chi tiết về các đăng ký cụ thể -
find_binding - Trả về danh sách các dịch vụ web phù hợp với một bộ tiêu chí cụ thể dựa trên thông tin ràng buộc kỹ thuật.
find_business - Trả về danh sách các thực thể kinh doanh phù hợp với một bộ tiêu chí cụ thể.
find_ltservice - Trả về danh sách các dịch vụ web phù hợp với một bộ tiêu chí cụ thể.
find_tModel - Trả về danh sách các tModels phù hợp với một bộ tiêu chí cụ thể.
get_bindingDetail - Trả về thông tin đăng ký đầy đủ cho một mẫu ràng buộc dịch vụ web cụ thể.
get_businessDetail - Trả về thông tin đăng ký cho một thực thể kinh doanh, bao gồm tất cả các dịch vụ mà thực thể đó cung cấp.
get_businessDetailExt - Trả về thông tin đăng ký đầy đủ cho một thực thể kinh doanh.
get_serviceDetail - Trả về thông tin đăng ký đầy đủ cho một dịch vụ web.
get_tModelDetail - Trả về thông tin đăng ký đầy đủ cho một tModel.
find_relatedBusinesses - Khám phá các doanh nghiệp có liên quan thông qua mô hình uddi-org: Mối quan hệ.
Hãy xem xét một công ty XYZ muốn đăng ký thông tin liên hệ, mô tả dịch vụ và thông tin truy cập dịch vụ trực tuyến với UDDI. Các bước sau là cần thiết:
Chọn một nhà điều hành để làm việc. Mỗi nhà điều hành có các điều khoản và điều kiện khác nhau để cho phép truy cập vào bản sao sổ đăng ký.
Xây dựng hoặc lấy một ứng dụng khách UDDI, chẳng hạn như những ứng dụng được cung cấp bởi các nhà khai thác.
Nhận mã thông báo xác thực từ nhà điều hành.
Đăng ký thông tin về doanh nghiệp. Bao gồm nhiều thông tin có thể hữu ích cho những người đang tìm kiếm kết quả phù hợp.
Phát hành mã thông báo xác thực.
Sử dụng các API truy vấn để kiểm tra việc truy xuất thông tin, bao gồm cả thông tin mẫu ràng buộc, để đảm bảo rằng ai đó có được thông tin đó có thể sử dụng thành công để tương tác với dịch vụ của bạn.
Điền thông tin tModel trong trường hợp ai đó muốn tìm kiếm một dịch vụ nhất định và thấy doanh nghiệp của bạn là một trong những nhà cung cấp dịch vụ.
Cập nhật thông tin khi cần thiết để phản ánh thông tin liên hệ kinh doanh thay đổi và chi tiết dịch vụ mới, lấy và phát hành mã xác thực mới từ nhà điều hành mỗi lần. Bất cứ khi nào bạn cần cập nhật hoặc sửa đổi dữ liệu bạn đã đăng ký, bạn phải quay lại nhà điều hành mà bạn đã nhập dữ liệu.
Các ví dụ sau sẽ cho thấy cách Công ty XYZ đăng ký thông tin của mình và cách nhà phân phối quan tâm đến việc mang dòng sản phẩm của XYZ có thể tìm thấy thông tin về cách liên hệ với công ty và đặt hàng, sử dụng các dịch vụ Web của XYZ.com.
Tạo sổ đăng ký
Sau khi nhận được mã xác thực từ một trong các nhà khai thác Microsoft, chẳng hạn như các nhà phát triển XYZ.com quyết định thông tin nào sẽ xuất bản lên sổ đăng ký và sử dụng một trong các công cụ UDDI do Microsoft cung cấp. Nếu cần, các nhà phát triển cũng có thể viết một chương trình Java, C # hoặc VB.NET để tạo các thông báo SOAP thích hợp. Đây là một ví dụ.
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>
Ví dụ này minh họa một thông báo SOAP yêu cầu đăng ký một thực thể kinh doanh UDDI cho Công ty XYZ. Phần tử khóa trống vì toán tử tự động tạo khóa UUID cho cấu trúc dữ liệu. Hầu hết các trường bị bỏ qua vì mục đích hiển thị một ví dụ đơn giản.
Công ty XYZ luôn có thể thực hiện một hoạt động save_business khác để thêm vào thông tin cơ bản cần thiết để tạo một thực thể kinh doanh.
Lấy thông tin
Sau khi Công ty XYZ đã cập nhật mục UDDI của mình với thông tin liên quan, các công ty muốn trở thành nhà phân phối của XYZ có thể tra cứu thông tin liên hệ trong sổ đăng ký UDDI và lấy mô tả dịch vụ và điểm truy cập cho hai dịch vụ Web mà XYZ.com xuất bản trực tuyến nhập đơn hàng: đơn đặt hàng số lượng lớn trước mùa giải và đơn đặt hàng còn lại trong mùa.
Ví dụ này minh họa một yêu cầu SOAP mẫu để lấy thông tin chi tiết kinh doanh về Công ty XYZ. Khi bạn biết UUID hoặc khóa, cho doanh nghiệp cụ thể đã được đăng ký, bạn có thể sử dụng nó trong API get_businessDetail để trả về thông tin cụ thể về doanh nghiệp đó.
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>
Mô hình dữ liệu UDDI xác định một cấu trúc chung để lưu trữ thông tin về một doanh nghiệp và các dịch vụ web mà nó xuất bản. Mô hình dữ liệu UDDI hoàn toàn có thể mở rộng, bao gồm một số cấu trúc trình tự lặp lại của thông tin.
Tuy nhiên, WSDL được sử dụng để mô tả giao diện của một dịch vụ web. WSDL khá dễ sử dụng với UDDI.
WSDL được biểu diễn trong UDDI bằng cách sử dụng kết hợp thông tin businessService, bindingTemplate và tModel .
Như với bất kỳ dịch vụ nào được đăng ký trong UDDI, thông tin chung về dịch vụ được lưu trữ trong cấu trúc dữ liệu businessService và thông tin cụ thể về cách thức và vị trí dịch vụ được truy cập được lưu trữ trong một hoặc nhiều cấu trúc bindTemplate liên quan . Mỗi cấu trúc bindTemplate bao gồm một phần tử chứa địa chỉ mạng của dịch vụ và đã liên kết với nó một hoặc nhiều cấu trúc tModel mô tả và xác định duy nhất dịch vụ.
Khi UDDI được sử dụng để lưu trữ thông tin WSDL hoặc con trỏ đến tệp WSDL, tModel phải được gọi theo quy ước là kiểu wsdlSpec , nghĩa là phần tử Tổng quanDoc được xác định rõ ràng là trỏ đến định nghĩa giao diện dịch vụ WSDL.
Đối với UDDI, nội dung WSDL được chia thành hai phần tử chính là tệp giao diện và tệp thực thi.
Dịch vụ web của hệ thống đặt chỗ Hertz cung cấp một ví dụ cụ thể về cách thức hoạt động của UDDI và WSDL. Đây là <tModel> cho dịch vụ web này -
<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>
Các điểm chính là -
Phần tử Tổng quanURL cung cấp URL đến nơi có thể tìm thấy tệp WSDL định nghĩa giao diện dịch vụ. Điều này cho phép con người và các công cụ nhận biết UDDI / WSDL xác định định nghĩa giao diện dịch vụ.
Mục đích của phần tử keyedReference trong categoryBag là để đảm bảo rằng tModel này được phân loại là tài liệu đặc tả WSDL.
Một số triển khai UDDI hiện có sẵn. Những triển khai này giúp tìm kiếm hoặc xuất bản dữ liệu UDDI dễ dàng hơn mà không bị sa lầy vào sự phức tạp của API UDDI. Dưới đây là tóm tắt ngắn gọn về các triển khai UDDI chính có sẵn.
Triển khai Java
Có hai triển khai UDDI cho Java.
UDDI4J (UDDI cho Java) - UDDI4J ban đầu được tạo ra bởi IBM. Vào tháng 1 năm 2001, IBM đã chuyển mã sang trang mã nguồn mở của riêng mình. UDDI4J là một thư viện lớp Java cung cấp một API để tương tác với một UDDI.
jUDDI - jUDDI là một triển khai Java mã nguồn mở của sổ đăng ký UDDI và một bộ công cụ để truy cập các dịch vụ UDDI.
Triển khai Perl
UDDI::Lite - Nó cung cấp một ứng dụng khách UDDI cơ bản để yêu cầu và xuất bản.
Thực hiện Ruby
UDDI4r - Nó cung cấp một ứng dụng khách UDDI cơ bản để yêu cầu và xuất bản.
Triển khai Python
UDDI4Py - UDDI4Py là một gói Python cho phép gửi các yêu cầu và xử lý các phản hồi từ các API UDDI Phiên bản 2.
Dự án UDDI cũng xác định một tập hợp các định nghĩa Lược đồ XML mô tả các định dạng dữ liệu được sử dụng bởi các API đặc tả khác nhau. Tất cả các tài liệu này đều có sẵn để tải xuống tại www.uddi.org . Phiên bản hiện tại của tất cả các nhóm thông số kỹ thuật là Phiên bản 2.0.
Các thông số kỹ thuật bao gồm những điều sau:
- Nhân rộng UDDI,
- Nhà điều hành UDDI,
- API của lập trình viên UDDI và
- Cấu trúc dữ liệu UDDI
Nhân rộng UDDI
Tài liệu này mô tả các quy trình và giao diện sao chép dữ liệu mà nhà điều hành đăng ký phải tuân theo để đạt được sự sao chép dữ liệu giữa các trang web. Đặc tả này không phải là API của lập trình viên; nó xác định cơ chế sao chép được sử dụng giữa các nút UBR.
Nhà khai thác UDDI
Tài liệu này phác thảo hành vi và các tham số hoạt động được yêu cầu bởi các nhà khai thác nút UDDI. Đặc tả này xác định các yêu cầu quản lý dữ liệu mà người vận hành phải tuân thủ.
API của lập trình viên UDDI
Thông số kỹ thuật này xác định một tập hợp các chức năng mà tất cả các đăng ký UDDI hỗ trợ để hỏi về các dịch vụ được lưu trữ trong hệ thống đăng ký và để xuất bản thông tin về doanh nghiệp hoặc dịch vụ cho cơ quan đăng ký. Đặc tả này xác định một loạt các thông báo SOAP chứa các tài liệu XML mà sổ đăng ký UDDI chấp nhận, phân tích cú pháp và phản hồi. Đặc tả này, cùng với lược đồ API UDDI XML và đặc tả Cấu trúc dữ liệu UDDI, tạo nên một giao diện lập trình hoàn chỉnh cho sổ đăng ký UDDI.
Cấu trúc dữ liệu UDDI
Đặc tả này bao gồm các chi tiết cụ thể của cấu trúc XML có trong các thông điệp SOAP được xác định bởi API của lập trình viên UDDI. Đặc tả này xác định năm cấu trúc dữ liệu cốt lõi và mối quan hệ của chúng với nhau.
Lược đồ API XML UDDI không có trong một đặc tả; đúng hơn, nó được lưu trữ như một tài liệu Lược đồ XML xác định cấu trúc và kiểu dữ liệu của cấu trúc dữ liệu UDDI.
UDDI và các phần tử của nó trong hướng dẫn này và cũng đã thấy kiến trúc hoàn chỉnh và mô hình dữ liệu của UDDI.
Chúng ta đã tìm hiểu về hai giao diện UDDI: Giao diện Nhà xuất bản và Giao diện Yêu cầu. Chúng tôi cũng đã học cách đăng ký và tìm kiếm các dịch vụ web với UDDI.
Cái gì tiếp theo?
Bước tiếp theo là tìm hiểu về SOAP, WSDL và Dịch vụ Web.
XÀ BÔNG TẮM
SOAP là một giao thức dựa trên XML đơn giản cho phép các ứng dụng trao đổi thông tin qua HTTP.
Nếu bạn muốn tìm hiểu thêm về SOAP, vui lòng truy cập hướng dẫn SOAP của chúng tôi .
WSDL
WSDL là định dạng tiêu chuẩn để mô tả một dịch vụ web ở định dạng XML.
WSDL là một phần không thể thiếu của UDDI.
Nếu bạn muốn tìm hiểu thêm về WSDL, vui lòng truy cập Hướng dẫn WSDL của chúng tôi .
Dịch vụ web
Các dịch vụ web có thể chuyển đổi các ứng dụng của bạn thành các ứng dụng web.
Nếu bạn muốn tìm hiểu thêm về các dịch vụ web, vui lòng truy cập hướng dẫn Dịch vụ Web của chúng tôi .
Đây là tài liệu tham khảo đầy đủ về các API yêu cầu UDDI và các API xuất bản UDDI.
Các API yêu cầu UDDI
Tên API | Sự miêu tả | V1.0 | V2.0 |
---|---|---|---|
find_binding | Tìm kiếm các liên kết mẫu được liên kết với một dịch vụ cụ thể. | Y | Y |
find_business | Tìm kiếm doanh nghiệp phù hợp với tiêu chí đã chỉ định. | Y | Y |
find_ RelatedBusinesses | Khám phá doanh nghiệp có liên quan thông qua mô hình uddi-org: Relationship. | Y | |
find_service | Tìm kiếm dịch vụ liên quan đến một doanh nghiệp cụ thể. | Y | Y |
find_tModel | Tìm kiếm bản ghi tModel phù hợp với tiêu chí đã chỉ định. | Y | Y |
get_bindingDetail | Truy xuất bindingTemplate hoàn chỉnh cho mỗi bindKey được chỉ định. | Y | Y |
get_businessDetail | Truy xuất businessEntity hoàn chỉnh cho mỗi businessKey được chỉ định. | Y | Y |
get_businessDetailExt | Truy xuất businessEntity mở rộng cho mỗi businessKey được chỉ định. | Y | Y |
get_serviceDetail | Truy xuất bản ghi businessService cho mỗi serviceKey được chỉ định. | Y | Y |
get_tModelDetail | Truy xuất bản ghi tModel cho mỗi tModelKey được chỉ định. | Y | Y |
Các API xuất bản UDDI
Tên API | Sự miêu tả | V1.0 | V2.0 |
---|---|---|---|
get_authToken | Truy xuất mã thông báo ủy quyền. Tất cả các hoạt động của giao diện Nhà xuất bản yêu cầu phải gửi mã thông báo ủy quyền hợp lệ cùng với yêu cầu. | Y | Y |
discard_authToken | Thông báo cho cơ quan đăng ký UDDI không còn chấp nhận mã thông báo ủy quyền đã cho. Bước này tương đương với việc đăng xuất khỏi hệ thống. | Y | Y |
save_business | Tạo hoặc cập nhật thông tin của thực thể kinh doanh có trong sổ đăng ký UDDI. | Y | Y |
save_service | Tạo hoặc cập nhật thông tin về các dịch vụ web mà một tổ chức kinh doanh cung cấp. | Y | Y |
save_binding | Tạo hoặc cập nhật thông tin kỹ thuật về việc triển khai dịch vụ web. | Y | Y |
save_tModel | Tạo hoặc cập nhật đăng ký các khái niệm trừu tượng do cơ quan đăng ký UDDI quản lý. | Y | Y |
delete_business | Xóa hoàn toàn các thực thể kinh doanh đã cho khỏi sổ đăng ký UDDI. | Y | Y |
delete_service | Xóa hoàn toàn các dịch vụ web đã cho khỏi sổ đăng ký UDDI. | Y | Y |
delete_binding | Xóa chi tiết kỹ thuật dịch vụ web nhất định khỏi sổ đăng ký UDDI. | Y | Y |
delete_tModel | Loại bỏ các tModels được chỉ định khỏi sổ đăng ký UDDI. | Y | Y |
get_registeredInfo | Trả về bản tóm tắt mọi thứ mà sổ đăng ký UDDI hiện đang theo dõi cho người dùng, bao gồm tất cả các doanh nghiệp, tất cả các dịch vụ và tất cả các tModels. | Y | Y |
set_publisherAssertions | Quản lý tất cả các xác nhận mối quan hệ được theo dõi được liên kết với tài khoản nhà xuất bản cá nhân. | Y | |
add_publisherAssertions | Khiến một hoặc nhiều publisherAssertions được thêm vào bộ sưu tập xác nhận của từng nhà xuất bản. | Y | |
delete_publisherAssertions | Khiến một hoặc nhiều phần tử publisherAssertion bị xóa khỏi bộ sưu tập xác nhận của nhà xuất bản. | Y | |
get_assertionStatusReport | Cung cấp hỗ trợ quản trị để xác định trạng thái của xác nhận nhà xuất bản hiện tại và chưa xuất hiện liên quan đến bất kỳ đăng ký kinh doanh nào do tài khoản nhà xuất bản cá nhân quản lý. | Y | |
get_publisherAssertions | Nhận toàn bộ các xác nhận của nhà xuất bản được liên kết với tài khoản nhà xuất bản cá nhân. | Y |
Tham chiếu mã lỗi
Tham chiếu đầy đủ các mã lỗi do các API UDDI trả về như đã cho -
Mã lỗi