White Paper on Portlet App Development

1. Paper on developing JSR 168 portlet application with mutli-server deployment approach
Abstract
From the early days of web application development
when static HTML pages used to present the purely
static information on the browsers , to the days of
dynamic , sophisticated , state of the art websites which
fulfill almost all the demands of Internet users through
a unified interface, a lot has changed in terms of
technology, tools and knowledge when we talk of
Internet based application.
Static HTML based web application are obsolete and
no longer meets the overwhelming demands of the
Internet users who are now a days are not only the
people surfing web on their personal desktop/laptops
but they are executives, managers , corporate partners
of a large organization accessing diverse information
systems,decision support system, collaborating with
other counter parts to fulfill the growing demands of
their businesses.
From static HTML pages to dynamic and script
(PHP,CGI,Pearl etc.) driven web application, Internet
applications have taken a big leap but as the demand
grew it became difficult for those who wanted a Web
Site that offered users ability to access various systems
from a single web page. Although there are many
efforts taking place in the Java arena to provide systems
integration, none have made the same impact as portals.
Portlets are the components that are like a window on a
portal page which displays a piece of information or
application and when grouped together ,constitute a
portal page.
JSR168 portlet specification has emerged as universally
accepted guidelines and specification for developing
pluggable portlet applications and became a De facto
standard these days.
Keywords
JSR168, Portlet ,HTML, Portal
Introduction
JSR-168 is a collection of Java APIs for portlet
developers .The JSR 168 specification aims at
defining porlets that can be used by any JSR168
portlet container also called portals.
The current breed of portals either already support the
JSR 168 specification, or the developers are working
quickly to try and bring them up to par with the
specification. JSR 168 provides instructions to both
portal software manufacturers and portlet developers.
For portal software manufacturers, this JSR provides
the details on how a portal should be developed, what
interfaces and objects need to exist, the communication
process and sequence that should occur, security, and
much more. For the portlet developer, it provides the
interfaces that need to be implemented and used, the
lifetime and scope of the portlets, and other related
details.
This white paper discusses the approach for developing
vendor independent portlet applications based on JSR
168 specification.
Portlet Applications – A multi-server deployment perspective
Mohit Kumar
Portal Consultant
Birlasoft
+91-120 662-9000
mohit.kumar@birlasoft.com

2. Paper on developing JSR 168 portlet application with mutli-server deployment approach
The generic portlet application
Before I could explain , how to convert a portlet
application into a generic one, a brief information on
packaging and deployment of the portlet application
would be useful to understand the concept of a generic
portlet.
As per JSR 168 specification :
A portlet application's resources, portlets, and
deployment descriptors are packaged together in one
Web application archive (war file). In contrast to
servlet-only Web applications, portlet applications
consist of two deployment descriptors: one to specify
the Web application resources (web.xml) and one to
specify the portlet resources (portlet.xml). All
Web resources that are not portlets must be specified in
the web.xml deployment descriptor. All portlets and
portlet-related settings must be specified in an
additional file called portlet.xml. There are three
exceptions to this rule, which are all defined in the
web.xml, as they are valid for the whole Web
application:
The portlet application description
The portlet application name
The portlet application security role mapping
As result of the two deployment descriptor files, portlet
application deployment is a two-step deployment that
deploys the Web application into the application server
and the portlets into the portal server.
Now what is a generic portlet application?
A generic portlet application is a portlet application
which is written based on the JSR 168/286 API
specification and bundled as per the JSR168/286
specification.
However this is not possible to develop a one package
(portlet application archive) fit all (Portlet container)
application because all of the Portal Servers existing
today require vendor specific information added to the
portlet archive before deploying on their container. So
what is the way forward then?
Before I can answer the above question lets have a
look at the some of the leading Portal Servers
vendors that currently exist and understand what
dependencies they have to offer for developing and
deploying the JSR 168 portlet application onto their
Portal Server.
IBM WebSphere Portal
IBM provides with commercial tools like
WSAD,RAD for developing Portlet and other type of
application with a integrated test environment.
Developers can develop their portlet applications
using these IDEs and make a achieve deployable on
WebSphere Portal Server.
While developing JSR 168 portlet application in RAD
or using Application Server Toolkit to assemble the
application ,there are additional deployment
descriptors added to the WEB-INF directory of the
application e.g.
Ibm-web-bnd.xmi
Ibm-web-ext.xmi
These descriptors contain vendor specific information
that can be understood by the vendor’s server
implementation only (e.g. WebSphere Portal Server).
Apart from the deployment descriptors there are
vendor specific APIs that are commonly used in the
portlet application.Examples are PUMAAPI (IBM),

