Portlet: Portal webservice technology
Work with hands-on project experienced teamplayer
M.Sc.EE (DTU) - Sun J2EE certified - BEA Weblogic certified - arbejdet som officiel IBM Global Services / BEA Systems / 7N / ProData konsulent...
This site only represent private opinions from a
humble M.Sc.EE consultant, operating without ties
to large companies. Information is provided without
responsability for how a reader might use it.
JSR 168 - Pluto - Tomcat
Java Specification Request (JSR) 168 defines a
from 2003 for portlets as Java-based Web components,
managed under a portlet container, organizing processing of requests and
generation of dynamic content. This definition is now being replaced by the succeeding JSR 286
Portals can make use portlets as pluggable user interface components
to build up a presentation layer in information systems.
JSR 168 objectives are also:
Disadvantages of JSR 168:
- Defining runtime container environment standards, providing portlet support
- Defining API between (portlet) container and portlets
- Defining fraework for storing transient and persistent portlet data
- Defining framework for allowing portlets to include servlets and JSP (JavaServer Pages)
- Defining deployment descriptor standards for packaging of portlets
- Defining binary portlet portability among JSR 168 compliant portals
- Defining standards for executing JSR 168 portlets as remote portlets using the Web Services for Remote Portlets (WSRP) protocol
- unable to provide asynchronous requests to individual portlets through direct URL addressing
- (subsequently) not straightforward integration with AJAX as the event handling
requires use of JavaScrips to some degree to avoid that the
entire Portal view (including all portlets) needs to be updated simultaneously.