Xd cms module cho hệ thống intranet của cty tma

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA CÔNG NGHỆ THÔNG TIN

BỘ MÔN CÔNG NGHỆ PHẦN MỀM

ĐẶNG ĐÌNH VƯƠNG

BÙI VĨNH PHÚ

XÂY DỰNG CMS MODULE CHO HỆ THỐNG

INTRANET CỦA CÔNG TY TMA

KHÓA LUẬN CỬ NHÂN TIN HỌC

TP. HCM, NĂM 2005

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA CÔNG NGHỆ THÔNG TIN

BỘ MÔN CÔNG NGHỆ PHẦN MỀM

ĐẶNG ĐÌNH VƯƠNG – 0112458

BÙI VĨNH PHÚ – 0112024

XÂY DỰNG CMS MODULE CHO HỆ THỐNG

INTRANET CỦA CÔNG TY TMA

KHÓA LUẬN CỬ NHÂN TIN HỌC

GIÁO VIÊN HƯỚNG DẪN

TS. TRẦN VIẾT HUÂN

KS. NGUYỄN TẤN HỘ

KS. LÊ THANH NHÀN

TP. HCM, NĂM 2005

LỜI CẢM ƠN

Chúng tôi xin chân thành cảm ơn Khoa Công nghệ Thông tin, trường Đại học

Khoa học Tự nhiên, Thành phố Hồ Chí Minh và Công ty TMA đã tạo điều kiện cho

chúng tôi thực hiện đề tài tốt nghiệp này.

Xin cảm ơn Thầy Trần Viết Huân, Anh Nguyễn Tấn Hộ, Anh Lê Thanh Nhàn,

người đã tận tình hướng dẫn, chỉ bảo chúng tôi trong suốt thời gian thực tập tại Công

ty.

Chúng tôi cảm ơn các anh chị trong nhóm TIS đã giúp đỡ, đóng góp ý kiến cho

chúng tôi trong quá trình cài đặt, thử nghiệm chương trình.

Xin gửi lời cảm ơn chân thành đến gia đình, ba mẹ và bè bạn vì đã luôn là

nguồn động viên to lớn, giúp đỡ chúng tôi vượt qua những khó khăn trong suốt quá

trình làm việc.

Mặc dù đã cố gắng hoàn thiện luận văn với tất cả sự nỗ lực của bản thân, nhưng

chắc chắn không thể tránh khỏi những thiếu sót. Kính mong quý Thầy Cô tận tình chỉ

bảo.

Một lần nữa, chúng tôi xin chân thành cảm ơn và luôn mong nhận được sự đóng

góp quý báu của tất cả mọi người.

Tháng 7 năm 2005

Đặng Đình Vương

Bùi Vĩnh Phú

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

MỤC LỤC

DANH SÁCH CÁC HÌNH VẼ ......................................................................................1

MỘT SỐ KÝ HIỆU VÀ TỪ VIẾT TẮT......................................................................4

MỞ ĐẦU .........................................................................................................................6

Chương 1 Giới thiệu đề tài ........................................................................................7

TỔNG QUAN ...............................................................................................................12

Chương 2 Tổng quan về sự phát triển của các hệ CMS .......................................13

NGHIÊN CỨU..............................................................................................................16

Chương 3 Nhu cầu sử dụng hệ CMS trong các tổ chức........................................17 1. Nhu cầu hiện tại ..................................................................................................18

1.1 Tình hình các web site của các tổ chức ở Việt Nam.....................................18 1.2 Nhu cầu cập nhật và quản lý nội dung..........................................................18

1.2.1 Nhu cầu của các doanh nghiệp...............................................................18 1.2.2 Nhu cầu của các tờ báo điện tử ..............................................................20 1.2.3 Nhu cầu trong các hệ thống thông tin của các công ty ..........................21

2. Những lợi ích mà một hệ CMS mang lại cho các công ty..................................23

Chương 4 Hệ thống intranet hiện tại của công ty .................................................25 1. Yêu cầu khi phát triển hệ thống intranet của công ty TMA ...............................26

1.1 Tình hình hiện tại ..........................................................................................26 1.2 Quy định về kiến trúc....................................................................................27

1.2.1 Kiến trúc mạnh .......................................................................................27 1.2.2 Xây dựng các công cụ hệ thống phi chức năng .....................................28 1.2.3 Bảo mật ..................................................................................................28 1.2.4 Khả năng tích hợp ..................................................................................29

1.3 Yêu cầu lúc phát triển ...................................................................................29 2. Portal hiện tại của TMA .....................................................................................30

2.1 Đặc điểm và các thành phần của portal ........................................................30 2.2 Các thành phần đã được xây dựng................................................................31 2.3 Kiến trúc hệ thống của portal........................................................................34

2.3.1 Kiến trúc hệ thống của các portal phổ biến............................................34 2.3.2 Kiến trúc hệ thống của portal TMA .......................................................35

3. Công nghệ được sử dụng để phát triển hệ thống intranet ...................................36


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


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


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


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


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


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



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



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



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 http://www.eclipse.org/

HTML Hyper Text Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Secure Hypertext Transfer Protocol

JBoss Web application server miễn phí http://www.jboss.org/products/jbossas

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 http://www.objectlearn.com/index.html

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



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



MỞ ĐẦU



Chương 1 Giới thiệu đề tài



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ở.



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

• …



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



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.



TỔNG QUAN



Chương 2 Tổng quan về sự phát triển của các hệ CMS



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…



• 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.



NGHIÊN CỨU



Chương 3 Nhu cầu sử dụng hệ CMS trong các tổ chức



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



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



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.



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.



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



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.



• 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.



Chương 4 Hệ thống intranet hiện tại của công ty



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



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í.



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.



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í.



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.



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:



Module Mã nguồn mở sử dụng

Portal Liferay

http://www.liferay.com/cms/servlet/HOME-

INDEX

Document Management System OpenEDMS và Knowledge Tree

http://www.openedms.com/edms/index.html

http://theknowledgetreeinc.com/

Search Engine http://Dig

http://www.htdig.org/

Report Engine Datavision

http://datavision.sourceforge.net/

Workflow Engine Bonita

http://bonita.objectweb.org/

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:



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



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ó



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…



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.



• Để 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.



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:



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



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



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.



• 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.



Chương 5 Chuẩn JSR 168



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. (http://jcp.org/en/jsr/detail?id=168)

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

AP

I

API

APIAPI

API

JSR-168



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.



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.



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.



• 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.



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ị.



• 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.



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



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.

...

<portlet>

...

<expiration-cache>300</expiration-cache>

...

</portlet>

...

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.



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.



• 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ẻ <description>.

• Tên của ứng dụng Portlet được khai báo bằng thẻ <display-name>.

• 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ẻ <security-role>.



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 :



• Đị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:



Hình 16: Cấu trúc một đặc tả triển khai Portlet



Hình 17: Cấu trúc một đặc tả triển khai Portlet (tt)



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 : <portlet-name>.

• Kiểu Portlet tùy chọn : <portlet-mode>.

• Kiểu cửa sổ tùy chọn : <window-state>.

• Thuộc tính người sử dụng : <name>.

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: <name>.

• Hỗ trợ kiểu: <mime-type>.

• Tham chiếu: <name>.

• Tham chiếu vai trò bảo mật: <role-name>.

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.



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:

<%@ taglib uri=http://java.sun.com/portlet prefix=”portlet” %>

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 :

<portlet:actionURL windowState=”maximized” portletMode=”edit”>

<portlet:param name=”action” value=”editStocks”/>

</portlet:actionURL>

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.



Chương 6 Chuẩn JSR 170



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. (http://jcp.org/en/jsr/detail?id=170). 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



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



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());



// 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();



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.



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.



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 -> http://www.jcp.org/jcr/1.0 : Dùng cho việc đặt tên các loại Node có

sẵn. Ví dụ: jcr: content.

• nt -> http://www.jcp.org/jcr/nt/1.0 : Dùng cho việc đặt tên các loại Node

chính (primary node types).

• mix -> http://www.jcp.org/jcr/mix/1.0 : Dùng cho việc đặt tên các loại

Node phụ (mixin node types).

• pt -> http://www.jcp.org/jcr/pt/1.0 : 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 -> http://www.jcp.org/jcr/sv/1.0 : Dùng trong khung nhìn System

View khi chuyển nội dung của Repository sang dạng thức XML.



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



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.



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 :



• 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ụ..



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.



• 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.



• 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 ...



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



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



| |-- 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.



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



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.



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



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.



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.



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)



• 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”).



• 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).



• Base Version B của N (Node được tham chiếu đến bởi thuộc tính

jcr:baseVersion của N) được thay đổi bằng cách thêm vào thuộc tính

jcr:successor và thuộc tính này giữ tham chiếu đến V vừa mới được thêm

vào.

• Thuộc tính jcr:baseVersion của N được thay đổi để tham chiếu đến V.

• Thuộc tính jcr:isCheckedOut của N được gán giá trị false.

• Trạng thái của N được lưu lại trong V bằng cách lưu lại những thông tin

của các Node con và thuộc tính của N tuỳ thuộc vào thuộc tính

OnParentVersion của các Node con và thuộc tính con này.

• Các thuộc tính jcr:primaryType, jcr:mixinTypes và jcr:uuid của N được

lưu lại trong V nhưng được đổi tên thành jcr:frozenPrimaryType,

jcr:frozenMixinTypes và jcr:frozenUUID để tránh sự trùng tên với những

thuộc tính jcr:primaryType, jcr:mixinTypes và jcr:uuid của V.

• V được gán một tên, thông thường tên này dựa trên tên của Node trước

đó của V.

• Nếu nhãn của phiên bản (Version Label) được hỗ trợ khi check-in thì

nhãn này sẽ được thêm vào như là một giá trị của thuộc tính đa trị

jcr:versionLabels.

10.7 Phục Hồi Lại Trạng Thái Trước Đó Của Node

Để phục hồi lại trạng thái trước đó của Node N được lưu trong các phiên bản

của nó, chằng hạn xét một phiên bản có tên “x.y” (ta gọi Node tương ứng với phiên

bản này là V), cần phải gọi phương thức N.restore(“x.y”). Khi đó, các sự kiện sau sẽ

diễn ra.



• Các Node con và thuộc tính của N sẽ thay đổi, bị xoá bỏ hay được thêm

vào tùy thuộc vào bản sao của các Node con và thuộc tính con này trên V

và tuỳ thuộc vào thuộc tính OnParentVersion của từng thành phần con

này.

• Thuộc tính jcr:baseVersion của N được thay đổi để tham chiếu tới V.

• Thuộc tính jcr:isCheckedOut của N được thay đổi thành giá trị false.

10.8 Checkout

Thuộc tính jcr:isCheckedOut của một Node N được sử dụng để xác định trạng

thái của Base Version hiện tại của Node N là có giống với trạng thái hiện tại của N trên

