Đề tài Nghiên cứu xây dựng CMS module cho hệ thống intranet của công ty TMA

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN CÔNG NGHỆ PHẦN MỀM ĐẶNG ĐÌNH VƯƠNG BÙI VĨNH PHÚ XÂY DỰNG CMS MODULE CHO HỆ THỐNG INTRANET CỦA CÔNG TY TMA KHÓA LUẬN CỬ NHÂN TIN HỌC TP. HCM, NĂM 2005 TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN CÔNG NGHỆ PHẦN MỀM ĐẶNG ĐÌNH VƯƠNG – 0112458 BÙI VĨNH PHÚ – 0112024 XÂY DỰNG CMS MODULE CHO HỆ THỐNG INTRANET CỦA CÔNG TY TMA KHÓA LUẬN CỬ NHÂN TIN HỌC GIÁO VIÊN HƯỚNG DẪN TS. TRẦN VIẾT HUÂN KS. NGUYỄN TẤN HỘ KS. LÊ THANH NHÀN TP. HCM, NĂM 2005 LỜI CẢM ƠN Chúng tôi xin chân thành cảm ơn Khoa Công nghệ Thông tin, trường Đại học Khoa học Tự nhiên, Thành phố Hồ Chí Minh và Công ty TMA đã tạo điều kiện cho chúng tôi thực hiện đề tài tốt nghiệp này. Xin cảm ơn Thầy Trần Viết Huân, Anh Nguyễn Tấn Hộ, Anh Lê Thanh Nhàn, người đã tận tình hướng dẫn, chỉ bảo chúng tôi trong suốt thời gian thực tập tại Công ty. Chúng tôi cảm ơn các anh chị trong nhóm TIS đã giúp đỡ, đóng góp ý kiến cho chúng tôi trong quá trình cài đặt, thử nghiệm chương trình. Xin gửi lời cảm ơn chân thành đến gia đình, ba mẹ và bè bạn vì đã luôn là nguồn động viên to lớn, giúp đỡ chúng tôi vượt qua những khó khăn trong suốt quá trình làm việc. Mặc dù đã cố gắng hoàn thiện luận văn với tất cả sự nỗ lực của bản thân, nhưng chắc chắn không thể tránh khỏi những thiếu sót. Kính mong quý Thầy Cô tận tình chỉ bảo. Một lần nữa, chúng tôi xin chân thành cảm ơn và luôn mong nhận được sự đóng góp quý báu của tất cả mọi người. Tháng 7 năm 2005 Đặng Đình Vương Bùi Vĩnh Phú Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA MỤC LỤC DANH SÁCH CÁC HÌNH VẼ ......................................................................................1 MỘT SỐ KÝ HIỆU VÀ TỪ VIẾT TẮT......................................................................4 MỞ ĐẦU .........................................................................................................................6 Chương 1 Giới thiệu đề tài ........................................................................................7 TỔNG QUAN ...............................................................................................................12 Chương 2 Tổng quan về sự phát triển của các hệ CMS .......................................13 NGHIÊN CỨU..............................................................................................................16 Chương 3 Nhu cầu sử dụng hệ CMS trong các tổ chức........................................17 1. Nhu cầu hiện tại ..................................................................................................18 1.1 Tình hình các web site của các tổ chức ở Việt Nam.....................................18 1.2 Nhu cầu cập nhật và quản lý nội dung..........................................................18 1.2.1 Nhu cầu của các doanh nghiệp...............................................................18 1.2.2 Nhu cầu của các tờ báo điện tử ..............................................................20 1.2.3 Nhu cầu trong các hệ thống thông tin của các công ty ..........................21 2. Những lợi ích mà một hệ CMS mang lại cho các công ty..................................23 Chương 4 Hệ thống intranet hiện tại của công ty .................................................25 1. Yêu cầu khi phát triển hệ thống intranet của công ty TMA ...............................26 1.1 Tình hình hiện tại ..........................................................................................26 1.2 Quy định về kiến trúc....................................................................................27 1.2.1 Kiến trúc mạnh .......................................................................................27 1.2.2 Xây dựng các công cụ hệ thống phi chức năng .....................................28 1.2.3 Bảo mật ..................................................................................................28 1.2.4 Khả năng tích hợp ..................................................................................29 1.3 Yêu cầu lúc phát triển ...................................................................................29 2. Portal hiện tại của TMA .....................................................................................30 2.1 Đặc điểm và các thành phần của portal ........................................................30 2.2 Các thành phần đã được xây dựng................................................................31 2.3 Kiến trúc hệ thống của portal........................................................................34 2.3.1 Kiến trúc hệ thống của các portal phổ biến............................................34 2.3.2 Kiến trúc hệ thống của portal TMA .......................................................35 3. Công nghệ được sử dụng để phát triển hệ thống intranet ...................................36 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA 4. Các chuẩn dùng để phát triển hệ thống...............................................................36 5. Nhu cầu của công ty TMA khi xây dựng một hệ CMS......................................37 5.1 Nhu cầu chia sẻ thông tin giữa các dự án và các vị trí công việc .................39 5.2 Xây dựng hệ CMS dưới dạng một portlet có thể được sử dụng bởi các ứng dụng và các thành phần khác ..............................................................................41 5.3 Các kỹ thuật sử dụng trong quá trình phát triển............................................41 Chương 5 Chuẩn JSR 168 .......................................................................................43 1. Giới thiệu về chuẩn JSR 168 ..............................................................................44 2. Một số khái niệm chính ......................................................................................45 2.1 Portal .............................................................................................................45 2.2 Portlet ............................................................................................................45 2.3 Portlet Container ...........................................................................................46 3. So sánh Portlet và Servlet ...................................................................................46 3.1 Điểm giống nhau giữa Portlet và Servlet ......................................................46 3.2 Điểm khác nhau giữa Portlet và Servlet .......................................................46 3.3 Đặc trưng của Portlet mà không có ở servlet................................................47 4. Giao diện portlet .................................................................................................47 5. Portlet URL.........................................................................................................48 6. Portlet Mode .......................................................................................................48 7. Window State......................................................................................................49 8. Portlet Request....................................................................................................50 9. Portlet Response .................................................................................................50 10. Portlet Preferences ............................................................................................51 11. Caching .............................................................................................................51 12. Ứng dụng Portlet...............................................................................................53 12.1 Các thành phần của ứng dụng Portlet .........................................................53 12.2 Cấu trúc cây thư mục ..................................................................................53 12.3 Tập tin lưu trữ của ứng dụng Portlet...........................................................54 13. Các đặc tả đóng gói và triển khai......................................................................54 13.1 Đặc tả triển khai của ứng dụng Web và ứng dụng Portlet ..........................54 13.2 Triển khai ứng dụng Portlet và ứng dụng Web...........................................55 13.3 Các thành phần của đặc tả triển khai Portlet...............................................55 13.4 Tính duy nhất của các giá trị trong đặc tả triển khai Portlet .......................59 14. Thư viện các thẻ Portlet ....................................................................................59 14.1 Thẻ actionURL............................................................................................60 14.2 Thẻ renderURL ...........................................................................................60 Chương 6 Chuẩn JSR 170 .......................................................................................61 1. Giới thiệu về chuẩn JSR 170 ..............................................................................62 2. Mô hình repository..............................................................................................63 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA 3. Một số API cơ bản ..............................................................................................64 3.1 Thao tác trên repository ................................................................................66 4. Sự liên hệ giữa Node, Property và Item..............................................................67 5. Sự sắp xếp các Item con .....................................................................................67 6. Namespace ..........................................................................................................68 7. Property...............................................................................................................69 7.1 Property đa trị................................................................................................69 7.2 Các kiểu dữ liệu của Property .......................................................................69 7.2.1 Kiểu Date................................................................................................70 7.2.2 Kiểu Reference, Path và Name ..............................................................70 8. Node....................................................................................................................71 8.1 Quan hệ giữa các node cùng tên và cùng cha ( Same-Name Siblings ) .......71 8.2 Các kiểu của Node ........................................................................................71 8.2.1 Kiểu node chính và kiểu node phụ .........................................................73 8.2.2 Property definitions ................................................................................73 8.2.3 Child Node Definitions ..........................................................................74 8.2.4 Các kiểu node được định nghĩa sẵn .......................................................75 8.3 Node tham chiếu (Referenceable Nodes) .....................................................78 9. Workspace ..........................................................................................................79 9.1 Repository có một workspace.......................................................................79 9.2 Repository có nhiều Workspace và sự tương ứng các node .........................80 10. Tạo phiên bản ( Versioning ) ............................................................................82 10.1 Version History ...........................................................................................83 10.2 Mối quan hệ giữa các versionable node và version history ........................84 10.3 Đồ Thị Biểu Diễn Các Phiên Bản Trên Repository....................................84 10.4 Phiên Bản Cơ Bản (Base Version)..............................................................85 10.5 Khởi Tạo Một Version History...................................................................85 10.6 Tạo Phiên Bản Mới Của Một Node ............................................................86 10.7 Phục Hồi Lại Trạng Thái Trước Đó Của Node ..........................................87 10.8 Checkout .....................................................................................................88 10.9 Update .........................................................................................................88 10.10 Các Node Có Thể Tạo Phiên Bản Trên Repository..................................89 10.11 Thuộc Tính OnParentVersion ...................................................................91 10.11.1 COPY .................................................................................................92 10.11.2 VERSION...........................................................................................93 10.11.3 INITIALIZE.......................................................................................93 10.11.4 COMPUTE.........................................................................................94 10.11.5 IGNORE.............................................................................................94 10.11.6 ABORT ..............................................................................................94 10.12 Ví dụ về một Repository có hỗ trợ tạo phiên bản .....................................95 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA 11. Lắng Nghe Sự Kiện Trên Repository (Observation)........................................96 11.1 Phát sinh sự kiện .........................................................................................96 11.2 Các loại sự kiện...........................................................................................97 11.3 Đối tượng lắng nghe và xử lý sự kiện.........................................................98 11.4 Lựa chọn sự kiện để lắng nghe ...................................................................99 11.5 Các sự kiện xảy ra đối với một hành động trên Repository........................99 11.5.1 Hành động thêm một Item....................................................................99 11.5.2 Hành động thay đổi giá trị của Property ............................................100 11.5.3 Hành động thêm vào một Node đã tồn tại trong Repository .............100 11.5.4 Khôi phục lại trạng thái của một Node ..............................................101 11.5.5 Sao chép một Node ............................................................................101 11.5.6 Xóa một Item......................................................................................102 11.5.7 Di chuyển vị trí của một Node ...........................................................102 11.5.8 Tạo Phiên Bản Của Item ....................................................................102 11.5.9 Khoá một Item....................................................................................103 11.5.10 Mở khóa một Item............................................................................103 12. Vấn đề bảo mật trên Repository .....................................................................104 13. Cơ chế khóa trên Repository ..........................................................................104 13.1 Mức độ khóa .............................................................................................104 13.2 Phạm vi khóa.............................................................................................104 13.3 Loại khóa...................................................................................................105 14. Tìm kiếm nội dung trên Repository................................................................105 14.1 Ngôn ngữ truy vấn JCRQL .......................................................................106 14.1.1 Mệnh đề SELECT ..............................................................................106 14.1.2 Mệnh đề FROM .................................................................................106 14.1.3 Mệnh đề LOCATION ........................................................................106 14.1.4 Mệnh đề WHERE...............................................................................109 14.1.5 Mệnh đề SEARCH.............................................................................110 14.1.6 Mệnh đề ORDER BY.........................................................................111 15. Một số ví dụ về việc cài đặt JCR ....................................................................112 15.1 JCR cài đặt bên trên File System ..............................................................112 15.2 JCR cài đặt bên trên một Database ...........................................................113 Chương 7 So sánh một số giải pháp CMS mã nguồn mở phổ biến ...................115 1. Giới thiệu các giải pháp hiện tại .......................................................................116 1.1 Xu hướng phát triển của các hệ CMS .........................................................116 1.1.1 Xu hướng về mặt thương mại ..............................................................116 1.1.2 Xu hướng về công nghệ, kỹ thuật ........................................................117 1.2 So sánh các giải pháp CMS thông dụng .....................................................118 1.2.1 Tiêu chí lựa chọn các giải pháp CMS để so sánh ................................118 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA 1.2.2 Các tiêu chí so sánh..............................................................................118 2. Mô tả các giải pháp đã so sánh .........................................................................123 2.1 Giải pháp Cofax 2.0 ....................................................................................123 2.2 Giải pháp Daisy 1.1.....................................................................................125 2.2.1 Repository chứa nội dung ....................................................................126 2.2.2 Giao diện web.......................................................................................126 2.3 Giải pháp Magnolia 2.1...............................................................................127 2.4 Giải pháp OpenCMS 5.0.............................................................................129 3. Kết luận.............................................................................................................130 ỨNG DỤNG................................................................................................................132 Chương 8 Các chức năng của TMA CMS ...........................................................133 1. Mô hình Use case..............................................................................................134 2. Mô tả các chức năng .........................................................................................135 2.1 Quản lý vai trò.............................................................................................135 2.2 Quản lý người sử dụng................................................................................135 2.3 Phân quyền sử dụng cho vai trò ..................................................................136 2.4 Phân phối vai trò đến người sử dụng ..........................................................137 2.5 Tối ưu hoá các thông tin cấu hình hệ thống................................................138 2.6 Biên soạn nội dung trang web.....................................................................138 2.7 Áp dụng template vào trang web ................................................................139 2.8 Phân loại nội dung.......................................................................................139 2.9 Truy nhập vào hệ CMS ...............................................................................139 2.10 Tìm kiếm nội dung....................................................................................140 2.11 Lựa chọn ngôn ngữ ...................................................................................140 Chương 9 Tích hợp hệ thống CMS vào TMA portal ..........................................141 1. System Architecture của Magnolia CMS .........................................................142 1.1 Mô hình một số package quan trọng của Magnolia CMS ..........................142 1.2 Mô tả các package.......................................................................................142 1.2.1 Package info.magnolia.cms..................................................................142 1.2.2 Package info.magnolia.cms. security ...................................................143 1.2.3 Package info.magnolia.cms.servlets ....................................................143 1.2.4 Package info.magnolia.cms.core..........................................................143 1.2.5 Package info.magnolia.module.adminInterface...................................143 1.2.6 Package info.magnolia.module.templating..........................................144 1.2.7 Package info.magnolia.repository........................................................144 1.2.8 Package info.magnolia.exchange .........................................................144 2. Hướng tiếp cận để tích hợp...............................................................................144 2.1 Hướng tiếp cận thứ 1...................................................................................144 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA 2.2 Hướng tiếp cận thứ 2...................................................................................145 3. Cách thức thực hiện ..........................................................................................146 3.1 Tạo dự án J2EE dựa trên mã nguồn của Magnolia .....................................147 3.2 Chuẩn hoá dự án J2EE theo chuẩn JSR 168 ...............................................147 3.3 Tích hợp hệ thống bảo mật .........................................................................151 KẾT LUẬN.................................................................................................................152 HƯỚNG PHÁT TRIỂN.............................................................................................155 TÀI LIỆU THAM KHẢO .........................................................................................157 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 1 Đặng Đình Vương DANH SÁCH CÁC HÌNH VẼ Hình 1: Hệ CMS quản lý tự động nội dung trang web ....................................................8 Hình 2: Giao diện hệ thống intranet của công ty TMA ...................................................9 Hình 3: Hệ thống thông tin hiện tại của công ty TMA ..................................................10 Hình 4: Quy trình cập nhật thông tin trong doanh nghiệp .............................................19 Hình 5: Quy trình cập nhật thông tin trong doanh nghiệp khi sử dụng CMS................19 Hình 6: Quy trình cập nhật thông tin trong một tờ báo địên tử .....................................20 Hình 7: Quy trình cập nhật thông tin trong toà soạn báo điện tử có sử dụng hệ CMS..21 Hình 8: Quy trình cập nhật thông tin trong một hệ thống thông tin ..............................22 Hình 9: Quy trình cập nhật thông tin trong một hệ thống thông tin có CMS ................23 Hình 10: Kiến trúc SOA của intranet của công ty TMA ...............................................26 Hình 11: Các thành phần trong portal của công ty TMA ..............................................33 Hình 12: Kiến trúc hệ thống của các portal phổ biến ....................................................34 Hình 13: Kiến trúc hệ thống của portal TMA................................................................35 Hình 14: Chia sẻ thông tin giữa các dự án và vị trí công việc trong công ty TMA.......40 Hình 15: Mô hình chuẩn JSR 168..................................................................................44 Hình 16: Cấu trúc một đặc tả triển khai Portlet .............................................................57 Hình 17: Cấu trúc một đặc tả triển khai Portlet (tt) .......................................................58 Hình 18: Chuẩn JSR 170 giao tiếp với cơ sở dữ liệu.....................................................62 Hình 19: Mô hình một workspace của một repository ..................................................63 Hình 20: Mối liên hệ giữa Node, Property và Item .......................................................67 Hình 21: Repository có một workspace........................................................................79 Hình 22: Repository có nhiều workspace .....................................................................81 Hình 23: Đồ thị mô tả một Version History..................................................................83 Hình 24: Repository có nhiều workspace và hỗ trợ tạo phiên bản ................................95 Hình 25: Giao diện Cofax ............................................................................................123 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 2 Đặng Đình Vương Hình 26: Giao diện Daisy.............................................................................................125 Hình 27: Giao diện Magnolia.......................................................................................127 Hình 28: Giao diện OpenCMS.....................................................................................129 Hình 29: Các gói chính của Magnolia CMS................................................................142 Hình 30: Cấu trúc dự án J2EE của hệ CMS.................................................................148 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 3 Đặng Đình Vương DANH SÁCH CÁC BẢNG Bảng 1: Một số thành phần đã được xây dựng trong hệ thống portal của Công ty .......32 Bảng 2: Các hằng số trong giao diện javax.jcr.version.OnParentVersionAction..........92 Bảng 3: Các hằng số định nghĩa trong giao diện javax.jcr.observation.EvenType ......97 Bảng 4: So sánh yêu cầu hệ thống của một số CMS ...................................................119 Bảng 5: So sánh tính bảo mật của một số CMS...........................................................119 Bảng 6: So sánh tính tiện dụng của một số CMS ........................................................120 Bảng 7: So sánh hiệu suất hoạt động của một số CMS ...............................................120 Bảng 8: So sánh tính khả chuyển của một số CMS .....................................................121 Bảng 9: So sánh khả năng quản lý của một số CMS ...................................................121 Bảng 10: So sánh các khả năng hỗ trợ khác của một số CMS.....................................122 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 4 Đặng Đình Vương MỘT SỐ KÝ HIỆU VÀ TỪ VIẾT TẮT API Application Programming Interface CMS Content Management System Drag’n’drop Thuật ngữ Drag and Drop Eclipse Phần mềm miễn phí dùng phát triển các ứng dụng trên Java HTML Hyper Text Markup Language HTTP Hypertext Transfer Protocol HTTPS Secure Hypertext Transfer Protocol JBoss Web application server miễn phí JCR Java Content Repository JDK Java Development Kit JSR Java Specification Request Lomboz plug-in giúp Eclipse giao tiếp với JBoss và tạo các dự án J2EE MIME Multipurpose Internet Mail Extensions MVC Mô hình thiết kế Model-View-Controller ORB Object Request Broker RMI-IIOP Remote Method Invocation over internet Inter-ORB Protocol SOA Service Oriented Architecture SOAP Simple Object Access Protocol Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 5 Đặng Đình Vương SPI Service Provider Interface URI Uniform Resource Identifiers URL Uniform Resource Locator XHTML eXtensible Hyper Text Markup Language XML eXtensible Markup Language WSRP web Services for Remote portlets WYSIWYG What You See Is What You Get Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 6 Đặng Đình Vương MỞ ĐẦU Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 7 Đặng Đình Vương Chương 1 Giới thiệu đề tài Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 8 Đặng Đình Vương Một cách đơn giản nhất, CMS là một hệ thống hỗ trợ người sử dụng trong việc tạo ra các trang web, quản lý nội dung các trang web. Sau cùng, các trang web sẽ được xuất bản để phân phối đến mọi người. Cả quy trình từ lúc tạo ra nội dung trang web, quản lý nội dung được tạo ra và sau cùng phân phối nội dung này đều hoàn toàn tự động. Hình vẽ sau sẽ mô tả cho quy trình tự động này. Hình 1: Hệ CMS quản lý tự động nội dung trang web Luận văn này được thực hiện trong quá trình thực tập của chúng tôi tại công ty phần mềm Tường Minh (TMA). Khi luận văn bắt đầu thì hệ thống thống tin (intranet) của công ty đang được xây dựng lại. Việc xây dựng này dựa trên các chuẩn mở và các công nghệ, giải pháp mã nguồn mở. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 9 Đặng Đình Vương Hình 2: Giao diện hệ thống intranet của công ty TMA Hệ thống Intranet của công ty TMA hỗ trợ các công cụ, các chức năng như sau: • Quản lý nhân sự • Quản lý năng lực của nhân viên • Quản lý tuyển dụng • Quản lý thông tin các dự án • Hệ quản lý tài liệu • Tìm kiếm thông tin • Hệ thống bảo mật • Các sự kiện nội bộ của công ty • … Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 10 Đặng Đình Vương Hệ thống thông tin này nếu được nhìn dưới góc độ của người phát triển sẽ bao gồm các thành phần như sau: Portal được xây dựng dựa trên Liferay HR Employee Contact Project Information Các ứng dụng Recruitment PA Event Các dịch vụ HR Recruitment Search Các thành phần chức năng Search Engine Authentifi- cation Scheduling System Workflow Engine Các thành phần phi chức năng Cung cấp Cung cấp Cung cấp DMS CMS Reporting Engine Hình 3: Hệ thống thông tin hiện tại của công ty TMA Hệ thống thông tin này bao gồm các ứng dụng, các dịch vụ dùng để hỗ trợ hoạt động cho các ứng dụng. Ngoài ra, còn có các thành phần chức năng dùng để cung cấp Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 11 Đặng Đình Vương các chức năng cho các dịch vụ. Các thành phần phi chức năng dùng để hỗ trợ hoạt động cho các ứng dụng, các dịch vụ và các thành phần chức năng. Hệ CMS cần xây dựng cho công ty TMA sẽ thuộc nhóm các thành phần phi chức năng như trên hình vẽ trên đã minh hoạ. Mục đích chính của đề tài này là xây dựng và tích hợp CMS module vào trong hệ thống intranet của công ty TMA. Để thực hiện điều này, chúng tôi đã thực hiện 3 công việc chính như sau: • Nghiên cứu về CMS. • Tìm hiểu và so sánh các giải pháp xây dựng CMS để chọn ra giải pháp thích hợp nhất với yêu cầu công ty. • Tích hợp giải pháp đã chọn vào trong hệ thống intranet của công ty. Chúng tôi thực hiện đề tài này ngoài mong muốn bảo vệ thành công khoá luận của mình, còn muốn qua đó học hỏi thêm nhiều kiến thức và kinh nghiệm trong việc phát triển một hệ CMS, một lãnh vực mới mẻ và đầy tiềm năng. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 12 Đặng Đình Vương TỔNG QUAN Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 13 Đặng Đình Vương Chương 2 Tổng quan về sự phát triển của các hệ CMS Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 14 Đặng Đình Vương Xây dựng hệ thống CMS là một lãnh vực chỉ mới xuất hiện trong 6 năm gần đây. Công ty Microsoft chỉ mới tham gia lãnh vực này vào năm 2002. Ở Việt Nam, số lượng các công ty xây dựng và sử dụng các hệ CMS vẫn rất giới hạn do đây vẫn còn là lãnh vực quá mới mẻ ở nước ta. Tuy chỉ mới xuất hiện gần đây nhưng lãnh vực này cũng đạt được một số kết quả khả quan. Các công nghệ và các tiêu chuẩn đã được đề ra để phát triển các hệ CMS. Đa phần các công ty phát triển các hệ CMS đều với mục đích kinh doanh. Bên cạnh đó cũng có những công ty, tổ chức và cá nhân cung cấp các giải pháp CMS của họ dưới dạng mã nguồn mở hay miễn phí. Các công nghệ sử dụng cho việc phát triển các hệ CMS cũng rất đa dạng. Sự đa dạng này có thể thấy rõ qua thống kê sau đây: • Java: CMS Genie, CMS Master, Cofax, Contelligent, Daisy, Eplica, imCMS, Jahia, jNetPublish, Magnolia, NetPotential CM… • Java Script: CMS Master, Complete Site Manager, Contelligent, e107, eazyCMS, Magnolia, NetPotential CMS, Open CMS… • PHP: Acuity CMS, AGPCMS, Aiyoota!-CMS, Back-End CMS, BxCMS, Caravel, CathDesign CMS, Complete Site Manager, dotWidget CMS, e107, eazyCMS, EGOCMS, fly CMS, Jaws, Mambo, Komodo CMS, OpenPHPNuke, PostNuke… • C++: Lighthouse, Manila… • ASP: Acuity CMS, Baseline CMS… • Cold Fusion: AssetNow, EasyConsole CMS… • ASP.NET: AxCMS.net, Composite CMS, contentXXL - ASP.NET CMS, DotNetNuke, Dozing Dogs ASP.NET CMS, Dynamicweb… Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 15 Đặng Đình Vương • VB.NET: AxCMS.net, contentXXL - ASP.NET CMS, Dozing Dogs ASP.NET CMS… • C#: AxCMS.net, contentXXL - ASP.NET CMS, Dozing Dogs ASP.NET CMS, Rainbow… • Python: Easy Publisher… Một số hệ CMS được xây dựng như là một thành phần của portal. Số còn lại được phát triển dưới dạng một ứng dụng hoạt động độc lập. Ngoài 2 dạng CMS vừa nêu thì việc sử dụng một hệ CMS độc lập để tích hợp vào một portal có sẵn vẫn rất mới mẻ. Do đó, các tài liệu về công việc này rất giới hạn và số lượng các người phát triển am tường về lãnh vực này cũng rất hiếm. Thật vậy, trong quá trình thực hiện đề tài, khi chúng tôi gặp các vấn đề và đem các vấn đề này để hỏi các lập trình viên chuyên phát triển các hệ CMS thì họ cũng không có câu trả lời xác đáng cho các vấn đề chúng tôi đã gặp phải. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 16 Đặng Đình Vương NGHIÊN CỨU Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 17 Đặng Đình Vương Chương 3 Nhu cầu sử dụng hệ CMS trong các tổ chức Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 18 Đặng Đình Vương 1. Nhu cầu hiện tại 1.1 Tình hình các web site của các tổ chức ở Việt Nam Ở Việt Nam, theo đà phát triển của kinh tế, số lượng các doanh nghiệp và các tổ chức xuất hiện này càng nhiều. Các tổ chức này đều có nhu cầu cung cấp thông tin cho khách hàng của mình. Do đó, việc tạo ra các web site cho các tổ chức này là tối cần thiết. Tuy nhiên, nội dung các web site của Việt Nam đa số còn sơ sài và không đáp ứng được nhu cầu của khách hàng. Một trong các lý do chính của tình trạng này là sự thiếu cập nhật thông tin lên các web site. Nhưng nguyên nhân sâu xa về mặt kỹ thuật là thiếu các phần mềm dùng để cập nhật và quản lý nội dung các web site. 1.2 Nhu cầu cập nhật và quản lý nội dung 1.2.1 Nhu cầu của các doanh nghiệp Để cập nhật thông tin cho các trang web trong doanh nghiệp, người ta cần phải thu thập các thông tin từ nhiều nguồn khác nhau. Sau đó, các thông tin này sẽ được chuyển cho nhóm phụ trách về web site của doanh nghiệp đó để cập nhật lên web site của họ. Hình vẽ sau sẽ minh họa cho quy trình cập nhật thông tin này Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 19 Đặng Đình Vương Hình 4: Quy trình cập nhật thông tin trong doanh nghiệp Với một hệ CMS, doanh nghiệp không cần phải có nhóm phụ trách web bởi vì mọi thao tác cập nhật thông tin đều được làm một cách tự động. Ngoài ra, thời gian cập nhật nội dung cũng được giảm thiểu một cách đáng kể. Hình vẽ sau sẽ minh họa cho quy trình cập nhật thông tin trong doanh nghiệp khi sử dụng một hệ CMS. Hình 5: Quy trình cập nhật thông tin trong doanh nghiệp khi sử dụng CMS Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 20 Đặng Đình Vương 1.2.2 Nhu cầu của các tờ báo điện tử Trong các toà soạn báo điện tử, để cập nhật thông tin thường xuyên, các phóng viên và các nhà báo phải tập hợp thông tin từ nhiều nguồn khác nhau. Sau đó, các thông tin này phải chờ sự kiểm duyệt. Các thông tin sau khi được kiểm duyệt sẽ chuyển cho đội ngũ làm web của toà soạn để cập nhật lên web site của báo điện tử. Hình 6: Quy trình cập nhật thông tin trong một tờ báo địên tử Nếu sử dụng một hệ CMS trong toà soạn của mình, toàn soạn báo có thể giảm đi một số bước trong quy trình cập nhật thông tin của họ. Do đó, họ có thể giảm thiểu thời gian và công sức làm công việc này. Bởi vì khi đã sử dụng hệ CMS thì họ không cần phải có đội ngũ làm web cho toàn soạn và các biên tập viên có thể duyệt các thông tin này bằng cách sử dụng hệ CMS. Ngoài ra, hệ CMS còn có thể giúp các phóng viên và các nhà báo trong việc thu thập thông tin. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 21 Đặng Đình Vương Hình vẽ sau sẽ minh hoạ quy trình cập nhật thông tin trong một toà soạn báo có sử dụng hệ CMS Hình 7: Quy trình cập nhật thông tin trong toà soạn báo điện tử có sử dụng hệ CMS 1.2.3 Nhu cầu trong các hệ thống thông tin của các công ty Trong các hệ thống thông tin của các công ty, người ta phân thành các phòng ban và các dự án. Các phòng ban và các dự án này có nhiệm vụ phải cung cấp thông tin cho nhóm làm web của công ty. Sau đó, thông tin này mới được cập nhật lên hệ thống Intranet. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 22 Đặng Đình Vương Quy trình cập nhật thông tin này được minh hoạ bằng hình vẽ dưới đây. Hình 8: Quy trình cập nhật thông tin trong một hệ thống thông tin Trong quy trình này, các phòng ban và các dự án sở hữu thông tin riêng của họ. Tuy nhiên, họ không có quyền đưa các thông tin này lên hệ thống intranet của công ty. Việc cập nhật thông tin bị phụ thuộc vào nhóm làm web. Do đó, khi nhóm làm web nhận được thông tin từ các phòng ban và các dự án, họ cần phải kiểm tra lại tính chính xác của thông tin đó trước khi cập nhật thông tin lên hệ thống intranet. Do các phòng ban và các dự án quá bận rộn với công việc của họ, họ thường không cung cấp thông tin thường xuyên cho nhóm làm web để cập nhật thông tin về phòng ban hay dự án của mình. Khi những thông tin trên intranet của công ty quá lỗi thời vì không được cập nhật thường xuyên thì nhóm làm web mới nhắc nhở các phòng ban và các dự án cung cấp thông tin cho mình để cập nhật. Và điều này thật sự làm chán nản cả nhóm làm web lẫn các phòng ban và các thành viên của dự án. Ngược lại, khi sử dụng một hệ CMS trong hệ thống thông tin của công ty, các phòng ban và các dự án có thể cập nhật các thông tin của họ một cách nhanh chóng mà không cần phải phụ thuộc vào nhóm làm web. Hơn nữa, chính các phòng ban và các dự án sẽ chịu trách nhiệm về các thông tin mà mình đưa lên cũng như là tình trạng thông Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 23 Đặng Đình Vương tin thiếu cập nhật về phòng ban hay dự án của mình. Do đó, các phòng ban và các dự án sẽ cảm thấy có trách nhiệm hơn với việc cập nhật thông tin thường xuyên này. Hình 9: Quy trình cập nhật thông tin trong một hệ thống thông tin có CMS Ngoài ra, hệ thống thông tin của công ty có thể sử dụng hệ CMS này như một công cụ để quản lý nội dung. Và công cụ này được sẽ được sử dụng bởi nhiều ứng dụng khác nhau trên intranet. 2. Những lợi ích mà một hệ CMS mang lại cho các công ty Do đề tài này được thực hiện nhằm phát triển một hệ CMS cho công ty TMA, do đó, chúng tôi chỉ quan tâm và nêu ra những lợi ích mà một hệ CMS mang lại cho hệ thống intranet của Công ty. Những lợi ích này được trình bày dưới đây: • Cập nhật thông tin nhanh chóng. • Giảm thời gian, công sức và chi phí cho việc cập nhật thông tin. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 24 Đặng Đình Vương • Các ứng dụng khác có thể sử dụng hệ CMS này như một công cụ hỗ trợ cho việc cung cấp và cập nhật thông tin. • Giúp người sử dụng dễ dàng tạo ra nội dung các trang web trong một môi trường thuận tiện. • Phân quyền sử dụng tương ứng với mỗi người sử dụng. • Cá nhân hoá thông tin người sử dụng. • Cung cấp cơ chế tìm kiếm thông tin. • Áp dụng các template để giúp cho việc tạo ra nội dung một cách đồng nhất. • Cho phép thay đổi dễ dàng cách thức hiển thị của các trang web trong web site. • Chấm dứt tình trạng thông tin thiếu cập nhật trên các web site. • Nâng cao trách nhiệm của các phòng ban và các đề án trong công việc cập nhật thông tin về phòng ban và đề án. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 25 Đặng Đình Vương Chương 4 Hệ thống intranet hiện tại của công ty Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 26 Đặng Đình Vương 1. Yêu cầu khi phát triển hệ thống intranet của công ty TMA 1.1 Tình hình hiện tại Khi đề tài này được bắt đầu thì nhóm TIS (TMA Information System) đang phát triển một hệ thống intranet mới cho công ty dựa trên kiến trúc SOA (Service Oriented Architecture). Hình vẽ sau sẽ minh hoạ cho kiến trúc này. Portal được xây dựng dựa trên Liferay Hình 10: Kiến trúc SOA của intranet của công ty TMA Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 27 Đặng Đình Vương Trong hình vẽ trên, chúng ta có thể liệt kê một số thành phần như sau: • Các ứng dụng: quản lý nhóm, thông tin liên hệ nhân viên, quản lý nhân sự, quản lý thông tin các dự án… • Các Dịch vụ: Dịch vụ bảo mật, dịch vụ tuyển dụng… • Các thành phần chức năng: Các gói thư viện dùng chung… • Các thành phần phi chức năng: Hệ quản lý tài liệu, Hệ quản lý nội dung, Hệ tìm kiếm thông tin, Hệ hỗ trợ làm báo cáo… Trong quá trình xây dựng hệ thống intranet, công ty đề ra các yêu cầu để phát triển một hệ thống ổn định, chẳng hạn các yêu cầu về hệ thống và các yêu cầu về triển khai. Các thành viên tham gia phát triển hệ thống và các thành phần liên quan phải tuân thủ các quy định đã đề ra. 1.2 Quy định về kiến trúc 1.2.1 Kiến trúc mạnh Một kiến trúc mạnh được xây dựng phải bao gồm các tính chất sau: • Có thể dễ dàng mở rộng kiến trúc intranet trong tương lai. • Hệ thống phải hoạt động ổn định. • Intranet có thể sử dụng dưới dạng một hệ thống phân tán. • Intranet hỗ trợ nhiều loại ứng dụng. • Intranet hoạt động với hiệu suất cao. • Intranet sử dụng các thành phần mã nguồn mở và miễn phí. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 28 Đặng Đình Vương 1.2.2 Xây dựng các công cụ hệ thống phi chức năng Hệ thống intranet bao gồm một số công cụ phi chức năng như sau : • Thành phần bảo mật: hệ thống intranet có một hệ thống bảo mật cho phép phân quyền những người sử dụng trên hệ thống. • Kiểm soát quy trình xử lý: hệ thống intranet xác định cơ chế quản lý các quy trình xử lý. • Hệ quản lý nội dung trang web: hệ thống intranet cung cấp các thành phần dùng để quản lý nội dung các trang web. • Hệ quản lý tài liệu: hệ thống intranet cung cấp các thành phần dùng để quản lý tài liệu trong hệ thống hệ thống intranet. • Các template của giao diện người dùng: hệ thống intranet hỗ trợ các template để giúp cho người sử dụng tạo ra nhanh chóng và dễ dàng nội dung một cách đồng nhất. 1.2.3 Bảo mật • Hỗ trợ nhiều loại người dùng: do trong công ty TMA có nhiều nhóm và trong mỗi nhóm có nhiều vị trí công việc khác nhau nên cần phải hỗ trợ nhiều loại người dùng khác nhau. • Truy cập mọi nơi: do các nhân viên của công ty có nhu cầu truy cập vào mạng intranet của công ty khi họ trở về nhà của họ nên hệ thống intranet sẽ hỗ trợ cơ chế để đáp ứng nhu cầu này • Ghi nhận truy cập: hệ thống intranet ghi nhớ các thao tác trên hệ thống trong phiên làm việc của từng người sử dụng. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 29 Đặng Đình Vương 1.2.4 Khả năng tích hợp Các yêu cầu này cho phép tích hợp dễ dàng các module vào trong hệ thống intranet của công ty: • Kiến trúc mã nguồn mở: đặc điểm này cho phép hỗ trợ nhiều công nghệ khác nhau cùng hoạt động . • Sử dụng các thư viện có sẵn thay vì xây dựng từ đầu. 1.3 Yêu cầu lúc phát triển Do hệ thống intranet được xây dựng để sử dụng trong nội bộ của công ty TMA, Công ty đã đặt ra các yêu cầu trong quá trình phát triển như sau: • Cần phải sử dụng các công cụ mã nguồn mở và miễn phí để phát triển hệ thống. • Cần phải sử dụng các công cụ trên nền web để tích hợp dễ dàng các công cụ này vào hệ thống thông tin hiện tại của TMA. • Hệ thống intranet và các thành phần của nó được xây dựng dựa trên mã nguồn mở và miễn phí. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 30 Đặng Đình Vương 2. Portal hiện tại của TMA 2.1 Đặc điểm và các thành phần của portal Theo như thiết kế ban đầu, portal của công ty TMA bao gồm các các đặc điểm sau: • Cơ chế bảo mật: đây chính là đặc điểm quan trọng nhất của portal dùng để kiểm soát truy cập của người sử dụng. • Khả năng tích hợp: đặc điểm này cho phép tích hợp các thành phần khác nhau vào trong nhân của portal. • Hệ quản trị tài liệu: hệ thống này dùng để quản lý các tài liệu sử dụng trong nội bộ công ty. • Hệ quản trị nội dung: hệ thống này dùng để quản lý nội dung các trang web được sử dụng trong nội bộ Công ty. • Cơ chế tìm kiếm: cơ chế cho phép các nhân viên trong Công ty tìm kiếm thông tin cần thiết của họ. • Cơ chế hỗ trợ báo cáo. • Hệ quản lý quy trình hoạt động: hệ thống này giúp cho các nhân viên trong công việc của họ. Khi có sự thay đổi xảy ra trong quy trình làm việc thì chỉ cần định nghĩa lại thứ tự thực hiện các công việc trong quy trình để nhận được cùng một kết quả như lúc chưa thay đổi, thay vì phải viết lại toàn bộ quy trình làm việc. • Hệ quản lý lịch trình: hệ thống hoạt động vào một thời điểm định trước trong tương lai. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 31 Đặng Đình Vương Trong các thành phần nêu trên, có một số thành phần đã được xây dựng hoàn thiện và số còn lại đang trong giai đoạn thực hiện. 2.2 Các thành phần đã được xây dựng Vào thời điểm bắt đầu thực hiện luận án này, các thành phần sau đã được xây dựng và tích hợp vào portal của công ty: Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 32 Đặng Đình Vương Module Mã nguồn mở sử dụng Portal Liferay INDEX Document Management System OpenEDMS và Knowledge Tree Search Engine Report Engine Datavision Workflow Engine Bonita Bảng 1: Một số thành phần đã được xây dựng trong hệ thống portal của Công ty Các đặc điểm và các thành phần trong portal của công ty được thể hiện trong hình vẽ sau: Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 33 Đặng Đình Vương Enterprise Portal Document Management Integration Reporting engine Security Workflow management Content management Scheduling system Searching Engine Hình 11: Các thành phần trong portal của công ty TMA ht://Dig Liferay Bonita Datavision OpenEDMS & Knowledge Tree Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 34 Đặng Đình Vương 2.3 Kiến trúc hệ thống của portal 2.3.1 Kiến trúc hệ thống của các portal phổ biến Hình 12: Kiến trúc hệ thống của các portal phổ biến Trong các portal phổ biến, người ta sử dụng trình duyệt web và giao thức HTTP để kết nối đến các ứng dụng web trên portal. Mỗi portal có duy nhất một portlet/servlet container. Các ứng dụng web của portal giao tiếp với portlet/servlet container bởi các APIs và các SPIs. Portlet/servlet container chứa toàn bộ các portlet. Các portlet này cung cấp các APIs để portlet/servlet container có thể sử dụng các chức năng của nó Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 35 Đặng Đình Vương 2.3.2 Kiến trúc hệ thống của portal TMA Hình 13: Kiến trúc hệ thống của portal TMA Trong kiến trúc này, khi ta nhập vào dữ liệu dạng HTML, WML hay XML (“Web services” trong hình vẽ), các dữ liệu này đi qua 3 tầng: trình diễn, xử lý và dữ liệu của mô hình MVC. Trong 3 tầng này, người ta có thể sử dụng các công nghệ như: struts, servlet, spring, EJB, Hibernate, JMS… Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 36 Đặng Đình Vương Ngoài dữ liệu dạng HTML, WML hay XML, chúng ta còn có thể sử dụng các đối tượng dưới dạng J2EE, J2SE hay J2ME. 3. Công nghệ được sử dụng để phát triển hệ thống intranet Trong quá trình xây dựng hệ thống intranet, các công nghệ và kỹ thuật sau đã được sử dụng: • Multi-platform: Linux, Solaris, Windows • Platform : .NET, J2EE • XML, SOAP, HTTP, RMI-IIOP, WSRP... • Hệ quản trị cơ sở dữ liệu: Hypersonic, MySQL, PostgreSQL, SQL Server. • Web application server: JBoss, TomCat, Sun ONE, webLogic, Jonas. 4. Các chuẩn dùng để phát triển hệ thống Trong quá trình phát triển hệ thống intranet của Công ty, Công ty đã quyết định các thành phần được xây dựng cần tuân theo các chuẩn trên thế giới nếu có thể được. Sự phát triển các thành phần dựa trên các chuẩn này có các lợi ích như sau: • Sử dụng một chuẩn để phát triển sẽ cần ít thời gian và chi phí hơn. • Trên thế giới đều biết đến chuẩn được sử dụng để phát triển, do đó sẽ có nhiều sự hỗ trợ hơn trong quá trình xây dựng các thành phần. • Có nhiều mã nguồn mở được xây dựng dựa trên các tiêu chuẩn, do đó có thể tận dụng các thành phần này cho portal. • Các thành phần được xây dựng dựa trên các chuẩn sẽ tích hợp dễ dàng hơn vào hệ thống hiện tại. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 37 Đặng Đình Vương • Để mở rộng hệ thống hiện tại trong tương lai, cần phải xây dựng các thành phần theo chuẩn. Sau đây là các chuẩn được yêu cầu sử dụng trong quá trình phát triển hệ thống thông tin của công ty: • Chuẩn JSR 168 dùng để xây dựng các portlet. • Chuẩn JSR 170 để xây dựng hệ CMS. 5. Nhu cầu của công ty TMA khi xây dựng một hệ CMS Hệ CMS được xây dựng để sử dụng trong công ty TMA phải bao gồm các chức năng của một hệ CMS thông thường. các chức năng này được mô tả như sau: • Quản lý nội dung. ƒ Tạo, xoá và sửa đổi nội dung. ƒ Cập nhật nội dung. • Quản lý vai trò ƒ Tạo, xoá, sửa đổi vai trò. ƒ Cập nhật thông tin của vai trò. ƒ Cho phép vai trò đăng nhập vào hệ thống. ƒ Ngăn cấm vai trò đăng nhập vào hệ thống. • Phân quyền cho các vai trò. ƒ Mỗi vai trò có thể có nhiều quyền khác nhau và các quyền này được gán cho vai trò bởi người quản lý web site. ƒ Các quyền này có thể là đọc, ghi, đọc và ghi… • Quản lý người sử dụng. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 38 Đặng Đình Vương ƒ Tạo, xoá bỏ, sửa đổi thông tin người sử dụng. ƒ Cập nhật thông tin người sử dụng. ƒ Cho phép người sử dụng đăng nhập vào hệ thống. ƒ Ngăn cấm người sử dụng đăng nhập vào hệ thống. • Gán các vai trò cho người sử dụng. ƒ Do trong một tổ chức tồn tại rất nhiều phòng ban và vị trí công việc khác nhau, do đó cần phải phân chia vai trò cho từng người sử dụng khác nhau trên hệ thống tuỳ thuộc vào từng phòng ban và vị trí công việc của họ. ƒ Một người sử dụng có thể có nhiều vai trò khác nhau trong hệ thống và các vai trò này được gán bởi người quản lý web site. • Sử dụng các template cho các trang web: các trang web cần phải đồng bộ với nhau về cách thức hiển thị, do đó cần phải sử dụng các template giống nhau cho toàn bộ web site. • Phân loại nội dung: điều này là cần thiết để tránh tình trạng dữ liệu bị sắp xếp không theo trật tự và để có thể tìm kiếm dễ dàng thông tin cần thiết. • Tìm kiếm thông tin: do nội dung trang web và các thông tin liên quan ngày càng nhiều, do đó cần phải có cơ chế tìm kiếm thông tin để hỗ trợ các nhân viên trong các trường hợp cần thiết. • Thay đổi các thông số cấu hình: hệ thống này cho phép thay đổi các thông tin cấu hình để tối ưu hoá hoạt động của hệ thống. Ngoài các nhu cầu cầu của một hệ CMS thông thường, công ty TMA còn có 2 nhu cầu như sau: Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 39 Đặng Đình Vương 5.1 Nhu cầu chia sẻ thông tin giữa các dự án và các vị trí công việc Trong công ty TMA có rất nhiều dự án và trong mỗi dự án lại tồn tại nhiều vị trí công việc khác nhau, bao gồm có 3 vị trí như sau: • Quản lý dự án. • Quản lý nhóm. • Thành viên bình thường. Mỗi dự án sở hữu các thông tin riêng về dự án đó và các công việc họ đang thực hiện. Một phần các thông tin này có thể cho phép mọi người trong công ty đều có thể xem được. Phần còn lại chỉ cho phép các thành viên trong nhóm có thể truy cập vào thôi. Mỗi dự án có một người phụ trách cập nhật thông tin về dự án đó. Người này thông thường là trưởng dự án hoặc trưởng nhóm. Người này có quyền thực hiện một số thao tác như: tạo, xoá bỏ, sửa đổi…các thông tin của nhóm trên intranet. các thành viên khác của nhóm chỉ có quyền xem trên các thông tin của nhóm. Hình vẽ sau sẽ minh hoạ cho điều vừa trình bày Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 40 Đặng Đình Vương Hình 14: Chia sẻ thông tin giữa các dự án và vị trí công việc trong công ty TMA Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 41 Đặng Đình Vương 5.2 Xây dựng hệ CMS dưới dạng một portlet có thể được sử dụng bởi các ứng dụng và các thành phần khác Như đã trinh bày như trên, chúng ta biết rằng hệ CMS xây dựng là một thành phần phi chức năng dùng để cung cấp chức năng cho các ứng dụng, các dịch vụ, các thành phần chức năng khác. Do đó, cần phải xây dựng hệ CMS dưới dạng một portlet để có thể sử dụng bởi các ứng dụng và các thành phần khác trên intranet. 5.3 Các kỹ thuật sử dụng trong quá trình phát triển Do hệ CMS này được xây dựng để tích hợp vào hệ thống thông tin có sẵn của công ty TMA dưới dạng một portlet. Do đó, có một số quy định trong quá trình phát triển hệ CMS này như sau: • Hệ CMS này phải được xây dựng dưới dạng một portlet: điều này cần thiết để tích hợp vào portal hiện tại của Công ty. • Hệ CMS này phải tuân theo chuẩn JSR 168: do chuẩn JSR 168 là chuẩn dùng để tích hợp một portlet vào portal. • Hệ CMS phải được lập trình bằng Java: portal hiện tại của công ty được lập trình bằng Java và các portlet trên portal tuân theo chuẩn JSR 168. • Hệ CMS phải được xây dựng dựa trên các giải pháp mã nguồn mở và miễn phí. • Sử dụng chuẩn JSR 170 để xây dựng hệ thống này nếu có thể được: do chuẩn JSR 170 là chuẩn dùng để hỗ trợ việc xây dựng các hệ CMS, việc xây dựng hệ thống này nên tuân theo chuẩn JSR 170 để có thể mở rộng hệ thống này trong tương lai nếu có nhu cầu. • Hệ thống này phải có khả năng hoạt động trên nền Linux: portal hiện tại của công ty hoạt động trên Linux. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 42 Đặng Đình Vương • Hệ thống này phải có khả năng họat động trên application server JBoss: do portal hiện tại của công ty hoạt động trên JBoss. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 43 Đặng Đình Vương Chương 5 Chuẩn JSR 168 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 44 Đặng Đình Vương 1. Giới thiệu về chuẩn JSR 168 Chuẩn JSR 168 dùng để định nghĩa portlet và cách thức giao tiếp giữa portlet và portal. Phiên bản hiện tại của chuẩn này là 1.0 được đưa ra bởi Sun Microsystems vào ngày 29/08/2003. ( Hình 15: Mô hình chuẩn 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. Portlet Portlet PortletPortlet Portlet A P I API APIAP I API JSR-168 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 45 Đặng Đình Vương 2. Một số khái niệm chính 2.1 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 từng người sử dụng khác nhau mà Portal cho phép. Một Portal có thể chứa nhiều Portlet 2.2 Portlet Portlet là một thành phần (component) 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 yêu cầu. Portlet có thể tích hợp vào Portal và Portal sẽ cung cấp một 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 Portlet được gọi là Fragment. Một Fragment là một mảnh dữ liệu được tạo bởi các ngôn ngữ như: HTML, XHTML, WML… 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. 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. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 46 Đặng Đình Vương 2.3 Portlet Container Porlet Container cung cấp một môi trường lúc Runtime 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. 3. So sánh Portlet và Servlet 3.1 Điểm giống nhau giữa Portlet và Servlet • Cùng là thành phần Web sử dụng công nghệ của Java. • Được chứa đựng và quản lý bởi một Container. • Tạo ra nội dung dữ liệu động để phản hồi lại yêu cầu. • Cùng tương tác với người sử dụng thông qua cơ chế yêu cầu/phản hồi. 3.2 Điểm khác nhau giữa Portlet và Servlet • Portlet chỉ tạo ra các Fragment chứ không tạo ra toàn bộ tài liệu. Portal sẽ tập hợp các Fragment do Portlet tạo ra thành nội dung của trang Web trên Portal.. • Không cần phải kết hợp một Portlet với một địa chỉ URL như Servlet • Người sử dụng tương tác với Portlet thông qua Portal. • Portlet có thể được sử dụng nhiều nơi trên cùng một trang Web của Portal. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 47 Đặng Đình Vương 3.3 Đặc trưng của Portlet mà không có ở servlet • Portlet cho phép truy cập và lưu trữ cầu hình và tối ưu hoá dữ liệu. • Portlet cho phép truy cập vào các thông tin về người sử dụng. • Portlet hỗ trợ chức năng viết lại URL ( URL Rewriting Function ) cho phép tạo ra liên kết trong nội dung của nó. • Portlet có thể lưu trữ dữ liệu tạo thời trong phiên làm việc của Portlet ở 2 phạm vi: Phạm vi ứng dụng và Phạm vi cá nhân. 4. 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 hoá trực tiếp hoặc gián tiếp giao diện Portlet. Lớp GenericPortlet hiện thực hoá 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 GenericPorlet 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 của 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 processAction được gọi. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 48 Đặng Đình Vương • 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 hệ thống mà nó đang sử dụng và lưu lại trạng thái hiện thời của nó. 5. 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ì Porlet cần phải sử dụng đối tượng PorletURL. Nếu phương thức createActionURL được gọi thì sẽ tạo ra một URL hành động và nếu phương thức createRenderURL được gọi thì tạo ra một URL trình diễn. 6. Portlet Mode Kiểu Portlet xác định chức năng mà Portlet hiện đ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 cho 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 Portlet cần phải tạo ra. Có 3 kiểu Portlet được quy định 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. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 49 Đặng Đình Vương ƒ Mọi Portlet đều phải hỗ trợ kiểu 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 họat độ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 VIEW • HELP ƒ Trong kiểu HELP, Portlet cung cấp những thông tin giúp đỡ người sử dụng về Portlet. Những thông tin này có thể là những thông tin chung về toàn bộ Portlet hoặc là các giúp đỡ cảm ngữ cảnh (Context- sensitive help) Các hằng số tượng trưng cho 3 kiểu Portlet được khai báo trong lớp PortletMode 7. Window State Trạng thái cửa sổ cho biết khoảng không gian trên trang Web Portal dành cho nội dung của Portlet. Có 3 trạng thái cửa sổ được định nghĩa : • NORMAL: cho biết Porlet có thể chia sẻ trang Portal với các Portlet khác. Ngoài ra, trạng thái này còn cho biết giới hạn hiển thị của thiết bị do đó Portlet sẽ điều chỉnh kích thước phù hợp với vùng hiển thị. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 50 Đặng Đình Vương • MAXIMIZED: cho biết chỉ có một Portlet hiển thị trên trang Portal hoặc Portlet được ưu tiên hiển thị nội dung nhiều hơn các Portlet còn lại. • MINIMIZED: Cho biết nội dung của Portlet chỉ được hiển thị ít nhất có thể được hoặc không được hiển thị. Các trạng thái cửa sổ được định trong lớp WindowState. 8. 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 processAction hay render. Mỗi đối tượng yêu cầu chỉ có thể họat độ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. 9. Portlet Response 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 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. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 51 Đặng Đình Vương Mỗi đối tượng phản hồi chỉ có thể họat độ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 Portlet Response được khai báo trong giao diện PortletResponse. 10. 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. Và 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ông tin 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. 11. 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ời 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 họat động tùy thuộc và từng Portlet và từng người sử dụng Portlet. Nội Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 52 Đặng Đình Vương 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 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ới thời gian hết hạn là 300 giây. ... ... 300 ... ... 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ể được lập trình viên thay đổi 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. 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 được lưu tạm thời của Portlet sẽ không bao giờ bị hết hạn. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 53 Đặng Đình Vương 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. Nếu nội dung của Portlet được lưu trữ tạm thời và có yêu cầu đến Portlet từ phía người sử dụng thì Portlet Container sẽ không sử dụng nội dung tạm thời được lưu trữ mà sẽ gọi đến phương thức xử lý yêu cầu của Portlet 12. Ứng dụng Portlet 12.1 Các thành phần của ứng dụng Portlet Ứng dụng Portlet là một ứng dụng Web nên ngoài việc bao 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 lớp… Do đó, bên cạnh các thông tin 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. 12.2 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 như sau: • Có thêm tập tin /WEB-INF/portlet.xml là tập tin đặc tả triển khai của Portlet. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 54 Đặng Đình Vương • 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. 12.3 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ư là 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. 13. Các đặc tả đóng gói và triển khai 13.1 Đặ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 dùng để đặc tả các tài nguyên của ứng dụng Web. • Tập tin portlet.xml dùng để đặ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 có liên quan đến Portlet thì được khai báo trong tập tin portlet.xml . Ngòai 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ẻ . Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 55 Đặng Đình Vương 13.2 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 đều 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 Một ví dụ về cấu trúc cây thư mục của ứng dụng Portlet như sau: /images/myButton.gif /META-INF/MANIFEST.MF /WEB-INF/web.xml /WEB-INF/portlet.xml /WEB-INF/lib/myHelpers.jar /WEB-INF/classes/com/mycorp/servlets/MyServlet.class /WEB-INF/classes/com/mycorp/portlets/MyPortlet.class /WEB-INF/jsp/myHelp.jsp Ứng dụng Portlet nếu muốn sử dụng các tài nguyên không thể đóng gói được vào tập tin WAR, chẳng hạn EJB, thì có thể đóng gói các tài nguyên này dưới dạng tập tin EAR. 13.3 Các thành phần của đặc tả triển khai Portlet Các thông tin cấu hình và các thông tin triển khai sau đây phải được hỗ trợ trong tập tin đặc tả triển khai Portlet : Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 56 Đặng Đình Vương • Định nghĩa ứng dụng Portlet (Portlet Application Definition) • Định nghĩa Portlet (Portlet Definition) Hình vẽ sau minh họa cấu trúc của một đặc tả triển khai Portlet: Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 57 Đặng Đình Vương Hình 16: Cấu trúc một đặc tả triển khai Portlet Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 58 Đặng Đình Vương Hình 17: Cấu trúc một đặc tả triển khai Portlet (tt) Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 59 Đặng Đình Vương 13.4 Tính duy nhất của các giá trị trong đặc tả triển khai Portlet Các giá trị trong đặc tả triển khai sau phải là duy nhất trong phạm vi của định nghĩa ứng dụng Portlet (Portlet Application Definition): • Tên Portlet : . • Kiểu Portlet tùy chọn : . • Kiểu cửa sổ tùy chọn : . • Thuộc tính người sử dụng : . Các giá trị trong đặc tả triển khai sau phải là duy nhất trong phạm vi của định nghĩa Portlet (Portlet Definition): • Giá trị khởi tạo: . • Hỗ trợ kiểu: . • Tham chiếu: . • Tham chiếu vai trò bảo mật: . 14. Thư viện các thẻ Portlet Thư việc các thẻ Portlet dùng để hỗ trợ cho các trang JSP khi được gọi từ Portlet có thể truy nhập vào các thành phần của Portlet như là : RenderRequest, RenderResponse…Các thư viện này cũng giúp cho các trang JSP có thể truy cập vào các chức năng của Portlet như việc tạo ra các Portlet URL. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 60 Đặng Đình Vương Các trang JSP khi sử dụng các thư viện này cần phải khai báo chúng trong thẻ thư viện theo như mẫu sau: 14.1 Thẻ actionURL Thẻ actionURL tạo ra một URL tham chiếu đến Portlet hiện tại và thực thi một số yêu cầu với các tham số khởi tạo. Các tham số này có thể được thêm vào URL bằng cách nhập thẻ param giữa thẻ đóng và thẻ mở actionURL như trong ví dụ sau : 14.2 Thẻ renderURL Thẻ renderURL tạo ra một URL tham chiếu đến Portlet hiện tại và thực thi một số yêu cầu render với các tham số khởi tạo. Các tham số này có thể được thêm vào URL bằng cách nhập thẻ param giữa thẻ đóng và thẻ mở renderURL. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 61 Đặng Đình Vương Chương 6 Chuẩn JSR 170 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 62 Đặng Đình Vương 1. Giới thiệu về chuẩn JSR 170 Chuẩn JSR 170 dùng để định nghĩa cách thức lưu trữ và truy xuất dữ liệu. Có nhiều loại dữ liệu được hỗ trợ như: hệ quản trị cơ sở dữ liệu, hệ thống tập tin của hệ điều hành, tập tin XML…Ngoài ra, chuẩn này còn cung cấp các API và các cơ chế để chuyển đổi giữa các cơ sở dữ liệu cũng như hỗ trợ cho việc truy xuất cơ sở dữ liệu, như: lưu trữ dữ liệu theo cấu trúc cây, quản lý phiên bản dữ liệu, lắng nghe sự kiện xảy ra trên cấu trúc lưu trữ dữ liệu, không cho truy cập vào dữ liệu… Phiên bản hiện tại của chuẩn JSR 170 là 0.16.2 được đưa ra bởi Day Management AG vào ngày 25/01/2005. ( Hình vẽ sau mô tả cách thức giao tiếp của JSR 170 với các hệ cơ sở dữ liệu. Hình 18: Chuẩn JSR 170 giao tiếp với cơ sở dữ liệu Repository DBMS Repository File System Repository XML Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 63 Đặng Đình Vương 2. Mô hình repository Một JCR (Java Content Repository) bao gồm một hay nhiều workspace, mỗi workspace là một cấu trúc cây gồm nhiều item, một item có thể là một node hay một property, mỗi node có thể không có con hay có nhiều con và không có property hay có nhiều property. Có duy nhất một node không có cha gọi là root. Tất cả các node ngoại trừ root có ít nhất một cha. Property có một cha và không có con, được gọi là lá của cây. Property là một đơn vị nội dung nhỏ nhất bao gồm tên và giá trị tương ứng . Dữ liệu thực sự được chứa đựng trong giá trị của property. Hình 19: Mô hình một workspace của một repository Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 64 Đặng Đình Vương Trong biểu đồ trên, root có 3 node con là a,b và c. Mỗi node con có nhiều node con hay nhiều Property, chẳng hạn node a có 2 con là d và e, node e có 2 property là j và k, Property j chứa một hình ảnh và Property k chứa một số thực. Bất kỳ item nào trong cấu trúc trên đều có thể được xác định bằng một đường dẫn tuyệt đối. Ví dụ đường dẫn / chỉ đến root, đường dẫn /a/d/i chỉ đến 1 Property có giá trị là true. Đường dẫn tuyệt đối luôn bắt đầu với / . Đường dẫn tương đối chỉ ra một node hay một property từ một node đã được xác định trước. Ví dụ : với node /a trong biểu đồ trên thì đường dẫn tương đối đến property với giá trị true là d/i, đến property có giá trị -25 là ../c/h. 3. Một số API cơ bản Toàn bộ Repository được đại diện bởi một đối tượng Repository. Một Client kết nối tới một Repository bằng cách cung cấp một đối tượng Credentials và xác định một Workspace cụ thể bên trong một Repository. Nếu Credentials được thông qua thì Client có thể truy cập đến một Workspace đã xác định, sau đó Client sẽ nhận một Ticket. Ví dụ : // Lấy đối tượng Repository Repository repository = (Repository)java.rmi.Naming.lookup("MyRepo"); // Lấy đối tượng Credentials Credentials credentials = new SimpleCredentials("MyName", "MyPassword".toCharArray()); Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 65 Đặng Đình Vương // Lấy một Ticket Ticket myTicket = repository.login(credentials, "MyWorkspace"); Với đối tượng Ticket, Client có thể truy cập đến bất kỳ một Node hay Property nào trong cây của Workspace đang truy cập : // Lấy Node Root Node root = myTicket.getRootNode(); // Lấy một Node bất kỳ với đường dẫn tuyệt đối Node myNode = root.getNode("a/e"); // Lấy một Property của myNode Property myProperty = myNode.getProperty("k"); // Lấy ra giá trị của một Property Value myValue = mỷPoperty.getValue(); // Chuyển đổi một Value về một kiểu nào đó double myDouble = myValue.getDouble(); Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 66 Đặng Đình Vương 3.1 Thao tác trên repository Sau khi có một Ticket, Client có thể thao tác vào Repository bằng cách thêm hay xoá các node, property và thay đổi các giá trị của các Property Ví dụ : Sau khi có một node, Client có thể thêm vào một node con và thêm một Property vào node con đó. //Thêm một Node con Node newNode = myNode.addNode(“n”); //Thêm một Property newNode.setProperty(“x”,”Hello”); Sự thay đổi bởi các phương thức của Node và Property không tác động ngay vào Workspace của Repository. Các sự thay đổi đó được lưu giữ tạm thời cùng với đối tượng Ticket cho đến khi phương thức Ticket.save hoặc Node.save được gọi Ticket.save sẽ cập nhật tất cả sự thay đổi từ lần save trước đó. Phương thức Node.save(boolean shallow) lưu toàn bộ cây con của đối tượng node (khi shallow = false) hoặc chỉ lưu các property của node đó (khi shallow = true) Về mặt tổng quát, Ticket là một kho lưu trữ tạm thời, tất cả những sự thay đổi được thực hiện thông qua những phương thức của Ticket hoặc gián tiếp thông qua các phương thức của Node và Property. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 67 Đặng Đình Vương 4. Sự liên hệ giữa Node, Property và Item Do các Node và các Property có một số chức năng chung nên các phương thức chung được định nghĩa trong Interface Item. Hình 20: Mối liên hệ giữa Node, Property và Item Biểu đồ UML trên chỉ ra Property và Node là các SubInterface của Item. Một Property có một và chỉ một Node cha, một Node có thể có một hay nhiều Node cha và có nhiều Item con. 5. Sự sắp xếp các Item con Một node được hỗ trợ sắp thứ tự nghĩa là sẽ tồn tại 2 danh sách, một cho các node con và một cho các property. các node con và các property sẽ không chung thứ tự với nhau. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 68 Đặng Đình Vương Khi một item con có thỉ mục là n bị xoá khỏi một node có hỗ trợ sắp thứ tự thì tất cả các item có chỉ mục lớn hơn n sẽ bị giảm đi 1 đơn vị. Khi một item được thêm vào mà không chỉ rõ chỉ mục, nó sẽ tự động được thêm vào cuối danh sách. 6. Namespace Giống như XML, JCR cũng đưa ra khái niệm Namespaces định nghĩa các tiền tố tham chiếu đến các URI.Các tiền tố này dùng cho việc đặt tên các Item trong Repository đồng thời tránh sự trùng tên giữa các Node hay các Property trong các mã nguồn khác nhau. Mỗi JCR Repository đều có một đối tượng NamespaceRegistry dùng để thực hiện các thao tác liên quan đến đăng ký các Namespace. Trong khi đăng ký Namespace, một số tiền tố được tự động tạo ra và không thể xóa bỏ được. Các tiền tố đó là : • jcr -> : Dùng cho việc đặt tên các loại Node có sẵn. Ví dụ: jcr: content. • nt -> : Dùng cho việc đặt tên các loại Node chính (primary node types). • mix -> : Dùng cho việc đặt tên các loại Node phụ (mixin node types). • pt -> : Dùng cho việc đặt tên các Property và sử dụng trong việc chuyển nội dung của Repository sang dạng thức XML. • sv -> : Dùng trong khung nhìn System View khi chuyển nội dung của Repository sang dạng thức XML. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 69 Đặng Đình Vương 7. Property 7.1 Property đa trị Trong một số trường hợp, một property có thể chứa nhiều giá trị. Điều này tùy thuộc vào kiểu của node cha. Để truy xuất các giá trị của một property, ta sử dụng phương thức Property.getValues(), phương thức này trả về một mảng các đối tượng Value chứa các giá trị của Property. Các giá trị chứa trong property đa trị đều có chung một kiểu. 7.2 Các kiểu dữ liệu của Property Có 9 kiểu dữ liệu của Property được định nghĩa bằng các hằng số trong lớp PropertyType. Bao gồm : PropertyType.STRING PropertyType.BINARY PropertyType.DATE PropertyType.LONG PropertyType.DOUBLE PropertyType.BOOLEAN PropertyType.NAME PropertyType.PATH PropertyType.REFERENCE Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 70 Đặng Đình Vương Các kiểu STRING, BINARY, LONG, DOUBLE, BOOLEAN của Property tương tự như các kiểu string, binary, long, double, boolean được định nghĩa trong package java.lang của Java. 7.2.1 Kiểu Date Định dạng của dữ liệu có kiểu Date phải theo chuẩn ISO 8601 : YYYY - MM - DDThh:mm:ss.sssTZD. Trong đó : YYYY 4 chữ số biểu diễn năm MM 2 chữ số biểu diễn tháng ( từ 01 đến 12 ) DD 2 chữ số biểu diễn ngày ( từ 01 đến 31 ) hh 2 chữ số biểu diễn giờ ( từ 00 đến 23 ) (không cho phép biểu diễn dạng am/pm) mm 2 chữ số biểu diễn phút ( từ 00 đến 59 ) ss.sss 5 chữ số biểu diễn giờ với sai số lấy 3 chữ số thập phân ( từ 00.000 đến 59.999 ) TZD Time Zone Designator 7.2.2 Kiểu Reference, Path và Name Property có kiểu Name dùng để chứa các thuộc tính сủa namespace, nó là một giá trị kiểu string chứa một phần của namespace. Property có kiểu Path đại diện cho một đường dẫn trong một workspace bao gồm cả đường dẫn tuyệt đối và tương đối. Path không phải là kiểu tham chiếu, nó có thể chứa một đường dẫn chỉ đến một Item không tồn tại trong workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 71 Đặng Đình Vương Property có kiểu Reference dùng để tham chiếu đến một node trong workspace. Giá trị của property này là một UUID của node mà nó tham chiếu. Nó không cho phép xóa bất kỳ một node nào có trong đích đến của nó. Nếu muốn xoá node, trước tiên phải xoá các tham chiếu đến node đó. 8. Node 8.1 Quan hệ giữa các node cùng tên và cùng cha ( Same-Name Siblings ) Một node có thể chấp nhận các node khác có cùng cha và cùng tên với nó. Trong trường hợp này, một đường dẫn không xác định duy nhất một node mà là một mảng các node. Chỉ mục của các node trong mảng các node này có thể bị thay đổi khi ta xóa hay thêm một node mới vào. Phương thức chuẩn để lấy về tập hợp các Node là Node.getNodes(String namePattern). Phương thức này trả về một mảng các node con của đối tượng Node. Khác với node, một property có thể có nhiều giá trị chứ không tồn tạiquan hệ này. 8.2 Các kiểu của Node Nét đặc biệt của JCR là khả năng hỗ trợ kiểu cho node. Kiểu node quy định các Node con hay các Property mà Node đó có thể có hoặc bắt buộc phải có. Một kiểu node bao gồm các thành phần sau : Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 72 Đặng Đình Vương • Name: tên của kiểu . JCR quy định sẵn một số kiểu bao gồm các kiểu node chính có tên bắt đầu với “nt:” và các kiểu node phụ có tên bắt đầu với “mix:”. • Supertype: mỗi kiểu node có thể là mở rộng của một hay nhiều kiểu node khác và kiểu node được mở rộng là Supertype của kiểu node mở rộng. • Property Definitions: mỗi kiểu node quy định một tập các thuộc tính mà Node có kiểu này có thể có hay bắt buộc phải có. Đồng thời kiểu node cũng quy định những đặc điểm mà các thuộc tính này phải có, những đặc điểm này gọi là Property Definition. • Child Node Definitions: mỗi kiểu node quy định một tập các Node con mà Node có kiểu này có thể có hay bắt buộc phải có. Đồng thời kiểu node cũng quy định những đặc điểm mà các Node con của Node này phải có, những đặc điểm này gọi là Node Definition. • Mixin Status: JCR quy định mỗi kiểu node chỉ có thể là kiểu node chính hay kiểu node phụ.. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 73 Đặng Đình Vương 8.2.1 Kiểu node chính và kiểu node phụ JCR quy định mỗi Node bắt buộc phải có một và chỉ một kiểu node chính và kiểu node chính này sẽ quy định những đặc điểm của các Node con và các thuộc tính mà Node có kiểu này có thể có. Ngoài một kiểu node chính duy nhất, JCR còn cho phép mỗi Node có thể có nhiều kiểu node phụ dùng để định nghĩa thêm những đặt tính mà Node có thể có. Kiểu node chính được lưu trong giá trị của thuộc tính jcr:primaryType và kiểu Node phụ được lưu trong giá trị của thuộc tính jcr:mixinTypes. Do mỗi Node có thể có nhiều kiểu node phụ nên thuộc tính jcr:mixinTypes là thuộc tính đa trị Kiểu node nt:base là Supertype cuả mọi kiểu node chính trong Repository 8.2.2 Property definitions Mỗi Property Definition của kiểu node chứa các thông tin sau: • Name: tên của thuộc tính. • Type: kiểu thuộc tính. • Value constraints: miền giá trị được giới hạn cho thuộc tính. • Default value: gíá trị mặc định của thuộc tính khi thuộc tính được tạo ra mà không xác định rõ giá trị. • Auto-created: cho biết thuộc tính có tự động được tạo ra khi Node sỏ hữu loại Node được tạo ra hay không. • Mandatory: cho biết thuộc tính là bắt buộc phải có trong Node hay không. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 74 Đặng Đình Vương • On-parent-version: trạng thái của thuộc tính dùng để cho biết những gì sẽ được thực hiện khi một phiên bản mới của Node chứa thuộc tính được tạo ra. • Read-only: cho biết thuộc tính là chỉ đọc hay không • Primary-Item: cho biết thuộc tính này có phải là thành phần chính của Node sở hữu thuộc tính hay không • Multiple Values: cho biết thuộc tính có thể đa trị hay không. 8.2.3 Child Node Definitions Mỗi Child Node Definition của loại Node chứa các thông tin sau: • Name: tên Node con. • Required Primary Node Types: các kiểu node chính mà Node con này phải có (chỉ có một và chỉ một trong các kiểu node chính này).. • Default Primary Node Type: Nếu trong quá trình tạo ra Node con mà không xác định kiểu node chính cho nó thì kiểu node chính này sẽ tự động được gán cho Node con. • Required Mixin Node Types: các kiểu node phụ mà Node con này phải có. • Default Mixin Node Types: các kiểu node phụ sẽ tự động được gán cho Node con nếu đến lúc lưu nội dụng Node con mà vẫn chưa được xác định kiểu node phụ. • Auto-created: cho biết Node con có tự động được tạo ra khi Node cha được tạo ra hay không. • Mandatory: cho biết Node con này có bắt buộc phải có hay không. • On-parent-version: trạng thái của Node con dùng để cho biết những gì sẽ được thực hiện khi một phiên bản mới của Node cha được tạo ra. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 75 Đặng Đình Vương • Read-only: cho biết thuộc tính là chỉ đọc hay không. • Primary-Item: cho biết Node con này có phải là thành phần chính của Node cha hay không. • Same-name siblings: cho biết có thể cho phép nhiều Node con khác có cùng tên với Node con này hay không. 8.2.4 Các kiểu node được định nghĩa sẵn JCR quy định mỗi Repository đều phải hỗ trợ ít nhất kiểu node chính nt:base và các kiểu node chính khác nếu có đều phải là kiểu con của nt:base. Ngoài ra, JCR còn định nghĩa sẵn các kiểu node thường được sử dụng trong các Repository, các kiểu node này được định nghĩa sẵn theo định dạng sau: NodeTypeName ... Supertypes ... IsMixin ... ChildNodeDef Name ... RequiredPrimaryTypes ... DefaultPrimaryType ... RequiredMixinTypes ... DefaultMixinTypes ... AutoCreate ... Mandatory ... OnParentVersion ... Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 76 Đặng Đình Vương ReadOnly ... PrimaryItem ... SameNameSibs ... ... . (more ChildNodeDefs) . .. PropertyDef Name ... Type ... ValueConstraint ... DefaultValue ... AutoCreate ... Mandatory ... OnParentVersion ... ReadOnly ... PrimaryItem ... Multiple ... . .. . (more PropertyDefs) … 8.2.4.1 Các kiểu node phụ được định nghĩa sẵn Có 2 kiểu node phụ được định nghĩa sẵn là mix:referenceable và mix:versionable trong đó mix:versionable là kiểu node con của mix:referenceable mix:referenceable | |-- mix:versionable Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 77 Đặng Đình Vương Một Node có kiểu là mixin: referenceable được sử dụng cho mục đích : • Nó là đích của thuộc tính có kiểu REFERENCE • Có nhiều hơn một Node cha Một Node có kiểu là mix: versionable dùng cho các Repository có hỗ trợ việc lưu các phiên bản của Node (versioning system). các thuộc tính được quy định bởi kiểu node này đều là các thuộc tính chỉ đọc 8.2.4.2 Các kiểu node chính được định nghĩa sẵn Mọi kiểu node chính đều được bắt nguồn từ kiểu nt:base. Do đó, một Node trên Reporitory ít nhất phải có kiểu node chính nt:base. Kiểu node chính nt:version và nt:versionHistory là cần thiết nếu có sử dụng phiên bản. Cây sau mô tả cấu trúc thừa kế của các kiểu node chính dược định nghĩa sẵn nt:base | |-- nt:default | |-- nt:hierarchyElement | | | |-- nt:file | | | |-- nt:folder |-- nt:nodeType | |-- nt:propertyDef | |-- nt:childNodeDef | |-- nt:versionHistory Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 78 Đặng Đình Vương | |-- nt:version | |-- nt:query 8.3 Node tham chiếu (Referenceable Nodes) Nét đặc biệt của Node tham chiếu là nó được sử dụng trong trường hợp repository có nhiều workspace và việc tạo các phiên bản của node. Một repository có thề có nhiều node tham chiếu, để làm được điều này, nó phải hỗ trợ kiểu mix:refrenceable. Node có kiểu mix:referenceable có một property mang tên jcr:uuid, property này được tạo ra và quản lý bởi hệ thống, client chỉ có thể đọc chứ không thể thay đối hay xóa property này. UUID của một node tham chiếu được ấn định bởi hệ thống trong lúc nó được tạo. Trong một workspace xác định, không tồn tại nhiều hơn một node có chung một UUID. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 79 Đặng Đình Vương 9. Workspace Như ta đã biết, một repository bao gồm một hay nhiều workspace, mỗi workspace chứa duy nhất một node root. Repository có thể đơn giản, chứa một workspace hay phức tạp, chứa một số lượng lớn workspace. Sau đây là một số mô hình của repository. 9.1 Repository có một workspace Trong trường hợp này repository là một cây gồm các node và property.. Hình 21: Repository có một workspace Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 80 Đặng Đình Vương 9.2 Repository có nhiều Workspace và sự tương ứng các node Trong trường hợp này, một node trong một workspace có thể có các node tương ứng ( corresponding nodes ) trong các workspace khác và chúng cùng chia sẻ một UUID. Các node tương ứng này có thể được xem như là thể hiện của cùng một node trên nhiều workspace khác nhau. Tuy nhiên trong một workspace, không tồn tại 2 node có cùng chung một UUID. Chỉ có các node với kiểu mix:refereneable mới có thể có các node tương ứng trên các workspace khác nhau. Các node tương ứng này chỉ cần có chung một UUID. Do đó chúng có thể có các đường dẫn khác nhau cũng như các property và các node con khác nhau. Khi một node tham chiếu mới (referenceable node) được tạo ra trong workspace bởi hàm Node.addNode thì nó sẽ được ấn định một UUID mới bởi hệ thống. Muốn một node có một node tương ứng trong một workspace khác, nó phải được nhân bản ("cloned") từ workspace nguồn đến workspace đích bằng cách sử dụng phương thức : Workspace.clone( String srcAbsPath, String destAbsPath, String destWorkspace, boolean shallow) Phương thức này thực hiện nhân bản cây con từ đường dẫn srcAbsPath trong workspace nguồn đến đường dẫn destAbsPath trong workspace đích destWorkspace nếu shallow = false, hoặc chỉ nhân bản một node và property của nó nếu shallow= rue. Phương thức clone thực nhân bản cả những node tham chiếu và những node không tham chiếu ( nonreferenceable node ), nhưng chỉ những node tham chiếu mới duy trì mối quan hệ tương ứng của nó giữa các workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 81 Đặng Đình Vương Trong trường hợp các root node trong các workspace có kiểu là mix:referenceable thì chúng phải có chung một UUID. Root node của một workspace sẽ tự động được tạo ra khi workspace đó được tạo. Biểu đồ sau mô tả một repository có 2 workspace Hình 22: Repository có nhiều workspace Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 82 Đặng Đình Vương Trong biểu đồ trên, repository có 2 workspace là WS1 và WS2. Đường đứt khúc chỉ ra các node có mối quan hệ tương ứng. Trong mỗi workspace có các node không xuất hiện trên workspace còn lại, các node này có thể là các node tham chiếu nhưng không được nhân bản hay các node không tham chiếu. 10. Tạo phiên bản ( Versioning ) Hệ thống tạo phiên bản được xây dựng dựa trên node tham chiếu đã trình bày ở trên. Trong một repository hỗ trợ tạo phiên bản , workspace có thể chứa cả versionable node và nonversionable node. Versionable node có kiểu là mix:versionable. Kiểu mix:versionable là kiểu con thừa kế từ kiểu mix:referenceable, do đó một node cho phép tạo phiên bản thì nó là node tham chiếu và có một UUID. Khả năng có thể tạo phiên bản của node có nghĩa là tại bất kỳ một thời điểm cho trước nào đó, trạng thái của node có thể được lưu giữ để phục vụ cho việc phục hồi trong tương lai. Trạng thái lưu lại này được gọi là một version và hành động lưu lại được gọi là checking in. Version là một phần của version history. Trong một version history, các version hình thành một biểu đồ miêu tả mối quan hệ giữa các versionable node. Các version history lưu trong version storage. Có một version storage trong một repository, nó là một cây con bên dưới node /jcr:versionStorage và được lưu trong mỗi workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 83 Đặng Đình Vương 10.1 Version History Version History được lưu trong Repository như là một Node có kiểu Node là nt:versionHistory và một Node có kiểu là nt:version sẽ được thêm vào Version History khi một trong những thể hiện của Node trên các Workspace thực hiện thao tác lưu phiên bản (check-in). Khi đó phiên bản mới của Node sẽ được lưu như là thành phần tiếp theo của một hay nhiều phiên bản trước đó (successor). Do đó, Version History sẽ được lưu như là một đồ thị. Hình 23: Đồ thị mô tả một Version History Trong đồ thị dùng để lưu Version History trên thì Node VH có kiểu là nt:versionHistory và Vroot, Va, Vb và Vc có kiểu là nt:version. VH là Node cha của các Node Vroot, Va, Vb và Vc; trong khi Va, Vb là phiên bản kế tiếp của Vroot, tương tự Vc là phiên bản kế tiếp của Va và Vb. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 84 Đặng Đình Vương Trên Version History luôn có một Node đóng vai trò như là phiên bản ban đầu (Root Version Node). Node này được tạo ra tự động khi Version History mới được tạo ra và đóng vai trò là điểm khởi đầu dùng để duyệt qua hết tất cả các phiên bản khác nằm trên đồ thị biểu diễn Version History. Trong ví dụ trên thì phiên bản ban đầu của Version History VH là Vroot. 10.2 Mối quan hệ giữa các versionable node và version history Mối quan hệ giữa các node và version history được xây dựng trên sự tương ứng thông qua UUID. Các node có chung một UUID sẽ có cùng chung một version history. Trong một workspace chỉ có một versionable node trong một version history Trong một workspace có thể có các version history rỗng. Và các node không có khả năng tạo phiên bản ( nonversionable node ) hiển nhiên không có version history. Khi một versionable node được tạo ra, một version history cho node đó sẽ được tự động tạo ra trong version storage Một versionable node khi được nhân bản sang một workspace khác, node được nhân bản sẽ có chung UUID và chung version history với node gốc. 10.3 Đồ Thị Biểu Diễn Các Phiên Bản Trên Repository Đồ thị dùng để biểu diễn các phiên bản khác nhau của cùng một đối tượng Node trên Repository có cấu trúc cơ bản như sau : • Đồ thị có thể một hay nhiều phiên bản • Đồ thị chỉ có một và chỉ một phiên bản ban đầu (Root Version Node) Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 85 Đặng Đình Vương • Phiên bản ban đầu không có phiên bản trước nó • Những phiên bản không phải phiên bản ban đầu phải có một hoặc nhiều phiên bản trước nó • Mỗi phiên bản có thể có một hoặc nhiều phiên bản sau nó • Mỗi phiên bản không thể là phiên bản trước của chính nó 10.4 Phiên Bản Cơ Bản (Base Version) Các Node có cùng một UUID trên các Workspace khác nhau được xem như là các phiên bản khác nhau của cùng một đối tượng Node trên Repository và các thể hiện này có cùng một Version History. Tuy nhiên, trên Version History có thể có nhiều phiên bản khác nhau và mỗi thể hiện của đối tượng Node có thể chọn cho riêng mình một phiên bản cơ bản khác nhau. Phiên bản cơ bản của một thể hiện dùng để làm phiên bản trước mặc định của một phiên bản mới của thể hiện đó được tạo ra trên Version History. 10.5 Khởi Tạo Một Version History Khi một Node có thể tạo ra phiên bản (Versionable Node) được tạo ra trên Repository thì khi đó một Version History cũng được tạo ra cho Node. Lúc mới tạo ra thì Version History chỉ có một Node có kiểu nt:versionHistory và một Node con có kiểu nt:version đóng vai trò là Root Version. Ví dụ : xét trường hợp một Node N được tạo ra như sau. • Node M là Node cha của Node N và tạo ra Node N bằng cách gọi phương thức M.addNode(“N”). Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 86 Đặng Đình Vương • Trước khi được lưu lại (gọi đến phương thức save) thì Node N được gán thêm loại Node phụ mixin:versionable bằng cách gọi phương thúc N.addMixin(“mix:versionable”). • Khi gọi đến phương thức save của N thì một Version History mới sẽ được tự động tạo ra cho Node N. Điều đó có nghĩa là một Node mới có kiểu nt:versionHistory VH sẽ được tạo ra trên Repository và Node VH này có một Node con có kiểu nt:version V0 gọi là jcr:rootVersion và Node con này chính là Root Version. • Root Version này không chứa trạng thái nào của Node mà nó chỉ chứa thông tin về loại Node và UUID thông qua các thuộc tính jcr:frozenPrimaryType, jcr:frozenMixinType, jcr:frozenUUID của nó. • Giá trị của thuộc tính jcr:versionHistory (thuộc tính này có kiểu REFERENCE) của N được gán bằng với UUID của VH. Điều này cho phép N có thể giữ tham chiếu đến Version History của nó. • Giá trị của thuộc tính jcr:baseVersion (thuộc tính này có kiểu REFERENCE) của N được gán bằng với UUID của V0. Điều này cho. phép N có thể giữ tham chiếu đến Base Version của nó. • Thuộc tính jcr:isCheckedOut của N được gán giá trị true. 10.6 Tạo Phiên Bản Mới Của Một Node Để tạo ra một phiên bản mới của Node lưu trong Version History, cần gọi đến phương thức N.checkin, khi đó sẽ phát sinh một loạt các sự kiện sau. • Một Node mới V có kiểu nt:version sẽ được tạo ra và thêm vào làm Node con của Node VH (Node đại diện cho Version History của N trên Repository và được tham chiếu đến bởi thuộc tính jcr:versionHistory của N). Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 87 Đặng Đình Vương • Base Version B của N (Node được tham chiế