Xây dựng khung đàm phán chất lượng dịch vụ cho dịch vụ web

DANH MỤC CÁC BẢNG Bảng 2-1: Phân loại thành nhóm thuộc tính chất lượng dịch vụ trong dịch vụ Web 14Bảng 3-1: Mối quan hệ giữa phân cấp ngữ cảnh và phân cấp mô tả trong mô hình thông tin

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

HOÀNG XUÂN HUY

XÂY DỰNG KHUNG ĐÀM PHÁN CHẤT LƯỢNG DỊCH VỤ CHO DỊCH VỤ WEB

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội – 2014

ĐẠI HỌC QUỐC GIA HÀ NỘI

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS VÕ ĐÌNH HIẾU

Hà Nội - 2014

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, đây là kết quả nghiên cứu của tôi trong đó có sự giúp đỡ rất lớn của thầy hướng dẫn Các nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực

Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt

kê tại phần tài liệu tham khảo ở cuối luận văn

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

Học viên thực hiện

Hoàng Xuân Huy

LỜI CẢM ƠN

Trước tiên, tôi xin được gửi lời cảm ơn đến tất cả quý thầy cô đã giảng dạy trong chương trình Cao học khóa 18, ngành công nghệ phần mềm, khoa công nghệ thông tin trường đại học Công Nghệ Đặc biệt, tôi xin cảm ơn TS Phạm Ngọc Hùng đã nhiệt tình chỉ bảo tôi trong suốt quá trình học

Tôi xin chân thành cảm ơn sâu sắc TS Võ Đình Hiếu, thầy đã tận tình và tâm huyết hướng dẫn cho tôi trong suốt thời gian làm luận văn

Do thời gian có hạn và kinh nghiệm trong nghiên cứu khoa học chưa nhiều nên luận văn vẫn còn những thiếu xót, tôi rất mong nhận được ý kiến góp ý của Thầy/Cô và các anh chị học viên

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

Học viên thực hiện

Hoàng Xuân Huy

MỤC LỤC

DANH MỤC TỪ VIẾT TẮT

DANH MỤC CÁC HÌNH

DANH MỤC CÁC BẢNG

MỞ ĐẦU 1

Chương 1: TỔNG QUAN VỀ DỊCH VỤ WEB 3

1.1 Giới thiệu về dịch vụ Web 3

1.2 Kiến trúc dịch vụ Web 4

1.3 SOAP 5

1.4 WSDL 7

1.5 UDDI 10

1.6 Mô hình phân lớp dạng ngăn xếp trong dịch vụ Web 10

1.7 Phương pháp xây dựng dịch vụ Web kết hợp 11

1.8 Tổng kết 13

Chương 2: CHẤT LƯỢNG DỊCH VỤ VÀ ĐÀM PHÁN DỊCH VỤ WEB 14

2.1 Chất lượng dịch vụ 14

2.1.1 Các thuộc tính chất lượng dịch vụ 14

2.1.2 Phương pháp cung cấp chất lượng dịch vụ 16

2.2 Đàm phán dịch vụ Web 18

2.2.1 Chính sách đàm phán 20

2.2.2 Thông điệp đàm phán 21

2.2.3 Giao thức đàm phán 22

2.3 Tổng kết 22

Chương 3: TÌM HIỂU VỀ AXIS2 23

3.1 Giới thiệu Axis2 23

3.1.1 Các đặc điểm chính của Axis2 23

3.1.2 Ưu điểm của Axis2 24

3.1.3 Các mô đun lõi của Axis2 24

3.1.4 Các mô đun khác của Axis2 (Mô đun không lõi) 25

3.2 Mô đun xử lý XML 26

3.2.1 Trục mô hình đối tượng (AXIOM) 26

3.3 Mô đun xử lý thông điệp SOAP 27

3.3.1 Xử lý trong Axis2 (Handler) 28

3.3.2 Giai đoạn trong Axis2 30

3.3.3 Đặc điểm luồng trong Axis2 (Flow) 32

3.4 Mô đun giao vận và mô đun triển khai 32

3.4.1 Mô đun giao vận 32

3.4.2 Triển khai nóng và cập nhật nóng 33

3.4.3 Mô đun triển khai 33

3.5 Mô đun thông tin 34

3.6 Mô đun giao diện lập trình ứng dụng khách hàng (Client API) 36

3.7 Tổng kết 38

Chương 4: XÂY DỰNG KHUNG ĐÀM PHÁN CHẤT LƯỢNG DỊCH VỤ CHO DỊCH VỤ WEB 39

4.1 Mô tả bài toán 39

4.2 Kiến trúc khung đàm phán 42

4.3 Dịch vụ Web kết hợp Travel_WS 44

4.3.1 Các phương thức của dịch vụ kết hợp Travel_WS 44

4.3.2 Biểu đồ tuần tự quá trình đàm phán 48

4.3.3 Lược đồ hoạt động của quá trình đàm phán 48

4.3.4 Thời gian giới hạn sử dụng của dịch vụ kết hợp 52

4.4 Dịch vụ Web thành phần trong khung đàm phán 52

4.4.1 Thông tin cấu hình của các dịch vụ Web thành phần 52

4.4.2 Phương thức đàm phán của dịch vụ Web thành phần BookingHotel 52

4.4.3 Phương thức đàm phán của dịch vụ Web thành phần BookingTour 55

4.4.4 Thời gian giới hạn sử dụng của các dịch vụ thành phần 57

4.5 Các giao diện của dịch vụ thành phần 58

4.5.1 Giao diện WSDL của BookingHotel 58

4.5.2 Giao diện WSDL của BookingTour 58

4.6 Lựa chọn hàm chức năng 58

4.6.1 Lựa chọn hàm chức năng dựa vào phương pháp tính tổng 58

4.6.2 Lựa chọn hàm chức năng dựa vào phương pháp chuẩn hóa 59

4.6.3 Lựa chọn hàm chức năng dựa vào phương pháp gán trọng số 60

4.6.4 Áp dụng phương pháp gán trọng số để so sánh các hàm chức năng trong khung đàm phán 61

4.7 Kết quả thực nghiệm 62

4.8 Tổng kết 66

KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU 67

TÀI LIỆU THAM KHẢO 69

PHỤ LỤC A: GIAO DIỆN WSDL CỦA BOOKINGHOTEL 71

PHỤ LỤC B: GIAO DIỆN WSDL CỦA BOOKING TOUR 74

DANH MỤC TỪ VIẾT TẮT

Chữ viết tắt Tiếng Anh

SOAP Simple Object Access Protocol

WSDL Web Services Description Language

UDDI Universal Description, Discovery and Integration

JSON JavaScript Object Notation

REST Representational State Transfer

HTTP HyperText Transfer Protocol

SMTP Simple Mail Transfer Protocol

DANH MỤC CÁC HÌNH

Hình 1-1 Mô hình JAXRPC [18] 4

Hình 1-2 Mô hình phân lớp dạng ngăn xếp trong công nghệ của dịch vụ Web [8] 11 Hình 1-3 Vòng đời dịch vụ Web kết hợp [12] 12

Hình 2-1 Mô tả cấu trúc dữ liệu trong UDDI [16] 16

Hình 2-2 Lược đồ miền của chính sách đàm phán [10] 21

Hình 3-1 Các thành phần chính trong kiến trúc của Axis2 [1] 24

Hình 3-2 Mô hình xử lý thông điệp SOAP [2] 27

Hình 3-3 Cấu trúc thông điệp mở rộng với một vài tiêu đề [3] 29

Hình 3-4 Các giai đoạn của luồng xử lý trong kiến trúc Axis2 [5] 30

Hình 3-5 Lời gọi dịch vụ Web đồng bộ [2] 37

Hình 3-6 Lời gọi dịch vụ Web bất đồng bộ [2] 37

Hình 4-1 Mô hình dịch vụ Web kết hợp chọn hàm chức năng của dịch vụ thành phần 41

Hình 4-2 Kiến trúc khung đàm phán chất lượng dịch vụ Web 42

Hình 4-3 Thông tin cấu hình của dịch vụ Web kết hợp Travel_WS 43

Hình 4-4 Biểu đồ tuần tự mô tả đàm phán giữa dịch vụ Travel_WS với dịch vụ thành phần 48

Hình 4-5 Lược đồ hoạt động của quá trình đàm phán giữa dịch vụ kết hợp Travel_WS với dịch vụ thành phần 49

Hình 4-6 Thông tin cấu hình của dịch vụ thành phần BookingHotel 52

Hình 4-7 Thông tin cấu hình chất lượng dịch vụ của dịch vụ Web kết hợp 61

