Khai phá và kết hợp tối ưu các dịch vụ web trong thiết kế workflows với soa

Tuy nhiên, các công cụ thiết kế này vẫn chưa hỗ trợ được người thiết kế khả năng tối ưu hoá tập các dịch vụ được chọn trong workflow, hay đề nghị một số giải pháp thích hợp cho mỗi bước

NGUYỄN VIẾT HÂN

KHAI PHÁ VÀ KẾT HỢP TỐI ƢU CÁC DỊCH VỤ WEB TRONG THIẾT KẾ

WORKFLOWS VỚI SOA

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

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 9 năm 2011

TRƯỜNG ĐH BÁCH KHOA TP HCM CỘNG HOÀ XÃ HỘI CHỦ NGHIÃ VIỆT NAM

Tp HCM, ngày 30 tháng 9 năm 2011

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ và tên học viên: NGUYỄN VIẾT HÂN Phái: Nam

Ngày, tháng, năm sinh: 04/12/1982 Nơi sinh: THỪA THIÊN HUẾ Chuyên ngành: Khoa học Máy tính MSHV: 00708193

I- TÊN ĐỀ TÀI : KHAI PHÁ VÀ KẾT HỢP TỐI ƯU CÁC DỊCH VỤ WEB TRONG THIẾT KẾ WORKFLOWS VỚI SOA

II- NHIỆM VỤ VÀ NỘI DUNG:

- Xây dựng giải pháp tìm kiếm dịch vụ web tổng hợp

- Xây dựng giải pháp tối ưu hóa sự kết hợp của các dịch vụ web trong một workflow

III- NGÀY GIAO NHIỆM VỤ: 25/01/2010

IV- NGÀY HOÀN THÀNH NHIỆM VỤ: 30/09/2011

LỜI CẢM ƠN

Tôi xin gởi lời cảm ơn chân thành và sâu sắc nhất đến PGS.TS Đặng Trần Khánh, người Thầy đã tận tình hướng dẫn tôi trong suốt quá trình thực hiện luận văn cao học và tạo mọi điều kiện để tôi có thể hoàn thành luận văn này

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 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

Tôi gởi lòng tri ân đến tất cả bạn bè, những người đã động viên, thăm hỏi cũng như đã giúp đỡ thiết thực giúp tôi hoàn tất luận văn này

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

Workflow là một qui trình công việc bao gồm nhiều bước tuần tự nối tiếp nhau Mỗi bước xác định một công việc cụ thể cần phải được thực hiện và đối tượng chịu trách nhiệm thực hiện công việc đó Đối tượng trong workflow có thể là một người hoặc một nhóm người, cũng có thể là những chương trình máy tính

Kiến trúc SOA cho phép xây dựng một hệ thống từ một tập các dịch vụ hoàn toàn độc lập với nhau về bản chất, cách hiện thực, cũng như là cơ chế hoạt động nhưng có khả năng giao tiếp với nhau bằng thông điệp Web Services là một trong những thể hiện phổ biển và thành công nhất của kiến trúc SOA với quan niệm mỗi dịch vụ là một dịch vụ web Kiến trúc Web Services đã mở ra khả năng tự động hoá hoàn toàn các workflow khi các chương trình máy tính ứng với mỗi bước trong workflow được xây dựng thành các dịch vụ web

Một số công cụ thiết kế workflow hiện nay như BPEL, Windows Workflow Foundation có khả năng tích hợp được dịch vụ web trong quá trình thiết kế bằng cách gán một bước trong workflow với một dịch vụ web cụ thể Tuy nhiên, các công cụ thiết kế này vẫn chưa hỗ trợ được người thiết kế khả năng tối ưu hoá tập các dịch vụ được chọn trong workflow, hay đề nghị một số giải pháp thích hợp cho mỗi bước thiết kế với những thông tin về dịch vụ đã có sẵn trong kho dịch vụ của doanh nghiệp Đều này là do các công cụ thiết kế không khai thác được các thông tin về những dịch vụ đã có trong hệ thống và sử dụng chúng trong quá trình thiết kế

Đề tài này hướng đến việc xây dựng một giải pháp hỗ trợ cho giai đoạn thiết

kế Workflows bằng cách khai phá và kết hợp tối ưu các dịch vụ web

ABSTRACT

A workflow consists of a sequence of connected steps Each step represents to

a task that need to be executed by a participant Participant could be person, group

of persons or complex mechanisms

Service Oriented Architecture(SOA) allows to build a system from independent services, these services could be different from the built-technologies, implementation,executation but can communicate each other via messages Web Services is the most well-known implementation of SOA where a web service is a service Web Services opens the ability to have the full workflow run automatically when applications turn into web services

Some of workflow designing tools(BPEL, Windows Workflow Foundation) have ability to work with web service by allow assigning a web service to a workflow step Howerver, these tools lack the ability to optimize the workflow or recommend the best web services that could be suitable for each step It is because these tools don't keep the information about the existed web services and using them in the designing process

This thesic proposes a solution to support the workflow designing process with the ability to discovery and optimize the composition of web services

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 30 tháng 09 năm 2011

Nguyễn Viết Hân

MỤC LỤC

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

ABSTRACT v

LỜI CAM ĐOAN vi

MỤC LỤC vii

DANH MỤC HÌNH x

Chương 1 GIỚI THIỆU ĐỀ TÀI 1

1.1 Lý do thực hiện đề tài 1

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

1.3 Tóm lược những kết quả đạt được 4

1.4 Cấu trúc của luận văn 4

Chương 2 SOA, Web Services và Workflows 6

2.1 Service Oriented Architecture 6

2.1.1 Giới thiệu 6

2.1.2 Các tiêu chí hiện thực kiến trúc SOA 7

2.1.3 Hoạt động của dịch vụ trong SOA 8

2.2 Web Services 9

2.2.1 Giới thiệu 9

2.2.2 Các thành phần cơ bản trong Web Services 9

2.2.3 Quá trình khai phá dịch vụ trong Web Services 12

2.3 Workflows 14

2.3.1 Giới thiệu 14

Chương 3 CƠ SỞ LÝ THUYẾT 18

3.1 Description Logic 18

3.1.1 Giới thiệu 19

3.1.2 Cú pháp của Description Logic 21

3.1.3 Ngữ nghĩa của Description Logic 22

3.1.4 Reasoning trên Concept và Individual 24

3.2 Ontology 26

3.2.1 Các thành phần của Ontology 26

3.2.2 Phân loại Ontology 27

3.2.3 Reasoning trong Ontology 28

3.3 Semantic Web 29

3.3.1 RDF(S) 30

3.3.2 OWL 32

3.4 Semantic Web Services 33

3.4.1 Giới thiệu 33

3.4.2 Kiến trúc Semantic Web Services Discovery 35

3.4.3 Phân loại kiến trúc SWS Discovery 38

3.5 Web Service Annotation Ontology 40

3.5.1 OWL-S 40

3.5.2 WSMO 41

3.5.3 WSDL-S 42

3.5.4 So sánh giữa OWL-S, WSMO và WSDL-S 43

3.6 Các phương pháp tiếp cận trong giải thuật MatchMaking 44

3.6.1 Cách tiếp cận I: Semantic Capabilities Matching 45

3.6.2 Cách tiếp cận II: Multilevel Matching 47

3.6.3 Cách tiếp cận III: DL MatchMaking với Service Profile Ontologies 48

3.6.4 Cách tiếp cận IV: Similarity Measures and Information Retrieve Techniques 48

