Comment lines: Stefan Hepper: Rolling with developments in the Web component programming model

Should you use servlets, portlets, or widgets? Here are some guidelines to help you sift through new technologies and specifications and make the best decision for what you want to accomplish. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Stefan Hepper, WebSphere Portal Programming Model Architect, EMC

Stefan HepperStefan Hepper is the responsible architect for the WebSphere Portal and Workplace programming model and public APIs. He co-led the Java Portlet Specification V1.0 (JSR 168) and is now leading the V2.0 (JSR 286) effort. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory.


developerWorks Professional author
        level

18 June 2008

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:

  • Servlets

    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.

  • Portlets

    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.

  • Widgets

    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.


Other options

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.


Summary

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Lotus
ArticleID=314538
ArticleTitle=Comment lines: Stefan Hepper: Rolling with developments in the Web component programming model
publish-date=06182008