đồ án công nghệ thông tin Mô hình kiến trúc tối ưu để xây dựng ứng dụng Portal

Corporate portal thường được dùng bởi các nhân viên trong một cơ quan hay tổ chức sử dụng để chia sẻ thông tin với nhau, cộng tác với nhau để cùng giải quyết một côngviệc, qua đó nâng ca

Mục lục

Mục lục 1

Lời cảm ơn 3

Lời nói đầu 4

Chương I: Giới thiệu cổng giao tiếp điện tử 5

1 Định nghĩa 5

2 Lịch sử phát triển 5

3 Phân loại Portal 6

4 Thuộc tính cơ bản của Portal 7

5 Chức năng của Portal 8

6 Kiến trúc của Portal 9

7 Các mô hình phát triển 12

Chương II: Tìm hiểu về Portlet 21

1 Định nghĩa 21

2 Định dạng chung của một Portlet 21

3 Giới thiệu về chuẩn JSR 168 23

3.1 Những nền tảng chung của Portlet 23

3.2 Định nghĩa 24

3.3 Portlets và Servlets ……… ……… 24

3.4 Những tương tác trong Portal 25

3.4.1 Portlet Interface và lớp GenericPortlet 26

3.4.2 Vòng đời của Portlet 27

3.4.3 Các trạng thái thực thi Portlet 27

3.4.4 Quản lý yêu cầu Portlet 28

3.5 Các yếu tố khác của Java Portlet API 34

3.5.1 PortletConfig 34

3.5.2 PortletURL 35

3.5.3 Các chế độ của Portlet 36

3.5.4 Các cửa sổ trạng thái 37

3.5.5 Ngữ cảnh của Portlet 38

3.5.6 Ngữ cảnh của Portal 38

3.5.7 Các tham chiếu Portlet 38

3.5.8 Phiên làm việc 39

3.5.9 JSPs và Servlet 40

3.5.10 Cấu tạo ứng dụng Portlet 44

4 Phát triển ứng dụng và Workflow cho Portal 44

4.1 Kiến trúc Portlet 45

Chương III: Mô hình kiến trúc tối ưu để xây dựng ứng dụng Portal 48

1 Giới thiệu qua về các mô hình phát triển Web thông dụng hiện nay 48 1.1 Mô hình tổng quan trong phát triển Web 48

1.2 Mô hình JSP 49

1.3 Mô hình MVC 50

1.3.1 Định nghĩa 51

1.3.2 Mô hình JSP Model 2 architecture ……… …….51

2 Đặc điểm của các ứng dụng chạy trên nền Portal (Portlet) 52

2.1 Mô hình hoạt động của Portlet 52

2.2 Các yêu cầu đặt ra đối với ứng dụng Portlet ………….……….53

2.2.1 Tính độc lập với các Portal Engine …… ……….… 53

2.2.2 Hệ thống phải hoạt động được với các hệ quản trị cơ sở dữ liệu khác nhau……… ……….53

3 Mô hình truy xuất cơ sở dữ liệu……… ………….… 53

3.1 Mô hình truy xuất cơ sở dữ liệu theo kiểu truyền thống……….53

3.2 Mô hình truy xuất dữ liệu sử dụng Hibernate Framework…… 54

3.2.1 Sơ lược về Hibernate Framework……….……… 54

3.2.2 Đề xuất mô hình truy xuất cơ sở dữ liệu……… 53

3.3 Các yêu cầu đối với mô hình kiến trúc……… 56

3.4 Lựa chọn mô hình kiến trúc tối ưu ……….………… … 56

Kết luận 59

Tài liệu tham khảo 60

Lời cảm ơn

Trong suốt quá trình học tại trường Đại học Dân lập Hải Phòng, em đãđược các thầy cô hướng dẫn và truyền đạt những kiến thức chuyên môn cầnthiết Ngoài ra, em còn được làm việc nghiêm túc, tích cực trên tinh thần độc lậpsáng tạo Đây là những kinh nghiệm quý báu trước khi bắt tay vào làm việc trongtương lai

Thời gian làm luận văn vừa qua là cơ hội để em có thể áp dụng những kiếnthức mà trong suốt 4 năm qua em đã được học tập, cùng với sự hướng dẫn tậntình của thầy Trần Minh và thầy Nguyễn Hoài Thu cùng các thầy các cô trongtrường, em đã hoàn thành tốt đề tài tốt nghiệp của mình

Một lần nữa, em xin chân thành cảm ơn các thầy các cô Kính chúc thầy

cô cùng gia đình mạnh khỏe, hạnh phúc, chúc thầy cô tiếp tục đạt được nhữngthành công mới trong sự nghiệp giảng dạy và nghiên cứu khoa học

Em xin chân thành cảm ơn !

Sinh viên Nguyễn Thị Mai

Lời nói đầu

Chúng ta đã biết, website đã và đang đóng góp rất lớn vào việc phổ cậpthông tin, như giới thiệu tin tức, các cơ sở dữ liệu, và một số chương trình ứngdụng trên mạng, đã làm thay đổi cả thế giới từ khi xuất hiện vào đầu những năm

90 của thế kỷ trước Ngày nay, mọi giao tiếp thông qua website đã trở thành phổbiến Tuy nhiên chúng ta có thể mạnh dạn gọi một số lớn các website là “websitetruyền thống” bởi những mặt tồn tại do công nghệ cũ để lại như: sự quá tải thôngtin; thông tin không được phân lọai; khó khăn trong việc duy trì bảo quản; khótích hợp thông tin, dịch vụ; không có khả năng cung cấp một nền tảng để có thểphát triển và mở rộng

Công nghệ Portal (Cổng điện tử) phát triển sau thời kỳ này khoảng 7-8năm như một tất yếu xuất phát từ nhu cầu thực tế Portal là một bước tiến hóacủa website truyền thống Nó ra đời để giải quyết những vấn đề mà websitetruyền thống gặp phải

Là “siêu website”, gọi đầy đủ là Portal Website, gọi tắt là Portal, đối vớingười dùng vẫn chỉ là trang web qua browser

Là đích quy tụ hầu hết các thông tin và dịch vụ cho người sử dụng cần.Thông tin và dịch vụ được phân loại nhằm thuận tiện cho tìm kiếm và vùi lấp cácthông tin

Bảo toàn đầu tư lâu dài Có nền tảng công nghệ đảm bảo

Môi trường chủ động dùng cho việc tích hợp ứng dụng

Sự ra đời và phát triển của Portal đã dẫn tới sự phát triển tất yếu của cácchuẩn được sử dụng hoạt động trên nền Portal, đó là các chuẩn Ichannel, Portlet, và giới thiệu về chuẩn Portlet JSR 168 của Java Community

