# Portlet API Requirements

Thomas Schaeck (schaeck@de.ibm.com)

15. November 2000

The purpose of this document is to gather the requirements for the Portlet API to be provided by JetSpeed 2.

To contribute requirements, please send a brief description with a rationale to jetspeed-dev@jakarta.apache.org under the topic “Re: Portlet API Requirements”.

### Self Contained API

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should be a generic API that does not expose JetSpeed intrinsics or components used by JetSpeed.

Rationale: This allows to implement the Portlet API on different bases, which is necessary to give the Portlet API the potential to become a standard.

### Separation of Data depending on Life-Cycle

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should clearly separate data that exists per portal, per portlet, per user, per-user and per-portlet, per user session or per request.

Rationale: This is required to implement the API and portlets that use it in a scalable and thread-safe way.

### Similarity to Servlet API

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should be similar to the Servlet API

- Portlet similar to Servlet
- PortletConfig similar to ServletConfig
- PortletContext similar to ServletContext
- PortletRequest/Response similar to ServletRequest/
- Response
- ...

Rationale: This will give all programmers who know servlets a quick start and lead to good acceptance of the API, increasing chances that it becomes a standard.

### Allow for pluggable Services

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g.

- User info (for getting user info like name, address, age...)
- Persistence (for storing per-user, per-portlet settings)
- Location (for obtaining the user's location)
- Personalization (for storing/getting personalization info)
- Data (access to databases, schema-to-object mappings)
- Content (access to syndicated content)
- Cache (access to URLs via caches)
- ...

Rationale: This allows for a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API.

### Flexibility to allow for generating different Mark-Up

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should be flexible enough to allow for rendering using different technologies (e.g. JSPs, XML/XSL...) as well as different mark-up (e.g. XML, WML, XHTML, HTML, VoiceXML, ...).

Rationale: This allows implementing portlets that can support various devices, either by doing final rendering or by producing XML that can be further processed.

### Provide abstract Base Classes to ease Development

(Thomas Schaeck – schaeck@de.ibm.com )

The Portlet API should provide abstract base classes for portlets.

Rationale: This allows for quick implementation of portlets by only overwriting the relevant methods.

### Only allow for XML compliant Output

(Raphael Luta)

The Portlet API should allow only well-formed XML compliant output from the Portlet.

Rationale: this would guarantee that the portal can always post-process the portlet output if needed and would prevent a portlet from breaking the display with a non well-formed output.