Dự án Universal Description, Discovery, and Integration (UDDI) tiếp tục làm giàu thêm bộ công cụ có sẵn cho các doanh nghiệp để mô hình hóa và cụ thể hóa các dịch vụ web được đăng ký với UDDI. Bài viết này sẽ giới thiệu về UDDI và vai trò của nó trong sự phát triển các dịch vụ Web. Bạn sẽ biết được cách UDDI làm việc cũng như khám phá những đặc tính mới cho các đặc tả kỹ thuật UDDI. (Bài viết này được xuất bản và phát hành vào tháng 5 năm 2002 tạp chí IBM developerWorks.)

Tom Bellwood, Kỹ thuật viên cao cấp, IBM

Tom Bellwood là nhân viên kỹ thuật cao cấp của IBM và có nhiều năm kinh nghiệm trong lĩnh vực kỹ thuật, từ thiết kế thiết bị bán dẫn đến hệ thống tự động và phát triển ứng dụng. Ông là chuyên gia UDDI đóng góp rất nhiều vào việc phát triển các dịch vụ Web trên thế giới. Ông là chỉ đạo kỹ thuật cho IBM UDDI Business Registry và có mặt trong nhiều hội nghị kỹ thuật.



20 05 2009

UDDI là gì?

Dự án UDDI khuyến khích những khả năng thực hiện nội tại và sự lựa chọn của các dịch vụ web. UDDI là các mối quan hệ của các nhà lãnh đạo kinh doanh và công nghiệp, và được thành lập bởi IBM, Ariba, và Microsoft. Hiện nay, có trên 300 công ty thành viên tham gia. UDDI cung cấp các chuẩn kỹ thuật theo các tiêu chuẩn cho việc mô tả và khám phá, cũng như tập hợp các cài đặt dựa trên Internet. UDDI tiếp tục phát triển nhanh chóng và tiếp tục tăng hỗ trợ công nghiệp. Các đặc tính kĩ thuật phát triển nhanh chóng vì nó nhận được phản hồi từ các cài đặt nhanh, những cài đặt này xác nhận các khái niệm và cung cấp nền tảng kinh nghiệm phong phú cho việc hoàn thiện các đặc tả sau này.

UDDI giải quyết các vấn đề trong kinh doanh. Đầu tiên, nó giúp mở rộng và đơn giản hóa các giao dịch giữa doanh nghiệp tới doanh nghiệp (business-to-business - B2B). Đối với những nhà sản xuất cần tạo nhiều mối quan hệ với những khách hàng khác nhau, mỗi khách hàng ứng với một tập các giao thức và các chuẩn, UDDI hỗ trợ miêu tả dịch vụ rất linh hoạt sử dụng bất kỳ giao thức tương tác nào. Với một cửa hàng hoa ở Australia nó muốn được quảng cáo ở khắp mọi nơi trên thế giới nhưng lại không biết làm thế nào, UDDI cung cấp cách để thực hiện điều này. Những đặc tả này cho phép khám phá đơn giản và hiệu quả về kinh doanh và những dịch vụ họ cung cấp bằng việc công bố chúng trong bảng đăng ký.

Với những nhà cung cấp thị trường B2B cần lấy dữ liệu cho các nhà cung cấp khác trong cùng một lĩnh vực có liên quan tới dịch vụ thanh toán, đóng gói, giao hàng, bảo hiểm, ..., UDDI cho phép việc khai phá và tích hợp các dịch vụ web liên quan vào trong một tiến trình kinh doanh kết hợp. UDDI cung cấp "cửa hàng một cửa" cho việc tìm kiếm thông tin về dịch vụ điện tử và thương mại. Công bố thông tin dịch vụ và kinh doanh ở UDDI sẽ được quảng bá rộng rãi.