Chương I: Giới thiệu cổng giao tiếp điện tử

1 Định nghĩa

Cổng giao tiếp điện tử - Portal: Là một khái niệm thường được nhắc đến

nhiều trong những năm gần đây của thị trường tin học Bởi vì phạm vi áp dụngcủa Portal là rất rộng, bao gồm các hệ thống bên trong (internal), bên ngoài(external), đằng sau bức tường lửa và nằm rải rác khắp nơi trên internet, do vậykhó có được định nghĩa hoàn chỉnh và chính xác về Portal Một cách chung nhất,

có thể tạm định nghĩa portal như sau:

Portal là một phần mềm ứng dụng cung cấp một giao diện mang tính cá nhân hóa cho người sử dụng Thông qua giao diện này, người dùng có thể khám phá, tìm kiếm, giao tiếp với các ứng dụng, với các thông tin, và với những người khác.

Sự ra đời và phát triển của portal đã dẫn tới sự phát triển tất yếu của các chuẩn được sử dụng để xây dựng các ứng dụng hoạt động trên nền Portal, đó làchuẩn Ichannel, Portlet ,

2 Lịch sử phát triển

Website đã và đang đóng góp rất lớn vào việc phổ cập thông tin, như giớithiệu tin tức, các cơ sở dữ liệu, và một số chương trình ứng dụng trên mạng, đãlàm thay đổi cả thế giới từ khi xuất hiện vào đầu những năm 90 của thế kỷ trước.Ngày nay mọi giao dịch thông qua web đã trở nên phổ biến

Công nghệ Portal (Cổng điện tử) phát triển sau thời kỳ này khoảng 7-8năm như là một tất yếu xuất phát từ nhu cầu thực tế Portal là một bước tiến hóacủa web truyền thống Nó ra đời để giải quyết những vấn đề mà website truyềnthống gặp phải

- Portal (cổng giao tiếp điện tử) là một bước tiến hóa của website truyềnthống

- Là “siêu website”, gọi đầy đủ là Portal Website, gọi tắt là Portal, đốivới người dùng vẫn chỉ là sử dụng trang web thông qua trình duyệt (tức

là web browser), nhưng đằng sau nó là sự thay đổi thuật ngữ và quanniệm mới về triết lý phục vụ thay cho cách hiểu “tuyên truyền“ thôngqua website như trước đây

- Là điểm đích quy tụ hầu hết các thông tin và dịch vụ cho người sửdụng cần, là điểm đích đến thực sự Thông tin và dịch vụ được phânloại nhằm thuận tiện cho tìm kiếm và hạn chế vùi lấp các thông tin.

- Bảo toàn đầu tư lâu dài Có nền tảng công nghệ đảm bảo, do côngInternet đã phát triển rất cao so với thời kỳ xuất hiện Word Wide Webvào đầu những năm 90 của thế kỷ trước Những công nghệ tạo nên thờiđại portal đều hỗ trợ tính mở và kế thừa rất mạnh, sao cho việc mởrộng quy mô phục vụ bằng các phần mềm ứng dụng mới được “lắprắp” vào Portal đang có mà không phải hủy bỏ hoặc sửa chữa lớn nhưnhững website trước đây

- Môi trường chủ động dùng cho việc tích hợp ứng dụng

- Xu hướng “tiến hóa” chung của website theo hướng tiến đến Portalđược trình bày trong hình vẽ:

q Nhiều loại User

q Tập trung vào nền công

trong các cơ quan

q Chuẩn và tương tác được

(Standard and Interoperability)

Phát triển của Portal

Hình 1.1: Lịch sử phát triển của Portal

3 Phân loại Portal

Sau đây là một vài kiểu điển hình của Portal

- Vertical portal Thuật ngữ này được sử dụng để chỉ những Portal mà

nội dung thông tin cùng các dịch vụ của nó được thiết kế để phục vụcho một lĩnh vực xác định, cho một chuyên ngành xác định, do vậykhách hàng của nó là diện hẹp Theo đánh giá, hiện nay trên thế giới,Vertical portal là loại hình Portal có tốc độ phát triển nhanh nhất

- Horizontal portal Thuật ngữ này được sử dụng để chỉ những Portal mà

nội dung thông tin cùng các dịch vụ của nó bao trùm nhiều chủ đề,

nhiều lĩnh vực, do vậy nó mang tính diện rộng, phục vụ cho nhiều loạikhách hàng khác nhau Các Portal nổi tiếng như Yahoo, NetCenter,Altavista, .

- Information portal Xây dựng hệ thống cung cấp thông tin trên cơ sở

thu gom số liệu từ nhiều nguồn khác nhau Các nguồn dữ liệu này nằmrải rác trên mạng toàn cầu Internet, từ các CSDL của các mạng nội bộIntranet, và thậm chí cả từ các Portal khác

- Community portal Xây dựng “một vị trí ảo” trên Internet cho các cá

nhân, các doanh nghiệp “tụ tập” để giúp đỡ lẫn nhau và để hợp tác vớinhau trong cùng một mục đích xác định Community portal mang lại

cơ hội cộng tác cho các cá nhân, tổ chức doanh nghiệp mà ranh giới địa

lý không có ý nghĩa ở đây

- Corporate portal (or Enterprise portal) Corporate portal thường được

dùng bởi các nhân viên trong một cơ quan hay tổ chức sử dụng để chia

sẻ thông tin với nhau, cộng tác với nhau để cùng giải quyết một côngviệc, qua đó nâng cao năng suất lao động và hiệu quả giải quyết côngviệc của mình

- Commercial portal Cung cấp “chợ điện tử” (e-mail) trong thị trường

thương mại điện tử

- Goverment portal Cung cấp các “cổng hành chính công điện tử” để

chính quyền (Trung ương và địa phương) thực hiện các chức năng củamình đối với dân chúng thông qua việc cung cấp thông tin và các dịch

vụ hành chính công

4 Thuộc tính cơ bản của Portal

- Cá nhân hóa giao diện người sử dụng (Personalization)

- Tổ chức phân loại thông tin (Categoize)

- Hỗ trợ khả năng tìm kiếm nhanh thông tin (Search)

- Thông tin được tích hợp từ nhiều nguồn khác nhau (Intergration)

- Hỗ trợ mô hình làm việc cộng tác (Collaboration)

- Hỗ trợ mô hình tự động xử lý công việc theo quy trình đã xác định từtrước (Workflow)

- Khả năng bảo mật cao, hỗ trợ đăng nhập hệ thống một lần duy nhất(Single-Sign-On)

5 Chức năng của Portal

- Khả năng cá nhân hóa (Customization hay Personalization) :