Repository hay không. Sở dĩ có chuyện này do trong quá trình thao tác thì những thay

đổi trên Node chỉ có ý nghĩa là thay đổi tạm thời và những thay đổi tạm thời này sẽ

được lưu vào Repository khi sự thay đổi đó được lưu thật sự xuống Repository(việc

lưu này có thể thông qua nhiều cách khác nhau). Thuộc tính này có giá trị true có nghĩa

là 2 trạng thái này không giống nhau và nếu có giá trị false thì có nghĩa là 2 trạng thái

này giống nhau. Trạng thái này được xác định thông qua phương thức N.chekout.

10.9 Update

Phương thức Node.update(String srcWorkspace, boolean shallow ) sử dụng

trong trường hợp repository không hỗ trợ versioning. Node gọi phương thức này sẽ ánh

xạ trạng thái của nó sang các node tương ứng trong srcWorkspace.



10.10 Các Node Có Thể Tạo Phiên Bản Trên Repository

JCR quy định một Node có thể tạo ra phiên bản của nó trên Repository khi và

chỉ khi nó sở hữu kiểu Node phụ mixin:versionable. Những mô tả về kiểu Node phụ

này được thể hiện dưới đây :

NodeTypeName

mix:versionable

Supertypes

mix:referenceable

IsMixin

true

PropertyDef

Name jcr:versionHistory

Type REFERENCE

ValueConstraint "nt:versionHistory"

DefaultValue null

AutoCreate true

Mandatory true

OnParentVersion COPY

ReadOnly true

PrimaryItem false

Multiple false

PropertyDef

Name jcr:baseVersion

Type REFERENCE

ValueConstraint "nt:version"

DefaultValue null



AutoCreate true

Mandatory true

OnParentVersion IGNORE

ReadOnly true

PrimaryItem false

Multiple false

PropertyDef

Name jcr:isCheckedOut

Type BOOLEAN

ValueConstraint null

DefaultValue "true"

AutoCreate true

Mandatory true

OnParentVersion IGNORE

ReadOnly true

PrimaryItem false

Multiple false

Cũng cần lưu ý là kiểu Node phụ mixin:versionable là kiểu con của kiểu

mix:referenceable do đó những Node có kiểu mixin:versionable cũng có UUID. Thêm

vào đó, Node có kiểu mixin:versionable còn có thêm các thuộc tính jcr:versionHistory,

jcr:baseVersion và jcr:isCheckedOut.

Thuộc tính jcr:versionHistory có kiểu thuộc tính là REFERENCE dùng để tham

chiếu đến một Version History bằng cách lưu UUID của Version History Node như là

giá trị của thuộc tính. Version History này dùng để lưu những phiên bản của Node.



jcr:baseVersion có kiểu thuộc tính là REFERENCE dùng để tham chiếu đến một

phiên bản trên Version History (Version History này có tham chiếu được lưu trong

thuộc tính jcr:versionHistory) bằng cách lưu UUID của Version Node. Version Node

này chính là phiên bản cơ bản (Base Version) của Node.

jcr:isCheckedOut có kiểu thuộc tính là BOOLEAN dùng để lưu trạng thái của

Node và phiên bản với giả trị false cho biết trạng thái hiện tại là check-in và true cho

biết trạng thái hiện tại lả check-out.

10.11 Thuộc Tính OnParentVersion

Mỗi thành phần (bao gồm Node và các thuộc tính) của một Node có một trạng

thái cho biết hành động tương ứng xảy ra đối với Node con hay thuộc tính khi Node

cha của nó thực hiện việc tạo ra phiên bản trên Repository. Trạng thái này được xác

định bởi thuộc tính OnParentVersion trong PropertyDef hay trong ChildNodeDef được

quy định bởi loại Node của Node cha.

Xét ví dụ trong đó có Node N là một Node có thể tạo ra phiên bản được

(Versionable Node) trên một Workspace W của Repository R. Node N này có loại

Node T với T là loại Node con của loại Node nt:versionable và T cho phép N có thuộc

tính có tên P và Node con C.

các hành động xảy đến cho P và C khi N tạo ra phiên bản trên Repository tùy

thuộc vào thuộc tính OnParentVersion trong PropertyDef của P và trong

ChildNodeDef của C được quy định bởi T.

Các giá trị có thể có của thuộc tính OnParentVersion là

• COPY

• VERSION



• INITIALIZE

• COMPUTE

• IGNORE

• ABORT

Các giá trị của thuộc tính OnParentVersion này được quy định như các hằng số

trong lớp OnParentVersionAction.

javax.jcr.version. OnParentVersionAction

int COPY

int VERSION

int INITIALIZE

int COMPUTE

int IGNORE

int ABORT

Bảng 2: Các hằng số trong giao diện javax.jcr.version.OnParentVersionAction

10.11.1 COPY

Khi gọi phương thức chekin() của N, C và toàn bộ các thành phần con của nó

(bao gồm Node con và các thuộc tính con) sẽ được sao chép vào vùng lưu phiên bản

như là cây con của VN. C và các thành phần trong cây con của nó sẽ không có Version

History của riêng nó, do đó, C không cần phải là Node có thể tạo phiên bản được

(Versionable Node)



Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, những bản sao

chép của C và cây con của nó đã được lưu trước đó (khi gọi phương thức checkin)

cũng sẽ được phục hồi để thay thế C và cây con của nó trên Workspace

10.11.2 VERSION

Khi gọi phương thức chekin() của N, VN sẽ thêm vào một tham chiếu đến

Version History của C. Do đó, điều này cũng yêu cầu C là một Node có thể tạo ra

phiên bản. Nếu C là Node không thể tạo ra phiên bản thì cách xử lý cũng giống như

trường hợp IGNORE.

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, nếu trên

Workspace hiện thời có sẵn một Node tương ứng với Version History của C thì khi đó

thể hiện của C này sẽ trở thành Node con của N. Nếu trên Workspace hiện thời không

có Node nào (hay nói chính xác là thể hiện nào) tương ứng với Version History của C

thì một phiên bản trên Version History của C sẽ được phục hồi lại như là một Node con

của N. Workspace trên đó N được phục hồi sẽ quyết định xem phiên bản nào sẽ được

phục hồi và sự quyết định này là do cấu hình của Workspace quy định.

10.11.3 INITIALIZE

Khi gọi phương thức chekin() của N, một Node mới của C sẽ được tạo ra và

thêm vào vùng lưu phiên bản của Repository như là Node con của VN. Khi Node mới

của C được tạo ra thì sự khởi tạo này cũng giống như việc khởi tạo khi C được tạo ra

trên Workspace bằng cách thông thường. Node mới của C không có Version History,

do đó C cũng không cần phải là một Node có thể tạo phiên bản.



Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, Node con C

của VN sẽ không được quan tâm, điều đó có nghĩa là Node C hiện tại có trên

Workspace sẽ giữ nguyên trạng thái, không bị thay thế bởi Node con C của VN.

10.11.4 COMPUTE

Khi gọi phương thức chekin() của N, một Node mới của C sẽ được tạo ra và

thêm vào vùng lưu phiên bản của Repository như là Node con của VN. Khi Node mới

của C được tạo ra thì sự khởi tạo này được quy định bởi các hàm khởi tạo được định

nghĩa bởi loại Node của C. Node mới của C không có Version History, do đó C cũng

không cần phải là một Node có thể tạo phiên bản.


của VN sẽ không được quan tâm, điều đó có nghĩa là Node C hiện tại có trên

Workspace sẽ giữ nguyên trạng thái, không bị thay thế bởi Node con C của VN.

10.11.5 IGNORE

Khi gọi phương thức chekin() của N, không có thông tin nào của C được lưu

trong VN.


của N sẽ vẫn giữ nguyên trạng thái hiện tại.

10.11.6 ABORT

Khi gọi phương thức chek-in của N thì sẽ phát sinh lỗi (ngoại lệ). Điều này cho

thấy khi một Node cha có Node con có thuộc tính OnParentVersion có giá trị

FORBIDDEN / ABORT thì Node cha đó sẽ không được quyền check-in.



10.12 Ví dụ về một Repository có hỗ trợ tạo phiên bản

Hình 24: Repository có nhiều workspace và hỗ trợ tạo phiên bản



Hình trên mô tả một repository có hỗ trợ versioning và gồm 2 workspace là

WS1 và WS2. WS2 chứa node x không có một version history nào trong version

storage, do đó nó là nonversionable node

Version storage mô tả các version history, mỗi verion history chứa 3 version của

các node 01, 02, và 03.

11. Lắng Nghe Sự Kiện Trên Repository (Observation)

JCR quy định các Repository ở cấp độ 2 có thể cung cấp cơ chế để các ứng

dụng sử dụng Repository có thể nhận biết và quản lý các sự kiện được tạo ra khi có sự

thay đổi xảy ra trên Repository.

Ứng dụng có thể đăng ký với Repository những sự kiện nào mà nó muốn quản

lý cũng như những sự kiện nào nó không muốn xảy ra trên Repository thông qua việc

đăng ký một đối tượng để nhận các sự kiện này (Listener), những đối tượng này phải

hiện thực hóa giao diện javax.jcr.observation.EventListener hay giao diện

javax.jcr.observation.VetoableEventListener. Khi một sự kiện được tạo ra, Repository

gọi đến phương thức onEvent của đối tượng nhận sự kiện đăng ký với Repository và

đối số của phương thức này là đối tượng có kiểu Event dùng để chứa những thông tin

về sự kiện vừa được phát sinh.

11.1 Phát sinh sự kiện

Một sự kiện được phát sinh hay được kích hoạt (Fired) khi có sự thay đổi xảy ra

và sự thay đổi này được cập nhật lên Repository. Cũng cần nhắc lại là có những thay

đổi chỉ xảy ra tạm thời và những thay đổi tạm thời này chỉ được cập nhật thực sự lên

Repository khi gọi đến phương thức save của đối tượng thay đổi tạm thời.



Sự kiện sẽ không được phát sinh khi những thay đổi tạm thời xảy ra mà chữa

được lưu xuống Repository. Đối với những phương thức mà khi thực hiện phương thức

đó, nội dung của Repository bị thay đổi ngay lập tức (chẳng hạn những phương thức

Workspace.copy hay Workspace.move) thì sự kiện sẽ được tạo ra.

Thông tin về sự kiện được phát sinh có thể tìm thấy thông qua các phương thức được

khai báo trong giao diện javax.jcr.observation.Event.

11.2 Các loại sự kiện

Mỗi loại sự kiện phát sinh có một giá trị kiểu long đại diện và các giá trị này là

các hằng số được định nghĩa trước trong giao diện javax.jcr.observation.EventType

javax.jcr.observation.EventType

long ITEM_ADDED

long ITEM_CHANGED

long ITEM_REMOVED

long ITEM_VERSIONED

long ITEM_RESTORED