UDDI dựa vào những chuẩn đã có như là ngôn ngữ đánh dấu mở rộng (XML) và giao thức truy cập đối tượng đơn giản (SOAP). Tất cả các cài đặt của UDDI đều hỗ trợ các đặc tả UDDI. Đặc tả công cộng được phát triển trong một tiến trình mở bởi các thành viên của tổ chức. Mục đích là để tạo và thực thi ba phiên bản liên tiếp của đặc tả kỹ thuật trước khi chuyển giao quyền sở hữu cho một cá nhân độc lập. Phiên bản 1 của đặc tả UDDI được công bố trong tháng 9 năm 2000, phiên bản 2 được công bố váo tháng 6 năm 2001. Phiên bản 3 đang được phát triển và được hi vọng sẵn sàng vào giữa năm 2002. Phiên bản 1 xây dựng nền tảng cho việc đăng ký, còn phiên bản 2 thêm các đặc tính như quan hệ kinh doanh. Phiên bản 3 tiếp tục giải quyết các lĩnh vực quan trọng cho việc phát triển dịch vụ web, như là bảo mật, tăng cường quốc tế hóa, khả năng tương tác nội bộ, và hàng loạt các cải tiến hàm API để cải tiến công cụ tốt hơn.

Hình 1. Lớp dịch vụ Web với UDDI
Lớp dịch vụ Web với UDDI

Quan sát Hình 1, UDDI phù hợp với ngăn xếp dịch vụ Web tổng quan và là thành phần quan trọng của sự sáng lập của nó, cho phép sự sáng tạo, đặc tả, khám phá và dẫn chứng của dịch vụ Web.

UDDI xây dựng trên tầng vận chuyển của mô hình mạng và tầng thông điệp XML dựa trên SOAP. Các ngôn ngữ mô tả dịch vụ, như là ngôn ngữ miêu tả dịch vụ Web (Web Services Description Language - WSDL), cung cấp thuật ngữ XML đồng nhất (tương tự như ngôn ngữ tương tác dữ liệu - IDL) để dùng trong việc mô tả các dịch vụ web và giao diện của chúng. Bạn có thể xây dựng trên nền tảng này bắng cách thêm các tầng lớp khả năng, như là mô tả quy trình của dịch vụ web sử dụng ngôn ngữ Web Services Flow, bảo mật, quản lý và đặc tính chất lượng dịch vụ.


UDDI làm việc như thế nào

Bản ghi của UDDI chứa các mô tả của các doanh nghiệp có thể truy cập bằng các chương trình máy tính và các dịch vụ mà chúng hỗ trợ. Nó cũng chứa các tham chiếu tới các đặc tả cụ thể mà một dịch vụ web có thể hỗ trợ, các định nghĩa phân loại (được sử dụng cho việc xếp loại kinh doanh và dịch vụ), và các hệ thống định danh (sử dụng để xác định các doanh nghiệp). UDDI cung cấp một lược đồ và mô hình lập trình với định nghĩa luật giao tiếp với bản ghi. Tất cả các hàm API trong đặc tả UDDI được định nghĩa trong XML, gói gọn trong một phong bì SOAP, và gửi qua HTTP.

Hình 2. Luồng thông báo UDDI giữa Client và Registry
Luồng thông báo UDDI giữa Client và Registry

Hình 2 minh họa sự truyền tải thông báo UDDI, từ yêu cầu SOAP của máy khách thông qua giao thức HTTP đến một nốt bản ghi đăng ký và quay lại. Máy chủ SOAP của hệ thống đăng ký tiếp nhận các thông điệp UDDI SOAP, xử lý nó, và trả lại một kết quả SOAP đến máy khách. Theo chính sách của bản ghi, các yêu cầu từ máy khách mà bắt buộc phải chỉnh sửa dữ liệu phải là các giao dịch đảm bảo an ninh và được xác thực.

Hình 3. UDDI làm việc như thế nào
UDDI làm việc như thế nào

Hình 3 minh họa cách một bản ghi UDDI được tạo thành với dữ liệu và cách các khách hàng khám phá và sử dụng những thông tin. Một bản ghi UDDI được xây dựng trên dữ liệu cung cấp bởi khách hàng của nó. Có vài bước để tạo ra dữ liệu hữu dụng trong UDDI. Như trong bước 1, công bố thông tin hữu ích đến bản ghi bắt đầu khi các công ty phần mềm và các cá nhân định nghĩa các đặc tả liên quan đến công nghiệp hay kinh doanh, mà họ đăng ký với UDDI. Những thứ này được biết như là các mô hình kỹ thuật, hoặc thông dụng hơn là tModels.

