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

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

pdf75 trang | Chia sẻ: netpro | Lượt xem: 2484 | Lượt tải: 3download
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:

  • pdfXây dựng cơ chế Single Sign On từ môi trường Sakai vào Việt Nam-GRID.pdf