Making Portlets More Portable
- Promise of Portlet Standardization
- Next Step: Cross-Portlet Coordination
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Enterprise portals were supposed to make life easier for corporate developers and their end-users by unifying access to disparate data sources and applications under a single user interface.
Alas, portals have suffered from the same proprietary standards and non-interoperability issues as the enterprise applications they were designed to centralize. That's because portlets—portal components—developed for one vendor's proprietary API cannot be used with a different vendor's portal. And given the many different types of portals that companies have accumulated over the years—through mergers and departmental IT initiatives—that lack of standardization has made life more difficult. It's been a problem not only for in-house developers struggling to support various portal products, but also for commercial portlet makers, who must create a different version of the same portlet function for each portal platform that they support.
"In the early days, complementary software suppliers would offer preintegrated portlets, or views, that would provide customized views into underlying applications [such as SAP or PeopleSoft]. But those didn't necessarily work [because] the customer had changed the data model or made some other customizations to the underlying application," says Brian McDonough, research manager for enterprise portal software at IDC, noting that prepackaged portlets fell out in favor of toolkits to allow customers to develop customized portlets. However, those portlets still can't be plugged into another vendor's portal platform.
Promise of Portlet Standardization
Two recently approved standards promise to make portlet development a lot smoother.
Sun Microsystem's Java Portlet Specification (formerly JSR 168) last year established a standard API for creating portlets so that developers can create one portlet and reuse it in any portal that supports the Java Portlet Specification.
A complementary standard, Web Services for Remote Portals (WSRP) version 1.0 from OASIS, defines a common interface and protocol for creating pluggable, user-facing, interactive Web services. WSRP standardizes Web services at the presentation layer of the Web services stack. JSR 168 portlets can be exposed as WSRP-compliant Web services. WSRP enables portlets to be accessed by multiple remote portals. For instance, this would allow one department's portal to access a portlet residing on another department's portal server.
"JSR 168 is the standard for actually building Java portlets and it addresses things such as personalization, security, content aggregation," explains Sue Vickers, the group manager for Oracle's 9iAS Portal. "WSRP comes into play for communication between the portal and [remote] portlets that you build—the actual plug and play of your Web services or your portlets."
Oracle, which is a contributor to the OASIS WSRP specification and a member of the Expert Group for JSR 168, issued preview releases of two of its portal tools with support for JSR 168 and WSRP included. Another supporter of the standards is Documentum, which incorporated JSR 168 into its Web Development Kit used for building content management-related components. Documentum also plans to support WSRP later in 2004, according to Jeff Spitulnik, senior product manager for Documentum's portal integration platform products. "The new specifications reduce the amount of variability between the portal platforms, so we have reduced both our development and maintenance costs, while at the same time expanding the functionality of our portlets," says Spitulnik.
So far, not many in-house developers appear to be doing more than initial experimentation with the specifications. However, Paul Walk, senior Web services developer for the London Metropolitan University, says his team's initial efforts with creating JSR 168 and WSRP portlets have been promising. The university has been exploring the idea of turning J2EE and ColdFusion Web applications into modular components that could then be used by commercial portal products as well as other Web applications. So far, they succeeded in turning a component used for student course enrollment into a JSR 168 portlet and then deploying it as a WSRP portlet on a test basis.
"My experience so far is that it seems to work and is worth pursuing," he says, noting that his group plans to continuing developing JSR 168-based portlets, which can be later deployed as WSRP portlets as needed.