4.2.1 Kiến trúc khung
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 đó. Các thành phần chính của tầng này gồm có :
100
Quản Lý VO và nhóm (VO and Group Management): có trách nhiệm cập nhật các tổ chức ảo (VO), các nhóm trong VO, người dùng trong các nhóm, quản lý quyền truy nhập và vai trò của người dùng trong các VO.
Lập kế hoạch hoạt động (Activity Planning): chịu trách nhiệm tạo mới các kế hoạch
làm việc hay cập nhật các kế hoạch đang triển khai
Phân công hành động (Activity Planning): chịu trách nhiệm phân công các hành động cụ thể trong kế hoạch làm việc cho từng người dùng
Lựa chọn tài nguyên và công cụ (Selecting Resources and Artifacts): cho phép người dùng tìm và lựa chọn các tài nguyên phù hợp cho các hành động trong kế hoạch làm việc, cũng như các công cụ cộng tác cần thiết cho việc cộng tác của các hành động. Kết quả cuối cùng của việc chọn lựa này sẽ là một kịch bản công việc.
Kho chứa các công cụ cộng tác (Collaborative Artifact Store): lưu trữ toàn bộ các
công cụ cộng tác.
Cho chạy và giám sát (Running and Monitoring): có nhiệm vụ khởi động, cho chạy, giám sát và cho kết thúc các hoạt động.
Thư mục tài nguyên (Resource Directory): chứa toàn bộ các tài nguyên cần thiết cho
việc chạy các thao tác của công việ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.
Ở đây, đưa ra một ví dụ đơn giản trong lĩnh vực ra quyết định y tế cộng tác, nhằm minh họa ý tưởng về việc sử dụng khung cho việc trợ giúp sự cộng tác trong hoạt động này.
Ví dụ 4-1:Khi khối lượng tri thức điều trị y tế không ngừng tăng lên, làm cho các nhân viên y tế ngày càng khó để trở thành chuyên gia trong vài lĩnh lực chuyên môn. Sự thật này đã làm cho việc tư vấn trở thành một thành phần thiết yếu của các tiến trình chẩn trị cộng tác hiện đại. Một kịch bản đơn giản có thể như sau:
Một bác sĩ và hai chuyên gia chia sẻ kiến thức nhằm đi đến một sự nhất trí liên quan đến một ca chẩn đoán, đòi hỏi có các kiểm tra chẩn đoán và các thủ tục can thiệp. Quá trình suy luận và ra quyết định có thể gồm các bước sau:
- Bước 1: Bác sĩ và các chuyên gia cộng tác với nhau để đưa ra một kế hoạch chẩn đoán, mà bao gồm các giai đoạn, các đặc điểm ra quyết định, các kiểm tra y tế, các hỗ trợ y tế, các dữ liệu dựa trên tri thức và sự trao đổi của họ.
- Bước 2: Một khi kế hoạch đã được sắp đặt, mỗi thành viên trong nhóm sẽ chịu trách nhiệm một phần nào đó trong kế hoạch và trao đổi với nhau theo đặc tả đã đề ra.
- Bước 3: Mỗi thành viên lựa chọn các công cụ cộng tác cần thiết nhằm trợ giúp quá trình chẩn đoán của họ. Bước này sẽ tạo ra một kịch bản mô tả đầy đủ chi tiết liên
101
quan đến những người thực hiện và các hành động phải làm để thu được kết quả đã được mô tả ở trong kế hoạch.
- Bước 4: Các hành động được thực thi theo kịch bản. Trong giai đoạn này, các thành viên tham gia cộng tác có thể luôn luôn giám sát tiến độ của toàn bộ tiến trình và nếu cần thì cập nhật lại kế hoạch.
Cũng cần lưu ý, quá trình suy luận và ra quyết định trong thực tế thường phức tạp hơn mô tả ở trên rất nhiều, như đã được trình bày trong [86].
4.2.2 Thiết kế modul
Kiến trúc của khung cộng tác ở trên được chia thành một số modul như sau (xem Hình 4-2):
1. VO and Group Management Modul (VGMM): Như đã nói ở trên, modul này sẽ chịu trách nhiệm cập nhật các tổ chức ảo, cũng như các nhóm người dùng trong đó.
2. Activity Planning Modul (APM): Modul này cho trách nhiệm xây dựng và cập nhật các kế hoạch hoạt động. Để cho kế hoạch vừa có thể được biểu diễn dễ dàng, vừa có thể thực thi được, cách tiếp cận ngôn ngữ luồng công việc (hay nói ngắn gọn là ngôn ngữ luồng) đã được lựa chọn. Đồng thời, qua khảo sát các ngôn ngữ luồng hiện nay, BPMN (Business Process Model & Notation) [70] là phù hợp nhất đối với khung cộng tác này vì một số lý do:
Thứ nhất, vì đây là ngôn ngữ luồng được phát triển nhằm thống nhất các ngôn ngữ luồng khá đa dạng hiện nay. Hơn nữa, đây là ngôn ngữ hướng vào việc mô tả các chu trình nghiệp vụ của người dùng ở mức cao (mức làm gì và chu trình thực hiện gồm các bước gì), chứ không mô tả ở mức thấp, thực hiện chu trình đó như thế nào. Chính vì vậy, rất thích hợp để mô tả các kế hoạch công việc của một nhóm người.
Thứ hai, việc chuyển từ BPMN sang ngôn ngữ luồng để thực thi BPEL (Business Process Execution Language), là ngôn ngữ được chọn để cài đặt Activity Execution Modul, cũng đang thu hút được khá nhiều nghiên cứu và đã đạt được khá nhiều kết quả khả quan [73] [18] [3] [79].
3. Activity Execution Modul (AEM): Modul này sẽ chịu trách nhiệm thực thi luồng công việc ở modul APM trên. Để triển khai modul này, tương tự như với modul APM, cách tiếp cận sử dụng ngôn ngữ luồng đã được sử dụng. Trong số các ngôn ngữ luồng hiện nay, BPEL (Business Process Execution Language) [68] [33] đã được chọn làm ngôn ngữ mô tả cho modul này vì một số lý do sau:
Thứ nhất: BPEL là ngôn ngữ luồng vừa có khả năng mô tả các tiến trình nghiệp vụ mức cao, vừa có thể thực thi luồng công việc nhờ các BPEL engine đã được phát triển khá phổ biến hiện nay như ActiveBPEL, ODE, v.v. Thứ hai: BPEL là ngôn ngữ luồng hướng dịch vụ, bằng cách chuẩn hóa việc thực thi các luồng công việc thông qua việc gọi các dịch vụ Web. Điều này rất có ý nghĩa trong việc triển khai và mở rộng ngôn ngữ luồng trong môi trường lưới, vì đây là môi trường đang được phát triển và chuẩn hóa theo
102
hướng dịch vụ. Tuy nhiên, BPEL có hạn chế là khả năng chỉ mới hỗ trợ việc gọi các dịch vụ Web, chứ chưa gọi được dịch vụ lưới. Khắc phục hạn chế này cũng là một trong những nội dung nghiên cứu của luận án.
4. Hạ tầng lưới: Hạ tầng sẽ chứa kho tài nguyên và quản lý một cách có hiệu quả các tài nguyên của lưới để phục vụ cho các chức năng của các modul khác. Ngoài ra, hạ tầng này cũng sẽ giúp thực thi và giám sát các công việc trong các kế hoạch đã đề ra trong các modul APM và AEM ở trên.
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.
Từ các modul trên, chúng có thể được lắp ghép như trong Hình 4-2. Theo cấu trúc này, trình tự các thao tác của người sử dụng có thể được khái quát gồm các bước sau:
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.
103
Hình 4-2: Cấu trúc các modul của khung.
1. Bước 1: Người dùng đăng nhập (login) vào hệ thống. Ngoài tài khoản để đăng nhập như các hệ thống thông thường, đối với hệ thống lưới, người dùng phải có trước các bản chứng thực (certificate) hợp lệ, được cấp bởi một trong các tổ chức chứng thực có đủ tin cậy (Authorization Organization). Sau khi đăng nhập, người dùng có thể đăng ký vào trong các tổ chức ảo để bắt đầu các phiên làm việc. 2. Bước 2: Người dùng sử dụng các công cụ soạn thảo kế hoạch (ở đây là các
BPMN editor) để cập nhật các bản kế hoạch về một công việc nào đó. Việc soạn thảo này có thể được thực hiện phối hợp với nhau – nhóm người dùng vừa cùng trao đổi và cùng cập nhật bản kế hoạch để đưa ra được bản thảo tốt nhất tại thời điểm đó. Sau đó, nó vẫn có thể được điều chỉnh cho phù hợp hơn với tình hình mới.
3. Bước 3: Bản kế hoạch đã được thống nhất ở trên sẽ được dịch sang một bản thảo ở dạng mới (là BPEL trong hệ thống này) để phù hợp hơn với việc thực thi và giám sát việc thi hành này trên môi trường lưới.
4. Bước 4: Để chuẩn bị cho việc thực thi bản kế hoạch đã được dịch, cần phải tìm và định vị các tài nguyên (phần cứng, phần mềm) cần thiết.
5. Bước 5: Người sử dụng sẽ cho thực thi và trong quá trình đó giám sát các kết quả thực hiện, so sánh với kế hoạch đã đề ra ban đầu, từ đó có thể phát hiện kịp thời các vấn đề nảy sinh và có những điều chỉnh cần thiết.
104
4.2.3 Kết luận phần thiết kế
Trong phần thiết kế cho khung cộng tác, luận án đã đưa ra thiết kế ở cả hai mức sơ bộ và chi tiết. 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, các mục tiêu có thể được chia sẻ và cùng được tối ưu, và các hành động sẽ được phân bổ và được thực thi một cách tối ưu bởi các thành viên tham gia. Mục tiêu nhằm cung cấp một khung lưới đa dụng hỗ trợ cho những công việc cộng tác trong nhiều lĩnh vực ứng dụng khác nhau.
Luận án đã cài đặt môi trường lưới sử dụng Globus Tookit 4 [36] cho tầng điều phối tài nguyên của khung. Các cài đặt khác cho khung cộng tác sẽ được trình bày chi tiết hơn trong phần sau.
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:
- 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].
4.3.1 Giải pháp gọi dịch vụ lưới từ tiến trình BPEL
4.3.1.1 Khảo sát vấn đề
Hiện nay, engine ODE chỉ có thể gọi các dịch vụ Web, không thể gọi các dịch vụ lưới. Trong [13], luận án đã tiến hành khảo sát để làm rõ nguyên nhân của vấn đề trên. Trên cơ sở đó, đề xuất một giải pháp cho việc gọi dịch vụ lưới từ tiến trình BPEL trong engine ODE. Đầu tiên, phát triển một chương trình kiểm thử (test) nhằm xác định engine ODE gọi dịch vụ Web như thế nào và từ đó xác định chính xác vấn đề khi ODE gọi một dịch vụ lưới bên ngoài từ một tiến trình BPEL. Chương trình kiểm thử gồm có ba phần:
- Một dịch vụ lưới gọi là MathService đã được điều chỉnh từ một ví dụ trong [87] (ví dụ này chỉ chạy được với Globus Toolkit (GT) 4.0. Luận án đã có những thay đổi cần thiết để nó có thể chạy được với GT 4.2). Dịch vụ lưới này đã theo mẫu factory/instance [87]. Theo mẫu này, mỗi dịch vụ lưới sẽ có một dịch vụ factory, gọi là MathFactoryService, là một dịch vụ Web bình thường có vai trò là tạo ra các thể hiện của dịch vụ lưới. Bên cạnh việc tạo ra các thể hiện mới, thao tác này (gọi là createResource) cũng trả về các ResourceKeys (Khóa Tài Nguyên) cho các thể hiện. Công cụ Globus Toolkit 4.2 đã được sử dụng để khai thác dịch vụ lưới trong container dịch vụ Web.
105
- Một tiến trình BPEL được gọi là Test-FactoryGS-V2. Sơ đồ của tiến trình này được minh họa trong Hình 4-3. Chi tiết của tiến trình sẽ được giải thích ở phần sau. - ODE engine được khai thác trong Apache Tomcat 6.
Ngoài ra, công cụ SoapUI [85] cũng được sử dụng để chạy và kiểm tra tiến trình BPEL. Để xác định rõ vấn đề, tiến trình BPEL được thiết kế để kiểm tra ba hoạt động (activities):
- Hoạt động đầu tiên là gọi dịch vụ lưới để lấy ResourceKey của nó.
- Hoạt động thứ hai là gán giá trị ResourceKey này cho một PartnerLink, cho phép
PartnerLink này mang theo ResourceKey.
- Hoạt động thứ ba là sử dụng PartnerLink để gọi thao tác khác của dịch vụ lưới.
Hình 4-3: Sơ đồ của tiến trình BPEL Test-Factory GS-V2
Các hoạt động chính của tiến trình BPEL FactoryGS-V2
Tiến trình BPEL được thiết kế sẽ thực hiện ba hoạt động như sau:
(1) Gọi thao tác createResource của MathFactoryService và lưu trữ giá trị
ResourceKey được trả về trong một biến gọi là CreateResourceOut bởi đoạn mã sau: <invoke name="Invoke1" partnerLink="MathFactoryServicePL"
operation="createResource"
xmlns:tns="http://www.globus.org/namespaces/examples/core/- FactoryService"
106
inputVariable="CreateResourceIn"
outputVariable="CreateResourceOut"/>
(2) Gán giá trị của biến CreateResourceOut cho một PartnerLink bởi đoạn mã sau: <assign name="Assign5">
<copy>
<from variable="CreateResourceOut" part="response" />
<to partnerLink="MathServicePL"/>
</copy>
</assign>
(3) Gọi một thao tác của dịch vụ lưới MathService bởi đoạn mã sau:
<invoke name="Invoke2" partnerLink="MathServicePL"
operation="getValueRP" xmlns:porttype="http://www.globus.org/namespaces/examples/core/Math Service_instance" portType="porttype:MathPortType" inputVariable="GetValueRPIn" outputVariable="GetValueRPOut"/> \end{verbatim}
4.3.1.2 Kết quả kiểm thử và giải thích
Khi hoạt động (1) được gọi thành công, giá trị trả về của CreateResourceOut chứa
ResourceKey, như được chỉ ra trong phần in đậm trong đoạn thông báo trả về sau: <?xml version='1.0' encoding='utf-8'?> <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ … <soapenv:Header> … </soapenv:Header> <soapenv:Body>
107 <createResourceResponse xmlns="http://www.globus.org/namespaces/examples/core/FactoryServic e"> <wsa:EndpointReference> <wsa:Address>http://127.0.0.1:8082/wsrf/services/examples/core/fact ory/MathService </wsa:Address> <wsa:ReferenceParameters> <ns1:MathResourceKey xmlns:ns1="http://www.globus.org/namespaces/examples/core/MathServi ce_instance"> 12692431 </ns1:MathResourceKey> </wsa:ReferenceParameters> </wsa:EndpointReference> </createResourceResponse> </soapenv:Body> </soapenv:Envelope>
Việc gán giá trị của CreateResourceOut cho PartnerLink MathServicePL được thực hiện thành công (hoạt động (2)). Tuy nhiên, việc gọi thao tác trong hoạt động (3) đã thất bại. Qua việc kiểm tra kỹ lưỡng các thông báo vào/ra, nguyên nhân chính xác của vấn đề đã được tìm thấy. Trong thông báo được gửi để gọi thao tác getValueRP của dịch vụ lưới, dữ liệu MathResourceKey cần thiết đã không có. Dữ liệu này lại nằm trong thành phần EPR (EndPointReference: tham chiếu điểm cuối, là thành phần có nhiệm vụ lưu trữ địa chỉ dịch vụ lưới và các tài nguyên của nó).
Thông qua khảo sát, có thể thấy việc lấy EPR cần hai bước. Bước đầu tiên, gọi thao tác
CreateResource sẽ trả về EPR từ dịch vụ lưới. Sau đó, EPR trả về này cần được lưu trong một PartnerLink để sử dụng sau này. Mặc dù EPR chứa ResourceKey, ODE vẫn hỗ trợ hai bước này rất tốt (Lưu ý rằng trong một dịch vụ Web, EPR của nó không chứa ResourceKey
và ODE chỉ hỗ trợ dịch vụ Web, chứ không hỗ trợ dịch vụ lưới).
Một điều tồn tại của ODE, khi gọi dịch vụ lưới nảy sinh trong trường hợp PartnerLink
mang theo EPR được sử dụng để gọi thao tác trong dịch vụ lưới. Bởi vì thông báo được sử dụng trong lời gọi này thiếu ResourceKey.
108
4.3.1.3 Giải pháp
Từ khảo sát trên, rõ ràng là để ODE engine hỗ trợ việc gọi dịch vụ lưới, cần phải phát