Portal

Phần mở đầu Trong sự phát triển mạnh mẽ của Internet, thì các Website giữ một vai trò đặc biệt quan trọng trong mọi lĩnh vực của đời sống nhân loại. Với đam mê sáng tạo và chinh phục thế giới, công nghệ thông tin đã và đang thay đổi từng ngày. Các thế hệ website ra đời, cải tiến liên tục, cùng với Web Service, sự trợ giúp của công nghệ Mobile Agent - một chương trình thay mặt người dùng thực hiện công việc tìm kiếm và xử lý thông tin trên Internet khái niệm Website truyền thống được chuyển thành “Website thông minh” với sự trợ giúp của dịch vụ Search Engine, một công cụ cho phép tìm kiếm và lọc thông tin trên cơ sở các từ khoá được xác lập bởi người dùng và dịch vụ phân loại thông tin – Category. Từ đó, thuật ngữ “Website thông minh” hay “Cổng điện tử” - Portal được hình thành. Trong bối cảnh hội nhập kinh tế quốc tế, Việt Nam trở thành thành viên chính thức của tổ chức thương mại thế giới WTO tháng 11 năm 2006, cả dân tộc Việt Nam bước vào sân chơi lớn của thế giới. Những yêu cầu về cải cách hành chính, phát triển chính phủ điện tử, thương mại điện tử càng trở nên cấp thiết và mang tính sống còn. Ở nước ta, một số địa phương cũng rất quan tâm phát triển công nghệ Portal như thành phố Hà Nội, thành phố Hồ Chí Minh, Quảng Nam và một số địa phương khác… Các địa phương này đã xây dựng được cổng thông tin điện tử cho riêng mình, để nó trở thành một công cụ phục vụ đắc lực trong việc quản lý, điều hành các hoạt động kinh tế, xã hội. Xuất phát từ thực tế đó, những người làm công nghệ thông tin chúng tôi hướng nghiên cứu của mình vào các vấn đề liên quan tới thiết kế, xây dựng các cổng điện tử, đặc biệt là chính phủ điện tử, thương mại điện tử với các dịch vụ hành chính công phục vụ công dân, doanh nghiệp và các nhà đầu tư tại Việt Nam. Đó cũng là 1 lý do quan trọng để JavaVietnam phối hợp với PCWorld VN và HaNoi Aptech tổ chức kỳ thi Lập trình viên trong năm DOTY 2006 . Sau đây là các bài tổng hợp từ diễn đàn Javavietnam của các thành viên trong kỳ 2.

Tổng quan về Portal 1. Khái niệm về Portal 1.1. Định nghĩa Portal Portal, tên đầy đủ là Web Portal, là một hệ thống hoạt động trên Web, định danh và xác thực người dùng đăng nhập, từ đó sẽ cung cấp một giao diện web để người dùng dễ dàng truy cập, khai thác thông tin và dịch vụ cũng như thao tác, tuỳ biến các công việc tác nghiệp của mình một cách nhanh chóng và đơn giản. Portal có các tính năng giúp người quản trị thu thập, quản lý nhiều nguồn thông tin khác nhau, từ đó phân phối chúng dưới dạng các dịch vụ cho từng người dùng khác nhau tuỳ thuộc vào nhóm quyền, vào nhu cầu cũng như mục đích của người dùng đó. Portal thực hiện việc này hết sức linh động, từ những công việc như tìm xem và đặt mua sách trong một kho hàng trực tuyến, xem và thay đổi thông tin về sinh viên và giáo viên trên các ứng dụng quản lý giảng dạy, đến việc đăng và chia sẻ các thông tin, tài nguyên, bài viết trên các diễn dàn hay cung cấp việc truy cập thống nhất và thuận lợi đến các thông tin nội bộ trong một website của công ty... Portal như một cổng vào vạn năng cho người dùng tìm kiếm thông tin và tác nghiệp một cách thuận lợi và dễ dàng.

Hình 1.1. Hình ảnh về một Portal

