Xây dựng ứng dụng tự động tổng hợp các web service

Điều này vẫn còn là một thách thức vô cùng khó khăn trong việc ánh xạ yêu cầu của người dùng thành một tập các service có tương quan với nhau mà output của service này có thể thỏa mãn yê

BÙI DŨNG ANH TUẤN

XÂY DỰNG ỨNG DỤNG TỰ ĐỘNG TỔNG HỢP CÁC WEB SERVICE

Chuyên ngành: Khoa học Máy tính

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 09 năm 2009

Trang i

LỜI CAM ĐOAN

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở trường này hoặc trường khác

Ngày 02 tháng 07 năm 2009

Bùi Dũng Anh Tuấn

Tôi cũng xin cảm ơn gia đình đã động viên và tạo mọi điều kiện tốt nhất để tôi có thể tiếp tục theo đuổi việc học tập nghiên cứu Tôi trân trọng dành tặng thành quả của luận văn này cho em trai, Cha Mẹ Nhờ công lao dưỡng dục của Người mà chúng con mới có được thành quả như ngày hôm nay Con xin hứa sẽ tiếp tục cố gắng phấn đấu để vươn cao hơn nữa

Với sự phát triển vượt bậc của Web service, sự quan trọng của quá trình tổng hợp các Web service sẵn có thành một service phức tạp hơn để đạt được các giải pháp mới và hữu dụng hơn đang ngày càng gia tăng Qúa trình tổng hợp các service để đạt được một chức năng mới rất cần thiết cho các hoạt động thương mại, các nghiên cứu khoa học và các loại ứng dụng phân bố khác Đặc biệt đối với vấn đề tự động tổng hợp, hệ thống cần phải định nghĩa các luồng điều khiển và các luồng dữ liệu để hỗ trợ quá trình tổng hợp các service riêng lẻ Điều này vẫn còn là một thách thức vô cùng khó khăn trong việc ánh xạ yêu cầu của người dùng thành một tập các service có tương quan với nhau mà output của service này có thể thỏa mãn yêu cầu input của service khác và tổng hợp tất cả các service này lại có thể thỏa mãn yêu cầu của người dùng

Luận văn này đề xuất một bộ lập kế hoạch dựa trên các phần mềm mã nguồn mở OWLS-Xplan và JGraphpad để tự động tổng hợp các service cơ bản được đặc tả bằng ngôn ngữ OWL-S – một ngôn ngữ ontology dựa trên kỹ thuật Web ngữ nghĩa Trong trường hợp một mục tiêu có thể được thỏa mãn bởi nhiều hơn một service, giải thuật backward-chaining áp dụng heuristic là lựa chọn service có số lượng input nhỏ nhất hoặc lựa chọn service có thông số tiền điều kiện dễ thỏa mãn nhất Giải thuật tự động thực thi

sẽ gọi bản kế hoạch được tạo ra bởi bộ lập kế hoạch và xác định các dữ liệu cần thiết cho việc gọi thực thi nhờ sử dụng các câu truy vấn thích hợp

With the growing number of Web services, importance of composing existing Web services into more complex services in order to achieve new and more useful solutions is increasing Composing existing services to obtain new functionality is essential for business, scientific and other types of distributed applications Especially in automatic composition, the system needs to define control and data-flow to guide the assembling individual services It is still a very challenging due to difficulty of mapping user needs to

a collection of correlated services where their interim outputs can satisfy each other input requirements and the final deliverable meets the user demands

This thesis proposes a planner based on OWLS-Xplan and JGraphpad open sources that automatically composes atomic/basic services described in OWL-S, which is an ontology language based on the Semantic Web technology In cases where a goal can be satisfied by more than one service, the backward chaining applying heuristics such as selecting the service with the least number of inputs, or selecting services that have preconditions that are known to be easily satisfiable The automatic invocation algorithm takes the plan generated by the planner and determines data required for invocation using suitable queries

Trang v

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN .ii

TÓM TẮT LUẬN VĂN iii

ABSTRACT iv

MỤC LỤC v

DANH MỤC HÌNH x

CHƯƠNG 1: TỔNG QUAN VỀ ĐỀ TÀI 1

1.1 Giới thiệu chung về đề tài 1

1.2 Tầm quan trọng và khả năng ứng dụng thực tế của đề tài 3

1.3 Mục tiêu và giới hạn của đề tài 5

1.3.1 Mục tiêu của đề tài 5

1.3.2 Giới hạn của đề tài 6

1.4 Phương pháp nghiên cứu và đánh giá kết quả 6

1.4.1 Phương pháp nghiên cứu 6

1.4.2 Đánh giá kết quả 7

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT CỦA ĐỀ TÀI 8

2.1 World Wide Web 8

2.2 Service Oriented Architecture (SOA) 8

2.3 Web service 9

2.3.1 Tổng quan về Web service 9

2.3.2 Kiến trúc của Web service 10

2.3.3 Ưu điểm của Web service 11

2.4 Web ngữ nghĩa 11

2.4.1 RDF 12

2.4.2 RDF schema 13

2.4.3 OWL 13

2.4.4 OWL-S 14

Trang vi

2.5 Workflow 15

2.6 Tổng hợp workflow 16

2.7 Protégé 21

2.7.1 Tổng quan về Protégé 21

2.7.2 Phân loại Protégé 21

2.7.3 Các đặc trưng của Protégé-OWL 23

2.8 Jena 23

2.8.1 Tổng quan về Jena 23

2.8.2 Các đặc trưng của Jena 24

2.8.3 Kiến trúc của Jena 24

2.9 Jess 26

2.9.1 Tổng quan về Jess 26

2.9.2 Các đặc trưng của Jess 27

2.10 OWLS-API 27

2.10.1 Tổng quan về OWLS-API 27

2.10.2 Các đặc trưng của OWLS-API 27

2.11 OWLS-Xplan 28

2.11.1 Tổng quan về OWLS-Xplan 28

2.11.2 Các đặc trưng của OWLS-Xplan 30

2.12 JGraph 30

2.12.1 Tổng quan về JGraph 30

2.12.2 Các đặc trưng của JGraph 31

2.13 JGraphpad 32

2.13.1 Tổng quan về JGraphpad 32

2.13.2 Các đặc trưng của JGraphpad 32

2.13.3 Tiêu chí thiết kế, hiện thực JGraphpad 32

2.14 Nano XML Parser 33

2.14.1 Tổng quan về Nano 33

2.14.2 Các đặc trưng của Nano 34

CHƯƠNG 3: PHÂN TÍCH CÁC GIẢI PHÁP TỔNG HỢP SERVICE 39

Trang vii

3.1 BPEL 39

3.2 Các hướng nghiên cứu khác 42

3.3 Hướng nghiên cứu của tác giả Berardi 46

3.4 Hướng nghiên cứu của tác giả Mithun 48

3.5 Phần mềm mã nguồn mở OWLS-Xplan 49

3.6 Nhận xét về các hướng nghiên cứu 51

3.7 Nhận xét về hướng nghiên cứu của tác giả Mithun 52

3.8 Nhận xét về phần mềm OWLS-Xplan 54

CHƯƠNG 4: YÊU CẦU THIẾT KẾ VÀ KIẾN TRÚC CỦA ỨNG DỤNG 54

4.1 Yêu cầu thiết kế ứng dụng 54

4.2 Kiến trúc của ứng dụng 54

4.3 Các phần mềm hiện thực kiến trúc 57

4.4 Kế hoạch hiện thực ứng dụng 58

4.5 Giải thuật sử dụng trong hiện thực ứng dụng 60

4.5.1 Giải thuật lựa chọn service tốt nhất 60

4.5.2 Giải thuật tổng hợp service 61

CHƯƠNG 5: HIỆN THỰC ỨNG DỤNG 62

5.1 Cải tiến JGraph 62

5.1.1 JGraph.java trong gói org.jgraph 63

5.1.2 GraphUI.java trong gói org.jgraph.plaf 68

5.1.3 BasicGraphUI.java trong gói org.jgraph.plaf.basic 69

5.2 Cải tiến JGraphpad 70

5.2.1 JgraphpadAboutDialog.java trong gói com.jgraph.pad.dialog 72

5.2.2 JgraphpadPane.java trong gói com.jgraph.pad.factory 74

5.2.3 EditorGraph.java trong gói planner 74

5.3 Hiện thực mới Editor 75