DANH MỤC CÁC BẢNG

Bảng 2-1: Phân loại thành nhóm thuộc tính chất lượng dịch vụ trong dịch vụ Web 14Bảng 3-1: Mối quan hệ giữa phân cấp ngữ cảnh và phân cấp mô tả trong mô hình thông tin của Axis2 35Bảng 4-1: Minh họa phương pháp so sánh dựa trên tổng các thuộc tính chất lượng dịch vụ 58Bảng 4-2: Bảng minh họa giá trị gốc trong phương pháp chuẩn hóa 59Bảng 4-3: Bảng minh họa các giá trị đã được chuyển đổi trong phương pháp chuẩn hóa 59Bảng 4-4: Bảng minh họa các giá trị thuộc tính chất lượng dịch vụ trong phương pháp gán trọng số 60Bảng 4-5: Bảng minh họa tính tổng giá trị thuộc tính chất lượng dịch vụ trong phương pháp gán trọng số 61Bảng 4-6: Bảng biểu diễn tổng các thuộc tính chất lượng dịch vụ của các hàm chức năng trong dịch vụ BookingHotel 61Bảng 4-7: Bảng biểu diễn tổng các thuộc tính chất lượng dịch vụ của các hàm chức năng trong dịch vụ BookingTour 62Bảng 4-8: Bảng biểu diễn tổng các thuộc tính chất lượng dịch vụ của dịch vụ thành phần Travel_WS 62

MỞ ĐẦU

Ngày nay, công nghệ dịch vụ Web được áp dụng phổ biến và trở một phần quan trọng trong các hệ thống thông tin Dịch vụ Web được áp dụng trên nhiều miền ứng dụng khác nhau như trong thương mại điện tử, du lịch, giáo dục … Có được điều này do dịch vụ Web cung cấp phương tiện cho phép các ứng dụng phần mềm chạy trên nhiều nền tảng khác nhau trao đổi với nhau trên môi trường mạng

Số lượng nhà cung cấp dịch vụ Web và người sử dụng dịch vụ Web cũng tăng nhanh, đồng thời các yêu cầu của người dùng ngày càng trở nên phức tạp hơn Trong công nghệ dịch vụ Web, một dịch vụ Web mới có thể được xây dựng bằng cách sử dụng các dịch vụ Web đã tồn tại Dịch vụ Web mới được gọi là dịch vụ Web kết hợp Các dịch vụ Web có sẵn là dịch vụ Web thành phần Dịch vụ Web kết hợp không chỉ phụ thuộc vào chức năng của các dịch vụ thành phần mà còn phụ thuộc vào chất lượng dịch vụ của các dịch vụ đó

Luận văn này tập trung vào khía cạnh chất lượng dịch vụ của dịch vụ Web kết hợp Cụ thể, luận văn tìm hiểu về vấn đề đám phán giữa dịch vụ Web kết hợp và các dịch vụ Web thành phần để chọn các thông số chất lượng dịch vụ cho phù hợp với yêu cầu của người dùng Bài toán sẽ là: người dùng đưa ra yêu cầu chất lượng dịch vụ cho dịch vụ Web kết hợp là WS, làm thế nào để WS đàm phán và chọn ra dịch vụ Web thành phần thỏa mãn yêu cầu đưa ra Luận văn đề xuất một khung đàm phán chất lượng dịch vụ cho dịch vụ Web kết hợp Dịch vụ Web kết hợp trong khung được cung cấp các giá trị thuộc tính chất lượng dịch và các ràng buộc của nó

từ phía người dùng Số lượng thuộc tính chất lượng dịch vụ trong khung đàm phán này không bị giới hạn Khung này sử dụng phương pháp gán trọng trọng số để phân biệt độ ưu tiên của các thuộc tính chất lượng dịch vụ

Nội dung chính của luận văn được chia thành bốn chương Chương 1 trình bày tổng quan về dịch vụ Web, kiến trúc của dịch vụ Web, mô hình phân tầng trong dịch vụ Web, các phương pháp tiếp cận xây dựng dịch vụ Web kết hợp

Chương 2 trình bày về chất lượng dịch vụ trong dịch vụ Web, các thuộc tính chất lượng dịch vụ, các phương pháp cung cấp chất lượng dịch vụ Vấn đề đám phán trong dịch vụ Web như chính sách đàm phán, giao thức đàm phán, thông điệp đàm phán cũng được trình bày trong chương này

Chương 3 trình bày tổng quan về Axis2, các đặc điểm của Axis2, giới thiệu các mô đun trong Axis2 bao gồm: mô đun xử lý XML, mô đun thông tin, mô đun

xử lý thông điệp SOAP, mô đun triển khai, mô đun client API Các mô đun này là

những thành phần chính trong kiến trúc Axis2 Mỗi mô đun có một chức năng nhiệm vụ riêng và chúng liên kết với nhau tạo thành hệ thống trong Axis2

Chương 4 đưa ra mô hình khung đàm phán chất lượng dịch vụ dịch vụ Web, các dịch vụ được triển khai trên Axis2, cài đặt thử nghiệm bằng ngôn ngữ Java và

sử dụng các thư viện của Axis2

Phần cuối của luận văn là kết luận và hướng phát triển

Chương 1: TỔNG QUAN VỀ DỊCH VỤ WEB

Chương này giới thiệu tổng quan về dịch vụ Web Mục 1.1 trình bày khái niệm và đặc điểm của dịch vụ Web Kiến trúc của dịch vụ Web được trình bày ở mục 1.2 và các đặc điểm quan trọng của dịch vụ Web như SOAP, WSDL, UDDI được trình bày ở mục 1.3, 1.4 và 1.5 Mục 1.6 trình bày tổng quan về mô hình phân tầng trong dịch vụ, điều này giúp chúng ta hiểu được kiến trúc và các khả năng phát triển của dịch vụ Web Mục 1.7 trình bày về các vấn đề xây dựng dịch vụ Web kết hợp

1.1 Giới thiệu về dịch vụ Web

Có nhiều định nghĩa về dịch vụ Web, theo định nghĩa của [8] “Một dịch vụ Web là phần mềm mà làm cho bản thân nó luôn sẵn sàng trên Internet và sử dụng

hệ thống thông điệp dựa các tiểu chuẩn XML XML được sử dụng để mã hóa tất cả giao tiếp với dịch vụ Web Ví dụ, một khách hàng gọi một dịch vụ Web bằng cách gửi thông điệp XML, sau đó chờ XML phản hồi tương ứng Bởi vì tất cả giao tiếp trên dịch vụ Web là XML nên các dịch vụ Web không gắn bất kỳ với hệ thống hệ điều hành hoặc ngôn ngữ lập trình nào Các ứng dụng có thể giao tiếp với nhau mà không phục thuộc vào hệ điều hành và nền tảng của nhau.” Dịch vụ Web cung cấp giao thức và các định dạng dữ liệu phổ biến như HTTP, XML, SOAP, REST, WSDL, JSON để cho phép các ứng dụng trao đổi với nhau thông qua dịch vụ Web Dưới đây là một số đặc điểm chính của dịch vụ Web [6]

Dịch vụ Web có tính đồng bộ và bất đồng bộ Tính đồng bộ hoặc bất đồng

bộ được đề cập trong lời gọi của khách hàng khi muốn thực hiện một dịch vụ Web Tính đồng bộ là khối khách hàng phải chờ cho các hoạt động trước nó phải hoàn thành trước khi nó muốn được thực hiện Tính bất đồng bộ cho phép khách hàng gọi một dịch vụ sau đó thực hiện chức năng khác Tính không đồng bộ là yếu tố quan trọng để giúp hệ thống dịch vụ Web có mềm dẻo và linh hoạt hơn

Dịch vụ Web hỗ trợ các lời gọi từ xa (RPC) Dịch vụ Web cho phép khách

hàng gọi các hàm, các thủ tục và phương thức trên đối tượng điều khiển từ xa thông qua giao thức dựa trên XML Cả hai công nghệ Enterprise JavaBeans (EJBs) and NET được phân phối và truy cập thông qua một loạt các cơ chế RPC Hình 1.1 dưới đây mô tả mô hình JAX- RPC, JAX- RPC là thư viện phổ biến trên ngôn ngữ java hỗ trợ cho việc trao đổi thông điệp giữa người sử dụng dịch vụ (client) và nhà cung cấp dịch vụ Web (Web service)

Dịch vụ Web hỗ trợ cấu trúc dữ liệu dạng văn bản XML được sử dụng

để biểu diễn dữ liệu cho tất cả giao thức và thông điệp của dịch vụ Web Nên dịch