3.6.5 Cách tiếp cận V: Graph-Based 49

3.6.6 Cách tiếp cận VI: Indirect Graph-Based Matching 51

3.6.7 Cách tiếp cận VII: Indirect-Backward Chaining Matching 52

3.6.8 Tổng kết về cách phương pháp tiếp cận Matchmaking 53

Chương 4 NHỮNG CÔNG TRÌNH LIÊN QUAN 54

4.1 TUB OWL-S Matcher(OWLSM) 54

4.1.1 Giới thiệu 54

4.1.2 Giải thuật Matching 55

4.1.3 Hiện thực 56

4.1.4 Nhận xét 56

4.2 OWLS/UDDI Matchmaker 57

4.2.1 Giới thiệu 57

4.2.2 Giải thuật Matching 57

4.2.3 Hiện thực 58

4.2.4 Nhận xét 62

4.3 OWLS-MX 62

4.3.1 Giới thiệu 62

4.3.2 Giải thuật Matching 63

4.3.3 Hiện thực 63

4.3.4 Nhận xét 64

4.4 OWL-SLR 65

4.4.1 Giới thiệu 65

4.4.2 Giải thuật Matching 66

4.4.3 Xây dựng công thức cho TS và FS 67

4.4.4 Xây dựng công thức cho NFS 69

4.4.5 Hiện thực 69

4.4.6 Nhận xét 70

4.5 Kết luận 70

Chương 5 XÂY DỰNG GIẢI THUẬT 71

5.1 Một số định nghĩa 71

5.2 Các kịch bản chính và yêu cầu đối với công cụ 73

5.2.1 Các kịch bản chính 73

5.2.2 Yêu cầu đối với công cụ 73

5.3 Hệ thống các tiêu chí đánh giá 74

5.3.1 Công thức tính giá trị của các tiêu chí cho dịch vụ tổng hợp 74

5.3.2 Đặc tả các tiêu chí đánh giá bằng ontology 75

5.3.3 Kỹ thuật sắp xếp độ ưu tiên của dịch vụ 80

5.4 Giải thuật ServiceMatchmaking 80

5.4.1 Degree of Match(DoM) 81

5.4.2 Degree of Match và các tiêu chí đánh giá dịch vụ 83

5.4.3 Giải thuật SingleServiceMatchmaking 83

5.4.4 Giải thuật SimpleComposeServiceMatchmaking 85

5.4.5 Giải thuật ComplexComposeServiceMatchMaking 88

5.5 Giải thuật OptimizeWorkflowBuilding 89

Chương 6 HIỆN THỰC 91

6.1 Các đặc điểm chính 91

6.2 Các chức năng 91

6.3 Mô hình tổng quát 91

6.4 Mô hình cơ sở dữ liệu 93

6.5 Giao diện ứng dụng 95

Chương 7 TTHỰC NGHIỆM VÀ ĐÁNH GIÁ 98

7.1 Mục tiêu thực nghiệm 98

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

7.3 Tiến hành thực nghiệm 101

7.3.1 Thực nghiệm tìm kiếm với Single Service 101

7.3.2 Thực nghiệm sắp xếp độ ưu tiên dịch vụ 102

7.4 Nhận xét 104

7.5 Kết luận 104

Chương 8 KẾT LUẬN 105

8.1 Tổng kết 105

8.2 Những đóng góp của đề tài 105

8.3 Hướng phát triển 106

TÀI LIỆU THAM KHẢO 107

DANH MỤC HÌNH

Hình 2.1: Quá trình giao tiếp giữa các đối tượng trong SOA 8

Hình 2.2: Mối quan hệ giữa XML/WSDL/SOAP/UDDI 10

Hình 2.3: cấu trúc của một thông điệp SOAP 11

Hình 2.4: Mô hình khái niệm của các thành phần trong WSDL 2.0 12

Hình 2.5: Chu kỳ hoạt động của dịch vụ web 13

Hình 2.6: Kiến trúc quá trình khai phá dịch vụ 14

Hình 2.7: Các thành phần trong hệ thống workflow 16

Hình 2.7: Các thành phần của hệ thống workflow trong môi trường SOA 17 Hình 3.1: Biểu diễn terminology trong Description Logic 20

Hình 3.2: TBox biểu diễn mối quan hệ gia đình 23

Hình 3.3: ABox với assertion về quan hệ gia đình 24

Hình 3.4: Ontology và Ontology instance 28

Hình 3.5: Phân loại Ontology 28

Hình 3.6: Kiến trúc phân lớp của Semantsic Web 30

Hình 3.7: Biểu biểu một phát biểu RDF 31

Hình 3.8: Biểu diễn một tài liệu RDF 31

Hình 3.9: Biểu diễn một tài liệu RDF(s) 32

Hình 3.10: Vai trò của ngữ nghĩa trong hoạt động của Web Services 35

Hình 3.11: Kiến trúc SWS Discovery tập trung I 38

Hình 3.12: Kiến trúc SWS Discovery tập trung II 39

Hình 3.13: Kiến trúc SWS Discovery dạng P2P 40

Hình 3.14: Mối quan hệ giữa các sub ontologies trong OWL-S 41

Hình 3.15: Mô hình tài liệu WSDL-S 42

Bảng 3.2: Giá trị các cấp độ Match theo output 46

Hình 3.16: Tóm tắt giải thuật trong cách tiếp cận I 47

Hình 3.17: Tóm tắt giải thuật trong cách tiếp cận II 47

Hình 3.18: Ontology trước (a) và sau (b) khi thêm yêu cầu Q 48

Hình 3.19: Tóm tắt giải thuật trong cách tiếp cận IV 49

Hình 3.20: Biểu diễn dịch vụ bằng đồ thị 50

Hình 3.21: Tóm tắt giải thuật trong cách tiếp cận V 50

Bảng 3.3: Ví dụ về các khai báo dịch vụ 52

Hình 3.22: Đồ thị biểu diễn các dịch vụ trong bảng 3.3 52

Hình 4.1: Mô hình kết hợp kết quả Matching 55

Hình 4.2: Vehicle ontology 58

Hình 4.3: Cách xác định mức DoM 58

Hình 4: Kiến trúc UDDI/OWL-S Registry 58

Hình 4.5: Ánh xạ giữa OWL-S Profile và UDDI 60

Hình 4.6: Màn hình tùy chọn của OWLS-MX 64

Hình 5.1: Simple compose service 72

Hình 5.2a: Complex compose service 72

Hình 5.2b: Complex compose service 72

Hình 5.3: Concept Quality 75

Hình 5.4: Concept QoWSProfile 75

Hình 5.5: Attribute hasQuality 75

Hình 5.6: Attribute qualityNane, qualityValue 76

Hình 5.7: Các Concept đặc tả cho các tiêu chí đánh giá 76

Hình 5.8: tài liệu OWL-S trước khi thêm các tiêu chí đánh giá 77

Hình 5.9: tài liệu OWL-S sau khi thêm các tiêu chí đánh giá 80

Hình 5.10: Vehicle Ontology 81

Hình 5.11: giải thuật singleServiceMatchmaking 85

Hình 5.12: Đồ thị cho giải thuật SimpleComposeServiceMatchmaking 86

Hình 5.13: Giải thuật SimpleComposeServiceMatchMaking 88

89

Hình 5.14: Đồ thị cho giải thuật ComplexComposeServiceMatchmaking 89 Hình 5.15: Giải thuật OptimizeWorkflowBuilding 90

