Luận án Môi trường Tính toán lưới

(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. 141 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 e- Lab”, 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 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 417- 432. 75. ODE Apache, version 1.3.5 (2011), at 76. Papakhian M (1998), Comparing job-management systems: the user’s perspective, IEEE Computational Science and Engineering, Vol 5(2), pages 4-9. 142 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 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 problem- solving 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 org/packs/192.html. 93. The Globus Security Team (2005), Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective, Technical report. 143 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 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 Process_Modeling_Notation_tools. 101. W3C Working Group (2004), Web Services Architecture at 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. 144 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) 145 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á 146 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 147 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 148 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. 149 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). 150 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 151 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 152 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ý. 153 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. 154 - 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ó 155 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 156 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. 157 - 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. 158 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. 159 - 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]. 160 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. 161 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. 162 - 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 B- 10). 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ữ. 163 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. 164 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 165 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 166 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.