vụ Web có khả năng hỗ trợ cấu trúc dữ liệu dạng văn bản Điều này cho phép dịch

vụ Web biểu diễn các trúc dữ liệu từ đơn giản đến phức tạp và làm cho dịch vụ Web trở nên mềm dẻo và linh hoạt hơn trong trao đổi dữ liệu

Hình 1-1 Mô hình JAXRPC [18]

1.2 Kiến trúc dịch vụ Web

Có ba vai trò trong kiến trúc dịch vụ Web bao gồm: nhà cung cấp dịch vụ, nhà yêu cầu dịch vụ và đăng ký dịch vụ Trong đó, nhà cung cấp dịch vụ có vai trò xây dựng dịch vụ Web và làm cho dịch vụ đó luôn ở trạng thái sẵn sàng được sử dụng Nhà yêu cầu dịch vụ Web là đối tượng cần sử dụng dịch vụ Web, các đối tượng này sẽ gọi dịch vụ Web bằng cách gửi một thông điệp yêu cầu SOAP Đăng

ký dịch Web là một nơi tập trung chứa thông tin các dịch vụ, cho phép các nhà phát triển hoặc nhà cung cấp có thể xuất bản một dịch vụ Web mới hoặc tìm ra một dịch

vụ đã tồn tại Trong dịch vụ Web có ba thành phần chính là SOAP, WSDL và UDDI

- SOAP được quy ước theo một định dạng, được đóng gói và được hướng dẫn định tuyến giống như dạng phong bì thư Dạng phong bì thư có ý nghĩa cho mô

tả nội dung của thông điệp Cấu trúc thông điệp SOAP bao gồm hai thành phần chính là phần tiêu đề và phần thân và chúng được gói trong phần phong bì thư

- SOAP có một phương tiện vận chuyển hoặc một giao thức ràng buộc để cung cấp một cơ chế chung cho phép gửi một phong bì SOAP thông qua một giao thức ở mức thấp như HTTP

- SOAP có quy tắc mã hóa cung cấp một quy ước biểu diễn các thẻ dựa trên XML

- SOAP có cơ chế gọi các thủ tục từ xa (Remote Procedure Call) kí hiệu là RPC, nghĩa là SOAP hỗ trợ các lời gọi hàm từ xa Một trong những mục tiêu của SOAP là xây dựng cơ chế đóng gói thông điệp và thực hiện trao đổi thông qua các lời hỏi hàm từ xa Sử dụng SOAP cho RPC không bị giới hạn giao thức nhưng thông thường hay sử dụng giao thức HTTP

Một vấn đề đặt ra là, làm thế nào phân biệt cấu trúc dữ liệu XML và cấu trúc

dữ liệu SOAP, khi nào dữ liệu XML trở thành SOAP Giả sử chúng ta có cấu trúc

dữ liệu về một đơn hàng dạng XML như ở ví dụ 1.1, cấu trúc dữ liệu này không phải là một tài liệu SOAP, nó chỉ đơn giản là một tài liệu XML Các bước chuyển cấu trúc dữ liệu XML của ví dụ 1.1 thành một tài liệu SOAP theo những bước sau: gói dữ liệu XML ở vào bên trong một phần thân của SOAP Gói phần thân của SOAP vào bên trong phòng bì thư SOAP Đưa tùy chọn vào phần tiêu đề của SOAP, khai báo không gian tên (namespace), mã hóa dữ liệu XML, thiết lập các ràng buộc trong SOAP Khi đó, ta có cấu trúc dữ liệu một tài liệu SOAP như ở ví dụ 1.2

Ví dụ 1.1: mô tả cấu trúc dữ liệu XML về thông tin một đơn hàng

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<PurchaseOrder xmlsn="urn:xml-sample">

<shipTo country="VN">

<name>hoang xuan huy</name>

<street>123 xuan thuy</street>

Ví dụ 1.2: Cấu trúc dữ liệu một tài liệu SOAP về thông tin một đơn hàng

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<SOAP-ENV:Envelop

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelop" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<name>hoang xuan huy</name>

<street>123 xuan thuy</street>

Phần mô tả trừu tƣợng

Phần này chỉ cung cấp thông tin về đặc điểm giao diện của dịch vụ Web mà không có bất kỳ sự mô tả hoặc các thông tin liên quan đến công nghệ sử dụng để cài đặt dịch vụ Web Điều này làm cho dịch vụ Web không phải thay đổi phần mô tả khi nền tảng công nghệ triển khai dịch vụ Web bị thay đổi Phần mô tả trừu tượng của WSDL bao gồm các phần tử types, message và portType

Phần tử types định nghĩa các kiểu dữ liệu liên quan đến các thông điệp nhận

và thông điệp gửi của dịch vụ Web Phần tử types sử dụng định nghĩa lược đồ XML (XML schema definitions) viết tắt XSD để mô tả các kiểu dữ liệu cho phần tử types

Ví dụ 1.3 mô tả cấu trúc phần tử types trong một WSDL

Ví dụ 1.3: Cấu trúc phần tử types trong một WSDL

<types>

<schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema">

Phần tử message để biểu diễn trừu tượng cấu trúc của thông điệp Thông điệp

là phương tiện để trao đổi giữa bên yêu cầu dịch vụ và bên cung cấp dịch vụ Một thông điệp bao gồm một hoặc nhiều phần tử part Một phần tử part miêu tả một phần dữ liệu và kiểu dữ liệu của thông điệp Ví dụ 1.4 mô tả cấu trúc 2 thông điệp

có tên là GetLastTradePriceInput, GetLastTradePriceOutput Thông điệp GetLastTradePriceInput chứa phần tử có tên là body và kiểu dữ liệu TradePriceRequest, kiểu này được mô tả ở ví dụ 1.3

Thông điệp GetLastTradePriceOutput cũng chứa phần tử có tên là body và kiểu dữ liệu TradePrice, kiểu này cũng được mô tả ở ví dụ 1.3

Ví dụ 1.4: ví dụ mô tả cấu trúc phần tử message trong WSDL

Ví dụ 1.5: Cấu trúc phần portType trong WSDL

<portType name="StockQuotePortType">

Ví dụ 1.6: ví dụ mô tả cấu trúc phần tử binding trong WSDL

Ví dụ 1.7: Cấu trúc liên kết giữa các phần tử service và port trong WSDL

<service name="StockQuoteService">

<documentation>My first service</documentation>

<port name="StockQuotePort" binding="tns:StockQuoteBinding">

<soap:address location="http://example.com/stockquote"/>

</port>

</service>

Kết hợp các phần của các ví dụ từ 1.3 đến ví dụ 1.7 ta có mô tả đầy đủ của WSDL

về một dịch Web cung cấp giá cổ phiếu

1.5 UDDI

Mô tả và khám phá dịch vụ Web (Universal Description, Discovery and Integration) được viết tắt là UDDI UDDI được xây dựng dựa trên một số tiêu chuẩn công nghệ, bao gồm các thành phần như [16]: HTTP, XML, XSD, SOAP và WSDL Vì vậy, UDDI là nơi chứa thông tin về dịch vụ, cho phép đăng ký dịch vụ

và cho phép tìm kiếm dịch vụ Một số đặc điểm chính của UDDI bao gồm: 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à một nền tảng độc lập và một khung mở UDDI có thể giao tiếp trên các giao thức SOAP, CORBA và sử dụng WSDL để miêu tả giao diện cho các dịch vụ Web

1.6 Mô hình phân lớp dạng ngăn xếp trong dịch vụ Web

Trong kiến trúc dịch vụ Web bao gồm hai thành phần là thành phần lõi và thành phần mở rộng Trong đó, thành phần lõi là thành phần bắt buộc của một dịch

vụ Web bao gồm các lớp như sau: lớp giao thức giao tiếp, lớp thông điệp, lớp miêu

tả dịch vụ Web (WSDL) và lớp khám phá dịch vụ Web (UDDI) Lớp giao thức giao tiếp có thể sử dụng một số giao thức HTTP, SMTP, FTP trong dịch vụ Web Lớp thông điệp gồm các dữ liệu dạng XML và giao thức SOAP

Thành phần mở rộng bao gồm lớp chất lượng dịch vụ và lớp xử lý logic Thành phần mở có vai trò hỗ trợ phát triển các yêu cầu cao cấp trong xây dựng dịch

vụ Web Vì vậy các mô hình của thành phần mở rộng này được xây dựng tùy thuộc vào nhu cầu tổ chức phát triển Hình 1.2 mô tả tất các lớp ở dạng ngăn xếp trong công nghệ dịch vụ Web Từ đó chúng ta thấy được một khả năng quan trọng của dịch vụ Web là cho phép kết hợp các dịch vụ đơn lẻ để tạo thành một dịch mới, để