5.3.1 Mục tiêu 75

5.3.2 Cách hiện thực 75

5.3.3 Các phần hiện thực quan trọng 77

Trang viii

5.3.3.1 Lấy các thông tin trạng thái từ file ontology 77

5.3.3.2 Tạo ra initial file 79

5.3.3.3 Tạo ra goal file 80

5.4 Hiện thực mới Planner 80

5.4.1 Mục tiêu 80

5.4.2 Cách hiện thực 81

5.4.3 Các phần hiện thực quan trọng 83

5.4.3.1 Kiểm tra initial file và goal file 83

5.4.3.2 Tạo ra domain file và problem descrition file 84

5.4.3.3 Tạo các đối số cần thiết cho việc khởi tạo bản kế hoạch 85

5.4.3.4 Tạo ra kế hoạch tổng hợp các service 86

CHƯƠNG 6: THỰC NGHIỆM 89

6.1 Mục tiêu của thực nghiệm 89

6.2 Thiết lập môi trường thực nghiệm 89

6.3 Tiến hành thực nghiệm 90

6.3.1 Thí nghiệm 1 90

6.3.2 Thí nghiệm 2 91

6.3.3 Thí nghiệm 3 92

6.3.4 Thí nghiệm 4 93

6.4 Đánh giá 95

6.4.1 Đánh giá định tính 95

6.4.2 Đánh giá định lượng 96

6.5 Kết luận 96

CHƯƠNG 7: KẾT LUẬN 97

7.1 Tổng kết 97

7.2 Những đóng góp của đề tài 97

7.3 Hướng phát triển 98

TÀI LIỆU THAM KHẢO 100

Trang ix

PHỤ LỤC 1 103

PHỤ LỤC 2 104

PHỤ LỤC 3 109

PHỤ LỤC 4 115

Trang x

DANH MỤC HÌNH

Hình 1.1 Web service với các input đầu vào và các output đầu ra 1

Hình 1.2 Mô hình tương tác giữa người dùng và hệ thống 3

Hình 1.3 Hệ thống không hỗ trợ tổng hợp service không chấp nhận yêu cầu của người dùng 4

Hình 1.4 Hệ thống hỗ trợ tổng hợp service chấp nhận yêu cầu người dùng 5

Hình 2.1 Kiến trúc SOA 9

Hình 2.2 Các kỹ thuật được dùng trong Web service 10

Hình 2.3 Kiến trúc Web service 11

Hình 2.4 Minh họa mô hình bộ ba của RDF 12

Hình 2.5 Minh họa RDFS 13

Hình 2.6 Ví dụ về cú pháp OWL 14 Hình 2.7 Mô hình OWL-S 15

Hình 2.8 Minh họa Workflow 16

Hình 2.9 Minh họa mô hình tổng hợp Web service 17

Hình 2.10 Mô hình orchestration 18

Hình 2.11 Mô hình choreography 19

Hình 2.12 Minh họa mô hình tổng hợp quy trình kinh doanh 20

Hình 2.13 Trình soạn thảo Protégé-Frames 22

Hình 2.14 Trình soạn thảo Protégé-OWL 23

Hình 2.15 Kiến trúc của Jena 26

Hình 2.16 Sử dụng OWLS-Xplan để tạo ra bản kế hoạch 30

Hình 2.17 YAWL Editor tối ưu JGraph để hiện thực các công cụ cần thiết 31

Hình 2.18 Giao diện làm việc của JGraphpad 32

Hình 2.19 Quá trình phân tích của NanoXML 34

Hình 3.1 Một quy trình kinh doanh đặc tả bằng BPEL 39

Hình 3.2 Cấu trúc của BPEL 40

Hình 3.3 Minh họa quy trình BPEL đặc tả các Web service 41

Hình 3.4 Mô hình tương tác dự kiến giữa bộ lập kế hoạch và BPEL 42

Hình 3.5 So sánh giữa các phương pháp tổng hợp Web service 46

Hình 3.6 Kiến trúc framework của tác giả Berardi 47

Hình 3.7 Kiến trúc hệ thống của tác giả Mithun 49

Hình 3.8 Kiến trúc của OWLS-Xplan 50

Hình 3.9 Giao diện làm việc của OWLS-Xplan 51

Hình 4.1 Kiến trúc của ứng dụng 56

Hình 4.2 Tương tác giữa người dùng và ứng dụng 57

Hình 4.3 Các phần mềm được sử dụng để hiện thực ứng dụng 58

Hình 4.4 Các bước hiện thực ứng dụng 59

Trang xi

Hình 5.1 Cấu trúc tổ chức của gói JGraph 62

Hình 5.2 Các lớp cần chỉnh sửa của gói Jgraph 63

Hình 5.3 Nhập thông tin về nơi đến và nơi đi của Hospital 64

Hình 5.4 Phải nhập các thông tin về Airport, Patient và Flight parameters trước khi nhập thông tin về Flight 65

Hình 5.5 Thiếu nhập các thông tin bắt buộc trước khi chọn trạng thái End 66

Hình 5.6 Hệ thống hỏi người dùng có muốn nhập thông tin tùy chọn Airport tự động hay không? 66

Hình 5.7 Một workflow hoàn chỉnh đặc tả yêu cầu của người dùng 68

Hình 5.8 Hiển thị tên trong component của workflow như Start, Time, Patient 69

Hình 5.9 Cấu trúc tổ chức của JGraphpad 71

Hình 5.10 Các phần chỉnh sửa của JGraphpad 72

Hình 5.11 Hiển thị About dialog của ứng dụng 73

Hình 5.12 Hình splash khi khởi tạo ứng dụng 75

Hình 5.13 Các trạng thái của đối tượng dựa trên đặc tả của ontology 76

Hình 5.14 Một workflow hợp lệ đặc tả yêu cầu người dùng 76

Hình 5.15 Tạo ra initial file và goal file sau khi vẽ xong workflow đặc tả 77

Hình 5.16 Tạo ra domain file và problem description file thành công 81

Hình 5.17 Tạo ra domain file và problem description file thất bại 81

Hình 5.18 Một phần của bản kế hoạch tổng hợp các service 82

Hình 5.19 Đồ thị tổng hợp các service 83

Hình 5.20 Thanh progress bar chuyển các service từ dạng OWL-S sang XML 85

Hình 5.21 Một phần của file *_plan.xml – đặc tả bản kế hoạch tổng hợp service 87

Hình 5.22 Đồ thị biểu diễn kế hoạch tổng hợp các service 88

CHƯƠNG 1 TỔNG QUAN VỀ ĐỀ TÀI

1.1 Giới thiệu chung về đề tài

Một Web service là một ứng dụng trên Web có khả năng tương tác linh động với các ứng dụng trên Web khác nhờ sử dụng chung các tiêu chuẩn mở như XML, UDDI và

SOAP Web service là nền tảng kỹ thuật cơ bản cho nhiều ứng dụng phổ biến như

e-Commerce, Grid computing, Service Oriented Computing, và Cloud computing Web

service thêm vào một mức chức năng mới bổ sung thêm vào kiến trúc hệ thống Web hiện tại, nhờ vậy Web service cho phép sử dụng và kết hợp các thành phần chức năng được phân bố trong và ngoài tổ chức [25] Hình bên dưới mô tả một Web service tiêu biểu

Hình 1.1 Web service với các input đầu vào và các output đầu ra

Với sự phát triển vượt bậc của Web service trong những năm qua, tầm quan trọng của việc tổng hợp các Web service đang tồn tại thành một service mới phức tạp hơn để đạt được những giải pháp mới và hữu dụng hơn đang ngày càng gia tăng Thật vậy, quá trình tổng hợp các service giúp gia tăng quá trình phát triển ứng dụng, gia tăng tính thừa

kế các service đang có sẵn trong hệ thống, hạn chế công sức xây dựng và phát triển các service phức tạp Nhờ vậy, việc tổng hợp các service đang có sẵn thành một service mới rất cần thiết cho các hoạt động kinh doanh, các nghiên cứu khoa học và đặc biệt đối với các ứng dụng phân bố Tuy nhiên, quá trình tổng hợp các service thường được thực hiện một cách thủ công hoặc bán tự động – điều này vô cùng bất tiện, đặc biệt trong các trường hợp tổng hợp phức tạp Do đó bài toán tự động tổng hợp các Web service vẫn đang là một vấn đề thử thách hiện nay

