Đồ án Môn học công nghệ thông tin

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 Định nghĩa 5 Lịch sử phát triển 5 Phân loại Portal 6 Thuộc tính cơ bản của Portal 7 Chức năng của Portal 8 Kiến trúc của Portal 9 Các mô hình phát triển 12 Chương II: Tìm hiểu về Portlet 21 Định nghĩa 21 Định dạng chung của một Portlet 21 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 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 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 Đặ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ần thiế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ập sá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 trong tươ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ến thứ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ận tì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ô trong trườ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ững thà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ập thô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 ứ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 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à “website truyề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ông tin; 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-8 nă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óa của website truyền thống. Nó ra đời để giải quyết những vấn đề mà website truyề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ới ngườ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á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. 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ác chuẩ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ụng củ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ậy khó 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ới thiệ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-8 nă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óa của web truyền thống. Nó ra đời để giải quyết những vấn đề mà website truyền thố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ền thống. Là “siêu website”, gọi đầy đủ là Portal Website, gọi tắt là Portal, đối vớ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à quan niệm mới về triết lý phục vụ thay cho cách hiểu “tuyên truyền“ thông qua 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ân loạ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ông Internet đã phát triển rất cao so với thời kỳ xuất hiện Word Wide Web và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ắp rắ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ẽ: 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ậy khá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ại khá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ằm rả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ới nhau 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ông việc, qua đó nâng cao năng suất lao động và hiệu quả giải quyết công việ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ủa mì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ụng khá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ại thờ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 cho nhiề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ùng thô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ác nhau 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ển thị 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ấy thông tin về người dùng khi hoạt động mà không phải yêu cầu người dùng đăng nhậ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ất thô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ày khô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ành phầ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óm ngườ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ành viên tại một công thông tin công cộng (như Yahoo, MSN. . .)hoặc được người quả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 tin doanh 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ựa trên vai trò (Role-based security) được sử dụng như một tiêu chuẩn trong các hoạt động xác định quyền truy cập và cung cấp thông tin cho các đối tượng khác nhau trong các Portal cũng như các ứng dụng web. Kiến trúc của Portal 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). 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 qua lớp Presentation Services.Tầng trình diễn chịu trách nhiệm về cung cấp giao diện cho 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ôn ngữ Script) và gọi các thành phần thích hợp từ tầng Business Logic để xử lý các yêu cầu. Kết quả sau xử lý được trả lại cho người dùng. 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ân tí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ả cho phí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ễn củ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ồng công việc, tập các API dùng để tạo ra các dữ liệu và sau đó thông qua Presentation 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ạo mới, sửa đổi, xóa, ...) của người sử dụng hoặc nhóm người sử dụng, phân quyề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 truy nhậ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ải nhớ quá nhiều tên và mật khẩu khi truy nhập tài nguyên của mình, Portal cũ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ập vào hệ thống thì có thể tự thay đổi giao diện trình bày như bố cục và giao diệ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 theo các chủ đề (topics, subtopics, ...) sao cho người dùng có thể nhanh chóng tìm thấy thông tin mà mình cần. Trong mục quản lý nội dung còn có các chứ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ản thô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ủa cá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ạn thả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ác mố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ông việ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, CSDL chuyê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ác CSDL này được liên thông với nhau và tạo thành một hệ thống phục vụ điều hà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ột ngành dọc liên quan đến Đơn vị đó. Khi có yêu cầu, hệ thống sẵn sàng cho việc kế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 theo nhiề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ến trú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 ứng dụng, chúng ta sẽ đi sâu nghiên cứu về framework uPortal trong những phần dướ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 đích chính của uPortal là đưa ra một bộ khung (framework) cho phép tích hợp các thô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ốn chia 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ả trong kiế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 (Document Object 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ên nhiề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 tay như 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ấp mộ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ết mộ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ên nhiề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ác nhau như Oracle, SQL Server, My SQL, DB2,… nhờ vào một lớp (một thành phầ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ủa uPortal 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 Destin vớ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ận trự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ên chuẩn XML/XSLT. Đồng thời các mẫu thiết kế (design pattern) được áp dụng nhiề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. Phiên bản Thời điểm phát hành uPortal 1.0 07 – 2000 uPortal 1.5 02 – 2001 uPortal 1.6 06 – 2001 uPortal 2.0 07- 2001 uPortal 2.0.3 06-12-2003 uPortal 2.1.3 23-06-2003 uPortal 2.1.5 14-01-2004 uPortal 2.2.1 05-04-2004 uPortal 2.3.5 24-09-2004 uPortal 2.4.3.1 28-10-2005 uPortal 2.5.2 02-03-2006 - Mô hình Portal Container quản lý các yêu cầu từ phía client và quản lý việc chạy của các kênh IChannel trong Portal. Khi Portal Container nhận được yêu cầu từ client nó sẽ phân tích, xử lý và đưa yêu cầu tới kênh ứng dụng được yêu cầu để thực thi, và trả về kết quả cho Portal Container. Khi nhận được kết quả từ kênh ứng dụng Portal Container sẽ kết hợp với các nội dung khác của trang để trả về HTML cho client. 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 đặt trong 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: 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 server chuyển tới, nhận model là kết quả từ các business logic, sau đó gọi View để tạo response 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 logic layer. + 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. Channel 3 Render Channel 1 Render Channel 2 Render XML Layout XML XML XSLT 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ông tin/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ẻo cho 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ác kê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ạn chí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 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 đời trì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 đổi nà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ào trong 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. User Layout Structured Layout Page Content Final Document header/footer content presentation 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ác chứ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 được implement theo mô hình MVC, controller thực hiện business logic của kênh, kết quả của business logic được mô hình trong model, và controller gọi view để hiển thị kết quả trong model. Business logic của kênh được mô hình hoá trong Model dướ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ác kênh trên một kiểu layout. Có hai engine chính được thực hiện khi tạo một trang web trong kiến trúc portal: * 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ệu HTML. 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ở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. Portlet là một thành phần nhỏ của ứng dụ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ụng web phía máy chủ có một web container để quản lý việc “chạy” các thành phần web (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ầu củ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êu cầ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ặc XHTML… 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ân cửa sổ đó Các portlet có thể được xây dựng thành nhiều mức và ngữ cảnh của portal cho 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ột nộ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à 536 pixel, còn portlet hẹp có độ rộng là 214 pixel. Chiều dài của các portlet này tùy thuộ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ủa portlet. 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 Process nhằ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ày giú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át triể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ền tả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ụng Web phía máy chủ có một web container để quản lý việc "chạy" các thành phần web (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ía máy chủ, chẳng hạn như Tomcat, có thêm các tính năng bổ sung bên cạnh web container (console quản lý, CSDL người dùng, v.v), còn bao gồm vài ứng dụng web đặ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ức năng bao quanh portlet container chúng gắn chặt với đặc tả, cho phép ứng dụng portlet 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ột portlet container cũng vậy, theo định nghĩa một web container. Hình 2.2 chỉ ra stack Portal, nó xác nhận làm thế nào các phần khác nhau được xây dựng phía trê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 portlets bê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àn chỉ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ình thô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ết thì nó độc lập với việc cài đặt ứng dụng portal server (nó có rất nhiều phươ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 request trên portal. - Các ứng dụng portlet là mở rộng của ứng dụng WEB. Vì thế cả 2 ứng dụng được triển khai (deploy) trong file WAR (Web Archive file) và cả 2 bao gồm một file mô tả triển khai ứng dụng web (web.xml). Tuy nhiên một ứng dụng portlet 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ện trước khi đi vào chi tiết làm thế nào một portlet có thể tự hoàn trả (render) với JSPs 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ủa portlet. 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êu cầu (request) của portlet hoặc là lấy một fragment trong cache. Sau đó, container nắ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ải thự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ởi tạo (tạo tài nguyên, cấu hình, vv...). Portlet chỉ được tải về khi cần đến, trừ khi bạn cấu hình container để tải chúng ngay khi khởi động. Phương thức init lấy một đối tượng object đã cài đặt (implement) lớp giao tiếp interface PortletConfig, 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 đến Object đã 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ạp của biệt lệ khởi tạo (exception) portlet container, bởi thông thường chúng được lấ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ục tải portlet) và làm không vừa lòng nhà phát triển (tại sao portlet container không tả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 portlet destroy trong servlet, và được gọi mỗi khi container tống khứ portlet. Khi một exception được đưa ra trong phương thức init của portlet, thì phương thức destroy đượ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 khi exception được đưa ra, nhà phát triển không thể mong đợi phương thức destroy dọ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 cho phé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ột trang, một Preferences sẽ tham chiếu đến nó. Sự kết đôi của portlet và đối tượng Preferences 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ên trong 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ượng tham chiếu Preferences Object này là cần thiết, hãy hình dung rằng điều đó cung cấ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) được tạ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ần một vài tham chiếu mới có thể chạy được. Tuy nhiên, khi employee directory portlet đượ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ên trang, 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ủa portlet 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ột portlet, 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àm thế 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 đáp render 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 song song. Phương thức processAction() chịu trách nhiệm việc thay đổi trạng thái trên một portlet cho trước, trong khi phương thức render chịu trách nhiệm sản sinh 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ại mộ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ại thời qian đã cho. Hãy xem xét ví dụ chung sau: một portal cho Simpsons. Một trong những portlet cho phép bạn chọn các đặc tính của Simpson ở những trang mà bạn muốn xem. 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 đổi trạng thái mà những đặc tính đã chọn hay portlet thông qua phương thức processAction(). Trong phương thức này, qua nó, bạn sẽ soạn thảo thuộc tính chia 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ệu gọ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ép nhữ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ững yê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êu cầ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ủa một portlet dựa trên tham số yêu cầu hành động (action request). Nó được hoàn tất bằng cách sử dụng phương thức processAction(), nó lấy tham số là 2 đối tượ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ổ - Các đối tượng tham chiếu portlet - Ngữ cảnh portal Để thay đổi chế độ portlet hay trạng thái cửa sổ, bạn gọi phương thức tương ứng trong đối tượng ActionResponse. Sự thay đổi trở nên hiển nhiên khi phương thức render được gọi tiếp sau khi kết thúc quá trình xử lý trong phương thức processAction(). Bạn cũng có thể truyền các tham số render bằng cách sử dụng đối tượng ActionResponse. RenderRequest: RenderRequests sản sinh một fragment từ trạng thái hiện tại của portlet. Nó cung cấp: - Các tham chiếu hồi đáp (render request) - Chế độ portlet - Phiên làm việc của portlet - Trạng thái cửa sổ - Các đối tượng tham chiếu portlet Cũng có phương thức RenderResponse() đi kèm, nó cung cấp phương tiện cần thiết để hồi đáp nội dung. Bạn có thể gọi getOutputStream() hay getWriter() như từng làm trong servlet, hay bạn có thể gửi đi (dispatch) sự sản sinh nội dung cho một servlet hay JSP. Các đối tượng request và response đều không là luồng an toàn. Điều đó có nghĩa là một nhà phát triển nên tránh chia sẽ các tham chiếu cho chúng với những luồng thực thi khác. Hầu hết các nhà phát triển sẽ không chú ý đến vấn đề này, nhưng hãy nhớ ghi chú nhỏ lý thú này lần sau khi bạn quyết định cố gắng làm điều gì đó không hợp lý. 3.4.4.2 Lớp GenericPortlet Lớp GenericPortlet là một lớp trừu tượng được cài đặt (implement)của giao diện portlet (interface). Đó là con đường chung nhất mà hầu hết users sẽ sử dụng để viết portlets - bằng cách kế thừa lớp này. Lớp GenericPortlet kế thừa phương thức render bằng cách cài đặt tiêu đề của portlet, và sau đó gọi phương thức doDispatch() của nó, và đến lượt nó, xác định chế độ của portlet, và gọi phương thức thích hợp: doEdit() để EDIT, doView() để VIEW. Ta sẽ thảo luận về chế độ portlet sau. Đoạn mã sau mô tả một lớp kế thừa GenericPortlet : package org.opensourceportals.samples;import java.io.IOException;import javax.portlet.ActionRequest;import javax.portlet.ActionResponse;import javax.portlet.GenericPortlet;import javax.portlet.PortletException;import javax.portlet.PortletMode;import javax.portlet.PortletRequestDispatcher;import javax.portlet.RenderRequest;import javax.portlet.RenderResponse;/*** ExamplePortlet là ví dụ cơ bản về một lớp kế thừa GenericPortlet */public class ExamplePortlet extends GenericPortlet {/** phương thức này sẽ ghi đè phương thức doEdit của GenericPortlet*Được gọi để cung cấp một đánh dấu được hồi đáp khi chế độ portlet là PortletMode.EDIT* Lúc này, ta sẽ gửi phương thức đến một JSP trong thư mục gốc của portlet gọi là “edit.jsp”*/protected void doEdit(RenderRequest request,RenderResponse response) throws PortletException, IOException {PortletRequestDispatcher prd =getPortletContext().getRequestDispatcher(“/edit.jsp”);prd.include(request, response);}Ta sẽ mô tả ExamplePortlet, có kế thừa lớp GenericPortlet. Ở đây ta có thể ghi chồng phương thức doEdit, nó quản lý việc hồi đáp khi portlet ở chế độ EDIT./** phương thức này sẽ ghi đè phương thức doEdit của GenericPortlet*Được gọi để cấp một đánh dấu được hồi đáp khi chế độ portlet là * Phương thức này sẽ ghi đè phương thức doEdit của GenericPortlet *Được gọi để cung cấp một đánh dấu được hồi đáp khi chế độ portlet là PortletMode.VIEW * Lúc này, ta sẽ gửi phương thức đến một JSP trong thư mục gốc của portlet gọi là “view.jsp” */ protected void doView(RenderRequest request,RenderResponse response) throws PortletException, IOException {PortletRequestDispatcher prd =getPortletContext().getRequestDispatcher(“/view.jsp”);prd.include(request, response);} PortletMode.HELP* Lúc này, ta sẽ gửi phương thức đến một JSP trong thư mục gốc của portlet gọi là “help.jsp”*/ protected void doHelp(RenderRequest request,RenderResponse response) throws PortletException, IOException {PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher(“/help.jsp”);prd.include(request, response);} /** Phương thức này sẽ ghi đè phương thức doEdit của GenericPortlet*Được gọi để cung cấpmột đánh dấu được hồi đáp khi chế độ portlet là PortletMode.VIEW* Lúc này, ta sẽ gửi phương thức đến một JSP trong thư mục gốc của portlet gọi là “view.jsp”*/protected void doView(RenderRequest request,RenderResponse response) throws PortletException, IOException {PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher(“/view.jsp”);prd.include(request, response);} Tương tự, ta cung cấp các cách ứng xử được yêu cầu để hồi đáp portlet khi nó ở chế đội HELP và VIEW. /* phương thức này được ghi chồng để xác định tiêu đề một cách tự động. Nó có thể * có ích nếu bạn đang có tham số trong tiêu đề của bạn giống như : “News on *16/11/2005”*/protected String getTitle(RenderRequest request) {return “Example Portlet”;}/* Đây là phương thức cốt yếu của portlet, các thao tác của trạng thái portlet * được hoàn tất thông qua phương thức này. Để đơn giản, chúng ta sẽ truyền * đối số chỉ định chế độ portlet mà portlet có thể được thiết lập.*/public void processAction(ActionRequest request,ActionResponse response) throws PortletException, IOException {PortletMode mode =new PortletMode(request.getParameter(“mode”));response.setPortletMode(mode);}} Cuối cùng, ta chỉ định ghi chồng phương thức getTitle(), cho phép hoàn toàn hợp lý trong việc hồi đáp tiêu đề (như hiển thị ngày hiện tại) thay vì hiển thị tiêu đề tĩnh được mô tả trong mô tả triển khai (deployment descriptor). Ta cũng có thể quản lý phương thức processAction(), nó chịu trách nhiệm trong cách trả lời đối tượng ActionRequest. Đoạn mã nêu trên chỉ ra sự cài đặt cơ sở của portlet bằng cách viết một lớp kế thừa lớp GenericPortlet. Portlet này không gửi đi đến các trang JSPs khác dựa trên chế độ của nó (và thiết lập tên của nó một cách hệ thống). 3.5 Các yếu tố khác của Java Portlet API Đoạn mã sẽ cho biết các thành phần ở mức thấp bên trong đặc tả, việc cung cấp một portlet hình ảnh của nhà phát triển bên trong của đặc tả, làm sáng tỏ những khái niệm quan trọng và những nguy cơ tiềm ẩn. 3.5.1 PortletConfig Khi một portlet được khởi tạo, nó cần truy cập đến những tham số khởi tạo và thông tin các hình khác. Đối tượng PortletConfig cung cấp những thứ đó. Thêm vào những thông số khởi tạo, đối tượng PortletConfig còn có thể trình bày một ResourceBundle (bó tài nguyên) cho portlet. Đối tượng PortletConfig cung cấp những thứ đó. Thêm vào những thông số khởi tạo, đối tượng PortletConfig còn có thể trình bày một ResourceBundle (bó tài nguyên) cho portlet. Một ResourceBundle cho phép việc định vị ứng dụng portlet dễ dàng hơn. Bạn có thể xác định ResourceBundle trong dòng của mô tả triển khai ứng dụng portlet (deployment descriptor) như sau: Homer’s D’oh a Day PortletdohSimpsons, Homer Simpson, Entertainment ... Như một sự lựa chọn, bạn có thể chỉ định một tham chiếu đến một ResourceBundle theo cách : ...com.somedomainname.HomerPortlet... Bất cứ cách nào bạn sử dụng (cái đầu tiên thường tốt hơn cho các ứng dụng với yêu cầu định vị tối thiểu), các hiệu ứng mạng nhện cho người phát triển cũng như vậy. Những tính chất này thường được tạo bên trong một ResourceBundle và được làm hiệu lực thông qua đối tượng PortletConfig 3.5.2. PortletURL Khi xây dựng nội dung của portlet, điều cần thiết là xây dựng các URLs cung cấp khả năng gọi portal. Đây là cái cơ bản tạo nên tương tác trong portal. Nhằm mục đích cho phép việc tạo lập PortletURL đúng thực tế, có 2 sự cài đặt: ActionURL và RenderURL. Cả 2 đều được tạo từ giao diện RequestResponse interface bằng cách sử dụng các phương thức createActionURL() và createResponseURL() tương ứng. ActionURL: cung cấp khả năng đưa ra những yêu cầu hành động (action request) trên portal, để làm những việc như thay đổi chế độ portlet, thay đổi trạng thái cửa sổ, xác thực một form, v.v... RenderURL: cung cấp khả năng bỏ qua phương thức processAction() của portlet và đơn thuần triệu gọi phương thức hồi đáp (render), việc truyền thông số hồi đáp để điều khiển việc biểu diễn. RenderURL: cung cấp khả năng bỏ qua phương thức processAction() của portlet và đơn thuần triệu gọi phương thức hồi đáp (render), việc truyền thông số hồi đáp để điều khiển việc biểu diễn. Bạn có thể tìm thấy rất nhiều phương thức trong lớp giao tiếp PortletURL interface đáng chú ý : - setSecure(): cung cấp khả năng để chỉ định URL ở đâu nên dùng HTTP ở đâu thì không. Nếu nó không được sử dụng, nó tiếp tục với bất cứ thứ gì yêu cầu hiện tại chỉ định. Vì thế, bạn không phải chỉ định lặp lại nó. - setWindowState() : cho phép bạn thay đổi trạng thái cửa sổ của portlet. - addParameter(): thêm các thông số vào URL. - toString(): cung cấp một chuổi biểu diễn của URL. Chú ý rằng nó không đảm bảo một URL hợp lệ, như là portal có thể sử dụng token để viết lại URL. - setPortletMode() : cho phép bạn thiết lập chế độ của portlet. 3.5.3. Các chế độ của portlet Một chế độ portlet biểu diễn một trạng thái chức năng của một portlet. Đây được dùng bởi portlet để xác định làm thế nào để quản lý các yêu cầu hồi đáp. Điều đó, phụ thuộc vào chế độ, portlet sẽ hồi đáp những đánh dấu khác nhau. Các portlets có thể thay đổi chế độ của chúng như là một phần của quá trình xử lý yêu cầu hành động (action request). Thêm vào đó, một portlet có thể được cấu hình với những chế độ thích hợp khác nhau và hạn chế xa hơn tính sẵn sàng dựa trên chức năng. Bảng sau mô tả các chế độ portlet chuẩn được định nghĩa trong portlet API. Các chế độ của portlet - VIEW Sản sinh đánh dấu hình dung trạng thái và tính chất của portlet. Nhà phát triển cài đặt doView() của lớp GenericPortlet để cung cấp chức năng này. - EDIT Sản xuất đánh dấu để có thể thay đổi tính chất của portlet. Nhà phát triển cài đặt doEdit() của lớp GenericPortlet để cung cấp chức năng này. - HELP Cung cấp các cấp chức năng này để hướng dẫn cho portlet. Nhà phát triển cài đặt doHelp() của lớp GenericPortlet để cung cấp chức năng này. Một portal cũng có thể cung cấp các chế độ portlet tuỳ thích. Nhớ rằng điều đó phụ thuộc portal, không phụ thuộc portlet. Vì thế, nếu một portlet cài đặt chế độ portlet bổ sung, thì chúng sẽ không chuyển được giữa các container portlet khác nhau. portlet cần phải ghi đè phương thức doDispatch() để gọi phương thức hồi đáp thích hợp. Chẳng hạn, nếu bạn định nghĩa một chế độ portlet có tên "SPECIAL" phương thức doDispatch() sẽ gọi phương thức hồi đáp của nó, thông thường là doSpecial(). Tất nhiên là, vì bạn đang cài đặt phương thức, bạn có thể gọi bất cứ phương thức gì bạn muốn. 3.5.4. Các cửa sổ trạng thái Các cửa sổ trạng thái chỉ định portlet bao nhiêu không gian được sử dụng cho nó. Điều này cho phép portlet chỉnh sửa những hồi đáp của nó để thích hợp với trạng thái của cửa sổ. Bảng sau bao gồm những trạng thái cửa sổ được xác định bằng Portlet API. Trạng thái - NORMAL portlet sẽ chia màn hình với các portlet khác. Điều đó có nghĩa là portlet sẽ giới hạn các đánh dấu của nó (markup). - MINIMIZED portlet sẽ cung cấp ít đầu ra hoặc không. - MAXIMIZED portlet không chia sẻ màn hình với các portlet khác, vì thế portlet không bị giới hạn trong đánh dấu của nó (markup). Cũng giống như chế độ portlet, một portal có thể định nghĩa các cửa sổ trạng thái tuỳ ý, nó cũng phải được cấu hình trong mô tả triển khai portlet (portlet deployment descriptor). 3.5.5. Ngữ cảnh của Portlet PortletContext là một đối tượng wrapper cho ứng dụng portlet của bạn. Có một đối tượng PortletContext cho mỗi ứng dụng portlet. PortletContext cung cấp : Truy xuất biến khởi tạo Lấy và thiết lập các thuộc tính ngữ cảnh Ghi lại sự kiện Lấy tài nguyên ứng dụng (như hình ảnh, file XML ...) Lấy được một yêu cầu gửi đi để có sức mạnh đòn bẩy của servlet và JSPs trong portlet 3.5.6. Ngữ cảnh của Portal Một portlet có thể lấy một tham chiếu đến portal mà nó đang chạy trong đó thông qua đối tượng PortalContext. Việc gọi phương thức getPortalContext() của đối tượng PortletRequest sẽ trả về PortalContext. PortalContext cung cấp : - Tên của portal - thông qua phương thức getPortalInfo() - Các đặc tính của portal - qua phương thức getProperty() và getPropertyNames() - Những chế độ portlet được hỗ trợ - qua getSupportedPortletModes() - Những cửa sổ trạng thái được hỗ trợ - qua getSupportedWindowStates() 3.5.7. Các tham chiếu Portlet (Portlet Preferences) Nhằm thao tác tuỳ biến hoá và cá nhân hoá portlet của bạn, bạn cần thay đổi chút ít các tham số của portlet bằng nhiều cách. Những cái này gọi là portlet preferences (tham chiếu của portlet). Ví dụ cái portlet cổ điển là cái portlet thời tiết, và theo sau ví dụ đó, bạn có thể có một tham chiếu có tên "cities", với các giá trị biểu diễn zip code của những thành phố mà bạn cần biết thời tiết. Ghi chú rằng các tham chiếu chỉ dành cho việc cấu hình portlet, vì thế việc bảo trì danh sách tất cả các thành phố thích hợp trong một tham chiếu sẽ là không thích hợp cho dùng các preferences. Việc suy nghĩ về chúng theo ý nghĩa của lập trình hướng đối tượng, chúng sẽ là các thuộc tính của bản thân các portlets. Preferences được thao tác thông qua một đối tượng Object có cài đặt (implement) lớp giao tiếp PortletPreferences interface. Tất cả các giá trị tham chiếu được lưu trữ trong mảng String, vì thế bạn sẽ không thể lưu trữ toàn Object như bạn làm với thuộc tính yêu cầu hay phiên làm việc, cũng không có những thuận lợi trong khai báo kiểu, như bạn làm với các lối vào môi trường. Vì thế, nếu bạn đang lưu trữ các số dưới các tham chiếu, bạn sẽ cần tự chuyển đổi. Đặc biệt, lớp giao diện PortletPreferences interface cung cấp: - getNames(): sẽ trả về một bảng liệt kê Enumeration các tên các preferences thích hợp. - getValue(): truyền cho nó tên của tham chiếu bạn quan tâm, đi kèm với một giá trị mặc định (trong trường hợp nó không tìm thấy), và nó trả về phần tử đầu tiên của mảng các giá trị tham chiếu. - getValues(): truyền cho nó tên tham chiếu bạn muốn và một mảng String các giá trị mặc định và nó trả về một mảng String của các giá trị của nó. - setValue(): truyền cho nó tên tham chiếu và giá trị của tham chiếu đó, và nó thiết lập (cài đặt) nó là một phần tử đơn mảng String chứa đựng các giá trị. phương thức này đưa ra một biệt lệ nếu tham chiếu không bị thay đổi UnmodifiableException. - setValues(): truyền cho nó tên tham chiếu và một mảng String biểu diễn giá trị của tên đó, và nó thiết lập các giá trị tham chiếu. Phương thức này đưa ra một biệt lệ nếu tham chiếu không bị thay đổi UnmodifiableException . - isReadOnly(): truyền cho nó tên tham chiếu và nó trả về một giá trị Boolean xác định tham chiếu có thể thay đổi được hay không. - reset(): truyền cho nó tên tham chiếu và nó trả về một giá trị mặc định, nếu không, nó sẽ xoá tham chiếu. - store(): lưu trữ các tham chiếu. Bởi đó chỉ có thể hoàn thành bên trong processAction(), nó sẽ đưa ra một biệt lệ IllegalStateException nếu nó hoàn tất trong một lời triệu gọi hồi đáp, phương thức cũng sẽ đưa ra biệt lệ ValidatorException nếu không hợp lệ. - getMap(): trả về map của các tham chiếu. Map bao gồm các khoá String và một mảng String[ ] chứa các giá trị. Map này cũng không thể thay đổi. 3.5.8. Phiên làm việc Bởi vì portal được xây dựng trên cơ chế request - response (và chủ yếu dựa trên giao thức HTTP), phải có một vài cơ chế thích hợp để bảo trì trạng thái qua các triệu gọi. Chẳng hạn, không thể thấy việc xác thực người dùng (authenticate users) với mọi yêu cầu. Có rất nhiều kĩ thuật để quản lý phiên làm việc sessions, với cookies và mã hoá URL là 2 cách thông dụng nhất của ứng dụng Web (cookies được dùng dưới các hood bởi nhiều servlet container để implement HTTPSession interface). Session là điểm then chốt đối với nhà phát triển portlet, nhưng có nhiều cái để cài đặt chúng (implement), vì thế portlet API cung cấp giao tiếp PortletSession interface. Khi một client tạo một request, server gửi đi một định danh session trong response. Nếu client muốn kết nối vào session (phiên làm việc), client cung cấp định danh session đó cho các request tiếp sau của họ. PortletSession có thể được sử dụng để nắm giữ các thuộc tính. PortletSession hoạt động giống như HTTPSession trong mặt này, việc cung cấp khả năng lưu trữ cặp đôi khoá - giá trị (key-value ), với đối tượng bất kỳ. Có một điểm khác nhau chủ yếu PortletSession có 2 phần khác nhau : - APPLICATION_SCOPE thì tương tự như phạm vi HTTPSession. Một đối tượng được đặt trong phạm vi này là thích hợp cho tất cả các portlets bên trong phiên làm việc (session). - PORTLET_SCOPE chỉ đến khi một đối tượng là thích hợp chỉ một portlet đó. PORTLET_SCOPE là thống nhất trong cách đặt không gian tên cho một thuộc tính cho trước. Ví dụ, một thuộc tính nó tên là city.name sẽ được lưu trữ trong javax.portlet.p.47?city.name. ("47" là số định dạng được gán bên trong). Tên thuộc tính này ngăn cản namespace (không gian tên) xung đột với các portlets khác lưu trong biến session của chúng với các tên tương tự. - Mặc dù việc có một hệ thống đặc biệt để đặt tên những thuộc tính của nó, PORTLET_SCOPE lại không bảo vệ các thuộc tính của nó với các thành phần web khác. Thêm vào đó, ứng dụng namespace (không gian tên) là hoàn toàn thực hiện dưới hood. Bạn chỉ việc gọi các phương thức getAttribute() và setAttribute() để chỉ định PORTLET_SCOPE và sự chuyển đổi không gian tên namespace được thực hiện bởi đối tượng PortletSession. Để làm cho nó thuận lợi hơn, các thành phần web khác có thể nhận tính năng này thông qua phương thức PortletSessionUtil.decodeAttribute() bằng cách truyền tên thuộc tính đơn giản, ví dụ như "city.name". 3.5.9. JSPs và Servlet Bởi các ứng dụng portlets hoàn toàn mở rộng của các ứng dụng web, ở đây phải có một cơ chế để include JSP và servlet trong portlet. Dựa vào việc nghiên cứu đầu tiên về lớp GenericPortlet, nhiều nhà phát triển Web nghĩ, " Ôi, không! chúng ta đã trở lại những ngày của servlet xa xưa với việc nhúng các đánh dấu (markup)". Tuy nhiên, cũng giống như servlet, nhà phát triển nhận thấy việc sử dụng phương thức RequestDispatcher() là có ích để tránh cái gọi là "đặt tất cả trứng của mình trong một cái rổ " tức vấn đề đặt tất cả các markup của mình trong một servlet, và tất cả mã Java trong trang JSP, một nhà phát triển portlet có thể dùng PortletRequestDispatcher. Khi cài đặt (implement) phương thức hồi đáp của giao diện portlet hay đúng hơn là cài đặt một trong các phương thức "do_" của lớp GenericPortlet (chẳng hạn như doView, doEdit, doHelp ...), nhà phát triển có thể dùng PortletRequestDispatcher như sau : String reqPath = “/calView.jsp”;PortletRequestDispatcher prd = portContext.getRequestDispatcher(reqPath);prd.include(req, resp); Trong trường hợp này, ta phải chỉ định trang JSP của mình: calView.jsp, nó sẽ nằm trong thư mục gốc của ứng dụng portlet, mà ta sẽ chỉ tới với các dấu slash /. Bạn phải luôn bắt đầu dẫn với dấu slash hở /, và cung cấp một đường dẫn từ thư mục gốc của PortletContext (thường là thư mục gốc của ứng dụng portlet). Từ đó, bạn lấy PortletRequestDispatcher (prd) từ phương thức PortletContext (portContext). Sau đó bạn truyền cho các phương thức RenderRequest(req) và RenderResponse(resp)các tham số vào phương thức include của PortletRequestDispatcher(prd).đường Tương tự, ta có thể gọi một servlet bằng cách mô tả tên của nó (trong file mô tả triển khai ứng dụng Web web.xml). Chẳng hạn, ta có thể phải chỉ định một servlet như sau trong web.xml: chartorg.opensourceportals.ChartServlet0 Bởi vì ta đã đặt tên servlet của mình là "chart", nên ta có thể chỉ định nó như sau : String reqName = “chart”;PortletRequestDispatcher prd = portContext.getNamedDispatcher(reqName);prd.include(req, resp); Lúc này ta dùng phương thức getNamedDispatcher() với tên của servlet để lấy một Object PortletRequestDispatcher. Đây là một điểm quan trọng khác để ta xem xét nếu chọn phải làm như sau : String reqPath = “/calView.jsp?user=Jennifer”;PortletRequestDispatcher prd = portContext.getRequestDispatcher(reqPath);prd.include(req, resp); Vì tham số user được chỉ định trong chuỗi truy vấn, nó sẽ lấy theo thứ tự từ trước đến sau vài tham số hồi đáp khác được đặt tên user và truyền cho JSP. Bạn hầu như chắc chắn sẽ không chú ý đến vấn đề này, nhưng đó là những thứ phải ghi nhớ trong trường hợp bạn rơi vào cách ứng xử: việc chỉ định một chuỗi truy vấn để lấy lần lượt các tham số khác. Có nhiều hạn chế trong việc dùng Object HttpServletRequest. Những phương thức này không thích hợp để include servlet và JSP: getProtocol() getRemoteAddr() getRemoteHost() getRealPath() getRequestURL() getCharacterEnconding() setCharacterEncoding() getContent Type() getlnputStream() getReader() getContentLength() Những phương thức sau đều trả về null (trừ getContentLength trả về 0) nếu bị triệu gọi từ một servlet hay JSP được include bởi một Object PortletRequestDispatcher. Tuỳ thuộc vào việc làm thế nào bạn tạo PortletRequestDispatcher, bạn có thể không phải truy xuất đến các phương thức khác. Nhưng phương thức bổ sung này là không thích hợp việc truy xuất servlet và JSPs từ PortletRequestDispatcher được tạo bằng cách gọi getNamedDispatcher(). getPathInfo() getPathTranslated() getServletPath() getRequestURI() getQueryString() Những phương thức không sẵn có của HttpServletResponse : encodeRedirectURL() encodeRedirectUrl() setContent Type() setContentLength() setLocale() sendRedirect() sendError() addCookie() setDataHeader() addDateHeader() setHeader() addHeader() setlntHeader() addlntHeader() setStatus() containsHeader() Những phương thức mã hoá luôn trả về null, và containsHeader() luôn trả về trị false, nhưng những cái còn lại thì sẽ đơn giản không làm gì cả. Điều này có thể là một mã nguồn làm thất vọng lớn nếu bạn không cẩn thận, nhà phát triển ạ, bởi nó đơn giản chỉ không làm việc và sẽ không cho bất cứ một ghi chú nào. Java Portlet Specification đề nghị đối với việc sử dụng các phương thức tiếp theo của RequestDispatcher của các servlet và JSPs đã include. Trong khi điều này không có vẻ như một sự thoả thuận lớn, ghi chú là Apache’s Struts Framework dùng dùng phương thức forward RequestDispatcher trong Object ActionServlet của nó. Việc đưa ra thông dụng của Struts như là một framework ứng dụng Web, đó có thể làm nên một sự thúc đẩy (tác động) quan trọng trong việc thống nhất tích hợp portal trong nhiều cơ quan tổ chức. Điều đó không có nghĩa là nó không làm việc vô tổ chức, nhưng nó không là một định mệnh và sẽ được xem xét cẩn thận trong điều kiện của bạn và được testing với cài đặt portal của bạn. 3.5.10. Cấu tạo ứng dụng portlet Ứng dụng portlet được cấu tạo giống như ứng dụng Web trong đó ta có các tính năng sau : - Có thể bao gồm servlets, JSPs, classes, file JAR (java archives), và các file tĩnh khác. - Được đóng gói - tất cả các ứng dụng Web đều được đóng gói trong thư mục root chung. - Có thư mục WEB-INF/classes để lưu giữ các lớp độc lập có thể tải bởi classloader. - Có thư mục WEB-INF/lib để lưu giữ Java Archives (JAR) có thể tải bởi classloader. - Được đóng gói thành file Web Archive (WAR) Thêm vào các tính năng này, ứng dụng portlet còn bao gồm một file mô tả triển khai ứng dụng Web, được đặt tại WEB-INF/portlet.xml. File này được mô tả chi tiết ở chương sau "Portlet Application Deployment Descriptor.” 4. Phát triển ứng dụng và Worflow cho Portal Phần này đi sâu vào việc phát triển ứng dụng portlet theo chuẩn JSR 168 cho các server portal, nó hoàn toàn tương thích với chuẩn JSR 168. Nó cung cấp một cái nhìn khái quát về các khái niệm portlet cần thiết, kiến trúc portlet, và phát triển các tiến trình, bao gồm cả sự tương thích và triển khai (deployment). Ta sẽ xây dựng một portlet ứng với mỗi phần. Portal Enterprise mà ta sẽ dùng để xây dựng ứng dụng portlet là nền tảng portal eXo nó hỗ trợ chuẩn JSR 168 và là một giải pháp mã nguồn mở. Chúng ta sẽ tìm hiểu về kiến trúc của nền tảng portal eXo và tạo các portlet mẫu theo paradigm MVC, mà eXo cũng hỗ trợ cho phát triển portlet. 4.1 Kiến trúc portlet Đối với nhà phát triển, đặc tả portlet cung cấp một cách chuẩn mực để phát triển portlet, và vì thế làm cho mã portlet có thể dùng lại được trong thực tế. Hãy tưởng tượng việc có thể bảo trì chỉ một tập các mã portlet sẽ làm việc trên những portal tương thích tối thiểu chuẩn JSR168 nếu chỉ có vài thay đổi trong việc cấu hình. Đối với nhà quản trị IT, lợi ích chính nhất là lúc này những portlet thuộc lĩnh vực (hành chính) của họ hỗ trợ các nhà sản xuất tương thích JSR 168. Điều đó cho phép sự mềm dẻo lớn hơn với sự dính líu công việc kỹ sư một ít khi cung cấp những portlet của họ tại hội chợ triển lãm. Đối với nhà sản xuất, đặc tả tạo ra khả năng cung cấp tất cả các công cụ (tools) - từ IDE (môi trường tích hợp phát triển) đến các ứng dụng máy chủ - và nó tăng doanh số của các tool này. Một portal bao gồm những portlet cá nhân người dùng, chúng có thể được thêm vào bớt ra và tuỳ biến bởi người dùng. Các portlet là cái làm đẹp cho tầng trình bày của portal. Chúng là thành phần giao diện người dùng có thể tuỳ biến bởi use, và chúng có thể được thêm vào và bớt đi từ portal một cách dễ dàng. Chúng cũng xử lý yêu cầu người dùng và sản sinh nội dung theo yêu cầu thông qua portlet container . 4.1.1. Portlet Container Một portlet container được sử dụng để quản lý các portlet thông qua vòng đời của chúng. Container cho phép nhà phát triển gọi các phương thức chỉ định trong suốt thời gian sống của một portlet. Nó nâng các nhà phát triển lên quyết định phương thức nào được cài đặt (implement). Là một qui tắc tổng quát, các nhà phát triển nên thường kế thừa lớp GenericPortlet khi tạo các portlet. Lớp GenericPortlet gọi các phương thức hồi đáp chỉ định dựa trên chế độ hiện tại (curr ent mode) của portlet. Những phương thức này được mô tả trong bảng sau: Phương thức - doEdit được gọi bởi phương thức hồi đáp khi portlet ở chế độ EDIT. Chế độ EDIT nên được dùng với mục đích chỉ định biên soạn portlet. Ví dụ: nếu taọ một portlet danh mục vốn đầu tư chứng khoán và nó chứa đựng một danh sách các chứng khoán, khi ta nhấn edit ta sẽ có thể biên soạn danh sách này trong danh mục vốn đầu tư của mình (portfolio). - doView được gọi bởi phương thức hồi đáp khi portlet ở chế độ VIEW. Chế độ VIEW là chế độ chính cuả portlet. Nội dung chính của portlet sẽ hiển thị trong suốt chế độ này. Ví dụ: Nếu ta có một portlet xếp thứ hạng bóng đá, thứ hạng sẽ hiển thị trong chế độ VIEW. - do Help được gọi bởi phương thức hồi đáp khi portlet ở chế độ HELP. Chế độ HELP dùng hiển thị các hướng dẫn chỉ định về cách sử dụng portlet. Lấy ví dụ danh mục vốn đầu tư chứng khoán, chế độ HELP có thể mô tả cách thích hợp để biên soạn (edit) và nhập các chứng khoán cũng như các kí hiệu của chúng vào trong portlet. Các phương thức khác có thể được truy cập với hoặc không kế thừa từ lớp GenericPortlet. Những phương thức này cho phép nhà phát triển nắm giữ những chức năng khác nhau mà không cần thiết trên chế độ hiện tại của portlet. Những phương thức bổ sung này được trình bày trong bảng sau: Phương thức init(): được gọi bởi container khi portlet được tạo và được sử dụng để khởi tạo portlet và chuẩn bị để sử dụng nó. Lấy ví dụ, nếu portlet của bạn cần phải load những cấu hình chỉ định từ CSDL hay nguồn dữ liệu bên ngoài, thì phải mất nhiều thời gian thực hiện việc đó. destroy(): được gọi bởi container khi container phá huỷ portlet, bằng cách cho phép bạn xoá sạch bất cứ thứ gì cần chú ý đặc biệt. Lấy ví dụ, nếu một kết nối CSDL được mở, thì nó cho phép bạn đóng những kết nối mở và xoá gọn gàng khi portlet bị phá huỷ. processAction(): được gọi bởi container khi user xác nhận thay đổi trên portlet. Đây là phương thức thiết yếu để bạn có thể xử lý dữ liệu đã xác nhận bởi user từ một portlet. Ví dụ, bạn có thể có một form yêu cầu ngày sinh của user. Khi user xác nhận form, processAction() được gọi, cho phép bạn xử lý thông tin và quyết định hiển thị cái gì đến user, như việc thay đổi chế độ portlet (mode) nếu bạn muốn. render(): được gọi bất cứ khi nào portlet cần vẽ lại. Trong hầu hết các trường hợp, bạn sẽ không cần nắm giữ phương thức này vì doView, doEdit, và doHelp tồn tại trong lớp GenericPortlet và tự động được gọi bởi phương thức render. Bốn phương thức mà bạn sẽ tương tác nhiều nhất khi phát triển một portlet là doView(), doEdit(), doHelp(), và processAction(). Những phương thức này xuất hiện tương tự như servlet vì chúng gửi yêu cầu (request) và trả lời (response) các đối tượng. Tuỳ thuộc vào những phương thức được sử dụng với chúng, những Object này có thể được sử dụng để: Đạt được sự truy xuất đến đối tượng tham chiếu của portlet nhằm duy trì trạng thái. Lấy tham số được xác nhận bởi user thông qua form; Đạt được thông tin phiên làm việc (session); Thu thập thông tin bảo mật về user, như thông tin user-role; Thay đổi những biểu hiện khác nhau của portlet, và làm thế nào nó được hồi đáp. Chẳng hạn, tiêu đề có thể bị thay đổi thông qua đối tượng response. Chương III: Mô hình kiến trúc tối ưu để xây dựng ứng dụng Portal. 1. Giới thiệu về các mô hình phát triển Web thông dụng hiện nay 1.1. Mô hình tổng quan trong phát triển Web Hình 3.1 : Mô hình chung của các hệ thống Web Một ứng dụng Web (Web Application) thường bao gồm các thành phần chủ yếu sau : Web Server Web Server là chương trình ứng dụng đón nhận tất cả các yêu cầu của người sử dụng, phân tích các yêu cầu này xem người sử dụng cần gì và sau đó sẽ gọi đến những ứng dụng dịch vụ cần thiết và sau đó trả kết quả về cho người sử dụng. Các ứng dụng dịch vụ ở đây có thể là Application Server cũng có thể là các hệ thống quản lý File đơn giản. Kết quả được Web Server trả về là dữ liệu có cấu trúc dạng HTML để Web Browser có thể hiểu được và hiển thị cho người sử dụng. Application Server Đây là hệ thống thực hiện các yêu cầu mà Web Server đưa ra. Toàn bộ những việc sử lý nghiệp vụ sẽ được thực hiện ở Application Server. Application Server có thể là những hệ thống có độ phức tạp khác nhau và các Application Server này sẽ được phát triển tùy theo độ phức tạp của nghiệp vụ. Để xử lý được các yêu cầu của người sử dụng thì Web Application Server có thể phải sử dụng đến các hệ quản trị cơ sở dữ liệu, hay các hệ thống dịch vụ bên ngoài hoặc hệ thống File System. File System Trong trường hợp đơn giản một ứng dụng Web chỉ có các thành phần cơ bản là các File dạng HTML tĩnh (có nội dung không thay đổi) và được lưu trữ bởi hệ thống quản lý File. Khi người sử dụng có yêu cầu thì Web Server sẽ sử dụng hệ thống File System để đọc các File này và trả kết quả trở lại cho Browser. Database System Đối với những ứng dụng Web tương đối phức tạp thì thường phải có lưu trữ dữ liệu và cập nhật dữ liệu, để làm được điều này thì các Application Server phải sử dụng các hệ quản trị cở sở dữ liệu. 1.2. Mô hình JSP Trong phần trước chúng ta đã đưa ra mô hình tổng quan của một hệ thống Web. Chúng ta thấy rằng các hệ thống Web (Web Application) thì phần quan trọng nhất là Application Server. Việc phát triển các Application Server có thể ứng dụng nhiều mô hình khác nhau tùy thuộc vào các ứng dụng cụ thể. Trong phần này chúng ta sẽ đề cập đến một trong những mô hình này. Mô hình này thường được gọi là mô hình JSP 1 (JSP Model 1 archirecture) Hình 3.2 : Mô hình JSP Mô tả hoạt động : Trong mô hình JSP 1, các yêu cầu (request) từ phía người sử dụng sẽ được gửi tới Application Server và được các File JSP đón nhận và thực hiện việc phân tích, giải quyết các yêu cầu này rồi trả kết quả lại cho người sử dụng. Nếu cần thiết thì hệ thống sẽ truy xuất trực tiếp cơ sở dữ liệu. Như vậy chúng ta thấy đây là mô hình logic 2 lớp, các File JSP sẽ bao gồm cả việc thực hiện các quá trình nghiệp vụ của hệ thống, trực tiếp giao tiếp với cơ sở dữ liệu và thực hiện luôn cả chức năng hiển thị (trả kết quả cho người sử dụng). Dễ dàng nhận thấy mô hình này rất khó kiểm soát chương trình vì hệ thống không có sự phân tầng dẫn đến tình trạng khi sửa đổi một phần nào đó sẽ làm ảnh hưởng đến tất cả các thành phần khác của hệ thống. 1.3. Mô hình MVC 1.3.1. Định nghĩa Mô hình MVC là mô hình phát triển phần mềm có sự phân định các thành phần mô hình (model), hiển thị (View), và điều khiển (control) một cách độc lập. Việc này giúp cho hệ thống hoạt động tốt hơn và dễ kiểm soát hơn vì các phần tách biệt sẽ làm cho việc phát triển hệ thống được thực hiện một cách độc lập. Hình 3.3 : Mô hình MVC Model : Mô hình dữ liệu và các quy trình nghiệp vụ mà hệ thống cần thực hiện để thông qua đó hệ thống có thể cập nhật dữ liệu. View : Thực hiện việc trình diễn nội dung của phần mô hình cho người sử dụng. Để làm được việc này phần View sẽ nhận những thông tin cần thiết từ phía bộ phận điều khiển để có dữ liệu hiển thị cho người sử dụng. Người sử dụng sẽ giao tiếp trực tiếp với hệ thống thông qua thành phần này. Controller : Là bộ phận điều khiển chịu trách nhiệm thực thi tất cả các yêu cầu của người sử dụng. Việc sử lý các quy trình nghiệp vụ sẽ được thực hiện tại thành phần này của hệ thống. Sau khi thực hiện xong thành phần này sẽ tiến hành trả kết quả lại cho bộ phận View để hiển thị cho người sử dụng. Điểm mạnh của mô hình MVC là có sự phân chia rõ ràng giữa các thành phần của hệ thống điều này giúp cho hệ thống họat động một cách hiệu quả hơn và chương trình cũng dễ dàng cập nhật hơn. 1.3.2. Mô hình JSP Model 2 architecture JSP Model 2 archirtecture là mô hình lập trình sử dụng JSP nhưng áp dụng kiến trúc kiểu MVC đây là mô hình kiến trúc được sử dụng rất nhiều trong các ứng dụng Web hiện nay. Hình 3.4 : JSP Model 2 architecture Trong mô hình này bộ phận điều khiển sẽ là một Servlet. Servlet này sẽ có chức năng đón nhận tất cả các yêu cầu của người sử dụng và thực hiện việc sử lý nghiệp vụ cần thiết sau đó trả kết quả trở lại cho bộ phận hiển thị để trả lại kết quả lại phía Browser. Bộ phận hiển thị (View) sẽ là các File JSP chuyên làm nhiệm vụ nhận kết quả của Controller và thực hiện việc tạo ra (render) dữ liệu dạng HTML để trả về cho người sử dụng. Bộ phận Model: Là bộ phận thực hiện việc mô hình hóa các quy trình xử lý dữ liệu cần thiết của hệ thống. 2. Đặc điểm của các ứng dụng chạy trên nền Portal (Portlet) 2.1. Mô hình hoạt động của Portlet Portlet là một ứng dụng Web nhưng bản thân nó không hoạt động độc lập được mà phải tích hợp với một Portal Server. Hình vẽ sau mô tả quy trình hoạt động của Portlet Hình 3.5: Mô hình hoạt động của Portlet Giải thích mô hình : Trong mô hình này Portlet là một bộ phận trên trang Web hiển thị trên Browser của người sử dụng. Portlet sẽ không giao tiếp trực tiếp với người sử dụng mà thông qua Portal Server. Tất cả các yêu cầu (request) gửi tới đều thông qua Portal Server, Portal Server sẽ làm nhiệm vụ invoke request tới Portlet Container và Portlet Container sẽ làm nhiệm vụ xác định Portlet nào phải thực hiện yêu cầu. Sau đó Portlet sẽ sử lý yêu cầu và gửi kết quả trở lại Portal Server. Portal Server lúc này sẽ làm nhiệm vụ đẩy dữ liệu nhận được từ Portlet ra vùng dữ liệu được quy định dành cho Portlet này. Như vậy ở đây chúng ta thấy quá trình vận hành của một Portlet là rất phức tạp thông qua nhiều bước. Trong đó có quá trình giao tiếp giữa Portal Server và Portlet là quan trọng nhất. Nếu có bất cứ sự thay đổi nào từ phía này sẽ làm ảnh hưởng đến phía kia và ngược lại. Chính vì vậy nên cần thiết phải có một chuẩn giao tiếp giữa Portal Server và Portlet. Hiện nay chuẩn thông dụng nhất và được hầu hết các hãng lớn (IBM, Sun, Oracle, ...) thống nhất sử dụng đó là JSR 168. 2.2. Các yêu cầu đặt ra đối với các ứng dụng Portlet. 2.2.1. Tính độc lập với các Portal Engine. Các ứng dụng Portlet cần phải được xây dựng độc lập với các Portal Engine có nghĩa là các Portlet cần phải chạy tốt trên các ứng dụng Portal Engine khác nhau. Điều này đảm bảo khi nâng cấp thành phần nền tảng của hệ thống thì không cần phải chỉnh sửa lại các ứng dụng và sẽ bảo toàn được đầu tư xây dựng các ứng dụng. 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. Ứng dụng Portlet cần phải hoạt động được với nhiều hệ quản trị cơ sở dữ liệu khác nhau. Đây là một trong những yêu cầu rất quan trọng vì yêu cầu thay đổi hệ quản trị cơ sở dữ liệu là một yêu cầu hoàn toàn thực tế đặc biệt trong bối cảnh hiện nay hệ quản trị cơ sở dữ liệu được sử dụng tại Cổng giao tiếp điện tử Hà Nội là hệ quản trị cơ sở dữ liệu PostgreSQL là một hệ cơ sở dữ liệu tuy đáp ứng được nhu cầu hiện tại và trong tương lai gần nhưng khó có thể đáp ứng được yêu cầu trong tương lai xa nếu khối lượng thông tin ngày càng lớn. 3. Mô hình truy xuất cơ sở dữ liệu 3.1. Mô hình truy xuất cơ sở dữ liệu theo kiểu truyền thống Hình 3.6 : Mô hình truy xuất cơ sở dữ liệu kiểu truyền thống Theo mô hình này hệ thống sẽ thực hiện việc truy xuất cơ sở dữ liệu thông qua các JDBC Driver. Các JDBC Driver này sẽ khác nhau đối với các hệ quản trị cơ sở dữ liệu khác nhau. Việc viết các câu truy vấn cơ sở dữ liệu sẽ được thực hiện theo từng hệ quản trị cơ sở dữ liệu. Mô hình này có những ưu điểm và nhược điểm sau: Ưu điểm : Tốc độ thực hiện nhanh. Cách viết lệnh theo kiểu truyền thống. Nhược điểm : Khi thay đổi hệ quản trị cơ sở dữ liệu sẽ phải thực hiện viết lại chương trình. Không tiện dụng đối với người lập trình. 3.2. Mô hình truy xuất dữ liệu sử dụng Hibernate Framework 3.2.1. Sơ lược về Hibernate Framework Hibernate là một framework cho phép thực hiện ánh xạ các đối tượng và sơ sở dữ liệu đồng thời cung cấp một dịch vụ truy vấn thông qua một hệ lệnh gọi là HQL (Hibernate Query Language). Đặc điểm của Hibernate là có thể thực hiện được với mọi cơ sở dữ liệu mà không cần thay đổi lại các câu lệnh. Nếu muốn thay đổi hệ quản trị cơ sở dữ liệu thì chỉ cần thay đổi cấu hình để truy xuất tới hệ quản trị cơ sở dữ liệu. Đây chính là ưu điểm lớn nhất của Hibernate Framework. Bên cạnh ưu điểm này thì việc sử dụng Hibernate cũng có nhược điểm là làm cho việc thực hiện truy vấn sẽ chậm hơn là cách truy vấn trực tiếp thông qua JDBC. Tuy nhiên việc tốc độ chậm đi này là không đáng kể. Bởi vậy Hibernate vẫn được sử dụng hàng ngày càng rộng rãi nhờ những ưu điểm không thể tranh cãi của nó. 3.2.2. Đề xuất mô hình truy xuất cơ sở dữ liệu Như ở phần trên đã đề cập các ứng dụng Portal (Portlet) được sản xuất ra cần phải có khả năng làm việc với nhiều hệ quản trị cơ sở dữ liệu khác nhau. Bởi vậy cần phải có mô hình truy xuất cơ sở dữ liệu hợp lý. Mô hình truy xuất cơ sở dữ liệu truy xuất cơ sở dữ liệu này phải đảm bảo không phụ thuộc vào các hệ quản trị cơ sở dữ liệu. Hình 3.7 : Mô hình truy xuất cơ sở dữ liệu Trong mô hình truy xuất này việc thực hiện truy xuất cơ sở dữ liệu sẽ được thực hiện thông qua Hibernate Framework. Các câu lệnh truy vấn sẽ được viết theo ngôn ngữ truy vấn HQL. Việc thực hiện truy xuất tới các hệ quản trị cơ sở dữ liệu sẽ hoàn toàn do Hibernate thực hiện. Hibernate sẽ thực hiện ánh xạ giữa ngôn ngữ HQL và SQL đối với từng hệ quản trị cơ sở dữ liệu khác nhau. Với mô hình truy xuất cơ sở dữ liệu này người sử dụng sẽ không cần quan tâm đến hệ quản trị cơ sở dữ liệu được sử dụng. 3.3. Các yêu cầu đối với mô hình kiến trúc - Tuân thủ mô hình MVC Như đã phân tích ở các phần trên chúng ta thấy đối với các ứng dụng Web nói chung và các ứng dụng Portal nói riêng thì mô hình kiến trúc MVC là mô hình phù hợp. Bởi vậy nên mô hình kiến trúc được lựa chọn cần phải sử dụng mô hình MVC. - Tuân thủ 100% JSR 168 Như chúng ta đã đề cập ở phần trên việc tuân thủ chuẩn JSR 168 là yếu tố rất quan trọng để đảm bảo tính sẫn sàng cho việc thay đổi thành phần lõi của hệ thống. Bởi vậy mô hình kiến trúc đưa ra phải đảm bảo việc tuân thủ chặt chẽ JSR 168. 3.4. Lựa chọn mô hình kiến trúc tối ưu Hình 3.8: Mô hình kiến trúc Portlet Kiến trúc của Portlet tuân thủ chặt chẽ mô hình MVC. Mọi thông tin được gửi đến hệ thống thông qua Portlet Container sẽ được thành phần điều khiển (Controller) tiếp nhận xử lý. Quá trình xử lý sẽ được thực hiện bởi các Action cụ thể tại đây các mô hình nghiệp vụ sẽ được sử dụng để giải quyết các bài toán nghiệp vụ cụ thể. Nếu cần thiết hệ thống sẽ truy xuất đến các tác nhân ngoài như hệ thống quản lý File các dịch vụ WebServeice hoặc các hệ thống quản trị cơ sở dữ liệu. Việc truy xuất đến các hệ quản trị cơ sở dữ liệu sẽ được thực hiện thông qua Hibernate Framework. Sau khi xử lý kết quả sẽ được gửi đến tầng hiển thị để thực hiện việc hiển thị. Tại tầng hiển thị (View) các File JSP thực hiện việc hiển thị thông tin đến người sử dụng. Thành phần Controller và các Action sẽ tuân thủ các phương thức được định nghĩa trong đặc tả JSR 168. Điều này sẽ đảm bảo hệ thống vừa tuân thủ JSR 168 đồng thời vẫn sử dụng được mô hình MVC chuẩn Kết luận Trong thời gian tốt nghiệp, em đã luôn cố gắng tìm tòi, nghiên cứu các tài liệu để hoàn thành các công việc được giao. Kết hợp với các kiến thức đã học ở nhà trường đã giúp em tìm hiểu kỹ, hiểu sâu về các khía cạnh của vấn đề. Trên đây là phần trình bày đề tài tốt nghệp: Tìm hiểu về Portlet và ứng dụng trong cổng giao tiếp điện tử. Để đảm bảo việc xây dựng chương trình hỗ trợ phát triển các ứng dụng Portal (Portlet) thì việc đưa ra một mô hình kiến trúc chuẩn cho các ứng dụng Portal là rất cần thiết. Sau khi nghiên cứu, phân tích và đánh giá các mô hình phát triển Web cũng như các tính chất cơ bản của Portal thì mô hình được lựa chọn để sử dụng là mô hình MVC kết hợp sử dụng các phương thức định nghĩa bởi JSR 168. Ngoài ra việc truy xuất cơ sở dữ liệu sẽ được thực hiện thông qua Hibernate Framework là một ứng dụng trung gian giúp cho việc thực hiện các ứng dụng Portal có thể hoạt động với nhiều hệ quản trị cơ sở dữ liệu khác nhau. Song do thời gian và trình độ có hạn nên em không tránh khỏi những thiếu sót. Em rất mong sự quan tâm đóng góp ý kiến và chỉ bảo của thầy cô để đề tài của em được hoàn thiện hơn; giúp em tự tin hội nhập vào mọi môi trường làm việc cụ thể, phục vụ hiệu quả hơn cho xã hội để xứng đáng với tấm bằng kỹ sư Công nghệ thông tin. Em xin chân thành cảm ơn các thầy! Hà Nội, Ngày tháng năm 2007 SINH VIÊN Nguyễn Thị Mai Tài liệu tham khảo 1. (Website giới thiệu về giải pháp Upotal) 2. (Website giới thiệu các giải pháp mã nguồn mở) 3. 4. (Website giới thiệu về Portal) 5. (Website giới thiệu phần mềm của hệ thống VIE Portal) 6. dot.net.com (Website giới thiệu đôi nét về Website truyền thống và xu hướng làm việc trên Portal hiện nay