Tổng hợp các dịch vụ web có ngữ nghĩa = design and implement a semantic web process composition framnework

Luận văn này tìm hiểu cách khắc phục một số nhược điểm của cách tiếp cận có cấu trúc khi mô tả các dịch vụ Web trong các tiêu chuẩn và các giải pháp hiện có rồi xây dựng hệ thống tổng hợ

TRƯỜNG ĐẠI HỌC BÁCH KHOA TP HỒ CHÍ MINH

KHOA CÔNG NGHỆ THÔNG TIN

LUẬN VĂN CAO HỌC

TỔNG HỢP CÁC DỊCH VỤ WEB CÓ NGỮ NGHĨA (DESIGN AND IMPLEMENT A SEMANTIC WEB PROCESS

COMPOSITION FRAMEWORK)

Giáo viên hướng dẫn TS Nguyễn Xuân Dũng

LỜI CẢM ƠN

Trong quá trình học tập và thực hiện luận văn cao học, em được sự giúp đỡ rất lớn của khoa CNTT và các thầy cô Bên cạnh đó những người thân, bạn bè cũng là nguồn động viên không thể thiếu để luận văn này có thể hoàn tất

Trước hết, em rất cảm ơn khoa CNTT và các thầy cô đã tạo những điều kiện thuận lợi trong quá trình học và làm luận văn cao học này Em xin gửi lời cám

ơn sâu sắc đến Thầy, TS Dương Tuấn Anh về sự quan tâm và nhiệt tình đối với sinh viên trong suốt khóa học và trong thời gian làm luận văn Tính chuyên nghiệp, nghiêm túc trong công việc và những tình cảm của thầy sẽ luôn là tấm gương để chúng em noi theo

Em xin chân thành cảm ơn Thầy, TS Nguyễn Xuân Dũng đã tận tình hướng dẫn, khích lệ tinh thần tìm hiểu, hỗ trợ em hoàn tất luận văn cao học này

Con xin cảm ơn bố mẹ đã luôn theo sát động viên trong những lúc khó khăn nhất để con cố gắng hoàn thành tốt luận văn cao học

Tôi mong muốn gửi lời cảm ơn đến tất cả những người thân và bạn bè đã luôn hỗ trợ tôi một cách nhiệt tình và vô tư trong suốt quá trình học tập và thực hiện luận văn cao học

Tháng 11 năm 2004

Lại Đức Nhuận

TÓM TẮT

Quá trình Web là công nghệ thế hệ mới cho phép tiến hành các hoạt động kinh doanh cốt lõi trong thương mại điện tử và dịch vụ điện tử Các quá trình Web được tạo ra bằng cách tổng hợp những dịch vụ Web và những thành phần phần mềm có sẵn Quá trình Web hàm chứa cả dòng công việc (workflow) bên trong tổ chức và dòng công việc giữa các tổ chức

Mặc dù đã có những bước tiến đáng kể về lĩnh vực này, hiện vẫn còn một số vấn đề tồn tại khiến cho việc ứng dụng và triển khai dịch vụ Web cũng như việc tạo ra các quá trình Web chưa được như mong muốn Tồn tại đáng lưu ý nhất liên quan đến việc mô tả và tìm kiếm các dịch vụ Web Đa số các tiêu chuẩn và giải pháp

hiện có [5] tập trung vào cách tiếp cận có cấu trúc để mô tả các dịch vụ Web, sử

dụng cách mô tả dựa trên XML Cách tiếp cận này có hạn chế là dịch vụ Web được mô tả mà không thể hiện một cách tường minh ngữ nghĩa của dịch vụ Web như người cung cấp dịch vụ Web mong muốn

Hiện có một số cách để giải quyết vấn đề này theo hướng dùng dịch vụ Web có ngữ nghĩa (semantic web services) Các dịch vụ Web có ngữ nghĩa được mô tả và tìm kiếm dựa trên thông tin “tự mô tả một cách hình thức” Hầu hết các chuẩn hiện

có [1, 2, 3, 4, 13] để tổng hợp quá trình Web từ các dịch vụ Web đều dựa trên nền

tảng là các tiêu chuẩn mô tả những dịch vụ Web Vì vậy nếu mô tả các dịch vụ Web có ngữ nghĩa thì trong quá trình tổng hợp để có quá trình Web, ta thao tác với các thành phần riêng biệt mà mỗi thành phần đều có ngữ nghĩa của quá trình Web Khi mọi hoạt động của một quá trình Web đều được mô tả một cách có ngữ nghĩa, ta gọi quá trình Web đó là quá trình Web có ngữ nghĩa

Luận văn này tìm hiểu cách khắc phục một số nhược điểm của cách tiếp cận có cấu trúc khi mô tả các dịch vụ Web trong các tiêu chuẩn và các giải pháp hiện có rồi xây dựng hệ thống tổng hợp các quá trình Web từ các dịch vụ Web bằng cách cải tiến đã đề ra

ABSTRACT

Using Web process is a new approach to perform core businesses in commerce Web processes are created by composing Web services and reusable components Web process consists of both internal workflow inside a company and external workflows among organizations

e-Although there are fast progress in this field, some problems do remain that prevent the usage of Web services and Web processes One of the most important technical obstacles is the way to describe and discover Web services

Most of the recommendations and standards in use nowadays [5] focus mainly

on the structural approach to describe Web services, using XML-based syntax This approach has the primary limitation: Web services are described without representing Web services semantics explicitly as service suppliers wanted

There are several ways to solve the above problem using semantic Web services With these solutions Web services are described and discovered based on information “self-described formally” If we describe Web services semantically then we deal with Web process composition where every component has some semantics When every activity of a Web process is described semantically, we call that Web process a semantic Web process

This thesis presents a way to solve the weakness of the structural approach to

describe Web services in current standards [1, 2, 3, 4, and 13] and solutions and

then design, implement a framework to compose Web processes from Web services using the recommended enhancements

MỤC LỤC