Đến thời điểm hiện tại, có nhiều hướng nghiên cứu khác nhau cả trong nghiên cứu lẫn trong thương mại nhằm tạo ra các tiêu chuẩn cho mục tiêu tổng hợp Web service Các

phương pháp tổng hợp khá đa dạng, từ cách làm thủ công đến cách làm bán tự động và tự

động hoàn toàn Một trong những giải pháp phổ biến là sử dụng BPEL4WS [3] (Business

Process Execution Language for Web Services) kết nối tĩnh giữa các service lại với nhau

Ngoài ra, các hướng nghiên cứu khác như dự án SWORD [4] hỗ trợ quá trình tổng hợp ở mức bán tự động nhưng không hỗ trợ các tiêu chuẩn phổ biến WSDL và OWL-S; dự án Semantic E-Workflow [4] thực hiện quá trình tổng hợp service một cách thủ công; dự án SHOP2[4] cũng chỉ hỗ trợ quá trình tổng hợp ở mức bán tự động Rõ ràng việc tự động tổng hợp các Web service vẫn còn là một thách thức lớn bởi lẻ trong hệ thống tự động tổng hợp service, hệ thống cần phải định nghĩa các luồng điều khiển và luồng dữ liệu để giúp cho việc tổng hợp các service riêng lẻ được khả thi Điều này vẫn còn là một vấn đề phức tạp do khó khăn trong việc ánh xạ yêu cầu của người dùng với tập các service liên quan, thích hợp mà output của service này có thể thỏa mãn yêu cầu input của service kia

và tổng thể quá trình tổng hợp các service này thỏa mãn đúng yêu cầu của người dùng

Từ các vấn đề trên, ta đưa ra bài toán cần giải quyết như sau: Xây dựng ứng dụng

tự động tổng hợp các Web service Ý nghĩa của bài toán như sau: Đầu tiên, người dùng

sẽ nhập vào thông tin về service họ cần Lúc này, hệ thống sẽ kiểm tra xem với các service sẵn có, hệ thống có thể đáp ứng được yêu cầu về service mà người dùng yêu cầu hay không? Trong trường hợp đơn giản, một service riêng lẻ của hệ thống có thể thỏa mãn yêu cầu của người dùng, service này sẽ được cung cấp cho người dùng Trong trường hợp phức tạp hơn, yêu cầu service của người dùng không thể thỏa mãn bởi bất kỳ một service riêng lẻ bất kỳ nào của hệ thống Tuy nhiên, nếu yêu cầu service của người dùng có thể chia thành nhiều yêu cầu nhỏ hơn và mỗi yêu cầu nhỏ hơn này có thể được làm thỏa mãn bởi một service riêng lẻ nào đó thì yêu cầu của service này vẫn có thể được phục vụ bởi hệ thống Khi đó, một quá trình tổng hợp các service cần thiết trên sẽ được thực hiện và cung cấp kết quả của quá trình này cho người dùng Mô hình tương tác giữa người dùng và hệ thống được minh họa như hình vẽ bên dưới

Hình 1.2 Mô hình tương tác giữa người dùng và hệ thống

1.2 Tầm quan trọng và khả năng ứng dụng vào thực tế của đề tài

Ta minh họa một ví dụ đơn giản bên dưới cho thấy tầm quan trọng của đề tài Giả

sử hệ thống này có 5 Web service riêng lẻ: “Traveltopia service” có chức năng quản lý các chuyến du lịch, “eFlights service” có chức năng quản lý các chuyến bay, “Opodo

service” có chức năng là một đại lý du lịch đến các nước Châu Âu, “eHotel service” có

chức năng quản lý các khách sạn nổi tiếng trên thế giới, “ItalianHotels service” có chức

năng kiểm tra một khách sạn phải ở Ý hay không Yêu cầu của người dùng trong ngữ cảnh này là: Đi du lịch ở Ý và ở khách sạn, đặt chuyến bay ở gần sân bay Rất dễ nhận ra rằng yêu cầu này của người dùng không thể được chấp nhận bởi bất kỳ Web service nào

có sẵn của hệ thống hiện tại, ngữ cảnh này được minh họa như hình bên dưới

Hình 1.3 Hệ thống không hỗ trợ tổng hợp service

không chấp nhận yêu cầu của người dùng

Ta nhận thấy rằng: yêu cầu này rõ ràng rất phức tạp, đòi hỏi nhiều điều kiện cần phải thỏa mãn cùng lúc Nếu hệ thống không hỗ trợ việc tổng hợp các service hay tạo ra các service mới dựa trên các service đang có, yêu cầu này sẽ bị từ chối ngay lập tức, được minh họa như hình ở trên Tuy nhiên, khi phân tích yêu cầu của người dùng, ta nhận thấy rằng với các service hiện tại, hệ thống vẫn có thể đáp ứng yêu cầu của người dùng Thật vậy, yêu cầu của người dùng có thể phân nhỏ thành 2 yêu cầu nhỏ hơn: yêu cầu 1 là đặt chuyến bay đến Ý và yêu cầu 2 là tìm chỗ ở khách sạn ở Ý Yêu cầu 1 có thể giải quyết

bằng cách kết hợp các service như sau {Traveltopia service + eFlights service + Opodo

service: kết hợp service quản lý du lịch + service quản lý các chuyến bay + service quản

lý du lịch tới các nước Châu Âu}, yêu cầu 2 cũng có thể được giải quyết bằng cách kết

hợp các service như sau {eHotel service + ItalianHotels service: kết hợp service quản lý

các khách sạn trên thế giới + service các khách sạn ở Ý} Do cả 2 yêu cầu nhỏ này đều có thể được giải quyết thành công nên yêu cầu của người dùng được chấp nhận nếu hệ thống

hỗ trợ việc tổng hợp các service từ các service đang có Hình bên dưới cho thấy yêu cầu trên của người dùng được thỏa mãn nhờ sự tổng hợp các service bên trong hệ thống

Hình 1.4 Hệ thống hỗ trợ tổng hợp service chấp nhận

yêu cầu phức tạp của người dùng

Ví dụ trên cho ta thấy được tầm quan trọng của việc tổng hợp các service bên trong

hệ thống Tuy nhiên, có một vấn đề đặt ra rằng: ở ví dụ trên chỉ có 5 service và một yêu cầu của người dùng tương đối phức tạp mà để thỏa mãn yêu cầu này, ta phải phân tích, lựa chọn kỹ càng và phối hợp chính xác các service cần thiết Nếu số lượng service lên con số hàng trăm, thậm chí hàng ngàn thì với cách làm thủ công như hiện tại, thời gian để tìm ra đáp án là hệ thống với các service đang tồn tại có thể đáp ứng được yêu cầu của người dùng hay không sẽ vô cùng lớn Khuyết điểm chính của vấn đề này là do quá trình tổng hợp service được thực hiện theo cách thủ công hay bán tự động Do đó yêu cầu tự động tổng hợp service là một bài toán vô cùng cần thiết và phù hợp với thực tiễn Từ thực

tế này, có thể khẳng định rằng bài toán tự động tổng hợp các service sẽ hữu dụng cho các ứng dụng thực tế, cả trong nghiên cứu lẫn trong doanh nghiệp công ty

1.3 Mục tiêu và giới hạn của đề tài

1.3.1 Mục tiêu của đề tài

• Phát triển cách mô tả ngữ nghĩa của Web service để phục vụ cho quá trình tự động tổng hợp các Web service

• Nghiên cứu và xây dựng giải thuật lựa chọn service tốt nhất trong số các service cùng có khả năng thỏa mãn một mục tiêu

• Xây dựng prototype hiện thực các phương pháp trên

• Tối ưu giải thuật tự động tổng hợp các service

• Đánh giá giải thuật tự động tổng hợp này

1.3.2 Giới hạn của đề tài

• Hiện tại, có hai loại Web service được sử dụng nhiều trong thực tế Loại thứ nhất là Web service có trạng thái, được sử dụng nhiều trong các hệ thống tính toán lưới Mỗi hành động của service sẽ tùy thuộc vào trạng thái của service ở thời điểm đó Loại Web service thứ hai là Web service không có trạng thái, được sử dụng nhiều trong thực tiễn và nghiên cứu Các Web service này có các input đầu vào và các output đầu ra xác định Đề tài này sẽ tập trung giải quyết

