Portlet Modes
Portlet mode functionality allows a portlet to display different information depending on which mode the user is interested in (the same can be said for window states, covered later). The portlet mode names given are rather obvious to anyone reading them as to what their function should be. Using a generic example of a WeatherPortlet, we can speculate on the definitions for each of the default modes covered in the specification:

• VIEW - doView(): Generates a content fragment displaying weather from NOAA.
• EDIT - doEdit(): Allows a user to modify his or her preferences, say, forcing the portlet to only show the weather in Miami, FL, USA.
• HELP - doHelp(): Displays a help HTML fragment with instructions on how to use the portlet.

Some vendors define custom portlet modes that your portlets can implement. Support for custom portlet modes is briefly defined in the specification, and is as simple as adding a custom-portlet-mode node to the portlet descriptor and any other vendor-specific modifications to the descriptor or the portlet class.

Window States
Window states control how much space any portlet takes up on any given page. They function when the portlet container passes the user's desired window state to the portlet. The portlet can then modify the fragment of data to display or even change the window state while processing the action request. The use of custom window states, much like custom portlet modes, is briefly mentioned in the specification and implemented by some vendors. Much like custom portlet modes, the portlet descriptor must be modified to use the custom-window-state element. Window states are briefly explained below. Note that not all portal vendors translate the specification in the same way, leaving much of the window mode behavior up to the portal implementation:

• NORMAL: This portlet has a limited space and is probably sharing a page with other portlets.
• MINIMIZED: In this state, a portlet renders no output, or very little content.
• MAXIMIZED: Normally, this state implies that the portlet will take up all the viewable area on the page. Often, it's the only portlet displayed on that page.

The Future of Portal Software
A subsequent version of the portlet specification should begin in the near future. Planned for future releases are topics such as:

• Interportlet-communication (IPC), allowing communication between portlets on events
• Portlet filters, which are similar to servlet filters
• Portlet markup extensions, where a portlet will be able to modify the markup outside of the markup fragment

Aside from additions to the portlet specification, there has been a trend by the portal industry to integrate outside technologies, augmenting their products' feature sets. You could expect this trend to continue and expand, given the growing popularity and success of portal software. Some of the technologies being integrated that are worth noting are listed here:

• WSRP (Web Services for Remote Portlets) specification: WSRP (www.oasis-open.org/committees/download.php/3343/ oasis-200304-wsrp-specification-1.0.pdf) allows for the creation of a distributed portal infra-structure. This facilitates WSRP-compliant portals being able to display portlets from another WSRP-compliant portal.
• JCR (Java Content Repository, JSR 170) specification: Adoption of this specification seems to be universal in the portal space. It seeks to provide a common API to content repositories; allows for architecture-agnosticism; and features support for versioning, locking, transactions, and searching, among other things.
• Framework support: Facilitates the use of existing Web application frameworks to be leveraged in portlet development, such as JSF/My Faces, Struts, and Spring MVC. Figure 5 shows Sun's JSF CarDemo application running as a MyFaces portlet inside of JBoss Portal.

The Portal Option
Now we must answer the question: "Are portals the magic bullet of Web application development?" To answer this question, you must look at the functional specification for the particular application being developed. Simply because you are developing a Web application doesn't mean you need to build or implement an existing portal. However, if your application specifications call for implementing some of the following, it would be wise to heavily consider using a portal:

• Single sign-on
• Personalization
• Content management
• User and role management
• Security and permissions management

Consider also some of the questions that we encounter from those evaluating portal software in their development projects:

My proposed Web application requires some of the features commonly found in portals; should I just develop my own proprietary architecture in-house then?

What we have found in the past when development teams create systems such as these, they tend to cobble in random odds and ends to fill the requirements listed with little consideration given to how all these disjointed parts will work together - if the component will be maintained in the future, will there be someone responsible for keeping up with the particular component, or if support outside of a mailing list is even offered for that particular component. During the development of JBoss Portal, we stayed away from creating what we refer to as a "Frankenstein Project" and leveraged technologies that were proven in production environments (see Figure 6) and supported in-house by the lead developers. This philosophy aided us in identifying problems when they popped up, and having the knowledge on-staff to deal with them. How comfortable are you allowing your developers to pick and choose random components from the Internet and glue them together? Leveraging portal software to handle the heavy lifting and intricacies of a Web application's development allows developers to concentrate on portlet development, which is probably the integral part of the business anyway.