có thể đáp ứng các yêu cầu phức tạp của người dùng

Hình 1-2 Mô hình phân lớp dạng ngăn xếp trong công nghệ của dịch vụ Web [8]

1.7 Phương pháp xây dựng dịch vụ Web kết hợp

Dịch vụ Web kết hợp là sự kết hợp của hai hay nhiều dịch vụ Web thành phần để tạo thành một dịch vụ mới thỏa mãn các yêu cầu hay nghiệp vụ phức tạp của người dùng Có hai loại dịch vụ Web kết hợp là dịch vụ Web kết hợp bằng tay

và dịch vụ Web kết hợp tự động Nhược điểm của dịch vụ Web kết hợp bằng tay là mất nhiều thời gian để tổng hợp, dễ bị lỗi và không khó có khả năng mở rộng Vì vậy, các nghiên cứu về xây dựng hợp dịch vụ Web kết hợp chủ yếu tập trung cho dịch vụ Web kết hợp tự động Xây dựng dịch vụ Web kết hợp tự động có hai phương pháp tiếp cận chính là: phương pháp dựa trên quy trình công việc (workflow) và phương pháp dựa vào lập kế hoạch trí tuệ nhân tạo [12]

Phương pháp lập kế hoạch dựa trí tuệ nhân tạo bao gồm các yếu tố sau: mô tả trạng thái của các dịch vụ Web, xác định mục tiêu mong muốn của trạng thái, mô tả tập hợp các hoạt động có thể để chuyển đổi từ trạng thái này sang trạng thái khác Các thành phần lập kế hoạch có mục đích tìm ra chuỗi các hành động để làm thay đổi trạng thái của thế giới thực từ trạng thái ban đầu đến trạng thái mục tiêu Các kỹ thuật lập kế hoạch dựa trên trí tuệ nhân tạo trong xây dựng dịch vụ Web kết hợp đã được nghiên cứu khoảng hơn 10 năm Tuy nhiên, các kỹ thuật này không đạt được thành công đối với các ứng dụng trong thực tế

Phương pháp xây dựng dịch vụ Web kết hợp dựa quy trình làm việc được thực hiện dựa vào việc trừu tượng quy trình thực tế và chúng có khả năng cao để chuyển hóa từ mô hình thực tế sang mô hình dịch vụ Web kết hợp Một quy trình làm việc thường không phù hợp ngay với dàn các dịch vụ Web bởi một số lý do: các dịch vụ Web không thể ngay lập tức phù hợp với các thành phần trong quy trình làm việc, các dịch vụ Web trong giàn nhạc có tính ràng buộc với nhau nhưng không phải dễ dàng có thể ứng dụng trong quy trình kinh doanh

Hình 1-3 Vòng đời dịch vụ Web kết hợp [12]

Hình vẽ 1-3 mô tả về vòng đời của dịch vụ Web kết hợp dựa trên quy trình làm việc (workflow) Đây chính là mô hình tổng quát để xác định ra các bước chính cho xây dựng dịch vụ Web kết hợp Từ đó, chúng ta có thể xem xét từng thành phần trong quy trình thực tế để áp dụng vào từng phần trong mô hình dịch vụ Web kết hợp Sau đây là các giai đoạn về vòng đời của dịch vụ Web kết hợp

- Giai đoạn đặc tả mục tiêu: trong đó các mục tiêu và các sở thích của nhà yêu cầu dịch vụ được xác định Sau đó mục tiêu này được phân rã tự động hoặc bán

tự động thành các quá trình kinh doanh Quá trình kinh doanh bao gồm các nhiệm

vụ (task), mỗi nhiệm vụ có một chức năng rõ ràng cùng với kiểm soát luồng dữ liệu qua lại giữa các nhiệm vụ

- Giai đoạn phát hiện dịch vụ: các dịch vụ Web cụ thể phù hợp với yêu cầu chức năng và phi chức năng của nhiệm vụ được tìm kiếm ở nơi đăng ký dịch vụ như UDDI Kết quả của tìm kiếm có khả năng trả ra nhiều hơn một dịch vụ

- Giai đoạn lựa chọn dịch vụ: giai đoạn này được thực hiện sau khi phát hiện ra các dịch vụ Trong giai đoạn này, rất nhiều phương pháp được đề xuất để

lựa chọn ra dịch vụ Web thành phần tối ưu nhất Từ đó, dich vụ Web kết hợp được tạo ra từ sự kết hợp các dịch vụ thành phần này

- Giai đoạn thực hiện và giám sát dịch vụ: khi lựa chọn dịch vụ thành phần được hoàn thành, thì có thể sử dụng được dịch vụ kết hợp này bằng cách thực hiện dịch vụ (Service execution) Quá trình sử dụng dịch vụ kết hợp được theo dõi và giám sát để kiểm soát sự thay đổi các trạng thái hay kiếm soát sự thất bại của các dịch vụ trong quá trình kết hợp

Chương 2: CHẤT LƯỢNG DỊCH VỤ VÀ ĐÀM PHÁN DỊCH

VỤ WEB

Chương này trình bày tổng quan về chất lượng dịch vụ của dịch vụ Web và các thuộc tính chất lượng dịch vụ ở mục 2.1.1 Mục 2.1.2 trình bày các phương pháp cung cấp thông tin chất lượng dịch cho dịch vụ Web Mục 2.2 trình bày các vấn đề liên quan đến đàm phán dịch vụ Web

2.1.1 Các thuộc tính chất lượng dịch vụ

Các yêu cầu chất lượng dịch vụ cho dịch vụ Web chủ yếu đề cập đến các khía cạnh chất lượng của một dịch vụ Web Chất lượng dịch vụ của dịch vụ Web bao gồm: độ sẵn sàng, độ tin cậy, tính an ninh, thời gian đáp ứng, chi phí, thông lượng, khả năng tương tác và các yêu cầu chất lượng dịch vụ liên quan đến mạng Bảng 2.1 dưới đây phân loại thành từng nhóm thuộc tính chất lượng dịch vụ của dịch vụ Web

Bảng 2-1: Phân loại thành nhóm thuộc tính chất lượng dịch vụ trong dịch vụ Web

Nhóm chất

lượng dịch

vụ

Thuộc tính chất lượng dịch vụ

Mô tả

Hiệu suất Thời gian phản hồi Là khoảng thời gian trôi giữa sự bắt đầu yêu

cầu dịch vụ và hoàn thành phản hồi của dịch

vụ Thời gian phản hồi = Thời gian thực hiện + thời gian chờ

Thời gian thực hiện là khoảng thời gian thực hiện chức năng của dịch vụ Thời gian chờ là tổng thời gian cho tất cả các sự kiện gián tiếp như thời gian thông điệp được chuyển đổi giữa người sử dụng dịch vụ và nhà cung cấp dịch vụ

Thông lượng Thông lượng dịch vụ = Số yêu cầu tối đa /

Đơn vị thời gian

Độ tin cậy Là khả năng chức năng yêu cầu trong dịch vụ

Web được thực hiện

Tính sẵn sàng Là xác suất mà một dịch vụ Web ở trạng thái

sẵn sàng

Chi phí Giá cả Giá cả là bên yêu cầu dịch vụ phải trả khi gọi

một hoạt động đặc biệt của dịch vụ Web Giá

cả của chức năng trong dịch vụ Web càng cao thì độ phức tạp của chức năng đó càng lớn

An ninh Xác thực Xác thực trong dịch vụ Web có mục đích

ngăn chặn một kẻ xâm nhập giả mạo

Độ tin cậy Trong dịch vu Web, để ngăn không cho kẻ

trộm nghe lén thông điệp trong dịch vụ Web Phương pháp mã hóa thông điệp trước gửi và giải mã thông điệp nhận đem lại tính tin cậy trong bảo mật của dịch vụ Web

Tính toàn vẹn Trong một số trường hợp trao đổi thông điệp,

dữ liệu này quan trọng Vì vậy bộ phận nhận thông điệp xác nhận thông điệp không bị sửa đổi trong quá trình truyền Điều này đảm bảo

kẻ xâm nhập không thể thay thế thông điệp bất hợp pháp Hay nói cách khác, nó chính là tính toàn vẹn trong trao đổi thông điệp

2.1.2 Phương pháp cung cấp chất lượng dịch vụ

Cung cấp thông tin chất lượng dịch vụ của các dịch vụ Web thành phần đóng vai trò quan trọng trong việc xây dựng dịch vụ Web kết hợp Đối với mỗi dịch vụ Web thành phần đã có nhiều giải pháp được đề xuất để cung cấp thông tin chất lượng dịch vụ