Trong bước 2, các công ty cũng đăng ký bản mô tả kinh doanh các dịch vụ của họ. Một bản ghi UDDI sẽ theo dõi tất cả các điểm này bằng cách gán cho mỗi điểm một định danh duy nhất, được biết đến như là một khóa định danh phổ biến duy nhất (Unique Universal Identifier - UUID) như trong bước 3. Một khóa UUID được đảm bảo là duy nhất và không bao giờ thay đổi trong một bản ghi UDDI. Những khóa này trông giống như một chuỗi số thập lục phân ngẫu nhiên có định dạng (ví dụ, C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). Chúng có thể được sử dụng để tham chiếu đến một điểm mà chúng được gán vào. Các khóa UUID tạo trong một bản ghi chỉ có nghĩa nội trong bản ghi đó.

Các khách hàng khác, như là e-Marketplaces, máy tìm kiếm, và ứng dụng thương mại trong bước 4, sử dụng một bản ghi UDDI để khám phá các dịch vụ quan tâm. Và ngược lại, các doanh nghiệp khác có thể yêu cầu các dịch vụ này, cho phép sự tích hợp đơn giản và thay đổi theo thời gian như minh họa trong bước 5.

Dữ liệu trong một bản ghi UDDI có thể được phân chia một cách khái niệm vào bốn hạng mục, mỗi hạng mục biểu diễn một điểm vào cao nhất trong UDDI. Mọi điểm vào đó được gán cho một khóa UUID duy nhất và luôn có thể được định vị trong bản ghi UDDI đó với khóa UUID này:

  • Các mô hình kỹ thuật
  • Kinh doanh
  • Dịch vụ kinh doanh
  • Dịch vụ đi kèm

Thông tin đăng ký cho kinh doanh và dịch vụ có thể được chia thành ba nhóm: bản bạch, bản vàng và bản xanh.

Bản bạch thể hiện thông tin cơ bản của một doanh nghiệp như là tên, mô tả việc kinh doanh, thông tin liên lạc,... Nó cũng bao gồm bất cứ định danh nào của cho doanh nghiệp đó, như là một số Dun & Bradstreet D-U-N-S®.

Thông tin trên bản vàng mở rộng khả năng của bạn cho việc tìm kiếm một doanh nghiệp hay một dịch vụ nội trong bản ghi bằng cách hỗ trợ sự phân lớp sử dụng hệ thống phân loại để phân loại. Sự phân lớp như vậy có thể được liên kết không chỉ với các doanh nghiệp và dịch vụ mà còn với tModels. Nếu chỉ có bản bạch, bản vàng hoặc cả hai được cung cấp, một bản ghi có giá trị giới hạn trong sự khám phá và sử dụng dịch vụ. Để thực hiện, bản xanh cung cấp các thông tin về cách và nơi để một dịch vụ được yêu cầu.

Bản xanh là thông tin đi kèm gắn với các dịch vụ và cung cấp các tham chiếu tới các đặc tả kỹ thuật mà các dịch vụ thực thi, cũng như là các con trỏ đến các tệp và cơ chế khám phá dựa trên URL.

Một bản ghi UDDI được cấu thành từ một hoặc nhiều cài đặt của đặc tả UDDI mà cùng hoạt động để chia sẻ dữ liệu bản ghi. Một bản ghi đặc biệt được cấu thành từ một tập các cài đặt UDDI có thể truy cập công cộng được được gọi là các nốt. Chúng làm việc cùng nhau để chia sẻ dữ liệu và, chúng thành lập bản ghi doanh nghiệp UDDI Business. Bản ghi này cung cấp miễn phí ra cộng đồng. Tất cả các bản ghi doanh nghiệp tồn tại trên tất cả các trang Operator, nhưng chúng chỉ có thể bị thay đổi tại nơi mà chúng được tạo ra.

Cả IBM và Microsoft điều hành các nốt phiên bản 1 trong bản ghi doanh nghiệp UDDI, và chúng, cũng như cả HP và SAP, đang điều hành các trang web thử nghiệm mà hỗ trợ các đặc tả UDDI phiên bản 2. Cả bốn công ty lớn đó lên kế hoạch để hỗ trợ đăng ký sản phẩm phiên bản 2 vào giữa năm 2002. Mỗi nhà điều hành hỗ trợ các hàm API SOAP định nghĩa bởi đặc tả UDDI. Thỏa thuận được củng cố thông qua hợp đồng thương mại. Các nhà điều hành cung cấp miễn phí các dịch vụ kèm theo như là các giao diện người dùng dựa trên trình duyệt.


