Recently, the first formal request for a new standard concerning the API between portals and portlets was submitted to the Java Community Process for review.

Java Specification Request (JSR) 168 proposes a standardized interface that allows so-called portlets to be written in a way that makes them universally applicable across all portals from all vendors. Once realized, JSR 168 will have a far-reaching impact and will represent a significant step forward in defining portlets as a prime interface to Web services, which can be conveniently aggregated and personalized within portals.

To understand the long-term consequences of JSR 168, it's useful to review the role of both Web services and Web-based portals in the development of application software targeted at the Internet. The concept of Web services has energized the realm of application development by providing a new type of Web-based platform that connects users and widely distributed applications residing on servers. Web services are generally defined as modular, encapsulated functions that can be loosely coupled to provide specific results to an end user ­ either an individual, an application, or even another Web service. The continuing growth of the Web has created the potential for precipitous growth in Web services and a nearly infinite combination of interactions between services and users of all types.

But in another sense, Web services has created an embarrassment of riches for IT professionals. Without some way to anchor and focus Web services for the benefit of specific end users, their productive impact will be severely constrained. A very practical solution to this problem is found in the Web-based portal, a well-established entity that aggregates and organizes multiple streams of information produced by applications distributed across the Web. The recent profusion of enterprise-level portals has already demonstrated their value as an organizing framework for Web services at all scales of operation, from end users to departments and enterprises. In every case they bring coherence to a potentially overwhelming and chaotic flow of information.

While the portal represents the client side of solving the Web services problem, it obviously requires a complementary entity on the server side. This need is now being filled by a software component called the portlet, which owes much of its technical ancestry to the servlet.

In earlier phases in the evolution of the Java Virtual Machine (JVM), the original intent was to have platform-independent code that would execute on the client side in the form of applets. However, over time, the concept of platform-independent Java execution migrated onto the server side, where the majority of an application's execution occurs, leaving the client to act more in an interface role. Hence, the emergence of servlets.

A portlet further extends this concept by having a Java-based application execute on the server side and then present the user with a highly flexible interface that resides within the graphic real estate of a portal, which treats the application as one of many interactive channels presented to the user at any given time.

The coupling of portlets to portals, which act as organizers/aggregators of portlet content, offers significant potential to the developer community, technically and economically. From a technical standpoint, the portal represents a good generalized software framework to guide the course of content development. Its infrastructure provides a number of attributes that support the tactical details of content delivery and presentation. These include items such as single sign-on capability; flexible and extensible authentication; management of policies via identity; device identification; distributed session management; and the ability to deliver content across a wide array of end user devices, such as desktop machines, cell phones, PDAs, and kiosks.

From an economic standpoint, the portal represents a convenient and clear way to organize the market for portlet content. Enterprises, organizations, and service providers will use the portal as a highly flexible vehicle to package services in ways that represent the specific requirements of various user communities.

However, to realize the full potential of portals and portlets, one last barrier remains, and that's where the proposed standard comes in. While the general concept of a portal is well understood and accepted, this belies a great deal of diversity in the way portals are technically constructed and how they interface with portlets. Consequently, developers must currently pick a target portal and write code aimed specifically at the execution environment defined by that particular one. JSR 168 seeks to remedy this situation by defining an API that universally dictates the interface between all portals and portlets across the Web.

While there are numerous details within JSR 168, it's worth considering some of the highlights that show the potential benefit of the proposed API. Most fundamental, with the formalization of the portlet API, the specification request officially defines a new atomic unit of execution within the Java arena, in the same way that JavaBeans, applets, and servlets are recognized. This concrete definition of a portlet gives programmers a clear frame of reference to guide their programming efforts. At the same time, it provides a client-agnostic programming interface that extends across all end-user devices with full provisions for declarative security and remote execution.

With the API specified by the proposed standard, portlets would have well-structured, predictable access to their host portal environment. For instance, they would be able to obtain and act upon user profile information provided by the portal. They would also be able to dynamically interact with the portal window and action event model to make the best use of their allotted real estate on the portal page at any given moment. They would also have a stable model for managing configuration (personalization) on a per-user basis. At a higher level, the API would allow portlets to interact with other portlets within the same portal environment through data sharing.

For a standard such as this one to gain broad acceptance, it must deliver benefits that extend through the entire value chain of the Web services industry, and a quick tour through this chain shows that JSR 168 will have consistently positive impact. Upstream, at the IDE level, toolmakers will have an opportunity to expand and remarket their current offerings to embrace portlets as a new atomic unit of execution. For instance, with a standardized API, it will become possible to automatically derive portlets from other applications via a new type of IDE tool.

Further downstream, developers will have a significantly expanded market opportunity because their applications will be freed from the confines of specific portal requirements. Writing to these ever-changing interfaces consumes a large share of development dollars that could otherwise be put into new content.

Once new content becomes available, portal providers will have a wide range of options in configuring the information flow on their portals. Right now, providers must individually construct and maintain the interface for each service occupying space in their portal environment. With JSR 168 enacted, the standardized interface will substantially reduce the time and cost of integrating and supporting Web services packaged as portlets.

At the enterprise level, the proposed standard promises to streamline the process of delivering specific applications to users throughout the organization. Once the standard is in place, all application vendors will have a single target for portlet development, and can routinely provide a standards-compliant portlet as part of the application itself. Also, the process of deploying portlets will be greatly simplified and can easily span portal products from multiple vendors, if necessary.

Perhaps the biggest benefit comes at the far end of the chain for the user accessing a portal from a desktop or mobile device. When JSR 168 is fully implemented, portal users everywhere will finally realize the full benefit and richness of the portlet as a primary point of entry into the domain of Web services.

JSR 168 operates in the great tradition of technology standards that shift market competition from proprietary lock-ins to a contest based on the best implementation for the broadest set of users. While it may produce some short-term disruptions, the long-term result is a major win for everyone involved.

On Portals and Portlets
Over the past couple of years, portals have come to play a key role in the delivery of applications, content, and, more recently, Web services. In general, a portal can be defined as a highly personalized Web site providing secure access to applications and business processes that the portal user shares with well-defined user communities on both sides of the firewall. All services delivered to the portal are based on a set of roles, permissions, and preferences assigned to the individual portal user.

For example, an engineer working on mechanical systems might have a much different portal configuration than an accountant assigned to inventory control within the same enterprise. Also, users have the latitude to extend beyond their portal's initial provisioning of applications and data and personalize its environment to suit their particular working style. At the same time, the portal should be able to support a full range of client device types and even different physical locations for the user. In terms of IT infrastructure, portals must be integrated with a number of other software components, including directory servers for user management and application or Web servers that provide a conduit to applications, data, reports, and transactions.

Portlets, on the other hand, connect to and display applications of various sizes and scopes that execute independently from the portal, but use the portal as either a dynamic or static interface to the user. In effect, portals can be thought of as collections of portlets. The permission to use these portlets is defined by the user's role in a given community, and is managed by the portal's interaction with various directory services. Multiple portlets may be running ­ and even interacting ­ within a user's portal at any given time.