và xử lý trên các Web service không có trạng thái

• Trong nhiều hệ thống, trạng thái của tài nguyên nói chung và service nói riêng

có hai trạng thái là sẵn sàng và không sẵn sàng Service ở trạng thái sẵn sàng khi không có tài nguyên hay hệ thống nào sử dụng nó, và ngược lại khi có một tài nguyên hoặc hệ thống sử dụng, service ở trạng thái không sẵn sàng Đề tài này làm việc trên các Web service của hệ thống được giả định là luôn ở trạng thái sẵn sàng

1.4 Phương pháp nghiên cứu và đánh giá kết quả

1.4.1 Phương pháp nghiên cứu

Để đạt được mục tiêu của đề tài, cần phải hoàn thiện theo thứ tự các bước sau:

• Tìm hiểu các hướng nghiên cứu hiện tại Từ đó rút ra được các điểm hạn chế cần khắc phục, tối ưu

• Tìm hiểu cách khai báo và đặc tả Web service Qua đó, nhận ra khuyết điểm của cách mô tả ngữ nghĩa của các Web service và đề ra phương thức cải tiến cách mô tả này để phục vụ cho quá trình tổng hợp service

• Tìm hiểu giải thuật tự động tổng hợp các service để nhận ra cách tiếp cận và cách thêm một tiêu chí mới vào trong giải thuật đang có Nhờ vậy có thể xây

dựng được giải thuật mới tự động tổng hợp các service phù hợp với tiêu chí đưa ra

• Tiến hành đánh giá kết quả của giải thuật mới này, và kiểm tra xem có phù hợp với mục tiêu của đề tài hay không

1.4.2 Đánh giá kết quả

Để kiểm tra xem mục tiêu của đề tài có thỏa mãn được hay không, ta phải tiến hành đánh giá kết quả đạt được theo thứ tự các bước sau:

• Thiết lập môi trường thực nghiệm

• Tạo ra các Web service cơ bản của hệ thống, đặc biệt phải xây dựng nhiều service có khả năng cùng thỏa mãn một mục tiêu nào đó nhưng có số lượng input khác nhau hoặc tham số các tiền điều kiện khác nhau

• Tạo ra các yêu cầu của người dùng, trong đó mỗi yêu cầu này chỉ có thể được thỏa mãn bằng cách tổng hợp các service đang tồn tại của hệ thống

• Dựa vào sự tổng hợp các service thỏa mãn các yêu cầu trên của người dùng, tiến hành thống kê xem service được chọn có phải là service tốt nhất trong số các service có cùng khả năng thỏa mãn mục tiêu này hay không

Đánh giá số liệu thống kê cho biết service được chọn có phải là service tốt nhất hay không Nếu xác suất này quá thấp thì chứng tỏ là tiêu chí mới đã không đạt được mục tiêu của đề tài Ngược lại, bằng thực nghiệm, tiêu chí mới đã minh chứng tích hợp thành công vào hệ thống cũ và mục tiêu của đề tài đã đạt được

CHƯƠNG 2

CƠ SỞ LÝ THUYẾT CỦA ĐỀ TÀI

2.1 World Wide Web

World Wide Web hay còn gọi là web – là tập hợp các tài liệu gắn kết với nhau, trong

đó các tài liệu này được viết theo định dạng (X)HTML, được truy xuất thông qua các giao thức chuẩn như HTTP, HTTPS … Và các tài liệu này có thể được nhận dạng thông qua

các URIs

HTTP là giao thức phổ biến cho việc truyền/nhận các tài liệu trên web, HTML là định dạng dùng để biểu diễn các tài liệu và các kết nối của nó trên web Tuy nhiên, người dùng có thể sử dụng các giao thức khác HTTP cho việc trao đổi thông tin trên web Ví dụ

như người dùng có thể sử dụng giao thức FTP, SMTP và SOAP [25] Mặc dù HTML khá

phổ biến và thường được sử dụng cho việc biểu diễn các tài liệu Web, vẫn có rất nhiều các định dạng cho việc biểu diễn dữ liệu trên Web đang ra đời và phát triển Ví dụ như

định dạng PNG, CSS, XML và các định dạng dựa trên XML như XHTML,…

2.2 Service Oriented Architecture (SOA)

SOA là sự phát triển của mô hình tính toán phân bố dựa trên kiến trúc thiết kế yêu cầu/trả lời phục vụ cho các ứng dụng đồng bộ và bất đồng bộ Các luận lý kinh doanh hoặc các hàm chức năng riêng lẻ của ứng dụng được chuẩn hóa và được biễu diễn dưới dạng một service đối với các ứng dụng của người dùng Vấn đề chính đối với các

service này là khả năng kết nối lỏng – interface của service độc lập với phần hiện thực

bên dưới Các nhà phát triển ứng dụng hoặc các nhà tích hợp hệ thống có thể xây dựng các ứng dụng bằng cách kết hợp một hoặc nhiều service mà không cần biết chi tiết hiện thực bên dưới của các service này Ví dụ, một service có thể được hiện thực bằng Net hoặc Java, và ứng dụng có thể được triển khai trên các hệ thống hay hệ điều hành khác nhau

Kiến trúc SOA có các đặc tính nổi bật sau:

• Các service có các interface có khả năng tự đặc tả, độc lập với các tài liệu XML WSDL là kỹ thuật phổ biến dùng để đặc tả các service

• Các service kết nối với các thông điệp chính thức được định nghĩa thông qua XML Schema Sự kết nối giữa người dùng và nhà cung cấp hoặc giữa các service thường được diễn ra trong môi trường không đồng nhất – không hoặc biết rất ít thông tin về nhà cung cấp

• Các service được lưu trữ trong sổ đăng ký registry – đóng vai trò như một danh sách thư mục Các ứng dụng có thể tìm kiếm các service cần thiết trong registry

và gọi service này UDDI là kỹ thuật phổ biến dùng để đặc tả các registry

• Mỗi service có thông số chất lượng service gắn liền với service Một vài các phần tử chất lượng dịch vụ là yêu cầu bảo mật, như sự xác định quyền và sự thẩm định quyền, trao đổi thông điệp tin cậy và các chính sách liên quan đến việc cho phép ai có quyền gọi service này

Hình 2.1 Kiến trúc SOA [27]

SOA có nhiều cách hiện thực Trong những năm gần đây, Web service là một trong những kỹ thuật phổ biến dùng để hiện thực SOA Trong phần kế tiếp, ta sẽ trình bày về Web service

2.3 Web service

2.3.1 Tổng quan về Web service

Web service – được tổ chức W3C định nghĩa là một hệ thống phần mềm được thiết kế để hỗ trợ sự tương tác giữa các máy tình với nhau thông qua môi trường mạng được tương thích Cụ thể hơn, khái niệm Web service đặc tả một tiêu chuẩn chung cho việc tích hợp các ứng dụng Web nhờ sử dụng các tiêu chuẩn mở phổ biến

như XML, SOAP, WSDL và UDDI [25] dựa hoàn toàn trên các giao thức Internet Trong đó, XML dùng để tạo ra các thẻ dữ liệu, SOAP dùng để truyền dữ liệu, WSDL dùng để đặc tả các service đang sẵn sàng và UDDI dùng để liệt kê danh sách các

service đang sẵn sàng Được sử dụng làm phương tiện giao dịch chủ yếu cho việc

tương tác giữa các hệ thống, ứng dụng, Web service cho phép các tổ chức có thể kết nối dữ liệu mà không cần có kiến thức về cơ cấu tổ chức dữ liệu của tổ chức khác

Không giống như mô hình client/server truyền thống, cũng không giống như hệ thống Web server/ trang web, Web service không cung cấp giao diện người dùng

Thay vào đó, Web service chia sẻ các yêu cầu nghiệp vụ, dữ liệu và các quy trình thông qua một giao diện lập trình trên mạng Những người phát triển có thể thêm các Web service khác vào trong giao diện này (như các trang Web hoặc một chương trình thực thi được) để cung cấp chức năng cụ thể này cho các người dùng khác Web service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể kết nối được với nhau mà không tốn thời gian lập trình, bởi lẻ tất cả các kết nối ở dạng

XML, các Web service không bị gắn chặt vào một hệ điều hành nhất định hoặc một

ngôn ngữ lập trình nhất định, Ví dụm Java có thể làm việc chung với Perl, ứng dụng