Cho phép thiết đặt các thông tin khác nhau cho các loại đối tượng sử dụngkhác nhau theo yêu cầu Tính năng này dựa trên hoạt động thu thập thông tin vềngười dùng và cộng đồng người dùng, từ đó cung cấp các thông tin chính xác tạithời điểm được yêu cầu

- Tích hợp và liên kết nhiều loại thông tin (Content aggregation):

Cho phép xây dựng nội dung thông tin từ nhiều nguồn khác nhau chonhiều đối tượng sử dụng Sự khác biệt giữa các nội dung thông tin sẽ được xácđịnh qua các ngữ cảnh của người dùng

- Xuất bản thông tin (Content syndication):

Thu thập thông tin từ nhiều nguồn khác nhau, cung cấp cho người dùngthông qua các phương pháp hoặc giao thức (protocol) một cách thích hợp Một

hệ thống thông tin chuyên nghiệp phải có khả năng xuất bản thông tin với cácđịnh dạng quy chuẩn

- Hỗ trợ nhiều môi trường hiển thị thông tin (Multidevice support):

Cho phép hiển thị cùng một nội dung thông tin trên nhiều loại thiết bị khácnhau như: màn hình máy tính (PC), thiết bị di động (Mobile phone, PDA ) sửdụng để in hay cho bản fax một cách tự động bằng cách xác định thiết bị hiểnthị thông qua các thuộc tính khác nhau

- Khả năng đăng nhập một lần (Single Sign On):

Cho phép dịch vụ xuất bản thông tin hoặc các dịch vụ khác của portal lấythông tin về người dùng khi hoạt động mà không phải yêu cầu người dùng đăngnhập lại mỗi khi yêu cầu Đây là một tính năng rất quan trọng vì các ứng dụng vàdịch vụ trong portal sẽ phát triển một cách nhanh chóng khi xuất hiện nhu cầu,

mà các ứng dụng và dịch vụ này tất yếu sẽ có nhu cầu về xác thực hoặc truy xuấtthông tin người dùng

- Quản trị portal (Portal administration):

Xác định cách thức hiển thị thông tin cho người dùng cuối Tính năng nàykhông chỉ đơn giản là thiết lập các giao diện người dùng với các chi tiết đồ họa(look-and-feel), với tính năng này người quản trị phải định nghĩa được các thànhphần thông tin, các kênh tương tác với người sử dụng cuối, định nghĩa nhómngười dùng cùng với các quyền truy cập và sử dụng thông tin khác nhau

- Quản trị người dùng (Portal user management):

Cung cấp các khả năng quản trị người dùng cuối, tùy thuộc vào đối tượng

sử dụng của portal Tại đây, người sử dụng có thể tự đăng ký trở thành thànhviên tại một công thông tin công cộng (như Yahoo, MSN .)hoặc được ngườiquản trị tạo lập và gán quyền sử dụng tương ứng đối với các công thông tindoanh nghiêp Mặt khác, tùy thuộc vào từng kiểu Portal mà số lượng thành viên

có thể từ vài nghìn tới hàng triệu Hiện tại phương pháp phân quyền sử dụng dựatrên vai trò (Role-based security) được sử dụng như một tiêu chuẩn trong cáchoạt động xác định quyền truy cập và cung cấp thông tin cho các đối tượng khácnhau trong các Portal cũng như các ứng dụng web

6 Kiến trúc của Portal

Intergated Database

Portlets/

Channels

Public &

Subscribe

Hình 1.2: Mô hình kiến trúc Portal

Được xây dựng dựa trên mô hình Web ba tầng (Web Application 3-tier):tầng trình diễn (Client), tầng ứng dụng (Portal Server) và tầng cơ sở dữ liệu(Enterprise Resources)

6.1 Tầng trình diễn (Client):

Người dùng có nhiều lựa chọn về nền trình diễn (Internet, Mobile,PDA, ).Hệ thống sẽ tự động gọi các tệp cấu hình sẵn cho tầng nền thông qualớp Presentation Services.Tầng trình diễn chịu trách nhiệm về cung cấp giao diệncho nhiều loại người dùng khác nhau, có nhiệm vụ lấy các yêu cầu, dữ liệu từngười dùng, có thể định dạng nó theo những qui tắc đơn giản (dùng các ngônngữ Script) và gọi các thành phần thích hợp từ tầng Business Logic để xử lý cácyêu cầu Kết quả sau xử lý được trả lại cho người dùng

6.2 Tầng ứng dụng (Portal Server):

Là môi trường hoạt động và là nơi chứa các ứng dụng của Cổng giao tiếpđiện tử Là đầu mối tiếp nhận và xử lý yêu cầu của người dùng đầu cuối, phântích, tiền xử lý yêu cầu và chuyển yêu cầu đã xử lý cho phần ứng dụng tươngứng xử lý Tầng này bao gồm 3 thành phần chính: dịch vụ phục vụ trình diễn,phần ứng dụng, kiến trúc hạ tầng

- Dịch vụ phục vụ trình diễn (Persentation Services): Đảm nhận nhiệm

vụ đón các yêu cầu từ tầng trình diễn (yêu cầu phía client) và trả về kết quả chophía client Đồng thời có nhiệm vụ thực thi các thành phần điều khiển trình diễncủa ứng dụng chủ cũng như thực thi các modules giao tiếp với các Server khác(Email, LDAP server)

- Phần ứng dụng (Bussiness Logic): Thực hiện các quy trình xử lý

nghiệp vụ và điều khiển Phần này bao gồm tập các API để thực hiện các luồngcông việc, tập các API dùng để tạo ra các dữ liệu và sau đó thông quaPresentation Services xuất ra XHTML, HTML, WML, … tùy theo nền trình diễn

mà phía client yêu cầu Phần này bao gồm các khối chức năng chính sau:

+ Khối bảo mật (Sercurity & SSO – Single Sign-On): Khối này bao gồm

các chức năng cơ bản liên quan đến việc đăng ký, quản lý tài khoản (tạomới, sửa đổi, xóa, ) của người sử dụng hoặc nhóm người sử dụng, phânquyền cho người dùng hoặc nhóm người dùng truy cập tới tài nguyên vàdịch vụ của hệ thống Với quan điểm thông tin và dịch vụ chỉ được truynhập bởi người dùng hợp lệ, Portal cần thiết duy trì hệ thống kiểm tra vàxác thực người dùng truy cập Thêm nữa để tránh cho người dùng phảinhớ quá nhiều tên và mật khẩu khi truy nhập tài nguyên của mình, Portalcũng được cài đặt khả năng xác thực một cửa theo đó người sử dụng (đã

được đăng ký và có tài khoản) chỉ cần đăng nhập một lần, nhưng có thểtruy cập tới thông tin và dịch vụ (theo quyền truy cập) có trên Portal.

