Tài liệu Khóa luận 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 đ...
167 trang |
Chia sẻ: hunglv | Lượt xem: 1001 | Lượt tải: 0
Bạn đang xem trước 20 trang mẫu tài liệu Khóa luận Xây dựng CMS Module cho hệ thống Intranet của công ty TMA, để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
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ế
Các file đính kèm theo tài liệu này:
- Unlock-0112024-0112458.pdf