KHAI PHÁ và kết hợp tối ưu các DỊCH vụ WEB NGỮ NGHĨA với SOA

Với giới hạn về thời gian và kinh nghiệm nghiên cứu, nhóm sinh viên quyết định thực hiện đề tài nghiên cứu tìm hiểu về các khái niệm trong quá trình kết hợp các dịch vụ web ngữ nghĩa và

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA CÔNG NGHỆ PHẦN MỀM

KHOÁ LUẬN TỐT NGHIỆP

KHAI PHÁ VÀ KẾT HỢP TỐI ƯU CÁC DỊCH VỤ WEB NGỮ NGHĨA

VỚI SOA

Giảng viên hướng dẫn : PGS TS VŨ THANH NGUYÊN

ThS NGUYỄN ĐĂNG KHOA

Sinh viên thực hiện : CAO THỊ HUYỀN SA

Giảng viên hướng dẫn: PGS TS Vũ Thanh Nguyên

ThS Nguyễn Đăng Khoa

Sinh viên thực hiện: Cao Thị Huyền Sa

Xin cảm ơn các thầy cô trong khoa Công nghệ phần mềm đã cung cấp cho chúng em những kiến thức quý báu để hoàn thành khóa luận

Xin cảm ơn các thành viên lớp CNPM02, đã hỗ trợ nhóm trong thời gian thực hiện khóa luận, giúp đỡ nhóm thực hiện tìm kiếm một số tài liệu và là nguồn ủng

NHẬN XÉT (Của giảng viên hướng dẫn)

NHẬN XÉT (Của giảng viên phản biện)

TÓM TẮT KHÓA LUẬN

Một workflow bao gồm một chuỗi các bước được kết nối Nhấn mạnh là trên mô hình flow, nơi mà mỗi bước tiếp theo bước trước đó mà không có sự chậm trễ hay khoảng cách và kết thúc ngay trước khi bước tiếp theo có thể bắt đầu Nó là một mô tả của một chuỗi các hoạt động, được khai báo là work của một người, một nhóm người, một tổ chức của nhân viên, hoặc một hoặc nhiều cơ chế đơn giản hoặc phức tạp Workflow có thể được xem như là sự trừu tượng của một công việc thực tế

Trong công nghệ phần mềm, một Kiến Trúc Hướng Dịch Vụ (SOA) là một tập hợp các nguyên tắc và phương pháp thiết kế và phát triển phần mềm trong form của các services tương thích Các web services có thể thực hiện một kiến trúc hướng dịch vụ Các web services làm cho các building-blocks chức năng có thể truy cập qua các giao thức Internet tiêu chuẩn độc lập với các nền tảng và với các ngôn ngữ lập trình Các Web Services mở ra khả năng có các workflow đầy

đủ chạy tự động khi các ứng dụng chuyển thành các web services

Các implementors thường xây dựng các SOAs bằng cách sử dụng các chuẩn dịch vụ web (ví dụ, SOAP) đã được sự chấp nhận rộng rãi trong ngành công nghiệp sau khi giới thiệu Version 1.2 từ W3C (World Wide Web Consortium) in 2003 Những chuẩn này (còn gọi là các đặc tả dịch vụ Web) cũng cung cấp khả năng tương tác cao hơn và một số bảo vệ từ việc khóa các phần mềm của nhà cung cấp độc quyền Tuy nhiên, người ta có thể sử dụng bất kỳ công nghệ dựa trên service như Jini, CORBA hoặc REST

Một số công cụ thiết kế workflow (BPEL, Windows Workflow Foundation) có khả năng làm việc với web service bằng cách cho phép chỉ định một web service cho một workflow step Tuy nhiên, những công cụ này thiếu khả năng tối ưu hóa workflow hoặc khả năng đề cử các web services tốt nhất có thể phù hợp cho mỗi bước Đó là bởi vì những công cụ này không giữ các thông tin

về cách web services tồn tại và sử dụng chúng trong quá trình thiết kế

Khóa luận này tìm hiểu một giải pháp để hỗ trợ quá trình thiết kế workflow với khả năng phát hiện và tối ưu hóa các thành phần của các web services

ABSTRACT

A workflow consists of a sequence of concatenated (connected) steps Emphasis is on the flow paradigm, where each step follows the precedent without delay or gap and ends just before the subsequent step may begin It is a depiction

of a sequence of operations, declared as work of a person, a group of persons, an organization of staff, or one or more simple or complex mechanisms Workflow may be seen as any abstraction of real work

In software engineering, a Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form

of interoperable services Web services can implement a service-oriented architecture Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages Web Services opens the ability to have the full workflow run automatically when applications turn into web services

Implementors commonly build SOAs using web services standards (for example, SOAP) that have gained broad industry acceptance after recommendation of Version 1.2 from the W3C (World Wide Web Consortium) in