Hình 6.1 Các hoạt động chính của ứng dụng 92

Hình 6.2: Chi tiết các hoạt động của query phase 92

Hình 6.3: Mô hình cơ sở dữ liệu 93

Hình 6.4: Màn hình điều chỉnh các tham số cho bộ lọc 95

Hình 6.5: Màn hình điều chỉnh trọng số của các tiêu chí đánh giá 96

Hình 6.6: màn hình điều chỉnh các ràng buộc trên Graph 96

Hình 6.7: Màn hình Query Single Service 97

Hình 7.1: Cấu trúc thư mục của đĩa CD đính kèm 98

Hình 7.2: Màn hình triển khai ứng dụng 99

Hình 7.3: Ontology cho NAICS 100

Hình 7.4: Virtual directory trên IIS 101

Bảng 7.1 : Tập các câu truy vấn dịch vụ 101

Bảng 7.2: Các bộ lọc dành cho thực nghiệm 102

Hình 7.5: Kết quả thực nghiệm cho Single Service 102

Bảng 7.3: Dịch vụ và giá trị các tiêu chí đánh giá 103

Bảng 7.4: Bộ giá trị các tham số của các tiêu chí đánh giá 103

Hình 7.6: Minh họa độ ưu tiên dịch vụ thay đổi theo bảng tham số 104

Chương 1

GIỚI THIỆU ĐỀ TÀI

Chương giới thiệu đề tài sẽ trình bày yêu cầu, mục tiêu và nội dung sơ lược

của đề tài Đồng thời nêu lên những động cơ thúc đẩy việc thực hiện đề tài trong

thực tiễn cũng như trong nghiên cứu

1.1 Lý do thực hiện đề tài

Workflow là một qui trình công việc bao gồm nhiều bước tuần tự nối tiếp

nhau Mỗi bước xác định một công việc cụ thể cần phải được thực hiện và đối tượng

chịu trách nhiệm thực hiện công việc đó Đối tượng trong workflow có thể là một

người hoặc một nhóm người, cũng có thể là những chương trình máy tính

Trong bất kỳ một doanh nghiệp, cơ quan, tổ chức nào cũng đều tồn tại các

workflow ở dạng tường minh hoặc không tường minh Mô hình hoá cơ chế hoạt

động của doanh nghiệp thành các workflow là một trong những giải pháp để giải

quyết bài toán về tăng hiệu suất hoạt động, giảm chi phí Bên cạnh đó, thông qua

mô hình các workflow ta có thể phát hiện ra những bộ phận có chức năng bị trùng

lặp để giải quyết những bài toán về cân bằng tải, tối ưu hoá việc sử dụng nguồn tài

nguyên hiện tại

Khoa học máy tính đã và đang được ứng dụng để tăng khả năng tự động hoá

trong hoạt động của doanh nghiệp Hiện nay, phần lớn các doanh nghiệp đều sử

dụng một hoặc nhiều chương trình máy tính để phục vụ cho nhu cầu của mình Tuy

nhiên, mỗi chương trình máy tính chỉ thực hiện được một chức năng nào đó trong

toàn bộ hoạt động của doanh nghiệp Để có thể thực thi một workflow một cách tự

động, các chương trình máy tính khi được lắp ghép vào một workflow cụ thể phải

có khả năng giao tiếp được với nhau Điều này là rất khó do các chương trình máy tính thường được xây dựng trên những nền tảng kỹ thuật khác nhau, ngôn ngữ lập trình và cấu trúc cũng khác nhau

Kiến trúc SOA cho phép xây dựng một hệ thống bao gồm một tập các dịch vụ hoàn toàn độc lập với nhau về bản chất, cách hiện thực, cũng như là cơ chế hoạt động nhưng có khả năng giao tiếp với nhau bằng thông điệp Web Services là một trong những thể hiện phổ biển và thành công nhất của kiến trúc SOA với quan niệm mỗi dịch vụ là một dịch vụ web Kiến trúc Web Services đã mở ra khả năng tự động hoá các workflow khi các chương trình máy tính được xây dựng thành các dịch vụ web

Một số công cụ thiết kế workflow hiện nay như BPEL, Windows Workflow Foundation có khả năng tích hợp được web service trong quá trình thiết kế qua khả năng gán một bước trong workflow với một dịch vụ web cụ thể Tuy nhiên, các công cụ thiết kế này vẫn chưa hỗ trợ được người thiết kế khả năng tối ưu hoá tập các dịch vụ được chọn trong workflow, hay đề nghị một số giải pháp thích hợp cho mỗi bước thiết kế với những thông tin về dịch vụ đã có sẵn trong kho dịch vụ của doanh nghiệp Đều này là do các công cụ thiết kế không khai thác được các thông tin về những dịch vụ đã có trong hệ thống và sử dụng chúng trong quá trình thiết kế Một số ví dụ minh họa về những ứng dụng trong thực tế được cho như sau:

Ví dụ 1:

Trường đại học A muốn phát triển một chương trình đào tạo quốc tế Để thực hiện điều này, trường cần phải thành lập một văn phòng đào tạo quốc tế và xây dựng các workflow mới để đáp ứng nhu cầu xử lý thông tin và điều hành hoạt động Các bộ phận liên quan trong qui trình hoạt động của các workflow cũng phải được thành lập như: bộ phận lên kế hoạch giảng dạy, bộ phận thu học phí, bộ phận hỗ trợ sinh viên…Tuy nhiên, nếu người thiết kế workflow nắm được thông tin về vai trò, hoạt động và chức năng của các phòng ban hiện tại ở trường, một số bộ phận có thể không cần phải thành lập, do một số bước trong workflow có thể được đảm trách

bởi những phòng ban này Ngoài ra, một số phòng ban có khả năng thực hiện cùng một chức năng, chẵn hạn chức năng hỗ trợ sinh viên có thể được đảm trách bởi văn phòng đào tạo hoặc bởi từng văn phòng khoa, nhưng qui mô về nhân sự và khối lượng công việc ở mỗi nơi là khác nhau Nên nếu biết thêm những thông tin này thì người thiết kế workflow hoàn toàn có khả năng chọn lựa được bộ phận có khả năng thực hiện công việc tốt hơn cho hoạt động của workflow

Ví dụ 2:

Một doanh nghiệp hoạt động trong lĩnh vực bán lẻ muốn triển khai phương thức bán hàng qua mạng Để thực hiện điều này, doanh nghiệp nhận thấy phải xây dựng một chương trình có thể thực hiện những chức năng sau: xây dựng website giới thiệu sản phẩm, thực hiện thanh toán qua mạng, xuất hóa đơn bán hàng, kiểm tra số lượng sản phẩm trong kho, so sánh giá cả giữa các sản phẩm cùng loại với các doanh nghiệp khác Tuy nhiên, một số chức năng như: thanh toán qua mạng, so sánh giá cả, website giới thiệu sản phẩm, hoàn toàn có thể được cung cấp bởi những doanh nghiệp khác Do dó, doanh nghiệp có thể chọn lựa giữa những dịch vụ có sẵn hoặc xây dựng mới để tiết kiệm chi phí

Đề tài này hướng đến việc xây dựng một giải pháp hỗ trợ người thiết kế khả năng tự động tìm kiếm và tối ưu hoá sự kết hợp của các dịch vụ web trong giai đoạn thiết kế workflow với những thông tin về dịch vụ web đã được lưu trữ trong kho dịch vụ của doanh nghiệp Mô hình bài toán được phát biểu như sau:

Đặc tả một qui trình nghiệp vụ (workflow), mỗi bước trong qui trình nghiệp vụ tương ứng với một dịch vụ web đơn hoặc một dịch vụ web tổng hợp, làm sao để chọn lựa được các dịch vụ thích hợp trong kho dịch vụ hiện tại của doanh nghiệp để gắn vào các bước của qui trình nghiệp vụ một cách tốt nhất theo một số tiêu chí cho trước Các tiêu chí để chọn lựa có thể là chi phí khi sử dụng dịch vụ, tốc độ của dịch vụ,độ tin cậy của dịch vụ

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

Mục tiêu của đề tài là xây dựng một giải pháp để hỗ trợ quá trình thiết kế Workflows bằng cách tìm kiếm và tổng hợp các dịch vụ web trong kho dịch vụ của doanh nghiệp cho mỗi bước của workflow và đề xuất sự kết hợp tối ưu giữa các dịch vụ web trong workflow Giải pháp này sẽ được hiện thực bằng một công cụ cụ thể

Trong đề tài này, tác giả giới hạn chỉ xây dựng giải pháp dựa trên nền tảng là kiến trúc Web Services và sử dụng Ontology để đặc tả dịch vụ web

1.3 Tóm lƣợc những kết quả đạt đƣợc

Với những yêu cầu của đề tài, sau thời gian nghiên cứu và hiện thực, tác giả đã xây dựng được một công cụ có khả năng tìm kiếm và tổng hợp các dịch vụ web trong một kho đăng ký dịch vụ và đề xuất các giải pháp kết hợp các dịch vụ vào trong các bước của workflow một cách tối ưu tương ứng với một số tiêu chí cụ thể

1.4 Cấu trúc của luận văn

Các phần còn lại của luận văn này được tổ chức như sau:

Chương 2 trình bày một cách tổng quan các khái niệm về kiến trúc SOA, Web Services và Workflow

Chương 3 giới thiệu cơ sở lý thuyết để xây dựng đề tài, bắt đầu từ Description Logic, là cơ sở để xây dựng Ontology, tác giả lần lược trình bày các khái niệm về Ontology, Semantic Web, Semantic Web Services và các thành phần trong kiến trúc của Semantic Web Servies Discovery Một số Web Service Annotation Ontology phổ biến và các cách tiếp cận của giải thuật Matchmaking trong quá trình khai phá dịch vụ của Semantic Web Services tính đến thời điểm hiện tại cũng sẽ được giới thiệu trong chương này

Chương 4 giới thiệu một số công cụ Matchmaker phổ biến Các công cụ này đều áp dụng kỹ thuật logic-based cho giải thuật matching và thực hiện matchmaking trên các dịch vụ đơn

Chương 5 là nội dung chính của đề tài Trong chương này, tác giả đề xuất cách thức xây dựng hệ thống các tiêu chí đánh giá, cách đặc tả các tiêu chí đánh giá trong ontology, trình bày các công thức thể hiện mỗi quan hệ giữa các tiêu chí đánh giá và giữa các thành phần tham gia trong giải thuật Matchmaking cùng với các cấp độ matching cho giải thuật Bên cạnh đó, tác giả cũng sẽ trình bày các giải thuật matchmaking cho dịch vụ đơn, dịch vụ tổng hợp và giải thuật tối ưu hóa cho workflow

Chương 6 là phần hiện thực công cụ

Chương 7 là phần thực nghiệm đánh giá kết quả

Chương 8 là một số kết luận, đề xuất sau khi xây dựng đề tài

Chương 2

SOA, Web Services và Workflows

Chương này giới thiệu tổng quan về SOA, Web Services, các thành phần và

hoạt động của Web Services và Workflows

2.1 Service Oriented Architecture

2.1.1 Giới thiệu

Khái niệm tính toán phân bố (distributed computing) được giới thiệu vào

những năm 1980s, dẫn đến một giai đoạn phát triển các kiến trúc đối tượng phân bố

(distributed objects architecture) trong suốt những năm 1990s Giai đoạn này đã

xuất hiện một số nền tảng cho kiến trúc phân bố như Java RMI và DCOM, tuy

nhiên chúng vẫn còn khá nhiều hạn chế, RMI chỉ sử dụng được trong môi trường

Java trong khi DCOM bị giới hạn bởi cơ sở hạ tầng của Microsoft Ngoài ra, do các

ứng dụng phân bố thường được phát triển trên những nền tảng khác nhau cho nên

vấn đề giao tiếp giữa chúng là rất khó khăn

Để giải quyết những hạn chế của các kiến trúc phân bố truyền thống trên, vào

đầu những năm 2000s, khái niệm kiến trúc hướng dịch vụ (SOA) được giới thiệu

(hay chính xác hơn là được giới thiệu lại, vì trong thực tế khái niệm về SOA đã

được định nghĩa bởi Sun vào cuối những năm 1990s khi mô tả Jini)

SOA giới thiệu một cách tiếp cận làm thuận tiện hoá quá trình phát triển và kết

hợp các module dịch vụ, các module dịch vụ này có thể dễ dàng được kết hợp với

nhau hay được sử dụng lại để tạo ra các ứng dụng phân bố Theo W3C, một SOA là

một tập bao gồm các thành phần có thể gọi được, và mô tả bên ngoài của chúng có

thể được quảng bá và được tìm thấy Các thành phần này được tổ chức thành các

dịch vụ và có thể giao tiếp với nhau theo một chuẩn qui định trước Dịch vụ là phần

tử cơ bản cung cấp các chức năng cần thiết của ứng dụng trong SOA

2.1.2 Các tiêu chí hiện thực kiến trúc SOA

Để có thể đạt được những thành công lớn hơn so với các kiến trúc tiền bối, một số tiêu chí đã được đặt ra khi phát triển hệ thống theo kiến trúc SOA:

o Tính mềm dẻo (Scalable): các giải pháp trong quá khứ không được thiết kế

để tương thích với tính mềm dẻo của web SOA nên làm việc được với nhiều loại môi trường cài đặt, có thể trong một tổ chức, giữa các đối tác kinh doanh, hay trên toàn thế giới

o Tính nối kết lỏng (Loosely-coupled): SOA là một bước phát triển từ những

hệ thống được nối kết chặt chẽ đến những hệ thống được nối kết lỏng hơn Bên gửi

và bên nhận trong SOA nên độc lập với nhau Tính kết nối chặt chẽ không thích hợp với SOA vì nó làm cho các ứng dụng phân bố trở nên cứng nhắc và dễ bị phá vỡ Một sự thay đổi nhỏ trong một ứng dụng thành viên có thể dẫn đến yêu cầu phải thay đổi để thích nghi trong các ứng dụng thành viên khác

o Khả năng giao tiếp không phụ thuộc (Interoperability): một thành viên

phải có khả năng giao tiếp với các thành viên khác mà không bị phụ thuộc vào hệ thống máy tính đang sử dụng

o Khả năng khai phá (Discovery): một thành viên phải có khả năng giao tiếp

với một thành viên khác mà có thể nó chưa biết trước Thành viên được chọn để giao tiếp có thể được tìm kiếm từ một tập các ứng viên thông qua hoạt động khai phá

o Tính trừu tƣợng (Abstraction): SOA nên trừu tượng hoá kỹ thuật phát triển

bên dưới, cho phép người lập trình có thể tập trung vào công việc xây dựng dịch vụ cho người dùng thay vì thực hiện các công việc kết nối hệ thống