Windows có thể làm việc chung với các ứng dụng UNIX

Web service không yêu cầu sử dụng các trình duyệt như IE, Firefox, Web

service đôi khi cũng được gọi là application service

Hình 2.2 Các kỹ thuật được dùng trong Web service [27]

2.3.2 Kiến trúc của Web service

Kiến trúc của Web service cần có 3 hành động cơ bản: xuất bản (publish), tìm kiếm (find) và gắn kết (bind) Nhà cung cấp dịch vụ (service provider) sẽ xuất bản dịch vụ cho nhà môi giới dịch vụ (service registry) Người yêu cầu dịch (service

requester) vụ sẽ tìm kiếm các dịch vụ cần thiết thông qua nhà môi giới dịch vụ và gắn

kết với các service tìm thấy thích hợp Ý tưởng trên được minh họa như hình vẽ 2.2

2.3.3 Ưu điểm của Web service

ƒ Gia tăng tính tương thích bằng cách làm giảm đi yêu cầu chia sẻ tri thức, sự hiểu biết

ƒ Cho phép khả năng tích hợp nhanh chóng (just-in-time)

ƒ Làm giảm độ phức tạp bằng cách gói gọn, bao đóng

ƒ Cho phép tương thích dễ dàng với các ứng dụng cũ (legacy)

Hình 2.3 Kiến trúc Web service [27]

2.4 Web ngữ nghĩa

XML (EXtensible Markup Language) là một chuẩn mở dùng để đặc tả dữ liệu của tổ

chức WEC XML được dùng để định nghĩa các phần tử dữ liệu trên trang Web và các tài liệu thương mại XML sử dụng các cấu trúc thẻ tương tự như HTML, tuy nhiên trong khi HTML định nghĩa các phần tử được hiển thị như thế nào thì XML định nghĩa các phần tử

sẽ chứa cái gì Trong khi HTML sữ dụng các thẻ được định nghĩa trước thì XML cho phép các thẻ được định nghĩa bởi người sử dụng [27]

Tuy nhiên, khuyết điểm chính của XML là các tài liệu XML không diễn đạt được ý

nghĩa của dữ liệu trong tài liệu XML Ngôn ngữ schema như XML schema cho phép ràng

buộc các định dạng, nhưng không cho phép ràng buộc các ý nghĩa của dữ liệu XML [8] Việc trao đổi các tài liệu XML trên web chỉ có thể khả thi khi các bên tham gia trong quá trình trao đổi phải đồng ý tuân theo một định dạng cấu trúc đã được thống nhất trước

(thường được biểu diễn bằng XML schema) của dữ liệu và ý nghĩa của các từ khóa và cấu

trúc hình thành nên tài liệu XML Web ngữ nghĩa cho phép việc biểu diễn và trao đổi thông tin theo cách có ngữ nghĩa, tận dụng việc xử lý tự động dựa trên các đặc tả trên web

Sự chú thích trên ngữ nghĩa web biểu diễn các liên kết giữa các thông tin tài nguyên trên web và kết nối các thông tin tài nguyên này thành các thuật ngữ hình thức – các cấu

trúc kết nối này được gọi là mô hình ontology, trong đó các mô hình này tạo nên khung

sườn của ngữ nghĩa web Nhờ vậy mà nó cho phép các máy tính có thể hiểu được thông tin thông qua các kết nối giữa các tài nguyên thông tin và các từ khóa trong các mô hình Hơn nữa, các mô hình này làm cho dễ dàng cho việc tương thích giữa các thông tin tài nguyên thông qua các kết nối đến các mô hình giống nhau hoặc giữa các mô hình với nhau

Ngôn ngữ dùng để tạo kết nối giữa các tài nguyên và các tài nguyên được chú thích

ngữ nghĩa với các kết nối tới các mô hình trong web ngữ nghĩa là RDF Có 2 ngôn ngữ

mô hình web ngữ nghĩa được tổ chức W3C đề nghị là RDF schema và OWL (Ontology

Web Language)

2.4.1 RDF (Resource Description Framework)

RDF [10] xây dựng trên mô hình bộ ba chủ thể - vị từ - vật thể (subject –

predicate – object), thường được viết là s-p-o, dưới dạng các mô hình dữ liệu cơ bản

Một vật thể trong bộ ba trên có thể là một chức năng nào đó, và chủ thể của bộ ba trên cũng có vai trò tương tự như vật thể, tạo ra các đồ thị nhãn có hướng Trong khi

đó các tài nguyên tương ứng với các node và các vị từ tương ứng với các cạnh Ngoài

ra, RDF cho phép một dạng reification (một câu lệnh về một câu lệnh nào đó), có

nghĩa là một câu lệnh RDF có thể được sử dụng như là chủ thể trong một bộ ba nào

đó Cuối cùng, RDF có một khái niệm là node trống (bNode), là các node mà không

có tên Hình bên dưới minh họa mô hình bộ ba của RDF

Hình 2.4 Minh họa mô hình bộ ba của RDF

Về nguyên tắc, RDF được xây dựng trên nền tảng XML RDF không phải là mở rộng của XML, nhưng XML có thể được sử dụng để mô tả và trao đổi các câu lệnh RDF theo chuẩn RDF/XML Thực chất, RDF/XML là chuẩn cú pháp cho RDF Ngoài nó ra, còn rất nhiều cú pháp khác cho RDF mà các cú pháp này thích hợp với

sự sử dụng của con người, ví dụ như là cú pháp Turtle [26] – nhưng các cú pháp này

không xử lý phần trao đổi RDF

2.4.2 RDF Schema

RDF Schema [10] (RDFS) có thể được xem như là mở rộng của RDF với các từ

vựng cho việc định nghĩa lớp, quan hệ thứ bậc giữa các lớp, các thuộc tính (mối quan

hệ nhị phân), quan hệ thứ bậc giữa các thuộc tính, và các ràng buộc thuộc tính Các lớp và thuộc tính RDFS có thể được khởi tạo trên RDF Hình dưới đây sẽ cho ta thấy một ví dụ về mô hình RDFS

Hình 2.5 Minh họa RDFS

RDF(S) (tham khảo đến sự kết hợp giữa RDF và RDF Schema) không được so

sánh có ý nghĩa lắm so với các ngôn ngữ mô hình khác, đơn giản bởi vì nó chỉ cho phép sự biểu diễn các khái niệm, sự phân loại các khái niệm, mối quan hệ nhị phân, các miền đơn giản và tầm vực giới hạn của các thuộc tính Sự hạn chế về ngữ nghĩa của RDF(S) là một động cơ chính cho việc phát triển các ngôn ngữ có ngữ nghĩa hơn của web ngữ nghĩa

2.4.3 OWL (Web Ontology Language)

OWL là một tập các ngôn ngữ mark-up được thiết kế để sử dụng cho các ứng

dụng cần xử lý nội dung thông tin thay vì chỉ hiển thị thông tin Các OWL ontology đặc tả các hệ thống có thứ bậc của một miền theo cách có thể phân tích và hiểu bởi các phần mềm Ngoài ra, OWL tạo điều kiện dễ dàng cho việc hiển thị ý nghĩa và ngữ nghĩa hơn XML, RDF và RDF-S [27]

OWL [10] bao gồm 3 loại mẫu cho việc gia tăng tính ngữ nghĩa là: Lite, DL và Full OWL-Lite là ngôn ngữ OWL có cú pháp đơn giản nhất OWL-Lite được sử dụng trong các tình huống mà chỉ cho phép sự phân lớp của một lớp đơn giản và các ràng buộc đơn giản Trong đó, OWL-DL có khả năng biễu diễn ngữ nghĩa tốt hơn

OWL-Lite và dựa trên đặc tả luận lý DL (Description Logic) – đặc tả luận lý là một mãnh có khả năng quyết định của First Order Logic và khả năng tự động suy diễn

hợp lý Do đó nó có thể tự động tự động tính toán sự phân loại của hệ thống thứ bậc

và kiểm tra sự không tương thích của ontology Và OWL-Full là ngôn ngữ OWL có khả năng diễn đạt ngữ nghĩa tốt nhất Tuy nhiên, OWL-Full không thể thực hiện các suy diễn tự động trên các ontology

Hình 2.5 dưới đây minh họa OWL DL sử dụng mô hình được viết dưới dạng cú pháp trừu tượng Chúng ta định nghĩa một lớp Person với thuộc tính hasChild, thuộc

