JSR-286: Portlet 2.0规范详解与IPC机制

需积分: 9 84 浏览量更新于2024-07-30 收藏 1.05MB PDF 举报

"Portlet 2规范，基于JSR-286，引入了Portlet 2.0标准和portlet间的通信（IPC）机制。" Portlet 2规范是Java世界中针对portlet开发的一项重要标准，它在原有的Portlet 1.0规范基础上进行了扩展和增强，以适应更复杂、更多功能的Web应用需求。该规范由Java Community Process (JCP)定义，主要由IBM公司领导完成，并最终以JSR-286的形式发布。这一规范的目的是提高portlet的交互性和灵活性，同时提升portlet在企业级门户平台上的性能和用户体验。 Portlet 2.0规范的主要改进包括： 1. **异步处理**：新规范引入了异步portlet模式，允许portlet在后台处理请求，而不阻塞用户界面的更新，提高了应用程序的响应速度。 2. **富互联网应用（RIA）支持**：Portlet 2.0支持更多的RIA技术，如AJAX，使portlet能够提供更加动态和交互性的用户界面。 3. **Inter-Portlet Communication (IPC)**：IPC机制使得不同的portlet之间可以进行数据交换和协作，增强了portlet之间的协同工作能力。这对于构建复杂的、多组件的门户应用至关重要。 4. **生命周期管理**：portlet的生命周期管理得到加强，包括初始化、渲染、动作处理等阶段，提供了更精细的控制，开发者可以更好地管理portlet的状态和行为。 5. **资源API**：新增了资源请求和响应的概念，使得portlet可以更好地处理HTTP请求的资源，比如图片、CSS和JavaScript文件，提高了性能和可维护性。 6. **缓存机制**：Portlet 2.0引入了缓存机制，允许portlet缓存其输出内容，减少了服务器的负载和网络传输的延迟。 7. **安全性增强**：规范提供了更强大的安全特性，如portlet级别的权限控制，确保用户只能访问他们被授权的内容。 8. **portlet模式**：支持多种portlet模式，如编辑模式和查看模式，让portlet可以根据场景切换不同的显示和操作方式。 9. **portlet部署描述符增强**：部署描述符（portlet.xml）的改进，允许开发者更灵活地配置portlet的行为和属性。 Portlet 2.0规范的实施不仅提升了portlet开发的效率，也极大地提高了portlet应用的质量和用户体验。它为开发者提供了丰富的工具和框架，用于构建可扩展、高度集成的企业级Web应用。通过遵循JSR-286规范，portlet开发者可以创建出与门户平台紧密配合、功能强大的portlet组件，进一步推动了企业信息化的发展。

Java

Portlet Specification, version 2.0 (2008-01-11)

Gothe(Sun Microsystems, Inc.), Vishal Goenka (SunGard Higher Education), Stefan

Hepper (IBM Corp.), Martin Holzner (Novell, Inc.), Danny Machak (TIBCO Software

Inc.), Kito D. Mann, Benjamin Mestrallet (eXo Platform SARL), Stephen Millidge, Jason

Novotny, Punit Pandey, Ilya Rybak (SAP AG), Charles Severance, Hani Suleiman, David

Sean Taylor (Apache Software Foundation), Julien Viet(JBoss, Inc.), James Ward 5

(Adobe Systems Inc.), Carsten Ziegeler (Day).

We want to give special thanks to (as members of the Expert Group) Subbu Allamaraju,

Wesley Budziwojski, Craig Doremus, Ate Douma, Michael Freedman, Kevin Frender for

their major contributions to this specification.

Finally we would like to thank Torsten Dettborn (University of Jena) who led the TCK 10

and RI efforts

PLT.1.9 Acknowledgements V 1.0

The Portlet Specification V1.0 was the result of the work of JSR168 Expert Group,

Subbu Allamaraju (BEA), Chris Braun (Novell), Don Chapman (SAS), Michael

Freedman (Oracle), Laurent Guiraud (SAP), Randal Hanford (Boeing), Andre Kramer 15

(Citrix), Axel Kratel (Borland), Danny Machak (TIBCO), Kris Meukens (EDS), Wes

Mitchell (Broadvision), Takao Mohri (Fujitsu), Dean Moses (Vignette), Andrew Rickard

(ATG), William Seiger (Sybase), David Sean Taylor (Apache), Stefan Hepper (IBM) and

Alejandro Abdelnur (Sun).

We want to give special thanks to (as members of the Expert Group) Subbu Allamaraju, 20

