 | Level: Introductory Ann Fred, Staff Software Engineer, EMC
Stan Lindesmith, Staff Software Engineer, EMC
01 Feb 2003 Some software designers always choose the latest technology to implement their solutions. Others tend to stick with more familiar, time-tested platforms. In this article, Stan and Ann Marie put their Web application and portlet development experience to work to help you decide if portlets are the way to go for your application. They also provide an extensive list of resources for more information on the topics that interest you.
What are portlets? Portals? A portal server?
You may have asked yourself: What is a portlet?, What is a portal?, What is a portal server? Here, we present a summary answer for each question, and tell you where to find more information if you need it. Once you have a good understanding of what portlets, portals, and portal servers are, you'll be equipped to make an informed decision about using them for your projects.
The WebSphere Portal site provides IBM's working definition of a portal:
"Portals provide a secure, single point of interaction with diverse information, business processes, and people, personalized to a user's needs and responsibilities." There is a good analogy between what portals add to Web applications and what window managers (like Microsoft Windows) add to operating systems (like DOS). Both provide a consistent and uniform way to interact with applications.
Portlets, according to the WebSphere Portal site, are "visible active components users see within their portal pages... In the simplest terms, a portlet is a Java servlet that operates inside a portal."
See Figure #1 for an example portal page with two visible components on it. Each visible component is called a portlet. In this example, one portlet allows the user to go to a URL; the other portlet provides some reminder text to the user.
Figure 1. Example portal page with two portlets
A portal server provides common services such as application connectivity, integration, administration, and presentation that would be required across all portal environments. Functionally, a portal server serves the portlets to the user.
The WebSphere Portal Server site has a wealth of information on portlets, portals, and portal servers. We recommend starting there if you are not familiar with the basic concepts of portlets and portal servers. We also like the WebSphere Portal Zone, a technical site aimed specifically at developers and administrators for the WebSphere Portal Server.
Note: We are IBM Java programmers with lots of experience with WebSphere software, and little experience with competitors' products. We write about what we know, so most of the references and examples in this article are to IBM sites and WebSphere products. However, most of what we say here is not IBM-specific. The basic concepts and characteristics of portals, portal servers, and portlets are very similar, regardless of which portal server your company uses. We hope that anyone considering using portlets will find our article helpful.
Understanding Java servlets, JavaServer Pages, and Microsoft Active Server Pages technologies
Java servlets, JavaServer Pages (JSP), and Microsoft Active Server Pages (ASP) technologies are the tried-and-true development platforms for Web applications. They are mature platforms, with accepted standards and plenty of tools for developing and testing them.
Servlets are essentially a standard way of extending the functionality of a Web browser. They were designed to replace CGI (Common Gateway Interface) scripts. There is a standard API (application programming interface) that developers "fill in" to implement their Web applications. The servlet engine provides some useful and time-saving features, including converting HTTP requests from the network to an easy-to-use HttpServletRequest object, providing an output stream for the programmer to use for the response, and converting the easy-to-use HttpServletResponse object to an HTTP response that can be sent back over the network. The servlet engine also provides convenient session management features that allow you to remember users between requests, and you can allocate resources (such as database connections) that can be used for multiple requests. Like portlets, servlets act as a bridge between your business data and a Web browser interface. Servlets have the advantage of maximum portability: they can run within more Web servers or Web application servers and on more platforms than any other Web application technology available today. For more information, see Sun's Java Servlet Technology page (see Resources for a link).
|
ASP and JSP technologies
Although both Microsoft Active Server Pages (ASP) and JavaServer Pages (JSP) technologies provide the developer with a clean way of programming to the Model-View-Controller design pattern (see Resources for more information), there are significant differences between them.
You should consider which Web servers and platforms you will want to use to deploy your solution. You should consider if you want to use technology that is proprietary or that is based on open standards. You need to consider the future after you roll out your beta solution: do you need it to be extensible and highly scalable?
The article "Comparing JavaServer Pages and Microsoft Active Server Pages Technologies" provides an analysis of each of these concerns (and more); you'll find a link in Resources.
|
|
JSP pages are actually a type of servlet. Each JSP page is automatically converted into a servlet behind the scenes. Just like a servlet, JSP pages give developers access to the request and response objects, and you write your output to the response's output stream. Some developers make the mistake of completely replacing their servlets with JSP pages, but ideally they are used differently and complement each other. JSP pages provide a convenient syntax for generating your output - a mixture of Java, special JSP syntax, and browser markup (like HTML and JavaScript) - while servlets, which are pure Java technology, provide a cleaner way to interact with your business data. The Model-View-Controller design, which is familiar to many developers, helps us to use servlets and JSP pages together. The Model is your business data and objects that help you read and update it. The Controller is the servlet, which takes requests from the user's Web browser, acts on them using the Model, and neatly packages the information that the JSP page will need into one object (usually called a bean). The JSP page is the View, which renders the information from the servlet in a clear and visually pleasing way. Any platform that supports servlets can also support JSP pages. (See Resources for more information on JSP pages.)
ASP pages provide functionality similar to servlets and JSP pages. ASP pages are used to create an interactive Web page experience for the user. ASP pages also enable developers to use an MVC design to separate the business logic from the presentation by using ActiveX controls. They also integrate easily with Microsoft's .NET platform. However, unlike servlets and JSP pages, ASP pages are not compatible with Java portlets, and there is not an easy way to convert them into portlets. Because of the ActiveX controls, ASP pages are restricted to Windows platforms (unless you can find a third-party porting/bridging program that exists for the platform you are targeting). Overall, ASP pages are not as compatible with nearly as many Web servers, Web application servers, and operating systems as the Java technologies, so we prefer servlets and JSP pages.
For the sake of completeness, we should discuss CGI scripts. While CGI scripts were the favorite technology for interactive Web sites before the dawn of servlets, JSP pages, and ASP pages, they are outdated now, and we do not recommend using them for anything. There are some die-hard developers out there who still use CGI, but they are dealing with a lot of unnecessary pain. The newer technologies that we talk about in this article are much easier to develop, debug, and maintain. CGI has many limitations, performance problems, and security flaws as well. If cost is a concern, you can get a good Web application server that supports the latest technologies for free: check out the Java Web Services Developer Pack from Sun and the Apache Software Foundation's open-source Jakarta, Tomcat, and Jetspeed projects. The Apache server is also appropriate for real production systems. (See Resources for links.)
Understanding portlets
Portlets are a hot new Web application development technology. Although JSR 168 (see Resources) provides a portlet specification, portlets are not fully standardized yet.
For example, WebSphere Portal Server portlets will not work in the BEA portal server because the BEA application server does not support the WebSphere Portlet API. There are also not as many tools available to help you develop portlets as there are for the more established technologies like servlets. However, this is not a reason to avoid them. Once the standards are finalized, it should be simple to convert existing portlets to meet the new standards. Toolkits for developing them are already available, and development tools are improving constantly. Check out the WebSphere Studio Zone for portal and mobile device toolkits for WebSphere Studio.
There are not nearly as many trained portlet developers as there are experienced Servlet, JSP, and ASP developers. However, developers who have experience with these older technologies, especially servlets and JSP technologies, can quickly and easily learn how to write portlets. It is more cost-effective (and less tedious) for developers to write portlets than servlets because the portal server provides many features that the developers would otherwise have to provide themselves.
Portlets are actually a special type of servlet, and they also use JSP pages to render their user interfaces. The Portlet API extends and subclasses the Servlet API, meaning that portlets can do anything that servlets do, with some changes in their behavior and some extra features. The most significant behavior change is in how requests are served: servlets process "doGet" and "doPost" requests, which map to HTTP GET and POST requests, while portlets process "doView" and "doEdit" requests, which come from the portal server instead of directly from a Web browser. A minor improvement is the PortletLog, which provides better logging and tracing features than the standard Servlet API. A second improvement provided by the WebSphere Portal Server is better support for internationalization of your portlets. The Portlet API also gives you access to configuration information about your portlet application and your portlet instance.
Portlets also have many standard features that are not available to servlets at all. One key feature is built-in support to automatically use different JSP pages for different user devices. This lets you write portlets that work on many devices, including desktop computers with modern Web browsers, older or palmtop computers with limited Web browsers, personal digital assistants (PDAs), and Web-enabled wireless phones. You do not need to program to a lowest common denominator; you can provide multiple interfaces for different device types, reusing the same underlying business logic, and the portal server will choose the most appropriate one for each user. You can even have multiple portlet controllers, which allows you to have different page/action sequences for each device type.
Another important feature provided by the Portlet API is the ability to handle messages and events. The ActionListener turns user clicks in your pages into action events, an easy-to-use model familiar to many Java programmers. The WindowListener notifies your portlet of window events from the portal, such as when your portlet is maximixed, minimized, and restored. The MessageListener lets you handle messages sent from one portlet to another.
Yet another key feature of portlets is the ability to customize them in a number of ways. When developers use the standard Cascading Style Sheet provided by the portal server, all of their portlets will have the same look and feel. Companies can create themes and skins for their portlets that reflect their individual style, and all of the portlets (even those developed by a third party) will change to that new style automatically.
You can also customize your portlets on a user-group basis. You can assign some user groups permissions to use portlets, and those without permissions to use the portlets will not even see them in their portal. Your portlet can also change its output based on the user group(s) that the current user is in because the portal server provides an easy way to determine group membership. The portal server can use your existing LDAP directory to import user groups, or you can create a new user directory.
The third type of portlet customization is user preferences. Subject to limits that the portal administrator sets, users can decide which portlets are in their portal, what pages those portlets are on, and any other preferences your developers allow them to change. For example, you can allow your users to customize their stock ticker portlet with their own portfolio of stocks, and store that information in the PortletData object for that user. When the user logs out and returns they will have their saved preferences from the previous session.
There are many other valuable features provided by the WebSphere Portal Server and its extensions, including content management, transcoding, voice support, and offline browsing. If you choose to develop portlets you will also have these features available to you, but they are outside the scope of this article. More information on these advanced features is available on the WebSphere Portal Server home page and the WebSphere Portal Zone.
Portlets and Web services
Web services are another flashy new Web application development technology. Web services are modular applications that can be described, published, located, and invoked over the Web. These modular applications are are loosely coupled, dynamically bound components. For a good introduction to Web services and how they can be applied to real world business problems, see the series "Best practices for Web services" (developerWorks, January 2003).
Like portlets, Web services are not fully standardized yet, but standards work is well underway, and you can use Web services today. There are also some development tools available already, including the WebSphere SDK for Web Services.
| |
A Web service is a logical extension of object-oriented design. A developer can implement a function and then define that function (via an API) as a Web service. After the application is created and the interfaces defined, the Web service is made available (published) so that a customer (requester) of the service can use it. As seen in Figure 2, the architecture has three distinct users: a Web service provider who defines the modular application then asks the Web service broker to publish the application so that a Web service requester can use it in their application. The actions that these three take (publish, find, and bind) are also represented in the diagram. For more details of the Web service architecture, read "Web Services architecture overview" (developerWorks, September 2000).
Figure 2. Web services is a publish-find-and-bind architecture
Web services use a service description language to describe themselves to the outside world. You can read about the various standards for defining and marshalling your data in "Finding your way through Web service standards" (developerWorks, October 2002).
When do portlets make the most sense?
If your goal is to bring together your Web applications and information into one convenient place, portlets are the obvious choice. If your development goals are somewhat different, consider these other portlet and portal server features that you might want to take advantage of:
- Portlets can be extended to work on many client devices. Your users can move from computer to computer, and mobile device to mobile device, and still use the infomation and applications they need.
- Portlets allow you to easily customize their content for different user groups, and individual users can rearrange and tailor them to their needs.
- You can make your portlets have a unified look, and change their appearance quickly, using Cascading Style Sheets along with themes and skins that the portal server provides. You can create your own themes and skins as well, to better reflect your company's image and style.
- Portlets can be published as Web services, so that companies outside of your portal server's environment can easily write programs to use them.
- The WebSphere Portal Server provides excellent support for internationalization, beyond what your Web application server provides. It is straightforward to develop portlets that will display correctly for international users, even in double-byte or bidirectional languages like Chinese and Arabic.
- Portlets help divide complex applications into tasks: in general, one group of closely related tasks equals one portlet. WebSphere Portal Server's administration portlets are a good example: notice (in Figure 3) how the administration tasks are broken down into categories (Portlets, Portal Settings, etc.), groups of related tasks (Manage Users, Manage User Groups), and single tasks (Search for users, Create new user).
- Portlets make it easy to add features to your applications later. If the new feature is large, you should create a new portlet. For small updates, you can update the existing portlets without losing users' individual preferences.
- Portlets, like other Web applications, play well with firewalls. They use standard Web protocols to receive and display information.
- You only need to install and configure portlets once for all of your users, which is much easier than working with stand-alone applications on each computer. This applies to the other Web application technologies as well.
- The portal server works with the Web application server to provide security, installation support, reliability, and availability for many users, so you don't need to spend a large part of your development effort working on these features.
- Once you do invest in a portal server, you may find its advanced features useful: content management, transcoding, voice support, and offline browsing, among others.
Figure 3. A portlet is a group of closely-related tasks
When are other solutions better?
Portlets are not the solution to every design challenge. Here are a few things that portlets do not do well:
-
Complex user interfaces do not translate well to portlets. The markup languages like HTML and WML simply cannot describe some interfaces. Try to imagine implementing an integrated development environment (IDE) like Eclipse or Visual Basic in HTML and you'll have the idea. Native applications and Java applications work better for this. (If you have a complex user interface and still want to take advantage of the benefits of portlets, WebSphere Portal version 4.2 does support Struts, which can be very helpful. Struts are part of the Apache Jakarta project - more information is available on the Struts site; you'll find a link in Resources.)
-
User interfaces with data that must be constantly updated are also not portlet material. When you update one portlet, all portlets on the entire page must be re-drawn, so it is generally not a good practice to have your portlets automatically reload themselves with new data. On the other hand, you can have "refresh" option in the portlet so your users can choose when to reload the page. Figure 4 shows an example of a stock portlet with a refresh link from IBM's employee portal. The link will reload that portlet, but it will also reload the rest of the portal page. You cannot be sure how often users will choose to refresh the page, so if your data must not be out-of-date, use a native application or a Java application instead of a Web application.
Figure 4. Data that needs to be refreshed
-
Highly interactive user interfaces do not translate well to Web applications in general, or portlets in particular. If you want your interface to change automatically when a user takes some action, like selecting an entry in a drop-down list, you can either submit the form and reload the entire page (annoying), or use a scripting language to re-draw the portlet (very difficult). If you use a scripting language, you will need to make sure it works for all of the devices you want to support, and you will also need to make sure your portlet still works if scripts are disabled by some of your users. For mobile devices, you will probably need to have alternate JSP pages that do not use scripts. Native applications or Java applications are easier to make highly interactive than are Web applications.
-
Portlets need to live "within their box." Be careful if you have a link in a portlet that takes you to a Web page outside of the portal server environment, because it is difficult to get back to the portal after that. Frames are not allowed (Internal frames are allowed, but only Microsoft Internet Explorer users can see them). Pop-up windows and scripts usually cannot be used for mobile devices. If you can't make your application fit into the portal framework, don't make it into a poorly-behaved portlet.
-
If you will want to provide services to other applications, consider writing a Web service first. Once you implement a Web service, you can write a portlet to use it, and you can publish the Web service to share it with other applications. The stock portlet above is a good example: the stock quote service should be a Web service that the stock quote portlet and other applications can use. In this case, you might also write a program that automatically sends users a text pager message when a stock reaches a certain price.
-
If your company does not have a portal server yet, and does not plan to invest in one immediately, go ahead and implement your application as a servlet using JSP pages for the output. You can always convert it to a portlet later.
-
Portlets are not fully standardized, and they are not yet supported on as many platforms as the other Java technologies. Until then, you will have to lock yourself into one portal server on the server platforms that it supports. If this is not an acceptable trade-off, implement your application as a servlet first and you will be able to convert it to a portlet later.
 |
