Portal frameworks provide the infrastructure and tools for building portal sites regardless of which type they might be.

A typical portal framework combines a number of different tools. First and foremost, it contains the tools needed to aggregate, organize, and present information through a Web browser. Portals from this perspective are analogous to icons on the Windows desktop at an operating systems level or database icons on Lotus Notes' desktop pages at an applications level: they provide a convenient way for users to organize information. In this role, portals provide a uniform look and feel while allowing users to customize and personalize presentation.

The user interface to a portal is a portal page, containing some number of portlets that users can arrange into columns and rows and minimize, maximize, or arrange to suit their individual needs. Each portlet is a window into a Web site or application. The portal framework can define a default common look and feel for the portlets appearing on the portal page, and is responsible for intercepting and routing URL requests into specific portlets and for supporting navigation both between portlets and, in some instances, within portlets.

In addition to managing aggregation and presentation, the portal framework provides the infrastructure for handling common services across portlets. Portal frameworks now include an increasing number of advanced capabilities, such as:

• Business intelligence
• Categorization
• Collaboration
• Content management
• Integration
• Knowledge management
• Search
• Security
• Reporting
• Wireless access
• Workflow

JSR 168
JSR 168 Version 1.0 became part of Java 2 in October with the Executive Committee for SE/EE's approval of the 1.0 specification. JSR 168 creates a standard API for portlets to "plug into" Java 2 Enterprise Edition ( J2EE)-based portal frameworks. The goal is to have this API provide applications with portability across portal frameworks - allowing an application written to work in one framework to be able to execute in any standards compliant framework.

JSR 168 defines a portlet as a Web component that is managed by a portlet container. The portlet container runs portlets and provides them with the necessary runtime environment. The portlet container may operate either as part of or independently of a portal application (framework), the portal application being responsible for common portal services. Figure 1 shows the JSR 168 Portal Reference Architecture, originally presented in Alejandro Abnelnur's Portlet Specification briefing to the OASIS Technical Committee (you can find the briefing in its entirety at the OASIS Web site, www.oasis-open.org), modified to illustrate these components. In this architecture, the portlet generates markup fragments that the portlet container provides to the portal framework; the portal framework adds a frame, a title, and control buttons to create a portal window that becomes part of a larger portal page.

The JSR 168 API provides standard interfaces that allow Java-based portlets to interact with the portlet container and portal framework. The API defines standard interaction points exposed through an extensible portlet interface. It includes classes and methods for:

While JSR 168 addresses the interfaces between local portlets and the portlet container, it leaves it to the vendor to work out the interfaces between the portlet container and the portal framework, and it looks to WSRP to address the issue of remote execution.

WSRP Version 1.0
OASIS approved WSRP Version 1.0 as an OASIS standard in August; they are now working on Version 1.1, which is due out next year. WSRP provides a component model that allows user-facing Web services to easily plug into portal frameworks as remote portlets. Figure 2 shows the WSRP Reference Portal Architecture (see the WSRP Overview briefing at the OASIS web site) that supports both local and remote portlets. Local portlets run on the portal server (framework) and interact with the portal framework through the Portal API ( JSR 168 for J2EEbased frameworks). Remote portlets run on another server and interact with the portal server through Generic Portlet Proxies and WSRP. Generic Portlet Proxies allow the portal server to interact with remote portlets in the same way it interacts with its own local portlets, through the Portal API. WSRP provides the protocol for the portal server to interact with the remote server. WSRP also allows the portal server to make its local portlets available to other portals.

WSRP defines portal services as interactions between consumers and producers, where consumers are applications and portals that "consume" portlet services and producers are portal frameworks (or Web services applications) providing those services. WSRP defines portlets as Web services that generate markup and permit consumers to interact with that markup, and WSRP producers as containers containing Web services portlets. In this model, portlet containers expose their framework and the local portlets it supports through four types of Web services interfaces:

WSRP builds on Web services standards for publishing, finding, and binding services. Its goal is to enable any application, including portal frameworks, to publish their content as portlets, which portals can consume.

JSR 168 and WSRP are complementary: one's focus is on the local portlet code and its interactions with the framework while the other's is on remote interactions. Once both standards mature and appear in products, you will be able to develop portlet applications to the JSR 168 standard and depend on portal frameworks to provide WSRP services, when appropriate, as illustrated in Figure 3. This will allow you to create "write once, run anywhere" portlet applications without concern for whether users will access the portlets locally or remotely, through the framework or through another application.