Nhìn qua các đặc tả UDDI

Đặc tả UDDI được cấu thành từ vài tài liệu khác nhau. Đặc tả API mô tả các hàm API SOAP cho phép bạn thực hiện các hoạt động tìm kiếm và quảng bá. Cách xử lý lỗi, ngữ nghĩa của yêu cầu, kết quả cũng được mô tả. Các thông tin thực tế về các quy ước và cách sử dụng cũng có sẵn. Các tài liệu bao gồm đặc tả cấu trúc dữ liệu và lược đồ API định nghĩa thông điệp và ngữ nghĩa của dữ liệu.

Các hàm API của UDDI được chia thành hai nhóm, truy vấn và phát hành. Phiên bản 1 hỗ trợ các thao tác API, như trong Ví dụ 1.

Ví dụ 1. Các hàm API phiên bản 1 của UDDI
Inquiry Operations:      Publishing Operations:
Find                      Save
     find_business             save_business
     find_service              save_service
     find_binding              save_binding
     find_tModel               save_tModel
Get details               Delete
     get_businessDetail        delete_business
     get_serviceDetail         delete_service
     get_bindingDetail         delete_binding
     get_tModelDetail          delete_tModel
     get_registeredInfo        get_registeredInfo
                          Security
                               get_authToken
                               discard_authToken

Các API truy vấn chia thành ba mẫu truy vấn:

Phiên bản 2.0 của UDDI

UDDI định nghĩa bốn thành phần lõi dữ liệu trong mô hình dữ liệu:

  • businessEntity (mô hình hóa thông tin kinh doanh)
  • businessService (mô tả một dịch vụ)
  • tModel (mô tả các đặc tả, phân lớp, hoặc các định danh)
  • binding Template (ánh xạ giữa một businessService và tập các tModel mô tả dấu tay (fingerprint) kỹ thuật của nó)

Ngoài những thành phần cốt lõi này, phiên bản 2 đã thêm sự hỗ trợ cho mô hình hóa quan hệ giữa các doanh nghiệp.

Đặc tả UDDI và bản ghi doanh nghiệp UDDI, cái mà cung cấp một tập các cài đặt tham chiếu tương tác để chia sẻ các đăng ký, cho phép một mô hình lập trình mà hỗ trợ hoặc dịch vụ khám phá khi thực thi và khi thiết kế, phụ thuộc vào nhu cầu của khách. Lời tuyên bố giá trị tích hợp của IBM Web Services Initiative kết hợp với các công nghệ quan trọng khác, như là WSDL, cho phép các tổ chức thực hiện việc khám phá động và đính kèm các dịch vụ web ngay tại thời điểm hoạt động.

Sự tiến triển liên tục của đặc tả UDDI làm tăng giá trị của các bản ghi UDDI bằng cách đánh địa chỉ khu vực quan trọng, như là tính nguyên vẹn dữ liệu, điều khiển truy cập, định danh, và xác thực, cũng như là tính cùng hoạt động, mô hình dữ liệu cải tiến, truy vấn, và địa phương hóa.

  • Các mẫu tìm kiếm mẫu thừa kế công dụng của toán từ tìm kiếm, cái mà cho phép bạn duyệt các mục dữ liệu sử dụng các điều kiện khác nhau, như là hạng mục phân loại, các định danh, hoặc thông tin tên từng phần sử dụng hàm API_xxx find_xxx.
  • Các mẫu tìm kiếm sâu liên quan đến việc thu nhập thông tin chi tiết về một mục dữ liệu mà bạn đã tìm thấy. Hàm API get_xxx hỗ trợ khả năng này.
  • Các mẫu tìm kiếm viện dẫn thông tin là mẫu tìm kiếm cuối cùng. Việc gọi các dịch vụ ra yêu cầu sử dụng thông tin mẫu kèm theo, thông thường được lưu trữ tạm thời bởi các máy trạm để sử dụng lặp đi lặp lại mà không cần gửi lại bản ghi cho cùng một thông tin mà máy trạm cần. Nếu thông tin đính kèm thay đổi, máy trạm cần phải gửi lại bản ghi để cập nhật lại thông tin. Đây chính là mẫu tìm kiếm viện dẫn thông tin.

