Plug-and-play portlets

A push for standard Java and Web services interfaces for portlets promises to free the enterprise portal from proprietary frameworks

PORTLET INTEROPERABILITY, CURRENTLY the subject of two high-profile standards initiatives, is the dream of anyone familiar with today's enterprise portal landscape. The idea is that portlets -- those little portal windows that connect to specific back-end functions -- would be able to run in any portal environment regardless of the specific portal framework for which they had been written. This would save enterprises much of the time and money they currently spend custom-developing portlets for each portal vendor's framework. Furthermore, the notion behind one of the initiatives is that Web services could simplify the challenge of creating standard portlet interfaces, making it easy to plug any service or application (in the form of a portlet) into one big unified enterprise portal. Think this will happen soon?

Here's the problem: The portal is the Iwo Jima of enterprise software. It's where applications, content, and business processes come together in the eyes of the customers who pay for them. As a result, the portal will be the battleground not only for a fight between the Java and .Net camps, but also for a battle over the heart of the enterprise IT stack between application server vendors, integration and business process management (EAI/BPM) vendors, and packaged applications vendors (CRM, ERP, SCM), all of which offer their own portal products.

Portals serve a wide range of uses in the enterprise -- from internal self-service and knowledge management portals to external b-to-b catalogs and e-commerce platforms. They are about aggregating information and content (both static and dynamic), integrating functionality from other applications, and providing unifying services such as user access control, personalization, and a common user interface.

Most vendors' portal frameworks are written in Java; although they may be incompatible with one another, they use the same basic technology: J2EE (Java 2 Enterprise Edition), servlets, JSP (Java Server Pages), and so on. Portlets connect to back-end systems and resources through a variety of mechanisms, from screen-scraping to APIs. Every portal framework has its own portlet or components API, and often its own term for portlets, such as gadgets, gears, modules, and Web parts.

The push for open standards is being driven by the high cost of developing and maintaining proprietary portlets. Lacking such standards, today's portlets are very brittle: When a back-end application changes, the custom portlet code must be changed too. Most vendors provide a library of portlets to interface with common apps such as SAP or Siebel. Often these portlets must be customized, however, or developed from scratch to connect to homegrown or legacy apps. Consequently, many enterprises run multiple incompatible portals, creating a code-maintenance nightmare. And developer knowledge is fragmented among 30 different portlet frameworks.

Apart from SAP's iView technology for presenting portlets within Web pages, little has been done about portlet interoperability. Some vendors provide functionality for federating or connecting to other portals, including those built on competing technologies, typically by reverse-engineering them, which doesn't solve the brittleness problem. Other vendors are starting to offer portlets that can consume Web services automatically just by downloading the WSDL (Web Services Description Language) file.

But a real push is on to create a standard portal component or interface model so portlets can be shared and reused across frameworks, and published as services that can be syndicated to and consumed by other portals or applications. JSR (Java Specification Request) 168, a proposal submitted to the Java Community Process, is attempting to identify standard APIs for portlets to plug into J2EE portal servers.

The WSRP (Web Services for Remote Portals) technical committee of the Organization for the Advancement of Structured Information Standards (OASIS) is trying to develop a Web services-based, language-independent component model for plugging Web services into portlets, so service providers can implement to a common plug-and-play interface. WSRP services are essentially WSIA (Web Services for Interactive Applications) component services built on SOAP (Simple Object Access Protocol) and WSDL, with the addition of context elements including user profile and information about device, locale, and desired markup language.

Now the bad news: Much of the value of enterprise portals lies in the interaction and coordination among the different functions within the overall framework. For example, all portlets in the portal should draw on the same user and account management, personalization, session management, and directory and search capabilities. And perhaps most importantly, they should support process coordination and workflow so that a group of portlets representing services can act in a synchronized way as part of a business process.