+ Cá nhân hóa người dùng (Personalization): Một trong những đặc tính

của Portal là khả năng cá nhân hóa Một người dùng sau khi đăng nhậpvào hệ thống thì có thể tự thay đổi giao diện trình bày như bố cục và giaodiện trình bày, thành phần thông tin hiển thị, …

+ Khối tổ chức, quản lý và tìm kiếm nội dung thông tin (Search & Categorize): Để giảm thiểu tình trạng quá tải thông tin của người sử dụng,

thông tin cần được quản lý bởi Portal phải được phân loại và sắp xếp theocác chủ đề (topics, subtopics, ) sao cho người dùng có thể nhanh chóngtìm thấy thông tin mà mình cần Trong mục quản lý nội dung còn có cácchức năng xuất bản thông tin bao gồm các bước tạo, phê duyệt và xuất bảnthông tin, nhưng do vai trò quan trọng của khối này nên đã tách riêng

+ Khối xuất bản thông tin (Publish & Subscribe): Khối này cung cấp các

chức năng cơ bản thể hiện qui trình xuất bản thông tin với sự tham gia củacác bộ phận khác nhau như: tạo lập, biên tập nội dung bằng một hệ soạnthảo văn bản, và phê duyệt xuất bản

+ Khối tích hợp ứng dụng (Intergration): Cung cấp các giao thức chuẩn,

mà thông qua đó các ứng dụng được tích hợp vào Portal, hoặc tạo lập cácmối liên kết (links) với các trang thông tin điện tử/website khác

+ Khối mô hình làm việc cộng tác (Collaboration): Khối này cung cấp và

thực hiện quản lý các phần mềm công cụ nhằm tăng cường khả năng traođổi thông tin 2 chiều giữa các thành viên của Portal, giữa thành viên vàngười quản trị Poral trong quá trình xử lý công việc

+ Khối mô hình xử lí công việc theo qui trình định trước (Applications & Workflow): Khối này cho phép xây dựng nên các quy trình xử lý công việc

theo các bước định trước, và áp dụng các quy trình này vào xử lý các côngviệc một cách tự động

+ Khối ứng dựng xây dựng (Portlets/Channels): Là khối bao gồm các

ứng dựng xây dựng theo các chuẩn Portlets và Channels là những chuẩnứng dụng Portal hỗ trợ để thực hiện những chức năng cụ thể, riêng biệt

- Kiến trúc hạ tầng (Portal Infrastructure): Là những kiến trúc bên dưới

giúp cho Portal giao tiếp với tầng Cơ sở dữ liệu, các ứng dụng bên ngoài Portal

và với người dùng khác

6.3 Tầng cơ sở dữ liệu (Enterprise Reources):

Bao gồm các hệ thống CSDL lưu trữ dữ liệu chính của Portal, CSDLchuyên nghành và CSDL tích hợp sẵn sàng phục vụ cho các hoạt động truy cập,

xử lý, kiết xuất và trình diễn thông tin ở các tầng trên

- CSDL Portal (Portal Database): gồm hệ thống CSDL chính của Portal

phục vụ lưu trữ các thông tin dữ liệu về cấu hình, các tham số của hệ thống, dữliệu người dùng, dữ liệu bản tin, các thông tin, dữ liệu phục vụ điều hành,… CácCSDL này được liên thông với nhau và tạo thành một hệ thống phục vụ điềuhành, quản lý Portal

- CSDL ứng dụng (Structured & Unstructured Database): là hệ thống

các CSDL phục vụ quản lý một lĩnh vực hoặc đối tượng đặc thù của từng Đơn vị

sử dụng hệ thống Portal Đây cũng chính là hệ thống CSDL chung phục vụ mộtngành dọc liên quan đến Đơn vị đó Khi có yêu cầu, hệ thống sẵn sàng cho việckết xuất và tổng hợp thông tin để cung cấp cho Portal

- CSDL tích hợp (Intergrated Database): Đây là hệ CSDL của Portal và

các hệ thống khác cần liên thông dữ liệu với nhau Hệ CSDL hoạt động theonhiều cơ chế (như LDAP, Active Directory, …), cho phép tích hợp thông tin hệthống của các hệ CSDL nền khác nhau

7 Các mô hình phát triển

7.1 Portal theo chuẩn Ichannel

IChannel là một chuẩn phát triển kênh ứng dụng dựa trên mô hình kiếntrúc MVC, và áp dụng công nghệ XML/XSLT trong trình diễn và chuyển đổi dữliệu IChannel được dùng trong framework uPortal để phát triển các kênh ứngdụng, chúng ta sẽ đi sâu nghiên cứu về framework uPortal trong những phầndưới đây:

a uPortal

- Giới thiệu

uPortal là một dự án được bắt đầu và phát triển bởi JA-SIG Mục đíchchính của uPortal là đưa ra một bộ khung (framework) cho phép tích hợp cácthông tin, ứng dụng vào trong một giao diện web nhằm tạo ra một cổng truy

nhập duy nhất đáp ứng yêu cầu sử dụng của một cộng đồng người dùng muốnchia sẻ, trao đổi các thông tin trực tuyến trên Internet

Công nghệ nền tảng mà uPortal tuân theo là các chuẩn được đặc tả trongkiến trúc hệ thống mở J2EE, bao gồm Applet, Servlet, JSP, EJB, JTA, JMS, uPortal thao tác với các object của một web-page theo đặc tả DOM (DocumentObject Model), và sử dụng Java, XML, XSLT

Công nghệ XML/XSLT được sử dụng cho phần trình diễn đối với người

sử dụng Công nghệ này cho phép trình diễn cùng một nội dung thông tin trênnhiều thiết bị khác nhau như máy vi tính cá nhân PC, các thiết bị di động cầm taynhư Mobile, PDA, và v.v

Kiến trúc trong đặc tả J2EE làm uPortal trở thành một hệ thống mở vàmềm dẻo, có khả năng tích hợp với các hệ thống hạ tầng và các ứng dụng dịch

vụ hay các nguồn dữ liệu khác nhau Theo như kiến trúc đó, uPortal cung cấpmột tập các giao diện để tích hợp với các hệ thống và ứng dụng bên ngoài