o Tính tiêu chuẩn (Standards): các giao thức giao tiếp phải được chuẩn hoá

để đảm bảo khả năng giao tiếp rộng rãi nhất

2.1.3 Hoạt động của dịch vụ trong SOA

Trong SOA, có ba hoạt động cơ bản liên quan đến một dịch vụ, đó là các hoạt

động khai phá, yêu cầu và đáp ứng Khai phá là quá trình tìm kiếm các dịch vụ có thể cung cấp chức năng đáp ứng được yêu cầu Yêu cầu cung cấp dữ liệu đầu vào cho dịch vụ và Đáp ứng trả về kết quả từ đầu ra của dịch vụ Dễ dàng nhận thấy

trong kiến trúc này có ba nhân tố chính tham gia: người yêu cầu, nhà cung cấp, và nơi đăng ký dịch vụ

Hình 2.1 minh hoạ một quá trình giao tiếp giữa người yêu cầu và nhà cung cấp dịch vụ trong SOA, quá trình này được bắt đầu bằng việc hai đối tượng tương tác trở nên biết nhau (bước 1) Điều này đạt được là do nhà cung cấp dịch vụ đã quảng

bá các thông tin mô tả về dịch vụ (WSD) và ngữ nghĩa(Sem.) tại một nơi đăng ký dịch vụ để người sử dụng có thể tìm thấy Trong bước 2, hai đối tượng tương tác thống nhất với nhau về các thông tin sẽ được trao đổi trong quá trình giao tiếp Một khi thông tin mô tả và ngữ nghĩa đã được chấp nhận và chuyển đến hai bên (bước 3), hai đối tượng có thể giao tiếp được với nhau để tiến hành các hoạt động cần thiết (bước 4)

Hình 2.1: Quá trình giao tiếp giữa các đối tƣợng trong SOA

2.2 Web Services

2.2.1 Giới thiệu

Các dịch vụ web là những ứng dụng được môdun hoá, đóng gói như là những ứng dụng độc lập, và có thể truy xuất được qua mạng Internet Kiến trúc Web Services được biết đến như là một thể hiện phổ biến và thành công nhất của kiến trúc SOA Một dịch vụ web là một bộ phận phần mềm có thể được gọi thông qua web bằng thông điệp XML theo chuẩn SOAP Một dịch vụ web có thể cung cấp một hoặc nhiều tác vụ Các tác vụ này, cùng với định dạng thông điệp input và output, được mô tả bằng ngôn ngữ WSDL Do được xây dựng dựa trên những tiêu chuẩn mở của web, dịch vụ web độc lập với nền tảng xây dựng bên dưới và ngôn ngữ hiện thực

Trong đề tài này, kiến trúc SOA được thể hiện thông qua kiến trúc Web Services, nên một dịch vụ web, chính xác hơn là một tác vụ của nó, được đồng nghĩa với một dịch vụ

Đối với một dịch vụ web, để có thể được sử dụng rộng rãi, nó phải được mô tả

và quảng bá ra bên ngoài WSDL cung cấp một ngôn ngữ mô tả đủ chi tiết để có thể gọi bất kỳ tác vụ nào của dịch vụ Nhà cung cấp dịch vụ mô tả dịch vụ và quảng bá chúng tại một nơi đăng ký dịch vụ gọi là UDDI Điều này cho phép các đối tượng yêu cầu dịch vụ tìm kiếm trong các bản đăng ký (registry) và chọn các dịch vụ thích hợp với yêu cầu của mình UDDI cho phép khả năng tạo ra các bản đăng ký mà có thể truy xuất được qua web Một bản đăng ký chứa nội dung mô tả dịch vụ bằng WSDL và các thông tin kèm theo, chẵn hạn như thông tin về nhà cung cấp dịch vụ, giá sử dụng dịch vụ Khách hàng có thể có thể sử dụng một hoặc nhiều bản đăng ký

để tìm kiếm các dịch vụ mong muốn

2.2.2 Các thành phần cơ bản trong Web Services

XML, SOAP, WSDL và UDDI là những thành phần nòng cốt để triển khai Web Services XML là tiêu chuẩn để biểu diễn thông tin, SOAP xác định tầng vận chuyển để gửi thông điệp giữa nhà cung cấp và sử dụng dịch vụ, WSDL mô tả dịch

vụ và UDDI được sử dụng để đăng ký và tìm kiếm dịch vụ Hình 2.2 mô tả mối quan hệ giữa các thành phần

Hình 2.2: Mối quan hệ giữa XML/WSDL/SOAP/UDDI

XML, một chuẩn nổi bật với khả năng biểu diễn dữ liệu, được chọn là ngôn

ngữ biểu diễn dịch vụ web XML là ngôn ngữ dành cho việc biểu diễn các dữ liệu bán cấu trúc và được giới thiệu như là một giải pháp cho các vấn đề về giao tiếp dữ

liệu XML sử dụng siêu dữ liệu (metadata) để biểu diễn cấu trúc của dữ liệu (DTD

hay XSD)

SOAP là một chuẩn định nghĩa kiểu và định dạng của các thông điệp XML có

thể được trao đổi trong một môi trường phân bố Một trong những mục tiêu chính của SOAP là trở thành giao thức giao tiếp giữa các ứng dụng được phát triển trên các ngôn ngữ, hệ điều hành và nền tảng khác nhau Một thông điệp SOAP được bao bởi thẻ Envelope, thẻ Header chứa các thông tin thêm về thông điệp, thẻ Body chứa nội dung cần trao đổi của thông điệp Hình 2.3 là một ví dụ minh hoạ cấu trúc của một thông điệp SOAP:

<?xml version="1.0">

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

Hình 2.3: cấu trúc của một thông điệp SOAP

WSDL cung cấp một mô hình và định dạng XML để mô tả dịch vụ web, cho

phép khả năng tách biệt giữa thông tin mô tả các chức năng nghiệp vụ ở mức trừu tượng với chi tiết hiện thực bên dưới của dịch vụ Với phiên bản hiện nay (

2.0), WSDL mô tả dịch vụ web ở hai mức: mức trừu tượng (abstract) và mức chi

tiết (concrete).Những thành phần cơ bản của WSDL bao gồm: message, operation,

Interface, binding, endpoint, service Ở mức trừu tượng, dịch vụ được mô hình qua

các message mà nó gửi và nhận, các message này được biểu diễn độc lập với các

kiểu dữ liệu cụ thể của hệ thống, thông thường sử dụng lược đồ XML (XML

Schema) Operation liên kết một mẫu trao đổi thông điệp (message exchange pattern) với một hoặc nhiều message, mẫu trao đổi thông điệp qui định thứ tự và số

lượng các message trong quá trình gửi và nhận Interface nhóm một hoặc nhiều

operation lại với nhau nhưng không qui định phương thức truyền nhận hay một

kiểu dữ liệu cụ thể nào Ở mức chi tiết, binding xác định phương thức truyền nhận

và các kiểu dữ liệu cụ thể của một hoặc nhiều interface Endpoint liên kết một

binding với một địa chỉ mạng (IP address), và cuối cùng, service nhóm các endpoint tương ứng với một interface lại với nhau Hình 2.4 minh hoạ mô hình khái

niệm của WSDL:

Hình 2.4: Mô hình khái niệm của các thành phần trong WSDL 2.0

UDDI là một dịch vụ thư mục (directory service), được sử dụng để quảng bá