Phương pháp 1: cung cấp thông tin chất lượng dịch vụ dựa vào UDDI

UDDI ngoài các chức năng chính chứa thông tin dịch vụ Web, cung cấp xuất bản và tìm kiếm dịch vụ Web thì UDDI có khả năng chứa thông tin chất lượng dịch vụ cho dịch vụ Web Cấu trúc của UDDI cho phép mô tả thêm các thông tin chất lượng dịch vụ khi cần thiết

Hình 2-1 Mô tả cấu trúc dữ liệu trong UDDI [16]

Hình 2.1 thể hiện cấu trúc dữ liệu của UDDI, bao gồm năm thành phần như sau:

- Thành phần BusinessEntity chứa các thông tin cơ bản của dịch vụ gồm phân loại, định danh, mô tả và mối quan hệ với các dịch vụ khác

- Thành phần publisherAssertion được sử dụng để thiết lập mối quan hệ giữa các BusinessEntity

- Thành phần businessService để mô tả tập hợp các dịch vụ, những dịch vụ này có thể là một dịch vụ Web hoặc một dịch loại khác như dịch vụ hướng dẫn sử dụng Một thành phần BusinessEntity chứa một hoặc nhiều thành phần businessService

- Thành phần bindingTemplate chứa một văn bản mô tả và địa chỉ của điểm truy cập của dịch vụ Web Ngoài ra bindingTemplate đóng vai trò là một con trỏ để trỏ đến thành phần tModel

- Thành phần tModel chứa thông tin mô tả đặc điểm của dịch vụ Web để con trỏ của tModel có thể tham chiếu đến dịch vụ đó Hơn nữa, thành phần tModel cho phép chứa chứa thông tin chất lượng dịch vụ Thông tin của chất lượng dịch vụ trong tModel bao gồm: name, value, unit Như vậy, thông tin chất lượng dịch vụ có thể chứa trong mô hình tModel Ví dụ 2.1 dưới đây minh họa thông tin chất lượng dịch vụ chứa trong UDDI

Ví dụ 2.1: Lưu trữ thông tin chất lượng dịch vụ ở UDDI

<tModel tModelKey="uuid:1C620754-09E4-4930-AA19-709C62E52166"> <name>uudi-org:qosInfo</name>

<description xml:lang="en">Quality of Service Information

</tModel>

Phương pháp 2: cung cấp thông tin chất lượng dịch vụ dựa vào SOAP Do

SOAP có khả năng hỗ trợ tìm kiếm dịch vụ Web, nên chúng ta có thể đính kèm thông tin chất lượng dịch vụ trong mục tìm kiếm này Việc này được thực hiện bằng cách mở rộng cấu trúc của thông điệp SOAP Giả sử chúng ta có một thông điệp SOAP chứa thông tin truy vấn để tìm một dịch vụ đặt xe chứa thông tin chất lượng dịch vụ với độ sẵn sàng là 0.9 được mô tả như ví dụ 2.2 [17]

Ví dụ 2.2: Lưu trữ thông tin chất lượng dịch vụ ở UDDI

<?xml version="1.0" encoding="UTF-8"?>

<envelop xmlns= "http://schmas.xmlsoap.org/soap/envelop/">

<body>

<find_service businessKey="*" generic="1.0"

Phương pháp 3: dịch vụ Web thành phần chứa các hàm chất lượng dịch vụ

Trong phương pháp này, dịch vụ Web thành phần xây dựng thêm các hàm chất lượng dịch vụ, các hàm này có chức năng chỉ cung cấp thông tin chất lượng dịch vụ cho các hàm chức năng trong dịch vụ Web Vì vậy, các hàm chất lượng dịch vụ này cũng được mô tả ở trên WSDL của dịch vụ Web Trước khi người dùng muốn sử dụng một hàm chức năng, người dùng có kiểm tra thông tin chất lượng dịch vụ của các hàm này thông qua một số hàm chất lượng dịch vụ Ưu điểm của phương pháp này có tính mềm dẻo, tính tiện dụng trong kiểm tra thông tin chất lượng dịch vụ cho dịch vụ Web thành phần, trong xây dựng dịch vụ Web kết hợp dựa trên thông tin chất lượng dịch vụ

Trên đây là ba phương pháp để thể hiện chất lượng dịch vụ trong dịch vụ Web Mỗi phương pháp đều có ưu điểm ra nhược điểm riêng Trong nội dung luận văn này, tác giả chọn phương pháp 3 để chứa thông tin chất lượng dịch vụ cho dịch

vụ Web thành phần Phương pháp này sẽ được trình bày cụ thể trong chương 4 của luận văn

2.2 Đàm phán dịch vụ Web

Đàm phán là sự tương tác giữa các bên trong một nỗ lực đạt được một số thỏa thuận về một khía cạnh cụ thể Một quá trình đám phán có thể gồm một hoặc nhiều vòng đàm phán Trong mỗi vòng đàm phán, bên khởi tạo (initiator) gửi một

đề nghị tới bên khác Nếu đề nghị này được chấp nhận thì vòng đàm phán này kết thúc và quá trình đàm phán chỉ cần thực hiện một vòng đàm phán Ngược lại, đề nghị này không được chấp nhận thì bên khởi tạo (initiator) gửi một đề nghị mới cho các bên đàm phán và quá trình đàm phán phải thực hiện một vòng đàm phán mới Quá trình đàm phán được kết thúc khi các bên đạt được một sự thỏa thuận về một khía cạnh cụ thể [11]

Các cuộc đàm phán của các bên có thể là song phương hoặc đa phương Các bên giao tiếp với nhau bằng sử dụng các giao thức đàm phán cho đến khi đạt được

sự thỏa thuận với nhau Trong đàm phán được chia làm hai loại Loại đầu tiên là đàm phán phân phối hay thường gọi là đàm phán thắng thua (win-lose) Nghĩa là khi hai bên thực hiện đàm phán thì một bên đạt được mục đích của mình và bên còn lại thì bị hỏng và không nhận ra chính nó Loại thứ hai là đàm phán tích hợp hay thường gọi là đàm phán thắng thắng (win-win) Đàm phán tích hợp đề cập đến quá trình mà cả hai bên đều xác định được mục tiêu cho mình thông qua việc hai bên thỏa thuận cùng đạt được một tiện ích chung Một ưu điểm chính của đàm phán tích hợp là luôn giảm khả năng đàm phán sẽ thất bại Vì vậy đàm phán tích hợp được sử dụng nhiều hơn

Trong tổng hợp chất lượng dịch vụ của dịch vụ Web thường sử dụng đàm phán về hiệp định ở mức độ dịch vụ (Service Level Agreements) được viết tắt là SLAs Các xử lý đàm phán liên quan đến các đặc điểm kỹ thuật của tham số đàm phán, sự trao đổi giữa các thành phần trong quá trình đàm phán và cuối cùng tạo ra SLAs nếu các bên đàm phán đi đến một sự đồng thuận Để xây dựng mô hình đàm phán thỏa thuận ở mức độ dịch vụ của dịch vụ Web thường dựa vào một số đặc điểm sau: dựa vào các thuộc tính của dịch vụ, dựa vào đặc điểm yêu cầu của người dùng, dựa vào mức độ ưu tiên

Đàm phán dịch vụ Web là một trong những vấn đề được quan tâm nhiều, nên

có rất nhiều nghiên cứu về đàm phán dịch vụ Web INSPIRE [19] là khung đàm phán dịch vụ Web hỗ trợ trong lĩnh vực văn hóa INSPIRE có thể tiến hành đàm phán nặc danh (negotiation anonymously), đánh giá các lời đề nghị và xem lại lịch

sử của quá trình đàm phán INSPIRE hỗ trợ nhiệm vụ ưu tiên, phân tích các đề nghị, thay thế đề nghị, đánh giá các phản hồi cung cấp và đánh giá hiệu quả của sự thỏa hiệp bằng cách sử dụng tối ưu Pareto

NegoPlan [20] là một hệ chuyên gia xây dựng các vấn đề chiến lược, NegoPlan dựa trên các luật để biểu diễn các hoạt động của đàm phán, để phát triển một vấn đề đại diện, để cung cấp thông tin, để duy trì một cấu trúc cho phép đồng nhất và có hợp lệ của một mô hình được xác minh NegoPlan tập trung về chiến lược cho các hoạt động đàm phán, nên NegoPlan không hỗ trợ cho các khía cạnh khác của hoạt động đàm phán