long LABEL_ADDED

long LABEL_REMOVED

long ITEM_LOCKED

long ITEM_UNLOCKED

long LOCK_EXPIRED

Bảng 3: Các hằng số định nghĩa trong giao diện javax.jcr.observation.EvenType



Các loại sự kiện này có thể phân thành các nhóm sau

• Nhóm sự kiện liên quan đến những thay đổi trên các Item của

Repository, bao gồm: ITEM_ADDED, ITEM_REMOVED,

ITEM_CHANGED.

• Nhóm sự kiện liên quan đến việc quản lý phiên bản trên Repository, bao

gồm: ITEM_VERSIONED, ITEM_RESTORED, LABEL_ADDED,

LABEL_REMOVED.

• Nhóm sự kiện liên quan đến việc quản lý khoá (Locking) trên

Repository, bao gồm: ITEM_LOCKED, ITEM_UNLOCKED,

LOCK_EXPIRED .

11.3 Đối tượng lắng nghe và xử lý sự kiện

Để có thể xử lý các sự kiện xảy ra trên Repository, ứng dụng cần phải đăng ký

với Repository đối tượng dùng để lắng nghe sự kiện trên Repository. Các đối tượng

lắng nghe sự kiện này phải hiện thực hóa giao diện EventListener hay giao diện

VetoableEventListener.

javax.jcr.observation.EventListener

void onEvent(Event event)

Phương thức này được gọi khi sự kiện xảy ra.

javax.jcr.observation.VetoableEventListener

void onEvent(Event event)

Phương thức này được gọi khi sự kiện xảy ra.



Đối tượng EventListener được thông báo sự kiện xảy ra trên Repository một

cách bất đồng bộ (asynchoronous). Điều đó có nghĩa là khi sự kiện xảy ra trong một

giao tác (transaction) và chỉ đến khi giao tác được ủy nhiệm thì đối tượng

EventListener mới được thông báo sự kiện xảy ra.

Đối tượng VetoableEventListener được thông báo sự kiện xảy ra trên

Repository một cách đồng bộ (synchoronous). Điều đó có nghĩa là khi sự kiện xảy ra

trong một giao tác (transaction) thì ngay lập tức sự kiện này sẽ được thông báo đến cho

đối tượng VetoableEventListener mà không cần phải đợi đến lúc submit giao tác. Nếu

sự kiện đã được đăng ký bởi đối tượng VetoableEventListener với Repository (có

nghĩa là ứng dụng không muốn sự kiện đó xảy ra trên Repository khi ứng dụng thực

hiện) và trong một giao tác, sự kiện này lại xảy ra thì khi thực hiện phương thức save

để cập nhật dữ liệu xuống Repository sẽ phát sinh lỗi ActionVetoedException và khi

đó giao tác này sẽ được RollBack.

11.4 Lựa chọn sự kiện để lắng nghe

Để giảm số lượng sự kiện mà một đối tượng nhận sự kiện phải lắng nghe trên

Reporitory, khi đăng ký đối tượng nhận sự kiện với Reporitory, Ta có thể tạo thêm một

đối tượng dùng để lựa chọn chỉ lắng nghe và xử lý những sự kiện nào thực sự cần thiết

cho ứng dụng đang xây dựng. Đối tượng này phải hiện thực hóa giao diện

EventSelector.

11.5 Các sự kiện xảy ra đối với một hành động trên Repository

11.5.1 Hành động thêm một Item

Khi một Node hay một Property mới được thêm vào Repository thì các sự kiện

sau sẽ xảy ra:



• Sự kiện ChangeEvent tương ứng với Item mới được thêm vào. Trong đó

getType() trả về EventType.ITEM_ADDED

getItem() trả về Item vừa được thêm vào

getOldItem() trả về giá trị null

• Sự kiện ChangeEvent tương ứng với Node cha. Trong đó

getType() trả về EventType.ITEM_CHANGED

getItem() trả về Node cha của Item mới được thêm vào

getOldItem() trả về bản sao của Node cha trước khi thêm Item

11.5.2 Hành động thay đổi giá trị của Property

Khi giá trị của một Property bị thay đổi bằng cách gọi phương thức

Node.setProperty hay Node.setValue thì sự kiện sau sẽ xảy ra

• sự kiện ChangeEvent tương ứng với thuộc tính bị thay đổi. Trong đó

getType() trả về EventType.ITEM_CHANGED.

getItem() trả về thuộc tính bị thay đổi.

getOldItem() trả về bản sao của thuộc tính trước lúc bị thay đổi.

11.5.3 Hành động thêm vào một Node đã tồn tại trong Repository

Khi thêm một Node đã tồn tại trong Repository bằng cách gọi phương thức

Node.addExistingNode thì sự kiện sau sẽ xảy ra

• Sự kiện ChangeEvent tương ứng với Node cha của Node được thêm vào,

trong đó:


getItem() trả về Node cha.



getOldItem() trả về bản sao của Node cha trước khi thêm Node có sẵn

làm Node con.

11.5.4 Khôi phục lại trạng thái của một Node

Khi một Node được phục hồi lại trạng thái trước đó của nó bằng cách gọi

phương thức Node.restoreVersion thì sự kiện sau sẽ xảy ra

• Sự kiện VersionControlEvent, trong đó

getType() trả về EventType.ITEM_RESTORED.

getItem() trả về Node gọi phương thức restore.

getVersionHistory() trả về Version History của Node gọi phương thức

restore.

getVersion() trả về phiên bản được restore.

11.5.5 Sao chép một Node

Khi một Node trong Repository được sao chép từ vị trí này sang vị trí khác thì

các sự kiện sau sẽ xảy ra

• Sự kiện ChangeEvent tương ứng với mỗi Item thêm vào, trong đó :

getType() trả về EventType.ITEM_ADDED.

getItem() trả về Item vừa thêm.

getOldItem() trả về giá trị null.

• Sự kiện ChangeEvent tương ứng với mỗi Node cha của mỗi Item thêm

vào, trong đó:


getItem() trả về Node cha.

getOldItem() trả về bản sao của Node cha trước khi thêm Item.



11.5.6 Xóa một Item

Khi một Item bị xóa khỏi Repository thì các sự kiện sau sẽ xảy ra

• Sự kiện ChangeEvent tương ứng với Item bị xoá bỏ, trong đó:

getType() trả về EventType.ITEM_REMOVED.

getItem() trả về bản sao của Item vừa bị xoá bỏ.

getOldItem() trả về bản sao của Item vừa bị xoá bỏ.

• Sự kiện ChangeEvent tương ứng với Node cha của Item bị xoá bỏ, trong

đó:


getItem() trả về Node cha của Item bị xoá bỏ.

getOldItem() trả về bản sao của Node cha trước khi xoá bỏ Item.

11.5.7 Di chuyển vị trí của một Node

Thao tác di chuyển bao gồm thao tác sao chép Item từ vị trí cũ sang vị trí mới và

xoá bỏ Item ở vị trí cũ. Do đó, các sự kiện phát sinh khi thực hiện thao tác này bao

gồm các sự kiện xảy ra khi sao chép và xoá bỏ Item.

11.5.8 Tạo Phiên Bản Của Item

Khi một phiên bản của Item được tạo thì sự kiện sau sẽ xảy ra

• Sự kiện VersionControlEvent tương ứng với phiên bản mới, trong đó:

getType() trả về EventType.ITEM_VERSIONED

getItem() trả về Node tạo phiên bản

getVersionHistory() trả về Version History của Node tạo phiên bản

getVersion() trả về phiên bản mới vừa được tạo



Ngoài ra, sự kiện EventType.ITEM_VERSIONED cũng xảy ra đối với mỗi

Node con tự động tạo phiên bản của Node tạo phiên bản.

11.5.9 Khoá một Item

Khi một Item bị khóa bằng cách gọi phương thức Item.lock thì sự kiện sau sẽ

xảy ra

• Sự kiện LockEvent, trong đó

getType() trả về EventType.ITEM_LOCKED.

getItem() trả về Item bị khoá.

getLock() trả về đối tượng Lock.

Nếu một Node bị khóa và bắt buộc các Item con cũng bị khóa theo thì sự kiện

này cũng phát sinh đối với các Item con.

11.5.10 Mở khóa một Item

Khi một Item được mở khóa bằng cách gọi phương thức Item.unlock hoặc thời

hạn khóa hết hiệu lực thì sự kiện sau sẽ xảy ra

• Sự kiện LockEvent, trong đó

getType() trả về EventType.ITEM_UNLOCKED.

getItem() trả về Item được mở khoá.

getLock() trả về đối tượng Lock đã sử dụng.

Nếu một Node được mở khóa và các Item con cũng được khóa theo thì sự kiện

này cũng phát sinh đối với các Item con.



12. Vấn đề bảo mật trên Repository

JCR định nghĩa các phương thức cho phép nhận biết các quyền hạn được cho

phép của một phiên làm việc trên một Node hay một thuộc tính. JCR cũng định nghĩa

các phương thức cho phép hay từ chối các quyền được cấp trên phiên làm việc.

Các quyền hạn cho phép thao tác trên Item tương ứng với một phiên làm việc

được định nghĩa bằng các hằng số trong giao diện Permission bao gồm ADD_NODE,

SET_PROPERTY, REMOVE_ITEM, READ_ITEM.

13. Cơ chế khóa trên Repository

Khi một khoá được đặt trên một Item của Repository bởi một người dùng thì

người dùng này gọi là người sở hữu khoá và Item này gọi là Item bị khoá.

13.1 Mức độ khóa

Mức độ khoá cho biết có thể khoá trên mức độ Node và thuộc tính hay chỉ có

thể khoá trên mức độ Node thôi.

Nếu mức độ khoá là chỉ trên Node thì điều này cũng có nghĩa là khi thực hiện

khoá hay mở khoá trên Node thì đồng thời việc khoá hay mở khoá này cũng được thực

hiện trên những thuộc tính của Node đó.

13.2 Phạm vi khóa

Có 2 loại phạm vi khoá là khoá độc quyền (Exclusive) và khoá chia sẻ (Shared).



• Khoá độc quyền có nghĩa là khi một người sử dụng đã thực hiện khoá

độc quyền trên Item rồi thì những người sử dụng khác không được quyền

thực hiện bất kỳ khoá nào trên Item đó nữa.

• Khoá chia sẻ có nghĩa là khi một người sử dụng đã thực hiện khoá chia

sẻ trên Item rồi thì những người sử dụng khác không được quyền thực

hiện khoá độc quyền nhưng có thể thực hiện khoá chia sẻ trên Item đó.

13.3 Loại khóa

Loại khoá cho biết khoá đó ngăn không cho những người sử dụng khác (ngoài

người sở hữu khoá) thực hiện thao tác nào trên Item bị khoá. Chằng hạn khi loại khoá

là Write thì sẽ ngăn không cho những người sử dụng khác ghi lên Item bị khoá. Loại