và tìm kiếm các dịch vụ web trên mạng UDDI bao gồm 2 thành phần: UDDI data

model sử dụng cho các mô tả nghiệp vụ và cho bản thân dịch vụ và các hàm UDDI API sử dụng cho việc tham khảo và xuất bản dữ liệu của UDDI UDDI data model

được chi tiết hoá qua các lược đồ XML, bao gồm 4 thành phần chính:

o BusinessEntity: thông tin về nhà cung cấp dịch vụ, ví dụ như tên, mô tả, và

thông tin liên hệ

o BusinessService: thông tin về dịch vụ hay một nhóm dịch vụ

o BindingTemplate: thông tin chi tiết về vị trí của dịch vụ và cách thức sử dụng

dịch vụ

o tModel (technical Model): chứa thông tin về các tài liệu WSDL

Trong kiến trúc UDDI, quá trình khai phá dịch vụ được thực hiện bằng tay thông qua trình duyệt, hoặc tự động thông qua UDDI API

2.2.3 Quá trình khai phá dịch vụ trong Web Services

Chu kỳ hoạt động của một dịch vụ web bao gồm các giai đoạn: Advertisement Discovery SelectionComposition  Invocation (Hình 2.5) Trong đó,Discovery là quá trình khai phá dịch vụ, được sử dụng khi một đối tượng muốn sử dụng một dịch vụ để đáp ứng nhu cầu của mình mà không biết thông tin về các nhà cung cấp dịch vụ Khai phá dịch vụ được thực hiện để tìm kiếm các ứng

Service implementation (concrete definition)

Service interface (abstract definition)

Message

Interface Binding Service Endpoint Operation

viên thích hợp, đó là hoạt động xác định vị trí của các dịch vụ thoả mãn các yêu cầu

về chức năng của đối tượng yêu cầu dịch vụ, mục tiêu là tìm được một dịch vụ thích hợp để sử dụng

Hình 2.5: Chu kỳ hoạt động của dịch vụ web

Hình 2.6 mô tả các thành phần trong hoạt động khai phá dịch vụ của Web Services Các thành phần chính cùng với sự tương tác giữa chúng được điễn tả như sau:

Nhà cung cấp dịch vụ (service provider) là một đơn vị cung cấp một số dịch

vụ cho các đơn vị khác thông qua các yêu cầu mà nó nhận được Mỗi hiện thực của

dịch vụ của một nhà cung cấp được gọi là một phiên bản dịch vụ (service instance)

và thường nằm trong hệ thống riêng của nhà cung cấp Các nhà cung cấp sẽ cố gắng quảng bá dịch vụ của mình cho các khách hàng tiềm năng Việc quảng bá này được

thực hiện bằng cách xuất bản hay đăng ký các thông tin quảng bá dịch vụ (service

advertisement) tại một nơi mà những đơn vị khác có thể truy xuất đến được Nơi

này được gọi là nơi đăng ký dịch vụ (service registry) Những đơn vị tìm kiếm để

sử dụng dịch vụ gọi là đối tượng yêu cầu dịch vụ (service requestor), các đối tượng

sẽ đưa ra các yêu cầu dịch vụ (service request) đối với nơi đăng ký Tuỳ thuộc vào

phạm vi của ứng dụng, các đối tượng yêu cầu dịch vụ có thể là các hệ thống của

Web Service Lifecycle

Advertisement Discovery

Selection

Composition

Invocation

doanh nghiệp, người sử dụng, các đối tượng mạng di động hay những hệ thống khác

có thể giao tiếp qua web Nhìn chung, các yêu cầu dịch vụ đều được cấu trúc và mô hình tương tự như các mô tả dịch vụ Cuối cùng, các yêu cầu dịch vụ sẽ được so trùng với các mô tả dịch vụ thông qua sự hỗ trợ của các giải thuật so trùng

(matching algorithm) để đối tượng yêu cầu dịch vụ có thể tìm thấy các dịch vụ thích

hợp với yêu cầu của mình Nếu giải thuật so trùng thành công trong việc tìm ra được một mô tả dịch vụ, nó sẽ cung cấp cho đối tượng yêu cầu dịch vụ các thông tin chi tiết để có thể sử dụng được dịch vụ

Hình 2.6: Kiến trúc quá trình khai phá dịch vụ 2.3 Workflows

2.3.1 Giới thiệu

Workflow thường được sử đụng để kết hợp các trình tự xử lý nghiệp vụ và thông tin hỗ trợ chúng lại với nhau và liên kết với các ứng dụng cục bộ vào trong một cơ sở hạ tầng phân bố uyển chuyển và linh hoạt

Service

Requestor

Service Registry

Service Provider

Matching Engine

Service request

Service advertisement

2: search

1: advertises

3: matches 4: returns services matches

Theo tổ chức Workflow Management Coalition, workflow được định nghĩa là quá trình tự động hóa của các trình tự xử lý nhiệp vụ, toàn bộ hoặc bán phần, mà trong quá trình đó các tài liệu, thông tin hay công việc được chuyển từ đối tượng tham gia này sang đối tượng tham gia khác để xử lý theo một tập các qui luật cho

trước

“the automation of a business process, in whole or part, during which

documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules”

Mặc dù không được phát biểu một cách tường minh như định nghĩa trên, một trong những động cơ thúc đẩy cho việc triển khai Workflows chính là khả năng cung cấp một giải pháp linh hoạt cho việc phát triển, xây dựng các thủ tục xử lý nghiệp vụ với chi phí tái cơ cấu hệ thống nhỏ nhất Workflows thực hiện điều này bằng cách ràng buộc sự phân chia giữa các thành phần:

o Định nghĩa của các hoạt động trong quá trình xử lý nghiệp vụ và các yêu cầu

về dữ liệu của chúng

o Các qui luật điều khiển luồng xử lý giữa các hoạt động trong trình tự xử lý

o Vai trò và trách nhiệm tương ứng với công việc đang được thực thi trong các hoạt động của trình tự xử lý

o Mô hình tổ chức bên dưới để liên kết vai trò và trách nhiệm và đối tượng thực

sự đang thực thi công việc

Về mặt lý thuyết, các thành phần này có thể được thay đổi một cách độc lập mà không ảnh hưởng đến các thành phần khác cũng như là các hoạt động đang được tiến hành trong hệ thống Hình 2.7 trình bày mô hình về một hệ thống workflow theo [6]:

Hình 2.7: Các thành phần trong hệ thống workflow

Trong môi trường SOA, ứng dụng là các dịnh vụ nên hệ thống workflow có thể được điều chỉnh như hình 2.8:

Hình 2.7: Các thành phần của hệ thống workflow trong môi trường SOA

Nhiệm vụ của luận văn chính là việc hỗ trợ tìm kiếm và kết hợp các dịch vụ một cách tối ưu trong giai đoạn thiết kế Workflows

Design

er

Service

Service

Chương 3

CƠ SỞ LÝ THUYẾT

Với mục tiêu đã đặt ra cho đề tài, tác giả tiếp cận theo hướng sử dụng các

thành phần ngữ nghĩa, cụ thể là sử dụng ontology, để đặc tả dịch vụ web và thực

hiện các thao tác xử lý trên những thành phần này Do đó, cơ sở lý thuyết của đề tài

được giới hạn trong lĩnh vực Semantic Web Services (SWS) Chương này mở đầu

bằng việc giới thiệu Description Logic, là nền tảng của hầu hết các ontology phổ

biến Tiếp đến, tác giả sẽ giới thiệu về ontology và ứng dụng của ontology trong