kiểu Person, và lớp Parent, cũng là một Person nhưng mà có con Cuối cùng, chúng

ta định nghĩa John, mà có con là Mary Kết luận mà chúng ta có thể rút trích được từ OWL DL là John là một thực thể của Parent

Hình 2.6 Ví dụ về cú pháp OWL

2.4.4 OWL-S

OWL-S (Ontology Web Language for Services) là tập các cấu trúc của ngôn

ngữ mark-up để đặc tả các thuộc tính và các khả năng của Web service dưới dạng rõ ràng và máy tính có thể OWL-S dựa trên các ontology của các đối tượng và các khái niệm được định nghĩa nhờ sử dụng OWL

Sự phát triển mạnh mẽ của OWL-S cho phép các nhiệm vụ sau:

• Tự động khám phá các Web service: với sự phát triển của Web service,

nhiều Web service có sẵn trên Web, thực thi nhiều công việc khác nhau OWL-S sẽ giúp cho các tác nhân phần mềm có thể khám phá các Web service thỏa mãn một nhu cầu nào đó với các ràng buộc về chất lượng mà

không cần sự can thiệp của con người

• Tự động gọi các Web service: Tổng quát, sẽ cần thiết để viết một chương

trình gọi một Web service sử dụng các đặc tả WSDL của service này OWL-S sẽ cho phép mọt tác nhân phần mềm có thể tự động đọc các đặc tả

của Web service như thông số đầu vào, đầu ra và gọi Web service này

• Tự động tương thích và tổng hợp các Web service: Trên Web, nhiều

service ở trạng thái sẵn sàng, do đó có thể thực thi một công việc phức tạp bao gồm các lời gọi đến các Web service dựa trên các đặc tả mục tiêu ở mức cao OWL-S sẽ giúp cho vấn đề tương thích và tổng hợp theo cách cho

phép sự thực thi tổng hợp các công việc này

OWL-S ontology có 3 phần chính: service profile, process model và service

grounding

• Service profile: được dùng để đặc tả service là gì Thông tin này chủ yếu có

ý nghĩa cho người dùng, bao gồm tên và đặc tả của service, hạn chế về tính

áp dụng và chất lượng của service, thông tin liên lạc và người tạo ra

service

• Process model: được dùng để đặc tả như thế nào khách hàng có thể liên kết

với service Đặc tả này bao gồm tập các đầu vào, đầu ra, tiền điều kiện và

kết quả của quá trình thực thi service

• Service grounding: được dùng để xác định chi tiết các thông tin mà người

dùng cần để liên kết với service như giao thức kết nối, định dạng thông

để bao trùm thế giới kinh doanh hiện hành, trong đó thế giới này là một quy trình được biến đổi từ các nhu cầu của e-commerce và di chuyển đến Web services Trong trường hợp workflow được sử dụng trong khoa học và công trình, khái niệm workflow được rút

ra từ lập trình phân bố sử dụng các hệ thống như Linda, AVS, Khoros và các đoạn script

phức tạp tạo thành một hệ thống lập trình phức tạp thống nhất

Tổng hợp workflow bao gồm các hoạt động yêu cầu kết hợp và liên kết các phần workflow đang tồn tại với các thành phần khác để tạo ra một quy trình mới Định nghĩa này tương tự như tổng hợp service và tổng hợp workflow Tuy nhiên, quá trình tự động tổng hợp các thành phần của ứng dụng là một thử thách, vì sự tổng hợp tự động này khó lấy được chức năng của các thành phần và kiểu dữ liệu được dùng bởi các thành phần Hình bên dưới mô tả một workflow thường gặp trong thực tế

Hình 2.8 Minh họa workflow [27]

2.6 Tổng hợp workflow

Đến thời điểm hiện tại, có 3 hướng nghiên cứu chính tập trung vào chủ đề tổng hợp workflow gồm: tổng hợp Web service, tổng hợp các quy trình kinh doanh và tổng hợp Grid Service

• Tổng hợp Web service

Tổng hợp Web service có thể chia thành 2 phần chính: tổng hợp tĩnh và tổng hợp

động Tổng hợp tĩnh bao gồm orchestration (một dịch vụ điều phối các dịch vụ

khác) và choreography (mỗi dịch vụ mô tả các tương tác với nó) Đối với sự tổng hợp theo mô hình orchestration, nhiều ngôn ngữ cho mô hình này đã phát triển và phổ biến như WS-BPEL và WS-CDL… Trong khi có một vài hướng nghiên cứu tập

trung vào tự động tạo ra các tổng hợp workflow tĩnh, đa số các hướng nghiên cứu tổng hợp Web service hiện giờ dựa vào sự tổng hợp động sử dụng các chú thích ngữ nghĩa

Để cố gắng hoàn thành các yêu cầu của việc tự động tổng hợp Web service, hầu hết các giải thuật chỉ tạo ra một lời giải – đó là một đường dẫn đến mục tiêu mà bỏ qua các lới giải khả thi khác

Hình 2.9 Minh họa mô hình tổng hợp Web service

Tùy thuộc vào từng yêu cầu, sự tổng hợp các Web service sẽ tạo thành các quy trình private hoặc các quy trình public, tương ứng với 2 khái niệm thường sử dụng:

orchestration và choreography

ƒ Orchestration

Trong mô hình orchestration, một Web service trung tâm sẽ đảm nhận vai trò điều khiển các service có liên quan và kết hợp sự thực thi của các tác vụ khác nhau trên các service có liên quan đến tác vụ này Điều này được thực

hiện bằng các yêu cầu của orchestration Các Web service có liên quan sẽ

không biết (hoặc không muốn biết) rằng các service này có liên quan đến một

quá trình tổng hợp mà service này là một phần của workflow này Chỉ có Web service trung tâm của mô hình mới biết được điều này, do đó orchestration tập trung vào các định nghĩa rõ ràng, chính xác trên các tác vụ

và thứ tự gọi các Web service [3] Mô hình orchestration thường được dùng trong các quy trình kinh doanh private và được mô hình như hình bên dưới

Hình 2.10 Mô hình orchestration

ƒ Choreography

Khác với mô hình orchestration, mô hình choreography không dựa vào

một Web service trung tâm và mỗi Web service trong mô hình choreography

sẽ biết chính xác khi nào sẽ thực thi các tác vụ của service này và service này cần phải tương tác với service nào Mô hình này tập trung vào vấn đề trao đổi thông điệp trong các quy trình kinh doanh public Tất cả các phần tử tham gia vào mô hình cần đảm bảo về quy trình kinh doanh, các tác vụ thực thi, thông điệp trao đổi, và sự tính toán thời gian hợp lý cho việc truyền thông điệp [3]

Mô hình choreography được minh họa như hình bên dưới

Hình 2.11 Mô hình choreography

Theo quan điểm tổng hợp các Web service để thực thi một quy trình kinh

doanh, mô hình orchestration có nhiều ưu điểm hơn so với mô hình

choreography Mô hình orchestration là mô hình linh động hơn so với mô

hình choreography với các ưu điểm sau:

ƒ Biết chính xác service nào chịu trách nhiệm thực thi toàn bộ quy trình

ƒ Các service kết hợp chặt chẽ với nhau, mặc dù các service này không quan tâm là nằm trong cùng một quy trình

ƒ Có thể cung cấp cách giải quyết khác khi có một sự cố trong hệ thống xảy ra

• Tổng hợp quy trình kinh doanh

Nhiều giải thuật tổng hợp các quy trình kinh doanh đề nghị sử dụng các ký hiệu hay chú thích hình học khác nhau Trong [16], các quy trình kinh doanh được mô

hình sử dụng Petri-net và được chú thích với domain ontology sử dụng sự tính toán

và sự tổng hợp giống nhau Sự giống nhau có thể được đo lường nhờ sử dụng cú pháp, ngôn ngữ và sự khác biệt [17] Phương pháp này cho là có một kho lưu trữ các quy trình kinh doanh: sự tổng hợp sẽ kết hợp các chuỗi quy trình đang tồn tại thành một công việc đơn nhất

Cũng trong [17], các quy trình kinh doanh của các tổ chức được tự động tạo ra

sử dụng kiến trúc dịch vụ SAP Do đó, các thành phần thông điệp và các domain

