Tìm hiểu mô hình web service với uddi và cài đặt giải pháp cho phép tích hợp tự

Để triển khai được mô hình kiến trúc SOA, đại bộ phận các doanh nghiệp thường sử dụng các dịch vụ web, đó là thông qua các đặc tả chuẩn web như SOAP, XML, HTTP…Tuy nhiên bài toán đặt ra,

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

VŨ ĐÌNH PHÚ

TÌM HIỂU MÔ HÌNH WEB SERVICE VỚI UDDI VÀ CÀI ĐẶT GIẢI PHÁP CHO PHÉP TÍCH HỢP TỰ ĐỘNG CÁC WEB SERVICE ĐỂ

TẠO DỊCH VỤ GIÁ TRỊ GIA TĂNG

Chuyên ngành: Công nghệ thông tin

LUẬN VĂN THẠC SĨ KỸ THUẬT

Công nghệ thông tin

NGƯỜI HƯỚNG DẪN KHOA HỌC:

1.TS Phạm Huy Hoàng

Hà Nội – 2014

Lời cam đoan

Tôi – Vũ Đình Phú – Cam kết luận văn này là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của TS Phạm Huy Hoàng

Các kết quả nêu trong luận văn này là trung thực, không phải là sao chép toàn văn của bất kỳ một công trình nào khác

Lời cảm ơn

Với lòng kính trọng và sự biết ơn sâu sắc, tôi xin được bày tỏ lời cảm ơn tới thầy - Tiến sỹ Phạm Huy Hoàng- người đã tận tâm dìu dắt, hướng dẫn, chỉ dạy những kiến thức quý báu đồng thời tạo mọi điều kiện thuận lợi để tôi hoàn thành luận văn này

Xin được chân thành cảm ơn các thầy, cô trường Đại học Bách Khoa Hà Nội, đặc biệt là các thầy cô Viện Công nghệ thông tin và Truyền thông Đồng thời, xin được gửi lời cảm ơn sâu sắc tới các thầy cô và các bạn cùng lớp đã cùng giúp

đỡ, hỗ trợ tôi trong suốt quá trình nghiên cứu và thực hiện luận văn này

Con xin dành lời cảm ơn sâu nặng nhất tới bố mẹ, gia đình - những người đã luôn khích lệ, động viên, dìu dắt con suốt con đường dài

Hà Nội, tháng 8 năm 2014

Vũ Đình Phú

Mục lục

Nội dung

Mục lục 4

Danh mục các ký hiệu, các chữ viết tắt 6

Danh mục hình vẽ, bảng biểu 7

Chương mở đầu 9

Bối cảnh lựa chọn đề tài 9

Nhiệm vụ đặt ra, đối tượng, phạm vi nghiên cứu 10

Các luận điểm cơ bản và đóng góp mới của luận văn 10

Hướng tiếp cận, phương pháp nghiên cứu 10

Cấu trúc luận văn 11

Chương 1: Tìm hiểu tổng quan về web service 12

1 Giới thiệuchung về web service 12

2 Kiến trúc web service 12

3 Các thành phần chính của dịch vụ web 15

Chương 2 Tìm hiểu tổng quan về UDDI, framework triển khai JUDDI 18

2.1 Sơ lược về UDDI và lịch sử hình thành 18

2.2 Kiến trúc UDDI 20

2.2.1 Mô hình Pattern UDDI 20

2.2.2 Mô hình hóa dữ liệu UDDI 23

2.2.3 Đặc tả các UDDI API 32

2.2.4 Mô hình UDDI dịch vụ đám mây 43

2.3 Giới thiệu JUDDI áp dụng vào thực thi cài đặt mô hình UDDI 44

Chương 3 Áp dụng mô hình UDDI vào phát triển, cài đặt dịch vụ tích hợp trong web site du lịch 48

3.1 Phát biểu bài toán 48

3.2 Thiết kế cấu trúc thông tin bổ trợ mô tả dịch vụ tích hợp vào UDDI 48

3.3 Triển khai, áp dụng mô hình UDDI trong hệ thống website du lịch 51

3.3.1 Với nhà quản trị hệ thống UDDI 51

3.3.2 Với nhà cung cấp web service 54

3.3.3 Với nhà phát triển dịch vụ giá trị gia tăng 59

Chương 4: Kết luận 67

Các kết quả đạt được 67

Các điểm còn hạn chế 67

Hướng phát triển 68

Danh mục tài liệu tham khảo 69

Danh mục các ký hiệu, các chữ viết tắt

UDDI Universal Description

Discovery & Integration

Mô hình dùng để mô tả, quảng bá, tìm kiếm và tích hợp các web service

WSDL Web service description

language

Ngôn ngữ miêu tả dịch vụ web service

Language

Ngôn ngữ đánh đấu mở rộng

Danh mục hình vẽ, bảng biểu

Hình 1.2 1 Chồng giao thức dịch vụ web 13

Hình 1.2 2 Kiến trúc chi tiết của SOAP 14

Hình 2.2 1 Mô hình pattern UDDI 20