The problem is that none of the players participating in the two standards efforts really want to standardize interfaces or APIs that will enable this kind of richer portlet coordination. That's because it would commoditize their own offerings, enabling other companies to exploit their application logic and infrastructure functions. A very possible outcome of both JSR 168 and WSRP, therefore, could be basic interfaces between portlets and portal servers, but not interfaces for enabling higher-level coordination such as session or process flow management. In other words, we'd get a neater view into the same old bunch of silos.

"The first cut at standards is going to be at the level of boxes on the screen ... sufficient to invoke a service and display it," predicts Dean Moses, chief architect of Epicentric Portal Server. Portlets will be able to move to different vendors' containers, but only if you don't use any single vendor's deeper capabilities or APIs. "They have existing investments in the frameworks," says Brian Murphy, product planner for Microsoft's Sharepoint Portal Server, of the leading J2EE portal players. "Every single one of them is dragging their feet."

Part of the current debate centers around the relative value of standardization within the Java world (via JSR 168) vs. broader standardization via Web services. JSR 168's API-level integration would be better for transactional portlets -- providing better performance, security, and scalability. "Now I'm gonna get 20 portlets interoperating ... that gets exponentially complex," says Sun iPlanet CTO Hal Stern. Java is a good language for assembly, he claims, due to its strong interfaces.

A Web services-based approach, by contrast, would sacrifice performance for broader applicability and interoperability. These interfaces would be less functional (and the question is how much less) especially in areas such as security, management, and QoS (quality of service). Incumbent integration players, and some JSR 168 advocates, paint Web services as wholly inadequate for any serious portlet or application integration, until more robust Web services protocols are developed. Yet both the Java and Web services approaches are pretty much starting from scratch when it comes to higher-level interaction issues such as metadata/directory, process, and identity management -- issues that are being addressed first in the development of other protocols such as WSIL (Web Services Inspection Language), WSFL (Web Services Flow Language), ebXML (E-business XML), and XSD (XML Schema Definition) and likely won't be incorporated into portlet standards for some time.

An interesting question is whether JSR 168 will support whatever protocol emerges from the WSRP group. "Our goal is that the Java portlet interface and WSRP standard are defined so it's possible to wrap WSRP services into portlet proxies written to the Java portlet API, and possible to publish portlets written to the Java portlet API as Web services," says Thomas Schaeck, architect of IBM's Websphere Portal Server.

IBM is the crossover vendor between the two communities, playing lead roles in both standards efforts. Other players are more partisan, calling the Java effort inadequate for connecting portlets to non-Java (legacy, mainframe, and Windows) systems, and anticipating that the JSR 168 group will drag its feet on support for Web services calls via HTTP.

The bloodier portlet battle, however, is about where integration gets done and who gets to do it -- and thereby stay closest to the customer. Portals are the emerging presentation layer for almost everything, including collaboration, so the question is what kind of integration will get done and which services will be provided at the portal versus lower in the stack? And how tightly, for example, will portals be linked with the application server? The major players, including app server, EAI, and packaged apps vendors, all claim that the piece of the puzzle they do best is the crucial piece, trying to leverage their competitive advantage to get into the other players' areas. The tone of the rhetoric belies the intensity of the fight.

"They call [the app server] a container for good reason," says Fred Meyer, Tibco's chief strategy officer. "Once you get in, it's very hard to get out. Application servers are built with the idea that they control the universe. ... You can't do messaging that way."

"Web services offer what appears to be a very quick fix," says Shane Pearson, group product manager of BEA's Weblogic Portal, but "bad things can happen if they're poorly written."

So what level of portlet interoperability can enterprises expect? Clearly both Java and Web services standardized interfaces are needed and will emerge -- life is too short for one company to rewrite every function you want in your portal. But just as clearly, the basic model of what a portal is is still being determined in the marketplace, which is shifting from pure-plays to big end-to-end players with integrated technology stacks and the incentive to pursue a lock-in strategy.

At a minimum, enterprises will get better development tools for building and customizing portlets and incorporating Web services. And as basic portlet interface standards start to emerge out of JSR 168 and WSRP, at least the presentation layer will become more interoperable and less brittle. Things can only get better from here.

Copyright © 2002 IDG Communications, Inc.