Portlet API

[Thomas Schaeck <SC...@de.ibm.com>]

As a part of IBM's initiative to enable interoperability between portals
and portlets for the benefit of portlet developers, ISVs, systems
integrators, portal vendors, and customers, we have submitted a JSR to
start the definition of a Java Portlet API standard. The new JSR should
appear at www.jcp.org soon, meanwhile see below for the scope of the JSR.

One of the next steps will be to form a Portlet API expert group and to
create a JCP community draft for the Portlet API Specification. We'd
apprechiate the JetSpeed community to support this standards initiative and
JetSpeed developers to get involved in the expert group.

Merry Christmas !

Best regards,

Thomas

Thomas Schaeck
Architect, WebSphere Portal Server Development
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479   Mobile: +49-(0)171-6928407   e-mail:
schaeck@de.ibm.com   Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany


Portlet API



The Portlet API specification defines an API for web application components
that interact with and can be aggregated in web applications like portals.
We refer to these components as portlets in the remainder of this text.


Portlets are web components like servlets, but have additional, special
properties that allow them to easily plug into and run in enclosing web
applications like portals. Portlets are designed to be aggregatable in the
larger context of composite pages, e.g. multiple instances of the same
portlet parameterized with different per-user, per-instance portlet data
can coexist on the same portal page. Usually, many portlets are invoked in
the course of handling a single request to aggregate their respective
produced markup fragments in a page of markup. The markup fragments
generated by portlets often need to contain links to trigger actions in the
portlet, therefore URL-rewriting methods are required that allow portlets
to transparently create links within the markup fragments they output,
without needing to know how URLs are structured in the particular web
application.


Portlets rely on the portlet container infrastructure accessible via the
Portlet API for functions like access to user profile information for the
current user, access to the window object that represents the window in
which the portlet is displayed, participation in the portal window and
action event model, access to web client information, inter-portlet
messaging and a standard way of storing and retrieving
per-user/per-instance data persistently.


The Portlet API provides standard interfaces for the functions mentioned
above. The Portlet API extends the servlet programming model and defines a
common base class and interfaces for portlets and tags for JSPs called by
portlets, cleanly separating portlets from the surrounding infrastructure
so that portlets can run on different portal servers like servlets can run
on different application servers.


The Portlet API specification shall evolve from the portlet concept as
developed in the Apache JetSpeed Open Source project. In many aspects, the
Portlet API is an extension of the Servlet API, defining additional
interfaces for portlet-specific functionality. In some other aspects, it
restricts use of functions provided by the Servlet API to the subset that
makes sense for portlets just producing aggregatable markup fragments and
not having ownership of the entire page that displays them. For example,
unlike servlets, portlets may not send errors or redirects as a response,
this may only be done by the application that invokes and aggregates the
portlets into a larger page.


Portlets can be grouped in Portlet Applications. Portlets in one portlet
application can exchange messages via the Portlet API. Portlet Applications
are packaged, distributed and deployed using WAR files that include
portlet-related meta-information, utilizing existing Servlet
infrastructure.


The Portlet API shall be compatible with the Remote Portlet Web Services
concept in the sense that portlets written to the Portlet API can act as
local proxies in a portal server for remote portlet web services located on
other servers and portlets written to the Portlet API can be wrapped into
remote portlet web services.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>