\[

1 ĐẶT VẤN ĐỀ 1

2 CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH HIỆN CÓ 4

2.1 N GÔN NGỮ ĐÁNH DẤU MỞ RỘNG ĐƯỢC (XML) 4

2.2 N GÔN NGỮ XSD 4

2.3 G IAO THỨC HTTP (H YPER T EXT T RANSFER P ROTOCOL ) 5

2.4 G IAO THỨC SOAP (S IMPLE O BJECT A CCESS P ROTOCOL ) 5

2.5 Đ ẶC TẢ UDDI (U NIVERSAL D ESCRIPTION D ISCOVERY & I NTEGRATION ) 5

2.5.1 Dữ liệu UDDI 6

2.5.2 Dịch vụ do UDDI cung cấp thông qua các tập API 7

2.5.3 Nút UDDI (UDDI Nodes) 7

2.5.4 UDDI registry 8

2.5.5 Nhóm các UDDI registry 8

2.5.6 Cá nhân, nhà xuất bản và chủ sở hữu 8

2.5.7 Chuyển đổi chủ sở hữu 9

2.5.8 Data custody 9

2.6 N GÔN NGỮ MÔ TẢ DỊCH VỤ W EB (WSDL) 9

2.7 S Ử DỤNG WSDL TRONG UDDI REGISTRY 12

2.8 T ỔNG QUAN VỀ CÁC NGÔN NGỮ ĐÁNH DẤU NGỮ NGHĨA CHO TÀI NGUYÊN W EB 13

2.9 T ỔNG QUAN VỀ CÁC ĐẶC TẢ QUÁ TRÌNH W EB HIỆN CÓ 17

2.9.1 BPEL4WS 18

2.9.2 BPML 19

2.9.3 DAML-S (Tên mới là OWL-S) 20

2.9.4 METEOR-S 21

2.10 N HẬN XÉT VỀ CÁC PHƯƠNG PHÁP VÀ CÔNG TRÌNH HIỆN CÓ 22

3 TỔNG HỢP CÁC DỊCH VỤ WEB CÓ NGỮ NGHĨA 23

3.1 M Ô HÌNH HỆ THỐNG TỔNG HỢP CÁC DỊCH VỤ W EB CÓ NGỮ NGHĨA 23

3.2 C Ơ SỞ HẠ TẦNG PHỤC VỤ VIỆC TÌM KIẾM 24

3.3 T ỔNG HỢP QUÁ TRÌNH W EB CÓ NGỮ NGHĨA 26

3.4 R EPOSITORY LƯU TRỮ CÁC THÔNG TIN LIÊN QUAN Ở DẠNG XML 30

3.5 K HỐI CHỨC NĂNG PHỤC VỤ VIỆC THỰC THI QUÁ TRÌNH W EB 30

4 THIẾT KẾ VÀ HIỆN THỰC HỆ THỐNG 31

4.1 T HIẾT KẾ HỆ THỐNG 31

4.1.1 Mô tả ngữ nghĩa cho dịch vụ Web 31

4.1.2 Đăng ký dịch vụ Web có ngữ nghĩa vào UDDI registry 34

4.1.3 Xếp hạng các phương thức của dịch vụ Web 45

4.1.4 Tìm kiếm dịch vụ Web có ngữ nghĩa 47

4.2 H IỆN THỰC HỆ THỐNG 48

4.2.1 Hiện thực cơ sở hạ tầng phục vụ tìm kiếm 48

4.2.2 Hiện thực chức năng mô tả và đăng ký dịch vụ Web có ngữ nghĩa 53

4.2.3 Hiện thực chức năng tổng hợp quá trình Web có ngữ nghĩa 57

4.2.4 Hiện thực chức năng sinh quá trình Web 60

4.2.5 Hiện thực chức năng phục vụ việc thực thi quá trình Web có ngữ nghĩa 60

4.3 N HẬN XÉT VÀ KẾT LUẬN 62

5 KẾT LUẬN 64

5.1 C ÁC KẾT QUẢ , KẾT LUẬN 64

5.2 H ƯỚNG PHÁT TRIỂN 67

5.2.1 Hoàn thiện trình duyệt UDDI registry 68

5.2.2 Phát triển UDDI registry 68

5.2.3 Hoàn thiện phần soạn thảo và đăng ký dịch vụ Web có ngữ nghĩa 68

5.2.4 Cải tiến, thêm phương pháp xếp hạng các phương thức của dịch vụ Web 68

5.2.5 Áp dụng các tiến bộ mới trong mô tả quá trình Web 68

5.2.6 Cải tiến, thêm phương pháp mô tả quá trình Web có ngữ nghĩa 68

5.2.7 Hoàn thiện phần soạn thảo quá trình Web có ngữ nghĩa 68

5.2.8 Cải tiến, phát triển động cơ triển khai quá trình Web 68

6 TÀI LIỆU THAM KHẢO 69

7 PHỤ LỤC 71

DANH MỤC HÌNH

\[

Hình 1 Quan hệ giữa một số kiểu thực thể trong UDDI 6

Hình 2 Quan hệ giữa một số thành phần của WSDL 11

Hình 3 Khái quát về ánh xạ từ mô tả bằng WSDL sang cấu trúc dữ liệu trong UDDI 13

Hình 4 OIL hình thành dựa trên 3 nền tảng khác 16

Hình 5 Các phương pháp biểu diễn ngữ nghĩa 17

Hình 6 Mô hình hệ thống tổng hợp các quá trình Web có ngữ nghĩa 23

Hình 7 Hoạt động của cơ sở hạ tầng tìm kiếm dịch vụ Web có ngữ nghĩa 25

Hình 8 Giới hạn của BPEL 29

Hình 9 Khối chức năng phục vụ thực thi quá trình Web 30

Hình 10 Cam kết tuân theo Ontology trong tài liệu WSDL 31

Hình 11 Biểu diễn ngữ nghĩa cho dịch vụ Web trong tài liệu WSDL 33

Hình 12 Chi tiết biểu diễn ngữ nghĩa cho dịch vụ Web 34

Hình 13 tModel tương ứng với giao diện cho dịch vụ Web ở hình sau 36

Hình 14 Giao diện cho dịch vụ Web, mô tả bằng WSDL 37

Hình 15 Mô tả về hiện thực của dịch vụ Web, viết bằng WSDL 39

Hình 16 businessService tương ứng với mô tả dịch vụ Web 40

Hình 17 tModel mức tối thiểu đại diện cho dịch vụ Web có ngữ nghĩa 42

Hình 18 tModel mức chi tiết đại diện cho dịch vụ Web có ngữ nghĩa 43

Hình 19 Tài liệu WSEL mô tả chất lượng dịch vụ cho dịch vụ Web 46

Hình 20 Mô hình hoạt động của juddi 49

Hình 21 Lưu đồ về cách thao tác trên juddi 50

Hình 22 Lược đồ thực thể – mối quan hệ được dùng trong juddi 51

Hình 23 Giao diện người dùng để tương tác với UDDI registry 52

Hình 24 Giao diện người dùng để thêm Publisher 53

Hình 25 Giao diện người dùng để mô tả dịch vụ Web, nút definitions 53

Hình 26 Giao diện người dùng để mô tả dịch vụ Web, nút import 54

Hình 27 Giao diện người dùng để mô tả dịch vụ Web, nút types 54

Hình 28 Giao diện người dùng để mô tả dịch vụ Web, nút message 55

Hình 29 Giao diện người dùng để mô tả dịch vụ Web, nút portType/operation 55

Hình 30 Giao diện người dùng để mô tả dịch vụ Web, nút binding/operation 56

Hình 31 Giao diện người dùng để mô tả dịch vụ Web, nút port 56

Hình 32 Giao diện người dùng để mô tả quá trình Web, nút process 57

Hình 35 Giao diện người dùng để mô tả quá trình Web, thêm hoạt động mới 58

Hình 36 Giao diện người dùng để mô tả quá trình Web, nút receive 59

Hình 37 Giao diện người dùng để mô tả quá trình Web, nút reply 59

Hình 38 Giao diện người dùng phục vụ triển khai quá trình Web 60

Hình 39 Giao diện người dùng để liệt kê các quá trình Web đã triển khai 61

Hình 40 Giao diện người dùng để triển khai mới quá trình Web 61

Hình 41 Giao diện người dùng để un-deploy quá trình Web 62

Hình 42 Các phương pháp biểu diễn ngữ nghĩa 66

1 ĐẶT VẤN ĐỀ

Trong những năm gần đây có sự chú ý đáng kể về triển vọng của các dịch vụ Web (Web services) Những thành phần phần mềm dưới dạng chuẩn hóa giờ đây có thể được mô tả, đăng ký và truy xuất bằng các giao thức dựa trên ngôn ngữ đánh dấu có khả năng mở rộng (XML) Điều này dẫn tới những ứng dụng mạnh mẽ trên mạng Internet Xét trên phương diện thương mại điện tử thì ý tưởng xây dựng các quá trình kinh doanh động (dynamic trading processes) từ những dịch vụ Web sẽ cho phép các doanh nghiệp tận dụng được tối đa lợi ích của Internet do khả năng tích hợp các dịch vụ có chất lượng tốt nhất từ doanh nghiệp và đối tác, nhà cung cấp để phục vụ khách hàng

Hiện nay đang có các nỗ lực rất lớn liên quan đến dịch vụ Web, đến những phương pháp tổng hợp các dịch vụ Web nhằm tạo ra các quá trình Web (Web processes) từ các công ty hàng đầu về công nghệ thông tin như IBM, Sun Microsystems, HP, Microsoft và từ các trường đại học lớn trên thế giới như Đại học

Georgia [1], Đại học Queensland Quá trình Web là công nghệ thế hệ mới cho phép

tiến hành các hoạt động kinh doanh cốt lõi trong thương mại điện tử và dịch vụ điện tử Các quá trình Web được tạo ra bằng cách tổng hợp những dịch vụ Web và những thành phần phần mềm có sẵn Quá trình Web hàm chứa cả dòng công việc (workflow) bên trong tổ chức và dòng công việc giữa các tổ chức

Mặc dù đã có những bước tiến đáng kể về lĩnh vực này, hiện vẫn còn một số vấn đề tồn tại khiến cho việc ứng dụng và triển khai dịch vụ Web cũng như việc tạo ra các quá trình Web chưa được như mong muốn Tồn tại đáng lưu ý nhất liên quan đến việc mô tả và tìm kiếm các dịch vụ Web Đa số các tiêu chuẩn và giải pháp

hiện có [5] tập trung vào cách tiếp cận có cấu trúc để mô tả các dịch vụ Web, sử

dụng cách mô tả dựa trên XML Cách tiếp cận này có hạn chế là dịch vụ Web được mô tả mà không thể hiện một cách tường minh ngữ nghĩa của dịch vụ Web như người cung cấp dịch vụ Web mong muốn

Hiện có một số cách để giải quyết vấn đề này theo hướng dùng dịch vụ Web có

có [1, 2, 3, 4, 13] để tổng hợp quá trình Web từ các dịch vụ Web đều dựa trên nền

tảng là các tiêu chuẩn mô tả những dịch vụ Web Vì vậy nếu mô tả các dịch vụ Web có ngữ nghĩa thì trong quá trình tổng hợp để có quá trình Web, ta thao tác với các thành phần riêng biệt mà mỗi thành phần đều có ngữ nghĩa của quá trình Web Khi mọi hoạt động của một quá trình Web đều được mô tả một cách có ngữ nghĩa, ta gọi quá trình Web đó là quá trình Web có ngữ nghĩa

Tại Việt Nam, hiện nay đang dần hình thành các dịch vụ điện tử, ban đầu là các dịch vụ công do chính phủ cung cấp qua Internet và tiến tới là chính phủ điện tử; nước ta cũng sẽ sớm hội nhập mạnh mẽ vào xu thế sử dụng thương mại điện tử của thế giới Để tận dụng tối đa lợi ích của cơ sở hạ tầng Internet, việc tìm hiểu, phân tích, thiết kế và xây dựng một hệ thống cho phép tổng hợp có hiệu quả các quá trình Web, nhất là các quá trình Web có ngữ nghĩa, là rất có ý nghĩa cả về lý thuyết và ứng dụng thực tế Giải quyết tốt vấn đề đặt ra ở phần trên cho phép tạo ra các quá trình Web có ngữ nghĩa nhằm tiến hành các hoạt động kinh doanh cốt lõi trong thương mại điện tử và dịch vụ điện tử một cách hữu hiệu

Luận văn này tìm hiểu cách khắc phục một số nhược điểm của cách tiếp cận có cấu trúc khi mô tả các dịch vụ Web trong các tiêu chuẩn và các giải pháp hiện có rồi xây dựng hệ thống tổng hợp các quá trình Web từ các dịch vụ Web bằng cách cải tiến đã đề ra

Việc thiết kế và xây dựng một hệ thống cho phép tổng hợp có hiệu quả các quá trình Web, nhất là các quá trình Web có ngữ nghĩa đòi hỏi giải quyết nhiều vấn đề

Thứ nhất cần đặt lại vấn đề ngữ nghĩa gồm những gì, các phương pháp biểu diễn

ngữ nghĩa hiện có ra sao; nên chọn cách biểu diễn ngữ nghĩa sẵn có hay nên tìm kiếm một cách biểu diễn ngữ nghĩa mới; nếu dùng một cách biểu diễn ngữ nghĩa sẵn có thì nên dùng cách nào

Thứ hai, hệ thống này nên được thiết kế theo hướng tập trung hay phân tán ? Có

nên bao gồm tất cả các thành phần kể từ mô tả, đăng ký và tìm kiếm các dịch vụ Web; các phương án tổng hợp nên quá trình Web cho đến phần tạo ra quá trình Web thực sự, và phần thực thi quá trình Web hay không ? Hay là nên thiết kế hệ thống này như một phần của hệ thống khác lớn hơn và chỉ nên bao gồm trong hệ thống này các phương án tổng hợp nên quá trình Web ?

Thứ ba, đây là hệ thống phức tạp gồm nhiều thành phần, vậy trong khuôn khổ đề

tài nên xây dựng toàn bộ hệ thống với các chức năng tương đối hay nên tập trung

đề liên quan đến chi tiết kỹ thuật của hệ thống cần được giải quyết tốt để tạo ra sản phẩm hoàn chỉnh có khả năng ứng dụng cao

Quan điểm chủ đạo của đề tài là xây dựng toàn bộ hệ thống với các chức năng tương đối trước, rồi sau đó mới đi chuyên sâu cải tiến từng phần của hệ thống Hệ thống tổng hợp các quá trình Web có ngữ nghĩa là hữu ích về lý thuyết và ứng dụng, tuy nhiên nó lại rất phức tạp, đòi hỏi giải quyết khối lượng công việc lớn Do đó cách làm này là hợp lý để trong thời gian ngắn có thể kiểm chứng được về mặt lý thuyết và có một hệ thống hoạt động được trong thực tế Về lâu dài có thể cải tiến từng phần để hệ thống hoạt động hiệu quả hơn và/hoặc quá trình Web tạo ra hoạt động tốt hơn

Các phần tiếp theo của luận văn được trình bày như sau:

• Phần 2 nêu các cơ sở lý thuyết và một số phương pháp giải quyết hiện có

• Phần 3 trình bày mô hình của phương pháp giải quyết mà luận văn này sử dụng

• Phần 4 trình bày thiết kế và hiện thực hệ thống

• Phần 5 tóm tắt các kết quả và nêu một số nhận xét, kết luận, hướng phát triển

• Cuối cùng là phần tài liệu tham khảo và các phụ lục

2 CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH HIỆN CÓ

Phần này tóm lược những cơ sở lý thuyết cho việc tổng hợp các quá trình Web có ngữ nghĩa từ các dịch vụ Web có ngữ nghĩa Tiếp sau đó là một số phương pháp và công trình hiện có để giải quyết vấn đề Cuối cùng là một số nhận xét về các phương pháp và công trình này

2.1 Ngôn ngữ đánh dấu mở rộng được (XML)

XML (Extensible Markup Language) là ngôn ngữ cho phép mô tả và định nghĩa dữ liệu Hầu hết các ngôn ngữ và giao thức liên quan đến dịch vụ Web, quá trình Web đều được xây dựng dựa trên việc sử dụng XML Đặc điểm chính của XML là

• Đây là ngôn ngữ đánh dấu dùng các thẻ (tag), cho phép mô tả và định nghĩa dữ liệu

• Cung cấp một cách để tạo ra bộ từ vựng tùy thuộc lĩnh vực đang quan tâm

• Cho phép trao đổi một cách thuận tiện và dễ dàng dữ liệu giữa các hệ thống máy tính khác nhau về phần cứng, phần mềm

• Hỗ trợ tìm kiếm thông minh nhờ có các thẻ đánh dấu

• Cho phép người dùng xem dữ liệu theo cách họ thích

• Cho phép cập nhật dữ liệu từng phần một

2.2 Ngôn ngữ XSD

Ngôn ngữ XSD (XML Schema Definition Language) được xây dựng dựa trên ngôn ngữ XML XSD cho phép mô tả các quy định về cấu trúc của một tài liệu XML Liên quan đến tổng hợp quá trình Web, XSD được dùng trong một số trường hợp cần quy định cấu trúc của một tài liệu nào đó, mà tài liệu này được viết bằng ngôn ngữ dựa trên XML

Do dựa trên ngôn ngữ XML cho nên XSD có toàn bộ các đặc điểm, ưu điểm của XML

2.3 Giao thức HTTP (Hyper Text Transfer Protocol)

Đây là giao thức thông dụng được sử dụng để truyền thông tin trên Internet Kết hợp với một số ngôn ngữ như WSDL và một số giao thức khác như SOAP, HTTP cho phép đăng ký, triển khai và thực thi các dịch vụ Web

2.4 Giao thức SOAP (Simple Object Access Protocol)

Đây là giao thức dựa trên ngôn ngữ XML Cùng với một số giao thức khác (như HTTP), SOAP phục vụ cho việc trao đổi thông tin trong môi trường phân tán, gồm nhiều phần tử mạng không đồng nhất Giao thức SOAP có 3 phần:

• Phần vỏ bọc (envelop) cho phép mô tả dữ liệu gì ở trong một thông điệp và cách xử lý dữ liệu ra sao

• Phần các luật mã hóa cho phép biểu diễn những đối tượng thuộc các kiểu dữ liệu được định nghĩa trong ứng dụng

• Phần quy ước để biểu diễn các gọi hàm từ xa (RPC – remote procedure calls)

SOAP có thể được dùng kết hợp với nhiều giao thức khác Tuy nhiên đặc tả của W3C về SOAP chỉ nêu cách sử dụng SOAP kết hợp với HTTP và HTTP Extension Framework

2.5 Đặc tả UDDI (Universal Description Discovery & Integration)

Trọng tâm của đặc tả UDDI [15] là định nghĩa ra một tập các dịch vụ hỗ trợ

cho việc mô tả và tìm kiếm những thứ sau đây

• Các tổ chức, công ty và các nhà cung cấp dịch vụ Web

• Các dịch vụ Web mà những tổ chức này cung cấp

Được dựa trên các chuẩn khác như HTTP, XML, XML Schema, SOAP; UDDI cung cấp một cơ sở hạ tầng cho phép tạo ra một môi trường trong đó các phần mềm được phát triển dựa trên các dịch vụ Web

Kiến trúc nền tảng của UDDI bao gồm các thành phần sau đây:

2.5.1 Dữ liệu UDDI

Mô hình dữ liệu của UDDI bao gồm các đối tượng thuộc về các kiểu thực thể sau:

• businessEntity: Biểu diễn một tổ chức hay công ty cung cấp dịch vụ Web

• businessService: Mô tả một tập các dịch vụ Web do một công ty cung cấp

• bindingTemplate: Mô tả các chi tiết kỹ thuật cần thiết để dùng một dịch vụ Web

• tModel: Mô tả một mô hình kỹ thuật (technical model) biểu diễn một khái niệm dùng lại được, ví dụ như một kiểu dịch vụ Web, một giao thức dùng bởi các dịch vụ Web, hay một hệ thống phân loại

• publisherAssertion: Mô tả mối quan hệ giữa các businessEntity

• subscription: Mô tả yêu cầu theo dõi sự thay đổi của các thực thể quy định trong subscription

Hình sau minh họa mối quan hệ giữa một số kiểu thực thể trên:

Hình 1 Quan hệ giữa một số kiểu thực thể trong UDDI

businessEntity

businessService

bindingTemplate

tModel

2.5.2 Dịch vụ do UDDI cung cấp thông qua các tập API

• Tập các API cho phép thao tác trên một nút UDDI

• Tập các API cho phép thao tác trên client

ƒ UDDI Subscription Listener

ƒ UDDI Value Set

2.5.3 Nút UDDI (UDDI Nodes)

Các dịch vụ Web hỗ trợ ít nhất một trong số các tập hợp API sau được gọi là một nút UDDI

Một nút UDDI có các đặc điểm sau đây

• Cho phép tương tác với dữ liệu UDDI thông qua một hoặc nhiều tập hợp các API ở trên

• Một nút UDDI chỉ thuộc duy nhất một UDDI registry

• Về mặt ý niệm, một nút UDDI được toàn quyền truy xuất và xử lý một bản sao luận lý của dữ liệu trong UDDI registry Việc nhân bản các dữ liệu trong một UDDI registry có thể được tiến hành giữa các nút UDDI nằm trên các hệ thống khác nhau nhằm tạo ra nhiều bản sao phục vụ cho quá trình hoạt động (ví dụ như tăng tính sẵn có của dữ liệu chẳng hạn)

2.5.4 UDDI registry

Một hay nhiều nút UDDI có thể kết hợp để tạo ra một UDDI registry Các nút trong một UDDI tổng hợp lại sẽ quản lý một tập các dữ liệu nhất định trong UDDI

Một UDDI registry có các đặc điểm sau:

• Một UDDI registry bao gồm một hay nhiều nút

• Các nút trong một UDDI tổng hợp lại sẽ quản lý một tập các dữ liệu nhất định, định nghĩa trước rõ ràng trong UDDI

• Một UDDI registry bắt buộc phải đưa ra các quyết định về chính sách (policy) tại các điểm cần thiết UDDI registry có thể tạm hoãn việc ra quyết định và ủy thác cho các nút UDDI trong UDDI registry tiến hành

2.5.5 Nhóm các UDDI registry

Các thực thể businessEntity, businessService, bindingTemplate, tModel hình thành những cấu trúc nền tảng trong UDDI Trong UDDI registry, mỗi dữ liệu cụ thể của một cấu trúc nền tảng được xác định một cách duy nhất thông qua một khóa UDDI

Bằng cách chọn các chính sách thích hợp, nhiều UDDI registry có thể tạo ra một nhóm (affiliation) gồm nhiều UDDI registry Mục đích của việc tập hợp các UDDI registry thành nhóm là cho phép điều khiển dễ dàng việc sao chép các cấu trúc dữ liệu nền tảng giữa các UDDI registry trong nhóm Một nhóm nhiều UDDI registry có các đặc điểm sau:

• Các UDDI registry dùng chung một không gian giá trị để gán cho các khóa Điều này nghĩa là mỗi dữ liệu cụ thể của một cấu trúc nền tảng được xác định bởi một khóa, giá trị của khóa là duy nhất trong nhóm các UDDI registry này Không có 2 giá trị được phép trùng nhau cho một khóa trong nhóm các UDDI registry

• Các UDDI registry có chính sách tương thích nhau trong việc gán khóa cho những thực thể dữ liệu

• Chính sách của các UDDI registry cho phép các nhà xuất bản (publisher) gán khóa cho những thực thể dữ liệu

2.5.6 Cá nhân, nhà xuất bản và chủ sở hữu

Khi được xuất bản trong UDDI registry thì thông tin trở thành một phần nội

quan hệ giữa nhà xuất bản, mục tin được xuất bản và nút UDDI nơi xảy ra tác vụ xuất bản sẽ được tạo ra Định nghĩa về cá nhân, nhà xuất bản và chủ sở hữu như sau:

• Cá nhân là người, tổ chức hoặc một vai trò trong công việc có giao tiếp với UDDI registry

• Nhà xuất bản (publisher) là bất cứ ai dùng tập các hàm trong UDDI Publication

• Chủ sở hữu là nhà xuất bản có quyền thay đổi một thực thể dữ liệu

2.5.7 Chuyển đổi chủ sở hữu

Chủ sở hữu của một dữ liệu có thể chuyển đổi quyền sở hữu dữ liệu cho một nhà xuất bản khác Các hàm thư viện trong tập UDDI Custody Transfer cho phép thực hiện các thao tác này

2.5.8 Data custody

Nói chung việc nhân bản dữ liệu giữa các nút UDDI phải tuân theo một giao thức nhất định Trong đặc tả UDDI có chỉ rõ nếu việc nhân bản dữ liệu giữa các nút UDDI sử dụng các hàm thư viện như UDDI đề nghị thì UDDI registry phải đảm bảo các chính sách sau đây:

• Mỗi nút UDDI chịu trách nhiệm quản lý một phần dữ liệu trong UDDI registry mà nút UDDI này thuộc về

• Mỗi đơn vị dữ liệu chỉ thuộc quyền quản lý của một nút UDDI duy nhất

• Mỗi đơn vị dữ liệu có thể là businessEntity, businessService, bindingTemplate, tModel hoặc publisherAssertion

• Việc thay đổi một đơn vị dữ liệu sẽ được tiến hành bởi nút UDDI quản lý dữ liệu này

• UDDI registry chịu trách nhiệm đề ra chính sách về thẩm quyền cho từng nút UDDI

• Vai trò quản lý đối với một dữ liệu nhất định có thể được chuyển đổi giữa các nút UDDI

2.6 Ngôn ngữ mô tả dịch vụ Web (WSDL)

Ngôn ngữ mô tả dịch vụ Web (WSDL – Web Services Description Language) cũng được xây dựng dựa trên ngôn ngữ XML Đúng như tên gọi, WSDL cho phép mô tả dịch vụ Web Các dịch vụ Web được mô tả như những điểm cuối

Các thông điệp có thể chứa thông tin hướng văn bản hoặc hướng thủ tục Các

tác vụ và các thông điệp được mô tả một cách trừu tượng rồi sau đó mới được ràng buộc vào một giao thức mạng cụ thể, một định dạng thông điệp cụ thể nhằm hoàn tất việc định nghĩa điểm cuối Các điểm cuối cụ thể có quan hệ với nhau khi kết hợp lại sẽ tạo ra những điểm cuối trừu tượng gọi là các dịch vụ WSDL có khả năng mở rộng ở chỗ cho phép mô tả các điểm cuối và các thông điệp không phụ thuộc vào định dạng của thông điệp cũng như giao thức mạng sử dụng để truyền thông Tuy nhiên đặc tả hiện tại của W3C về WSDL chỉ nêu

ra cách dùng WSDL với SOAP, HTTP GET/POST và MIME Một tài liệu WSDL sử dụng các thành phần sau trong quá trình mô tả dịch vụ Web:

• Types (kiểu)

Nơi chứa các định nghĩa kiểu, có sử dụng một hệ thống kiểu khi định nghĩa WSDL không đề ra một ngôn ngữ định nghĩa hệ thống kiểu nào cả, mà dùng ngôn ngữ sẵn có XSD làm ngôn ngữ định nghĩa kiểu Tuy nhiên WSDL không lệ thuộc vào XSD Nhằm cung cấp tính mở rộng được, WSDL cho phép sử dụng bất cứ ngôn ngữ định nghĩa hệ thống kiểu phù hợp nào cũng được

• Message (thông điệp)

Định nghĩa trừu tượng và có kiểu về dữ liệu đang được truyền

• Operation (tác vụ)

Mô tả trừu tượng về một hành động được hỗ trợ bởi dịch vụ Web

• Port type

Một tập các tác vụ trừu tượng được hỗ trợ bởi một hay nhiều điểm cuối

• Binding (ràng buộc hay còn gọi là liên kết)

Một đặc tả cụ thể về định dạng của dữ liệu và giao thức truyền cho một port type

• Port

Còn gọi là điểm cuối (endpoint), là sự kết hợp của một ràng buộc và một địa chỉ mạng

Một dịch vụ là một bộ sưu tập gồm nhiều điểm cuối

Cần nói rõ rằng bản thân WSDL chưa nhấn mạnh vào ngữ nghĩa của dịch vụ Web Tuy nhiên WSDL là cách tiếp cận có cấu trúc tốt để mô tả các dịch vụ Web Đó là lý do khiến cho đa số các chuẩn đặc tả quá trình Web hiện có đều xây dựng dựa trên nền tảng của WSDL

Hình vẽ sau cho thấy mối quan hệ giữa một số thành phần của WSDL

Hình 2 Quan hệ giữa một số thành phần của WSDL

2.7 Sử dụng WSDL trong UDDI registry

Đặc tả UDDI cung cấp một phương pháp mô tả và tìm kiếm các nhà cung cấp dịch vụ Web cũng như các dịch vụ Web mà không phụ thuộc nền tảng phần cứng và phần mềm nào Các cấu trúc dữ liệu mà UDDI sử dụng cung cấp một hệ thống cho phép mô tả những thông tin cơ bản về các dịch vụ, đồng thời cung cấp một cơ chế mở rộng được nhằm xác định chi tiết (bằng bất cứ ngôn ngữ mô tả nào) các thông tin để truy xuất dịch vụ

Có rất nhiều ngôn ngữ mô tả như vậy, nhưng nổi bật nhất chính là WSDL WSDL bổ sung cho UDDI trong việc cung cấp một phương cách có hệ thống nhằm mô tả các giao diện trừu tượng và các ràng buộc đối với những giao thức khác nhau của bất kỳ dịch vụ mạng nào

John Colgrave tại IBM và Karsten Januszewski tại Microsoft đã trình bày đặc tả chi tiết về quan hệ giữa UDDI với WSDL và trình bày cách tiếp cận để ánh xạ các mô tả dùng WSDL thành các cấu trúc dữ liệu trong UDDI Những hiểu biết này giúp dùng được WSDL kết hợp với UDDI cho việc mô tả, đăng ký và tìm kiếm các dịch vụ Web trong UDDI registry, trong đó các dịch vụ Web được mô tả bằng WSDL

Chi tiết hơn thì đặc tả của John Colgrave và Karsten Januszewski đề nghị ra ánh xạ từ các mô tả dùng WSDL thành các cấu trúc dữ liệu trong UDDI nhằm

• Cho phép đăng ký tự động các định nghĩa dùng WSDL với UDDI

• Cung cấp các truy vấn chính xác và linh hoạt trên UDDI dựa vào các chi tiết do WSDL cung cấp

Một cái nhìn khái quát về chi tiết của ánh xạ từ các mô tả bằng WSDL sang các cấu trúc dữ liệu trong UDDI như sau

Hình 3 Khái quát về ánh xạ từ mô tả bằng WSDL sang cấu trúc dữ liệu trong UDDI

2.8 Tổng quan về các ngôn ngữ đánh dấu ngữ nghĩa cho tài nguyên Web

Phần này tóm lược về lý thuyết biểu diễn tri thức, sự liên quan của việc biểu diễn ngữ nghĩa cho tài nguyên Web với lý thuyết biểu diễn tri thức rồi sau đó đề cập đến các ngôn ngữ đánh dấu ngữ nghĩa cho tài nguyên Web

Việc biểu diễn ngữ nghĩa cho tài nguyên Web là một trường hợp cụ thể của việc biểu diễn tri thức Trong biểu diễn tri thức thì thông tin về ngữ cảnh là đặc biệt quan trọng Có hai khía cạnh cần quan tâm về ngữ cảnh, đó là hiểu biết chung về thế giới cần biểu diễn và hiểu biết chuyên biệt về tình huống cụ thể của tri thức cần biểu diễn

Hiểu biết chung về thế giới cần biểu diễn là nền tảng cho việc giải quyết nhiều bài toán diễn dịch, mà một trong số các bài toán quan trọng đó là tường minh hóa ngữ nghĩa, tránh mơ hồ hay hiểu nhầm Hiểu biết chuyên biệt về tình huống cụ thể của tri thức cần biểu diễn là cần thiết để xác định chính xác ngữ nghĩa trong một tình huống cụ thể

Việc biểu diễn ngữ nghĩa cho tài nguyên Web, cũng giống như biểu diễn tri thức nói chung, phải bao gồm một cơ sở tri thức ở dạng nào đó và một tập các kỹ thuật suy luận

Các kỹ thuật suy luận được phân loại thành hai kiểu suy luận khác nhau:

suy luận dạng deductive và suy luận dạng nondeductive Suy luận dạng

deductive chỉ đưa ra các kết luận tuân theo một cách logic các sự thật được biết đến Suy luận dạng nondeductive bao gồm khả năng tổng quát hóa từ các

ví dụ (đây là suy luận dạng inductive – inductive inference) và khả năng tìm nguyên nhân khi biết kết quả (suy luận dạng abductive – abductive inference) Có hai cách xây dựng thành phần suy luận cho một hệ thống biểu diễn tri

thức: hướng thủ tục hoặc hướng khai báo

Trong các hệ thống biểu diễn tri thức sử dụng thành phần suy luận hướng khai báo thì cơ sở tri thức thường biểu diễn dưới dạng các tiên đề, và việc suy luận tiến hành theo dạng deductive, tuân theo những tiên đề đã có Các hệ thống này nhấn mạnh đến việc xây dựng cơ sở tri thức độc lập với thành phần suy luận

Ngược lại, trong những hệ thống sử dụng phương thức suy luận hướng thủ tục thì cơ sở tri thức có thể chẳng mang ý nghĩa gì nếu không đi theo phương thức suy luận riêng biệt tương ứng Các hệ thống này nhấn mạnh vào khía cạnh suy luận khi biểu diễn tri thức Cách làm này có ưu điểm là có thể đặc biệt hiệu quả trong một số suy luận cụ thể trong các miền trị được định nghĩa rõ Tuy nhiên nhược điểm của cách làm này là sự phụ thuộc chặt chẽ giữa cơ sở tri thức và thành phần suy luận

Trong các kỹ thuật biểu diễn ngữ nghĩa, dạng đơn giản nhất thường được đề cập là logic mệnh đề rồi đến logic vị từ Các kỹ thuật này trong sáng nhưng khả năng biểu diễn bị hạn chế

Một kỹ thuật có khả năng biểu diễn cao hơn là frame Trong frame đã có các khái niệm về sự thật (fact), đối tượng, khe (slot) hay còn gọi là vai trò (role) – tương tự như vai trò chủ đề (thematic role) trong một dạng biểu diễn

khác là logical form Khi biểu diễn cơ sở tri thức bằng frame người ta đã dùng

đến các ràng buộc, hạn chế để quy định cho các vai trò Ngoài ra còn có khái niệm biểu diễn hành động (action) bằng cách dùng frame, trong đó nêu tiền điều kiện của hành động, các kết quả (effect) gây ra bởi hành động, cũng như khả năng phân rã (decomposition) hành động thành những hành động nhỏ hơn

Một kỹ thuật biểu diễn ngữ nghĩa hiệu quả liên quan đến ontology Mỗi

ontology là một đặc tả về một hệ thống các khái niệm cùng với mối quan hệ giữa chúng

Hiểu một cách đơn giản thì ontology là một tập các định nghĩa của các từ vựng Một agent sau đó có thể quy định rằng nó sử dụng ontology nào nhằm giúp các agent khác hiểu đúng ngữ cảnh mà agent này muốn đề cập (giúp hiểu đúng ngữ nghĩa) Ví dụ nếu không dùng ontology thì khi tìm kiếm từ khóa

“chip” trên động cơ tìm kiếm của Google, người ta có thể có các kết quả là những thông tin về vi mạch máy tính kèm với các thông tin về khoai tây rán Trong khi đó nếu tìm kiếm mà quy định rõ chỉ dùng ontology liên quan đến máy tính thì không còn kết quả không phù hợp là thông tin về khoai tây rán nữa

Trong các nỗ lực phát triển những ontology thì OIL (Ontology Inference Layer) là đáng chú ý do cung cấp cách biểu diễn trên nền Web các ontology và cách suy luận dựa trên những ontology này

Để biểu diễn ngữ nghĩa thì ngay cả XML, XML Schema, RDF(Resource Description Framework) và RDF Schema cũng được nhắc đến, nhưng chúng có hạn chế lớn về khả năng biểu diễn và mô hình suy luận

OIL là sự kết hợp của cả kỹ thuật biểu diễn tri thức bằng frame với cú pháp của XML, RDF và khả năng biểu diễn ngữ nghĩa cũng như suy luận của Description Logic

Hình 4 OIL hình thành dựa trên 3 nền tảng khác

Trong nỗ lực mở rộng RDF cho mục đích biểu diễn ngữ nghĩa, chính phủ Mỹ đã tài trợ cho dự án DAML (DARPA Agent Markup Language) Những thành viên của nhóm phát triển này nhanh chóng đi đến kết hợp với các thế mạnh

của OIL và hình thành DAML+OIL [13] DAML+OIL mở rộng OIL bằng cách

thêm vào một số phương thức biểu diễn phức tạp hơn, giúp biểu diễn ngữ nghĩa mạnh mẽ hơn

Dựa trên các kỹ thuật biểu diễn ngữ nghĩađang tiếp tục được hoàn thiện này,hiện có một số khuyến nghị về cách thức đặc tả quá trình Web có ngữ nghĩa

Nổi bật trong số này là BPEL [2, 3, 6], BPML [4] và OWL-S [13] (tên gọi mới

của DAML-S, một phần trong dự án DAML do chính phủ Mỹ tài trợ)

Các trường đại học hàng đầu trên thế giới cũng có nhiều đóng góp quan trọng, trong đó phải kể tới những kết quả của Đại học Georgia trong dự án tổng thể

METEOR-S [1] Có thể tóm tắt tương quan giữa một số cách biểu diễn ngữ

nghĩa như hình vẽ sau

OIL

Mô hình hóa của

Frame Ngữ nghĩa và suy luận của Description Logic Cú pháp của XML, RDF

Hình 5 Các phương pháp biểu diễn ngữ nghĩa 2.9 Tổng quan về các đặc tả quá trình Web hiện có

Các ngôn ngữ cho phép tổng hợp quá trình Web từ nhiều dịch vụ Web là rất quan trọng để cho phép tích hợp ứng dụng mức xí nghiệp (EAI – Enterprise Application Integration) cũng như tích hợp quá trình kinh doanh

Hiện có rất nhiều nỗ lực đưa ra các chuẩn về vấn đề này, và đa số các chuẩn này đều dựa trên nền tảng của ngôn ngữ XML Trong số các dự thảo, các đề nghị đó nổi bật có 3 chuẩn sau đang nhận được sự ủng hộ và thừa nhận ngày càng cao:

Logic mệnh đề Logic vị từ

Frame Logical form

Resource Description Framework Ontology Inference Layer DAML+OIL BPEL BPML OWL-S

METEOR-S Mong muốn của luận văn này

• DAML-S – DAML-based Web Service Ontology (hiện đã đổi tên thành OWL-S)

Mặc dù những chuẩn này cùng có mục đích là mô tả, tổng hợp quá trình Web từ các dịch vụ Web, chúng khác nhau trên nhiều khía cạnh Muốn so sánh các chuẩn này thì phải nghiên cứu kỹ kịch bản ứng dụng các quá trình Web và sự hỗ trợ của từng chuẩn này trong mỗi kịch bản ứng dụng

Hiện có nhiều tài liệu so sánh các chuẩn tổng hợp quá trình Web này Trước hết chúng ta xét qua một số nét chính trong 3 chuẩn tổng hợp quá trình Web vừa nói, chỉ ra một số nhược điểm của mỗi loại và nêu ý tưởng mà một cách cải tiến nên có

2.9.1 BPEL4WS

BPEL4WS [2, 3] là một ngôn ngữ cho phép xác định các quá trình Web

và các giao thức quy định cách tương tác giữa các dịch vụ Web (các giao thức này còn được gọi là các quá trình Web trừu tượng) BPEL4WS thay thế hai ngôn ngữ trước đây là XLANG và WSFL trong việc đặc tả dòng chảy các dịch vụ Web

BPEL cung cấp mô hình và văn phạm dựa trên XML, cho phép định nghĩa các tương tác giữa một quá trình Web với các đối tác của quá trình Web này

thông qua những giao diện của các dịch vụ Web (các giao diện cho biết chữ

ký – signature – của dịch vụ Web)

Trong BPEL, đối tác của một quá trình Web được định nghĩa chính là dịch vụ Web BPEL cũng định nghĩa trạng thái và ý nghĩa logic của các tương tác giữa một quá trình Web với các đối tác của quá trình Web BPEL còn định nghĩa những phương pháp giải quyết các ngoại lệ một cách hệ thống

Các quá trình Web trừu tượng được dùng để xác định việc trao đổi thông điệp giữa các bên liên quan, nhưng không cho biết hành vi bên trong hay cách hiện thực của các dịch vụ Web như thế nào Trong khi đó các quá trình

Web thực thi được (quá trình Web cụ thể) lại giống như các mô tả dòng công

việc (workflow), sử dụng các hoạt động (activity) cơ bản và các hoạt động có

cấu trúc để xác định dạng thức, thứ tự thực thi của các dịch vụ Web có liên

Mô hình về quá trình Web của BPEL dựa trên ngôn ngữ mô tả dịch vụ Web WSDL, trong đó các dịch vụ Web do quá trình Web này kích hoạt và các dịch vụ Web kích hoạt quá trình Web này đều được biểu diễn bằng ngôn ngữ WSDL Một quá trình Web thực thi được cũng có thể là một dịch vụ Web, và giao diện của quá trình Web này có thể được biểu diễn bằng WSDL

2.9.2 BPML

BPML [4] là một ngôn ngữ mô hình hóa quá trình Web BPML dựa trên

một mô hình và văn phạm trừu tượng để biểu diễn các quá trình Web trừu tượng cũng như các quá trình Web thực thi được Dùng BPML có thể định nghĩa các quá trình Web, các dịch vụ Web phức tạp cũng như sự hợp tác giữa nhiều đối tác

Một quá trình trong BPML được hiểu như sự tổng hợp của các hoạt động, mỗi hoạt động thực hiện một số chức năng nào đó Quá trình Web này sẽ điều khiển sự thực thi của các hoạt động Một quá trình cũng có thể là một phần của một quá trình khác

Mỗi hoạt động (cả hoạt động đơn giản và hoạt động phức tạp – hoạt động phức tạp là quá trình Web, mà quá trình Web này là một phần của quá trình

Web đang xét) trong một quá trình có một ngữ cảnh (context), ngữ cảnh này

định nghĩa các hành vi thông dụng của mọi hoạt động được thực thi trong ngữ cảnh đó Dựa trên khái niệm về ngữ cảnh như vậy BPML định nghĩa quá trình Web là một hoạt động phức tạp tự định nghĩa ngữ cảnh thực thi của riêng nó

Đặc tả BPML định nghĩa 17 loại hoạt động và 3 loại quá trình Các loại quá trình gồm có quá trình lồng nhau (nested process) là loại quá trình được định nghĩa để thực thi trong ngữ cảnh nhất định, và định nghĩa của quá trình là một phần định nghĩa của ngữ cảnh Loại quá trình thứ hai là quá trình ngoại lệ (exception process), chuyên dùng để xử lý các biến cố xảy ra khi thực thi một quá trình cha chứa nó Loại quá trình thứ ba là quá trình bồi thường (compensation process) giúp xử lý các hậu quả do biến cố sinh ra trong quá trình cha

Trong định nghĩa của quá trình nêu rõ một trong ba cách mà quá trình được tạo ra: đáp ứng với một thông điệp nhận được, đối phó với một signal

đưa ra đề nghị chuẩn hóa tài liệu BPML bằng cách dùng RDF cho siêu dữ liệu có ngữ nghĩa, XHTML và siêu dữ liệu Dublin Core nhằm cải thiện tính dễ đọc cũng như khả năng xử lý của ứng dụng

2.9.3 DAML-S (Tên mới là OWL-S)

DAML-S (DAML-based Web Service Ontology) [13] là một cách tiếp

cận mới nhằm cung cấp một ngôn ngữ đánh dấu đủ mạnh để biểu diễn các tính chất cũng như các chức năng của những dịch vụ Web một cách có ngữ nghĩa DAML-S dựa trên DAML+OIL với mục đích cho phép tìm kiếm, kích hoạt, soạn thảo (compose) và theo dõi các dịch vụ Web

DAML-S định nghĩa một ontology thích hợp cho việc khai báo và mô tả các dịch vụ bằng cách dùng một tập các lớp và thuộc tính cơ bản Trong DAML-S, mỗi dịch vụ Web được xem như một Process, và Process Model của nó được dùng để điều khiển các tương tác với dịch vụ Web

Các chi tiết về hoạt động của dịch vụ Web được nắm bắt thông qua hai loại ontology là Process Ontology và Process Control Ontology Process Ontology mô tả dữ liệu nhập, dữ liệu xuất, các tiền điều kiện, các kết quả (effects) cũng như các thành phần con của dịch vụ Web Process Control Ontology cho phép giám sát hoạt động của dịch vụ Web Tuy nhiên phiên bản hiện hành của DAML-S chưa định nghĩa Process Control Ontology DAML-S phân loại các quá trình thành ra 3 loại: Loại thứ nhất là quá trình nguyên tố (atomic process) Đây là quá trình không có các thành phần con và thực thi được trong một bước đơn lẻ Loại thứ hai là quá trình đơn giản (simple process) Quá trình đơn giản nhằm cung cấp nền tảng để biểu diễn các quá trình nguyên tố và các quá trình phức hợp, và vì thế không kích hoạt để thực thi các quá trình đơn giản được Loại thứ ba là quá trình phức hợp (composite process), đây là quá trình phân rã được thành các quá trình con Một quá trình phức hợp dùng một số cấu trúc điều khiển để xác định làm thế nào các dữ liệu nhập được chấp nhận và làm thế nào các dữ liệu xuất được trả về

Việc so sánh và phân tích các đặc điểm của những ngôn ngữ này một cách

chi tiết [8, 9, 10] là rất cần thiết để tạo ra một chuẩn mạnh mẽ phục vụ cho

Các quá trình Web nên có tính “động” và linh hoạt để thích ứng được với sự thay đổi nhu cầu của khách hàng và thị trường Để đáp ứng các đòi hỏi

này, BPEL và BPML [9] trừu tượng hóa các tham khảo dịch vụ Web bằng

cách dùng các giao diện dịch vụ Web chứ không dùng các hàm hiện thực dịch vụ Web Điều này giúp chọn đúng các hàm hiện thực dịch vụ Web cho mỗi hoạt động trong quá trình triển khai quá trình Web (gọi là ràng buộc trong thời gian triển khai) hay trong quá trình thực thi quá trình Web (gọi là ràng buộc trong thời gian thực thi)

Tuy nhiên các chuẩn tổng hợp quá trình Web hiện hành như BPEL và BPML thiếu một đặc điểm quan trọng, đó là không thể biểu diễn các hành

động trong quá trình Web một cách có ngữ nghĩa [1] Ví dụ như BPML thì chỉ

đề nghị thêm ngữ nghĩa vào việc mô tả các quá trình Web

Có một số công trình đã giải quyết vấn đề này bằng cách thêm ngữ nghĩa

vào các hoạt động của một quá trình Web [1] Ngữ nghĩa của tất cả các hoạt

động riêng biệt trong một quá trình Web được nắm bắt và lưu trữ trong một process template (dạng như một mẫu mô tả về quá trình Web) Các mô tả về ngữ nghĩa của những hoạt động này được tách biệt khỏi bản hiện thực của dịch vụ Web Trước khi triển khai quá trình Web, hệ thống sẽ tìm kiếm các dịch vụ Web nào thỏa mãn yêu cầu ngữ nghĩa đã mô tả, sau đó các dịch vụ Web này sẽ được ràng buộc vào hoạt động tương ứng của quá trình Web trong process template Dựa vào các thông tin về giao diện và kiểu thông điệp do các dịch vụ Web cung cấp, một quá trình Web thực thi được sẽ được sinh ra rồi triển khai

Với cách giải quyết như trên, các hệ thống quản lý quá trình Web đều rất cần đến một giải thuật tìm kiếm dịch vụ Web có hiệu quả dựa trên các đòi hỏi biết trước Đòi hỏi này càng trở nên quan trọng khi tính tới số lượng các dịch vụ Web trên Internet Cách tìm kiếm dựa trên từ khóa nhiều khi không đem lại hiệu quả tốt, và tìm kiếm dựa trên ngữ nghĩa là một giải pháp bổ sung rất hữu hiệu

2.9.4 METEOR-S

Mặc dù chỉ trong phạm vi một trường Đại học, nhưng dự án METEOR-S [1]

của đại học Georgia, Mỹ có những nghiên cứu rất giá trị về cách thức đặc tả

METEOR-S hướng tới giải quyết tất cả các vấn đề liên quan tới chu trình sống của quá trình Web, và dự án được chia nhỏ thành nhiều phần để giải quyết các bài toán nhỏ hơn liên quan đến quá trình Web

Kết quả đáng giá của dự án trong việc đặc tả ngữ nghĩa cho quá trình Web là mô tả được ngữ nghĩa cho quá trình Web bằng cách kết hợp DAML+OIL với WSDL Cách làm này dựa trên phân tích rằng mặc dù DAML-S cũng dùng DAML+OIL để biểu diễn ngữ nghĩa cho quá trình Web, DAML-S lại thiếu các cấu trúc chỉ ra chi tiết việc truyền thông, nói chuyện giữa các dịch vụ Web; DAML-S phức tạp và chưa trở thành chuẩn được áp dụng rộng rãi trên phạm vi toàn cầu trong khi đó WSDL có ưu điểm là chuẩn mô tả đơn giản đã được chấp nhận rộng rãi

Cách làm của METEOR-S có ưu điểm hơn BPEL ở chỗ khả năng biểu diễn ngữ nghĩa mạnh mẽ hơn: Trong khi BPEL chỉ cho phép biểu diễn quá trình Web hạn chế về ngữ nghĩa thì METEOR-S cho phép biểu diễn quá trình Web có ngữ nghĩa mạnh mẽ bằng cách dùng DAML+OIL Trong khi BPEL chỉ cho phép biểu diễn quá trình Web từ nhiều dịch vụ Web cụ thể thì METEOR-S cho phép biểu diễn quá trình Web từ 3 loại mô tả dịch vụ Web khác nhau: các dịch vụ Web cụ thể, các giao diện của dịch vụ Web (Web service interface), các mẫu mô tả các hoạt động có ngữ nghĩa (semantic activity template)

2.10 Nhận xét về các phương pháp và công trình hiện có

Có rất nhiều phương pháp, rất nhiều cách tiếp cận khác nhau Khối lượng kiến thức liên quan để có thể đưa ra một cải tiến là rất lớn

3 TỔNG HỢP CÁC DỊCH VỤ WEB CÓ NGỮ NGHĨA

Phần này đề xuất một phương pháp tổng hợp các dịch vụ Web có ngữ nghĩa dựa trên

cơ sở lý thuyết và các công trình hiện có đã đề cập Phương pháp được đề nghị dựa trên cơ sở của UDDI, WSDL, DAML+OIL và METEOR-S

3.1 Mô hình hệ thống tổng hợp các dịch vụ Web có ngữ nghĩa

Hệ thống tổng hợp các dịch vụ Web có ngữ nghĩa được đề nghị có mô hình gồm 4 khối chức năng chính: Cơ sở hạ tầng phục vụ việc đăng ký và tìm kiếm các dịch vụ Web có ngữ nghĩa, module phục vụ việc tổng hợp các dịch vụ Web có ngữ nghĩa, repository lưu trữ các thông tin có liên quan ở dạng XML, và cuối cùng là khối chức năng phục vụ thực thi quá trình Web Mối quan hệ giữa các khối chức năng này được thể hiện trong hình vẽ sau:

Hình 6 Mô hình hệ thống tổng hợp các quá trình Web có ngữ nghĩa

Module giúp tổng hợp quá trình

Web có ngữ nghĩa

Khối chức năng phục vụ thực thi

quá trình Web

UDDI registry

UDDI

registry

UDDI registry

UDDI registry

UDDI

registry

UDDI registry

Cơ sở hạ tầng phục vụ tìm kiếm

Repository lưu trữ thông tin

Các phần sau lần lượt trình bày chi tiết về 4 khối chức năng vừa nêu và chi tiết hiện thực hệ thống

3.2 Cơ sở hạ tầng phục vụ việc tìm kiếm

Cơ sở hạ tầng cho việc tìm kiếm các dịch vụ Web là rất quan trọng cho việc sử dụng các quá trình Web Các dịch vụ Web mô tả bằng WSDL hiện được xuất bản, đăng ký trong các UDDI registry phổ quát (UBR – Universal Business Registry) UBR hiện được xem như một “thư mục cha” của tất cả các dịch vụ Web

Tuy nhiên trong đặc tả UDDI như trình bày ở trên, người ta đã nhận biết được nhu cầu sử dụng nhiều UDDI registry và cần thiết có mối tương tác giữa các UDDI registry này Trong trường hợp có nhiều UDDI registry như vậy thì việc tìm kiếm một dịch vụ Web trở nên phức tạp Trước tiên cần tìm đúng UDDI registry rồi sau đó mới tìm kiếm dịch vụ Web trên UDDI registry này Việc tìm kiếm các dịch vụ Web sẽ trở nên dễ dàng và chính xác hơn khi ta

phân loại các UDDI registry theo lĩnh vực (domain), trong đó quy định UDDI

registry thuộc lĩnh vực nào chỉ quản lý các dịch vụ Web trong lĩnh vực đó mà thôi Ngoài ra việc mô tả ngữ nghĩa cho dịch vụ Web và đăng ký ngữ nghĩa của dịch vụ Web cho UDDI registry cũng giúp cải tiến khả năng tìm kiếm dịch vụ Web cả về thời gian và độ chính xác

Cách thức tiến hành cụ thể là sử dụng các ontology, sau đó dùng DAML+OIL để mô tả các dịch vụ Web, trong đó quy định ngữ nghĩa của dịch vụ Web này cam kết tuân theo ontology nào Các mô tả bằng DAML+OIL này bổ sung cho WSDL trong việc mô tả ngữ nghĩa của dịch vụ Web, các mô tả đó sẽ được đăng ký với UDDI registry một cách phù hợp Đến đây ta đã có một phần chính yếu của cơ sở hạ tầng phục vụ cho việc tìm kiếm các dịch vụ Web có ngữ nghĩa

Phần quan trọng còn lại của cơ sở hạ tầng phục vụ cho việc tìm kiếm các dịch vụ Web có ngữ nghĩa là UDDI registry phải hỗ trợ các yêu cầu tìm kiếm có thông tin về ngữ nghĩa Đặc tả UDDI chỉ đề ra quy định rằng UDDI registry phải hỗ trợ tìm kiếm dựa trên từ khóa, tuy nhiên đặc tả này không loại trừ khả năng mở rộng, cho nên điều cần thiết là định nghĩa cách thức để người dùng có thể gửi các yêu cầu tìm kiếm dịch vụ Web dựa trên ngữ nghĩa đến UDDI registry

Một vấn đề cần giải quyết nữa là UDDI registry phải cung cấp giải thuật tìm kiếm hiệu quả khi nhận được yêu cầu tìm kiếm dựa trên ngữ nghĩa Thông tin về ontology mà dịch vụ Web sử dụng sẽ được so trùng với thông tin về ontology mà người dùng cung cấp Các thông tin về ngữ nghĩa của dịch vụ Web cần tìm do người dùng cung cấp sẽ được sử dụng để tìm kiếm các dịch vụ phù hợp

Quy trình xây dựng và sử dụng cơ sở hạ tầng tìm kiếm dịch vụ Web có ngữ nghĩa được minh họa như sau:

Hình 7 Hoạt động của cơ sở hạ tầng tìm kiếm dịch vụ Web có ngữ nghĩa

Phân loại UDDI registry theo

Đăng ký dịch vụ Web có ngữ nghĩa cho UDDI registry tương ứng theo lĩnh vực

UDDI registry hỗ trợ tìm kiếm dựa trên ngữ nghĩa Người dùng gửi yêu cầu tìm kiếm dựa trên ngữ nghĩa

Tìm đúng UDDI registry dựa vào thông tin về domain của yêu cầu tìm kiếm

Tìm các dịch vụ Web dựa vào thông tin về ontology và các chi tiết khác liên quan đến ngữ nghĩa của dịch vụ Web do người dùng cung cấp

Xếp hạng các kết quả dựa vào những tiêu chuẩn do người dùng cung cấp Gửi kết quả

Để phục vụ cho cơ sở hạ tầng tìm kiếm thì các ontology sẽ được lưu chứa trong

repository (xem thêm phần 3.4)

Cách làm này tận dụng những ưu điểm của DAML+OIL trong biểu diễn ngữ nghĩa và thừa hưởng sự chuẩn hóa trong mô tả các dịch vụ Web của WSDL Cách tiếp cận này giống DAML-S ở chỗ cũng dùng DAML+OIL nhưng không phức tạp như DAML-S (DAML-S phải nêu ra cách mô tả các dịch vụ Web riêng), trong khi đó DAML-S lại chưa đạt được độ chuẩn hóa và chưa được áp dụng trên phạm vi toàn cầu như WSDL

Cách làm này giống BPEL ở chỗ cùng dùng WSDL để mô tả các dịch vụ Web, nhưng BPEL lại không có khả năng biểu diễn ngữ nghĩa cho dịch vụ Web mạnh mẽ như của DAML+OIL

3.3 Tổng hợp quá trình Web có ngữ nghĩa

Để tổng hợp quá trình Web có ngữ nghĩa từ nhiều dịch vụ Web thì một yếu tố quan trọng trước tiên là phải biểu diễn tốt ngữ nghĩa của từng dịch vụ Web, vì mỗi dịch vụ Web là một thành phần nguyên tố của quá trình Web Ngữ nghĩa của mỗi dịch vụ Web nên bao gồm:

• Cam kết tuân theo ontology nào (qua ontology ta xác định được dịch vụ Web thuộc domain nào)

• Ngữ nghĩa của dữ liệu nhập

• Ngữ nghĩa của dữ liệu xuất

• Ngữ nghĩa của tiền điều kiện (preconditions) để tiến hành dịch vụ Web Đây là các ràng buộc để dịch vụ Web được thực hiện thành công

• Ngữ nghĩa của kết quả (effect) thực thi dịch vụ Web

• Ngữ nghĩa của tiến trình thực thi dịch vụ Web Phần ngữ nghĩa này cho biết mối tương quan giữa dữ liệu nhập và dữ liệu xuất cũng như ảnh hưởng của tiến trình thực thi dịch vụ Web đến môi trường toàn cục trong đó dịch vụ Web được thực thi

• Ngữ nghĩa trong trường hợp cần rollback dịch vụ Web Phần ngữ nghĩa này chưa từng được đề cập trong các công trình hiện có Trong METEOR-S có đề cập đến tất cả 6 loại ngữ nghĩa trên, chỉ có loại ngữ nghĩa trong trường hợp cần rollback dịch vụ Web là chưa được đề cập

Trong BPEL để tổng hợp quá trình Web từ nhiều dịch vụ Web thì có khái

giao dịch (gồm nhiều dịch vụ Web) bị vi phạm đặc tính ACID (atomic, consistent, isolated, durable)

Tuy nhiên trong BPEL thì compensationHandler chỉ nêu ra sẽ làm gì trong trường hợp giao dịch thất bại chứ không nêu được ngữ nghĩa của việc

rollback từng dịch vụ Web Tác giả đề tài này tin tưởng rằng cần thiết phải mô tả ngữ nghĩa của việc rollback từng dịch vụ Web

Cũng không thể mô tả ngữ nghĩa cho compensationHandler vì compensationHandler có dạng rất chung chung: “nếu thực hiện giao dịch gồm n dịch vụ Web mà thất bại thì rollback các dịch vụ Web đã hoàn tất” Chính vì vậy nếu ta mô tả ngữ nghĩa cho compensationHandler thì sẽ gặp khó khăn là ngữ nghĩa của compensationHandler sẽ khác đi tùy vào số dịch vụ Web đã hoàn tất trước khi giao dịch thất bại Những phân tích này cho thấy mô tả ngữ nghĩa khi rollback dịch vụ Web như một phần ngữ nghĩa của dịch vụ Web là hợp lý nhất

Đây là mở rộng đáng kể trong việc mô tả ngữ nghĩa cho dịch vụ Web của đề tài này so với các công trình hiện có Trong tương lai thì việc sử dụng quá trình Web như một hay nhiều giao dịch là tất yếu, và muốn làm việc trên các giao dịch thì phải xử lý rốt ráo vấn đề rollback Có thể phát biểu như sau:

1 Việc dùng dịch vụ Web có ngữ nghĩa là nhằm thể hiện một cách tường minh ngữ nghĩa của dịch vụ Web như người cung cấp dịch vụ Web mong muốn

2 Việc mô tả ngữ nghĩa khi rollback dịch vụ Web giúp xác định một cách tường minh ngữ nghĩa của việc rollback dịch vụ Web khi dịch vụ Web được dùng như một phần của giao dịch

3 Việc mô tả ngữ nghĩa khi rollback dịch vụ Web là cần thiết để cung cấp

các quá trình Web có ngữ nghĩa thực sự có ngữ nghĩa về việc rollback

một giao dịch bao gồm nhiều dịch vụ Web

4 Việc mô tả ngữ nghĩa khi rollback dịch vụ Web nên được tiến hành tại từng dịch vụ Web

METEOR-S có đề cập đến ba dạng khác nhau của dịch vụ Web mà việc tổng hợp quá trình Web hỗ trợ, đó là

• Giao diện của dịch vụ Web

• Bản mô tả dịch vụ Web có ngữ nghĩa

Điều này có nghĩa một quá trình Web có thể được tạo ra từ nhiều dịch vụ Web đã có hiện thực cụ thể bằng một ngôn ngữ lập trình nào đó Quá trình Web cũng có thể được tổng hợp từ nhiều giao diện của dịch vụ Web, nghĩa là được tổng hợp từ bất cứ dịch vụ Web nào hiện thực giao diện đề ra

Tuy nhiên chỉ khi quá trình Web được tổng hợp từ các bản mô tả dịch vụ Web có ngữ nghĩa thì quá trình Web mới thực sự có ngữ nghĩa

Những hỗ trợ này của METEOR-S là tốt hơn rất nhiều so với BPEL BPEL chỉ cho phép tạo ra quá trình Web bằng cách tổng hợp các hiện thực cụ thể của dịch vụ Web mà thôi

Ví dụ sau, lấy từ một ví dụ mẫu trong BPWS4J của IBM minh họa cho hạn chế của BPEL Chú ý các dòng số 5, 11, 12, 30, 31 và 32 của tài liệu BPEL Các dòng này quy định rằng quá trình Web được tổng hợp từ dịch vụ Web nằm trong namespace cố định có tên chỉ ra ở dòng 5, kiểu của thông số phục vụ cho hàm getQuote phải có tên cố định là GetQuoteInput và GetQuoteOutput Tên hàm phải cố định là getQuote URL chỉ ra tài liệu chứa các mô tả WSDL của dịch vụ Web này cũng phải cố định Dịch vụ Web này phải là một hiện thực cụ thể trong một ngôn ngữ lập trình nào đó

Tuy nhiên việc tạo quá trình Web bằng cách tổng hợp các hiện thực cụ thể của dịch vụ Web cũng có những linh hoạt nhất định, đó là thứ tự thông số của hàm thay đổi được, thân hàm thay đổi được

Hình 8 Giới hạn của BPEL

Luận văn này cố gắng cung cấp việc tổng hợp quá trình Web từ cả 03 dạng đặc tả khác nhau của dịch vụ Web như trong METEOR-S, với việc thêm vào ngữ nghĩa trong trường hợp cần rollback dịch vụ Web Các chi tiết về thiết kế và hiện thực được trình bày trong phần 3.6 và 3.7

3.4 Repository lưu trữ các thông tin liên quan ở dạng XML

Các ontology, giao diện của dịch vụ Web (dưới dạng WSDL), mô tả dịch vụ Web (dưới dạng WSDL), mô tả dịch vụ Web có ngữ nghĩa (dưới dạng WSDL mở rộng) có thể được lưu trữ riêng biệt trong repository chuyên dùng hoặc lưu trữ trong Web server để người dùng truy xuất dễ dàng, phục vụ việc tìm kiếm và thực thi các quá trình Web Trong giới hạn luận văn này, các thông tin trên được lưu trữ ở Web server

3.5 Khối chức năng phục vụ việc thực thi quá trình Web

Để phục vụ việc thực thi quá trình Web, trong giới hạn luận văn này, BPWS4J được sử dụng BPWS4J cung cấp nền tảng để các quá trình Web mô tả bằng BPEL thực thi được Dữ liệu nhập cho BPWS4J hoạt động bao gồm

• Tài liệu mô tả quá trình Web bằng BPEL

• Tài liệu mô tả giao diện của dịch vụ Web bằng WSDL

• Các tài liệu WSDL mô tả các hiện thực cụ thể của dịch vụ Web mà quá trình Web sẽ sử dụng

Sau khi triển khai, quá trình Web có thể được truy xuất thông qua SOAP Hình ảnh tổng quan về khối chức năng này như sau:

Bản mô tả quá trình Web dùng:

• Giao diện của dịch vụ Web

• Hiện thực cụ thể của dịch vụ Web

Mô tả giao diện của dịch vụ Web (WSDL) Mô tả hiện thực của dịch vụ Web (WSDL)

Bản mô tả quá trình Web dùng:

• Giao diện của dịch vụ Web

• Hiện thực cụ thể của dịch vụ Web

• Mô tả dịch vụ Web có ngữ nghĩa

Mô tả giao diện của dịch vụ Web (WSDL) Mô tả hiện thực của dịch vụ Web (WSDL) Mô tả dịch vụ Web có ngữ nghĩa (WSDL mở rộng)

Luận văn này hỗ trợ

Luận văn này cung cấp cho BPWS4J

4 THIẾT KẾ VÀ HIỆN THỰC HỆ THỐNG

4.1 Thiết kế hệ thống

4.1.1 Mô tả ngữ nghĩa cho dịch vụ Web

Trọng tâm của hệ thống là xây dựng quá trình Web có ngữ nghĩa Để làm được điều này trước tiên cần mô tả ngữ nghĩa cho dịch vụ Web

Các dịch vụ Web hiện được mô tả bằng WSDL Để mô tả ngữ nghĩa cho dịch vụ Web, luận văn này sử dụng cơ chế mở rộng của WSDL nhằm mô tả ngữ nghĩa cho toàn dịch vụ Web và cho từng phương thức của dịch vụ Web

Ngữ nghĩa cho toàn dịch vụ Web được cung cấp thông qua cam kết tuân theo ontology nào Ta quy định dịch vụ Web cam kết tuân theo một ontology nếu trong tài liệu WSDL mô tả dịch vụ Web này có sử dụng một namespace chỉ đến ontology Ví dụ tài liệu WSDL như sau:

Hình 10 Cam kết tuân theo Ontology trong tài liệu WSDL

được xem như cam kết tuân theo ontology SomeDomain.daml Ontology ở đây sử dụng cách thức mô tả như quy định bởi DAML+OIL Namespace

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

<definitions targetNamespace="http://www.sample.com/RealEstateWebService" xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:CommittedOnt=” http://www.sample.com/SomeDomain.daml ” xmlns:SemWebExt=”http://www.nhuanvn.com/SemWebExt”

>

………

</definitions>