META Group: The Emergence Of 'Portlets'

Since the inception of the portal market in 1999, each portal vendor has maintained its own proprietary portlet API (application programming interface), incompatible with all others.

www.metagroup.com

This situation has contributed to two problems that hamper the portal market. First, organizations face increased risk when they must invest in significant systems integration efforts using proprietary APIs. Indeed, systems integration often accounts for 25% or more of first-year portal costs. Switching costs and exit barriers are high for portals, prompting many organizations to delay committing to a single enterprisewide framework.

Second, many of our clients have reported multiple portal products in their organizations, and the lack of standards makes leveraging application connectors between portals difficult.

By the second half of 2003, we expect most proprietary standards to be marginalized, acting as proprietary value-added extensions to portlet standards. De facto standards - notably Microsoft Web Parts and, to a lesser extent, SAP iViews - have experienced minimal uptake so far, but they will experience a boost when Microsoft's SharePoint Portal Server and associated Web Parts standard become more intertwined with Microsoft's .Net strategy (2003/04).

We expect to see introduction of aggregation technologies that can act as a hub for a heterogeneous array of portlets by the second half of this year, though their utility will be marginalized by the strong uptake of true portlet standards expected in 2004. Once in place, these standards will be the foundation for the portlets of market-leading products through 2007.

Although portal vendors are driving standards efforts, application vendors have also been strong drivers in this area. Portal vendors want to establish clear points of differentiation (i.e., teamware, disconnected capabilities) before ceding their adapters to standards, while application vendors would benefit substantially by being able to expose a single set of portlets, instead of having to write multiple versions as they currently are required to do. End users also stand to benefit by having a much wider array of portlets compatible with their chosen portal framework.

As part of portal evaluations, organizations should rate vendors' participation in the relevant Web services standards bodies as part of "architectural fit" assessment. Adherence to portlet standards, while currently of little importance, will assume critical importance to architects in 2003/04. Most portal players (except Microsoft) have been active in these efforts.

Although Microsoft has been a prime mover of Web services technology, it has been notably absent from portal-specific Web services efforts, and we expect it to drive the Web services version of its Web Parts product.

Even when portal standards are accepted, all the complexities of portal construction will not be simplified. Indeed, none of the portlet standards help with administration, single sign-on, or provisioning. Therefore, organizations with multiple portals should plan to tie into a common directory, authentication, and provisioning system.

We expect portlet standards to come from three areas: Web services standards (the most important standards for the long term), Microsoft, and Java.

Web Services Standards

Web Services for Interactive Applications (WSIA; an OASIS technical committee) is a generic attempt to provide a system-to-user interface standard, but it is not portal-specific. WSIA provides a standard for describing metadata about visual, interactive components.

We do not expect specifications to be approved until the fourth quarter of this year, which means vendor implementations will not appear until the first quarter of next year (at best).

The Web Services for Remote Portals standard (WSRP; also an OASIS technical committee) is a portal-specific standard that sits on top of WSIA and will be more important to include in portal evaluations.

WSRP uses current Web services standards (e.g., SOAP for invocation, a specialized form of WSDL for defining portlets, publication through UDDI), and defines how portlets hosted inside an organization or from a third-party provider would communicate with applications.

WSRP meetings began in earnest in March, so, as with WSIA, we do not expect to have usable implementations of WSRP until 2003. By 2005, we expect WSRP or some evolution of it to be a basis for standardized Web-services-based portlets.

Unfortunately, Web services portal standards can only be as complete as the underlying Web services standards they rely on. Currently, Web services standards do not exist for metering, quality of service, security, or workflow, all of which would be useful for a creator of portlet Web services. For this reason, we do not expect portlet Web services adoption to gain steam until 2004.

Microsoft

Although Microsoft's Web Parts was not created by or submitted to a standards body, we believe it will be universally implemented by application vendors because of Microsoft's market power and dominance of the knowledge-worker desktop. By 2003, we expect Web Parts to provide true Web services and be part of Microsoft's .Net strategy.

Java Specifications

The Java Specifications Requests (JSRs) for portals (JSRs 168 and 127) are different from the Web services portlet standards in that they standardize the interface of the portlet rather than the protocol, and leverage the J2EE Connectivity API for connecting to enterprise applications.

The Java portal API will enable interoperability between portlets written in Java. Although these portlets could only run locally, they will be more tightly coupled than the Web services standards and should yield superior performance. The JSRs are in the early stage of definition, but we expect a specification by this year's fourth quarter or the first quarter of 2002.

Business Impact: Organizations can reduce the risk of aggregating interfaces of multiple systems by using a standards-based approach.

Bottom Line:Until portlet Web services standards are finalized, organizations that can obtain short-term, positive ROI from portals should feel comfortable connecting with vendors that are involved in the standards efforts. We expect these vendors to transition to standards as they become available.

META Group of Stamford, Conn., is a leading research and consulting firm, focusing on information technology and business transformation strategies. For more information, visit MetaGroup.com.