3. Paper on developing JSR 168 portlet application with mutli-server deployment approach
BEA Weblogic Portal
Like IBM , BEA too provides developers with an IDE
called Weblogic Workshop for developing portlet
application and other types of J2EE applications.
When I tried developing JSR168 portlet
application(also called as java portlets in Weblogic
Workshop) through Weblogic workshop following
were the default deployment descriptor which tool
automatically got added to the portlet application
project in the workshop apart from the usual portlet
deployment descriptor and web deployment descriptor.
beehive-netui-config.xml
netuix-config.xml
In order to deploy JSR168 portlet applications into
Weblogic Portal the application need to add into
Weblogic specific information in the form of .portlet
and .portal files in the project directories.
Also one has to get rid of the Weblogic specific APIs to
make the portlet application independent of any vendor
specific API.
Liferay Portal
Liferay Portal is an Open Source Portal which provides
a JSR 168 compliant container for deploying JSR 168
portlets.
Now Liferay also demands some deployment
descriptors which very very specific to its own
container. e.g.
Liferay-portlets.xml
Liferay-display.xml
liferay-plugin-package.xml
And to use those deployment descriptors properly ,
they require vendor specific DTDs to be included in
the XMLs.e.g.
liferay-portlet-app_4_3_0.dtd
liferay-plugin-package_4_3_0.dtd
Whatever IDE is used to develop JSR168 portlet
application for Liferay, one need to add above
deployment descriptors with proper configuration to
WEB-INF of the project in their workspace, if they
intend to deploy it on Liferay Portal.
So the above description about the various Portal
Server vendors of current time shows that they have
got some level of dependencies when deployment of
JSR 168 portlet application is concerned. Although all
of the above Portal Server vendors claim to provide
fully JSR 168 compliance for their portlet containers,
none of them completely complies with it.
The way forward
Therefore the answer is here , in order to build a
generic portlet application , the portlet application
must not contain any vendor specific API
implementation.

4. Paper on developing JSR 168 portlet application with mutli-server deployment approach
However for the reason that those vendor specific
deployment descriptors will not be parsed or read by
the portlet container, the vendor specific deployment
descriptors can be left untouched in the portlet archive
and hence they will not affect the deployment or
execution of the portlet application as far as the name
of the deployment descriptor doesn’t conflict with
another deployment descriptor.
Following are some of the points to remember while
developing JSR168 compliant portlet application that
are intended to run on multiple portal severs.
1. Identify target Portal Servers
Before developers start writing code for portlet
development in the editor of their choice , they should
plan for target portal servers i.e. what all portal servers
this portlet application is intended for.
e.g. The portlet application may be targeted to run on
WebSphere Portal Server ,Weblogic Portal
Server,Liferay Portal Server and Vignette Portal Server.
2. Identify Dependant deployment descriptors
As discussed above identify all dependent
deployment descriptor and include them in the
WEB-INF of your portlet application with
proper configuration.
3. Identify Vendor Specific APIs/Tag Libraries
Avoid including vendor specific APIs and tag libraries
in your portlet application package because when the
application will be deployed on a portal server which
do not understand those APIs , the portlet application
will fail to run.
Some examples of Vendor Specific APIs are PUMA
4. sdf
5. sdf
6.
API , Dynamic UI API ,Model API from IBM , NetUI
API from Weblogic etc.
Each of the vendor also provides their own tag
libraries to facilitate the development of JSPs in the
portlet application some example include Portlet API
Tags from IBM ,NetUI tags from Weblogic etc.
Instead of the vendor specific tag libraries , always
use standard portlet tag library.
4. Avoid vendor specific framework APIs
Struts portlet framework and JSF portlet framework
are being used by many developers these days for
developing robust portlet applications.
However most of such frameworks are vendor
specific and do not provide interoperability between
different portal serves.
e.g IBM Struts Portlet framework is proprietary to
IBM and portlet developed with this framework will
fail to run in Weblogic or Liferay portal.
Some other examples are Apache Myfaces portlet
framework , IBM JSF portlet framework etc.
Below is a snapshot taken from Weblogic Workshop
IDE that depicts how your WEB-INF of portlet
application will look like after you have supported
your portlet for deployment on WebSphere, Weblogic
and Liferay.

5. Paper on developing JSR 168 portlet application with mutli-server deployment approach
Snapshot of WEB-INF
Our Custom framework
For developers looking to build JSR 168 portlet ,
below is a recommended structure of framework that
will ease their development effort and later on
deploying on their targeted JSR 168 compliant Portal
Servers.
The purposed JSR168 portlet framework will
consist of 5 basic layers in the application namely
1. Portlet
2. Delegate
3. Service
4. Data Access
5. Model
And 3 additional support layers:
1. Exception
2. Logging
3. Utility
Reference Package Structure
Layer 1 : Portlet
com.ti.module.portlet
Layer 2 : Delegate
com.ti.module.delegate(Interface)
com.ti.module.delegateImpl(Implement
ation)
Layer 3 : Service
com.ti.module.service(Interface)
com.ti.module.serviceimpl(Implementati
on)
Layer 4 : Data Access
com.birlasoft.imms.dao(Interface)
com.birlasoft.imms.daoImpl(Implement
ation)

6. Paper on developing JSR 168 portlet application with mutli-server deployment approach
Layer 5 : Model
com.ti.module.model
And 3 additional support layers:
Layer 1 : Exception
com.ti.module.exception
Layer 2 : Logging
com.ti.module.log
Layer 3 : Utility
com.ti.module.util
Popular Servers
source : http://portlets.blogspot.com
Conclusion
The portlet application targeted for multiple portal
servers require some level of discipline in using
vendor specific APIs and other artifacts.
There are plenty of portal servers available today ,
some are commercial , some are open source and each
of the portal server provides their own mechanism and
tools for developing portlets applications, but more or
less they are all propitiatory. The need for developing
open standard based portlet component is increasing
at a great pace.
Multi-Server deployable portlet application can be
developed by avoiding usage of proprietary APIs and
implementing a generic framework defined in this
paper.
REFERENCES
1. JSR 000168 Portlet Specification
http://jcp.org/aboutJava/communityprocess/review/jsr
168/
2. WebSphere Portal Infocenter
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/
index.jsp
3. Weblogic Portal Server and JSR 168
http://dev2dev.bea.com/pub/e/314