Lưu và xóa (với hàm API save_xxxdelete_xxx) có thể được thực hiện trên mỗi đầu mục ở cấp cao nhất, tên các hàm tự giải thích chức năng của nó, nhưng lưu ý rằng cách thức lưu trữ của toán tử save trong UDDI thông thường mang tính phá hủy. Ví dụ, việc tái lưu trữ (resave) cùng một dịch vụ với thông tin khác sẽ là sự thay thế hoàn toàn thông tin cũ bằng thông tin mới (hay còn gọi là ghi đè).

Toán tử gắn với authTokens yêu cầu bạn phải đăng ký trước với một nốt UDDI Business Registry cụ thể và cung cấp thông tin xác thực cần thiết để thành lập một sự thống nhất của nhà phát hành thông tin. Những thông tin xác thực này được sử dụng để lấy một authToken để thực hiện một toán tử xuất thông tin (với hàm APIsave_xxx). authToken có thể được tái sử dụng với thời gian ngắn trong khi các toán tử xuất thông tin chưa bị hết hạn. Chính sách toán tử quyết định cả nội dung và thời gian tồn tại của một authToken.


Có gì mới trong phiên bản 2 của UDDI?

Phiên bản 2 của UDDI giới thiệu một số tính năng quan trọng tăng cường chất lượng và hiệu quả của việc sử dụng bản ghi UDDI từ các đặc tả trong phiên bản 1. Các phần tiếp theo sẽ mô tả các tính năng mới trong phiên bản 2:

  • Hỗ trợ mô hình hóa các tổ chức phức tạp
  • Hỗ trợ phân mục và định danh mạnh hơn cho các khánh hàng
  • Cải tiến truy vấn
  • Tính năng quốc tế hóa
  • Nhân bản dựa trên đối tượng đồng đẳng (Peer-based)

Hỗ trợ mô hình hóa

Các cập nhật gắn với hỗ trợ nhằm mục đích chính là giúp các tổ chức lớn mô hình hóa một cách hiệu quả các dịch vụ và công việc kinh doanh của họ. Rất nhiều công ty, từ lớn đến nhỏ, có thể mong muốn phân chia các lựa chọn web mà họ đưa ra theo vị trí địa lý mà họ phục vụ, trình diễn chính các doanh nghiệp đó trên nền web một cách độc lập nhưng có liên quan đến nhau. Trong phiên bản 1 của UDDI, lựa chọn duy nhất cho tính huống này là duy trì các doanh nghiệp độc lập và không liên quan. Phiên bản 2 cho phép bạn định nghĩa các mối quan hệ giữa các doanh nghiệp, như là cha-con (parent-child), đồng đẳng (peer-peer), và đồng nhất (identity). Điều này cho tính mềm dẻo để mô hình hóa một doanh nghiệp với nhiều chi nhánh, các bạn hàng bên ngoài, hoặc các phân hệ nội bộ khác nhau. Các mối quan hệ có thể được hình thành giữa hai doanh nghiệp bất kỳ (được định nghĩa bởi các khóa duy nhất). Mô hình kỹ thuật chính tắc tModel cho kiểu quan hệ doanh nghiệp (Business Relationship types) hỗ trợ khả năng này, cùng với các hàm API mới cho phép bạn định nghĩa, xóa bỏ, và yêu cầu trạng thái của một mối quan hệ, như chỉ ra trong Ví dụ 2.

Một hàm truy vấn API gọi là find_relatedBusinesses cho phép tìm kiếm nặc danh các mối quan hệ liên quan đến một công ty cho trước. Các hàm API mới khác trong Ví dụ 2 đều gắn liền với các quan hệ mà một nhà xuất bản cụ thể tạo ra và sở hữu và không thể truy cập thông qua các hàm truy vấn nặc danh. Một quan hệ doanh nghiệp bao gồm một cặp xác nhận quan hệ giống nhau, mỗi xác nhận đó nối với hai doanh nghiệp với nhau và xác định mối quan hệ cụ thể đang được thành lập. Những người sở hữu của hai doanh nghiệp liên quan phải khai báo cùng một xác nhận quan hệ để tạo ra một quan hệ doanh nghiệp có thể thấy được từ bên ngoài. Chỉ những xác nhận quan hệ khớp với nhau được trả lại như là kết quả của một truy vấn find_relatedBusinesses().

