Members of the OASIS standards consortium Thursday advanced Web Services
for Remote Portlets (WSRP) 1.0 as an OASIS Standard, codifying how portal
front ends should consume Web services, and the way which content providers
should write Web services for portals.
“WSRP defines how Web services plug into portals,” said Thomas Koulopoulos,
president of Boston-based Delphi Group, a consulting firm which specializes
in commerce, portals, content and knowledge management, enterprise
wireless, and e-Learning. “Once a WSRP service is published to a public
directory, portal administrators are able to locate and dynamically
integrate it with just a few mouse clicks. WSRP is a critical standard
enabling distributed portals to share portlets as visual, user-facing Web
services for integration with other portals.”
OASIS said WSRP will eliminate the need for content aggregators to choose
between locally hosting a content source or writing code specific to each
remote content source. Instead, through the standard, OASIS said content
can be hosted in the environment most suitable to its execution, while
remaining easily accessible to content aggregators.
“WSRP is intended to provide an interoperability specification for portlets and other pieces of application and interface functionality to be easily interchanged between portal providers and the consumers of those application interfaces,” Ronald Schmelzer, senior analyst with ZapThink, a research firm specializing in XML Web services, told internetnews.com. “Basically, a developer can create a portlet for an Oracle portal server and consume it within a Plumtree portal server. The idea is that it’s not just the functionality of the portal that needs to be interoperable, but also basic interface and navigational elements.”
Fellow ZapThink senior analyst Jason Bloomberg added, “The Web services referred to in the ‘Web services for Remote Portlets’ specification are presentation-oriented Web services, which makes them a bit different from most Web services that provide application interfaces independent of how the resulting information is presented to the user. The key challenge facing portals that wish to use these presentation-oriented Web services to provide interoperability across different portal platforms is the challenge of maintaining state — for example, authentication status, where in a business process the user is, etc. Since the browser environment provides little help in maintaining the user state (browsers being limited primarily to cookies for this purpose), the WSRP provides a much richer set of tools for maintaining state as portlets bounce around from one portal to another.”
OASIS noted that one of the key capabilities of the standard is that it allows content producers to maintain control over the
code that formats the presentation of their content. But that could be a double-edged sword, Bloomberg said.
“One challenge facing vendors who might now be looking to support WSRP, as well as their customers, is the fact that WSRP supports the interoperability of the interface, that is, how the portlets look,” he said. “It’s possible, therefore, to have a portal that contains portlets with very different visual metaphors and interaction paradigms. So, just like when the first multiple font capabilities led to dreadful amateur newsletters, it’s up to the consumers of WSRP-capable tools to ensure that their portals don’t look like a mix-and-match jumble.”
Schmelzer noted that WSRP is likely to be most applicable in environments where there are heterogeneous portal producers and consumers, and when developers can’t make any assumptions about what systems or individuals will consume the portal applications they create.
“However, we haven’t seen that many portal or other software vendors take advantage of WSRP or promote the WSRP capabilities in their product lines,” Schmelzer said. “In part, this is because WSRP must also take advantage of the security, management, and process specifications that are currently being worked on by the other standards and specification creation bodies. Our guess is that WSRP will really take off once these underlying specifications are well established and implemented.”
The WSRP specification builds on the foundational Web services standards advanced by
the World Wide Web Consortium (W3C). OASIS President and CEO Patrick Gannon
explained that it uses WSDL
requires SOAP
“WSRP 1.0 is an important step forward in expanding the reach and ubiquity
of portal technologies by providing standards that extend customer
applications to support federated portals,” said Shane Pearson, group
product manager of WebLogic Portal at BEA Systems , a
member of the WSRP Technical Committee.
Dmitri Tcherevik, vice president and director of Web services at Computer
Associates , another technical committee member, added, “By
providing a ‘plug-n-play’ standard that enables developers to capture
portal content from compliant sources and make that content available to
users in readily accessible portlets, WSRP unleashes the full potential
power of Web services.”
The standard was the effort of 25 OASIS member companies, including BEA,
BEA, Citrix, Fujitsu, IBM, Oracle, Plumtree, SAP and Vignette have been
OASIS said the standard allows remote portlet Web services to be
Citrix Systems , IBM
, Microsoft
, Novell
, Oracle
, Plumtree Software
, SAP
, Sun
Microsystems , TIBCO
and Vignette
.
“The OASIS WSRP Technical Committee was founded in early 2002 with the
vision of providing a single interface standard for all interactive,
presentation-oriented Web services,” said Rich Thompson of IBM, chair of
the WSRP Technical Committee. “WSRP v1.0 succeeds in providing this
platform neutral definition of an interface. Early vendor support for
WSRP — we’ve tracked eight implementations to date — clearly demonstrates
the need for this standardized means of accessing remote content.”
participating in interoperability testing of their implementations.
implemented in various ways, including on the Java/J2EE and Microsoft .NET
platforms.