ontology được sắp xếp lại cho hợp nhất, mỗi quy trình sẽ được chú thích ngữ nghĩa

và các ánh xạ thích hợp sẽ được tạo ra

Hình 2.12 Minh họa mô hình tổng hợp quy trình kinh doanh

• Tổng hợp Grid service

Hầu hết các dự án nghiên cứu Grid không những cung cấp khả năng chú thích các Grid workflow mà còn tạo ra các tổng hợp workflow bán tự động Ví dụ như

Akogrimo định nghĩa một ngôn ngữ cho việc đặc tả ngữ nghĩa các tài nguyên và

workflow để định nghĩa ra một Grid service phức tạp bằng cách tổng hợp các Grid service đang tồn tại lại với nhau Trình quản lý workflow sẽ biên dịch một quy trình kinh doanh vào trong quá trình tổng hợp các service Ở thời điểm hiện tại, các chú thích ngữ nghĩa không được đính kèm theo và sự tìm kiếm các quy trình kinh doanh chỉ đơn giản dựa trên các keyword đơn giản Trong tương lai, các chú thích ngữ

nghĩa sẽ được đính kèm trong Akogrimo bằng cách sử dụng ngôn ngữ ngữ nghĩa như OWL-S

Môi trường ODESGS của dự án OntoGrid [21] giúp dễ dàng trong việc xử lý

một số lượng lớn các Grid service ngữ nghĩa bằng cách bán tự động tổng hợp các

dịch vụ Nó sử dụng phương pháp giải quyết vấn đề PSM (Problem Solving Method)

và các ontology cho việc đặc tả các Grid service theo cách hình thức và rõ ràng Đặc

tả PSM này bao gồm một profile, một mô hình model và một choreogaphy Ontology đặc tả cho PSM dựa trên UPML (Unified Problem-Solving Method) và cho phép PSM tự động tổng hợp các workflow mới

2.7 Protégé

2.7.1 Tổng quan về Protégé

Protégé [28] là một trình soạn thảo ontology miễn phí, mã nguồn mở và đồng

thời là framework dựa trên tri thức Nó cung cấp cho cộng đồng người dùng một tập hợp các tool để xây dựng các mô hình miền và các ứng dụng dựa trên tri thức với các ontology

Ở bên trong, Protégé hiện thực một tập các kiến trúc và hành vi của mô hình tri

thức, hỗ trợ sự thành, trực quan hóa và thao tác trên các ontology được thể hiện dưới

nhiều định dạng khác nhau Ngoài ra, Protégé có thể được tùy biến để cung cấp các

miền trị thuận tiện cho việc tạo ra các mô hình tri thức và nhập dữ liệu

Protégé dựa trên ngôn ngữ Java, có khả năng mở rộng, và cung cấp một kiến

trúc dạng cắm vào và sử dụng ngay (plug-and-play), điều này giúp cho Protégé linh

động trong việc phát triển các ứng dụng một cách nhanh chóng Không những thế,

Protégé được sự hỗ trợ mạnh mẽ của một cộng đồng các người phát triển và các

chuyên gia học thuật, các thành viên chính phủ và các đoàn thể người sử dụng, dùng

Protégé cho các giải pháp tri thức như trong việc khám chữa bệnh, tổng hợp trí thông

minh…

2.7.2 Phân loại Protégé

Một ontology đặc tả các khái niệm và các mối quan hệ - các yếu tố này rất quan trọng trong một miền xác định, cung cấp một vốn từ vựng cho miền trên cũng như các đặc tả về ngữ nghĩa của các từ khóa được sử dụng trong vốn từ vựng này Phạm vi của ontology trải dài theo nhiều cách phân loại, từ lược đồ cơ sở dữ liệu cho tới các nguyên lý, tiên đề Trong thời gian gần đây, ontology được áp dụng trong nhiều lĩnh vực kinh doanh và trong cộng đồng khoa học dưới dạng chia sẻ, tái sử dụng và xử lý các miền tri thức Và hiện nay ontology trở thành trung tâm của nhiều ứng dụng như các cổng tri thức khoa học, quản lý thông tin và tích hợp hệ thống, thương mại điện tử

và các web service ngữ nghĩa

Kiến trúc Protégé hỗ trợ hai mô hình ontology sau:

• Trình soạn thảo Protégé – Frames

Trình soạn thảo này cho phép người sử dụng xây dựng và phát triển các ontology – trong đó các ontology này dựa trên frame, phù hợp với chuẩn giao

thức mở kết nối OKBC (Open Knowledge Base Connectivity) Trong mô hình

này, một ontology bao gồm một tập các lớp được tổ chức dưới dạng cây phân

cấp để biểu diễn các khái niệm nổi bật của một miền, tập các khe gắn liền với các lớp để đặc tả các thuộc tính và các mối quan hệ, và tập các thể hiện của các lớp này – các minh họa đặc trưng của các khái niệm đang giữ các giá trị của các

thuộc tính Hình bên dưới minh họa trình soạn thảo Protégé-Frames

Hình 2.13 Trình soạn thảo Protégé-Frames

• Trình soạn thảo Protégé – OWL

Trình soạn thảo này cho phép người dùng xây dựng các ontology của web ngữ nghĩa, đặc biệt là OWL ontology Trong đó, các ontolygy này bao gồm các đặc tả các lớp, các thuộc tính và các minh họa của các lớp này Ví dụ như với một ontology, định dạng ngữ nghĩa OWL xác định như thế nào kế thừa các hệ quả luận lý, ví dụ như các sự kiện không hiện hành trong ontology, nhưng lại được tạo ra bởi đặc tính ngữ nghĩa Việc tạo ra này được suy dẫn đến dựa trên một tài liệu đơn nhất hoặc các tài liệu phân bố được kết hợp lại sử dụng cơ chế

của OWL Hình bên dưới minh họa trình soạn thảo Protégé-OWL

Hình 2.14 Trình soạn thảo Protégé-OWL

2.7.3 Các đặc trưng của Protégé-OWL

Trình soạn thảo Protégé-OWL hỗ trợ người dùng các tính năng nổi bật sau:

• Tải và lưu các ontology OWL và ontology RDF

• Chỉnh sửa và trực quan hóa các lớp, các thuộc tính, và các luật SWRL

• Định nghĩa các đặc điểm của lớp luận lý dưới dạng các biểu thức OWL

• Thực thi các reasoner như là các phân loại đặc tả luận lý

• Chỉnh sửa các cá thể OWL đại diện cho các web ngữ nghĩa

Ngoài ra, kiến trúc linh động của Protégé-OWL giúp cho người sử dụng dễ dàng cấu hình và mở rộng công cụ này Protégé-OWL được tích hợp chặt với Jena (được

giới thiệu ở phần 2) và có một tập các hàm Java API phục vụ cho quá trình phát triển các thành phần giao diện tùy theo mục đích của người dùng hoặc phát triển các web service ngữ nghĩa

2.8 Jena

2.8.1 Tổng quan về Jena

Jena [34] là một framework Java dùng để xây dựng các ứng dụng web ngữ

nghĩa Jena cung cấp một môi trường lập trình cho RDF, RDFS và OWL, SPARQL và

bao gồm các engine suy dẫn dựa trên tập luật

Jena là một framework mở, và vẫn đang được phát triển bởi nhóm phát triển

