The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR

Community

Expert Group

Summary | Proposal | Detail (Summary & Proposal)

JSRs: Java Specification Requests

JSR 167: Java^TM Portlet Specification

This JSR has been Withdrawn
Reason: As there is very significant overlap between JSRs 162 & 167, Sun and IBM reached a mutual agreement regarding the proposals. They reached a point where they felt that they had a mutually acceptable new combined JSR proposal, which they then sought endorsement of from the existing supporters of JSR 162 and 167.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: A Portal is a web site that offers personalized content and services from different sources in a single place. This consolidation of content and services is normally referred as aggregation. The capability of selecting the content and services to display and their layout in the Portal page on user basis is usually known as personalization. An example of a Portal web site is http://my.yahoo.com/.

This specification will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security.

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Adam Abramski

E-Mail Address: adam.abramski@sun.com

Telephone Number: +1 408 276 6378

Fax Number: +1 408 276 4283

Specification Lead: Alejandro Abdelnur & Wesley Budziwojski

E-Mail Address: alejandro.abdelnur@sun.com & wesley.budziwojski@sun

Telephone Number: +1 408 276 5207 & +1 408 276 3594

Fax Number: +1 408 276-4283

Initial Expert Group Membership:

BEA
Epicentric
Sybase

Supporting this JSR:

Accenture
BEA
Borland
Bowstreet
Cap Gemini Ernst & Young
Citrix
Documentum
Enformia Ltd.
Epicentric
Interwoven
Macromedia
Plumtree
Sybase
Tarantella, Inc.
Vignette

Section 2: Request

2.1 Please describe the proposed Specification:

The Java^TM Portlet specification will define a Portlet API that provides means for aggregating several content sources and applications front ends. It will also address how the security and personalization is handled.

It will define the different components for Portal Computing, their interaction, lifecycle and semantics. These components will comprise -but they will not be restricted to-:
Portlets, Desktop, Deployment descriptor, developer APIs, and vendor extension APIs for security, user customization, and layout management. The Java^TM Portlet specification will define the minimum set of possible states for a Portlet-such as normal, minimized, maximized, etc.- and the valid state transitions per desktop type. The Java^TM Portlet specification will define an extensible Layout management but it will only mandate a basic one.

This first version of the Java^TM Portlet specification will concentrate in the following design goals:

Client agnostic
Support for multiple types of clients
Support for multiple types of desktops
Automatic client type detection and desktop selection
Simple developer API
Support for Localization and Internationalization
Hot deployment and re-deployment of Portal applications
Declarative security (same as to the mechanism found in Servlet and EJB specs)
The Java^TM Portlet specification will be built on top of the Java^TM Servlet specification. It is envisioned that the developer API will be similar to the Java^TM Servlet API.
The Expert group will consider functionality such as support for, parallel execution of Portlets within the Desktop, logging, security and personalization.
The Expert group will decide if the specification should include a set of specialized Portlet implementations for common tasks such as syndication (RSS), HTML scrapper, Web Services access, etc.
The Expert Group will evaluate defining a Credential mapping service to allow the Portal application to access resources in other applications -not supporting the notion of distributed sessions- on behalf of user.
It is understood that the subject of this JSR is already being addressed by Open Source projects and products from different vendors. The Objective of this JSR is to create a standard for Java Portal Applications, which will help unifying a fragmented area. The expert group will ensure this specification draws appropriately from such projects and products.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

A Java^TM extension for the J2EE 1.4 platform.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification will establish a standard API for creating Portlets, thus avoiding locking in Portal developers in a specific implementation and allowing Portlets developers to reach a wider audience while reducing their development efforts.

2.4 Why isn't this need met by existing specifications?

While the Servlet/JSP specifications define an include mechanism for aggregating Servlets and JSPs, they do not define the Desktop metaphor where this aggregation happens. Neither the Servlet/JSP specifications define the possible states and transitions of an included Servlet or JSP, or how the state of one Servlet or JSP affects the display of the other included Servlets or JSPs. In addition, The Servlet/JSP specifications do not define a personalization interface or the idea of persisting the personalization information.
The Java^TM Server Faces (JSR 127) aims to define a standard, MVC based, Web GUI framework focusing on the UI components (input fields, lists, buttons, etc.) and their event model. However, it does not address aggregation, security and personalization.

2.5 Please give a short description of the underlying technology or technologies:

The Java^TM Portlet specification will be designed leveraging the following technologies: XML, JAXP, Java Servlet/JSP, JAAS and other J2EE technologies.
For example, Java^TM Server Faces could be used by a Portlet developer to render the Portlet's content. In addition, Java^TM Server Faces could be used by a Portal vendor to implement the rendering of the Portal desktop. For a description of the Java^TM Portlet technology, refer to section 2.1.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.portlet.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

Yes. APIs and descriptors to support internationalization and localization are a fundamental design goal of this JSR.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

To be determined by the expert group, initial target is December 2002.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

We anticipate a mixture of mailing list and occasional face to face or teleconference meetings.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Different implementations are available today, the following list enumerates some of them:
Apache Software Foundation: Jakarta JetSpeed 1.3
http://jakarta.apache.org/jetspeed/site/index.html
BEA: Web Logic Portal 4.0
http://www.bea.com/products/weblogic/portal/index.shtml
IBM: WebSphere Portal 1.2
http://www-4.ibm.com/software/webservers/portal/
iPlanet: iPlanet Portal Server 3.0
http://www.iplanet.com/products/iplanet_portal/home_portal.html
Oracle: Oracle 9i Portal
http://www.oracle.com/ip/deploy/ias/portal/index.html

3.2 Explanation of how these items might be used as a starting point for the work.

They will be useful for gathering features and evaluating the effectiveness and shortcoming of each implementation.

2.1 Please describe the proposed Specification:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

2.3 What need of the Java community will be addressed by the proposed specification?

2.4 Why isn't this need met by existing specifications?

2.5 Please give a short description of the underlying technology or technologies:

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 Are there any security issues that cannot be addressed by the current security model?

2.9 Are there any internationalization or localization issues?

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

2.11 Please describe the anticipated schedule for the development of this specification.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

2.6 Is there a proposed package name for the API Specification? (i.e., `javapi.something`, `org.something`, etc.)