Công nghệ Java là một công nghệ cho phép xây dựng các phần mềm “viếtmột lần, chạy mọi nơi” tức là các ứng dụng được viết bằng Java chạy được trênnhiều nền hệ thống khác nhau Windows, Linux, Unix,… Do đó uPortal cũng làmột hệ thống mà chạy được trên nhiều môi trường hệ điều hành khác nhau Nócũng có thể chạy với nhiều web server và kết nối đến nhiều hệ cơ sở dữ liệu khácnhau như Oracle, SQL Server, My SQL, DB2,… nhờ vào một lớp (một thànhphần) chuyên đảm nhận kết nối cơ sở dữ liệu để đảm bảo các lớp phía trên củauPortal hoạt động độc lập không phụ thuộc vào loại cơ sở dữ liệu

- Lịch sử của uPortal

Phiên bản đầu tiên của uPortal – uPortal 1.0 với tên gọi Monterey 1.0được đưa ra vào năm 2000 Sau đó đến phiên bản uPortal 1.5 với tên gọi Destinvới việc bổ sung hệ thống kiểm soát quyền truy cập Ở các phiên bản uPortal 1.x,việc biểu diễn nội dung nhờ vào các thành phần JSP Các thành phần này nhậntrực tiếp dữ liệu và sinh ra các trang HTML

Nhưng đến các phiên bản uPortal 2.x đưa ra một kiến trúc mới dựa trênchuẩn XML/XSLT Đồng thời các mẫu thiết kế (design pattern) được áp dụngnhiều hơn để tổ chức các thành phần phần mềm của uPortal mang tính mềm dẻo

và tính mở cao Từ phiên bản uPortal 2.1.3 được đưa ra ngày 23 tháng 6 năm

2003 đã tăng cường thêm nhiều tính tăng như quản lý nhóm, kênh từ xa (remote

channel),… Và đến phiên bản 2.3.5 ra ngày 14 tháng 9 năm 2004 đã hỗ trợchuẩn portlet JSR-168.

Các phiên bản và thời điểm phát hành có thể tóm tắt bằng bảng dưới đây

Data Access Object layer

RDBMS Layer

Database Database Server

Portal Container

Channel 3 Channel 2

Channel 1

Web Server

Hình 1.3:Mô hình của Portal

- Công nghệ xử lý dựa trên mô hình kiến trúc MVC

uPortal là web-based application, được kiến trúc dựa trên mô hình MVC.Khi triển khai Portal được đóng gói lại theo dạng web archive(.war) và được đặttrong một thư mục trên web server Mối liên hệ giữa web server và các vai tròcủa mô hình MVC trong uPortal được mô tả trong hình vẽ sau:

: Nguoi dung Web Server Controller Modul lay du lieu - Http Request Modul xu li du lieu - Object Model Modul hien thi - View

1: Yeu cau - Http request

2: Chuyen yeu cau

3: Lay du lieu nhap vao tu nguoi dung internet

4: Thuc hien cac chuc nang he thong

5: Tao du lieu - XML data 6: Chon kieu hien thi - stylesheet

7: Goi modul hien thi qua Web Server

9: Lay du lieu 8: Gui yeu cau hien thi den modul hien thi

10: Tao trang web tra loi

11: T ra loi - Http reponse

Hình 1.4: Mối liên hệ giữa web server và các vai trò của mô hình MVC

+ Controller có nhiệm vụ nhận các request từ người dùng do web serverchuyển tới, nhận model là kết quả từ các business logic, sau đó gọi View để tạoresponse trả lời request

+ View trong uPortal là các stylesheet Controller gọi view để hiển thị dữliệu XML trong Model Dữ liệu XML của model được tạo ra từ domain logiclayer

+ uPortal sử dụng các bộ thư viện mã nguồn mở như xalan.jar, xerces.jar(Apache Group – www.apache.org) và JAXP (Sun – www.sun.com) để chuyểnđổi các dữ liệu từ domain-logic thành XML và từ XML thành HTML

- Sử dụng công nghệ XML/XSLT trong trình diễn, chuyển đổi dữ liệu

uPortal áp dụng công nghệ XML/XSLT trong trình diễn và chuyển đổi dữliệu, hình dưới đây mô phỏng cho cơ chế trình diễn này

Hình 1.5: Sơ đồ mô phỏng cơ chế trình diễn thông tin của

uPortal

+ Tạo trình diễn

Bộ khung phần mềm uPortal là một bộ khung để phân phối các thôngtin/dịch vụ tích hợp được thu thập từ các loại nguồn thông tin được phân loại.Chức năng chính của bộ khung là cung cấp một bộ máy hiệu quả và mềm dẻocho việc tạo một trình diễn Cho trước một tập nguồn tài nguyên thông tin (cáckênh), và một chỉ dẫn cách sắp xếp và bộ khung trình diễn (stylesheets), bộkhung uPortal sẽ phối hợp để tạo thành một tài liệu tổ hợp cuối cùng

Điểm bắt đầu cho bất cứ một sự tạo trình diễn luôn là một tổ chức trừu

tượng của các kênh: tài liệu bố cục người dùng (user layout document) Tiến

trình tạo trình diễn tổ hợp chuyển đổi user layout document theo ba giai đoạnchính để đạt được tài liệu cuối cùng dưới dạng một ngôn ngữ đánh dấu XML(markup language):

Giai đoạn đầu là chuyển một hệ thống trừu tượng bố cục của người dùng

(user layout) sang dạng một trình diễn có cấu trúc - gọi là chuyển đổi cấu trúc (structure transformation), và lôgic của nó được định nghĩa bởi structure

stylesheet (sử dụng XSL) Ví dụ, the structure stylesheet cho biểu diễn “tab và

cột” mặc định sẽ chuyển cấu trúc user layout trừu tượng thành một cấu trúc của

Channel 3 Render

Channel 1 Render

Channel 2 Render

XML

Layout XML

XSLT

các yếu tố “tab” và “cột” Sau chuyển đổi cấu trúc, hệ thống khởi tạo vòng đờitrình diễn của các kênh mà sẽ được hợp thành vào trong trình diễn cuối cùng.

Giai đoạn thứ hai của tiến trình sẽ chuyển kết quả của giai đoạn chuyển

đổi cấu trúc sang giao thành một ngôn ngữ đánh dấu (như HTML) Chuyển đổinày gọi là chuyển đổi nền (theme transformation) và lôgic của nó được định

nghĩa bởi theme stylesheet.

Nội dung được cung cấp bởi mỗi kênh riêng biệt sẽ được sát nhập vàotrong kết quả của chuyển đổi cấu trúc

Giai đoạn cuối cùng là xuất bản kết quả của chuyển đổi nền với nội dung

của kênh vào trong một luồng các ký tự theo các luật của ngôn ngữ đánh dấu vàphương tiện biểu diễn

Hình 1.6: Các giai đoạn tạo trình diễn

+ Chuyển đổi

uPortal là framework, trong đó các thực thể tạo nên framework được thiết