Ví dụ sau đây chỉ ra cách một quan hệ được thành lập và được tìm thấy. Đầu tiên, bạn lấy một thẻ xác thực để xuất bản thông tin:

Ví dụ 2. Lấy một thẻ xác thực authToken
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Body>
<get_authToken generic="2.0"
  xmlns="urn:uddi-org:api_v2"
  userID="businessA_UserId"
  cred="businessA_Password" />
  </Body>
</Envelope>

Kết quả trả lại như sau:

Ví dụ 3. Kết quả trả lại
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Body>
<authToken generic="2.0"
  operator="www.ibm.com/services/uddi"
  xmlns="urn:uddi-org:api_v2" >
    <authInfo>businessA_AuthToken</authInfo>
</authToken>
  </Body>
</Envelope>

Tiếp theo, bạn thành lập một xác nhận doanh nghiệp liên quan đến hai doanh nghiệp, A và B, với các khóa businessKeys tương ứng được đơn giản hóa thành businessKeyAbusinessKeyB thay vì định dạng UUID chuẩn. Vỏ bọc SOAP không được hiển thị, cho đơn giản.

<add_publisherAssertions generic="2.0"
  xmlns="urn:uddi-org:api_v2">
  <authInfo>businessA_AuthToken</authInfo>
    <publisherAssertion>
    <fromKey>"businessKeyA"</fromKey>
<toKey>"businessKeyB"</toKey>
  <keyedReference keyValue="parent-child"
  keyName="Subsidiary"
  tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
  </publisherAssertion>
</add_publisherAssertions>

Khi một xác nhận đồng nhất được thành lập bởi chủ nhận của danh nghiệp B, một quan hệ doanh nghiệp công cộng sẽ được công khai trong bản đăng ký. Tiếp theo, bạn thực hiện một truy vấn đơn giản sử dụng hàm API find_relatedBusinesses() :

<find_relatedBusinesses generic="2.0"
xmlns="urn:uddi-org:api_v2">
  <businessKey>"businessKeyA"</businessKey>
</find_relatedBusinesses>

Ví dụ 3 là kết quả XML trả về. Một truy vấn tỉ mỉ hơn có thể bao gồm một keyedReference xác định quan hệ cụ thể sẽ được tìm thấy.

Một đặc tính quan trọng được thêm vào trong phiên bản 2 để hỗ trợ nhu cầu mô hình hóa của các doanh nghiệp lớn được gọi là tham chiếu dịch vụ (Service Projection), nó cho phép một doanh nghiệp tạo một tham chiếu tới một dịch vụ của một doanh nghiệp khác. Điều này rất hữu ích trong một vài tình huống, như là một công ty đưa ra cùng một dịch vụ tới hai hay nhiều hơn doanh nghiệp đối tác của nó, hoặc một dịch vụ chung (ví dụ, giao hàng trong đêm) có thể muốn khuyến khích bằng cách kết nối nó với các dịch vụ mà đối tác của họ đưa ra.

Một tham chiếu dịch vụ được tham chiếu chỉ là như vậy. Người tạo ra một tham chiếu dịch vụ không thể thay đổi bản thân dịch vụ đang được tham chiếu, nhưng theo khía cạnh khác, dịch vụ ứng xử như là nó được sở hữu bởi doanh nghiệp tạo ra tham chiếu đó. Dịch vụ được trả lại như là một phần của một lời gọi hàm API get_businessDetail() hoặc get_serviceDetail(). Bạn phân chia một dịch vụ được tham chiếu từ một dịch vụ thực thông qua khóa doanh nghiệp bạn sở hữu liên kết với một dịch vụ. Khóa đó luôn khớp với doanh nghiệp thực mà sở hữu dịch vụ đó, chứ không phải là doanh nghiệp tạo ra sự tham chiếu dịch vụ đó.


Phân hạng mục mạnh hơn