Sự phát triển của web portal Khái niệm “Web Portal” đã xuất hiện từ khá lâu, chỉ sau khi ra đời WWW một thời gian ngắn. Ban đầu, các website chỉ như các báo quảng cáo điện tử, chứa các thông tin của một doanh nghiệp để khách hàng của họ có thể truy cập để xem và theo dõi một cách thuận tiện. Lúc đó, Portal được dùng để chỉ một trang chủ, chứa các liên kết đến các nội dung trong một website nào đó. Ngoài ra, nó còn chứa một công cụ tìm kiếm nội bộ, cho phép người dùng dễ dàng tìm các thông tin nằm trong nội dung các trang web. Chính vì vậy, cái tên Web Portal mang ý nghĩa: một cái “cổng” để truy nhập vào website. Web Portal tựa như một danh bạ Web (Web directory) liên kết với một search engine đơn giản, tất cả chỉ dùng nội bộ trong một website. Sau thời gian đầu, các website không chỉ mang ý nghĩa đại diện để giới thiệu của các công ty, chúng trở thành những công cụ tác nghiệp trực tuyến rất thuận tiện dành cho cả khách hàng, đối tác và các nhân viên cũng như ban quản trị doanh nghiệp. Do đó các tính năng quan trọng nên tích hợp vào một website như các tính năng đăng nhập và xác thực người dùng, các tính năng quản lý nội dung, tính năng cá nhân hoá, đa ngôn ngữ cũng như các tính năng tác nghiệp cụ thể đối với từng website. Web Portal cung cấp khả năng tích hợp các tính năng này một cách dễ dàng thành một trang web duy nhất. Web Portal đầu tiên kiểu này là Americal Online (AOL - http://www.aol.com/ ) . Hiện tại, Web Portal không chỉ là một “cổng vào”, dẫn đường người dùng truy cập website, mà đã trở thành một siêu website, nghĩa là ngoài chứa đựng mọi thông tin và dịch vụ cần có như một website thông thường, nó còn có khả năng quản trị giao diện cũng như nội dung của nhiều website, thêm bớt không những nội dung mới mà còn các dịch vụ mới, tích hợp các module thông dụng nhất như các forum, chat room, blog hay RSS feed…và quan trọng là, cung cấp việc truy cập các nguồn thông tin rất đa dạng và khác nhau này chỉ thông qua một lần đăng nhập duy nhất (single sign-on). Một Web Portal nổi tiếng hiện nay là My Yahoo! (http://my.yahoo.com/) của Yahoo, người dùng chỉ cần đăng nhập một lần duy nhất trong trang này để truy cập vào một trang web riêng mà Yahoo đã thiết kế sẵn, với nhiều module có sẵn như tin tức, bản tin thời tiết, bản đồ… Ngoài ra ở trang My Yahoo cũng có các link liên kết đến các ứng dụng web của Yahoo quen thuộc như Messenger, Mail, Group, Blog, Music… và người dùng sẽ không cần phải đăng nhập lại. Sang Tiếng Việt, Web Portal được dịch là “Cổng giao tiếp điện tử”, “Cổng giao dịch điện tử” hoặc ngắn gọn hơn: “Cổng điện tử”. Tuy nhiên, cũng như tên tiếng Anh của chúng, các từ này thật sự chưa thể phản ánh hết được chính xác thế nào là một Portal.

Để làm rõ bản chất của Portal chúng ta đưa ra bảng so sánh giữa Portal với một Website thông thường sau đây. 1.2. So sánh Portal với một Website thông thường Portal

Website thông thường

+ Portal hỗ trợ khả năng đăng nhập một lần Một website thông thường không có được khả tới tất cả các tài nguyên được liên kết với năng đăng nhập một lần. Portal. Nghĩa là, người dùng chỉ cần một lần đăng nhập là có thể vào và sử dụng tất cả các ứng dụng đã được tích hợp trong Portal đó mà người dùng này có quyền. + Portal hỗ trợ khả năng cá nhân hóa theo Thường không hỗ trợ, nếu có chỉ ở mức độ rất người sử dụng. nhỏ, không phải là đặc điểm nổi bật. Đây là một trong những khả năng quan trọng của Portal, giúp nó phân biệt với một website thông thường. Portal cá nhân hóa nội dung hiển thị, thông thường đây là sự lựa chọn một cách tự động dựa trên các quy tắc tác nghiệp, chẳng hạn như vai trò của người sử dụng trong một tổ chức. Ví dụ khi một người mua hàng đăng nhập vào hệ thống, Portal sẽ hiện ra một danh sách các sản phẩm mới. Hoặc nếu cần quan tâm đến các lĩnh vực khảo cổ thì Portal có thể cung cấp các thông tin bảng danh sách các đồ cổ. + Khả năng tùy biến. Đây là một khả năng tiêu biểu của một Portal.

Một vài Website có nhưng chỉ dừng lại ở mức độ dựng sẵn, người dùng chỉ có thể lựa chọn một vài giao diện đã có, mà không tự mình thay đổi từng mục một cách tùy ý.

Ví dụ một giao diện Portal có mục thông tin thời tiết, chúng ta có thể bỏ phần thông tin này đi nếu chúng ta không quan tâm đến nó. Hoặc chúng ta có thể thay đổi cách hiển thị của Portal. Ví dụ như thay vì hiển thị bằng font chữ màu xác định chúng ta có thể thay nó bằng chữ màu đỏ, hay có thể tự thay đổi giao diện của Portal nếu mặc định chức năng A được đặt sau chức năng B, nếu không thích chúng ta có thể thay đổi lại thứ tự hiển thị này. Đặc tính này tương tự như màn hình desktop của chúng ta. Chỉ sử dụng các liên kết để tới các site khác + Liên kết truy cập tới hàng trăm kiểu dữ nhưng nội dung chủ yếu vẫn chỉ tập trung liệu, kho dữ liệu, kể cả dữ liệu tổng hợp trong trang đó. hay đã phân loại. Portal nó có khả năng liên kết tới tài nguyên dữ liệu rộng lớn, gồm nhiều kiểu dữ liệu từ dữ liệu thông thường đến siêu dữ liệu.

- Không hỗ trợ + Portal hỗ trợ rất tốt khả năng liên kết và hợp tác người dùng. Portal không chỉ liên kết chúng ta với những gì chúng ta cần mà còn liên kết với những người mà chúng ta cần. Khả năng liên kết này được thực hiện bởi các dịch vụ hợp tác. 1.3. Các đặc trưng cơ bản của Portal 1.3.1 Chức năng tìm kiếm (Search function). Chức năng tìm kiếm là dịch vụ đầu tiên cần phải có của tất cả các Portal. Sau khi người sử dụng mô tả loại thông tin mà mình cần thông qua các từ khoá hoặc tổ hợp các từ khoá, dịch vụ này sẽ tự động thực hiện tìm kiếm thông tin trên các Website có trên Internet và trả lại kết quả cho người dùng. Thời gian thực hiện của dịch vụ tìm kiếm này rất nhanh, do vậy rất tiện lợi cho người dùng. 1.3.2. Dịch vụ thư mục (Directory service) Đối với những người dùng không muốn tìm kiếm thông tin qua các từ khoá, họ có nhu cầu tìm kiếm thông tin theo một chủ đề, lĩnh vực nào đó, thì có thể sử dụng dịch vụ thư mục phân loại thông tin. Dịch vụ thư mục là dịch vụ thực hiện phân loại và sắp xếp thông tin trên các website theo chủ đề có thể có nhiều chủ đề con trong một chủ đề và có thể tiếp tục phân tách xuống các mức thấp hơn. 1.3.3. Ứng dụng trực tuyến (Online desktop application). Bao gồm các ứng dụng phổ biến nhất của Internet, hiện nay có các ứng dụng điển hình như : - Thư điện tử: Các Portal lớn như Yahoo, Excite, v.v… thường cung cấp các tài khoản điện tử (E-mail account) miễn phí cho người dùng. Dịch vụ này rất có ý nghĩa vì người dùng có thể nhận/gửi tại bất cứ địa điểm nào của Internet. - Lịch cá nhân: Một số Portal cung cấp dịch vụ “lịch cá nhân - calendar” miễn phí cho người dùng. Dịch vụ này giúp người sử dụng có thể sử dụng lịch cá nhân mọi nơi trên Internet. - Hội thoại trực tuyến: Dịch vụ này cho phép nhóm người dùng hội thoại trực tuyến với nhau thông qua môi trường Internet, không phụ thuộc vào khoảng cách địa lý giữa họ. Có thể liệt kê nhiều loại dịch vụ trực tuyến khác như dịch vụ hỗ trợ kỹ thuật trực tuyến giữa các nhà sản xuất với khách hàng của mình… - Các dịch vụ khác: Một trong những dịch vụ hấp dẫn người sử dụng là bưu thiếp điện tử. Thay vì gửi bưu thiếp qua đường bưu điện thông thường, ngay nay người sử dụng có thể gửi bưu thiếp chức mừng người thân của mình thông qua mạng Internet. 1.3.4. Cá nhân hoá các dịch vụ (Personalization or Customization). Cá nhân hoá là dịch vụ đặc trưng quan trọng của Portal. Trên cơ sở các thông tin của từng khách hàng cụ thể, nhà cung cấp có thể tạo ra các dịch vụ mang tính định hướng cá nhân, phù hợp với yêu cầu, sở thích của từng khách hàng riêng biệt của mình. Thông qua đó các nhà cung cấp có khả năng tăng cường mối quan hệ với khách hàng, duy trì được sự tín nhiệm của khách hàng đối với nhà cung cấp.

Cá nhân hoá các dịch vụ được tiến hành thông qua dữ liệu thông tin cá nhân về khách hàng (customer profiles). Dữ liệu này chứa các thông tin mang tính cá nhân như nghề nghiệp, thói quen, sở thích v.v… từ những thông tin cá nhân này, các nhà cung cấp có khả năng giới hạn cung cấp các thông tin và các dịch vụ mà khách hàng thực sự quan tâm muốn có. Có nghĩa là tránh được việc cung cấp các thông tin và dịch vụ không cần thiết có thể sẽ gây khó chịu cho khách hàng, và thậm chí dẫn đến quyết định ngừng sử dụng dịch vụ của nhà cung cấp. 1.3.5. Cộng đồng ảo (Virtual community hay Collaboration). Cộng đồng ảo là một “một địa điểm ảo” trên Internet mà các cá nhân, các doanh nghiệp có thể “tập hợp” để giúp đỡ, hợp tác với nhau trong các hoạt động thương mại. Nói một cách khác “cộng đồng ảo” mang lại cơ hội hợp tác cho các cá nhân, tổ chức doanh nghiệp mà ranh giới địa lý không còn có ý nghĩa. Sau đây là một số ví dụ về cộng đồng ảo: - Hội thoại trực tuyến – Online chat: Thông qua dịch vụ này người ta có thể triển khai các hội nghị mà không cần phải tập trung toàn bộ cán bộ công nhân viên ở các địa phương trong phạm vi cả nước về một địa điểm cụ thể nào đó. - Hỗ trợ trực tuyến - Online support : Tại đây khách hàng có thể nhận được trực tiếp các hỗ trợ, tư vấn của các nhà sản xuất về sản phẩm mà khách hàng đã lựa chọn. 1.3.6. Một điểm tích hợp thông tin duy nhất (Comporate Portal) Đặc trưng này cho phép đơn vị cung cấp cho người sử dụng dùng một điểm truy nhập duy nhất để thu thập và xử lý thông tin từ các nguồn khác nhau, hoặc sử dụng các ứng dụng để khai thác kho tài nguyên thông tin chung. Như chúng ta đã biết, có rất nhiều thông tin hàng ngày cần phải được xử lý và chuyển đến người dùng dưới nhiều nguồn khác nhau, ví dụ như E-mail, news, tài liệu, báo cáo, các bài báo, audio và các video files, v.v… sẽ rất khó khăn cho người dùng nếu các thông tin này được xử lý một cách riêng rẽ; Comporate Portal cho phép sử dụng các công cụ tích hợp để xử lý các nguồn thông tin này, do vậy năng suất lao động xử lý các thông tin của người dùng sẽ được nâng cao. 1.3.7. Kênh thông tin (Channel) Portal cũng cho phép xây dựng các liên kết (connector) tới các ứng dụng hoặc Portal khác. Một Portal khác hoặc một Website thông thường khác có thể cung cấp nội dung thông tin của mình trong kênh thông tin của Portal. Kênh thông tin là đặc tính rất mới của Portal, cho phép xây dựng các dịch vụ truy cập, xử lý các thông tin nằm bên trong mạng Intranet của một tổ chức, và sau đó tổ chức hiển thị kết quả xử lý tin trên kênh thông tin của Portal. Từ những tính năng của portal nêu trên thì ta có thể hình dung một dịch vụ mà hệ thống Portal cung cấp :

- Các dịch vụ cơ bản: Post bài định dạng HTML/Document, Danh sách liên kết, Upload/Download Files, Thao tác ảnh… - Các dịch vụ giao tiếp công cộng:

Forum, Thông báo, Thăm dò - Bỏ phiếu… - Các dịch vụ cung cấp thông tin: Thông báo, Bản tin... - Các dịch vụ tìm kiếm: Tìm kiếm, Phân loại … - Các dịch vụ trợ giúp người dùng: Thông tin cá nhân, Lịch biểu… - Các dịch vụ tác nghiệp: Quản lý nội dung, Hợp tác dự án, Quản lý bán hàng, quản lý nhân sự… Lợi ích của hệ thống Portal Hệ thống Portal hỗ trợ cộng đồng người dùng trực tuyến, các cán bộ, nhân viên, các đối tác và các nhà cung cấp... dưới nhiều hình thức kết hợp khác nhau. Cơ sở hạ tầng Portal giúp việc khởi tạo, tích hợp, quản lí và cá nhân hóa toàn diện các thông tin và ứng dụng cho mỗi người dùng riêng biệt phục vụ các nhu cầu và sở thích của một cộng đồng riêng biệt. Các lợi ích thực sự của hệ thống Portal này đem lại nhìn từ khía cạnh hiệu quả ứng dụng thực tế đó là: · Nâng cao hiệu quả làm việc cho các cá nhân và tô chưc, đối tác... nhờ truy cập bảo mật, tích hợp tới các thông tin và ứng dụng liên quan, cũng như truy cập tổng thể tới tất cả các cá nhân, thông tin, tổ chức và các nhà cung cấp từ bất kì đâu, bất kì khi nào. · Cải thiện các tiến trình hợp tác nhờ luồng thông tin tốt hơn giữa con người và các ứng dụng, và nhờ các môi trường cộng tác giúp giảm thời gian để chuyển đổi thông tin thô thành tri thức. · Giảm gánh nặng của việc triển khai và quản lí thông tin và các dịch vụ ứng dụng trong một tô chưc. · Duy trì, quản lý, mở rộng, nâng cấp, tái sử dụng dễ dàng, tiết kiệm chi phí đầu tư để xây dựng lại hệ thống. · Cho phép các hãng thứ 3 tham gia vào việc cung cấp ứng dụng hệ thống, các dịch vụ trung gian... Khả năng này làm phong phú, đa dạng khả năng úng dụng và triển khai của hệ thống Portal. 1.4. Phân loại Portal. Việc phân loại Portal có thể có nhiều cách khác nhau. Nếu căn cứ vào đặc trưng của Portal người ta chia Portal thành các loại như sau :

1.4.1. Consumer Portal Cung cấp nhiều lựa chọn cho việc tìm kiếm, chuyển, E-mail, tự sửa khuôn dạng, lựa chọn tin tức, calendar, quản lý địa chỉ liên hệ, các cuộc hẹn, các lưu ý, chú thích, các địa chỉ website, real-time chat và các chức năng Intranet, v.v… 1.4.2. Vertical Portal Chuyên cung cấp các thông tin và dịch vụ cho một lĩnh vực chuyên môn, khoa học, kinh tế cụ thể nào (mang tính chuyên ngành). 1.4.3. Horizontal Portal Nội dung bao trùm nhiều chủ đề (mang tính diện rộng), phục vụ các mối quan tâm khác nhau, hỗ trợ bằng các chức năng dịch vụ phong phú, phục vụ cộng đồng, phục vụ tổ chức hành chính.

Portal khách hàng

Portal B2B

Portal cho người lao động

Portal cho các nhà đầu tư

Cơ sở hệ thống Portal theo chiều ngang Cơ sở Portal theo chiều ngang 1.4.4. Enterprise Portal Cung cấp các dịch vụ truy xuất thông tin từ mọi nguồn tài nguyên thông tin trong mạng Intranet của một tổ chức qua một cổng truy cập duy nhất. 1.4.5. B2B Portal Cung cấp các dịch vụ định hướng theo mối quan hệ tương tác thông tin hai chiều giữa các doanh nghiệp (B2B) trong môi trường thương mại điện tử. 1.4.6. G2G Portal Cung cấp các dịch vụ hành chính công theo mối quan hệ tương tác thông tin hai chiều giữa các cơ quan hành chính nhà nước (G2G) trong môi trường trao đổi thông tin điện tử.

1.5. Các kỹ thuật của hệ thống Portal. 1.5.1. Portlet Portlet là giao diện người dùng, là các module tương tác nhiều mức cho phép tích hợp vào Portal các ứng dụng web khác nhau. Các Portlet này sinh ra các đoạn trang (fragment), các đoạn trang này được Portal ghép lại thành một trang hoàn chỉnh .

Portlet thực thi trong môi trường thời gian thực được gọi là Portlet Container, các Portlet trình bày nội dung của chúng trong một cửa sổ hiện trên trang Portal, tương tự như cửa sổ trong màn hình (desktop). Cửa sổ của Portlet có một thanh tiêu đề chứa, các nút điều khiển cho phép người sử dụng mở rộng và thu nhỏ nó [13]. Một Portlet có thể hiển thị trên một trang web như một cửa sổ cá nhân nhỏ, Portlet là nội dung bên trong cửa sổ, nó không phải là bản thân cửa số đó. Các Portlet bao gồm nhiều mức, cho phép người sử dụng giao tiếp với nó để thực hiện công việc trong môi trường Portal. 1.5.2. Phân loại Portlet và các dịch vụ web Giống như dịch vụ web hướng dữ liệu, các Portlet dựa trên kiến trúc hướng dịch vụ, nó cho phép các công ty sử dụng lại các thành phần của phần mềm để nhanh chóng xây dựng các ứng dụng trong các Portal mới.

Không giống như các dịch vụ web hướng dữ liệu, các Portlet tóm lược các dịch vụ tác nghiệp ở mức cao bao gồm các tương tác người dùng, các lưu đồ và các trình diễn tùy biến. Portlet địa phương (Local Portlet) Các Portlet địa phương là các Portlet thực thi ở bên trong một máy chủ Portal. Khi một máy chủ Portal sinh ra một trang và những thứ cần thiết trong một đoạn trang, nó gọi Code Portlet và sử dụng giao diện tiền định nghĩa. JSR168 định nghĩa một giao diện Portlet địa phương chuẩn cho môi trường J2EE.

Portlet từ xa (Remote Portlet) Portlet từ xa là các Portlet thực thi bên ngoài một máy chủ Portal, hoặc bên trong một máy chủ của một tổ chức hoặc ở một vị trí từ xa. Khi một Portal cần đoạn trang, nó sẽ gọi Portlet từ xa thông qua SOAP.

Giao thức WSRP cung cấp định nghĩa một chuẩn giao diện SOAP cho các Portlet từ xa. Vấn đề quan trọng của Portlet từ xa là tách các Portlet ra khỏi tổ chức và môi trường Portal. Để thực hiện việc này có thể : •

Sử dụng các Portlet thành phần thứ ba để tạo thành các Portal mới.

•

Phân bổ trách nhiệm tạo và bảo trì các chức năng ứng dụng giữa các đơn vị khác nhau.

•

Sử dụng các công cụ phát triển, các phương thức và các kiến trúc khác nhau để tạo ra các chức năng Portlet.

•

Đạt được thông qua môi trường phát triển trong vấn đề tải, thực thi, quản lý và bảo mật.

WebService cho các Portal từ xa (WSRP) Chuẩn WSRP là giao thức định nghĩa giao diện SOAP tạo khả năng cho các Portal và các ứng dụng không phải là Portal kết nạp vào các Portlet từ xa. WSRP được định nghĩa bởi tổ chức OASIS, một tổ chức phi lợi nhuận toàn cầu có chức năng phát triển, tập hợp, và thông qua các chuẩn. Đặc biệt WSRP được thực hiện khi SOAP gọi phiên HTTP. Các đoạn trang, đặc biệt là HTML được trả lại như là một thành phần của payload SOAP.

WSRP và các chuẩn WSIA có liên quan Sự ra đời của định nghĩa WSRP là kết quả làm việc của ủy ban OASIS và WSIA (dịch vụ web cho ứng dụng hợp tác).

Phần lớn các nhà sản xuất đều tuyên bố dự định của họ sẽ hỗ trợ Portal thông qua chuẩn WSRP. Ủy ban WSRP và WSIA bao gồm BEA, Bowstreet, CA, Epicentric, Fujitsu, IBM, Novell, Oracle, Plumtree, SAP, Sun, TIBCO, WebCollage, và một số hãng khác... Các chi tiết kỹ thuật của chuẩn WSRP WSRP định nghĩa các giao diện như sau :

• Một tập hợp giao diện hỗ trợ sự kết hợp ban đầu giữa Portal và Portlet. • Một giao diện cho phép một Portal yêu cầu một đoạn trang từ một Portlet. • Một giao diện cho phép một Portal đưa tương tác của người sử dụng vào Portlet. • Một tập hợp các giao diện cho phép Portal và Portlet cộng tác và lưu trữ đa cấu hình của một Portlet. Portlet Container Các Framework Portal cung cấp môi trường thực thi thời gian thực cho các Portlet được biết đến như là một Portlet Container. Sự tổng hợp nội dung không phải là chức năng liên kết với Portlet Container nhưng nó lại liên kết với Portal hoặc Portal server.

Mô tả ngữ cảnh trong đó tồn tại một Portlet Portal service Portlet dựa vào container cung cấp hạ tầng cơ sở cần thiết để đáp ứng cho một môi trường Portal. Cơ sở hạ tầng Portal cung cấp tập hợp các dịch vụ cốt lõi được yêu cầu bởi các Portlet. - Dịch vụ cá nhân hóa tạo khả năng cho các Portlet sử dụng các công cụ và các thông tin profile để sửa đổi nội dung nhằm mục đích thỏa mãn người dùng. - Dịch vụ thông báo sự kiện tạo khả năng cho các Portlet đáp ứng nhiều yêu cầu mà không ảnh hưởng đến môi trường của Portal. - Dịch vụ liên lạc cung cấp sự giao tiếp từ Portlet này tới Portlet khác. - Quản trị nội dung đáp ứng kết nối dễ dàng tới tài nguyên ứng dụng hay nội dung ảo nào đó. - Các dịch vụ tìm kiếm đáp ứng việc tìm kiếm đa tiêu chí trên nhiều nguồn tài nguyên dữ liệu.

-

Dịch vụ hợp tác tạo khả năng cho người dùng liên lạc và tham dự vào các cộng đồng người sử dụng cùng quan tâm đến một lĩnh vực. - Dịch vụ quản trị người dùng và nhóm người dùng cho phép người sử dụng gia nhập vào một Portal, tự quản lý tài khoản và các thông tin mà mình ưa thích. - Dịch vụ biến đổi trang đáp ứng rất nhiều thiết bị client. - Các dịch vụ khác cung cấp hoặc quản lý • Profile người dùng và các kiểu dữ liệu liên tục. • Dịch vụ điều khiển truy cập và bảo mật bao gồm chứng thực và cấp quyền người dùng. Portal Server Portal server là một máy chủ ứng dụng chuyên biệt cung cấp logic tác nghiệp cho một ứng dụng Portal, đặc biệt được xây dựng trên nền máy chủ ứng dụng J2EE, Portal cung cấp sự phát triển và cơ sở hạ tầng thời gian thực cho Portal. Một Portal Server thường làm việc liên kết với một Web Server để xử lý yêu cầu của client. Portlet có thể được xem như là một cách mở rộng chức năng của Portal Server.

Máy chủ Portal mở rộng một máy chủ ứng dụng để hỗ trợ ứng dụng Portal Theo ví dụ dưới đây, Portal yêu cầu xử lý một kịch bản. Đây là kịch bản được sinh ra khi người sử dụng yêu cầu trang Portal từ thiết bị client. 

Thiết bị client (sử dụng Web Browser hoặc PDA) gửi một yêu cầu HTTP cho trang Portal tới máy chủ Web.



Máy chủ Web nhận ra yêu cầu và gửi tiếp yêu cầu đó tới máy chủ Portal.



Máy chủ Portal sẽ quyết định nếu yêu cầu này chứa một hành động hướng mục đích tới một Portlet trên trang Portal. Portal sẽ yêu cầu Portlet container gọi Portlet xử lý hành động này .



Portlet container yêu cầu mỗi Portlet liên kết đến trang Portal gửi lại một đoạn trang (fragment) với nội dung được yêu cầu .



Các Fragment này được quay trở về máy chủ Portal, nơi đó chúng được tổng hợp để tạo nên một trang Portal.



Trang Portal được gửi trở lại thiết bị client để hiển thị.

Dưới đây là sơ đồ các bước xử lý yêu cầu kịch bản của một hệ thống Portal:

Yêu cầu HTTP

Máy chủ Portal

Portlet Container

Portlet

Nếu có yêu cầu hành động tới một Portlet

Máy chủ Web

Gửi Yêu cầu Hành động yêu cầu

Hành động xử lý

Gọi yêu cầu Gửi đoạn trang

Trả lại Trang Portal

Trả lại Trang Portal

Trả lại đoạn trang Tổng hợp các đoạn trang

Trả lại đoạn trang

Trang Portal yêu cầu xử lý kịch bản.

Báo cho mỗi Portlet trên trang

Thiết bị Client

1.6 Các bước xây dựng Portal 1.6.1 Lập kế hoạch Đây là giai đoạn xây dựng giải pháp tổng thể, đáp ứng nhu cầu quản lý và chiến lược của khách hàng. Kế hoạch tổng thể bao gồm: phạm vi của dự án, các mục tiêu chiến lược của khách hàng và hiện trạng của hệ thống bao gồm cả các mối quan hệ thông tin nội bộ với bên ngoài. 1.6.2 Thiết kế tổng thể Thiết kế tổng thể là giai đoạn xây dựng kiến trúc ứng dụng cho phép chuyển hoá từ các yêu cầu nghiệp vụ sang ứng dụng Portal. Cũng như các phần mềm ứng dụng, kiến trúc ứng dụng bao gồm mô hình chức năng và mô hình hoạt động. Mô hình chức năng là toàn bộ các chức năng nghiệp vụ của hệ thống, mô tả cấu trúc, phân cấp các thành phần của hệ thống, các trao đổi thông tin và các giao diện giữa các thành phần của hệ thống. Mô hình hoạt động mô tả kiến trúc phần cứng (hạ tầng phần cứng, phương thức tổ chức mạng), kiến trúc phần mềm và các thành phần dữ liệu, các ràng buộc (tốc độ xử lý, mức độ bảo mật,…) và phần quản trị hệ thống (lập kế hoạch nguồn lực, chuyển giao hệ thống, sao lưu, khôi phục). Kiến trúc ứng dụng cũng phải chỉ rõ mức độ đáp ứng của các giải pháp đối với chiến lược kinh doanh và phương thức đạt được yêu cầu đó. 1.6.3 Phát triển Portal Phát triển là giai đoạn cài đặt giải pháp đã được xây dựng ở các bước trên, bao gồm: thiết kế, lập trình, kiểm tra, cài đặt sử dụng hệ thống Portal. Các phân tích viên thông thường tham gia vào giai đoạn này với vai trò kiểm soát viên để đảm bảo cho hệ thống đáp ứng được yêu cầu của người dùng. Các giai đoạn hình thành và phát triển Portal được thể hiện qua sơ đồ sau (hình 1.13)

Giá trị của thông tin và dịch vụ Website

(1) - Thông tin hoạt động cơ quan - Thông tin quảng cáo

PortalPortal

(2) - Một số dịch vụ đặc trưng của Portal như EMail, search, forum,.. - Thử nghiệm các dịch vụ trên Portal dưới hình thức mở rộng phạm vi một sô áp dụng của Intranet với khả năng tương tác một chiều của

(3) - Tiếp tục làm giàu nội dung của Portal. - Tiếp tục bổ sung các dịch vụ cơ bản. - Cung cấp khả năng tương tác hai chiều cho các dịch vụ thử nghiệm của giai đoạn

(4) - Định nghĩa lại qui trình làm việc, qui trình điều hành quản lý. - Thực hiện cải cách tổ chức phù hợp với qui trình mới - Chính thức áp dụng các ứng dụng trực tuyến đã được thử nghiệm

(5) - Thực hiện các dịch vụ công của chính phủ điện tử.

Độ phức tạp của cơ sở hạ tầng (phần cứng và phần mềm)

Các giai đoạn của lộ trình xây dựng và triển khai Portal

1.7. Các công nghệ xây dựng Portal. 1.7. 1 Công nghệ xây dựng các phân hệ Một hệ thống Portal gồm 3 phân hệ chính : tổ chức trang thông tin; kiểm soát truy cập và quản lý thành viên; xử lý yêu cầu và xây dựng nội dung. -

Tổ chức trang thông tin (Page Aggregation) + Nội dung của trang được lấy từ kho dữ liệu; + Có khả năng trình bày trang theo những mẫu có sẵn trong kho dữ liệu;

-

Kiểm soát truy cập và quản lý thành viên (Security & Member services) + Nhiệm vụ quản lý thành viên và kiểm soát tuy cập. + Dữ liệu lấy từ kho có thể được tổ chức dưới dạng LDAP, CSDL ActiveDirectory,

… -

Xây dựng yêu cầu và xây dựng nội dung :

+ Nhiệm vụ xử lý các yêu cầu của người sử dụng, tạo nội dung của các trang thông tin. + Thiết lập sẵn các kênh thông tin (Channel/Portlet) như : tìm kiếm (Search), làm việc theo nhóm (Collaboration),… 1.7. 2. Công nghệ để xây dựng Portal Hiện nay hai công nghệ chủ yếu được sử dụng để phát triển Portal là J2EE và .NET, để thấy được bản chất của các công nghệ này chúng ta đưa ra bảng so sánh giữa hai công nghệ như sau: Bảng so sánh giữa J2EE và .NET MicroSoft.NET

J2EE

Các đặc tính

Ngôn ngữ lập trình C# Programming

Java programming

C# và Java đều phát triển từ C/C++.

Language

language

Hầu hết các tính năng cơ bản của C/C++ đều được sử dụng trong hai ngôn ngữ này. C# có vay mượn một số

ý

tưởng

về

thành

phần

(component) của JavaBeans như Properties/attributes, events… Java có thể chạy trên mọi flatform (Unix, Windows) hỗ trợ Java VM.

C# chỉ có thể chạy trên nền Windows. Ngôn ngữ lập trình xây dựng các trang thông tin ASP (Active Server

(JSP) Java Server

ASP+ sử dụng VB.NET, C# và một

Page)

