Bài giảng Phát triển phần mềm hướng dịch vụ: Phần 2

Nối tiếp phần 1, Bài giảng Phát triển phần mềm hướng dịch vụ: Phần 2 tiếp tục trình bày những nội dung về các mô hình kiến trúc; kiến trúc hướng dịch vụ; Ontology và OWL; công cụ Protégé cho xây dựng OWL; dịch vụ web ngữ nghĩa và OWL-S; khám phá dịch vụ web ngữ nghĩa; lựa chọn dịch vụ web ngữ nghĩa; thiết kế cơ chế khám phá dịch vụ web ngữ nghĩa;... Mời các bạn cùng tham khảo!

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG PHẠM VĂN CƯỜNG, NGUYỄN TRỌNG KHÁNH BÀI GIẢNG PHÁT TRIỂN PHẦN MỀM HƯỚNG DỊCH VỤ HÀ NỘI 2020 CHƯƠNG CÁC MƠ HÌNH KIẾN TRÚC 5.1 KIẾN TRÚC HƯỚNG DỊCH VỤ Phần mô tả trường hợp sử dụng với yêu cầu phức tạp phương pháp tính tốn Các u cầu đáp ứng dễ dàng thơng qua kiến trúc phù hợp với đặc tính thiết yếu trường hợp sử dụng mà người ta gọi kiến trúc hướng dịch vụ (SOA – Service Oriented Architecture) 5.1.1 Các yếu tố kiến trúc hướng dịch vụ Để đạt ưu điểm trên, SOA quy định yêu cầu sau: Kết nối lỏng (Loose coupling) – Khơng có thuộc tính giao dịch chặt chẽ áp dụng thành phần Nói chung, việc xác định tính quán liệu không phù hợp qua nguồn thông tin từ phận thành phần khác Tuy nhiên, điều hợp lý cho mối quan hệ hợp đồng mức cao mà qua tương tác thành phần quy định Tính trung lập cài đặt (Implementation neutrality) - Giao diện quan trọng Chúng ta phụ thuộc vào chi tiết việc triển khai thành phần tương tác Đặc biệt, phương pháp cụ thể cho ngơn ngữ lập trình Khả cấu hình linh hoạt (Flexible configurability) - Hệ thống cấu hình trễ linh hoạt Nói cách khác, thành phần khác ràng buộc với trễ trình Các cấu hình tự động thay đổi Thời gian hoạt động dài (Long lifetime) - Không thiết phải cần thành phần có thời gian sống lâu Tuy nhiên, xử lý tính tốn thành phần khơng đồng tự trị môi trường động nên cần đến khả xử lý trường hợp ngoại lệ Điều có nghĩa thành phần phải tồn đủ lâu để phát trường hợp ngoại lệ có liên quan, để có hành động sửa sai, để đáp ứng với hành động khắc phục thực thành phần khác Các thành phần phải tồn đủ lâu để khám phá, dựa vào, để tạo niềm tin hành vi Mức độ chi tiết (Granularity) – Các bên tham gia SOA nên hiểu mức thơ Đó là, thay mơ hình hóa hành động tương tác mức độ chi tiết, tốt để nắm bắt giá trị cao cấp cần thiết cho thấy mục đích hợp đồng kinh doanh thành viên tham gia Mức thô giúp giảm phụ thuộc thành viên tham gia làm giảm thông tin cần liên lạc, cần tập trung với vài thơng điệp có ý nghĩa Các nhóm (teams) - Thay đóng khung tính tốn cách tập trung, tốt suy nghĩ cách thức tính tốn thực bên tự trị Nói cách khác, thay bên tham gia huy đối tác mình, tính tốn hệ thống mở nên vấn đề đối tác kinh doanh làm việc nhóm Đó là, thay bên riêng lẻ, nhóm bên tham gia hợp tác mơ hình tốt 56 5.1.2 So sánh lời gọi thủ tục từ xa (RPC) với định hướng tài liệu (OD) Có hai khung nhìn dịch vụ Web Các dịch vụ hiểu theo khung nhìn RPC làm trung tâm tài liệu làm trung tâm Khung nhìn thứ xem dịch vụ việc đưa tập phương pháp gọi từ xa, nghĩa là, thông qua gọi thủ tục từ xa Khung nhìn sau coi dịch vụ việc trao đổi tài liệu với Trong hai khung nhìn, truyền tài liệu XML tính tốn đối tượng dựa tương ứng với tài liệu XML Tuy nhiên, có khác biệt quan trọng khái niệm Khung nhìn RPC xem tài liệu XML liên quan đến việc tính tốn phân phối tổng thể Các tài liệu đơn biểu diễn (serialization) đối tượng kinh doanh dùng để tính tốn Khung nhìn coi tài liệu làm trung tâm coi tài liệu biểu diễn (representation) mục đích tính toán phân tán Mỗi thành phần đọc, tạo, lưu, truyền tài liệu Các tài liệu tạm thời thực hóa thành đối tượng kinh doanh phép tính tốn Khung nhìn RPC tương ứng với dịch vụ gỗ dán mỏng dịch vụ Web ứng dụng có Ứng dụng định tính dịch vụ hỗ trợ Khung nhìn tài liệu xem xét dịch vụ Web tự nhiên hơn, coi phương tiện thực mối quan hệ kinh doanh Các văn phải xử lý (và mối quan hệ chúng) xác định chức dịch vụ Các đối tượng kinh doanh khơng lộ cho phía bên biết Vì lý này, khung nhìn tài liệu làm trung tâm hợp lý với trường hợp sử dụng việc sử dụng dịch vụ mơi trường mở Khung nhìn RPC hợp lý cho trường hợp sử dụng làm cho ứng dụng phát triển liên tác độc lập Những xảy nhà phát triển ứng dụng thể giao diện ứng dụng họ hình thức dịch vụ Web, sau bị ràng buộc theo cách thông thường Nếu ứng dụng thiết kế hỗ trợ tích hợp phương thức, khung nhìn RPC dịch vụ hợp lý cho liên tác Tuy nhiên, ứng dụng thiết kế để hoạt động thành phần độc lập, khung nhìn tài liệu hợp lý hơn, liên tác ứng dụng 5.2 KIẾN TRÚC RESTful 5.2.1 Khái niệm Thuật ngữ REST xuất phát từ luận án Tiến sĩ Roy Fielding, xuất năm 2000, viết tắt từ REpresentational State Transfer REST tự khơng phải kiến trúc; REST tập hợp ràng buộc, áp dụng để thiết kế hệ thống, tạo kiểu kiến trúc phần mềm Nếu thực tất nguyên tắc REST, ta tạo hệ thống có vai trị cụ thể liệu, thành phần, siêu liên kết, giao thức truyền thông người tiêu dùng liệu Một hệ thống RESTful tuân thủ ràng buộc sau: • hệ thống máy khách-máy chủ • stateless — dịch vụ không cần lưu trữ phiên người dùng; nói cách khác, yêu cầu phải độc lập với yêu cầu khác 57 • phải hỗ trợ hệ thống nhớ đệm — sở hạ tầng mạng phải hỗ trợ nhớ đệm cấp độ khác • phải đáp ứng truy cập thống — tài nguyên phải có địa điểm truy cập hợp lệ • phải phân lớp — hỗ trợ khả mở rộng • phải cung cấp mã theo yêu cầu — ràng buộc tùy chọn, ứng dụng mở rộng thời gian chạy cách cho phép tải xuống mã theo yêu cầu, ví dụ: Java Applet Những ràng buộc khơng quy định loại cơng nghệ sử dụng; xác định cách liệu truyền thành phần lợi ích việc tuân theo hướng dẫn Do đó, hệ thống RESTful thực kiến trúc mạng có sẵn Quan trọng hơn, không cần phải phát minh công nghệ giao thức mạng mới: sử dụng sở hạ tầng mạng có Web để tạo kiến trúc RESTful Do đó, kiến trúc RESTful kiến trúc bảo trì, mở rộng phân phối Web hệ thống điển hình RESTful, tai lại đưa yêu cầu RESTful vào phát triển ứng dụng web thân Web tuân thủ theo kiến trúc RESTful Trước tiên, cần phải xác định điều kiện đủ để Web trở nên RESTful Về bản, web tĩnh RESTful, trang web tĩnh tuân theo định nghĩa Fielding kiến trúc RESTful Ví dụ: sở hạ tầng web có cung cấp hệ thống nhớ đệm, kết nối không trạng thái siêu liên kết đến tài nguyên, nơi tài nguyên tất tài liệu có sẵn trang web phần trình bày tài liệu thiết lập tệp đọc trình duyệt (tệp HTML, cho thí dụ) Do đó, web tĩnh hệ thống xây dựng theo kiểu kiến trúc giống REST Tuy nhiên, ứng dụng web động truyền thống lúc RESTful, chúng thường phá vỡ số ràng buộc Ví dụ: hầu hết ứng dụng động khơng đáp ứng stateless, máy chủ yêu cầu theo dõi người dùng thông qua chưa phiên cookie phía máy khách Do đó, kết luận web động thường không xây dựng theo kiểu kiến trúc giống REST Trong phần tiếp theo, yếu tố trừu tượng tạo nên hệ thống RESTful giới thiệu, cụ thể tài nguyên, biểu diễn, URI loại yêu cầu HTTP tạo nên giao diện thống sử dụng để truyền liệu máy khách / máy chủ 5.2.2 Tài nguyên biểu diễn tài nguyên Tài nguyên RESTful thứ đánh địa Web Tức là tài nguyên truy cập chuyển máy khách máy chủ Điều dẫn đến tài ngun ánh xạ lơ gíc, theo thời gian tới khái niệm miền toán triển khai giải pháp Dưới số ví dụ tài ngun REST: • Một câu chuyện tin tức 58 • Nhiệt độ NY lúc 4:00 chiều EST • Tờ khai thuế lưu trữ sở liệu IRS • Danh sách lịch sử sửa đổi mã kho lưu trữ SVN CVS • Một học sinh lớp học trường • Kết tìm kiếm cho mục cụ thể mục web, chẳng hạn Google Mặc dù ánh xạ tài nguyên nhất, số trường hợp yêu cầu khác tài nguyên trả biểu diễn nhị phân lưu trữ máy chủ Ví dụ: giả sử có tài nguyên ngữ cảnh hệ thống xuất Sau đó, yêu cầu "bản sửa đổi xuất bản" yêu cầu "bản sửa đổi số 12" thời điểm trả đại diện tài nguyên: sửa đổi cuối sửa đổi 12 Tuy nhiên, sửa đổi xuất tăng lên đến phiên 13, yêu cầu sửa đổi trả phiên 13 yêu cầu sửa đổi 12 tiếp tục trả phiên 12 Vì tài nguyên kiến trúc RESTful, tài nguyên truy cập trực tiếp độc lập, yêu cầu khác trỏ với liệu Bởi HTTP sử dụng để giao tiếp, ta chuyển loại thơng tin truyền máy khách máy chủ Ví dụ: yêu cầu tệp văn từ Vnexpress, trình duyệt nhận tệp văn Nếu yêu cầu phim Flash từ YouTube, trình duyệt nhận phim Flash Dữ liệu truyền trực tuyến hai trường hợp qua TCP / IP trình duyệt biết cách diễn giải luồng nhị phân thông qua trường Content-Type phần Header HTTP Do đó, hệ thống RESTful, việc biểu diễn tài nguyên phụ thuộc vào kiểu mong muốn người gọi (kiểu MIME), định yêu cầu giao thức truyền thông Biểu diễn tài nguyên gửi qua lại máy khách máy chủ Biểu diễn trạng thái tạm thời liệu thực tế nằm số thiết bị lưu trữ thời điểm yêu cầu Nói chung, luồng nhị phân với siêu liệu mơ tả cách mà máy khách máy chủ sử dụng luồng (siêu liệu chứa thơng tin bổ sung tài ngun, ví dụ: xác thực, thơng tin mã hóa mã bổ sung thực thi thời gian chạy) Trong suốt vòng đời dịch vụ web, có nhiều khách hàng yêu cầu tài nguyên Các máy khách khác sử dụng đại diện khác tài nguyên Do đó, biểu diễn có nhiều dạng khác nhau, chẳng hạn hình ảnh, tệp văn luồng XML luồng JSON, phải có sẵn thơng qua URI Đối với yêu cầu người tạo thơng qua trình duyệt web, biểu diễn thường dạng trang HTML Đối với yêu cầu tự động từ dịch vụ web khác, khả đọc khơng quan trọng sử dụng biểu diễn hiệu XML 5.2.3 URI Mã định danh tài nguyên đồng nhất, Uniform Resource Identifier - URI, dịch vụ web RESTful siêu liên kết đến tài nguyên phương tiện để máy khách máy chủ trao đổi biểu diễn 59 Các ràng buộc RESTful không quy định URI phải siêu liên kết Ở RESTful URI siêu liên kết, ta sử dụng Web để tạo dịch vụ web Nếu sử dụng công nghệ hỗ trợ khác, URI RESTful khác Trong hệ thống RESTful, URI không thay đổi theo thời gian, chất kiến trúc để quản lý dịch vụ, định vị tài nguyên, dàn xếp biểu diễn sau gửi lại phản hồi với tài nguyên yêu cầu Quan trọng hơn, ta thay đổi cấu trúc thiết bị lưu trữ cấp máy chủ (ví dụ: hốn đổi máy chủ sở liệu), URI giữ nguyên nguyên giá trị, miễn dịch vụ web trực tuyến ngữ cảnh tài ngun khơng thay đổi Khơng có ràng buộc REST, tài nguyên truy cập qua vị trí: địa web điển hình URI cố định Ví dụ: ta đổi tên tệp máy chủ web, URI khác; ta di chuyển tệp sang thư mục khác máy chủ web, URI thay đổi Lưu ý ta sửa đổi máy chủ web để thực chuyển hướng thời gian chạy nhằm trì khả định địa chỉ, thay đổi tất tệp, quy tắc quản lý 5.2.4 Giao diện đồng qua yêu cầu HTTP Trong phần trước, khái niệm tài nguyên biểu diễn tài nguyên giới thiệu Trong đó, tài nguyên ánh xạ trạng thái thực thể trao đổi máy khách máy chủ Ngoài ra, biểu diễn tài nguyên vận chuyển qua lại máy khách máy chủ thông qua giao thức truyền thông thời gian chạy —qua HTTP Trong phần này, ý nghĩa việc trao đổi biểu diễn ý nghĩa việc máy khách máy chủ thực hành động tài nguyên xem xét chi tiết Việc phát triển dịch vụ web RESTful tương tự làm để phát triển ứng dụng web điển hình Tuy nhiên, khác biệt phát triển ứng dụng web đại truyền thống cách hành động thực liệu trừu tượng Cụ thể, phương pháp phát triển đại bắt nguồn ngữ nghĩa danh từ (trao đổi tài nguyên); kiểu cũ bắt nguồn ngữ nghĩa động từ (hành động từ xa thực liệu) Phương pháp đai triển khai dịch vụ web RESTful; kiểu cũ triển khai dịch vụ tương tự RPC (lời thủ tục từ xa) Ngoài ra, dịch vụ RESTful sửa đổi trạng thái liệu thông qua biểu diễn tài nguyên; dịch vụ RPC ẩn phần biểu diễn liệu thay vào gửi lệnh để sửa đổi trạng thái liệu cấp độ máy chủ (không biết liệu trông nào) Cuối cùng, phát triển ứng dụng web đại, mơ hồ thiết kế triển khai hạn chế, có bốn hành động thực tài nguyên — Tạo, Truy xuất, Cập nhật Xóa (CRUD) Cịn phát triển ứng dụng web truyền thống, có vơ số hành động khơng tên khơng có tiêu chuẩn triển khai Do đó, với vai trị phân định cho tài nguyên biểu diễn tài nguyên, hành động CRUD ánh xạ với phương thức HTTP POST, GET, PUT DELETE sau: Hành động Giao thức HTTP tương đương TẠO POST 60 LẤY GET CẬP NHẬT PUT XÓA DELETE Ở dạng đơn giản nhất, dịch vụ web RESTful ứng dụng nối mạng điều khiển trạng thái tài nguyên Trong ngữ cảnh này, thao tác tài nguyên có nghĩa tạo, truy xuất, cập nhật xóa tài nguyên Tuy nhiên, dịch vụ web RESTful không giới hạn bốn khái niệm thao tác liệu Ngược lại, dịch vụ web RESTful thực thi logic cấp máy chủ, cần nhớ kết phải biểu diễn tài nguyên Phần chi tiết hóa hành động giao thức HTTP tương ứng 5.2.4.1 Phương thức GET – Nhận Tài nguyên Phương thức GET sử dụng để NHẬN tài nguyên Trước sâu vào chế yêu cầu HTTP GET r equest, ta cần xác định tài nguyên ngữ cảnh dịch vụ web loại biểu diễn mà trao đổi Phần tiếp sử dụng ví dụ dịch vụ web với tác vụ liên quan đến sinh viên lớp học, vị trí http://restfuljava.com/ Giả sử ta có biểu diễn XML sinh viên sau: Jane 10 /students/Jane And a list of students to look like: Jane 10 /students/Jane John 11 /students/John /students Giả sử URI có dạng http://restfuljava.com/students cho phép truy cập danh sách sinh viên http://restfuljava.com/students/{name} để truy cập sinh viên cụ thể có định danh thông qua giá trị name 61 Bây ta gửi yêu cầu tới dịch vụ web Ví dụ: muốn hồ sơ sinh viên có tên Jane, yêu cầu gửi tới URI http://restfuljava.com/students/Jane Biểu diễn Jane, thời điểm yêu cầu, sau: Jane 10 /students/Jane Tương tự, danh sách sinh viên truy cập thông qua URI http://restfuljava.com/students Phản hồi từ dịch vụ bao gồm biểu diễn tất sinh viên sau (giả sử có hai sinh viên có sẵn): Jane 10 /students/Jane John 11 /students/John /students Đi sâu vào chi tiết yêu cầu ta thấy, yêu cầu truy xuất tài nguyên Jane sử dụng phương thức GET với URI http://restfuljava.com/students/Jane Biểu đồ trình tự yêu cầu GET ta trơng sau: Hình 5-1 Sơ đồ tương tác sử dụng phương thức GET 62 Trình tự thực hiên bao gồm: 1) Ứng dụng khách Java đưa yêu cầu HTTP với phương thức GET Jane định danh cho sinh viên 2) Máy khách đặt kiểu biểu diễn mà xử lý thơng qua trường Accept tiêu đề yêu cầu 3) Máy chủ web nhận diễn giải yêu cầu GET hành động truy xuất tài nguyên Tại thời điểm này, máy chủ web chuyển quyền kiểm soát cho tảng RESTful để xử lý yêu cầu Lưu ý tảng RESTful không tự động truy xuất tài nguyên Nền tảng RESTful hỗ trợ làm dễ dàng việc thực ràng buộc REST Logic nghiệp vụ thực thi việc lưu trữ vai trò mã Java 4) Chương trình phía máy chủ tìm kiếm tài ngun Jane Tìm tài ngun tìm sở liệu, hệ thống tệp lệnh gọi đến dịch vụ web khác 5) Khi chương trình tìm thấy Jane, chuyển đổi liệu nhị phân tài nguyên thành biểu diễn yêu cầu khách hàng 6) Với biểu diễn chuyển đổi sang XML, máy chủ gửi lại phản hồi HTTP với mã số 200 với biểu diễn XML tải trọng Lưu ý có lỗi nào, máy chủ HTTP báo cáo lại mã lỗi thích hợp Tất thông điệp máy khách máy chủ lời gọi theo giao thức HTTP tiêu chuẩn Đối với hành động truy xuất, yêu cầu GET gửi client nhận phản hồi HTTP trở lại với tải trọng phản hồi biểu diễn tài nguyên có lỗi, mã lỗi HTTP tương ứng (ví dụ: 404 tài ngun khơng tìm thấy; 500, có vấn đề với mã Java dạng ngoại lệ) Lấy biểu diễn tất sinh viên hoạt động giống cách lấy biểu diễn cho sinh viên riêng lẻ, ta sử dụng URI http://restfuljava.com/students kết biểu diễn XML: Jane 10 /students/Jane John 11 /students/John 63 /students Phương thức HTTP GET nên sử dụng để truy xuất biểu diễn tài nguyên Mặc dù yêu cầu GET sử dụng để cập nhật trạng thái liệu máy chủ, điều không khuyến khích u cầu GET phải an tồn hợp lý Để yêu cầu an toàn, tức nhiều yêu cầu đến tài nguyên không thay đổi trạng thái liệu máy chủ Giả sử có biểu diễn R yêu cầu xảy thời điểm t Sau đó, yêu cầu thời điểm t1 cho tài nguyên R trả R1; sau đó, yêu cầu thời điểm t2 cho tài nguyên R trả R2; miễn khơng có hành động cập nhật thực khoảng thời gian từ t1 đến t2, R1 = R2 = R 5.2.4.2 Phương thức POST – Tạo tài nguyên Các phương thức POST sử dụng để TẠO tài nguyên Để tạo sinh viên, ta sử dụng phương thức HTTP POST URI để tạo sinh viên danh sách http://restfuljava.com/students/Jane Loại phương thức cho yêu cầu thiết lập máy khách Giả sử Jane không tồn danh sách có Biểu diễn XML Jane thể sau: Jane 10 Lưu ý phần tử liên kết phần biểu diễn, trống giá trị tạo thời gian chạy không tạo ứng dụng khách gửi yêu cầu POST Đây quy ước cho ví dụ này; nhiên, ứng dụng khách sử dụng dịch vụ web định cấu trúc URI Sơ đồ trình tự yêu cầu POST sau: 64 Bước tạo đồ thị biểu diễn mối liên hệ tiến trình Trong trường hợp này, dịch vụ cần tạo đơn giản nên đồ thị hiển thị dạng hình 6.11 Hình 6.11: Đồ thị tiến trình Tiếp theo ta định nghĩa luồng liệu Trong trường hợp đầu tiến trình SearchFlight FlightItineraries (các hành trình chuyến bay) đầu vào tiến trình SelectFlight Trong cac trường hợp khác ví dụ tiến trình tiến trình phức hợp luồng liệu cần đươc xác định cho tiến trình Để xây dựng luồng liệu tham số cần rang buộc (binding) giá trị liệu, giá trị nguồn (dữ liệu từ đâu) giá trị hàm Ta phải thêm câu lệnh SearchFlightPerform hay SelectFlightPerform để tạo giới hạn cho khoảng giá trị tham số đầu vào Bộ soạn thảo OWL-S tự động tạo biểu diễn luồng liệu đồ thị tiến trình Để vẽ lại đồ thị tiến trình, nút đồ thị phải khóa lại đồ thị với nút mầu vàng chữ mầu xanh thể luồng liệu Hình 6.12 luồng liệu cho dịch vụ BravoAir 105 Hình 6.12: Luồng điều khiển liệu Bước tiếp đến tạo OWL-grounding cho dịnh vụ Trước hết ta cần tạo grounding có tên BravoAirSearchFlightGrounding cho tiến trình SearchFlight, biến thể grounding grounding:WSDLAtomicProcessGrounding Tương tự tiến trình SelectFlight MakeReservation Hình 6.13: groundings cho tiến trình dịch vụ BravoAir Bước tạo OWL-S profile cho dịnh vụ Đầu tiên ta cần lựa chọn tham số cho profile thường tập tất tham số đầu vào đầu tiến trình Việc định người thiết kế dịch vụ lựa chọn tham số xuất profile dịch vụ Trong ví dụ ta sử dụng tất tham số định nghĩa ngoại 106 trừ tham số nội FlightItineraries Kết tham số profile trình bầy hình 6.14 Hình 6.14: Các tham số profile dịch vụ Bước cuối tạo dịch vụ đặt tên cho Sau liên kết dịch vụ vừa tạo với profile, tiến trình grounding mà ta tạo bước trước Ta cần phái gán biến thể với thuộc tính thích hợp Chẳng hạn, biến thể BravoAir_Profile cần có thuộc tính service:presents, BravoReservationFlight gán cho service:describedBy, hay BravoAir_Grounding gán cho service:supports 7.5 BÀI TẬP Hãy xây dịch vụ Web sử dụng công cụ Protégé plug-in OWL-S để cung cấp dịch vụ tra cứu điểm môn học học kỳ cho sinh viên đại học Cơ sở liệu sinh viên cần tạo hệ quản trị sở liệu bạn lựa chọn (như SQL server, MS Access, MySQL v.v ) Cơ sở liệu có bảng chứa thơng tin sinh viên như: mã sinh viên, họ tên sinh viên, học kỳ (học kỳ mấy?), danh sách môn học theo học kỳ điểm trung bình mơn học Trong dịch vụ Web có phương thức Tracuu với tham số đầu vào mã sinh viên học kỳ; phương thức trả tên sinh viên, danh sách môn học điểm môn theo học kỳ Học viên yêu cầu phát triển ứng dụng phía client để gọi đến (invoke) phương thức Tracuu hiển thị thông tin trả dạng bảng Học viên yêu cầu tuân thủ bước ví dụ quản lý đặt chỗ cho chuyến bay mục 6.4 107 CHƯƠNG KHÁM PHÁ DỊCH VỤ WEB NGỮ NGHĨA 8.1 KHÁM PHÁ DỊCH VỤ WEB NGỮ NGHĨA Khám phá dịch vụ Web ngữ nghĩa trình xác định vị trí mà dịch vụ web tồn dựa vào biểu diễn ngữ nghĩa chức phi chức dịnh vụ web Tình khám thường xảy ta cố gắng sử dụng chức (function) dịch vụ web lúc ta xây dựng tiến trình kinh doanh nâng cấp tiến trình kinh doanh có Cả hai cách tiếp cận tính tốn hướng dịch vụ dịch vụ web ngữ nghĩa giaỉ vấn đề Khám phá dịch vụ thực theo nhiều cách khác tùy thuộc vào tảng biểu diễn dịch vụ, công cụ lựa chọn dịch vụ, cách thức kết hợp với Nhìn chung, tảng khám phá dịch vụ cần có thành phần sau: § § § 8.2 Biểu diễn dịch vụ: Các công cụ hình thức để mơ tả ngữ nghĩa chức phi chức dịnh vụ web Lựa chọn dịch vụ: Các chế suy diễn để đối sánh dịch vụ (service matching), cặp đối sánh dựa biểu diễn dịch vụ: truy vấn (query), xếp hạng (ranking), ộ tương đồng phần hay toàn phép đối sánh Kiến trúc khám phá: Bao gồm mơi trường giả định hình trạng mạng (network topology) không tập trung (decentralized) hay tập trung (centralized), lưu trữ thông tin dịch vụ, chế xác định vị trí, vai trị tác tử (là yêu cầu dịch vụ, cung cấp dịch vụ chuyển tiếp dịch vụ) THIẾT KẾ CƠ CHẾ KHÁM PHÁ DỊCH VỤ WEB NGỮ NGHĨA Đối sánh dịch vụ ngữ nghĩa xác định xem ngữ nghĩa dịch vụ có tuân thủ quảng bá (advertised) hay khơng Đây vấn đề cốt lõi tảng khám phá dịch vụ Web ngữ nghĩa Các cách tiếp cận đối sánh ngữ nghĩa dịch vụ phân làm hai loại theo: § § Loại phần ngữ nghĩa dịch vụ xem xét đối sánh, và: Cách thức đối sánh thực Trong phần ta tìm hiểu kiến trúc chế khám phá ngữ nghĩa dịch vụ thuật toán đối sánh ngữ nghĩa dịch vụ 8.2.1 Kiến trúc chế khám phá Các kiến trúc chế khám phá ngữ nghĩa dịch vụ phân thành hai loại: tập trung không tập trung minh họa hình 7.1 Cách phân loại dựa cách thức lưu trữ thông tin xác định vị trí ngữ nghĩa dịch vụ Các hệ thống khám phá dịch vụ tập trung dựa dịch vụ danh bạ toàn cục (nhưng thay thế) trì tác tử tác tử đối sánh (matchmaker), mơi giới hịa giải 108 Ngược lại hệ thống khám phá dịch vụ không tập trung dựa lưu trữ thông tin phân tán nhiều dạng mạng ngang hàng: mạng có cấu trúc, mạng phi cấu trúc mạng lai Hình 7.1: Kiến trúc tập trung không tập trung chế khám phá ngữ nghĩa dịch vụ [2] Các hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc tập trung: Trong hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc tập trung, danh bạ dịch vụ tập trung tác tử đối sánh trả danh sách nhà cung cấp dịch vụ tương ứng ngữ nghĩa cho người yêu cầu Ngược lại với chế xử lý tập trung client-server phần mềm trung gian môi giới, người yêu cầu dịch vụ tương tác trực tiếp với nhà cung cấp lựa chọn cho việc cung cấp dịch vụ Ưu điểm danh bạ dựa kiến trúc tập trung quản lý tài nguyên hiệu thời gian tìm kiếm nhanh, máy chủ tìm kiếm tập trung hay đăng kí JINI giao diện đăng kí CORBA ORB điểm Một ứng dụng danh bạ dịch vụ tập trung hệ thống chia sẻ file âm nhạc Napster, hệ thống SETI@home tận dụng tài nguyên phân tán khổng lồ mạng cho việc xử lý tìm kiếm Theo cách nhìn khám phá ngữ nghĩa dịch vụ Web, tác tử đối sánh ngữ nghĩa dịch vụ web tự hệ thống ngữ nghĩa dịch vụ web theo kiến trúc tập trung Ví dụ hệ thống dịch vụ chăm sóc sức khỏe điện tử SCALLOPS e-health sử dụng tác tử đối sánh OWLS-MX dịch vụ tập trung để lựa chọn y tế điện tử phù hợp cho trường hợp cấp cứu Các hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc không tập trung: 109 Các hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc không tập trung dựa chế lưu trữ thông tin xác định vị trí mạng ngang hàng Các mạng ngang hàng chia thành loại: có cấu trúc, phi cấu trúc mạng lai Các hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc không tập trung dựa mạng ngang hàng có cấu trúc khơng có máy chủ danh bạ trung tâm lại có số lượng lớn hình trạng mạng (topology điều khiển cách chặt chẽ Các tài nguyên không đặt cách ngẫu nhiên hay danh bạ trung tâm mà phân phát theo nhu cầu xử lý yêu cầu từ người dùng Nói cách khác số dịch vụ hệ thống phân tán tới mạng ngang hàng theo cách trải dàn (overlay) có cấu trúc phụ thuộc vào nội dung xác định phân tán sử dụng cho định tuyến tới điểm có yêu cầu (point queries) Ngược lại, hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc không tập trung dựa mạng ngang hàng phi cấu trúc lại khơng có số hay việc điều khiển xác hình trạng mạng mà file lưu trữ dựa tri thức hình trạng mạng Có nghĩa việc định tuyến tài nguyên theo yêu cầu không bị hạn chế danh bạ dịch vụ mà chúng thực Các hệ thống khám phá ngữ nghĩa dịch vụ dựa kiến trúc không tập trung dựa mạng ngang hàng lai (hybrid P2P) kết hợp hai chế xác định vị trí có cấu trúc khơng có cấu trúc Nghĩa với việc định tuyến số dịch vụ phát tán hiệu tài nguyên mạng 8.2.2 Các thuật toán đối sánh Dưới số thuật toán đối sánh ngữ nghĩa dịch vụ (semantic service matching); Phân loại thuật toán đối sánh ngữ nghĩa dịch vụ trình bầy hình 7.2 Trong hình vẽ thuật tốn đối sánh có thê chia thành hai nhóm: nhóm thứ là: đối sánh ngữ nghĩa dịch vụ dựa phi lo gic (non-logic), logic lai (hybrid); nhóm thứ hai đối sánh ngữ nghĩa dịch vụ dựa profile mơ hình process 110 Hình 7.2: Phân loại thuật toán đối sánh ngữ nghĩa dịch vụ [2] Đối sánh ngữ nghĩa dịch vụ dựa lô gic: Đối sánh ngữ nghĩa dịch vụ dựa logic thực phép suy diễn logic ngữ nghĩa dịch vụ Thuật toán tập trung vào so sánh ngữ nghĩa hình thức theo cặp dịch vụ Các khái niệm lo gic hay luật suy diễn sử dụng để định nghĩa ngữ nghĩa đặc tả thể coi lý thuyết suy diễn cấp (first-order) suy diễn dựa luật (rule-base) tập từ vựng tối thiểu Các thể khác nhà cung cấp dịch vụ người yêu cầu dịch vụ phải đối sánh khoảng thời gian thiết kế, hay thời gian chạy phần có q trình đối sánh Các cấp độ đối sánh (matching degrees) cặp dịch vụ ngữ nghĩa xác định cách suy diễn logic kết hợp suy diễn lo gic với việc thực thuật tốn khác (khơng có suy diễn lo gic) Các cấp độ đối sánh thường dùng xác (exact), plugin, gộp vào (subsume), phép tách (disjoin) mà xác định khác dựa vào phần ngữ nghĩa dịch vụ kiểu lý thuyết logic sử dụng để tính tốn chúng Đối sánh ngữ nghĩa dịch vụ dựa phi lơ gic: Như trình bầy trên, đối sánh ngữ nghĩa dịch vụ dựa phi lô gic không thực phép suy diễn logic ngữ nghĩa dịch vụ Thay vào đó, chúng tính độ đối sánh ngữ nghĩa với cặp biểu diễn dịch vụ cho trước Chẳng hạn, để đo độ tương tự cú pháp, đối sánh đồ thị có cấu trúc, hay phép tính khoảng cách khái niệm dạng số thể cho trước Có nhiều độ đo tương tự hai văn từ lĩnh vực nghiên cứu trích xuất thông tin (information retrieval), khai phá mẫu xấp xỉ, hay gom nhóm liệu (data clustering) từ data mining, hay xếp hạng từ khóa, tìm kiếm tài liệu XML có cấu trúc với XQuery v.v Nói chung đối sánh ngữ nghĩa dịch vụ dựa phi lô gic tận dụng ngữ nghĩa ngầm định (implicit) bên Ví dụ từ mẫu (pattern), đố thị (subgraph), hay tần suất tương đối (relative frequency) sử dụng nhiều biểu diễn dịch vụ, khai báo IOPE mô tả rõ ràng (explicitly) lo gic Đối sánh ngữ nghĩa profile dịch vụ dựa phương pháp lai (Hybrid Semantic Profile Matching) Các kỹ thuật đối sánh cú pháp mục tiêu cho việc phát triển giải pháp đối sánh ngữ nghĩa profile dịch vụ dựa phương pháp lai kết hợp đối sánh dựa lo gic phi lo gic đối sánh dựa lo gic phi lo gic không đáp ứng yêu cầu Nhiều thực nghiệm đánh giá phương pháp đối sánh lai cho kết tốt nhiều so với phương pháp đối sánh dựa lo gic phi lo gic điều kiện Đối sánh ngữ nghĩa mơ hình process dịch vụ dựa lơ gic: Đối sánh ngữ nghĩa mơ hình process dịch vụ nhìn chung khơng thơng dụng không chủ ý nhà thiết kế biểu diễn ngữ nghĩa dịch vụ Web Bên cạnh ngữ nghĩa mơ hình process OWL-S hay WSDL chưa định nghĩa cách hình thức Đây vấn đề mà giải phần cách viết lại biểu diễn mơ hình process theo lơ gic thích hợp với hệ thống tự động chứng minh với công cụ hỗ trợ phân tích 111 Đối sánh ngữ nghĩa mơ hình process dịch vụ dựa phi lô gic lai: Đối sánh ngữ nghĩa mơ hình process dịch vụ dựa phi lơ gic thích hợp áp dụng để biến đổi cặp ngữ nghĩa mơ hình process dịch vụ web Chẳng hạn, cách tiếp cận để đối sánh đồ thị phụ thuộc tiến trình dựa độ đo tương tự cú pháp phép lai Phép đệ qui so sánh đồ thị phụ thuộc mô hình tiến trình dựa nhiệm vụ luồng công việc đối sánh lo gic tham số vào/ra nút đồ thị biểu diễn tiến trình dịch vụ Nói cách khác, đối sánh tiến trình dịch vụ theo chức tận dụng để tìm kiếm tập dịch vụ dịch vụ phức hợp 8.2.3 Chi tiết cài đặt Trong mục giới thiệu crawler thiết kế để rút trích nội dung web ngữ nghĩa Slug Slug crawler mã nguồn mở Java download địa chỉ: http://www.ldodds.com/projects/slug/ Slug cho phép người dùng đặt cấu hình cách mềm dẻo cho thao tác: rút trích, xử lý lưu trữ nội dung dịch vụ web ngữ nghĩa cách sửa tham số file cấu hình Hơn nữa, slug cung cấp từ vựng RDF để mơ tả cấu hình crawler thu thập siêu liệu liên quan đến hoạt động crawling Các siêu liệu crawler cho phép báo cáo phân tích q trình crawling việc trích rút thông tin hiệu thông qua lưu trữ vào vùng đệm (caching) HTTP a Cài đặt crawler mô tả dịch vụ web ngữ nghĩa Trước hết cần download địa (phiên alpha-2); sau tiến hành cài đặt Giải nén thư mục home Thư mục \slug chứa tất file code file cấu hình Bạn nên tạo thư mục biến môi trường $SLUG_HOME để tham chiếu đến slug cập nhật đường dẫn vào biến PATH JVM Java 1.5 trở nên cần cài trước Sau đó, bạn cần cài Apache Ant để build code Bước cuối thiết lập cấu hình file config b Cài đặt kho chứa mô tả dịch vụ web ngữ nghĩa Việc cài đặt kho chứa mô tả dịch vụ web slug ta thiết lập từ file cấu hình, cụ thể ta edit nội dung đoạn mã XML file cấu hình (hình 7.3) Bên cạnh ta thiết lập thơng tin sau: § Số luồng chạy đồng thời trích rút liệu § Vị trí đặt kho chứa mơ tả dịch vụ web, § Thành phần xử lý rút trích liệu § Crawler sử dụng lọc để tìm URL 112 A Scutter that includes writing incoming data into a persistent memory Note that the memory is different to that holdings Scutter persistent state.10 Hình 7.3: Cấu hình kho chứa mơ tả dịch vụ web ngữ nghĩa 113 CHƯƠNG LỰA CHỌN DỊCH VỤ WEB NGỮ NGHĨA 9.1 KHÁI NIỆM LỰA CHỌN DỊCH VỤ Lựa chọn dịch vụ bắt đầu với khám phá dịch vụ Để dịch vụ sử dụng cần phải khám phá người dùng cần có trao đổi (correspondence) tương ứng thiết lập mục tiêu người dung khả đáp ứng dịch vụ Một ứng dụng không cần phải khám phá tất dịch vụ đối sánh với tập yêu cầu, chí với lời giải tối ưu nhất, cần tìm lời giải đủ tốt theo nghĩa đặc tính chất lượng Bằng việc dựa khám phá đáp ứng yêu cầu đặc tả chất lượng dịch vụ (QoS) Ta giảm kết trung gian khơng thích hợp, giảm chi phí tính tốn cho việc khám phá Lựa chọn dịch vụ tiếp cận từ quan điểm: § Người dùng tìm kiếm nhà cung cấp tiềm § Nhà cung cấp tìm kiếm người dùng tiềm § Mơi giới tìm kiếm người dùng nhà cung cấp phiên đấu giá hay SoCom Cả quan điểm hưởng lợi từ việc biểu diễn ngữ nghĩa chất lượng thuộc tính Nhắc lại u cầu chức dịch vụ làm (vi dụ: IOPE OWL-S) yêu cầu phi chức chất lượng dịch vụ (độ tin cậy, tính sẵn sàng) Những biểu diễn tốt dựa thể sử dụng cho yêu cầu chức phi chức Người dùng nhận nhiều gợi ý dịch vụ thỏa mãn gần thỏa mãn yêu cầu họ họ cần phải lựa chọn dịch vụ thích hợp nhiều dịch vụ khác Việc cần sử dụng thêm nhiều tiêu chuẩn khác nữa, ví dụ: lựa chọn dịch vụ in ấn giá rẻ hay cần thêm thông tin bên thứ ba danh tiếng dịch vụ in Hay chí thương lượng với dịch vụ để xem xét dịch vụ phù hợp thỏa mãn yêu cầu 9.2 LỰA CHỌN DỰA TRÊN ĐỐI SÁNH NGỮ NGHĨA Khám phá ngữ nghĩa dịch vụ khả thi tập biểu diễn ngữ nghĩa, tương tự việc quảng bá giới vật chất Các biểu diễn WSDL dùng cho việc quảng bá (ví dụ: cho phép thực lời gọi phiên demo dịch vụ web), thiếu ngữ nghĩa cho thuộc tính chức khơng đặc tả thuộc tính phi chức Các quảng cáo thực tế sống (như cung cấp dịch vụ điện thoại đường dài, giá rẻ) diễn tả ngôn ngữ lo gic hình thức ví dụ thú vị biểu diễn ngữ nghĩa khả dịch vụ Các biểu diễn ngữ nghĩa tạo nhà cung cấp dịch vụ bên thứ ba Nhưng bên thứ ba thường tạo biểu diễn dịch vụ mà không cung cấp biểu diễn Chẳng hạn, có nhiều trang web khách sạn, hầu hết biểu diễn ngữ nghĩa nội dung dịch vụ web không cung cấp internet Một đaị lý dịch vụ du lịch chọn để cung cấp biểu diễn trang web mà khách hàng 114 đại lý sử dụng Các biểu diễn tạo theo yêu cầu dịch vụ Chúng bảo trì máy tính cục bộ, lưu giữ bên thứ ba, gửi cho tác tử đối sánh trung gian, lưu trữ điểm đăng ký tập trung Điều hàm ý đối sánh ngữ nghĩa phức tạp việc biểu diễn ngữ nghĩa phong phú (richer) Nói cách khác, biểu diễn phong phú cho phép lựa chọn xác Về phía khách hàng, mục tiêu đại lý phải mơ tả ngơn ngữ hình thức Mục đích việc đối sánh tìm dịch vụ đủ tốt tương tự mục tiêu người dùng khả đáp ứng dịch vụ mà quảng cáo Nhìn chung, đối sánh thường xác định bới thuật toán heuristic với thể đặc tả thuật ngữ sử dụng quảng cáo biểu diễn mục tiêu đại lý Có hai cách tiếp cận chung cho đối sánh ngữ nghĩa dịch vụ rõ ràng (explicit) ngầm định (implicit) Tưởng tượng dịch vụ chứng khoán dùng kí hiệu thị trường chứng khốn New York đại diện cho tên cơng ty Ví dụ “IBM” trả lại thơng tin lược đồ q trình làm ăn cơng ty IBM 12 tháng vừa qua Giả sử có vài dịch vụ thu phí người sử dụng, vài dịch vụ khác người dùng cung cấp miến phí Trong biểu diễn ngầm định, đề xuất cho OWL-S, mơ tả dịch vụ theo IOPE, với phí effect trình thực dịch vụ Biểu diễn rõ ràng sử dụng thể để mô tả dịch vụ biến thể với lớp định nghĩa FreeStockProfiler FreeBasedStockProfiler Người dùng trình bày rõ ràng biểu diễn dịch vụ mà họ yêu cầu đầy đủ chi tiết để đối sánh dịch vụ tiềm khác, truyền biểu diễn tới tác tử khác (tác tử đối sánh tác tử trung gian), chấp nhận gợi ý dịch vụ thỏa mãn yêu cầu Chẳng hạn camera cần đặt gần máy in để in ảnh mầu với chất lượng đủ tốt khoảng thời gian xác định Sau trình bày rõ ràng biểu diễn thích hợp máy in, camera sử dụng mơ tả để tìm kiếm danh bạ gửi ảnh tới tác tử khác để đưa đến máy in thích hợp khác Một máy đối sánh (matching engine) nên có khả năng: § Hỗ trợ đối sánh ngữ nghĩa mềm dẻo thể sẻ chia § Cung cấp việc điều khiển đối sánh tới dịch vụ yêu cầu § Khuyến khích nhà quảng cáo người yêu cầu cần trung thực với biểu diễn dịch vụ họ § Hiệu giảm thiểu số fasle negative false positive phép đối sánh Thuật toán đối sánh ngữ nghĩa dựa OWL, cho phép tác tử đối sánh nhận độ tương tự ngữ nghĩa yêu cầu quảng cáo cú pháp khác dịch vụ Điều đạt cách so sánh IOPE đặc tả mơ hình dịch vụ với đặc tả yêu cầu Để cung cấp khả đối sánh ngữ nghĩa mềm dẻo, yêu cầu đối sánh theo phân cấp gộp thể cho trước mà bao gồm khái niệm thể đối sánh tương tự cú pháp yêu cầu quảng cáo Do đó, thể cung cấp ngữ cảnh mà yêu cầu quảng cáo thể rõ rang Chẳng hạn, đối sánh 115 xe ô tô (car) quảng cáo với xe tơ (vehicle) xe tơ tính gộp (subsumed) vào xe ô tô Một đối sánh (match) quảng cáo yêu cầu xảy tất đầu yêu cầu khớp với đầu quảng cáo tất đầu vào quảng cáo khớp với đầu vào yêu cầu Chẳng hạn dịch vụ có khả đáp ứng nhu cầu người yêu cầu người yêu cầu cung cấp tất thông tin đầu vào cho dịch vụ đối sánh hoạt động Do đó, chí yêu cầu đầu không khớp với đầu quảng cáo coi đối sánh thất bại Dựa vào tương ứng ngữ nghĩa yêu cầu quảng cáo, kiểu đối sánh phân biệt sau: § Đối sánh xác (exact): đầu yêu cầu giống hệt với đầu quảng cáo Nghĩa là, đầu quảng cáo thỏa mãn hoàn toàn với đầu yêu cầu § Đối sánh Plug-in: đầu yêu cầu tính gộp (subsumed) với đầu quảng cáo Chẳng hạn, dịch vụ cung cấp tất loại xe ô tô plug in khớp (matched) với yêu cầu xe ô tô Dịch vụ quảng cáo thay vị trí dịch vụ yêu cầu Việc đối sánh làm giảm độ xác (precision) có khả thỏa mãn u cầu § Đối sánh tính gộp (subsume): Khi đầu yêu cầu tính gộp đầu quảng cáo Chẳng hạn dịch vụ u cầu xe tơ khớp với phép tính gộp (subsuming) yêu cầu mong muốn xe ô tô Việc đối sánh làm giảm độ bao phủ (recall) dịch vụ quảng cáo khơng hoàn toàn thỏa mãn yêu cầu Như vậy, đối sánh xác trường hợp đặc biệt đối sánh plug-in đối sánh tính gộp 9.3 LỰA CHỌN DỰA TRÊN MƠ HÌNH XÃ HỘI Khám phá dịch vụ xác định vị trí dịch vụ liên quan đến việc tìm cho dịch vụ cho trước đâu Đặc tả cho dịch vụ mong muốn tương ứng với câu truy vấn Tuy nhiên, thay câu trả lời (correctness) ta xem xét câu trả lời đủ (completeness) Vài dịch vụ thỏa mãn yêu cầu cụ thể tìm cho dịch vụ tốt khó khăn Đây điểm mấu chốt phân biệt rút trích thơng tin khám phá dịch vụ Rút trích thơng tin gặp khó khăn mơi trưởng mở nguồn thơng tin cần rút trích thường phải cụ (đóng) Tuy nhiên, khám phá dịch vụ khơng gặp khó khăn kiến trúc hướng dịch vụ, toán khám phá lựa chọn dịch vụ giảm thiểu nguồn thông tin cần khám phá lựa chọn thành dịnh vụ mong muốn (desired services) Chắc chắn việc tìm dịch vụ mong muốn bao gồm thao tác tìm hướng (navigation) thơng tin (information navigation) nguồn thông tin tổ chức đồ thị Một dịch vụ khám phá cách tìm kiếm đồ thị Theo truyền thống, đồ xây dựng cạnh kết nối nguồn đến nguồn khác Ví dụ, trang web chứa siêu liên kết đến trang web khác khái niệm cho việc tìm hướng Tuy nhiên, web không cung cấp ngữ nghĩa khái niệm hợp lý Do tất cạnh nguồn thơng tin xem Hiển nhiên việc tìm 116 hướng quan trọng tìm kiếm đố thị khổng lồ với hàng triệu nút hàng tỉ cạnh, làm giảm đáng kể thời gian tìm kiếm 9.3.1 Các kỹ thuật tư vấn Tư vấn (recommendation) cơng việc dự đốn nhu cầu mối quan tâm người dùng Các hệ tư vấn (recommender systems) sử dụng rộng rãi lĩnh vực lựa chọn sản phẩm Lọc cộng tác dựa nội dung cách tiếp cận tĩnh cho việc lựa chọn dựa trang web Nó bao gồm lọc trang web tài liệu theo từ xuất trang web tài liệu Tuy nhiên, bước lùi tiêu chuẩn dịnh vụ web nay, bao gồm biểu diễn hình thức có cấu trúc dịch vụ, hỗ trợ cho khám phá dựa biểu diễn Một cách tiếp cận khác lọc thông tin xã hội (social information filtering) Trong đó, lọc cộng tác (collaborative filtering) sử dụng rộng rãi trang web thương mại điện tử amazon.com Trong lọc cộng tác, đánh giá người dùng sản phẩm khác lưu trữ tập trung Các đánh giá thường thu thập người dùng mua sản phẩm Người dùng gợi ý mua sản phẩm dựa đánh giá người dùng khác Ví dụ, Alice Bob mua sánh A,B,C Alice mua sánh D hệ lọc cộng tác tư vấn cho Bob nên mua sách D Người tiêu dùng gợi ý gọi người dùng tích cực (active user) Ý tưởng đốn người dùng tích cực đánh giá sản phẩm dựa đánh giá người khác hay dựa đánh giá sản phẩm dịch vụ khác Cách tiếp cận thông thường sử dụng tương quan Pearson (Pearson correlation) để đánh trọng số Một cách tương ứng sử dụng véc tơ tương tự người dùng mà người dùng mơ hình hóa khơng gian nhiều chiều a Tư vấn dựa mơ hình Theo cách tiếp cận này, mơ hình cho người dùng cần xây dựng trước sau sử dụng mơ hình để đốn người dùng tích cực Sau gom nhóm (clustering) người dùng, người dùng tích cực xuất nhóm Sau mơ hình xác suất ví dụ mạng Baysian để biểu diễn mơ hình b Tư vấn dựa nhớ Cách tiếp cận dựa nhớ xem xét đánh giá tất người dùng trực tiếp thay xen vào bước xây dựng mơ hình Việc dự đốn cho đánh giá người dùng tích cực tổng trọng số đánh giá từ người dùng khác mà trọng số tương ứng với độ tương tự người dùng tích cức người dùng khác Có hai bước để dự đốn Một tính giá trị trung bình theo đánh giá thu được, tính độ tương tự khơng tương tự đánh giá người dùng khác 9.3.2 Lựa chọn dịch vụ dựa tư vấn Lựa chọn dịch vụ dựa tư vấn chia làm khía cạnh: § Khám phá tìm kiếm (lookup)và tìm hướng (navigation) mạng 117 § Tư vấn thông nhu cầu tương tự không tương tự § Đánh giá chất lượng Ba khía cạnh xem xét tảng Nền tảng cộng đồng dịch vụ (service community) Một cộng đồng bao gồm số người quan trọng (principals) mà người có tiềm sử dụng cung cấp dịch vụ khác Những người quan trọng trợ giúp bới tác tử để giúp họ quản lý tương tác Các tác tử đánh giá dịch vụ lời tư vấn cung cấp người khác Quan trọng hơn, giống người, tác tử trì danh bạ người quan trọng đáng để tương tác, định sử dụng dịch vụ Vì tác tử hỗ trợ chức đăng kí Và vậy, tác tử tương tác với Một tác tử truy vấn đến tác tử khác dịch vụ mà cần Tác tử nhận truy vấn lờ đi, đáp lại thực dịch vụ, hay gửi yêu cầu truy vấn tới tác tử khác để yêu cấu thực dịch vụ 118 TÀI LIỆU THAM KHẢO [1] Munidar P Singh, Michael N Huhns Service-Oriented Computing: Semantics, Processes, Agent Wiley&Sons, 2005 [2] Liyang Yu Introduction to the Semantics Web and Semantics Web Services Capma Publisher, 2011 [3] Bài giảng Protégé: http://owl.cs.manchester.ac.uk/publications/talks-and-tutorials/protgowl-tutorial/ (truy cập ngày 24/12/2014) [4] Ví dụ OWL-S: http://www.daml.org/services/owl-s/1.1/examples.htlm (truy cập ngày 24/12/2014) [5] Dịch vụ webASP.NET: http://www.tutorialspoint.com/asp.net/asp.net_web_services.htm (truy cập ngày 25/12/2014) [6] Shahir Daya, Nguyen Van Duy, Kameswara Eati, Carlos M Ferreira, Dejan Glozic, Vasfi Gucer, Manav Gupta, Sunil Joshi, Valerie Lampkin, Marcelo Martins, Shishir Narain, Ramratan Vennam Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Approach IBM Redbooks, 2015 [7] Sam Newman Building Microservices: Designing Fine-Grained Systems 1st Edition Wiley&Sons, 2015 119 ... dễ dàng quản lý phát triển 5.4 BÀI TẬP Kiến trúc hướng dịch vụ (SOA) gì? Nêu đặc trưng kiến trúc hướng dịch vụ? Kiến trúc RESTful gì? Nêu thao tác kiến trúc RESTful? Kiến trúc vi dịch vụ microservice... đai triển khai dịch vụ web RESTful; kiểu cũ triển khai dịch vụ tương tự RPC (lời thủ tục từ xa) Ngoài ra, dịch vụ RESTful sửa đổi trạng thái liệu thông qua biểu diễn tài nguyên; dịch vụ RPC ẩn phần. .. (taxonomies) mà mơ tả lớp khác dịch vụ Ví dụ dịch vụ web ngữ nghĩa profile sử dụng OWL-S 1.1 trình bầy hình 6 .2 98 Hình 6 .2: Dịch vụ web ngữ nghĩa profile sử dụng OWL-S 1.1 [2] 7.3 .2 Bản thể OWL-S process