Servlets and portlets and widgets, oh my
Over time, the Web component programming model has changed quite a bit. It started with servlets and monolithic applications in the Java™ space, moved to the portlet model and composable server-side components, and now to widgets as client-side composable components.
The Java Servlet Specification came into life as version 1.0 in 1997 and provided developers with the ability to create dynamic Web applications in Java. The servlet specification has evolved since then and is now part of the overall Java EE architecture. A Java servlet requires a servlet container to run it, like the one provided by IBM® WebSphere® Application Server.
The Java Portlet Specification started out in 2002 as version 1.0 to address the needs of the then-growing portal market to create server-side components in Java that could be aggregated by a portal application into a portal page. The portlet specification is now available as version 2.0 and there are discussions about including it into the next version of Java EE. A Java portlet requires a portlet container, like the one provided by IBM WebSphere Portal or WebSphere Application Server to run it.
Java portlets and widgets are similar in that both are component models that support ad hoc mashing up or aggregation within a single user interface. Both of these models provide capabilities for configuration and context sharing of combined components. Portlets and widgets differ in that portlets are always implemented in Java and run on a J2EE™ server, whereas widgets are user facing services that might be implemented in many ways, including Java portlets, static files, J2EE, PHP, Rails, or .NET®.
The client side widget model is still in its infancy and thus there are no settled standards available right now. Different vendors provide different implementations and solutions for the problem of having a composable component running in the browser. IBM WebSphere Portal and the upcoming IBM Mashup Center provide a client-side widget model that is modeled after the server-side portlet model. There is now an effort under way at Open Ajax to define a standard client-side widget specification in the Gadget Task Force. Widgets need a client-side container running in the Web browser for their execution.
Choosing the right technology
With this many choices, which technology should you use to solve your use case at hand? Here my personal thoughts on this:
I would use servlets for services that I need to write that do not have a UI part attached to it. A classic example are REST-services that might get accessed from client-side code and provide data to a client-side function that are not personalized to a specific user. Examples include content feeds, like ATOM or RSS, that provide information such as news feeds.
I would use portlets for UI-based Web applications as a default. I would even use portlets for a complete monolithic Web application if you start from scratch, since IBM WebSphere Application Server V6.1 lets you run portlets on the application server. This configuration has the advantage of letting you to offer your application via the Web Services for Remote Portlets (WSRP) protocol to a portal server to integrate your application into a portal -- or even to re-use this portlet later when moving from the plain application server to a portal server.
I would use widgets for highly interactive UI components and for creating typical mashup applications that are very narrow in the use case they address, since they are short lived and can be easily created using a script-based language. Widgets are also a solution for creating a mashup between different backend technologies, like a Java EE-based portal server and a PHP-based server. Widgets should never contain any critical business logic, since all code is running visible and modifiable to everyone on the client. Business logic should be hidden in backend services. Widgets and portlets can provide a nice synergy, as the user prefers, and access control can be applied to both the widget on the client as well as the business logic running in the portlet.
Of course, life is never as simple as this, and thus there are some gray areas where you need to decide what tradeoffs you are willing to accept, based on your specific situation:
- Servlets or portlets?
The first trade off is between servlets and portlets. You might have reasons to stay on the servlet path, like your favorite Web framework only supports servlets and not portlets, or you have a legacy application that is already servlet-based.
- Portlets or widgets?
Here, the tradeoffs are more difficult because you are comparing a server-side technology with a client-side technology. You also have more options here, as you can either enrich the server-side code with AJAX-based UI components, or leverage technologies like the client-side aggregation in WebSphere Portal V6.1 (Beta) that only re-renders the portlets that have really changed for a user request but not the complete page. My recommendation would be to start with a portlet if you are creating a business application, and to start with a widget if you are creating a typical mashup application.
Another alternative is to move one or two levels up in the abstraction layer. The first level of abstraction can be achieved by using UI frameworks that are agnostic to servlets or portlets, like JavaServer™ Faces (JSF), with which you can create your application based on JSF components and define a UI flow and state transitions. When running your JSF application, you can decide if you want to run it as a servlet or a portlet. Of course, this only works to the level where you use the features common to portlets and servlets. As soon as you start using additional portlet functionality, you will be bound to the portlet model. There is currently a Java Specification Request under way to standardize the portlet to JSF bridge (JSR 301) that will result in a portable way of using a portlet JSF bridge; this is also a candidate for the next version of Java EE.
The next abstraction level above UI frameworks like JSF is something like the IBM WebSphere Portlet Factory, which has the more course grained builder concept that even abstracts you from the actual UI framework being used. This enables you to upgrade your application to newer UI framework technologies, or to such things like client-side AJAX functionality, by simply selecting a newer version of the builder you used (or a different builder option), leaving your application otherwise untouched.
Things are currently moving in the Web component programming model and it is not always easy to select the best technology for a given use case. In my simple view of the world today, I would use servlets for creating non-UI-based services, portlets for UI-based business applications, and widgets for the mashup use cases. Of course, that simple view can be distorted by reality in many ways, some of which I tried to outline here. It will be very interesting to watch this space and see how the new client side technologies will be used in enterprise scenarios.
- JSR 286: Portlet Specification 2.0
- IOASIS standard: Web Services for Remote Portlets Specification v2.0
- JSR 252: JavaServer Faces 1.2
- IBM Mashup Center
- JSR 154: Java Servlet 2.4 Specification
- JSR 301: Portlet Bridge Specification for JavaServer Faces
- IBM WebSphere Portlet Factory product information
- IBM WebSphere Portal product information
- IBM WebSphere Application Server product information
- IBM developerWorks WebSphere Portal zone
- IBM developerWorks WebSphere Application Server zone
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.