|
Technology INDUSTRY STANDARD
The Path to Portlet Interoperability
By John Edwards
JSR 168 and WSRP open portals to cross-platform deployment.
Easy, pain-free application integration tops the wish list of just about any organization engaged in enterprise portal projects. Hampered by proprietary APIs that impose reliance on a single portal platform, many developers find themselves forced to re-create the same portlet for different portal products.
Relief is on the way, however, in
the form of two new standards: Java Specification Request 168 (JSR 168) and Web Services for Remote Portlets (WSRP). Together, they promise to enable the development of portlets that work with various portal offerings.
Of Portals and Portlets
Over the past several years, portals have become powerful and sophisticated information clearinghouses. As portals have grown in number, scope, and influence, so has the importance of portlets. Portlets are Web components, usually managed by containers, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components to provide a presentation layer to information systems.
While portlets have become increasingly important and commonplace, getting them to work with multiple portals from various vendors has been a major headache. That's the problem JSR 168 and WSRP are designed to solve. "These standards remove the limitation of being able to develop portlets for only one platform at a time," says Michael Freedman, a consulting technical staff member of the Oracle portal team and a member of both standards' expert committees.
Developed under the auspices of the Java Community Process (JCP), JSR 168 addresses the areas of content aggregation, personalization, presentation, and security. It defines the functionality of
a portlet container and the standard interface through which it interacts with user-specific portlet code. It also provides a URL-rewriting mechanism for creating user interaction within a portlet container. In addition, the
standard defines ways of effectively handling portlet security and personalization characteristics.
Sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), WSRP defines a
standardized interface between a portal and portlet container service that allows the plug and play of visual, user-facing
Web services with portals. It enables interoperability between a WSRP-enabled container and any WSRP-compliant portal. WSRP defines a Web Services Description Language (WSDL) interface description for WSRP services, and provides Markup Fragment Rules for markup generated by WSRP services.
"Combine [the standards], and you get a portlet container that runs portlets developed for the Java platform and exposes them as Web services suitable for plugging into a WSRP-enabled portal,
on either the same or completely different platforms," says David Ward, team lead of Oracle's portlet technologies development team.
Seamless Interoperability
The power presented by JSR 168 and WSRP doesn't lie in exciting new features or functions, but in compatibility. Developers using the new standards can expect seamless interoperability. "You can build a portlet once and be assured that it will run on any compliant portal," says Jay Daugherty, senior director for Oracle Application Server Portal. "You have the flexibility to deploy your portlets wherever it makes the most sense." JSR 168 and WSRP also promise to make deployment easier. Adds Freedman, "You can deploy a single installation in a remote environment to service many different portals.
"With standards, it's not as difficult to move your portlet investment to another platform," adds Freedman. Streamlined portlet migration will make it easier for organizations to choose portal partners on the basis
of cost and capabilities rather than portlet compatibility.
Also standing to benefit from JSR 168 and WSRP are organizations that receive direct feeds from external Web sites. These organizations will be able to take advantage of the standard interface provided by WSRP. "This eliminates the need for special-purpose proxies," says Ward. With WSRP, a portal server can request markup from portlets by executing the standard getMarkup method call. Compare this with the situation before WSRP existed: "Each content provider had to invent his or her own specialized protocol for retrieving content," says Ward. "So if I wanted to use Content Provider A's weather portlet, I had to wade through lots of specifications to determine how to interact with A's systems, and then try to write the specialized code to integrate it with my portal."
Ready to Roll
JSR 168 and WSRP have both reached the end of lengthy approval processes. OASIS has given WSRP its final blessing. JCP, meanwhile, has published JSR 168's final draft.
With both standards now in place, Oracle is extensively supporting JSR 168 and WSRP with an array of products and services. "From a portal perspective, the standards will be included in a patch release to Oracle Application Server 10g, currently scheduled for the first quarter of 2004," says Freedman.
For portlet development, the Oracle Application Server Portal Development Kit (PDK) now supports both standards. The PDK, which can be downloaded from Oracle's Portal Center (portalcenter.oracle .com), includes the tools and documentation needed to build interoperable JSR 168 and WSRP portlets quickly and easily. Also included in the PDK is a Java Portlet Wizard that lets developers build interoperable Java portlets in Oracle JDeveloper.
To help organizations test their portlets, Oracle provides the Oracle Application Server Portal Verification Service (portalstandards.oracle.com). "The service is designed to let portlet developers test the interoperability of their standards-based portlets," says Freedman.
This hosted service demonstrates the ability of Oracle Application Server to use portlets built with JSR 168 and WSRP. Organizations building WSRP producers—the exposed portlet containers—can evaluate their implementations in Oracle's environment, and several vendors have already successfully used the service to test the interoperability of their producers with Oracle's implementation, according to Oracle's Ward. The service provides a setting for registering a WSRP producer and adding its portlets to a portal page. It also includes an Oracle WSRP producer containing sample portlets implemented with the Oracle Application Server PDK.
Just the Beginning
The final approval of JSR 168 and WSRP doesn't mark the end of the road for portal standardization. The benchmarks simply signify the first stage
of what promises to become a world
of complete and seamless portal portability. "The new standards let you
move the portlets, but there's a lot of data behind them and the portal
itself that ties users down," says Freedman. "Neither of these standards yet addresses the ability to take an existing portal—one that's already designed and populated—and migrate it to another product from the same or a different portal vendor."
Future versions of JSR 168 and WSRP, however, are certain to address the issues surrounding full portal portability. "My guess is that it will be a push to get the portal portability capabilities into the second versions; they will more likely fall into the third versions," says Freedman. The next editions of JSR 168 and WSRP are slated for release late next year, he notes, with the third versions possibly arriving a year or so later. "There's good synergy between the JSR 168 and WSRP groups, so it looks like the future release dates will be very correlated."
John Edwards (jedwards@john-edwards.com) is
a freelance technology writer based near Phoenix, Arizona. His latest book is Leveraging Web Services (AMACOM, 2003).
|
Portals and Portlets, JSR 168, and WSRP
A portal is a Web-based application that provides personalization, single sign-on,
and content aggregation from different sources and hosts the presentation layer of information systems.
A portlet is a Web component, usually managed by a container, that processes requests and generates dynamic content. Portals use portlets as pluggable user interface components to provide a presentation layer to information systems.
Java Specification Request 168 (JSR 168) defines a standard interface for portlets implemented for the Java platform and defines the contract between a portlet and its container.
JSR 168 addresses the areas of content aggregation, personalization, presentation, and security. It defines the functionality of a portlet container and the standard interface—the portlet API—through which it interacts with user-specific portlet code. The standard also provides a URL-rewriting mechanism for creating user interaction within a portlet container. In addition, it defines ways of effectively handling portlet security and personalization characteristics.
Web Services for Remote Portlets (WSRP) is a Web services standard that defines a standardized interface between a portal and a portlet container service. WSRP enables interoperability between a WSRP-enabled container and any WSRP-compliant portal. Its definitions include a Web Services Description Language (WSDL) interface description for WSRP services. The standard also provides Markup Fragment Rules for markup generated by WSRP services.
|
| 
Bookmark