How do I get started?
If you have decided that portlets are a great technology for your next project, you probably want information to help you get started with development. The details of portlet development are beyond the scope of this article, but here are some links to articles and tutorials that will help you learn more about the WebSphere Portal.
Both the WebSphere Developer Technical Journal and developerWorks have published a number of great technical how-to articles that will help you write portlets. Search through their archives to find them.
Good tutorials for new portlet developers are "WebSphere Portal Programming: Pervasive Portlet Development" (WebSphere Developer Technical Journal, July 2002) and "WebSphere Portal V4 programming, Part 1: Portlet application programming" (developerWorks, August 2002). You may also want to know how to use WebSphere Application Developer and the portal toolkit to write a portlet. An older series of articles, "WebSphere Portal Server Development Using WebSphere Studio Application Developer" (WebSphere Developer Technical Journal, April 2002) may be helpful. You should also consider using a Web service with your portlet. A quick tutorial is the developerWorks article "Create your own portlet and Web service" (developerWorks, April 2002).
If you prefer a formal class, IBM Learning Services offers classes for portal and portlet developers. At the time this article was written, IBM WebSphere Portal Version 4 Application Development (course code PW531) is what we recommend. They also offer a course in IBM WebSphere Portal Version 4 Administration (course code PW431). Go to the WebSphere category to find them, or enter the course code in the search field. You can expect their classes to be very good to excellent.
Acknowledgements
We would like to thank the co-workers who proofread this article and provided valuable insight. Some of those reviewers are authors of articles referenced in this paper.
Resources - Get basic background information on What is a portal? and What is a portlet? from the WebSphere Portal Server product site, which provides many other answers about portals and portlets.
- Visit the WebSphere Portal Zone for a technical site aimed specifically at developers and administrators for WebSphere Portal Server.
- WebSphere Developer Technical Journal has published several helpful articles on how to write portlets.
- The WebSphere Developer Domain is a great technical resource for WebSphere developers, and includes the WebSphere Studio Zone, which provides portal and mobile device toolkits for WebSphere Studio.
- The Apache Software Foundation has Jakarta, Tomcat, and Jetspeed, the free open-source platforms for Web applications.
- The The Apache Jakarta Project site also provides Ant, a lovely multi-platform development build tool that can help you deploy your Web applications (and portlets) more easily. Struts are part of the Jakarta project as well.
- To learn more about using Struts, read "Struts, an open-source MVC implementation" (developerWorks, February 2001) or "Struttin' your stuff with WebSphere Studio" (developerWorks, September 2002).
- Sun has many good resources on the Web. The Java Servlet Technology website provides general information about servlets. The JavaServer Pages site provides information about JSPs. For more information about Model-View-Controller (MVC), please read the design pattern. And you can download the Java Web Services Developer Pack, which has a free (Apache-based) Web application server that supports the latest technologies, along with the other Java support that you will need to get started.
- Also on Sun's site: "Comparing JavaServer Pages and Microsoft Active Server Pages Technologies," Sun's analysis of the JSP vs ASP question. We also found this analysis written by someone who does not work for Sun or IBM.
- JSR 168 provides the details of the Java Specification Request for a portlet specification.
- For more information about Web services, read "Web Services architecture overview".
- For more information about combining portlets and Web services, read "Create your own portlet and Web service" (developerWorks, December 2002).
- Visit Marty Hall's site for a tutorial on servlets and JSPs.
- The series "Finding your way through Web service standards" (developerWorks, October 2002) takes you through the various Web services standards.
- The series "Best practices for Web services" (developerWorks, January 2003) provides an analysis of where Web services are applicable within real world business processes.
- "WebSphere Portal Programming: Pervasive Portlet Development" (WebSphere Developer Technical Journal, July 2002) is a tutorial on writing your first portlet that works on multiple devices.
- "WebSphere Portal V4 programming, Part 1: Portlet application programming" (developerWorks, August 2002) is another good tutorial on writing your first portlet.
- For information on developing portlets, themes, and skins using WebSphere Studio Application Developer, see "WebSphere Portal Server Development Using WebSphere Studio Application Developer" (WebSphere Developer Technical Journal, April 2002).
- IBM Learning Services offers classes for portal and portlet developers.
About the authors | 
| |
Ann Marie Fred is a Staff Software Engineer at the IBM Research Triangle Park Lab in North Carolina. She has several years of experience developing graphical Java applications, servlets, applets, portlets, and Web applications. Ann Marie's primary interests are in Pervasive Computing and Web applications. Her current project is developing portlets to administer IBM WebSphere products. Ann Marie received her Bachelor's of Science in Computer Science degree from Duke University in 1999. She is currently attending Graduate School in Computer Science at The University of North Carolina at Chapel Hill. You can contact her at amfred@us.ibm.com. |
| | |
Stan Lindesmith is a Staff Software Engineer at the IBM Pervasive Computing Lab in Research Triangle Park, North Carolina. He has several years of experience developing Java applications for IBM's wireless software products. Stan's primary interests are in Pervasive Computing. His current project is developing portlets to administer IBM WebSphere products. Stan received a Bachelor's of Science degree in Computer Science and a Bachelor's of Science degree in Applied Mathematics from the University of Missouri at Rolla in 1990. Stan received a Master's of Science degree in Computer Science from Michigan State University in 1992. You can contact him at stanl@us.ibm.com. |
Rate this page
| |
