3. Hướng nghiên cứu của đề tài
1.4.2. Cấu trúc dữliệu UDDI
Thông tin được chứa trong một đăng ký UDDI bao gồm năm kiểu khác nhau:
businessEntity hoặc tổ chức công ty thực tế. Điều này có thể có nghĩa là toàn bộ tổ chức hoặc nó có thể là một tổ chức liên kết hoặc chi nhánh.
publisherAssertion hoặc mối quan hệ giữa businessEntities. Để hợp lệ publisherAssertions phải được cả hai bên yêu cầu, trừ khi cả hai thực thể có trách nhiệm với chủ báo hoặc trừ khi cả hai thực thể được nhập vào trong đăng ký bằng một tài khoản người dùng giống nhau.
bindingTemplate, về cơ bản là đặc tả của một giao diện của một dịch vụ. Nhiều businessServices có thể thực hiện businessServices.
businessService hay một dịch vụ do một doanh nghiệp cung cấp. Bây giờ, điều đó có vẻ đơn giản, nhưng trong thế giới của UDDI, điều đó không nhất thiết có nghĩa là nó là một dịch vụ Web. Ví dụ, thực sự có thể xác định dịch vụ hỗ trợ điện thoại của doanh nghiệp của (có nghĩa là số điện thoại thực tế mà người dùng quay số và tất cả mọi thứ mà đi kèm với nó) như một dịch vụ UDDI. Tất nhiên, sẽ không có một tài liệu WSDL giả, nhưng nó sẽ là một dịch vụ được doanh nghiệp của cung cấp.
tModels hoặc các mô hình siêu dữ liệu. Khi nghiên cứu UDDI, Francis đi đến kết luận rằng tModel có lẽ là lý do lớn nhất tại sao UDDI đã không cất cánh như mong đợi. Như một đăng ký của các dịch vụ, sẽ mong đợi tìm thấy một cách để trực tiếp xác định giao diện cho một dịch vụ, như WSDL thực hiện. Nhưng, như đã nói, UDDI đã chưa bao giờ được dự định là độc quyền về các dịch vụ Web và được thiết kế với linh hoạt hơn nữa. tModels thực hiện trợ giúp trỏ đến các tài liệu XML, như chúng ta sẽ thấy sau này, nhưng trong thực tế chúng có nghĩa là một cách tổng quát để xác định thông tin về thứ gì đó, thông qua dịch vụ, một doanh nghiệp hay bất cứ điều gì khác. UDDI nổi danh là quá phức tạp, nhưng với cốt lõi của mình UDDI thuộc về năm kiểu dữ liệu được mô tả ở trên, được kết hợp với bốn hoạt động: tìm kiếm, nhận, lưu và xóa. Nói cách khác, đặc tả UDDI lưu ý những điều sau đây để có thể thực hiện với dữ liệu:
find_xx: Những phương thức này, chẳng hạn như find_businessEntity, find_businessService và v.v, cung cấp một cách để tìm kiếm một bản ghi trong đăng ký UDDI. Những phương thức này trả về khóa để nhận dạng đối tượng.
get_xx: Một khi có khóa duy nhất nhận dạng một đối tượng, có thể sử dụng get_xx methods, nhưget_businessService và v.v, để lấy ra chính đối tượng thực tế đó. Ví dụ, get_businessService trả về toàn bộ đối tượng businessService, từ đó thu được bất kỳ thông tin nào mà cần.
save_xx: Như có thể đã đoán được, các phương thức này thêm thông tin vào cơ sở dữ liệu hoặc chúng thay đổi thông tin đã có trong cơ sở dữ liệu.
delete_xx: Những phương thức này, chẳng hạn delete_binding Template, delete_tModel, và v.v, lấy khóa duy nhất của đối tượng làm tham số và loại bỏ nó khỏi cơ sở dữ liệu. Hành vi thực tế của các phương thức này phụ thuộc vào những gì đang xóa. Ví dụ, vì tModels thường xuyên được các đối tượng khác trong cơ sở dữ liệu tham chiếu, nên chúng có thể không thực sự bị xóa.
Hầu như tất cả mọi thứ của UDDI dựa trên 20 phân cắt giữa năm đối tượng (businessService, bindingTemplate, publisherAssertion, businessEntity và tModel) và bốn hành động (find, get, save và delete).