Page

số ngôn ngữ khác để xây dựng module trong việc tạo trang. Tất cả các module này sẽ được dịch thành native code thông qua common language runtime. JSPs

sử

dụng

đoạn

mã

Java

(snippets, hoặc JavaBean references), compiled into Java byte codes (either on

deman

depending

or

batch-compiled,

on

the

JSP

implementation) Cơ chế thực hiện chương trình IL Common

Java Virtual Machi

.NET common language runtime cho

Language Runtime

and CORBA IDL

phép các module được viết bằng

and ORB

nhiều ngôn ngữ khác nhau cod thể sử dụng các component dùng chung trên platform windows Java's Virtual Machine cho phép các module viết bằng Java chạy trên bất kỳ platform nào hỗ trợ JVM CORBO cho phép các Module viết bằng các ngôn ngữ khác nhau có thể sử dụng các component chạy trên bất cứ flatform nào mà có cài đặt ORB

Giao diện trong công cụ lập trình Win forms and Web

Java Swing

Win form and Web Form được hỗ

forms

trợ thông qua MS Visual Studio. Java Swing được hỗ trợ trong nhiều công cụ Java IDE

Khả năng kết nối CSDL và trao đổi dữ liệu ADO+ và SOAP-

JDBC, EJB, JMS,

.NET sử dụng ADO+

trên cơ sở Web

XML librraries

Services

(XML 4J JAVXP)

JAVA sử dụng JDBC để kết nối dữ liệu đối với CSDL Trong việc trao đổi dữ liệu giữa các ứng dụng : ADO+ sử dụng chuẩn XML để trao đổi dữ liệu trên nền HTTP (gồm cả AKA và SOAP)

1.7. 3 Mô hình hoạt động của J2EE và .NET a.. Mô hình hoạt động của J2EE

Clie nt Tie r

Business Parners Or Other system

Web Services Technology (SOAP, UDDL, WSDL..)

Applets Appliactions Fire wall

Web Browser

PDA

HTTP

BOP

HTTP Containe r

Serviets

JSPs

We b Se rvice Containe r

EJBs

Property Protocol

Back-End Syste m

Context Respository

Connectors SQL

Database

Property Protocol Exiting System Lagacy System ERP System