Henning Blohm, Chris Braun, Don Chapman, Adrian Fletcher, Michael Freedman,

Laurent Guiraud, Andre Kramer, Danny Machak, Wes Mitchell, Takao Mohri, Dean

Moses, Peter Petersen, Andrew Rickard and David Sean Taylor for their contributions.

We would like to thank OASIS WSRP Technical Committee, JSR127 Java Server Faces

Expert Group and JSR154 Servlet Specification Expert Group for their cooperation. 25

We would also like to thank all the people who have sent us feedback during the

Community Review and Public Review stages.

Finally we would like to thank Maneesha Jain (Sun) and Stephan Hesmer (IBM) who led

the TCK and RI efforts.

Java

Portlet Specification, version 2.0 (2008-01-11)

PLT.2

Overview

PLT.2.1 What is a Portal?

A portal is a web based application that –commonly- provides personalization,

authentication, content aggregation from different sources and hosts the presentation 5

layer of information systems. Aggregation is the action of integrating content from

different sources within a web page. A portal may have sophisticated personalization

features to provide customized content to users. Portal pages may have different set of

portlets creating content for different users.

PLT.2.2 What is a Portlet? 10

A portlet is an application that provides a specific piece of content (information or

service) to be included as part of a portal page. It is managed by a portlet container, that

processes requests and generates dynamic content. Portlets are used by portals as

pluggable user interface components that provide a presentation layer to information

systems. 15

The content generated by a portlet is also called a fragment. A fragment is a piece of

markup (e.g. HTML, XHTML, WML) adhering to certain rules and can be aggregated

with other fragments to form a complete document. The content of a portlet is normally

aggregated with the content of other portlets to form the portal page. The lifecycle of a

portlet is managed by the portlet container. 20

Web clients interact with portlets via a request/response paradigm implemented by the

portal. Normally, users interact with content produced by portlets, for example by

following links or submitting forms, resulting in portlet actions being received by the

portal, which are forwarded by it to the portlets targeted by the user's interactions.

The content generated by a portlet may vary from one user to another depending on the 25

user configuration for the portlet.

This specification will deal with Portlets as Java technology based web components.

PLT.2.3 What is a Portlet Container?

A portlet container runs portlets and provides them with the required runtime

environment. A portlet container contains portlets and manages their lifecycle. It also 30

Java

Portlet Specification, version 2.0 (2008-01-11)

provides persistent storage for portlet preferences. A portlet container receives requests

from the portal to execute requests on the portlets hosted by it.

A portlet container is not responsible for aggregating the content produced by the

portlets. It is the responsibility of the portal to handle the aggregation.

A portal and a portlet container can be built together as a single component of an 5

application suite or as two separate components of a portal application.

PLT.2.4 An Example

The following is a typical sequence of events, initiated when users access their portal

page:

• A client (e.g., a web browser) after being authenticated makes an HTTP request to 10

the portal

• The request is received by the portal

• The portal determines if the request contains an action targeted to any of the

portlets associated with the portal page

• If there is an action targeted to a portlet, the portal requests the portlet container to 15

invoke the portlet to process the action

• A portal invokes portlets, through the portlet container, to obtain content

fragments that can be included in the resulting portal page

• The portal aggregates the output of the portlets in the portal page and sends the

portal page back to the client 20

PLT.2.5 Compatibility

The Java Portlet Specification V 2.0 does not break binary compatibility with V 1.0. This

means that all portlets written against the V 1.0 specification can run unchanged. Portlet

V2.0 containers must support deploying JSR 168 portlets and the JSR 168 deployment

descriptor.

The only exceptions to this rule are:

• RenderResponse.setContentType is no longer required before calling getWriter

getOutputstream. Calling getWriter or getOutputstream without previously

setting the content type results no longer in an IllegalStateException in V 2.0.

•

getProtocol for included servlets / JSPs no longer returns null, but 30

‘HTTP/1.1’ in V2.0.

PLT.2.6 Major changes introduced with V 2.0

The major new features of version 2.0 include:

Java

Portlet Specification, version 2.0 (2008-01-11)

• Events – enabling a portlet to send and receive events and perform state changes

or send further events as a result of processing an event.

• Public render parameters – allowing portlets to share parameters with other

portlets.

• Resource serving – provides the ability for a portlet to serve a resource. 5

• Portlet filter – allowing on-the-fly transformations of information in both the

request to and the response from a portlet.

PLT.2.6.1 Clarifications that may make V1.0 Portlets Non-

compliant

Depending on the implementation of the portlet of a specific runtime behavior of a portlet 10

