MỤC LỤC
LỜI CAM ĐOAN . ii
Chương 1: Tổng Quan Về Đề Tài Luận Văn . vii
1.1 Giới thiệu đề tài . vii
1.2 Mục tiêu của đề tài . viii
1.3 Hướng tiếp cận của đề tài . viii
1.4 Phương pháp triển khai đề tài . viii
1.5 Cấu trúc luận văn . viii
Chương 2: Các kiến thức nền tảng trong đề tài luận văn . ix
2.1 Tổng quan về hệ thống tính toán lưới . ix
2.2 Globus Toolkit 4.0 . xi
2.3 Single Sign On . xix
2.4 Tổng quan về sakai . xxiii
2.5 Tổng quan về OGCE portal . xxviii
2.6 Tổng quan về Axis Service . xxx
2.7 Chuẩn portlet JSR 168 . xxxii
Chương 3: Phân tích và hiện thực hệ thống đề tài luận văn . xxxvii
3.1 Phân tích hệ thống . xxxvii
3.2 Đề xuất cơ chế tích hợp portlet JSR 168 vào Sakai . xliii
3.2.1 Xây dựng các tool tương ứng . xliii
3.2.2 Tích hợp Grid portlet dựa vào chuẩn WSRP . xlv
3.2.3 Tích hợp portlet JSR 168 vào Sakai . xlv
Chương 4: Kết luận . lii
4.1 Những thành quả đạt được của luận văn: . lii
4.2 Những hạn chế của luận văn . lii
4.3 Những khó khăn khi thực hiện đề tài . lii
4.4 Hướng phát triển của luận văn: . liii
Chương 5: Phụ lục và tài liệu tham khảo . liv
5.1 Cài đặt Globus Toolkit 4.0 . liv
5.2 Cài đặt OGCE portal . lxv
5.3 Cài đặt sakai phiên bản 2.5.4 . lxvii
Tài liệu tham khảo . lxxv
75 trang |
Chia sẻ: netpro | Lượt xem: 2473 | Lượt tải: 3
Bạn đang xem trước 20 trang tài liệu Luận văn Xây dựng cơ chế Single Sign On từ môi trường Sakai vào Việt Nam-GRID, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
diện trên theo ý người dùng.
Lớp Presentation
Bên dưới lớp Aggregation là lớp Presentation chứa một bộ các thành phần cấu thành một
trang của Sakai. Tham khảo hình dưới là một ví dụ các thành phần giao diện trong lớp
Presentation tập hợp trong một file JSP.
<sakai:instruction_message
value="#{msgs.sample_one_instructions}" />
<sakai:group_box
title="#{msgs.sample_one_groupbox}">
<h:inputText
value="#{MyTool.userName}" />
<sakai:date_input
value="#{MyTool.date}" />
<sakai:button_bar_item
action="#{MyTool.processActionDoIt}
value="#{msgs.sample_one_cmd_go}" />
Hình 2. 15: Lớp Presentation của Sakai
Các công nghệ hiện sử dụng ở lớp Presentation là JSF, JSP, Velocity,và Struts, RSF.
Lớp Tool
Tool là một đơn vị chức năng rời rạc trong Sakai ví dụ như tool announcement, wiki…
Mỗi tool giúp đáp ứng một chức năng nào đó của người dùng. Các tool thao tác trên dữ
liệu của mình bằng các dịch vụ cơ bản cung cấp ở lớp service. Chức năng của Sakai
kernel là quản lí các dịch vụ và các tool. Sakai cho phép các nhà phát triển có thể tự xây
dựng các dich vụ riêng của mình. Do đó khi một dịch vụ mới hay một tool mới được xây
dựng thì phải đăng kí với Sakai Kernel. Ví dụ ta đang chạy Sakai mà copy vào thư mục
wedapp/toolApp thì ngay lập tức toolApp sẽ được đăng ki với Sakai Kernel. Các tool này
được xây dựng dựa trên các dịch vụ bên dưới của lớp Service.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxvii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Lớp services
Việc thiết kế lớp dich vụ nhằm giúp đơn giản hóa quá trình phát triển Sakai che dấu đi các
hiện thực chi tiết bên dưới của Sakai. Nhà phát triển ứng dụng trên Sakai chỉ cần dựa trên
các dich vụ được cung cấp. Ví dụ như một tool không cần biết kiểu cơ sở dử liệu bên dưới
là MySQL hay Oracle… hay hệ thống file nào được các dịch vụ sử dụng và đặt ở đâu.
Các service cơ bản của Sakai như dịch vụ lấy, xóa, thêm một user hay thông tin về các
môn học. Hoặc ví dụ người phát triển có thể phát triển một dịch vụ thêm, điều chỉnh, xóa
trên sổ lớp. Từ đó các tool khác có thể sử dụng các dịch vụ này để thay đổi sổ lớp hay
chẳng hạn viết một công cụ in sổ lớp dưới những định dạng khác nhau dựa trên dịch vụ đã
có. Còn làm thế nào để xây dựng các dịch vụ này người đọc có thể tham khảo chương 11
của tài liệu tham khảo[Sakai-Courseware-Management-the Official-Guide].
Nhìn một các tổng quát thì Sakai như một bó khổng lồ các ứng dụng web chạy cùng
một servlet container, cùng chia sẽ các dịch vụ trung tâm. Khi một trình duyệt gửi một
request; một ứng dụng sẽ nhận request đó, làm một vài công việc, xong trả về một
respone chứa những thông tin mà request yêu cầu. Quá trình này nhìn chung là khá phưt
tạp trước hết request từ web browser sẽ đi qua một bột Aggregator ở lớp Aggregator sau
đó sẽ chia request thành nhiều request nhỏ để chỉ định cho các tool, sau đó các tool này sử
dụng các dịch bên dưới và trả về các kết quả mong muốn. Cuối cùng bộ Aggregator sẽ thu
thập các kết quả trả về của các tool đó để trả về một response cho người dùng ở web
Browser ,thông thường là một trang web.
2.5 Tổng quan về OGCE portal
OGCE portal là một portal cung cấp các portlet và tool dùng để truy cập vào hệ thống
Grid Computing thông qua môi trường web. OGCE portal được phát triển dựa trên bột
thư viện Java Cog Kit. Nó bao gồm nhiều portlet như ProxyManager, JobSubmission,
FileManager, Grid Information, Comp-file Manager… và các tool khác axis2, balancer,
applets…
Hình 2. 16: Các portlet đặc trưng của OGCE portal
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxviii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Hình 2. 17: Portlet Myproxy Manager của OGCE portal
Portlet proxymanager dùng để quản lý các chứng chỉ proxy của user. Chỉ khi chứng
chỉ của user được load lên trong proxymanager portlet thì các portlet khác sẽ sử dụng
chứng chỉ này đề xác thực và trở nên sẵn sàng để sử dụng.
Hình 2. 18: Portlet Comp-file-management của OGCE portal
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxix
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Portlet Comp-file-management dùng để truyền file giữa các tài nguyên Grid, upload
file lên một tài nguyên Grid, download file từ tài nguyên Grid về máy.
Kiến trúc OGCE portal
OGCE portal sử dụng Gridsphere container như một portlet container để quản lý tất cả
các Grid portlet trong OGCE portal. Do đó các portlet đều phát triển trên nền Gridsphere,
ngoài tuân thủ chuẩn JSR 168, còn portlet còn phải tương thích với Gridsphere và sử dụng
một vài gói thư viện để chạy như gridsphere-tag.jar…
Hình 2. 19: Kiến Trúc của OGCE portal
Như hình ở trên tất cả các các portlet khác của portal đều phải sử dụng MyProxy
Manager để lấy chứng chỉ trước khi sẵn sàng. Các portlet này sẽ giao tiếp với Globus
Tool Kit 4.0 bằng bộ thư viện interface cung cấp cho client là java CoG API. Vì tất cả các
portlet JSR 168 này đều khả chuẩn từ Gridsphere framework sang uPortal. Do đó để chạy
các portlet JSR 168 này trong pluto container ở trong Sakai là hoàn toàn có cơ sở. Vì
pluto về bản chất là một bản thu gọn của uPortal.
2.6 Tổng quan về Axis Service
Trước hết tại sao nhóm phải giới thiệu gói dịch vụ Axis[14] ở đây là vì trong quá trình thực
hiện đề tài thì nhóm gặp lỗi liên quan đến gói dịch vụ này của apache tomcat. Cũng chính
lỗi đó mà nhóm đã tốn rất nhiều thời gian để debug.
Apache Axis là một gói dịch vụ dùng để điều khiển luồn dữ liệu vào và ra portal. Vì
các dữ liệu lưu thông trên portal đều đưa về dạng một file XML,ví dụ như các giá trị,
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxx
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
thuộc tính của các Java Object, theo một giao thức nào đó cùng với thông tin phụ đi kèm
để truyền đi đến các dịch vụ. Do đó để điều khiển các luồn vào ra này thì bên dưới
Apache cung cấp một gói gọi là Axis ở cả client và server để điều phối dữ liệu.
Trước hết xin gới thiệu hình mô tả cấu trúc bên trong của Axis
Hình 2. 20: Kiến trúc của Axis Services
Hình trên là quá trình hoạt động của Axis Engine bên phía server. Một message đến
tại Transport Listener. Trong trường hợp này ta xem nó là một HTTP servlet . Công việc
của Listener là sẽ đóng gói request đó thành một Message rồi đặt Message này vào một
class gọi là MessageContext. Trong MessageContext chứa Message còn chứa nhiều
thuộc tính khác được Listener thiết lập. Khi MessageContext đã được xây dựng thành
công thì nó được truyền qua bộ AxisEngine. Công việc của AxisEngine là xác định được
service bên dưới mà request cần và trả về một reponse cho Listener. Thông tin chi tiết về
cấu tạo các class bên trong xin xem thêm tài liệu tham khảo, mô tả chi tiết các quá trinh
tạo Message và truyền message.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxi
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
2.7 Chuẩn portlet JSR 168
Chuẩn portlet JSR 168[15] dùng để định nghĩa portlet và cách thức giao tiếp giữa portlet và
portal.
Hình 2. 21: Mô hình chuẩn của JSR 168
Hình trên mô tả sự giao tiếp giữa portal và các portlet. Sự giao tiếp này được thực hiện
thông qua các API được cung cấp bởi chuẩn JSR 168.
Một số khái niệm chính:
Portal
Portal là một ứng dụng web dùng để tích hợp các nội dung từ các nguồn khác nhau vào
cùng một trang web. Các nội dung có thể được cấu hình tùy thuộc vào người sử dụng
khác nhau mà Portal cho phép. Một Portal có thể chứanhiều Portlet.
Portlet
Portlet là một thành phần dựa trên nền Web sử dụng các công nghệ của Java. Portlet được
quản lý bởi một Portlet Container. Portlet dùng để xử lý các yêu cầu và tạo ra các thành
phần dữ liệu động để phản hồi các yêu cầu.
Portlet có thể tích hợp vào Portal và Portal sẽ cung cấp tầng trình diễn cho các thành
phần của Portlet.
Nội dung được tạo ra bởi các Portlet được gọi là Fragment. Một Fragment là một
mảnh dữ liệu được tạo ra bởi các ngôn ngữ như: HTML, XML… theo một định dạng
được quy định. Các Fragment này có thể được kết hợp với các Fragment của các Portlet
khác để hình thành trang Web của portal.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Người sử dụng tương tác với Portlet thông qua cơ chế yêu cầu/phản hồi được cung cấp
bởi Portlet. Nội dung phản hồi yêu cầu được Portlet tạo ra và nội dung này cũng tùy thuộc
vào cấu hình ứng với từng người sử dụng.
Portlet Container
Portlet Container cung cấp một môi trường để chứa đựng và quản lý chu kỳ sống của một
Portlet.
Portlet Container nhận yêu cầu từ Portal và chuyển yêu cầu này đến Portlet tương ứng
để Portlet xử lý yêu cầu và tạo nội dung phản hồi.
Giao diện Portlet
Giao diện Portlet khai báo các API cơ bản nhất của một Portlet. Mọi Portlet được xây
dựng đều phải hiện thực hóa trực tiếp hoặc gián tiếp giao diện Portlet.
Lớp GenericPortlet hiện thực hóa giao diện Portlet và định nghĩa các chức năng cơ bản
nhất mà một Portlet cần có. Do đó khi xây dựng Portlet, lập trình viên nên mở rộng trực
tiếp hoặc gián tiếp lớp GenericPortlet này.
Một Portlet được quản lý thông qua chu trình sống của nó bắt đầu từ lúc Portlet được
tải lên, tạo thể hiện của nó và khởi tạo, hoạt động để phản hồi yêu cầu của người sử dụng
đến lúc nó được loại bỏ. Các phương thức được gọi đến trong chu trình sống của Portlet
là:
• Gọi Phương thức init trong quá trình khởi tạo Portlet.
• Nêu yêu cầu do máy khách gởi tới là yêu cầu hành động( Action Request) thì
phương thức processAction được gọi. Nếu yêu cầu do máy khách gởi tới là yêu cầu
biểu hiện ( Render Request) thì phương thức render được gọi
• Khi Portlet Container xác định một Portlet không còn sử dụng nữa thì gọi đến
phương thức destroy của Portlet đó. Khi phương thức destroy được gọi thì Portlet
sẽ giải phóng tài nguyên mà nó đang sử dụng và lưu lại trạng thái hiện thời của nó.
Portlet URL
Một Portlet có thể tạo ra URL tham chiếu đến chính Portlet đó. Khi đó các URL này được
gọi là Portlet URL.
Để tạo ra một Portlet URL thì Portlet cần phải sử dụng đối tượng PortletURL. Nếu
phương thức createActionURL được gọi thì sẽ tạo ra một Action URL và nếu phương
thức createRenderURL được gọi thì sẽ tạo ra một render URL.
Portlet Mode
Kiểu portlet xác định chức năng mà Portlet đó đang thực hiện. Thông thường Portlet
thực hiện các tác vụ và tạo ra nội dung tùy thuộc vào chức năng hiện thời. Kiểu Portlet
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxiii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
cho ta biết những tác vụ nào một Portlet cần thực hiện và những nội dung nào Portet cần
phải tạo ra.
Có 3 kiểu Portlet được quy đinh là:
• VIEW:
Chức năng chính của Portlet khi sử dụng kiểu VIEW là tạo ra nội dung cho biết
trạng thái của Portlet.
Lập trình viên sẽ hiện thực hóa kiểu VIEW bằng cách định nghĩa lại phương thức
doView của lớp GenericPortlet.
Mọi Portlet đều phải hỗ trợ mode VIEW .
• EDIT:
Trong kiểu EDIT, một Portlet sẽ cung cấp nội dung và cấu hình các thành phần
của nó để người sử dụng có thể tối ưu hóa hoạt động của Portlet.
Lập trình viên sẽ hiện thực hóa kiểu EDIT bằng cách định nghĩa lại phương thức
doEdit của lớp GenericPortlet.
Mọi Portlet không nhất thiết phải hỗ trợ kiểu EDIT.
• HELP
Trong kiểu HELP, Portlet cung cấp những tin về Portlet. Những thông tin này
thường là những thông tin chung về toàn bộ Portlet.
Portlet Request
• Một yêu cầu gởi đến Portlet chứa các thông tin về yêu cầu từ phía máy khách, các
tham số của yêu cầu, nội dung dữ liệu yêu cầu, kiểu Portlet, trạng thái cửa sổ…
• Yêu cầu được đại diện bởi một đối tượng và đối tượng này được truyền vào như là
đối số của phương thức procesAction hay render.
• Mỗi đối tượng yêu cầu chỉ có thể hoạt động trong phạm vi của một phương thức
processAction hay render.
• Các chức năng cần thiết của đối tượng PortletRequest được khai báo trong giao
diện PortletRequest.
Portlet Respone
• Một phản hồi của Portlet bao gồm những thông tin được tạo ra bởi Portlet gởi trả
về cho Portlet Container dựa trên yêu cầu được gởi đến như: sự thay đổi kiểu
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxiv
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Portlet, tiêu đề, nội dung… Portlet Container sẽ sử dụng những thông tin này để
tạo ra phản hồi đến người sử dụng, thông thường là một trang Web Portal.
• Mỗi đối tượng phản hồi chỉ có thể hoạt động trong phạm vi của một phương thức
procesAction hay render.
• Các chức năng cần thiết của đối tượng Portlet Respone được khai báo trong giao
diện PortletRespone.
Portlet Preferences
• Portlet thông thường được cấu hình cho phù hợp với từng người sử dụng. Các
thông tin về cấu hình của Portlet được gọi là Portlet Preference. Portlet Container
sẽ chịu trách nhiệm lưu giữ những thông tin cấu hình này.
• Portlet có thể truy cập vào các thông tin cấu hình của nó thông qua giao diện
PortletPreferences và Portlet chỉ có thể thay đổi các thônt tinh về cấu hình của nó
bên trong phương thức processAction.
• Định nghĩa Portlet xác định các thuộc tính preference mà một Portlet sử dụng.
Định nghĩa này bao gồm các giá trị khởi tạo và xác định xem thuộc tính này có
phải là thuộc tính chỉ đọc hay không.
Caching
• Việc lưu các nội dung cần sử dụng vào vùng nhớ tạm thời được thực hiện nhằm
mục đích rút ngắn thừoi gian xử lý của Portlet, đồng thời cũng rút ngắn thời gian
xử lý của Server.
• Đặc tả Portlet xác định cơ chế hết hạn việc lưu trữ nội dung lưu tạm thời này. Cơ
chế này hoạt động tùy thuộc vào từng Portlet và từng người sử dụng Portlet. Nội
dung được lưu trữ tạm thời không được chia sẻ giữa các người sử dụng khác nhau
đang sử dụng đồng thời cùng một Portlet.
• Một Portlet muốn tăng thời gian xử lý bằng cách sử dụng cơ chế lưu trữ tạm thời
nội dung cần phải định nghĩa thời gian hết hạn của nội dung lưu tạm thời ( tính
bằng đơn vị giây) trong đặc tả triển khai của nó. Ví dụ sau đây cho biết một Portlet
muốn nội dung của nó được lưu trữ tạm thời và có thời gian hết hạn là 300 giây.
• Một Portlet nếu đã định nghĩa thời gian hết hạn lưu trữ dữ liệu tạm thời của nó
trong đặc tả triển khai của nó vẫn có thể thay đổi được.
• Thời gian hết hạn của việc lưu trữ tạm thời này có thể được thay đổi bằng cách
thay đổi thuộc tính của đối tượng RenderResponse.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxv
…
…
300
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
• Nếu thời gian hết hạn này được gán bằng 0 thì việc lưu trữ dữ liệu tạm thời bị bỏ
qua đối với Portlet. Nếu giá trị này được gán bằng -1 thì các nội dung lưu trữ tạm
thời của Portlet sẽ không bao giờ bị hết hạn.
• Nêu một Portlet không định nghĩa thời gian hết hạn của dữ liệu lưu trữ tạm thời
trong đặc tả triển khai của nó thì việc thay đổi giá trị thời gian này trong đối tượng
RenderResponse sẽ không có tác dụng do sẽ bị Portlet Container bỏ qua.
• Nếu nội dung của Portlet được lưu trữ tạm thời và chưa hết hạn, đồng thời không
có một yêu cầu nào đến Portlet từ phía người sử dụng thì Portlet Container sẽ sử
dụng nội dung được lưu trữ tạm thời khi cần thiết.
Ứng dụng Portlet
Ứng dụng Portlet là một ứng dụng Web nên ngoài việc bảo gồm Portlet và đặc tả triển
khai Portlet, nó còn có thể chứa các thành phần khác như: Servlet, trang JSP, các class…
Do đó, bên cạnh các thông tinh về ứng dụng Portlet, nó còn chứa đựng thông tin về các
thành phần được đưa vào ứng dụng Portlet.
Cấu trúc cây thư mục
Một ứng dụng Portlet cũng có cấu trúc cây thư mục được tổ chức giống như một ứng
dụng Web. Tuy nhiên có một số khác biệt sau:
- Có thêm tập tin /WEB_INF/portlet.xml là tập tin đặc tả triển khai của Portlet.
- Các lớp được sủ dụng cho ứng dụng Portlet và các tài nguyên khác được truy cập
bởi ứng dụng Portlet cần phải được lưu trong thưmục /WEB-INF/classes hoặc
trong các tập tin JAR được lưu trong thư mục /WEB-INF/lib.
Tập tin lưu trữ của ứng dụng Portlet
Một ứng dụng Portlet cũng được đóng gói như một ứng dụng Web. Nghĩa là sử dụng
dạng WAR (Web Application Archive) khi triển khai ứng dụng.
Các đặc tả đóng gói và triển khai
Đặc tả triển khai của ứng dụng Web và ứng dụng Portlet
Trong các ứng dụng Portlet, luôn tồn tại 2 tập tin đặc tả là:
• Tập tin web.xml dung để đặc tả các tài nguyên của ứng dụng Web.
• Tập tin portlet.xml dung để đặc tả các tài nguyên của ứng dụng Portlet.
Các tài nguyên nào không liên quan đến Portlet thì được khai báo trong tập tin đặc tả
web.xml. Còn các tài nguyên nào liên quan đến Portlet thì được khai báo trong tập tin
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxvi
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
portlet.xml. Ngoài ra, một số thông tin của Portlet cần phải được khai báo trong tập tin
web.xml như sau:
• Mô tả về ứng dụng Portlet được khai báo bằng thẻ .
• Tên của ứng dụng Portlet được khai báo bằng thẻ .
• Việc ánh xạ các vai trò bảo mật( Security Role Mapping) của ứng dụng Portlet
được khai báo bằng thẻ .
Triển khai ứng dụng Portlet và ứng dụng Web
Các Portlet, đặc tả triển khai và mọi tài nguyên phải được đóng gói trong cùng một tập tin
WAR. Trong đó, thư mục WEB-INF bao gồm các thành phần:
- Tập tin đặc tả triển khai /WEB-INF/portlet.xml
- Các lớp của Portlet nằm trong thư mục /WEB-INF/classes
- Các tập tin JAR được lưu trong thư mục /WEB-INF/lib
Chương 3: Phân tích và hiện thực hệ thống đề tài luận
văn
3.1 Phân tích hệ thống
Dựa trên mục tiêu của đề tài là phải kết nối hệ thống Sakai với hệ thống Tính Toán Lưới
của trường. Hệ thống Sakai của trường đang dùng là phiên bản Sakai 2.5.4 và hệ thống
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxvii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Tính Toán Lưới được hiện thực bởi Globus Toolkit 4.0.x. Và để truy cập vào hệ thống
Tính Toán Lưới này bằng một môi trường web thì có nhiều portal hổ trợ công việc đó.
Hiện tại OGCE(Open Grid Computing Environments) là một trong những portal hỗ trợ
gần như đầy đủ các chức năng tương tác với hệ thống Tính Toán Lưới qua Globus
Toolkit 4.0. Trong portal OGCE gồm các portlet: iframe-portlet, jobsubmission,
proxymanager-portlet, gp-browser-2, gp-job-submission, condor-job-submission… thông
qua những portlet này người dùng sử dụng và quản lý hệ thống Grid Computing.
Hình 3. 1: Mô hình tổng quát hệ thống ban đầu
Hình trên mô tả tổng quát hệ thống OGCE portal kết nối với Globus Toolkit 4.0.
Trong đó người dùng sử dụng các portlet JSR 168 để tương tác với hệ thống Tính Toán
lưới. Trong đó ta thấy có ba portlet mà tiêu biểu thể hiện trên hình là ProxyManager
Portlet, JobSubmit Portlet, Comp-file-Manager portlet. OGCE đáp ứng được khả năng
truy cập hệ thống Tính Toán Lưới nhưng lại không được phát triển nhằm tạo ra một cộng
đồng những người sử dụng hệ thống Tính Toán Lưới. Quay lại mô hình ban đầu, kế bên
portal OGCE lúc này là hệ thống Sakai của trường mà ở đây người dùng độc lập với hệ
thống Tính Toán Lưới. Mục đích của đề tài lúc này là làm sao kết nối hệ thống Sakai này
với hệ thống Tính Toán Lưới của trường.
Hình sau thể hiện mô hình mà nhóm đã quyết định xây dựng. Sau khi ta hoàn thành
xong thì người dùng có thể kết nối với hệ thống Tính Toán Lưới bên dưới thông qua
Globus Toolkit 4.0 sử dụng cơ chế xác thực bằng chứng chỉ khóa công cộng.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxviii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Hình 3. 2:Mô hình tổng quát hệ thống cần xây dựng.
Từ hình trên cho thấy là nhóm phải bằng cách nào đó đưa các chức năng hiện có ở
OGCE portal vào Sakai..
Trước hết để kết nối hệ thống Sakai và hệ thống Grid Computing hiện nay chúng ta
phải làm gì?
Rõ ràng là phải giải quyết được vấn đề truy cập, cấp phát quyền người dùng , sao cho
người dùng của Sakai có thể truy cập vào hệ thống tính toán lưới thông qua Globus. Cơ
chế xác thực và cách quản lý user của Sakai và Globus Toolkit 4.0 là hoàn toàn khác
nhau. Một bên Sakai sẽ sử dụng cơ chế xác thực User Directory Service. Một bên Globus
Toolkit 4.0 sử dụng chứng chỉ khóa công cộng để quản lý người dùng. Qua quá trình khảo
sát và nghiên cứu thì nhóm thực hiện đề tài chưa đi sâu giải quyết vấn đề mâu thuẫn trên.
Tức là trên hệ thống Sakai có nhiều nhóm người dùng khác nhau, có nhóm sử dụng hệ
thống Tính Toán Lưới, có nhóm không sử dụng tại một thời điểm nào đó. Do đó phải cần
can thiệp bên dưới sao cho những nhóm người dùng sử dụng các portlet chức năng của
Globus Toolkit 4.0, có khả năng đăng nhập Globus một cách tự động. Còn những nhóm
người dùng không được cấp quyền sử dụng Globus thì không có bất kỳ một chứng chỉ
nào để truy cập Globus.
Từ những đánh giá ở trên ta sẽ có được mô hình hoạt động chi tiết của hệ thống mong
muốn như hình dưới. Trong mô hình đó cần có một dịch vụ getProxyService( username,
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xxxix
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
passphrase). Dịch vụ này có chức năng tự động lấy các chứng chỉ proxy mà người dùng
username trên sakai có về sakai.
1 .Là quá trình dịch vụ getProxyService() lưu tất cả các chứng chỉ proxy vào một
bảng chứng chỉ proxy.
2. Là quá trình từ phía người sẽ có một portlet ProxyManager tự động cập nhật tất
cả các chứng chỉ proxy và liệt kê ra cho người dùng username sử dùng một trong
các chứng chỉ đó.
Hình 3. 3:Sơ đồ hoạt động của hệ thống mong muốn
Dưới đây là các hình ảnh của hai portlet ProxyManager và JobSubmission trên portal
OGCE trong mô hình hệ thống ban đầu.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xl
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Hình 3. 4:Portlet MyproxyManager của OGCE portal
Hình trên là hình ảnh của proxymanager-portlet, portlet này sẽ tương tác với MyProxy
server để lấy các chứng chỉ Proxy của user. Mục đích của nhóm là rút gọn giai đoạn này
người dùng Sakai sẽ không còn phải nhập username và passphrase một lần nữa. Mà sẽ có
một dịch cụ GetProxyservice(username, passphrase) bên dưới trong Sakai đảm nhận vai
trò này. Giao diện người dùng sẽ chuyển sang giao diện của hình tiếp theo. Giữ lại cac
chức nay còn lại của ProxyManager Portlet.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xli
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Hình 3. 5: Lấy Proxy của người dùng qua OGCE portal
Hình trên là hình ảnh proxymanager-portlet của OGCE portal đã lấy về chứng chỉ Proxy
của user. Proxymanager-portlet còn hỗ trợ sử dụng nhiều chứng chỉ cùng thời, ở đó cho
phép user chuyển quyền sử dụng từ Proxy cộng đồng và Proxy cá nhân bằng chức năng
Set as default. Các portlet khác sẽ sử dụng Proxy được thiết lập mặc định là default proxy.
Còn bên dưới là hình của portlet OGCE jobsubmission:
Hình 3. 6:Portlet JobSubmission của OGCE portal
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xlii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Trong quá trình tìm hiểu và thực hiện đề tài thì nhóm đã hiện thực được hệ thống, có thể
nói là chấp nhận được hoạt động như hình bên dưới, bằng cách thực hiện tích hợp các
portlet JSR 168 của OGCE vào Sakai Portal.
Hình 3. 7:Sơ đồ hoạt động hệ thống đã hiện thực
Trong hệ thống Sakai của nhóm thì người dùng login vào Sakai ở bước 1,trong bước 2
sau đó sử dụng Portlet ProxyManger của OGCE portal để lấy các chứng chỉ từ Myproxy
Server. Tiếp theo tại bước 3 là lưu lại các chứng chỉ này vào Proxy Table trên portlet.
3.2 Đề xuất cơ chế tích hợp portlet JSR 168 vào Sakai
Từ yêu cầu của đề tài thì đòi hỏi phải có một cơ chế nào đó mà user đăng nhập vào Sakai
phải truy cập được hệ thống lưới thông qua Globus tookit 4.0. Dưới đây là ba phương án
mà nhóm đã tìm hiểu được.
3.2.1 Xây dựng các tool tương ứng
Sakai có thể chia ra làm hai phần một là Sakai container và Sakai tool. Để khai thác các
ứng dụng web người phát triển phải viết các tool cho Sakai.
Nhóm cũng đã tìm hiểu viết một tool cho Sakai sử dụng công cụ Sakai App Builder.
Quay lại vấn đề là chúng ta cần truy cập Grid thông qua Sakai do đó nhóm sẽ phải
phát triển các tool như proxymanager-tool hay jobsubmision-tool... các tool tương ứng
với các portlet của Sakai.
SVTH: Huỳnh Quang Trung – Đặng Hoàng Thiên Phong xliii
Xây dựng cơ chế Single Sign On từ môi trường Sakai vào VN-GRID GVHD: TS. Phạm Trần Vũ
Do đó người viết các tool này phải đảm bảo hiểu được hoạt động của code từng portlet
và các thư v
Các file đính kèm theo tài liệu này:
- Xây dựng cơ chế Single Sign On từ môi trường Sakai vào Việt Nam-GRID.pdf