Tete-a-Tete [21] là một ứng dụng bán lẻ và Tete-a-Tete đã tích hợp phương pháp đàm phán vào ứng dụng Đại lý mua hàng và bán hàng thương lượng qua nhiều điều khoản của giao dịch bao gồm cảnh báo, thời gian giao dịch, hợp đồng dịch vụ, chính sách trả, tùy chọn cho vay, dịch vụ quà tặng, các dịch vụ gia tăng

Các khung đàm phán được nêu ở trên đa số chỉ tập trung giải quyết một bài toán cụ thể, nếu muốn áp dụng bài toán khác vào trong khung thì vấn đề này chưa thấy đề cập đến Vì vậy, mục đích trong khung đàm phán dịch vụ Web của luận văn sẽ tập trung xây dựng khung đàm phán về khía chất lượng dịch vụ, khung đảm bảo có tính mềm dẻo, có thể áp dụng được nhiều toán khác nhau

2.2.1 Chính sách đàm phán

Chính sách được hiểu cơ bản là đặt ra các quy tắc trong đó xác định một hành động hay một sự xác nhận được thực hiện khi một điều kiện nhất định nào đó được đáp ứng, khi đó dẫn đến các quyết định được hiện để đạt mục tiêu nhất định Mỗi chính sách đàm phán thường có một đặc tả miền cụ thể khác nhau Các yếu tố chính trong miền là: ngữ cảnh, mục đích, ràng buộc, vấn đề ưu tiên hay vấn đề tùy chọn và một số yếu tố khác như ở hình 2-2

Yếu tố ngữ cảnh: có ba loại ngữ cảnh được đề cập trong chính sách đàm

phán Một là ngữ cảnh đàm phán (Negotiation Context), ngữ cảnh này dùng đề cập một bối cảnh cụ thể mà chính sách sẽ áp dụng Hai là ngữ cảnh người tiêu dùng (Consumer Context), ngữ cảnh này dùng đề cập đến thông ngữ cảnh của các bên đàm phán Ba là ngữ cảnh khác (Other Context), ngữ cảnh này đề cập đến bối cảnh khác của các bên đàm phán

Yếu tố mục tiêu: mỗi bên đàm phán thường có nhiều mục tiêu và chúng

được phân cấp Ví dụ như trong đàm phán chất lượng dịch vụ, các mục tiêu ở mức

độ cao như: độ sẵn sàng của dịch vụ, thời gian phản hồi hay chi phí phải trả khi sử dụng dịch vụ Căn cứ vào mức độ của mục tiêu mà các nhà cung cấp dịch vụ có thể đưa ra bảng phân cấp các đặc điểm kỹ thuật về chính sách đàm phán

Các vấn đề và tùy chọn: các vấn đề là những tham số đàm phán trong một

nhà cung cấp dịch vụ và các tùy chọn là các giá trị khác nhau mà các tham số đàm phán có thể có Các bên đàm phán cần phải xác định giá trị tốt nhất, giá trị tồi nhất, giá trị chấp nhận được đối với từng tùy chọn

Độ ƣu tiên: các bên đàm phán này có thể xác định các giá trị ưu tiên cho các

mục đích khác nhau khi trường hợp có nhiều hơn một mục tiêu được áp dụng Vấn

đề này phục vụ cho giải quyết xung đột và các vấn đề tùy chọn cho mục đích cân bằng

Hình 2-2 Lƣợc đồ miền của chính sách đàm phán [10]

2.2.2 Thông điệp đàm phán

Các dịch vụ thành phần sử dụng thông điệp để trao đổi với nhau trong quá trình đàm phán Khi dịch vụ A đàm phán dịch B thì một thông điệp yêu cầu (Request message) được gửi từ dịch A tới dịch vụ B, dịch vụ B sẽ phản hồi cho thông điệp A với một thông điệp phản hồi (Respone message) Ví dụ 2.3 minh họa

về thông điệp trong xử lý đàm phán thuê xe ô tô

Ví dụ 2.3: Thông điệp đàm phán thuê xe ô tô

<negotiationMessage id="1854" ref="None" type="Offer">

- Giao thức Call For Proposal (CFP) thường dùng để gọi một đề nghị

- Giao thức Propose dùng đề đề xuất một đề nghị hoặc mời truy cập với bên đàm phán khác

- Giao thức Acept dùng để chấp nhận một đề nghị hay một lời mời tham gia

từ bên đàm phán khác

- Giao thức Terminate dùng để chấp dứt quá trình đàm phán

- Giao thức Reject dùng để từ chối một lời đề nghị hoặc lời mời tham gia từ bên đàm phán Tuy nhiên bên sẵn sàng sẽ phải xem xét lời đề nghị hoặc lời mời tham gia

- Giao thức Acknowledge dùng để xác nhận việc tiếp nhận lời đề nghi hay lời mời tham gia

- Giao thức Modify dùng để thay đổi lời đề nghị hay lời mời tham gia trước khi phản hồi cho bên đàm phán kia

Giao thức đàm phán có nhiều ngữ nghĩa hơn thông điệp đàm phán Mỗi giao thức đàm phán có tiền điều kiện và hậu điều kiện, một số giao thức tương đương với thông điệp Tuy nhiên các giao thức phải tuân theo các quy định và các ràng buộc của các bên đàm phán

2.3 Tổng kết

Chương này đã trình bày tổng quan về chất lượng dịch của dịch vụ Web Các thuộc tính chất lượng dịch vụ chính là thành phần cơ bản về chất lượng dịch vụ của dịch vụ Web Ngoài ra, chương này đã giới thiệu một số kỹ thuật có thể biểu diễn chất lượng dịch vụ cho dịch vụ Web Phần còn lại của chương này đã trình bày về vấn đề đàm phán dịch vụ Web như: thông điệp đàm phán, giao thức đàm phán và chính sách đàm phán

Chương 3: TÌM HIỂU VỀ AXIS2

Axis2 là khung chương trình để triển khai dịch vụ Web Tất cả các dịch vụ Web trong khung đàm phán của luận văn được triển khai trên Axis2 Mục 3.1 giới thiệu tổng quan về Axis2 Thành phần chính trong kiến trúc của Axis2 là bao gồm các mô đun: mô đun xử lý XML, mô đun xử lý thông điệp SOAP, mô đun giao vận,

mô đun triển khai, mô đun thông tin, mô đun giao diện lập trình ứng dụng cho khách hàng Mục 3.2, 3.3, 3.4, 3.5, 3.6 sẽ lần lượt giới thiệu về các mô đun này

3.1 Giới thiệu Axis2

Thế hệ đầu tiên của khung chương trình dịch vụ Web là Apache SOAP Thế

hệ thứ hai là Apache Axis, các đặc điểm của Axis tham khảo tại [4] Axis trở thành một trong những dự án thành công nhất của Apache và được sử dụng nhiều trong công nghiệp Do sự phát triển nhanh của ngành công nghiệp dịch vụ Web nên rất nhiều các tổ chức đã chuyển sang sử dụng dịch vụ Web, từ đó phát sinh ra các tiêu chuẩn mới về dịch vụ Web Đặc biệt, sự phát triển của điện toán đám mây (Cloud computing) cũng đưa ra một số thách thức với công nghệ dịch vụ Web Vì vậy Apache Axis không thể đáp ứng được hết các yêu cầu hiện tại

Một dự án phát triển Apache Axis2 được ra đời vào năm 2004 Axis2 là thế

hệ tiếp theo của Axis1, Axis2 được xây dựng trên một kiến trúc mới thỏa mãn tính mềm dẻo, hiệu quả hơn Axis1 Một số tính năng mới và sự cải tiến được giới thiệu

ở Axis2 như là AXIOM, dịch vụ Web bất đồng bộ, MTOM, hỗ trợ MEPs

3.1.1 Các đặc điểm chính của Axis2

- Axis2 cung cấp một khung chương trình để xử lý các thông điệp SOAP Khung chương trình này có thể được mở rộng trong các xử lý thông điệp SOAP hoặc trong các hoạt động cơ sở Hơn nữa, Axis2 cho phép mô hình hóa các dạng trao đổi thông điệp khác nhau (MEPs) để được sử dụng ở trong khung xử lý (processing framework) [3]

- Axis2 có khả năng triển khai một dịch vụ Web với sự hỗ trợ của WSDL hoặc không cần WSDL

- Axis2 cung cấp giao diện thao tác người dùng (Client API) sử dụng để gọi các dịch vụ Web Giao diện thao tác người dùng có thể hỗ trợ cho các hai mô hình đồng bộ và bất đồng bộ

- Axis2 cho phép thay đổi thông tin cấu hình hoặc ở các thành phần của nó trong triển khai dịch vụ Web

