Tài liệu Khung cộng tác đa dụng trong môi trường tính toán lưới [tt]

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 (CSCW)) [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 một hệ hình thức (formalism). Điều này dẫn đến một số vấn đề: 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 1 (plan),v.v); các 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 đá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. 2. 3. 4. Kế hoạch là gì? Mối quan hệ giữa kế hoạch và các hành động (action) để thực thi kế hoạch đó? Mối quan hệ giữa các kế hoạch trong cùng một hoạt động là gì? 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. Để đánh giá tính khả thi của Mô hình Kế hoạch, cần phải thử nghiệm trong một số môi trường ứng dụng cụ thể. Trong nghiên cứu của luận án bước đầu triển khai thực nghiệm trong Môi trường Tính toán lưới. Trong môi trường này sẽ áp dụng Mô hình Kế hoạch, thiết kế xây dựng hệ thống hỗ trợ quản lý các kế hoạch, gọi là khung cộng tác đa dụng. 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 để có thể cài đặt được khung cộng tác, qua đó có thể đánh giá tính thực tiễn của Mô hình Kế hoạch. Do 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ý 2 tài nguyên không đồng nhất và phân tán, nên rất phù hợp để triển khai khung cộng tác, 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 [105], Grid-based Cooperative Work Framework (GCWF) [104]. 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. - 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. 3 - 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. Các kết quả nghiên cứu Nghiên cứu của luận án hướng tới 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 các hạn chế của các hệ thống lưới hiện tại. Hệ thống được đề xuất cho phép hỗ trợ khả năng cộng tác, tạo ra các kế hoạch công việc, hỗ trợ tối đa việc thực hiện tự động 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át triển của các ứng dụng lưới, nhất là những ứng dụng có tính cộng tác cao 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). 4 CHƢƠNG 1: TỔNG QUAN 1.1. Các kiến thức nền tảng liên quan đến kế hoạch và cộng tác Trong phần này, cơ sở lý luận liên quan đến cộng tác và kế hoạch sẽ được chỉ ra, 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], 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ể đó. 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]. 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: - 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 tạo 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 5 - 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. Thứ hai: Đây là hệ quả của vấn đề thứ nhất. 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. 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. 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). 1.1.2. Lý thuyết Hoạt động Khái niệm hoạt động theo tiếp cận lý thuyết hoạt động Một hoạt động được xem xét một cách toàn diện với các thành phần nội tại và các động lực của nó. 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 11). 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. Sự trợ giúp trung gian (mediation) được thực hiện thông qua một công cụ. Một đối tượng có thể là một kế hoạch, một ý tưởng được các chủ thể chia sẻ, thao tác hay chuyển đổi [51]. 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 đề 6 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: - 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.  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. - 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:  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:  Chưa hỗ trợ gọi dịch vụ lưới từ tiến trình BPEL:  Việc khai thác tiến trình BPEL còn phức tạp và thủ công: 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. 7 CHƢƠNG 2: MÔ HÌNH KẾ HOẠCH VÀ KHUNG CỘNG TÁC Đầ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. 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). 8 2.1.3 Phụ thuộc khả thi Đị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; 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 thì ở đây, 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 khả thi. - Tính phản xạ: với mọi hoạt động A thì hiển nhiên ta có A → A. - 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. - 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. Các tính chất riêng của phụ thuộc khả thi 1. 2. 3. 4. Atomic(S,T,O) → Abstractt (S,O); Atomic(S,T,O) → Abstracts (T,O); Abstractt (S,O) → Abstract(O); Abstracts (T,O) → Abstract(O); 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; 6. Nếu C({A_1,A_2,...,A_n},R) là hoạt động tập thể chính quy thì (A1,An) ⇀ C; 7. Cho C({A1, A2,...,An}, R) là một hoạt động tập thể chính quy. Khi đó  một hoạt động đơn A(S,T,O) sao cho C → A. 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; 9 9. Cho C({A1, A2, ..., An}, R) là một hoạt động tập thể chính quy. 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 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ả: 1. 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. 2. 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. 3. 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’; 2.1.4 Kế hoạch Định nghĩa 2-8: Kế hoạch (plan): một 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, 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). PTKT cũng 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; 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. 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. 10 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). 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-16: Biểu diễn kế hoạch không khả thi bằng đồ thị VÀ/HOẶC. 11 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: Kết quả kiểm tra P là khả thi (FEASIBLE) hoặc chưa xác định (UNKNOWN). Xử lý: 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 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 Đị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: Quản lý kế hoạch: 12 - Làm mịn: Thực thi: Hình 2-23: Tổng quan về Khung Cộng tác. Tổng quan về Khung Cộng tác được minh họa ở Hình 2-23. Như có thể thấy trong hình vẽ nà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ể thi hành được, rồi thi hành và giám sát kế hoạch. 2.2.2. Mô tả các hoạt động Trong phần này, chúng tôi 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 Bảng 2-2 biểu diễn cấu trúc của một đặc tả hoạt động bao gồm các trường thông tin cần thiết. Bảng 2-2: 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 Công cụ Chủ thể Liên kết Diễn giải 13 Mô hình hóa dựa trên luồng công việc Phần này sẽ xem xét việc áp dụng 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 mà chúng tôi chọn trong nghiên cứu này là BPMN (Business Process Modelling Notations) và BPEL (Business Process Execution Language), thì 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ụ mà 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 thi hành vật lý - chúng có thể được tự động thi hành nhờ các BPEL engine phù 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: - Nó 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. Và 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. Vì chúng tôi 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-4 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 (bản tóm tắt chỉ đưa ra một phần của bảng). Bảng 2-4: Á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) 14 Chú thích/Ký hiệu Hoạt động A(S,T,O) đơn Task (nhiệm vụ) 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 Hoạt động tập thể Process (tiến trình) Cách đầy đủ 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ụ Các Gateway và Các quan hệ phụ thuộc giữa một cặp thuộc Connecting Object 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. 15 CHƢƠNG 3: LÀM MỊN KẾ HOẠCH 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: - 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. 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 biểu diễn bằng ngôn ngữ BPMN thì nó có thể không thực 16 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. 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.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 [79][3][65][70][49][74]. 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 17 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. 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. 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. 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 các mẫu có cấu trúc đầy đủ 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 mà 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: - Đầu ra: Xử lý: 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. 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 mà biểu diễn cho các mẫu nhỏ hơn. 1. Xác định các vùng trong tập L. Ở giai đoạn này, mỗi vùng mới chỉ chứa hai đỉnh: một vào và một ra. 18 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. 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ự, 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. Định lý 3-8: Giải thuật 3-2 là đúng đắn và đầy đủ. Đị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 4: THIẾT KẾ VÀ CÀI ĐẶT KHUNG CỘNG TÁC 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. 19 4.1. Các yêu cầu của khung Các yêu cầu cơ bản của khung đã được xác định sơ bộ ở phần 2.2.1. Ngoài ra, để đá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ý: ˗ Sự không đồng nhất của các hệ thống thực thi bên dưới: 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 chung 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 đó. Hình 4-1: Kiến trúc Khung lưới cộng tá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. 4.2.2 Thiết kế modul 20