What are the different Portlet deployment approaches in Portal environment ?

During Portal development, there is always a question that comes up –

What is the best way to deploy portlets within Portal environment?

This article lists down different ways of deploying portlets within Portal environment listing advantages and disadvantages of each.

Portlet Deployment

One Portlet per war

In this approach, each portlet is bundled as one war file.

Advantages:

• Abstraction to the lowest level
• Independent development and testing of portlets
• Change to single portlet will not impact other portlets within portal

Disadvantages:

• Messy deployment as the number of portlets grow
• Sharing of portlet session is an issue

All portlets in a single War file

In this approach, we pack all the portlets in one war file.

Advantages:

• Clean deployment, easy to manage
• Easy to share portlet session

Disadvantages:

• Parallel development is a challenge
• The size of the deploying war becomes extremely large and takes a long time to deploy
• Single change in one portlet will cause a redeploy of all portlets, adding re-testing overheads and making portal unavailable

Grouping portlets in one war

This approach refer to portlets grouped together based on function/ same functionality into single WAR files.

Advantages:

• Small changes to a functionality will not affect the overall portal
• Clean and easy to manage
• Portlets which need to share session will be grouped into one
• Parallel development at functionality level is possible

Disadvantages:

• Maintenance at individual Portlet level might affect other packaged portlet of the application

Shared Libraries

Apart from portlet applications, there are certain shared libraries used by most of the portlet applications (WAR's). This lead to challenge of how to deploy these shared applications. Here are few options:

Single Portlet application and shared libraries packed into one EAR
This approach suggests having single portlet application, along with shared libraries and resource files, packed as one EAR file.

Advantages:

• Each EAR will be truly independent
• Common functionality could be extended based on the need of the portlet application
• Changes to shared libraries will not impact all the other independent EAR's

Disadvantages:

• Each EAR would be large and will take longer deployment time
• Each individual EAR would contain copy of the framework classes and maintainability of different versions of framework classes in different columns will be a challenge
• More complex deployment process
• Changes to shared libraries will require redeployment of all the EARs
• Complex deployment
• Class loading strategy of the application server would have to be restricted to PARENT LAST

Multiple Portlet applications and shared libraries packed into one EAR file

This approach suggests that multiple portlet applications along with shared libraries and resources files, such as properties, packed into one single EAR.

Advantages:

• All portlet applications share same common libraries

Disadvantages:

• Big size and will take a long time for deployment
• Change to single portlet application will require redeployment of whole EAR and thus unavailability of the application
• Complex deployment

Shared library in ext of Portal server

This approach suggests that the shared library to be placed within the ext library directory of the portal server. This approach is suggested when there is are framework libraries which need to be shared across the organization (Organization level frameworks for logging/exception handling etc.) and each application hosted in the environment should follow those standards.

Advantages:

• One of the most common way of sharing the files among the multiple applications
• In portal world, all the common files pertaining to theme, portlets and third party application are stored in shared library
• No need to use Dyna Cache or JSR 286 events to  save and share values across portlets
• Library would be available across applications
• Individual applications would be lighter since they won’t contain the code for framework classes

Disadvantages:

• Change management for the shared libraries would be very risky

Steps for Creating a Shared library on Portal Server

• Logon to Websphere Application server console
• Navigate to Environment -> Shared Libraries
• Click apply and save it

Assigning to a server

• Go to servers -> Application servers -> websphere portal -> Java and Process management -> classloader.
• Click Shared library references
• Add the library that you want to share
• Save the configuration and restart the Portal server.

Note: Restart of server is mandatory for the class loader to load all the newly added class files. Now, you can add the shared jars to build path for proper compilation and deployment.