Mô hình hoạt động công nghệ J2EE b. Mô hình hoạt động của .NET

Web Services Technology (SOAP, UDDL, WSDL..) Business Partners Or

Other System

Clie nt Tie r

Business Parners Or Other system

Web Services Technology (SOAP, UDDL, WSDL..)

Applets Appliactions

Web Browser

PDA

HTTP

HTTP

Fire wall

Containe r ASP.NET We b Se rvice Containe r

.NET Managed Components

Property Protocol

Back-End Syste m

Context Respository

Web Services Technology (SOAP, UDDL, WSDL..)

Connectors SQL

Database

Property Protocol MainFrame System

Business Partners Or Other System

Mô hình hoạt động công nghệ .NET

So sánh các Portal trên thế giới Bài dịch từ A Service Oriented Architecture for Portals Using Portlets Asif Akram, Dharmesh Chohan, Xiao Dong Wang, Xiaobo Yang and Rob Allan CCLRC e-Science Centre, CCLRC Daresbury Laboratory

Warrington WA4 4AD, UK 1. Các tiêu chí đánh giá Có một sự khó khăn khi so sánh các Portal vì mỗi Portal trong số chúng dựa trên những yêu cầu khác nhau và các công nghệ khác nhau. Việc so sánh portal dựa trên những tiêu chí đánh giá khác nhau. Những tiêu chí này dựa trên lõi và những yêu cầu lựa chọn từ Portal: a.JSR-168 compliant (Tuân theo JSR-168) : JSR-168 là yêu cầu khá quan trọng cho việc phát triển portal từ những developer tự do cho đến những nhà cung cấp Portal API cụ thể. b.Ease to installation (Tính dễ dàng cài đặt) : các portal có ý nghĩa là một presentation layer cho business logic sẵn có và không nên mang đến sự phức tạp cho giải pháp. Việc đánh giá ở đây dựa trên các yêu cầu để bắt đầu, ví dụ: cấu hình database, framework có chứa web-container hay ko? Hầu hết các portal sử dụng Tomcat container và dễ dàng cài đặt c.Documentation Standard (Tài liệu chuẩn) : việc phát triển Portal tương tự như phát triển Web Application ví dụ Servlet và JSP, nhưng vẫn còn những công việc phụ thuộc vào Portal Framework. Tài liệu của Portal Framework với các ví dụ được viết sẵn sẽ rất quan trọng. Đây là tiêu chí đánh giá sự hoàn hảo, sự chính xác và chất lượng tài liệu của mỗi Portal Framework bao hàm cả Administrator/User Guides

d.Online Support (Hỗ trợ trực tuyến): tài liệu không trả lời hết và nhắm vào các câu hỏi của tất cả các lập trình viên, và thỉnh thoảng một lập trình viên có thể cần sự hỗ trợ của các framework developer. Trong tiêu chí này, việc đánh giá dựa trên chất lượng, sự nhanh chóng, sự tương ứng của các hồi đáp của các developer cho các truy vấn. Tiêu chí này cũng bao gồm việc sửa chữa Wiki, tính linh hoạt khi hỗ trợ những đặc điểm mới e.Portal Management (Quản lý Portal) : việc deploy các portlet trong Portal Framework yêu cầu việc cấu hình những mô tả deploy khác nhau. Một vài trong số đó là Portlet API như portlet.xml và yêu cầu J2EE như web.xml, phân còn lại cụ thể đối với các Portal Framework. Tiêu chí này bao gồm chức năng quản trị, ví dụ: thêm user, gán quyền cho các user, gán đề mục cho các portlet và và chức năng của user để tùy biến các portlet theo các yêu cầu khác nhau, chẳng hạn: layout, skin, thêm hoặc xóa các portlet. f.Portlet Resources (Các tài nguyên Portal) : thông thường, những Portal thường đi kèm với các portlet tiện ích có thể reuse chẳng hạn Mail Portlet, Calendar Portlet và Search Portlet. Trong tiêu chí này, việc đánh giá dựa trên tính hữu dụng và tính reuse của các portlet đi kèm với Portal g.Performance & Scalability: thiết kế kiến trúc của Portal Framework là điều quyết định khả năng thực thi của nó. Những Portal là những layer bổ sung cho SOA (Service Oriented Architecture) và vì thế có khả năng làm chậm đi khả năng thực thi của các service. Việc cung cấp chức năng portal cơ bản là không đủ trong một môi trường thương mại mà ở đó tốc độ thực thi và tính thương mại là rất quan trọng. Tiêu chí này đánh giá dựa trên giới hạn của thời gian khởi động, thời gian load portlet, thời gian truy cập database... h.Security (bảo mật) : hầu hết các Portal Framework đi kèm với cơ chế bảo mật default là user login với password. Kỹ thuật authentication & authorization (xác thực và phân quyền) này không đủ trong thương mại hoặc những project khoa học. Trong tiêu chí này, việc đánh giá các khả năng bảo mật bổ sung của Portal Framework chẳng hạn Java Authentication & Authorization Service (JAAS), Java Open Single Sign On (JOSSO) & cấu hình SSL i.Technology Used (Công nghệ sử dụng) : những Portal Framework khác nhau sử dụng những công nghệ lựa chọn khác nhau không phải là một phần của Portlet API. Tiêu chí này đánh giá các công nghệ phổ biến khác nhau được sử dụng bởi những Portal Framework khác nhau như Struts, JSF, Spring, Hibernate, Tiles, EJB và Web Service j.Portal Features (Các đặc điểm của Portal) : các Portal Framework không chỉ là những portal/portlet container host các portlet khác nhau. Mà hầu hết các Portal Framework đi kèm với các chức năng bổ sung để phát triển các portal J2EE trong thực tế chẳng hạn Content Management System (CMS), Workflow, các công cụ Administrator Management, các công cụ Framework Monitoring. Tiêu chí này đánh giá các đặc điểm sẵn có cũng như tiêu chuẩn và khả năng sử dụng chúng trong Portal Framework\ k.Server Dependency (Sự phụ thuộc server) : portlet API là một mở rộng của servlet API và không cần những đặc điểm cao cấp của J2EE, nhưng trong thực tế hầu hết Web Application là J2EE Application sử dụng EJB cho persistence. Web Service cũng có thể được sử dụng để đóng gói và trao đổi... Vì thế Portal Framework không chỉ giới hạn trong servlet container như Tomcat. Sẽ là hữu dụng hơn nếu như các Portal Framework có thể deploy trên những server khác nhau và trong tiêu chí này việc đánh giá tập trung vào tính tương thích của các Portal Framework với những server thương mại và mã nguồn mở khác nhau l.WSRP standard compliant (Tuân theo chuẩn WSRP) : portlet API là presentation layer cho Web Application, nhưng không cần thiết client chỉ dựa trên Web; chuyển đổi sang desktop client cũng là một lựa chọn. WSRP specification tạo nên khả năng sử dụng portal/portlet trong những ứng

dụng không phải Web chẳng hạn Java Swing. Tiêu chí này đánh giá việc hỗ trợ WSRP trong các framework 2. Đánh giá các Portal Rất khó khăn để đánh giá hết tất cả những open source Portalvì có rất nhiều Portal mà các developer lựa chọn tùy theo tính dễ dàng phát triển, sự giàu có của các chức năng, sự tùy biến trong giao diện, và kiến trúc có khả năng gắn nối. Việc đánh giá chỉ nằm trong danh sách các Portal dưới đây: -uPortal: theo sự sử dụng rất lớn trong các học viện -eXo: theo sự phổ biến -Liferay: theo sự phổ biến, giao diện người dùng và chức năng lựa chọn -Stringbeans: theo sự dễ dàng sử dụng a.uPortal

uPortal là một Portal Framework được sử dụng rộng rãi trong các học viện và nó chủ yếu nhằm vào những yêu cầu của các tổ chức này. uPortal là một Portal Framework rất ổn định và đã được ra đời thậm chí trước cả JSR-168 specification, theo đó uPortal đã áp dụng những kỹ thuật ko theo chuẩn được gọi là channel. uPortal mặc dù đã tuân theo JSR-168 nhưng hầu hết những đặc điểm sẵn có trong uPortal vẫn dựa trên tùy biến và giải pháp đã phát triển với các channel adapter hơn là các portlet nguyên thủy. uPortal hỗ trợ portlet thông qua Pluto Portlet Framework. uPortal cũng là open source Portal Framework hỗ trợ nhiều kiểu portal nhất: từ Java portal đến HTML portal, từ text portal đến XML portal. uPortal có thể sử dụng Central Authentication Service (CAS) để điều khiển truy cập các ứng dụng xác thực dựa trên “khi nào”, “ai”, “từ đâu”, và “dịch vụ gì”. Kiểu xác thực này rất mạnh mẽ trong môi trường hỗn tạp như các trường đại học/cao đẳng. Rất dễ dàng để cấu hình các group và các permission service là yêu cầu quyết định trong môi trường này với nguồn thông tin cục bộ. uPortal hỗ trợ các portlet tuân theo JSR-168 thông qua adapter và yêu cầu các file cấu hình chuẩn như portlet.xml và web.xml Trước đây, tài liệu liên quan đến uPortal không được quan tâm tốt và không được cập nhật thường xuyên. Các tài liệu về uPortal đặt ở nhiều nơi khác nhau: website uPortal, wiki, email list, issue management system của uPortal (JIRA) và những nguồn khác. uPortal hỗ trợ đặc tả WSRP và uPortal có thể được sử dụng như một WSRP với WSRP4J implementation reference b.eXo Platform

eXo Platform định nghĩa như một portal và một CMS. Thông thường eXo được sử dụng như một portal tích hợp; eXo cung cấp cho các user khả năng truy cập tùy biến vào hệ thống thông tin của công ty và các tài nguyên. Thông qua môi trường Web, eXo cung cấp business information cho phép chuyển đổi và quản lý data của nó cũng như việc thực thi các xử lý business trái ngược nhau

eXo là enterprise portal tuân thủ JSR-168 xây dựng từ những module khác nhau. Nó dựa trên JSF, Pico Container, JbossMX và AspectJ. WSRP cũng được hỗ trợ trong eXo. eXo cũng hỗ trợ những công nghệ khác nhau bằng cách implement những cầu nối khác. eXo Platform đi kèm với hai phiên bản, “express” và “enterprise” edition. Không có nhiều sự khác nhau giữa hai phiên bản này trong giới hạn các chức năng và các đặc điểm mà chỉ là sự khác nhau của các container ví dụ Servlet Container và EJB Container. Express edition được deploy trong servlet engine trong khi đó enterprise edition được deploy trong application server J2EE 1.3 đầy đủ. Cả hai phiên bản này đều được deploy thành công trong Tomcat 5.0 và JBoss 4.1 Giống như những Portal Framework khác, có nhiều tập hợp các porlet đi kèm với eXo Platform. Các portet liên quan MVC, liên quan Web, liên quan navigation, liên quan user/admin. Các porlet liên quan đến workflow và WSRP cũng được chứa trong tập hợp này. eXo mang đến một layer (Struts) giữa portal và bất kỳ application Struts nào có sẵn bên trong các portlet, các Struts application này có thể được nhúng vào trong một portlet với một chút thay đổi. Những cầu nối khác, như Cocoon cũng được chứa trong eXo để nhúng vào các Cocoon application có sẵn vào một portlet fragment. Nhìn chung, eXo Platform là một open source Portal Framework mạnh mẽ với việc hỗ trợ nhiều công nghệ mới. Khả năng thực thi của eXo Platform tốt nhất với thời gian upload portal nhỏ nhất c.Liferay

