Khung cộng tác đa dụng trong môi trường tính toán lưới

MỤC LỤC LỜI CAM ĐOAN LỜI CẢM ƠN DANH MỤC CHỮ VIẾT TẮT DANH MỤC BẢNG DANH MỤC HÌNH VẼ MỞ ĐẦU CHƯƠNG 1: TỔNG QUAN ................................................................................................. 16 1.1 Các kiến thức nền tảng liên quan đến kế hoạch và cộng tác ....................................... 16 1.1.1 Các cơ chế phối hợp ............................................................................................. 16 1.1.2 Lý thuyết Hoạt động ............................................................................................. 17 1.1.3 Biểu diễn hoạt động bằng ngôn ngữ luồng công việc .......................................... 22 1.2 Tính toán lưới .............................................................................................................. 23 1.2.1 Sơ lược lịch sử phát triển ...................................................................................... 23 1.2.2 Các kiến trúc lưới ................................................................................................. 24 1.2.3 Hạ tầng lưới .......................................................................................................... 27 1.3 Khung lưới cộng tác .................................................................................................... 29 1.3.1 Khung cộng tác ..................................................................................................... 29 1.3.2 Các khung lưới cộng tác không có hỗ trợ ngôn ngữ luồng công việc .................. 31 1.3.3 Các khung lưới cộng tác có hỗ trợ ngôn ngữ luồng công việc ............................. 33 1.4 Các giải pháp thực thi kế hoạch trên lưới .................................................................... 34 1.5 Quá trình khai thác tiến trình BPEL ............................................................................ 35 1.6 Vấn đề còn tồn tại và tiếp cận ..................................................................................... 36 1.6.1 Vấn đề còn tồn tại ................................................................................................. 36 1.6.2 Tiếp cận ................................................................................................................ 38 CHƯƠNG 2: MÔ HÌNH KẾ HOẠCH VÀ KHUNG CỘNG TÁC ĐA DỤNG ................... 39 2.1 Mô hình kế hoạch ........................................................................................................ 39 2.1.1 Các khái niệm cơ bản ........................................................................................... 39 2.1.2 Các trạng thái của hoạt động ................................................................................ 48 2.1.3 Phụ thuộc khả thi .................................................................................................. 50 2.1.4 Kế hoạch ............................................................................................................... 53 2.2 Khung cộng tác đa dụng .............................................................................................. 64 1 2.2.1 Các yêu cầu đối với khung cộng tác đa dụng ....................................................... 64 2.2.2 Mô tả các hoạt động.............................................................................................. 65 2.3 Các nghiên cứu liên quan ............................................................................................ 72 CHƯƠNG 3: LÀM MỊN KẾ HOẠCH ................................................................................. 74 3.1 Chi tiết hóa kế hoạch ................................................................................................... 74 3.1.1 Bổ sung chi tiết ..................................................................................................... 76 3.1.2 Phân tách .............................................................................................................. 77 3.1.3 Mối quan hệ giữa chi tiết hóa và phụ thuộc khả thi ............................................. 78 3.2 Tăng cường tính khả thi của hoạt động ....................................................................... 78 3.2.1 Các kỹ thuật chuyển đổi ....................................................................................... 78 3.2.2 Các hạn chế tồn tại................................................................................................ 85 3.2.3 Giải thuật phát hiện mẫu có cấu trúc đầy đủ ........................................................ 86 3.2.4 Giải thuật xây dựng các mẫu có cấu trúc đầy đủ .................................................. 91 3.2.5 Các nghiên cứu liên quan ..................................................................................... 96 CHƯƠNG 4: THIẾT KẾ VÀ CÀI ĐẶT KHUNG LƯỚI CỘNG TÁC ĐA DỤNG ............ 98 4.1 Các yêu cầu của khung ................................................................................................ 98 4.2 Thiết kế khung ............................................................................................................. 99 4.2.1 Kiến trúc khung .................................................................................................... 99 4.2.2 Thiết kế modul .................................................................................................... 101 4.2.3 Kết luận phần thiết kế ......................................................................................... 104 4.3 Cài đặt khung ............................................................................................................. 104 4.3.1 Giải pháp gọi dịch vụ lưới từ tiến trình BPEL ................................................... 104 4.3.2 Mở rộng mô hình điều khiển truy nhập dựa trên thuộc tính cho các hệ thống luồng công việc cho môi trường lưới .......................................................................... 115 4.3.3 Giải pháp tự động hóa quá trình khai thác tiến trình BPEL ............................... 126 KẾT LUẬN ......................................................................................................................... 133 DANH MỤC CÁC CÔNG TRÌNH ĐÃ CÔNG BỐ TÀI LIỆU THAM KHẢO PHỤ LỤC 2 DANH MỤC HÌNH VẼ Hình 1-1: Sơ đồ một hoạt động............................................................................................. 18 Hình 1-2: Sự chuyển đổi giữa các mức của hoạt động. ........................................................ 19 Hình 1-3: Hai loại hoạt động tập thể. .................................................................................. 20 Hình 1-4: Các mức cộng tác trong các hoạt động tập thể.................................................... 21 Hình 1-5: Kiến trúc lưới. ...................................................................................................... 24 Hình 1-6: Kiến trúc Dịch Vụ lưới Mở (OGSA). .................................................................... 26 Hình 1-7: Cấu trúc của tổ chức ảo (Virtual Organization). ................................................. 26 Hình 1-8: Quan hệ giữa OGSA và Globus Toolkit 4. ........................................................... 28 Hình 2-1: Cấu trúc của một hoạt động đơn ......................................................................... 40 Hình 2-2: Góc nhìn chức năng của một hoạt động đơn A(S,T,O) ........................................ 41 Hình 2-3: Biểu diễn một hoạt động đơn............................................................................... 41 Hình 2-4: Các tình huống cho common-in(A1, A2). .............................................................. 43 Hình 2-5: Các tình huống cho in-out (A1, A2). ...................................................................... 43 Hình 2-6: Ví dụ về biểu diễn đường dẫn path(A1, A2). ......................................................... 44 Hình 2-7: Các thành phần của hoạt động “Học một chủ đề”. ............................................. 44 Hình 2-8: Các thành phần của hoạt động “Dạy học cho nhóm”. ........................................ 45 Hình 2-9: Hoạt động tập thể "Học một chủ đề". .................................................................. 46 Hình 2-10: Hoạt động tập thể chỉnh. .................................................................................... 46 Hình 2-11: Hoạt động Xử lý yêu cầu làm thẻ tín dụng. ........................................................ 47 Hình 2-12: Các cặp hoạt động tương đương. ....................................................................... 49 Hình 2-13: Biểu diễn cho một kế hoạch. ............................................................................... 54 Hình 2-14: Biểu diễn kế hoạch khả thi bằng đồ thị VÀ/HOẶC. ........................................... 55 Hình 2-15: Biểu diễn kế hoạch không khả thi. ...................................................................... 55 Hình 2-16: Biểu diễn kế hoạch không khả thi bằng đồ thị VÀ/HOẶC.................................. 56 Hình 2-17: Kế hoạch cho việc xây dựng giải thuật sắp xếp. ................................................ 57 Hình 2-18: Kế hoạch cho việc xây dựng Dịch vụ lưới của giải thuật sắp xếp. .................... 58 Hình 2-19: Đường dẫn khả thi (biểu diễn bằng nét đứt). ..................................................... 59 Hình 2-20: Đường dẫn không khả thi (biểu diễn bằng nét đứt). .......................................... 59 Hình 2-21: Đường dẫn khả thi thứ nhất cho Kế hoạch sắp xếp. ......................................... 60 Hình 2-22: Đường dẫn khả thi thứ hai cho Kế hoạch sắp xếp. ............................................ 60 Hình 2-23: Tổng quan về khung cộng tác đa dụng ............................................................... 65 Hình 2-24: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn trực quan). ............................................................................................................. 71 Hình 2-25: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn bằng XML). .................................................................................................................... 71 Hình 3-1: Phân cấp khối cấu trúc của một tiến trình ........................................................... 80 Hình 3-2: Ánh xạ của một số mẫu......................................................................................... 81 Hình 3-3: Một sơ đồ tiến trình nghiệp vụ với các khối cấu trúc CAB .................................. 82 Hình 3-4: Mẫu Sequence....................................................................................................... 83 Hình 3-5: Mẫu Flow ............................................................................................................. 83 Hình 3-6: Mẫu Switch ........................................................................................................... 83 Hình 3-7: Mẫu Pick............................................................................................................... 84 3 Hình 3-8: Mẫu While ............................................................................................................ 84 Hình 3-9: Rút gọn của hai “AND fork gateways” nối với nhau. .......................................... 84 Hình 3-10: Rút gọn của hai “AND join gateways” nối với nhau ......................................... 85 Hình 3-11: Rút gọn của hai AND gateways khác nhau nối với nhau (AND fork nối với AND join)........................................................................................................................................ 85 Hình 3-12 : Tiến trình BPMN. .............................................................................................. 92 Hình 3-13: Đồ thị biểu diễn tiến trình BPMN và kết quả của phép duyệt theo chiều sâu (DFS). Ở bước 1, DFS được sử dụng để phát hiện các vùng chu trình và vùng bất chu trình. ............................................................................................................................................... 93 Hình 3-14: Các vùng đã phát hiện được sau bước 1. Ở đây phát hiện được ba vùng: R2 là vùng chu trình, còn R1 và R3 là hai vùng bất chu trình. ....................................................... 93 Hình 3-15: Các vùng đã phát hiện được sau bước 2 (một số nhãn cho các nút từ các hình trước đã cố tình được bỏ bớt từ hình này trở đi nhằm làm cho các hình vẽ đỡ rắc rối hơn) 94 Hình 3-16: Vùng cuối cùng được trả về R sau các bước cuối 3, 4 và 5 ............................... 94 Hình 4-1: Kiến trúc khung lưới cộng tác. ............................................................................. 99 Hình 4-2: Cấu trúc các modul của khung. .......................................................................... 103 Hình 4-3: Sơ đồ của tiến trình BPEL Test-Factory GS-V2 ................................................ 105 Hình 4-4: Lược đồ tuần tự của hai handler. ....................................................................... 111 Hình 4-5: Tiến trình BPEL thử nghiệm............................................................................... 113 Hình 4-6: Kết quả chạy tiến trình BPEL............................................................................. 113 Hình 4-7: Luồng công việc cho tiến trình xử lý việc nộp bài cho hội nghị. ....................... 121 Hình 4-8: Thiết kế chi tiết mô hình CABAC........................................................................ 122 Hình 4-9: Chức năng chính của công cụ ............................................................................ 127 Hình 4-10: Các bước thực hiện của công cụ ...................................................................... 128 Hình 4-11: Cấu trúc của tệp deploy.xml ............................................................................. 128 Hình 4-12: Cấu trúc của các tệp ví dụ. ............................................................................... 130 Hình 4-13: Workflow của tiến trình trong ví dụ. ................................................................ 130 Hình 4-14: Tệp deploy.xml đã được tạo ra sau khi công cụ được chạy ............................. 131 Hình 4-15: Kết quả chạy ví dụ bằng công cụ soapUI. ....................................................... 131 4 DANH MỤC BẢNG Bảng 2-1: Bảng giá trị cho hàm AND ................................................................................... 50 Bảng 2-2: Một số kiểu dữ liệu và hàm phụ cho giải thuật 2-1.............................................. 63 Bảng 2-3: Cấu trúc của một đặc tả hoạt động ...................................................................... 66 Bảng 2-4: Đặc tả hoạt động cho hoạt động Học một chủ đề ............................................... 67 Bảng 2-5: Ánh xạ từ các thành phần của hoạt động sang luồng công việc. ......................... 69 Bảng 2-6: Mô hình hóa cho hoạt động “Xử lý yêu cầu làm thẻ” (phần đầu). ...................... 70 Bảng 4-1: Ánh xạ các khối chức năng vào các modul hệ thống. ........................................ 102 Bảng 4-2: Các hàm tiện ích được sử dụng trong CABAC ................................................. 120 Bảng 4-3: Biểu diễn các quy tắc trong Ví dụ 4-3 ............................................................... 120 Bảng 4-4: Một số quy tắc truy nhập cho Ví dụ 4-4 ............................................................. 122 Bảng 4-5: Ý nghĩa của các luồng dữ liệu trong Hình 4-8. .................................................. 123 Bảng 4-6: So sánh các tính năng của mô hình CABAC và các mô hình khác. ................... 126 5 LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi. Các kết quả trong luận án là trung thực và chưa từng được công bố trong bất kỳ công trình nào khác. Hà nội, ngày Giáo viên hướng dẫn tháng năm 2015 Tác giả TS. Nguyễn Hữu Đức Nguyễn Thanh Bình GS. TS. Nguyễn Thanh Thủy 6 DANH MỤC CHỮ VIẾT TẮT Tên viết tắt Tên đầy đủ Ý nghĩa ABAC Attribute-Based Access Mô hình điều khiển truy nhập dựa trên thuộc Control tính. AT Activity Theory Axis Apache eXtensible SOAP engine và công cụ phần sụn của dịch vụ Interaction System Web (Web Service middleware tool). Phiên bản 2 của nó có tên gọi Axis2 [4] có nhiều cải tiến quan trọng so với phiên bản trước. BPEL Business Process Ngôn ngữ luồng công việc cho phép biểu diễn Execution Language các tiến trình nghiệp vụ ở nhiều mức, nhất là ở mức thấp mà có thể được thực thi tự động. BPMN Business Modeling (Version 1) CDG Collaborative Grid Lý thuyết Hoạt động: là một lý thuyết đã có một lịch sử khá dài (ra đời từ những năm 19201930.) với khởi đầu là các nghiên cứu của ba nhà nghiên cứu theo trường phái lịch sử văn hóa (cultural-historical school) của ngành tâm lý học Nga là L. S. Vygotsky, A. N. Leont'ev và A. R. Luria. Lý thuyết này được đưa ra nhằm giải thích các trạng thái tâm lý của con người thông qua các hoạt động có chủ đích của họ. Process Ngôn ngữ luồng công việc cho phép mô hình Notation hóa các tiến trình nghiệp vụ ở mức cao (mức phân tích và thiết kế nghiệp vụ). Nó bao gồm sơ Business Process Model đồ (biểu diễn hướng người dùng), và văn bản & Notation (Version 2) (để lưu trữ và xử lý tự động, sử dụng ngôn ngữ XML). Design Là một khung (phân hệ) nhằm giải quyết hai vấn đề trong thiết kế cộng tác: chia sẻ tài nguyên và cộng tác phân tán về mặt địa lý. Kiến trúc này chủ yếu dựa trên OGSA, và được cài đặt bằng các dịch vụ lưới trong Globus Tookit 3, với ba công nghệ chính: Thiết kế Cộng tác có trợ giúp của Máy tính (CSCD - Computer Supported Collaborative Design), tính toán lưới và cổng thông tin Web (Web portal). 7 CSCW Computer Supported Công việc cộng tác có trợ giúp của máy tính. Collaborative Work ĐKTN Điều khiển truy nhập Cụm từ viết tắt này được sử dụng ở phần 4.2.2 khi nói về các mô hình điều khiển truy nhập. EPR EndPoint Reference Tham chiếu Điểm cuối: là sự kết hợp giữa địa chỉ dịch vụ lưới và tài nguyên tương ứng. GC Grid Computing Tính toán lưới. GCF-MD Grid-based Khung lưới cộng tác cho các thiết bị di động: là Collaborative nền tảng cho phép các thiết bị di động có thể Framework for Mobile cộng tác với nhau để giải quyết các bài toán có Devices khối lượng tính toán lớn G-ODE Grid Orchestration BPEL engine được luận án phát triển dựa trên Director Engine ODE engine của Apache nhằm cung cấp thêm khả năng gọi dịch vụ lưới. GS Grid Services MAC Mandatory Control ODE Orchestration Director Một BPEL engine (module phần mềm giúp thực Engine thi các tệp BPEL) mã nguồn mở của Apache [75]. OCGSA Open Collaborative Kiến trúc dịch vụ lưới cộng tác mở. Grid Service Architecture OGSA Open Grid Architecture PTKT Phụ Thuộc Khả Thi RBAC Role-Based Control SOA Service Architecture SOAP Simple Object Access Giao thức truy nhập đối tượng đơn giản. Protocol Dịch vụ lưới. Access Điều khiển truy nhập bắt buộc. Bắt buộc (mandatory) với nghĩa là các quyền truy nhập đã bị quy định cứng bởi hệ thống, và nó không thể bị thay đổi bởi người dùng hoặc bởi chương trình của người dùng. Services Kiến trúc dịch vụ lưới mở. Phụ thuộc giữa các hoạt động, được định nghĩa trong phần 2.1.3. Access Mô hình điều khiển truy nhập dựa trên vai trò. Oriented Kiến trúc Hướng Dịch vụ. 8 SPM Standard Models Process Mô hình tiến trình chuẩn: là các sơ đồ khái quát của các Ngôn ngữ tiến trình nghiệp vụ (Business Process Languages) như BPMN và UML (Unified Modeling Language). VO Virtual Organization XACML eXtensible Control Language WF Workflow Luồng công việc WS Web Service Dịch vụ Web. WSRF Web Service Resource Khung tài nguyên dịch vụ Web: một chuẩn mở Framework rộng cho dịch vụ Web (Web services) nhằm quản lý các dịch vụ Web có trạng thái. Tổ chức ảo. Access Ngôn ngữ đánh dấu điều khiển truy nhâp mở Markup rộng, được sử dụng để định nghĩa các quy tắc truy nhập trong những hệ thống điều khiển truy nhập dựa trên vai trò (RBAC), hay dựa trên thuộc tính (ABAC). 9 LỜI CẢM ƠN Luận án này là kết quả của một quá trình lao động khá lâu dài và vất vả, ngoài những nỗ lực của bản thân tác giả, còn có sự giúp đỡ nhiệt tình của rất nhiều người. Qua đây, tác giả xin trân trọng gửi những lời cảm ơn chân thành và sâu sắc nhất đến tất cả mọi người. Đặt biệt, tác giả xin được bày tỏ lòng biết ơn sâu sắc đến những người Thầy hướng dẫn của mình, trực tiếp hay gián tiếp, kể cả trong và ngoài nước, gồm các Thầy: - Giáo sư Nguyễn Thanh Thủy, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội, Tiến sĩ Nguyễn Hữu Đức, trường Đại học Bách khoa Hà Nội, Giáo sư Hoàng Bằng Đoàn, trường Đại học Công nghệ Sydney (UTS), Úc, Giáo sư Tharam Dillon, trường Đại học Công nghệ Sydney (UTS), Úc, Tiến sĩ George Feuerlicht, trường Đại học Công nghệ Sydney (UTS), Úc. Tác giả cũng xin được bày tỏ sự cảm kích vô hạn đối với tất cả các Thầy, Cô giáo, nơi tác giả được may mắn học tập và nghiên cứu tại Trường Đại Học Bách Khoa Hà Nội và Trường Đại Học Công Nghệ Sydney (Úc). Trong quá trình nghiên cứu, tác giả cũng may mắn được làm việc tại Trung Tâm Tính Toán Hiệu Năng Cao, thuộc Viện Nghiên Cứu Quốc Tế về Khoa Học Tính Toán (ICSE), Trường ĐHBK Hà Nội. Tại đây, tác giả đã nhận được sự giúp đỡ to lớn và nhiệt tình của rất nhiều người trong Trung tâm, từ Thầy Nguyễn Hữu Đức Giám đốc Trung tâm, cho đến các nhân viên và các sinh viên thực tập, trong đó đặc biệt là hai sinh viên Nguyễn Văn Cường và Nguyễn Trường Minh, lớp KSTN K52, đã hỗ trợ tác giả trong một phần cài đặt công cụ G-ODE. Nhân đây, tác giả cũng xin được bày tỏ lời cảm ơn sâu sắc đến ban lãnh đạo và những đồng nghiệp nơi tác giả đang công tác là Bộ môn Điện tử - Kỹ thuật máy tính, Viện Điện Tử - Viễn Thông, Trường Đại Học Bách Khoa Hà Nội. Và cuối cùng, tác giả xin bày tỏ lòng biết ơn sâu sắc đến toàn thể gia đình, bạn bè, những người thân về sự giúp đỡ, động viên không ngừng, trong mọi hoàn cảnh dù khó khăn đến đâu. 10 MỞ ĐẦU Các hoạt động của con người, theo một cách đơn giản, có thể được chia thành hai loại: hoạt động cá nhân và hoạt động tập thể. Trong hoạt động tập thể, có sự tham gia của nhiều người để hoàn thành một mục tiêu nào đó, cần có các biện pháp thích hợp để phối hợp công việc của các thành viên, sao cho cuối cùng tập thể đó có thể hoàn thành được mục tiêu đề ra. Tùy theo lĩnh vực hoạt động, cách thức tổ chức và mục tiêu của hoạt động, có thể tồn tại các biện pháp phối hợp khác nhau với các tên gọi khác nhau như: cơ chế điều phối, công cụ cộng tác, bộ lập lịch, v.v. Trước đây, đối với các hệ thống thông tin nhằm quản lý các hoạt động nghiệp vụ tập thể, các cơ chế cộng tác thường được thiết kế và cài đặt như là một bộ phận không thể tách rời của qui trình nghiệp vụ. Thậm chí, hoạt động cộng tác thường chỉ được xem như một bước tất yếu trong toàn bộ qui trình nghiệp vụ, chứ chưa được xem như một đối tượng độc lập để có thể được tái sử dụng nhiều lần. Nói cách khác, vấn đề hỗ trợ cộng tác chưa được giải quyết trực tiếp và có hệ thống. Đối với các hệ thống quy mô nhỏ với số lượng người dùng tương đối ít và số lượng thông tin phụ thuộc cần trao đổi không nhiều, vấn đề này có thể dễ dàng được giải quyết. Tuy nhiên, với những hệ thống lớn từ hàng chục đến hàng trăm người sử dụng trở lên, số lượng dữ liệu phụ thuộc, cũng như tính chất các mối quan hệ giữa những người dùng cũng nhiều và phức tạp, vấn đề cộng tác trở nên không đơn giản. Điều này đặt ra nhiệm vụ phải giải quyết vấn đề cộng tác một cách bài bản, để từ đó có thể xây dựng những công cụ cộng tác đa dụng, mềm dẻo và hiệu quả. Cho đến nay, trong lĩnh vực nghiên cứu về vấn đề cộng tác, có một số nền tảng lý thuyết đã được phát triển như: Coordination Mechanisms [24] (Cơ chế Điều phối) và Common Artifacts [66] (Các công cụ thông dụng) và Activity Theory [58] [20] (Lý thuyết Hoạt động). Trong số này, Lý thuyết Hoạt động, mặc dù ra đời sớm nhất và trọng tâm nghiên cứu không phải là sự cộng tác, nhưng trong thời gian gần đây, lý thuyết này đã thu hút được nhiều sự chú ý từ một số lĩnh vực nghiên cứu liên quan đến khả năng cộng tác như: Tương tác Người-Máy (human-computer interaction) [51], Công việc cộng tác có trợ giúp của máy tính (Computer Supported Collaborative Work) [20]. Có thể đưa ra một số lý giải cho vấn đề này. Đầu tiên, lý thuyết này cho một cài nhìn toàn diện về hoạt động, nhất là các hoạt động tập thể cần có sự cộng tác. Thứ hai, nó đã giải thích một cách rõ ràng bản chất của cộng tác trong các hoạt động có tính cộng tác và từ đó, các cơ chế cộng tác và điều phối cần thiết có thể được mô hình hóa, thiết kế và cài đặt. Tuy nhiên, cho đến nay, dường như lý thuyết này vẫn thiếu sự mô tả hình thức cho các khái niệm đưa ra. Điều này dẫn đến một số vấn đề: (1) không rõ ràng trong các khái niệm trừu tượng (như hoạt động (activity), hành động (action), kế hoạch (plan),v.v); (2) một số vấn đề còn mở liên quan đến cách biểu diễn hoạt động, quan hệ giữa hoạt động và kế hoạch hành động, v.v chưa có câu trả lời thỏa 11 đáng. Điều này làm hạn chế khả năng phát triển và ứng dụng của lý thuyết hoạt động trong thực tế. Theo nghĩa thông thường, sự cộng tác được hiểu là khi có hai hay nhiều chủ thể (có thể là con người hoặc máy tính) phối hợp với nhau để thực hiện một mục tiêu chung nào đó. Nguồn gốc của mọi sự cộng tác là ở sự phân chia công việc, thường được mô tả dưới dạng một kế hoạch (trong thực tiễn, kế hoạch có thể tường minh dưới dạng một bản hợp đồng có chữ ký của các bên tham gia, nhưng cũng có thể chỉ là ngầm định như phân công bằng miệng rồi mọi người tự giác thực hiện). Kế hoạch đó sẽ quyết định cách thức và các công cụ cộng tác cần thiết cho các thành viên. Khi kế hoạch có sự thay đổi sẽ dẫn đến sự thay đổi trong việc cộng tác. Do đó, việc quản lý tốt kế hoạch sẽ giúp phát hiện và quản lý sự cộng tác tốt hơn. Tìm hiểu bản chất kế hoạch hành động, ta thấy có nhiều điểm tiếp cận tương đồng như trong lý thuyết hoạt động. Lý thuyết này tỏ ra rất thích hợp cho việc giải thích quá trình lập kế hoạch, cũng như các loại hình cộng tác dựa trên kế hoạch. Từ những phân tích trên, có thể nhận thấy cần phải mô tả hình thức các khía cạnh trong lý thuyết hoạt động, làm rõ hơn bản chất và nguồn gốc của sự cộng tác, để từ đó giúp cho việc biểu diễn và quản lý sự cộng tác trong thực tế được đầy đủ và hiệu quả hơn. Hệ hình thức dự định xây dựng trong luận án có tên gọi Mô hình Kế hoạch, góp phần trả lời các câu hỏi sau: 1. Kế hoạch là gì? Cần hiểu rõ ràng kế hoạch thông qua cấu trúc và vai trò trong các hoạt động. 2. Mối quan hệ giữa kế hoạch và các hành động (action) để thực thi kế hoạch đó? Mỗi kế hoạch cần có các hành động tương ứng nhằm thực thi mục tiêu của kế hoạch đó. Một mặt, kế hoạch giúp cho chủ thể thực thi kế hoạch biết trước các hành động cần tiến hành, cũng như thứ tự của chúng. Mặt khác, thông qua quá trình thực thi các hành động, cùng với các kết quả thu được trong quá trình đó, cũng có thể giúp cho việc điều chỉnh và hoàn thiện thêm kế hoạch. Tuy nhiên, quá trình chuyển đổi từ kế hoạch sang hành động và ngược lại chưa được biểu diễn một cách rõ ràng. Ví dụ như sự khác nhau giữa kế hoạch và hành động tương ứng thực sự là gì và khi nào có sự chuyển đổi từ kế hoạch sang hành động và nó diễn ra thế nào v.v. 3. Mối quan hệ giữa các kế hoạch trong cùng một hoạt động là gì? Để hoàn thành một mục tiêu nào đó, một hoạt động không chỉ có một bản kế hoạch, nhất là trong các tình huống chưa biết rõ, nhằm chuẩn bị tốt nhất ứng phó với các khả năng có thể xảy ra. Ngoài ra, đối với các hoạt động có nhiều mục tiêu, từ một kế hoạch ban đầu đạt mục tiêu tổng thể sẽ được chia thành các kế hoạch con, đáp ứng các mục tiêu bộ phận. Vấn đề là biểu diễn quan hệ giữa các kế hoạch này như thế nào? 4. Khung cộng tác cần phải bao quát các kế hoạch và các hành động tương ứng như thế nào? Để quản lý và tái sử dụng các cơ chế cộng tác này, cần phát triển các công cụ hỗ trợ cộng tác, gọi là khung cộng tác (collaborative framework) để có thể dễ dàng tích hợp vào các hệ thống khác nhau. Do vậy, cần phải xác định các chức năng và từ đó thiết kế cấu trúc của một khung cộng tác tương ứng. Thông thường, một khung công tác cần có tối thiểu các chức năng như: mô tả các kế hoạch, mô tả hành 12 động, tạo các kế hoạch, bổ sung hành động mới, thực thi các hành động trong một môi trường cụ thể. Để đánh giá tính khả thi của Mô hình Kế hoạch, luận án bước đầu triển khai thực nghiệm trong Môi trường Tính toán lưới với việc thiết kế cài đặt một hệ thống hỗ trợ xây dựng và quản lý các kế hoạch thực thi trên lưới, gọi là khung lưới cộng tác đa dụng (multipurpose collaborative grid framework). Có hai lý do giải thích sự chọn này trong luận án: - - Thứ nhất: Đó là cần một môi trường tính toán phù hợp để triển khai thực nghiệmvà đánh giá tính thực tiễn của Mô hình Kế hoạch. Hạ tầng Tính toán lưới được xây dựng theo kiến trúc mở, hướng dịch vụ quản lý tài nguyên không đồng nhất và phân tán, rất phù hợp để triển khai khung cộng tác, vì đây là một hệ thống đòi hỏi việc quản lý nhiều người dùng và thường sử dụng các loại tài nguyên khác nhau. Thứ hai: Tính toán lưới đang là một lĩnh vực nghiên cứu và phát triển nhanh chóng, với mục tiêu tạo ra một hạ tầng hỗ trợ việc chia sẻ tài nguyên có sự phối hợp trong các tổ chức động và liên ngành (còn gọi là tổ chức ảo) [52]. Mặc dù hạ tầng này hiện nay đang phát triển khá nhanh nhưng vẫn còn thiếu khả năng hỗ trợ việc xây dựng các ứng dụng có tính cộng tác. Thời gian gần đây, đã có một số nghiên cứu được thực hiện nhằm phát triển các khung lưới cộng tác như GridCole [67], QuarkNet/Grid [62], Collaborative Design Grid [106], Grid-based Cooperative Work Framework (GCWF) [105]. Tuy nhiên, khả năng hỗ trợ kế hoạch của các hệ thống này còn rất hạn chế (chi tiết về các hạn chế của các hệ thống cộng tác lưới này sẽ được phân tích chi tiết hơn trong Chương 1). Vì vậy, nghiên cứu của luận án hy vọng góp phần xây dựng khung lưới cộng tác, giúp khắc phục được phần nào các hạn chế trong tính toán lưới thông thường. Mục đích và đối tượng nghiên cứu của luận án: Mục đích nghiên cứu: Nghiên cứu trong luận án nhằm xác định rõ các hạn chế về khả năng hỗ trợ các ứng dụng cộng tác trong môi trường lưới hiện tại, từ đó đề xuất các giải pháp phù hợp, có thể giải quyết các hạn chế đó. Đối tượng nghiên cứu: Đối tượng nghiên cứu chính của luận án là các khung có khả năng hỗ trợ các nhu cầu cộng tác trong môi trường tính toán lưới. Ngoài ra, do môi trường tính toán lưới có cấu trúc khá phức tạp với nhiều thành phần, nên nghiên cứu trong luận án dựa trên cơ sở lý luận lý thuyết hoạt động, luồng công việc (workflow), các mô hình điều khiển truy nhập, v.v. Phương pháp nghiên cứu Một số phương pháp nghiên cứu, được áp dụng trong luận án, bao gồm: - Phân tích thực tế: từ việc tìm hiểu và phân tích các hệ thống và lý thuyết hiện tại liên quan (như các khung lưới hiện tại, các lý thuyết liên quan đến cộng tác,v.v) để hình dung các vấn đề còn tồn tại, từ đó xác định cụ thể trọng tâm của đề tài nghiên cứu. 13 - - - Phát triển lý thuyết-mô hình hóa: dựa trên tiếp cận lý thuyết hoạt động, luận án phát triển mô hình hóa kế hoạch và quá trình lập kế hoạch, qua đó xác định tính khả thi và không khả thi của kế hoạch. Thực nghiệm: sử dụng mô hình đã được phát triển, luận án tiến hành thiết kế và cài đặt một hệ thống gọi là khung lưới cộng tác đa dụng nhằm hiện thực hóa các ý tưởng trong mô hình kế hoạch. Đánh giá-so sánh: trong quá trình phát triển mô hình, triển khai thiết kế, cài đặt thực tế, luận án tiến hành so sánh các kết quả nghiên cứu đạt được với các kết quả nghiên cứu khác có liên quan, nhằm xác định rõ các ưu/nhược điểm của tiếp cận luận án, qua đó xác định các vấn đề nghiên cứu tiếp theo. Các kết quả nghiên cứu Nghiên cứu của luận án hướng tới việc mô tả hình thức về Kế hoạch dựa trên tiếp cận trong Lý thuyết Hoạt động, để từ đó phát triển mô hình kế hoạch và sự cộng tác, nhằm giải quyết một số hạn chế trong cơ chế phối hợp. Sau đó, dựa trên mô hình, luận án sẽ xây dựng một khung lưới cộng tác đa dụng cho phép khắc phục một số hạn chế về cộng tác của các hệ thống lưới hiện tại. Hệ thống được đề xuất hỗ trợ khả năng lập kế hoạch, cũng như việc thực hiện các công việc trong kế hoạch trên môi trường lưới. Với giải pháp này, luận án đã góp phần nâng cao khả năng cộng tác của môi trường lưới hiện nay, phục vụ tốt cho các ứng dụng có tính cộng tác cao trên lưới như điều trị y tế, quản trị doanh nghiệp,v,v. Các nghiên cứu trong luận án đã đạt được các kết quả sau: - - Về mặt lý thuyết: xây dựng một mô hình về cộng tác và khung cộng tác, cho phép giải thích đầy đủ hơn bản chất của sự cộng tác và các loại hình cộng tác cần thiết trong khung cộng tác. Về mặt thực tiễn: phát triển khung cộng tác hoạt động trong môi trường tính toán lưới, với các khả năng chính như sau:  Biểu diễn kế hoạch ở hai mức cơ bản: mức trực quan hướng người dùng, được biểu diễn bằng ngôn ngữ luồng công việc hướng đồ thị như BPMN (Business Process Model & Notation) [70] và mức thực thi (chi tiết hơn, cho phép tự động thực thi kế hoạch trong một môi trường tính toán nào đó, được biểu diễn bằng ngôn ngữ luồng công việc có cấu trúc như BPEL (Business Process Execution Language) [33][68].  Chuyển đổi kế hoạch ở mức trực quan một cách bán tự động sang kế hoạch ở mức thực thi.  Triển khai kế hoạch ở mức thực thi trong hai môi trường tính toán phân tán phổ biến hiện nay: môi trường Web (thông qua việc gọi các Web services) và môi trường lưới (thông qua việc gọi các Grid services). Cấu trúc của luận án Ngoài phần Mở đầu, Kết luận và Phụ lục, luận án gồm bốn chương với những nội dung chính như sau: 14 - - - - Chương 1. Tổng quan: Trình bày các nghiên cứu liên quan đến chủ đề nghiên cứu của luận án như: tiếp cận lý thuyết hoạt động, cơ chế cộng tác, cũng như các khung lưới cộng tác, cùng với các hạn chế của chúng. Một số vấn đề khác liên quan đến khung lưới, khai thác thủ công tiến trình BPEL trong môi trường ODE Engine của Apache [75], cũng như các giải pháp mở rộng dịch vụ lưới trong tiến trình BPEL cũng được đề cập. Chương 2. Mô hình kế hoạch và khung cộng tác: trình bày về một hệ hình thức (formalism) về cộng tác và khung cộng tác. Trong hệ hình thức này, luận án chỉ ra lõi của cộng tác là kế hoạch. Do đó, khung hỗ trợ cộng tác cần phải quản lý được kế hoạch. Chương 3. Làm mịn kế hoạch: trình bày về các kỹ thuật giúp chuyển đổi kế hoạch từ trực quan (trừu tượng) sang mức thực thi (chi tiết), nhằm làm tăng tính khả thi của nó. Có hai cách tiếp cận giúp làm mịn kế hoạch: chi tiết hóa và chuyển đổi ngôn ngữ luồng công việc biểu diễn cho hoạt động. Trong đó, các hoạt động cũng là một phần chính của kế hoạch. Chương 4. Thiết kế & Cài đặt khung lưới cộng tác: Chương này trình bày các kết quả thiết kế và cài đặt cho khung cộng tác. Trong phần thiết kế, sẽ trình bày thiết kế cấu trúc khung cộng tác, thiết kế mô hình an ninh cho khung cộng tác trong môi trường lưới. Trong phần cài đặt sẽ trình bày các kết quả của một số cài đặt cho khung cộng tác, như kỹ thuật tự động khai thác tiến trình BPEL trong môi trường ODE, giải pháp gọi dịch vụ lưới từ tiến trình BPEL. Ngoài ra, phần Kết luận sẽ tóm tắt lại các kết quả và đóng góp khoa học trong nghiên cứu của luận án. Đồng thời, một số vấn đề còn tồn tại và một số hướng nghiên cứu tiếp theo cũng đã được phát hiện. Phần Phụ lục sẽ trình bày các kiến thức cơ bản liên quan: như tính toán lưới, kiến trúc hướng dịch vụ (SOA), các lý thuyết cộng tác, một số ngôn ngữ luồng và ngôn ngữ đặc tả các tiến trình nghiệp vụ (BPEL và BPMN), cũng như một số hệ thống hỗ trợ các ngôn ngữ này. 15 CHƯƠNG 1: TỔNG QUAN Chương này trình bày tóm tắt các cơ sở lý luận về kế hoạch, cộng tác và giới thiệu tổng quan về các khung lưới cộng tác hiện có. Trên cơ sở đó, luận án chỉ ra những vấn đề cần giải quyết và các giải pháp tương ứng. 1.1 Các kiến thức nền tảng liên quan đến kế hoạch và cộng tác Phần này trình bày một số cơ sở lý luận liên quan đến cộng tác và kế hoạch, dựa trên đó làm rõ hơn các hạn chế còn tồn tại, qua đó sẽ xác định cụ thể hơn các vấn đề được luận án tập trung giải quyết. 1.1.1 Các cơ chế phối hợp Các cơ chế phối hợp (Coordination Mechanisms), được đề xuất đầu tiên bởi Schmidt và cộng sự [24]. Đây là một cách tiếp cận nhằm khái quát hóa các công cụ được dùng để kết nối các hoạt động cộng tác. Do trong hoạt động cộng tác có sự tham gia của nhiều chủ thể (có thể là con người hoặc máy móc), nên nó cần có các công cụ phù hợp để trợ giúp cho việc chia sẻ, phối hợp giữa các chủ thể đó. Tổng quan về các cơ chế phối hợp này có thể được tìm thấy trong [25]. Việc nghiên cứu và phát triển các cơ chế phối hợp hướng tới Công việc cộng tác có trợ giúp của máy tính (Computer Supported Collaborative Work - CSCW) [38]. Cơ chế phối hợp được định nghĩa trong [24] như sau: "Cơ chế phối hợp có thể được định nghĩa như một giao thức (protocol), bao gồm tập hợp các quy ước tường minh và các thủ tục được quy định trước. Nó được hỗ trợ bởi một công cụ (artifact) riêng biệt với một định dạng tiêu chuẩn, quy định và cơ chế phân công công việc phối hợp các hoạt động phân tán nhằm giảm thiểu độ phức tạp của việc phối hợp." Một cơ chế phối hợp gồm có hai thành phần: - - Giao thức (protocol): là tập các thủ tục và quy ước nhằm quy định trách nhiệm của các thành viên tham gia vào công việc cộng tác, cũng như trình tự sử dụng công cụ giữa những thành viên đó. Công cụ (artifact): được các thành viên sử dụng để hiện thực hóa giao thức. Công cụ cần phải có khuôn dạng rõ ràng, để các thành viên tham gia công việc có thể hiểu và sử dụng nhằm trao đổi thông tin cho nhau, theo cách thức được quy định bởi giao thức trên. Cũng trong [24], Schmidt và cộng sự chia công việc thành hai loại: 16 - Công việc hợp tác (cooperative work): là công việc có sự tham gia của nhiều chủ thể, nên cũng cần có sự phối hợp giữa những thành viên đó. Công việc kết nối (articulation work): dùng để phối hợp công việc giữa các thành viên tham gia công việc cộng tác, nhằm đảm bảo sự trao đổi, chuyển tiếp công việc được diễn ra một cách chính xác và nhanh chóng. Một số công việc phổ biến thuộc loại này như: lập lịch, lập kế hoạch, phân chia công việc và giám sát tiến độ,v.v. Cách tiếp cận này, mặc dù đã xác định được vai trò và cấu trúc của các cơ chế phối hợp, nhưng vẫn còn tồn tại một số hạn chế cơ bản như sau: - - Thứ nhất: Việc phân chia công việc thành hai loại (công việc hợp tác và công việc kết nối), như trong nghiên cứu [24], là không rõ ràng và chỉ mang tính tương đối. Tùy vào ngữ cảnh, với cùng một công việc, có thể thuộc loại này hay loại kia. Ví dụ, danh sách kiểm tra (check-list) là việc hợp tác được sử dụng phổ biến trong rất nhiều ứng dụng, trong khi đó xây dựng danh sách kiểm tra lại là một công việc kết nối. Khi công việc cần sự tham gia và phối hợp của nhiều thành viên, nó lại là một công việc hợp tác. Trọng tâm của các cơ chế phối hợp là hỗ trợ cho các công việc kết nối, nên việc phân định không rõ ràng hai loại công việc sẽ gây khó khăn cho việc xác định một cơ chế phối hợp đúng và đầy đủ. Thứ hai: Cách tiếp cận này chưa làm rõ được vai trò của kế hoạch trong các công việc cộng tác. Đây là hệ quả của vấn đề thứ nhất, vì một kế hoạch dường như đóng cả hai vai trò: vừa là một công việc kết nối, lại có thể vừa là công việc hợp tác. Khi lên kế hoạch hoạt động cho một công việc nào đó, thông thường cần sự tham gia và thống nhất của đa số các thành viên tham gia, nên có thể sẽ là một công việc hợp tác. Nhưng đồng thời, sử dụng kế hoạch, các thành viên có thể phân chia và phối hợp các hoạt động để thực thi và hoàn thành kế hoạch. Do đó, lập kế hoạch cũng lại là một công việc kết nối. Một trong những mục tiêu nghiên cứu của luận án là phát triển một mô hình cho phép khắc phục những hạn chế trên, làm rõ vai trò của kế hoạch trong các hoạt động cộng tác. Mô hình kế hoạch, được đề xuất trong luận án dựa trên tiếp cận Lý thuyết Hoạt động, cho phép biểu diễn các kế hoạch với sự tham gia của các chủ thể thực hiện một số công việc (được gọi là hoạt động). Để tránh gây nhầm lẫn, trong mô hình này các công việc được phân chia theo một cách đơn giản và trực quan hơn: hoạt động đơn (có một chủ thể) và hoạt động tập thể (có nhiều chủ thể). Mặc dù được phân chia đơn giản hơn, nhưng các hoạt động trong mô hình này vẫn có thể biểu diễn được cả hai loại công việc như trong cách phân loại của Schmidt và cộng sự [24]. Chi tiết về mô hình này sẽ được trình bày cụ thể trong Chương 2. 1.1.2 Lý thuyết Hoạt động Giới thiệu Lý thuyết hoạt động (Activity Theory) đã có một lịch sử khá dài với khởi đầu là các nghiên cứu của ba nhà nghiên cứu theo trường phái lịch sử văn hóa (cultural-historical school) của ngành tâm lý học Nga là L. S. Vygotsky, A. N. Leont'ev và A. R. Luria, trong những năm 1920 và 1930. Tuy nhiên, cho đến gần đây, lý thuyết này lại thu hút được nhiều 17 sự chú ý trong một số lĩnh vực của công nghệ thông tin như giao tiếp người-máy (HumanComputer Interaction) [51], Công việc cộng tác có sự trợ giúp của máy tính (Computer Supported Collaborative Work) [20]. Trong ngữ cảnh của công việc cộng tác, Lý thuyết Hoạt động giúp giải thích rõ ràng hơn vai trò của việc lập kế hoạch công việc và mối quan hệ giữa việc lập kế hoạch công việc và bản thân công việc. Trong một số lĩnh vực như y tế, nghiên cứu khoa học, v.v., kế hoạch thực sự đóng vai trò trung tâm, bởi vì nếu không có kế hoạch, thì sẽ rất khó nhìn thấy được mục tiêu của công việc và biết được bằng cách nào đạt được mục tiêu một cách hiệu quả. Khái niệm hoạt động theo tiếp cận lý thuyết hoạt động T S O Hình 1-1: Sơ đồ một hoạt động. Một hoạt động gồm có chủ thể S (subject), đối tượng O (object), còn được gọi là khách thể mục tiêu và được trợ giúp trung gian bởi một công cụ T (tool) (xem Hình 1-1). Chủ thể có thể là người hay máy tham gia vào hoạt động và định hướng hoạt động hướng đến đối tượng. Một đối tượng có thể là một sản phẩm cụ thể nào đó, nhưng cũng có thể là một kế hoạch, một ý tưởng được các chủ thể chia sẻ, các thao tác hay chuyển đổi [51]. Công cụ có thể là một hệ thống máy tính, hay một ngôn ngữ. Hoạt động này được phân biệt với hoạt động khác qua đối tượng, thể hiện mục tiêu của hoạt động. Đối tượng có quan hệ với động cơ của hoạt động, do đó hoạt động của chủ thể sẽ tác động đến đối tượng. Ví dụ 1-1: Hoạt động Đóng-Mới(Thợ mộc, Dụng cụ, Sản phẩm) biểu diễn một hoạt động đóng mới một sản phẩm mộc, trong đó Chủ thể là Thợ mộc sẽ sử dụng Công cụ là các Dụng cụ mộc như gỗ, cưa, bào, v.v để tạo ra đối tượng là một sản phẩm mới như cái bàn, cái tủ, v.v. Các đặc tính của Hoạt động Mỗi hoạt động đều có ba đặc tính như sau: - - Hướng đối tượng/mục tiêu: đối tượng của một hoạt động gắn chặt với động cơ/mục tiêu của hoạt động đó. Mọi hoạt động đều có mục tiêu riêng, được biểu đạt tường minh hoặc ngầm định. Nhúng trong hoạt động tập thể: Theo Leont'ev [58] : “hoạt động của các cá nhân nằm trong hệ thống các quan hệ xã hội và sẽ không tồn tại nếu không có các quan hệ này”. Đặc tính này cung cấp một nền tảng quan trọng khi thảo luận về hoạt động công việc cộng tác (cooperative work activity). 18 - Có sự trợ giúp trung gian: bởi các công cụ:  Cho phép mở rộng chức năng của chủ thể.  Được phát triển trong quá trình thực thi hoạt động. Cấu trúc của Hoạt động Theo Leont'ev [58], hoạt động có ba mức phân cấp quan hệ với nhau về mặt chức năng: hoạt động, hành động và thao tác với ý nghĩa như sau: - - Hoạt động (activity): xác định các thành phần: chủ thể, đối tượng, động cơ và mục đích, và các công cụ có vai trò trợ giúp trung gian. Hành động (action): cho phép xác định cần phải làm gì để đạt được mục tiêu của hoạt động. Hành động có thể hiểu là các tiến trình hướng mục đích được tiến hành nhằm thu được các kết quả, phục vụ cho việc đạt được đối tượng mục tiêu của hoạt động. Thao tác (operation): là các tiến trình thực thi các hành động. Các thao tác cho phép thực hiện một cách tự động các hoạt động. Giảm tính động cơ Hoạt động Giảm tính khái quát Hành động Tăng tính động cơ Thao tác Tăng tính khái quát Hình 1-2: Sự chuyển đổi giữa các mức của hoạt động. Một điểm quan trọng là luôn có sự chuyển đổi giữa ba mức chức năng nêu trên (xem Hình 1-2) [20]. Để thực hiện được mục tiêu của hoạt động cần có các hành động thích hợp. Lý do phân chia các hoạt động thành các hành động xuất phát từ nhu cầu cần phân chia mục tiêu của hoạt động (ban đầu còn khá lớn, trừu tượng) thành các mục tiêu nhỏ (cụ thể hơn) để có thể phân bổ cho các chủ thể thích hợp. Mỗi hành động của hoạt động lại được chia nhỏ thành dãy các thao tác tương ứng để hoàn thành được mục tiêu riêng của chủ thể. Ví dụ 1-2 sau đây sẽ minh họa rõ hơn các mức của hoạt động và sự chuyển đổi này. Ví dụ 1-2: Hoạt động Sắp-xếp (Dịch vụ lưới, Dãy vào, Dãy ra) biểu diễn hành động cài đặt một dịch vụ lưới (grid service), dưới dạng một modul chương trình chạy trên môi trường lưới, có nhiệm vụ tiếp nhận một dãy vào (với vai trò như một công cụ) và tiến hành sắp xếp nó để thu được dãy ra đã được sắp xếp. Dãy ra này đóng vai trò là mục tiêu của hoạt động. Để thực hiện hoạt động này, cần một loạt các hành động trong quy trình cài đặt một dịch vụ lưới như: phân tích các dữ liệu vào/ra, thiết kế giải thuật, cài đặt dịch vụ, v.v. Mỗi hành động sẽ lại bao gồm một dãy các thao tác mà thường khá quen thuộc và thậm chí là đã được chuẩn hóa. Ví dụ hành động phân tích dữ liệu bao gồm các thao tác như mô hình hóa dữ liệu, xác định cấu trúc dữ liệu, v.v. 19 Có thể thấy việc phân chia thành ba mức như ở trên chỉ là tương đối. Điểm chính ở đây là hoạt động có cấu trúc lồng – một hoạt động có thể chứa các hoạt động con. Các hoạt động con này lại có thể được phân chia nhỏ, thành các hoạt động nhỏ hơn. Quá trình phân chia này tiếp diễn cho đến khi các hoạt động đủ nhỏ và đủ chi tiết, để có thể được thực thi bởi các chủ thể phù hợp. Đặc điểm này của hoạt động chưa được thể hiện rõ ràng trong Lý thuyết Hoạt động. Hạn chế này cũng là một trong những vấn đề được giải quyết khi đề xuất Mô hình Kế hoạch trong luận án. Hoạt động tập thể phân tán (Distributed Collective Activity) Do giới hạn nghiên cứu về công việc cộng tác, nên luận án quan tâm chủ yếu đến khía cạnh cộng tác theo tiếp cận lý thuyết hoạt động, đã được nghiên cứu trong hoạt động tập thể phân tán [32], [34]. Hoạt động tập thể là hoạt động có hai chủ thể trở lên (còn gọi là đồng chủ thể), có các đối tượng chung và các tiến trình do các chủ thể thực hiện phải liên lạc và điều phối với nhau. Các chủ thể tham gia phải có mục tiêu chung, gắn kết với một đối tượng chung. Các chủ thể phải hiểu các mục tiêu bộ phận chung của hành động và có các công cụ khác nhau để đạt được các mục tiêu bộ phận này. Có hai loại hoạt động tập thể: hoạt động cộng tác không có công cụ trợ giúp và hoạt động cần có công cụ trợ giúp (xem Hình 1-3) [20]. O O S1 S1 S2 S2 T b. Hoạt động tập thể có công cụ a. Hoạt động tập thể không có công cụ Hình 1-3: Hai loại hoạt động tập thể. Công cụ đóng vai trò cộng tác giữa các hành động trong hoạt động tập thể được gọi là Công cụ cộng tác (Collaborative Artifact - CA) [20]. Trong các hoạt động tập thể, có ba mức cộng tác được tổ chức theo cấu trúc phân cấp đã được xác định bởi Fichtner [34], Eugestrom [32], và Bardram [20] (xem Hình 1-4). - Hoạt động điều phối (Co-ordinated activity): đây là loại hoạt động có mức cộng tác thấp nhất, các chủ thể làm việc và phối hợp theo một kịch bản đã xác định. Các chủ 20 - - thể cùng làm việc với nhau để đạt được một mục tiêu chung, tuy rằng có thể cũng chưa biết rõ ngay từ đầu. Hoạt động hợp tác (Co-operative activity): đây là loại hoạt động có mức cộng tác cao hơn loại hoạt động điều phối. Các chủ thể gắn với đối tượng chung và do đó, chia sẻ mục tiêu của hoạt động. Các mục tiêu chung được áp đặt lên các hành động và các mục tiêu cá nhân của từng chủ thể. Mục tiêu chung chỉ có thể đạt được thông qua hợp tác. Trong hoạt động hợp tác, đối tượng mục tiêu đã cố định ngay từ đầu. Vần đề là thực hiện hoạt động như thế nào, do vậy phải xác định kịch bản cho nó. Ở đây, các công cụ đã có không phải xây dựng. Vấn đề là phát hiện các công cụ. Hoạt động đồng kiến thiết (Co-constructive activity): đây là loại hoạt động có mức cộng tác cao nhất. Trái ngược với hai mức trên, đối tượng mục tiêu của hoạt động mức này không cố định và thậm chí chưa tồn tại. Đối tượng mục tiêu đó cần phải được kiến thiết nhờ sự phối hợp của các chủ thể. Các hoạt động loại này thường ở mức tổ chức. 3. Hoạt động đồng kiến thiết 2. Hoạt động hợp tác 1. Hoạt động điều phối để xây dựng để xác định theo Đối tượng Kịch bản Kịch bản Hình 1-4: Các mức cộng tác trong các hoạt động tập thể. Có thể thấy trong Lý thuyết Hoạt động đã chỉ ra vai trò của Kịch bản trong hoạt động tập thể dưới dạng bản kế hoạch hành động, phân chia công việc cụ thể cho từng chủ thể thành viên và chỉ ra các bước cần thực hiện công việc được giao. Khi chưa có kịch bản này, hoạt động cũng chưa thực hiện được. Tuy nhiên, kịch bản trong tiếp cận Lý thuyết Hoạt động có một số hạn chế sau: - Thứ nhất: Chưa thể hiện được cấu trúc của kịch bản. Thực tế là kịch bản phải đóng vai trò bản kế hoạch bao gồm các hoạt động nhằm thực thi mục tiêu của kịch bản đó. Đồng thời, nó cũng chứa thông tin về thứ tự giữa các hoạt động. Những thông 21 - tin này đóng vai trò quyết định trong việc xác định các biện pháp phối hợp và thực thi các hoạt động trong kịch bản. Khắc phục hạn chế này cũng là một trong những mục tiêu nghiên cứu của luận án và đã được thể hiện trong Mô hình kế hoạch. Thứ hai: Biểu diễn các hoạt động, nhất là các hoạt động tập thể phức tạp có nhiều chủ thể tham gia, chưa được rõ ràng. Như đã trình bày trong phần Cấu trúc hoạt động ở trên, hoạt động có cấu trúc lồng, có thể chứa nhiều hoạt động con. Khi hoạt động có nhiều hoạt động con, giữa chúng tồn tại các ràng buộc như thứ tự thực hiện, chia sẻ dữ liệu, v.v. Do đó, không biểu diễn rõ ràng các ràng buộc này sẽ gây ra sự nhập nhằng trong logic của hoạt động và những khó khăn trong việc hỗ trợ thực thi hoạt động. Hạn chế này sẽ được luận án khắc phục nhờ sử dụng ngôn ngữ luồng công việc trong biểu diễn hoạt động. Chi tiết sẽ được trình bày trong Chương 2, phần 2.2. 1.1.3 Biểu diễn hoạt động bằng ngôn ngữ luồng công việc Quản lý luồng công việc là quá trình mô hình hóa và kiểm soát việc thực thi các tiến trình ứng dụng hay tiến trình nghiệp vụ trong nhiều lĩnh vực như khoa học, kỹ thuật, kinh doanh,v.v. nhằm mục đích tìm ra các tiến trình tối ưu hiệu quả nhất [78]. Việc nghiên cứu các hệ thống quản lý luồng công việc (WMS - Workflow Management Systems) thu hút được nhiều sự chú ý, vì nó cho phép kết hợp góc nhìn hướng dữ liệu với góc nhìn hướng tiến trình, trong đó các hoạt động và trình tự thực hiện chúng được mô hình hóa, được đặc tả, được thực thi và có kiểm soát một cách tự động [63]. Trong các hệ thống này, các tiến trình nghiệp vụ được mô tả bằng các luồng công việc, sử dụng một ngôn ngữ mô hình hóa luồng công việc (viết tắt là ngôn ngữ luồng công việc hay ngôn ngữ luồng). Nói cách khác, ngôn ngữ luồng giúp xây dựng các mô hình tiến trình biểu diễn cho các tiến trình nghiệp vụ. Ngôn ngữ luồng công việc cần mô tả được các thông tin liên quan đến luồng công việc trong các tiến trình nghiệp vụ, nhằm mục tiêu điều khiển và kiểm soát việc thực thi các tiến trình nghiệp vụ trong các hệ thống quản lý luồng công việc. Các thông tin liên quan trong luồng công việc thường không đồng nhất và bao gồm nhiều khía cạnh, từ mô tả cấu trúc của tiến trình nghiệp vụ, khía cạnh tổ chức và các chương trình ứng dụng, cho đến các dữ liệu chi tiết về môi trường thực thi tiến trình. Về bản chất, mỗi hoạt động cũng chính là một tiến trình nghiệp vụ, bao gồm một dãy các hành động để đạt được mục tiêu (hay đối tượng) nào đấy. Do đó, trong nghiên cứu của luận án, ngôn ngữ luồng được lựa chọn để biểu diễn cho các hoạt động. Cách tiếp cận này không chỉ cho phép biểu diễn khá đầy đủ các hoạt động trong kế hoạch, mà còn hỗ trợ khả năng chuyển đổi, thực thi các hoạt động này. Cụ thể hơn, hai ngôn ngữ luồng công việc tiêu biểu là BPMN (Business Process Modeling Notation) và BPEL (Business Process Execution Language) và các công nghệ liên quan được chọn sử dụng để biểu diễn các kế hoạch ở hai mức khác nhau. Điều lưu ý là BPMN được dùng để mô tả các kế hoạch ở mức trừu tượng (chưa thực thi được), còn BPEL được dùng để mô tả các kế hoạch ở mức chi tiết hơn (thực thi được). Chi tiết về việc biểu diễn này sẽ được trình bày trong Chương 2, phần 2.2. Phần 22 Phụ lục B sẽ trình bày chi tiết hơn về các ngôn ngữ luồng và các hệ thống quản lý luồng công việc. 1.2 Tính toán lưới 1.2.1 Sơ lược lịch sử phát triển Thuật ngữ lưới (Grid) xuất hiện vào giữa những năm 90 của thế kỷ trước để chỉ các hạ tầng tính toán phân tán, được phát triển để giải quyết một vấn đề cụ thể bài toán lưới, thông qua “chia sẻ tài nguyên cộng tác và giải quyết các vấn đề trong các tổ chức ảo, động và bao gồm nhiều thành viên” [52]. Việc chia sẻ ở đây không chỉ là trao đổi các tệp, mà còn cần truy nhập vào các tài nguyên như máy tính, phần mềm, dữ liệu,v.v., và chiến lược cộng tác môi giới tài nguyên (resource brokering). Việc chia sẻ này cũng cần phải được kiểm soát một cách chặt chẽ, giữa bên cung cấp tài nguyên (resource provider) và bên tiêu thụ tài nguyên (resource consumer) phân định rõ ràng và chi tiết: chia sẻ gì, ai chia sẻ và điều kiện chia sẻ. Tập hợp các cá nhân, tổ chức được phối hợp theo các luật chia sẻ như trên hình thành nên các Tổ chức ảo (virtual organization - VO) [52]. Các tổ chức ảo khác nhau nhiều về mục đích, phạm vi, cấu trúc,… nhưng đều có các yêu cầu chung như sau: - Cơ chế chia sẻ linh hoạt, từ client-server đến peer-to-peer. Mức độ kiểm soát chính xác và phức tạp cho các tài nguyên được chia sẻ: sử dụng truy nhập, ủy quyền, áp dụng các chính sách cục bộ hay toàn cục. Chủng loại tài nguyên đa dạng: tệp, chương trình, dữ liệu, mạng, thiết bị,v…v. Chế độ sử dụng: một người dùng, nhiều người dùng, chất lượng dịch vụ (QoS). Công nghệ tính toán lưới đã trải qua ba thế hệ [27]: - Thế hệ thứ nhất: Nhằm cung cấp tài nguyên tính toán cho các ứng dụng hiệu năng cao [27]. Hai dự án tiêu biểu là: FAFNER nhằm xác định nền tảng Siêu tính toán trên nền WEB và I-WAY nhằm tích hợp 10 mạng máy tính phân bố trên 17 trạm băng thông rộng trên nền ATM. - Thế hệ thứ hai: Tính toán lưới trở thành “một hạ tầng phân tán thiết yếu trên phạm vi toàn cầu mà có thể hỗ trợ các ứng dụng khác nhau yêu cầu về tính toán và dữ liệu trên phạm vi lớn” [27]. Rất nhiều hệ thống và công nghệ khác nhau đã được phát triển như: hạ tầng phần mềm (Globus Toolkit, Legion); hệ thống đối tượng phân tán (như CORBA, JINI, RMI); Các hệ điều phối tài nguyên và lập lịch ( như Condor, PBS, Storage Resource Broker,...); Grid Portals (như Hot Page, GridPort); các hệ tích hợp (như Cactus, Datagrid, UNICORE); Peer-2-Peer (như JXTA, Napster, Gnutella). - Thế hệ thứ ba: Đây là thế hệ lưới hiện tại, nhằm giải quyết các vấn đề một cách tự động và trên quy mô lớn, sử dụng các kiến trúc: hướng dịch vụ, dịch vụ Web để tạo ra các dịch vụ lưới. Sự phát triển của các kiến trúc hoàn chỉnh cho các ứng dụng 23 lưới có quy mô lớn đã dẫn đến sự ra đời của Kiến trúc Dịch vụ lưới Mở (Open Grid Service Architecture - OGSA) trong các Tổ chức Ảo (Virtual Organisations - VO). 1.2.2 Các kiến trúc lưới Kiến trúc lưới phân tầng (Layered Grid Architecture) Kiến trúc lưới đầu tiên đã được trình bày trong [52] (xem hình 1-5). Cột bên trái biểu diễn kiến trúc phân tầng, cột bên phải tóm tắt các chức năng chính của mỗi tầng. Kiến trúc này đề xuất các chức năng chính của các hệ thống lưới và phân chia thành năm tầng: Ứng dụng (Application), Tập thể (Collective), Tài nguyên (Resource), Kết nối (Connectivity) và Cơ cấu (Fabric). Hình 1-5: Kiến trúc lưới. Kiến trúc dịch vụ lưới mở (Open Grid Service Architecture) Với mục tiêu xây dựng một kiến trúc hoàn chỉnh hơn, Kiến trúc dịch vụ lưới mở (Open Grid Services Architecture - OGSA), đã được đề xuất và càng ngày càng được chấp nhận một cách rộng rãi [52] [53] xem Hình 1-6. Kiến trúc dịch vụ lưới mở là một trong số những sản phẩm của Diễn Đàn lưới Mở (Open Grid Forum - OGF) nhằm giải quyết nhu cầu chuẩn hóa các hệ thống lưới. Như đã được trình bày trong [53] (trang 4), “Chìa khóa cho việc triển khai tầm nhìn lưới là sự chuẩn hóa, nhờ đó các thành phần khác nhau cấu thành nên môi trường tính toán hiện đại có thể được phát hiện, truy nhập, cấp phát, giám sát,.v.v.” Kiến trúc này định nghĩa một tập các tính năng và hành vi cốt lõi của các hệ thống lưới. OGSA phù hợp với công nghệ dịch 24 vụ Web qua việc sử dụng WSDL (Web Services Description Language: ngôn ngữ mô tả dịch vụ Web) để xây dựng các dịch vụ có khả năng tự mô tả và khám phá được. Loại dịch vụ mới này được gọi là dịch vụ lưới (Grid service). OGSA cũng bổ sung một số mở rộng cần thiết như: hỗ trợ các thông tin trạng thái, quản lý vòng đời, báo hiệu, quản lý chính sách và sự bảo mật. Kiến trúc OGSA dựa trên nền tảng kiến trúc hướng dịch vụ (Service Oriented Architecture) và dịch vụ WEB. Một trong những vấn đề trung tâm của kiến trúc lưới là sự tương thông (interoperability), bởi vì mọi tổ chức ảo (Virtual Organization) trong các ứng dụng lưới cần phải thiết lập sự cộng tác và truyền thông giữa các thành viên. Do đó, kiến trúc lưới thực sự là một kiến trúc giao thức (protocol architecture). Điều này dẫn đến yêu cầu phát triển kiến trúc dựa trên các chuẩn nhằm tăng cường khả năng mở rộng, khả chuyển và chia sẻ code chương trình [52]. Sự ra đời của chuẩn OGSA này đã đáp ứng các yêu cầu trên nhờ việc kết hợp các công nghệ lưới và dịch vụ WEB. Trong thực tế, OGSA bao gồm các dịch vụ lưới, chia thành các nhóm. Phiên bản 1.5 của OGSA [53] có các nhóm dịch vụ như sau (xem Hình 1-6): - - Dịch vụ hạ tầng (Infrastructure Services): cung cấp các chức năng cơ bản nhất của OGSA, dịch vụ WEB: định danh, báo hiệu, giao tác và phối hợp. Dịch vụ quản lý tài nguyên (Resource Management Services): cung cấp chức năng quản lý các loại tài nguyên khác nhau. Dịch vụ dữ liệu (Data Services): cung cấp chức năng: truy nhập, cập nhật các tài nguyên dữ liệu, di chuyển dữ liệu giữa các tài nguyên, quản lý các siêu dữ liệu (metadata) Dịch vụ thông tin (Information Services): cung cấp chức năng: truy nhập, xử lý thông tin về tài nguyên và dịch vụ trong môi trường lưới. Dịch vụ quản lý thực thi (Execution Management Services): cung cấp chức năng như: khởi tạo, chạy và kết thúc các đơn vị công việc (các ứng dụng lưới). Dịch vụ an ninh (Security Services): cung cấp chức năng như: xác thực (authentication), xác quyền (authorization), đảm bảo tính riêng tư (privacy). Dịch vụ tự quản (Self-Management Services): cung cấp chức năng như tự cấu hình (self-configuration), tự điều trị (self-healing ), tự tối ưu (self-optimizing). 25 Dịch vụ QL tài nguyên Dịch vụ QL thực thi Dịch vụ thông tin Dịch vụ dữ liệu Dịch vụ an ninh Dịch vụ tự quản Dịch vụ hạ tầng Hình 1-6: Kiến trúc Dịch Vụ lưới Mở (OGSA). Cấu trúc của một Tổ Chức Ảo (Virtual Organization) Tổ chức ảo (VO) được định nghĩa trong [52] như “một tập các cá nhân và/hoặc các tổ chức tham gia vào việc chia sẻ tài nguyên trong các ứng dụng lưới.” Từ định nghĩa này, cấu trúc của tổ chức ảo được biểu diễn như trong Hình 1-7. Hình 1-7: Cấu trúc của tổ chức ảo (Virtual Organization). Các tổ chức ảo có thể khác nhau về hoạt động, quy mô, tổ chức, v.v nhưng chúng đều có một số đặc tính chung như sau: - Gồm các thành viên tin tưởng lẫn nhau, tuy với mức độ quan hệ khác nhau nhưng có cùng mong muốn chia sẻ các tài nguyên để thực thi một công việc nào đó. Việc chia sẻ này không chỉ đơn thuần là chia sẻ tệp, mà còn có thể bao gồm việc truy nhập vào các tài nguyên khác. 26 - - - Việc chia sẻ tài nguyên là có điều kiện: các chủ tài nguyên cho phép các tài nguyên đó được sẵn sàng với một số ràng buộc cụ thể: khi nào, ở đâu và tài nguyên nào. Để cài đặt các ràng buộc này, cần phải có các phương thức mô tả. Các quan hệ chia sẻ có thể thay đổi theo thời gian như các tài nguyên tham gia hay quyền truy nhập. Quan hệ này cũng không nhất thiết phải chỉ rõ các cá nhân có danh tính, mà ngầm xác định theo chính sách điều hành và cơ chế truy nhập. Quan hệ chia sẻ không đơn thuần là client-server mà thường là peer-to-peer. Quan hệ chia sẻ cho phép phối hợp trên nhiều tài nguyên, trong đó mỗi tài nguyên lại được sở hữu bởi các tổ chức khác nhau. Các ứng dụng lưới được phát triển và được thực thi trong một tổ chức ảo, bao gồm các cá nhân và tổ chức thuộc nhiều lĩnh vực mạng và ứng dụng khác nhau. Mỗi lĩnh vực có tài nguyên riêng, cũng như chính sách quản lý tài nguyên riêng. 1.2.3 Hạ tầng lưới Hiện nay, có khá nhiều hạ tầng lưới đã được phát triển như Globus Toolkit, Legion, Unicore, gLite, v.v. Do tính phức tạp của việc tìm hiểu và triển khai hạ tầng lưới, nên trong luận án sẽ chọn Globus Toolkit (GT) đã được lựa chọn. Có hai lý do giải thích cho sự lựa chọn này: - Thứ nhất: đây là hạ tầng đang được triển khai cài đặt trong Viện quốc tế về khoa học và kỹ thuật tính toán (ICSE), Đai học Bách Khoa Hà Nội nơi luận án thực hiện nghiên cứu. - Thứ hai: hạ tầng này hỗ trợ đầy đủ cho các yêu cầu của việc triển khai khung cộng tác, nhất là các hạ tầng tính toán và khả năng hỗ trợ hướng dịch vụ được triển khai từ phiên bản 4 (Globus Toolkit 4 – GT4). Chi tiết về phần thiết kế và triển khai khung cộng tác trên môi trường lưới GT4 sẽ được trình bày ở Chương 4. Trong phần sau, luận án sẽ giới thiệu sơ bộ về môi trường này. Globus Toolkit Từ cuối những năm 90, bộ công cụ Globus Toolkit (GT) [36] đã được phát triển như một hạ tầng mã nguồn mở nhằm hỗ trợ sự phát triển của các ứng dụng lưới hướng dịch vụ. Phiên bản được sử dụng trong luận án là bản 4.0 (thường được gọi tắt là GT4), giải quyết được những vấn đề thông dụng nhất của mọi ứng dụng lưới như an ninh, quản lý tài nguyên, quản lý thực thi, truyền dữ liệu, quản lý thông tin, v.v. Do sử dụng mã nguồn mở, cùng với khả năng trợ giúp kỹ thuật tốt, GT4 ngày càng trở nên một lựa chọn tốt cho những nhà phát triển các ứng dụng lưới, cũng như các hạ tầng lưới khác. GT4 là một công cụ hạ tầng lưới cài đặt chuẩn WSRF và kiến trúc OGSA. Tuy nhiên, GT4 có hạn chế là chỉ chay trên nền Linux. Trong Hình 1-8 là so sánh các lớp của OGSA với các thành phần của GT4. Kiến trúc của GT4 bao gồm ba thành phần chính: 27 - Các dịch vụ hạ tầng: Đây là thành phần chính của kiến trúc này. Được xây dựng theo kiến trúc hướng dịch vụ (SOA) và dịch vụ WEB. Các dịch vụ này được nhóm theo chức năng như Quản lý thực thi (GRAM), Truy nhập và truyền dữ liệu (OGSA-DAI, GridFTP, RFT), Giám sát và khám phá dịch vụ (Index, Trigger, WebMDS), An ninh (MyProxy, SimpleCA). Dịch vụ QL thực thi Dịch vụ QL tài nguyên Dịch vụ thông tin Dịch vụ dữ liệu Workspace Mgmt Community Scheduling Framework Grid Telecontrol Protocol Grid Resource Allocation & Management WebMDS GridFTP Index Reliable File Transfer Trigger Data Replication Data Access & Integration Delegation Credential Management Dịch vụ tự quản Dịch vụ an ninh Community Authentication Authorizatio OGSA Globus Toolkit 4 Hình 1-8: Quan hệ giữa OGSA và Globus Toolkit 4. - - Các Container: ba container được sử dụng để chứa các dịch vụ do người dùng định nghĩa mà có thể được viết bằng một trong các ngôn ngữ lập trình Java, C hoặc Python. Các container này hỗ trợ một số đặc tả dịch vụ WEB (Web service specifications) như WSRF, WS-Notification và WS-Security. Các thư viện cho client: các thư viện này cho phép nhà phát triển ứng dụng viết các chương trình client bằng Java, C và Python. Các chương trình này có thể gọi các thao tác của các dịch vụ (gồm các dịch vụ hạ tầng hoặc dịch vụ do người dùng định nghĩa). Các chức năng chính của mỗi thành phần của GT4 như sau: - DAI (Data Access Integration): cung cấp khả năng truy nhập và truy vấn đến cơ sở dữ liệu quan hệ và XML. GRAM (Grid Resource Allocation & Management): Cung cấp giao diện dịch vụ WEB quản lý việc thực thi các công việc tính toán trên các máy tính ở xa: khởi tạo, chạy và giám sát trạng thái của các công việc. 28 - GridFTP & RFT (Grid File Transfer Protocol and Reliable File Transfer): GridFTP cho phép các client thực hiện việc di chuyển dữ liệu một cách tin cậy, an toàn và có hiệu năng cao nhờ các thư viện và các công cụ. Qua mạng diện rộng (WAN - Wide Area Network), tốc độ truyền dữ liệu đầu cuối của nó có thể đạt đến 27Gbit/giây. Trong khi đó, dịch vụ RFT quản lý một cách tin cậy việc truyền đồng thời nhiều GridFTP. - VOMS (VO Management System): Hệ thống này là một phần mềm độc lập với công cụ GT4. Hệ thống này quản lý dữ liệu ủy quyền trong việc cộng tác trong khuôn khổ các tổ chức ảo, cung cấp một cơ sở dữ liệu về vai trò và khả năng của người dùng. Ngoài ra cũng cung cấp tập các công cụ truy nhập và thao tác trên cơ sở dữ liệu đó. Nội dung của cơ sở dữ liệu được sử dụng để tạo ra các thông tin chứng thực lưới cho người dùng. 1.3 Khung lưới cộng tác Phần này giới thiệu về khái niệm khung cộng tác và một số khái niệm liên quan như khung lưới cộng tác, khung lưới cộng tác đa dụng. 1.3.1 Khung cộng tác Khung cộng tác (Collaborative Framework) là thuật ngữ có thể được diễn giải theo nhiều cách khác nhau: hệ thống, công cụ hỗ trợ cộng tác; bộ tiêu chuẩn để đánh giá các hệ thống cộng tác [29]; một hiệp định hợp tác [64]. Trong luận án này, khung cộng tác được sử dụng với ý nghĩa: một hệ thống hay công cụ hỗ trợ cộng tác. Khung cộng tác có thể được sử dụng độc lập hay tích hợp với hệ thống khác để hỗ trợ việc xây dựng các ứng dụng yêu cầu khả năng cộng tác. Như đã thấy trong phần 1.1, các tiếp cận liên quan đến cộng tác, nhu cầu và các loại hình cộng tác là rất đa dạng. Từ việc chia sẻ, trao đổi trực tiếp các tài nguyên chung giữa các chủ thể, cho đến nhu cầu phải có một bản kế hoạch hành động chung. Với bản kế hoạch đầy đủ, các chủ thể thành viên không những biết được những tài nguyên cần chia sẻ, mà còn biết được cách phối hợp các công việc và sử dụng các tài nguyên như thế nào. Ngoài ra, các tài nguyên khác nhau lại có thể chia sẻ và trao đổi theo cách khác nhau (ví như việc chia sẻ tệp dữ liệu là khác với việc chia sẻ tài nguyên tính toán). Điều này càng làm tăng tính đa dạng và phức tạp của các khung cộng tác. Cũng do tính đa dạng của khung cộng tác, có nhiều cách phân loại khác nhau. Ở đây, luận án dựa vào hai tiêu chí phân loại: - Theo lĩnh vực ứng dụng: theo tiêu chí này có một số nhóm sau: o Nhóm 1 - Hệ thống hỗ trợ làm việc nhóm: đây là nhóm các khung cộng tác được phát triển đầu tiên, với trọng tâm là các công cụ hỗ trợ việc trao đổi và chia sẻ trong nhóm, như trao đổi email, lịch làm việc, v.v. Đại diện cho nhóm này là hệ thống Lotus Notes/Domino (sau này đã được chuyển thành IBM Notes/Domino); 29 - o Nhóm 2 - Hệ thống quản trị nội dung: chính là khung cộng tác thuộc nhóm 1 được bổ sung thêm cơ chế chia sẻ các nội dung số như tài liệu, hình ảnh, âm thanh; Các hệ thống tiêu biểu cho nhóm này bao gồm Xerox DocuShare, Moodle; o Nhóm 3 - Hệ thống công việc cộng tác có trợ giúp của máy tính: được phát triển từ nhóm một và hai bổ sung thêm các cơ chế phối hợp, phỏng theo các loại hình cộng tác trong thực tế. Một giới thiệu khái quát về loại hệ thống này có thể được tìm thấy trong [80]; o Nhóm 4 - Hệ thống luồng công việc: được phát triển từ nhóm 3, bổ sung thêm khả năng làm việc theo một kịch bản cho trước, được gọi là luồng công việc. Việc xây dựng luồng công việc thường được thực hiện bằng ngôn ngữ luồng công việc. o Nhóm 5 - Khung lưới cộng tác (Grid Collaborative Framework): được phát triển từ các nhóm ở trên, tích hợp thêm môi trường tính toán lưới. Để tăng cường khả năng cộng tác, các khung cộng tác tìm cách kếp hợp các khả năng cộng tác của các hệ thống hiện có. Như đã giới thiệu về tính toán lưới, bản thân các hạ tầng Tính toán lưới là các khung cộng tác đa dụng, với sự hỗ trợ chia sẻ nhiều loại tài nguyên khác nhau, ở nhiều mức độ chia sẻ khác nhau. Chính vì vậy, việc tìm cách kết hợp môi trường này vào trong các khung cộng tác để tăng cường khả năng cộng tác là một lựa chọn phù hợp. Theo mục đích phát triển, theo tiêu chí này có hai nhóm sau: o Khung cộng tác chuyên biệt: là khung cộng tác nhằm trực tiếp vào hỗ trợ một loại ứng dụng cộng tác chuyên biệt nào đó. Cách tiếp cận trong việc phát triển các khung loại này là tập trung hỗ trợ các khả năng cộng tác đặc thù cho các tài nguyên chuyên biệt. Ví dụ, hướng vào các ứng dụng trong y tế PATIENT SCHEDULER [20] ; GCF-MD hướng vào các ứng dụng cho thiết bị di động [88]. o Khung cộng tác đa dụng: loại khung này không hướng vào loại ứng dụng cụ thể nào, cho phép hỗ trợ các loại hình cộng tác khác nhau, trong đó, khả năng mở rộng người dùng có thể định nghĩa các loại hình cộng tác trên cơ sở các loại hình hiện có, cũng được quan tâm. Đây là loại khung cộng tác được luận án tập trung trong nghiên cứu nhằm xây dựng một khung cộng tác có thể hỗ trợ nhiều loại ứng dụng lưới khác nhau. Trong phần sau, luận án sẽ giới thiệu tóm tắt về các khung lưới cộng tác hiện có, phân tích các hạn chế tồn tại, để từ đó xác định rõ hơn các mục tiêu nghiên cứu của luận án. Để tiện cho việc xem xét, các khung này sẽ phân thành hai nhóm: nhóm đầu tiên các khung cộng tác không có hỗ trợ ngôn ngữ luồng công việc và khung có hỗ trợ các ngôn ngữ luồng công việc. 30 1.3.2 Các khung lưới cộng tác không có hỗ trợ ngôn ngữ luồng công việc OCGSA Kiến trúc OCGSA (Open Collaborative Grid Service Architecture – Kiến trúc dịch vụ lưới cộng tác mở) [56] hướng tới cung cấp một khung chung cho các ứng dụng cộng tác. Trong kiến trúc này, khái niệm dịch vụ lưới trong OGSA [52] (như một dịch vụ mức thấp) được mở rộng thành dịch vụ lưới cộng tác (dịch vụ mức cao), bằng việc mở rộng portType của dịch vụ lưới với siêu dữ liệu (metadata) cho việc quản lý nhóm và an toàn. Song song với đó, cơ chế báo hiệu cũng được mở rộng với khả năng định nghĩa trước các chủ đề báo hiệu. Một thành phần mới của OCGSA so với OGSA là dịch vụ lưu trữ sự kiện (Event Archiving service), có trách nhiệm quản lý các thông báo/các bản tin trao đổi giữa những người dùng/nhóm người dùng. Tuy vậy, các mở rộng trong OCGSA vẫn chưa đáp ứng được yêu cầu của các ứng dụng cộng tác trong thực tế, do còn thiếu hỗ trợ các cơ chế điều phối cụ thể và rõ ràng. Hơn nữa, kiến trúc này chỉ đưa ra mức cơ bản, mà chưa mô tả các cơ chế phù hợp cụ thể hỗ trợ sự cộng tác thực tế, dẫn đến khó áp dụng được trong việc phát triển các khung hay ứng dụng cộng tác lưới thực tế. Grid-enabled large scale (LAGrid) Khung cộng tác dựa trên lưới này [105] được phát triển nhằm xây dựng một môi trường cộng tác có khả năng sử dụng lưới có quy mô lớn, hỗ trợ người dùng cộng tác với các đặc điểm chính sau: - Quy mô lớn (theo cả chiều rộng và chiều sâu, với cấu trúc phân cấp) Cơ chế phối hợp khác nhau (đồng bộ/không đồng bộ, trong nội bộ nhóm/giữa các nhóm). Các cơ chế điều phối khác nhau (tường minh/ngầm định/ngẫu hứng). Tích hợp các cơ chế điều phối. Các cấu trúc cộng tác tĩnh (được xác định trước khi cộng tác), và động (xác định khi đang cộng tác). Mặc dù khung loại này hỗ trợ phát triển môi trường cộng tác quy mô lớn, nhưng lại không hỗ trợ các tình huống theo kịch bản, dưới dạng kế hoạch làm việc trong các tiến trình. Do thiếu kế hoạch, nên rất khó quản lý các hoạt động của các tiến trình. Điều này có thể dẫn đến việc thực hiện tiến trình không hiệu quả và không thể kiểm soát được. Khung cộng tác được đề xuất trong luận án có mục tiêu khá giống với khung cộng tác này, nhưng dựa trên cách tiếp cận khác, dựa trên kiến trúc mở, hướng dịch vụ (SOA Service Oriented Architecture), dịch vụ lưới của kiến trúc OGSA, nhằm nâng cao tính mở và khả năng mở rộng. 31 Collaborative Design Collaborative Design Grid (CDG) [106] là khung cho phép giải quyết hai vấn đề trong cộng tác: chia sẻ tài nguyên và cộng tác phân tán về mặt địa lý. Kiến trúc khung này dựa trên kiến trúc OGSA, được cài đặt bằng các dịch vụ lưới trong Globus Tookit 3. Thiết kế kiến trúc các CDG dựa trên ba công nghệ chính: Thiết kế cộng tác Có trợ giúp của Máy tính, tính toán lưới và cổng thông tin Web. Tuy nhiên, kiến trúc CDG có một số hạn chế. Thứ nhất, nó sử dụng Globus Toolkit phiên bản 3 (GT3) chưa hỗ trợ đầy đủ các tiêu chuẩn lưới như dịch vụ lưới và kiến trúc OGSA. Thứ hai, CDG chưa hỗ trợ các công việc cộng tác thực hiện có kịch bản, không có các kế hoạch làm việc. Khung lưới cộng tác cho các thiết bị di động (GCF - MD) Khung lưới cộng tác cho các thiết bị di động (Grid-based Collaborative Framework for Mobile Devices - GCF-MD) [88] cho phép các thiết bị di động có thể làm việc cộng tác với nhau để giải quyết các bài toán có khối lượng tính toán lớn. Để quản lý việc thực thi các công việc, đa số các hệ thống lưới sử dụng hạ tầng lưới như Globus Toolkit hay Condor. Tuy nhiên, cho đến nay, các hạ tầng lưới này chưa phù hợp với các hệ thống lưới “hạng nhẹ” (light-weight grid systems) như lưới di động (mobile grids) hay lưới cảm biến (sensor grids), do đòi hỏi cao cả về khả năng xử lý và dung lượng bộ nhớ. Do đó, GCF-MD phải xây dựng hạ tầng lưới bao gồm hai thành phần chính: Brokering Service and Keep-alive Server. Hạn chế chủ yếu của khung GCF-MD là nó không tuân theo cách tiếp cận của kiến trúc hướng dịch vụ (SOA), khả năng hỗ trợ dịch vụ WEB, dịch vụ lưới. Khung lưới cộng tác được xây dựng trong luận án sẽ đi theo cách tiếp cận này, để có khả năng mở và mềm dẻo hơn. PATIENT SCHEDULER Công cụ này [20] là một khuôn mẫu được phát triển qua dự án SAIK, cải thiện việc phối hợp và điều phối trên mạng máy tính trong điều trị cho các bệnh nhân. Tuy nhiên, đây mới chỉ là một mẫu thử, và mới chỉ áp dụng được trong lĩnh vực y tế. SPRING Khung lưới các cảm biến [42] SPRING (Scalable Proxy-based aRchItecture for seNsor Grid) được thiết kế theo cách tiếp cận sử dụng một proxy, được gọi là Proxy Mạng Cảm biến Không dây. Proxy này hoạt động như một giao diện giữa hạ tầng lưới và một WSN. Tuy nhiên, khung này không có khả năng hỗ trợ thực thi các kế hoạch. Khung tính toán dựa trên hoạt động (ABC) Được đề xuất trong các nghiên cứu [22] [21], khung tính toán dựa trên hoạt động (Activity-Based Computing) nhằm hỗ trợ hoạt động di động, cộng tác và khẩn cấp, như các hoạt động điều trị y tế. Thực thể cơ bản nhất của khung này là hoạt động tính toán (computational activity), sự kết hợp của các dịch vụ, tài nguyên, công cụ và người dùng có 32 liên quan mật thiết đến một hoạt động nào đó. Khung này cung cấp Hạ tầng tính toán dựa trên hoạt động với mục đích hỗ trợ người dùng quản lý các hoạt động tính toán. Nghiên cứu của luận án tuy có cùng tiếp cận, sử dụng lý thuyết hoạt động, nhưng lại đi theo một cách tiếp cận khác nhằm khắc phục hạn chế cơ bản của lý thuyết hoạt động thiếu khả năng biểu diễn tường minh kế hoạch và hỗ trợ quá trình lập kế hoạch. Do đó, trong nghiên cứu của luận án sẽ bổ sung các mô hình, ngôn ngữ mô tả và môi trường thực thi để khắc phục các hạn chế đó. 1.3.3 Các khung lưới cộng tác có hỗ trợ ngôn ngữ luồng công việc Trong số các ngôn ngữ luồng hiện có, Business Process Execution Language (BPEL) đã nhận được sự chú ý và chấp nhận nhiều nhất để kết hợp các ứng dụng dựa trên các thành phần (component based applications). Lý do chính là BPEL cho phép kết hợp của hai ngôn ngữ luồng: XLANG (của hãng Microsoft) và Workflow (của hãng IBM) thông qua kết hợp các dịch vụ WEB hiện có thành các dịch vụ WEB hoặc ứng dụng phức tạp hơn. Nhiều công cụ hỗ trợ BPEL đã và đang được phát triển như các bộ soạn thảo, các engine thực thi (enactment engines), v,v. Do đó, nghiên cứu của luận án tập trung vào các khung có hỗ trợ BPEL. Các khung có hỗ trợ BPEL CGPCE Trong CGPCE (Collaborative Grid Process Creation Environment – Môi trường tạo tiến trình lưới cộng tác) [94], [95], BPEL được sử dụng để biểu diễn và soạn thảo tiến trình ảo, cho phép nhiều người dùng phân tán có thể cộng tác với nhau để thiết kế và chạy các tiến trình. Một mở rộng lưới của BPEL, gọi là Grid-For-Each (GFE), được đề xuất và cài đặt nhằm tăng cường việc thực thi song song các hoạt động BPEL một tiến trình lưới. Trong tài liệu [95], các chi tiết của mở rộng này (giải pháp và cài đặt) đã được trình bày. Lý do chính là do BPEL 1.1 không hỗ trợ các dịch vụ WEB có trạng thái, trong khi đó đa số các dịch vụ lưới là có trạng thái. Giải pháp để khắc phục hạn chế này là đưa vào một hoạt động mới trong BPEL gọi là gridInvoke. Hệ thống GFE có một số hạn chế. Thứ nhất, việc cộng tác hoàn toàn dựa trên Eclipse Communication Framework (ECF), kiến trúc chỉ hỗ trợ các cộng tác đa năng (General Purpose Collaboration). Do vậy, để hữu dụng với các ứng dụng cộng tác lưới, sẽ mất rất nhiều thời gian và công sức. Thứ hai, hệ thống không tuân theo tiếp cận hướng dịch vụ (SOA), và điều này sẽ làm hạn chế tính mềm dẻo trong việc phát triển các ứng dụng lưới. Collaborative BPEL Design Tool with Rich Internet Application Công cụ này [40] giải quyết được khá nhiều vấn đề khó khăn khi soạn thảo thiết kế cộng tác (collaborative design editor) như: khả năng WYSIWIS (What You See Is What I See), gia nhập muộn (late joining), cơ chế khóa (locking mechanisms) kiểm soát tính cố kết của nội dung thiết kế. Tuy nhiên, công cụ này chưa quan tâm đến các dịch vụ lưới, cũng như cơ chế để thực thi dịch vụ luôn ở mức thiết kế chi tiết. Grid Service Composition in BPEL 33 Trong các nghiên cứu [71], [72], các tác giả đã đề cập vấn đề sử dụng BPEL kết hợp với các dịch vụ lưới: Giải pháp được áp dụng là kết hợp các dịch vụ lưới theo chuẩn WSRF trong các ứng dụng tin học y sinh. Hạn chế chủ yếu của hệ thống này là chỉ tập trung vào việc kết hợp các dịch vụ lưới, không quan tâm đến việc cộng tác của nhiều người dùng khi thực hiện công việc. Khung hỗ trợ ngôn ngữ luồng khác GridCole GridCole [67] là một hệ thống E-learning cộng tác có hỗ trợ việc thực hiện các tình huống học theo kịch bản, trong đó mỗi tình huống đó bao gồm một dãy các hoạt động. Hơn nữa, với khả năng tùy chỉnh, người dùng cuối của hệ thống (những giảng viên và sinh viên) có thể tích hợp các công cụ bên ngoài vào trong tình huống học. Sử dụng cách tiếp cận dịch vụ lưới cho phép sự tích hợp các loại công cụ khác nhau, thậm chí là với các yêu cầu về siêu máy tính hay các phần cứng chuyên dụng. Trong hệ thống này, đặc tả IMS Learning Design (IMS-LD) được sử dụng để mô tả các tình huống học. Có hai loại công cụ bên ngoài trong GridCole là cá nhân và cộng tác, trong đó, các công cụ cộng tác sẽ được sử dụng để điều phối các hoạt động bên trong mỗi tình huống. Mô tả của các tình huống học cộng tác là một bài học theo đặc tả IMS-LD. Hai loại bài học được sử dụng: hoàn chỉnh và không hoàn chỉnh. Các bài học hoàn chỉnh là các bài học chứa tất cả các thông tin cần thiết cho việc tích hợp các công cụ trong giai đoạn thực thi các tình huống học. Trái lại, các bài học không hoàn chỉnh không có những thông tin như vậy, chỉ có các mô tả chung về các công cụ cần có. Do đó, các bài học không hoàn chỉnh chưa thể được thực thi chừng nào chúng còn chưa được chuyển đối sang bài học hoàn chỉnh. Hạn chế chủ yếu của hệ thống là không có sự hỗ trợ kế hoạch. Các bài học không hoàn chỉnh có thể đóng vai trò của các kế hoạch, nhưng vẫn không phải là các kế hoạch độc lập. 1.4 Các giải pháp thực thi kế hoạch trên lưới Tiếp cận của luận án hướng đến việc biểu diễn các hoạt động trong kế hoạch bằng ngôn ngữ luồng công việc. Cụ thể hơn là biểu diễn bằng BPEL cho các hoạt động ở mức thực thi. Vì vậy phần này sẽ xem xét các kỹ thuật hiện nay để có thể thực thi được các tiến trình BPEL trong môi trường lưới. BPEL được khai thác thành công nhờ khả năng kết hợp các dịch vụ web trong việc mô tả luồng công việc phục vụ các ứng dụng doanh nghiệp. Hướng đến một áp dụng tương tự cho môi trường lưới, một số nghiên cứu sử dụng BPEL để kết hợp các dịch vụ lưới trong các công việc có cấu trúc và mức độ cao hơn như các luồng lưới. Tuy nhiên, do bản tính có trạng thái của dịch vụ lưới, BPEL và các engine của nó không thể được khai thác trực tiếp nếu không có các tính năng bổ sung. Trong thời gian gần đây, nhiều nỗ lực trong các nghiên cứu nhằm cố gắng giải quyết vấn đề này. Một số đề xuất đã được đưa ra cho phép gọi các dịch vụ lưới từ BPEL [95], [71], dành riêng cho ActiveBPEL engine. Với ODE [75], một BPEL engine mã nguồn mở 34 khá phổ biến, hiện tại chưa thấy một giải pháp cụ thể nào. Do đó, luận án tập trung vào thực hiện các dịch vụ lưới trong ODE engine. Cụ thể, quá trình thực hiện sẽ gồm hai bước: - Bước 1: Phân tích cơ chế ODE gọi các dịch vụ thực hiện tiến trình; Bước 2: Đề xuất giải pháp thực tiễn cho phép ODE có khả năng cung cấp các dịch vụ lưới. Dịch vụ lưới là một dịch vụ Web có trạng thái, kết hợp với các tài nguyên cố kết. Mỗi tài nguyên có ID riêng, được gọi là một Resource Key (Khóa Tài Nguyên). Sự kết hợp của địa chỉ dịch vụ lưới và tài nguyên tương ứng xác định một Tham chiếu Điểm cuối (endpoint reference- EPR). Thông thường, giá trị của địa chỉ dịch vụ lưới là tĩnh, được xác định trước khi chạy dịch vụ. Tuy nhiên, giá trị của khóa tài nguyên lại động. Điều này gây ra khó khăn cho ODE khi xử lý dịch vụ lưới. Các cách tiếp cận có thể dùng để giải quyết vấn đề này bao gồm: - - Mở rộng BPEL bằng cách bổ sung thêm các hoạt động mới [95] vào trong BPEL chuẩn. Trong số các hoạt động này, có một hoạt động (được gọi là gridCreateResource-Invoke) được dùng để lấy EPR, một hoạt động khác (được gọi là GridInvoke) được dùng để gọi các thao tác của dịch vụ lưới. Bổ sung thêm một thao tác cho dịch vụ lưới như được đề xuất trong [71], [72]. Thao tác này sẽ trả về EPR của một thể hiện của dịch vụ lưới đó (nên thao tác đó thường được gọi là CreateResource). Rõ ràng là việc mở rộng BPEL không phải là một việc đơn giản, đòi hỏi nhiều thay đổi trong engine BPEL chuẩn, từ việc biên dịch các tiến trình BPEL cho đến cài đặt các hành động mới. Nghiên cứu của luận án sẽ tập trung vào việc bổ sung thao tác cho dịch vụ lưới do tiềm năng cung cấp các giải pháp nhanh gọn hơn và tốt hơn. 1.5 Quá trình khai thác tiến trình BPEL Trong thời gian gần đây, BPEL đang trở thành một ngôn ngữ được chấp nhận một cách rộng rãi để cấu thành các tiến trình nghiệp vụ mới từ các Web service. Các tiến trình BPEL, bản thân cũng là các Web service, có thể được sử dụng để cấu thành các tiến trình nghiệp vụ mới. Ưu điểm của tiến trình BPEL so với các Web service thông thường, đó là một tiến trình BPEL cho phép sự phối hợp giữa các Web service bên trong và bên ngoài theo các yêu cầu nghiệp vụ. Tuy nhiên, các tiến trình BPEL không thể khai thác và chạy bởi các Web service server như Apache Tomcat và Axis. Chúng cần có các BPEL engine đặc thù mà thường được xây dựng dựa trên các Web service server. Cho đến nay, đang tồn tại một số BPEL engine như Active EndPoint ActiveBPEL, Java Business Integration của Sun và Orchestration Director Engine (ODE) của Apache. Trong số engine trên, ODE đang nổi lên như một engine mạnh, dễ sử dụng và là mã nguồn mở. Hơn nữa, engine này cũng có thể dễ dàng được tích hợp trong các môi trường BPEL khác. Ví dụ như Eclipse BPEL Designer đã tích hợp ODE làm BPEL engine của mình. Để khai thác một tiến trình BPEL trong ODE, một loạt các bước cần được tiến hành. Đầu tiên, các Partner Link phải được tạo ra từ các tệp WSDL và từ bản thân tiến trình 35 BPEL. Ngoại trừ một Parner Link mà đại diện cho các thực thể sẽ sử dụng tiến trình BPEL, các Parner Link khác đại diện cho các Web service bên ngoài mà sẽ được gọi (invoke) trong tiến trình BPEL. Sau đó, một tệp khai thác đặc thù (có tên là deploy.xml) phải được tạo ra tuân theo đặc tả cấu trúc của ODE. Cuối cùng, tất cả các tệp cần thiết liên quan đến tiến trình BPEL sẽ được copy vào một thư mục đặc thù và rồi chúng sẽ được kiểm tra lỗi và biên dịch. Nếu có lỗi được phát hiện (đây là tình huống thường xảy ra), log tệp của Web server đang hosting ODE phải được kiểm tra một cách thủ công để tìm thông báo lỗi và từ đó tìm nguyên nhân lỗi. Dù việc biên dịch có thành công, thì lỗi chạy (runtime error) vẫn có thể tồn tại, quá trình kiểm tra và đoán lỗi sẽ phải lặp đi lặp lại cho đến khi tìm ra. Từ mô tả trên, có thể thấy quá trình tiền khai thác khá phức tạp, mất thời gian và dễ gây lỗi. Thậm chí với một người đã quen thuộc với việc khai thác các Web service, vẫn còn có những bước làm thủ công phức tạp không cần thiết. Ngoài ra, nó cũng đòi hỏi sự hiểu biết về BPEL, kiến thức sâu về cấu trúc và cú pháp của WSDL và cấu trúc đặc thù của tệp deploy.xml của ODE. Việc tạo ra các Partner Link trong các tệp WSDL khác nhau và tệp deploy.xml cũng là một quá trình tẻ nhạt, mất thời gian và rất dễ gây ra lỗi. Công việc tẻ nhạt và tốn thời gian nhất là quá trình tìm lỗi trong tệp log, mà nó thường rất dài và không có cấu trúc, vì nó chứa tất cả các loại thông báo từ Web server chứ không chỉ các thông báo liên quan đến quá trình khai thác tiến trình BPEL. Điều này cho thấy sự cần thiết phải có một công cụ để tự động hóa quá trình khai thác. Ở đây luận án sẽ giới thiệu một công cụ hỗ trợ quá trình khai thác tiến trình BPEL trong ODE. Công cụ này sẽ giải quyết được các vấn đề nêu ở trên bằng việc cung cấp các tính năng sau: - Tự động kiểm tra tính hợp lệ của tệp tiến trình BPEL và các tệp WSDL liên quan. Nếu tất cả các tệp này đều hợp lệ thì tệp deploy.xml cần thiết sẽ được tạo ra. Tự động thu thập các tệp cần thiết vào trong thư mục khai thác của ODE, và khởi tạo quá trình biên dịch. Lọc và trả về chỉ các thông báo liên quan, hữu ích về các lỗi tiềm năng gắn với quá trình chuẩn bị và biên dịch. Đề xuất các giải pháp và các lý do có thể gây ra lỗi. Hỗ trợ việc tích hợp với trình soạn thảo BPEL. 1.6 Vấn đề còn tồn tại và tiếp cận 1.6.1 Vấn đề còn tồn tại Từ việc xem xét khái quát ở trên, luận án nhận ra một số vấn đề còn tồn tại cần được tiếp tục nghiên cứu và giải quyết. Mặc dù số lượng và phạm vi của những vấn đề này là khá nhiều và đa dạng, chúng đều liên quan đến vấn đề phát triển khung cộng tác đa dụng trong môi trường tính toán lưới. Ở đây, để tiện cho việc nắm bắt và giải quyết các vấn đề này, luận án phân chia chúng theo nguồn gốc phát sinh. Theo đó, các vấn đề còn tồn tại hiện nay được chia thành hai nhóm: 36 - - Nhóm thứ nhất: gồm các vấn đề liên quan đến các mô hình và cách tiếp cận hiện nay về kế hoạch và sự cộng tác. Nhóm này bao gồm các vấn đề sau:  Mối quan hệ phức tạp giữa kế hoạch và sự cộng tác chưa được giải thích rõ ràng. Đa số các lý thuyết chỉ coi kế hoạch như một công cụ cộng tác, và quá trình lập kế hoạch như một công việc kết nối. Tuy nhiên, có thể thấy nguồn gốc của rất nhiều loại hình cộng tác đều xuất phát từ các bản kế hoạch. Hơn nữa bản thân quá trình lập kế hoạch cũng thường là một công việc cộng tác và cũng cần có sự hỗ trợ của các công cụ cộng tác. Việc làm rõ mối quan hệ này có vai trò rất quan trọng trong việc thấu hiểu các khái niệm, để từ đó chúng có thể được hình thức hóa và biểu diễn một cách đúng đắn, đầy đủ và hiệu quả.  Cấu trúc của kế hoạch và sự phát triển của nó cũng chưa được đề cập đến. Khái niệm về kế hoạch xuất hiện dưới rất nhiều dạng khác nhau trong các công việc thực tế: từ một bảng phân công công việc trong một nhóm làm việc, một chu trình sản xuất một sản phẩm, cho đến những kế hoạch phát triển cho một vùng, một quốc gia. Tuy nhiên, cấu trúc chung của chúng, cũng như quá trình hình thành phát triển của chúng như thế nào thì dường như chưa có một lý thuyết nào đề cập đến. Nhóm thứ hai: gồm các vấn đề liên quan đến các các khung có hỗ trợ cộng tác hiện nay. Nhóm này bao gồm một số vấn đề sau:  Chỉ có tính chuyên biệt cho từng lĩnh vực: Mỗi khung lưới trên gắn chặt với một lĩnh vực ứng dụng chuyên biệt và điều này làm cho chúng rất khó có thể được sử dụng lại như một khung lưới cho các ứng dụng trong lĩnh vực khác. Ví như hệ thống PATIENT SCHEDULER chỉ nhắm vào các ứng dụng trong điều trị y tế; GCF-MD chỉ hỗ trợ các thiết bị di động và không đi theo kiến trúc mở hướng dịch vụ (SOA);  Thiếu khả năng hỗ trợ kế hoạch: Với đa số các công việc cộng tác, bước đầu tiên là lập kế hoạch để tạo ra một kế hoạch thực hiện, chứa dãy các công việc cần được thực hiện bởi những thành viên phụ thuộc vào vai trò, vị trí của họ. Sau đó, theo kế hoạch, công việc sẽ được phân bổ, được thực thi và được giám sát để nắm được tiến độ thực hiện công việc, từ đó có những bước đánh giá tiếp theo. Thiếu khả năng hỗ trợ kế hoạch sẽ rất khó khăn để nắm được tiến độ công việc cũng như hỗ trợ sự cộng tác, và quan trọng hơn là thay đổi kế hoạch một khi nó đang được triển khai. Ví dụ các hệ thống OCGSA, LAGrid, CDG, GCF-MD đều thiếu khả năng hỗ trợ kế hoạch.  Thiếu khả năng hỗ trợ việc thực thi tự động trong môi trường lưới: Sau khi xây dựng kế hoạch thực hiện các công việc (hay còn được gọi là tiến trình nghiệp vụ), nhu cầu đặt ra là làm thế nào để thực thi được các công việc đó theo kế hoạch đã đề ra. Điều này đòi hỏi trước tiên phải tìm được những đối tượng/đối tác phù hợp với các công việc. Sau đó tiến hành phân công công việc cho họ, rồi giám sát tiến độ của việc thực thi. Vấn đề này trở nên khó khăn hơn khi muốn tự động hóa quá trình này trong môi trường lưới. Do một trong những đặc thù của môi trường này là tính động của các đối tượng tham gia (các đối tượng có thể 37  tham gia hoặc rời khỏi môi trường một cách tùy ý mà không có nhiều ràng buộc), nên việc quản lý được từng đối tượng cũng không phải là việc dễ dàng. Chưa hỗ trợ gọi dịch vụ lưới từ tiến trình BPEL: Do hoạt động trong khung cộng tác sẽ được biểu diễn bằng ngôn ngữ luồng BPEL, nên hạn chế này sẽ ảnh hưởng đến việc thực thi hoạt động trong môi trường lưới. Để thi hành các tiến trình BPEL, cần có các BPEL engine. BPEL engine được chọn trong luận án là ODE của Apache, do nó là một trong số các engine mã nguồn mở và có hỗ trợ khá tốt. Tuy nhiên, engine này lại có hạn chế là chưa hỗ trợ việc gọi dịch vụ lưới, mà mới chỉ hỗ trợ gọi dịch vụ Web. Có một BPEL engine khác tuy không có hạn chế này là ActiveBPEL, nhưng nó lại không phải là mã nguồn mở nữa. Do vậy, ODE là lựa chọn duy nhất và luận án sẽ đưa ra biện pháp khắc phục hạn chế này.  Việc khai thác tiến trình BPEL còn phức tạp và thủ công: Để khai thác một tiến trình BPEL trong ODE, một loạt các bước cần được tiến hành. Đầu tiên, các Partner Link phải được tạo ra từ các tệp WSDL và từ bản thân tiến trình BPEL. Ngoại trừ một Parner Link mà đại diện cho các thực thể sẽ sử dụng tiến trình BPEL, các Parner Link khác đại diện cho các Web service bên ngoài mà sẽ được gọi (invoke) trong tiến trình BPEL. Sau đó, một tệp khai thác đặc thù (có tên là deploy.xml) phải được tạo ra tuân theo đặc tả cấu trúc của ODE. Cuối cùng, tất cả các tệp cần thiết liên quan đến tiến trình BPEL sẽ được copy vào một thư mục đặc thù và rồi chúng sẽ được kiểm tra lỗi và biên dịch. Nếu có lỗi được phát hiện, (đây là tình huống thường xảy ra), log tệp của Web server đang hosting ODE sẽ được kiểm tra một cách thủ công để tìm thông báo lỗi và từ đó tìm nguyên nhân lỗi. Dù việc biên dịch có thành công, lỗi chạy (runtime error) vẫn có thể tồn tại, quá trình kiểm tra và đoán lỗi sẽ phải lặp đi lặp lại cho đến khi tìm ra. 1.6.2 Tiếp cận Nghiên cứu của luận án nhằm giải quyết các vấn đề trên. Tiếp cận trong luận án bao gồm: - - Đối với nhóm vấn đề thứ nhất: vì nhóm này liên quan đến các vấn đề lý thuyết, nên một mô hình cải tiến từ Lý thuyết Hoạt động, với tên gọi Mô hình Kế hoạch, đã được phát triển. Chi tiết về Mô hình Kế hoạch và yêu cầu tổng quan của khung cộng tác dựa trên mô hình này được trình bầy trong Chương 2. Đối với nhóm vấn đề thứ hai: vì nhóm này liên quan đến việc phát triển khung lưới cộng tác đa dụng, nên một loạt các giải pháp liên quan đến các vấn đề này sẽ được luận án đề xuất. Từ việc xác định các yêu cầu tổng thể của khung được trình bày trong Chương 2, sau đó là làm mịn các kế hoạch được trình bầy trong Chương 3 và đến cuối cùng là các giải pháp thiết kế và cài đặt khung được trình bày trong Chương 4. 38 CHƯƠNG 2: MÔ HÌNH KẾ HOẠCH VÀ KHUNG CỘNG TÁC ĐA DỤNG Đầu chương này sẽ giới thiệu về Mô hình kế hoạch, dựa trên mô tả hình thức các thành phần của hoạt động theo tiếp cận của Lý thuyết Hoạt động. Sau đó, luận án trình bày mô tả hình thức khái niệm kế hoạch, nhằm làm rõ vai trò, cấu tạo, quy luật phát triển của kế hoạch, quan hệ giữa kế hoạch và cộng tác. Luận án đề xuất Mô hình kế hoạch tương đối hoàn chỉnh. Trên cơ sở đó các yêu cầu của một khung cộng tác đa dụng có hỗ trợ kế hoạch được đề xuất. Kết quả nghiên cứu về mô hình kế hoạch và khung cộng tác đa dụng đã được công bố trong [15][16]. 2.1 Mô hình kế hoạch 2.1.1 Các khái niệm cơ bản Khái niệm về hoạt động đã được đề cập trong Chương 1, trong đó mỗi hoạt động gồm ba thành phần cơ bản là chủ thể, công cụ và đối tượng, nhằm biểu diễn cho ý nghĩa khái quát của các hoạt động có chủ đích. Để tiện cho việc biểu diễn các loại hoạt động, chúng được chia làm hai loại: - - Hoạt động đơn (Single Activity): là hoạt động không chứa các hoạt động con khác, được mô tả bởi các thành phần cơ bản là chủ thể, công cụ và mục tiêu (chi tiết về cấu trúc của hoạt động đã được trình bày ở phần 1.1.3). Hoạt động tập thể (Collective Activity): là hoạt động chứa hai hay nhiều hoạt động con. Do sự xuất hiện của nhiều hoạt động con, nên cần có quan hệ thứ tự bộ phận, nhằm xác định thứ tự thực thi giữa chúng. Định nghĩa 2-1: Hoạt động (Activity): được định nghĩa như sau: Activity ::- Single | Collective(L, R); Single ::- Atomic(S, T, O) | Abstract(O) |AbstractT(S, O) | AbstractS(T, O); Trong đó: - S, T, O tương ứng là chủ thể (Subject), tài nguyên hay công cụ (Tool) được sử dụng bởi chủ thể S và mục tiêu (Objective)/đối tượng (Objective) của hoạt động. Single: biểu thị một hoạt động đơn. Nó có thể ở một trong hai dạng cụ thể: Atomic(S, T, O) là hoạt động nguyên tố, nghĩa là chủ thể S sử dụng công cụ T để tạo ra đối tượng O. Hoạt động Abstract(O) là hoạt động trừu tượng mới chỉ có mục tiêu, chưa có chủ thể thực hiện cũng như công cụ cần thiết để thực thi được hành động đó. Tương tự, hai dạng hoạt động còn lại AbstractT (S, O) và AbstractS (T, O) cũng là hoạt động trừu tượng trong đó vẫn thiếu một trong các thành phần chủ thể hoặc công cụ. 39 - Collective(L, R): là hoạt động tập thể, chứa các hoạt động con L= {A1, A2, ..., An} và thành phần R là tập các quan hệ phụ thuộc r(Ai, Aj) giữa các cặp hoạt động (Ai, Aj) (Ai, Aj ∈ L) (các quan hệ phụ thuộc này sẽ được giải thích rõ hơn ở phần định nghĩa 2.3). Từ tập các quan hệ này ta có thể suy ra mối quan hệ giữa tất cả các hoạt động con, do đó xác định được thứ tự thực thi của chúng trong hoạt động tập thể. Chú thích: Để gọi tên các hoạt động được thống nhất và tường minh, ta sẽ ký hiệu các hoạt động đơn như sau: Atomic(S, T, O) được thay bằng Tên(S, T, O); Abstract(O) được thay bằng Tên(, , O); AbstractT (S, O) được thay bằng Tên(S, , O); AbstractS(T, O) được thay bằng Tên(, T, O); Ví dụ 2-1: Hoạt động Học(Sinh viên, Môn học, Kết quả) biểu diễn cho loại hoạt động Atomic(S, T, O); hoạt động Học(, Môn học, Kết quả) biểu diễn cho loại hoạt động AbstractS (T, O); hoạt động Học(Sinh viên, , Kết quả) biểu diễn cho loại hoạt động AbstractT(S, O); và hoạt động Học(, , Kết quả) biểu diễn cho loại hoạt động Abstract(O). Hình 2-1 (còn được gọi là sơ đồ hoạt động) minh họa các thành phần của một hoạt động đơn. T (2) S (3) (1) O Hình 2-1: Cấu trúc của một hoạt động đơn Ý nghĩa của hoạt động: Một hoạt động A(S,T,O) có thể mang nhiều ý nghĩa khác nhau tùy thuộc vào các ngữ cảnh khác nhau. Tuy nhiên, có thể đưa ra diễn giải chung như sau: Sử dụng công cụ T, chủ thể S muốn tạo ra mục tiêu (còn gọi là đối tượng) O. Có thể xảy ra trường hợp, S có thể tạo ra O mà không cần có công cụ nào (T=∅). Mô hình này nhằm biểu diễn các hoạt động có chủ đích nhằm đạt được mục tiêu nào đó của chủ thể. Mô hình này cũng giúp trả lời ba câu hỏi cơ bản của mọi hoạt động: - Làm cái gì? Đối tượng O là mục tiêu của hoạt động. Đối tượng này có thể là cụ thể như cái bàn, cái ghế, máy tính,v.v hoặc trừu tượng như tri thức hay sở thích nào đó. Làm như thế nào? Sử dụng công cụ T và các quan hệ R. Để đạt được đối tượng O, điều quan trọng là chỉ rõ cách thức đạt được, thông qua mô tả tường minh các công cụ T cách sử dụng chúng gắn với các quan hệ R. Với mô tả này, hoạt động sẽ đóng vai trò như một bản kế hoạch, trong đó xác định các bước cần làm để đạt được mục tiêu. Trong trường hợp công cụ T chưa tồn tại, hoạt động A ban đầu phải tham chiếu đến một hoạt động AT, nhằm phát hiện hoặc tạo ra công cụ T, sau đó dùng T 40 trong hoạt động A để thu được O. Điều này có nghĩa là một hoạt động có tính lồng nhau (nesting), tức là có thể chứa các hoạt động khác. - Ai thực hiện? Chủ thể S, chịu trách nhiệm thực thi hoạt động. Khi xem xét hoạt động trong một kế hoạch, chủ thể cho phép xác định các tác nhân tham gia trong quá trình hoàn thành kế hoạch. Từ Hình 2-1, ý nghĩa của các liên kết giữa các thành phần trong một hoạt động có thể được hiểu như sau: - Liên kết (1): Hành động của chủ thể là nhằm đạt được đối tượng O. Liên kết này biểu diễn mục đích chính của hoạt động. - Liên kết (2): Chủ thể phải có thông tin về công cụ trước sử dụng. Ngoài ra, chủ thể phải biết qui trình sử dụng công cụ để tạo ra đối tượng. - Liên kết (3): Biểu thị chuyển đổi đặc biệt từ công cụ sang đối tượng đích. Hình 2-2 biểu diễn một góc nhìn khác (góc nhìn chức năng hay góc nhìn hộp đen của hoạt động đơn A(S, T, O)). Với góc nhìn này, chủ thể và công cụ đóng vai trò đầu vào và đối tượng đóng vai trò đầu ra. Còn tất cả các quan hệ giữa các thành phần trên đều bị ẩn. Như vậy so với góc nhìn này, góc nhìn ở Hình 2.1 có thể được gọi là góc nhìn hộp trắng, qua đó mọi quan hệ bên trong giữa các thành phần đều được diễn tả tường minh. Với góc nhìn hộp trắng, lý thuyết hoạt động chỉ ra một nguyên tắc rất quan trọng. Đó là không chỉ quan tâm đến đầu vào, đầu ra của hoạt động, mà quan tâm đến cả quá trình làm thế nào để biến đổi từ đầu vào đến đầu ra và diễn tả tường minh. Điều này có ý nghĩa rất quan trọng trong các ứng dụng, đòi hỏi sự tường minh trong quá trình thực hiện như lập kế hoạch, điều trị y tế, v.v. S A O T Hình 2-2: Góc nhìn chức năng của một hoạt động đơn A(S,T,O) Từ góc nhìn chức năng, một biểu diễn trực quan của hoạt động đơn được đưa ra, như trong Hình 2-3, sẽ được sử dụng trong luận án. Hình 2-3: Biểu diễn một hoạt động đơn. 41 Định nghĩa 2-2: Cho trước một hoạt động A. - subject(A): trả về tập chủ thể của A: { } ế = ( ⎧ ℎ ặ ⎪ ⎪ ∅ ế = ℎ ặ ( )= ⎨ ( ) ế = ⎪ ⎪ ∈ ⎩ = ( - , , ) ( , ); ( ) ( , ); ( , ), ớ , ,…, ); tool(A): trả về tập công cụ của A: { } ế = ( , , ) ⎧ ℎ ặ ( , ); ⎪ ( ) ∅ ế = ⎪ ( , ) ℎ ặ ( )= ⎨ ( ) ế = ( , ), ớ ⎪ ⎪ ∈ ⎩ = ( , , … , ); - objective(A): trả về tập mục đích của A: ( )= ⎧ ⎪ ⎨ ⎪ ⎩ { } ế à ℎ ạ độ đơ ; ( ) ế = ( , ), ớ ∈ = ( , ,…, ); Định nghĩa 2-3: Quan hệ phụ thuộc giữa hai hoạt động A1 và A2: - Chung đầu vào (common-in): hai hoạt động có chung một hoặc cả hai đầu vào. Hình 2-4 minh họa cho loại phụ thuộc này. common-in(A1, A2) := subject(A1) = subject(A2) | tool(A1) = tool(A2) | subject(A1) = subject(A2) and tool(A1) = tool(A2); - Vào-ra (in-out): đầu ra của hoạt động này là đầu vào của hoạt động kia. in-out(A1, A2): đầu ra của A1 là đầu vào của A2. Hình 2.5 minh họa cho loại phụ thuộc này. in-out(A1, A2) := objective(A1) = subject(A2) | objective(A1)=tool(A2); - Rẽ nhánh (switch): Mỗi thời điểm chỉ có duy nhất một hoạt động được thực hiện. Việc lựa chọn hoạt động nào sẽ phụ thuộc vào một điều kiện logic C nào đó. Quan hệ này còn có tên gọi khác như loại trừ (exclusion) hay lựa chọn (selection). ℎ( , , ) ≔ 42 ế đú ế Có thể mở rộng biểu diễn các trường hợp rẽ một nhánh và nhiều nhánh. Ví dụ rẽ một nhánh cho hoạt động A theo điều kiện C được biểu diễn bởi switch(A, _, C), với “_” là biểu diễn cho một hoạt động rỗng. - - Đồng bộ (synchronization): synch(A1, A2) hai hoạt động A1 và A2 này phải kết thúc trước khi thực hiện các hoạt động khác. Hai hoạt động cần phải được đồng bộ, thường do mỗi kết quả đầu ra của từng hoạt động chưa hoàn chỉnh và là bộ phận của một kết quả lớn hơn. Không phụ thuộc (hay Độc lập (independence)): independence(A1, A2) hai hoạt động không có bất kỳ phụ thuộc nào. Quan hệ này có liên hệ với hai loại quan hệ trên như sau: independence(A1, A2) := (Not common-in(A1, A2)) And (Not in-out(A1, A2)); Hình 2-4: Các tình huống cho common-in(A1, A2). Hình 2-5: Các tình huống cho in-out (A1, A2). Định nghĩa 2-4: Đường dẫn (path): Quan hệ phụ thuộc Vào-ra giữa hai hoạt động A1 và A2 (in-out(A1, A2)) tạo ra một quan hệ thứ tự thực thi trước sau (A1 phải được thực thi trước A2). Điều này tạo ra một đường dẫn một chiều (path) từ A1 đến A2, ký hiệu path(A1, 43 A2). Khái niệm đường dẫn có thể được mở rộng: path(A1, A2, ..., Ak), trong đó i=1..(k-1),  quan hệ in-out(Ai, Ai+1). Để ngắn gọn, khi không xảy ra nhầm lẫn, ta chỉ cần ký hiệu hai hoạt động đầu và cuối của đường dẫn, tức là path(A1, A2,..., Ak) sẽ được viết gọn thành path(A1, Ak); Tuy nhiên, do giữa hai hoạt động cũng có thể tồn tại nhiều đường dẫn, nên cách ký hiệu path(A1, Ak) biểu thị tất cả các đường dẫn từ A1 đến Ak. Trong sơ đồ biểu diễn hoạt động tập thể, đường dẫn được biểu diễn bằng nét đứt (xem hình 2.6). Hình 2-6: Ví dụ về biểu diễn đường dẫn path(A1, A2). Sau đây là một số ví dụ về các hoạt động. Ví dụ 2-2: Hoạt động đơn "Học một chủ đề": Một sinh viên muốn tự học một chủ đề nào đó. Hình 2-7 biểu diễn hoạt động này, trong đó ý nghĩa của các thành phần như sau: Tài liệu (2) Sinh viên (3) (1) Tri thức Hình 2-7: Các thành phần của hoạt động “Học một chủ đề”. - Chủ thể: Sinh viên. Đối tượng: Tri thức về chủ để mà sinh viên này muốn học. Công cụ: Các tài liệu tham khảo liên quan đến chủ đề. Liên kết (1): Hành động của sinh viên hướng tới nắm được tri thức của chủ đề cần học. Liên kết (2): sinh viên phải tìm các tài liệu liên quan, đọc, thực hành để nắm được các nội dung của chủ đề. 44 - Liên kết (3): Trong hoạt động này, quá trình chuyển đổi từ tri thức trong tài liệu sang tri thức, sinh viên nắm được là ngầm định. Ví dụ 2-3: Hoạt động đơn "Dạy học cho nhóm": Một giáo viên dạy học cho một nhóm sinh viên về một chủ đề nào đó. Hình 2-8 biểu diễn hoạt động này với các thành phần sau: Tài liệu, phương tiện (2) Giáo viên, Nhóm sinh viên (3) (1) Tri thức Hình 2-8: Các thành phần của hoạt động “Dạy học cho nhóm”. - - Chủ thể: giáo viên (teacher), nhóm các sinh viên (students). Đối tượng: tri thức (knowledge) mà sinh viên muốn nắm được cũng như giáo viên muốn truyền đạt. Công cụ: các tài liệu liên quan (documents), các phương tiện giảng dạy (materials). Liên kết (1): Hành động của giáo viên hướng tới giúp sinh viên nắm được kiến thức về chủ đề một cách đầy đủ và nhanh nhất. Liên kết (2): giáo viên cung cấp hoặc giúp các sinh viên tìm kiếm các tài liệu liên quan, hướng dẫn cách nghiên cứu để đạt hiệu quả tốt nhất. Giáo viên cũng giúp giải đáp các câu hỏi của sinh viên. Các sinh viên cũng có thể học hỏi lẫn nhau thông qua thảo luận hay làm việc nhóm. Liên kết (3): Sinh viên thu nhận kiến thức từ ba nguồn: từ các tài liệu, từ giáo viên và từ các sinh viên khác trong nhóm. Giáo viên sử dụng các phương tiện giảng dạy để giảng dạy cho các sinh viên. Ví dụ 2-4. Hoạt động tập thể "Học một chủ đề": Phân tích chi tiết hơn hoạt động đơn "Học một chủ đề" ở Ví dụ 2.2, hoạt động này có thể bao gồm hai hoạt động con là "Tìm tài liệu" và "Nghiên cứu tài liệu". Do đó, nó cũng lại là một hoạt động tập thể, được gọi là Học(L, R) với các thành phần như sau: - L = {A1, A2}; với A1= Tìm-TL(Sinh viên, {Thư viện, Internet}, Tài liệu); A2 = Nghiên-cứu-TL(Sinh viên, Tài liệu, Tri thức); R = {common-in(A1, A2), in-out(A1, A2)}: là do subject(A1) = subject(A2) = Sinh viên, và Objective(A1) = Tool(A2) = Tài liệu. Từ các quan hệ này suy ra hoạt động A1 (Tìm-TL) phải được thực hiện trước hoạt động A2 (Nghiên-cứu-TL); Hình 2-9 minh họa cho hoạt động này, trong đó biểu diễn mối quan hệ giữa các thành phần của hai hoạt động: chúng có chung chủ thể Sinh viên, và đầu ra Tài liệu của hoạt động 45 Tìm-TL trở thành đầu vào loại T (công cụ) của hoạt động Nghiên-cứu-TL. Mối quan hệ inout này chỉ ra rằng hoạt động A1 (Tìm-TL) phải được thực hiện trước hoạt động A2 (Nghiên-cứu-TL), trên cơ sở đó tạo lập được path(A1, A2) như trong hình 2.9b. Hình 2-9: Hoạt động tập thể "Học một chủ đề". Định nghĩa 2-5: Hoạt động tập thể chỉnh (well-formed collective activity): hoạt động tập thể C({A1, A2, ..., An}, R) là chỉnh nếu nó thỏa mãn các điều kiện sau: - Tồn tại chỉ một hoạt động con đóng vai trò đầu vào (sau này quy ước đó là A1); Tồn tại chỉ một hoạt động đóng vai trò đầu ra (sau này quy ước là An); Mọi hoạt động con khác đều nằm trên ít nhất một đường dẫn path(A1, An); Ví dụ hoạt động tập thể chỉnh được trình bày trong hình 2-10. Hình 2-10: Hoạt động tập thể chỉnh. 46 Hoạt động tập thể "Học một chủ đề" ở ví dụ 2.4 là một hoạt động tập thể chỉnh. Sau đây là một ví dụ về hoạt động tập thể chỉnh phức tạp hơn. Ví dụ 2-5 : Hoạt động Xử lý yêu cầu làm thẻ ngân hàng. Hình 2-11 biểu diễn các thành phần của hoạt động (hình này mượn sử dụng một số ký hiệu từ mô hình Activity Diagram của UML (Unified Modeling Language) [96] với ý nghĩa tương đương) bao gồm các bước xử lý (hoạt động con) sau: 1. Gửi yêu cầu: Quá trình xử lý thẻ bắt đầu khi có một khách hàng gửi yêu cầu làm thẻ đến Phòng Quản lý thẻ; 2. Tiếp nhận yêu cầu: Một nhân viên trong Phòng quản lý thẻ tiếp nhận và kiểm tra thông tin trong yêu cầu của khách hàng; 3. Xử lý yêu cầu: Nếu tất cả các thông tin yêu cầu đều đầy đủ và đủ điều kiện cấp thẻ thì yêu cầu sẽ được chấp nhận. Trái lại, yêu cầu sẽ bị khước từ. Quyết định xử lý yêu cầu sẽ được thông báo đến khách hàng; 4. Sau khi yêu cầu được chấp nhận, có hai nhiệm vụ độc lập sẽ được tiến hành: sản xuất thẻ và thông báo chấp nhận. Trong thông báo sẽ xác nhận việc đồng ý cấp thẻ và thông tin về thời gian cấp thẻ. Vì hai công việc trên là độc lập nên chúng có thể được tiến hành song song để rút ngắn thời gian phục vụ khách hàng; 5. Trả thẻ: Sau khi hoàn thành hai nhiệm vụ trên, thì thẻ sẽ được gửi đến cho khách hàng; 6. Cuối cùng, tiến trình xử lý sẽ kết thúc ngay sau khi thẻ tín dụng hoặc quyết định khước từ được gửi đến khách hàng. Hình 2-11: Hoạt động Xử lý yêu cầu làm thẻ tín dụng. 47 Định nghĩa 2-6: Tương đương về chức năng: Hai hoạt động A và B là tương đương về chức năng nếu chúng có đầu vào và đầu ra giống nhau. Ký hiệu A  B. Có ba khả năng xảy ra (tương ứng với ba phần a, b, và c trong Hình 2-12): - A và B là hai hoạt động đơn: giả sử chúng có dạng tương ứng là A(SA, TA, OA) và B(SB, TB, OB). Khi đó: A  B nếu và chỉ nếu SA = SB và TA = TB và OA = OB; - Trong A và B có một hoạt động đơn và một hoạt động tập thể: giả sử A là hoạt động đơn, B là hoạt động tập thể và chúng có dạng tương ứng là A(SA, TA, OA) và B({B1,B2,...,Bn},R). Khi đó: A  B nếu và chỉ nếu SA = Subject(B1) và TA = Tool(B1) và OA = Objective(Bn); - A và B là hai hoạt động tập thể: giả sử chúng có dạng tương ứng là A({A1, A2,...,Am}, RA) và B({B1, B2,...,Bn}, RB). Khi đó: A  B nếu và chỉ nếu Subject(A1)=Subject(B1) và Tool(A1)=Tool(B1) và Objective(Am)=Objective(Bn); Một tính chất quan trọng của hoạt động tập thể chỉnh là nó tương đương về mặt chức năng với một hoạt động đơn, do đó giúp cho việc chuyển đổi giữa hoạt động tập thể và hoạt động đơn, sẽ được sử dụng trong quá trình lập kế hoạch sau này. Ngoài ra, các hoạt động tập thể chỉnh cũng là sự đơn giản hóa các hoạt động khi chúng chỉ có một đầu vào và một đầu ra. Vì thực ra, với một hoạt động tập thể mà có nhiều đầu vào và đầu ra, ta đều có thể tách thành các hoạt động con có một đầu vào và một đầu ra, nên sau này các hoạt động tập thể mà chúng ta xem xét đến trong các kế hoạch đều là các hoạt động chỉnh. 2.1.2 Các trạng thái của hoạt động Tại một thời điểm, một hoạt động có thể ở một trong ba trạng thái như sau: - - - Khả thi (feasible): Một hoạt động là khả thi nếu nó có thể đạt được mục tiêu đề ra ít nhất một lần, nghĩa là tìm được ít nhất một chủ thể và một công cụ có thể thực hiện được một mục tiêu đề ra. Không khả thi (infeasible): Một hoạt động là không khả thi nếu không bao giờ có thể đạt được mục tiêu đề ra. Với một hoạt động đơn A(S, T, O), nếu S và T là các tập vô hạn, về lý thuyết ta không thể kiểm tra được tính không khả thi của A. Do đó, để kiểm tra tính chất này, sau này ta chỉ xét các hoạt động mà có các tập S và T là hữu hạn. Bất định (unknown): Một hoạt động là bất định nếu nó hiện chưa chắc chắn là khả thi hay không khả thi. Nếu gọi state(A) là hàm trả về trạng thái hiện tại của hoạt động A, ta có thể định nghĩa hàm trạng thái này như sau: 48 ⎧ ⎪ ⎪ ⎪ ⎪ ( )= ⎨ ⎪ ⎪ ⎪ ⎪ ⎩ ( , , ) à ế = ∃ ∈ , ∃ ∈ , ∃ ∈ , ℎ ừ à ạ ; ( , , ) à ế = ∀ ∈ , ∀ ∈ , ∄ ∈ , ℎ ừ à ạ ; ( ); ế = ( ) ế = ({ , , … , }, ), ( )= ( ) đó ( ) ( ); … a. Hai hoạt động đơn tương đương b. Hoạt động đơn và hoạt động tập thể tương đương c. Hai hoạt động tập thể tương đương Hình 2-12: Các cặp hoạt động tương đương. 49 Ý nghĩa của phép toán AND cho các giá trị trạng thái của hoạt động được cho trong bảng 2-1 (hàm AND là đối xứng nên một số dạng biểu thức tương đương đã bị loại ra khỏi bảng này). Bảng 2-1: Bảng giá trị cho hàm AND A B A AND B Khả thi Khả thi Khả thi Khả thi Không khả thi Không khả thi Khả thi Bất định Bất định Không khả thi Không khả thi Không khả thi Không khả thi Bất định Không khả thi Bất định Bất định Bất định 2.1.3 Phụ thuộc khả thi Trong phần này, khái niệm về sự phụ thuộc khả thi (feasible dependence) giữa các hoạt động sẽ được đưa ra. Khái niệm này chính là cơ sở cho quá trình lập kế hoạch. Định nghĩa 2-7: Phụ thuộc khả thi: Cho hai hoạt động A và B. Ta nói B phụ thuộc khả thi vào A (hay A xác định khả thi B), nếu sự khả thi của B có thể bị ảnh hưởng từ sự khả thi của A. Sự ảnh hưởng này có hai mức độ và dẫn đến hai mức phụ thuộc như sau: - - Phụ thuộc hoàn toàn: với mức này thì nếu A khả thi thì B cũng khả thi. Ký hiệu của phụ thuộc hoàn toàn: A → B; Phụ thuộc bộ phận (hay còn gọi là phụ thuộc không khả thi): với mức này thì nếu A khả thi thì B lại chưa chắc đã khả thi, nhưng nếu A không khả thi thì B cũng không khả thi. Ký hiệu của phụ thuộc bộ phận: A ⇀ B; Ví dụ 2-6: Xét hai hoạt động Sinh-viên-học(Sinh viên, Môn, Kết quả) (là hoạt động kiểu Atomic) và Học( , Môn, Kết quả) (là hoạt động kiểu AbstractS). Ta thấy nếu Sinh-viên-học là khả thi, tức là tồn tại ít nhất một sinh viên s và một môn học m và một kết quả k, sao cho s học môn m có kết quả k. Như vậy, hoạt động Học cũng khả thi. Do đó Sinh-viên-học → Học. Ví dụ 2-7: Xét hai hoạt động Tìm-kiếm(Sinh viên, Thư viện, Tài liệu) và Học(Sinh viên, Tài liệu, Kiến thức). Hai hoạt động này có quan hệ là Objective(Tìm-kiếm) = Tool(Học) = 50 Tài liệu. Nên dễ thấy nếu như hoạt động Tìm-kiếm mà không khả thi, tức là sinh viên không tìm được tài liệu trên thư viện, thì hoạt động Học cũng không khả thi, vì sinh viên không có tài liệu để học. Do đó Tìm-kiếm ⇀ Học. Ví dụ 2–8: Hoạt động Du-lịch-bộ-hành(S=Con người, T=Đi bộ, O=Vòng quanh thế giới) biểu diễn hành động một người muốn đi bộ vòng quanh thế giới. Hoạt động Dulịch(S=Con người, O=Vòng quanh thế giới) biểu diễn hành động một người muốn đi du lịch vòng quanh thế giới nhưng chưa biết dùng phương tiện gì. Ta dễ dàng suy ra, nếu Du-lịchbộ-hành là khả thi, tức là đã tồn tại một cá nhân có thể đi bộ vòng quanh thế giới, thì Dulịch cũng khả thi, ít nhất là với phương tiện Đi bộ. Do đó, Du-lịch-bộ-hành(S=Con người, T=Đi bộ, O=Vòng quanh thế giới) → Du-lịch(S=Con người, O=Vòng quanh thế giới). Các tính chất chung của phụ thuộc khả thi Đây là các tính chất áp dụng cho cả hai loại phụ thuộc khả thi là phụ thuộc hoàn toàn và phụ thuộc bộ phận (hay phụ thuộc không khả thi). Do vậy, để trình bày được ngắn gọn, kí hiệu phụ thuộc khả thi chỉ dùng một loại là phụ thuộc hoàn toàn, nhưng được áp dụng cho cả hai loại phụ thuộc bộ phận. - - - Tính phản xạ: với mọi hoạt động A thì ta có A → A. Chứng minh: Dựa vào định nghĩa của cả hai loại phụ thuộc khả thi ở trên ta dễ dàng suy ra tính khả thi hoặc không khả thi của một hoạt động phụ thuộc vào chính nó. Tính bất đối xứng: với hai hoạt động A và B cho trước, nếu A → B, thì chưa chắc B → A. Chứng minh: Tính chất này có thể được chứng minh thông qua một ví dụ về phụ thuộc khả thi là Atomic(S,T,O) → AbstractT(S,O), nhưng không thể chắc chắn được điều ngược lại là AbstractT(S,O) → Atomic(S,T,O) (xem thêm về một số dạng phụ thuộc khả thi ở phần sau). Tính bắc cầu: với ba hoạt động A, B, C. Nếu A → B và B → C thì A → C. Chứng minh: Ta sẽ chứng minh cho hai trường hợp: o o Các phụ thuộc thuộc này là phụ thuộc hoàn toàn: khi đó, nếu A khả thi thì từ A → B suy ra B cũng khả thi. Sau đó từ B → C thì C cũng khả thi. Suy ra A → C; Các phụ thuộc là phụ thuộc bộ phận (phụ thuộc không khả thi): khi đó, nếu A không khả thi thì từ A ⇀ B suy ra B cũng không khả thi. Sau đó từ B ⇀ C thì C cũng không khả thi. Suy ra A ⇀ C. Các tính chất riêng của phụ thuộc khả thi Đây là các tính chất áp dụng riêng cho từng loại phụ thuộc khả thi, nên ký hiệu cũng dùng đúng cho từng loại phụ thuộc khả thi. 1. Atomic(S, T, O) → AbstractT(S, O); 51 Chứng minh: Nếu Atomic(S, T, O) khả thi thì theo định nghĩa về khả thi, ∃ s ∈ S, t ∈ T và o ∈ O sao cho từ s và t có thể tạo ra o. Do đó hiển nhiên ta cũng có AbstractT(S, O) cũng khả thi vì ít nhất đã tồn tại T ∈ Atomic(S, T, O) mà Atomic(S, T, O) khả thi. 2. Atomic(S, T, O) → AbstractS (T, O); 3. AbstractT (S, O) → Abstract(O); 4. AbstractS (T, O) → Abstract(O); Chứng minh: Chứng minh cho các dạng phụ thuộc 2, 3 và 4 tương tự như ở dạng 1. 5. Cho hai hoạt động A và B. Nếu A  B (A và B là tương đương về chức năng) thì A → B và B → A; Chứng minh: Do A và B là tương đương về chức năng, nên theo định nghĩa này chúng có chung đầu vào (S và T) và chung đầu ra (O). Do đó, hiển nhiên là nếu A khả thi thì B cũng khả thi và ngược lại. 6. Nếu C({A1, A2, ..., An}, R) là hoạt động tập thể chỉnh thì: A1 ⇀ C và An ⇀ C; Chứng minh: Do A1, An là các hoạt động con đóng vai trò lần lượt là đầu vào và đầu ra của C, nên nếu một trong hai hoạt động này mà không khả thi thì C cũng không thể khả thi. Nhận xét : Thực ra tính chất này không chỉ đúng với A1 và An, mà có thể mở rộng cho các hoạt động Ak khác (với 2 ≤ k ≤ (n - 1)) sao cho path(A1,Ak) hoặc path(Ak, An) là đường dẫn duy nhất. 7. Cho C({A1, A2, ..., An}, R) là một hoạt động tập thể chỉnh. Khi đó  một hoạt động đơn A(S, T, O) sao cho C → A. Chứng minh: Ta chọn hoạt động A(S, T, O) sao cho subject(A1) = S, tool(A1) = T và objective(An) = O. Vì C là hoạt động chỉnh, nên với cách chọn A như trên, ta sẽ có hai hoạt động có đầu vào và đầu ra giống nhau. Do đó, nếu C khả thi thì A cũng khả thi. 8. Cho hai hoạt động A1(S1, T1, O1) và A2(S2, T2, O2). Nếu  quan hệ in-out(A1, A2) thì A1 ⇀ A2; Chứng minh: Vì  quan hệ in-out(A1, A2), tức là đầu vào của A2 cũng là đầu ra của A1, nên nếu A1 không khả thi thì cũng không tạo ra đầu ra của A1, tức là A2 cũng không khả thi. 9. Cho C({A1, A2, ..., An}, R) là một hoạt động tập thể chỉnh. C được gọi là hoạt động hợp lệ (valid) nếu nó phụ thuộc khả thi vào các hoạt động con của nó, tức là: A1, A2, ..., An → C. Còn trái lại ta nói C là không hợp lệ. Với hoạt động tập thể không hợp lệ, thì mặc dù tất cả các hoạt động con của nó đã khả thi, nhưng vẫn chưa xác định được bản thân hoạt động đó có khả thi không. Như vậy, hoạt động tập thể này không 52 có ý nghĩa thực tiễn trong quá trình lập kế hoạch, nên sau này chúng ta chỉ quan tâm đến các hoạt động tập thể hợp lệ. Một số hệ quả: - - - Hệ quả 1: Một hoạt động tập thể là không khả thi nếu và chỉ nếu tồn tại ít nhất một hoạt động con của nó không khả thi. Chứng minh: tính chất này là được suy trực tiếp từ tính chất 6 và tính chất 9 của phụ thuộc khả thi. Nếu một hoạt động tập thể là không khả thi thì trong nó phải tồn tại ít nhất một hoạt động con không khả thi, vì nếu không, khi tất cả các hoạt động con của nó đều khả thi thì theo tính chất 9 hoạt động này phải khả thi, trái với giả thiết ban đầu. Trong trường hợp ngược lại, nếu hoạt động tập thể có chứa ít nhất một hoạt động con không khả thi thì theo tính chất 6, hoạt động này cũng không khả thi. Suy ra điều phải chứng minh. Hệ quả 2: Một hoạt động tập thể là khả thi nếu và chỉ nếu tất cả các hoạt động con của nó đều khả thi. Chứng minh: tính chất này cũng là được suy ra từ tính chất 6 và tính chất 9 của phụ thuộc khả thi. Nếu hoạt động tập thể là khả thi thì tất cả các hoạt động con của nó phải khả thi, vì trái lại, nếu tồn tại ít nhất một hoạt động con không khả thi thì theo tính chất 6 hoạt động tập thể này cũng không khả thi, trái với giả thiết ban đầu. Trong trường hợp ngược lại, nếu tất cả các hoạt động con của hoạt động tập thể là khả thi thì theo tính chất 9 hoạt động tập thể này cũng khả thi. Suy ra điều phải chứng minh. Hệ quả 3: Cho trước hai hoạt động A(S, T, O) và A’(S’, T’, O’). Nếu O = O’ và S  S’ và T  T’ thì A → A’; Chứng minh: Nếu A khả thi, thì theo định nghĩa khả thi, ∃ ∈ , ∃ ∈ , ∃ ∈ sao cho từ s và t có thể tạo ra o. Mà theo giả thiết O = O’ và S  S’ và T  T’, nên ∈ , ∈ , à ∈ ′, tức là A’ cũng khả thi. Nhận xét: ta cũng dễ thấy rằng tính chất này chính là sự khái quát cho các tính chất 1, 2, 3 và 4 ở trên. 2.1.4 Kế hoạch Khái niệm cơ bản Định nghĩa 2-8. Kế hoạch P, ký hiệu P(LA, F), là một cấu trúc gồm hai thành phần:   LA = {A1, A2,...,An}: tập các hoạt động, trong đó có một hoạt động đóng vai trò là hoạt động gốc, là hoạt động đầu tiên được tạo ra của kế hoạch và cũng bắt đầu từ hoạt động này, các hoạt động khác cũng lần lượt được sinh ra. Sau này ta quy ước chọn A1 làm hoạt động gốc; F = {Ai → Aj | Ai, Aj  LA}: tập các phụ thuộc khả thi (PTKT). Phụ thuộc khả thi sẽ đóng vai trò sản sinh ra các hoạt động mới. Từ hoạt động Aj sẽ sinh ra hoạt động Ai sao cho Ai → Aj; Tương tự như cấu trúc cây, ta gọi nút Aj là nút cha và nút Ai là nút con. Tuy nhiên, khác với cấu trúc cây, một nút con trong cấu trúc kế hoạch có thể có nhiều nút cha. 53 Chú ý: mặc dù ở tập F ta sử dụng ký hiệu → cho phụ thuộc khả thi hoàn toàn, nhưng ở đây là mang ý nghĩa phụ thuộc khả thi nói chung, tức là có thể là phụ thuộc khả thi hoàn toàn hoặc bộ phận. Nên ta gọi F là tập phụ thuộc khả thi (PTKT). Đồng thời sau này, trong trường hợp thông thường không cần có sự phân biệt rõ giữa hai loại phụ thuộc khả thi, ký hiệu này cũng sẽ được dùng để biểu diễn phụ thuộc khả thi nói chung. Hình 2-13 biểu diễn cho một kế hoạch, trong đó bao gồm các nút biểu diễn cho các hoạt động (bao gồm cả hoạt động đơn và hoạt động tập thể) và ký hiệu → biểu diễn cho các phụ thuộc khả thi. Hình 2-13: Biểu diễn cho một kế hoạch. Do có hai loại phụ thuộc khả thi là phụ thuộc hoàn toàn (phụ thuộc thực sự khả thi) và phụ thuộc bộ phận (phụ thuộc không khả thi) tương đối độc lập, nên trong một kế hoạch cũng thường được biểu diễn ở hai dạng:  Kế hoạch khả thi: là kế hoạch chỉ chứa các phụ thuộc hoàn toàn, như được biểu diễn ở Hình 2-13. Từ hệ quả 2 của phụ thuộc khả thi (một hoạt động tập thể là khả thi khi và chỉ khi tất cả các hoạt động con của nó là khả thi), để nhấn mạnh tính khả thi của một nút biểu diễn một hoạt động tập thể phụ thuộc vào tất cả các nút con của nó, ta thêm một ký hiệu  (quả trám đậm) vào nút đó (biểu diễn đây là một nút VÀ (and)). Còn các nút không có ký hiệu này sẽ là nút HOẶC (or) (là nút biểu diễn các hoạt động đơn). Như vậy, kế hoạch khả thi có thể được biểu diễn bằng một đồ thị VÀ/HOẶC, như được biểu diễn trên hình 2-14. 54 nút HOẶC nút VÀ Hình 2-14: Biểu diễn kế hoạch khả thi bằng đồ thị VÀ/HOẶC.  Kế hoạch không khả thi: là kế hoạch chỉ chứa các phụ thuộc bộ phận (phụ thuộc không khả thi), như được biểu diễn ở Hình 2-15. Cũng từ hệ quả 1 của phụ thuộc khả thi (một hoạt động tập thể là không khả thi khi và chỉ khi tồn tại ít nhất một hoạt động con của nó không khả thi), kế hoạch không khả thi cũng có thể được biểu diễn bởi một đồ thị VÀ/HOẶC. Trong đó các nút VÀ biểu diễn các hoạt động đơn, và các nút HOẶC biểu diễn các hoạt động tập thể (xem hình 2-16). Hình 2-15: Biểu diễn kế hoạch không khả thi. 55 Hình 2-16: Biểu diễn kế hoạch không khả thi bằng đồ thị VÀ/HOẶC. Ví dụ 2–9: Xét kế hoạch P cho bài toán sắp xếp một dãy số L. Mục đích của bài toán là xây dựng một modul cho phép sắp xếp một dãy L gồm N số theo thứ tự tăng dần. Quá trình xây dựng kế hoạch P(LA, F) là quá trình cập nhật dần tập hoạt động LA và tập phụ thuộc khả thi F như sau: 1. 2. LA = Sort(, L, Ls); F =∅; Kế hoạch P ban đầu chỉ có một hoạt động Sort(, L, Ls) với mục đích xây dựng hoạt động Sort sao cho chuyển dãy đầu vào L thành dãy đầu ra được sắp xếp Ls, nhưng hiện vẫn chưa biết sẽ dùng chủ thể (ở đây là loại modul nào). Do có các giải thuật sắp xếp khác nhau như SelectionSort, MergeSort, nên áp dụng dạng PTKT 2 (Atomic(S,T,O → AbstractS(T,O)) ta bổ sung thêm các hoạt động SelectionSort(SelectionModul, L, LS) và MergeSort(MergeModul, L, Ls) và hai PTKT SelectionSort(SelectionModul, L, LS) → Sort(, L, LS) và MergeSort(MergeModul, L, LS) → Sort(, L, LS). Tức là lúc này ta sẽ có: LA = {Sort(, L, Ls), SelectionSort(SelectionModul, L, LS), MergeSort(MergeModul, L, LS); F = {SelectionSort(SelectionModul, L, LS) → Sort(, L, LS), MergeSort(MergeModul, L, LS) → Sort(, L, LS); 3. Quá trình xây dựng cứ tiếp tục như vậy cho đến khi có được một kế hoạch như được biểu diễn trong Hình 2-17. 56 Hình 2-17: Kế hoạch cho việc xây dựng giải thuật sắp xếp. Ví dụ 2-10: Được phát triển từ ví dụ 2-9, nhưng trong kế hoạch ở đây hướng đến việc xác định tính khả thi của việc cài đặt dịch vụ lưới thực hiện việc sắp xếp này. Hình 2-18 biểu diễn cho kế hoạch này. Có thể nhận thấy, kế hoạch này khá giống với kế hoạch của ví dụ 2-9, vì hai kế hoạch này có mục tiêu tương tự nhau là cần đưa ra một cài đặt cho giải thuật sắp xếp. Tuy nhiên, kế hoạch trong ví dụ này cụ thể hơn so với ví dụ 2-9, với hoạt động ban đầu Sort(GS, L, Ls) nhắm vào việc cài đặt một dịch vụ lưới GS, không còn mơ hồ, chưa được xác định như hoạt động ban đầu Sort(_, L, Ls) của ví dụ 2-9. Điều này cũng giúp cho việc xây dựng kế hoạch đơn giản và nhanh chóng hơn, vì các yêu cầu càng cụ thể thì việc xác định các thành phần như chủ thể và công cụ sẽ dễ dàng hơn. Như trong ví dụ này, khi đã xác định mục tiêu là dịch vụ vụ lưới, ta có thể tập trung ngay vào các chủ thể (những người lập trình) và công cụ (ngôn ngữ/môi trường lập trình) phù hợp cho cài đặt dịch vụ lưới. 57 Hình 2-18: Kế hoạch cho việc xây dựng Dịch vụ lưới của giải thuật sắp xếp. Tính khả thi của kế hoạch Một trong những mục tiêu của việc xây dựng kế hoạch là xác định tính khả thi của nó. Sau đây là một định nghĩa về tính chất này. Định nghĩa 2-9. Tính khả thi của kế hoạch: Cho kế hoạch P({A1,A2,...,An},F). Tính khả thi của P được quyết định bởi tính khả thi của hoạt động gốc của nó, tức là: - P({A1, A2,...,An},F) là khả thi  A1 khả thi. - P({A1, A2,...,An},F) là không khả thi  A1 không khả thi. Định nghĩa 2-10. Giá trị một đường dẫn: Cho đường dẫn pl=path(A1, A2,...,An) (tức là i=1..(n-1) Ai → Ai + 1). Khi đó giá trị của pl, ký hiệu val(pl), là giá trị trạng thái state(Ai) của mọi nút Ai (một trong các giá trị Khả Thi (FEASIBLE), Không Khả Thi (INFEASIBLE), Bất Định (UNKNOWN)), với i=1..n. Tức là: val(pl) = { state(Ai)| i = 1..n} Ta cũng ký hiệu: val(pl, Ai) = state(Ai); Chú ý : khái niệm đường dẫn được dùng ở đây là khái niệm đường dẫn thông thường trong đồ thị, với các cạnh là các phụ thuộc khả thi. Nó khác với khái niệm đường dẫn được định nghĩa trong Định nghĩa 2-4, mà trong đó mỗi cạnh biểu diễn một quan hệ phụ thuộc Vào-Ra. Đối với một kế hoạch, ta chỉ quan tâm đến một trong hai trạng thái là khả thi (FEASIBLE) và không khả thi (INFEASIBLE), nên sau này ta cũng chỉ quan tâm đến hai trạng thái này của một hoạt động. 58 Dựa theo tính chất của phụ thuộc khả thi, ta có thấy giá trị một đường dẫn phụ thuộc vào giá trị của hoạt động đầu tiên. Cụ thể là với đường dẫn path(A1, A2, ..., An), nếu A1 là khả thi thì tất cả các nút còn lại cũng khả thi. Ngược lại, nếu A1 không khả thi thì các nút còn lại cũng không khả thi (ở đây chúng ta đã đơn giản hóa cách tính giá trị đường dẫn, vì thực sự giá trị này còn phụ thuộc vào loại phụ thuộc khả thi). Định nghĩa 2-11: - Đường dẫn khả thi (feasible path): đường dẫn khả thi là đường dẫn mà hoạt động trên nút cuối cùng là khả thi (xem Hình 2-19). - Đường dẫn không khả thi (infeasible path): đường dẫn không khả thi là đường dẫn mà hoạt động trên nút cuối cùng là không khả thi (xem Hình 2-20). Hình 2-19: Đường dẫn khả thi (biểu diễn bằng nét đứt). Hình 2-20: Đường dẫn không khả thi (biểu diễn bằng nét đứt). 59 Nhận xét 2-1: Từ các định nghĩa về kế hoạch khả thi (không khả thi) và đường dẫn khả thi (không khả thi) ở trên, có thể suy ra một kế hoạch là khả thi (hoặc không khả thi) nếu trong nó tồn tại ít nhất một đường dẫn khả thi (hoặc không khả thi) có chứa nút gốc. Ví dụ 2-11: Các hình 2-21 và 2-22 minh họa cho các đường dẫn khả thi trong kế hoạch (được biểu diễn bằng đường nét đứt) của ví dụ sắp xếp dãy số trong hình 2-17. Hình 2-21: Đường dẫn khả thi thứ nhất cho Kế hoạch sắp xếp. Hình 2-22: Đường dẫn khả thi thứ hai cho Kế hoạch sắp xếp. 60 Giải thuật xác định tính khả thi của kế hoạch Từ nhận xét 2-1 ở trên, ta suy ra để xác định tính khả thi của một kế hoạch, chúng ta sẽ dựa vào đồ thị mà tất cả các cạnh đều là các phụ thuộc khả thi hoàn toàn (ta gọi nó là đồ thị khả thi). Còn để xác định tính không khả thi, chúng ta cần dựa vào đồ thị có tất cả các cạnh đều là các phụ thuộc không khả thi (ta gọi nó là đồ thị không khả thi). Vì cả hai loại đồ thị này đều là đồ thị VÀ/HOẶC và quá trình xác định khả thi hay không khả thi là tương tự nhau, nên ở đây chúng ta chỉ trình bầy một giải thuật để xác định tính khả thi. Đối với giải thuật này, đầu vào của nó là một kế hoạch P, đầu ra sẽ xác định xem P là khả thi (FEASIBLE) hoặc chưa xác định (UNKNOWN). Chú ý trạng thái chưa xác định không có nghĩa là không khả thi. Đây là trạng thái trung gian giữa khả thi và không khả thi. Nếu kế hoạch là chưa xác định, thì cần kiểm tra tiếp tính không khả thi của nó dựa vào đồ thị không khả thi. Đối với kiểm tra tính không khả thi, thì đầu ra cũng có hai trạng thái: không khả thi (INFEASIBLE) và chưa xác định. Ý tưởng khái quát của giải thuật này, việc kiểm tra tính khả thi sẽ xuất phát từ nút hoạt động gốc, sau đó nó sẽ đi theo các cung là các phụ thuộc khả thi để tìm đường dẫn khả thi. Nếu như tồn tại ít nhất một đường dẫn khả thi thì kế hoạch sẽ khả thi. Còn trái lại thì kết luận là kế hoạch chưa xác định. Như vậy, giải thuật này sẽ sử dụng chiến lược duyệt theo chiều sâu (Depth First Search – DFS), là chiến lược tìm được tất cả các đường dẫn xuất phát từ một nút. Tuy nhiên, ở đây xuất hiện hai vấn đề đối với cách biểu diễn đồ thị VÀ/HOẶC hiện tại cho kế hoạch. Thứ nhất, đó là tính khả thi của một nút không chỉ phụ thuộc vào một nút kế tiếp mà có thể nhiều nút, nên trong quá trình kiểm tra, từ một nút ta cũng cần truy nhập vào nhiều nút kế tiếp. Do đó, chiến lược tìm kiếm sẽ kết hợp cả chiến lược duyệt theo chiều rộng (Breadth First Search – BFS). Thứ hai, đó là trong đồ thị này, mỗi cung nối từ nút A2 đến nút A1 là một cạnh có hướng (directed arc) biểu diễn một phụ thuộc khả thi A2 → A1. Nhưng trong phép duyệt theo chiều sâu, thì thứ tự truy nhập lại từ nút gốc đến các nút khác, tức là từ nút A1 rồi mới đến A2. Để giải quyết vấn đề này, có một giải pháp đơn giản là trước khi thực hiện giải thuật, cần tạo ra đồ thị đảo của đồ thị ban đầu (đồ thị đảo Gcủa một đồ thị G là đồ thị giữ nguyên các nút, nhưng có các cạnh là đảo ngược so với G). Giải thuật kiểm tra được cài đặt dưới dạng một hàm đệ quy bằng ngôn ngữ lập trình C++, gọi là CheckFeasible(), được trình bầy trong Giải thuật 2-1. Hàm này có sử dụng một số hàm phụ và các kiểu dữ liệu đã định nghĩa trước, với ý nghĩa như được trình bầy trong Bảng 2-2. Chú thích: để tiện theo dõi các cặp ngoặc nhọn biểu diễn khối lệnh trong hàm, các ngoặc đóng và mở tương ứng sẽ được đánh cùng một chỉ số. Ví dụ “{1” là ngoặc mở của ngoặc đóng “}1”, “{2” là ngoặc mở của ngoặc đóng “}2”, v.v. Đối với danh sách các hoạt động con L, ta dùng ký hiệu L[i-1] để lấy hoạt động thứ i. Như vậy, hoạt động nằm ở đầu danh sách là L[0]. 61 Giải thuật 2-1: Giải thuật xác định tính khả thi của kế hoạch. Kế hoạch P(LA, F), trong đó LA là danh sách các hoạt động, F là tập các phụ thuộc khả thi. Đầu vào: Trong đó: LA = {A1, A2, …, An} ; A1 là hoạt động gốc. Vì kế hoạch được biểu diễn bằng đồ thị VÀ/HOẶC, từ nút gốc A1 có thể truy nhập được tất cả các nút khác, với các nhánh biểu diễn các phụ thuộc khả thi, nên trong thủ tục kiểm tra chỉ cần truyền vào nút gốc A1 là nó sẽ đại diện cho toàn bộ kế hoạch P. Đảo ngược đồ thị biểu diễn P. Đầu ra: Xử lý: Kết quả kiểm tra P là khả thi (FEASIBLE) hoặc chưa xác định (UNKNOWN). 1. STATE CheckFeasible(Activity A1) {0 2. if (GetState(A1) = FEASIBLE) return FEASIBLE; 3. else {1 4. ActivityList L = GetChildren(A1); 5. int m = Size(L); 6. switch (m) {2 7. case 0: //Danh sách rỗng 8. return UNKNOWN; 9. case 1: //Danh sách chỉ có một hoạt động 10. return CheckFeasible(L[0]); 11. default: {3 12. if (GetType(A1) = AND) {4 13. int i = 0; 14. while (i < m && CheckFeasible(L[i]) = FEASIBLE) i++; 15. if (i >= m) return FEASIBLE; 16. else return UNKNOWN; 17. }4 else {5 //A1 là nút OR 18. int i = 0; 19. while (i < m && CheckFeasible(L[i]) = UNKNOWN) i++; 20. if (i >= m) return UNKNOWN; 21. else return FEASIBLE; 22. }5 23. }3 24. }2 25. }1 26. }0 62 Bảng 2-2: Một số kiểu dữ liệu và hàm phụ cho giải thuật 2-1. Tên hàm/dữ liệu Ý nghĩa Khai báo STATE Dữ liệu kiểu liệt kê, biểu diễn các trạng thái của hoạt động, cũng là trạng thái của kế hoạch như FEASIBLE, INFEASIBLE, UNKNOWN. enum STATE {FEASIBLE, INFEASIBLE, UNKNOWN}; getState(Activity A) Hàm trả về trạng thái hiện tại của một hoạt động, được biểu diễn bằng một nút trong đồ thị. STATE getState(Activity A); ActivityList Kiểu dữ liệu biểu diễn danh sách các hoạt động. GetChildren(Activity A) Hàm trả về các hoạt động con của của một hoạt động A. Đó là các hoạt động mà xác định khả thi A. Tức là, nếu A1 → A2, thì A1 là nút con của A2 trong đồ thị. ActivityList GetChildren(Activity A); Size(ActivityList L) Hàm trả về số lượng các hoạt động của danh sách L int Size(ActivityList L); GetType(Activity A) Hàm trả về kiểu của hoạt động A, nó có thể là một trong hai loại, nút AND hoặc nút OR. enum NODETYPE {AND, OR}; NODETYPE GetType(Activity A); Định lý 2-1: Giải thuật 2-1 là dừng và xác định đúng trạng thái của một kế hoạch có nút gốc là A1. Chứng minh: Có hai vấn đề cần chứng minh: thứ nhất là giải thuật trên là dừng và thứ hai là nó đúng. 1. Chứng minh tính dừng: giải thuật 2-1 thực ra là giải thuật duyệt đồ thị theo chiều sâu, bắt đầu từ nút gốc A1, vì mục đích của giải thuật là tìm các đường dẫn khả thi trong đồ thị. Nên số nút mà giải thuật phải thăm nhiều nhất là n (là số lượng hoạt động trong kế hoạch). Do số lượng hoạt động trong một kế hoạch là hữu hạn, nên chắc chắn giải thuật này sẽ dừng. 2. Chứng minh tính đúng đắn: Để chứng minh tính chất này, ta sẽ chỉ ra giải thuật đã dự trù tất cả các khả năng của kế hoạch để xác định đúng trạng thái của nó. Kế hoạch khả thi khi nó chứa ít nhất một đường dẫn khả thi. Ở dòng lệnh 2, giải thuật kiểm tra nếu nút gốc A1 đã khả thi thì hiển nhiên kế hoạch đã khả thi và giải thuật sẽ dừng. Còn trái lại, 63 quá trình tìm đường dẫn khả thi sẽ tiếp tục với các nút con của A1, được đặt ở danh sách L (dòng lệnh 4). Ở đây lại có ba khả năng đối với L: a. Nếu L rỗng: tức là A1 không có phụ thuộc khả thi vào hoạt động nào nữa, mà nó cũng đang ở trạng thái UNKNOWN, nên trạng thái của kế hoạch cũng phải là UNKNOWN. b. Nếu L có đúng một hoạt động: thì rõ ràng tính khả thi của A1 sẽ phụ thuộc vào hoạt động con này, nên có lời gọi đệ quy để kiểm tra và trả về trạng thái của hoạt động con này (dòng lệnh 10). c. Nếu L có từ hai hoạt động trở lên: lúc này lại tùy thuộc vào A1 là loại nút nào trong đồ thị VÀ/HOẶC. Có một trong hai khả năng: i. Nếu A1 là nút AND: khi đó cần kiểm tra tất cả các nút con của nó trong L. Nếu tất cả chúng đều khả thi thì A1 khả thi (các dòng lệnh 13-15). Còn trái lại thì A1 chưa xác định (dòng lệnh 16). ii. Nếu A1 là nút OR: khi đó cần kiểm tra tất cả các nút con của nó trong L. Nếu tất cả chúng đều chưa xác định thì A1 cũng chưa xác định (các dòng lệnh 18-20). Còn trái lại thì A1 khả thi (dòng lệnh 21). Như vậy, giải thuật trên là dừng và đúng đắn. 2.2 Khung cộng tác đa dụng 2.2.1 Các yêu cầu đối với khung cộng tác đa dụng Phần này sẽ trình bày về khái niệm của một khung cộng tác đa dụng có hỗ trợ kế hoạch và các yêu cầu của khung đó. Định nghĩa 2-12. Khung cộng tác có hỗ trợ kế hoạch: là một hệ thống phần mềm hỗ trợ việc quản lý các kế hoạch, ít nhất là các thao tác sau đây: - - - - Định nghĩa các hoạt động: hệ thống cần phải hỗ trợ một hoặc một số ngôn ngữ thích hợp cho phép định nghĩa các hoạt động. Các ngôn ngữ luồng công việc như BPMN và BPEL rất thích hợp cho thao tác này (Phần mô tả các hoạt động sử dụng ngôn ngữ luồng công việc sẽ được trình bầy trong phần sau 2.2.2). Quản lý kế hoạch: như đã trình bầy ở phần Mô hình kế hoạch, mỗi kế hoạch được biểu diễn dưới dạng một đồ thị VÀ/HOẶC. Có thể sử dụng một trong các cách cài đặt đồ thị trong Lý thuyết đồ thị để cài đặt cho cho kế hoạch. Trong cài đặt đó, cần cài đặt các thao tác cho phép cập nhật kế hoạch, như thêm/bớt hoạt động, thêm/bớt các phụ thuộc khả thi; các phép tìm kiếm hoạt động và phụ thuộc khả thi. Làm mịn (Refinement): Là quá trình chuyển đổi tự động hay bán tự động kế hoạch từ mức này sang mức khác (Quá trình này sẽ được trình bày chi tiết hơn ở Chương 3). Thực thi (Execution): Cho phép thực thi kế hoạch nhờ các engine thực thi hay hạ tầng tính toán nào đó. Việc thực thi sẽ ra kết quả nào đó, và kế hoạch là thành công nếu kết quả thực thi là khớp với kết quả mong muốn. Trái lại kế hoạch là chưa thành công và kế hoạch cần được thay đổi lại cho phù hợp. 64 Tổng quan về khung cộng tác được minh họa ở Hình 2-23. Như có thể thấy, khung cộng tác có khả năng hỗ trợ nhiều người dùng cùng tham gia vào quá trình quản lý các kế hoạch, từ việc xây dựng kế hoạch, chuyển đổi nó sang các mức chi tiết hơn mà có thể thực thi được, rồi thực thi và giám sát kế hoạch. Hình 2-23: Tổng quan về khung cộng tác đa dụng 2.2.2 Mô tả các hoạt động Phần này sẽ trình bày chi tiết hơn về vấn đề mô tả các hoạt động. Trong phần trước, khi dùng định nghĩa về hoạt động hay sơ đồ hoạt động, có thể thấy là mô tả đó còn khá trừu tượng, nhất là phần biểu diễn các quan hệ giữa các thành phần khá sơ sài. Các mô tả đó gắn với các ba thành phần chính là Chủ thể, Đối tượng đích và Công cụ. Trong phần này, luận án sẽ đưa ra hai cách biểu diễn mới giúp biểu diễn chi tiết và đầy đủ hơn về các hoạt động: đặc tả hoạt động (activity specification) và mô hình hóa dựa trên luồng công việc (workflow-based modeling). Đặc tả hoạt động Xuất phát từ định nghĩa 2-1 về hoạt động và sơ đồ hoạt động ở Hình 2-1, đặc tả hoạt động sẽ bổ sung thêm một số thành phần còn thiếu, chưa rõ ràng, chưa đầy đủ trong các mô tả. Bảng 2-2 biểu diễn cấu trúc của một đặc tả hoạt động mà bao gồm các trường thông tin với ý nghĩa như sau: 1. 2. Tên của hoạt động (Activity Name): tên này cần rõ ràng và ngắn gọn. Tóm tắt (Abstract): diễn giải ngắn gọn về các mục tiêu của hoạt động (đối tượng tường minh hoặc ngầm định của hoạt động). Chủ thể của hoạt động cũng có thể được giới thiệu ở đây. 65 3. 4. 5. 6. 7. Đối tượng (Object): liệt kê các đối tượng đích của hoạt động. Chủ thể (Subject): liệt kê các chủ thể của hoạt động. Khi phần này được để trống có nghĩa là chủ thể chưa được xác định hoặc chưa quan trọng tại thời điểm đặc tả này. Công cụ (Tool): liệt kê các công cụ trung gian của hoạt động. Tương tự như mục Subject, mục này cũng có thể được để trống. Liên kết (Relationships): liệt kê các liên kết giữa các thành phần của hoạt động. Đối với hoạt động đơn, thì phần này mô tả khái quát mối quan hệ giữa ba thành phần Chủ thể, Đối tượng và Công cụ. Còn đối với hoạt động tập thể, liên kết này bao gồm các danh mục các hoạt động con và các mối quan hệ phụ thuộc giữa chúng. Diễn giải (Explanation): diễn giải chi tiết quá trình thực thi hoạt động, mô tả chi tiết hơn các bước (có thể là các hoạt động con) cần tiến hành của hoạt động. Qua đó cũng mô tả chi tiết hơn việc chủ thể sử dụng công cụ để tạo ra đối tượng đích như thế nào. Bảng 2-3: Cấu trúc của một đặc tả hoạt động Tên hoạt động: Tóm tắt: Đối tượng Chủ thể Công cụ Liên kết Diễn giải Ví dụ 2-12: Minh họa việc sử dụng đặc tả hoạt động để biểu diễn cho hoạt động Học đã được nêu ở Ví dụ 2-2. Bảng 2-4 trình bày các nội dung của đặc tả này. 66 Bảng 2-4: Đặc tả hoạt động cho hoạt động Học một chủ đề Tên hoạt động: Học một chủ đề Tóm tắt: Một sinh viên muốn học một chủ đề nào đề Đối tượng Chủ thể Công cụ Kiến thức về chủ đề Sinh viên Các tài liệu liên quan Liên kết Tìm(Sinh viên, Nguồn tìm kiếm, Tài liệu liên quan) NghiênCứu(Sinh viên, Tài liệu liên quan, Kiến thức) Diễn giải Tiến trình học gồm có hai bước. Đầu tiên, sinh viên cần tìm kiếm các tài liệu liên quan đến chủ đề muốn học từ các nguồn sẵn có như thư viện, hiệu sách, bạn bè, mạng,v.v. Sau đó, sinh viên sẽ phải nghiên cứu các tài liệu tìm được để hiểu về chủ đề. Từ ví dụ 2-12 ở trên có thể thấy rằng, mặc dù đặc tả hoạt động đã chi tiết và đầy đủ hơn sơ đồ hoạt động, nhưng vẫn còn khá trừu tượng và thiếu hình thức, nên vẫn còn xa mới có thể làm cho máy tính hiểu được, để từ đó có thể phân tích và thực thi tự động được nó. Nhất là đối với hoạt động tập thể có chứa các hoạt động con và các mối quan hệ phụ thuộc giữa chúng, cách biểu diễn đặc tả ở trên lại càng không phù hợp, vì vậy còn khá dài dòng và thiếu trực quan. Do đó, cần có những cách biểu diễn khác hình thức hơn, nhưng vẫn cần đủ chi tiết để nó có thể được hiểu và thực thi bởi máy tính. Đó là lý do dẫn đến cách biểu diễn thứ hai cho các hoạt động tập thể sẽ đề cập ở phần sau trong luận án. Đó là mô hình hóa dựa trên luồng công việc. Mô hình hóa dựa trên luồng công việc Trong thời gian gần đây, việc nghiên cứu khả năng áp dụng các kỹ thuật luồng công việc trong việc biểu diễn, kiểm soát và thực thi các tiến trình nghiệp vụ đã và đang thu được rất nhiều các kết quả khả quan. Phần này sẽ xem xét việc áp dụng công nghệ này, đặc biệt là ngôn ngữ luồng công việc trong việc biểu diễn các hoạt động. Trong hai ngôn ngữ luồng công việc được lựa chọn trong nghiên cứu của luận án BPMN [70] và BPEL [68], BPMN là ngôn ngữ được dùng để biểu diễn các hoạt động (mà sau này còn được gọi là kế hoạch) ở mức logic nghiệp vụ, sẽ được trình bày chi tiết hơn ngay trong phần này. Còn BPEL sẽ được dùng để biểu diễn các hoạt động ở mức thực thi vật lý - có thể tự động thực thi nhờ các BPEL engine phù hợp (Phần Phụ lục B sẽ trình bày chi tiết hơn về các hệ thống và ngôn ngữ luồng công việc). Sử dụng ngôn ngữ luồng công việc để biểu diễn cho các hoạt động có một số ưu điểm như sau: 67 - - Cách biểu diễn này thường dễ hiểu và dễ kiểm soát hơn cách sử dụng đặc tả hoạt động, đã được dùng ở phần trên, do các ngôn ngữ luồng công việc đều có các công cụ mô hình hóa biểu diễn trực quan. Điều này có thể thấy rõ hơn sau khi xem xét ví dụ 2-13 sẽ được minh họa ở ngay sau đây. Các ngôn ngữ luồng công việc thường hỗ trợ hai cách biểu diễn: cách biểu diễn trực quan đã nói ở trên nhằm hướng đến người dùng, và cách biểu diễn dựa trên ngôn ngữ XML nhằm hướng đến việc xử lý tự động. Hơn nữa, hai cách biểu diễn này thường có thể được chuyển đổi qua lại dễ dàng trong các hệ thống luồng công việc. (Xem Ví dụ 2-13 sau đây để hình dung rõ hơn về hai cách biểu diễn này). Dựa trên cách biểu diễn dùng đặc tả hoạt động, cách biểu diễn mô hình hóa dựa trên luồng công việc có các đặc điểm sau: - Kế thừa năm trường thông tin của đặc tả hoạt động là Tên hoạt động, Tóm tắt, Đối tượng, Chủ thể, Công cụ. Do hai trường Liên kết và Diễn giải trong đặc tả hoạt động có những thông tin trùng lặp (vì bản thân các liên kết đều nằm trong phần Diễn giải), nên hai trường này sẽ được gộp chung thành một trường mới là Mô hình. Trong trường này, một ngôn ngữ luồng công việc phù hợp (BPMN là ngôn ngữ được chọn ở đây) để mô hình hóa phần Liên kết và các bước thực hiện trong phần Diễn giải trước đây. Dễ dàng nhận thấy các thành phần của hoạt động có thể được chuyển sang các thành phần thích hợp của ngôn ngữ luồng công việc. Bảng 2-5 mô tả cụ thể việc chuyển đổi (còn được gọi là ánh xạ) từng thành phần của hoạt động sang các thành phần của luồng công việc BPMN. Chi tiết về các thành phần của ngôn ngữ được trình bày trong [69][70] và được luận án tóm tắt trong phần phụ lục B.3. 68 Bảng 2-5: Ánh xạ từ các thành phần của hoạt động sang luồng công việc. Thành phần của hoạt động Thành phần của luồng công việc Chủ thể Data input (dữ liệu vào) Công cụ Data input (dữ liệu vào) Mục tiêu Data output (dữ liệu ra) Hoạt động đơn A(S,T,O) Task (nhiệm vụ) Chú thích/Ký hiệu Có hai cách biểu diễn hoạt động đơn: - Cách đơn giản: chỉ cần có nhiệm vụ A; - Cách đầy đủ: ngoài nhiệm vụ A thì sẽ có đầy đủ các thành phần S, T và O. A Cách đơn giản S O A T Cách đầy đủ Hoạt động tập thể Process (tiến trình) Thành phần này của luồng công việc được dùng để biểu diễn cho một tiến trình ngiệp vụ mà trong đó thường bao gồm nhiều nhiệm vụ (task). Nên nó hoàn toàn thích hợp để biểu diễn cho một hoạt động tập thể, mà trong đó lại chứa nhiều hoạt động con. Các quan hệ phụ thuộc Các Gateway và Connecting Object Các quan hệ phụ thuộc giữa một cặp hoạt động sẽ ảnh hưởng đến thứ tự thực thi chúng, mà điều này cần có các cơ chế điều khiển. Đây lại chính là nhiệm vụ của các gateway và connecting object trong ngôn ngữ luồng. 69 Chung đầu vào Data input Hai hoạt động sẽ có chung Data input. Vào-Ra Data input và Data output Data output của hoạt động này sẽ là Data input của hoạt động kia. Khi hai hoạt động có quan hệ này thì sẽ sinh ra một thứ tự tuần tự (sequence) giữa chúng. A1 Rẽ nhánh A2 Exclusive gateway (hay Fork gateway) A1 A2 Đồng bộ Merge gateway (hay Join gateway) A1 A2 Ví dụ 2-13 minh họa cách biểu diễn bằng mô hình hóa dựa trên luồng công việc này. Ví dụ 2-13: Cách biểu diễn bằng mô hình dựa trên luồng công việc được chia làm hai phần: Phần đầu chứa năm trường thông tin giống như trong đặc tả hoạt động (Bảng 2-6); Phần Mô hình được biểu diễn bằng ngôn ngữ luồng Xử lý yêu cầu làm thẻ và BPMN là ngôn ngữ được dùng để mô hình hóa với hai cách thể hiện: cách thể hiện trực quan ở Hình 2-24 và cách thể hiện bằng XML ở Hình 2-25. Bảng 2-6: Mô hình hóa cho hoạt động “Xử lý yêu cầu làm thẻ” (phần đầu). Tên hoạt động: Xử lý yêu cầu làm thẻ ngân hàng Tóm tắt: hoạt động này nhằm xử lý các yêu cầu làm thẻ mà khách hàng gửi đến ngân hàng Đối tượng Chủ thể Công cụ Thẻ ngân hàng Khách hàng, nhân viên Ngân Mẫu yêu cầu làm thẻ hàng 70 Bắt đầu Kiểm tra yêu cầu Gửi yêu cầu Kết thúc Thông báo hủy y/c Hủy bỏ yêu cầu Y/c hợp lệ? Ko Có Tạo thẻ Chấp nhận yêu cầu Gửi thẻ đến NSD Thông báo chấp nhận Hình 2-24: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn trực quan). SequenceFlow1 SequenceFlow1 SequenceFlow2 ... Hình 2-25: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn bằng XML). Việc thiết kế và cài đặt khung cộng tác này sẽ lần lượt được trình bày chi tiết hơn trong chương 4. 71 2.3 Các nghiên cứu liên quan Trong [1], một hệ hình thức về hành động dựa trên logic vị từ và logic thời gian đã được giới thiệu. Hệ hình thức này được xây dựng nhằm hai mục tiêu. Mục tiêu thứ nhất là nâng cao khả năng biểu diễn của các lý thuyết về hành động trước đó nhằm giúp định nghĩa các ý nghĩa của các câu tiếng Anh mô tả các hành động. Mục tiêu thứ hai nhằm đề xuất một biểu diễn hữu dụng cho việc suy diễn hành động để hỗ trợ việc giải quyết các bài toán. Trong hệ hình thức này, một kế hoạch được mô hình hóa như một hợp thành của hai tập hợp hành động: TO-DO là tập hợp hành động mà kế hoạch phải thực hiện và NOT-TO-DO là tập hợp hành động mà kế hoạch không phải thực hiện. Nghiên cứu của luận án về mô hình kế hoạch lại không theo cách tiếp cận logic như trên, luận án chọn tiếp cận ngôn ngữ luồng công việc. Có hai lý do cho sự lựa chọn này:   Thứ nhất, khái niệm kế hoạch trong luận án rộng hơn khái niệm kế hoạch được dùng trong Lý thuyết Hoạt động. Trong khi kế hoạch được dùng trong Lý thuyết Hoạt động chỉ là tập các hành động, trong kế hoạch được đề xuất trong luận án còn thêm ba thành phần: Đối tượng, Chủ thể, Công cụ. Hơn nữa, các thành phần này lại luôn biến đổi trong các kế hoạch, không cố định (do các quá trình chi tiết hóa và khái quát hóa các kế hoạch). Chính đặc điểm này làm cho việc sử dụng logic để biểu diễn sẽ không dễ dàng và thuận lợi. Thứ hai, khung kế hoạch được nghiên cứu đề xuất trong luận án hướng đến việc hỗ trợ các kế hoạch lớn và phức tạp. Điều này đòi hỏi có những công cụ biểu diễn cho các kế hoạch một cách trực quan và rõ ràng, nhằm giảm thiểu các hiểu nhầm hoặc thậm chí hiểu sai các nội dung trong kế hoạch. Thực tế cho thấy việc sử dụng logic rất khó đạt được yêu cầu này, trong khi các ngôn ngữ luồng công việc hỗ trợ khả năng này rất tốt. Ngoài ra, các kỹ thuật luồng công việc cũng có nhiều hỗ trợ trong việc chuyển đổi kế hoạch, thực thi các kế hoạch trong các môi trường tính toán. Trong [89] và [19], vai trò của kế hoạch trong các hoạt động và mối quan hệ giữa kế hoạch và hành động cũng đã được nghiên cứu và trình bày. Tuy nhiên, các nghiên cứu này vẫn thiếu một hệ hình thức cho lý thuyết hoạt động và cũng chưa sử dụng cách tiếp cận luồng công việc như trong luận án. Trong [50], các tác giả cũng đề xuất một khung dựa trên lý thuyết hoạt động và nhằm hỗ trợ việc thiết kế các môi trường học có tính xây dựng (Constructivist Learning Environments). Tuy nhiên, khung này chưa đưa ra cách mô tả việc xây dựng các môi trường đó và cũng không hỗ trợ việc xây dựng các kế hoạch hành động. Trong [22] [21], một khung có tên gọi Tính toán dựa trên hoạt động (Activity-Based Computing) đã được đề xuất nhằm hỗ trợ các hoạt động, nhất là các hoạt động có yêu cầu cao về tính di động, khả năng cộng tác và có tính khẩn cấp, như trong các hoạt động điều trị y tế. Thực thể cơ bản nhất của khung là hoạt động tính toán (computational activity), là một sự kết hợp của các dịch vụ, tài nguyên, công cụ và người dùng có liên quan mật thiết đến một hoạt động nào đó. Khung cũng cung cấp một hạ tầng (infrastructure) có tên gọi Hạ tầng 72 tính toán dựa trên hoạt động với mục đích hỗ trợ người dùng quản lý các hoạt động tính toán. Nghiên cứu của luận án tuy cùng chia sẻ ý tưởng với các nghiên cứu này về việc sử dụng tiếp cận Lý thuyết Hoạt động, nhưng lại đi theo một cách tiếp cận khác là sử dụng các kỹ thuật luồng công việc trong việc biểu diễn các kế hoạch hành động. KẾT LUẬN CHƯƠNG Trong chương này, dựa trên tiếp cận của Lý thuyết Hoạt động, mô hình về kế hoạch đã đưa ra [15]. Mô hình giúp làm rõ hơn nhiều khái niệm liên quan đến kế hoạch như hoạt động, hành động, tính khả thi, v.v. Luận án đề xuất vai trò của ngôn ngữ luồng công việc trong việc biểu diễn kế hoạch và kết hợp chúng trong mô hình. Từ mô hình này, các yêu cầu của một khung hỗ trợ kế hoạch cũng được phác họa. Việc thiết kế chi tiết và cài đặt cho khung sẽ được trình bày trong các chương tiếp theo. Có thể thấy, việc xây dựng một bản kế hoạch là xuất phát từ một hoạt động gốc, sau đó các hoạt động mới xác định khả thi các hoạt động hiện có sẽ được phát hiện và bổ sung thêm vào kế hoạch. Các hoạt động mới càng được bổ sung, kế hoạch càng chi tiết hơn và tính khả thi cũng tăng lên, vì khả năng tìm được đường dẫn khả thi cũng nhiều lên. Quá trình xây dựng kế hoạch như thế này cũng được gọi là làm mịn kế hoạch. Tuy nhiên, nếu chỉ dựa vào các định nghĩa và tính chất của phụ thuộc khả thi để xác định các hoạt động mới thì dường như không dễ dàng đối với người dùng thông thường. Khó khăn này cần được khắc phục bằng cách tiếp cận khác, thân thiện hơn với người dùng. Hơn nữa, mặc dù việc biểu diễn hoạt động tập thể bằng ngôn ngữ BPMN giúp làm rõ hơn logic của nó, nhất là quan hệ giữa các hoạt động con của hoạt động, nhưng vẫn chưa đủ để xác định được tính khả thi của hoạt động. Vì tính khả thi của một hoạt động phải được kiểm chứng qua việc thực thi trên một môi trường tính toán nào đó. Trong khi đó, ngôn ngữ BPMN lại là ngôn ngữ hướng đồ thị nhằm mô tả và phân tích các hoạt động, chưa tập trung vào việc thực thi chúng. Vấn đề này có thể được giải quyết bằng các phương pháp chuyển đổi hoạt động được biểu diễn bằng BPMN sang ngôn ngữ có tính thực thi cao hơn như BPEL (Business Process Execution Language). Các vấn đề nêu trên sẽ được trình bầy chi tiết trong Chương 3. 73 CHƯƠNG 3: LÀM MỊN KẾ HOẠCH Chương này sẽ tập trung trình bày các vấn đề liên quan đến việc làm mịn kế hoạch, là quá trình kế hoạch được chuyển đổi dần dần từ dạng còn khá trừu tượng và chưa rõ tính khả thi sang các dạng chi tiết hơn và tính khả thi ngày càng cao hơn. Trong chương 2, luận án đã đề xuất mô hình kế hoạch, theo đó cấu trúc của bản kế hoạch là một tập các hoạt động mà được sinh ra từ một hoạt động gốc. Việc sinh ra một hoạt động mới từ một hoạt động cũ là do giữa chúng có một quan hệ phụ thuộc khả thi. Tuy nhiên, có thể thấy rằng nếu chỉ dựa vào phụ thuộc khả thi (PTKT) để tìm kiếm các hoạt động mới, quá trình này cũng không hề dễ dàng và khá mất thời gian. Chương này sẽ đề xuất một biện pháp giúp khắc phục hạn chế này, được gọi là chi tiết hóa. Ngoài ra, việc sử dụng ngôn ngữ luồng để biểu diễn cho hoạt động đã được đề cập ở Chương 2, trong đó ngôn ngữ BPMN đã được chọn. Tuy nhiên, đối với một hoạt động, việc sử dụng BPMN để mô tả nó không phải là lựa chọn duy nhất, có thể được biểu diễn bằng các ngôn ngữ luồng khác, như BPEL. Hơn nữa, mặc dù việc biểu diễn hoạt động tập thể bằng ngôn ngữ BPMN giúp làm rõ hơn logic của nó, nhất là quan hệ giữa các hoạt động con của hoạt động, nhưng vẫn chưa đủ để xác định được tính khả thi của hoạt động. Vì tính khả thi của một hoạt động phải được kiểm chứng qua việc thực thi trên một môi trường tính toán nào đó. Trong khi đó, ngôn ngữ BPMN lại là ngôn ngữ hướng đồ thị nhằm mô tả và phân tích các hoạt động, chưa tập trung vào việc thực thi chúng. Vấn đề này có thể được giải quyết bằng các phương pháp chuyển đổi hoạt động được biểu diễn bằng BPMN sang ngôn ngữ có tính thực thi cao hơn như BPEL. Tuy nhiên, việc chuyển đổi thủ công từ một hoạt động sang các ngôn ngữ luồng khác nhau khá chậm chạp và phức tạp, nhất là đối với các ngôn ngữ luồng ở mức thực thi như BPEL. Ngoài ra, việc này cũng dễ tạo ra các biểu diễn không nhất quán cho cùng một hoạt động. Do đó, một giải pháp để giải quyết vấn đề này là làm sao việc chuyển đổi thủ công từ hoạt động sang ngôn ngữ luồng chỉ cần thực hiện một lần cho một ngôn ngữ. Sau đó, cần có các kỹ thuật phù hợp cho phép tự động hóa quá trình chuyển đổi hoạt động được biểu diễn từ ngôn ngữ này sang ngôn ngữ kia. Chương này sẽ trình bày về các kỹ thuật chuyển đổi này, đặc biệt là việc chuyển đổi từ ngôn ngữ luồng hướng đồ thị như BPMN sang ngôn ngữ luồng hướng cấu trúc như BPEL. Đồng thời, giải thuật giúp giải quyết một trong số các vấn đề liên quan cũng được đề xuất. Giải thuật này đã được luận án công bố trong [17]. 3.1 Chi tiết hóa kế hoạch Trong Mô hình Kế hoạch đã được trình bày ở chương 2, cấu trúc của kế hoạch bao gồm một tập các hoạt động được sinh ra từ một hoạt động gốc nhờ các quan hệ phụ thuộc khả thi. Tuy nhiên, nếu chỉ dựa vào phụ thuộc khả thi (PTKT) để tìm kiếm các hoạt động mới sẽ không hề dễ dàng vì một số lý do như sau: 74 - Thứ nhất: định nghĩa về PTKT chưa thực sự giúp xác định tình huống khi nào sẽ xuất hiện PTKT. Vấn đề này cũng tương tự như trong thiết kế cơ sở dữ liệu, việc áp dụng các quy tắc phụ thuộc hàm để tìm các phụ thuộc hàm sẽ rất khó khăn, nếu thiếu các liên hệ về các quy tắc nghiệp vụ mà có thể sinh ra các phụ thuộc hàm. - Thứ hai: dựa vào các PTKT thì có thể sinh ra các hoạt động mới trong kế hoạch, nhưng chưa đạt được mục tiêu cuối cùng của việc sinh ra các hoạt động mới – đó là làm sao nhanh chóng tìm được các hoạt động mới khả thi để nhanh chóng xác định được tính khả thi của hoạt động gốc và toàn bộ kế hoạch. Nguyên nhân của vấn đề là do bản chất của việc tìm kiếm hoạt động mới mà chỉ dựa vào PTKT là tìm kiếm có tính mò mẫm, may rủi. Nếu may mắn thì sẽ tìm được hoạt động khả thi, còn nếu không thì không biết lúc nào quá trình tìm kiếm này mới dừng lại. Từ các vấn đề trên, có thể thấy sự cần thiết của việc tìm kiếm các cách chuyển đổi hoạt động mới, với mục tiêu vừa tận dụng cách chuyển đổi dựa vào PTKT, vừa giúp cho quá trình phát hiện các hoạt động khả thi, qua đó xác định tính khả thi của kế hoạch được nhanh chóng và dễ dàng hơn. Các kế hoạch của một hoạt động có thể đóng một trong hai vai trò như sau: - Công cụ cụ thể (Specific tool): với vai trò này, các kế hoạch giúp hình thành con đường để đạt được mục tiêu của hoạt động. Mỗi hoạt động tồn tại trong một tình huống cụ thể nào đó mà các kế hoạch phải tính đến, để chúng có thể khả thi trong tình huống đó. Điều này có nghĩa là các kế hoạch phải phù hợp tối đa với hoạt động của chúng trong tình huống cụ thể. Để thực hiện được vai trò này, các kế hoạch sẽ trải qua một quá trình chi tiết hóa (process of specialization): chúng sẽ trở nên càng ngày càng cụ thể hơn đối với hoạt động trong tình huống cụ thể. - Công cụ khái quát (General tool): Sau khi một kế hoạch đã được áp dụng thành công trong một hoạt động, đương nhiên ta muốn nó lại có thể được áp dụng trong các hoạt động tương tự. Để thực hiện được vai trò này, các kế hoạch sẽ trải qua một quá trình khái quát hóa (process of generalization): ngược với quá trình chi tiết hóa ở trên. Trong quá trình này, các kế hoạch sẽ trở nên càng ngày càng khái quát để chúng có thể áp dụng vào các hoạt động trong các tình huống khác nhau. Hiện có ba cách tiếp cận mới trong việc chuyển đổi các hoạt động trong kế hoạch : - Chi tiết hóa : là quá trình chuyển dần dần một hoạt động ở mức trừu tượng và chưa khả thi sang các hoạt động mới ở mức chi tiết hơn và cuối cùng đạt được các hoạt động đủ chi tiết để có thể khả thi. - Khái quát hóa : là quá trình ngược lại của quá trình chi tiết hóa trên. - Chuyển đổi giữa cách biểu diễn hoạt động : như chúng ta đã thấy trong phần 2.2.2 Mô tả hoạt động, hoạt động có thể được biểu diễn bằng các ngôn ngữ luồng công việc khác nhau. Với một số hoạt động, tính khả thi của chúng được quyết định bởi khả năng có thể thực thi chúng được không. Khả năng thực thi lại phụ thuộc rất nhiều vào ngôn ngữ biểu diễn cho hoạt động. Ví dụ như cùng một hoạt động, nếu 75 biểu diễn bằng ngôn ngữ BPMN thì nó có thể không thực thi được vì ngôn ngữ đó khá trừu tượng, nhưng nếu được biểu diễn bằng ngôn ngữ BPEL, có thể thực thi được. Nhưng do tính phức tạp của BPEL, nó lại không dễ dùng để biểu diễn cho các hoạt động. Trong khi đó BPMN lại thích hợp hơn cho vai trò này. Do đó, nếu có thêm phương pháp chuyển đổi tự động hoặc bán tự động từ BPMN sang BPEL sẽ hỗ trợ rất lớn cho người dùng trong việc biểu diễn và xác định tính khả thi của hoạt động. Trong phần này, luận án cũng sẽ trình bày một giải thuật hỗ trợ cho quá trình chuyển đổi này. Phương pháp chi tiết hóa sẽ được trình bày chi tiết ngay sau đây. Còn phần chuyển đổi giữa các ngôn ngữ, cụ thể là từ ngôn ngữ dạng đồ thị kiểu như BPMN sang ngôn ngữ dạng khối cấu trúc như BPEL sẽ được trình bày chi tiết trong phần sau của chương. Như đã nói ở phần trên, quá trình chi tiết hóa kế hoạch là quá trình chuyển dần dần các hoạt động trong kế hoạch ở mức trừu tượng và chưa thực thi được sang các hoạt động ở mức chi tiết hơn và cuối cùng đạt được các kế hoạch đủ chi tiết để có thể thực thi được. Do đó, quá trình chi tiết hóa cũng còn được gọi là quá trình làm mịn (refinement). Mỗi bước chi tiết hóa có thể ở một trong hai dạng: - Bổ sung chi tiết: được thực hiện khi một hay một số chi tiết còn thiếu nào đó trong một hoạt động cần được bổ sung để tạo ra một hoạt động mới đầy đủ thông tin hơn. - Phân tách: phân rã một thành phần không nguyên tố (có thể chia nhỏ hơn được) nào đó của hoạt động hoặc bản thân hoạt động, thành những thành phần con nhỏ hơn. Quá trình này có thể lặp đi lặp lại cho đến khi các thành phần con được phân rã đã đủ chi tiết ở mức nguyên tố. 3.1.1 Bổ sung chi tiết Quá trình chi tiết hóa cho một hoạt động xảy ra khi một hay một số chi tiết nào đó cần được bổ sung thêm vào trong hoạt động. Do đó, chúng ta có biểu thức khái quát mô tả việc chi tiết hóa này như sau: A' = A + d; trong đó: d là một chi tiết mới cần bổ sung; A' là một hoạt động mới và chi tiết hơn hoạt động cũ A. Chi tiết mới d có thể là một trong số những kiểu sau: - Đối tượng (Object): trường hợp này có nghĩa là chúng ta muốn thêm mục tiêu cho hoạt động ban đầu. Công cụ (Tool): trường hợp này có nghĩa là hoạt động cần thêm công cụ để hoàn thành được mục tiêu. Chủ thể (Subject): trong trường hợp này, hoạt động cần thêm chủ thể tham gia để thực hiện đươc mục tiêu. Hoạt động (Activity): trong trường hợp này, hoạt động A cần thêm một hoạt động mới và A’ sẽ trở thành hoạt động tập thể (collective activity). 76 Hơn nữa, khi một chi tiết mới được thêm vào hoạt động, sẽ cần bổ sung thêm các liên kết liên quan. Ví dụ, sau khi bổ sung một đối tượng, sẽ xuất hiện các liên kết mới giữa đối tượng mới và các đối tượng cũ, cũng như giữa đối tượng mới và các công cụ và chủ thể cũ. Sau đây, luận án sẽ đưa ra một số định nghĩa hình thức hơn cho phương thức bổ sung chi tiết này. Định nghĩa 3-1: Thao tác bổ sung chi tiết (ký hiệu là phép '+') có một số dạng như sau: - - - Bổ sung Chủ thể: Abstract(O) + S = AbstractT(S,O); AbstractS(T,O) + S = Atomic(S,T,O); Bổ sung Công cụ: Abstract(O) + T = AbstractS(T,O); AbstractT(S,O) + T = Atomic(S,T,O); Bổ sung Hoạt động: C(L, R) + A = C’(L ∪ A, R ∪ {r(A, Ai) | Ai ∈ L}), với L=(A1, A2, ..., An); 3.1.2 Phân tách Như đã trình bày ở trên, phép phân tách một hoạt động là thao tác tách một thành phần nào đó của nó thành các thành phần nhỏ hơn. Do một hoạt có thể chứa bốn loại thành phần (chủ thể, công cụ, đối tượng, và hoạt động con), nên về nguyên tắc phép tách có thể áp dụng cho cả bốn thành phần. Tuy nhiên, về mặt thực tiễn chỉ xét hai loại phân tách sau: - Phân tách đối tượng: áp dụng cho việc phân tách hoạt động trừu tượng, khi thành phần đối tượng của nó chưa nguyên tố. - Phân tách hoạt động con: áp dụng cho việc phân tách hoạt động tập thể, trong đó một hoạt động con của nó được tách thành một tập các hoạt động nhỏ hơn. Phép phân tách decomposition được định nghĩa như sau: Định nghĩa 3-2: decomposition(Abstract(O)) = C(L,R), trong đó: O  L (tương đương về chức năng) ; decomposition(C(L, R)) = C’(L \ Ai ∪ Li, R’); trong đó: Ai ∈ L, Ai  Li, R’ = R \ {r(Ai,Aj) |Aj ∈ L} ∪ {r(Ak,Am)|Ak,Am ∈ (L \ Ai ∪ Li)}}; 77 3.1.3 Mối quan hệ giữa chi tiết hóa và phụ thuộc khả thi Dựa vào các tính chất của phụ thuộc khả thi và các phép chi tiết hóa đã trình bày ở trên, có thể nhận thấy giữa chúng có một số quan hệ như sau: - Các phép tách giúp tăng cường tính khả thi của hoạt động: tức là nếu A là hoạt động chưa khả thi thì decomposition(A) có thể khả thi. Điều này có nghĩa là decomposition(A)  A. Đồng thời, do phép tách là phép biến đổi tương đương về chức năng, nên nếu decomposition(A) không khả thi, thì khả năng A là không khả thi cũng rất lớn. - Các phép bổ sung (ngoại trừ bổ sung hoạt động), đều tạo ra hoạt động mới, cho phép xác định khả thi hoạt động cũ. Tức là, nếu A’ = A + d thì A’  A; 3.2 Tăng cường tính khả thi của hoạt động Phần này sẽ trình bày về cách tiếp cận thứ hai giúp tăng cường tính khả thi của kế hoạch. Khác với cách tiếp cận đầu tiên (tìm và bổ sung thêm các hoạt động mới vào bản kế hoạch), cách tiếp cận này lại tìm cách tăng cường tính khả thi của một trong các loại hoạt động hiện có trong kế hoạch, hoạt động tập thể, bằng cách chuyển đổi cách biểu diễn của nó từ ngôn ngữ luồng hướng đồ thị BPMN sang ngôn ngữ luồng có cấu trúc và tính thực thi cao hơn là BPEL. 3.2.1 Các kỹ thuật chuyển đổi Trong thời gian gần đây, vấn đề chuyển đổi giữa hai loại ngôn ngữ luồng công việc là ngôn ngữ hướng đồ thị và ngôn ngữ hướng cấu trúc (với hai ngôn ngữ tiêu biểu là BPMN và BPEL) thu hút được khá nhiều sự chú ý của các nhà nghiên cứu, bởi một số lý do như sau: - Nhu cầu của các phương pháp phát triển hệ thống hướng tiến trình hoàn chỉnh [73]: Tương tự như các phương pháp phát triển phần mềm khác, phương pháp này cũng chia quá trình phát triển phần mềm thành một số giai đoạn tiêu biểu như: phân tích, thiết kế và cài đặt. Ở giai đoạn phân tích và thiết kế, các hoạt động nghiệp vụ trong doanh nghiệp được biểu diễn dưới dạng các mô hình tiến trình nghiệp vụ (business process models). Do các mô hình này chủ yếu dành cho việc trao đổi ở mức cao giữa những nhà phân tích và thiết kế, nên cách biểu diễn phù hợp nhất là bằng các ngôn ngữ hướng đồ thị hay biểu đồ. Trong số các ngôn ngữ loại này, BPMN nổi lên như một ngôn ngữ tiêu chuẩn đang được sử dụng rộng rãi và được hỗ trợ bởi khá nhiều công cụ (khoảng 40 công cụ cho đến nay [100]). Trái lại ở giai đoạn cài đặt, lại đòi hỏi các các công cụ thích hợp để biểu diễn các tiến trình nghiệp vụ mà có thể thực thi được. So với các mô hình nghiệp vụ ở các giai đoạn phân tích và thiết kế, mô hình nghiệp vụ có thể thực thi được ở giai đoạn cài đặt cần bổ sung thêm nhiều chi tiết cài đặt như: thao tác dữ liệu, liên kết ứng dụng,v.v. Ngôn ngữ thích hợp để biểu diễn các ngiệp vụ có thể thực thi được thường là các ngôn ngữ có cấu trúc, trong đó BPEL là ngôn ngữ tiêu biểu. Do đó, việc phát triển các kỹ thuật chuyển đổi tự động hay bán tự động từ các ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc là một nhu cầu tự nhiên và cần thiết. 78 - Cho phép các tiến trình nghiệp vụ thực thi được trong một môi trường tính toán đích: Một số ngôn ngữ luồng công việc hỗ trợ việc thực thi các tiến trình nghiệp vụ trong một số môi trường cụ thể nào đó. Ví dụ như BPEL hỗ trợ trực tiếp việc kết hợp (composition) và gọi các dịch vụ Web (Web service). Ngoài ra, gần đây có một số mở rộng của BPEL cho phép việc gọi các dịch vụ lưới (Grid service) [71] [95] [9]. Tuy nhiên, các tiến trình nghiệp vụ, được biểu diễn bằng các ngôn ngữ ở mức thực thi này thường không dễ nhìn và dễ hiểu với con người, do chứa nhiều chi tiết phức tạp liên quan đến việc gọi và thực thi các dịch vụ bên ngoài. Do đó, đứng ở góc độ người dùng, mong muốn biểu diễn các tiến trình nghiệp vụ bằng các ngôn ngữ hướng đồ thị và sau đó các tiến trình này có thể được dịch tự động sang ngôn ngữ ở mức thực thi được. Trong phần này, chúng ta sẽ điểm lại các kỹ thuật chính hiện nay được dùng để dịch từ ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc nói chung và từ ngôn ngữ BPMN sang BPEL nói riêng, nhằm làm sáng tỏ các ưu điểm và hạn chế của những kỹ thuật này. Do sự không khớp nhau của hai lớp ngôn ngữ, như đã được chỉ ra trong [79], nên vấn đề chuyển đổi giữa chúng không hề đơn giản. Hơn nữa, khi mục đích chuyển đổi khác nhau cũng đòi hỏi phải có các kỹ thuật khác nhau. Điều này càng làm cho vấn đề chuyển đổi thêm khó khăn và phức tạp. Chính vì vậy, trong khuôn khổ nghiên cứu của luận án, sẽ không có tham vọng khảo sát toàn bộ các kỹ thuật này, mà chỉ tập trung vào một phía của việc chuyển đổi. Đó là chuyển đổi từ ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc. Trọng tâm nghiên cứu này cũng phù hợp với một trong những mục tiêu nghiên cứu của luận án, đó là tìm hiểu vấn đề chi tiết hóa kế hoạch. Còn ở chiều ngược lại, luận án dự định sẽ nghiên cứu trong tương lai gần. Mặc dù hiện nay có khá nhiều các kỹ thuật chuyển đổi từ ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc, chúng đều có chung một số mục tiêu như sau [3]: - Đầy đủ (Completeness): làm sao cho kỹ thuật có thể được áp dụng cho bất kỳ topo (topology) nào của tiến trình nguồn (được biểu diễn bằng ngôn ngữ hướng đồ thị). Tự động (Automation): làm sao cho việc chuyển đổi có thể được tiến hành một cách tự động, không cần sự can thiệp của con người. Dễ đọc (Readability): làm sao để tiến trình được tạo ra ở ngôn ngữ đích là dễ đọc và dễ hiểu bởi con người. Vì thực tế cho thấy, dù mức độ tự động của chuyển đổi có tốt đến đâu thì vẫn cần sự can thiệp của con người đối với tiến trình đích. Do đó mục tiêu này nhằm giảm gánh nặng cho người dùng khi phải can thiệp vào tiến trình đích. Trong [65], một số chiến lược cho việc chuyển đổi giữa hai lớp ngôn ngữ đã được đề xuất (sử dụng hai ngôn ngữ BPMN và BPEL để minh họa cho các chiến lược). Trong số đó, có bốn chiến lược áp dụng cho việc chuyển đổi từ ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc: - Bảo toàn các thành phần (Element-preservation): Ý tưởng chung của chiến lược là ánh xạ tất cả các thành phần của tiến trình nguồn sang cấu trúc Flow, và ánh xạ các 79 cung (arcs) sang cấu trúc Link. Chiến lược này tuy đơn giản, nhưng còn tồn tại hai hạn chế đối với tiến trình đích được tạo ra: nó không dễ đọc và chứa nhiều thành phần activity rỗng (empty activities). - Tối thiểu hóa các thành phần (Element-minimization): Chiến lược này nhằm khắc phục hạn chế thứ hai của chiến lược đầu tiên. - Phát hiện các cấu trúc (Structure-identification): Chiến lược này nhằm khắc phục hạn chế đầu (tiến trình đích không dễ đọc) của chiến lược thứ nhất, bằng cách phát hiện các thành phần activity có cấu trúc trong tiến trình nguồn, để từ đó ánh xạ chúng sang các thành phần activity có cấu trúc trong tiến trình đích. - Tối đa hóa các cấu trúc (Structure-maximization): Chiến lược này nhằm nâng cao chiến lược thứ ba bằng cách phát hiện tối đa các activity có cấu trúc trong tiến trình nguồn, từ đó giúp giảm thiểu số lượng các thành phần phải ánh xạ. Nó đồng nghĩa với việc tạo ra tiến trình đích đơn giản và dễ đọc hơn. Trong [70], việc chuyển đổi từ BPMN sang BPEL được gọi là ánh xạ (mapping), và được chia thành hai nhóm: - - Ánh xạ các thành phần cơ bản (Mappings of basic elements): Ở nhóm này, hầu như tất cả các thành phần cơ bản của BPMN (như tasks, sub-processes, activity loops, events, v.v) đều được ánh xạ sang các thành phần tương ứng của BPEL. Ánh xạ các khối cấu trúc (Mappings of Blocks): Một khối cấu trúc là một đồ thị con liên thông (sub connected graph) kết nối với phần còn lại của tiến trình nguồn (là một đồ thị) bởi đúng hai luồng tuần tự (sequence flows): một luồng vào và một luồng ra. Các khối cấu trúc có thể kết hợp với nhau để tạo thành khối cấu trúc lớn hơn. Khối cấu trúc lớn nhất được gọi là một phân cấp khối cấu trúc (block hierarchy) (xem Hình 3-1). Trong [49], một giải thuật tìm kiếm khối cấu trúc này với độ phức tạp tuyến tính đã được trình bày. Một khối cấu trúc có chứa một số cấu trúc được gọi là các mẫu (patterns), mà có thể được ánh xạ sang các thành phần của BPEL (xem Hình 3-2 minh họa một số ánh xạ thuộc loại này). Hình 3-1: Phân cấp khối cấu trúc của một tiến trình 80 Hình 3-2: Ánh xạ của một số mẫu Trong [79], các tác giả đã phân tích những bất đồng cơ bản mức khái niệm (basic conceptual mismatches) giữa BPMN và BPEL. Theo phân tích, các bất đồng này là nguồn gốc gây ra các vấn đề khi chuyển đổi giữa hai ngôn ngữ. Đây là điều mà các kỹ thuật chuyển đổi cần lưu ý giải quyết. Có ba loại bất đồng đã được phát hiện: - Bất đồng về khả năng biểu diễn lĩnh vực (Domain Representation Capability Mismatch); Bất đồng về khả năng hỗ trợ luồng điều khiển (Control Flow Support Mismatch); Bất đồng về cách thức biểu diễn tiến trình (Process Representation Paradigm Mismatch); Kỹ thuật ánh xạ được đề cập trong [74], ánh xạ các tiến trình được mô tả bằng Mô hình Tiến trình Tiêu chuẩn (Standard Process Models (SPM)) là các sơ đồ khái quát của các Ngôn ngữ Tiến trình Nghiệp vụ (Business Process Languages) như BPMN và UML (Unified Modeling Language). Mỗi SPM được xây dựng từ các phần tử (elements) và các luồng (transitions). Nó là một mô hình (model) có đúng một phần tử activity khởi tạo (initial activity) (là phần tử không có luồng vào) và đúng một phần tử activity kết thúc (final activity) (là phần tử không có luồng ra). Hướng tới sử dụng cấu trúc event handlers trong BPEL, kỹ thuật này có thể áp dụng cho bất kỳ loại SPM nào, chừng nào chúng không chứa các khóa sống (livelock). Để ánh xạ một tiến trình, kỹ thuật này bao gồm ba bước. Đầu tiên, các điều kiện tiên quyết (precondition sets) sẽ được tạo ra từ tất cả các phần tử activity của mô hình. Sau đó, các điều kiện này sẽ được chuyển thành tập các quy tắc Sự kiện-Điều kiện-Hành động (Event-Condition-Action (ECA) rules). Cuối cùng, các quy tắc này sẽ được dịch sang các cấu trúc event handler của BPEL. Mặc dù kỹ thuật này có ưu điểm là có thể được áp dụng cho nhiều loại sơ đồ BPMN, nhưng nó cũng tồn tại hai hạn chế cơ bản. Thứ nhất, do sử dụng cấu trúc event handler (là 81 cơ chế tổng quát để xử lý các sự kiện và thường không có cấu trúc), nên code BPEL được tạo ra thường cũng không có cấu trúc, nghĩa là nó thường dài dòng và không dễ đọc. Thứ hai, code BPEL được tạo ra thường chứa nhiều cấu trúc activity rỗng. Để giải quyết các vấn đề trên, một cải tiến nhằm cố gắng phát hiện các khối activity có cấu trúc đã được đưa ra trong [74]. Sau đó các khối có cấu trúc này (được gọi là Clusterable Activity Block (CAB)), có thể được ánh xạ sang các phần tử activity có cấu trúc trong BPEL (xem Hình 3-3 (dựa theo hình ảnh trong [74])). Tuy nhiên, phương pháp cụ thể làm thế nào để tìm được các khối có cấu trúc lại không được trình bày trong nghiên cứu. Hình 3-3: Một sơ đồ tiến trình nghiệp vụ với các khối cấu trúc CAB Chính do thiếu sót trên, một vấn đề đã nảy sinh của kỹ thuật này được phát hiện bởi Blox [18]. Đó là số lượng khối cấu trúc CAB được tìm thấy có thể không cố định. Điều này có nghĩa là từ một tiến trình đầu vào lại có thể nhiều tiến trình đầu ra khác nhau: nó lại dẫn đến một vấn đề khá rắc rối là phải chọn ra tiến trình nào trong số đó. Trong nghiên cứu [3], các tác giả tiếp tục phát triển khái niệm khối cấu trúc CAB, nhưng đổi tên nó thành component hay pattern. Nói chung, không phải tất cả các loại sơ đồ tiến trình trong BPMN đều có thể được dịch sang BPEL. Do đó, nghiên cứu này chỉ tập trung vào việc dịch một loại sơ đồ tiến trình với tên gọi sơ đồ tiến trình lõi chính tắc (wellformed core business process diagram (WFC-BPD)). Có ba loại mẫu (pattern) đã được xác định và mỗi loại có một kỹ thuật ánh xạ riêng. - Mẫu có cấu trúc đầy đủ (Well-structured patterns): là các mẫu mà có thể được ánh xạ đầy đủ sang một trong năm khối cấu trúc của BPEL (sequence, flow, pick, switch and while). Trong [3], có bảy mẫu của BPMN được xác định là có cấu trúc đầy đủ là: SEQUENCE, FLOW, PICK, SWITCH, REPEAT, WHILE, REPEAT+WHILE. Do ba mẫu lặp đều có thể được ánh xạ sang cấu trúc WHILE trong BPEL, nên ở đây chúng sẽ được gộp lại trong chỉ một mẫu WHILE. Do đó, ở 82 đây chỉ còn năm mẫu (xem các từ Hình 3-4 đến 3-8) có thể được ánh xạ đầy đủ sang các cấu trúc của BPEL. Hình 3-4: Mẫu Sequence Hình 3-5: Mẫu Flow Hình 3-6: Mẫu Switch 83 Hình 3-7: Mẫu Pick Hình 3-8: Mẫu While - - Mẫu có cấu trúc gần đủ (Quasi-structured patterns): là những mẫu mà có thể dễ dàng được chuyển đổi sang các mẫu có cấu trúc đầy đủ, để từ đó sẽ được ánh xạ sang các khối có cấu trúc trong BPEL. Mẫu bất chu trình dựa trên luồng (Flow based acyclic patterns): là loại mẫu tối thiểu không chứa chu trình và các gateway, trong đó thuộc một trong hai loại AND-fork hoặc AND-join. Các mẫu này có thể được ánh xạ sang các thành phần kết hợp của các khối có cấu trúc và các liên kết điều khiển (control links). Tư tưởng cơ bản của việc ánh xạ các mẫu loại này là việc rút gọn các cặp AND gateway nối với nhau. Có ba trường hợp kết nối được minh họa ở các Hình 3-9, 3-10 và 3-11. Hình 3-9: Rút gọn của hai “AND fork gateways” nối với nhau. 84 Hình 3-10: Rút gọn của hai “AND join gateways” nối với nhau Hình 3-11: Rút gọn của hai AND gateways khác nhau nối với nhau (AND fork nối với AND join). Một cách tiếp cận khác trong việc dịch ngôn ngữ là dựa trên kỹ thuật chuyển đồ thị phụ thuộc sang tiến trình có cấu trúc như đã được giới thiệu trong [31] và sau đó được áp dụng để dịch từ BPMN sang BPEL bởi Blox [18]. 3.2.2 Các hạn chế tồn tại Từ tổng quan về các kỹ thuật chuyển đổi từ ngôn ngữ hướng đồ thị sang ngôn ngữ có cấu trúc trình bày ở trên, có thể thấy rằng chúng vẫn còn tồn tại hai vấn đề sau: - Thứ nhất: làm thế nào để phát hiện được các loại mẫu khác nhau trong tiến trình biểu diễn bằng ngôn ngữ nguồn (là ngôn ngữ hướng đồ thị như BPMN). Hầu hết các kỹ thuật chuyển đổi chỉ tập trung vào việc làm thế nào để chuyển đổi các mẫu từ tiến trình nguồn sang tiến trình đích, nhưng lại không hề đề cập đến vấn đề làm thế nào để phát hiện và tách được các mẫu ra khỏi tiến trình nguồn, để từ đó mới có thể chuyển đổi mẫu đó sang tiến trình đích. Theo nghiên cứu của luận án, vấn đề này cũng không hề đơn giản, đòi hỏi phải có những kỹ thuật phù hợp. Trong phần sau, luận án sẽ đề xuất giải thuật nhằm giải quyết một phần vấn đề này, đó là làm thế nào để phát hiện và tách ra được các mẫu có cấu trúc đầy đủ (well-structured patterns) đã được trình bày ở phần trên. 85 - Thứ hai: Tính đúng đắn của đa số các kỹ thuật chuyển đổi đã được đề xuất vẫn chưa được chứng minh đầy đủ. Tính đúng đắn của một kỹ thuật dịch, ở đây với nghĩa là ngữ nghĩa của tiến trình biểu diễn bằng ngôn ngữ đích phải giống với ngữ nghĩa của tiến trình biểu diễn bằng ngôn ngữ nguồn. Điều đó có nghĩa là một kỹ thuật dịch đúng sẽ bảo toàn ngữ nghĩa của tiến trình nguồn. Thiếu các chứng minh về tính đúng đắn sẽ làm giảm mức độ tin cậy và khả năng áp dụng các kỹ thuật này, vì chúng ta vẫn chưa chắc chắn là chúng có đúng không. Giải quyết vấn đề này nằm ngoài khuôn khổ của luận án. Đây cũng là hướng nghiên cứu mới có triển vọng. 3.2.3 Giải thuật phát hiện mẫu có cấu trúc đầy đủ A. Một số khái niệm và tính chất cơ bản của đồ thị Định nghĩa 3-3: Một đồ thị G được gọi là đồ thị luồng điều khiển (control flow graph) nếu nó chứa hai nút phân biệt start và end sao cho mọi nút khác của G đều nằm trên một đường dẫn (path) nào đó từ nút start đến nút end. Nút start không có nút đứng trước (predecessors) và nút end không có nút đứng sau (successors). Tất cả các đồ thị mà chúng ta sẽ xét trong phần này đều là đồ thị luồng điều khiển, nên từ nay về sau tên này sẽ được gọi ngắn gọn là đồ thị. Định nghĩa 3-4: Cho một đồ thị G có chứa hai nút (hoặc hai cạnh) x và y. Ta nói rằng x chế ngự (dominate) y nếu mọi đường dẫn từ nút start đến y đều chứa x. Khi đó ta cũng nói x là phần tử chế ngự (dominator) của y. Ta nói rằng x chế ngự sau (post-dominate) y nếu mọi đường dẫn từ y đến nút end đều chứa x. Khi đó ta cũng nói x là phần tử chế ngự sau (post-dominator) của y. Ta nói rằng x là phần tử chế ngự liền kề (immediate dominator) của y nếu x chế ngự y và mọi phần tử chế ngự khác của y cũng sẽ chế ngự x. Ta nói rằng x là phần tử chế ngự sau liền kề (immediate post-dominator) của y nếu x chế ngự sau y và mọi phần tử chế ngự sau khác của y cũng sẽ chế ngự sau x. Theo quy ước, một nút không chế ngự chính nó, cũng không chế ngự sau chính nó. Định lý 3-1: [61] Ngoại trừ nút start, mỗi nút của đồ thị có đúng một nút chế ngự liền kề. Ngoại trừ nút end, mỗi nút của đồ thị có đúng một nút chế ngự sau liền kề. Định nghĩa 3-5: Hai cạnh (hay hai nút) u, v của đồ thị G được gọi là một cặp (couple), kí hiệu là couple(u, v), nếu u chế ngự v và v chế ngự sau u. Một couple(u, v) được gọi là một cặp liền kề (immediate couple) nếu u là phần tử chế ngự liền kề của v và v là phần tử chế ngự sau liền kề của u. Định lý 3-2: Hai cạnh u và v của một đồ thị G là một cặp couple(u, v) nếu và chỉ nếu tồn tại ít nhất một đường dẫn từ nút start đến nút end có chứa cả u và v, và mọi đường dẫn khác từ start đến end thì hoặc chứa cả u và v, hoặc không chứa cả u và v. 86 Chứng minh: Nếu (u, v) là một cặp, thì u là phần tử chế ngự của v, và v là phần tử chế ngự sau của u. Theo định nghĩa về chế ngự và chế ngự sau ở trên, mọi đường dẫn từ start đến v đều chứa u, mọi đường dẫn từ u đến end đều chứa v. Do đó, mọi đường dẫn từ start đến end mà chứa u thì cũng chứa v và ngược lại. Và hiển nhiên phải tồn tại ít nhất một đường dẫn như vậy. Còn với mọi đường dẫn khác mà không có u, thì nó cũng không có v, bởi vì nếu không thì nó phải có u. Định nghĩa 3-6: Hai cạnh (hoặc nút) u và v của đồ thị G tạo thành biên của một vùng (a boundary of a region) nếu chúng là một cặp liền kề. u và v lần lượt được gọi là điểm vào (entry point) và điểm ra (exit point) của vùng. Định nghĩa 3-7: Cho đồ thị G. Một cạnh (hay một nút) e của G được gọi là nằm trong biên của một vùng (u, v) (hay nói ngắn gọn là nằm trong vùng) nếu: - u là phần tử chế ngự của e và, v là phần tử chế ngự sau của e. Khi một cạnh nằm trong một vùng có nghĩa là cạnh đó nằm giữa điểm vào và điểm ra của vùng đó. Định nghĩa 3-8: Một tập các cạnh (hay các đỉnh) (e1, e2, ..., ek) của một đồ thị G tạo thành một vùng (region), ký hiệu reg(e1, e2, ..., ek), nếu (e1, ek) là biên của vùng và mọi cạnh (hay đỉnh) khác đều nằm trong biên của vùng. Trong các tiến trình BPMN, mỗi thành phần task hay event có đúng một cạnh vào (incoming edge) và một cạnh ra (outgoing edge). Do đó, mỗi cặp cạnh của một thành phần task hay event sẽ tạo thành một vùng và ta gọi nó là vùng tầm thường vì nó chỉ có biên mà không có cạnh nào khác nằm bên trong vùng. Định lý 3-3: Các mẫu trong số ba mẫu Flow, Pick và Switch đều tạo thành một vùng. Chứng minh: Ở đây chúng ta chỉ cần chứng mình cho mẫu Flow. Các chứng minh cho các mẫu khác hoàn toàn tương tự. Giả sử ta có mẫu Flow F(e1, e2, ..., ek) của đồ thị G. Theo định nghĩa của mẫu Flow, e1 là cạnh vào (incoming edge) duy nhất và ek là cạnh ra (outgoing edge) duy nhất của F. Hơn nữa, tồn tại ít nhất hai đường dẫn từ e1 đến ek, và mọi ei (2  i  k-1) đều chỉ nằm trên một trong số các đường dẫn. Do đó, e1 là phần tử chế ngự liền kề của ek, và ek là phần tử chế ngự sau liền kề của e1, và mọi cạnh khác đều nằm giữa e1 và ek. Điều này cũng có nghĩa F là một vùng. □ Định lý 3-4: Mẫu Sequence là một dãy các vùng. Điều này có nghĩa là một mẫu Sequence S(e1, e2, ..., ek) có thể được tách ra thành p vùng tuần tự (sequential regions): r1(e1, 87 e2, ..., ei1), r2(ei1, ..., ei2), ..., rp(ei(p-1), ..., ek), sao cho ∀ i=1..(p-1), cạnh ra của ri cũng là cạnh vào của ri+1. Chứng minh: Kết quả trên tương đối hiển nhiên, bởi vì mẫu Sequence bao gồm các task tuần tự (cũng là các vùng tầm thường) và các mẫu khác (chính là các vùng, theo Định lý 3-3). Định lý 3-5: [49] Nếu R1 và R2 là hai vùng của đồ thị G, chúng phải thỏa mãn một trong hai điều kiện sau: - Hai tập các nút trong R1 và R2 là không giao nhau, hoặc R1 nằm trong R2 (nghĩa là tất cả các cạnh của R1 đều nằm trong R2) hoặc ngược lại. Từ Định lý 3-5 có thể dễ dàng suy ra hai hệ quả sau: - Hệ quả 1: Tất cả các vùng của một đồ thị có thể được tổ chức thành một cây. Hệ quả 2: Vùng R1(e1, e2, ..., ek) nằm trong vùng R2 nếu e1 và ek nằm trong R2, hoặc R1 nằm trong vùng R3 khác, mà R3 lại nằm trong vùng R2. Định nghĩa 3-9: Một danh sách các vùng R1, R2,..., Rk được gọi là khả tuần tự (sequenceable) nếu chúng có thể được nhóm lại trong một mẫu Sequence. Điều này xảy ra khi các vùng trên thỏa mãn điều kiện: ∀ i=1..(k-1), cạnh ra (outgoing edge) của Ri cũng là cạnh vào (incoming edge) của Ri+1. Định lý 3-6: Mẫu While tạo thành một chu trình (circle). Chứng minh: Tính đúng đắn của định lý này khá hiển nhiên, như đã biểu thị trong Hình 3-8 biểu diễn mẫu này. Do mẫu While có thể được lồng trong một mẫu While khác, nên chu trình của mẫu này cũng có tính lồng nhau. Như chúng ta có thể thấy từ các hình từ 3-5 đến 3-8 về các mẫu, giữa vùng và chu trình có một sự tương đồng: chúng đều có một cạnh vào và một cạnh ra. Hơn nữa, một danh sách có cả vùng và chu trình cũng có thể khả tuần tự như Định nghĩa 3-9. Do đó từ bây giờ, chúng ta sẽ gọi một chu trình là vùng chu trình (circle region). Còn vùng thông thường sẽ được gọi là vùng bất chu trình (non-circle region) để phân biệt nó với vùng chu trình. Điều này cũng có nghĩa là từ nay, khi chúng ta đề cập đến vùng, có thể là vùng chu trình hoặc vùng bất chu trình. Định nghĩa 3-10: Cho đồ thị luồng G=(V, E), với V và E tương ứng là tập các đỉnh và tập các cạnh của G. Một đồ thị đảo của G (reversed graph) của G, ký hiệu G-=(V-, E-), là một đồ thị thỏa mãn các điều kiện: V-=V, và ∀ (x, y) ∈ E-, thì (y, x) ∈ E. Định lý 3-7: Cho đồ thị G và hai đỉnh x và y trong G. Nếu x là đỉnh chế ngự của y, thì x là đỉnh chế ngự sau của y trong đồ thị đảo G và ngược lại. 88 Chứng minh: Chúng ta sẽ chỉ ra rằng nếu x là đỉnh chế ngự của y trong G, thì x là đỉnh chế ngự sau của y trong đồ thị đảo G-. Chú ý rằng đỉnh start và đỉnh end trong G tương ứng trở thành các đỉnh end và start trong G-. Nếu x là nút chế ngự của y trong G, nó có nghĩa là x đứng trước y trên mọi đường dẫn từ nút start đến y. Nó cũng có nghĩa là x đứng sau y trên mọi đường dẫn từ y đến nút end trong G-. Do đó, x là nút chế ngự sau của y trong G-. Chứng minh tương tự cho chiều ngược lại. Hệ quả trực tiếp của Định lý 3-7 là lời giải cho vấn đề tìm kiếm phần tử chế ngự sau có thể dễ dàng được suy ra từ lời giải cho vấn đề tìm kiếm phần tử chế ngự. Định nghĩa 3-11: Nút bán chế ngự (Semidominator) [57]: cho trước một nút w  start trong một đồ thị G. Một nút bán chế ngự (semidominator) của w, ký hiệu sdom(w), là một nút trong G được định nghĩa như sau: sdom(w)=min{v | ∃ một đường dẫn v=v0,v1,...,vk=w sao cho v < w và vi > w với 1  i  k-1}; B. Giải thuật phát hiện các mẫu có cấu trúc đầy đủ Từ các kết quả của hai Định lý 3-3 và 3-4, vấn đề phát hiện ba mẫu có cấu trúc đầy đủ là Flow, Pick và Switch có thể được suy ra từ vấn đề tìm kiếm các vùng, là một vấn đề đã được nghiên cứu khá đầy đủ trước đây với nhiều giải thuật [57] [5] [49] [91]. Trong số các giải thuật này, luận án lựa chọn giải thuật trong [57] cho nghiên cứu này, bởi sự đơn giản và hiệu quả của nó so với các giải thuật khác. Sau khi phát hiện được các vùng, chúng ta còn cần phải xác định kiểu mẫu của vùng (một trong số ba mẫu có cấu trúc đầy đủ đã đề cập trước đây). Từ kết quả của Định lý 3-6, vấn đề tìm kiếm mẫu While có thể được suy ra từ vấn đề tìm kiếm các chu trình, một vấn đề đã được nghiên cứu và giải quyết trước đây với một số giải thuật như trong [90] [48]. Ý tưởng chính của các giải thuật này sẽ được luận án trình bày kỹ hơn ở phần sau. Mẫu Sequence sẽ được xây dựng từ các vùng và chu trình đã được phát hiện. Còn vấn đề xác định kiểu mẫu của vùng lại khá dễ giải quyết, bởi vì mỗi mẫu lại có những đặc trưng riêng dễ phân biệt như sau: - - Mẫu Flow: Cạnh vào của mẫu này phải là cạnh vào một fork parallel gateway (là cấu trúc với một cạnh vào và hai hoặc nhiều hơn cạnh ra) và cạnh ra của nó phải là cạnh ra của một join parallel gateway (là cấu trúc với hai hay nhiều hơn cạnh vào và một cạnh ra). Mẫu Pick: Cạnh vào của mẫu này phải là cạnh vào của một fork exclusive gateway, và cạnh ra của nó phải là cạnh ra của một join exclusive gateway. Mẫu Switch: Tương tự như mẫu Pick, cạnh ra của mẫu này phải là cạnh ra của một join exclusive gateway, nhưng cạnh vào của nó lại là cạnh vào của một fork eventbased gateway. 89 Mẫu While: Cạnh vào của mẫu này phải là một cạnh vào trong số hai cạnh vào của một join exclusive gateway và cạnh ra của nó phải là một cạnh ra trong số hai cạnh ra của một fork exclusive gateway (cạnh ra kia sẽ quay lại join exclusive gateway để thành vòng lặp). - B.1 Giải thuật tìm kiếm các vùng Như đã nói ở trên, giải thuật mà được chọn để tìm kiếm các vùng là của Lengauer và Tarjan [57]. Ý tưởng cơ bản của giải thuật là đưa bài toán tìm nút chế ngự liền kề của một nút cho trước về bài toán tìm nút bán chế ngự của nút đó (xem lại Định nghĩa 3-11 về nút bán chế ngự). Theo phân tích trong [57], giải thuật này có độ phức tạp là O(m.logn) (với m và n tương ứng là số cạnh và số đỉnh của đồ thị), tốt hơn nhiều so với một giải thuật khác được đề xuất trong [77] với độ phức tạp là O(m.n). Giải thuật 3-1: [57] Giải thuật này gồm có ba bước chính: 1. Tiến hành tìm kiếm theo chiều sâu (depth first search) bắt đầu từ nút start của đồ thị. Trong quá trình tìm kiếm, đánh số các nút lần lượt theo thứ tự được thăm. 2. Tìm các nút bán chế ngự của tất cả các nút của đồ thị. 3. Tìm nút chế ngự liền kề cho từng nút của đồ thị. Như chúng ta đã biết, một phép tìm kiếm theo chiều sâu của đồ thị bắt đầu từ một nút r sẽ tạo ra một cây khung (spanning tree) có gốc tại r và chứa tất cả các đỉnh của đồ thị với số thứ tự được thăm theo thứ tự trước. Do đó, sau phép tìm kiếm, khi chúng ta so sánh hai nút của đồ thị, giả sử như u v1). Để lưu trữ các đường dẫn đã thăm, giải thuật này sử dụng hai ngăn xếp (stacks): point stack để lưu đường dẫn đang thăm, mark stack để chứa các đỉnh đã thăm. Để tránh việc thăm lại các đường dẫn đã được thăm rồi, hai ngăn xếp này sẽ được làm rỗng trước mỗi phép thăm. Tuy nhiên, giải pháp này lại có thể dẫn đến nhiều phép duyệt đường dẫn không cần thiết ở các phép duyệt kế tiếp, bởi vì có nhiều phần trong các đường dẫn sẽ được tìm lại đã được thăm ở các phép tìm trước đó. Một nguồn nữa cho các phép duyệt không cần thiết là việc chọn nhầm đỉnh bắt đầu tìm kiếm – là đỉnh mà không nằm trong bắt kỳ chu trình nào. Giải thuật này chọn đỉnh bắt đầu hoàn toàn ngẫu nhiên, nên khả năng chọn nhầm không hề nhỏ. Chính vì những hạn chế trên mà độ phức tạp của giải thuật này trong trường hợp xấu nhất, được tính toán bởi Johnson [48], là O(n.e.(c+1)), với n là số đỉnh, e là số cạnh và c là số chu trình. Dựa trên giải thuật của Tarjan, giải thuật của Johnson [48] có một cải tiến quan trọng nhằm tránh việc chọn nhầm đỉnh bắt đầu. Trong giải thuật này, đỉnh bắt đầu được chọn là đỉnh nhỏ nhất trong một thành phần liên thông mạnh (strongly connected component)- là thành phần luôn có ít nhất một chu trình. Nhờ cải tiến này mà độ phức tạp của giải thuật chỉ còn O((n+e).(c+1)), tốt hơn khá nhiều so với giải thuật của Tarjan. 3.2.4 Giải thuật xây dựng các mẫu có cấu trúc đầy đủ Như chúng ta thấy, giải thuật phát hiện các mẫu chỉ tìm kiếm biên của mẫu (cụ thể hơn là chỉ tìm hai đỉnh của biên). Nhưng để ánh xạ được mẫu, ta cần phải có đầy đủ thông tin về tất cả các thành phần trong mẫu: cả biên và cả các thành phần ở trong biên. Do đó, sau khi áp dụng Giải thuật 3-1 để tìm tất cả các biên của các mẫu, giải thuật của luận án sẽ tìm các thành phần và bổ sung chúng vào trong vùng thích hợp. Kết quả cuối cùng của giải thuật sẽ là một vùng mà có thể chứa tất cả các vùng khác. Giải thuật 3-2: Đầu vào: tập hợp L gồm tất cả các đỉnh của đồ thị luồng G. Đồ thị này biểu diễn một tiến trình BPMN, là kết quả trả về từ giải thuật 3-1. Giả sử rằng mỗi đỉnh v của đồ thị có ba hàm: 91 - number(): trả về số thứ tự của v, là số thứ tự của nút trong phép tìm kiếm theo chiều sâu của đồ thị. idom() và ipdom(): tương ứng trả về đỉnh chế ngự liền kề và đỉnh chế ngự sau liền kề v. Đầu ra: một vùng R biểu diễn mẫu tổng thể (overall pattern) của tiến trình BPMN. Vùng này có thể chứa các vùng con khác, biểu diễn cho các mẫu nhỏ hơn. Xử lý: giải thuật gồm các bước sau: 1. Xác định các vùng trong tập L (sử dụng giải thuật của Lengauer và Tarjan [57] để tìm các vùng bất chu trình và dùng giải thuật của Johnson để tìm các vùng chu trình [48] như đã được đề cập trong phần 3.3.2). Ở giai đoạn này, mỗi vùng mới chỉ chứa hai đỉnh: một vào và một ra. 2. Thay thế tất cả các đỉnh mà biểu diễn cho các thành phần tasks và events (ngoại trừ start events và end events) bằng các vùng tầm thường (trivial regions). Sau bước này, ngoại trừ hai đỉnh start và end, trong L chỉ còn chứa các vùng, mà không còn đỉnh nào nữa. 3. Xây dựng các vùng Sequence biểu diễn cho các mẫu Sequence: chừng nào trong L còn tồn tại danh sách vùng R1, R2,…, Rk khả tuần tự (sequenceable) (xem Định nghĩa 3-9), tiến hành thay thế danh sách trên bằng vùng Sequence Rseq(R1, R2,…, Rk). 4. Xây dựng các vùng không phải kiểu Sequence (như Switch, While, Pick, Flow): chừng nào trong L còn tồn tại hai vùng R1 và R2 sao cho R1 nằm trong R2, thì bổ sung R1 vào trong R2, rồi loại bỏ R1 khỏi L. 5. Lặp lại các bước 3 và 4 cho đến khi L chỉ còn chứa một vùng R. Trả về R và giải thuật kết thúc. Ví dụ 3-1: Ví dụ này nhằm minh họa hoạt động của Giải thuật 3-2. Tiến trình BPMN được minh họa trong Hình 3-12. Các kết quả cho từng bước thực thi của giải thuật được minh họa trong các hình kế tiếp (xem các hình từ Hình 3-13 đến Hình 316). Hình 3-12 : Tiến trình BPMN. 92 Hình 3-13: Đồ thị biểu diễn tiến trình BPMN và kết quả của phép duyệt theo chiều sâu (DFS). Ở bước 1, DFS được sử dụng để phát hiện các vùng chu trình và vùng bất chu trình. Hình 3-14: Các vùng đã phát hiện được sau bước 1. Ở đây phát hiện được ba vùng: R2 là vùng chu trình, còn R1 và R3 là hai vùng bất chu trình. 93 Hình 3-15: Các vùng đã phát hiện được sau bước 2 (một số nhãn cho các nút từ các hình trước đã cố tình được bỏ bớt từ hình này trở đi nhằm làm cho các hình vẽ đỡ rắc rối hơn) Hình 3-16: Vùng cuối cùng được trả về R sau các bước cuối 3, 4 và 5 Định lý 3-8: Giải thuật 3-2 là đúng đắn và đầy đủ. Chứng minh: Ta cần chứng minh tính đúng đắn và chứng minh tính đầy đủ. Tính đúng đắn: Chúng ta sẽ chỉ ra rằng giải thuật trên sẽ phát hiện đúng bất kỳ mẫu có cấu trúc đầy đủ nào và nó trả về đúng vùng cần phát hiện. Để tìm kiếm các vùng (cả chu trình và bất chu trình), giải thuật dựa trên hai giải thuật nổi tiếng, nên tính đúng đắn của chúng được xem là hệ quả trực tiếp. Từ mô tả giải thuật, chúng ta có thể thấy rằng sau bước 2 và trước bước 3, ngoại trừ hai nút start và end, thì tất cả các nút còn lại đều nằm trong các vùng (bao gồm vùng chu trình, 94 bất chu trình và vùng tầm thường). Hơn nữa, mỗi nút chỉ nằm trong đúng một vùng. Theo Định lý 3-5, với mọi cặp vùng R1 và R2, một trong hai trường hợp sau có thể xảy ra: 1. Nếu R1 nằm trong R2 hoặc ngược lại: thì bước 4 sẽ được áp dụng, và một trong hai vùng sẽ được di chuyển vào trong vùng kia. 2. Nếu R1 và R2 không có nút chung: thì một trong ba tình huống sau có thể xảy ra: a. Nếu R1 và R2 nằm trong danh sách các nút khả tuần tự thì bước 3 sẽ được áp dụng. b. Nếu R1 và R2 cùng nằm trong một vùng khác: thì bước 4 sẽ được áp dụng. c. Nếu R1 và R2 thuộc hai vùng khác nhau: thì bước 4 sẽ được áp dụng. Do đó, sau bước 2, hoặc bước 3 hoặc bước 4 sẽ được thay nhau áp dụng lặp lại nhiều lần. Do số lượng vùng sau bước 2 là cố định và sau bước 3 hoặc bước 4, số vùng luôn giảm, nên giải thuật phải kết thúc và trả về một vùng cuối cùng. Tính đúng đắn của giải thuật đã được chứng minh. Tính đầy đủ (Completeness): Chúng ta sẽ chỉ ra rằng giải thuật có thể xác định được toàn bộ các mẫu có cấu trúc đầy đủ trong tiến trình BPMN. Như đã được chỉ ra trong phần chứng minh tính đúng đắn của giải thuật, ngoại trừ hai nút start và end, sau bước 2 không có nút nào khác nằm ngoài các vùng. Do đó, hiển nhiên là không thể có mẫu nào bị bỏ sót sau quá trình thực hiện giải thuật. Tính đầy đủ của giải thuật đã được chứng minh. Định lý 3-9: Độ phức tạp của Giải thuật 3-2 áp dụng cho một đồ thị G (với số lượng các đỉnh, các cạnh và các vùng lần lượt là n, e và r) là O((n + e).(rc + 1) + e.logn + 2r2); trong đó rc là số lượng các vùng chu trình (circle regions). Chứng minh: Gọi C là độ phức tạp của giải thuật, và Ci là độ phức tạp của giải thuật tính được sau bước thứ i. Điều này có nghĩa là C=C5. Do có hai loại vùng là vùng chu trình và vùng bất chu trình, nên nếu giả sử chúng ta gọi số lượng các vùng chu trình và bất chu trình tương ứng là rc và rn, thì ta sẽ có r=rc + rn. Sau bước 1, ta có độ phức tạp của giải thuật (sử dụng các công thức tính độ phức tạp trong [57] [48]): C1 = O((n + e).(rc + 1)) + O(e.logn); Độ phức tạp của giải thuật ở bước 2 là: O(nt + ne); trong đó nt và ne tương ứng là số lượng các task và event. Do đó sau bước 2 ta có: C2 = C1 + O(nt + ne); Do (nt + ne) < n, nên ta suy ra: C2 = C1. Để xây dựng các vùng Sequence trong bước 3, ta nên sắp xếp các vùng tìm thấy trong các bước trước. Độ phức tạp của thao tác sắp xếp này là O(r2), với r là số lượng vùng. Do đó, sau bước 3 ta có: 95 C3 = C2 + O(r2) = O((n + e).(rc + 1) + e.logn + r2); Độ phức tạp của bước 4 cũng tương tự như của bước 3, bởi vì việc kiểm tra quan hệ bao hàm cũng tương tự như kiểm tra thứ tự tuần tự. Do đó sau bước 4 ta có: C4 = C3 + O(r2) = O((n + e).(rc + 1) + e.logn + 2r2); Cuối cùng, ta có: C5 = C4 = O((n + e).(rc + 1) + e.logn + 2r2) □ 3.2.5 Các nghiên cứu liên quan Trong [3], các tác giả trình bày và cài đặt một công cụ dịch từ BPMN sang BPEL, được gọi là BPMN2BPEL. Tuy nhiên, như đã nói ở trên, chi tiết kỹ thuật của việc cài đặt không được đề cập. Do đó, nghiên cứu của luận án sẽ giúp làm rõ hơn kỹ thuật cài đặt này. Trong [28], việc dịch từ BPMN sang BPEL lại áp dụng một cách tiếp cận khác so với đa số cách tiếp cận trước đó, sử dụng một ngôn ngữ chuyển đổi khái quát và khai báo, được gọi là AtlanMod Transformation Language (ATL). Ngôn ngữ này được dùng để chuyển đổi từ mô hình nguồn sang mô hình đích bằng cách định nghĩa các quy tắc chuyển đổi (transformation rules). Tuy nhiên, khả năng mô hình hóa các mẫu và định nghĩa các quy tắc chuyển đổi vẫn chưa được đề cập đến. Hơn nữa, phần chuyển từ ngữ nghĩa dịch sang các quy tắc chuyển đổi cũng không rõ ràng, nên không dễ áp dụng trong thực tế. 96 KẾT LUẬN CHƯƠNG Chương này giới thiệu tóm tắt và khái quát các kỹ thuật hiện nay dùng để làm mịn kế hoạch, với hai phương pháp: chi tiết hóa và chuyển đổi ngôn ngữ biểu diễn hoạt động. Cả hai phương pháp đều giúp làm tăng cường tính khả thi của kế hoạch, nhưng lại đi theo các cách tiếp cận khác nhau. Trong khi chi tiết hóa giúp xác định thêm các hoạt động mới nhằm làm rõ hơn các phần còn trừu tượng trong các hoạt động cũ, chuyển đổi ngôn ngữ biểu diễn hoạt động không bổ sung thêm hoạt động mới, thay đổi cách biểu diễn hoạt động, từ ngôn ngữ trừu tượng chưa thực thi được (BPMN), sang ngôn ngữ thực thi được (BPEL). Kế thừa các kỹ thuật chuyển đổi ngôn ngữ luồng liên quan đến các kỹ thuật dịch ngôn ngữ hướng đồ thị (như BPMN) sang ngôn ngữ có cấu trúc (hay hướng khối cấu trúc, như BPEL) trước đây, luận án bổ sung thêm một giải thuật nhằm khắc phục một số vấn đề còn tồn tại trong việc phát hiện và xây dựng các mẫu có cấu trúc đầy đủ. Các biện pháp được trình bày trong chương này giúp hoàn thiện hơn các yêu cầu của khung lưới cộng tác đa dụng, giúp chuẩn bị sẵn sàng cho các bước thiết kế và cài đặt sẽ được trình bày trong Chương 4. 97 CHƯƠNG 4: THIẾT KẾ VÀ CÀI ĐẶT KHUNG LƯỚI CỘNG TÁC ĐA DỤNG Chương này sẽ trình bày phần thiết kế và cài đặt của khung cộng tác đa dụng với các yêu cầu như đã được trình bày trong phần 2.2. Kết quả phần thiết kế của luận án đã được công bố trong [12][10]. Ở phần cài đặt, do khối lượng cần cài đặt của khung cộng tác đa dụng này là khá lớn, nên luận án mới tập trung vào cài đặt một số thành phần chính như sau: - - - Giải pháp gọi Dịch vụ lưới từ tiến trình BPEL, với kết quả đã được công bố trong [13][9]. Tuy nhiên, giải pháp còn hạn chế là mới chỉ gọi được các dịch vụ lưới không an toàn, chứ chưa gọi được các dịch vụ lưới an toàn. Hạn chế này được khắc phục trong một giải pháp được nói đến ngay sau đây. Giải pháp mở rộng mô hình điều khiển truy nhập cho các hệ thống luồng công việc trong môi trường lưới. Giải pháp sẽ giúp hoàn thiện hơn giải pháp gọi dịch vụ lưới ở trên, và cho phép gọi các dịch vụ lưới an toàn. Giải pháp tự động hóa khai thác tiến trình BPEL. Giải pháp này đã được công bố trong [11]. Trong chương này, để ngắn gọn, khung lưới cộng tác đa dụng sẽ được gọi là khung. 4.1 Các yêu cầu của khung Mục tiêu chính của kiến trúc này được dùng như một khung lưới có hỗ trợ kế hoạch cho một phạm vi rộng các ứng dụng cộng tác. Theo Mô hình Kế hoạch, mỗi kế hoạch bao gồm các hoạt động được xác định thông qua quá trình làm mịn kế hoạch (đã được trình bày trong Chương 3). Trong quá trình này, nhiều người sử dụng có thể phối hợp với nhau để cập nhật kế hoạch thông qua các biện pháp làm mịn kế hoạch như chi tiết hóa và chuyển đổi cách biểu diễn hoạt động. Khi các hoạt động trong kế hoạch đủ mịn, người dùng cũng có thể cho phép chạy và giám sát tình trạng của các hoạt động nhằm kiểm chứng tính khả thi của chúng. Các yêu cầu của khung đã được xác định sơ bộ ở phần 2.2.1, bao gồm: - Định nghĩa các hoạt động: cho phép sử dụng một ngôn ngữ luồng công việc (như BPMN hoặc BPEL) để định nghĩa các hoạt động. Quản lý kế hoạch: do mỗi kế hoạch được biểu diễn dưới dạng một đồ thị VÀ/HOẶC, nên có thể sử dụng một trong các cách cài đặt đồ thị trong Lý thuyết đồ thị để cài đặt cho cho kế hoạch. Trong cài đặt đó, cần có các thao tác cho phép cập nhật kế hoạch, như thêm/bớt hoạt động, thêm/bớt các phụ thuộc khả thi (chi tiết hóa kế hoạch); các phép tìm kiếm hoạt động và phụ thuộc khả thi; chuyển đổi các hoạt động của kế hoạch từ BPMN sang BPEL để chuẩn bị cho quá trình thực thi chúng trong môi trường tính toán thích hợp (môi trường lưới là một trong số được chọn). 98 Thực thi các hoạt động của kế hoạch: người dùng sẽ chọn các engine thực thi hay hạ tầng tính toán nào đó để thực thi các hoạt động trong kế hoạch. Việc thực thi sẽ giúp kiểm chứng tính khả thi của các hoạt động, từ đó suy ra tính khả thi của kế hoạch. - Tổng quan về các yêu cầu trên của khung đã được minh họa ở Hình 2-23. Để đáp ứng được các yêu cầu quản lý kế hoạch và thực thi các hoạt động ở trên, khung cần có thêm một số yêu cầu khác như sau: ˗ ˗ Cộng tác phân tán về mặt địa lý: Khung hỗ trợ việc cộng tác phân tán về mặt địa lý, cho phép các thành viên tham gia (hoặc nhóm thành viên) ở các vị trí địa lý khác nhau có thể cộng tác với nhau. Sự không đồng nhất của các hệ thống thực thi bên dưới: Khung hỗ trợ các công cụ và các hệ thống thực thi khác nhau bởi các thành viên tham gia tại các vị trí khác nhau. Trong luận án, hai hệ thống tính toán: môi trường tính toán lưới và môi trường Web được dùng để xây dựng khung. Hai yêu cầu mới này có thể đạt được bằng việc sử dụng cơ sở hạ tầng lưới hiện nay. Do đó, nhờ khả năng hỗ trợ lập kế hoạch và khả năng cộng tác phân tán trong môi trường lưới, khung được xây dựng trở thành một khung lưới cộng tác đa dụng. 4.2 Thiết kế khung 4.2.1 Kiến trúc khung Kiến trúc của khung sẽ bao gồm hai tầng (xem Hình 4-1): 1. Tầng Hoạt động Tập thể (Collective Activity Layer): tầng này cho phép nhiều người dùng hợp tác để xây dựng một kế hoạch làm việc, soạn thảo kịch bản công việc, sau đó chạy và giám sát công việc đã được soạn thảo đó. Các thành phần chính của tầng này gồm có : Hình 4-1: Kiến trúc khung lưới cộng tác. 99 Quản Lý VO và nhóm (VO and Group Management): có trách nhiệm cập nhật các tổ chức ảo (VO), các nhóm trong VO, người dùng trong các nhóm, quản lý quyền truy nhập và vai trò của người dùng trong các VO. Lập kế hoạch hoạt động (Activity Planning): chịu trách nhiệm tạo mới các kế hoạch làm việc hay cập nhật các kế hoạch đang triển khai Phân công hành động (Activity Planning): chịu trách nhiệm phân công các hành động cụ thể trong kế hoạch làm việc cho từng người dùng Lựa chọn tài nguyên và công cụ (Selecting Resources and Artifacts): cho phép người dùng tìm và lựa chọn các tài nguyên phù hợp cho các hành động trong kế hoạch làm việc, cũng như các công cụ cộng tác cần thiết cho việc cộng tác của các hành động. Kết quả cuối cùng của việc chọn lựa này sẽ là một kịch bản công việc. Kho chứa các công cụ cộng tác (Collaborative Artifact Store): lưu trữ toàn bộ các công cụ cộng tác. Cho chạy và giám sát (Running and Monitoring): có nhiệm vụ khởi động, cho chạy, giám sát và cho kết thúc các hoạt động. Thư mục tài nguyên (Resource Directory): chứa toàn bộ các tài nguyên cần thiết cho việc chạy các thao tác của công việc. 2. Tầng Điều Phối Tài nguyên (Resource Coordination Layer): nhiệm vụ chính của tầng này là quản lý các tài nguyên phân tán và làm cho chúng luôn trong trạng thái sẵn sàng sử dụng cho tầng ở trên. Hạ tầng lưới hiện tại (hệ thống Globus Toolkit 4) sẽ được sử dụng cho tầng này. Ở đây, đưa ra một ví dụ đơn giản trong lĩnh vực ra quyết định y tế cộng tác, nhằm minh họa ý tưởng về việc sử dụng khung cho việc trợ giúp sự cộng tác trong hoạt động này. Ví dụ 4-1: Khi khối lượng tri thức điều trị y tế không ngừng tăng lên, làm cho các nhân viên y tế ngày càng khó để trở thành chuyên gia trong vài lĩnh lực chuyên môn. Sự thật này đã làm cho việc tư vấn trở thành một thành phần thiết yếu của các tiến trình chẩn trị cộng tác hiện đại. Một kịch bản đơn giản có thể như sau: Một bác sĩ và hai chuyên gia chia sẻ kiến thức nhằm đi đến một sự nhất trí liên quan đến một ca chẩn đoán, đòi hỏi có các kiểm tra chẩn đoán và các thủ tục can thiệp. Quá trình suy luận và ra quyết định có thể gồm các bước sau: - - - Bước 1: Bác sĩ và các chuyên gia cộng tác với nhau để đưa ra một kế hoạch chẩn đoán, mà bao gồm các giai đoạn, các đặc điểm ra quyết định, các kiểm tra y tế, các hỗ trợ y tế, các dữ liệu dựa trên tri thức và sự trao đổi của họ. Bước 2: Một khi kế hoạch đã được sắp đặt, mỗi thành viên trong nhóm sẽ chịu trách nhiệm một phần nào đó trong kế hoạch và trao đổi với nhau theo đặc tả đã đề ra. Bước 3: Mỗi thành viên lựa chọn các công cụ cộng tác cần thiết nhằm trợ giúp quá trình chẩn đoán của họ. Bước này sẽ tạo ra một kịch bản mô tả đầy đủ chi tiết liên 100 quan đến những người thực hiện và các hành động phải làm để thu được kết quả đã được mô tả ở trong kế hoạch. - Bước 4: Các hành động được thực thi theo kịch bản. Trong giai đoạn này, các thành viên tham gia cộng tác có thể luôn luôn giám sát tiến độ của toàn bộ tiến trình và nếu cần thì cập nhật lại kế hoạch. Cũng cần lưu ý, quá trình suy luận và ra quyết định trong thực tế thường phức tạp hơn mô tả ở trên rất nhiều, như đã được trình bày trong [86]. 4.2.2 Thiết kế modul Kiến trúc của khung cộng tác ở trên được chia thành một số modul như sau (xem Hình 4-2): 1. 2. 3. VO and Group Management Modul (VGMM): Như đã nói ở trên, modul này sẽ chịu trách nhiệm cập nhật các tổ chức ảo, cũng như các nhóm người dùng trong đó. Activity Planning Modul (APM): Modul này cho trách nhiệm xây dựng và cập nhật các kế hoạch hoạt động. Để cho kế hoạch vừa có thể được biểu diễn dễ dàng, vừa có thể thực thi được, cách tiếp cận ngôn ngữ luồng công việc (hay nói ngắn gọn là ngôn ngữ luồng) đã được lựa chọn. Đồng thời, qua khảo sát các ngôn ngữ luồng hiện nay, BPMN (Business Process Model & Notation) [70] là phù hợp nhất đối với khung cộng tác này vì một số lý do:  Thứ nhất, vì đây là ngôn ngữ luồng được phát triển nhằm thống nhất các ngôn ngữ luồng khá đa dạng hiện nay. Hơn nữa, đây là ngôn ngữ hướng vào việc mô tả các chu trình nghiệp vụ của người dùng ở mức cao (mức làm gì và chu trình thực hiện gồm các bước gì), chứ không mô tả ở mức thấp, thực hiện chu trình đó như thế nào. Chính vì vậy, rất thích hợp để mô tả các kế hoạch công việc của một nhóm người.  Thứ hai, việc chuyển từ BPMN sang ngôn ngữ luồng để thực thi BPEL (Business Process Execution Language), là ngôn ngữ được chọn để cài đặt Activity Execution Modul, cũng đang thu hút được khá nhiều nghiên cứu và đã đạt được khá nhiều kết quả khả quan [73] [18] [3] [79]. Activity Execution Modul (AEM): Modul này sẽ chịu trách nhiệm thực thi luồng công việc ở modul APM trên. Để triển khai modul này, tương tự như với modul APM, cách tiếp cận sử dụng ngôn ngữ luồng đã được sử dụng. Trong số các ngôn ngữ luồng hiện nay, BPEL (Business Process Execution Language) [68] [33] đã được chọn làm ngôn ngữ mô tả cho modul này vì một số lý do sau:  Thứ nhất: BPEL là ngôn ngữ luồng vừa có khả năng mô tả các tiến trình nghiệp vụ mức cao, vừa có thể thực thi luồng công việc nhờ các BPEL engine đã được phát triển khá phổ biến hiện nay như ActiveBPEL, ODE, v.v.  Thứ hai: BPEL là ngôn ngữ luồng hướng dịch vụ, bằng cách chuẩn hóa việc thực thi các luồng công việc thông qua việc gọi các dịch vụ Web. Điều này rất có ý nghĩa trong việc triển khai và mở rộng ngôn ngữ luồng trong môi trường lưới, vì đây là môi trường đang được phát triển và chuẩn hóa theo 101 4. hướng dịch vụ. Tuy nhiên, BPEL có hạn chế là khả năng chỉ mới hỗ trợ việc gọi các dịch vụ Web, chứ chưa gọi được dịch vụ lưới. Khắc phục hạn chế này cũng là một trong những nội dung nghiên cứu của luận án. Hạ tầng lưới: Hạ tầng sẽ chứa kho tài nguyên và quản lý một cách có hiệu quả các tài nguyên của lưới để phục vụ cho các chức năng của các modul khác. Ngoài ra, hạ tầng này cũng sẽ giúp thực thi và giám sát các công việc trong các kế hoạch đã đề ra trong các modul APM và AEM ở trên. Bảng 4-1 mô tả việc ánh xạ các khối chức năng của khung cộng tác vào các modul hệ thống trình bày ở trên. Từ các modul trên, chúng có thể được lắp ghép như trong Hình 4-2. Theo cấu trúc này, trình tự các thao tác của người sử dụng có thể được khái quát gồm các bước sau: Bảng 4-1: Ánh xạ các khối chức năng vào các modul hệ thống. Khối chức năng Modul Quản Lý VO và nhóm. VO and Group Management Modul (VGMM). Lập kế hoạch hoạt động. Activity Planning Modul (APM): Sử dụng BPMN làm ngôn ngữ mô tả kế hoạch. Phân công hành động. Activity Planning Modul (APM) và Activity Execution Modul (AEM): Sử dụng công cụ để dịch từ BPMN sang BPEL. Lựa chọn tài nguyên và công cụ. Activity Execution Modul (AEM): Sử dụng BPEL làm ngôn ngữ mô tả việc thực thi kế hoạch ở trên. Kho chứa các công cụ cộng tác. Tích hợp trong APM và AEM. Cho chạy và giám sát. Workflow engine tích hợp trong AEM & Hạ tầng lưới. Thư mục tài nguyên. Hạ tầng lưới. 102 Hình 4-2: Cấu trúc các modul của khung. 1. 2. 3. 4. 5. Bước 1: Người dùng đăng nhập (login) vào hệ thống. Ngoài tài khoản để đăng nhập như các hệ thống thông thường, đối với hệ thống lưới, người dùng phải có trước các bản chứng thực (certificate) hợp lệ, được cấp bởi một trong các tổ chức chứng thực có đủ tin cậy (Authorization Organization). Sau khi đăng nhập, người dùng có thể đăng ký vào trong các tổ chức ảo để bắt đầu các phiên làm việc. Bước 2: Người dùng sử dụng các công cụ soạn thảo kế hoạch (ở đây là các BPMN editor) để cập nhật các bản kế hoạch về một công việc nào đó. Việc soạn thảo này có thể được thực hiện phối hợp với nhau – nhóm người dùng vừa cùng trao đổi và cùng cập nhật bản kế hoạch để đưa ra được bản thảo tốt nhất tại thời điểm đó. Sau đó, nó vẫn có thể được điều chỉnh cho phù hợp hơn với tình hình mới. Bước 3: Bản kế hoạch đã được thống nhất ở trên sẽ được dịch sang một bản thảo ở dạng mới (là BPEL trong hệ thống này) để phù hợp hơn với việc thực thi và giám sát việc thi hành này trên môi trường lưới. Bước 4: Để chuẩn bị cho việc thực thi bản kế hoạch đã được dịch, cần phải tìm và định vị các tài nguyên (phần cứng, phần mềm) cần thiết. Bước 5: Người sử dụng sẽ cho thực thi và trong quá trình đó giám sát các kết quả thực hiện, so sánh với kế hoạch đã đề ra ban đầu, từ đó có thể phát hiện kịp thời các vấn đề nảy sinh và có những điều chỉnh cần thiết. 103 4.2.3 Kết luận phần thiết kế Trong phần thiết kế cho khung cộng tác, luận án đã đưa ra thiết kế ở cả hai mức sơ bộ và chi tiết. Khung cho phép tạo mới hoặc cập nhật các kế hoạch có tính cộng tác, các mục tiêu có thể được chia sẻ và cùng được tối ưu, và các hành động sẽ được phân bổ và được thực thi một cách tối ưu bởi các thành viên tham gia. Mục tiêu nhằm cung cấp một khung lưới đa dụng hỗ trợ cho những công việc cộng tác trong nhiều lĩnh vực ứng dụng khác nhau. Luận án đã cài đặt môi trường lưới sử dụng Globus Tookit 4 [36] cho tầng điều phối tài nguyên của khung. Các cài đặt khác cho khung cộng tác sẽ được trình bày chi tiết hơn trong phần sau. 4.3 Cài đặt khung Phần này sẽ trình bày các kết quả cài đặt bước đầu cho khung lưới cộng tác đa dụng, gồm các cài đặt chính như sau: - - - Giải pháp gọi Dịch vụ lưới từ tiến trình BPEL. Tuy nhiên, giải pháp còn hạn chế là mới chỉ gọi được các dịch vụ lưới không an toàn, chứ chưa gọi được các dịch vụ lưới an toàn. Hạn chế này được khắc phục trong một giải pháp được nói đến ngay sau đây. Kết quả này đã được công bố trong [13][9]. Giải pháp mở rộng mô hình điều khiển truy nhập cho các hệ thống luồng công việc trong môi trường lưới. Giải pháp nhằm hoàn thiện hơn giải pháp gọi dịch vụ lưới ở trên với việc cho phép gọi các dịch vụ lưới an toàn. Giải pháp tự động hóa khai thác tiến trình BPEL, với kết quả đã được công bố trong [11]. 4.3.1 Giải pháp gọi dịch vụ lưới từ tiến trình BPEL 4.3.1.1 Khảo sát vấn đề Hiện nay, engine ODE chỉ có thể gọi các dịch vụ Web, không thể gọi các dịch vụ lưới. Trong [13], luận án đã tiến hành khảo sát để làm rõ nguyên nhân của vấn đề trên. Trên cơ sở đó, đề xuất một giải pháp cho việc gọi dịch vụ lưới từ tiến trình BPEL trong engine ODE. Đầu tiên, phát triển một chương trình kiểm thử (test) nhằm xác định engine ODE gọi dịch vụ Web như thế nào và từ đó xác định chính xác vấn đề khi ODE gọi một dịch vụ lưới bên ngoài từ một tiến trình BPEL. Chương trình kiểm thử gồm có ba phần: - Một dịch vụ lưới gọi là MathService đã được điều chỉnh từ một ví dụ trong [87] (ví dụ này chỉ chạy được với Globus Toolkit (GT) 4.0. Luận án đã có những thay đổi cần thiết để nó có thể chạy được với GT 4.2). Dịch vụ lưới này đã theo mẫu factory/instance [87]. Theo mẫu này, mỗi dịch vụ lưới sẽ có một dịch vụ factory, gọi là MathFactoryService, là một dịch vụ Web bình thường có vai trò là tạo ra các thể hiện của dịch vụ lưới. Bên cạnh việc tạo ra các thể hiện mới, thao tác này (gọi là createResource) cũng trả về các ResourceKeys (Khóa Tài Nguyên) cho các thể hiện. Công cụ Globus Toolkit 4.2 đã được sử dụng để khai thác dịch vụ lưới trong container dịch vụ Web. 104 - Một tiến trình BPEL được gọi là Test-FactoryGS-V2. Sơ đồ của tiến trình này được minh họa trong Hình 4-3. Chi tiết của tiến trình sẽ được giải thích ở phần sau. ODE engine được khai thác trong Apache Tomcat 6. Ngoài ra, công cụ SoapUI [85] cũng được sử dụng để chạy và kiểm tra tiến trình BPEL. Để xác định rõ vấn đề, tiến trình BPEL được thiết kế để kiểm tra ba hoạt động (activities): - - Hoạt động đầu tiên là gọi dịch vụ lưới để lấy ResourceKey của nó. Hoạt động thứ hai là gán giá trị ResourceKey này cho một PartnerLink, cho phép PartnerLink này mang theo ResourceKey. Hoạt động thứ ba là sử dụng PartnerLink để gọi thao tác khác của dịch vụ lưới. Hình 4-3: Sơ đồ của tiến trình BPEL Test-Factory GS-V2 Các hoạt động chính của tiến trình BPEL FactoryGS-V2 Tiến trình BPEL được thiết kế sẽ thực hiện ba hoạt động như sau: (1) Gọi thao tác createResource của MathFactoryService và lưu trữ giá trị ResourceKey được trả về trong một biến gọi là CreateResourceOut bởi đoạn mã sau: (2) Gán giá trị của biến CreateResourceOut cho một PartnerLink bởi đoạn mã sau: (3) Gọi một thao tác của dịch vụ lưới MathService bởi đoạn mã sau: \end{verbatim} 4.3.1.2 Kết quả kiểm thử và giải thích Khi hoạt động (1) được gọi thành công, giá trị trả về của CreateResourceOut chứa ResourceKey, như được chỉ ra trong phần in đậm trong đoạn thông báo trả về sau: 108  … 4.3.1.4 Cài đặt Giải pháp trên đã được cài đặt thành công thông qua việc nâng cấp Apache ODE engine để trở thành một công cụ có tên G-ODE [9]. Thiết kế chi tiết 1. Yêu cầu cho Dịch vụ lưới Giải pháp yêu cầu mỗi Dịch vụ lưới cần có một thao tác (operation) tên là createResource, được dùng để tạo ra một resource key, sẽ được sử dụng trong các lời gọi của các thao tác khác của Dịch vụ lưới. Việc gọi thao tác chỉ cần sử dụng lời gọi thông thường giống như gọi các thao tác của Dịch vụ Web. Thao tác createResource sẽ trả về một EPR bao gồm resource key của Dịch vụ lưới. Resource key sẽ được chèn vào vị trí thích hợp trong các thông báo (message) được gửi để gọi các thao tác khác của Dịch vụ lưới. 2. Message handlers (phần modul xử lý các thông báo) Dựa theo mô hình xử lý của ODE (được kế thừa từ Axis2), cài đặt trong luận án bao gồm hai handler: 109   GridHandlerIn: nằm trong phaseOrder InFlow: Handler này chịu trách nhiệm phát hiện resource key từ thông báo trả về bởi thao tác createResource của Dịch vụ lưới. Nếu resource key được tìm thấy, sẽ được ghi lại và sau này được sử dụng trong những lời gọi của các thao tác khác của Dịch vụ lưới. GridHandlerOut: nằm trong phaseOrder OutFlow: Handler chịu trách nhiệm tìm resource key thích hợp trong số những resource key đã được lưu lại, sau đó chèn vào phần đầu (header) của thông báo được gửi để gọi thao tác khác của Dịch vụ lưới. Hình 4-4 biểu diễn lược đồ tuần tự mô tả trình tự xử lý của các handler trên. Trình tự này bao gồm các bước sau: - - - Bước 1: một tiến trình BPEL gọi một thao tác MethodA của dịch vụ lưới (MethodA có thể là createResource hoặc thao tác khác). Khi nhận được lời gọi, ODE engine sẽ tạo ra một thông báo SOAP tương ứng và gửi đến GridHandlerOut để xử lý. Bước 2: GridHandlerOut sẽ kiểm tra sự tồn tại của resource key trong ConfigureContext. Nếu không tồn tại, thao tác MethodA phải là createResource và GridHandlerOut cho phép thông báo được đi qua, không bị thay đổi gì. Trái lại, nếu có sự tồn tại của resource key, GridHandlerOut sẽ chèn resource key vào thông báo trước khi gửi đi. Bước 3: thao tác MethodA thực sự được gọi và trả về một thông báo SOAP được GridHandlerIn xử lý. Bước 4: nội dung của thông báo trên sẽ được kiểm tra để tìm thành phần EPR. Nếu thành phần này tồn tại, có nghĩa là thao tác được gọi chính là createResource, thì thông báo này sẽ chứa resource key. Khi đó, resource key sẽ được lấy ra và lưu lại trong biến ConfigureContext. 110 Hình 4-4: Lược đồ tuần tự của hai handler. Do cùng một lúc có thể có nhiều thể hiện (instance) của một dịch vụ lưới được tạo ra và chạy tương tranh với nhau, nên một vấn đề nảy sinh là làm thế nào để lưu trữ các resource key của các thể hiện này. Bởi vì trong ODE, mỗi thể hiện của một dịch vụ lưới có một biến ConfigureContext duy nhất, nên trong cài đặt, ConfigureContext đã được dùng để lưu các resource key. 3. Chi tiết cài đặt Trong ODE, mỗi handler là một lớp kế thừa lớp AbstractHandler. Sau khi cài đặt hai handler GridHandlerIn và GridHandlerOut, cấu hình của chúng cần được chèn vào trong tệp cấu hình Axis2.xml như trong đoạn code sau: 111  4. Kết quả chạy thử nghiệm Chương trình thử nghiệm nhằm mục đích kiểm tra khả năng gọi dịch vụ lưới từ tiến trình BPEL thông qua cài đặt G-ODE sẽ chạy thế nào, đặc biệt khi tiến trình BPEL cần gọi nhiều dịch vụ lưới khác nhau. Trong lần thử nghiệm này, một tiến trình BPEL đơn giản được triển khai sẽ gọi hai dịch vụ lưới là MathService và CalcService (xem Hình 4-5). Tiến trình này thực hiện các công việc sau: a) Đầu tiên, hai tham số X và Y được khai báo. Sau đó hai thể hiện của hai dịch vụ lưới này sẽ được tạo ra (nhờ các hoạt động CreateCacl and CreateMath). Điều này nhằm lấy ra và sau đó lưu trữ lại giá trị resource key của các thể hiện này. b) Sau đó, hai luồng song song (parellel flow) gọi hai dịch vụ lưới được tạo ra. Trong luồng đầu tiên gọi thao tác Add(X), sau đó gọi thao tác Multiply(Y) của dịch vụ lưới CalcService (điều này có nghĩa là cho ra kết quả X*Y, bởi vì giá trị khởi tạo của dịch vụ này là bằng 0). Trong luồng thứ hai, chỉ gọi thao tác Add(X) của dịch vụ lưới MathService (kết quả sẽ là X). c) Cuối cùng, đầu ra với hai kết quả trên sẽ được trả về. Kết quả thực thi tiến trình BPEL được thể hiện trên Hình 4-6. Như có thể thấy trên hình, hai dịch vụ lưới có thể được gọi dễ dàng nhờ có G-ODE. Từ góc độ người phát triển tiến trình BPEL, việc gọi dịch vụ lưới gần giống như việc gọi dịch vụ Web, thậm chí không cần phải quan tâm đến sự tồn tại của các resource key của các dịch vụ lưới. 112 Hình 4-5: Tiến trình BPEL thử nghiệm. Hình 4-6: Kết quả chạy tiến trình BPEL. 113 4.3.1.5 Bàn luận về giải pháp Có thể thấy, cho đến nay vẫn chưa có giải pháp nào cho phép gọi các dịch vụ lưới sử dụng ODE engine. Luận án chỉ dừng lại so sánh giải pháp được đề xuất với các giải pháp mà sử dụng các BPEL engine khác. - - So sánh với giải pháp trong [95] mở rộng BPEL chuẩn bằng việc bổ sung các hoạt động mới, giải pháp được đưa ra trong luận án đơn giản hơn nhiều, nó thể hiện ở hai điểm. Thứ nhất, với giải pháp trong [95], người dùng không những phải học thêm các hoạt động mới thêm vào, cũng phải xác định xem một dịch vụ là dịch vụ lưới hay dịch vụ Web khi gọi dịch vụ đó. Còn với giải pháp trong luận án, việc gọi dịch vụ lưới hoàn toàn giống như gọi dịch vụ Web thông thường. Thứ hai, giải pháp mở rộng BPEL cũng đòi hỏi nhiều thay đổi, từ modul biên dịch tiến trình BPEL cho đến modul chạy tiến trình đã được dịch. Trái lại, giải pháp trong luận án không làm thay đổi đến các modul này. Nó chỉ bổ sung một số handler độc lập (mỗi cái là một Java class) và thực hiện một số thay đổi cần thiết chỉ trong tệp cấu hình để đăng ký các handler mới. Giải pháp được đề xuất trong [71] tương tự như của luận án, nhưng cho ActiveBPEL engine, chứ không phải cho ODE engine. Tương tự như ODE engine, BPEL engine này cũng không hỗ trợ việc gọi các dịch vụ lưới, mà chỉ gọi được các dịch vụ Web. Tuy nhiên, giải pháp này không đề cập đến vấn đề như đã đề cập ở trên đối với ActiveBPEL engine. Nếu chỉ sử dụng các mẹo trong tiến trình BPEL sẽ không giải quyết được vấn đề này của BPEL engine, dường như rất khó gọi thành công các dịch vụ lưới từ trong một tiến trình. Tóm lại, giải pháp được đưa ra trong luận án là giải pháp hợp lý cho phép ODE BPEL engine gọi các dịch vụ lưới. Giải pháp này không những đơn giản, không đòi hỏi phải chỉnh sửa BPEL engine, mà còn yêu cầu rất ít nỗ lực của những người phát triển tiến trình BPEL. 4.3.1.6 Kết luận về cài đặt G-ODE Qua khảo sát kỹ lưỡng vấn đề đối với ODE BPEL engine, nguyên nhân không thể gọi các dịch vụ lưới có thông tin trạng thái đã được phát hiện. Từ đó, luận án đã đề xuất một giải pháp đơn giản vàcó tính thực tế. Đồng thời, việc cài đặt thành công giải pháp qua GODE đã chứng tỏ sự đúng đắn và khả thi của giải pháp. Ý nghĩa của giải pháp là cho phép các dịch vụ lưới khác nhau có thể được kết hợp trong Grid/Workflows có cấu trúc sử dụng BPEL và được gọi thông qua cơ sở hạ tầng lưới (Grid infrastructure) nằm bên dưới. Điều đó ngầm chứa khả năng cho phép dãy các công việc phức tạp (complex sequences of tasks) có thể được kết hợp và thực thi tự động trên môi trường Tính toán lưới, thay vì chỉ thực hiện các yêu cầu tính toán lưới đơn giản. Tuy nhiên, giải pháp còn có hạn chế là nó mới chỉ gọi được các dịch vụ lưới không an toàn (unsecured grid services), chưa gọi được các dịch vụ lưới an toàn (secured grid services). Vấn đề này sẽ được giải quyết bằng giải pháp đưa ra một mô hình điều khiển truy nhập phù hợp, sẽ được trình bày ở phần tiếp theo. 114 4.3.2 Mở rộng mô hình điều khiển truy nhập dựa trên thuộc tính cho các hệ thống luồng công việc cho môi trường lưới Ở phần trên, vấn đề gọi dịch vụ lưới từ ODE engine đã được phân tích kỹ càng, từ đó giải pháp G-ODE của luận án đã được đề xuất và cài đặt thành công. Tuy nhiên, engine này vẫn còn thiếu một cơ chế điều khiển truy nhập phù hợp, rất cần thiết trong môi trường lưới, giải quyết hai vấn đề còn tồn tại với G-ODE: - - Thứ nhất: dịch vụ lưới an toàn vẫn chưa thể gọi được, mới chỉ có các dịch vụ không an toàn (các môi trường lưới thông thường hỗ trợ cả hai cách gọi này). Tuy nhiên, việc gọi các dịch vụ không an toàn chỉ dùng trong môi trường mạng cục bộ và có tính thử nghiệm. Còn trong môi trường lưới thực sự, thường chỉ chấp nhận cách gọi các dịch vụ an toàn. Lý do là để gọi được các dịch vụ lưới an toàn, đòi hỏi phải có cơ chế quản lý các chứng chỉ số hợp lệ (valid digital certificates ) của đối tượng gọi dịch vụ (ở đây là G-ODE engine). Tuy nhiên, đây là điều còn thiếu trong engine trong luận án. Thứ hai: G-ODE hiện nay và cả ODE đều chưa có sự hỗ trợ trong việc biểu diễn và quản lý các ràng buộc về luồng công việc (workflow constraints) như: gán vai trò cho người dùng (role assignment - ai có thể có quyền truy nhập và truy nhập vào hoạt động nào trong luồng công việc), phân chia công việc (seperation of duty - có thể hai công việc khác nhau trong cùng một luồng công việc cần phải được thực hiện bởi hai người khác nhau), công việc liên quan (binding of duty) một người đã thực hiện hoạt động này, cũng phải thực hiện nốt công việc kia, chứ không được giao cho người khác, các ràng buộc tĩnh (static constraints - là ràng buộc áp dụng chung cho tất cả các thể hiện của luồng công việc) và các ràng buộc động (dynamic constraints - là loại ràng buộc áp dụng riêng cho từng thể hiện của luồng công việc) [8], v.v Các loại ràng buộc này rất cần thiết trong các ứng dụng luồng công việc trong thực tế. Để giải quyết các vấn đề trên, luận án đã đề xuất một mô hình điều khiển mới, mở rộng từ mô hình điều khiển dựa trên thuộc tính. Phần này trình bày cấu tạo của mô hình, cách áp dụng để biểu diễn các loại ràng buộc trong lưới và trong luồng công việc. Điều khiển truy nhập Điều khiển truy nhập là quá trình kiểm soát mọi truy nhập vào hệ thống và các tài nguyên hệ thống, nhằm đảm bảo rằng chỉ có những truy nhập hợp lệ và đã được cấp đủ quyền, mới được phép thực hiện truy nhập [84]. Do đó, vai trò của một hệ thống điều khiển truy nhập bao gồm: - - Hỗ trợ những người dùng quan trọng (thường là nhà quản trị hoặc có vai trò quản trị) xây dựng các metadata điều khiển truy nhập cần thiết (như các thông tin về người dùng, quy tắc truy nhập, vai trò và quyền của người, tình trạng các tài nguyên, v.v). Tiếp nhận các yêu cầu truy nhập từ người dùng hoặc từ các tiến trình ứng dụng muốn truy nhập vào các tài nguyên của hệ thống. 115 - Kiểm tra các yêu cầu để từ đó sẽ đưa ra quyết định: chấp nhận (toàn bộ hay một phần) hoặc từ chối yêu cầu. Nếu yêu cầu được chấp nhận, cần phải cấp cho đối tượng có yêu cầu đủ các quyền cần thiết để truy nhập vào tài nguyên được yêu cầu. Giám sát quá trình truy nhập của đối tượng truy nhập nhằm phát hiện và xử lý kịp thời các vấn đề có thể phát sinh trong quá trình truy nhập này (như truy nhập không đúng quyền hạn, tài nguyên không đủ đáp ứng theo yêu cầu, v.v). Để hoàn thành được các vai trò như trên, hệ thống điều khiển truy nhập phải giải quyết thỏa đáng các vấn đề sau: - Sự bí mật (Secrecy): Tiết lộ các thông tin cần giữ bí mật. Sự toàn vẹn (Integrity): Các thay đổi không được phép hoặc không phù hợp. Không có từ chối truy nhập (No denials-of-service): Đảm bảo tính sẵn sàng của các tài nguyên cho những người dùng hợp lệ và đủ quyền. Quá trình phát triển của một hệ thống điều khiển truy nhập dựa trên ba khái niệm: - - - Chính sách an ninh (Security policy): quy định các quy tắc truy nhập ở mức cao. Ví dụ như: chỉ có người chủ của một tệp mới có thể thay đổi nó; chỉ có nhân viên làm việc toàn thời gian mới được phép soạn thảo loại tài liệu nào đó, trong khi các nhân viên làm việc bán thời gian chỉ được xem nội dung của tài liệu. Mô hình an ninh (Security model): biểu diễn hình thức của chính sách an ninh, nhằm chứng minh được các tính chất mong muốn (an toàn) của hệ thống đang được thiết kế và triển khai. Cơ chế an ninh (Security mechanism): là các chức năng ở mức thấp, được cài đặt để thực thi các chính sách và mô hình an ninh ở trên. 4.3.2.1 Các mô hình điều khiển truy nhập liên quan Các chính sách điều khiển truy nhập (ĐKTN) có thể rơi vào một trong hai loại [104]: - - Điều khiển truy nhập tùy ý (Discretionary Access Control (DAC)): là cách hạn chế truy nhập đến các tài nguyên dựa trên định danh và nhu cầu cần biết của người dùng, tiến trình ứng dụng hoặc nhóm người dùng có sở hữu tài nguyên đó. Sự điều khiển được gọi là tùy ý (discretion) theo nghĩa là một chủ thể đã có một số quyền truy nhập nào đó thì có thể chuyển quyền đó (một cách trực tiếp hay gián tiếp) cho bất kỳ chủ thể khác. Điều khiển truy nhập bắt buộc (Mandatory Access Control (MAC)): là cách hạn chế truy nhập đến các tài nguyên dựa trên các thuộc tính hay nhãn an ninh cố định, được gán cho người dùng cũng như cho các tài nguyên. Sự điều khiển được gọi là bắt buộc (mandatory) với nghĩa là các quyền truy nhập đã bị quy định cứng bởi hệ thống và nó không thể bị thay đổi bởi người dùng hoặc bởi chương trình của người dùng. Các mô hình an ninh tiêu biểu được dùng để cài đặt cho các chính sách DAC và MAC ở trên sẽ được giới thiệu ngay sau đây. 116 - - - Mô hình ĐKTN dựa trên định danh (Identity Based Access Control (IBAC)): Trong mô hình này, quyền truy nhập vào tài nguyên liên kết trực tiếp với định dạng của chủ thể (ví dụ như định danh tên người dùng). Việc truy nhập vào một tài nguyên chỉ được cho phép khi tồn tại liên kết đó. Một ví dụ về mô hình IBAC là việc sử dụng Access Control Lists (ACL - Danh sách điều khiển truy nhập). Một ACL chứa một danh sách những người dùng và các quyền truy nhập của họ như đọc, ghi, chạy, v.v. Mặc dù, có ưu điểm là tương đối dễ cài đặt, nhưng mô hình IBAC sử dụng ACL có nhược điểm: khi số lượng định danh trong ACL tăng lên sẽ dẫn đến việc duy trì và xử lý các yêu cầu truy nhập khó khăn và kém hiệu quả hơn. Điều này làm cho khả năng mở rộng (scale up) của cách tiếp cận này rất hạn chế. Hơn nữa, các quyết định truy nhập lại chỉ dựa trên định danh của người dùng, chứ không dựa trên vai trò, vị trí công việc và các đặc tính của họ. Cách tiếp cận này không phù hợp lắm trong các môi trường doanh nghiệp. Mô hình ĐKTN dựa trên vai trò (RBAC) được trình bày sau đây chính là nhằm khắc phục hạn chế của mô hình này. Mô hình ĐKTN dựa trên vai trò (Role Based Access Control (RBAC)): Mô hình này quy định quyền truy nhập vào tài nguyên dựa trên chức năng nghiệp vụ hay vai trò được chủ thể đang thực hiện. Quyền truy nhập được gán cho các vai trò thích hợp, thay vì gán trực tiếp cho định danh như trong mô hình IBAC. So với mô hình IBAC, mô hình RBAC thêm một mức gián tiếp giữa các định danh và các tài nguyên cần truy nhập. Do quyền truy nhập không còn được gán trùng lặp cho từng cá nhân người dùng, mô hình RBAC có khả năng mở rộng tốt hơn và các chi phí quản trị giảm đáng kể. Hơn nữa, mô hình RBAC cũng ánh xạ đến chức năng nghiệp vụ và trách nhiệm của người dùng một cách trực quan hơn là mô hình IBAC, nên nó cũng giúp người dùng dễ hiểu và dễ sử dụng hơn. Mô hình ĐKTN dựa trên thuộc tính (Attribute Based Access Control (ABAC)): là một mô hình ĐKTN tổng quát hơn mô hình RBAC, mô hình ABAC này có thể định nghĩa các quyền truy nhập dựa trên các đặc tính liên quan đến an ninh, hay còn được gọi là các thuộc tính mà có thể được phân chia thành ba nhóm:  Các thuộc tính của chủ thể (Subject Attributes): một chủ thể là một đối tượng thực hiện một hành động trên một tài nguyên nào đó. Mỗi chủ thể sẽ có các thuộc tính liên quan giúp xác định định danh và các đặc tính của chủ thể, ví như: mã số cá nhân, họ tên, nơi công tác, ví trị công tác, v.v. Do vậy, vai trò của một chủ thể cũng có thể được coi như một thuộc tính của chủ thể đó.  Các thuộc tính của tài nguyên (Resource Attributes): một tài nguyên là một thực thể (ví dụ như một web service, một cấu trúc dữ liệu, một cơ sở dữ liệu,v.v) được sử dụng bởi một chủ thể. Tương tự như một chủ thể, một tài nguyên cũng có các thuộc tính nhằm bổ sung thêm thông tin cần thiết cho quá trình kiểm tra và đưa ra các quyết định về truy nhập.  Các thuộc tính của môi trường (Environment Attributes): giúp mô tả các khía cạnh cần thiết của môi trường hoạt động hay ngữ cảnh mà trong đó các 117 - yêu cầu truy nhập xuất hiện. Các khía cạnh này có thể rất đa dạng như: vận hành, kỹ thuật, thời gian, địa điểm, v.v. Attribute Based Multipolicy Access Control: Mô hình ABMAC [55] là sự mở rộng của mô hình ABAC, nhằm đề xuất một mô hình điều khiển truy nhập có khả năng mở rộng để có thể dễ dàng hỗ trợ nhiều chính sách an ninh không đồng nhất. Mô hình này định nghĩa một số thực thể điều khiển truy nhập mới như sau:  Requestor: Thực thể sẽ gửi yêu cầu truy nhập đến các dịch vụ lưới và gọi các thao tác (operations) trong các dịch vụ đó. Thực thể này có vai trò tương tự như thực thể Subject trong mô hình ABAC.  Service: Dịch vụ lưới được các Requestor yêu cầu. Nó tương tự như thực thể Resource trong ABAC.  Resource: Thực thể cung cấp tài nguyên cho các hoạt động của các dịch vụ lưới. Một điểm thú vị của thực thể này trong môi trường lưới là nó có lưu tồn trạng thái (statefulness); có nghĩa là mỗi Resource có một tập các dữ liệu trạng thái được biểu diễn bằng một tài liệu XML và có chu kỳ sống xác định.  Action: Thao tác của dịch vụ lưới, có thể được gọi bởi các Requestor.  Environment: Các thông tin ngữ cảnh liên quan đến việc gọi dịch vụ lưới. Hiện nay, vẫn còn một hạn chế trong đa số các mô hình điều khiển truy nhập ABAC và dựa trên ABAC. Đó là chỉ coi các thuộc tính của các thực thể như các giá trị đơn (atomic value). Điều này có nghĩa là một thuộc tính không thể chứa các thuộc tính khác. Tuy nhiên, trong thực tế, nhiều khi các thuộc tính của các thực thể lại có tính phức hợp (compound), tức là chúng lại chứa các thuộc tính khác (xem ví dụ 4-1). Hạn chế này không những làm giảm khả năng biểu diễn của mô hình, mà còn gây ra nhiều khó khăn trong việc biểu diễn các quy tắc và chính sách an ninh. Mô hình được đề xuất trong luận án khắc phục hạn chế đó bằng khả năng hỗ trợ thuộc tính phức hợp. Ví dụ 4-2: Mỗi thực thể người dùng trong môi trường lưới thường có các thuộc tính như: name, certificates, roles. Thuộc tính certificates, nếu theo chuẩn X.509, lại có các thuộc tính như: subject-name, (distinguished name), issuer-name. 4.3.2.2 Mô hình điều khiển truy nhập mở rộng Phần này sẽ giới thiệu về mô hình mở rộng được đề xuất trong luận án có tên gọi: “compound attributed based access control model” (CABAC). Trong phần sau sẽ đưa ra định nghĩa cho các thành phần của mô hình. Sau đó, vấn đề áp dụng mô hình vào việc biểu diễn các quy tắc và chính sách phân quyền (authorization rules and policies). Định nghĩa mô hình CABAC: Một mô hình CABAC M là một bộ gồm các thành phần {S, R, E, AS, AR, AE, F, P}, ký hiệu M = {S, R, E, AS, AR, AE, F, P }, với các ý nghĩa như sau: 118 - S, R, E: tương ứng là tập các chủ thể (subjects), tập các tài nguyên (resources) và tập các yếu tố môi trường (environments). S = {s1, s2,..., sn} R = {r1, r2,..., rp} E = {e1, e2,..., eq}    AS, AR, AE: tương ứng là các tập các thuộc tính của các chủ thể, của các tài nguyên và của các yếu tố môi trường. Mỗi thuộc tính của các thực thể này có thể nhận giá trị nguyên tố (còn gọi là giá trị đơn), hoặc giá trị phức hợp (tức là nó có thể chứa một hay nhiều thuộc tính khác). F: là tập các hàm tiện ích được sử dụng để định nghĩa các quy tắc (rules). Tập hàm này hoàn toàn phụ thuộc vào cấu trúc cụ thể của mô hình, ví như số lượng và kiểu dữ liệu của các thuộc tính. Một số hàm tiêu biểu được liệt kê trong Bảng 4-2. P: tập các quy tắc truy nhập (rules), biểu diễn cho chính sách (Policy) an ninh của hệ thống. Phần biểu diễn các quy tắc sẽ được trình bày chi tiết hơn ở phần sau. Biểu diễn các chính sách an ninh Trong mô hình CABAC được đề xuất bởi luận án, mỗi quy tắc (rule) sẽ xác định một điều kiện mà nếu thỏa mãn thì một chủ thể không thể truy nhập vào một tài nguyên nào đó trong một môi trường cụ thể nào đó. Điều đó cũng có nghĩa là chủ thể chỉ có thể truy nhập vào tài nguyên trong điều kiện môi trường, nếu nó không thỏa mãn quy tắc. Mỗi quy tắc r là một biểu thức có dạng: r: cannot_access(s, r, m, e) ← B1, B,….., Bm,, not C1, not C2, …., not Cn; m, n ≥ 0 (4.1) Trong đó: s, r, m, e tương ứng ký hiệu cho một chủ thể, một tài nguyên, một mode (một tập các thao tác của r) và một yếu tố môi trường; B1, B2,…, Bm, not C1, not C2, …, not Cn là các toán hạng nguyên tố (atoms) và not ký hiệu cho phép phủ định (negation). Nếu giá trị vế phải của biểu thức trên là đúng (TRUE), thì chủ thể s không thể truy nhập tài nguyên r ở mode m trong ngữ cảnh e. Trong một quy tắc, giá trị của các tham số s, r, m và e có thể NULL (được ký hiệu bằng "_"), với ý nghĩa là quy tắc này áp dụng cho mọi giá trị có thể của tham số NULL đó (xem thêm Ví dụ 4-2). Ví dụ 4-2: Sau đây là một số biểu thức có giá trị NULL và ý nghĩa của nó: - - cannot_access(s, r, m,_): có nghĩa là s không thể truy nhập r ở mode m trong mọi ngữ cảnh; cannot_access(s, r, _, _): có nghĩa là s không thể truy nhập r ở mọi thao tác của r và trong mọi ngữ cảnh. 119 Bảng 4-2: Các hàm tiện ích được sử dụng trong CABAC Hàm Ý nghĩa type(r) Trả về kiểu của tài nguyên r. isAtomic(e, a) Kiểm tra xem thuộc tính a của thực thể e có phải là nguyên tố không. card(s) Trả về số lượng phần tử (lực lượng) của tập s. Get AttName (e) Trả về giá trị của thuộc tính AttName của thực thể e. getCurrentTask(r) Nếu r là một workflow, nó trả về nhiệm vụ hiện tại (current task) cần phải làm. isRun(s, r, t) Nếu r là một workflow, nó kiểm tra xem nhiệm vụ t trong r có phải được thực hiện bởi chủ thể s. Nó trả về TRUE nếu đúng và FALSE nếu trái lại. Ví dụ 4-3: Ví dụ này minh họa việc sử dụng mô hình được đề xuất trong luận án để biểu diễn một số quy tắc truy nhập cho một tổ chức ảo trong môi trường lưới. Để có thể đăng nhập (login) và truy nhập vào các tài nguyên trong tổ chức này, mỗi người dùng (user) cần phải có ít nhất một certificate (là một tệp xác thực có chữ ký điện tử của một tổ chức cấp chứng chỉ). Quy tắc này và một số quy tắc khác nữa được minh họa trong Bảng 4-3. Bảng 4-3: Biểu diễn các quy tắc trong Ví dụ 4-3 Quy tắc Biểu thức Các chủ thể có chứng chỉ (certificate) không hợp lệ thì không thể truy nhập vào bất cứ tài nguyên nào. r1: cannot_access(s, _, _,_) ← getInValidCertificate(s); Chỉ các chủ thể thuộc trường ĐHBK Hà Nội (HUST) mới có thể truy nhập vào các luồng công việc với đầy đủ các quyền thao tác của họ. r2: cannot_access(s, r, _, _) ← getOrganization(s) ≠ 'HUST', type(r) = 'workflow'; Chỉ người dùng Bob có thể truy nhập vào các luồng công việc để thực thi (RUN) chúng. r3: cannot_access(s, r, {RUN},_) ← getName(s) ≠ 'Bob'; Ví dụ 4-4: Ví dụ này minh họa việc sử dụng mô hình được đề xuất trong luận án trong các hệ thống luồng công việc. Luồng công việc được sử dụng ở đây là tiến trình gửi bài cho hội nghị, được minh họa ở Hình 4-7. Tiến trình này có thể được tóm tắt như sau: 120 Hình 4-7: Luồng công việc cho tiến trình xử lý việc nộp bài cho hội nghị. Đầu tiên, ở nhiệm vụ T1, các bài báo được gửi đến sẽ do một nhân viên trong Ban Tổ chức hội nghị tiếp nhận. Nhân viên này sẽ kiểm tra các điều kiện ban đầu của các bài báo (như chủ đề, định dạng,v.v), loại bớt các bài không hợp lệ (nhiệm vụ T2). Sau đó, các bài báo hợp lệ sẽ được gửi đi phản biện (review), mỗi bài sẽ gửi cho hai người phản biện độc lập (nhiệm vụ T3 và T4). Kết quả phản biện sẽ được gửi cho một người thứ ba để đưa ra quyết định cuối cùng: chấp nhận (accept) hay từ chối (reject) bài báo (nhiệm vụ T5). Hệ thống luồng công việc có thể sử dụng mô hình M = {S, R, E, AS, AR, AE, F, P}, với các thành phần có ý nghĩa như sau: - - - - S: tập các chủ thể là những người sử dụng của hệ thống luồng công việc và của môi trường lưới. R: tập các tài nguyên, ví như các luồng công việc trong hệ thống. E: tập các yếu tố môi trường. AS: tập các thuộc tính của chủ thể (người dùng), ví như: user-name, certificate(kiểu phức hợp), roles (tập các vai trò gán cho người dùng. Thuộc tính được đưa vào nhằm hỗ trợ khả năng như của mô mình RBAC [7]). AR: tập các thuộc tính của luồng công việc, ví như: workflow-name, tasks (tập các nhiệm vụ (kiểu phức hợp)), roles (tập các vai trò mà có thể truy nhập vào workflow). Thuộc tính phức hợp tasks lại bao gồm các thuộc tính sau: task-name, roles (tập các vai trò mà có thể thực thi nhiệm vụ này). AE: tập các thuộc tính về môi trường, ví như: current-date, current-time. F: tập các hàm tiện ích. Ngoài các hàm tiện ích như ở Bảng 4-2, hệ thống luồng công việc còn cần cung cấp thêm các hàm tiện ích liên quan đến luồng công việc P: danh sách các quy tắc truy nhập, được liệt kê ở Bảng 4-4. 4.3.2.3 Thiết kế chi tiết mô hình CABAC Từ các yêu cầu của mô hình CABAC nêu ở phần trên, luận án đưa ra thiết kế chi tiết cho các modul của mô hình, như được minh họa trong Hình 4-8. 121 Hình 4-8: Thiết kế chi tiết mô hình CABAC. Bảng 4-4: Một số quy tắc truy nhập cho Ví dụ 4-4 Quy tắc Biểu thức r1: luồng công việc yêu cầu có ít nhất bốn r1: cannot_access(_, r, _, _) ← người dùng tham gia (một người nhận và type(r)='workflow', card(getRoles(r)) < 4 ; kiểm tra bài báo, hai người phản biện, và một người nữa sẽ quyết định cuối cùng). r2: người dùng mà nhận bài (T1) cũng sẽ r2: cannot_access(s, getCurrentTasks(r), kiểm tra sơ bộ bài đó (T2). {RUN},_) ← type(r)='workflow', not isRun(s, r, T1), getTaskName(getCurrentTask(r)) = T2 r3: Hai tác giả phản biện các bài (T3 và T4) r3: cannot_access(s, getCurrentTasks(r), phải là hai người khác nhau. {RUN},_) ← type(r)='workflow', isRun(s, r, T3), Name(getCurrentTask(r)) = T4; getTask- r3.2: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow', isRun(s, r, T4), getTask-Name(getCurrentTask(r)) = T3; 122 Thành phần chính trong thiết kế này là Security component, được thiết kế tuân theo kiến trúc tiêu chuẩn của các hệ thống ABAC (attributed-based access control) XACML (eXtensible Access Control Markup Language) [43], bao gồm ba module: - - - PEP (Policy Enforcement Point): module thực hiện các điều khiển truy nhập, bao gồm các bước như sau: đầu tiên, nó tiếp nhận các lời gọi của các dịch vụ bên ngoài (data flow (1)) từ các tiến trình trong G-ODE engine. Sau đó, các lời gọi này sẽ được dịch thành các yêu cầu (requests) ở dạng chuẩn (well-defined forms) (luồng dữ liệu (2)). Các yêu cầu này sau đó sẽ được chuyển cho module PDP. PDP (Policy Decision Point): Sau khi tiếp nhận các yêu cầu từ PEP, module này sẽ đánh giá chúng dựa trên các chính sách an ninh (bao gồm tập các quy tắc truy nhập), để từ đó đưa ra quyết định trả về cho PEP (luồng dữ liệu (3)). Quyết định này thường là chấp nhận hoặc từ chối truy nhập. PIP (Policy Information Point): module này hoạt động như một nguồn giá trị cho các thuộc tính. Nó cũng chứa tập các hàm tiện ích của hệ thống. Ý nghĩa của các luồng dữ liệu trao đổi giữa các module (từ (1) đến (6)) được tóm tắt trong Bảng 4-5. Bảng 4-5: Ý nghĩa của các luồng dữ liệu trong Hình 4-8. Luồng dữ liệu Ý nghĩa (1) Từ một tiến trình trong G-ODE engine, tiến hành gọi một dịch vụ bên ngoài. Dịch vụ được gọi có thể là Web service hoặc Grid service. (2) Yêu cầu gọi được dịch ra bởi PEP. (3) Trả lời cho yêu cầu gọi do PDP trả về cho PEP. Đọc nội dung này, PEP sẽ biết được quyết định của PDP là chấp nhận hay từ chối yêu cầu gọi. Trong trường hợp chấp nhận, lời gọi sẽ được chuyển hướng đến địa chỉ thực gọi của nó (là một Web service hoặc Grid service) (nằm ở luồng dữ liệu số (4)). Trái lại, PEP sẽ thông báo cho G-ODE về sự từ chối truy nhập và lý do từ chối (nằm trong luồng dữ liệu số (6)). (4) Chuyển hướng lời gọi được gửi bởi PEP. (5) Trong trường hợp lời gọi là hướng đến Grid service, sẽ được kiểm tra thêm một lần nữa bởi Hạ tầng An ninh lưới (Grid Security Infrastructure - GSI) để xem có tuân theo các chính sách an ninh của lưới không. Nếu vi phạm, lỗi truy nhập sẽ được gửi lại cho PEP bởi luồng dữ liệu này. (6) Chứa thông tin từ chối từ PDP hoặc từ GSI. 4.3.2.4 Các nghiên cứu liên quan Trong [8], mô hình RBAC mở rộng (extended role based access control - ERBAC) đã được đề xuất nhằm khắc phục hạn chế trong các mô hình RBAC trước: chưa thể biểu diễn 123 các ràng buộc trên các vai trò (roles). Các loại ràng buộc này, ví dụ như ràng buộc phân chia công việc (separation of duties), khá phổ biến trong các tiến trình nghiệp vụ trong thực tế. Để giải quyết vấn đề này, đầu tiên các tác giả trong [8] đã phân tích nhiều loại ràng buộc cấp quyền (authorization constraints), phân chia chúng thành ba nhóm: tĩnh (static), động (dynamic) và lai (hybric). Các ràng buộc tĩnh có thể được kiểm tra trước khi hoặc không cần sự hoạt động của workflow. Trong khi đó, việc kiểm tra các ràng buộc động đòi hỏi sự hoạt động của workflow, vì nó phụ thuộc vào lịch sử của hoạt động. Các ràng buộc lai là sự kết hợp của cả hai loại ràng buộc tĩnh và động. Từ những phân tích trên, một ngôn ngữ mới dựa trên chương trình logic (logic program) đã được giới thiệu, nhằm biểu diễn cho các loại ràng buộc. Tuy nhiên, các vấn đề ràng buộc liên quan đến môi trường lưới và dịch vụ lưới lại chưa được đề cập đến trong nghiên cứu này. Do đó, việc áp dụng ngôn ngữ này ra sao để giải quyết vấn đề trên dường như vẫn chưa rõ ràng. Nghiên cứu của luận án hướng đến giải quyết vấn đề này. Trong [104], mô hình ABAC (attribute-based access control) cho các Web services đã được giới thiệu. Một giả thiết cho mô hình là tất cả các thuộc tính là đơn trị (giá trị nguyên tố). Giả thuyết này chỉ đúng và phù hợp với các hệ thống đơn giản. Còn với các hệ thống phức tạp hơn, như các hệ thống lưới và hệ thống luồng công việc với rất nhiều các thuộc tính phức hợp, giả thuyết này không còn áp dụng được nữa. Chính vì vậy, một trong những mục tiêu trong mô hình của luận án là loại bỏ giả thuyết này, cho phép các thuộc tính nhận cả kiểu phức hợp. Một hạn chế nữa trong mô hình ABAC [104] là cách biểu diễn các quy tắc truy nhập. Trong mô hình, mỗi quy tắc được biểu diễn bằng công thức: can_access(s, r, e) ← f(Attr(s), Attr(r), Attr(e)) (4.2) trong đó: s, r, e tương ứng biểu diễn chủ thể, tài nguyên và yếu tố môi trường; Attr(c) là quan hệ gán giá trị cho thuộc tính của thành phần c, với c có thể là s, r hoặc e; f() là hàm logic. Ý nghĩa của quy tắc (4.2) là nếu giá trị của vế phải là TRUE, thì s có thể truy nhập vào r trong điều kiện e. Với cách biểu diễn này, nếu giá trị của f() là FALSE, vẫn chưa đảm bảo là s không thể truy nhập vào r. Điều này có nghĩa là quyết định cannot-access đòi hỏi phải kiểm tra toàn bộ các quy tắc trong hệ thống. Hơn nữa, quyết định can-access cũng đòi hỏi phải kiểm tra tất cả các quy tắc khác, chứ không chỉ kiểm tra một quy tắc. Do đó, cách biểu diễn quy tắc này, từ góc độ sử dụng, chưa được hiệu quả. Trong mô hình được đề xuất trong luận án, cách biểu diễn các quy tắc cũng đơn giản như mô hình trên, với chỉ một loại quy tắc. Luận án sử dụng loại quy tắc cannot-access(), thay vì loại quy tắc can-access() như mô hình trên. Cách biểu diễn này mặc dù nhìn qua tương tự như cách cũ, nhưng hiệu quả sử dụng tốt hơn nhiều. Với quyết định cannot-access, thì chỉ cần kiểm tra đúng một quy tắc. Còn quyết định can-access, vẫn phải kiểm tra tất cả các quy tắc như cách tiếp cận trên. Vấn đề về cách biểu diễn các quy tắc đã được bàn luận trong [83]. Các tác giả phát hiện có hai cách tiếp cận trong việc biểu diễn các quy tắc: - Chính sách đóng (Closed policy) (hay còn gọi là cấp quyền tích cực (positive authorization)): cách tiếp cận này đặc tả các cho phép truy nhập (permissions for 124 - an access). Một yêu cầu truy nhập được cho phép nếu tồn tại quy tắc cấp quyền tích cực cho nó. Còn trái lại thì nó sẽ bị từ chối. Chính sách mở (Open policy) (còn được gọi là cấp quyền thụ động (negative authorization)): cách tiếp cận này đặc tả các từ chối truy nhập (denials for an access). Một yêu cầu truy nhập sẽ bị từ chối nếu tồn tại một cấp quyền thụ động cho nó. Còn trái lại thì nó sẽ được cho phép. Cách tiếp cận kết hợp của hai phương pháp trên cũng được xem xét như một biện pháp thuận tiện để biểu diễn các quy tắc. Tuy nhiên, cách tiếp cận này đưa đến hai vấn đề: thứ nhất là sự không đầy đủ của các quy tắc (incompleteness of rules) và thứ hai là sự không nhất quán giữa các quy tắc (inconsistency among rules). Trong khi vấn đề thứ nhất có thể được giải quyết dễ dàng bằng giải pháp chấp nhận các cấp quyền mặc định (default authorization), vấn đề thứ hai lại phức tạp hơn nhiều (xem thêm trong [83]). Đó là nguyên nhân theo đó giải pháp kết hợp không được lựa chọn trong mô hình được xem xét trong luận án. Trong [55], các tác giả giới thiệu một mô hình ABAC mở rộng, được gọi là ABMAC (Attribute-Based Multipolicy Access Control). Tuy nhiên, sự phân biệt giữa hai thực thể Service và Resource chưa được rõ. Trong khi ở phần 3.2, hai thực thể này dường như khác nhau, trong phần 3.3, Service lại trở thành một bộ phận của Resource. Hơn nữa, chưa có thuộc tính nào cho các thực thể này được định nghĩa. Ngoài ra, định nghĩa các chính sách với các khái niệm như combine_f, Policy_i, f_policy dường như cũng chưa được rõ ràng và đủ chi tiết. Trong [47], một mô hình với tên gọi unified attribute-based access control (UABAC) đã được giới thiệu, nhằm thống nhất ba loại mô hình thông dụng: DAC, MAC and RBAC. Mặc dù mô hình này có hỗ trợ thuộc tính kiểu tập hợp, nhưng lại không hỗ trợ thuộc tính kiểu phức hợp. Với thuộc tính kiểu tập hợp, có thể chứa tập các giá trị, nhưng không chứa được tập các thuộc tính khác như kiểu phức hợp. Hơn nữa, mục đích sử dụng của mô hình này khác với mô hình được đề xuất. Trong khi mô hình này nhằm thống nhất các mô hình trước đó, mô hình trong luận án tập trung vào việc tích hợp các yêu cầu truy nhập của hệ thống workflow với hệ thống lưới. Thông thường không dễ để có được một mô hình "thống nhất" hoặc "đa dụng" thích hợp với mọi tình huống thực tế. Thông thường trong áp dụng, hệ thống thường bị mất đi phần nào tính đơn giản và hiệu quả hoạt động. Ví dụ trong mô hình UABAC, để giải quyết vấn đề biểu diễn các kiểu ràng buộc khác nhau trong các mô hình khác nhau, ba kiểu ràng buộc đã được đề xuất: ConstrSub đặc tả cho các ràng buộc trên thuộc tính của chủ thể; ConstrObj đặc tả cho các ràng buộc trên thuộc tính của đối tượng khi nó được tạo ra; và ConstrObjMod đặc tả cho các ràng buộc trên thuộc tính của đối tượng khi nó bị thay đổi. Cách phân loại này sẽ dẫn đến một vấn đề không đơn giản là làm thế nào biểu diễn được các ràng buộc kết hợp có các kiểu thuộc tính khác nhau, được sử dụng vào các thời điểm khác nhau. Trong khi đó, vấn đề này không tồn tại trong mô hình được đề xuất trong luận án, do chỉ chứa một kiểu quy tắc. 125 Bảng 4-6: So sánh các tính năng của mô hình CABAC và các mô hình khác. ERBAC [8] ABAC [104] Hỗ trợ lưới Không Không Có Không Có Hỗ trợ luồng công việc Có Không Không Không Có Hỗ trợ thuộc tính đơn Không Có Có Có Có Hỗ trợ thuộc tính phức Không Không Không Không Có Tính năng hỗ trợ ABMAC [55] UABAC [47] CABAC Kết quả so sánh giữa mô hình CABAC được đề xuất và các mô hình khác được trình bày trong Bảng 4-6. Nhìn vào bảng có thể thấy, mô hình cuaẩ luận án hỗ trợ cả bốn tính năng an ninh cần thiết cho khung cộng tác. 4.3.2.5 Kết luận về mô hình Mô hình điều khiển truy nhập được đề xuất trong luận án đã khắc phục các hạn chế của các mô hình trước đó và đáp ứng tốt hơn các yêu cầu an ninh trong môi trường lưới. Đồng thời, giúp giải quyết được vấn đề gọi dịch vụ lưới an toàn từ tiến trình BPEL trong G-ODE, đã đề cập ở phần cài đặt G-ODE. 4.3.3 Giải pháp tự động hóa quá trình khai thác tiến trình BPEL 4.3.3.1 Thiết kế Mục tiêu thiết kế Như đã được trình bày ở phần 1.4 của chương 1, để hỗ trợ việc tự động hóa quá trình khai thác tiến trình BPEL trong ODE, luận án đã xây dựng một công cụ phần mềm với các tính năng sau: - Tự động kiểm tra tính hợp lệ của tệp tiến trình BPEL và các tệp WSDL liên quan. Nếu tất cả các tệp này đều hợp lệ thì tệp deploy.xml cần thiết sẽ được tạo ra. Tự động thu thập các tệp cần thiết vào trong thư mục khai thác của ODE và khởi tạo quá trình biên dịch. Lọc và trả về chỉ các thông báo liên quan, hữu ích về các lỗi tiềm năng gắn với quá trình chuẩn bị và biên dịch. Đề xuất các giải pháp và các lý do có thể gây ra lỗi. Hỗ trợ việc tích hợp với trình soạn thảo BPEL. Nhiệm vụ chính công cụ là tiếp nhận ở đầu vào tệp tiến trình BPEL và các tệp WSDL liên quan (dùng để mô tả cho các dịch vụ Web được gọi), sau đó kiểm tra tính hợp lệ của các tệp này, và cuối cùng tạo ra ở đầu ra là tệp deploy.xml (nếu tất cả các tệp đều hợp lệ), 126 hoặc thông báo lỗi (nếu có tồn tại ít nhất một tệp không hợp lệ) (xem Hình 4-9 mô tả khái quát các chức năng này). Các tệp được coi là hợp lệ nếu chúng thỏa mãn các điều kiện sau: - - Tệp tiến trình BPEL chính tồn tại và nội dung của nó là hợp lệ. Để kiểm tra tính hợp lệ của nội dung này, công cụ được xây dựng trong luận án chỉ quan tâm đến phần khai báo và sử dụng các Partner Link. Còn việc kiểm tra và biên dịch nội dung của tệp BPEL là trách nhiệm của BPEL engine. Với mỗi activity , hay sử dụng một Partner Link trong tệp BPEL, đòi hỏi một tệp WSDL tương ứng biểu diễn cho Partner Link đó. Do đó, tệp WSDL này cần phải tồn tại và có chứa Partner Link đó. Hơn nữa, nó phải chứa thông tin hợp lệ về tên của service và port (service name and port name). BPEL Kiểm tra và tạo tệp deploy.xml deploy.xml WSDL Hình 4-9: Chức năng chính của công cụ Các chức năng của công cụ Các bước thực hiện chính của công cụ được mô tả trong Hình 4-10. - - - Bước 1: Kiểm tra các tệp. Bước này kiểm tra sự đầy đủ của các tệp cần thiết. Điều này có nghĩa là cần có tồn tại ít nhất một tệp BPEL và mỗi Partner Link trong tệp đó yêu cầu phải có ít nhất một tệp WSDL. Công cụ được xây dựng trong luận án chỉ cần có thư mục chứa tất cả các tệp. Nó sẽ tự động phát hiện tệp BPEL và từ tệp này sẽ kiểm tra các tệp WSDL liên quan. Nếu tất cả các tệp cần thiết đều tồn tại thì nó tiếp tục thực hiện bước tiếp theo. Trái lại nó sẽ thông báo lỗi và dừng lại. Bước 2: Thu thập tất cả các thông tin cần thiết cho tệp deploy.xml. Cấu trúc của tệp deploy.xml được giới thiệu trong Hình 4-11. Như đã chỉ ra trong Hình 4-10, bước này cần phải tìm kiếm và lấy ra tên tiến trình (process name) từ tệp BPEL và tất cả các thông tin liên quan đến từng Partner Link trong tiến trình như tên dịch vụ và tên cổng (service name and port name) trong các tệp WSDL. Bước này cũng giúp kiểm tra và tìm ra các lỗi thường gặp như thiếu Partner Link trong tệp BPEL, thiếu tên dịch vụ hay tên cổng trong tệp WSDL,v..v.. Nếu tất cả các thông tin cần thiết là hợp lệ thì nó sẽ chuyển sang bước tiếp theo. Trái lại, nó sẽ thông báo lỗi và dừng lại. Bước 3: Tạo tệp deploy.xml. Ghi tất cả các thông tin cần thiết từ bước 2 vào tệp deploy.xml. 127 1. Kiểm tra các tệp? Hợp lệ 2. Thu thập thông tin cần thiết 3. Tạo tệp deploy.xml 4. Hoàn thành việc khai thác Hình 4-10: Các bước thực hiện của công cụ Hình 4-11: Cấu trúc của tệp deploy.xml 128 - Bước 4: Hoàn thành việc khai thác bằng cách copy toàn bộ các tệp cần thiết vào thư mục khai thác. Thông thường, khi tất cả các tệp đã được tìm thấy trong thư mục này, ODE engine sẽ tự động phát hiện và biên dịch chúng. 4.3.3.2 Cài đặt Công cụ được xây dựng trong luận án được phát triển dưới dạng một chương trình JAVA. Để chạy chương trình này, yêu cầu có hai tham số, một tham số vào (input) là thư mục chứa tất cả các tệp cần thiết; một tham số ra là tệp deploy.xml nếu tất cả các tệp trong thư mục đầu vào là hợp lệ. Trái lại, nó sẽ hiện thông báo lỗi và giúp tìm nguyên nhân tại sao không thể tạo ra tệp deploy.xml. Để đọc và ghi các tệp BPEL và WSDL mà đều là các tệp có dạng XML, luận án đã sử dụng DOM API (Document Object Model) của JAVA. Thực ra, một loại API khác có thể được sử dụng cho mục đích này là SAX (Simply API for XML). Tuy nhiên, so với SAX, sử dụng DOM không những cho phép thay đổi nội dung của tệp, mà còn thực hiện nhanh và dễ dàng hơn. Đó là do với DOM, nội dung của tệp chỉ cần đọc một lần rồi được lưu vào bộ nhớ trong. Điều này cũng phù hợp với yêu cầu đối với công cụ được xây dựng trong luận án, đó là không cần phải đọc nội dung các tệp nhiều lần. Công cụ được xây dựng trong luận án đã được kiểm tra với một số chương trình BPEL khác nhau. Với chương trình mà tất cả các tệp là hợp lệ, công cụ đã tạo ra tệp deploy.xml hợp lệ thích hợp và giúp cho chương trình BPEL trở nên sẵn sàng cho việc khai thác và chạy. Công cụ hỗ trợ hai loại tệp WSDL: - - Loại tệp WSDL thông thường: loại tệp này chứa đầy đủ các thông tin về các Partner Link, service và port. Do đó, việc có được các thông tin là hoàn toàn dễ dàng thông qua việc chỉ cần đọc nội dung của một tệp. Loại tệp WSDL Wrap: đây là loại tệp mở rộng của kiểu WSDL thông thường. Loại tệp này trích ra phần Partner Link từ tệp WSDL thông thường và bao chúng trong một tệp WSDL mới. Tệp wrap này phải nhập (import) tệp WSDL thông thường. Trong trường hợp có lỗi trong quá trình chạy do có tệp chứa lỗi, công cụ được xây dựng trong luận án sẽ thông báo lỗi và tệp chứa lỗi. Trong phần tiếp theo, luận án sẽ giới thiệu một ví dụ cụ thể để minh họa việc sử dụng công cụ này. Trong ví dụ này, luận án đã phát triển một tiến trình BPEL (process) mà gọi một Web service từ bên ngoài của WeatherBug để lấy thông tin dự báo thời tiết trên thế giới. Nó được cài đặt bằng công cụ Netbeans 6.1. Hình 4-12 mô tả cấu trúc các tệp của ví dụ. 129 Hình 4-12: Cấu trúc của các tệp ví dụ. Tiến trình chính được chứa trong tệp main.bpel, có hai partner link: client và WeatherProvider. Workflow của tiến trình được minh họa trong Hình 4-13. Hình 4-13: Workflow của tiến trình trong ví dụ. Trong hai partner link này, client đại diện cho đối tượng sẽ sử dụng tiến trình (là các tiến trình khác hay các dịch vụ Web, v.v..), còn WeatherProvider đại diện cho dịch vụ Web bên ngoài từ WeatherBug. Có thể thấy rằng, có nhiều thao tác trong dịch vụ Web, nhưng trong ví dụ này chỉ sử dụng một thao tác GetLiveCompactWeatherByCityCode(), trả về thông tin thời tiết trực tuyến của một thành phố từ đầu vào là code của thành phố đó. Sau khi phát triển ví dụ trên, luận án đã dùng công cụ được xây dựng để khai thác nó trong Tomcat Apache phiên bản 5.5. Công cụ được xây dựng trong luận án cần có hai tham số: sourceDir là thư mục chứa toàn bộ tệp nguồn và destDir là thư mục chứa tiến trình được khai thác (nó thường là CATALINA_HOME\webapps\ode\WEB-INF\ processes). Sau khi chạy công cụ với ví dụ trên, khi không có lỗi nào được phát hiện, một tệp deploy.xml sẽ được tạo ra trong thư mục sourceDir, sau đó toàn bộ các tệp trong thư mục này sẽ được copy sang thư mục destDir, khi đó tiến trình đã sẵn sàng được sử dụng. Hình 130 4-14 mô tả danh mục các tệp sau khi công cụ của luận án được chạy. Như thấy trong hình, tệp deploy.xml đã được tạo ra. Hình 4-14: Tệp deploy.xml đã được tạo ra sau khi công cụ được chạy Cuối cùng, luận án sử dụng công cụ soapUI để kiểm tra tiến trình trong ví dụ. Kết quả chạy được thể hiện ở Hình 4-15. Bên cửa sổ bên trái là city code của thành phố Melbourne, Australia, đầu vào của tiến trình. Còn cửa sổ bên phải là thông tin thời tiết hiện tại của thành phố đó. Hình 4-15: Kết quả chạy ví dụ bằng công cụ soapUI. 4.3.3.3 Kết luận và hướng nghiên cứu tiếp theo Cho đến nay, công cụ được xây dựng trong luận án mới chỉ là một chương trình JAVA độc lập. Để hữu dụng hơn, công cụ cần được tích hợp đầy đủ trong khung cộng tác. Một số tính năng mới cũng cần phải được phát triển như: hỗ trợ một dự án có nhiều tệp BPEL, cũng 131 như hỗ trợ việc tìm và phát hiện nhiều loại lỗi hơn nữa trong quá trình phát triển các tiến trình. KẾT LUẬN CHƯƠNG Chương này đã trình bày các kết quả thiết kế và cài đặt khung cộng tác. Trong phần thiết kế, luận án đã đưa ra thiết kế ở cả hai mức sơ bộ và chi tiết. Dựa trên Mô hình Kế hoạch, khung cho phép nhiều người dùng có thể cùng phối hợp với nhau để xây dựng và xác định tính khả thi của các kế hoạch. Mục tiêu là cung cấp một khung lưới đa dụng hỗ trợ cho những công việc cộng tác, có thể được áp dụng trong nhiều lĩnh vực ứng dụng khác nhau. 132 KẾT LUẬN Các đóng góp khoa học của đề tài Các đóng góp khoa học trong nghiên cứu của luận án có thể được tóm tắt vào những nội dung chính như sau: 1. Hình thức hóa và phát triển Lý thuyết Hoạt động để hướng đến một mô hình biểu diễn một cách rõ ràng hơn về kế hoạch và cộng tác (gọi là Mô hình Kế hoạch). Một mặt, việc hình thức các khía cạnh trong Lý thuyết Hoạt động sẽ giúp làm rõ hơn các phần chưa rõ ràng, cũng như bổ sung thêm một số phần còn thiếu trong lý thuyết. Mặt khác, mô hình kế hoạch được đề xuất cũng cho phép kết nối thành tố trong Lý thuyết Hoạt động với kỹ thuật luồng công việc nhằm biểu diễn kế hoạch ở cả hai khía cạnh hình thức và trực quan. Mô hình cũng cho phép các kế hoạch có thể được biểu diễn, được làm mịn và cuối cùng được thực thi (có thể là thực thi tự động). Kết quả này đã được đăng trong [15][16]. 2. Xác định rõ các vấn đề còn tồn tại với các khung lưới cộng tác hiện nay, để từ đó đề xuất một khung lưới cộng tác mới có Hỗ trợ Kế hoạch thông qua việc kết nối những ý tưởng chính của Lý thuyết Hoạt động với tính toán lưới. Khung cho phép tạo mới hoặc cập nhật các kế hoạch có tính cộng tác. Mục tiêu là cung cấp khung lưới đa dụng hỗ trợ cho những công việc cộng tác có thể áp dụng trong nhiều lĩnh vực ứng dụng khác nhau. Một số modul chính của khung lưới cộng tác đã được cài đặt. Kết quả này đã được đăng trên [10][14][12]. 3. Trong quá trình làm mịn kế hoạch, đã phát hiện một số vấn đề còn tồn tại trong lĩnh vực dịch ngôn ngữ luồng, nhất là vấn đề chuyển từ ngôn ngữ hướng đồ thị sang ngôn ngữ hướng cấu trúc. Đã đề xuất giải thuật tìm ra các mẫu trong ngôn ngữ hướng đồ thị, chuyển nó sang các thành phần tương ứng trong ngôn ngữ hướng cấu trúc. Hai ngôn ngữ luồng đại diện là BPMN và BPEL đã được lựa chọn để minh họa cho giải thuật. Kết quả này đã được đăng trong [17]. 4. Xây dựng một mô hình điều khiển truy nhập mới, đáp ứng các yêu cầu truy nhập của cả hai hệ thống là hệ thống luồng công việc và hệ thống lưới. Được mở rộng từ mô hình điều khiển truy nhập dựa trên thuộc tính ABAC (attribute-based access control model), mô hình của chúng tôi hỗ trợ cả hai loại thuộc tính đơn và phức hợp. Ngoài ra, mô hình được đề xuất trong luận án cũng đáp ứng được cả hai yêu cầu thường mâu thuẫn nhau trong các hệ thống điều khiển truy nhập. Đó là yêu cầu về tính đơn giản của việc biểu diễn các quy tắc truy nhập và yêu cầu về tính đầy đủ về khả năng biểu diễn các quy tắc này. Một thiết kế chi tiết về cấu trúc modul của mô hình, tuân theo chuẩn XACML của các hệ thống điều khiển truy nhập, cũng đã được luận án đề xuất. 5. Đưa ra một giải pháp hoàn chỉnh cho việc tự động hóa khai thác tiến trình BPEL trong môi trường ODE. Giải pháp đã được cài đặt bằng JAVA và thử nghiệm thành 133 công với các loại tiến trình khác nhau. Ý nghĩa của giải pháp là cho phép những người phát triển các tiến trình BPEL tiết kiệm được rất nhiều thời gian và công sức trong việc cấu hình để khai thác các tiến trình BPEL. Kết quả này đã được đăng trong [11]. 6. Tìm hiểu rõ nguyên nhân của vấn đề không thể gọi được các dịch vụ lưới từ tiến trình trong môi trường ODE, từ đó đưa ra giải pháp hiệu quả, đơn giản và khả thi để giải quyết vấn đề này. Ý nghĩa của giải pháp là cho phép các dịch vụ lưới khác nhau có thể được kết hợp trong Grid/Workflows có cấu trúc sử dụng BPEL và được gọi thông qua cơ sở hạ tầng lưới nằm bên dưới. Điều đó ngầm chứa khả năng cho phép dãy các công việc phức tạp có thể được kết hợp và thực thi tự động trên môi trường tính toán lưới, thay vì chỉ thực hiện các yêu cầu tính toán lưới đơn giản. Kết quả này đã được đăng trên [9][13]. Các công trình đã công bố, các kết quả nghiên cứu của luận án đã được công bố trong sáu hội nghị khoa học quốc tế [11] [12] [13] [17] [15] [16] và ba tạp chí chuyên ngành [14] [9] [10]. Vai trò và mối quan hệ giữa các kết quả nghiên cứu của luận án đối với quá trình phát triển khung cộng tác được biểu diễn tóm tắt trong hình vẽ dưới đây. Trong hình này, phần trung tâm là kiến trúc tổng quan của khung cộng tác (đã được mô tả trước đây ở Hình 2-23), các mô tả ở xung quanh là tóm tắt các kết quả nghiên cứu, và các mũi tên nét đứt biểu diễn vai trò của kết quả nghiên cứu với bộ phận của khung cộng tác. Tổng quan về các kết quả đã đạt được của luận án. 134 Hạn chế của đề tài và hướng nghiên cứu tiếp theo Mặc dù đã hết sức cố gắng, nhưng luận án vẫn còn một số vấn đề cần giải quyết để có thể đạt đến một hệ thống hoàn chỉnh. Các vấn đề này bao gồm: 1. Mô hình kế hoạch đã được đề xuất chưa hoàn chỉnh: mô hình còn chưa giải quyết vấn đề khái quát hóa kế hoạch. Vấn đề tự động suy diễn các kế hoạch mới từ các kế hoạch hiện có cũng là vấn đề thú vị mà mô hình chưa đề cập đến. 2. Thiếu một công cụ hoàn chỉnh để dịch các kế hoạch viết bằng BPMN sang BPEL, từ đó có thể tự động hóa việc thực thi các kế hoạch. Nghiên cứu mới dừng lại ở việc đề xuất một giải thuật, nhưng còn thiếu cài đặt để đánh giá về mặt thực tế khả năng áp dụng của giải thuật. 3. Thiếu cài đặt đầy đủ cho toàn bộ khung cộng tác, nên chưa thể đưa nó áp dụng vào các nghiệp vụ thực tế. Việc giải quyết các vấn đề còn tồn tại ở trên là các nội dung nghiên cứu hy vọng có thể tiến hành trong tương lai. 135 DANH MỤC CÁC CÔNG TRÌNH ĐÃ CÔNG BỐ CỦA LUẬN ÁN 1. Binh Thanh Nguyen and Doan Bang Hoang (2008), “Building a Plan-Supported Grid Collaborative Framework”, In 2nd International Cenference on Communications and Electronics (ICCE 2008), Golden Sand Resort, Hoi An City, Vietnam, pages 150-155. 2. Binh Thanh Nguyen and Doan B Hoang (2009), “An automatic tool for deployment of BPEL processes in ODE Apache”, The 2009 International Conference on e-Learning, eBusiness, Enterprise Information Systems, and e-Government, Monte Carlo Resort, Las Vegas, USA, pages 248-253. 3. Binh Thanh Nguyen, Doan Bang Hoang, and Thuy Thanh Nguyen (2011), “Enabling Grid Services from BPEL process using ODE engine”, In ICCSIT 2011, Chengdu, China, pages 291-295. 4. Binh Thanh Nguyen, Duc Huu Nguyen and Doan Bang Hoang (2012), Towards A Grid Collaborative Framework, International Journal of Machine Learning and Computing (IJMLC), Vol 2(2), pages 99-106. 5. Binh Thanh Nguyen, Duc Huu Nguyen, and Thuy Thanh Nguyen (2012), G-ODE, an extension of the Apache ODE for grid services, Journal of Computer Science and Cybernetics, Vol 28(3), pages 245-259. 6. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2014), “Translation from BPMN to BPEL, current techniques and limitations”, In Proceedings of the Fifth Symposium on Information and Communication Technology - SoICT 2014, Hanoi, Vietnam, pages 21-30. 7. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2014), “A Formalism of Activity Theory”, In The 2nd KICS Korea-Vietnam International Workshop on Information and Communications, HaNoi, Vietnam, pages 41-45. 8. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2015), “Plan Model An Activity Theory Based Approach”, accepted by SOICT 2015, Hue, Vietnam, December 3-4 2015. 9. Binh Thanh Nguyen, Duc Huu Nguyen, Thuy Thanh Nguyen, and Doan Bang Hoang (2016), Design of a Workflow-based Grid Framework, International Journal of Computer Theory and Engineering, Vol 8(1), pages 14-23. 136 TÀI LIỆU THAM KHẢO 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Allen. J (1984), Towards a general theory of action and time, Artificial Intelligence, Vol 23(2), pages 123-154. Alonso Gustavo, Agrawal Divyakant, Amr El Abbadi and Carl Mohan (1997), Functionality and Limitations of Current Workflow Management Systems, IEEE Expert Intelligent Systems And Their Applications, Vol 12(5), pages: 25. Arthur H. M, Van Der Aalst, Chun Ouyang, Marlon Dumas and Wil M P (2008), Pattern-Based Translation of BPMN Process Models to BPEL Web Services, International Journal of Web Services Research, Vol 5(1), pages 42-62. Apache Software Foundation (2012), Apache Axis2 - Architecture Guide at http://ws.apache.org/axis2/1_5/Axis2ArchitectureGuide.html. Ball Thomas Ball (1993), What is in a Region? or Computing control dependences in nearlinear time for reducible control flow, ACM Letters on Programming Languages and Systems, Vol 1(December), pages 1-16. Bannon, L. and Hughes, J.A (1993), The context of CSCW, In Developing CSCW systems: Design Concepts, Report of COST 14 “CoTech” WG4, Denmark, pages 936. Bellettini Carlo, Elisa Bertino, and Elena Ferrari (2001), Role Based Access Control Models, Information Security Technical Report, Vol 6(2), pages 38-47. Bertino Elisa, Elena Ferrari, and Vijay Atluri (1999), The specification and enforcement of authorization constraints in workflow management systems, ACM Transactions on Information and System Security, Vol 2(1), pages 65-104. Binh Thanh Nguyen, Duc Huu Nguyen, and Thuy Thanh Nguyen (2012), G-ODE, an extension of the Apache ODE for grid services, Journal of Computer Science and Cybernetics, Vol 28(3), pages 245-259. Binh Thanh Nguyen, Duc Huu Nguyen, Thuy Thanh Nguyen, and Doan Bang Hoang (2016), Design of a Workflow-based Grid Framework, International Journal of Computer Theory and Engineering, Vol 8(1), pages 14-23. Binh Thanh Nguyen and Doan B Hoang (2009), “An automatic tool for deployment of BPEL processes in ODE Apache”, The 2009 International Conference on e-Learning, e-Business, Enterprise Information Systems, and e-Government, Monte Carlo Resort, Las Vegas, USA, pages 248-253. Binh Thanh Nguyen and Doan Bang Hoang (2008), “Building a Plan-Supported Grid Collaborative Framework”, In 2nd International Cenference on Communications and Electronics (ICCE 2008), Golden Sand Resort, Hoi An City, Vietnam, pages 150155. Binh Thanh Nguyen, Doan Bang Hoang, and Thuy Thanh Nguyen (2011), “Enabling Grid Services from BPEL process using ODE engine”, In ICCSIT 2011, Chengdu, China, pages 291-295. 137 14. Binh Thanh Nguyen, Duc Huu Nguyen and Doan Bang Hoang (2012), Towards A Grid Collaborative Framework, International Journal of Machine Learning and Computing (IJMLC), Vol 2(2), pages 99-106. 15. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2014), “A Formalism of Activity Theory”, In The 2nd KICS Korea-Vietnam International Workshop on Information and Communications, HaNoi, Vietnam, pages 41-45. 16. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2015), “Plan Model - An Activity Theory Based Approach”, accepted by SOICT 2015, Hue, Vietnam, December 3-4 2015. 17. Binh Thanh Nguyen, Duc Huu Nguyen and Thuy Thanh Nguyen (2014), “Translation from BPMN to BPEL, current techniques and limitations”, In Proceedings of the Fifth Symposium on Information and Communication Technology - SoICT 2014, Hanoi, Vietnam, pages 21-30. 18. Blox Jeroen (2009), BPMN 2 BPEL - research on mapping BPMN to BPEL, PhD thesis, Eindhoven University of Technology. 19. Bradram J. E (1997), “Plans as situated actions: An activity theory approach to workflow systems”, In Proceedings of the 5th European Conference on Computer Supported Collaborative Work, Lancaster, UK, pages 17-32. 20. Bradram J. E (1998). Collaboration, Coordination and Computer Support - An Activity Theoretical Approach to the Design of CSCW, PhD thesis, Aarhus University. 21. Bradram J. E (2009), Activity-based computing for medical work in hospitals, ACM Transactions on Computer-Human Interaction, Vol 16(2), pages 1-36. 22. Bradram J. E, Jonathan Bunde-Pedersen, and Mads Soegaard (2006), “Support for activity-based computing in a personal computing operating system”, In Proceedings of the SIGCHI conference on Human Factors in computing systems - CHI ’06, New York, USA, pages 211-220. 23. BonitaSoft (2011), Bonita Open Solution 5.4 User & Reference Guide at www.BonitaSoft.com. 24. Carla Simonee and Kjeld Schmidt (1996), Coordination mechanisms: Towards a conceptual foundation of CSCW systems design, Journal of Collaborative Computing, Vol 5(2-3), pages 155-200. 25. Cabitza Federico and Carla Simone (2013), Computational Coordination Mechanisms: A tale of a struggle for flexibility, Computer Supported Cooperative Work (CSCW), Vol 22(4-6), pages 475-529. 26. Cybok Dieter (2006), A Grid workflow infrastructure, Concurrency and Computation: Practice and Experience, Vol 18(10), pages 1243-1254. 27. David De Roure, Baker M. A, Nicholas R. Jennings and Nigel R. Shadbolt (2003), The evolution of the Grid, John Wiley & Sons, Chichester. 28. Doux Guillaume, Frédéric Jouault, and Jean Bézivin (2009), "Transforming BPMN process models to BPEL process definitions with ATL", In: GraBaTs 2009: 5th International Workshop on Graph-Based Tools, Zurich, pages: 8. 138 29. Evaluation Working Group of The DARPA Intelligent Collaboration and Visualization Program (1997), Methodology for Evaluation of Collaboration Systems, at http://zing.ncsl.nist.gov/nist-icv/documents/method.html. 30. El-Ghazawi Tarek, Kris Gaj, Nikitas Alexandridis, Frederic Vroman, Nguyen Nguyen, Jacek R. Radzikowski, Preeyapong Samipagdi, and Suboh A. Suboh (2004), A performance study of job management systems, Concurrency and Computation: Practice and Experience, Vol 16(13), pages 1229-1246. 31. Eshuis R. I and Paul Grefen (2009), Composing services into structured processes, International Journal of Cooperative Information Systems, Vol 18(2), pages 309-337. 32. Engestrom Y (1987), Learning by Expanding: An activity theoretical approach to development research, Helsinki: OrientaKonsultit Oy. 33. Frank Leymann, Dieter Roller, and Satish Thatte (2003), Goals of the BPEL4WS Specification, Technical report. 34. Fichtner B (1984), Co-ordination, co-operation and communication in formation of theoretical concepts in instruction, Aarhus: Aarhus University, Psykologisk Institut. 35. Foster Ian and Carl Kesselman (2004), The Grid2: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, USA. 36. Foster Ian (2006), Globus Toolkit Version 4: Software for Service-Oriented Systems, Computer Science & Technology, Vol 21(4), pages 513-520. 37. Fahringer Thomas, Sabri Pllana, Alex Villazon, Marian Bubak, Geert van Albada, Peter Sloot, and Jack Dongarra (2004), A-GWL: Abstract Grid Workflow Language, Computational Science – ICCS, Vol 3038, pages 42-49. 38. Francois J. N, Cosquer Sacha Krakowiak and Loic Decloedt (2002), Support for Distributed CSCW Applications, Lecture Notes in Computer Science, Vol 1752, pages 295-326. 39. Frey James, Todd Tannenbaum, Miron Livny, Ian Foster, and Steven Tuecke (2002), Condor-G: A Computation Management Agent for Multi-Institutional Grids, Cluster Computing, Vol 5(3), pages 237-246. 40. Held Markus (2008), “Collaborative BPEL Design with a Rich Internet Application”, Cluster Computing and the Grid (CCGrid), 8th IEEE International Symposium on, pages 202-209. 41. Henderson Robert (1995), “Job scheduling under the Portable Batch System”, IPPS '95 Proceedings of the Workshop on Job Scheduling Strategies for Parallel Processing, London, UK. 42. Hock Beng Lim, Protik Mukherjee, Vinh T. Lam , Weng F. Wong and Simon See (2005), “Sensor Grid: Integration of Wireless Sensor Networks and the Grid”, The IEEE Conference on Local Computer Networks 30th Anniversary, Sydney, pages 9198. 43. Hollingsworth David (1995), The Workflow Reference Model (Technical report TC001003), The Workflow Management Coalition (WfMC). 139 44. Huedo Eduardo, Rub. S. Montero and Ignacio Mart (2005), The Grid-Way Framework for Adaptive Scheduling and Execution on Grids, Scientific International Journal for Parallel and Distributed Computing , Vol 6(3), pages 1-8. 45. Ian Foster, Jeffrey Frey, Steve Graham, Steve Tuecke, Karl Czajkowski, Don Ferguson, Frank Leymann, Martin Nally, Igor Sedukhin, David Snelling, Tony Storey, William Vambenepe and Sanjiva Weerawarana (2004), Modeling Stateful Resources with Web Services version 1.1, Technical report. 46. JBoss Community, jBPM at http://www.jboss.org/jbpm. 47. Jin Xin, Ram Krishnan and Ravi Sandhu (2012), A unified attribute-based access control model covering DAC, MAC and RBAC, Springer, Vol 7371, pages 41-55. 48. Johnson Donald (1975), Finding all the elementary circuits of a directed graph, SIAM Journal on Computing, Vol 4(1), pages 77-84. 49. Johnson Richard, David Pearson and Pingali Keshav (1994), The program structure tree: computing control regions in linear time, SIGPLAN Not, Vol 29(6), pages 171185. 50. Jonassen David and Lucia Rohrer-Murphy (1999), Activity theory as a framework for designing constructivist learning environments, Educational Technology Research and Development, Vol 47(1), pages 61-79. 51. Kari Kuutti (1995), Activity Theory as a potential framework for human- computer interaction research, Massachusetts Institute of Technology Cambridge, USA. 52. Kesselman Carl, Ian Foster and Steven Tuecke (2001), The Anatomy of the Grid: Enabling Scalable Virtual Organizations, International Journal of High Performance Computing Applications, Vol 15(3), pages 200-222. 53. Kishimoto H, Ian Foster, A. Savva , D. Berry , A. Djaoui , A. Grimshaw , B. Horn , F. Maciel , F. Siebenlist , R. Subramaniam , J. Treadwell and J. Von Reich (2006), The Open Grid Services Architecture version 1.5, Technical report. 54. Lanzén Anders and Tom Oinn (2008), The Taverna Interaction Service: enabling manual interaction in workflows, Bioinformatics, Vol 24(8), pages 1118-1120. 55. Lang Bo, Ian Foster, Frank Siebenlist, Rachana Ananthakrishnan, and Tim Freeman (2009), A Flexible Attribute Based Access Control Method for Grid Computing, Journal of Grid Computing, Vol 7(2), pages 169-180. 56. Laszewski G, K. Amin and S. Nijsure (2002), "Open Collaborative Grid Service Architecture", EuroWeb'02 Proceedings of the 2002 international conference on EuroWeb, UK, pages 101-107. 57. Lengauer Thomas and Endre Robert Tarjan (1979), A Fast Algorithm for Finding Dominators in a Flowgraph, ACM Transactions on Programming Languages and Systems, Vol 1(1), pages 121-141. 58. Leont’ev A. N (1978). Activity, consciousness, and personality, Prentice-Hall, USA . 59. Litzkow M.J, M. Livny and M.W. Mutka (1988), “Condor-a hunter of idle workstations”, The 8th International Conference on Distributed, IEEE Comput, pages 104-111. 140 60. Lisa Childers and Borja Sotomayor (2006), Globus Toolkit 4: Programming Java Services. Morgan Kaufmann, USA. 61. Lowry Edward and Cleburne W Medlock (1969), Object code optimization, Communications of the ACM, Vol 12(1), pages 13-22. 62. Marjorie Bardeen, Eric Gilbert, Thomas Jordan, Paul Nepywoda, Elizabeth Quigg, Mike Wilde and Yong Zhao (2006), “The QuarkNet/Grid Collaborative Learning eLab”, Future Generation Computer Systems,Vol 22(6), pages 700-708. 63. Mathias Weske and Gottfried Vossen (1998), Workflow languages, Springer Berlin Heidelberg. 64. Melbourne Health (2012), Collaborative Framework 2012 – 2017, at http://www.mh.org.au/collaborative-framework-2012-2017/w1/i1017370/. 65. Mendling Jan, Kristian Bisgaard Lassen and Uwe Zdun (2006), Transformation strategies between block-oriented and graph-oriented process modelling languages, Technical report. 66. M. Robinson (1993). Common artefacts in the design of computer support for collaborative work. In Developing CSCW systems: Design Concepts, CoTech WG4. 67. Miguel L. Bote-Lorenzo, Eduardo Gomez-Sanchez, Guillermo Vega-Gorgojo, Yannis Dimitriadis, Juan I. Asensio-Perez and Ivan M. Jorrin-Abellan (2008), Gridcole: A tailorable grid service based system that supports scripted collaborative learning, Computers and Education, Vol 51(1), pages 155-172. 68. OASIS, Diane Jordan and John Evdemon (2009), Web Services Business Process Execution Language, Technical report. 69. Object Management Group (2006), Business Process Modeling Notation (BPMN) Version 1.0, Technical report. 70. Object Management Group (2011), Business Process Model and Notation (BPMN) Version 2.0, Technical Report January. 71. Onyeka Ezenwoye, S. Masoud Sadjadi, Ariel Cary and Michael Robinson (2007), Grid Service Composition in BPEL for Scientific Applications, Lecture Notes in Computer Science, Vol (4804), pages 1304-1312. 72. Onyeka Ezenwoye, S. Masoud Sadjadi, Ariel Cary and Michael Robinson (2007), Orchestrating WSRF-based Grid Services, Technical report. 73. Ouyang Chun, Van Der Aalst, M P Wil and H M Arthur (2009), From business process models to process-oriented software systems: The BPMN to BPEL way, ACM Transactions on Software Engineering and Methodology, Vol 19(1), pages 1-37. 74. Ouyang Chun, Marlon Dumas, Stephan Breutel and Arthur H M Hofstede (2006), “Translating Standard Process Models to BPEL. In Advanced Information Systems Engineering”, 18th International Conference (CAiSE 2006), Luxembourg, pages 417432. 75. ODE Apache, version 1.3.5 (2011), at http://ode.apache.org/. 76. Papakhian M (1998), Comparing job-management systems: the user’s perspective, IEEE Computational Science and Engineering, Vol 5(2), pages 4-9. 141 77. Paul WPurdom Jr and Edward F Moore (1972), Immediate predominators in a directed graph, Communications of the ACM, Vol 15(8), pages 777-788. 78. Papazoglou Michael, Joachim W Schmidt, John Mylopoulos, Wil Van Der Aalst and Kees Max Van Hee (2002), Workflow Management Models , Methods , and Systems, MIT press. 79. Recker Jan and Jan Mendling (2006), “On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages”, In The 18th International Conference on Advanced Information Systems Engineering. Proceedings of Workshops and Doctoral Consortium, Namur University Press. 80. Rodden, T. (1991), A survey of CSCW systems, Interacting with Computers, Vol 3(3), pages 319-353. 81. Rubio-Montero A. J, E. Huedo, R.S. Montero and I.M. Llorente (2007), “Management of Virtual Machines on Globus Grids Using GridWay”, IEEE International Parallel and Distributed Processing Symposium, pages 1-7. 82. Sabri Pllana, Jun Qin, and Thomas Fahringer (2005), “Teuta: A Tool for UML Based Composition of Scientific Grid Workflows”, In: First Austrian Grid Symposium, OCG, pages: 12. 83. Sabrina De Capitani Di Vimercati, Sara Foresti, Pierangela Samarati and Sushil Jajodia (2007), Access Control Policies and Languages, International Journal of Computational Science and Engineering, Vol 3(2), pages 94-102. 84. Samarati Pierangela and Sabrina De Capitani Di Vimercati (2001), Access Control: Policies, Models, and Mechanisms, In Foundations of Security Analysis and Design, vol 2171, pages 137-196. 85. SoapUI (2010), SoapUI Tool at http://www.soapui.org/. 86. Solaiman B (2001), “Medical decision-making and collaborative reasoning”, In Proceedings of the IEEE 2nd International Symposium on Bioinformatics and Bioengineering Conference, pages 161-165. 87. Sotomayor Borja (2005), The Globus Toolkit 4 Programmer’s Tutorial. 88. Stan Bhagyavati, Stan Kurkovsky and Arris Ray (2004), “A collaborative problemsolving framework for mobile devices”, In ACM-SE 42: Proceeding of the 42nd. Annual Southeast Regional Conference, New York, pages 5-10. 89. Suchman Lucy (1987), Plans and situated actions: The problem of human-machine communication, Cambridge University. 90. Tarjan Robert (1973), Enumeration of the elementary circuits of a directed graph, SIAM Journal on Computing, Vol 2(3), pages 211-216. 91. Tarjan Robert and Loukas Georgiadis (2004), “Finding dominators revisited”, In Proceedings of the fifteenth annual ACM-SIAM symposium on Discrete algorithms, Society for Industrial and Applied Mathematics. 92. Taverna (2012), Pack: Taverna 2.3 starter pack at http://www.myexperiment.org/packs/192.html. 93. The Globus Security Team (2005), Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective, Technical report. 142 94. Thomas Friese, Matthew Smith, Bernd Freisleben, Julian Reichwald, Thomas Barth and Manfred Grauer (2006), Collaborative Grid Process Creation Support in an Engineering Domain, Lecture Notes in Computer Science, Vol 4297, pages 263-276. 95. Thomas Friese, T. Dornemann, S. Herdt and Bernd Freisleben (2007), “Grid Workflow Modelling Using Grid-Specific BPEL Extensions”, In: Proceedings of German e-Science Conference, pages: 9. 96. Unified Modeling Language (UML) at http://www.uml.org/. 97. Von Gregorn Laszewski (2002), GSFL: A Workflow Framework for Grid Services. 98. W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski and A P Barros (2003), Workflow Patterns, Distributed and Parallel Databases, Vol 14(1), pages 5-51. 99. White Stephen (2006), Introduction to BPMN. IBM Corporation. 100. Wikipedia, BPMN Tools at http://en.wikipedia.org/wiki/Comparison_of_Business_Process_Modeling_Notation_tools. 101. W3C Working Group (2004), Web Services Architecture at http://www.w3.org/TR/ws-arch/, Technical report. 102. WMP van der Aalst, Weske Mathias and Wirtz Guido (2003), Advanced Topics In Workflow Management: Issues, Requirements and Solutions, Journal of Integrated Design & Process Science, Vol 7(3), pages 49-77. 103. Yu Jia and Rajkumar Buyya (2006), A Taxonomy of Workflow Management Systems for Grid Computing, Journal of Grid Computing, Vol 3(3-4), pages 171-200. 104. Yuan Eric and Jin Tong (2005), “Attributed based access control (ABAC) for web services”, ICWS '05 Proceedings of the IEEE International Conference on Web Services, Washington, USA, pages 74-79. 105. Yushun Li, Shengwen Yang, Jinlie Jiang and Meilin Shi (2006), Build Grid-enalbled large-scale Collaboration Environment in e-Learning Grid, Computer Supported Cooperative Work in Design and Manufacturing, Vol 31, pages 742-754. 106. Xianlong Jin, Zhi Li Yuan Cao, Xiaoyun Zhang and Yuanyin Li (2007), Architecture of collaborative design grid and its application based on LAN, Advances in Engineering Software, Vol 38(2), pages 121-132. 143 PHỤ LỤC A: TÍNH TOÁN LƯỚI A.1 Kiến trúc hướng dịch vụ Kiến trúc hướng dịch vụ (Service Oriented Architecture - SOA) là một giải pháp hoàn chỉnh để giải quyết ba vấn đề thách đố mà cộng đồng doanh nghiệp và khoa học đã phải đối mặt: sự không đồng nhất, sự tương thông và các yêu cầu luôn thay đổi. Hành vi của kiến trúc này có thể được biểu diễn trong Hình A-4, với ba thành phần tham gia: nhà cung cấp dịch vụ, điểm đăng ký dịch vụ và người dùng dịch vụ. Đầu tiên, một dịch vụ được một nhà cung cấp dịch vụ xây dựng, sau đó họ phát hành dịch vụ đó cho điểm đăng ký dịch vụ. Sau này, khi một người dùng cần một dịch vụ thì họ sẽ yêu cầu điểm đăng ký dịch vụ tìm cho họ xem dịch vụ đó có tồn tại hay không, và nếu có thì làm thế nào để có được nó. Cuối cùng, nếu dịch vụ đó được tìm thấy, thì các thông tin liên quan đến dịch vụ sẽ được gửi về cho người dùng đó, và dựa trên thông tin này mà người đó có thể gọi dịch vụ đó mà đang được quản lý bởi nhà cung cấp dịch vụ. Do đó, mục tiêu chính của kiến trúc này là phát triển và khai thác các dịch vụ ứng dụng, là các thành phần phần mềm có ba đặc trưng sau: - Tính gắn kết lỏng lẻo Sự trong suốt về vị trí Sự độc lập với giao thức Hình A-1: Kiến trúc Hướng Dịch Vụ. A.2 Dịch vụ WEB A.2.1 Định nghĩa Sau đây là một định nghĩa khá chính thức về dịch vụ Web được trích dẫn từ [101]: “Một dịch vụ WEB là một hệ thống phần mềm được thiết kế để hỗ trợ sự tương tác tương thông giữa máy tính với máy tính (interoperable machine-to-machine interaction) qua mạng máy tính. Nó có một giao diện được mô tả dưới một định dạng mà máy tính có thể xử lý được (đặc biệt là WSDL)” [101]. A.2.2 Kiến trúc (Architecture) 144 Kiến trúc phân tầng của Dịch vụ WEB được biểu diễn trong Hình A-2 [101]. Các chức năng của mỗi tầng như sau: - - - - Tầng Tiến trình: một tiến trình là sự kết hợp của nhiều dịch vụ WEB. Do đó, tầng này nói chung bao gồm một tập hợp các dịch vụ WEB. Ví dụ dịch vụ WEB “khám phá” cho phép tìm kiếm một dịch vụ WEB cần thiết từ tập các dịch vụ WEB. Trong khi đó, các dịch vụ WEB choreography and aggregation nhằm tạo ra các dịch vụ WEB mới bằng cách kết hợp các dịch vụ đã có. Tầng Mô tả: tầng này cần có một ngôn ngữ mà có thể mô tả các dịch vụ WEB mà máy tính có thể hiểu được. Web Services Description Language (WSDL) là ngôn ngữ đã được chọn bởi vì nó đáp ứng được các yêu cầu về mô tả các dịch vụ WEB. Thông qua việc đọc một tệp WSDL của một dịch vụ WEB, máy tính có thể hiểu các thao tác nào mà dịch vụ này hỗ trợ, cũng như cách gọi các thao tác đó như thế nào. Tầng Thông báo: tầng này nhằm hiện thực hóa việc gọi các thao tác trong tầng mô tả bởi việc gửi các thông báo giữa các máy. Giao thức SOAP (Simple Object Access Protocol) đã được thiết kế cho tầng này. Nó đặc tả các định dạng của các thông báo yêu cầu và các các thông báo trả lời được trao đổi giữa client và server. Tầng Truyền thông: Tầng này quan tâm đến việc truyền thông báo giữa các client và các server. Giao thức HTTP (HyperText Transfer Protocol) là lựa chọn chủ yếu cho tầng này, mặc dù về mặt lý thuyết thì các giao thức khác cũng có thể được sử dụng. Hình A-2: Kiến trúc Dịch Vụ Web. A.3 Web Service Resource Framework (WSRF) và Grid Services Chuẩn WSRF là một sự cải tiến và thay thế cho chuẩn OGSI (Open Grid Services Infrastructure) mà là một sự mở rộng của WSDL và XML Schema. OGSI cho phép sự mô hình hóa và quản lý các dịch vụ WEB có trạng thái, nhưng nó lại có một số hạn chế như quá 145 cứng nhắc và không mềm dẻo. WSRF nhằm khắc phục các hạn chế này. Trong hạ tầng lưới, các dịch vụ WEB có trạng thái cũng còn được gọi là các dịch vụ lưới. Trước khi xuất hiện các dịch vụ lưới, dịch vụ Web bị coi như một dịch vụ cô lập với mỗi thể hiện của nó hoàn toàn độc lập với các thể hiện khác của chính nó, bởi vì chúng không lưu giữ thông tin gì về trạng thái của bản thân chúng khi chúng mang nhưng kết quả đầu ra đến cho các Web client được yêu cầu. Tính không trạng thái này của dịch vụ Web làm cho mô hình client-server của chúng trở nên đơn giản. Tuy nhiên, việc phát triển các dịch dụ có tính giao tác dựa trên các dịch vụ Web đòi hỏi những thao tác phức tạp về trạng thái cố kết ở phía đầu server, và điều này không nhất quán với bản tính không trạng thái của dịch vụ Web. Vì lý do này, mà tổ chức OASIS đã chấp nhận Web Service Resource Framework (WSRF), một chuẩn mà cho phép các dịch vụ Web truy nhập vào các trạng thái cố kết của chúng theo một cách nhất quán và tương kết. Trong WSRF thì một trạng thái được gọi là tài nguyên trạng thái. WSRF nhằm mô hình hóa và quản lý các tài nguyên trạng thái dựa trên một cấu trúc được gọi là tài nguyên dịch vụ Web (WS-Resource), mà bao gồm một dịch vụ Web và các tài nguyên trạng thái gắn với nó [45]. WSRF định nghĩa các biện pháp nhờ đó: - Tài nguyên dịch vụ Web có thể được tạo ra và hủy bỏ Một tài nguyên trạng thái được sử dụng khi có sự trao đổi thông báo của dịch vụ Web được thực thi Một tài nguyên trạng thái có thể được truy vấn và bị thay đổi nhờ sự trao đổi thông báo của dịch vụ Web. Mỗi tài nguyên trạng thái thường có nhiều thể hiện độc lập mà chúng có thể được tạo ra và tiêu hủy. Khi một thể hiện mới của một tài nguyên trạng thái được tạo ra, thường là do một dịch vụ Web được gọi với cái tên là nhà sản xuất tài nguyên (resource factory), nó có thể được gán cho một định danh (identity - ID) (cũng còn được gọi là khóa tài nguyên). WSRF định nghĩa một loại quan hệ đặc biệt, được gọi là mẫu tài nguyên ngầm định, giữa một dịch vụ Web và các tài nguyên trạng thái của nó. Quan hệ này là một cơ chế nhằm gắn kết một tài nguyên trạng thái với việc thực thi sự trao đổi thông báo của dịch vụ Web. Thuật ngữ ngầm định có nghĩa là một tài nguyên trạng thái gắn kết với một trao đổi thông báo cho trước được coi như một đầu vào ngầm định cho việc thực thi yêu cầu thông báo. Đầu vào ngầm định có nghĩa là tài nguyên trạng thái này không được cung cấp như một tham số đầu vào tường minh trong thân của yêu cầu thông báo. Do đó, sự gắn kết này chủ yếu được thực hiện theo một cách động, tức là được thực hiện vào thời gian thực thi sự trao đổi thông báo [45]. Để biểu diễn địa chỉ của một dịch vụ Web được khai thác tại một điểm cuối cho trước của mạng, WSRF sử dụng cấu trúc Endpoint Reference (EPR) (Tham chiếu Điểm cuối) từ chuẩn WS-Addressing. Thành phần chính của một tham chiếu điểm cuối là một địa chỉ điểm cuối của dịch vụ Web. Tham chiếu điểm cuối cũng có thể chứa một metadata gắn với dịch 146 vụ Web đó, như các thông tin mô tả dịch vụ và các thuộc tính tham chiếu (tên này được dùng trong phiên bản 1.1 của WSRF. Trong phiên bản 1.2 đã được đổi thành các tham số tham chiếu). Các thuộc tính tham chiếu đóng một vai trò quan trọng trong mẫu tài nguyên ngầm định, vì nó được sử dụng để lưu giữ khóa tài nguyên của một thể hiện của tài nguyên trạng thái. Dịch vụ lưới là dịch vụ Web mà tuân theo chuẩn WSRF. Chúng cũng còn được gọi là dịch vụ Web tương thích với WSRF (WSRF-compatible Web services). A.4 Chương trình lập lịch Các chương trình lập lịch là một phần của phần sụn lưới mà chịu trách nhiệm lập lịch cho các công việc/chương trình cần được thực thi. Các chức năng chính của một chương trình lập lịch gồm có: - - - Gửi và giám sát công việc: chức năng này bao gồm gửi công việc từ một nút đến các nút mà sẽ có thể thực thi công việc; sau đó giám sát và kiểm soát trạng thái của các công việc đang được thực thi. Quản lý tài nguyên: chức năng này cho phép chương trình lập lịch có thể truy nhập, tìm và cấp phát các tài nguyên cần thiết để thực thi các công việc. Các tài nguyên có thể là tính toán, bộ nhớ, dữ liệu hoặc phần mềm. Tiến hành so khớp: đây là quá trình cố gắng tìm ra các tài nguyên phù hợp nhất trong số các tài nguyên sẵn có để thực thi các công việc. Hiện nay, có nhiều chương trình lập lịch đã được phát triển cho phần sụn lưới như Condor [59][39], GridWay [44] [81], và PBS [41]. Về so sánh chi tiết hơn giữa một số chương trình này, có thể được tham khảo thêm trong [30] [76]. A.5 Hạ tầng an ninh lưới Trong tính toán lưới, đảm bảo an ninh luôn là một trong những bộ phận quan trọng của các ứng dụng và hệ thống lưới. Có một số vấn đề cần phải giải quyết để đảm bảo yêu cầu an ninh này [60]: - - - Xác thực: là cơ chế kiểm tra xem một người dùng có đúng là đối tượng mà người đó đã khai báo hay không. Cơ chế này nhằm giúp chống lại những người dùng phi pháp bằng cách mạo danh của người khác. Riêng tư: là cơ chế nhằm đảm bảo rằng thông tin trao đổi giữa các bên là riêng tư, có nghĩa là chỉ những bên tham gia (bên nhận và bên gửi) mới có thể hiểu được nội dung trao đổi. Nếu ai đó có nghe lén trên đường truyền thông thì cũng không thể hiểu nội dung là gì. Toàn vẹn: Tính toàn vẹn của thông báo được gửi có nghĩa là phía nhận phải có thể chắc chắn rằng thông báo được nhận đúng là thông báo mà phía gửi đã gửi. Nói 147 - - cách khác, mọi thay đổi về nội dung của thông báo gốc trong quá trình truyền đều có thể bị phát hiện. Sự cấp quyền: Đây là cơ chế mà quyết định ai có quyền gì (có thể làm gì) trên tài nguyên nào. Điều này có nghĩa là trước khi cho phép một người dùng thực hiện một hành động trên một tài nguyên nào đó, thì hệ thống phải chắc chắn rằng người đó có đủ quyền để thực hiện hành động đó. Sự ủy quyền: Có nhiều tình huống trong tính toán lưới, việc cho phép một người dùng được ủy quyền của mình cho người dùng khác để thực thi một công việc nào đó là rất hữu ích và tiện lợi. Khả năng này cũng có thể mang đến một tiện ích thú vị khác là đăng nhập một lần. Bởi vì một ứng dụng lưới có thể chạy qua nhiều tổ chức khác nhau, nên sẽ vừa bất tiện và vừa thiếu an toàn nếu bắt buộc ứng dụng phải đăng nhập lại nhiều lần, mỗi khi ứng dụng muốn truy nhập vào các tài nguyên của một tổ chức. Trong bộ công cụ Globus Toolkit 4, có một thành phần có tên gọi Grid Security Infrastructure (GSI) đã được phát triển nhằm giải quyết các vấn đề an ninh nêu trên [93][60]. Dựa trên Hạ tầng Khóa Công Khai (Public Key Infrastruture - PKI) và nhằm trợ giúp cho các nhà phát triển các ứng dụng lưới, GSI có các đặc điểm sau: - - Về hỗ trợ Xác thực: Nó sử dụng chứng chỉ số hóa X509 (X509 digital certificates). Về hỗ trợ Riêng tư: Nó cung cấp hai mức độ riêng tư: mức giao vận với một lược đồ gọi là GSI Transport, và mức thông báo với hai lược đồ: GSI Secure Message và GSI Secure Conversation. Về hỗ trợ Toàn vẹn: Đặc tính này được hỗ trợ bởi Hạ tầng Khóa Công Khai (PKI). Về hỗ trợ sự Cấp quyền: Nó cung cấp khả năng Cấp quyền ở cả hai phía là Client và Server. Về hỗ trợ sự Ủy quyền: Nó sử dụng ủy nhiệm proxy. 148 PHỤ LỤC B: NGÔN NGỮ VÀ HỆ THỐNG LUỒNG CÔNG VIỆC Quản lý luồng công việc là quá trình mô hình hóa và kiểm soát việc thực thi các tiến trình ứng dụng, hay tiến trình nghiệp vụ trong nhiều lĩnh vực như khoa học, kỹ thuật, kinh doanh,v.v. nhằm mục đích tìm ra các tiến trình tối ưu theo cách hiệu quả nhất [78]. Trong thời gian gần đây, việc nghiên cứu các hệ thống quản lý luồng công việc đang thu hút được nhiều sự chú ý, vì cho phép kết hợp góc nhìn hướng dữ liệu, là cách tiếp cận truyền thống trong các hệ thống thông tin, với góc nhìn hướng tiến trình, trong đó các hoạt động và sự xuất hiện của chúng theo thời gian được mô hình hóa, được đặc tả và có thể được thực thi một cách tự động và có kiểm soát [63]. Trong các hệ thống này, các tiến trình nghiệp vụ được mô hình hóa bằng các luồng công việc. Để thực hiện được những việc này, các hệ thống quản lý luồng công việc cần có các ngôn ngữ mô hình hóa các luồng công việc, hay nói ngắn gọn, ngôn ngữ luồng công việc. Như vậy, ngôn ngữ luồng công việc giúp xây dựng các mô hình tiến trình và các mô hình tiến trình này chính là các biểu diễn cho các tiến trình nghiệp vụ. Các ngôn ngữ luồng công việc có nhiệm vụ mô tả được các thông tin liên quan đến luồng công việc trong các tiến trình nghiệp vụ, nhằm mục tiêu điều khiển và kiểm soát được việc thực thi các tiến trình nghiệp vụ này trong các hệ thống quản lý luồng công việc (WMS - Workflow Management Systems). Các thông tin liên quan trong luồng công việc thường không đồng nhất và bao gồm nhiều khía cạnh, từ mô tả cấu trúc của tiến trình nghiệp vụ, khía cạnh tổ chức và các chương trình ứng dụng, cho đến các dữ liệu chi tiết về môi trường thực thi tiến trình. Có một hạn chế khá lớn trong các WMS hiện nay là thiếu tính linh hoạt trong việc thực thi các luồng công việc. Điều này có nghĩa là sau khi một luồng công việc đã được định nghĩa, rồi thực thi, không thể thực hiện một sự thay đổi nào trong luồng công việc đó nữa, ngoài trừ dừng hẳn lại, rồi định nghĩa và thực thi lại từ đầu. Điều này thường gây lãng phí về thời gian và công sức, nhất là với các luồng công việc có thời gian thực thi trong thời gian dài rất phổ biến trong các ứng dụng thực tế. Do đó, yêu cầu về tính linh hoạt trong WMS cũng đang thu hút được nhiều nghiên cứu trong thời gian gần đây [102]. Kỹ thuật luồng công việc đã được lựa chọn như một trong số các nền tảng lý thuyết và công nghệ trong nghiên cứu về khung cộng tác dùng trong luận án, do cho phép biểu diễn khá đầy đủ phần kế hoạch hành động, cũng như hỗ trợ khả năng chuyển đổi, thực thi các kế hoạch này. Cụ thể hơn, hai ngôn ngữ luồng công việc tiêu biểu là BPMN và BPEL và các công nghệ liên quan được chọn sử dụng để biểu diễn các kế hoạch ở hai mức khác nhau. Trong khi BPMN được dùng để mô tả các kế hoạch tại mức trừu tượng (chưa thực thi được), thì BPEL sẽ được dùng để mô tả các kế hoạch tại mức chi tiết hơn (thực thi được). 149 B.1 Các khái niệm cơ bản Định nghĩa B-1. Tiến trình nghiệp vụ (cũng được gọi là thủ tục) như được định nghĩa trong [43]: “Là thủ tục trong đó các tài liệu, thông tin và nhiệm vụ được trao chuyển giữa những đối tượng tham gia theo một tập các quy tắc đã được xác định nhằm đạt được, hay đóng góp vào một mục tiêu kinh doanh tổng thể nào đó”. Trong Hình B-1 biểu diễn cấu trúc của một tiến trình nghiệp vụ theo định nghĩa ở trên. Hình B-1. Cấu trúc của một tiến trình nghiệp vụ. Như có thể thấy từ Hình B-1, các hệ thống quản lý luồng công việc cần hỗ trợ cho các luồng công việc trong các khía cạnh như sau: (trình bày trong [63] [102]). - - Khía cạnh chức năng: liên quan đến việc mô tả các chức năng luồng công việc cần phải thực hiện. Các chức năng này thường được phân chia theo một cấu trúc phân cấp, trong đó các chức năng cấp cao thường được gọi là các hoạt động, còn các chức năng cấp thấp thường được gọi là các nhiệm vụ hay các hoạt động con. Cấu trúc phân cấp này sẽ cho phép biểu diễn được việc tách/gộp các chức năng. Đến lượt mình, các nhiệm vụ lại có thể được chia nhỏ hơn thành các nhiệm vụ con. Và quá trình phân chia này có thể lặp lại nhiều lần cho đến khi các nhiệm vụ là đủ nhỏ và không phân chia được nữa - chúng được gọi là nhiệm vụ nguyên tố. Các nhiệm vụ ở mức trên sẽ phân chia nhỏ hơn là các nhiệm vụ không nguyên tố. Khía cạnh tiến trình: nhằm xác định các điều kiện và thứ tự thực thi cho các chức năng của luồng. Khía cạnh chức năng và tiến trình thường được kết hợp trong định nghĩa tiến trình luồng. Khía cạnh tổ chức (còn được gọi là 'khía cạnh tài nguyên' ): khía cạnh này liên 150 - - - quan đến vai trò và quyền hạn của những người tham gia sử dụng luồng trong một tổ chức. Điều này liên quan đến việc quản lý trách nhiệm, phân quyền truy nhập cho các cá nhân và các nhóm người dùng trong tổ chức đó. Các đối tượng này được coi như một loại tài nguyên của hệ thống. Khía cạnh thông tin: bao gồm các loại thông tin điều khiển luồng, cũng như các thông tin cần thiết cho các hoạt động/nhiệm vụ, ví như dữ liệu vào, ra. Ngoài ra, giữa các hoạt động/nhiệm vụ trong luồng công việc cũng cần có các luồng dữ liệu trao đổi với nhau nhằm biểu diễn các phụ thuộc dữ liệu giữa chúng. Các loại thông tin trên có thể được chia thành hai loại (theo [102]): thông tin điều khiển nhằm điểu khiển thứ tự hoạt động của các nhiệm vụ và thông tin sản xuất là các thông tin liên quan trực tiếp đến các nhiệm vụ như các dữ liệu vào/ra. Khía cạnh vận hành: khía cạnh này quan tâm đến việc thực thi luồng công việc trên một môi trường điều hành cụ thể. Nó chủ yếu thực hiện việc ánh xạ các hoạt động/nhiệm vụ của luồng công việc với các chương trình hay ứng dụng, sẽ thực sự thực thi các hoạt động/nhiệm vụ đó. Đồng thời nó cũng quản lý việc trao đổi các thông tin vào/ra của các chương trình hay ứng dụng thực thi đó với các hoạt động/nhiệm vụ tương ứng, nhằm cụ thể hóa các loại thông tin mà luồng công việc cần biểu diễn. Khía cạnh hành vi: Khía cạnh này biểu diễn các ràng buộc cho các luồng điều khiển giữa các nhiệm vụ. Bên cạnh các luồng điều khiển cơ bản như: tuần tự, rẽ nhánh và lặp, các tiến trình nghiệp vụ còn yêu cầu các luồng điều khiển nâng cao khác như: AND-split, AND-join (hay đồng bộ), OR-split, OR-join [98]. Định nghĩa B-2. Luồng công việc: được định nghĩa trong [2], như sau: “Là mô hình được biểu diễn trên máy tính của tiến trình nghiệp vụ, nhằm đặc tả tất cả các tham số liên quan để hoàn thành tiến trình này." Như đã trình bày ở trên, một tiến trình nghiệp vụ bao gồm nhiều khía cạnh. Vì một luồng công việc là một mô hình hay một biểu diễn cho một tiến trình nghiệp vụ. Tuy nhiên, do các nguyên nhân lý thuyết và thực hành, chỉ một loại luồng công việc không thể biểu diễn được đầy đủ hết tất cả các khía cạnh của tiến trình nghiệp vụ. Bởi vì nếu có một loại luồng công việc như thế, sẽ phải là sự tổng hợp của rất nhiều các kỹ thuật mô hình hóa khác nhau cho các khía cạnh khác nhau của tiến trình nghiệp vụ. Như thế sẽ trở nên quá phức tạp đến mức không còn hữu dụng. Do đó, tương tự như trong nhiều lĩnh vực cần sự mô hình hóa, một tiến trình nghiệp vụ cần được biểu diễn bằng nhiều luồng công việc khác nhau, trong đó mỗi luồng sẽ biểu diễn một hay một số ít khía cạnh liên quan chặt chẽ của tiến trình nghiệp vụ. Đó là lý do các nghiên cứu của luận án chọn hai ngôn ngữ luồng công việc là BPMN và BPEL, thuộc hai kiểu ngôn ngữ khác nhau, để có khả năng biểu diễn đầy đủ các khía cạnh của tiến trình nghiệp vụ, (được gọi là kế hoạch trong khung cộng tác được đề xuất trong 151 luận án). Chi tiết về hai ngôn ngữ luồng công việc này sẽ được trình bày chi tiết hơn trong phần sau. B.2 Các ngôn ngữ luồng công việc Phân loại ngôn ngữ luồng Thành phần trung tâm của mọi WMS là ngôn ngữ luồng công việc (WL - workflow language). Có nhiều cách tiếp cận khác nhau trong việc mô hình hóa và thực thi các luồng công việc và điều này cũng dẫn đến nhiều loại ngôn ngữ luồng công việc khác nhau. Ví dụ để cho phép người dùng mô hình hóa các luồng công việc, thường yêu cầu các ngôn ngữ luồng công việc cần có tính trực quan và dễ sử dụng, thường được biểu diễn bằng đồ thị. Để thực thi luồng công việc, việc sử dụng các ngôn ngữ kịch bản (văn bản) lại phù hợp hơn. Do đó trong các WMS đầy đủ có hỗ trợ cả mô hình hóa và thực thi các luồng công việc, thường có thể có nhiều mức biểu diễn các luồng công việc, từ mức trừu tượng (sử dụng đồ thị) cho đến mức chi tiết thực thi (sử dụng kịch bản). Hơn nữa, việc chuyển từ biểu diễn trừu tượng sang các kịch bản thường được làm tự động hoặc bán tự động. Có hai hướng tiếp cận đang được các WL sử dụng phổ biến hiện nay là hướng luồng dữ liệu và hướng tiến trình: - Các WL hướng luồng dữ liệu: đại diện cho cách tiếp cận này là ngôn ngữ SCUFL (Simple Conceptual Unified Flow Language) được sử dụng trong hệ quản trị luồng công việc Taverna [54]. Trong cách tiếp cận này, việc biểu diễn các luồng dữ liệu và biến đổi chúng là trọng tâm của luồng. Trong Hình B-2 minh họa việc sử dụng SCUFL để mô hình hóa một luồng công việc trong Taverna, được lấy từ một ví dụ trong bộ mẫu các luồng công việc của Taverna phiên bản 2.3 [92]. Trong hình này ta có thể thấy các dữ liệu vào sẽ bắt đầu được đưa vào thông qua các Workflow Input (luồng dữ liệu vào, cụ thể là ID và namespace), sau đó chúng sẽ được xử lý bằng các processor (bộ xử lý). Giữa các processor với nhau và với các thành phần dữ liệu được nối với nhau bằng các liên kết dữ liệu. Cuối cùng, các dữ liệu xử lý xong sẽ được đưa ra các luồng dữ liệu ra. Cách biểu diễn hướng luồng dữ liệu này rất thích hợp và dễ dàng cho những người dùng không có nhiều kinh nghiệm và kiến thức về tin học, vì không yêu cầu người dùng phải biểu diễn tường minh các cơ chế điều khiển và hoạt động phức tạp của luồng (như trình tự thu thập dữ liệu, các cơ chế xử lý song song,v.v). Thông thường, thứ tự thực thi của các processor chủ yếu được xác định dựa vào sự sẵn sàng của các luồng dữ liệu vào. Bất kỳ processor nào mà có các luồng dữ liệu vào đã sẵn sàng thì đều được xếp lịch để thực thi. Các cơ chế xếp lịch này sẽ được ngầm cài đặt bởi workflow engine là thành phần chịu trách nhiệm dịch và thực thi các mô hình luồng mà người dùng đã thiết kế. Do đó, các hoạt động song song của các processor độc lập cũng là ngầm định do các engine này quản lý. 152 Hình B-2. Một workflow được biểu diễn trong Taverna - Các WL hướng tiến trình: đại diện cho cách tiếp cận này là ngôn ngữ BPEL (Business Process Execution Language). Trái với các WL hướng luồng dữ liệu, thứ tự hoạt động của các bộ xử lý (hay còn gọi là các hoạt động) cần được định nghĩa tường mình bằng các luồng điều khiển. Đặc biệt là các thực thi song song của các bộ xử lý độc lập cũng cần phải được đặc tả rõ ràng. Ngôn ngữ này sẽ được trình bày chi tiết hơn ở phần sau. Các ngôn ngữ luồng công việc cho lưới GSFL GSFL (Grid Service Flow Language) [97] là một trong số những ngôn ngữ luồng được đề xuất đầu tiên cho môi trường lưới. Mục tiêu phát triển của GSFL là kế thừa các kết quả đã có trong các hệ thống luồng, có thể sáng tác các luồng mới từ các Web Service hiện có, để từ đó tạo ra một hệ thống luồng có thể hỗ trợ việc sáng tác các luồng mới từ các Grid Service. Việc phát triển GSFL cũng nhằm mục đích tương thích với chuẩn OGSA (Open Grid Service Architechture). Trong [97] đã đưa ra một số phân tích các yêu cầu riêng biệt của luồng công việc trong môi trường lưới, so với môi trường Dịch vụ Web thông thường. Một số yêu cầu đó là: - Đặc tả của luồng công việc cho lưới cần phải cho phép bản thân luồng công việc được xuất ra như là một dịch vụ (Dịch vụ web hoặc Dịch vụ lưới), và nó cũng có thể được mô tả bằng cách tương như các loại dịch vụ đó. Điều này sẽ cho phép dễ dàng tạo ra các luồng công việc cho lưới một cách đệ quy. 153 - Bản thân luồng công việc cho lưới cần hỗ trợ cơ chế cho phép các dịch vụ thành phần có thể trao đổi dữ liệu/thông báo trực tiếp với nhau mà không cần luồng công việc đóng vai trò trung chuyển các dữ liệu này. Điều này rất quan trọng, nhất là trong môi trường lưới, vì kích thước dữ liệu trao đổi thường khá lớn, nên nếu thiếu cơ chế trao đổi trực tiếp này giữa các dịch vụ, bản thân luồng công việc rất dễ trở thành điểm “cổ chai” cho các dịch vụ thành phần và đồng thời cũng giảm đáng kể khả năng thực thi song song của các dịch vụ này. Trong OGSA có sử dụng các cơ chế notificationSources và notificationSinks để giải quyết vấn đề này, nên các ngôn ngữ luồng công việc cho lưới cũng nên hỗ trợ các cơ chế này. Tuy nhiên trong [97], một yêu cầu khá quan trọng của các ngôn ngữ luồng công việc cho lưới là khả năng hỗ trợ gọi các dịch vụ lưới lại không được đề cập đến, chủ yếu chỉ tận dụng khả năng gọi các dịch vụ web mà đã được các ngôn ngữ luồng trước đó hỗ trợ như XLANG và WSFL. Ngoài ra, dường như còn thiếu các cài đặt hoàn chỉnh để từ đó đánh giá được hiệu quả thực thi và tính thực tế của ngôn ngữ này. A-GWL A-GWL (viết tắt của Abstract Grid Workflow Language) [37] là một ngôn ngữ luồng ở mức cao nhằm để mô tả các luồng ở mức logic trừu tượng. Ngôn ngữ này dựa trên lược đồ hoạt động của ngôn ngữ UML, là một ngôn ngữ mô hình hóa hướng đối tượng hiện đang được sử dụng rất rộng rãi. Luồng có thể được tạo ra từ UML, và sau đó nó có thể được tự động chuyển sang A-GWL bằng một công cụ gọi là Teuta [82]. Ưu điểm của ngôn ngữ này là sự kế thừa khả năng biểu diễn phong phú của lược đồ hoạt động của UML, trong đó đã cung cấp khá đầy đủ các thành phần để biểu diễn các loại luồng công việc ở nhiều mức trừu tượng khác nhau, như các cấu trúc điều khiển luồng (tuần tự và cả song song), các luồng dữ liệu, các cơ chế đồng bộ hóa giữa các hoạt động và cả cơ chế gửi tin nhắc để cho phép các dịch vụ trực tiếp gửi thông tin cho nhau (nhất là gửi dữ liệu kích thước lớn), không cần phải qua một trung tâm điều phối (như workflow engine). Tuy nhiên, A-GWL mới chỉ dừng ở mức mô tả được các luồng công việc ở mức trừu tượng và nó còn thiếu khả năng chuyển đổi sang các ngôn ngữ chi tiết hơn để có thể thực thi được luồng công việc đã được mô hình hóa. GWEL Grid Workflow Execution Language (GWEL) là một ngôn ngữ luồng công việc nhằm hỗ trợ trực tiếp cho việc kết hợp các dịch vụ lưới [26]. Tuy nhiên, nghiên cứu này mới dừng ở các ý tưởng khái quát, còn nhiều chi tiết như cú pháp của ngôn ngữ, phương pháp kết nối với các dịch vụ lưới như thế nào,v.v vẫn chưa được đề cập đến. Trong [103], các tác giả đưa ra một khảo sát và phân loại chi tiết hơn về các hệ thống và ngôn ngữ luồng công việc cho môi trường lưới. Trong số các ngôn ngữ luồng công việc, có 154 hai ngôn ngữ được luận án lựa chọn để biểu diễn cho các kế hoạch trong khung cộng tác, đó là BPMN và BPEL. Phần tiếp theo sẽ tóm tắt một số nội dung chính của hai ngôn ngữ này. B.3 BPEL và BPMN BPEL Giới thiệu Các nỗ lực xây dựng dịch vụ Web nhằm đạt được sự tương thông giữa các ứng dụng có sử dụng các tiêu chuẩn WEB. Với mục tiêu đó, một mô hình tích hợp nối kết lỏng lẻo đã được dịch vụ WEB sử dụng để cho phép có sự tích hợp linh hoạt giữa các hệ thống không đồng nhất thuộc các lĩnh vực ứng dụng khác nhau. Với các đặc tả cho dịch vụ WEB như SOAP, WSDL, UDDI, các ứng dụng khác nhau có thể tìm kiếm nhau và tương tác lẫn nhau theo một mô hình nối kết lỏng lẻo và độc lập với hạ tầng mà chúng đang chạy. Tuy nhiên, việc tích hợp hệ thống đòi hỏi thêm những khả năng khác chứ không chỉ là những tương tác đơn giản như trong mô hình dịch vụ Web. Mô hình này chủ yếu hỗ trợ các tương tác theo kiểu hỏi-đáp không có thông tin trạng thái, hoặc các tương tác một chiều không có sự liên hệ. Các ứng dụng và các tiến trình nghiệp vụ trong thực tế yêu cầu các tương tác phức tạp, và do đó chúng yêu cầu cần có sự hỗ trợ của các mô hình tích hợp các tiến trình nghiệp vụ chuẩn hóa và linh hoạt [68]. Mô hình cho các tương tác nghiệp vụ thường đòi hỏi dãy các trao đổi thông báo ngang hàng, theo kiểu hỏi-đáp hoặc một chiều có thông tin trạng thái và tương tác trong một thời gian lâu dài giữa hai hay nhiều đối tác tham gia. Do vậy, một mô tả hình thức cho các giao thức trao đổi thông báo như vậy là cần thiết để định nghĩa các tương tác nghiệp vụ được sử dụng trong các tiến trình nghiệp vụ. WS-BPEL (Web Services - Business Process Execution Language) được ra đời chính là nhằm mục đích này. Nó là một ngôn ngữ tiêu chuẩn cho phép định nghĩa các tiến trình nghiệp vụ mới thông qua việc kết hợp và tương tác của các tiến trình nghiệp vụ (hay các dịch vụ) hiện có. Khởi đầu nó có cái tên là BPEL for Web services, BPEL4WS, rồi sau đó chuyển thành WS-BPEL. Gần đây, BPEL đang trở thành một trong các ngôn ngữ chuẩn hóa thông dụng để cấu thành các Web service. BPEL có thể được dùng để định nghĩa hai loại tiến trình: trừu tượng và khả thi. Một tiến trình trừu tượng chủ yếu hướng tới khía cạnh nghiệp vụ không quan tâm làm cho nó có thể thực thi được, và nó sẽ được khai báo tường minh là “abstract”. Trong khi đó, tiến trình khả thi sẽ được đặc tả chi tiết và đầy đủ để nó có thể thực thi được. WS-BPEL định nghĩa một mô hình và một cú pháp nhằm mô tả hành vi của một tiến trình nghiệp vụ dựa trên sự tương tác giữa nó và các đối tác. Những tương tác này xuất hiện thông qua các giao diện dịch vụ Web và cấu trúc của quan hệ này tại mức giao diện được đóng gói trong một đối tượng được gọi là liên kết đối tác. Tiến trình BPEL sẽ xác định 155 những tương tác với các đối tác này sẽ được phối hợp như thế nào để đạt được mục tiêu về nghiệp vụ, cũng như các trạng thái và lôgic cần thiết cho sự phối hợp này. Ngoài ra, WS-BPEL cũng đưa vào những cơ chế để giải quyết các trường hợp ngoại lệ và xử lý lỗi, cũng như cơ chế bồi thường cho các hoạt động nghiệp vụ trong trường hợp xuất hiện ngoại lệ hay khi có yêu cầu từ đối tác. Các mục tiêu thiết kế của BPEL Ban đầu khi thiết kế BPEL (lúc đó còn được gọi là BPEL4WS (BPEL For Web Services)), các nhà thiết kế đã đề ra mười mục tiêu cho nó [33]: - - - - - - - - Mục tiêu 1: BPEL4WS định nghĩa các tiến trình nghiệp vụ mà tương tác với các thực thể bên ngoài thông qua các thao tác của dịch vụ WEB được định nghĩa bởi chuẩn WSDL 1.1 và bản thân chúng cũng được biểu diễn như là các dịch vụ WEB được định nghĩa bởi WSDL 1.1. Những tương tác này là “trừu tượng” theo nghĩa là các phụ thuộc là ở định nghĩa ở portType, chứ không phải là ở định nghĩa ở port. Mục tiêu 2: BPEL4WS định nghĩa các tiến trình nghiệp vụ sử dụng ngôn ngữ dạng XML (XML based language). BPEL4WS không quan tâm đến những biểu diễn đồ thị của các tiến trình, cũng như không xác định phương pháp luận cụ thể nào cho các tiến trình. Mục tiêu 3: BPEL4WS nên định nghĩa một tập các khái niệm về sự phối hợp các dịch vụ WEB như là một phương tiện sẽ được sử dụng bởi cả hai loại khung nhìn bên ngoài (trừu tượng) và bên trong (khả thi) của tiến trình nghiệp vụ. Mục tiêu 4: BPEL4WS nên cung cấp cả hai chế độ điều khiển là theo kiểu phân cấp và theo kiểu đồ thị và cho phép sử dụng trộn lẫn cả hai cách này một cách liền mạch nhất. Điều này sẽ giúp giảm được sự phân mảnh của không gian mô hình hóa tiến trình. Mục tiêu 5: BPEL4WS cung cấp các một cách giới hạn các hàm thao tác dữ liệu sao cho chúng đủ để thực hiện các thao tác dữ liệu đơn giản cho việc định nghĩa các dữ liệu liên quan đến tiến trình và các luồng điều khiển. Mục tiêu 6: BPEL4WS nên hỗ trợ một cơ chế định danh cho các thể hiện của tiến trình mà cho phép xác định định danh của thể hiện tiến trình tại mức thông báo ứng dụng. Định danh của thể hiện nên do đối tác định nghĩa và có thể thay đổi theo thời gian. Mục tiêu 7: BPEL4WS nên hỗ trợ việc sinh ra và kết thúc ngầm định các thể hiện của tiến trình như một cơ chế quản lý vòng đời cơ bản. Các thao tác quản lý vòng đời nâng cao như tạm dừng, hồi phục có thể được bổ sung trong các phiên bản sau. Mục tiêu 8: BPEL4WS nên định nghĩa một mô hình giao tác thực thi trong thời gian dài mà dựa trên các kỹ thuật đã được kiểm chứng qua thực tiễn như hành động bù đắp và phân phạm vi nhằm hỗ trợ việc khắc phục sự cố cho các phần của các tiến trình nghiệp vụ thực thi trong thời gian dài. 156 - - Mục tiêu 9: BPEL4WS nên sử dụng dịch vụ WEB như là mô hình để tách và ghép các tiến trình. Kết hợp cách tiếp cận này với chuẩn WS-Policy sẽ làm mô hình này mạnh mẽ hơn. Mục tiêu 10: BPEL4WS nên được xây dựng dựa trên các chuẩn dịch vụ WEB tương thích và các đề xuất tiêu chuẩn một cách tối đa theo cách modul và có thể kết hợp được. Chỉ trong trường hợp chưa có chuẩn hoặc đề xuất phù hợp, một đặc tả tương ứng mới cần được phát triển như một đặc tả của BPEL4WS hoặc một đề xuất tiêu chuẩn Dịch vụ WEB riêng biệt. Các khái niệm cơ bản Có hai cách tiếp cận trong việc cấu thành các dịch vụ Web: orchestration và choreography. Theo cách orchestration, chỉ một dịch vụ đóng vai trò là dịch vụ chính sẽ gọi các dịch vụ khác. Thế nên, chỉ dịch vụ chính này biết về trình tự các activity, trạng thái của các yêu cầu và trả lời của các dịch vụ được gọi. Ngược lại, trong cách choreography không có dịch vụ chính. Sự phản ứng giữa các dịch vụ do cơ chế điều phối hỗ trợ. BPEL hiện nay chỉ hỗ trợ cách orchestration. Trong BPEL, dịch vụ chính này được gọi là tiến trình nghiệp vụ (Business Process, BP) và các dịch vụ khác được gọi là đối tác. Có hai loại đối tác trong BPEL: đối tác được gọi là đối tác được gọi bởi dịch vụ chính và đối tác client là đối tác sẽ gọi dịch vụ chính. Mối liên kết tiềm tàng giữa một đối tác và một BP được gọi là liên kết đối tác (Partner Link, PL). Giao diện giữa một tiến trình và một đối tác là thông qua một portType mà đề xuất các thao tác. BPEL hỗ trợ hai lớp thao tác: input-only và input-output. Cấu tạo của một tiến trình BPEL Các thành phần chính của một tiến trình nghiệp vụ được mô tả trong Hình B-3 Hình B-3. Các thành phần chính của một tiến trình nghiệp vụ Trong Hình B-4 đưa ra một tiến trình nghiệp vụ cụ thể thực hiện việc giải một phương trình bậc 2. 157 Hình B-4. Tiến trình BPEL giải phương trình bậc 2. Các BPEL engine BPEL engine là một phân hệ phần mềm có nhiệm vụ thực thi các tiến trình nghiệp vụ được biểu diễn bằng BPEL. Phân hệ này thường được tích hợp trong những hệ thống phần mềm có hỗ trợ BPEL. Phần này sẽ giới thiệu tóm tắt về ba loại BPEL engine đang được sử dụng rộng rãi hiện nay là ActiveBPEL engine, BPEL engine trong JBI và ODE engine của Apache. ActiveBPEL engine Phiên bản 5.0 mới nhất của engine này là cài đặt mã nguồn mở cho BPEL engine, được viết bằng JAVA. Nó hỗ trợ cả hai chuẩn BPEL4WS 1.1 và WS-BPEL 2.0. Một trong những nhược điểm của engine này là quá trình khai thác các tiến trình BPEL không được tự động và rất phức tạp trong việc tạo tệp khai thác. BPEL engine trong JBI Engine này chỉ được tích hợp trong môi trường phát triển ứng dụng Netbeans. Một trong những hạn chế lớn nhất của engine này hiện nay là nó chỉ hỗ trợ chuẩn BPEL4WS 1.1 mà không có hỗ trợ cho chuẩn WS-BPEL 2.0. ODE engine ODE Engine (Orchestration Director Engine) là một BPEL engine mã nguồn mở của Apache. Phiên bản mới nhất hiện nay là 1.3 có nhiều đặc tính quan trọng như: - Hỗ trợ cả hai chuẩn BPEL4WS 1.1 và WS-BPEL 2.0. Hỗ trợ 2 lớp truyền thông: Web service http transport của Axis2 và ServiceMix của JBI. 158 - Nó có thể được tích hợp dễ dàng với gần như tất cả các lớp truyền thông nhờ giao diện API với engine. Cho phép việc khai thác nhanh các tiến trình BPEL. Điều này có nghĩa là chỉ cần sao chép các tệp cần thiết vào thư mục khai thác (do engine quy định trước), sau đó engine đang chạy sẽ tự động phát hiện ra các tệp này, rồi dịch và làm chúng sẵn sàng cho việc sử dụng. Bản ODE hiện nay không nhận ra tất cả các thông tin cần thiết được gửi đến từ các tiến trình BPEL và cũng không hỗ trợ việc gọi các dịch vụ lưới. Chương 4 sẽ khảo sát vấn đề này một cách chi tiết hơn và đưa ra giải pháp của luận án. BPMN Giới thiệu BPMN (đầu tiên được gọi là “Business Process Modeling Notation” trong phiên bản 1 [69]. Sang phiên bản 2, nó được đổi thành “Business Process Model & Notation” [70]) là một hệ thống ký hiệu sử dụng đồ họa, dùng để mô hình hóa các tiến trình nghiệp vụ. Nó được phát triển bởi BPMI (Business Process Management Initiative) và OMG (Object Management Group) với mục đích chính là tạo ra một hệ thống ký hiệu thống nhất và dễ hiểu cho tất cả những người sử dụng các tiến trình nghiệp vụ, từ những người phân tích nghiệp vụ bắt đầu tạo ra bản phác thảo cho tiến trình nghiệp vụ, cho đến những người phát triển các công nghệ để cài đặt việc thực thi các tiến trình nghiệp vụ đó. BPMN cũng hướng đến mục tiêu có thể tạo ra các tiến trình tự động mà có thể được thực thi trên máy tính, qua việc hỗ trợ tối đa khả năng chuyển đổi thành các tiến trình nghiệp vụ được biểu diễn bằng BPEL [99]. Hiện nay, BPMN đã được chuẩn hóa và được hỗ trợ của hơn 70 công ty trên thế giới, trong đó có nhiều công ty lớn. Trong hệ thống được xác định trong luận án, BPMN được lựa chọn làm công cụ để xây dựng các kế hoạch (plan), vì vai trò của các kế hoạch chính là các tiến trình nghiệp vụ ở dạng khởi đầu. Các loại mô hình trong BPMN Từ phiên bản 2, BPMN hỗ trợ ba loại mô hình: - - Tiến trình (hay Orchestration): loại mô hình này lại có thể bao gồm ba loại:  Tiến trình nghiệp vụ riêng tư không thực thi được.  Tiến trình nghiệp vụ riêng tư thực thi được.  Tiến trình nghiệp vụ công. Choreographies Tiến trình nghiệp vụ cộng tác Ví dụ về các loại mô hình trên được cho trong các Hình B-5 – B-8 [70]. 159 Hình B-5. Tiến trình nghiệp vụ riêng tư. Hình B-6. Tiến trình nghiệp vụ công. Hình B-7. Choreography. 160 Hình B-8. Tiến trình nghiệp vụ cộng tác Các thành phần cơ bản của BPMN Thành phần cơ bản nhất của BPMN là các “biểu đồ tiến trình nghiệp vụ” (Business Process Diagram - BPD). Nó là một loại lưu đồ được điều chỉnh để mô hình hóa các tiến trình nghiệp vụ. Một BPD được cấu thành từ nhiều phần tử đồ họa. Có khá nhiều phần tử đồ họa trong BPMN và được chia làm năm nhóm: - Các đối tượng luồng Dữ liệu Các đối tượng kết nối Các làn (Swimlanes) Các ký hiệu gia công (Artifacts) Các đối tượng luồng Gồm có ba đối tượng cơ bản nhất của BPD là Event, Activity và Gateway (xem Hình B-9). Hình B-9. Các loại đối tượng luồng cơ bản - Sự kiện: được biểu diễn bởi hình tròn, biểu thị cho điều gì đó xảy ra trong quá trình hoạt động của tiến trình nghiệp vụ, và gây ảnh hưởng đến luồng hoạt động này. Có ba loại sự kiện: Bắt đầu, Trung gian và Kết thúc. 161 - - Hoạt động: là thuật ngữ chung để biểu thị cho công việc cần được thực hiện. Nó được biểu diễn bởi hình chữ nhật có góc tròn. Có hai loại Hoạt động là Nhiệm vụ là loại hoạt động nguyên tố và Tiến trình con là loại hoạt động phức mà bên trong có chức các hoạt động khác. Rẽ nhánh: được dùng để biểu diễn việc hợp hay tách các luồng hoạt động. Nó được biễu diễn bởi một hình thoi. Có khá nhiều loại gateway được cung cấp trong BPMN nhằm biểu diễn nhiều cách điều khiển các luồng khác nhau (xem Hình B10). Hình B-10. Các loại gateway trong BPMN Dữ liệu Có bốn phần tử dữ liệu trong BPMN (xem B-11 cho cách ký hiệu các phần tử): - Đối tượng dữ liệu: biểu diễn thông tin được các hoạt động sử dụng để thực thi được hoặc kết quả chúng tạo ra Dữ liệu vào: biểu diễn dữ liệu đầu vào cho các tiến trình Dữ liệu ra: biểu diễn dữ liệu đầu ra cho các tiến trình Kho dữ liệu: biểu diễn dữ liệu cần được lưu trữ. 162 Hình B-11. Các loại phần tử dữ liệu Các đối tượng kết nối Khi các đối tượng luồng cần kết nối với nhau, chúng sẽ sử dụng các đối tượng kết nối. Có ba loại đối tượng kết nối là: Luồng tuần tự, luồng thông báo và liên kết (xem hình B-12). Hình B-12. Các loại đối tượng kết nối cơ bản Các làn Các làn là công cụ cho phép tổ chức hay chia các hoạt động trong tiến trình thành các nhóm. Có hai loại làn trong BPMN là Pool và Lane (xem Hình B-13): - Pool: là công cụ cho phép chia các tiến trình theo nhóm các thành viên. Mỗi Pool sẽ đại diện cho một thành viên trong tiến trình. Lane: là công cụ phân chia bên trong Pool. Tức là mỗi Pool có thể bao gồm một hoặc nhiều Lane. 163 Hình B-13. Các loại Làn Các ký hiệu gia công (Artifacts) Ngoài các kí hiệu cơ bản ở trên, BPMN còn cho phép người mô hình và các công cụ phát triển mở rộng thêm các thành phần ký hiệu mới và chúng được gọi là các ký hiệu gia công. Có hai loại ký hiệu gia công đã được định nghĩa trước trong BPMN là Nhóm và Chú thích (xem Hình B-14). Hình B-14. Các ký hiệu gia công đã được định nghĩa sẵn. Một số công cụ hỗ trợ BPMN - Bonita Open Solution: Bonita Open Solution phiên bản 5 một môi trường hỗ trợ BPMN2, mã nguồn mở, là sản phẩm của hãng BonitaSoft [23]. jBPM: jBPM [46] là sản phẩm mã nguồn mở của Jboss. - Activity BPM 164 PHỤ LỤC C: AXIS 2 Axis2 [4] là phiên bản mới của Axis (Apache eXtensible Interaction System), là một SOAP engine và một công cụ phần sụn của dịch vụ Web. Nó là một hệ thống quản lý thông báo SOAP với thiết kế kiến trúc kiểu modul. Khung Axis2 (Axis2 Framework) được xây dựng dựa trên bẩy modul cốt lõi. Các module khác không phải cốt lõi được phân lớp trên đỉnh của các modul cốt lõi này [4]. Trong số bẩy modul cốt lõi, có hai modul Xử lý XML và Xử lý SOAP là có quan hệ đến nghiên cứu của luận án. - - Modul xử lý XML: xử lý các thông báo SOAP là nhiệm vụ quan trọng nhất và phức tạp nhất trong Axis2 và hiệu quả của nó là nhân tố quan trọng nhất quyết định hiệu năng. Axis2 sử dụng mô hình AXIOM (AXis Object Model) để cung cấp một giao diện lập trình ứng dụng (API) đơn giản nhằm tăng cường hiệu năng xử lý SOAP và XML của Axis2 so với Axis. Modul xử lý SOAP: modul này kiểm soát thứ tự thực thi các xử lý. Bên cạnh việc định nghĩa sẵn các pha thực thi khác nhau, modul này cũng hỗ trợ khả năng có thể mở rộng bằng cách cho phép người sử dụng mở rộng Mô hình Xử lý tại các vị trí plug-in đặc biệt. Mô hình Xử lý SOAP được minh họa trong Hình C-1. Hình C-1. Mô hình Xử lý SOAP của Axis2 Hai hoạt động cơ bản của một bộ xử lý SOAP là gửi và nhận các thông báo SOAP. Để hỗ trợ các hoạt động này, kiến trúc trên cung cấp hai pipe (hay luồng xử lý thông báo) được gọi là In Pipe (pine nhập) và Out Pipe (pipe xuất). Cài đặt cho hai pipe này là do định nghĩa của hai phương thức (methods) send() và receive() trong Axis2 engine. Khả năng có thể mở rộng của mô hình xử lý SOAP được cung cấp bởi các handler. Khi xử lý một thông báo SOAP, chỉ có các handler mà đã được đăng ký mới được thực thi. Axis2 hỗ trợ ba phạm vi mà các handler có thể đăng ký vào là toàn cục, dịch vụ hoặc thao 165 tác. Chuỗi handler cuối cùng sẽ được tính toán bằng việc tổng hợp các handler từ tất cả các phạm vi. Hoạt động như các bộ chặn, các handler xử lý các bộ phận của thông báo SOAP và cung cấp các dịch vụ bổ sung. Các giai đoạn khác nhau của pipe được gọi là pha (phase), mà cung cấp một cơ chế nhằm xác định trật tự của các handler. Một handler luôn chạy trong một pha chuyên biệt. Cả hai pipe đều có các pha được xây dựng sẵn, cũng như các chỗ dành cho “các pha của người dùng”, đến người dùng có thể định nghĩa. 166 [...]... dữ liệu được sử dụng để tạo ra các thông tin chứng thực lưới cho người dùng 1.3 Khung lưới cộng tác Phần này giới thiệu về khái niệm khung cộng tác và một số khái niệm liên quan như khung lưới cộng tác, khung lưới cộng tác đa dụng 1.3.1 Khung cộng tác Khung cộng tác (Collaborative Framework) là thuật ngữ có thể được diễn giải theo nhiều cách khác nhau: hệ thống, công cụ hỗ trợ cộng tác; bộ tiêu chuẩn... năng cộng tác, các khung cộng tác tìm cách kếp hợp các khả năng cộng tác của các hệ thống hiện có Như đã giới thiệu về tính toán lưới, bản thân các hạ tầng Tính toán lưới là các khung cộng tác đa dụng, với sự hỗ trợ chia sẻ nhiều loại tài nguyên khác nhau, ở nhiều mức độ chia sẻ khác nhau Chính vì vậy, việc tìm cách kết hợp môi trường này vào trong các khung cộng tác để tăng cường khả năng cộng tác. .. hệ thống cộng tác [29]; một hiệp định hợp tác [64] Trong luận án này, khung cộng tác được sử dụng với ý nghĩa: một hệ thống hay công cụ hỗ trợ cộng tác Khung cộng tác có thể được sử dụng độc lập hay tích hợp với hệ thống khác để hỗ trợ việc xây dựng các ứng dụng yêu cầu khả năng cộng tác Như đã thấy trong phần 1.1, các tiếp cận liên quan đến cộng tác, nhu cầu và các loại hình cộng tác là rất đa dạng... quan đến khung lưới, khai thác thủ công tiến trình BPEL trong môi trường ODE Engine của Apache [75], cũng như các giải pháp mở rộng dịch vụ lưới trong tiến trình BPEL cũng được đề cập Chương 2 Mô hình kế hoạch và khung cộng tác: trình bày về một hệ hình thức (formalism) về cộng tác và khung cộng tác Trong hệ hình thức này, luận án chỉ ra lõi của cộng tác là kế hoạch Do đó, khung hỗ trợ cộng tác cần... o Khung cộng tác chuyên biệt: là khung cộng tác nhằm trực tiếp vào hỗ trợ một loại ứng dụng cộng tác chuyên biệt nào đó Cách tiếp cận trong việc phát triển các khung loại này là tập trung hỗ trợ các khả năng cộng tác đặc thù cho các tài nguyên chuyên biệt Ví dụ, hướng vào các ứng dụng trong y tế PATIENT SCHEDULER [20] ; GCF-MD hướng vào các ứng dụng cho thiết bị di động [88] o Khung cộng tác đa dụng: ... môi trường lưới Với giải pháp này, luận án đã góp phần nâng cao khả năng cộng tác của môi trường lưới hiện nay, phục vụ tốt cho các ứng dụng có tính cộng tác cao trên lưới như điều trị y tế, quản trị doanh nghiệp,v,v Các nghiên cứu trong luận án đã đạt được các kết quả sau: - - Về mặt lý thuyết: xây dựng một mô hình về cộng tác và khung cộng tác, cho phép giải thích đầy đủ hơn bản chất của sự cộng tác. .. được phân tích chi tiết hơn trong Chương 1) Vì vậy, nghiên cứu của luận án hy vọng góp phần xây dựng khung lưới cộng tác, giúp khắc phục được phần nào các hạn chế trong tính toán lưới thông thường Mục đích và đối tượng nghiên cứu của luận án: Mục đích nghiên cứu: Nghiên cứu trong luận án nhằm xác định rõ các hạn chế về khả năng hỗ trợ các ứng dụng cộng tác trong môi trường lưới hiện tại, từ đó đề xuất... luận án là các khung có khả năng hỗ trợ các nhu cầu cộng tác trong môi trường tính toán lưới Ngoài ra, do môi trường tính toán lưới có cấu trúc khá phức tạp với nhiều thành phần, nên nghiên cứu trong luận án dựa trên cơ sở lý luận lý thuyết hoạt động, luồng công việc (workflow), các mô hình điều khiển truy nhập, v.v Phương pháp nghiên cứu Một số phương pháp nghiên cứu, được áp dụng trong luận án, bao... dụng: loại khung này không hướng vào loại ứng dụng cụ thể nào, cho phép hỗ trợ các loại hình cộng tác khác nhau, trong đó, khả năng mở rộng người dùng có thể định nghĩa các loại hình cộng tác trên cơ sở các loại hình hiện có, cũng được quan tâm Đây là loại khung cộng tác được luận án tập trung trong nghiên cứu nhằm xây dựng một khung cộng tác có thể hỗ trợ nhiều loại ứng dụng lưới khác nhau Trong phần... rộng trong OCGSA vẫn chưa đáp ứng được yêu cầu của các ứng dụng cộng tác trong thực tế, do còn thiếu hỗ trợ các cơ chế điều phối cụ thể và rõ ràng Hơn nữa, kiến trúc này chỉ đưa ra mức cơ bản, mà chưa mô tả các cơ chế phù hợp cụ thể hỗ trợ sự cộng tác thực tế, dẫn đến khó áp dụng được trong việc phát triển các khung hay ứng dụng cộng tác lưới thực tế Grid-enabled large scale (LAGrid) Khung cộng tác ... người dùng 1.3 Khung lưới cộng tác Phần giới thiệu khái niệm khung cộng tác số khái niệm liên quan khung lưới cộng tác, khung lưới cộng tác đa dụng 1.3.1 Khung cộng tác Khung cộng tác (Collaborative... hình cộng tác khung cộng tác, cho phép giải thích đầy đủ chất cộng tác loại hình cộng tác cần thiết khung cộng tác Về mặt thực tiễn: phát triển khung cộng tác hoạt động môi trường tính toán lưới, ... cộng tác; tiêu chuẩn để đánh giá hệ thống cộng tác [29]; hiệp định hợp tác [64] Trong luận án này, khung cộng tác sử dụng với ý nghĩa: hệ thống hay công cụ hỗ trợ cộng tác Khung cộng tác sử dụng