Hình 2.2 2 Mối liên UDDI với SOAP 21

Hình 2.2 3 Cách hình thành một bản ghi 22

Hình 2.2 4 Các thực thể core trong mô hình kiến trúc UDDI 24

Hình 2.2 5 Thực thể bussinessEntity 25

Hình 2.2 6 Dữ liệ mô tả cho thực thể businessEntity 25

Hình 2.2 7 Thực thể businessService 26

Hình 2.2 8 Dữ liệu minh họa cho thực thể businessService 26

Hình 2.2 9 Mô hình thực thể liên kết 27

Hình 2.2 10 Dữ liệu cho mô hình thực thể liên kết 28

Hình 2.2 11 Thực thể tModel 30

Hình 2.2 12 Dữ liệu mô tả cho tModel 30

Hình 2.2 13 Thực thể publisherAssertion 31

Hình 2.2 14 Dữ liệu cho thực thể publisherAssertion 31

Hình 2.2 15 Mối quan hệ tiêu chí tìm kiếm trong findQualifiers 34

Hình 2.2 16 Các tiêu chí sắp xếp UDDI hỗ trợ 35

Hình 2.2 17 Cấu trúc finding_business 36

Hình 2.2 18 Các ví dụ về phân đoạn khóa trong UDDI 39

Hình 2.2 19 save_service API 41

Hình 2.2 20 Mô hình UDDI theo kiến trúc đám mây 43

Hình 2.3 1 Tập các API mà JUDDI hỗ trợ 44

Hình 2.3 2 JUDDI Administration 45

Hình 2.3 3 Các enpoint SOAP mà JUDDI hỗ trợ 46

Hình 2.3 4 Kiến trúc JUDDI core 47

Hình 3.3 1 Cấu trúc bảng dữ liệu trong JUDDI 52

Hình 3.3 2 Giao diện bên ngoài của apache JUDDI 53

Hình 3.3 3 lưu trữ một publisher dùng soap-ui 53

Hình 3.3 4 Dữ liệu của các publisher trong juddi 54

Hình 3.3 5 Lưu trữ một thực thể nghiệp vụ bằng SOAP-UI 55

Hình 3.3 6 Lưu trữ một thực thể nghiệp vụ bằng giao diện web 55

Hình 3.3 7 Lưu trữ một thực thể nghiệp vụ bằng code java 56

Hình 3.3 8 Bảng dữ liệu các thực thể nghiệp vụ 57

Hình 3.3 9 Danh sách các web service cài đặt demo 59

Hình 3.3 10 Cách tìm kiến một web service theo top-down 1 61

Hình 3.3 11 Cách tìm kiến một web service theo top-down 2 61

Hình 3.3 12 Cách tìm kiến một web service theo top-down 3 62

Hình 3.3 13 Ứng dụng tự động gọi web service 63

Hình 3.3 15 Giao diện trang chủ website du lịch 64

Hình 3.3 16 Giao diện chi tiết phòng đặt 65

Hình 3.3 17 Giao diện khi có yêu cầu đặt phòng 65

Hình 3.3 18 Giao diện khi yêu cầu đặt phòng nhanh 66

Chương mở đầu

Bối cảnh lựa chọn đề tài

Hiện nay từ những phần mềm đơn lẻ như phần mềm quản lý công nợ cho các cửa hàng cho đến các phần mềm phức tạp, sử dụng trong doanh nghiệp lớn như giải pháp tổng thể ERP đã đem lại rất nhiều tiện ích cho người dùng Tuy nhiên do nhu cầu phát triển, các phần mềm không ngừng được bảo trì, thêm các tính năng mới Nếu chỉ chạy theo xu hướng cũ, các phần mềm chỉ được phát triển độc lập ngôn ngữ, chạy đơn nền gây ra việc lãng phí không tái sử dụng được những tài nguyên có sẵn lẫn nhau, hoặc tính tương tác giữa các phần mềm thêm yếu kém Đại bộ phận doanh nghiệp cũng khó có thể sử dụng một giải pháp tổng thể như ERP vì chi phí

nó quá cao Kiến trúc phần mềm theo xu hướng cũ đã không còn đáp ứng đầy đủ theo nhu cầu phát triển nữa Điều này đã nảy sinh một xu thế kiến trúc mới là kiến trúc hướng dịch vụ-SOA SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới Các thành phần được nối kết qua cổng giao tiếp, có tính kế thừa các thành phần đang tồn tại, và sự tương tác giữa chúng không cần quan tâm đến việc chúng được phát triển trên nền tảng công nghệ nào Điều này khiến hệ thống có thể mở rộng và tích hợp một cách dễ dàng

Để triển khai được mô hình kiến trúc SOA, đại bộ phận các doanh nghiệp thường sử dụng các dịch vụ web, đó là thông qua các đặc tả chuẩn web như SOAP, XML, HTTP…Tuy nhiên bài toán đặt ra, khi các doanh nghiệp quảng bá các dịch

