TechFundu

Problem Statement

Achieving cross-platform interoperability and being able to leverage existing webservices infrastructure within an already existing Enterprise Portal Infrastructure to reduce cost and improve time to market and development efficiency would be worth considering while designing/development of an Enterprise Portal.

Solution

Web Services for Remote Portlets (WSRP) addresses the issue of location transparency for portlets. WSRP leverages webservices infrastructure for accessing the portlets hosted in remote containers. Location transparency is not new to the computing world. Several technologies were invented to do this, starting with RPC remote procedure calls. During component Object oriented paradigm revolution, DCOM, RMI, CORBA and EJB were invented to address this.

One unique facet of the specification is that it is a presentation-oriented Web service. Most Web services are expected to just carry raw data as the result of a request, and the caller is responsible for determining how it is used. While in an abstract sense this is also true of WSRP, it is different in the sense that WSRP generally carries fully rendered markup that is to be included within a portal page, with very few changes to be made by the consumer.

Introduction

Enterprise portals are today’s most popular interface for employees connecting to business and collaboration tools and each other. Through the integration of application servers, business intelligence, communications tools and content management, these portals have become the focal point for enterprise productivity.

The first generation of portals simply offers a convenient method of navigating to sites of common interest for the portal's user population, functioning as a switchboard to connect individual clients to a community of services.

In the second generation of portals, what was once static becomes largely dynamic. The portal's data channels are no longer passive carriers for an influx of data. Instead, they become interfaces to programs performing active functions on behalf of the user. A content channel in a portal can be thought of as an active content generator, driven by user or external events. Designing applications for this content-oriented delivery mechanism redistributes the processing load in a way that allows data to be delivered in highly specific, value-added ways to the end user.

Portal has evolved as a user-centric application integration platform. It has become a strategy rather than solution implementation. Federated Portals enable a fabric of distributed enterprise portal services that can simply be combined to enable IT to increase efficiency and allow business to respond quickly.

WSRP is the outcome of joint efforts of two Oasis (www.oasis-open.org, a non-profit ebusiness standards organization) technical committees, WSIA – Webservices for Interactive Applications and WSRP itself. WSRP 2.0 has been approved as standard in April 2008.

The WSRP specification defines a web service interface for accessing and interacting with interactive presentation-oriented web services.

We can develop WSRP producer portlets either in Java or .NET. Render them in a web portal application using a thin layer of portal specific code (for instance a JSR168 or Web part). This is SOA-friendly architecture, easy to deploy and modify, that also scales well.

WSRP defines a set of APIs that allows applications to utilize remote interactive Web services in the form of portlets. These APIs are built on top of the existing SOAP, WSDL, and UDDI Web services technologies.

The WSRP specification describes the conversation between producers and consumers on behalf of the users. These producers are the presentation-oriented Web services that host portlets, rendering the markup and processing user interactions. The consumers are the applications that integrate these Web services, presenting markup to users and managing user interaction.

WSRP provides a set of standard operations that enable a consumer to request valid markup fragments (such as HTML) from a producer based on an existing state. Users can then interact with the markup, while the state is preserved across these calls.

WSRP Specification

Portlet APIs may be defined for different programming languages; WSRP can bridge between the different platforms, leveraging platform independence of Web services.

The WSRP specification defines a web service interface for accessing and interacting with interactive presentation-oriented web services. It has been produced through the efforts of the Web Services for Remote Portlets (WSRP) OASIS Technical Committee. It is based on the requirements gathered and on the concrete proposals made to the committee.

Scenarios that motivate WSRP functionality include:

Content hosts, such as portal servers, providing Portlets as presentation-oriented web services that can be used by aggregation engines.
Aggregating frameworks, including portal servers, consuming presentation-oriented web services offered by content providers and integrating them into the framework.

This specification accounts for the fact that Producers (web services conforming to this specification) and Consumers (applications consuming Producers in a manner conforming to this specification) may be implemented on very different platforms, be it as a [J2EE] based web service, a web service implemented on Microsoft's [.Net] platform or a Portlet published directly by a portal. Special attention has been taken to ensure this platform independence. At the same time, attention has also been paid to ensure a reasonable mapping to technologies for producing markup fragments (e.g. webparts, JSR 168 portlets, etc). These web services are built on standard technologies, including [SSL/TLS], [URI/URL], [WSDL] and [SOAP], and expects to leverage future applicable Web Service standards, such as WS-Policy in future versions.

The WSRP-specification says nothing about the implementation of the portlet, it defines its interface. This is where WSRP connects to Java's portlet specification, JSR 168, and Microsoft’s Web parts. WSRP is not a competing technology, it’s more like complementary. JSR 168/Web parts are used to define the portlet whereas WSRP is used to define the portlets appearance in a remote portlet container (like a web portal app).

WSRP defines a producer-consumer-client architecture for getting applications to user desktop. Client refers to the browser that acts as a user desktop. Consumer refers a portal server or aggregation engine that aggregates from several producers to form the user desktop. Producer can be application interfaces (other portals serving portlets or stand-alone applications) that produce markups. WSRP defines producer constructs for service producers; consumption constructs for consumers and a protocol for consumer-producer communication.

Conclusion

Locally-running code is usually faster than a remotely-called Web service. Deploying locally-running code to all servers in a farm can be annoying, but if you’re load-balancing that middle tier, it’s the same amount of work. WSRP Portlets are very demanding on bandwidth. WSRP specification does not address authentication. WSRP Portlets need to have their own custom authentication system.

The advantages of WSRP are obvious, it can easily be used in any portal application without local installation and hence achieve interoperability of portlets across different portal platforms. It all comes down to developer productivity, ease of deployment, ease of maintenance, ease of reuse, etc. Developers and other IT organizations should investigate the use of WSRP when integrating their various service offerings into the enterprise portal.

References