khoá Write này cũng chính là loại khoá duy nhất mà JCR định nghĩa sẵn. Còn các loại

khoá khác, chảng hạn Read, Remove...thì JCR không định nghĩa sẵn mà từng ứng dụng

cụ thể phải định nghĩa các loại khoá này.

14. Tìm kiếm nội dung trên Repository

JCR hỗ trợ việc tìm kiếm trên Repository sử dụng hai ngôn ngữ truy vấn là

JCRQL và XPath. Các phương thức dùng để tạo và thực thi câu truy vấn được định

nghĩa trong giao diện javax.jcr.QueryManager.

Ngôn ngữ truy vấn JCRQL tương tự như ngôn ngữ truy vấn SQL và thường

được sử dụng để tìm kiếm nội dung theo dạng chuỗi giống như các Search Engine.

Ngôn ngữ truy vấn XPath trên JCR tương tự như XPath trên tài liệu XML, do

đó cần phải có khung nhìn XML (System View hay Document View, tốt nhất là sử

dụng Document View) để XPath họat động.



14.1 Ngôn ngữ truy vấn JCRQL

Câu truy vấn sử dụng ngôn ngữ JCRQL phải theo đúng định dạng sau: (các từ

khoá như SELECT và FROM phải viết hoa)

query ::= selectclause fromclause

[locationclause] [whereclause]

[textsearchclause] [orderclause]

14.1.1 Mệnh đề SELECT

Mệnh đề SELECT dùng để đưa ra danh sách tên các Node cần truy vấn, hoặc

nếu sử dụng ký hiệu “*” thì mọi Node đều được truy vấn.

selectclause ::= SELECT (* | nodenamelist)

nodenamelist ::= nodename {, nodename}

nodename ::= /* Tên của một Node */

14.1.2 Mệnh đề FROM

Mệnh đề FROM dùng để xác định chỉ các kiểu Node nào được truy vấn. Nếu

muốn truy vấn mọi kiểu của Node thì sử dụng ký hiêu “*”.

fromclause ::= FROM (* | nodetypelist)

nodetypelist ::= nodetype {, nodetype}

nodetype ::= /* Tên của kiểu Node*/

14.1.3 Mệnh đề LOCATION

Mệnh đều LOCATION dùng để giới hạn lại chỉ truy vấn trên một phần của cây

con trong cây phân cấp bằng cách sử dụng pattern để chỉ đường dẫn trên Reporitory.



locationclause ::= LOCATION [depthclause]

[followingclause] pathpattern

pathpattern ::= plainpath[/] |