vụ web trên một môi trường internet rộng lớn, làm sao để cho những doanh nghiệp khác có thể dễ dàng tìm kiếm, sử dụng lại các web service của doanh nghiệp này

Hay nói cách khác “một web service mà được doanh nghiệp quảng bá trên môi

trường web, làm sao cho nó trở nên có ý nghĩa hơn?” Một web service thực sự có

ý nghĩa khi mà những người dùng tiềm năng có thể tìm thấy đầy đủ thông tin mô tả của nó như đầu vào, đẩu ra, giao thức kết nối, mục đích sử dụng… từ đó có thể cho phép họ thực thi những yêu cầu theo nhu cầu sử dụng của họ…Vì nhu cầu muốn

cho việc tích hợp web service dễ dàng hơn, người dùng hiểu rõ hơn về web service

mà mình muống tích hợp, nảy sinh ra việc phát triển một chuẩn chung, sử dụng phổ

rộng, thống nhất, UDDI (Universal Description Discovery & Integration ) ra đời đã

giải quyết được điều này Qua quá trình làm việc ở công ty là về các sản phẩm của lớp giữa, cũng như việc tìm hiểu xu thế mong muốn của những nhà phát triển khi muốn sử dụng tài nguyên chung web service, tác giả xin được thực hiện luận văn về

chuẩn UDDI: “Tìm hiểu mô hình web service với uddi và cài đặt giải pháp cho phép tích hợp tự động các web service để tạo dịch vụ giá trị gia tăng”

Nhiệm vụ đặt ra, đối tượng, phạm vi nghiên cứu

- Tìm hiểu về dịch vụ web, mô hình UDDI, kỹ thuật cài đặt triển khai mô hình UDDI thông qua công nghệ java JUDDI

- Tiến hành phân tích bài toán khi quảng bá và truy vấn các web service lên UDDI server, từ đó đề xuất giải pháp thiết kế cấu trúc thông tin bổ trợ mô tả dịch vụ tích hợp vào UDDI, nhằm tăng hiệu quả hơn khi tích hợp vào UDDI

- Cài đặt thử nghiệm hệ thống tích hợp các web service được quảng bá lên UDDI server –tạo ra web site du lịch có sử dụng các web service từ hệ thống UDDI Từ đó đưa ra đánh giá, đề xuất hướng mở rộng, nhằm hiệu quả hơn khi tương tác với các web service trên UDDI server

Các luận điểm cơ bản và đóng góp mới của luận văn

- Tác giả thiết kế, đề xuất cấu trúc thông tin bổ trợ mô tả dịch vụ tích hợp vào UDDI, nhằm giúp cho việc truy xuất, tìm kiếm các web service trên UDDI được dễ dàng hơn

- Tác giả đã tiến hành cài đặt, phát triển hệ thống web site du lịch trong đó có một phần tích hợp tự động web service lấy từ UDDI server, tạo dịch vụ gia tăng Sau đó đưa hướng đề xuất, mở rộng khi làm việc với UDDI

Hướng tiếp cận, phương pháp nghiên cứu

- B1: Nghiên cứu sâu về đặc tả mô hình UDDI, đặc tả kỹ thuật JUDDI

- B2: Phân tích bài toán khi muốn áp dụng mô hình UDDI để tích hợp tự động các web service, làm sao để truy vấn các web service tren UDDI nhanh hơn

- B3: Tiến hành cài đặt, đánh giá hệ thống, rút ra kết luận

Cấu trúc luận văn

Luận văn sẽ bao gồm 04 chương với nội dung mỗi chương như sau

- Chương 1: Tóm tắt về tìm hiểu tổng quan về dịch vụ web service

- Chương 2: Trình bày tìm hiểu về UDDI như về kiến trúc, đặc tả, các

API, sau đó tìm hiểu framework JUDDI để cài đặt triển khai thử nghiệm cho mô hình UDDI

- Chương 3: Áp dụng mô hình UDDI để phát triển cài đặt dịch vụ cho

phép tích hợp các web service tự động trong hệ thống web site du lịch Chương này cũng đưa ra nhận định, đề xuất của tác giã để giúp cho khi triển khai mô hình UDDI thì người dùng được nhiều tiện ích hơn

- Và cuối cùng, chương 4, là chương trình bày kết luận và kiến nghị

cho toàn bộ nội dung luận văn

Chương 1: Tìm hiểu tổng quan về web service

1 Giới thiệuchung về web service