Semantic Web, Semantic Web Services Phần kế tiếp sẽ trình bày các thành phần

trong kiến trúc khai phá dịch vụ của Semantic Web Services và mô hình hoạt động

của chúng Cuối cùng là một số các tiếp cận của giải thuật Matchmaking trong

SWS

3.1 Description Logic

Description Logic(Baader, 2003), tên gọi trước đây là Terminological Logic,

là một họ trong các ngôn ngữ biểu diễn tri thức, xoay quanh các khác niệm như

concept, role(biểu diễn mối quan hệ giữa các concept) và những ràng buộc trên role

Description Logic(DL) có thể được phân biệt dựa vào các tính chất sau:

o Các phần tử cơ bản trong ngôn ngữ là atomic concept, atomic role và

individual(là thể hiện của concept)

o Khả năng biểu diễn của ngôn ngữ được giới hạn trong phạm vi sử dụng những

thành phần cơ bản để xây dựng các concept phức hợp, hoặc từ các concept,

role đã được xây dựng trước đó

o Các tri thức ẩn(implicit) về concept và individual có thể được suy ra bằng kỹ

thuật reasoning

3.1.1 Giới thiệu

DL xuất phát từ logic vị từ (First Order Logic) và được phát triển để biểu diễn tri thức theo dạng cấu trúc mạng với các thành phần chính là node và link Node đại diện cho class hay individual, link đại diện cho các mối quan hệ giữa chúng, trong

DL node có thể xem là tương đương với concept Do được xây dựng dựa trên logic

vị từ nên có thể xem concept là vị từ một ngôi (unary predicate) và role là vị từ hai ngôi (binary predicate)

Xem xét một ví dụ minh họa ở hình 3.1, đây là một mạng biểu diễn tri thức về các khái niệm person, parent, được lấy từ [3] Đường nối giữa Woman và Person chỉ ra rằng một woman là một person Mối quan hệ này được gọi là mối quan hệ

“IS-A” Thông qua mối quan hệ này ta xây dựng được một cấu trúc phân cấp trên tất cả các concept có liên quan Person là concept tổng quát hơn Woman Concept tổng quát hơn gọi là superconcept, concept chi tiết hơn gọi là subconcept Mối quan

hệ “IS-A” cũng cung cấp nền tảng cho việc thừa kế các thuộc tính, nếu một concept

A là subconcept của concept B thì nó sẽ thừa kế tất cả các thuộc tính của concept B Trong ví dụ này, Woman là subconcept của Person nên nếu Person có thuộc tính là age thì Woman cũng có thuộc tính age Một concept đồng thời có thể có nhiều superconcept, Woman có hai superconcept là Person và Female

Từ các atomic concept, các concept mới có thể được tạo ra thông qua các hàm tạo, chẵn hạn như phép giao và hội Trong ví dụ 3.1, Woman được định nghĩa là giao giữa Person và Female Đường gạch nối giữa Parent và Person được gọi là role Role có thể có các ràng buộc về giá trị, số lượng hoặc kiếu đối tượng Trong ví

dụ 3.1, hasChild(1,NIL) là ràng buộc về số lượng với 1 là cận dưới, NIL là cận trên,

phát biểu rằng là cha mẹ thì ít nhất phải có 1 con Role cũng được phép thừa kế từ các concept tổng quát hơn Concept Mother sẽ được thừa kế role hasChild từ concept Parent

Việc biểu diễn cấu trúc của các concept và mối quan hệ giữa chúng còn được

gọi là terminology Thông qua terminology ta có thể thấy dược mối quan hệ tổng

quát hóa và chi tiết hóa giữa các concept có liên quan

Một điều đáng chú ý là giữa những concept có thể có các mối quan hệ ẩn Trong ví dụ 3.1, có thể tìm thấy mối quan hệ ẩn giữa Mother và Woman Do Mother là subconcept của Female và Parent, và Parent là subconcept của Person, trong khi đó, concept Woman là subconcept của Person và Female nên concept Woman là superconcept của Mother Khả năng phát hiện được các mối quan hệ ẩn này là một đặc tính tiêu biểu của hệ cơ sở tri thức, được gọi là reasoning Chi tiết về reasoning sẽ được giới thiệu ở mục 3.3.4

Hình 3.1: Biểu diễn terminology trong Description Logic

ABox và TBox

Trong mỗi hệ cơ sở tri thức đều có một sự phân biệt rõ ràng giữa intensional knowledge và extensional knowledge Intensional knowledge biểu diễn các tri thức tổng quát trong domain trong khi extensional knowledge biểu diễn tri thức cho một vấn đề cụ thể Trong DL, hai khái niệm này được biểu diễn bởi TBox và ABox

Person

Female

Parent Woman

Mother

hasChild(1,NIL)

TBox biểu diễn các intensional knowledge bằng các terminology, và được xây dựng thông qua các phát biểu mô tả các concept tổng quát và thuộc tính Do đó có thể suy diễn được các tri thức ẩn với TBox

ABox biểu diễn các extensional knowledge, thường được sử dụng để giới

thiệu các individual bằng cách đặt tên và thực hiện các xác nhận (assert) cho thuộc tính của individual Một individual trong ABox là một thể hiện(instance) của một

concept trong terminology

3.1.2 Cú pháp của Description Logic

Trong DL, phần tử cơ bản là các atomic concept và các atomic role Các concept và role phức hợp có thể được định nghĩa từ các atomic concept và role.Với ngôn ngữ , một ngôn ngữ cơ bản trong họ DL, cú pháp được biểu diễn như sau:

Với:

 Bottom concept là concept mà không là concept tổng quát hóa của bất kỳ

concept nào(một số ngôn ngữ định nghĩa là nothings)

Có thể thấy rằng trong , toán tử phủ định chỉ được áp dụng với atomic concept ,và chỉ cho phép sử dụng universal concept với lượng từ Một ngôn ngữ khác

trong họ DL là , là ngôn ngữ mở rộng của cho phép sử dụng toàn diện lượng từ và các quan hệ ràng buộc về số lượng Ngôn ngữ này có khả năng biểu diễn gần với DAML+OIL (tiền thân của OWL) Các qui luật được thêm vào như sau:

3.1.3 Ngữ nghĩa của Description Logic

Concept và Role

Cho một diễn dịch  bao gồm một tập khác rỗng Δ(miền diễn dịch) và một hàm diễn dịch ánh xạ mỗi atomic concept A vào tập  Δ và mỗi atomic Role R vào không gian  Δ x Δ Đối với ngôn ngữ , hàm diễn dịch mở rộng cho các mô tả của concept được cho như sau:

Terminological Axiom và Definition

Terminological axiom là các công thức mô tả mối quan hệ giữa hai concept

hay role, có dạng đẳng thức hoặc bao hàm thức:

Một definition là một terminological axiom có dạng đẳng thức, và có vế bên

trái là một atomic concept, thường được sử dụng để đặt tên biểu tượng cho một khái niệm có biểu diễn phức hợp Ví dụ: định nghĩa một concept có biểu diễn phức hợp và đặt tên biểu tượng là Mother Một tập hữu hạn các definition được gọi là terminology hay TBox Trong một terminology, các tên biểu tượng chỉ được định nghĩa một lần duy nhất Một ví dụ minh họa về TBox với concept và role định nghĩa mối quan hệ gia đình được cho ở hình 3.2

Hình 3.2: TBox biểu diễn mối quan hệ gia đình

Assertion