plainpath[//[plainpath[/]]]

plainpath ::= itempattern{/pattern}

itempattern ::= * | [*]fragment{fragment}

fragment ::= char | char*

char ::= /* Bất kỳ ký tự nào đúng trong một tên của Item */

Để hiểu rõ hơn, ta xét ví dụ sau về pathpattern :

Pattern Selection

/press/release Chỉ Item /press/release

/press/release/* Mọi Item con của /press/release

/press/release/*/picture Mọit Item có tên picture là con của các

Item con của /press/release

/press/release// Item /press/release và mọi Item trong cây

phân cấp bắt đầu từ /press/release

/press/release//* Mọit Item trong cây phân cấp bắt đầu từ

/press/release, không bao gồm Item

/press/release

/press/release//picture Mọi Item có tên picture có trong cây phân

cấp bắt đầu tử /press/release

/press/release/*//picture Mọi Item có tên picture có trong cây phân

cấp bắt đầu tử các Item con của

/press/release



14.1.3.1 Mệnh đề FOLLOWING

followingclause ::= FOLLOWING [CHILDREN] softlinkprops

softlinkprops ::= itempattern {, itempattern}

Mệnh đề con FOLLOWING dùng để thay đổi phạm vi truy vấn được xác định

bởi pathpattern trong mệnh đề LOCATION. Khi không có mệnh đề con FOLLOWING

thì sử dụng phép toán “//” trong pathpattern dùng để truy vấn đế mọi Item con bên dưói

trong cây phân cấp. Còn khi sử dụng FOLLOWING thì khi sử dụng phép toán “//”,

trong quá trình truy vấn, khi gặp thuộc tính có kiểu PATH thì quá trình tìm kiếm sẽ

được chuyển hướng sang Item mà PATH đó chỉ tới, sau đó tiếp tục truy vấn bắt đầu từ

Item đó theo cơ chế trên.

Ví dụ:

SELECT myapp:picture FROM * LOCATION FOLLOWING

myapp:picturelink /press/releases//

Trả về các Item có tên là myapp:picture trên toàn bộ Reporitory sao cho các Item này

được trỏ tới bởi các Property kiểu PATH có tên myapp:picturelink ở phía dưới cây

phân cấp bắt đầu từ /press/releases.

14.1.3.2 Mệnh đề DEPTH

Mệnh đề con DEPTH dùng để giới hạn độ sâu truy vấn trong cây phân cấp tính

từ Item được xác định bởi pathpattern trong mệnh đề LOCATION.

depthclause ::= DEPTH number

number ::= /* Số nguyên kiểu integer */



Nếu giá trị của number là 0 thì có nghĩa là không truy vấn gì cả. Còn nếu giá trị

của number < 0 thì điều đó có nghĩa là độ sâu truy vấn không bị giới hạn.

Ví dụ:

SELECT * FROM * LOCATION DEPTH 2

/press/releases//myapp:picture

Sẽ trả về mọi Item có tên myapp:picture trong nhánh cây con của /press/releases và đi

sâu xuống dưới 2 cấp.

14.1.4 Mệnh đề WHERE

Mệnh đề WHERE cho phép giới hạn chỉ trả về các Node sao cho miền giá trị

của các thuộc tính trong các Node trả về này thoả điều kiện ràng buộc trong mệnh đề

WHERE.

whereclause ::= WHERE expression

expression ::= property op value | property LIKE pattern | expression

AND expression | expression OR expression | NOT expression

op ::= = | > | < | >= | <=

property := /* Tên của Property */

value := /* Một giá trị của Property, giá trị chuẩn có kiểu String */

pattern ::= "likepattern" | likepattern

likepattern ::= (wildcard | [wildcard]likefragment{likefragment})

likefragment ::= likechar | likechar wildcard

wildcard ::= * | ? | % | _

char ::= /* Bất kì ký tự nào trong chuỗi đại diện cho một value*/



Ví dụ:

Câu truy vấn sau :

SELECT myapp:image FROM * WHERE height < 100 AND

keyword LIKE "*apple*"

Sẽ trả về tất cả các Node tên là myapp:image sao cho thuộc tính height của nó có

giá trị <100 và thuộc tính keyword của nó có chứa chuỗi “apple”.

14.1.5 Mệnh đề SEARCH

Mệnh đề SEARCH cho phép đưa vào câu truy vấn ngôn ngữ tìm kiếm đầy đủ

theo từ. Cú pháp cuả mệnh đề SEARCH được mô tả dưói đây:

textsearchclause ::= TEXTSEARCH searchexp

searchexp ::= simplesearchexp |

customsearchexp |

"simplesearchexp" |

"customsearchexp"

simplesearchexp ::= [-]term {[OR][-]term}

term ::= word | 'word {word}'

word ::= /* Một chuỗi không có khoảng trắng)*/

customsearchexp ::= /* Một phần mở rộng được định nghĩa bởi các

chuẩn khác */

Mọi ứng dụng được xây dựng theo chuẩn JSR-170 đều phải hỗ trợ ít nhất

simple-search engine. Đây là kiểu tìm kiếm theo chuỗi thường sử dụng trong các

Search Engine như Google hay Yahoo như được định nghĩa trong simplesearchexp như

trên. Cú pháp của simplesearchexp này có thể được mô tả như sau:



• Khoảng trắng giữa các từ khoá tìm kiếm (Term) được hiểu như toán tử

AND.

• Các từ khoá bị loại trừ trong kết quả tìm kiếm được thêm vào dấu “-”

phía trước từ khoá đó. Nghĩa là kết quả tìm kiếm không được chứa những

từ khoá bị loại trừ này.

• Mỗi từ khoá tìm kiếm có thể chỉ bao gồm một từ hay là một nhóm các từ

và được giới hạn bởi dấu nháy đơn “ ' ”.

• Toàn bộ simplesearchexp có thể được giới hạn bở dấu nháy đôi “ “ ” để

có thể chứa ký tự trắng (khoảng trắng).

• Trong simplesearchexp, nếu muốn sử dụng ký hiệu “ ' ”, “ “ ”, “\” hay “-”

theo ý nghĩa thông thường thì phải sử dụng thêm ký hiệu “\” theo dạng “

\' ”, “ \“ ”, “\\” hay “\-”.

• Phạm vi của mệnh đề SEARCH là giao của 2 tập hợp:

• Tập giá trị của những thuộc tính con của các Node được xác định bởi các

mệnh đề khác trong câu truy vấn JCRQL (chẳng hạn mệnh đề SELECT,

FROM, LOCATION, WHERE ...).

14.1.6 Mệnh đề ORDER BY

orderclause ::= ORDER BY propname {, propname}

propname ::= /* Tên của một Property */

Mệnh đề ORDER BY dùng để sắp xếp kết quả câu truy vấn theo giá trị của một

hay nhiều thuộc tính.



15. Một số ví dụ về việc cài đặt JCR

15.1 JCR cài đặt bên trên File System

Giả sử ta có cấu trúc file như sau :

Một JCR được ánh xạ từ hệ thống file trên như sau :



15.2 JCR cài đặt bên trên một Database

Giả sử từ một cấu trúc repository như sau



Ta có thể ánh xạ qua database sử dụng 2 bảng, bảng NODES và bảng

PROPERTIES



Chương 7 So sánh một số giải pháp CMS mã nguồn

mở phổ biến



1. Giới thiệu các giải pháp hiện tại

1.1 Xu hướng phát triển của các hệ CMS

1.1.1 Xu hướng về mặt thương mại

Đa số các công ty phần mềm đều phát triển các hệ CMS để bán cho các công ty

có nhu cầu. Do đó, lãnh vực này rất có tiềm năng và các công ty chuyên cung cấp các

giải pháp CMS thu được rất nhiều lợi nhuận.

Các hệ CMS được tạo ra ngày càng dễ sử dụng. Xu hướng này nhằm lôi kéo

nhiều hơn nữa các công ty mua các giải pháp CMS để sử dụng cho các web site của họ.

Mọi thao tác xử lý trên hệ CMS cần phải thân thiện với người sử dụng, ngay cả

với các nhân viên của các doanh nghiệp hay các toà soạn báo là những người không

rành rẽ lắm về tin học.

Việc cấu hình các hệ CMS để đưa vào một hệ thống có sẵn cũng được tối ưu

hoá nhằm giảm thời gian và công sức trong giai đoạn triển khai hệ thống đến người sử

dụng cuối.

Khi một công ty tin học ký một hợp đồng để phát triển một hệ CMS, họ có

khuynh hướng sử dụng một mã nguồn mở và miễn phí cho công việc của họ, thay vì

phải mua một giải pháp và sửa đổi mã nguồn của giải pháp để đáp ứng nhu cầu khách

hàng.



1.1.2 Xu hướng về công nghệ, kỹ thuật

Bên cạnh các công ty phát triển các hệ CMS với mục tiêu thương mại, vẫn có

các tổ chức, các lập trình viên thích thú với việc phát triển các hệ CMS với mục đích

phi thương mại. Do đó, chúng ta có thể nhận thấy một số xu hướng sau:

• Phát triển các hệ CMS mã nguồn mở và miễn phí.

• Sử dụng ngày càng nhiều các thành phần miễn phí vào các hệ CMS, ví

dụ: JBoss (application server miễn phí), MySQL (hệ quản trị cơ sở dữ

liệu miễn phí), Linux (hệ điều hành miễn phí), Java (ngôn ngữ lập trình

miễn phí)…

• Các hệ CMS có thể hoạt động trên nhiều platform khác nhau: xu hướng

này giúp cho các hệ CMS có thể tương thích với nhiều hệ điều hành khác

nhau.

• Cung cấp ngày càng nhiều sự hỗ trợ cho người sử dụng cuối.

Do internet phát triển ngày càng nhanh nên số lượng người sử dụng

trong hệ CMS ngày càng nhiều.

Cho phép cung cấp nhiều chức năng hơn cho các tổ chức có nhiều

nhân viên.

• Ngày càng tiện dụng:

Hỗ trợ cơ chế drag ‘n’ drop.

Hỗ trợ cơ chế WYSIWYG.

• Dễ tích hợp các modules khác vào hệ CMS: giúp cho việc mở rộng dễ

dàng hệ CMS khi có nhu cầu.



1.2 So sánh các giải pháp CMS thông dụng

1.2.1 Tiêu chí lựa chọn các giải pháp CMS để so sánh

Do đây là một CMS module được xây dựng cho công ty TMA nên chúng tôi chỉ

chọn so sánh một số giải pháp CMS đáp ứng được yêu cầu của công ty. Nghĩa là các hệ

CMS này phải có ít nhất các đặc điểm sau:

• Mã nguồn mở: đặc điểm này cho phép sửa đổi mã nguồn không bị ràng

buộc để đáp ứng tốt nhất yêu cầu đề ra.

• Mã nguồn miễn phí.

• Mã nguồn phải được lập trình bằng Java và sử dụng các công nghệ của

Java: nguyên nhân do portal hiện tại của công ty được lập trình bằng Java

và yêu cầu đặt ra là phải xây dựng hệ CMS dưới dạng portlet để tích hợp

vào portal hiện tại. Do đó, giải pháp CMS phải được viết bằng Java.

1.2.2 Các tiêu chí so sánh

Chúng tôi so sánh các giải pháp CMS mã nguồn mở và lập trình bằng Java dựa

trên các khía cạnh sau:

• Yêu cầu hệ thống

• Bảo mật

• Tiện dụng

• Hiệu suất

• Tính khả chuyển

• Khả năng quản lý

• Các hỗ trợ khác



1.2.2.1 Yêu cầu hệ thống

Cofax 2.0

Daisy 1.1

Magnolia 2.1

OpenCMS 5.0

Application Server TomCat (Built-in) J2EE TomCat

Hệ quản trị cơ sở dữ liệu MySQL MySQL Postgres

JCR MySQL Oracle

MSSQL

Hệ điều hành Mọi Mọi Mọi Mọi

Ngôn ngữ lập trình Java Java Java Java 1.3+

Web server Mọi Mọi Mọi TomCat Apache

IIS

Bảng 4: So sánh yêu cầu hệ thống của một số CMS

1.2.2.2 Bảo mật

Cofax 2.0

Daisy 1.1

Magnolia 2.1

OpenCMS 5.0

Quản lý quyền truy cập Có Có Có Có

Lưu thông tin đăng nhập Không Không Không Không

Quản lý phiên làm việc Không Không Có Không

Tương thích với SSL Không Có Có Không

Xác nhận bằng email Không Có Không Không

Bảng 5: So sánh tính bảo mật của một số CMS



1.2.2.3 Tiện dụng

Cofax 2.0

Daisy 1.1

Magnolia 2.1

OpenCMS 5.0

Hỗ trợ cơ chế drag’n’drop Không Không Có Không

Thay đổi kích cỡ ảnh Không Không Có Không

Phục hồi lại thao tác trước đó

Không Có Có Không

Hỗ trợ WYSIWYG Có Có Có Có

Bảng 6: So sánh tính tiện dụng của một số CMS

1.2.2.4 Hiệu suất

Cofax 2.0

Daisy 1.1

Magnolia 2.1

OpenCMS 5.0

Hỗ trợ lưu trữ dữ liệu tạm thời (cache) cho toàn bộ hệ thống


Hỗ trợ lưu trữ dữ liệu tạm thời cho trang web

Có Có Có Không

Bảng 7: So sánh hiệu suất hoạt động của một số CMS



1.2.2.5 Tính khả chuyển

Cofax 2.0

Daisy 1.1

Magnolia 2.1

OpenCMS 5.0

Cho phép thêm thông tin của người sử dụng

Có Không Không Không

Hỗ trợ đa ngôn ngữ Không Có Có Không

Cho phép cơ sở dữ liệu phân tán


Bảng 8: So sánh tính khả chuyển của một số CMS

1.2.2.6 Khả năng quản lý

Cofax

2.0

Daisy

1.1

Magnolia

2.1

OpenCMS

5.0

Lập lịch cho nội dung Có Không Không Không

Quản lý trực tiếp từng phần

trang web


Phân loại nội dung Không Có Có Không

Hỗ trợ theme Không Có Giới hạn Không

Quản lý template Không Không Có Giới hạn

Bảng 9: So sánh khả năng quản lý của một số CMS



1.2.2.7 Các hỗ trợ khác

Cofax

2.0

Daisy

1.1

Magnolia

2.1

OpenCMS

5.0

Xuất dữ liệu dạng RSS Có Không Giới hạn Không

Hỗ trợ upload dữ liệu thông

qua FTP

Giới hạn Không Không Không

Hỗ trợ UTF-8 Không Có Có Không

Tuân theo XHTML Không Không Có Không

Bảng 10: So sánh các khả năng hỗ trợ khác của một số CMS



2. Mô tả các giải pháp đã so sánh

2.1 Giải pháp Cofax 2.0

Hình 25: Giao diện Cofax

Cofax là một CMS hỗ trợ mạnh về văn bản và đa phương tiện. Giải pháp này

được phát triển ban đầu bởi Knight Ridder để đơn giản hoá việc thể hiện và đẩy nhanh

tốc độ xuất bản các thông tin, sự kiện trên tờ báo điện tử của họ. Giải pháp này đã được

sử dụng bởi nhiều tờ báo điện tử lớn như : Philadelphia Inquirer News, Philadelphia

Daily News...



Hiện nay, Cofax được sử dụng bởi rất nhiều tổ chức trên thế giới dưới dạng một

CMS mã nguồn mở.

Giải pháp này sử dụng Java, cơ sở dữ liệu MySQL và XML để phát triển. Đây

là một giải pháp được thiết kế theo hướng đối tượng. Trong đó, mỗi module độc lập

với module khác. Điều này cho phép thay đổi một module không phù hợp bằng một

module khác thích hợp hơn. Ngoài ra, điều này còn giúp cho việc cấu hình một cách

độc lập các module với nhau.

Kiến trúc hệ thống của Cofax bao gồm 4 tầng chính như sau :

• Hệ thống quản lý giao tác.

Cofax sử dụng các lớp của Java để nhập dữ liệu dưới dạng XML, sau

đó lưu dữ liệu này vào trong Repository của Cofax.

Hệ thống này xử lý các giao tác bằng cách trao đổi các gói.

• Repository của Cofax

Repository của Cofax được đặt trên một tầng riêng rẽ và cung cấp các

APIs cho các tầng khác có thể sử dụng các chức năng của nó.

Theo thiết kế, tầng này chịu trách nhiệm giao tiếp với cơ sở dữ liệu,

như : Oracle, Sybase, Object Store, XML...

• Hệ thống CMS : tầng này có thể hỗ trợ ASP, JSP hay Servlet

• Hệ thống trình diễn nội dung : tầng này có thể hỗ trợ nhiều ngôn ngữ thể

hiện cho các template

Trong các tầng vừa nêu trên, người ta sử dụng thư viện các lớp chia sẻ của Java

cho các chức năng của chúng. Do đó, khi lập trình viên triển khai hay sửa đổi một chức

năng, họ có thể thao tác chỉ trên thư viện đó mà không cần thay đổi nhiều mã nguồn.



2.2 Giải pháp Daisy 1.1

Hình 26: Giao diện Daisy

Hệ thống CMS này bao gồm một Repository server có thể truy cập được bằng

cách sử dụng giao thức HTTP.

Daisy được phát triển đầu tiên bởi Schaubroeck, sau đó giải pháp này được phát

triển bởi Outerthought, trung tâm hỗ trợ mã nguồn mở dưới dạng Java và XML.

Trung tâm Outerthought có nhiều kinh nghiệm trong việc phát triển các công cụ

mã nguồn mở, và các công cụ này được sử dụng để phát triển các ứng dụng có tính

chất thương mại. Vì lý do này, các lập trình viên không những sử dụng mã nguồn của

Cofax trong ứng dụng của mình mà họ còn ra sức chia sẻ kinh nghịêm để cùng nhau

phát triển giải pháp này.



Giải pháp này bao gồm 2 thành phần chính như sau :

• Repository chứa nội dung.

• Giao diện web.

2.2.1 Repository chứa nội dung

Thành phần này của Daisy bao gồm những đặc điểm sau :

• Lưu trữ và phục hồi dữ liệu.

• Mỗi trang web cho phép chứa nhiều phần và nhiều paragraph. Loại trang

web sẽ định nghĩa các phần và các paragraph mà nó cần có.

• Trang web có thể chứa hình ảnh, tài liệu PDF hay XML.

• Mọi trang và mọi tài liệu đều được lưu trong một vùng lưu dữ liệu duy

nhất và vùng lưu dữ liệu này không có cấu trúc cây thư mục. Mỗi trang

và tài liệu được xác định bởi một định danh duy nhất.

• Dữ liệu được lưu trữ trong hệ quản trị cơ sở dữ liệu MySQL. Hiện nay,

Daisy đã hỗ trợ hệ quản trị cơ sở dữ liệu PostgreSQL.

2.2.2 Giao diện web

Thành phần này của Daisy bao gồm những đặc điểm sau :

• Môi trường biên soạn nội dung trang web WYSIWYG.

Hỗ trợ trình duyệt Internet Explorer và Mozilla/Firefox

Sử dụng các hình ảnh trong Repository của Daisy hay tải các hình ảnh

lên và sử dụng

• Nội dung các trang web được trình bày dưới dạng cây để duyệt dễ dàng.

• Hỗ trợ sửa đổi nội dung ngay trên cây hiển thị các trang web.



• Cung cấp cơ chế tìm kiếm.

Sử dụng Search Engine giống như của Yahoo và Google.

Hỗ trợ tìm kiếm theo ngôn ngữ định nghĩa của riêng Daisy.

Các trang web sử dụng template dựa trên XSLT.

Cho phép thêm các ghi chú vào tài liệu.

2.3 Giải pháp Magnolia 2.1

Hình 27: Giao diện Magnolia

Magnolia là hệ CMS mã nguồn mở có hõ trợ chuẩn JSR 170, chuẩn bao gồm

những API hỗ trợ cho các thao tác trên Repository chứa dữ liệu của Java.



Giải pháp này có thể hoạt động trên mọi hệ điều hành mà chỉ cần cài đặt JDK

1.4.1 trở lên. Sở dĩ làm được điều này do giải pháp này được phát triển dựa trên Java

và công nghệ XML

Các template của Magnolia được xây dựng dựa trên các tập tin JSP và các thẻ

quy định. Magnolia hoạt động trên một server J2EE.

Giải pháp này được phát triển đầu tiên bởi công ty Obinary và sau đó được phát

triển bởi Magnolia International.

Magnolia hỗ trợ rất nhiều ngôn ngữ như : Anh, Pháp, Trung Quốc, Đức, Ý,

Nhật, Tây Ban Nha, Nga, Bồ Đào Nha...

Trong giải pháp này, người ta chia mã nguồn thành 3 modules chính sau :

• Module quản lý nội dung.

Module này bao gòm các tập tin JSP, JavaScript và Servlet để thực

hiện chức năng.

Môi trường chỉnh sửa nội dung WYSIWYG.

Cho phép sửa đổi nội dung tại nơi nội dung đó xuất hiện trên trang

web.

Hỗ trợ các trình duyệt Internet Explorer và Mozilla/Firefox.

Cung cấp cơ chế phân loại nội dung dựa trên cấu trúc cây.

Dữ liệu được lưu trữ trong hệ thống tập tin của hệ điều hành dựa trên

chuẩn JSR 170. Do đó, giải pháp này không cần phải có hệ quản trị

cơ sở dữ liệu.

• Module Repository.

Hỗ trợ việc truy cập vào Repository chứa nội dung.

Sử dụng các gói và các APIs được quy định bởi JSR 170.



Hỗ trợ việc chuyển đổi dễ dàng Repository chứa nội dung : do

module này được xây dựng dựa trên chuẩn JSR 170, do đó nhà phát

triển có thể chuyển đổi qua lại việc sử dụng các Repository chứa nội

dung, như : các tập tin XML, hệ thống tập tin của hệ điều hành, hệ

quản trị cơ sở dữ liệu...cho giải pháp của họ.

• Module bảo mật.

Cung cấp những chức năng để phân chia vai trò và người sử dụng trên

hệ thống CMS này.

2.4 Giải pháp OpenCMS 5.0

Hình 28: Giao diện OpenCMS

Giải pháp này hỗ trợ những nguời sử dụng tạo ra các trang web mà không cần

phải biết về HTML. Môi trường biên soạn nội dung WYSIWYG với giao diện giống

như giao diện của Microsoft Office tạo sự thân thiện hơn với người sử dụng.



Giải pháp này là một giải pháp mã nguồn mở và hoàn toàn miễn phí. Nó được

xây dựng chủ yếu bởi công ty Alkacon Software. Ngoài ra còn có một số công ty khác

tham gia phát triển như : Advent Consulting, Agora Telematica, Aliacom.

OpenCMS phát triển dựa trên Java, JSP, Servlet và XML. Ngoài ra, giải pháp

này có thể hoạt động dựa trên các thành phần mã nguồn mở như : Linux, Apache,

Tomcat, MySQL, cũng nhữ các thành phần cần đến bản quyền như : Windows NT, IIS,

BEA Weblogic, Oracle DB.

Nội dung các trang web trong OpenCMS được lưu trong các tập tin XML va các

template của các trong web được xây dựng bằng cách sử dụng các trang JSP và Java.

Giải pháp này hỗ trợ chuẩn UTF-8, do đó nó cho phép hiển thị nhiều ngôn ngữ

khác nhau.

Ngoài môi trường biên soạn WYSIWYG, OpenCMS còn cung cấp cơ chế

command line để tăng tốc độ truy cập vào các tài nguyên hệ thống.

3. Kết luận

Sau khi so sánh các điểm mạnh và các mặt hạn chế của giải pháp : Cofax 2.0,

Daisy 1.1, Magnolia 2.1 và OpenCMS 5.0, chúng tôi chọn giải pháp Magnolia 2.1 để

phát triển thành module CMS của công ty TMA.

Sự lựa chọn này dựa trên những lý do sau :

• Giải pháp này tuân thủ chuẩn JSR 170, chuẩn dùng để xây dựng các hệ

CMS, do đó trong tương lai nếu yêu cầu thay đổi hệ thống này thì sẽ

giảm tối đa việc chỉnh sửa mã nguồn.



• Giải pháp này cho phép chỉnh sửa mã nguồn không giới hạn và là mã

nguồn mở

• Magnolia có thể hoạt động trên Linux và JBoss, môi trường mà portal

hiện tại của TMA đang hoạt động. Do đó, giải pháp này có khả năng sẽ

tích hợp được vào portal hiện tại của công ty.

• Có nhiều lập trình viên hiện đang phát triển giải pháp này, do đó, trong

trường hợp xảy ra các vấn đề về kỹ thuật, chúng tôi có thể nhận được

nhiều sự hỗ trợ từ phía họ.

• Chúng tôi có thể chuyển đổi giải pháp này để nó tuân thủ theo chuẩn JSR

168 nhằm tích hợp vào portal hiện tại của công ty. Nguyên nhân là giải

pháp này sử dụng ngôn ngữ lập trình Java và JSP, Servlet, JavaScript và

theo dạng dự án J2EE.

• Giải pháp này hỗ trợ nhiều ngôn ngữ nên người sử dụng có thể chọn

ngôn ngữ thân quen nhất với họ.

• Giải pháp này hỗ trợ tốt việc phân loại nội dung các trang web.

• Magnolia cung cấp môi trường biên soạn nội dung WYSIWYG tiện dụng

cho người sử dụng..

• Giải pháp này hỗ trợ mạnh và linh động việc phân quyền người sử dụng

trên hệ thống .

• Giải pháp này cho phép thay đổi dễ dàng các thông số cấu hình mà

không cần phải sửa đổi mã nguồn.

• Magnolia cung cấp chức năng drag’n’drop tạo tính tiện dụng cho người

dùng.

• Magnolia hỗ trợ việc quản lý nội dung tại vị trí hiển thị của nội dung trên

trang web.



ỨNG DỤNG



Chương 8 Các chức năng của TMA CMS



1. Mô hình Use case

Bien soan trang webPhan loai noi dung

Toi uu hoa cac thong tin cau hinh

Su dung cac template

Nguoi bien soan noi dung

Nguoi quan ly cau hinh

Truy nhap vao he CMS

Nguoi su dung trong portal

Quan ly nguoi su dungGan vai tro cho nguoi su dung

Lua chon ngon ngu ua thich

Nguoi quan ly nguoi su dung

Quan ly vai tro

Tim kiem thong tin

Phan quyen cho vai tro

Nguoi quan ly vai tro



2. Mô tả các chức năng

2.1 Quản lý vai trò

Một vai trò bao gồm các thuộc tính sau:

• Tên tắt vai trò.

• Tên đầy đủ của vai trò.

• Mô tả về vai trò.

• Quyền hạn của vai trò.

Một người quản lý vai trò có quyền thực hiện các thao tác sau:

• Thêm vai trò: khi người quản lý vai trò thêm một vai trò vào trong hệ

thống, cần phải xác định những thuộc tính của vai trò được nêu ở trên.

• Xoá vai trò.

• Sửa đổi vai trò.

Ngoài ra, người quản lý vai trò có quyền cho kích hoạt vai trò hoặc ngăn cấm sự

truy cập của vai trò vào hệ thống. Khi vai trò được kích hoạt, người sử dụng có vai trò

tương ứng có thể truy cập vào hệ CMS. Ngược lại, khi vai trò đã bị ngăn cấm thì người

sử dụng không được phép truy cập vào hệ thống.

2.2 Quản lý người sử dụng

Một người sử dụng trên hệ CMS bao gồm các thông tin như sau:

• Tên tắt người sử dụng.

• Tên đầy đủ người sử dụng.

• Mật mã người sử dụng.



• Ngôn ngữ yêu thích của người sử dụng.

• Các vai trò của người sử dụng trong hệ thống.

Một người quản lý người sử dụng có quyền thực hiện các thao tác sau:

• Thêm người sử dụng: khi một người quản lý người sử dụng thêm một

người sử dụng vào hệ thống, cần phải xác định các thông tin vừa nêu ở

trên.

• Xoá người sử dụng.

• Sửa đổi thông tin người sử dụng

Ngoài ra, người quản lý người sử dụng có quyền cho kích hoạt người sử dụng

hoặc ngăn cấm sự truy cập của người sử dụng vào hệ thống. Khi người sử dụng được

kích hoạt, người sử dụng có thể truy cập vào hệ CMS. Ngược lại, khi người sử dụng đã

bị ngăn cấm thì họ không được phép truy cập vào hệ thống.

2.3 Phân quyền sử dụng cho vai trò

Mỗi quyền sử dụng trên hệ thống chỉ có một phạm vi sử dụng trong một vùng

nhất định của hệ thống mà thôi. Trong hệ CMS của TMA, phạm vi sử dụng này bao

gồm các loại sau:

• Phạm vi trên web site: quyền sử dụng được thực hiện các thao tác trên

toàn bộ cấu trúc web site hoặc chỉ một phần của web site.

• Phạm vi người sử dụng: quyền sử dụng được thực hiện các thao tác trên

toàn bộ các người sử dụng của hệ thống hoặc chỉ một số người sử dụng

nhất định do hệ thống quy định.



• Phạm vi vai trò: quyền sử dụng được thực hiện các thao tác trên toàn bộ

các vai trò của hệ thống hoặc chỉ một số vai trò nhất định do hệ thống

quy định.

• Phạm vi cấu hình: quyền sử dụng được thực hiện các thao tác trên toàn

bộ các thông tin cấu hình của hệ thống hoặc chỉ một số thông tin cấu hình

nhất định do hệ thống quy định.

Các thao tác được thực hiện trên một phạm vi được mô tả như sau:

• Chỉ đọc: quyền sử dụng được gán thao tác này chỉ được cho phép đọc

trên các thông tin của hệ thống.

• Đọc và ghi: quyền sử dụng được gán thao tác này được cho phép đọc và

ghi trên các thông tin của hệ thống.

• Từ chối truy cập: người sử dụng được gán thao tác này sẽ không được

phép truy cập vào hệ thống.

Từ các loại phạm vi thao tác và các thao tác được phép trên phạm vi trình bày

phía trên, khi người quản lý cho phép hay thay đổi một vai trò, họ cần phải xác định

các thông tin tương ứng của vai trò.

2.4 Phân phối vai trò đến người sử dụng

Mỗi người sử dụng có thể sở hữu một hoặc nhiều vai trò trong hệ CMS.

Khi thêm người sử dụng mới vào hệ thống, người quản lý người sử dụng có thể

gán nhiều vai trò cho người sử dụng. Sau đó, người quản lý này có thể sửa đổi các vai

trò đã được gán trước đó hay thêm vào các vai trò mới cho người sử dụng.



2.5 Tối ưu hoá các thông tin cấu hình hệ thống

Hệ CMS này hỗ trợ tốt việc tối ưu hoá các thông tin cấu hình của hệ thống.

Các thông tin cấu hình chính có thể chỉnh sửa được trình bày dưới đây:

• Kiểu dữ liệu MIME. Ví dụ: phần mở rộng .html được áp dụng kiểu dữ

liệu MIME text/html. Các tập tin .js được áp dụng kiểu dữ liệu MIME

text/javascript và các tập tin .pdf được áp dụng kiểu dữ liệu MIME

application/pdf.

• Ngôn ngữ hiển thị.

• Thêm, xoá hay sửa đổi các tiêu đề trên menu.

• Vị trí của các tham số khởi tạo trang của người quản lý.

• Các giá trị mặc định khi trang web được tạo ra.

• Các template được hỗ trợ bởi hệ thống.

• Giao thức được sử dụng cho kết nối đến web site.

2.6 Biên soạn nội dung trang web

Sử dụng chức năng này của hệ CMS, người sử dụng có thể tạo ra các trang web.

Trong quá trình tạo ra các trang web này, người sử dụng có thể chọn các template cho

trang vừa tạo ra.

Trong quá trình biên soạn nội dung tran web, CMS cung cấp một môi trường

biên soạn tiện dụng WYSIWYG. Ngoài ra, trong quá trình này, họ có thể thêm vào các

hình ảnh cũng như là các đọan video để minh họa cho đoạn văn bản trên trang web.

Thêm vào đó, việc tạo ra các liên kết đến một tài liệu để download cũng được hỗ trợ.



Sau cùng, chức năng này cung cấp cơ chế cho phép xem lại và sửa đổi nội dung

vừa biên tập xong.

2.7 Áp dụng template vào trang web

Hệ CMS này cho phép tạo ra dễ dàng các template để áp dụng cho các trang

web. Người quản lý cấu hình hệ thống có thể tạo ra các template để những người biên

soạn nội dung có thể áp dụng các template này vào trang web họ vừa tạo ra.

2.8 Phân loại nội dung

Hệ thống CMS của TMA được xây dựng dựa trên chuẩn JSR 170, do đó hệ

thống này hỗ trợ rất tốt việc phân lọai nội dung. Người sử dụng có thể sắp xếp các

trang web tùy theo lọai của nó.

Các trang web được tổ chức trong một cấu trúc cây mà trong đó toàn bộ web

site là gốc của cây và mỗi loại là một node con của gốc đó.

2.9 Truy nhập vào hệ CMS

Do mã nguồn ban đầu của Magnolia được phát triển để hoạt động như một ứng

dụng độc lập, khi chúng ta muốn tích hợp mã nguồn này dưới dạng một portlet vào

portal hiện tại của công ty TMA, chúng ta cần phải bỏ qua cơ chế đăng nhập riêng của

Magnolia.

Để làm được điều này, khi người sử dụng đăng nhập vào hệ CMS, hệ thống này

sẽ lấy các thông tin người sử dụng được lưu trên portal, sau đó hệ thống này sẽ dựa

trên các thông tin vừa thu nhận được để cấp quyền tương ứng cho người sử dụng trong

hệ thống CMS.



2.10 Tìm kiếm nội dung

Hệ thống CMS này cung cấp cơ chế tìm kiếm thông tin giúp người sử dụng tìm

nội dung mình cần trên trang web.

Kết quả tìm kiếm được trình bày cùng với các liên kết đến các trang chứa nội

dung tìm được.

2.11 Lựa chọn ngôn ngữ

Chức năng này cho phép lựa chọn các ngôn ngữ khác nhau tùy thuộc vào từng

người sử dụng.

Trong hệ thống CMS của TMA, các ngôn ngữ sau đây được hỗ trợ: Pháp, Anh,

Trung Quốc, Đức, Ý, Nhật, Tây Ban Nha, Nga…



Chương 9 Tích hợp hệ thống CMS vào TMA portal



1. System Architecture của Magnolia CMS

1.1 Mô hình một số package quan trọng của Magnolia CMS

Hình 29: Các gói chính của Magnolia CMS

1.2 Mô tả các package

1.2.1 Package info.magnolia.cms

Package này chịu trách nhiệm xác nhận các yêu cầu từ phía người sử dụng và

thu thập các nội dung cần thiết để phản hồi yêu cầu.



Package này gọi đến các trang JSP hay servlet tương ứng để hồi đáp yêu cầu.

1.2.2 Package info.magnolia.cms. security

Quản lý các vấn đề về bảo mật trên Repository.

Cho phép khóa một thành phần tránh sự truy cập của người sử dụng.

Định nghĩa các phương thức dùng thao tác trên Repository, vai trò, người sử

dụng trong mỗi phiên làm việc.

1.2.3 Package info.magnolia.cms.servlets

Khởi tạo và đọc các thông tin cấu hình của ứng dụng từ Repository.

Chịu trách nhiệm xử lý và phản hồi các yêu cầu được gởi tới.

1.2.4 Package info.magnolia.cms.core

Thiết lập các thông số cấu hình cho Repository.

Thực hiện chức năng Cache khi có một yêu cầu được gởi đến. Có nghĩa là nếu

những thông tin dùng phản hồi yêu cầu đã được lưu trong Cache thì phản hồi ngay.

Nếu không thì lưu những thông tin của yêu cầu đó vào trong Cache.

Thực hiện chức năng tìm kiếm trên Repository.

Thêm, xoá, di chuyển nội dung các Page, Paragraphs hay các Properties.

Định nghĩa các phương thức hỗ trợ quản lý phiên bản.

1.2.5 Package info.magnolia.module.adminInterface



Cung cấp các lớp thể hiện Page, Paragraph, Dialog, Tree…

Định nghĩa các hằng số hỗ trợ đa ngôn ngữ.

1.2.6 Package info.magnolia.module.templating

Xác định và lưu lại các thông số về template của Paragraph, Page.

1.2.7 Package info.magnolia.repository

Package này cung cấp các phương thức cho các thao tác trên Repository

1.2.8 Package info.magnolia.exchange

Quản lý việc xuất bản nội dung từ bản author (dành cho người quản trị) san bản

public (trang web đã xuất bản). Bao gồm :

• Quản lý kết nối để truyền dữ liệu đến một URL cụ thể.

• Tạo nội dung để gởi đi.

• Activate, DeActivate nội dung.

2. Hướng tiếp cận để tích hợp

Để tích hợp Magnolia CMS dưới dạng một portlet vào portal hiện tại của TMA,

chúng ta có 2 cách tiếp cận như sau

2.1 Hướng tiếp cận thứ 1

Trong cách tiếp cận này, trước tiên chúng ta sử dụng mã nguồn của Liferay

portal để tạo ra một dự án J2EE. Sau đó, chúng ta đưa mã nguồn của Magnolia vào



trong dự án này. Các thành phần của Magnolia được đưa vào các thư mục tương ứng

của dự án J2EE này.

Tiếp theo, chúng ta sửa đổi dự án J2EE để đáp ứng được nhu cầu đề ra ban đầu.

Cuối cùng. Chúng ta biên dịch toàn bộ dự án này để tạo ra một gói ext.ear duy nhất. Và

chúng ta sẽ đưa gói vừa biên dịch xong vào thư mục

JBOSS_HOME/server/default/deploy của application server JBoss

(http://www.jboss.org) để chạy portal và portlet vừa được biên dịch.

Tuy nhiên, cách làm này tồn tại rất nhiều giới hạn mà trong đó, việc quản lý mã

nguồn là khó khăn lớn nhất. Thật vậy, nếu tiếp cận theo hướng này, khi muốn tích hợp

một portlet mới vào portal, chúng ta cần phải đưa toàn bộ các thành phần của portlet

vào từng thư mục tương ứng của dự án J2EE. Do đó, trong quá trình phát triển dự án,

chúng ta cần phải nhớ các package nào tương ứng với portlet và các package nào thì

không phải. Ngoài ra, khi xảy ra lỗi, chúng ta rất khó sửa chữa các lỗi này do mã

nguồn trong dự án J2EE này khá nhiều. Khó khăn này càng gia tăng khi chúng ta muốn

mở rộng các chức năng của portal và phát triển nhiều portlet hơn cho portal.

Trong thực tế, các lập trình viên của nhóm TIS trong công ty TMA đã từng tiếp

cận theo cách này và họ đã gặp phải vấn đề tương tự. Hiện nay, họ đã chuyển sang

hướng tiếp cận thứ 2 được trình bày dưới đây.

2.2 Hướng tiếp cận thứ 2

Trong hướng tiếp cận này, chúng ta cũng tạo ra một dự án J2EE. Tuy nhiên,

chúng ta chỉ đưa và mã nguồn của Magnolia CMS vào trong dự án mà thôi.

Tiếp theo, chúng ta sửa đổi mã nguồn của Magnolia CMS và mã nguồn của

portal để đáp ứng yêu cầu đặt ra ban đầu.



Sau đó, gói ext.ear của Liferay portal vào trong thư mục

JBOSS_HOME/server/default/deploy của application server JBoss.

Cuối cùng, chúng ta biên dịch dự án J2EE để nhận được một gói magnolia.war

và đưa package này vào thư mục JBOSS_HOME/server/default/deploy của application

server JBoss để chạy.

Trong thực tế, cách tiếp cận này có thể tránh được những khó khăn mà cách tiếp

cận thứ 1 gặp phải. Do đó, chúng tôi sẽ tích hợp hệ CMS vào portal hiện tại của công

ty TMA theo cách này.

3. Cách thức thực hiện

Để thực hiện theo cách tiếp cận thứ 2 vừa nêu trên, chúng ta cần phải thực hiện

các bước chính sau :

• Tạo ra một dự án J2EE dựa trên mã nguồn của Magnolia CMS

• Chuẩn hoá dự án J2EE này theo chuẩn JSR 168

• Tích hợp hệ thống bảo mật của Magnolia vào hệ thống bảo mật của

portal hiện tại của TMA : nguyên nhân là Magnolia CMS được xây dựng

để hoạt động như một ứng dụng độc lập, do đó, hệ CMS này có hệ thống

bảo mật riêng của nó. Ngoài ra, portal của TMA cũng có hệ thống bảo

mật riêng của portal. Do đó, khi người sử dụng muốn sử dụng hệ CMS

này thì họ cần phải đăng nhập đến 2 lần : 1 lần để được phép vào portal

và 1 lần nữa để được phép vào hệ CMS. Mà trong portal thì phải hỗ trợ

cơ chế single sign-on, cơ chế cho phép người sử dụng chỉ phải đăng nhập

1 lần vào portal để có thể sử dụng mọi chức năng của portal. Do đó, để



tích hợp Magnolia CMS vào portal hiện tại, chúng ta cần phải kết hợp 2

hệ thống bảo mật này để chỉ phải đăng nhập 1 lần duy nhất mà thôi.

3.1 Tạo dự án J2EE dựa trên mã nguồn của Magnolia

Trước tiên, chúng ta sử dụng Eclipse để tạo một dự án J2EE (trong báo cáo này,

chúng tôi xin phép không trình bày các bước để tạo một dự án J2EE trong Eclipse).

Sau đó, chúng ta đưa toàn bộ mã nguồn của Magnolia vào trong dự án này.

Sau cùng, chúng ta cần phải đưa các thư viện (các tập tin .jar và .class) cần thiết

vào trong dự án.

3.2 Chuẩn hoá dự án J2EE theo chuẩn JSR 168

Sau quá trình tìm hiểu chuẩn JSR 168, chúng ta nhận thấy cần phải sửa đổi dự

án J2EE này để tuân thủ theo chuẩn JSR 168. Có nghĩa là ngoài các thư mục và tập tin

của dự án J2EE, chúng ta cần phải sắp xếp lại các thành phần của dự án và sửa đổi tập

tin build.xml (tập tin sử dụng ngôn ngữ kịch bản ant (http://apache.org/) để hỗ trợ

Eclipse trong việc biên dịch dự án) để tạo ra gói magnolia.war có cấu trúc như sau :

magnolia.war

|------- html (thư mục chứa các tập tin JSP)

|------- WEB-INF

|------- tld (thư mục chứa thư viện các thẻ)

|------- classes

|------- config

|------- portlet.xml



|------- liferay-portlet.xml

|------- liferay-display.xml

|------- web.xml

Hình vẽ sau sẽ minh hoạ cấu trúc tổ chức này trong dự án được tạo ra trên

Eclipse

Hình 30: Cấu trúc dự án J2EE của hệ CMS

Trong cấu trúc này, tập tin portlet.xml có nội dung như sau :



<portlet>

<portlet-name>magnolia_id</portlet-name>

<display-name>magnolia</display-name>

<portlet-class>com.liferay.portlet.JSPPortlet</portlet-class>

<init-param>

<name>view-jsp</name>

<value>/index.jsp</value>

</init-param>

<expiration-cache>0</expiration-cache>

<supports>

<mime-type>text/html</mime-type>

</supports>

<portlet-info>

<title>magnolia</title>

<short-title>magnolia</short-title>

<keywords>magnolia</keywords>

</portlet-info>

<security-role-ref>

<role-name>Guest</role-name>

</security-role-ref>

<security-role-ref>

<role-name>Power User</role-name>


<security-role-ref>

<role-name>User</role-name>


</portlet>



Tập tin liferay-portlet.xml có nội dung như sau :

<portlets>

<portlet id=“magnolia_id” struts-path=“magnolia” use-default-

template=“true” />

</portlets>

Ngoài ra, nội dung của tập tin liferay-display.xml như sau :

<display>

<category name=“category.cms”>

<portlet id=“magnolia_id” />

</category>

</display>

Sau cùng, nội dung của tập tin web.xml như sau:

<context-param>

<param-name>company_id</param-name>

<param-value>liferay.com</param-value>

</context-param>

<listener>

<listener-class>

com.liferay.portal.servlet.PortletContextListener

</listener-class>

</listener>



.......

<taglib>

<taglib-uri>http://java.sun.com/portlet</taglib-uri>

<taglib-location>/WEB-INF/tld/liferay-portlet.tld</taglib-location>

</taglib>

3.3 Tích hợp hệ thống bảo mật

Sau khi tìm hiểu kiến trúc hệ thống của portal hiện tại và kiến trúc hệ thống của

Magnolia CMS, chúng ta nhận thấy rằng để tích hợp hệ thống bảo mật của Magnolia

vào hệ thống bảo mật của portal, chúng ta cần phải thực hiện các sửa đổi chủ yếu trên

package info.magnolia.cms.security của Magnolia CMS. các package khác của

Magnolia CMS cũng cần được sửa đổi, như : info.magnolia.logging,

info.magnolia.module.adminInterface, info.magnolia.cms.servlets… Ngoài ra, chúng ta

cũng cần phải sửa đổi các tập tin JSP sử dụng các chức năng của các package vừa nêu

và chuẩn hóa các trang JSP theo chuẩn JSR 168.

Tiếp theo, chúng ta sử dụng các APIs được cung cấp bởi các lớp của portal,

như : CompanyLocalManagerUtil, UserManagerUtil, PrincipalBean, …để lấy các

thông tin người sử dụng được cung cấp bởi họ khi đăng nhập vào portal. Các thông tin

này được sử dụng để đăng nhập vào CMS thay vì sử dụng các thông tin đăng nhập

được lấy lên từ Repository của Magnolia CMS.



KẾT LUẬN



Qua đề tài này, chúng tôi có thêm nhiều kiến thức và kinh nghiệm trong việc

phát triển một hệ CMS và tích hợp một thành phần vào một hệ thống thông tin có sẵn.

Ngoài ra, chúng tôi còn có thêm kinh nghiệm trong việc xây dựng các hệ CMS

dưới dạng một thành phần hay một ứng dụng độc lập. Các hệ thống này có thể ứng

dụng vào các doanh nghiệp hay các tổ chức có nhu cầu, đặc biệt là các toà soạn báo

điện tử.

Sau 6 tháng thực tập tại công ty TMA, chúng tôi học hỏi thêm nhiều kinh

nghiệm thực tế trong một môi trường làm việc chuyên nghiệp và đầy năng động.

Thêm vào đó, chúng tôi có cơ hội nâng cao khả năng nghiên cứu và ứng dụng các kiến

thức nghiên cứu được vào trong thực tế. Chúng tôi hiểu rõ hơn về các mặt mạnh và các

giới hạn của việc sử dụng các công cụ mã nguồn mở và miễn phí, như : Linux, Eclipse,

JBoss, Lomboz, J2SDK, MySQL, Liferay, Magnolia…

Về cơ bản luận văn đã thực hiện tốt các yêu cầu đề ra ban đầu của công ty .

• Xây dựng thành công hệ CMS dưới dạng một portlet để tích hợp vào

portal hiện tại của công ty TMA.

• Tích hợp hệ thống bảo mật của CMS vào hệ thống bảo mật của TMA

portal.

• Hệ CMS được xây dựng được sử dụng như làm một nơi chứa nội dung

tập trung của các trang web trong các module của hệ thống Intranet.

• Hệ CMS được xây dựng dưới dạng một module để có thể dược sử dụng

bởi các module khác trong hệ thống Intranet của công ty.



Tuy nhiên do giới hạn về thời gian và hiểu biết, chúng tôi xây dựng hệ thống

CMS này vẫn còn một số điểm giới hạn và cần được cải thiện trong các phiên bản tiếp

theo.

• Hệ thống CMS lưu trữ dữ liệu trong hệ thống tập tin của hệ điều hành.

Điều này tạo nhiều bất tiện khi dữ liệu lưu trữ của hệ thống ngày một

tăng lên.

• Chưa có thời gian thử nghiệm module CMS với các module khác trong

hệ thống Intranet của Công ty.



HƯỚNG PHÁT TRIỂN



Như đã trình bày ở trên, module CMS lưu trữ dữ liệu trong hệ thống tập tin của

hệ điều hành. Để hệ thống họat động hiệu quả hơn, nó cần được chuyển sang lưu trữ dữ

liệu bằng một cơ sở dữ liệu quan hệ.

Hệ thống bảo của module CMS cần được tiếp tục phát triển để có thể tự động

cập nhật người sử dụng khi những người sử dụng trong hệ thống Intranet có sự thay

đổi.

Hệ thống cần được phát triển thêm chức năng lưu các phiên bản của nội dung

(điều này được hỗ trợ mạnh bởi chuẩn JSR 170) giúp cho nội dung các trang web có

thể được phục hồi lại các trạng thái trước đó của nó.

Bên cạnh đó, với qui mô ngày càng mở rộng của Công ty, module CMS cần

được phát triển thêm các tính năng khác như hỗ trợ chuẩn RSS để giao tiếp với các

web site khác.

Ngoài các yêu cầu về xử lý, module CMS còn cần được phát triển để linh động

hơn trong việc tạo ra các template cho trang web.



TÀI LIỆU THAM KHẢO



[1] David Nuescheler - Day Software, Content Repository API for Java

Technology Specifications 0.16.2, Day Management AG, 25 January 2005

[2] Alejandro Abdelnur - Sun Microsystems, Java portlet Specification v1.0,

Sun Microsystems, 29 August 2003

[3] Steve Holzner, Eclipse Cookbook, O'Reilly, United States of America, 2004

[4] James Rumbaugh, Ivar Jacobson, Grandy Booch, The Unified Modeling

Language Reference Manual, Addison-Wesley, 1998.

[5] Nathan Meyers, Java Programming on Linux, Waite Group, 2000

[6] James Goodwill, Pure JSP: Java Server Pages, SAMS, 2000

[7] Mark Wutka, Special Edition Using Java Server Pages and servlets, QUE,

2000

[8] Jason Hunter and William Crawford, Java servlet Programming, O'Reilly,

United States of America, October 1998

[9] Michael Girdley and Kathryn A.Jones, web Programming with Java,

Sams.net Publishing, 1996

[10] Le Thanh Nhan – Tuong Minh Association, Technical reports, 2004 - 2005

[11] Nguyen Thanh Giang – Tuong Minh Association, Technical reports, 2004 -

2005

[12] Web site cuả Magnolia CMS, http://www.magnolia.info/en/magnolia.html

[13] Web site mã nguồn mở Java, http://java-source.net

[14] Web site các giải pháp CMS mã nguồn mở, http://opensourcecms.com

Documents

Xd cms module cho hệ thống intranet của cty tma