Trong phiên bản 1, ba cách phân loại dựng sẵn đã được cung cấp để sử dụng trong việc phân loại các doanh nghiệp và dịch vụ. Đó là các hạng mục công nghiệp NAICS, hạng mục dịch vụ và dự án UNSPC, và phân loại địa lý ISO-3166-2. Việc sử dụng những cách phân loại này được kiểm tra bởi bản ghi UDDI; việc cố gắng lưu trữ mã không hợp lệ sẽ bị từ chối. Điều quan trọng của việc phân loại có nghĩa trong UDDI không hề bị cường điệu. Đó là phương tiện mạnh mẽ để tìm kiếm thông tin hữu dụng cần thiết, và do đó cải tiến khả năng để tạo và điều khiển cách phân hạng mới được ưu tiên.

Phiên bản 2 thêm khả năng cho các tổ chức để định nghĩa một cách phân hạng mục được kiểm tra nội tại, cái mà có thể được đưa ra sử dụng công cộng trong UDDI. Những nhà cung cấp hạng mục công cộng này phải hỗ trợ một validate_values của dịch vụ web và làm cho nó có thể truy cập được đến bản ghi doanh nghiệp UDDI để hỗ trợ việc kiểm tra và xác nhận của các giá trị phân hạng mà các khách hàng mong muốn để liên kết với các bản ghi của họ. Đây là một quá trình được kiểm soát. Đăng ký của một cách phân hạng hiệu lực có thể được hoàn thành chỉ với sự chấp thuận của người điều hành bản ghi doanh nghiệp UDDI.

Đặc tính xác thực mới này cho phép các nhà cung cấp cách phân hạng tính mềm dẻo trong việc đảm bảo chỉ những giá trị phân hạng phù hợp được lưu trữ bởi khách hàng sử dụng cách phân hạng của họ. Khi một khách hàng yêu cầu sử dụng một hạng mục của một nhà cung cấp, nhà cung cấp có thể chọn để thực hiện một xác thực theo ngữ cảnh cùng với sự xác thực mà người yêu cầu được xác thực để sử dụng cách phân loại hạng mục đó. Tình huống không theo ngữ cảnh thông dụng cũng hỗ trợ lưu trữ tạm thời dữ liệu phân hạng mục bên trong bản ghi doanh nghiệp UDDI để giảm sự phụ thuộc vào dịch vụ phân hạng mục của các nhà cung cấp.


Các truy vấn cải tiến

Phiên bản 2 xây dựng trên các khả năng truy vấn đã được cung cấp từ trước và thêm các tính năng mạnh mẽ giải quyết các yêu cầu truy vấn phức tạp hơn. Để cải tiến hàm truy vấn find_xxx đã có, một vài điều kiện lọc đã được thêm vào, bao gồm orLikeKeys, orAllKeys, combineCategoryBags, serviceSubset, và andAllKeys. Trong đó, combineCategoryBags, serviceSubset, và orLikeKeys là đáng quan tâm.

Bộ định tính combineCategoryBags cho phép bạn gộp tất cả các dữ liệu phân loại được liên kết với một doanh nghiệp và tất cả các dịch vụ mà nó chứa (bao gồm cả các tham chiếu dịch vụ) vào một tập hợp đơn mà việc tìm kiếm sẽ thực hiện trên đó. Điều này là rất hữu ích bởi vì nó giảm bác bước trong việc tìm thấy một doanh nghiệp cần tìm bằng cách rà soát trong các doanh nghiệp và các dịch vụ của chúng cùng lúc.

Một cách tương tự, bộ lọc serviceSubset cho phép bạn tìm kiếm các doanh nghiệp sử dụng điều kiện phân hạng mục, những điều kiện này chỉ được kiểm trên các hạng mục được gắn kết với các dịch vụ của một công ty. Các hạng mục gắn kết với bản thân doanh nghiệp không được gộp trong việc tìm kiếm.