JSR 168 and WSRP lay the foundations for future portal framework products. Brock's comment about portals becoming commodities implies a level of standardization that creates a certain degree of product agnosticism. This agnosticism could occur at two levels: at the market level determining the future of framework products themselves and at the individual developer level determining how you should be writing your particular applications. Are the standards enablers at either level? Yes. I've already discussed how they are enablers at the individual developer or application level.

To answer the question at the market level, let's look at what it means to become a commodity at the market level and how the standards' scope might affect the outcome, and forecast possible outcomes and what they would mean to you in terms of how you develop applications.

First, what does it mean to say the portal framework could become a commodity? A commodity is a product or service offered at or below cost to drive the sales of other products. Products tend to become commodities when the cost is already low and price becomes the sole discriminator. When a product becomes a commodity, it tends to lose its identity as it is absorbed into other products. Most of us immediately think of the Web browser when someone talks about commodities and software. Netscape and Microsoft "gave" browsers away in hopes of using them to sell other products. Could the JSR 168 and WSRP standards cause a similar phenomenon with portal frameworks, at least within the Java community? Could portal frameworks in this community become free or lose their identity?

Second, how does scope impact the answers to these questions? JSR 168 and WSRP focus on core portal functionality (aggregation and personalization) rather than advanced features (search, content management, knowledge management, and business intelligence), meaning they only address a subset of portal framework functionality. This opens the possibility for multiple classes (a high and a low end) of portal frameworks.

Finally, both standards distinguish between portlet containers and portal frameworks (leaving aggregation to the framework) and focus on defining the interfaces between portlets and portlet containers. This distinction opens the door for vendors to incorporate portlet containers, but not portal frameworks, into their products (similar to Web servers today where some Web servers are also J2EE Web containers).

Figure 4 summarizes the possible outcomes:

Let's look at the likelihood of each.

Outcome 3, which is a return to pureplay portal products, is the least likely of the three to occur. Many application server and enhanced functionality vendors already include portal frameworks as part of their products today. Oracle and BEA Systems are examples in the application server market; BroadVision, PeopleSoft, and SAP are examples in the enhanced functionality platform market. JSR 168 and WSRP containers offer an alternative by making it easier to tie products together, increasing portability and interoperability, and potentially reducing product development costs, but the question becomes why would vendors who are successfully integrating frameworks today switch strategies, limiting themselves to providing only portlet containers. The answer is they wouldn't. Such a strategy would create dependencies in areas where they do not have dependencies today, while only marginally reducing costs. This would reduce their ability to discriminate their product from the competition's and prove too limiting.

Outcome 2 is the second least likely to occur. With both application server and enhanced functionality vendors integrating portal frameworks as part of their product offerings, the market for pure-play portal frameworks becomes very narrow and primarily price driven. The question becomes whether pure-play portal frameworks can survive in such a narrow space. For this scenario to play out, pure-play vendors would have to find ways, other than price, to distinguish their products; the need for product differentiation would drive these vendors to compete on enhanced functionality and features. You have to ask, at what point would increasingly function-rich, featureladen products cease being portal frameworks and become either application servers or enhanced functionality platforms?

That leads us to Outcome 1 being the most likely of the three to occur. Application server vendors will incorporate JSR 168- and WSRP-compliant container capabilities into their products in order to maintain standards compliance. They will continue to include frameworks in order to differentiate their products and to promote their products' use in development environments. Others will follow in order to remain competitive. At the other end of the spectrum, enhanced functionality platforms will continue incorporating portal frameworks into their products in order to promote the enhanced functionality they offer and to provide full, independent solutions. They will include JSR 168 and WSRP containers in order to increase portability and interoperability. These trends' combined force will make price the primary discriminator for pure-play portal frameworks, making it unlikely they will be able to maintain their identity.

Conclusion
My weather eye sees the same future as Brock's: portal frameworks will in all likelihood become commodities (though it's debatable whether normal market pressures, rather than standards, aren't the real driving force). Given this prediction, you are probably asking what you should do to position your applications. First you should ensure you are working with vendors that have been part of the JSR 168 and WSRP standards efforts with strong commitments to integrating the standards into their products. Once the standards appear in the products you use, you should focus on writing portlets using the standards' defined APIs and interfaces, avoiding to the maximum extent possible any proprietary extensions. This should allow you to develop "write once, run anywhere" portlets, provided you stick with standards-based products. What if the prediction is wrong? How would this strategy change? It wouldn't! That's the beauty of standards and one of the benefits of the JSR 168 and WSRP efforts.

Regardless of which scenario actually unfolds, you should be able to develop "write once, run anywhere" portlets that make your applications more or less product agnostic and able to integrate with any of the standards-based frameworks. This promise is what following standards-based strategies is all about.

References