- Axis2 cung cấp khả năng nhận và gửi các thông điệp SOAP với nhiều giao thức khác nhau

3.1.2 Ƣu điểm của Axis2

Axis2 đã cải thiện tốc độ xử lý XML bằng việc sử dụng công nghệ phân tích

cú pháp, khả năng linh hoạt trong mở rộng kiến trúc, hỗ trợ các tiêu chuẩn kỹ thuật của dịch vụ Web hiện tại cũng như các tiêu chuẩn kỹ thuật trong tương lại Ngày nay, Apache Axis2 là một mã nguồn mở của khung chương trình dịch vụ Web cho ngôn ngữ Java và Axis2 được sử dụng nhiều trong ngành công nghiệp và cả trong

giới học thuật

Sự tách biệt giữa logic (logic) và trạng thái (states) trong Axis2, nên các đoạn mã xử lý không có trạng thái bên trong Axis2 Điều này cho phép các đoạn mã

có thể thực hiện tự do bởi các luồng song song (pararellel threads)

Tất cả các thông tin của Axis2 được giữ trong một mô đun thông tin, điều này cho phép hệ thống bị đình chỉ hay tiếp tục sử dụng Khả năng mở rộng các hỗ trợ cho các dịch vụ Web mà không cần cấu hình phức tạp ở phía kiến trúc lõi

Hình 3-1 Các thành phần chính trong kiến trúc của Axis2 [1].

Axis2 được xây dựng trên kiến trúc mô đun (Module) bao gồm các mô đun lõi tạo nên kiến trúc cốt lõi của Axis2, các module không lõi là một lớp trên của các

mô đun lõi như ở hình 3.1

3.1.3 Các mô đun lõi của Axis2

Mô đun xử lý XML (XML Processing model): mô đun này quản lý hoặc xử

lý thông điệp SOAP là một trong những phần khó khăn nhất trong việc thực hiện một thông điệp Vấn đề nâng cao hiệu suất trong xử lý thông điệp mà một trong

những nhân tố quan trọng nhất để quyết định hiệu suất của một hệ thống dịch vụ Web Axis xử dụng DOM để biểu diễn lược đồ của thông điệp thì Axis2 sử dụng kỹ thuật XML InfoSet để biểu diễn thông điệp SOAP, kỹ thuật này được biết đến trong thuật ngữ AXIOM

Mô đun mô hình xử lý SOAP (SOAP Processing model): mô đun này kiểm soát sự thực hiện của các xử lý, xác định các giai đoạn khác nhau mà việc thực hiện

sẽ phải đi qua, người sử dụng có thể mở rộng mô hình xử lý SOAP này tại các địa điểm cụ thể

Mô đun mô hình thông tin (Information model): mô đun này để quản lý xử lý thông tin Mô hình này có một số đặc điểm chính sau như: khả năng lưu trữ hai trạng thái tĩnh và động, có một thành phần riêng biệt để xử lý các thông tin logic tương ứng, quản lý phiên làm việc và quản lý vòng đời của một dịch vụ

Mô đun triển khai: mô đun này cho phép người dùng dễ dàng triển khai các dịch vụ, thực hiện cấu hình và mở rộng mô hình xử lý SOAP Mô hình này hỗ trợ

cơ chế triển khai nóng, cập nhật nóng nghĩa là cho phép cập nhật thông tin mới nhất trên môi trường đang chạy

Mô đun giao diện thao tác phía người dùng (Client API): mô đun này cung cấp một giao diện thao tác thuận tiện cho người dùng tương tác với các dịch vụ Web khi sử dụng Axis2

Mô đun giao thức vận chuyển: Axis2 định nghĩa một khung vận chuyển cho phép người dùng sử dụng và tiếp xúc với các dịch vụ tương tự nhau trong nhiều giao thức vận chuyển khác nhau Các giao thức vận chuyển đó phù hợp với cho những nơi cụ thể trong mô hình xử lý SOAP Axis2 cung cấp một vài phương thức vận chuyển như : HTTP, SMTP, JMS, TCP Ngoài ra, người cùng có thể viết thêm hoặc tùy chỉnh giao thức vận chuyển trong trường hợp cần thiết

3.1.4 Các mô đun khác của Axis2 (Mô đun không lõi)

Mô đun sinh mã: Axis2 cung cấp một cung cụ sinh mã được tạo từ phía máy chủ (Server) và phía máy khách (Client) cùng với một mô tả Công cụ này giúp đơn giản hóa việc triển khai dịch vụ và gọi dịch vụ, từ đó tăng khả năng sử dụng của Axis2

Trên đây là những thông tin cơ bản về các mô đun chính trong kiến trúc của Axis2 Ở các mục tiếp theo giới thiệu chi tiết về một số mô đun lõi, từ đó chúng ta

có cái nhìn sâu hơn về kiến trúc của Axis2

3.2 Mô đun xử lý XML

Axis1 sử dụng DOM để thể hiện lược đồ XML và toàn bộ cấu trúc phân cấp đầy đủ của đối tượng DOM được lưu trữ trong bộ nhớ Điều này không có vấn đề gì khi kích thước của thông điệp là nhỏ Nhưng khi kích thước của thông điệp lớn, nên đây là một vấn đề của Axis1 Axis2 đã khắc phụ điều này bằng cách sử dụng một kỹ thuật mới gọi là trục mô hình đối tượng (AXIs Object Model) viết tắt là AXIOM để thể hiện lược đồ XML

3.2.1 Trục mô hình đối tƣợng (AXIOM)

Trục mô hình đối tượng sử dụng mô hình XML Infoset để thể hiện lược đồ XML Ngoài ra, AXIOM sử dụng kỹ thuật phân tích cú pháp kéo (PULL), trong khi các kỹ thuật biểu diễn lược đồ XML khác đều sử dụng kỹ thuật phân tích cú pháp đẩy (PUSH) Ưu điểm của kỹ thuật kéo (PULL) hơn kỹ thuật đẩy (PUSH) là các lời gọi có toàn quyền kiểm soát trong phân tích cú pháp, trong hành động và các sự kiện tiếp theo chỉ thị của người dùng Người dùng có thể quyết định lưu trữ hoặc loại bỏ các sự kiện được tạo ra từ phân tích cú pháp Ban đầu AXIOM được phát triển như là một thành phần của Apache Axis2 Tuy nhiên, sau đó nó trở thành một

dự án WS Component để các dự án khác Axis2 có thể kế thừa được Đặc điểm chính của trục mô hình đối tượng (AXIOM) [1]

- Tính trọng lượng nhẹ trong biểu diễn XML (Lightweight) AIXOM tối ưu hóa trong biểu diễn XML Infoset bằng cách giảm độ sâu của hệ thống phân cấp, giảm số lượng các phương thức và các thuộc tính trong các đối tượng

- Tính trì hoãn (Deferred building): đây là một trong những đặc điểm nhất của AXIOM Điều này có nghĩa là xây dựng mô hình đối tượng chỉ khi nó hoàn toàn cần thiết Các đối tượng không thực hiện trừ khi cần một nhu cầu cho chính họ

- Sử dụng kỹ thuật phân tích kéo: AXIOM xây dựng các giao diện lập trình ứng dụng (API) cho kỹ thuật phân tích kéo trong xử lý dữ liệu XML

Phương pháp truyền thống trong xử lý dữ liệu XML thường xây dựng giao diện lập trình ứng dụng dựa trên cây (Tree based APIs) bằng cách sử dụng DOM

Về cơ bản của phương pháp này thường tải toàn bộ dữ liệu XML vào bộ nhớ và xử

lý nó Nên các mô hình DOM khi được xây dựng thường lớn hơn so với tài liệu XML ban đầu, do đó gây lãng phí bộ nhớ và ảnh hưởng đến tốc độ truy cập

Một phương pháp mới hơn trong xử lý dữ liệu XML là xây dựng giao diện lập trình ứng dụng dựa trên sự kiện (Events base APIs ) Khi có một loại phân tích

cú pháp được đưa ra cho một XML xử lý, nó sẽ gửi sự kiện tương ứng với các mục thông tin mà nó tìm thấy Phương pháp này sử dụng SAX là một tiêu chuẩn phân

tích cú pháp để xử lý XML Phương pháp này hiệu quả hơn DOM về bộ nhớ Nhưng cả hai phương pháp này vẫn gặp phải nhược điểm là không kiểm soát tốt được tất cả sự kiện trong quá trình phân tích dữ liệu XML Khi một quá trình phân tích XML bắt đầu, phương pháp dựa trên mô hình cây hoặc dựa trên mô hình sự kiện đều phải tiêu thụ toàn bộ luồng dữ liệu cùng một lúc