Gọi a, b,c là tên của các individual, ta có hai loại assertion cho individual:

R(b , c) Role assertion

Assertion thứ nhất phát biểu rằng individual a thuộc diễn dịch của C, assertion thứ hai phát biểu rằng c là một bộ lọc trên role R cho b Ví dụ như: Father(Bob) biểu diễn Bob là một Father, hasChild(Bob, Mary) biểu diễn Bob có con là Mary

Hình 3.3: ABox với assertion về quan hệ gia đình

Một tập các hữu hạn các assertion là ABox Gọi a là ánh xạ của tên của individual a trong Δ(a Δ) Diễn dịch  thỏa mãn assertion C(a) nếu a C và thỏa assertion R(b,c) nếu (b,c ) R Một diễn dịch  thỏa mãn ABox  nếu nó thỏa mãn mọi assertion trong  Trong trường hợp này, ta gọi  là một mô hình của

 Một ví dụ về ABox với một số assertion xuất phát từ TBox trong hình 3.2 được cho ở hình 3.3

Một diễn dịch  thỏa một ABox  xuất phát từ một TBox  nếu khi đang là một mô hình của  nó đồng thời cũng là một mô hình của 

3.1.4 Reasoning trên Concept và Individual

Sau khi đã định nghĩa các TBox và ABox, các giải thuật suy luận có thể được

áp dụng trên TBox và ABox để khai phá các tri thức mới trong domain DL hỗ trợ các mẫu suy luận thường xảy ra trong các ứng dụng của các hệ xử lý thông tin về trí tuệ nhân tạo

Reasoning trên Concept

Gọi  là một là một TBox, ta có 4 tác vụ suy luận chính đối với concept:

o Subsumption: một concept C được subsumed bởi D trong  nếu C Dvới mọi mô hìnhcủa

o Satisfiability: một concept C được gọi là satisfiable trong nếu tồn tại một mô hìnhmà trong đó Ckhác rỗng

o Equivalence: hai concept C và D được gọi là equivalent trong nếu C

Dvới mọi mô hìnhcủa

o Disjointness: hai concept C và D được gọi là disjoint trong  nếu C D=

với mọi mô hìnhcủa

Subsumption

Trong các tác vụ trên, subsumption là tác vụ quan trọng nhất cho các giải thuật matching, thông thường được viết là , với D (subsumer) là concept có mức

tổng quát cao hơn so với C (subsumee) Nói một cách khác, subsumption là quá

trình kiểm tra liệu concept thứ nhất có thuộc tập con của concept thứ hai hay không Subsumption cho phép cấu trúc các terminology thành cây phân cấp, với cây phân cấp này, ta có thể thấy được các mối quan hệ cha con giữa các concept trong terminology

Xét TBox đã cho trong hình 3.2, concept Person subsume Woman, cả Woman

và Parent đều subsume Mother, và concept Grandmother được subsumed bởi Mother Concept Man và Woman là disjoint, tương tự Father và Mother cũng disjoint

Reasoning trên Individual

Các tác vụ reasoning trên individual bao gồm:

o Classification(Instance checking): kiểm tra việc một individual từ ABox có

phải luôn là một instance của một concept nhất định hay không

o Consistency checking: kiểm tra tính nhất quán trong ABox, ví dụ nếu trong

một ABox xuất phát từ TBox ở hình 3.2, tồn tại hai assertion Father(ANNA)

và Mother(ANNA) thì có thể xác định là ABox không có tính nhất quán

o Realization: phát hiện concept có mức tổng quát thấp nhất mà individual là

một thể hiện của nó

o Retrieval: tìm kiếm các individual trong hệ cơ sở tri thức là thể hiện của một

concept cho trước

3.2 Ontology

Thuật ngữ Ontology có nguồn gốc từ triết học hàm ý đến bản chất không thay

đổi của sự vật (“the essence of things through the changes”) Tuy nhiên, khi sử

dụng trong khoa học máy tính, một Ontology được định nghĩa là một đặc tả chính thức và tường minh của một khái niệm dùng chung:

An Ontology is a formal, explicit specification of a shared conceptualization

(Studer and colleagues, 1998) Ontology biểu diễn tri thức theo một định dạng mà máy tính có thể hiểu được, giúp nâng cao hiệu quả giao tiếp giữa người và máy tính hoặc giữa các máy tính Sử

dụng Ontology để biểu diễn tri thức thường đi kèm với một miền (domain) cụ thể

Ontology thường được diễn tả bằng các ngôn ngữ logic (description logic, order logic,…)

first-3.2.1 Các thành phần của Ontology

Hiện nay, để định dạng cho Ontology, người ta sử dụng nhiều kiểu định dạng khác nhau, mỗi định dạng sử dụng các thành phần khác nhau để biểu diễn Tuy nhiên, hầu hết chúng đều chia sẻ với nhau một số thành phần chính sau:

o Class(Concept): biểu diễn các khái niệm trong domain Ví dụ, trong phạm vi

về du lịch, các khái niệm là địa điểm (các thành phố, vùng, miền, …), chỗ ở (khách sạn, nhà nghỉ, ), các phương tiện giao thông (máy bay, tàu hoả, xe buýt, …) Class thường cho phép cơ chế thừa kế

o MetaClass: là những class mà thể hiện (instance) của nó là một Class

o Relation: biểu diễn mối quan hệ giữa các khái niệm, được định nghĩa là một

tập con bất kỳ của tập n phần tử, ký hiệu: R ⊂ C1 x C2 x …x Cn Trong đó,

đáng chú ý là mối quan hệ hai ngôi (binary relations) Trong quan hệ hai ngôi, ngôi thứ nhất gọi là domain, ngôi thứ hai gọi là range

o Attribute(Property): biểu diễn thuộc tính của khái niệm, là một quan hệ hai

ngôi Tuy nhiên, nó được phân biệt so với Relation ở chỗ range của nó là một

kiểu dữ liệu (datatype), ví dụ như : string, number, … thay vì là một Class

o Axioms: là những tri thức được mặc nhiên thừa nhận là đúng Chúng được sử

dụng để biểu diễn những tri thức mà không thể được xây dựng một cách tường minh từ những thành phần khác

o Instance: biểu diễn một đối tượng trong Ontology, là một thể hiển của Class

Hình 3.4 minh hoạ một ứng dụng của ontology trong lĩnh vực cung cấp dược phẩm Một số Class chính như là Product, HealthCaeProvider, HelthProgram Hospital, MedicareProvider là các Class thừa kế từ HealthCareProvider sellsProduct là một relation với domain là HealthCareProvider và range là Product Aspirin là một instance của Medicine

3.2.2 Phân loại Ontology

Thông thường, ontology được phân loại dựa trên mức độ tổng quát hay phạm vi

(level of generality) của các khái niệm mà nó biểu diễn Ontology thường được chia

thành ba cấp độ:

o Foundational(upper) ontologies biểu diễn những khái niệm chung nhất,

không phụ thuộc vào một lĩnh vực cụ thể nào, chẵn hạn như các khái niệm về thời gian, không gian Một ví dụ cho loại ontology này là DOLCE

o Generic ontologies chứa những tri thức chung trong một lĩnh vực như toán

học, sinh học hay Web Services Các khái niệm của chúng có thể thừa kế từ một foundational ontology Một ví dụ cho loại ontology này là OWL-S

o Domain ontologies có khả năng sử dụng lại thấp nhất, thường chỉ được sử

dụng trong một lĩnh vực cụ thể