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.
One Portlet per war
In this approach, each portlet is bundled as one war file.
Advantages:
In this approach, we pack all the portlets in one war file.
Advantages:
This approach refer to portlets grouped together based on function/ same functionality into single WAR files.
Advantages:
Disadvantages:
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:
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:
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
- Messy deployment as the number of portlets grow
- Sharing of portlet session is an issue
In this approach, we pack all the portlets in one war file.
Advantages:
- Clean deployment, easy to manage
- Easy to share portlet session
- 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
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
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
- 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:
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
- 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.
2 comments:
Very useful article
Arun, this is very useful
Post a Comment