Alejandro Abdelnur		Sun Microsystems, Inc.
	Wesley Budziwojski		Sun Microsystems, Inc.

 

Sun Microsystems, Inc.

Expert Group Private Page

 

This JSR has been withdrawn.

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.