Web service có thể được mô tả như các hàm được triển khai thông qua môi trường web và có thể được gọi từ các ứng dụng thông thường hoặc qua một web service khác.Web service có thể coi là giao thức dùng phổ biến nhất hiện nay Lý do web service dần phổ biến vì việc dùng web service khá đơn giản, giống như ta gọi hàm trong các chương trình, hơn nữa web service giúp cho các bộ phận, công ty có thể tái sử dụng code, không phụ thuộc vào môi trường cài đặt, rút ngắn thời gian tạo một ứng dụng Các giao thức liên quan sử dụng cho web service như: WSDL, XML-RPC, SOAP, REST, WPS, UDDI,JSON-RPC, JSON-WSP, XLANG…Các Framework dùng tạo web service như: Apache Axis, Apache Axis2 ( dùng ngôn ngữ Java, C, C++), Apache CXF (Java), Net Framework (C#, VB.NET), SOAP (C, C+), CodeIgniter(PHP), Zend Framework (PHP)…Một web service bao gồm phần

mô tả về đầu vào, đầu ra của message truyền nhận, và các accessPoint( điểm truy cập) để client có thể gọi và nhận phản hồi từ server.Web service có thể triển khai thông qua mạng internet, hoặc chỉ cần thông qua mạng LAN, Intranet, miễn sao có thông kết nối giữa bên cung cấp và bên yêu cầu gọi web service Với sự phát triển

và lớn mạnh của Internet, web service thật sự là một công nghệ đáng được quan tâm

để giảm chi phí và độ phức tạp trong tích hợp và phát triển hệ thống

2 Kiến trúc web service

Dịch vụ Web gồm có 3 chuẩn chính: SOAP, WSDL và UDDI Hình vẽ saumô tả chồng giao thức của dịch vụ Web:

Hình 1.2 1 Chồng giao thức dịch vụ web

Chồng giao thức dịch vụ Web là tập hợp các giao thức mạng máy tính được

sử dụng để định nghĩa, xác định vị trí, thi hành và tạo nên dịch vụ Web tương tác với những ứng dụng hay dịch vụ khác Chồng giao thức này có 4 thành phần chính:

 Dịch vụ vận chuyển: có nhiệm vụ truyền thông điệp giữa các ứng dụng

mạng, bao gồm những giao thức như HTTP, SMTP, FTP, JSM và gần đây nhất là giao thức thay đổi khối mở rộng (Blocks Extensible Exchange Protocol- BEEP)

 Thông điệp XML: có nhiệm vụ giải mã các thông điệp theo định dạng XML

để có thể hiểu được ở mức ứng dụng tương tác với người dùng Hiện tại, những giao thức thực hiện nhiệm vụ này là XML-RPC, SOAP và REST

 Mô tả dịch vụ: được sử dụng để miêu tả các giao diện chung cho một dịch

vụ Web cụ thể WSDL là ngôn ngữ thường được sử dụng cho mục đích này,

nó là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Dịch vụ Web

sẽ sử dụng ngôn ngữ này để truyền tham số và các loại dữ liệu cho các thao tác và chức năng mà dịch vụ Web cung cấp

 Khám phá dịch vụ: tập trung dịch vụ vào trong một nơi được đăng ký, từ đó

giúp một dịch vụ Web có thể dễ dàng khám phá ra những dịch vụ nào đã có trên mạng, tốt hơn trong việc tìm kiếm những dịch vụ khác để tương tác Một dịch vụ Web cũng phải tiến hành đăng ký để các dịch vụ khác có thể truy cập

và giao tiếp Hiện tại, UDDI API thường được sử dụng để thực hiện công việc này

Kiến trúc sâu hơn được mô tả trong vẽ sau:

Hình 1.2 2 Kiến trúc chi tiết của SOAP

Trong đó, tầng giao thức tương tác dịch vụ với công nghệ chuẩn là SOAP SOAP là giao thức nằm giữa tầng vận chuyển và tầng mô tả thông tin về dịch vụ, cho phép người dùng triệu gọi một dịch vụ từ xa thông qua một thông điệp XML Ngoài ra, để các dịch vụ có tính an toàn, toàn vẹn và bảo mật thông tin, trong kiến trúc dịch vụ Web, chúng ta có thêm các tầng Policy, Security, Transaction, Management

3 Các thành phần chính của dịch vụ web

3.1 XML – eXtensible Markup Language

Là một chuẩn mở do W3C đưa ra cho cách thức mô tả dữ liệu, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML nhưng HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì Với XML, các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở

Do dịch vụ Web là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp XML là công

cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một dịch vụ Web, tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML Khi đó, các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống nhất

3.2 WSDL – Web Service Description Language

WSDL định nghĩa cách mô tả dịch vụ Web theo cú pháp tổng quát của XML, bao gồm các thông tin:

hành dịch vụ Giao diện của một dịch vụ Web được miêu tả trong phần này đưa ra cách thức làm thế nào để giao tiếp qua dịch vụ Web Tên, giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với dịch vụ Web được đưa vào thư mục của WSDL

WSDL thường được sử dụng kết hợp với XSD (XML Schema) và SOAP để cung cấp dịch vụ Web qua Internet Một client khi kết nối tới dịch vụ Web có thể đọc WSDL để xác định những chức năng sẵn có trên server Sau đó, client có thể sử dụng SOAP để lấy ra chức năng chính xác có trong WSDL

3.3 SOAP – Simple Object Access Protocol

Chúng ta đã hiểu cơ bản dịch vụ Web như thế nào, bao gồm những thành phần cơ bản nào nhưng vẫn còn một vấn đề quan trọng: đó là, làm thế nào để truy xuất dịch vụ khi đã tìm thấy một dịch vụ? Câu trả lời là các dịch vụ Web có thể truy xuất bằng một giao thức là SOAP Nói cách khác chúng ta có thể truy xuất đến các dịch vụ web được đăng kí ở UDDI, lấy các miêu tả dịch vụ web WSDL và sau đó gọi các hàm được dịch vụ web đó cung cấp bằng các lệnh gọi hoàn toàn theo định dạng của SOAP

SOAP là một giao thức giao tiếp có cấu trúc như XML Nó được xem là cấu trúc xương sống của các ứng dụng phân tán được xây dựng từ nhiều ngôn ngữ và các hệ điều hành khác nhau SOAP là giao thức thay đổi các thông điệp dựa trên XML qua mạng máy tính, thông thường sử dụng giao thức HTTP

Một client sẽ gửi thông điệp yêu cầu tới server và ngay lập tức server sẽ gửi những thông điệp trả lời tới client Cả SMTP và HTTP đều là những giao thức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và chấp nhận rộng rãi hơn bởi ngày nay nó có thể làm việc rất tốt với cơ sở hạ tầng Internet

3.4 Universal Description, Discovery, and Integration (UDDI)

Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng dịch vụ Web

Nội dung chính của đồ án có tập trung nghiên cứu sâu về đặc tả UDDI, và được trình bày ở chương tiếp theo

Chương 2 Tìm hiểu tổng quan về UDDI, framework triển khai JUDDI

2.1 Sơ lược về UDDI và lịch sử hình thành

Vì nhu cầu bài toán muốn cho việc tích hợp web service dễ dàng hơn, người dùng hiểu rõ hơn về ý nghĩa web service mà mình muốn tích hợp, nảy sinh ra việc phát triển một chuẩn chung, sử dụng phổ rộng, thống nhất Chính vì thế UDDI (Universal Description Discovery & Integration ) ra đời đã giải quyết được điều này UDDI được đề xuất từ tháng 12 năm 2000 do những công ty phần mềm nổi tiếng toàn cầu như Microsoft, IBM và Ariba tạo thành một chuẩn chung Sau khi công bố chuẩn chung đầu tiên, UDDI đã dần phát triển với hơn 300 công ty lớn như Dell, Fujisu, HP, Hitachi, SAP, Sun… tham gia vào Đến ngày nay, UDDI được tài trợ chính thức bởi tổ chức OASIS (Open Standards for the Information Society), và

đã ra đời với chuẩn UDDI v3 UDDI được sử dụng cho nhiều mục đích, nó có thể được dùng chung cho các công ty phần mềm và các doanh nghiệp muốn tham gia vào việc quảng bá, giới thiệu web service của họ, những doanh nghiệp này mong muốn sử dụng tài nguyên web service lẫn nhau, hoặc UDDI cũng có thể dùng cho nôi bộ một doanh nghiệp, một công ty phần mềm, khi mà họ phát sinh nhu cầu tích hợp giữa các hệ thống là quá nhiều, họ không muốn kiểm soát web service của mình bằng cách thủ công nữa

UDDI là một nền tảng không phụ thuộc vào các ngôn ngữ, môi trường phát triển, và là một framework mở, các công ty phần mềm có thể tham gia đóng góp vào để cho UDDI càng hoàn chỉnh hơn UDDI có thể được dùng thông qua các giao thức: SOAP, CORBA, Java RMI… UDDI sử dụng đặc tả WSDL, thông qua các từ khóa trong WSDL như tuần tự, chuổi (sequence), chọn lựa (choice), không bắt buộc (optional)… để mô tả các giao diện cho các web services UDDI là một chuẩn công nghiệp mở, được khởi tạo để tạo điều kiện giúp các công ty, các tổ chức có thể tìm kiếm những web service lẫn nhau và xác định làm thế nào để chúng tương tác với nhau thông qua môi trường internet, làm giàu hơn tài nguyên web service trên internet

UDDI có thể được các doanh nghiệp, tổ chức dùng theo cách quảng bá (publishing) hoặc dùng theo dạng bảo mật (private) bên trong nôi bộ Một doanh nghiệp hoặc tổ chức có thể đăng ký ba kiểu định dạng thông tin vào trong UDDI Những loại thông tin này giống như trong một cuốn sổ danh bạ, nên có cách gọi

khác về UDDI đó chính là cuốn sổ danh bạ điện thoại:

 White pages:

o Thông tin cơ bản về công ty và ngành nghề kinh doanh của nó

o Thông tin cơ bản vềliên lạc của công ty như: địa chỉ nhà, số điện thoại, địa chỉ email…

o Một mã định danh duy nhất về công ty thông qua mã số thuế Thông tin này cho phép các công ty, tổ chức khác có thể khám phá ra các web service liên quan khác của công ty này dựa bằng việc lần từ mã

số thuế

 Yellow pages:

o Thông tin chi tiết hơn về công ty, bao gồm mô tả của khả năng công

ty có thể cung cấp cho bất cứ tổ chức, cá nhân nào mà muốn quan hệ làm ăn với công ty

o Nó sử dụng các tiêu chí phân loại thông dụng thường được chấp nhận trong công nghiệp như: mã ngành công nghiệp, mã sản phẩm, mã định danh của công ty, và các thông tin khác mà giúp các công ty, tổ chức khác có thể tìm kiếm chính xác những gì mà họ muốn tìm

 Green pages: Tiêu chí phân loại này chứa những thông tin về kỹ thuật về

một web service Điều này cho phép một ai đó có thể liên kết tới web service này sau khi họ tìm thấy nó ở mô tả Bao gồm:

o Các giao diện (interface) cài đăt

o Địa chỉ URL

o Các thông tin ràng buộc, quy ước để có thể truyền vào web service này

2.2 Kiến trúc UDDI

2.2.1 Mô hình Pattern UDDI

Phạm vi của đồ án nghiên cứu đặc tả mô hình UDDI mới nhất hiện nay là UDDI v3 Mọi thông tin tìm hiểu đều dựa trên tài liệu tham chiếu là UDDI v3 Trước hết chúng ta cùng xem qua mô hình pattern của UDDI:

Hình 2.2 1 Mô hình pattern UDDI

Điểm mấu chốt trong mô hình pattern của UDDI chính là UDDI registry UDDI registry dùng để thực thi (cài đặt) đặc tả cho UDDI UDDI registry được ví như cuốn sổ danh bạ có thể bao gồm phân loại white page, yellow page và green page Registry không chỉ là nơi được thiết kế để lưu trữ thông tin về các công ty, các service mà nó còn lưu trữ tham chiếu một cách chi tiết đến các tài liệu liên quan.Nhìn mô hình chúng ta có thể hiểu được hoạt động của UDDI như sau:

1 Các công ty, tổ chức có những web service ở server, tiến hành thiết lập bảo mật khi muốn tham gia vào UDDI Sau đó đăng ký thông tin về web service của mình vào UDDI Registry

2 Client chính là những tổ chức, cá nhân có mong muốn tìm kiếm thông tin web service phục vụ cho mục đích của riêng mình Client tiến hành tìm kiếm

ở trong UDDI Registry ra thông tin web service mình mong muốn

3 Sau khi tìm được web service phù hợp, client tiến hành gọi web service đó trực tiếp vào server của các công ty, tổ chức cung cấp web service

Từ mô hình pattern chúng ta sẽ tìm hiểu sâu hơn về cơ chế cách thức hoạt động trong UDDI: 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.2 2 Mối liên UDDI với SOAP

Hình vẽ trên 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 sau 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

Hình 2.2 3 Cách hình thành một bản ghi

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:

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)

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 hexa (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 đó

Trong bước 4: 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, sử dụng một bản ghi UDDI để khám phá các dịch vụ quan tâm

Trong bước 5: 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ững mục sau của chương, tác giả sẽ đi sâu vào chi tiết kiến trúc sử dụng trong UDDI Theo cách phân loại về kiến trúc UDDI được chia làm 3 cấu phần chính sau:

 Mô hình hóa dữ liệu UDDI

 UDDI cloud services

2.2.2 Mô hình hóa dữ liệu UDDI

UDDI được mô hình hóa dữ liệu thông qua một XML schema mô tả cấu trúc Một mô hình UDDI chuẩn mô tả bao gồm có 5 thành phần cấu trúc dữ liệu nền tảng (core) sau:

 businessEntity



Theo mô hình này, một businessEntity, ngoài thông tin nội tại của nó có chứa bên trong đó loại dữ liệu core của UDDI là: businessService

2.2.2.2 businessService- thực thể dịch vụ

Đại diện cho các service trong UDDI là mô hình cấu trúc businessService

Nó chứa thông tin mô tả về web service bên trong một businessEntity như tên, mô

tả chi tiết, mô tả kiểu web service này là gì, các loại tiêu chí phân loại của web service này là gì Mỗi businessService chứa bindingTemplate Mô hình hóa cấu trúc

dữ liệu của businessService như sau:

Hình 2.2 7 Thực thể businessService

Với mô hình này, ta có dữ liệu khi truyền trong UDDI thực tế như sau:

Hình 2.2 8 Dữ liệu minh họa cho thực thể businessService

Có một lưu ý rằng việc sử dụng Universally Unique Identifiers (UUIDs) trong businessKey and serviceKey của dữ liệu Mỗi thực thể business và mỗi

service business là một định danh được xác định duy nhất trong toàn bộ các UDDI registries UUID được sinh ra và gán ngay lần đầu tiên khi khởi tạo thông tin cho một registry

2.2.2.3 bindingTemplate – thực thể liên kết

Đại diện cho web service là các bindingTemplate Mỗi một bindingTemplate chứa một web service bên trong nó Mỗi bindingTemplate cung cấp thông tin kỹ thuật cần thiết của các ứng dụng để kết nối và tương tác với web service đang được

mô tả Nó phải chứa thông tin về điểm truy cập (accessPoint) cho web service hoặc một kỹ thuật gián tiếp để có thể tiếp cận được điểm truy cập này Hình vẽ sau mô tả cấu trúc của bindingTemplate:

Hình 2.2 9 Mô hình thực thể liên kết

Trong hình vẽ, ta thấy có accessPoint, đây chính là thành phần (element) để chứa thông tin về URI của web service đăng ký trong registry Áp dụng mô hình đó vào truyền nhận dữ liệu như sau:

Hình 2.2 10 Dữ liệu cho mô hình thực thể liên kết

Vì một businessService có thể có nhiều bindingTemplates, UDDI có thể lựa chọn những cài đặt khác nhau đối với các service tương tự nhau, phụ thuộc vào phạm vi cài đặt khác nhau về giao thức hoặc là về địa chỉ mạng

2.2.2.4 tModel- thực thể mô tả kỹ thuật

tModels được sử dụng trong UDDI để đại diện một khái niệm duy nhất hoặc các các cấu trúc Chúng cung cấp một cấu trúc cho phép tái sử dụng, là một chuẩn bên trong một framework phần mềm Thông tin mô hình UDDI được dựa trên khái niệm mô hình chi tiết kỹ thuật được chia sẻ và sử dụng các tModels gây ra các hành động này Với lý do này, tModels tồn tại bên ngoài mối liên hệ cha-con giữa các cấu trúc businessEntity, businessService and bindingTemplate

Mỗi đặc điểm kỹ thuật riêng biệt, phương thức truyền nhận, giao thức hoặc namespace được đại diện bởi một tModel Ví dụ về tModels cho phép khả năng tương tác của các dịch vụ web bao gồm những người dựa trên dịch vụ web: ngôn ngữ mô tả (WSDL), định nghĩa XML schema (XSD) và những loại khác

Có điều quan trọng để lưu ý đó là các tài liệu kỹ thuật và các tài liệu hỗ trợ cần thiết để phát triển web service không được lưu trữ trong UDDI registry Một UDDI tModel đơn giản chứa các địa chỉ mà từ đó chúng ta có thể tìm được các tài liệu tham chiếu Một tModel có thể chứa nhiều UDLs, nó còn lưu trữ metadata về các tài liệu kỹ thuật và một khóa thực thể để định nghĩa đó là một tModel

Ví dụ cho tModel được sử dụng cho những mục đích sau bên trong UDDI:

 Định nghĩa về giao thức truyền nhận, ví dụ HTTP, SMTP

 Tập các giá trị bao gồm định nghĩa các hệ thống, phân loại hệ thống, và namespaces

 Phân loại cấu trúc đang sử dụng các tập dữ liệu, gọi là “các cấu trúc phân loại”

Hình 2.2 11 Thực thể tModel

Đây là một ví dụ của tModel đại diện cho “holloWorld” interface:

Hình 2.2 12 Dữ liệu mô tả cho tModel

tModel được cung cấp sẵn khi sử dụng một mô hình cài đặt cụ thể, tuy nhiên chúng ta cũng có thể khai báo mở rộng tModel để phù hợp hơn với những yêu cầu trong quá trình triển khai UDDI cho hệ thống của chúng ta

2.2.2.5 publisherAssertion- thực thể mối quan hệ giữa các thực thể nghiệp vụ

Thành phần cấu trúc này chỉ ra là mối quan hệ trong cấu trúc, chúng có liên liên quan đến nhau giữa hai hoặc nhiều hơn businessEntity tùy thuộc vào một đặc tả

kết-về kiểu của quan hệ, ví dụ như là công ty con hoặc các bộ phận phòng ban trong công ty lớn Hình vẽ sau mô tả về cấu trúc publisherAssertion

Hình 2.2 13 Thực thể publisherAssertion

publisherAssertion chứa 3 thành phần: formKey (businessKey đầu tiên), toKey( businessKey tiếp theo) và keyedReference Thành phần keyedReference thiết kế tạo kiểu quan hệ trong cặp keyName-keyValue trong một tModel, tham chiếu duy nhất bởi một tModelKey Ví dụ minh họa cho một publisherAssertion

Hình 2.2 14 Dữ liệu cho thực thể publisherAssertion

Việc sử dụng publisherAssertion rất hửu dụng, khi chúng ta muốn phân chia các nhóm chức năng, muốn định nghĩa thành phân nhóm theo tầng, quyền sở hửu theo tầng ví dụ như: mối quan hệ các business là cha-con, ngang hàng… Điều này đảm bảo khi chúng ta phân loại được các nhóm nghiệp vụ, người dùng tìm kiếm vào đúng nhóm nghiệp vụ mà chúng ta publisher lên, và có thể đi tìm những nhóm nghiệp vụ liên quan một cách dễ dàng hơn

2.2.3 Đặc tả các UDDI API

Tài liệu tham chiếu về các API của UDDI được phân thành nhiều phần khác nhau, được phân chia trọng tâm theo hướng lập trình Các API được phân loại bao gồm: các API về truy vấn (inquiry), cá API về quảng bá (publishing) và các API thuộc dạng tùy chọn (optional) như: về bảo mật, quyền hạn lúc trao đổi dữ liệu…

Mỗi tập API hướng tới một hoặc nhiều tModels được tham chiếu trong cấu trúc bindingTemplate để chỉ ra rằng một web service đã được đưa ra phù hợp với tập API Nội dung của chương này sẽ đi chi tiết tìm hiểu các API mà UDDI v3 cung cấp ra, giúp cho các nhà phát triển, nhà cung cấp sử dụng trong việc truyền tải thông tin cấu trúc dữ liệu của các dịch vụ của họ vào UDDI registry

2.2.3.1 Tập API về truy vấn

Tập API về truy vấn cho phép chúng ta có thể tìm kiếm và thu được chi tiết

về các thực thể trong một UDDI registry Các API này cung cấp 3 định dạng (form) truy vấn khác nhau, các định dạng này được tuân theo hàng loạt quy ước cần thiết

để cho các chương trình phần mềm thông thường có thể sử dụng được các registry

Có 3 mô hình (pattern) được sử dụng là:

 Mô hình về trình duyệt (Browse pattern): Phần mềm-chương trình cho phép chúng ta có thể khám phá và kiểm tra một loạt số lượng dữ liệu được yêu cầu

mà một trình duyệt có thể đáp ứng được Mô hình này có đặc tính liên quan đến việc bắt đầu với hàng loạt thông tin, thực thi một câu lệnh tìm kiếm, tìm trong các tập kết quả thông thường và lựa chọn nhiều thông tin dùng cho mô hình truy vấn ngược Đặc tả cung cáp cho mô hình trình duyệt bằng các API gọi các hành động (operations) là “find” (được đánh dấu như: find_xx API) Những lời gọi này sẽ tìm kiếm và trả ra các cấu trúc với dạng thông tin tổng qua (overview) về các thông tin trong registries phù hợp với API gọi và theo tiêu chí của API Đặc tính của mô hình này là tìm kiếm liên quan đến các nhà kinh doanh, các doanh nghiệp như tên hoặc là bất cứ thông tin về doanh

nghiệp Thông thường nó được bắt đầu bằng việc gọi API find_business, điền vào là tên doanh nghiệp, sau đó mới gọi đến các API như find_service

 Mô hình truy vấn ngược (Drill-Down pattern):Ở mô hình trình duyệt, chúng

ta có thể lấy được thông chung của một doanh nghiệp Mà chúng ta được biết

là trong các cấu trúc dữ liệu: businessEntity, businessService, bindingTemplate and tModel, có một khóa với mỗi dạng thành phần dữ liệu Vậy khóa này, chúng ta có thể tìm kiếm một cách chính xác thông tin về doanh nghiệp

 Mô hình triệu gọi (Invocation pattern): Khi một chương trình muốn gọi và Registry để lấy thông tin ví dụ như bindingTemplate, nếu thông tin đó có trả

ra, thì UDDI thực hiện lưu trữ thông tin đó trong bộ nhớ cache của hệ thống,

và chương trình bên ngoài nếu gọi đúng khóa để lấy thông tin bindingTemplate ban đầu sẻ được lấy ra rất nhanh Tuy nhiên, trường hợp có

sự thay đổi về địa chỉ liên kết, mà UDDI vẫn lưu trữ địa chỉ ở trong cache thì lúc có lời gọi từ bên ngoài vào sẽ trả về là lỗi Trường hợp này ứng dụng bên ngoài nên gọi lại một lần nữa (vì ứng dụng bên ngoài luôn lấy địa chỉ này tự động từ UDDI), khi đó UDDI sẽ bỏ dữ liệu trong cache và tiến hành tìm kiếm trong Registry của mình bản cập nhật mới Trường hợp này gọi là triệu hồi

Một điều quan trọng trong việc sử dụng các API về truy vấn là việc chọn chất lượng truy vấn (Find Qualifiers) Bài viết xin đi sâu về vấn đề này Trong mỗi API truy vấn, có thêm một tùy chọn là findQualifiers, nó giống như một tiêu chí tìm kiếm và chúng ta cần phải biết rõ quy ước cho việc sử dụng các từ khóa trong tiêu chí tìm kiếm này findQualifies được UDDI hỗ trợ cho một số API truy vấn, nếu như trong một API chúng ta dùng nhiều findQualifies thì được UDDI hiểu là dùng theo tiêu chí và (AND), sau đây là bảng ví dụ tổng kết:

Hình 2.2 15 Mối quan hệ tiêu chí tìm kiếm trong findQualifiers

Một số cặp tiêu chí không nên – không được đi cùng nhau trong findQualifiers:

 andAllKeys, orAllKeys, and orLikeKeys

 sortByNameAsc and sortByNameDesc

 sortByDateAsc and sortByDateDesc

 combineCategoryBags, serviceSubset and bindingSubset

 exactMatch and approximateMatch

 exactMatch and caseInsensitiveMatch