Liferay Portal Enterprise mang nhiều ý nghĩa lớn hơn là một portal container, mà đi kèm với nó là rất nhiều đặc điểm hữu dụng như Content Management System (CMS), tuân theo WSRP, Single Sign On (SSO), hỗ trợ AOP (Aspect Oriented Programming), và nhiều công nghệ mới nhất khác. Liferay có một thiết kế kiến trúc rất rõ ràng dựa trên thực tế tốt nhất của J2EE, điều đó cho phép nó được sử dụng với một loạt các container khác nhau, từ những servlet container như Tomcat và Jetty cho tới những server tuân theo J2EE mạnh mẽ như BorlandES, JBoss, JOnAs, JRun, Oracle9iAS, Orion, Pramati, Sun JSAS, WebLogic và WebSphere. Trong trường hợp này, Liferay chỉ là một open source portal container hỗ trợ gần như hầu hết JavaServer open source hay thương mại. Tính linh hoạt trong thiết kế cho phép bổ sung business logic bât kỳ một công nghệ nào tương ứng và thích hợp như Struts, Tiles, Spring và EJB, có thể được dựa trên Hibernate, Java Messaging Service (JMS), Java Mail và Web Service. Liferay có thể thay đổi Portal Presentation trở thành một Java Application bất kỳ mà không có hoặc rất ít sự thay đổi. Việc customize các portal page và các portlet trong những open source Portal Framework như eXo Platform là không dễ dàng, và có thể làm rất nhiều trong việc cấu hình, nhưng với Liferay layout management thì rất dễ dàng. Liferay Portal có một GUI dựa trên Web cho phép user tương tác để thiết kế layout của Portal Page mà không cần phải chỉnh sửa bất kỳ file cấu hình nào. Điều này tương tự như Stringbeans Portal. Liferay Portal Enterprise đi kèm với những portlet hữu dụng. Và nếu đem so sánh với các open source Portal Framework khác, Liferay portal có một lượng lớn các portlet tiện ích tuân theo JSR168 và có thể được sử dụng trong bất kỳ Portal nào chỉ với rất ít thay đổi.

Liferay hỗ trợ WSRP specification cả cho WSRP consumer và WSRP producer như một thực thể của Liferay portal. Việc cấu hình Liferay yêu cầu một vài deployment descriptor không chuẩn chẳng hạn Struts hoặc Tiles, điều này có thể làm cho việc phát triển trở nên phức tạp hơn. Giống như hầu hết các Portal Framework, Liferay sử dụng database mặc định là Hypersonic rất tốt cho mục đích phát triển. Liferay có thể được sử dụng với bất kỳ database nào với chút ít ảnh hưởng tùy theo việc sử dụng Hibernate trong thiết kế của nó. Liferay có các JSP tag lib và nhiều class tiện ích khác trong những package khác nhau để trợ giúp các developer trong việc phát triển portal/portlet. Sử dụng những package tiện ích này có thể dễ dàng phát triển portal nhưng khi đó những portal này sẽ giống Liferay và các portlet thì không còn tuân theo JSR-168 nữa. d.Stringbeans

Stringbeans Portal được tạo nên là một portlet container tuân theo JSR-168 và một framework cho việc quản trị hữu dụng các portal application. Stringbeans được deploy như một J2EE Web Application trong một container hỗ trợ Servlet 2.3 Specification và JSP 1.2 Specification. Mặc định, Stringbeans sử dụng Hypersonic database. Tuy nhiên, Stringbeans vẫn làm việc với bất kỳ relational database nào hỗ trợ JDBC 2.0 và đã được kiểm tra trên PostgreSQL database. Stringbeans không hỗ trợ Hibernate, vì thế việc chuyển từ database này sang database khác phải yêu cầu tự cấu hình. Stringbeans có một tập hợp tài liệu user guide rất tốt có thể tìm thấy online hoặc download để sử dụng. Stringbean được đánh giá là có documentation tốt nhất trong số các open source Portal Framework. Thêm vào đó, hình thức online support của nhóm Stringbeans rất hữu dụng cả về thời gian hồi đáp các bug, các truy vấn, và cả trong việc bổ sung những đặc điểm phụ được yêu cầu. Stringbeans có nhiều đặc điểm thân thiện với user và developer và một trong số đó được liệt kê dưới đây: -Dễ dàng layout management -Hỗ trợ các theme cho look & feel -Xác thực user dựa trên JAAS -Page layout đầy đủ với menu và column -Logging với file đơn giản hoặc database đều hỗ trợ tốt -Điểu khiển truy cập mỗi portlet dựa trên user ID, role và các quan hệ database bất kỳ -Portal view dựa trên user ID, role và các mối quan hệ -Các portle có khả năng hiển thị RSS headline, data từ các table, các report, các biểu đồ, XML document thông qua XSL transformation -Hỗ trợ mobile client (WML 1.1 va XHTML P1.0) Stringbeans Portal có thể được deploy trong một J2EE server với EJB container. Việc deploy portlet trong Stringbeans Portal rất dễ dàng và thật sự tuân theo JSR-168, và chỉ yêu cầu hai file cấu hình là portlet.xml và web.xml. Hầu hết các Portal Framework khác đi kèm với nhiều file cấu hình làm cho việc phát triển và deploy trở nên phức tạp, ví dụ JBoss Portal Framework yêu cầu từ 6 đến 7 file cấu hình. Phiên bản hiện tại của Stringbeans đã hỗ trợ WSRP.

Kết quả

Giới thiệu Portal mã nguồn mở điển hình : Liferay portal 1 - Cài đặt Liferay Portal : Bước 1-Cài đặt Ant : 1. Copy Ant vào C:\Ant 2. Khai báo ANT_HOME . Bước 2-Cài đặt JDK : 1. Cài jdk vào C:\jdk 2. Khai báo JAVA_HOME Bước 3-Cài đặt JIKES : 1. Cài jikes vào C:\jikes 2. Khai báo JIKES_HOME Bước 4-Copy liferay portal source vào C:\Liferay_src Bước 5-Config lại file release.properties : 1. lp.eclipse.dir=C:/eclipse 2. lp.ext.dir=C:/liferay/ext 3. lp.source.dir=C:/liferay-src/portal Bước 6-Vào cmd : cd C:\Liferay_src 1. Chạy : ant start 2. Chạy : ant build-ext Bước 7-Chép webserver vào : C:\liferay\ext\servers\ Cài webserver nào thì bỏ vào thư mục tương ứng Bước 8-Ví dụ jboss-tomcat : Config file : liferay-ds.xml trong jboss-tomcat/server/default/deploy

<jndi-name>jdbc/LiferayPool jdbc:mysql://localhost/lportal com.mysql.jdbc.Driver <user-name>root <password> <min-pool-size>5 Create a data source bound to jdbc/LiferayPool by editing /conf/Catalina/localhost/liferay.xml. ... <parameter> driverClassName com.mysql.jdbc.Driver <parameter> url jdbc:mysql://localhost/lportal <parameter> username test <parameter> password test <parameter> maxActive 20 Copy the JDBC driver to /common/lib. JDBC drivers can be found from the database vendor's web site. Config file : transaction-service.xml trong jboss-tomcat/server/default/deploy

Đổi: true Thành : false Config file : jboss-tomcat/server/default/conf/ jboss-service.xml Đổi : org.jboss.deployment.DeploymentSorter Thành : org.jboss.deployment.scanner.PrefixDeploymentSorter

Cài đặt Portlet vào Liferay Portal : Cách 1-Build file : a. Tạo file jar thư mục chứa portlet thành file war b. Copy file war vào thư mục C:\liferay\ext\portlets c. Chạy ant để build file d. Tạo 2 file liferay-display.xml và liferay-portlet.xml trong WEB-INF e. Liferay-display.xml <portlet id=”" />\ ….. f. Liferay-portlet.xml <portlets> <portlet id="" /> ………. g. Tên portlet lấy trong file portlet.xml Cách 2-Khai báo file : Mở file portlet.xml trong C:\liferay\ext\servers\jboss-tomcat\server\default\deploy\ext.ear\portalweb-complete.war\WEB-INF Ta add thêm vào : ví dụ

<portlet> <portlet-name>69 Hello Laszlo <portlet-class><package + ten class> Mở tiếp file liferay-portlet.xml add thêm vào : <portlet id="69" struts-path="hello_laszlo" narrow="true" /> Mở tiếp file liferay-display.xml add thêm vào : <portlet id="69" /> vào category mà bạn muốn Chép file class vào : C:\liferay\ext\servers\jboss-tomcat\server\default\deploy\ext.ear\portalejb.jar\com\liferay\portlet

Config ngôn ngữ trong Liferay Portal : Mở file language_vi.properties.native : Tìm chữ tiếng Anh tương ứng : Home=Trang chủ Sau đó chạy : cmd Gõ : native2ascii –encoding UTF-8 language_vi.properties.native language_vi.properties

PHÁT TRIỂN LIFERAY PORTAL STEP BY STEP IDE : Eclipse 3.2. Tải src liferay mới nhất về Tạo workspace mới

Tạo Project mới

Chọn Java Project . Kích New

Nhập tên Project ext :

Kết quả là

Nhấn Finish. Chọn ext. Nhấn F5 để refresh

Tạo 1 dự án portal

Xong nhấn Finish Kết quả

ext : môi trường phát triển mở portal : mã nguồn Liferay portal.

Tổng quan về công nghệ JSR 168 Dựa trên đặc tả JSR168 1- Định nghĩa Portal Portal là một ứng dụng nền tảng web thường dùng cung cấp chức năng cá nhân hóa, đăng nhập một cửa, tổng hợp nội dung từ nhiều nguồn khác nhay và nắm giữ tầng trình bày của hệ thống thông tin. Tính năng tổng hợp tin là việc kết hợp nội dung từ nhiều nguồn khác nhau bên 1 trang web. Một cổng điện tử có thể có các tính năng cá nhân hóa tinh tế để tùy biến nội dung theo người sử dụng. Các trang trong cổng điện tử có thể có tập hợp các portlet khác nhau để sản sinh nội dung cho các đối tượng người dùng khác nhau. 2 – Portlet là gì ? Một portlet là thành phần web dựa trên kỹ thuật Java, được quản lý bởi portlet container, nó xử lý các yêu cầu và sản sinh ra nội dung động. Các portlet được sử dụng bởi các cổng điện tử dưới dạng các thành phần giao diện người dùng có khả năng tích hợp được, cung cấp 1 tầng trình diễn cho hệ thống thông tin. Nội dung sản sinh bởi 1 portlet cũng đuợc gọi là 1 fragment. Một fragment là 1 phần các ngôn ngữ đánh dấu (như HTML, XHTML, WML) tuân thủ nghiêm ngạt các luật và có thể được kết hợp với các fragments khác tạo nên 1 tài liệu hoàn chỉnh. Nội dung của một portlet thông thường được tích hợp với nội dung của các portlet khác để hình thành nên trang cổng điện tử. Chu kỳ sống của 1 portlet được quản lý bởi portlet container. Phía clients tương tác đến các portlet thông qua cơ chế hỏi/đáp (request/response) được cài đặt bởi cổng điện tử. Thông thường, người sử dụng tương tác với nội dung được sản sinh bởi các portlets, chẳng hạn bởi các liên kết hay các form xác nhận, kết quả trong các hành động của portlet đang được nhận bởi cổng điện tử, sẽ được trả về bởi nó đến các portlets đích thông qua những tương tác người dùng. Nội dung sản sinh bởi portlet có thề phát từ 1 người dùng đến người dùng khác tùy thuộc vào cấu hình của họ cho portlet. 3 – Portlet container là gì ? Portlet container chạy các portlet và cung cấp cho chúng môi trường thực thi cần thiết. Portlet container bao gồm các portlets và quản lý chu trình sống của chúng. Nó cũng cung cấp lâu dài những tham chiếu portlet. Portlet container nhận các yêu cầu từ cổng điện tử và thực thi các yêu cầu trên những portlets được chứa bởi nó. Portlet container không chịu trách nhiệm kết hợp nội dung sản sinh bởi các portlet. Trách nhiệm đó thuộc về cổng điện tử. Một cổng điện tử và Portlet container có thể được xây dựng với nhau thành 1 thành phần duy nhất của bộ ứng dụng hay như là 2 thành phần riêng biệt của ứng dụng cổng điện tử. 4 – Ví dụ : Sau đây là dòng sự kiện điển hình, được khởi tạo khi người dùng truy xuất trang cổng điện tử của họ : -

Một người dùng thông qua ứng dụng client (ví dụ trình duyệt web) sau khi đã được chứng thực, đưa ra 1 yêu cầu HTTP đến cổng điện tử.

-

Yêu cầu đó được nhận bởi cổng điện tử Cổng điện tử xác định nếu yêu cầu có 1 hành động nhắm đến các portlets được tích hợp trong cổng Nếu có 1 action nhắm đến 1 portlet, thì cổng điện tử yêu cầu portlet container triệu gọi portlet để xử lý hành động. Một cổng điện tử triệu gọi các portlets, thông qua Portlet container, để nhận được các phân mảnh fragment nội dung có thể được kết xuất trong trang thông tin kết quả. Cổng điện tử kết hợp đầu ra của các portlet trong trang cổng điện tử và gửi nó trở về phía client.