Vì vậy một phương pháp mới phân tích dữ liệu XML của AXIOM sử dụng

mô hình kéo trực tuyến hay gọi tắt là StAX( Streaming API for XML ) để xử lý dữ liệu XML khắc phục những nhược điểm của các phương pháp trên Trong mô hình này, người dùng có thể bắt đầu, tiến hành, tạm dừng và tiếp tục quá trình phân tích

dữ liệu XML Việc này hoàn toàn được kiểm soát Kiến trúc của trục mô hình đối tượng (AXIOM Architecture) là rất đơn giản bao gồm

- Giao diện lập trình ứng dụng cho AXIOM gọi tắt là AXIOM API AXIOM API cung cấp các thư viện cho người dùng

- Bộ xây dựng (Builder): xây dựng mô hình đối tượng XML dựa trên kỹ thuật phân tích cú pháp của StAX Mô hình đối tượng này cung cấp các sự kiện được tạo bởi từ việc phân tích cú pháp dữ liệu XML Ngoài ra bộ xây dựng này đóng vai trò như một bộ nhớ đệm trong kiến trúc của AXIOM

- XML Stream: dữ liệu XML này được lưu ở dạng nhị phân

3.3 Mô đun xử lý thông điệp SOAP

Nhận và gửi thông điệp SOAP có thể coi là hai trong số những công việc chủ yếu của máy xử lý SOAP Trong kiến trúc Axis2 cung cấp hai đường ống để thực hiện hai hành động cơ bản là nhận và gửi thông điệp SOAP Hai đường ống này có tên là InPipe và OutPipe Các mẫu tin nhắn trao đổi phức tạp ký hiệu MEPs, nó được xây dựng bởi kết nối hai loại ống InPipe và OutPipe Ngoài ra còn hai đường ống khác có mục đích hỗ trợ cho các thông điệp gửi đến và gửi đi bị lỗi [1]

Hình 3-2 Mô hình xử lý thông điệp SOAP [2].

Khả năng mở rộng của mô hình xử lý SOAP được cung cấp thông qua cơ chế

xử lý (handler) Khi một thông điệp đang được xử lý, thì các điều khiển này đã được đăng ký để sẽ thực hiện Các điều khiển này được đăng ký ở mức độ toàn cục, dịch vụ, hoặc trong một phạm vi hoạt động giới hạn của máy chủ Axis2 Cuối cùng Axis2 kết nối các điều khiển của các phạm vi trên thành một chuỗi điều khiển Các điều khiển có thể hoạt động như một máy đánh chặn, nghĩa là chúng xử lý một phần thông điệp và sau đó cung cấp các tiện ích dịch vụ (add on services) cho hệ thống khác Mô tả các bước truyền thông điệp trong mô hình xử lý thông điệp SOAP ở hình 3-2

- Khi một thông điệp được gửi đến thông qua Client API, ống OutPipe trên vùng người dùng được kích hoạt Ống OutPipe sẽ gọi các xử lý (handlers)

- Bộ giao vận gửi thông điệp (Transport sender) trên vùng người dùng sẽ gửi thông điệp SOAP tới ống InPipe trên vùng dịch vụ.Thông điệp SOAP này cuối cùng được bộ giao vận gửi thông điệp(Transport sender) trên vùng dịch vụ chuyển tới cuối điểm mục tiêu( endpoint) trên vùng dịch vụ

- Thông điệp SOAP này sau đó được nhận bởi bộ giao vận nhận (Transport reviever) của vùng người dùng ở điểm mục tiêu (endpoint) Thông điệp SOAP tiếp tục được chuyển vào ống InPipe ở vùng người dùng Trong ống InPipe này bao gồm các thao các xử lý( handlers) và kết thúc việc nhận thông điệp SOAP Đồng thời kết thúc quá trình gửi và nhận thông điệp phản hồi SOAP cho Client API

Quá trình trao đổi thông điệp ở trên xảy ra với mỗi thông điệp tại một thời điểm và với mọi thông điệp Sau khi xử lý xong một thông điệp, Axis2 có thể quyết định tạo ra một thông điệp SOAP khác Axis2 luôn luôn xem các thông điệp SOAP

ở dạng xử lý đơn Sự quản lý và kết nối các thông điệp được thực hiện ở lớp trên của khung (framework) Hai ống InPipe và OutPipe không có sự phân biệt khác nhau giữa vùng máy chủ và vùng người dùng

3.3.1 Xử lý trong Axis2 (Handler)

Trong hệ thống truyền thông điệp, các máy bay đánh chặn có ý nghĩa thực tế trong ngữ cảnh truyền thông điệp, máy bay đánh chặn có nhiệm vụ chặn dòng chảy của các thông điệp và thực hiện chen ngang các nhiệm vụ mới được phân công Trong thực tế, một máy bay đánh chặn là một đơn vị thực hiện nhỏ nhất trong hệ thống truyền thông điệp Vì vậy Axis2 cũng sử dụng khái niệm xử lý hay bộ xử lý (handlers) đóng vai trò là một máy bay đánh chặn.Việc Axis2 xây dựng cơ chế xử

lý (handlers) làm tăng khả năng mở rộng mềm dẻo trong mô hình xử lý thông điệp SOAP Ngoài việc bộ xử lý đóng vai trò là máy bay đánh chặn, thì nó còn cung cấp thêm các tiện ích dịch vụ (Add on services) cho nhiệm vụ hay hệ thống khác [3]

Hình 3-3 Cấu trúc thông điệp mở rộng với một vài tiêu đề [3].

Xử lý trong Axis2 là không trạng thái, nghĩa là Axis2 không giữ các trạng thái đã qua thực hiện của chúng trong bộ nhớ Cấu trúc thông điệp SOAP một xử lý thường tiếp xúc với tiêu đề của thông điệp SOAP, có thể đọc tiêu đề (header), thêm tiêu đề (add a header) hoặc loại bỏ tiêu đề (remove header) như ở hình 3-3 Ngoài

ra, xử lý đó có thể tiếp xúc với thân của thông điệp SOAP giống như tiếp xúc với tiêu đề Trong suốt thời gian xử lý (handlers) tiếp xúc với tiêu đề hoặc thân của thông điệp SOAP, nếu quá trình không thực thi đúng do các thông điệp có thể bị lỗi Khi đó chúng ta nên đưa vào một ngoại lệ và bộ phận lái tiếp theo trong chuỗi của Axis2 sẽ có những hành động cần thiết để giải quyết tình huống này

Bất kỳ một xử lý trong Axis2 có thể dừng thực thi thông điệp, nghĩa là xử lý

có thể kết thúc luồng thông điệp nếu nó không tiếp tục Vì vậy chúng ta có thể xây dựng ra các thông điệp có chất lượng tin cậy, hoặc một ngữ cảnh tin cậy bằng cách tạm dừng dòng chạy thông điệp dựa trên một số tiền điều kiện hoặc hậu điều kiện Viết một xử lý trong Axis2 rất đơn giản Nếu bạn muốn viết một xử lý bạn có thể kế thừa lớp AbstractHandler hoặc viết một Interface Handler Một xử lý đơn giản kế thừa AbstractHandler như ở ví dụ 3.1

Ví dụ 3.1: Đoạn mã mô tả xử lý trong Axis2

public class SimpleHandler extends AbstractHandler

//Write the processing logic here // DO something

đã đã sai với thông điệp do đó thông điệp không được phép đi tiếp

3.3.2 Giai đoạn trong Axis2

Khái niệm giai đoạn (phase) được giới thiệu trong Axis2, giai đoạn là nơi đặt các xử lý (handlers) trong một chuỗi dây chuyền của các thực hiện Giai đoạn có nhiệm vụ hỗ trợ việc thứ tự động của các xử lý Có một số định nghĩa về giai đoạn trong Axis2:

- Giai đoạn có thể coi là một tập hợp lôgic của các xử lý (handlers)

- Giai đoạn có thể coi là một thời gian cụ thể trong việc thực hiện các xử lý (handlers)

- Giao đoạn có thể coi là một thùng nơi đó để đặt xử lý

- Có thể xem xét giai đoạn như một xử lý (handlers)

Hình 3-4 Các giai đoạn của luồng xử lý trong kiến trúc Axis2 [5].

Trong kiến trúc Axis2 có một tập các giai đoạn được xác định trước Chúng được lưu trong tệp cấu hình axis2.xml Có hai loại giai đoạn là dòng chảy vào (InFlow) và dòng chảy ra (OutFlow) Trong đó dòng chảy vào (InFlow) gồm tập các