web ngữ nghĩa của HP (http://www.hpl.hp.com/semweb/ )

2.8.2 Các đặc trưng của Jena

Jena bao gồm các đặc trưng nổi bật sau:

• Tập các hàm RDF API

• Hỗ trợ việc đọc và ghi các RDF dưới dạng RDF/XML, NE và N-Triples

• Tập các hàm OWL API

• Hỗ trợ việc lưu trữ trong bộ nhớ và lưu trữ bền vững, liên tục

• Có engine truy vấn SPARQL

2.8.3 Kiến trúc của Jena

Trọng tâm của kiến trúc Jena là đồ thị RDF, một tập các node bộ ba Điều này được thấy rõ ở lớp Graph (xem hình vẽ bên dưới) Lớp này dựa trên cú pháp trừu

tượng RDF, được làm tối giản nhỏ nhất ở mức thiết kế: bấy kỳ ở đâu một hàm chức

năng đều có thể thực hiện ở các lớp khác Điều này cho phép một dãy các hiện thực của lớp này như lưu trữ các bộ ba trong bộ nhớ hoặc lưu trữ các bộ ba một cách bền vững, liên tục

Lớp EnhGraph là điểm mở rộng để xây dựng các hàm API: trong kiến trúc Jena các hàm chức năng được cung cấp bởi lớp EnhGraph được dùng để hiện thực các hàm API của Model1 và các hàm chức năng mới Onology của OWL và RDFS, cải tiến các

hàm API của DAML

Việc xử lý đầu vào và đầu ra được thực hiện thông qua lớp Model, cần thiết cho

các nguyên nhân lịch sử Kiến trúc Jena hỗ trợ truy vấn đường đi một cách nhanh chóng – đi qua tất cả các đường đi trên tất cả các lớp từ RDQL ở góc bên phải trên đỉnh cho đến cơ sở dữ liệu SQL ở đáy, cho phép người dùng truy vấn một cách tối ưu bởi trình truy vấn tối ưu SQL

Mô tả chi tiết của 3 lớp này như sau:

• Lớp Graph: Các bộ ba như là cấu trúc dữ liệu tổng quát

Lớp Graph dựa trên cứu pháp trừu tượng RDF Lớp này giúp cho thuận tiện thực thi các phần sau:

ƒ Lưu trữ các bộ ba, cả trong bộ nhớ và lưu trữ một cách bền vững như file…

ƒ Chỉ được xem các bộ ba có dữ liệu không phải là bộ ba, như là dữ liệu đọc từ hệ thống file phân cấp, hoặc dữ liệu lấy về từ một trang web

ƒ Các bộ ba ảo tương ứng với kết quả của một quá trình suy diễn từ các tập bộ ba khác được xem như là giả thuyết

Hiện thực của lớp Graph cung cấp cho kiến trúc Jena nhiều phương pháp lưu trữ các bộ ba, và các suy dẫn được gắn liền với RDFS, OWL

• Lớp Model: Góc nhìn của người lập trình ứng dụng

Kiến trúc Jena lưu trữ các hàm API của lớp Model như là lớp trừu tượng

chính của lược đồ RDF được sử dụng bởi các người lập trình ứng dụng Lớp này cung cấp một tập các phương thức cho các thao tác trên đồ thị (thông qua

interface Model) và các node trong đồ thị (thông qua interface Resource và các

lớp con của interface này)

Hơn nữa, các hàm API của DAML được cập nhật, cải tiến để tạo thành các hàm API Ontology có thể cải tiến như là các hàm API của DAML hoặc của OWL

• Lớp EnhGraph: Nhiều góc nhìn đồng thời

Cả 2 lớp Model và Ontology nằm ở trên đỉnh của lớp Graph thông qua lớp

trung gian là lớp EnhGraph Lớp này cung cấp một điểm mở rộng trong việc cung cấp các góc nhìn của đồ thị, các góc nhìn của các node trong đồ thị Lớp này tổng

quát các nhu cầu của các hàm API của lớp Model và Ontology, và ý nghĩa hơn

trong việc giúp cho việc thiết kế được chính xác rằng các lớp hiển thị sẽ ở trạng thái phi trạng thái: tất cả các trạng thái quan trọng sẽ nằm ở trong đồ thị (việc lưu

trữ các trạng thái được cho phép bởi các lớp hiển thị) Ngoài ra, lớp EnhGraph

được thiết kế cho phép nhiều góc nhìn của đồ thị và node – được sử dụng một cách đồng thời

Hình 2.15 Kiến trúc Jena

2.9 Jess

2.9.1 Tổng quan về Jess

Jess [35] là một rule engine và ngôn ngữ kịch bản được phát triển vào cuối năm

1990 ở California, Mỹ Jess được viết bằng ngôn ngữ Java, là một công cụ lý tưởng

cho việc quản lý các luật

Sử dụng Jess, người dùng có thể xây dựng một chương trình Java có khả năng

suy luận hợp lý về các tri thức được khai báo bằng các luật Jess khá nhỏ, nhẹ, và là một trong những rule engine nhanh nhất Nhờ sự hỗ trợ mạnh mẽ của ngôn ngữ kịch

bản giúp cho người dùng có thể truy xuất các hàm API một cách dễ dàng Jess cũng bao gồm một môi trường phát triển toàn diện dựa trên nền Eclipse

Jess có thể sử dụng cả trong thương mại lẫn trong nghiên cứu

2.9.2 Các đặc trưng của Jess

• Jess sử dụng giải thuật Rete để xử lý các luật, trong đó Rete là một cơ chế hiệu

quả trong việc giải quyết các vấn đề ánh xạ nhiều-nhiều

• Jess có nhiều đặc điểm duy nhất bao gồm backward-chaining, làm việc với các

truy vấn trong bộ nhớ

• Jess có thể thao tác trực tiếp cũng như suy luận về các đối tượng Java

• Đơn giản hóa các truy vấn: Tìm kiếm các vùng nhớ làm việc của Jess sử dụng các interface JDBC quen thuộc

• Thông báo lỗi rõ ràng hơn, cụ thể hơn

• Thao tác các đối tượng Java nhanh hơn: Làm việc với các đối tượng Java từ Jess

dễ dàng hơn và nhanh hơn 50%

• Nhiều đặc điểm mới của ngôn ngữ luật: Các phần tử điều kiện giống như

“forall” và “accumulate” cho phép người dùng diễn đạt các khái niệm một cách

mạnh hơn nhưng lại dễ dàng hơn

• Làm tương thích với các biểu thức chính quy: Thêm sức mạng của các biểu thức chính quy trong Java vào các luật

• Ngăn chặn các vòng lặp luật: Các vấn đề với vòng lặp luất đã là chuyện của quá

khứ Phiên bản Jess hiện tại cho phép người dùng thêm nhiều khả năng có thể

làm việc với vấn đề này một cách dễ dàng

2.10 OWLS-API

2.10.1 Tổng quan về OWLS-API

OWLS-API [29] cung cấp các hàm chức năng cần thiết để đọc, ghi, phân tích trên

các file OWL-S một cách dễ dàng và hiệu quả

2.10.2 Các đặc trưng của OWLS-API

• Phân tích các file OWL-S

Các hàm OWL-S API cung cấp 4 bộ phân tích khác nhau

ƒ OWLSProfileParser – phân tích các file OWL-S Profile

ƒ OWLSProcessParser – phân tích các file OWL-S Process

ƒ OWLSGroundingParser – phân tích các file OWL-S Grounding

ƒ OWLSServiceParser – phân tích các OWL-S Service

• Ghi các file OWL-S

Các hàm OWL-S API cung cấp 4 trình ghi file khác nhau

ƒ OWLSProfileWriter – ghi các file OWL-S Profile

ƒ OWLSProcessWriter – ghi các file OWL-S Process

ƒ OWLSGroundingWriter – ghi các file OWL-S Grounding

ƒ OWLSServiceWriter – ghi các file OWL-S Service

• OWL-S Builder

OWL-S Builder được dùng để tạo ra các đối tượng trong OWL-S API Các

hàm OWL-S API cung cấp 2 loại builder: OWLS_Object_Builder dùng để tạo ra các đối tượng OWL-S và OWLS_Store_Builder được dùng để tạo ra các kho

hoặc danh sách lưu trữ các đối tượng OWL-S

• Trình xử lý lỗi

Trình xử lý lỗi được dùng để quản lý các lỗi gặp phải trong quá trình phân tích các file OWL-S Một đối tượng của trình xử lý lỗi sẽ hiện thực

OWLSErrorHandler Các hàm chức năng của OWL-S API cung cấp một hiện

thực mặc định của Error Handler, DefaultOWLSErrorHandler – xử lý các lỗi

được tìm thấy Người dùng có thể tối ưu các trình xử lý lỗi này cho phù hợp với nhu cầu của ứng dụng

Các phần mềm lập kế hoạch HTN (Hierarchical task network) như SHOP2 sẽ

vận hành tốt trên các miền mà có tri thức chính xác và chi tiết về ít nhất một hệ thống cấp bậc riêng phần trong đó các mẫu của các hành động thực thi có cấu trúc luôn trong trạng thái sẵn sàng, ví dụ như trong ngữ cảnh lập kế hoạch cứu nguy Ngược lại, trong các miền không phải trường hợp ở trên, ví dụ như không có tập các phương thức

rõ ràng và không có các luật phân rã có thể dẫn tới một kế hoạch thực thi được, phần