5 – Quan hệ với J2EE : Portlet API ver 1.0 dựa trên nền tảng Java 2, phiên bản Enterprise ver 1.3 . Portlet container và các portlets gặp các yêu cầu, mô tả trong đặc tả J2EE để có thể thực thi trong môi trường J2EE. Thừa hưởng những tính năng tương tự của servlets, các khái niệm, tên và thái độ của portlet sẽ tương tự những cái đã được định nghĩa trong đặc tả servlet ver 2.3 khi có thể ứng dụng. 6 – Mối quan hệ giữa portlet và servlet : Đặc tả Servlet ver 2.3 đã định nghĩa Servlet như sau : “Một servlet là thành phần web trên nền tảng công nghệ Java, được quản lý bởi 1 container, nó sản sinh nội dung động. Cũng giống như các thành phân dựa trên Java khác, servlets là các classes Java độc lập nền được biên dịch ra mã bytecode trung gian có thể được tải một cách năng động và chạy bởi một máy chủ web hiểu Java. Containers, nhiều khi được gọi là bộ máy servlet, các mở rộng web server cung cấp chức năng servlet. Servlet tương tác với web client thông qua cơ chế yêu cầu/trả lời được cài đặt bởi servlet container” Portlets và Servlets Đ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 fragments, portal sẽ tổng hợp các fragments này lại vào 1 trang portal, 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. - Web Client tương tác đến portlet thông qua một hệ thống portal. - Portlet có 1 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 1 một tập chuẩn hoá 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). - Portlet có thể tồn tại nhiều lần trong 1 trang portal. ĐIỂM VƯỢT TRỘI : - Portlet có 1 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 trong đặc tả servlet .

- Portlet có thể thực hiện việc viết lại URL, vì thế để tạo 1 liên kết URL bên trong nội dung portlet 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 do đó portal server hoàn toàn mù mờ về việc tạo liên kết và các hoạt động trong trang các fragments...) - Portlet nhắm đến 2 sessions khác nhau trong đó lưu trữ dữ liệu các giao dịch thông qua các đối tượng : mức toàn ứng dụng và mức portlet riêng tư. ĐIỂM YẾU HƠN : - Portlet không thể thay đổi HTTP header hay thiết lập mã hoá 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 1 file mô tả triển khai ứng dụng web (web.xml). Tuy nhiên 1 ứng dụng portlet còn bao gồm 1 file mô tả triển khai ứng dụng portlet (portlet.xml) Vì 1 ứng dụng portlet là 1 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à servlet để cài đặt những tính năng của nó. Nhưng portlet không phải là servlets, để có thể sử dụng lại càng nhiều có thể các kiến trúc servlet đã có, đặc tả Portlet cung cấp cách cài đặt các tính năng tương tự như đặc tả servlet bao gồm : việc triển khai ứng dụng (deployment), tải các lớp thư viện (classloading), ứng dụng web, quản lý chu kỳ sống của ứng dụng web, quản lý phiên và việc gửi các yêu cầu (session management, request dispatching). Cả portlet, servlets, các trang JSPs được bó lại trong 1 ứng dụng web mở rộng gọi là ứng dụng portlet. Chúng chia sẽ nhau bộ tải lớp thư viện (class loader), phiên và ngữ cảnh ứng dụng. (application context, session). Cầu nối giữa portlet đến servlet/JSP Các portlets có thể dùng servlets, JSPs và thư viện thẻ JSP để sản sinh nội dung. Một portlet có thể triệu gọi các servlet và các trang JSPs giống như các servlet có thể triệu gọi các servlets và JSP khác sử dụng bộ gửi yêu cầu request dispatcher. Để có thể kết hợp liền mảnh giữa portlets và servlets đặc tả portlet sử dụng nhiều đối tượng servlets. Khi 1 servlet hay 1 trang JSP được gọi bên trong 1 portlet, yêu cầu servlet được đưa đến servlet hay JSP dựa trên portlet request và servlet trả lời được đưa đến servlet hay JSP dựa và portlet response. Ví dụ : -

Tập các thuộc tính trong portlet request là phù hợp để include servlet request Portlet và các JSP hay servlet được include chia sẽ cùng 1 luồng ra Tập các thuộc tính trong portlet session là có thể sử dụng được từ servlet session và vice versa.

7 – Mối quan hệ giữa Servlet Container và Portlet Container : Portlet Container là phần mở rộng của Servlet Container. Như thế là, 1 Portlet Container có thể được xây dựng phía trên 1 servlet Container đã tồn tại hay nó có thể cài đặt tất cả các tính năng của 1 servlet Container. Bất chấp làm thế nào 1 portlet Container được cài đặt, môi trường thực thi của nó được giả để hỗ trợ đặc tả servlet 2.3 8 – Thành phần của 1 trang portal :

Một portlet ssản sinh các phân mảnh đánh dấu. Một cổng điện tử thườnng thêm 1 tiêu đề, các nút điều khiển và các đồ hoạ trang trí khác vào phân mảnh đánh dấu được sản sinh bởi portlet, fragment mới này đựợc gọi là 1 cửa sổ portlet. Sau đó cổng điện tử kết hợp các cửa sổ portlet này vào trong tài liệu hòan chỉnh : trang portal.

9 – Quá trình tạo ra các trang portal : Các portlets chạy bên trong 1 portlet container. Portlet container nhận nội dung được sản sinh từ các portlets. Một cách điển hình, portlet container nắm giữ nội dung đến cổng điện tử. Portal server tạo trang portal với nội dung được sản sinh bởi các portlets và gửi nó đến thiết bị máy khách (client) khi nó được hiển thị đến người dùng.

10 – Chuỗi các yêu cầu trang portal : Người sử dụng truy cập portal bằng cách sử dụng thiết bị khách chẳng hạn như là 1 trình duyệt web HTML hay một điện thoại thông minh có thể lướt web. Vào lúc đang nhận yêu cầu, cổng điện tử xác định danh sách các portlets cần được thực thi để thõa mãn các yêu cầu. Portal thông qua portlet

container, triệu gọi các portlets. Cổng điện tử tạo các trang portal từ các phân mãnh fragments được sản sinh bởi các portlets và trang này sẽ trả về phía khách khi nó hiển thị đến người dùng.

11 – Portlet Interface : Portlet Interface là phần chính của portlet API. Tất cả các portlet phải implement interface này hoặc là extend lớp đã implement interface Portlet. Thư viện hàm ứng dụng Portlet API có lớp GenericPortlet đã implement interface Portlet và cung cấp các chức năng cơ bản. Các lập trình viên có thể extends trực tiếp hoặc gián tiếp lớp GenericPortlet. Số thực thể portlet : Portletcontainer phải khởi tạo và sử dụng chỉ 1 đối tượng portlet cho mỗi định nghĩa portlet (trong phần mô tả triển khai portlet.xml). Trong trường hợp portlet được triển khai như là 1 phần của ứng dụng portlet được đánh dấu để có thể phân phối, trong mô tả triển khai web.xml, portlet container có thể trình bày chỉ 1 đối tượng portlet ứng với mỗi định nghĩa portlet trong file mô tả triển khai là một máy ảo .

Mỗi một portlet đều mở rộng từ lớp thực thi giao diện portlet. Giao diện portlet gồm các phương thức sau đây: o init(): phương thức dùng để khởi tạo portlet. Phương thức này chỉ được gọi 1 lần sau khi tạo mẫu portlet. Cũng như applet, những phương thức như thế này dùng để tạo các nguồn tài nguyên, các đối tượng mà portlet dùng về sau. o destroy(): xác định portlet không cần tiếp tục hoạt động để giải phóng tài nguyên, cập nhật dữ liệu mà portlet đó sở hữu. o processAction(): thông báo cho portlet rằng người sử dụng đã gây ra một hành động lên portlet. o Render(): tạo ra mã lệnh ngôn ngữ đánh dấu để hiển thị nội dung portlet. Phương thức render được gọi trên mỗi một portlet nằm trên trang hiện thời. Để bổ sung các phương thức trên, khi một portlet được gọi trực tiếp bởi trình chứa, một lớp GenericPorlet được cung cấp cài đặt phương thức render() và ủy thác gọi các phương thức đặc biệt để hiển thị portlet dựa trên các mode của nó. Người phát triển có thể

mở rộng lớp GenericPorlet và cài đặt như nhiều phương thức khác như những phương thức render này. Đó là các phương thức: o doView(): Được gọi bởi phương thức render() khi portlet ở chế độ View. o doEdit(): Được gọi bởi phương thức render() khi portlet ở chế độ Edit. o doHelp(): Được gọi bởi phương thức render() khi portlet ở chế độ Help.

File mô tả triển khai portlet - portlet.xml: File này định nghĩa thông tin mà portlet container cần để thực thi portlet. Mỗi portlet được định nghĩa bởi một mô tả triển khai portlet.xml, portlet container sẽ sinh ra một đối tượng đơn của lớp portlet để phục vụ cho tất cả các yêu cầu đến portlet đó. Điều này tương tự như một hành vi của trình chứa sevlet. <portlet-app> <portlet> <portlet-name>Tên portlet <portlet-class>Lớp cài đặt portlet Tên tham số khởi chạy Giá trị tham số khởi chạy [<expiration-cache>Thời gian cache nội dung portlet] <supports> <mime-type>Kiểu nội dung portlet hỗ trợ (text/html,.) <portlet-mode>view [<supported-locale>Bản địa portlet hỗ trợ] <portlet-info> [<short-title>Tiêu đề vắn tắt của portlet Từ khóa của portlet] Portlet.xml là một file theo chuẩn xml. Có một phần tử gốc là portlet-app và một hoặc nhiều phần tử con là portlet. Mỗi phần tử con portlet thường gồm có các phần tử sau: Các phần tử portlet-name, portlet-class và init-param định nghĩa tên, lớp và các tham số khởi chạy cho portlet. Phần tử expiration-cache định nghĩa thời gian mà portal/portlet container sẽ cache nội dung được tạo bởi portlet. Nếu không thiết lập thuộc tính expiration-cache thì giá trị mặc định sẽ được sử dụng. Phần tử supports định nghĩa các kiểu nội dung mà portlet hỗ trợ và các chế độ hỗ trợ cho kiểu nội dung. Portal/portal container sẽ không triệu gọi một portal trong các chế độ mà portal không có định nghĩa kiểu hỗ trợ. Phần tử portlet-info định nghĩa thông tin như là tiêu đề mặc định cho portlet. Phần tử portlet-preferences định nghĩa các giá trị mặc định cho các thiết lập ưu tiên (preferences) portlet.

File mô tả triển khai portlet - web.xml. File web.xml theo chuẩn xml, là file mô tả triển khai ứng dụng portlet. Dựa vào file này mà portal truyền thông được với portlet được mô tả. <web-app> Tiêu đề ứng dụng <servlet> <servlet-name>Tên portlet Tiêu đề portlet <description>Mô tả Portlet <servlet-class>....PortletServlet <param-name>portlet-class <param-value>Lớp cài đặt portlet <param-name>portlet-guid <param-value>Tên portlet-context.Tên portlet <servlet-mapping> <servlet-name>Tên portlet /Tên portlet/* http://java.sun.com/portlet /WEB-INF/tld/portlet.tld Các phần tử của file giống như một file web.xml mô tả triển khai ứng dụng bình thường.

File tài liệu mô tả tag library – portlet.tld. Tùy theo mỗi portlet container mà file portlet.tld khác nhau. Với portlet container pluto file này như sau: 1.0 <jspversion>1.1 <shortname>portlet http://java.sun.com/portlet defineObjects org.apache.pluto.tags.DefineObjectsTag org.apache.pluto.tags.DefineObjectsTag$TEI

empty param org.apache.pluto.tags.ParamTag empty name <required>true true value <required>true true actionURL org.apache.pluto.tags.ActionURLTag org.apache.pluto.tags.BasicURLTag$TEI JSP windowState <required>false true portletMode <required>false true secure <required>false true var <required>false true renderURL org.apache.pluto.tags.RenderURLTag org.apache.pluto.tags.BasicURLTag$TEI JSP windowState

<required>false true portletMode <required>false true secure <required>false true var <required>false true namespace org.apache.pluto.tags.NamespaceTag empty 12 – Vòng đời của portlet : Một portlet được quản lý thông qua 1 chu trình sống được định nghĩa chặt chẽ, làm thế nào chúng được tải về (load), trình bày và khởi tạo, làm thế nào chúng nắm giữ các yêu cầu từ phía máy khách, và làm thế nào chấm dứt 1 dịch vụ. Chu trình sống của portlet được gói gọn lại thông qua các phương thức init(), processAction(), render(), destroy() của interface Portlet. Loading and Instantiation Portlet container chịu trách nhiệm tải và thuyết minh các portlets. Việc này có thể xảy ra khi khi Portlet container bắt đầu ứng dụng portlet hoặc chờ cho đến khi Portlet container xác định portlet nào cần để phục vụ các yêu cầu. Portlet container phải tải các lớp portlet bằng cách sử dụng chung ClassLoader mà servlet container dùng cho ứng dụng web, một phần của ứng dụng portlet. Sau khi tải các lớp của portlet, portlet container sẽ thuyết minh để có thể sử dụng chúng. Initialization Sau khi đối tượng portlet đã được thuyết minh, Portlet container phải khởi tạo chúng trước khi triệu gọi để nắm bắt các yêu cầu. Việc khởi tạo được dùng nhằm cho portlets có thể khởi tạo các tài nguyên hao tốn (chẳng hạn kết nối phía sau), và tiến hành các hoạt động cùng một lúc khác. Portlet container phải khởi tạo đối tượng portlet bằng cách gọi phương thức init() của Portlet interface chỉ với 1 đối tượng (ứng với mỗi định nghĩa portlet trong web.xml) implement interface PortletConfig. Đối tượng cấu hình này cung cấp truy xuất đến các thông số khởi tạo và

ResourceBundle đã được định nghĩa trong định nghĩa portlet trong file mô tả triển khai xml . Đối tượng cấu hình cũng mang sự truy xuất portlet đến đối tượng context, nó mô tả môi trường thực thi của portlet. Error Conditions on Initialization Trong khi khởi tạo, đối tượng portlet có thể ném ra 1 UnavailableException hay 1 PortletException. Trong trường hợp này, portlet container không được đặt đối tượng portlet vào dịch vụ đang kích hoạt và nó nó phải giải phóng đối tượng portlet. Phương thức destroy() sẽ không được gọi vì việc khởi tạo như thế xem như không thành công. Portlet container có thể cố gắng thuyết minh và khởi tạo các portlets vài lần nữa sau khi thất bại. Lỗi ngoại lệ (exception) theo qui định là UnavailableException biểu diễn 1 sự không sẳn sàng để sử dụng trong 1 thời gian tối thiểu. Khi điều này xảy ra, portlet container phải chờ cho thời gian theo lý thuyết qua đi trước khi tạo và khởi tạo 1 đối tượng portlet mới must wait for. Còn lỗi RuntimeException được ném ra trong quá trình khởi tạo có thể được xem như là 1 PortletException.

Hình minh hoạ vòng đời portlet :

Giai đoạn init

Giai đoạn hồi đáp (render)

Giai đoạn destroy

Rất giống như servlet, vòng đời 1 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 1 đố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 ném 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à 1 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 bực mình 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 1 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 1 exception được ném 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 ném, 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 . Các trạng thái thực thi portlet (Portlet Runtime States): Khi 1 portlet đang chạy, nó có 1 đố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ó 1 sự truy cập đầy đủ một cách hệ thống đến tham chiếu của nó. Khi 1 portlet được đặt vào 1 trang, một Preferences sẽ tham chiếu đến nó. Sự kết đôi của portlet và đối tượng Preferences trên 1 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. 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 1 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ó. Nếu yêu cầu của client là action request, thì nó chỉ hướng đến 1 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 . Như bạn có thể thấy, 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 1 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 1 user có thể thay đổi chỉ 1 portlet tại 1 thời điểm (bạn chỉ có thể click trên 1 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. Ghi nhớ 1 biệt lệ (exception ) để khi 1 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 1 cách dễ dàng cache, nhưng là nguồn đầu cơ (spec) 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 1 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à 1client = 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à 1 nhà phát triển có thể implement portlet của anh ta 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. 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 1 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 1 fragment từ trạng thái hiện tại của portlet. Nó cung cấp : + Các tham số yêu cầ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 1 servlet hay JSP. Ta sẽ đi chi tiết vào kỹ thuật này sau. Các đối tượng request và response đều không là luồng an toàn. Điều đó có nghĩa là 1 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ý. 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ả 1 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ề 1 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 1 đánh dấu được hồi đáp khi chế độ portlet là PortletMode.EDIT * Lúc này, ta sẽ gửi ph/thức đến 1 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 để ccấp 1 đánh dấu được hồi đáp khi chế độ portlet là PortletMode.HELP * Lúc này, ta sẽ gửi ph/thức đến 1 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ấp1 đánh dấu được hồi đáp khi chế độ portlet là PortletMode.VIEW * Lúc này, ta sẽ gửi ph/thức đến 1 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 1 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), nhưng bạn gặp mối nan giải của việc cài đặt portlet . Các yếu tố khác của Java Portlet API : Giờ thì bạn đã khảo sát những khái nhiệm ở mức cao của portlet API, đoạn này sẽ cho biết các thành phần ở mức thấp bên trong đặc tả, việc cung cấp 1 portlet hình cả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. PortletConfig Khi 1 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ấu 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 1 ResourceBundle ( bó tài nguyên) cho portlet . ResourceBundle bao gồm 1 vài trường được yêu cầu bởi đặc tả, bao gồm tiêu đề, tiêu đề ngắn, và các từ khoá.

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 :

<portlet> ... <portlet-info> <short-title>doh Simpsons, Homer Simpson, Entertainment ...

Như 1 sự lựa chọn, bạn có thể chỉ định 1 tham chiếu đến 1 ResourceBundle theo cách :

<portlet> ... <portlet-info> 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 1 ResourceBundle và được làm hiệu lực thông qua đối tượng PortletConfig . 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 1 form, vv... 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. Những nhà phát triển portlet nên sử dụng đối tượng PortletURL ( hoặc các thư viện thẻ đi kèm) thay vì tao tác trực tiếp trên những dòng truy vấn HTTP. Điều tất yếu là nhà phát triển không nên dùng GET trong các form HTML. Đó là bởi vì portal có thể mã hoá các thông số trạng thái nội tại bên trong PortletURL. 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

chir đị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 1 chuổi biểu diễn của URL. Chú ý rằng nó không đảm bảo 1 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 . Các chế độ của portlet : Một chế độ portlet biểu diễn 1 trạng thái chức năng của 1 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à 1 phần của quá trình xử lý yêu cầu hành động (action request). Thêm vào đó, 1 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. Chế độ 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 dòng 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 1 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 nghiã 1 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. Cũng ghi chú rằng bạn có thể chỉ định với loại đánh dấu nào là thích hợp cho 1 chế độ portlet cho trước. Thông tin thêm vào trong cấu hình các chế độ portal được trình bày ở phần sau :“Portlet Application Deployment Descriptor.” 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, 1 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). Ngữ cảnh portlet (PortletContext) PortletContext là 1 đối tượng wrapper cho ứng dụng portlet của bạn. Có 1 đố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 1 yêu cầu gửi đi để có sức mạnh đòn bẩy của servlet và JSPs trong portlet . Ngữ cảnh portal (PortalContext) Một portlet có thể lấy 1 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() Các tham chiếu portlet (PortletPreferences): 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ảu 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ó 1 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 1 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 1 đố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ề 1 bảng liệt kê Enumeration các tên các preferences thích hợp. + getValue() - bạn truyền cho nó tên của tham chiếu bạn quan tâm, đi kèm với 1 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 riên của mảng các giá trị tham chiếu. + getValues() - bạn truyền cho nó tên tham chiếu bạn muốn và 1 mảng String các giá trị mặc định và nó trả về 1 mảng String của các giá trị của nó. + setValue() - bạn 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à 1 phần tử đơn mảng String chứa đựng các giá trị. phương thức này ném ra 1 biệt lệ nếu tham chiếu không bị thay đổi UnmodifiableException . + setValues() - bạn truyền cho nó tên tham chiếu và 1 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 ném ra 1 biệt lệ nếu tham chiếu không bị thay đổi UnmodifiableException . + isReadOnly() - bạn truyền cho nó tên tham chiếu và nó trả về 1 giá trị Boolean xác định tahm chiếu có thể thay đổi được hay không. + reset() - bạn truyền cho nó tên tham chiếu và nó trả về 1 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ẽ ném ra 1 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ẽ ném 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à 1 mảng String[ ] chứa các giá trị. Map này cũng không thể thay đổi.

Ghi chú 2 điều quan trọng để hiểu về phương thức store() . Trước tiên, đó là 1 giao dịch nguyên tử. Vì thế, tất cả các thay đổi phải thành công hoặc không thay đổi nào thành công. Đó là điểm then chốt để hiểu nếu bạn có 1 danh sách tham chiếu khổng lồ cho portlet của bạn và bạn không nhập một số lượng lớn khủng khiếp các đầu vào. Hai là, bạn có thể lấy nọc cùng lúc ghi vào bộ lưu trữ tham chiếu. Một thông báo critical ở đây là bạn nên xem những tham chiếu của bạn như 1 thực thể riêng biệt và không là 1 tập hợp các tham số độc lập có thể sử dụng được thông qua 1 giao diện chung. Nhà phát triển có thể định nghĩa các lớp tuỳ ý để cung cấp 1 sự hợp lệ cho các tham chiếu. Những lớp này cài đặt (implement ) lớp giao tiếp PreferencesValidator interface và phải cung các các khả năng hợp lệ trong nghĩa luồng - an toàn. Việc implement giao tiếp PreferencesValidator interface là rất đơn giản : chỉ chó 1 phương thức validate(), nó lấy đối tượng PortletPreferences và không trả về gì cả. Đơn giản ném ra 1 biệt lệ ValidatorException nếu 1 vài giá trị không logíc với cái bạn định nghĩa. Sessions (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ó 1 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ác để cài đặt chúng (implement ), vì thế portlet API cung cấp giao tiếp PortletSession interface. Khi 1 client tạo 1 request, server gửi đi 1 đị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ó 1 đ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 rong 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 1 đối tượng là thích hợp chỉ 1 portlet đó. PORTLET_SCOPE là thống nhất trong cách đặt không gian tên cho 1 thuộc tính cho trước. Ví dụ, 1 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ó 1 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". Gọi 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ó 1 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 có mình và 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 1 cái rổ " tức vấn đề đặt tất cả các markup của mình trong 1 servlet , và tất cả mã Java trong trang JSP, 1 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 1 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 đường dẫn với

dấu slash hở //, và cung cấp 1 đườ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). Tương tự, ta có thể gọi 1 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 1 servlet như sau trong web.xml :

<servlet> <servlet-name>chart <servlet-class>org.opensourceportals.ChartServlet 0

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 1 Object PortletRequestDispatcher. Đây là 1 đ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 1 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() + getCharacterEncoding() + setCharacterEncoding() + getContentType() + getInputStream() + 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ừ 1 servlet hay JSP được include bởi 1 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/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() Lý do tại sao những ph/thức trên sẽ không thích hợp khi gọi phương thức getNamedDispatcher() khá đơn giản : Bởi bạn đã không sử dụng 1 đường dẫn cho những yêu cầu (request) của mình, không có dữ liệu mà các trường này có thể chứa. Tương tự như thế, HttpServletResponse cũng có những hạn chế trên cái gì có thể sử dụng được . Những phương thức không sẵn có của HttpServletResponse : + encodeRedirectURL() + encodeRedirectUrl() + setContentType() + setContentLength() + setLocale() + sendRedirect() + sendError() + addCookie() + setDateHeader() + addDateHeader() + setHeader() + addHeader() + setIntHeader() + addIntHeader() + 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à 1 mac 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ứ 1 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ư 1 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à 1 framework ứng dụng Web, đó có thể làm nên 1 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à 1 đị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. 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, files 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 1 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.” Bảo mật : Bởi bảo mật là 1 vấn đề lớn hơn những yêu cầu cỉa portlet API ta sẽ đề cập đến vấn đề này ở C 6. Các định nghĩa kiểu CSS (Cascading Stylesheets ) : Nhằm đặt đến 1 giao diện chung và có thể plug cho các portlets, Java Portlet API định nghĩa tập các kiểu CSS (Cascading Stylesheets) mà portlet có thể sử dụng để hồi đáp các markup của chúng. Bằng cách sử dụng 1 tập các kiểu chuẩn, portal có thể hổ trợ skin, tuỳ biến hoá màu sắc và font chữ. Những kiểu nầy có nghĩa đồng thời với chuẩn OASIS Web Services for Remote Portlets (WSRP). Để đầy đủ hơn, những định nghĩa kiểu này được trình bày trong bảng sau : Bằng cách sử dụng những styles này, nhà phát triển portlet đảm bảo rằng các portlet của họ có thể sử dụng lại trong các ứng dụng portlet khác, và thống nhất tương thích với WSRP. Thêm nữa, nhà phát triển có thể áp dụng các "skins" từ những ứng dụng portlet khác vào portlet của họ. Những thuộc tính thông tin người dùng (User Information Attributes) : Thuộc tính user được sử dụng để tạo 1 hiện trạng (profile) cho 1 user. Chúng được hiểu để chuẩn hoá trên nền World Wide Web Consortium’s (W3C) Platform for Privacy Preferences (P3P) 1.0 (www.w3.org/TR/P3P/). Những thuộc tính này cũng phù hợp thống nhất với những nổ lực của chuẩn WSRP (OASIS Web Services for Remote Portals ). Bảng sau liệt kê danh sách các thuộc tính user và những mô tả của chúng. Như bạn có thể thấy, những thuộc tính có đặc tính lặp lại chút ít, nhưng mang lại sự chính xác trong các tuỳ chọn của nhà phát triển những điều kiện trong đó những thuộc tính user bạn cần cho ứng dụng portlet . Tuy nhiên, nó không có thẩm quyền (khả năng) chỉ dùng trong ứng dụng portlet của bạn, và file mô tả triển khai ứng dụng Web phải mô tả những cái được dùng trong ứng dụng web portlet của bạn, và nhà phát triển cần ánh xạ chúng đến với cái thích hợp máy chủ portal đích. Cái này là ở đâu việc sử dụng các thuộc tính chuẩn là có ích ở một lúc nào đó, như là nó đơn giản lớn, nếu không hạn chế, số lượng các ánh xạ (mapping) cần thiết để triển khai ứng dụng cuả bạn. Hãy tự tin bạn có thể hoàn tất tất cả các ánh xạ ( và “Portlet Application Deployment Descriptor” sẽ thảo luận về điều đó trong file portlet.xml), bạn có thể truy cập đến những thuộc tính user như sau:

Map userdata = (Map) request.getAttribute(PortletRequest.USER_INFO);

String workEmail = (String) request.getAttribute(“user.business-info.online.email”); Bạn tóm lấy 1 Map của các thuộc tính user được triển khai bằng cách thiết lập thuộc tính đó từ PortletRequest. Sau đó bạn đơn giản nhìn vào giá trị thích hợp; trong trường hợp này, email làm việc của user ( được lưu dưới quote “user.business-info.online.email”). Các thuộc tính user là rấ quan trọng trong triển khai các giải pháp cá nhân hoá portlet . Bạn phải chắc chắn hiểu biết 1 cách đầy đủ những thuộc tính này.

Xây dựng một portlet JSR168 1 – HelloWorldPortlet 1.1 Cấu trúc thư mục :

1.2 Nội dung mã nguồn các file Nội dung file build.xml (file dùng để biên dịch và đóng gói ứng dụng portlets) <project name="HelloAliPortlet" default="war" basedir="."> <property name="src.dir" value="Java Source"/> <property name="web.dir" value="Web Content"/> <property name="build.dir" value="build"/> <property name="dist.dir" value="dist"/> <property name="lib.dir" value="lib"/> <property name="libextend.dir" value="C:\Sun\Java\jdk1.6.0\lib"/>

<mkdir dir="${build.dir}/classes"/> <javac srcdir="${src.dir}" destdir="${build.dir}/classes" debug="${javac.debug}" optimize="${javac.optimize}" nowarn="on"> <mkdir dir="${dist.dir}"/> <war destfile="${dist.dir}/ HelloAliPortlet.war" webxml="${web.dir}/WEB-INF/web.xml"> <exclude name="**/web.xml"/> <exclude name="/*.jar"/> <delete dir="build"/> <delete dir="${dist.dir}"/>

File HelloAliPortlet.java package com.pan.portlet.HelloAli; /* Date Created : 10 October, 2005 Author : Alibobo Description : Hello ALi Portlet - first lesson */ import java.io.IOException; import java.io.Writer; import javax.portlet.ActionRequest; import javax.portlet.ActionResponse;

import javax.portlet.GenericPortlet; import javax.portlet.PortletException; import javax.portlet.RenderRequest; import javax.portlet.RenderResponse; public class HelloAliPortlet extends GenericPortlet { public void doView(RenderRequest req, RenderResponse res) throws IOException, PortletException { res.setContentType("text/html"); res.getWriter().print("Hello World!"); } }

File web.xml <web-app> HelloAliPortlet File portlet.xml <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"> <portlet> <portlet-name>HelloAliPortlet Hello World <portlet-class>com.pan.portlet.HelloAli.HelloAliPortlet <expiration-cache>0 <supports> <mime-type>text/html <portlet-mode>VIEW <portlet-info> <short-title>Hello World Hello World

<security-role-ref> guest <security-role-ref> power-user <security-role-ref> user

File liferay-portlet.xml

Portlet

Application

<portlet> <portlet-name>HelloAliPortlet true true administrator Administrator guest Guest power-user Power User user User <custom-user-attribute> user.name.test <custom-class>com.pan.portlet.HelloAli.HelloAliPortlet File liferay-display.xml



Display

4.0.0//EN"

<portlet id="HelloAliPortlet"/>

1.2 Chạy ant để build ta được cấu trúc thư mục mới, HelloAliPortlet.war ở trong thư mục dist

Hot deploy trong Liferay Kết quả xuất hiện trong liferay

Vài câu hỏi thường gặp khi đọc ví dụ HelloPortlet, hay khi mới bắt đầu viết portlet Check the carefully compiled list of Frequently Asked Questions (FAQs) to see if someone has come before you with the same question. --------------H1 : Tui đã down cái APIs của portlet về và xem, thì thấy toàn là interface, mở source của nó ra xem mà chỉ có một vài class thì các method của nó cũng không có gì đáng kể. Đ1 : Thì JSR 168 - là đặc tả chuẩn dành cho portlet, nên nó chỉ định nghĩa các Interface chuẩn cho portlet . ------------H2 : Vậy các chức năng của interface đó mà developer sử dụng như trong mô tả của interface đó được hiện thực ở đâu? Ngoại trừ một vài constant có thể sử dụng thì còn lại toàn là method mà tôi chẳng thấy chỗ nào hiện thực nó cả, hay là chính developer phải hiện thực nó? Đ2 : Tất nhiên là có thể, nhưng nhiệm vụ của developer không phải là implements tất cả các Interface đó, trách nhiệm đó thuộc về phía các nhà phát triển portlet container. Trong mã nguồn của dự án portlet container Pluto (hãng Apache) ta thấy rõ điều này. (http://portals.apache.org/pluto/mirrors.html) ----------------H3 : Nói đến portlet container, vậy nó quan hệ như thế nào đến công nghệ JSP, Servlet, vì trong kiến trúc của nó tui thấy có JSP Container, servlet container ? Đ3 : Để quản lý giúp chu trình hoạt động của các portlet, Portal sử dụng một thành phần gọi là portlet container, có trách nhiệm khởi tạo, hỗ trợ các portlets khi xử lý các yêu cầu và huỷ các portlet tương ứng khi cần. Do portlet container tồn tại trong một servlet container thông thường, một ứng dụng portlet cũng có thể gửi yêu cầu đến các servlet, các file JSP hay các tài nguyên web khác. Một điểm nữa là Portlet container có thể được tích hợp sẵn trong portal, hoặc được cung cấp bởi các hãng thứ 3. Để tìm hiểu về java servlet, công nghệ JSP, bạn có thể download tài liệu bằng tiếng việt javaservlet.zip ở bên dưới. ---------------H4 : Theo tôi được biết uPortal dùng Portlet container là Pluto, vậy Liferay nó dùng Portlet container nào ? Đ4 : Để xây dựng được các portlet theo chuẩn đặc tả JSR 168 thì lẽ tất nhiên là phải xây dựng được 1 bộ implementation cho các interface mà đặc tả này đưa ra. Việc xây dựng bộ implementation này tương đương với việc xây dựng 1 portlet container, và nếu không làm được thì có thể dùng của các hãng thứ 3 (third-parties) cung cấp sẵn (như uPortal dùng Pluto). Liferay portal tự xây dựng cho mình 1 bộ implementation riêng, tức là kèm theo trong mã nguồn của mình 1 portlet container riêng của Liferay. ---------------H5 : Khi đọc tài liệu JSR 168, có chỗ nói portlet không có một địa chỉ cụ thể. Tôi không hiểu chỗ này lắm ?

Đ5 : Để lý giải cho thắc mắc này ta hãy xuất phát từ định nghĩa của Portal: bản thân Portal tương tác với người dùng thông qua 1 request/response paradigm. Thế nên, mọi yêu cầu (request) của người dùng sẽ được nhận bởi Portal (ở dạng ServletRequest), chuyển qua cho Portlet Container (để chuyển thành PortletRequest) và chuyển đến cho portlet cụ thể. Sau đó quá trình được lặp lại với PortletResponse -> ServletResponse và chuyển đến người dùng (tức trình duyệt web browser). Nói như vậy để thấy, URL mà chúng ta nhìn thấy trên thanh Address bar của trình duyệt là URL của bản thân portal chứ không phải của portlet. ---------------H6 : Khi viết một portlet ta có thể extends GenericPortlet hoặc Portlet. Vậy khi nào ta nên chọn cái nào? Đ6 : javax.portlet.Portlet là một Interface chuẩn cho portlet. Và để xây dựng một portlet từ interface này, bạn sẽ phải làm khá nhiều việc. Ví dụ: Code: import javax.portlet.Portlet; public class PortletXXX implements Portlet { public void render(RenderRequest req, RenderResponse res) throws PortletException, IOException { // Trong nội dung phương thức này, bạn sẽ phải tự xác định lấy MODE hiện tại của portlet. Và thực hiện việc trình bày nội dung cho phù hợp. } }

- javax.portlet.GenericPortlet là một class implements interface Portlet, và đã phân chia phương thức render thành 3 phương thức nhỏ tương ứng với 3 mode chuẩn của Portlet là doHelp(), doEdit() và doView(). Và do đó, bạn sẽ chỉ cần override các phương thức doXX() này thay vì phải implement phương thức render() gốc của Portlet. Do vậy, nếu bạn viết một ứng dụng portlet thông thường thì nên dùng cái GenericPortlet. Nhưng nếu muốn làm một việc cao cấp hơn một chút như tự định nghĩa thêm các MODE cho portlet, hoặc xây dựng 1 framework để viết portlet thì nên implement cái interface Portlet. --------------H7 : Để hồi đáp 1 request của người dùng, tôi thấy có lúc thì dùng render() method, lúc thì dùng doXXX() method, vậy dùng thế nào là đúng vậy ? Đ7 : Thông thường, mode VIEW là mode mặc định, nếu bạn không cần quan tâm đến các mode khác thì có thể dùng render() hoặc doView(). Bởi lúc đó hai phương thức này có vai trò tương đương. --------------H8 : Trình tự invoke của mấy cái method : render(), doView(), doEdit(), doHelp() là như thế nào ? tức là cái gì gọi nó, và gọi nó vào lúc nào? Đ8 : Thực ra thì phương thức render() tương đương với các phương thức doXXX(). Tuỳ vào mode hiện tại của portlet mà nó sẽ gọi doXXX() tương ứng. ---------------H9 : Khi viết portlet, nếu có init() method,tôi thấy lúc thì cần gọi super.init(), lúc thì không ( hình như là nếu extends GenericPortlet thì cần, còn extends Portlet thì lại không cần ) ? Đ9 : Không cần thiết phải gọi super.init() đâu. Bởi bản thân super cũng chẳng làm gì trong phương thức init() cả. --------------H10 : Khi viết portlet có gọi các trang jsp, làm thế nào để kiểm soát được các mode (VIEW, EDIT, HELP) của nó, nhấn chọn EDIT thì gọi edit.jsp, HELP thì gọi help.jsp chẳng hạn ? Đ10 : Mặc định mode đầu tiên của 1 portlet sẽ là mode VIEW. Còn sau đó, nếu bạn muốn chuyển đến mode nào thì tuỳ, vì ta có thể đặt được mode một cách tuỳ ý. Để biết được mode hiện tại của portlet là mode nào, ta có thể kiểm tra như sau: Code: public void render(RenderRequest req, RenderResponse res) throws PortletException, IOException { PortletMode currentMode = req.getPortletMode(); if (currentMode .equals(PortletMode.EDIT)) { // Mode hiện tại là mode EDIT } else if (currentMode .equals(PortletMode.VIEW)) { // Mode hiện tại là mode VIEW }

// ... }

Ứng dụng công nghệ Portal trong chính phủ điện tử tại Việt nam :

Giải pháp một cửa trong cải cách hành chính

Tác giả: Nguyễn Văn Chương & Nguyễn Sinh Thành