container the following clarifications may lead to different results when executing a

portlet in either a JSR 168 or a JSR 286 container:

• XML escaping of portlet URLs produced via the portlet tag library.

V 2.0 clarifies that the default is all portlet URLs are XML escaped. The default

can be changed with the new attribute escapeXML. JSR 168 portlets depending on 15

the fact that portlet URLs created via the tag library are not XML escaped can

change the default to non-escaped via the portlet container runtime option

javax.portlet.escapeXml (see PLT.26.7)

• Defining multiple values for the same parameter name in the Portlet param tag.

V 2.0 clarifies that if the same name of a parameter occurs more than once within 20

an actionURL, renderURL or resourceURL the values must be delivered as

parameter value array with the values in the order of the declaration within the

URL tag. Portlets assuming that the last occurrence wins and replaces the

previous set values will behave differently in V2.0 containers.

• getProtocol for included servlets / JSPs no longer returns null. 25

V 2.0 defines that getProtocol now returns ‘HTTP/1.1’ and thus is better aligned

with the servlet model that expects the

getProtocol to return this value in the

GenericServlet.

• Parameters set on the portlet URL and the post body are aggregated into the

request parameter set. Portlet URL parameters are presented before post body 30

data. JSR 168 did not define if and how post body and portlet URL parameters are

being merged. The added clarification mirrors the behavior defined in the servlet

specification for servlets.

• RenderResponse.setContentType is no longer required before calling getWriter

getOutputstream. Calling getWriter or getOutputstream without previously 35

setting the content type will no longer result in an IllegalStateException.

PLT.2.6.2 Changes to the Programming Model

The following additions were made to the V1.0 programming model:

Java

Portlet Specification, version 2.0 (2008-01-11)

• Use application level resource bundles instead of inline localization in the

portlet.xml.

In V1.0 the only ability to localize values on the portlet application level was

inside the

portlet.xml using the xml:lang attribute. With V2.0 portlet

application developers can now provide the localized values in a resource bundle 5

and thus have the localized values in separate files instead of cluttering the

deployment descriptor.

PLT.2.6.3 List of all Changes in the Specification

This section list all changes that are not editorial in nature:

• PLT.1.4: added JAXB 2.0 reference 10

• PLT 1.8: added V2.0 Acknowledgments

• PLT 2.5: added compatibility section

• PLT 2.6: added complete section with major changes introduced with V2.0

• PLT 2.7: added JavaSE and JavaEE requirements for V2.0, now based on servlet

2.4, J2EE 1.4 and Java 5.0 and a special Java 1.4 compiled version. 15

• PLT 3.0: updated to reflect new portlet capabilities

• PLT 3.2: added section on using servlet application lifecycle listeners for portlet

applications

• PLT 4.1: added portlet section

• PLT 4.3: added section about portlets and web frameworks 20

• PLT 5.0, 5.2: added references to new lifecycle interfaces EventPortlet and

ResourceServingPortlet

• PLT 5.2.3: moved the End of Service section from end of this chapter to this place

• PLT 5.3: grouped the existing sections Portlet Definition and Portlet Entity and

Portlet Window to a new section Portlet Customization Levels 25

• PLT 5.4: added new event and resource lifecycle methods

• PLT 5.4.2: added Event Request section

• PLT 5.4.3: added reference to HTTP spec that render should be a safe operation

• PLT 5.4.4: added Resource Request section

• PLT 5.4.5.1: added Action Dispatching section 30

• PLT 5.4.5.2: added Event Dispatching section

• PLT 5.4.5.3: added Resource Serving Dispatching section

• PLT 5.4.5.4: added render mode annotation description

• PLT 6.3: added Default Event Namespace section

• PLT 6.4: added Public Render Parameter Names section 35

• PLT 6.5: added Processing Event QNames section

• PLT 6.6: added Publishing Event QNames section

• PLT 6.7: added Supported Locales section

• PLT 6.8: added Supported Container Runtime Options section

• PLT 7.1: added resource URLs and clarification that portlet URLs are only valid 40

within the current request and may not be real URLs.

剩余275页未读，继续阅读

samzhouzl

粉丝: 0
资源: 2

JSR-286: Portlet 2.0规范详解与IPC机制

portlet规范介绍

portlet 规范和API（jsr 168/286）

JavaTM Portlet Specification 2.0

portlet specification

portlet scope

什么是 portlet

portlet还有人用吗

spring支持的几种bean的作用域

spring支持几种bean作用域

spring bean作用域

最新资源