kế và implement như một kênh độc lập trong kiến trúc hệ thống Cụ thể, cácchức năng của uPortal được kiến trúc như một kênh trong hệ thống Người dùng

hệ thống sử dụng kênh phụ thuộc vào vai trò và quyền Một kênh đượcimplement theo mô hình MVC, controller thực hiện business logic của kênh, kếtquả của business logic được mô hình trong model, và controller gọi view để hiểnthị kết quả trong model Business logic của kênh được mô hình hoá trong Modeldưới dạng dữ liệu XML, view được mô tả trong các stylesheet bằng XSL

Trang web trong kiến trúc portal được thiết kế dựa trên việc bố trí cáckênh trên một kiểu layout Có hai engine chính được thực hiện khi tạo một trangweb trong kiến trúc portal:

User

Layout

Structur ed Layout

Page Content

Final Documen t header/footer

content

presentation

* Channel Renderer Engine: Liên quan đến từng kênh cụ thể trong hệ

thống Engine này sử dụng mô hình Two step view để chuyển đổi dữ liệu kênh

từ domain logic sang XML, tiếp đó từ thực hiện chuyển đổi từ XML sang dữ liệuHTML Dưới đây là mô hình thể hiện cơ chế chuyển đổi này

Hình 1.7: Mô hình chuyển đổi theo cơ chế Channel Renderer Engine

* Layout Renderer Engine: Liên quan đến từng layout của kênh cụ thểtrong hệ thống Engine này cũng sử dụng mô hình Two step view để chuyển đổi

dữ liệu layout từ domain logic sang XML, tiếp đó từ thực hiện chuyển đổi từXML sang dữ liệu HTML

Hình 1.8: Mô hình chuyển đổi theo cơ chế Layout Renderer Engine

Chương II: Tìm hiểu về Portlet

1 Định nghĩa

Là một thành phần web có khả năng gắn nối (plugable) được quản lý bởimột portlet container, cái cung cấp một cách linh động nội dung như là một phầncủa sự kết hợp giao diện người dùng Portlet là một thành phần nhỏ của ứngdụng web, chạy bên trong trang portal cùng với một số lượng bất kỳ các thực thểnào đó khác, nó có thể xử lý các request và tạo ra các nội dung động

Một server portal quản lý các yêu cầu của client Giống như một ứng dụngweb phía máy chủ có một web container để quản lý việc “chạy” các thành phầnweb (như serverlet bộ lọc filters ), một portal có một portlet container để quản

lý việc chạy các portlets

Portlet là một thành phần web riêng biệt, có một hay một vài chức năng cụthể nào đó, giúp portal hoàn thành chức năng, nhiệm vụ của mình Mọi yêu cầucủa người sử dụng đối với portlet đều phải thông qua giao diện của portal

Các máy khách truy cập web tương tác với portlet thông qua mô hình yêucầu/trả lời(request/reponse) Với một chu kỳ yêu cầu xác định, từng portlet sinh

ra nội dung riêng biệt được gọi là đoạn nội dung (fragment).Các đoạn nội dungđược trình bày bằng một ngôn ngữ đánh dấu (markup) như HTML hoặcXHTML… sẽ được kết hợp với nhau thành một tài liệu trả lời hoàn chỉnh

Một portlet được hiển thị trên một trang portal như là một cửa sổ đơn.Portlet cung cấp nội dung chứa trong cửa sổ nhưng nó không phải là bản thâncửa sổ đó

Các portlet có thể được xây dựng thành nhiều mức và ngữ cảnh của portalcho phép người dùng giao tiếp với portlet để hoàn thành mục đích của mình

2 Định dạng chung của một Portlet

Trong hệ thống tích hợp có rất nhiều portlet khác nhau, mỗi portlet mang mộtnội dung khác nhau Tuy nhiên, định dạng của các portlet là giống nhau Có thểchia portlet làm 2 loại : portlet rộng và portlet hẹp Portlet rộng có độ rộng là 536pixel, còn portlet hẹp có độ rộng là 214 pixel Chiều dài của các portlet này tùythuộc vào chức năng mà nó thực hiện Dưới đây là minh hoạ cho một portlet:

Hình 2.1: Ví dụ về một Portlet

- Tiêu đề: Tiêu đề của portlet

- Thanh công cụ: chứa tiêu đề và các nút thao tác của portlet

- Tiêu đề phụ: Phần nội dung: hiển thị nội dung của portlet

- Phóng to tối đa ( ): khi nhấn vào nút này thì cửa sổ portlet sẽ có độ

rộng hết màn hình và các portlet khác sẽ được ẩn đi

- Thu nhỏ tối thiểu ( ): khi nhấn nút này thì cửa sổ portlet sẽ thu nhỏ

lại, chỉ còn hiển thị thanh công cụ

- Sửa hiển thị ( ): tùy từng portlet sẽ có chức năng này Đó là các

portlet mà người sử dụng có thể thay đổi một số yếu tố định dạng nhưthay đổi ngôn ngữ hiển thị cho portlet đó, thay đổi số tin tức hiển thịtrong portlet

- Tắt ( ): đóng portlet lại

- Khôi phục ( ) Khi bạn nhấn vào nút hoặc thì các nút này sẽ được thay

thế bằng nút Nút này được dùng để khôi phục lại kích cỡ ban đầu củaportlet

- Kéo thả ( ): nếu bạn muốn di chuyển portlet đến một vị trí khác thì

bạn nhấn vào nút này, đồng thời kéo chuột đến vị trí mới và thả ra

- Trợ giúp( ): Bạn có thể click vào đây để nhận được trợ giúp.

3 Giới thiệu về chuẩn JSR 168

JSR 168 – viết đầy đủ là Java Specification Request 168 Đây là chuẩnđược phê chuẩn tháng 10 năm 2003, phát triển bởi Java Community Processnhằm hoàn tất các thao tác giữa các bộ phận của Portal và Portlet, chuẩn nàygiúp đơn giản hóa việc phát triển các ứng dụng portlet và cho phép các nhà pháttriển tạo các thành phần ứng dụng có khả năng “cắm và chạy” trên bất kỳ nềntảng hệ thống J2EE Portal nào

3.1 Những nền tảng chung của Portlet

Một server portal quản lý các yêu cầu của client Giống như một ứng dụngWeb phía máy chủ có một web container để quản lý việc "chạy" các thành phầnweb (như servlets, jsps, bộ lọc filters, v.v ), một portal có một portlet container

để quản lý việc chạy các Portlets Chú ý rằng hầu hết các ứng dụng web phíamáy chủ, chẳng hạn như Tomcat, có thêm các tính năng bổ sung bên cạnh webcontainer (console quản lý, CSDL người dùng, v.v), còn bao gồm vài ứng dụngweb đặc biệt (chẳng hạn ứng dụng web administration)

