Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 24 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
24
Dung lượng
583,91 KB
Nội dung
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
Chủ thể
Công cụ
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
Kiến trúc của khung cộng tác ở trên được chia thành một số modul như sau (Hình
4-2):
Hình 4-2: Cấu trúc các modul của khung cộng tác.
Bảng 4-1 mô tả việc ánh xạ các khối chức năng của khung cộng tác vào các modul
hệ thống trình bày ở trên.
Bảng 4-1: Ánh xạ các khối chức năng vào các modul hệ thống.
Khối chức năng
Modul
Quản Lý VO và nhóm.
VO and Group Management Modul (VGMM).
Lập kế hoạch hoạt động.
Activity Planning Modul (APM): Sử dụng BPMN làm ngôn ngữ
mô tả kế hoạch.
Phân công hành động.
Activity Planning Modul (APM) và Activity Execution Modul
(AEM): Sử dụng công cụ để dịch từ BPMN sang BPEL.
Lựa chọn tài nguyên và công cụ. Activity Execution Modul (AEM): Sử dụng BPEL làm ngôn
ngữ mô tả việc thực thi kế hoạch ở trên.
Kho chứa các công cụ cộng tác.
Tích hợp trong APM và AEM.
Cho chạy và giám sát.
Workflow engine tích hợp trong AEM & Hạ tầng lưới.
Thư mục tài nguyên.
Hạ tầng lưới.
4.3. Cài đặt Khung
Phần này sẽ trình bày các kết quả cài đặt bước đầu cho khung lưới cộng tác đa
dụng, gồm các cài đặt chính như sau:
21
- Giải pháp gọi Dịch vụ lưới từ tiến trình BPEL. Tuy nhiên, giải pháp còn hạn
chế là mới chỉ gọi được các dịch vụ lưới không an toàn, chứ chưa gọi được các
dịch vụ lưới an toàn. Hạn chế này được khắc phục trong một giải pháp được nói
đến ngay sau đây. Kết quả này đã được công bố trong [13][9].
- Giải pháp mở rộng mô hình điều khiển truy nhập cho các hệ thống luồng công
việc trong môi trường lưới. Giải pháp nhằm hoàn thiện hơn giải pháp gọi dịch
vụ lưới ở trên với việc cho phép gọi các dịch vụ lưới an toàn.
- Giải pháp tự động hóa khai thác tiến trình BPEL, với kết quả đã được công bố
trong [11].
KẾT LUẬN
Các đóng góp khoa học của đề tài
Các đóng góp khoa học trong nghiên cứu của luận án có thể được tóm tắt vào
những nội dung chính như sau:
1. Hình thức hóa và phát triển Lý thuyết Hoạt động để hướng đến một mô hình
biểu diễn một cách rõ ràng hơn về kế hoạch và cộng tác (gọi là Mô hình Kế
hoạch). Một mặt, việc hình thức các khía cạnh trong Lý thuyết Hoạt động sẽ
giúp làm rõ hơn các phần chưa rõ ràng, cũng như bổ sung thêm một số phần
còn thiếu trong lý thuyết. Mặt khác, mô hình kế hoạch được đề xuất cũng cho
phép kết nối thành tố trong Lý thuyết Hoạt động với kỹ thuật luồng công việc
nhằm biểu diễn kế hoạch ở cả hai khía cạnh hình thức và trực quan. Mô hình
cũng cho phép các kế hoạch có thể được biểu diễn, được làm mịn và cuối
cùng được thực thi (có thể là thực thi tự động). Kết quả này đã được đăng
trong [15][16].
2. Xác định rõ các vấn đề còn tồn tại với các khung lưới cộng tác hiện nay, để
từ đó đề xuất một khung lưới cộng tác mới có Hỗ trợ Kế hoạch thông qua
việc kết nối những ý tưởng chính của Lý thuyết Hoạt động với tính toán lưới.
Khung cho phép tạo mới hoặc cập nhật các kế hoạch có tính cộng tác. Mục
tiêu là cung cấp khung lưới đa dụng hỗ trợ cho những công việc cộng tác có
thể áp dụng trong nhiều lĩnh vực ứng dụng khác nhau. Một số modul chính
của khung lưới cộng tác đã được cài đặt. Kết quả này đã được đăng trên
[10][14][12].
3. Trong quá trình làm mịn kế hoạch, đã phát hiện một số vấn đề còn tồn tại
trong lĩnh vực dịch ngôn ngữ luồng, nhất là vấn đề chuyển từ ngôn ngữ
hướng đồ thị sang ngôn ngữ hướng cấu trúc. Đã đề xuất giải thuật tìm ra các
mẫu trong ngôn ngữ hướng đồ thị, chuyển nó sang các thành phần tương ứng
trong ngôn ngữ hướng cấu trúc. Hai ngôn ngữ luồng đại diện là BPMN và
22
BPEL đã được lựa chọn để minh họa cho giải thuật. Kết quả này đã được
đăng trong [17].
4. Xây dựng một mô hình điều khiển truy nhập mới, đáp ứng các yêu cầu truy
nhập của cả hai hệ thống là hệ thống luồng công việc và hệ thống lưới. Được
mở rộng từ mô hình điều khiển truy nhập dựa trên thuộc tính ABAC
(attribute-based access control model), mô hình của chúng tôi hỗ trợ cả hai
loại thuộc tính đơn và phức hợp. Ngoài ra, mô hình được đề xuất trong luận
án cũng đáp ứng được cả hai yêu cầu thường mâu thuẫn nhau trong các hệ
thống điều khiển truy nhập. Đó là yêu cầu về tính đơn giản của việc biểu diễn
các quy tắc truy nhập và yêu cầu về tính đầy đủ về khả năng biểu diễn các
quy tắc này. Một thiết kế chi tiết về cấu trúc modul của mô hình, tuân theo
chuẩn XACML của các hệ thống điều khiển truy nhập, cũng đã được luận án
đề xuất.
5. Đưa ra một giải pháp hoàn chỉnh cho việc tự động hóa khai thác tiến trình
BPEL trong môi trường ODE. Giải pháp đã được cài đặt bằng JAVA và thử
nghiệm thành công với các loại tiến trình khác nhau. Ý nghĩa của giải pháp là
cho phép những người phát triển các tiến trình BPEL tiết kiệm được rất nhiều
thời gian và công sức trong việc cấu hình để khai thác các tiến trình BPEL.
Kết quả này đã được đăng trong [11].
6. Tìm hiểu rõ nguyên nhân của vấn đề không thể gọi được các dịch vụ lưới từ
tiến trình trong môi trường ODE, từ đó đưa ra giải pháp hiệu quả, đơn giản và
khả thi để giải quyết vấn đề này. Ý nghĩa của giải pháp là cho phép các dịch
vụ lưới khác nhau có thể được kết hợp trong Grid/Workflows có cấu trúc sử
dụng BPEL và được gọi thông qua cơ sở hạ tầng lưới nằm bên dưới. Điều đó
ngầm chứa khả năng cho phép dãy các công việc phức tạp có thể được kết
hợp và thực thi tự động trên môi trường tính toán lưới, thay vì chỉ thực hiện
các yêu cầu tính toán lưới đơn giản. Kết quả này đã được đăng trên [9][13].
Các công trình đã công bố, các kết quả nghiên cứu của luận án đã được công bố
trong sáu hội nghị khoa học quốc tế [11] [12] [13] [17] [15][16] và ba tạp chí chuyên
ngành [14] [9] [10].
Vai trò và mối quan hệ giữa các kết quả nghiên cứu của luận án đối với quá trình
phát triển khung cộng tác được biểu diễn tóm tắt trong hình dưới đây. Trong hình này,
phần trung tâm là kiến trúc tổng quan của khung cộng tác (đã được mô tả trước đây ở
Hình 2-23), các mô tả ở xung quanh là tóm tắt các kết quả nghiên cứu, và các mũi tên
nét đứt biểu diễn vai trò của kết quả nghiên cứu với bộ phận của khung cộng tác.
23
Tổng hợp về các kết quả đã đạt được của luận án.
Hạn chế của đề tài và hướng nghiên cứu tiếp theo
Mặc dù đã hết sức cố gắng, nhưng luận án vẫn còn một số vấn đề cần giải quyết để
có thể đạt đến một hệ thống hoàn chỉnh. Các vấn đề này bao gồm:
1. Mô hình kế hoạch đã được đề xuất chưa hoàn chỉnh: mô hình còn chưa giải
quyết vấn đề khái quát hóa kế hoạch. Vấn đề tự động suy diễn các kế hoạch mới
từ các kế hoạch hiện có cũng là vấn đề thú vị mà mô hình chưa đề cập đến.
2. Thiếu một công cụ hoàn chỉnh để dịch các kế hoạch viết bằng BPMN sang
BPEL, từ đó có thể tự động hóa việc thực thi các kế hoạch. Nghiên cứu mới
dừng lại ở việc đề xuất một giải thuật, nhưng còn thiếu cài đặt để đánh giá về
mặt thực tế khả năng áp dụng của giải thuật.
3. Thiếu cài đặt đầy đủ cho toàn bộ khung cộng tác, nên chưa thể đưa nó áp dụng
vào các nghiệp vụ thực tế.
Việc giải quyết các vấn đề còn tồn tại ở trên là các nội dung nghiên cứu hy vọng có
thể tiến hành trong tương lai.
24
[...]... đăng trong [15][16] 2 Xác định rõ các vấn đề còn tồn tại với các khung lưới cộng tác hiện nay, để từ đó đề xuất một khung lưới cộng tác mới có Hỗ trợ Kế hoạch thông qua việc kết nối những ý tưởng chính của Lý thuyết Hoạt động với tính toán lưới Khung cho phép tạo mới hoặc cập nhật các kế hoạch có tính cộng tác Mục tiêu là cung cấp khung lưới đa dụng hỗ trợ cho những công việc cộng tác có thể áp dụng trong. .. 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. .. 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... 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ừ... AEM & Hạ tầng lưới Thư mục tài nguyên Hạ tầng lưới 4.3 Cài đặt Khung Phần này sẽ trình bày các kết quả cài đặt bước đầu cho khung lưới cộng tác đa dụng, gồm các cài đặt chính như sau: 21 - Giải pháp gọi Dịch vụ lưới từ tiến trình BPEL Tuy nhiên, giải pháp còn hạn chế là mới chỉ gọi được các dịch vụ lưới không an toàn, chứ chưa gọi được các dịch vụ lưới an toàn Hạn chế này được khắc phục trong một giải... phép 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... 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 Kiến trúc của khung cộng tác ở trên được chia thành một số modul như sau (Hình 4-2): Hình 4-2: Cấu trúc các modul của khung cộng tác Bảng 4-1 mô tả việc ánh xạ các khối chức năng của khung cộng tác vào các modul hệ thống trình bày ở trên Bảng 4-1: Ánh xạ các khối chức năng vào... trong môi trường ODE, từ đó đưa ra giải pháp hiệu quả, đơn giản và khả thi để giải quyết vấn đề này Ý nghĩa của giải pháp là cho phép các dịch vụ lưới khác nhau có thể được kết hợp trong Grid/Workflows có cấu trúc sử dụng BPEL và được gọi thông qua cơ sở hạ tầng lưới nằm bên dưới Điều đó ngầm chứa khả năng cho phép dãy các công việc phức tạp có thể được kết hợp và thực thi tự động trên môi trường tính. .. đượ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à... được công bố trong [13][9] - Giải pháp mở rộng mô hình điều khiển truy nhập cho các hệ thống luồng công việc trong môi trường lưới Giải pháp nhằm hoàn thiện hơn giải pháp gọi dịch vụ lưới ở trên với việc cho phép gọi các dịch vụ lưới an toàn - Giải pháp tự động hóa khai thác tiến trình BPEL, với kết quả đã được công bố trong [11] KẾT LUẬN Các đóng góp khoa học của đề tài Các đóng góp khoa học trong nghiên ... cho phép giải thích đầy đủ chất cộng tác loại hình cộng tác cần thiết khung cộng tác Về mặt thực tiễn: phát triển khung cộng tác hoạt động môi trường tính toán lưới, với khả sau: Biểu diễn kế... có tính cộng tác Mục tiêu cung cấp khung lưới đa dụng hỗ trợ cho công việc cộng tác áp dụng nhiều lĩnh vực ứng dụng khác Một số modul khung lưới cộng tác cài đặt Kết đăng [10][14][12] Trong trình... }1 26 }0 2.2 Khung cộng tác đa dụng 2.2.1 Các yêu cầu khung cộng tác đa dụng Định nghĩa 2-12 Khung cộng tác có hỗ trợ kế hoạch: hệ thống phần mềm hỗ trợ việc quản lý kế hoạch, thao tác sau đây: