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

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI KHUNG CỘNG TÁC ĐA DỤNG TRONG MÔI TRƯỜNG TÍNH TỐN LƯỚI Chun ngành: Hệ thống thơng tin Mã số: 62480104 LUẬN ÁN TIẾN SĨ HỆ THỐNG THÔNG TIN Hà Nội – 2015 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI NGUYỄN THANH BÌNH TUYỂN TẬP CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN KHUNG CỘNG TÁC ĐA DỤNG TRONG MÔI TRƯỜNG TÍNH TỐN LƯỚI Chun ngành: Hệ thống thơng tin Mã số: 62480104 NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Nguyễn Hữu Đức GS.TS Nguyễn Thanh Thủy Hà Nội – 2015 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI TUYỂN TẬP CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN KHUNG CỘNG TÁC ĐA DỤNG TRONG MÔI TRƯỜNG TÍNH TỐN LƯỚI Chun ngành: Hệ thống thơng tin Mã số: 62480104 Hà Nội – 2015 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN Binh T Nguyen and D B Hoang, “Building a Plan-Supported Grid Collaborative Framework,” in 2nd International Cenference on Communications and Electronics (ICCE 2008), 2008, pp 150–155 Binh Thanh Nguyen and D B Hoang, “An automatic tool for deployment of BPEL processes in ODE Apache,” in EEE’09 - The 2009 International Conference on e-Learning, e-Business, Enterprise Information Systems, and e-Government, 2009 Binh T Nguyen, D B Hoang, and Thuy T Nguyen, “Enabling Grid Services from BPEL process using ODE engine,” in ICCSIT 2011, 2011 Binh T Nguyen, Duc H Nguyen, and D B Hoang, “Towards A Grid Collaborative Framework,” International Journal of Machine Learning and Computing, vol Vol.2(2), pp 99–106, 2012 Binh T Nguyen, Duc H Nguyen, and Thuy T Nguyen, “G-ODE, an extension of the Apache ODE for grid services,” Journal of Computer Science and Cybernetics, vol 28, no 3, 2012 Binh T Nguyen, Duc H Nguyen, and Thuy T Nguyen, “Translation from BPMN to BPEL , current techniques and limitations,” in Proceedings of the Fifth Symposium on Information and Communication Technology - SoICT 2014, p 10 Binh T Nguyen, Duc H Nguyen, and Thuy T Nguyen, “A Formalism of Activity Theory,” in The 2nd KICS Korea-Vietnam International Workshop on Information and Communications, 2014 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 Binh Thanh Nguyen, Duc Huu Nguyen, Thuy Thanh Nguyen, and Doan Bang Hoang, “Design of a Workflow-based Grid Framework,” International Journal of Computing Theory and Engineering, vol 8, no 1, p 10, 2016 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN “Building a Plan-Supported Grid Collaborative Framework,” in 2nd International Cenference on Communications and Electronics (ICCE 2008), 2008, pp 150–155 “An automatic tool for deployment of BPEL processes in ODE Apache,” in EEE’09 - The 2009 International Conference on e-Learning, e-Business, Enterprise Information Systems, and e-Government, 2009 “Enabling Grid Services from BPEL process using ODE engine,” in ICCSIT 2011, 2011 “Towards A Grid Collaborative Framework,” International Journal of Machine Learning and Computing, vol Vol.2(2), pp 99–106, 2012 “G-ODE, an extension of the Apache ODE for grid services,” Journal of Computer Science and Cybernetics, vol 28, no 3, 2012 “Translation from BPMN to BPEL , current techniques and limitations,” in Proceedings of the Fifth Symposium on Information and Communication Technology - SoICT 2014, p 10 “A Formalism of Activity Theory,” in The 2nd KICS Korea-Vietnam International Workshop on Information and Communications, 2014 “Plan Model - An Activity Theory Based Approach”, accepted by SOICT 2015, Hue, Vietnam, December 3-4 2015 “Design of a Workflow-based Grid Framework,” International Journa l of Computing Theory and Engineering, vol 8, no 1, p 10, 2016 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 tảng liên quan đến kế hoạch cộng tác 16 1.1.1 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 ngôn ngữ luồng công việc 22 1.2 Tính tố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 lưới 34 1.5 Quá trình khai thác tiến trình BPEL 35 1.6 Vấn đề tồn tiếp cận 36 1.6.1 Vấn đề tồn 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 40 2.1 Mơ hình kế hoạch 40 2.1.1 Các khái niệm 40 2.1.2 Các trạng thái hoạt động 49 2.1.3 Phụ thuộc khả thi 51 2.1.4 Kế hoạch 54 2.2 Khung cộng tác đa dụng 65 2.2.1 Các yêu cầu khung cộng tác đa dụng 65 2.2.2 Mô tả hoạt động 66 2.3 Các nghiên cứu liên quan 74 CHƯƠNG 3: LÀM MỊN KẾ HOẠCH 76 3.1 Chi tiết hóa kế hoạch 76 3.1.1 Bổ sung chi tiết 78 3.1.2 Phân tách 79 3.1.3 Mối quan hệ chi tiết hóa phụ thuộc khả thi 80 3.2 Tăng cường tính khả thi hoạt động 80 3.2.1 Các kỹ thuật chuyển đổi 80 3.2.2 Các hạn chế tồn 87 3.2.3 Giải thuật phát mẫu có cấu trúc đầy đủ 88 3.2.4 Giải thuật xây dựng mẫu có cấu trúc đầy đủ 93 3.2.5 Các nghiên cứu liên quan 98 CHƯƠNG 4: THIẾT KẾ VÀ CÀI ĐẶT KHUNG LƯỚI CỘNG TÁC ĐA DỤNG 100 4.1 Các yêu cầu khung 100 4.2 Thiết kế khung 101 4.2.1 Kiến trúc khung 101 4.2.2 Thiết kế modul 103 4.2.3 Kết luận phần thiết kế 106 4.3 Cài đặt khung 106 4.3.1 Giải pháp gọi dịch vụ lưới từ tiến trình BPEL 106 4.3.2 Mở rộng mơ hình điều khiển truy nhập dựa thuộc tính cho hệ thống luồng công việc cho môi trường lưới 117 4.3.3 Giải pháp tự động hóa q trình khai thác tiến trình BPEL 128 KẾT LUẬN 135 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CÔNG BỐ TÀI LIỆU THAM KHẢO PHỤ LỤC DANH MỤC HÌNH VẼ Hình 1-1: Sơ đồ hoạt động 18 Hình 1-2: Sự chuyển đổi mức 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 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 tổ chức ảo (Virtual Organization) 26 Hình 1-8: Quan hệ OGSA Globus Toolkit 28 Hình 2-1: Cấu trúc hoạt động đơn 41 Hình 2-2: Góc nhìn chức hoạt động đơn A(S,T,O) 42 Hình 2-3: Biểu diễn hoạt động đơn 42 Hình 2-4: Các tình cho common-in(A 1, A2) 44 Hình 2-5: Các tình cho in-out (A 1, A2) 44 Hình 2-6: Ví dụ biểu diễn đường dẫn path(A , A2) 45 Hình 2-7: Các thành phần hoạt động “Học chủ đề” 45 Hình 2-8: Các thành phần hoạt động “Dạy học cho nhóm” 46 Hình 2-9: Hoạt động tập thể "Học chủ đề" 47 Hình 2-10: Hoạt động tập thể chỉnh 47 Hình 2-11: Hoạt động Xử lý yêu cầu làm thẻ tín dụng 48 Hình 2-12: Các cặp hoạt động tương đương 50 Hình 2-13: Biểu diễn cho kế hoạch 55 Hình 2-14: Biểu diễn kế hoạch khả thi đồ thị VÀ/HOẶC 56 Hình 2-15: Biểu diễn kế hoạch không khả thi 56 Hình 2-16: Biểu diễn kế hoạch không khả thi đồ thị VÀ/HOẶC 57 Hình 2-17: Kế hoạch cho việc xây dựng giải thuật xếp 58 Hình 2-18: Kế hoạch cho việc xây dựng Dịch vụ lưới giải thuật xếp 59 Hình 2-19: Đường dẫn khả thi (biểu diễn nét đứt) 60 Hình 2-20: Đường dẫn khơng khả thi (biểu diễn nét đứt) 60 Hình 2-21: Đường dẫn khả thi thứ cho Kế hoạch xếp 61 Hình 2-22: Đường dẫn khả thi thứ hai cho Kế hoạch xếp 61 Hình 2-23: Tổng quan khung cộng tác đa dụng 66 Hình 2-24: Mơ hình hóa dựa BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn trực quan) 73 Hình 2-25: Mơ hình hóa dựa BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn XML) 73 Hình 3-1: Phân cấp khối cấu trúc tiến trình 82 Hình 3-2: Ánh xạ số mẫu 83 Hình 3-3: Một sơ đồ tiến trình nghiệp vụ với khối cấu trúc CAB 84 Hình 3-4: Mẫu Sequence 85 Hình 3-5: Mẫu Flow 85 Hình 3-6: Mẫu Switch 85 Hình 3-7: Mẫu Pick 86 Hình 3-8: Mẫu While 86 Hình 3-9: Rút gọn hai “AND fork gateways” nối với 86 Hình 3-10: Rút gọn hai “AND join gateways” nối với 87 Hình 3-11: Rút gọn hai AND gateways khác nối với (AND fork nối với AND join) 87 Hình 3-12 : Tiến trình BPMN 94 Hình 3-13: Đồ thị biểu diễn tiến trình BPMN kết phép duyệt theo chiều sâu (DFS) Ở bước 1, DFS sử dụng để phát vùng chu trình vùng bất chu trình 95 Hình 3-14: Các vùng phát sau bước Ở phát ba vùng: R2 vùng chu trình, cịn R1 R3 hai vùng bất chu trình 95 Hình 3-15: Các vùng phát sau bước (một số nhãn cho nút từ hình trước cố tình bỏ bớt từ hình trở nhằm làm cho hình vẽ đỡ rắc rối hơn) 96 Hình 3-16: Vùng cuối trả R sau bước cuối 3, 96 Hình 4-1: Kiến trúc khung lưới cộng tác 101 Hình 4-2: Cấu trúc modul khung 105 Hình 4-3: Sơ đồ tiến trình BPEL Test-Factory GS-V2 107 Hình 4-4: Lược đồ hai handler 113 Hình 4-5: Tiến trình BPEL thử nghiệm 115 Hình 4-6: Kết chạy tiến trình BPEL 115 Hình 4-7: Luồng cơng việc cho tiến trình xử lý việc nộp cho hội nghị 123 Hình 4-8: Thiết kế chi tiết mơ hình CABAC 124 Hình 4-9: Chức công cụ 129 Hình 4-10: Các bước thực cơng cụ 130 Hình 4-11: Cấu trúc tệp deploy.xml 130 Hình 4-12: Cấu trúc tệp ví dụ 132 Hình 4-13: Workflow tiến trình ví dụ 132 Hình 4-14: Tệp deploy.xml tạo sau công cụ chạy 133 Hình 4-15: Kết chạy ví dụ cơng cụ soapUI 133 DANH MỤC BẢNG Bảng 2-1: Bảng giá trị cho hàm AND 51 Bảng 2-2: Một số kiểu liệu hàm phụ cho giải thuật 2-1 64 Bảng 2-3: Cấu trúc đặc tả hoạt động 67 Bảng 2-4: Đặc tả hoạt động cho hoạt động Học chủ đề 69 Bảng 2-5: Ánh xạ từ thành phần hoạt động sang luồng công việc 71 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) 72 Bảng 4-1: Ánh xạ khối chức vào modul hệ thống 104 Bảng 4-2: Các hàm tiện ích sử dụng CABAC 122 Bảng 4-3: Biểu diễn quy tắc Ví dụ 4-3 122 Bảng 4-4: Một số quy tắc truy nhập cho Ví dụ 4-4 124 Bảng 4-5: Ý nghĩa luồng liệu Hình 4-8 125 Bảng 4-6: So sánh tính mơ hình CABAC mơ hình khác 128 luận án) Chi tiết hai ngôn ngữ luồng cơng việc trình bày chi tiết 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 WMS ngôn ngữ luồng công việc (WL - workflow language) Có nhiều cách tiếp cận khác việc mơ hình hóa thực thi luồng cơng việc điều dẫn đến nhiều loại ngôn ngữ luồng cơng việc khác Ví dụ phép người dùng mơ hình hóa luồng cơng việc, thường yêu cầu ngôn ngữ luồng công việc cần có tính trực quan dễ sử dụng, thường biểu diễn đồ thị Để thực thi luồng công việc, việc sử dụng ngôn ngữ kịch (văn bản) lại phù hợp Do WMS đầy đủ có hỗ trợ mơ hình hóa thực thi luồng cơng việc, thường có nhiều mức biểu diễn luồng công việc, từ mức trừu tượng (sử dụng đồ thị) 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 kịch thường làm tự động bán tự động Có hai hướng tiếp cận WL sử dụng phổ biến hướng luồng liệu hướng tiến trình: - Các WL hướng luồng liệu: đại diện cho cách tiếp cận ngôn ngữ SCUFL (Simple Conceptual Unified Flow Language) sử dụng 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 luồng liệu biến đổi chúng trọng tâm luồng Trong Hình B-2 minh họa việc sử dụng SCUFL để mơ hình hóa luồng cơng việc Taverna, lấy từ ví dụ mẫu luồng cơng việc Taverna phiên 2.3 [92] Trong hình ta thấy liệu vào bắt đầu đưa vào thông qua Workflow Input (luồng liệu vào, cụ thể ID namespace), sau chúng xử lý processor (bộ xử lý) Giữa processor với với thành phần liệu nối với liên kết liệu Cuối cùng, liệu xử lý xong đưa luồng liệu Cách biểu diễn hướng luồng liệu thích hợp dễ dàng cho người dùng khơng có nhiều kinh nghiệm kiến thức tin học, khơng u cầu người dùng phải biểu diễn tường minh chế điều khiển hoạt động phức tạp luồng (như trình tự thu thập liệu, chế xử lý song song,v.v) Thông thường, thứ tự thực thi processor chủ yếu xác định dựa vào sẵn sàng luồng liệu vào Bất kỳ processor mà có luồng liệu vào sẵn sàng xếp lịch để thực thi Các chế xếp lịch ngầm cài đặt workflow engine thành phần chịu trách nhiệm dịch thực thi mô hình luồng mà người dùng thiết kế Do đó, hoạt động song song processor độc lập ngầm định engine quản lý 154 Hình B-2 Một workflow biểu diễn Taverna - Các WL hướng tiến trình: đại diện cho cách tiếp cận ngôn ngữ BPEL (Business Process Execution Language) Trái với WL hướng luồng liệu, thứ tự hoạt động xử lý (hay gọi hoạt động) cần định nghĩa tường luồng điều khiển Đặc biệt thực thi song song xử lý độc lập cần phải đặc tả rõ ràng Ngôn ngữ trình bày chi tiết phần sau Các ngôn ngữ luồng công việc cho lưới GSFL GSFL (Grid Service Flow Language) [97] số ngôn ngữ luồng đề xuất cho môi trường lưới Mục tiêu phát triển GSFL kế thừa kết có hệ thống luồng, sáng tác luồng từ Web Service có, để từ tạo hệ thống luồng hỗ trợ việc sáng tác luồng từ Grid Service Việc phát triển GSFL nhằm mục đích tương thích với chuẩn OGSA (Open Grid Service Architechture) Trong [97] đưa số phân tích yêu cầu riêng biệt luồng công việc 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ả luồng cơng việc cho lưới cần phải cho phép thân luồng công việc xuất dịch vụ (Dịch vụ web Dịch vụ lưới), mô tả cách tương loại dịch vụ Điều cho phép dễ dàng tạo luồng công việc cho lưới cách đệ quy 155 - Bản thân luồng công việc cho lưới cần hỗ trợ chế cho phép dịch vụ thành phần trao đổi liệu/thơng báo trực tiếp với mà không cần luồng công việc đóng vai trị trung chuyển liệu Điều quan trọng, môi trường lưới, kích thước liệu trao đổi thường lớn, nên thiếu chế trao đổi trực tiếp dịch vụ, thân luồng công việc dễ trở thành điểm “cổ chai” cho dịch vụ thành phần đồng thời giảm đáng kể khả thực thi song song dịch vụ Trong OGSA có sử dụng chế notificationSources notificationSinks để giải vấn đề này, nên ngôn ngữ luồng công việc cho lưới nên hỗ trợ chế Tuy nhiên [97], yêu cầu quan trọng ngôn ngữ luồng công việc cho lưới khả hỗ trợ gọi dịch vụ lưới lại không đề cập đến, chủ yếu tận dụng khả gọi dịch vụ web mà ngơn ngữ luồng trước hỗ trợ XLANG WSFL Ngoài ra, dường cịn thiếu cài đặt hồn chỉnh để từ đánh giá hiệu thực thi tính thực tế ngôn ngữ A-GWL A-GWL (viết tắt Abstract Grid Workflow Language) [37] ngôn ngữ luồng mức cao nhằm để mô tả luồng mức logic trừu tượng Ngôn ngữ dựa lược đồ hoạt động ngôn ngữ UML, ngôn ngữ mơ hình hóa hướng đối tượng sử dụng rộng rãi Luồng tạo từ UML, sau tự động chuyển sang A-GWL công cụ gọi Teuta [82] Ưu điểm ngôn ngữ kế thừa khả biểu diễn phong phú lược đồ hoạt động UML, cung cấp đầy đủ thành phần để biểu diễn loại luồng công việc nhiều mức trừu tượng khác nhau, cấu trúc điều khiển luồng (tuần tự song song), luồng liệu, chế đồng hóa hoạt động chế gửi tin nhắc phép dịch vụ trực tiếp gửi thông tin cho (nhất gửi liệu kích thước lớn), khơng cần phải qua trung tâm điều phối (như workflow engine) Tuy nhiên, A-GWL dừng mức mô tả luồng cơng việc mức trừu tượng cịn thiếu khả chuyển đổi sang ngơn ngữ chi tiết để thực thi luồng cơng việc mơ hình hóa GWEL Grid Workflow Execution Language (GWEL) ngôn ngữ luồng công việc nhằm hỗ trợ trực tiếp cho việc kết hợp dịch vụ lưới [26] Tuy nhiên, nghiên cứu dừng ý tưởng khái quát, nhiều chi tiết cú pháp ngôn ngữ, phương pháp kết nối với dịch vụ lưới nào,v.v chưa đề cập đến Trong [103], tác giả đưa khảo sát phân loại chi tiết hệ thống ngôn ngữ luồng công việc cho môi trường lưới Trong số ngôn ngữ luồng cơng việc, có 156 hai ngơn ngữ luận án lựa chọn để biểu diễn cho kế hoạch khung cộng tác, BPMN BPEL Phần tóm tắt số nội dung hai ngôn ngữ B.3 BPEL BPMN BPEL Giới thiệu Các nỗ lực xây dựng dịch vụ Web nhằm đạt tương thông ứng dụng có sử dụng tiêu chuẩn WEB Với mục tiêu đó, mơ hình tích hợp nối kết lỏng lẻo dịch vụ WEB sử dụng phép có tích hợp linh hoạt hệ thống không đồng thuộc lĩnh vực ứng dụng khác Với đặc tả cho dịch vụ WEB SOAP, WSDL, UDDI, ứng dụng khác tìm kiếm tương tác lẫn theo mơ hình nối kết lỏng lẻo độc lập với hạ tầng mà chúng chạy Tuy nhiên, việc tích hợp hệ thống đòi hỏi thêm khả khác không tương tác đơn giản mơ hình dịch vụ Web Mơ hình chủ yếu hỗ trợ tương tác theo kiểu hỏi-đáp thơng tin trạng thái, tương tác chiều khơng có liên hệ Các ứng dụng tiến trình nghiệp vụ thực tế yêu cầu tương tác phức tạp, chúng yêu cầu cần có hỗ trợ mơ hình tích hợp tiến trình nghiệp vụ chuẩn hóa linh hoạt [68] Mơ hình cho tương tác nghiệp vụ thường địi hỏi dãy trao đổi thơng báo ngang hàng, theo kiểu hỏi-đáp chiều có thơng tin trạng thái tương tác thời gian lâu dài hai hay nhiều đối tác tham gia Do vậy, mơ tả hình thức cho giao thức trao đổi thông báo cần thiết để định nghĩa tương tác nghiệp vụ sử dụng tiến trình nghiệp vụ WS-BPEL (Web Services - Business Process Execution Language) đời nhằm mục đích Nó ngơn ngữ tiêu chuẩn cho phép định nghĩa tiến trình nghiệp vụ thông qua việc kết hợp tương tác tiến trình nghiệp vụ (hay dịch vụ) có Khởi đầu có tên BPEL for Web services, BPEL4WS, sau chuyển thành WS-BPEL Gần đây, BPEL trở thành ngôn ngữ chuẩn hóa thơng dụng để cấu thành Web service BPEL dùng để định nghĩa hai loại tiến trình: trừu tượng 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 thực thi được, khai báo tường minh “abstract” Trong đó, tiến trình khả thi đặc tả chi tiết đầy đủ để thực thi WS-BPEL định nghĩa mơ hình cú pháp nhằm mô tả hành vi tiến trình nghiệp vụ dựa tương tác đối tác Những tương tác xuất thông qua giao diện dịch vụ Web cấu trúc quan hệ mức giao diện đóng gói đối tượng gọi liên kết đối tác Tiến trình BPEL xác định 157 tương tác với đối tác phối hợp để đạt mục tiêu nghiệp vụ, trạng thái lơgic cần thiết cho phối hợp Ngồi ra, WS-BPEL đưa vào chế để giải trường hợp ngoại lệ xử lý lỗi, chế bồi thường cho hoạt động nghiệp vụ trường hợp xuất ngoại lệ hay có yêu cầu từ đối tác Các mục tiêu thiết kế BPEL Ban đầu thiết kế BPEL (lúc cịn gọi BPEL4WS (BPEL For Web Services)), nhà thiết kế đề mười mục tiêu cho [33]: - Mục tiêu 1: BPEL4WS định nghĩa tiến trình nghiệp vụ mà tương tác với thực thể bên ngồi thơng qua thao tác dịch vụ WEB định nghĩa chuẩn WSDL 1.1 thân chúng biểu diễn dịch vụ WEB định nghĩa WSDL 1.1 Những tương tác “trừu tượng” theo nghĩa phụ thuộc định nghĩa portType, định nghĩa port - Mục tiêu 2: BPEL4WS định nghĩa 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 biểu diễn đồ thị tiến trình, khơng xác định phương pháp luận cụ thể cho tiến trình - Mục tiêu 3: BPEL4WS nên định nghĩa tập khái niệm phối hợp dịch vụ WEB phương tiện sử dụng hai loại khung nhìn bên ngồi (trừu tượng) bên (khả thi) tiến trình nghiệp vụ - Mục tiêu 4: BPEL4WS nên cung cấp hai chế độ điều khiển theo kiểu phân cấp theo kiểu đồ thị cho phép sử dụng trộn lẫn hai cách cách liền mạch Điều giúp giảm phân mảnh không gian mơ hình hóa tiến trình - Mục tiêu 5: BPEL4WS cung cấp cách giới hạn hàm thao tác liệu cho chúng đủ để thực thao tác liệu đơn giản cho việc định nghĩa liệu liên quan đến tiến trình luồng điều khiển - Mục tiêu 6: BPEL4WS nên hỗ trợ chế định danh cho thể tiến trình mà cho phép xác định định danh thể tiến trình mức thơng báo ứng dụng Định danh thể nên đối tác định nghĩa thay đổi theo thời gian - Mục tiêu 7: BPEL4WS nên hỗ trợ việc sinh kết thúc ngầm định thể tiến trình chế quản lý vòng đời Các thao tác quản lý vòng đời nâng cao tạm dừng, hồi phục bổ sung phiên sau - Mục tiêu 8: BPEL4WS nên định nghĩa mơ hình giao tác thực thi thời gian dài mà dựa kỹ thuật kiểm chứng qua thực tiễn hành động bù đắp phân phạm vi nhằm hỗ trợ việc khắc phục cố cho phần tiến trình nghiệp vụ thực thi thời gian dài 158 - Mục tiêu 9: BPEL4WS nên sử dụng dịch vụ WEB mơ hình để tách ghép tiến trình Kết hợp cách tiếp cận với chuẩn WS-Policy làm mơ hình mạnh mẽ - Mục tiêu 10: BPEL4WS nên xây dựng dựa chuẩn dịch vụ WEB tương thích đề xuất tiêu chuẩn cách tối đa theo cách modul kết hợp Chỉ trường hợp chưa có chuẩn đề xuất phù hợp, đặc tả tương ứng cần phát triển đặc tả BPEL4WS đề xuất tiêu chuẩn Dịch vụ WEB riêng biệt Các khái niệm Có hai cách tiếp cận việc cấu thành dịch vụ Web: orchestration choreography Theo cách orchestration, dịch vụ đóng vai trị dịch vụ gọi dịch vụ khác Thế nên, dịch vụ biết trình tự activity, trạng thái yêu cầu trả lời dịch vụ gọi Ngược lại, cách choreography khơng có dịch vụ Sự phản ứng dịch vụ chế điều phối hỗ trợ BPEL hỗ trợ cách orchestration Trong BPEL, dịch vụ gọi tiến trình nghiệp vụ (Business Process, BP) dịch vụ khác gọi đối tác Có hai loại đối tác BPEL: đối tác gọi đối tác gọi dịch vụ đối tác client đối tác gọi dịch vụ Mối liên kết tiềm tàng đối tác BP gọi liên kết đối tác (Partner Link, PL) Giao diện tiến trình đối tác thông qua portType mà đề xuất thao tác BPEL hỗ trợ hai lớp thao tác: input-only input-output Cấu tạo tiến trình BPEL Các thành phần tiến trình nghiệp vụ mơ tả Hình B-3 Hình B-3 Các thành phần tiến trình nghiệp vụ Trong Hình B-4 đưa tiến trình nghiệp vụ cụ thể thực việc giải phương trình bậc 159 Hình B-4 Tiến trình BPEL giải phương trình bậc Các BPEL engine BPEL engine phân hệ phần mềm có nhiệm vụ thực thi tiến trình nghiệp vụ biểu diễn BPEL Phân hệ thường tích hợp hệ thống phần mềm có hỗ trợ BPEL Phần giới thiệu tóm tắt ba loại BPEL engine sử dụng rộng rãi ActiveBPEL engine, BPEL engine JBI ODE engine Apache ActiveBPEL engine Phiên 5.0 engine cài đặt mã nguồn mở cho BPEL engine, viết JAVA Nó hỗ trợ hai chuẩn BPEL4WS 1.1 WS-BPEL 2.0 Một nhược điểm engine trình khai thác tiến trình BPEL khơng tự động phức tạp việc tạo tệp khai thác BPEL engine JBI Engine tích hợp mơi trường phát triển ứng dụng Netbeans Một hạn chế lớn engine 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) BPEL engine mã nguồn mở Apache Phiên 1.3 có nhiều đặc tính quan trọng như: - Hỗ trợ hai chuẩn BPEL4WS 1.1 WS-BPEL 2.0 Hỗ trợ lớp truyền thông: Web service http transport Axis2 ServiceMix JBI 160 - Nó tích hợp dễ dàng với gần tất lớp truyền thông nhờ giao diện API với engine - Cho phép việc khai thác nhanh tiến trình BPEL Điều có nghĩa cần chép tệp cần thiết vào thư mục khai thác (do engine quy định trước), sau engine chạy tự động phát tệp này, dịch làm chúng sẵn sàng cho việc sử dụng Bản ODE không nhận tất thông tin cần thiết gửi đến từ tiến trình BPEL không hỗ trợ việc gọi dịch vụ lưới Chương khảo sát vấn đề cách chi tiết đưa giải pháp luận án BPMN Giới thiệu BPMN (đầu tiên gọi “Business Process Modeling Notation” phiên [69] Sang phiên 2, đổi thành “Business Process Model & Notation” [70]) hệ thống ký hiệu sử dụng đồ họa, dùng để mơ hình hóa tiến trình nghiệp vụ Nó phát triển BPMI (Business Process Management Initiative) OMG (Object Management Group) với mục đích tạo hệ thống ký hiệu thống dễ hiểu cho tất người sử dụng tiến trình nghiệp vụ, từ người phân tích nghiệp vụ bắt đầu tạo phác thảo cho tiến trình nghiệp vụ, người phát triển công nghệ để cài đặt việc thực thi tiến trình nghiệp vụ BPMN hướng đến mục tiêu tạo tiến trình tự động mà thực thi máy tính, qua việc hỗ trợ tối đa khả chuyển đổi thành tiến trình nghiệp vụ biểu diễn BPEL [99] Hiện nay, BPMN chuẩn hóa hỗ trợ 70 công ty giới, có nhiều cơng ty lớn Trong hệ thống xác định luận án, BPMN lựa chọn làm công cụ để xây dựng kế hoạch (plan), vai trị kế hoạch tiến trình nghiệp vụ dạng khởi đầu Các loại mơ hình BPMN Từ phiên 2, BPMN hỗ trợ ba loại mơ hình: - Tiến trình (hay Orchestration): loại mơ hình lại bao gồm ba loại: Tiến trình nghiệp vụ riêng tư khơng thực thi Tiến trình nghiệp vụ riêng tư thực thi Tiến trình nghiệp vụ cơng - Choreographies - Tiến trình nghiệp vụ cộng tác Ví dụ loại mơ hình cho Hình B-5 – B-8 [70] 161 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 162 Hình B-8 Tiến trình nghiệp vụ cộng tác Các thành phần BPMN Thành phần BPMN “biểu đồ tiến trình nghiệp vụ” (Business Process Diagram - BPD) Nó loại lưu đồ điều chỉnh để mơ hình hóa tiến trình nghiệp vụ Một BPD cấu thành từ nhiều phần tử đồ họa Có nhiều phần tử đồ họa BPMN 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 (Swimlanes) - Các ký hiệu gia công (Artifacts) Các đối tượng luồng Gồm có ba đối tượng BPD Event, Activity Gateway (xem Hình B-9) Hình B-9 Các loại đối tượng luồng - Sự kiện: biểu diễn hình trịn, biểu thị cho điều xảy q trình hoạt động tiến trình nghiệp vụ, gây ảnh hưởng đến luồng hoạt động Có ba loại kiện: Bắt đầu, Trung gian Kết thúc 163 - Hoạt động: thuật ngữ chung để biểu thị cho công việc cần thực Nó biểu diễn hình chữ nhật có góc trịn Có hai loại Hoạt động Nhiệm vụ loại hoạt động nguyên tố Tiến trình loại hoạt động phức mà bên có - chức hoạt động khác Rẽ nhánh: dùng để biểu diễn việc hợp hay tách luồng hoạt động Nó biễu diễn hình thoi Có nhiều loại gateway cung cấp BPMN nhằm biểu diễn nhiều cách điều khiển luồng khác (xem Hình B10) Hình B-10 Các loại gateway BPMN Dữ liệu Có bốn phần tử liệu BPMN (xem B-11 cho cách ký hiệu phần tử): - Đối tượng liệu: biểu diễn thông tin hoạt động sử dụng để thực thi kết chúng tạo - Dữ liệu vào: biểu diễn liệu đầu vào cho tiến trình Dữ liệu ra: biểu diễn liệu đầu cho tiến trình Kho liệu: biểu diễn liệu cần lưu trữ 164 Hình B-11 Các loại phần tử liệu Các đối tượng kết nối Khi đối tượng luồng cần kết nối với nhau, chúng sử dụng đố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 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ác Các công cụ cho phép tổ chức hay chia hoạt động tiến trình thành nhóm Có hai loại BPMN Pool Lane (xem Hình B-13): - Pool: công cụ cho phép chia tiến trình theo nhóm thành viên Mỗi Pool đại diện cho thành viên tiến trình - Lane: công cụ phân chia bên Pool Tức Pool bao gồm nhiều Lane 165 Hình B-13 Các loại Làn Các ký hiệu gia cơng (Artifacts) Ngồi kí hiệu trên, BPMN cịn cho phép người mơ hình cơng cụ phát triển mở rộng thêm thành phần ký hiệu chúng gọi ký hiệu gia cơng Có hai loại ký hiệu gia cơng định nghĩa trước BPMN Nhóm Chú thích (xem Hình B-14) Hình B-14 Các ký hiệu gia công định nghĩa sẵn Một số công cụ hỗ trợ BPMN - Bonita Open Solution: Bonita Open Solution phiên môi trường hỗ trợ BPMN2, mã nguồn mở, sản phẩm hãng BonitaSoft [23] - jBPM: jBPM [46] sản phẩm mã nguồn mở Jboss - Activity BPM 166 PHỤ LỤC C: AXIS Axis2 [4] phiên Axis (Apache eXtensible Interaction System), SOAP engine công cụ phần sụn dịch vụ Web Nó 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) xây dựng dựa bẩy modul cốt lõi Các module khác cốt lõi phân lớp đỉnh modul cốt lõi [4] Trong số bẩy modul cốt lõi, có hai modul Xử lý XML Xử lý SOAP có quan hệ đến nghiên cứu luận án - Modul xử lý XML: xử lý thông báo SOAP nhiệm vụ quan trọng phức tạp Axis2 hiệu nhân tố quan trọng định hiệu Axis2 sử dụng mơ hình AXIOM (AXis Object Model) để cung cấp giao diện lập trình ứng dụng (API) đơn giản nhằm tăng cường hiệu xử lý SOAP XML Axis2 so với Axis - Modul xử lý SOAP: modul kiểm soát thứ tự thực thi xử lý Bên cạnh việc định nghĩa sẵn pha thực thi khác nhau, modul hỗ trợ khả mở rộng cách cho phép người sử dụng mở rộng Mơ hình Xử lý vị trí plug-in đặc biệt Mơ hình Xử lý SOAP minh họa Hình C-1 Hình C-1 Mơ hình Xử lý SOAP Axis2 Hai hoạt động xử lý SOAP gửi nhận thông báo SOAP Để hỗ trợ hoạt động này, kiến trúc cung cấp hai pipe (hay luồng xử lý thông báo) gọi In Pipe (pine nhập) Out Pipe (pipe xuất) Cài đặt cho hai pipe định nghĩa hai phương thức (methods) send() receive() Axis2 engine Khả mở rộng mơ hình xử lý SOAP cung cấp handler Khi xử lý thông báo SOAP, có handler mà đăng ký thực thi Axis2 hỗ trợ ba phạm vi mà handler đăng ký vào toàn cục, dịch vụ thao 167 tác Chuỗi handler cuối tính tốn việc tổng hợp handler từ tất phạm vi Hoạt động chặn, handler xử lý phận thông báo SOAP cung cấp dịch vụ bổ sung Các giai đoạn khác pipe gọi pha (phase), mà cung cấp chế nhằm xác định trật tự handler Một handler chạy pha chuyên biệt Cả hai pipe có pha xây dựng sẵn, chỗ dành cho “các pha người dùng”, đến người dùng định nghĩa 168 ... 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... mơ 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 tốn... 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