Portal được cho là một mẫu tương tự, cung cấp ở mức cao hơn các chứcnăng bao quanh portlet container chúng gắn chặt với đặc tả, cho phép ứng dụngportlet trở nên khả chuyển, giống như ứng dụng web

Portlet API là một mở rộng của đặc tả servlet, điều đó có nghĩa là mộtportlet container cũng vậy, theo định nghĩa một web container Hình 2.2 chỉ rastack Portal, nó xác nhận làm thế nào các phần khác nhau được xây dựng phíatrên nhau để cung cấp một portal server

Hình 2.2: Stack Portal

3.2 Định nghĩa

- Portlet một thành phần web có khả năng gắn nối (plugable) được quản

lý bởi một portlet container, cái cung cấp một cách linh động nội dung như làmột phần của sự kết hợp giao diện người dùng

- Fragment Kết quả việc thực thi một portlet, một đoạn các ngôn ngữ

đánh dấu (HTML, XML ) nó gắn với một vài qui tắc

- Portlet Container Môi trường thực thi của một portlet Nó quản lý vòng

đời của portlet và quản lý các yêu cầu từ portal bằng cách triệu gọi các portletsbên trong container

3.3 Portlets và Servlets

Portlet API là một mở rộng của servlet API Thế nên, có cả sự tương đồng

và sự khác biệt giữa các thành phần Điều này là quan trọng để hiểu những nétđộc đáo (đặc thù) này để hiểu tại sao lại có một portlet đặc

Điểm tương đồng

- Portlet và Servlet đều là thành phần web J2EE

- Cả 2 được quản lý bởi container, điều khiển sự tương tác giữa chúng vàvòng đời

- Mỗi cái sản sinh nội dung web động thông qua cơ chếrequest/response

Điểm khác biệt

- Portlet sinh ra framents trong khi servlets sinh ra một tài liệu hoànchỉnh.

- Không giống servlet, portlet không nhảy tới trực tiếp một URL

- Portlet có một lược đồ request phức tạp hơn với 2 loại yêu cầu là:action (hành động) render (đáp ứng)

- Portlet gắn chặt đến một tập chuẩn hóa các trạng thái, modes chúngđịnh nghĩa các thao tác ngữ cảnh và những qui tắc đáp ứng (render)

Điểm vượt trội

- Portlet có một cơ chế phức tạp hơn để truy cập và cố gắng cấu hìnhthông tin

- Portlet phải truy cập đến hiện trạng (profile) thông tin người dùng,ngoại trừ người dùng cơ sở và giữ chức năng cung cấp thông tin đặc tảservlet

- Portlet có thể thực hiện việc viết lại portlet, vì thế để tạo một liên kếtthì nó độc lập với việc cài đặt ứng dụng portal server (nó có rất nhiềuphương thức để theo dõi thông tin phiên làm việc .)

- Portlet có 2 đích sessions khác nhau trong đó lưu trữ các đối tượng:ứng dụng chung và portlet riêng tư

Điểm yếu hơn

- Portlet không thể thay đổi HTTP header hay thiết lập mã hóa các trả lời(response)

- Portlet không thể truy xuất URL mà client dùng để khởi tạo các requesttrên portal

- Các ứng dụng portlet là mở rộng của ứng dụng WEB Vì thế cả 2 ứngdụng được triển khai (deploy) trong file WAR (Web Archive file) và cả 2 baogồm một file mô tả triển khai ứng dụng web (web.xml) Tuy nhiên một ứng dụngportlet còn bao gồm một file mô tả triển khai ứng dụng portlet (portlet.xml)

- Vì một ứng dụng portlet là một mở rộng của ứng dụng web, nên logic mànói nó có thể bao gồm những thành phần ứng dụng web khác Portlet có thể sửdụng JSPs và servlets để cài đặt những tính năng của nó

3.4 Những tương tác trong Portal

Ta sẽ chỉ ra rằng làm thế nào một tương tác portal điển hình xuất hiệntrước khi đi vào chi tiết làm thế nào một portlet có thể tự hoàn trả (render) vớiJSPs và servlet

Hình 2.3 ở dưới chỉ ra một chuổi các sự kiện xuất hiện bên trong portal đểquản lý một hồi đáp (render) điển hình của client Bên trong portal là Portlet API– phục tùng mệnh lệnh của portlet container chúng quản lý trạng thái thực thi củaportlet.

Hình 2.3: Sự kiện trong Portal

Container đánh giá những portlet đó thành các framents, hoặc là tạo yêucầu (request) của portlet hoặc là lấy một fragment trong cache Sau đó, containernắm fragment đến portal server để kết hợp chúng vào trong trang portal

3.4.1 Portlet Interface và lớp GenericPortlet

Giao diện portlet định nghĩa (cách thức) thái độ mà tất cả các portlet phảithực hiện Một cách cụ thể, chúng ta nên kế thừa (extend) lớp GenericPortlet để

xây dựng portlet, bởi nó cung cấp kiến trúc chứa tất cả những phương thức càiđặt portlet điển hình, không chỉ đơn giản những cái mình cần.

3.4.2 Vòng đời Portlet

Rất giống như servlet, vòng đời một portlet được quản lý bởi container,

và có phương thức init (khởi tạo) nó được dùng để quản lý những yêu cầu khởitạo (tạo tài nguyên, cấu hình, vv ) Portlet chỉ được tải về khi cần đến, trừ khibạn cấu hình container để tải chúng ngay khi khởi động Phương thức init lấymột đối tượng object đã cài đặt (implement) lớp giao tiếp interfacePortletConfig, cái quản lý các tham số khởi tạo và bó tài nguyên của Portlet:ResourceBundle Đối tượng này có thể được sử dụng để lấy tham chiếu đếnObject đã cài đặt (implement) lớp giao tiếp PortletContext interface

Nhà phát triển portlet không hoàn toàn mất thì giờ lo lắng về sự phức tạpcủa biệt lệ khởi tạo (exception) portlet container, bởi thông thường chúng đượclấy ra, và nhà phát triển tác động trở lại lên chúng (gỡ rối những tình huống cóthể dẫn đến biệt lệ exception và sửa chúng cho chúng nếu có thể) Tuy nhiên,đáng chú ý là một unavailableException có thể xác định thời gian mà portlet sẽkhông thích hợp Cả 2 đều có ích (giữ cho portlet container luôn cố gắng liên tụctải portlet) và làm không vừa lòng nhà phát triển (tại sao portlet container khôngtải lại portlet của tôi ?)

