Current portal implementation follows the component model architecture that allows the plugging of components in infrastructure, which are referred to as Portlets (see Figure 3). Let's examine a case in which a company plans to build an intranet portal to provide the facility for viewing the latest stock trends, news, and weather information to its employees.

In order to implement it they have to provide presentation layers in News Portlet, Stock Portlet, and Weather Portlet, which run locally on the portal server and access remote Web services to obtain the required information (see Figure 4). Later in this article we will see the benefits and drawback of this approach and how can we use WSRP in this type of scenario.

Now we have some understanding of various terminologies related to WSRP. To understand WSRP we have to find the answers to the some of the following questions.

• What is WSRP?
• Why and where would we use WSRP?
• What is the significance of WSRP?
• How can we provide the support for WSRP?
• How can we create and use WSRP?
• What are the limitations of WSRP?

What Is WSRP?
Web Services for Remote Portlets (WSRP) was created by OASIS and it's a Web services protocol for aggregating content and interactive Web applications from remote sources and it operates over connectionless technologies. WSRP builds on a few fundamental standards, most notably XML, SOAP, and WSDL, while allowing for the implementation of evolving standards to deliver a protocol rich in the abstractions and operations that Web service implementers and portlet consumers require.

The WSRP standard defines presentation-oriented, interactive Web services with a common, well-defined interface and protocol for processing user interactions and for providing presentation conventions for publishing, finding, and binding such services. Because of these common, well-defined WSRP interfaces we can plug 'n' play any WSRP services with any WSRP-compliant portals/applications.

In a nutshell, WSRP allows enterprises to consume and publish portlets as Web services. It decouples our portlet applications from portals and instead of bundling all of our portlets with the portal in a single application, we can choose to deploy our portlets in individual portlet applications, and let the portal consume those portlets using WSRP. This results in easier team development, upgrades, administration, low development cost, and usage of shared resources.

In a typical WSRP implementation three parties are involved (see Figure 5).

1. End User - The user who is actually accessing the Portal and taking its services.
2. WSRP Consumer - This is a Web service client that invokes the WSRP Web services offered by the WSRP producer and also provides an environment for users to interact with the portlets offered by one or more such producers. A typical WSRP consumer is a portal, which mediates the markup and the interaction with this markup between end users and presentation-oriented Web services.
3. WSRP Producer - It offers one or more portlets for consumption and implements various WSRP interfaces/operations. Typically it provides a runtime (or a container) for deploying and managing several portlets. Producer implements set of WSRP-defined Web services that allow for producer and portlet description, portlet and consumer management, and portlet markup.

A WSRP consumer can also be a WSRP producer, and a WSRP producer can also be a WSRP consumer.

Why and where would you use WSRP?
Let's reconsider the company intranet portal case study that we had discussed in the portal section. That approach works well and has no problems per se apart from certain limitations such as:

• This works only if all portlets are physically installed at the company intranet portal
• The company intranet portal team is responsible for designing and developing the presentation layer for each portal
• Most important, the company intranet development team is responsible for developing those local portlets as per the guidelines and in accordance with the interface description of the respective Web service provider

These shortcomings involve significant cost and loss of time - not to mention the maintenance overhead. Now the question is what is the solution for these kinds of scenarios. What if the company portal development team somehow can include application and presentation logic instead of just content? Wouldn't that be great? So, instead of just getting raw data and/or invoking business functions that still require special rendering on the portal side, it would be great if we could use the presentation services. See Figure 6 to understand the application architecture that uses WSRP.

WSRP has answers for all of our queries. As we know the WSRP are presentation-oriented, interactive Web services, thus they allow us to include the entire application, which adheres to the WSRP specification as it is in our customized application.

In this approach generic portlet proxies that consume all WSRP services conforming to the common interface eliminate the need to develop service-specific portlets to run on the portal. In this kind of architecture we have some major benefits such as:

• It is flexible and open ended - in the future if we find some other service provider is providing better services, the process and complexity involved in migrating to a new vendor is easy and low
• The complexity is low, which results in less time required and low cost
• There is low cost and less time required for development because we don't have to build the presentation layers or write any service-specific adapters for the concerned portlets/services
• It permits the usage of existing available services from different vendors
• Its implementation requires little or no programming

There are two major usage scenarios in which WSRP can be used:

1. For publishing content. Content providers can use WSRP to surface their content as remote portlets and publish them as WSRP services in public registries. In doing so they expose their services as per the WSRP specification.
2. For publishing existing services or local Portlets. In today's world we need to emphasize the notion of "REUSE AND DON'T REINVENT," and WSRP is a good technology for integrating the existing installations. Portals (intranet/extranet) can integrate remote portlets like any local portlet and put them on their pages, and applications may embed WSRP services through a plug-in mechanism, like COM components or ActiveX controls.

Some of the business scenarios where WSRP can be effectively used are:

• Intranet portals
• Content publishers
• Value-added service providers
• Information service providers
• Billing industry
• Enterprise Integration (EAI)
• Multimedia sports portal/mobility
• Travel and CRS

• Figure 11
• Figure 12
• Figure 13