2003 These standards (also referred to as Web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software One can, however, implement SOA using any service-based technology, such as Jini, CORBA or REST

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 thesis learns a solution to support the workflow designing process with the ability to discovery and optimize the composition of web services

MỞ ĐẦU

Web ngữ nghĩa, hay còn gọi là thế hệ Web 3.0 là một lĩnh vực hoàn toàn mới mẻ, đang cần có những đầu tư nghiên cứu nghiêm túc để có thể thực sự đưa web 3.0 trở thành thực tế và áp dụng rộng rãi, để tận dụng được các ưu điểm lớn của chúng mà web 2.0 đã trở nên già cỗi và khó lòng quản lý

Một trong số những khía cạnh cần được nghiên cứu trong lĩnh vực web ngữ nghĩa là việc sử dụng ontology matching để phối hợp tối ưu các dịch vụ web ngữ nghĩa, phục vụ cho việc tái sử dụng tài nguyên sẵn có trong môi trường web ngữ nghĩa trong việc xây dựng website theo hướng dịch vụ

Với giới hạn về thời gian và kinh nghiệm nghiên cứu, nhóm sinh viên quyết định thực hiện đề tài nghiên cứu tìm hiểu về các khái niệm trong quá trình kết hợp các dịch vụ web ngữ nghĩa và các công cụ hỗ trợ đã có hiện nay Qua đó, xây dựng và phát triển cho riêng mình giải thuật mới trong việc matching và khai phá các dịch vụ web ngữ nghĩa, phục vụ cho quá trình thực hiện tạo nên một công

cụ thực tế nếu phát triển khóa luận về sau

MỤC LỤC

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

1.1 Mục tiêu – giới hạn của đề tài 12

1.1.1 Mục tiêu 12

1.1.2 Giới hạn 12

1.2 Kết quả tóm lược của đề tài 12

1.3 Cấu trúc khóa luận 12

Chương 2: KIẾN THỨC CƠ BẢN 14

2.1 Services Orient Architecture 14

2.1.1 Giới thiệu công nghệ 14

2.1.2 Đặc điểm của SOA 17

2.1.3 Ưu và khuyết điểm của SOA 20

2.2 Web Service 20

2.2.1 Giới thiệu công nghệ 20

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

2.2.4 Ưu và khuyết điểm 30

Chương 3: Ontoglogy – CƠ SỞ LÝ THUYẾT 32

3.1 Description Logic 32

3.1.1 Giới thiệu 32

3.1.2 Cú pháp Description Logic 32

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

3.2 Ontology 35

3.2.1 Ontology là gì 35

3.2.2 Các thành phần của ontology 35

3.2.3 Phân loại Ontology 36

3.2.5 Ví dụ 39

3.3 Semantic Web 40

3.3.1 Giới thiệu Semantic Web 40

3.3.2 RDF(S) 42

3.3.3 OWL(S) 43

3.4 Dịch vụ web ngữ nghĩa (Semantic Web Service) 44

3.4.1 Giới thiệu 44

3.4.2 Kiến trúc Semantic Web Service 46

3.5 Web Service Annotation Ontology 46

3.5.1 OWL-S 46

3.5.2 WSMO 47

3.5.3 WSDL-S 48

3.5.4 SAWSDL 49

3.5.5 So sánh giữa OWL-S, WSMO, WSDL-S, SAWSDL 51

Chương 4: KHAI PHÁ SEMANTIC WEB SERVICE 53

4.1 Kiến trúc (Architecture) 53

4.1.2 Kiến trúc Khai phá Dịch vụ web (Web Service Discovery) 53

4.2 Phương pháp – Giải thuật 59

4.2.1 Định nghĩa Matchmaking 59

4.2.2 Degree of Match (DoM) 60

4.2.3 Các hướng tiếp cận Matchmaking 61

4.3 Các công cụ Matchmaking – Các công trình liên quan 70

4.3.1 OWL-S/UDDI Matchmaker (OWL-S/UDDIM) 70

4.3.2 Hybrid OWL-S Web Service Matchmaker (OWLS-MX) 76

4.3.3 METEOR-S Web Service Discovery Infrastructure (MWSDI) – Lumina 79

4.3.4 TUB OWL-S Matcher (OWLSM) 83

Chương 5: CÁC KHÁI NIỆM TRONG VIỆC XÂY DỰNG GIẢI THUẬT PHỤC VỤ KHAI PHÁ DỊCH VỤ WEB NGỮ NGHĨA 86

5.1 Giới thiệu 86

5.2 Ví dụ: 87

5.3 Các tiêu chí đánh giá dịch vụ 90

5.4 Quá trình lựa chọn dịch vụ 91

Chương 6: KẾT LUẬN 93

6.1 Tổng kết 93

6.2 Những đóng góp của đề tài 94

6.3 Hướng phát triển 94

DANH MỤC TÀI LIỆU THAM KHẢO 95

DANH MỤC CÁC BẢNG, SƠ ĐỒ, HÌNH

Danh mục hình

Hình 2.1 Mô hình trừu tượng Kiến trúc hướng dịch vụ SOA 5

Hình 2.2 Mô hình hoạt động của SOA 6

Hình 2.3 Mô hình hoạt động của Web Service 11

Hình 2.4: Các thành phần của Web service 12

Hình 2.5: Mô hình gửi nhận thông điệp qua SOAP 14

Hình 2.6: Cấu trúc của một SOAP message 15

Hình 2.7: Cấu trúc WSDL 16

Hình 3.1 Phân loại ontology theo chủ đề của sự phân hóa 26

Hình 3.2 Phân loại Ontology dựa trên mức độ tổng quát 28

Hình 3.3 Cấu trúc Semantic web 30

Hình 3.4 Cấu trúc dịch vụ web ngữ nghĩa 34

Hình 3.5 Mô hình OWL-S 35

Hình 3.6 Mô hình WSMO 36

Hình 3.7 Mô hình tài liệu WSDL-S 37

Hình 3.8 Mô hình SAWSDL 38

Hình 3.9 Tập dữ liệu từ thế giới thực 40

Hình 4.1 Kiến trúc khai phá dịch vụ web ngữ nghĩa 41

Hình 4.2 Ví dụ về OWL-S SAO 43

Hình 4.3 Kiến trúc tập trung I 44

Hình 4.4 Kiến trúc tập trung II 45

Hình 4.5 Kiến trúc tập trung 46

Hình 4.6 Cấu trúc của ontology trước (a) và sau (b) khi thêm yêu cầu Q 51

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

Hình 4.8 Biểu diễn dịch vụ trong bảng 4.7 54

Hình 4.9 Vehicle ontology 58

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

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

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

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

Hình 4.14 Kiến trúc Lumina - Semantic Web Service Discovery 68

Hình 4.15: Mô hình kết hợp kết quả Matching 69

Hình 5.1 Domain ontology trong dịch vụ giao thức ăn tại nhà 74

Hình 5.2 Domain ontology cho Thức ăn Trung Quốc 75

Hình 5.3 Một ví dụ về nguyên tắc phân loại QoS 78

Danh mục bảng Bảng 2.1 Các thành phần của tài liệu WSDL 17

Bảng 3.1 Ba ngôn ngữ biểu diễn dịch vụ web được W3C đệ trình 39

Bảng 4.1 Một số khái niệm thường gặp 48

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

Bảng 4.3: Tóm tắt giải thuật trong cách tiếp cận I 50

Bảng 4.4 Tóm tắt giải thuật trong cách tiếp cận II 50

Bảng 4.5 Tóm tắt giải thuật trong cách tiếp cận IV 52

Bảng 4.6 Tóm tắt giải thuật trong cách tiếp cận V 53

Bảng 4.7 Ví dụ về các khai báo dịch vụ 54

Bảng 4.8 Bảng so sánh các hướng tiếp cận 56

Bảng 4.9: Các mức DoM trong OWLSM 70

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

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

1.1.1 Mục tiêu

Đề tài nghiên cứu các khái niệm trong web ngữ nghĩa, mô hình kiến trúc hướng dịch vụ SOA, và quá trình kết hợp và tối ưu các dịch vụ web ngữ nghĩa, và các giải thuật, công cụ phục vụ việc kết hợp và tối ưu các dịch vụ web trong quá trình thiết kế workflow

Với công trình nghiên cứu này, hi vọng sẽ đóng góp phần nào về việc đưa các khái niệm về web 3.0 trở nên gần gũi và quen thuộc hơn với công nghệ hiện tại

1.1.2 Giới hạn

Đề tài giới hạn trong việc nghiên cứu sâu về các khái niệm có liên quan:

Mô hình kiến trúc hướng dịch vụ (SOA), dịch vụ web (Web Service), web ngữ nghĩa (Semantic Web) và dịch vụ web ngữ nghĩa (Semantic Web Service), Lôgic

mô tả (Description Logic), Ontology

Dựa trên những khái niệm đã nghiên cứu, nhóm thực hiện phân tích, so sánh các công cụ phục vụ việc khai phá và kết hợp các dịch vụ web với SOA Từ

đó, xây dựng giải thuật mới phục vụ quá trình này

1.2 Kết quả tóm lược của đề tài

Kết quả trước mắt của đề tài là một tài liệu phục vụ nghiên cứu các vấn đề liên quan

Ngoài ra, hướng phát triển của đề tài là xây dựng một giải thuật mới phục

vụ cho việc tham khảo và tạo nền tảng để xây dựng một công cụ mới, nếu đề tài được phát triển lên

1.3 Cấu trúc khóa luận

Khóa luận được chia thành 5 chương:

- Chương 1: Giới thiệu lý do thực hiện đề tài, cùng các mục tiêu và giới hạn đưa ra Mục tiêu của chương một là khái quát những nguyên nhân dẫn đến xây dựng đề tài và những kết quả mà đề tài đạt được

- Chương 2: Trình bày các kiến thức nền tảng của đề tài: Kiến trúc hướng dịch vụ, Web Service Chương hai cung cấp những nền tảng mà những khái niệm cơ sở được phát triển và dựa vào Mục tiêu của chương hai là

giúp cho các phần trình bày sau được rành mạch, dễ hiểu hơn, đồng thời là một nguồn tài liệu nghiên cứu cho những độc giả quan tâm

- Chương 3: Trình bày cơ sở lý thuyết về ontology và web ngữ nghĩa Về ontology, chúng tôi đưa ra các khái niệm về ontology, phân loại các ontology được W3C đưa ra và công nhận, đồng thời diễn giải ngữ nghĩa trong ontology qua một ví dụ cụ thể Về web ngữ nghĩa, chương 3 giới thiệu về web ngữ nghĩa (công nghệ, kiến trúc, ngôn ngữ…) và các khái niệm cao hơn như: dịch vụ web ngữ nghĩa, web service annotation ontology

- Chương 4: Các kiến thức cơ bản về quá trình khai phá dịch vụ web ngữ nghĩa: giới thiệu, kiến trúc, các hướng tiếp cận hiện có của quá trình và phân tích, nhận xét các công cụ khai phá hiện nay

- Chương 5: Trình bày các khái niệm trong việc xây dựng giải thuật phục

vụ cho khai phá dịch vụ web ngữ nghĩa Đây là phần chính của khóa luận, dựa trên các chương cung cấp các kiến thức trước

- Chương 6: Kết luận, tổng kết những điều làm được của đề tài, những điều chưa làm được và hướng phát triển

Chương 2: KIẾN THỨC CƠ BẢN

2.1 Services Orient Architecture

2.1.1 Giới thiệu công nghệ

2.1.1.1 SOA là gì?

SOA là viết tắt của Service Oriented Architecture (kiến trúc hướng dịch vụ) Như tên gọi của mình, SOA là một qui trình, hay hướng tiếp cận việc xây dựng, thiết kế, tích hợp phần mềm hay hệ thống phần mềm bằng cách khai phá và kết hợp các module, đóng vai trò là các “dịch vụ” có tính “kết nối mềm dẻo” và tái sử dụng Mỗi dịch vụ thực hiện một nghiệp vụ cố định và được xem là những thành phần tạo nên ứng dụng Các dịch vụ sẽ giao tiếp với nhau qua một ngôn ngữ chung và được kết hợp qua mạng Nói khái quát hơn, SOA là một tổ hợp các dịch

vụ được khai phá và kết hợp để xây dựng các phần mềm, chức năng hoặc hệ thống

Hình 2.1 Mô hình trừu tượng Kiến trúc hướng dịch vụ SOA

Kiến trúc hướng dịch vụ SOA gồm 3 lớp dịch vụ:

- Application Service Layer: gồm các dịch vụ ứng dụng

- Domain Service Layer

- Enterprise Service Layer

2.1.1.2 Hoạt động của mô hình SOA Kiến trúc SOA hoạt động dựa vào ba thành phần chính: Service Registry, Service Provider và Service Consumer

Hình 2.2 Mô hình hoạt động của SOA

- Service Provider: Cung cấp các service phục vụ cho một nhu cầu nào

đó Nhiệm vụ của Service Provice là chứa các dịch vụ, đưa chúng đến Service Register với các thông tin đầy đủ của service, phục vụ cho user (service consumer) User (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động Họ chỉ cần quan tâm dịch vụ đó là gì

- Serive Consumer: khách hàng dịch vụ hay những user sử dụng service được cung cấp bởi Service Provider Nhiệm vụ của Service Consumer là tìm kiếm trong Service Registry dịch vụ thích hợp để thực thi một nghiệp vụ được đưa ra

- Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau, Service Consumer dựa trên những thông tin này

để tìm kiếm và lựa chọn Service Provider phù hợp

Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp (các chức năng có thể cung cấp, khả năng của hệ thống (resource, performance, giá cả dịch vụ ) vào Service Registry Service Consumer khi có nhu cầu về một

service nào đó sẽ tìm kiếm thông tin trên Service Registry Ngoài chức năng hỗ trợ tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành thương lượng thêm (về mặt giá cả, resource sử dụng )

2.1.2 Đặc điểm của SOA

2.1.2.1 Nguyên tắc cơ bản của mô hình SOA

SOA tìm cách giải quyết một số vấn đề theo cách nhìn lấy ứng dụng làm trung tâm Có thể tóm gọn những phát biểu đó theo các nguyên lý như sau:

- Ứng dụng phải mở ra khả năng cho phép các ứng dụng mới hoặc ứng dụng đang tồn tại có thể sử dụng được Nó cũng phải có khả năng kết nối tới các dịch vụ được đưa ra bởi các ứng dụng khác để tạo thành các dịch vụ cao cấp hơn hay còn gọi là ứng dụng tổ hợp

- Sự khác biệt về công nghệ không thành vấn đề và khả năng tương tác trở thành mục tiêu then chốt

- Các chuẩn mở phải được thông qua để cho phép tích hợp giữa các doanh nghiệp Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp, nhiều đối tác thậm chí có thể với cả khách hàng

- Phải chú ý tới việc quản lý và và đảm bảo khả năng có thể quản trị của hệ thống để đảm bảo tính linh hoạt do ba nguyên tắc đầu tiên không bị xáo trộn và xung đột với nhau

Nói cách khác, SOA nhấn mạnh việc hạ thấp các rào cản truyền thống tới khả năng tái sử dụng của ứng dụng Tôn trọng nguyên tắc thiết kế này của SOA sẽ giải quyết được bài toán lớn về vấn đề tích hợp cũng như bảo trì hệ thống phần mềm đang là thách thức đối với các nhà phát triển công nghệ thông tin trong giai đoạn hiện nay

Dựa trên nguyên lý, hệ thống SOA có những tính chất cơ bản Để có thể xem xét hoạt động và xây dựng được hệ thống thì việc hiểu rõ tính chất của hệ thống đóng vai trò rất quan trọng

2.1.2.2 Các tính chất của SOA

Bởi đặc trưng của kiến trúc và hoạt động, mô hình SOA có các tính chất đặc trưng sau:

 Kết nối lỏng lẻo

Vấn đề kết nối nói tới một số ràng buộc giữa các module lại với nhau Có 2

loại kết nối là lỏng lẻo và chặt chẽ Các module có tính chất kết nối lỏng lẻo có

một số ràng buộc được mô tả rõ ràng trong khi các module có tính kết nối chặt lại

có nhiều ràng buộc không thể biết trước Hầu như mọi kiến trúc phần mềm đều

hướng đến tính kết nối lỏng lẻo giữa các module Mức độ kết nối của hệ thống

ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống Kết nối càng chặt bao nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra Mức độ kết nối tăng dần khi bên sử dụng dịch vụ cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan

hệ sẽ càng trở nên chặt chẽ Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa 2 bên

Tính kết nối lỏng lẻo giúp gỡ bỏ những ràng buộc điều khiển giữa những

hệ thống đầu cuối Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng năng xuất, khả năng mở rộng và khả năng đáp ứng cao Những thay đổi cài đặt cũng được che dấu đi Tính chất kết nối lỏng lẻo đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các giao diện phải theo chuẩn và cần một thành phần trung gian quản lý, trung chuyển yêu cầu giữa các hệ thống đầu cuối

 Quản lý chính sách

Tập các chính sách là tập tất cả các qui tắc chung mà mọi thành phần trong

hệ thống đều phải tuân thủ Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các chính sách Các chính sách cần được quản lý và áp dụng cho mỗi dịch vụ cả trong quá trình thiết kế và trong thời gian triển khai

Việc đó làm tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng Bởi

vì các chính sách được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm Nếu không sử dụng các chính sách, thì các nhân viên phát triển phần mềm, nhóm điều hành và nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những chính sách Ngược lại, nếu

sử dụng các chính sách, những nhân viên phát triển phần mềm chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp

 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm khai thác dịch vụ (service discovery) Một người sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần Người sử dụng chỉ cần hỏi một registry về một dịch vụ nào thỏa yêu cầu tìm kiếm Ví dụ, một hệ thống chuyển khoản, khách hàng yêu cầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng Registry trả về một tập các danh mục thỏa mãn yêu cầu Các mục đó chứa thông tin về dịch vụ, bao gồm cả chi phí giao dịch Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cung cấp dịch vụ dựa trên thông tin địa chỉ registry đã cung cấp để sử dụng dịch vụ kiểm tra thẻ tín dụng Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết dùng

để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô

tả và gửi đi Nhà cung cấp dịch vụ sẽ thực thi kiểm tra thẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần mô tả dịch vụ Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian Mối ràng buộc này là ràng buộc trong thời gian chạy Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy Vậy với SOA, bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về, cũng như địa chỉ dịch vụ cho đến khi cần

ngừng hoạt động bất cứ lúc nào, nhất là đối với những áp dụng tổng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó những ứng dụng được xây dựng Một kiến trúc hỗ trợ kết nối và thực thi động sẽ có khả năng tự phục hồi hơn một

hệ thống không hỗ trợ những tính năng trên

Ngoài ra, những hệ thống dựa trên dịch vụ yêu cầu tách biệt giữa giao diện

và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì Khả năng này chỉ có được khi client tương tác với giao diện của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ Đây là một trong những tính chất cơ bản của hệ thống hướng dịch

vụ (SOA)

2.1.3 Ưu và khuyết điểm của SOA

2.1.3.1 Ưu điểm

 Hệ thống uyển chuyển và lâu dài Dễ dàng và nhanh chóng tạo ra các

Bussiness process từ các service đã có

 Khả năng tương tác của các service khá cao

2.1.3.2 Khuyết điểm

 Hệ thống phức tạp

 Khó miêu tả dữ liệu không cấu trúc trong header của message

2.2 Web Service

2.2.1 Giới thiệu công nghệ

Theo định nghĩa của W3C (World Wide Web Consortium), dịch vụ Web là một hệ thống phần mềm được thiết kế để hỗ trợ khả năng tương tác giữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giao diện chung và sự gắn kết của nó được mô tả bằng XML Dịch vụ Web là tài nguyên phần mềm có thể xác định bằng địa chỉ URL, thực hiện các chức năng và đưa ra các thông tin người dùng yêu cầu Một dịch vụ Web được tạo nên bằng cách lấy các chức năng

và đóng gói chúng sao cho các ứng dụng khác dễ dàng nhìn thấy và có thể truy cập đến những dịch vụ mà nó thực hiện, đồng thời có thể yêu cầu thông tin từ dịch vụ Web khác Nó bao gồm các mô-đun độc lập cho hoạt động của khách hàng và doanh nghiệp và bản thân nó được thực thi trên server

Trước hết, có thể nói rằng ứng dụng cơ bản của Dịch vụ Web là tích hợp các hệ thống và là một trong những hoạt động chính khi phát triển hệ thống Trong hệ thống này, các ứng dụng cần được tích hợp với cơ sở dữ liệu (CSDL) và các ứng dụng khác, người sử dụng sẽ giao tiếp với CSDL để tiến hành phân tích

và lấy dữ liệu Trong thời gian gần đây, việc phát triển mạnh mẽ của thương mại điện tử và B2B cũng đòi hỏi các hệ thống phải có khả năng tích hợp với CSDL của các đối tác kinh doanh (nghĩa là tương tác với hệ thống bên ngoài - bên cạnh tương tác với các thành phần bên trong của hệ thống trong doanh nghiệp)

2.2.2 Hoạt động của dịch vụ web

Hình 2.3 Mô hình hoạt động của Web Service

Hoạt động của mô hình Web Service như sau:

- Service Provider: Dùng Web Services Description Language (WSDL) để

mô tả dịch vụ mà mình có thể cung cấp và xuất bản (đăng ký) với Service Broker (tương tự với Service Registry trong SOA)

- Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các

Service Provider Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp Thành phần chính của Service Broker là các kho lưu trữ được mô tả bởi Universal Discovery, Description, and Integration (UDDI)

- Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng (loại service,

thời gian sử dụng, resource cần thiết, mức giá .) và gởi cho Service Broker Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker, Service Requester có thể tìm thấy Service Provider thích hợp Ngay sau đó, giữa Service Requester và Service Provider thiết lập kênh giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong việc sử dụng service

Như vậy, sử dụng Web Service cho việc tích hợp SOA giúp ứng dụng đạt được những mục tiêu theo nguyên lý SOA:

- Thông qua các chuẩn công nghiệp Các chuẩn này gồm Web Service với các định nghĩa thành phần chuẩn công nghiệp cho XML

- Sử dụng được những phần mềm thương mại đã xây dựng sẵn nhiều nhất có thể Phần mềm phải cung cấp các kênh giao tiếp (adapter) cho Web service

- Đóng gói các ứng dụng cho phép kế thừa với giao diện đúng theo chuẩn công nghệ chung Các Web Service đều phải được sử dụng thông qua giao diện này

- Sử dụng dữ liệu và tầng dữ liệu độc lập nằm giữa các ứng dụng để ẩn đi cấu trúc dữ liệu bên dưới Mọi tương tác với dữ liệu đều phải thông qua Web Service

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

Nền tảng của các dich vụ web gồm các yếu tố: XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language)

Hình 2.4: Các thành phần của Web service

 XML - eXtensible Markup Language

XML là một chuẩn mở do W3C đưa ra và được phát triển từ SGML XML

là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa, nó được

sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B

Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML, nhưng không tuân theo một đặc tả quy ước như HTML, người sử dụng hay các chương trình có thể quy ước định dạng các tag XML để giao tiếp với nhau Trong khi HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì Với XML, các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở

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

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

Tài liệu XML chỉ chứa dữ liệu, không nhắc đến cách trình bày Điều này

có ý nghĩa đó là một XML parser, không cần phải hiểu ý nghĩa của các thẻ Nó chỉ

cần tìm các thẻ và xác định đây là một tài liệu XML hợp lệ vì trình duyệt không cần phải hiểu ý nghĩa của các thẻ, nên người dùng có thể tạo ra các thẻ bất kì để

sử dụng

 SOAP (Simple Object Access Protocol)

Là một giao thức dựa trên XML để cho phép các ứng dụng trao đổi thông tin qua HTTP, được thiết kế đơn giản và dễ mở rộng Đơn giản, SOAP là một giao thức để truy cập một Web Service, một giao thức truyền thông hay một định dạng để gửi tin nhắn Tất cả các thông điệp SOAP đều được mã hóa sử dụng XML, cho nên không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử dụng để thực hiện miễn là người dùng sử dụng các message theo định dạng XML Tương tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn là nó có thể xử lý được những message theo định dạng XML

Hình 2.5: Mô hình gửi nhận thông điệp qua SOAP

Bộ khung của một thông điệp SOAP bao gồm:

- Protocol Header: Cho biết thông tin về các chuẩn giao thức được sử dụng

- SOAP Envelop: Phần chính của thông điệp Thông tin chính của message bao gồm:

• SOAP Header: Chứa các SOAP header

• SOAP Body: Thông tin về name và data được đặc tả dưới dạng XML Ngoài ra còn có trường lỗi được dùng để gởi các web service exception

Hình 2.6: Cấu trúc của một SOAP message

 WSDL (Web Service Discription Language)

WSDL là một ngôn ngữ dựa trên XML dùng để mô tả giao diện của Web Service Nó cung cấp một cách thức chuẩn để mô tả các kiểu dữ liệu được truyền trong các thông điệp thông qua Web Service, các hoạt động được thực hiện trên các thông điệp và ánh xạ các hoạt động này đến giao thức vận chuyển

 Phần giao diện: mô tả giao diện và giao thức kết nối

 Phần thi hành: mô tả thông tin để truy xuất service

Cả hai phần này sẽ được lưu trong 2 tập tin XML:

 Tập tin giao diện service (cho phần 1)

 Tập tin thi hành service (cho phần 2)

Hình 2.7: Cấu trúc WSDL

 Tập tin giao diện - Service Interface

Một tài liệu WSDL mô tả một Web Service gồm các thành phần chính:

Element Defines

<types> Các kiểu dữ liệu đƣợc sử dụng bởi các Web Service

<message> Các thông điệp đƣợc sử dụng bởi các Web Service

<portType> Các hoạt động đƣợc thực hiện bởi các Web Service

<binding> Các giao thức truyền thông đƣợc sử dụng bởi các Web Service

Bảng 2.1 Các thành phần của tài liệu WSDL

Cấu trúc một tài liệu WSDL sẽ nhƣ sau:

 Tập tin thi hành - Service Implementation

WSDL mô tả 2 loại thông tin chính bao gồm : service và port

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

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

 UDDI (Universal Description, Discovery and Integration)

UDDI là một dịch vụ thư mục nơi mà các công ty có thể đăng ký và tìm kiếm các Web Service

UDDI cung cấp một khung ứng dụng về các nghiệp vụ để xuất bản một Web Service, khám phá các Web Service hiện hữu và xây dựng các đăng ký dịch

vụ chung

• UDDI là một thư mục để lưu trữ các thông tin về các Web Service

• UDDI là một thư mục của các Web Service giao diện mô tả bởi WSDL

• UDDI truyền qua SOAP

• UDDI được xây dựng trên Microsoft NET

Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service Những thông tin về Web Service được sử dụng và công bố lên mạng sử dụng giao thức này Nó sẽ kích hoạt các ứng dụng để tìm kiếm thông tin của Web Service khác nhằm xác định xem dịch vụ nào sẽ cần đến nó

Những UDDI registry hiện có:

 UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft, IBM đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý

 IBM Test Registry: bộ đăng ký cho những người phát triển để thử nghiệm công nghệ và kiểm tra những service của họ

 Private registries IBM ships: bộ đăng ký UDDI cá nhân

Trên đây là mô tả bộ chuẩn công nghiệp mà Web Service sử dụng để triển khai mô hình hoạt động theo tư duy SOA Thoạt nhìn, SOA và Web Service có vẻ giống nhau nhưng chúng không phải là một Định nghĩa cơ bản của Web Service dựa trên các công nghệ XML, WSDL, UDDI và SOAP cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn

Rõ ràng, theo định nghĩa thì Web Service là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm Web Service đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải Web Service (và không phải tất cả Web Service đều có kiến trúc SOA) Tuy vậy, SOA và Web Service có mối quan hệ tương hỗ: sự phổ biến của Web Service giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp Web Service thành công

2.2.4 Ưu và khuyết điểm

 Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong

hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán

 Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh nghiệp khác

Nhược điểm:

 Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của Dịch vụ Web, giao diện không thay đổi, có thể lỗi nếu một máy khách không được nâng cấp, thiếu các giao thức cho việc vận hành

 Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt

 Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật

Chương 3: Ontoglogy – CƠ SỞ LÝ THUYẾT

3.1 Description Logic

3.1.1 Giới thiệu

Logic mô tả (Description Logic, viết tắt DL) là họ các ngôn ngữ biểu diễn tri thức có thể sử dụng để biểu diễn tri thức thuật ngữ của một miền ứng dụng theo một cách có cấu trúc và được hiểu rõ một cách hình thức Mặt khác, cái tên logic mô tả ý nói đến các mô tả về khái niệm được dùng để mô tả một miền và ngữ nghĩa dựa logic (logic-based semantics) mà có thể thu được từ việc dịch từ logic mệnh đề bậc nhất Logic mô tả được thiết kế như một mở rộng của khung ngữ nghĩa (sematic frame) và lưới ngữ nghĩa (semantic network), hai loại này đã không được trang bị một ngữ nghĩa dựa logic hình thức

Logic mô tả được đặt tên hiện dùng từ năm 1980 Trước đó, nó có tên gọi

là hệ thống thuật ngữ (terminological system), và tiếp đó là các ngôn ngữ khái niệm (concept language)

3.1.2 Cú pháp Description Logic

Cú pháp của lôgic mô tả bao gồm:

 Một tập các ký hiệu mệnh đề dùng để ký hiệu các tên khái niệm (concept name);

 Một tập các ký hiệu mệnh đề đôi để ký hiệu các tên vai trò (role name);

 Một định nghĩa đệ quy để định nghĩa các thuật ngữ khái niệm từ các tên

khái niệm và tên vai trò bằng cách sử dụng các tạo tử (constructor)

Trong lôgic mô tả, các tên khái niệm được xem là các khái niệm nguyên

tử, các tên vai trò được coi là các vai trò nguyên tử Nhìn chung, một khái niệm đại diện cho tập các cá thể thuộc về nó, và một vai trò đại diện cho một quan hệ giữa các khái niệm

Cú pháp của một thành viên trong gia đình lôgic mô tả được đặc trưng bởi định nghĩa đệ quy của nó, các định nghĩa đệ quy này định nghĩa các tạo tử có thể được dùng để tạo các thuật ngữ khái niệm

Một số tạo tử thông dụng bao gồm các tạo tử lôgic trong logic bậc nhất

như phép giao (intersection) hay tuyển (conjunction) của các khái niệm, phép hợp (union) hay hội (disjunction) của các khái niệm, phép phủ định (negation) hay lấy phần bù (complement) của các khái niệm, hạn chế giá trị (hạn chế với mọi - universal restriction), hạn chế tồn tại (existential resctriction), v.v Các tạo tử

khác có thể còn bao gồm các hạn chế đối với các vai trò thường thấy trong các

quan hệ nhị phân, ví dụ, tính đảo (inverse), tính bắc cầu (transitivity), chức năng (functionality), v.v Đặc biệt đối với phép giao và phép hợp, lôgic mô tả sử dụng

các ký hiệu và để phân biệt chúng với ∧ và ∨ trong lôgic bậc nhất

Dưới đây là một ví dụ về định nghĩa cú pháp của lôgic mô tả AL

 một khái niệm nguyên tử là một khái niệm-AL;

 khái niệm đỉnh ( ) là một khái niệm-AL;

 khái niệm đáy ( ) là một khái niệm-AL;

 phần bù của một khái niệm-AL C cũng là một khái niệm-AL (ký hiệu là

Ví dụ, là một khái niệm-AL, nhưng không phải Còn nữa,

là một khái niệm-AL, nhưng thì không phải

3.1.3 Ngữ nghĩa của Description Logic

Ngữ nghĩa của lôgic mô tả được định nghĩa bằng cách giải nghĩa các khái niệm như là các tập hợp gồm các cá thể, và các vai trò như là các tập gồm các cặp

cá thể Các cá thể đó thường được cho là thuộc một miền xác định cho trước Sau

đó, ngữ nghĩa của các khái niệm và vai trò không nguyên tử được định nghĩa theo các khái niệm và vai trò nguyên tử Điều này được thực hiện bằng một định nghĩa

đệ quy tương tự như trong cú pháp

Ví dụ, cho trước miền xác định là một tập hợp Trước hết, một cách giải nghĩa các khái niệm-AL được định nghĩa qua các khái niệm và vai trò nguyên tử như sau:

 Một khái niệm nguyên tử được giải nghĩa là một tập các cá thể - một tập con của miền xác định

 Mỗi vai trò nguyên tử được giải nghĩa là một tập các cặp cá thể thuộc miền xác định, nghĩa là một quan hệ nhị phân trên miền xác định Trong trường

hợp đó, nếu một cá thể x có quan hệ với y qua một vai trò R, thì y được gọi

là một R-successor của x

Tiếp theo, cách giải nghĩa này được mở rộng tới khái niệm và vai trò không nguyên tử, bằng cách sử dụng các tạo tử Việc này được thực hiện như sau

 Khái niệm đỉnh được giải nghĩa là toàn bộ miền xác định

 Khái niệm đáy được giải nghĩa là tập rỗng

 ¬C được giải nghĩa là tập của mọi cá thể trong miền xác định mà không thuộc về giải nghĩa của C

 Giao của hai khái niệm C và D được giải nghĩa là tập hợp giao, nghĩa là tập hợp gồm tất cả các cá thể trong miền xác định mà thuộc về cả giải nghĩa của C và giải nghĩa của D

 Hạn chế giá trị ∀R.C được giải nghĩa là tập gồm mọi cá thể trong miền xác

định mà tất cả các R-successor của chúng (nếu có) đều nằm trong giải

 Mô hình hóa bằng lôgic mô tả

Trong các lôgic mô tả, có sự phân biệt giữa cái gọi là TBox (hộp thuật ngữ) và ABox (hộp khẳng định) Nói chung, TBox chứa các câu mô tả các cây phả hệ của các khái niệm (nghĩa là quan hệ giữa các khái niệm) trong khi ABox chứa các câu có nội dung xác định mỗi cá thể thuộc về vị trí nào trên cây phả hệ (nghĩa là quan hệ giữa các cá thể và các khái niệm) Ví dụ, khẳng định:

(1) Mỗi nhân viên là một người

thuộc về TBox, còn khẳng định:

(2) Hà là một nhân viên

thuộc về ABox Lưu ý rằng sự phân biệt TBox/ABox trong lôgic mô tả không có

ý nghĩa như vậy trong logic bậc nhất (hầu hết các lôgic mô tả đều có thể xếp vào loại lôgic này) Hai "loại" câu này được đối xử như nhau Khi dịch sang lôgic bậc nhất, một tiên đề xếp loại như (1) chỉ là một hạn chế có điều kiện cho các mệnh

đề đơn (khái niệm) mà trong đó chỉ có các biến Rõ ràng, một câu thuộc dạng này không được ưu tiên đặc biệt so với các câu chỉ chứa các hằng như (2)

Vậy tai sao lại phân biệt như thế? Lý do chính là vì sự tách biệt đó có thể

có ích khi mô tả và hệ thống hóa các qui trình-quyết định cho các lôgic mô tả khác nhau Ví dụ, một bộ lập luận có thể xử lý TBox và ABox riêng rẽ, phần vì một số bài toán suy luận quan trọng được gắn chặt với chỉ một trong hai hộp (bài

toán 'phân loại' liên quan đến TBox, bài toán 'kiểm tra thực thể' (instant checking)

gắn với ABox) Một ví dụ khác là độ phức tạp của TBox có thể ảnh hưởng lớn tới hiệu quả làm việc của một qui trình-quyết định cho trước của một hệ lôgic mô tả nào đó, mà không phụ thuộc vào ABox Do đó, đây là một cách hữu dụng để có thể nói về phần cụ thể đó của cơ sở tri thức

Lý do phụ là sự phân biệt đó là có nghĩa nếu nhìn từ góc độ người mô hình hóa cơ sở tri thức Đối với họ, việc phân biệt giữa quan niệm của ta về các thuật ngữ/khái niệm trong thế giới (các tiên đề phân loại trong TBox) và các thể hiện cụ thể của các thuật ngữ/khái niệm đó (các khẳng định thực thể trong ABox.)

3.2 Ontology

3.2.1 Ontology là gì

Trong khoa học máy tính, một ontology là một mô hình dữ liệu biểu diễn một lĩnh vực và được sử dụng để suy luận về các đối tượng trong lĩnh vực đó và mối quan hệ giữa chúng Ontology cung cấp một bộ từ vựng chung bao gồm các khái niệm, các thuộc tính quan trọng và các định nghĩa về các khái niệm và các thuộc tính này Ngoài bộ từ vựng, ontology còn cung cấp các ràng buộc, đôi khi các ràng buộc này được coi như các giả định cơ sở về ý nghĩa mong muốn của bộ

từ vựng, nó được sử dụng trong một miền mới có thể được giao tiếp giữa người với các hệ thống ứng dụng phân tán hỗn tạp khác

Các ontology được sử dụng như là một biểu mẫu trình bày tri thức về thế giới hay một phần của nó Các ontology thường miêu tả:

 Các cá thể: Các đối tượng cơ bản, nền tảng

 Các lớp: Các tập hợp, hay kiểu của các đối tượng

 Các thuộc tính: Thuộc tính, tính năng, đặc điểm, tính cách, hay các thông

số mà các đối tượng có và có thể đem ra chia sẻ

 Các mối liên hệ: Các con đường mà các đối tượng có thể liên hệ tới một đối tượng khác

Bộ từ vựng ontology được xây dựng trên cơ sở tầng RDF và RDFS, cung cấp khả năng biểu diễn ngữ nghĩa mềm dẻo cho tài nguyên Web và có khả năng

 Các lớp (Classes) - Khái niệm

Các lớp là các nhóm, tập hợp các đối tượng trừu tượng Chúng có thể chứa các

cá thể, các lớp khác, hay là sự phối hợp của cả hai

Các ontology biến đổi tuỳ thuộc vào cấu trúc và nội dung của nó: Một lớp có thể chứa các lớp con, có thể là một lớp tổng quan (chứa tất cả mọi thứ), có thể là lớp chỉ chứa những cá thể riêng lẻ Một lớp có thể xếp gộp vào hoặc bị xếp gộp vào bởi các lớp khác Mối quan hệ xếp gộp này được sử dụng để tạo ra một cấu trúc có thứ bậc các lớp, thường là với một lớp thông dụng nhất kiểu Thing ở trên đỉnh và các lớp rất rõ ràng kiểu 2002, Ford ở phía dưới cùng

 Các thuộc tính (Properties)

Các đối tượng trong ontology có thể được mô tả thông qua việc khai báo các thuộc tính của chúng Mỗi một thuộc tính đều có tên và giá trị của thuộc tính đó Các thuộc tính được sử dụng để lưu trữ các thông tin mà đối tượng có thể có Ví

dụ, đối với một cá nhân có thể có các thuộc tính: Họ_tên, ngày_sinh, quê_quán, số_cmnd…

Giá trị của một thuộc tính có thể có các kiểu dữ liệu phức tạp

 Các mối quan hệ (Relation)

Một trong những ứng dụng quan trọng của việc sử dụng các thuộc tính là để

mô tả mối liên hệ giữa các đối tượng trong ontology Một mối quan hệ là một thuộc tính có giá trị là một đối tượng nào đó trong ontology

Một kiểu quan hệ quan trọng là kiểu quan hệ xếp gộp (subsumption) Kiểu quan hệ này mô tả các đối tượng nào là các thành viên của các lớp nào của các đối tượng

Hiện tại, việc kết hợp các ontology là một tiến trình được làm phần lớn là thủ công, do vậy rất tốn thời gian và đắt đỏ Việc sử dụng các ontology là cơ sở để cung cấp một định nghĩa thông dụng của các thuật ngữ cốt lõi có thể làm cho tiến trình này trở nên dễ quản lý hơn Hiện đang có các nghiên cứu dựa trên các kỹ thuật sản sinh để nối kết các ontology, tuy nhiên lĩnh vực này mới chỉ hiện hữu về mặt lý thuyết

3.2.3 Phân loại Ontology

 Phân loại ontology theo chủ đề của sự phân loại hóa:

Hình 3.1 Phân loại ontology theo chủ đề của sự phân hóa

- Top-level Ontology: còn gọi là Ontology lớp cao, nhằm diễn tả những khái niệm tổng quan và trừu tượng có thể được chia sẻ qua nhiều lĩnh vực và ứng dụng Nó mượn các ý niệm triết học mô tả những khái niệm lớp cao cho mọi vật về sự tồn tại của chúng, như đối tượng vật chất hay đối tượng trừu tượng như là các ý niệm có đặc điểm chung về tri thức nhận thức thông thường về hiện tượng như thời gian, không gian, các tiến trình Do

sự tổng quan đó, nó không sử dụng trực tiếp trong các ứng dụng, mà thông qua các Ontology khác

- Domain Ontology và task Ontology: các loại Ontology này lấy tri thức từ trong những lĩnh vực xác định, như trong y khoa, địa lý hay tri thức về một tác vụ riêng biệt như sự chuẩn hoặc sự cấu hình Về mặt ý tưởng thì Ontology loại này thu hẹp hơn và xác định hơn so với Top-level Ontology

Sự khái niệm hóa trong một Domain Ontology là giữ các tác vụ độc lập, khi những ý niệm trong một tác vụ Ontology được miêu tả không có tính chất rõ rệt với chi tiết cụ thể đến một lĩnh vực Sự phát triển của Domain Ontology được thực hiện nhiều ở các lĩnh vực: y học, di truyền, địa lý, du lịch, thông tin môi trường Còn Task Ontology được phát minh cho các tác

vụ xây dựng, sắp xếp kế hoạch làm việc, giám sát trong một lĩnh vực khoa

học, cơ sở tri thức máy tính dạy học, sự theo dõi phóng tên lửa, các tác vụ hướng dẫn điều trị bệnh

- Application Ontology: càng thu hẹp về phạm vi, Application Ontology cung cấp một bộ từ vựng xác định được yêu cầu để mô tả sự ban hành các tác vụ chắc chắn trong một ngữ cảnh ứng dụng cụ thể Đặc biệt, nó sử dụng

cả Domain Ontology và Task Ontology và mô tả vai trò của chúng trong một tác vụ cụ thể

Chúng ta có thể thấy hệ thống phân cấp của Ontology thông qua sự trình bày ở trên: Ontology ở lớp thấp hơn kế thừa và chuyên môn hóa các khái niệm và mối quan hệ từ Ontology lớp trên Ontology lớp thấp cụ thể hơn và phạm vi ứng dụng thu hẹp hơn, còn Ontology ở lớp cao có khả năng rộng hơn, chủ yếu dành cho việc kế thừa và sử dụng lại

 Phân loại ontology dựa trên mức độ tổng quát:

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 độ:

- 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

- 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

- 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ể Một cách phân loại thứ hai là dựa trên mức

độ chi tiết (level of details) của khái niệm mà Ontology biểu diễn

Lightweight ontologies cho phép khả năng thừa kế và biểu diễn thuộc tính của khái niệm Heavyweight ontologies có thể chứa thêm Axioms và các ràng buộc Hình 3.5 minh hoạ cách phân loại Ontology theo

2 chiều, detail và generality

Hình 3.2 Phân loại Ontology dựa trên mức độ tổng quát

3.2.5 Ví dụ

Ví dụ về một Ontology có cơ sở logic mô tả

Một Ontology đơn giản về thư viện có tên là ThuVien có thể bao gồm 3 phần:

Phần thứ nhất: là tập các khái niệm và các thuộc tính quan trọng, có thể

bao gồm:

- Các khái niệm : Sach, TacGia, DocGia, NhaXuatBan, Nguoi

- Các thuộc tính: doc, viet, motphanCua, namxuatban, theloai

- Khái niệm định nghĩa: ví dụ khái niệm “Tác giả” bao gồm tất cả những

người viết sách hoặc một phần cuốn sách

Thành phần thứ hai của Ontology ThuVien được đưa ra bằng các giả định

cơ sở của miền và có thể bao gồm:

- Nguyễn Duy, Hồ Chí Minh, Phan Thị Tươi là tác giả:

Thành phần thứ ba của Ontology ThuVien là về các cá thể và mối quan

hệ của chúng, có thể bao gồm:

- “Programming the Semantic Web” là một quốn sách:

<ProgrammingTheSemanticWeb>: sach

- “Programming the Semantic Web” được viết bởi Toby Segaran

< ProgrammingTheSemanticWeb, TobySegaran >:viet

Các Ontology dựa trên logic mô tả có thể khai thác các công cụ lập luận mạnh của logic mô tả, do vậy máy có thể hiểu được các tài nguyên Web dễ hơn

Hỗ trợ lập luận Logic mô tả có thể rất hữu ích để đảm bảo chất lượng của các Ontology mà Ontology là nòng cốt của Web ngữ nghĩa

Giả sử ta muốn kiểm tra xem TobySegaran có phải là TacGia không?

Dựa vào 3 tri thức sau:

- < ProgrammingTheSemanticWeb >: sach

- < ProgrammingTheSemanticWeb, TobySegaran >:viet

Bộ lập luận DL sẽ đưa ra kết quả là thoả Do đó có thể có một đề nghị bổ sung tri thức cơ sở này vào trong Ontology ThuVien

Như vậy, các Ontology biểu diễn dựa trên logic mô tả đã khai thác được khả năng biểu diễn tri thức cũng như khả năng lập luận hiệu quả của logic mô tả

để máy có thể hiểu được tài nguyên Web

3.3 Semantic Web

3.3.1 Giới thiệu Semantic Web

Một trang web thông thường sử dụng ngôn ngữ HTML để biểu diễn các thông tin và tri thức Đó là dạng siêu ngôn ngữ có thể được trình bày bởi các trình duyệt web, nhằm chuyển tải nội dung cần thiết cho người đọc dưới dạng ký tự và văn bản Với loại nội dung này, người đọc phải tự xử lý và tiếp thu Máy tính chỉ

có nhiệm vụ truyền tải các chuỗi ký tự mà hoàn toàn không hiểu chúng Đó là lý

do Semanic Web (web ngữ nghĩa) ra đời