Phương thức destroy cung cấp một cơ may để xoá hết các tài nguyênđược thiết lập ở phương thức init (khởi tạo) Điều này tương tự với portletdestroy trong servlet, và được gọi mỗi khi container tống khứ portlet Khi mộtexception được đưa ra trong phương thức init của portlet, thì phương thứcdestroy được đảm bảo là không được gọi

Tuy nhiên, nếu tài nguyên được tạo trong phương thức init() trước khiexception được đưa ra, nhà phát triển không thể mong đợi phương thức destroydọn dẹp chúng, và phải quản lý chúng trong khối try - catch exception

3.4.3 Các trạng thái thực thi portlet (Portlet Runtime States)

Khi một portlet đang chạy, nó có một đối tượng Preferences kết hợp chophép tuỳ biến portlet Những giá trị khởi tạo của Preferences được xác định trong

mô tả triển khai (deployment descriptor), nhưng portlet có một sự truy cập đầy

đủ một cách hệ thống đến tham chiếu của nó Khi một portlet được đặt vào mộttrang, một Preferences sẽ tham chiếu đến nó Sự kết đôi của portlet và đối tượngPreferences trên một trang được biết đến như là của sổ portlet

Một trang có thể bao gồm rất nhiều những của sổ portlet như nhau bêntrong hiển thị của nó Trước khi bạn bắt đầu thắc mắc tại sao tất cả các đối tượngtham chiếu Preferences Object này là cần thiết, hãy hình dung rằng điều đó cungcấp khả năng để thao tác cho tính năng chủ yếu của portal - customization (khảnăng tuỳ biến)

Trong khi đối tượng tham chiếu khởi tạo portlet (Preferences Object) đượctạo để xác định cấu hình và trạng thái thực thi của portlet, việc ngắt trạng thái đểquản lý tuỳ biến giao diện của portlet là điều cần thiết Chẳng hạn, nói bạn cómột portlet thư mục làm công (employee directory portlet) Hiển nhiên là, nó cầnmột vài tham chiếu mới có thể chạy được Tuy nhiên, khi employee directoryportlet được nhúng vào trong trang chủ của "Hanoi Portal", nên không chỉ cómột giao diện tuỳ biến, nhưng cũng có tham chiếu liên quan đến thực tế trêntrang, chẳng hạn chỉ hiển thị các nhân viên của Hanoi Portal

3.4.4 Quản lý yêu cầu portlet (Portlet Request Handling)

Có 2 loại yêu cầu (request) có thể đưa ra đối với một portlet: action request

và render request (yêu cầu hành động và yêu cầu hồi đáp) Không ngẫu nhiên mànhững yêu cầu (request) này đi cùng với các loại URL tương ứng: action URLs

và render URLs Một action URL nhắm tới phương thức processAction củaportlet trong khi render URL hướng tới phương thức render của nó

3.4.4.1 “Chỉ có thể là một”

Nếu yêu cầu của client là action request, thì nó chỉ hướng đến mộtportlet, cái sẽ phải thực thi trước tiên Không có các action request khác có thểđược thực thi trên portlet còn lại, chỉ có render request Hình 2.4 minh hoạ làmthế nào một portal container có thể quản lý một action request

Chúng ta đã biết, portlet container sẽ thực thi phương thức processAction()trên portlet đích, chờ đợi cho đến khi nó kết thúc trước khi nó thực thi hồi đáp(render) của những portlets còn lại trên trang Việc gọi phương thức hồi đáprender trên các portlets còn lại có thể hoàn tất theo thứ tự, và có thể hoàn tất songsong

Phương thức processAction() chịu trách nhiệm việc thay đổi trạng tháitrên một portlet cho trước, trong khi phương thức render chịu trách nhiệm sảnsinh nội dung trình bày tương ứng (thích hợp) của portlet

Vì thế, hoàn toàn hợp lý khi một user có thể thay đổi chỉ một portlet tạimột thời điểm (bạn chỉ có thể click trên một hộp), và rằng tất cả các portlets phải

gọi hồi đáp (render) để sản sinh lại nội dung của chúng trên kết quả của action.Tuy nhiên, đó không phải để nói rằng tất cả các portlet không thể thay đổi tạithời qian đã cho

Hãy xem xét ví dụ chung sau: một portal cho Simpsons Một trong nhữngportlet cho phép bạn chọn các đặc tính của Simpson ở những trang mà bạn muốnxem Những portlet khác chứa đựng những thông tin đặc tính, hình thức vừa rồi,những câu trích dẫn lớn nhất Khi bạn chọn một đặc tính mới, bạn sẽ thay đổitrạng thái mà những đặc tính đã chọn hay portlet thông qua phương thứcprocessAction() Trong phương thức này, qua nó, bạn sẽ soạn thảo thuộc tínhchia sẽ cho trước nó xác định đặc tính của trang mà bạn tác động, chúng sẽ lànguyên nhân tất cả các portlets tự hồi đáp cho những đặc tính trên khi bạn triệugọi phương thức render của chúng

Ghi nhớ một biệt lệ (exception) để khi một phương thức hồi đáp (render)của portlet được gọi, và khi nội dung của portlet bị giữ Portlet API cho phépnhững containers chọn lựa để sử dụng bản copy nội dung được lưu giữ, thay vìgọi phương thức render Portlet container không là nơi cung cấp một cách dễdàng cache, nhưng là nguồn đầu cơ cung cấp dễ dàng nơi lưu trữ kết thúc, màđược cấu hình trong mô tả triển khai ứng dụng portlet (deployment descriptor).Người triển khai cung cấp một yếu tố kết thúc-lưu trữ trong đó user xác định sốgiây lưu trữ (hoặc -1 nếu không kết thúc)

Nơi lưu trữ là 1 client = 1 portlet, và không thể chia sẽ thông qua nhữngyêu cầu của client Tất nhiên là một nhà phát triển có thể implement portlet của

họ do cache quản lý trong phương thức render, lưu trữ dữ liệu thường được yêucầu trong PortletContext

Hình 2.4: Minh hoạ làm thế nào một portal container có thể quản lý một action request.

ActionRequest:

Như đã đề cập ở trên trong phần thảo luận về quản lý yêu cầu portlet,những yêu cầu hành động (action request) nắm giữ việc thay đổi trạng thái củamột portlet dựa trên tham số yêu cầu hành động (action request) Nó được hoàntất bằng cách sử dụng phương thức processAction(), nó lấy tham số là 2 đốitượng ActionRequest và ActionResponse Đối tượng ActionRequest tương tựnhư đối tượng ServletRequest cho biết

- Các tham số yêu cầu hành động (action request)

- Chế độ portlet

- Phiên làm việc của portlet

- Trạng thái cửa sổ