Cuối cùng, bộ định tính orLikeKeys là đặc biệt hữu ích bởi vì nó cho phép truy vấn phức tạp ảo. Ví dụ, bạn có thể tìm thấy các doanh nghiệp nằm ở Mỹ, Mexico, hoặc Canand mà chúng cung cấp dịch vụ kho đông lạnh hoặc dịch vụ chuyển giao hàng hóa chung. Điều này cho phép bạn thực hiện tìm kiếm các doanh nghiệp mà được phân loại với các cấp độ khác nhau theo đặc trưng của chúng, trong khi cùng lúc cho phép một truy vấn đơn tham chiếu đến nhiều hạng mục khác nhau cùng lúc.


Quốc tế hóa

Một vài đặc tính đã được thêm vào trong nỗ lực để giải quyết cải tiến sự quốc tế hóa trong UDDI. Hỗ trợ cho nhiều tên cùng lúc với một mã xml:lang đã được thêm vào các đối tượng businessEntity và businessService. Bạn phải cung cấp ít nhất một tên, nhưng bạn có thể cung cấp nhiều tên (mỗi tên với một mã ngôn ngữ khác nhau).

Một đặc tính quốc tế hóa khác trong phiên bản 2 là sự bổ trợ một kiểu phân hạng mới gọi là postalAddress, nó cho phép bạn tạo ra một mô hình tModel mô tả các địa chỉ thư tín địa phương mà chúng có thể được gắn kết với các địa chỉ tìm được trong các đối tượng doanh nghiệp.


Nhân bản

Trong khi không thấy trực tiếp từ khách hàng của UDDI, các cải tiến quan trọng được thực hiện trong việc nhân bản giữa các toán tử bản ghi trong phiên bản 2. Phiên bản 1 chỉ hỗ trợ một lược đồ nhân bản dựa trên tệp (file-based replication scheme) mà sự phức tạp tăng theo cấp n mũ 2 với số nốt bản ghi trong một bản ghi UDDI. Phiên bản 2 giải quyết nhu cầu của một số lớn hơn các nốt tham gia mà nhân bản với những nốt khác. Sự nhân bản có thể tiến hành trong một cách tiếp cận đồng đẳng mà ở đó các bản ghi cập nhật từ tất cả các nốt khác có thể được thu nhận từ bất cứ nốt nào. Sự nhân bản được hỗ trợ tốt hơn bởi định nghĩa của một tập các hàm API cho phép xử lý các thay đổi và quản lý các tiến trình.


Tiếp theo là gì?

Phiên bản tiếp theo của đặc tả UDDI được dự kiến cho giữa năm 2002 sẽ tập trung vào bảo mật, quản lý dữ liệu nâng cao, và quốc tế hóa hơn nữa. Bảo mật sẽ được giải quyết bởi cải tiến tính hợp nhất dữ liệu UDDI thông qua cải tiến kiểm soát truy cập, định danh và xác thực. Điều này sẽ bao gồm hỗ trợ cho các công nghệ bảo mật đã có và đang nổi lên từ các tổ chức như W3C và OASIS. Tính năng quản lý dữ liệu nâng cao sẽ cung cấp sự cải tiến liên tục tới khả năng tìm kiếm để cung cấp các câu truy vấn tốt hơn, sự thông dịch kết quả trả về tốt hơn, khả năng để nắm bắt các mô tả phong phú và có nghĩa hơn của các dịch vụ và doanh nghiệp, và quản lý dễ hơn các dữ liệu đã có. Sự cải tiến về quốc tế hóa sẽ bao gồm hỗ trợ cải tiến các công ty đa quốc gia để mô tả các hoạt động toàn cầu của họ trên toàn bộ các đơn vị kinh doanh và sẽ giải quyết sự địa phương hóa của dịch vụ và dữ liệu UDDI.


Kết luận

UDDI tiếp tục phát triển nhanh chóng. Bản cài đặt thử nghiệm của UDDI phiên bản 2 được cung bấp bởi nhiều nhà điều hành bản ghi doanh nghiệp UDDI trong năm 2001. Khi phiên bản 3 của bản đặc tả trở lên sẵn sàng vào giữa năm 2002, bản ghi sẽ tiếp tục thêm các tính năng cần thiết cho việc thực hiện kinh doanh trên nền web, giải quyết vấn đề an ninh, cải tiến quốc tế hóa, và các tính năng đi kèm để hỗ trợ công dụng của bản ghi và sự tương kết.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=387582
ArticleTitle=Tìm hiểu UDDI
publish-date=05202009