If you plan to use WebSphere Portal to provide access to enterprise applications and data, then you need to become familiar with the workings of portlets, the building blocks of portals.
A key aspect of portlet design is defining how actions and/or information that a user provides can be used to personalize the content for the user. The object is to highlight information of interest. A portal that is designed simply to deliver generic information is little more than a glorified Web site, but a portal designed to personalize the content, based upon user preferences, becomes a truly valuable resource.
Portal developers can achieve this by leveraging the information-sharing capabilities of portlets. Portlets are, essentially, small, self-contained application components that process user requests and display the resulting content from within a portal interface. Several portlets make up a portlet application, and can communicate with each other to send events and synchronize content. For example, if a user enters a postal code in a weather portlet to display local weather information, a news portlet could use the same postal code to highlight local news stories. A well-designed portal is like one of those very special people who listen to and remember all the little details of what people around them like, and use that to personalize cards and gifts to them. The more you remember and the more broadly that you re-use that information to personalize the experience, the more successful your portal will be.
Now let's look at how portlets work. Just as all Web applications -- Java servlets and Java Server Pages -- run in a Web application server container, portlets too, run inside their own portlet container, which sits above the Web container and makes use of its services. The portlet container provides an API through which portlets access services to respond to user actions, communicate with other portlets, or access information.
Java servlets process user requests and return the results, typically in HTML, to the user. While portlets are similar to servlets in that they process user requests and return results, the portal identifies the type of device that is being used to access the portal, and allows the portlet to respond in a format specific to that device. By default, the portal identifies whether the device supports HTML, cHTML or WML and only renders portlets that support that output format. That's a key point: The portal isn't magically translating the portlet's output into a format appropriate for the device. Rather, the developer has to choose which output formats the portlet will provide, and the portal simply identifies the device type and renders the portlets which support the device's format.
Three Key Concepts
When developing portlets, it's important to understand three key design concepts: design patterns, page aggregation and deployment descriptors.
Design patterns are a fairly well known concept to programmers, although not all programmers use them, or use them well. Design patterns are essentially templates of best practices for solving specific coding situations. The most common design pattern is the Model-View-Controller, or MVC pattern, which is widely used and very applicable to portlet applications. I like to think of the MVC pattern in terms of the flow of processing user actions and returning results to them. When a user takes an action (presses a button, submits a Web form), the Controller is responsible for handling the request. The Controller takes the request and passes it to the Model component. The Model component executes business logic to process the request then returns the result (usually as a data object), to the Controller. The Controller passes the data object to the View component, which is responsible for displaying that data in format appropriate for the end-user, and making sure that any actions result in calls back to the Controller.
Besides providing a "best case" template for coding a specific application, the MVC pattern is also beneficial in that it promotes loose coupling of components. This allows components to be updated independently of each other, and reused in other applications. For some actual code samples written to the Java BluePrints patterns, which contain a version of the MVC, go to http://java.sun.com/blueprints/code/index.html
Page aggregation is the process of displaying a portal page, combining the "theme" or look-and-feel of the page, the "skin" or look-and-feel of the portlet, and the content of each portlet. One key factor to keep in mind is that your portlet is simply one part of larger portal page with other portlets and the portal look-and-feel. To avoid coding conflicts with other portlets, it is standard practice to only use markup that can be used inside an HTML, cHTML or WML table (depending on which markup languages you intend to support).
Deployment descriptors are configuration files for portlets. Just like Java Servlets, portlets use a deployment descriptor called web.xml to map user requests (URLs) to a Java class which implements the Controller component of the Portlet. Portlet-specific configuration information (such as which output formats that the portlet supports), is stored in another deployment descriptor called portlet.xml. One key thing to keep in mind about these descriptors is that the name of the portlet must always be the same in both deployment descriptors. If the name is changed in one, it must also be changed in the other. The WebSphere Portal Toolkit provides an editor for making descriptor modifications, which ensures that both descriptors are always consistent.
The concept of application portability gained fame thanks to the advent of Java and the Java Virtual Machine, which provides a virtual "platform" to run a Java application on any computer regardless of the underlying hardware and operating system. Portability has also become an important characteristic of portlets, although only they did not start out that way.
J2EE applications are portable because they run inside J2EE containers, which provide a standard runtime environment. Until recently, however, there was no standard portlet container. Each vendor made its own proprietary container, so that portlets created for one portal product could not be used in another vendor's portal. Fortunately, the Java community has developed a portlet standard, JSR 168, which defines a portlet container standard that provides consistency across portal products.
For WebSphere developers, however, there's a catch. Because WebSphere Portal was released before JSR 168 was released, IBM developed its own portlet container. Today, WebSphere Portal 5.0.2 provides two containers -- the IBM portlet container and a JSR 168 compliant portlet container that is new in 5.0.2. The IBM container provides portlet compatibility with existing portlets and has additional features that are not yet part of the JSR 168 specification such as the Click-to-Action feature which allows portlets to easily interact with each other. The JSR 168 container, of course, uses a standards-based API that makes portlet code portable between WebSphere and other portal products. Fortunately, IBM's WebSphere Portal Toolkit can generate code for both containers, and the developer can choose which container type he or she wants when creating portlets.
For more information on JSR 168 and the IBM Portlet API, read "Comparing the Java Portlet Specification JSR 168 with the IBM Portlet API." Also check out "Best Practices: Developing Portlets Using JSR 168 and WebSphere Portal V5.02."
Two Keys to Remember
When learning how to build portlets, design them to collect and share that valuable information that users provide, and use it to personalize the content to the user. Doing so will make the difference between a "nice" portal and a truly valuable one.
Also, using the WebSphere Studio and Portlet Toolkit will greatly simplify your portlet development. It has wizards that create portlet code that is MVC compliant code, and has a number of invaluable features to aid you in designing, editing, packaging, testing and deploying portlets.
Tony Higham is the chief solutions officer at FatWire Software and an expert on Lotus, WebSphere and Java technologies. He can be reached at tony.higham@FatWire.com.
Sue Hildreth is a contributing writer and editor based in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scalebelow. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.