How to refactor a Java portlet application for a cloud-native future
The portal server isn’t dead, despite the ongoing consensus within the Java community that the time for portlet development has come and gone. But, the fact remains that companies like HCL still sell licenses to their portal server, and service-based vendors still sign big portal server support contracts. As such, developers who work on portal projects still write Java portlet applications based on the JSR-286 or JSR-362 APIs, which doesn’t bode well for organizations who want to pursue a more cloud-native future.
If organizations use a Java portal server as the center of their digital experience platform, their developers will be tempted to write Java portlet applications with the standard Portlet APIs. However, developers should avoid this method at all costs.
While developers write the code in this outdated fashion, once the architecture team recognizes there are better options available, the code will eventually need to be rewritten and moved onto something more compatible with modern, cloud-native development and deployment trends. The current model may work, but if an organization wants to move into the future, then it will need re-evaluate its processes and identify areas for change.
| Learn Apache Struts 2 Quickly |
|---|
| Here’s how to learn the fundamentals of Struts 2.5:
Follow these steps and you’ll be an Apache Struts 2 expert in no time! |
For organizations that need to build and deploy Java portlet applications today, here are a few ways to either minimize the use of Portlet APIs and subsequently create components that are more consistent with DevOps based, cloud-native computing environments.
Treat Java portlet applications like microservices
If you must develop a portlet, use a client-side rendering framework such as React, Ember or Angular to provide the UI. This allows the rendering aspect of the Java portlet application to be largely detached from the Portlet API, and the UI can be easily repurposed into a non portal environment.
Furthermore, move the logic from any interactions with backend services or state management functions out of the portlet and into Spring Boot microservices or behind RESTful APIs. Then, only use the Portlet APIs as an intermediary between the two. This allows you to still deploy applications to the portal using traditional portlet development and deployment techniques, while at the same time minimizes your dependence on the Portlet API and makes your architecture more cloud native.
Minimize the use of portlet-specific features
The Portlet API provides access to a number of very powerful features and services — like Portlet Preferences and Portlet Messaging — that aren’t available on standard application servers such as Tomcat or Jetty. While these features can be tempting to use because they can greatly improve the overall user experience, they come with the cost of lock-in. Furthermore, Java profilers tend to show they respond slower than the Servlet API.
Any Java portlet application that uses these features will need to be completely reworked when you adopt a cloud-native approach and migrate to a more lightweight, loosely coupled architecture. Avoid using features specific to the Portlet API that have no analogous implementation in frameworks such as Struts, JSF or the Servlet and JSP API.
Use the JSF or Spring portlet bridge
If you can’t avoid developing a Java portlet application, one option to minimize your technical debt is to use a portlet bridge.
Spring and MyFaces are two of the more popular portlet bridges. These software plugins allow you to develop portlet applications with either Spring MVC or JavaServer Faces by abstracting the underlying Portlet APIs. The result is an application that uses a more modern framework, is not dependent upon the underlying portal infrastructure, and can be easily deployed to an open-source Tomcat or Jetty server with only a few configuration changes.
The Spring MVC Portlet can help abstract away underlying Portlet APIs and make your Java portlet applications more cloud native
Use a content rendering portlet
All major portal servers provide a content rendering portlet that sends HTML and other web resources like JavaScript and CSS to the client. If your software development team can deliver all the required interactivity by your proposed Java portlet application through the HTML, JavaScript and CSS to the client, you can completely avoid any development against the JSR-286 or JSR-362 Portlet APIs. This move will completely free your applications from the portal and allow them to be easily migrated into any cloud-native environment or other content delivery system.
Cast Portlet APIs into Servlet APIs
Developers should avoid the Portlet API at all costs. On the other hand, the Servlet and JSP API still has a very bright future because all major Java web application frameworks are built upon the API as their foundation.
In fact, in most portal server implementations, the Portlet APIs are simply an extension of the underlying Servlet and JSP APIs. As a result, you can usually cast the Portlet components into their corresponding Servlet component. For example, it’s normally possible to convert the PortletRequest into the HttpServletRequest, or convert the PortletContext into the ServletContext, and so on.
If you write Java portlet applications as though they were a traditional Servlet and JSP application, you’ll be able to port those applications off the portal server and into a standard Java application server with minimal difficulties. And, if you avoid the use of Servlet APIs that are not particularly cloud-native — such as the HttpSession — your applications can be easily converted into microservices and deployed in Docker containers to Kubernetes clusters.
Ways to refactor Java portlet applications
In review, five strategies to refactor Java portlet applications into more cloud-native friendly components include:
- Think like a microservice
- Minimize the use of specific portlet features
- Use the JSF or Spring portlet bridge
- Use a content rendering portlet
- Cast Portlet APIs into Servlet APIs
The Java portal server has lost its luster as the centerpiece of an organizations digital experience platform. As such, those tasked with the development of Java portlet applications should be aware of the potential technical debt when new JSR-286 and JSR-362 portlets are developed and deployed.
If you take these five portlet refactoring strategies into account, organizations who do host applications on a portal server will make the migration to a cloud-native environment a much easier task when the opportunity eventually arises.