1.6.1 Vấn đề còn tồn tại
Từ việc xem xét khái quát ở trên, luận án nhận ra một số vấn đề còn tồn tại cần được tiếp tục nghiên cứu và giải quyết. Mặc dù số lượng và phạm vi của những vấn đề này là khá nhiều và đa dạng, chúng đều liên quan đến vấn đề phát triển khung cộng tác đa dụng trong môi trường tính toán lưới. Ở đây, để tiện cho việc nắm bắt và giải quyết các vấn đề này, luận án phân chia chúng theo nguồn gốc phát sinh. Theo đó, các vấn đề còn tồn tại hiện nay được chia thành hai nhóm:
37
- Nhóm thứ nhất: gồm các vấn đề liên quan đến các mô hình và cách tiếp cận hiện nay về kế hoạch và sự cộng tác. Nhóm này bao gồm các vấn đề sau:
Mối quan hệ phức tạp giữa kế hoạch và sự cộng tác chưa được giải thích rõ ràng. Đa số các lý thuyết chỉ coi kế hoạch như một công cụ cộng tác, và quá trình lập kế hoạch như một công việc kết nối. Tuy nhiên, có thể thấy nguồn gốc của rất nhiều loại hình cộng tác đều xuất phát từ các bản kế hoạch. Hơn nữa bản thân quá trình lập kế hoạch cũng thường là một công việc cộng tác và cũng cần có sự hỗ trợ của các công cụ cộng tác. Việc làm rõ mối quan hệ này có vai trò rất quan trọng trong việc thấu hiểu các khái niệm, để từ đó chúng có thể được hình thức hóa và biểu diễn một cách đúng đắn, đầy đủ và hiệu quả.
Cấu trúc của kế hoạch và sự phát triển của nó cũng chưa được đề cập đến. Khái niệm về kế hoạch xuất hiện dưới rất nhiều dạng khác nhau trong các công việc thực tế: từ một bảng phân công công việc trong một nhóm làm việc, một chu trình sản xuất một sản phẩm, cho đến những kế hoạch phát triển cho một vùng, một quốc gia. Tuy nhiên, cấu trúc chung của chúng, cũng như quá trình hình thành phát triển của chúng như thế nào thì dường như chưa có một lý thuyết nào đề cập đến.
- Nhóm thứ hai: gồm các vấn đề liên quan đến các các khung có hỗ trợ cộng tác hiện nay. Nhóm này bao gồm một số vấn đề sau:
Chỉ có tính chuyên biệt cho từng lĩnh vực: Mỗi khung lưới trên gắn chặt với một lĩnh vực ứng dụng chuyên biệt và điều này làm cho chúng rất khó có thể được sử dụng lại như một khung lưới cho các ứng dụng trong lĩnh vực khác. Ví như hệ thống PATIENT SCHEDULER chỉ nhắm vào các ứng dụng trong điều trị y tế; GCF-MD chỉ hỗ trợ các thiết bị di động và không đi theo kiến trúc mở hướng dịch vụ (SOA);
Thiếu khả năng hỗ trợ kế hoạch: Với đa số các công việc cộng tác, bước đầu tiên là lập kế hoạch để tạo ra một kế hoạch thực hiện, chứa dãy các công việc cần được thực hiện bởi những thành viên phụ thuộc vào vai trò, vị trí của họ. Sau đó, theo kế hoạch, công việc sẽ được phân bổ, được thực thi và được giám sát để nắm được tiến độ thực hiện công việc, từ đó có những bước đánh giá tiếp theo. Thiếu khả năng hỗ trợ kế hoạch sẽ rất khó khăn để nắm được tiến độ công việc cũng như hỗ trợ sự cộng tác, và quan trọng hơn là thay đổi kế hoạch một khi nó đang được triển khai. Ví dụ các hệ thống OCGSA, LAGrid, CDG, GCF-MD đều thiếu khả năng hỗ trợ kế hoạch.
Thiếu khả năng hỗ trợ việc thực thi tự động trong môi trường lưới: Sau khi xây dựng kế hoạch thực hiện các công việc (hay còn được gọi là tiến trình nghiệp vụ), nhu cầu đặt ra là làm thế nào để thực thi được các công việc đó theo kế hoạch đã đề ra. Điều này đòi hỏi trước tiên phải tìm được những đối tượng/đối tác phù hợp với các công việc. Sau đó tiến hành phân công công việc cho họ, rồi giám sát tiến độ của việc thực thi. Vấn đề này trở nên khó khăn hơn khi muốn tự động hóa quá trình này trong môi trường lưới. Do một trong những đặc thù của môi trường này là tính động của các đối tượng tham gia (các đối tượng có thể
38
tham gia hoặc rời khỏi môi trường một cách tùy ý mà không có nhiều ràng buộc), nên việc quản lý được từng đối tượng cũng không phải là việc dễ dàng. Chưa hỗ trợ gọi dịch vụ lưới từ tiến trình BPEL: Do hoạt động trong khung cộng
tác sẽ được biểu diễn bằng ngôn ngữ luồng BPEL, nên hạn chế này sẽ ảnh hưởng đến việc thực thi hoạt động trong môi trường lưới. Để thi hành các tiến trình BPEL, cần có các BPEL engine. BPEL engine được chọn trong luận án là ODE của Apache, do nó là một trong số các engine mã nguồn mở và có hỗ trợ khá tốt. Tuy nhiên, engine này lại có hạn chế là chưa hỗ trợ việc gọi dịch vụ lưới, mà mới chỉ hỗ trợ gọi dịch vụ Web. Có một BPEL engine khác tuy không có hạn chế này là ActiveBPEL, nhưng nó lại không phải là mã nguồn mở nữa. Do vậy, ODE là lựa chọn duy nhất và luận án sẽ đưa ra biện pháp khắc phục hạn chế này. Việc khai thác tiến trình BPEL còn phức tạp và thủ công: Để khai thác một tiến
trình BPEL trong ODE, một loạt các bước cần được tiến hành. Đầu tiên, các Partner Link phải được tạo ra từ các tệp WSDL và từ bản thân tiến trình BPEL. Ngoại trừ một Parner Link mà đại diện cho các thực thể sẽ sử dụng tiến trình BPEL, các Parner Link khác đại diện cho các Web service bên ngoài mà sẽ được gọi (invoke) trong tiến trình BPEL. Sau đó, một tệp khai thác đặc thù (có tên là deploy.xml) phải được tạo ra tuân theo đặc tả cấu trúc của ODE. Cuối cùng, tất cả các tệp cần thiết liên quan đến tiến trình BPEL sẽ được copy vào một thư mục đặc thù và rồi chúng sẽ được kiểm tra lỗi và biên dịch. Nếu có lỗi được phát hiện, (đây là tình huống thường xảy ra), log tệp của Web server đang hosting ODE sẽ được kiểm tra một cách thủ công để tìm thông báo lỗi và từ đó tìm nguyên nhân lỗi. Dù việc biên dịch có thành công, lỗi chạy (runtime error) vẫn có thể tồn tại, quá trình kiểm tra và đoán lỗi sẽ phải lặp đi lặp lại cho đến khi tìm ra.
1.6.2 Tiếp cận
Nghiên cứu của luận án nhằm giải quyết các vấn đề trên. Tiếp cận trong luận án bao gồm:
- Đối với nhóm vấn đề thứ nhất: vì nhóm này liên quan đến các vấn đề lý thuyết, nên một mô hình cải tiến từ Lý thuyết Hoạt động, với tên gọi Mô hình Kế hoạch, đã được phát triển. Chi tiết về Mô hình Kế hoạch và yêu cầu tổng quan của khung cộng tác dựa trên mô hình này được trình bầy trong Chương 2.
- Đối với nhóm vấn đề thứ hai: vì nhóm này liên quan đến việc phát triển khung lưới cộng tác đa dụng, nên một loạt các giải pháp liên quan đến các vấn đề này sẽ được luận án đề xuất. Từ việc xác định các yêu cầu tổng thể của khung được trình bày trong Chương 2, sau đó là làm mịn các kế hoạch được trình bầy trong Chương 3 và đến cuối cùng là các giải pháp thiết kế và cài đặt khung được trình bày trong Chương 4.
39
CHƯƠNG 2: MÔ HÌNH KẾ HOẠCH VÀ KHUNG
CỘNG TÁC ĐA DỤNG
Đầu chương này sẽ giới thiệu về Mô hình kế hoạch, dựa trên mô tả hình thức các thành phần của hoạt động theo tiếp cận của Lý thuyết Hoạt động. Sau đó, luận án trình bày mô tả hình thức khái niệm kế hoạch, nhằm làm rõ vai trò, cấu tạo, quy luật phát triển của kế hoạch, quan hệ giữa kế hoạch và cộng tác. Luận án đề xuất Mô hình kế hoạch tương đối hoàn chỉnh. Trên cơ sở đó các yêu cầu của một khung cộng tác đa dụng có hỗ trợ kế hoạch được đề xuất. Kết quả nghiên cứu về mô hình kế hoạch và khung cộng tác đa dụng đã được công bố trong [15][16].
2.1 Mô hình kế hoạch
2.1.1 Các khái niệm cơ bản
Khái niệm về hoạt động đã được đề cập trong Chương 1, trong đó mỗi hoạt động gồm ba thành phần cơ bản là chủ thể, công cụ và đối tượng, nhằm biểu diễn cho ý nghĩa khái quát của các hoạt động có chủ đích. Để tiện cho việc biểu diễn các loại hoạt động, chúng được chia làm hai loại:
- Hoạt động đơn (Single Activity): là hoạt động không chứa các hoạt động con khác, được mô tả bởi các thành phần cơ bản là chủ thể, công cụ và mục tiêu (chi tiết về cấu trúc của hoạt động đã được trình bày ở phần 1.1.3).
- Hoạt động tập thể (Collective Activity): là hoạt động chứa hai hay nhiều hoạt động con. Do sự xuất hiện của nhiều hoạt động con, nên cần có quan hệ thứ tự bộ phận, nhằm xác định thứ tự thực thi giữa chúng.
Định nghĩa 2-1: Hoạt động (Activity): được định nghĩa như sau: Activity ::- Single | Collective(L, R);
Single ::- Atomic(S, T, O) | Abstract(O) |AbstractT(S, O) | AbstractS(T, O);
Trong đó:
- S, T, O tương ứng là chủ thể (Subject), tài nguyên hay công cụ (Tool) được sử dụng bởi chủ thể S và mục tiêu (Objective)/đối tượng (Objective) của hoạt động. - Single: biểu thị một hoạt động đơn. Nó có thể ở một trong hai dạng cụ thể:
Atomic(S, T, O) là hoạt động nguyên tố, nghĩa là chủ thể S sử dụng công cụ T để tạo ra đối tượng O. Hoạt động Abstract(O) là hoạt động trừu tượng mới chỉ có mục tiêu, chưa có chủ thể thực hiện cũng như công cụ cần thiết để thực thi được hành động đó. Tương tự, hai dạng hoạt động còn lại AbstractT (S, O) và AbstractS (T, O)
cũng là hoạt động trừu tượng trong đó vẫn thiếu một trong các thành phần chủ thể hoặc công cụ.
40
- Collective(L, R): là hoạt động tập thể, chứa các hoạt động con L= {A1, A2, ..., An} và thành phần R là tập các quan hệ phụ thuộc r(Ai, Aj) giữa các cặp hoạt động (Ai, Aj) (Ai, Aj ∈ L) (các quan hệ phụ thuộc này sẽ được giải thích rõ hơn ở phần định nghĩa 2.3). Từ tập các quan hệ này ta có thể suy ra mối quan hệ giữa tất cả các hoạt động con, do đó xác định được thứ tự thực thi của chúng trong hoạt động tập thể.
Chú thích: Để gọi tên các hoạt động được thống nhất và tường minh, ta sẽ ký hiệu các
hoạt động đơn như sau: Atomic(S, T, O) được thay bằng Tên(S, T, O); Abstract(O) được thay bằng Tên(, , O); AbstractT (S, O) được thay bằng Tên(S, , O); AbstractS(T, O) được thay bằng Tên(, T, O);
Ví dụ 2-1: Hoạt động Học(Sinh viên, Môn học, Kết quả) biểu diễn cho loại hoạt động Atomic(S, T, O); hoạt động Học(, Môn học, Kết quả) biểu diễn cho loại hoạt động AbstractS (T, O); hoạt động Học(Sinh viên, , Kết quả) biểu diễn cho loại hoạt động AbstractT(S, O); và hoạt động Học(, , Kết quả) biểu diễn cho loại hoạt động Abstract(O).
Hình 2-1 (còn được gọi là sơ đồ hoạt động) minh họa các thành phần của một hoạt động đơn.
Hình 2-1: Cấu trúc của một hoạt động đơn
Ý nghĩa của hoạt động: Một hoạt động A(S,T,O) có thể mang nhiều ý nghĩa khác nhau tùy thuộc vào các ngữ cảnh khác nhau. Tuy nhiên, có thể đưa ra diễn giải chung như sau: Sử dụng công cụ T, chủ thể S muốn tạo ra mục tiêu (còn gọi là đối tượng) O. Có thể xảy ra trường hợp, S có thể tạo ra O mà không cần có công cụ nào (T=∅). Mô hình này nhằm biểu diễn các hoạt động có chủ đích nhằm đạt được mục tiêu nào đó của chủ thể. Mô hình này cũng giúp trả lời ba câu hỏi cơ bản của mọi hoạt động:
- Làm cái gì? Đối tượng O là mục tiêu của hoạt động. Đối tượng này có thể là cụ thể
như cái bàn, cái ghế, máy tính,v.v hoặc trừu tượng như tri thức hay sở thích nào đó. - Làm như thế nào? Sử dụng công cụ T và các quan hệ R. Để đạt được đối tượng O, điều quan trọng là chỉ rõ cách thức đạt được, thông qua mô tả tường minh các công cụ T cách sử dụng chúng gắn với các quan hệ R. Với mô tả này, hoạt động sẽ đóng vai trò như một bản kế hoạch, trong đó xác định các bước cần làm để đạt được mục tiêu. Trong trường hợp công cụ T chưa tồn tại, hoạt động A ban đầu phải tham chiếu đến một hoạt động AT, nhằm phát hiện hoặc tạo ra công cụ T, sau đó dùng T
S T O (2) (1) (3)
41
trong hoạt động A để thu được O. Điều này có nghĩa là một hoạt động có tính lồng nhau (nesting), tức là có thể chứa các hoạt động khác.
- Ai thực hiện? Chủ thể S, chịu trách nhiệm thực thi hoạt động. Khi xem xét hoạt động trong một kế hoạch, chủ thể cho phép xác định các tác nhân tham gia trong quá trình hoàn thành kế hoạch.
Từ Hình 2-1, ý nghĩa của các liên kết giữa các thành phần trong một hoạt động có thể được hiểu như sau:
- Liên kết (1): Hành động của chủ thể là nhằm đạt được đối tượng O. Liên kết này biểu diễn mục đích chính của hoạt động.
- Liên kết (2): Chủ thể phải có thông tin về công cụ trước sử dụng. Ngoài ra, chủ thể phải biết qui trình sử dụng công cụ để tạo ra đối tượng.
- Liên kết (3): Biểu thị chuyển đổi đặc biệt từ công cụ sang đối tượng đích.
Hình 2-2 biểu diễn một góc nhìn khác (góc nhìn chức năng hay góc nhìn hộp đen của hoạt động đơn A(S, T, O)). Với góc nhìn này, chủ thể và công cụ đóng vai trò đầu vào và đối tượng đóng vai trò đầu ra. Còn tất cả các quan hệ giữa các thành phần trên đều bị ẩn. Như vậy so với góc nhìn này, góc nhìn ở Hình 2.1 có thể được gọi là góc nhìn hộp trắng, qua đó mọi quan hệ bên trong giữa các thành phần đều được diễn tả tường minh. Với góc nhìn hộp trắng, lý thuyết hoạt động chỉ ra một nguyên tắc rất quan trọng. Đó là không chỉ quan tâm đến đầu vào, đầu ra của hoạt động, mà quan tâm đến cả quá trình làm thế nào để biến đổi từ đầu vào đến đầu ra và diễn tả tường minh. Điều này có ý nghĩa rất quan trọng trong các ứng dụng, đòi hỏi sự tường minh trong quá trình thực hiện như lập kế hoạch, điều trị y tế, v.v.
Hình 2-2: Góc nhìn chức năng của một hoạt động đơn A(S,T,O)
Từ góc nhìn chức năng, một biểu diễn trực quan của hoạt động đơn được đưa ra, như trong Hình 2-3, sẽ được sử dụng trong luận án.
Hình 2-3: Biểu diễn một hoạt động đơn.
A O
T S
42
Định nghĩa 2-2: Cho trước một hoạt động A. - subject(A): trả về tập chủ thể của A: ( ) = ⎩ ⎪ ⎪ ⎨ ⎪ ⎪ ⎧{ } ế = ( , , ) ℎ ặ ( , ); ∅ ế = ( ) ℎ ặ ( , ); ( ) ∈ ế = ( , ), ớ = ( , , … , ); - tool(A): trả về tập công cụ của A:
( ) = ⎩ ⎪ ⎪ ⎨ ⎪ ⎪ ⎧{ } ế = ( , , ) ℎ ặ ( , ); ∅ ế = ( ) ℎ ặ ( , ) ( ) ∈ ế = ( , ), ớ = ( , , … , ); - objective(A): trả về tập mục đích của A: ( ) = ⎩ ⎪ ⎨ ⎪ ⎧{ } ế à ℎ ạ độ đơ ; ( ) ∈ ế = ( , ), ớ = ( , , … , );
Định nghĩa 2-3: Quan hệ phụ thuộc giữa hai hoạt động A1 và A2:
- Chung đầu vào (common-in): hai hoạt động có chung một hoặc cả hai đầu vào. Hình 2-4 minh họa cho loại phụ thuộc này.
common-in(A1, A2) := subject(A1) = subject(A2) | tool(A1) = tool(A2) | subject(A1) = subject(A2) and tool(A1) = tool(A2);
- Vào-ra (in-out): đầu ra của hoạt động này là đầu vào của hoạt động kia. in-out(A1, A2): đầu ra của A1 là đầu vào của A2. Hình 2.5 minh họa cho loại phụ thuộc này.
in-out(A1, A2) := objective(A1) = subject(A2) | objective(A1)=tool(A2);
- Rẽ nhánh (switch): Mỗi thời điểm chỉ có duy nhất một hoạt động được thực hiện. Việc lựa chọn hoạt động nào sẽ phụ thuộc vào một điều kiện logic C nào đó. Quan hệ này còn có tên gọi khác như loại trừ (exclusion) hay lựa chọn (selection).
ℎ( , , ) ≔ ế đú
43
Có thể mở rộng biểu diễn các trường hợp rẽ một nhánh và nhiều nhánh. Ví dụ rẽ một nhánh cho hoạt động A theo điều kiện C được biểu diễn bởi switch(A, _, C), với “_” là biểu diễn cho một hoạt động rỗng.
- Đồng bộ (synchronization): synch(A1, A2) hai hoạt động A1 và A2 này phải kết thúc trước khi thực hiện các hoạt động khác. Hai hoạt động cần phải được đồng bộ,