Skip navigation.

eDocs Home > BEA WebLogic Portal 8.1 Documentation > Using WSRP with WebLogic Portal > Introduction to WSRP

Using WSRP with WebLogic Portal

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Introduction to WSRP

Web Services for Remote Portlets (WSRP) is a web services standard that allows you to "plug-n-play" visual, user-facing web services with portals or other intermediary web applications. It allows you to create a repository of services that users can reference to surface applications in their portlets or to consume applications from WSRP-compliant Producers, even those far removed from your enterprise.

BEA WebLogic Portal 8.1 SP3 includes an implementation of WSRP that allows the framework to use WSRP portlets.

This section includes information on the following subjects:

 

The WSRP Standard

BEA's implementation of WSRP is based upon the WSRP 1.0 standard created by OASIS. BEA Systems has been an active member of the OASIS technical group for WSRP 1.0 and continues to work as part of this standard effort for future enhancements to the specification.

You can read the current version on the WSRP standard at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp

 

WSRP Portlet Type Support

You can create WSRP-enabled portlets for these portlet types:

You can also use JSP portlets provided you start by creating a Java Page Flow (JPF) and pointing the Begin action to a JSP.

This version of WebLogic Portal supports only homogeneous portlets, therefore, the portlet modes must be compatible with the portlet; for example:

 

Why Use WSRP?

WSRP is an attractive option for web development for three main reasons:

WSRP Decouples the Deployment and Delivery of Applications

You can surface new applications on your portal, independent of release schedule and where and when the code is physically deployed.

For example, perhaps you have a portal on machine X and another on machine Y. To get a portlet from machine X to machine Y, currently your only method of doing so is to copy the portlet's code, JSPs, and so on, from machine X to the destination machine (Y). By using WSRP, you can access and display that portlet on machine Y simply by referencing it through the Producer's Web Service Description Language identifier (WSDL).

WSRP Delivers both Data and its Presentation Logic

As a "user-facing" web service, WSRP portlets provide both application and presentation logic. This is different from standard web services, or data-oriented web services, which contain business logic but lack presentation logic and thus require that every client implement that logic on its own.

While the data-oriented approach works well in many implementations, it is not well suited for dynamically integrating business applications. For example, to integrate an order status web service into a commerce portal, you would need to write code to display the results of the status services into the portal. Using WSRP, with the presentation logic included in the web service, you can achieve the aggregation of applications and services dynamically. You no longer need to develop the presentation logic in order to do the integration; you can simply request the order status service to show up as a portlet inside the commerce portal at a predetermined location.

BEA's Implementation of WSRP Requires Little or No Programming

You don't have to do a lot of programming to make a portlet remote. In a non-WSRP compliant implementation, integrating remote content and application logic into an end-user presentation usually requires a significant custom programming effort. Typically, vendors of aggregating applications, such as a portal, write special adapters for applications and content providers to accommodate the variety of different interfaces and protocols those providers use.

WebLogic Workshop 8.1 SP3 provides tools that allow you to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks—without writing a line of code. Additionally, applications created with WebLogic Workshop 8.1 SP3 are, by default, WSRP-compliant, which means they can be leveraged into other user's portlets with little or no additional programming required on your part.

Other Benefits of WSRP

In addition to those listed above, WSRP provides these additional benefits to developers:

 

Producers and Consumers

WSRP introduces the concepts of Producers and Consumers. By using WSRP, you can aggregate application functionality by integrating WSRP-compliant Producers into WebLogic Portal as a Consumer. Your end users thus will be able to interface with Consumers to view the integrated applications.

Figure 1-1 Web Services Between Producer and Consumer

Web Services Between Producer and Consumer


 

Producers

Producers host portlets and provide such services as self-description, mark up, registration, and portlet management. Producers can optionally manage the registration of Consumers and require them to pre-register prior to interacting with portlets. A registration establishes a relationship between Consumers and Producers.

Producers are further classified into either simple or complex Producers.

Simple Producers

A simple Producer is a non-portal web application that contains pageflows and Struts applications. It does not depend upon any portal features (for example, customization), nor does it require registration, support URL rewriting in the Consumer, or support a management interface.

With simple Producers:

You can create a simple Producer from a complex Producer so that pageflows and Struts applications available as "portlets" to remote portals. This procedure is described in Creating a Simple Producer from a Complex Producer.

Complex Producers

A complex Producer requires registration, does support URL rewriting in the Consumer, and does support a management interface. By default, all portlets created with WebLogic Workshop 8.1 SP3 are complex Producers.

With complex Producers:

Consumers

Consumers aggregate information from Producers and surface it in other portals. Consumers route requests from users to the appropriate Producer, which, in turn processes the request and sends results back to the Consumer. The Consumer aggregates the results coming from various Producers and send the final result back to the user. Consumers provide separation of the traffic flowing between them and the Producers. They also ensure that all interactions are kept private to that specific user during the sessions.

 

WSRP and WebLogic Portal

In addition to complying with the OASIS WSRP standard, BEA's WSRP implementation adds some additional features to provide you with greater control over remote portlet usage. These features are described in Table 1-1:

Table 1-1 Features in BEA's WSRP Implementation

Feature

Description

Portlet Wizard

Remote portlets can be easily implemented by using the Portlet Wizard that comes with WebLogic Workshop. You can create and install robust remote portlets with a few simple mouse-clicks and a Producer's Web Service Description Language identifier (WSDL).

Administration Portal

The WebLogic Portal Administration Portal allows you to easily deploy and manage Producer and Consumer portlets for your enterprise from a central location.

Producer-by-Default

All web projects created with WebLogic Workshop are, by default, Producers. You don't need to do any special coding or add additional content to a project to make it available as a Producer.

Registration

Consumers might be required to register with a Producers. Registration allows Producers to identify each Consumer with a unique, Consumer-provided handle. This helps identify what portlets are available to that Consumer.

Service Description

The service description shows what a Producer has to offer. It lets a Consumer discover a Producer and it lists the capabilities and properties that are available from the Producer. As a portlet repository, the service description also lists the portlets available from that Producer.

Markup and User Interaction

Request time operations to initiate or terminate a session. It gets markup for a portlet, which is returned in the body of the message. It submits user interaction request for a portlet.

Portlet Management

The Producer may allow cloning, customization, and deleting of portlets. Customization features allow portal administrators to manage portlet preferences for remote portlets.

 

How WSRP Works

Figure 1-2 illustrates the WSRP process, including handoffs from end user to Consumer to Producer and back.

Figure 1-2 WSRP Process Flow

WSRP Process Flow


 

 

WSRP-compliant Portlet Lifecycle

The portlet lifecycle for a WSRP-compliant portlet includes both development time and deployment time capabilities.

Development Time

Producer side (complex Producer) Developers will be able to leverage Java Page Flows, JSR 168, and Struts applications to expose their functionality in remote portlets. They can portletize the application and configure any related properties. Since all projects created with this version WebLogic Workshop 8.1 SP3 are, by default, Producers, developers don't need to be aware of WSRP.

Consumer side Developers declare the Producers that are available to be used in the application. By using the Portlet Wizard in WebLogic Workshop, they can create a remote portlet based on the service description file from the Producer. They will need to:

  1. Select "Remote" from a list of portlet types.
  2. Configure a few options.
  3. Create a new portlet.
  4. Drag and drop the WSRP-based portlet to the portal.

See Building a Remote Portlet in the WebLogic Workshop online help system for a detailed description of this process.

Deployment Time

Producer side For applications not built with this version of WebLogic Portal, some changes are required:

New applications, after WSRP installation, are automatically configured.

Consumer side The experience would be similar to the current Administration Portal today since remote portlets look like local portlets.

 

Building a Simple Remote Portlet

To see how easily you can build a remote Consumer portlet, please see Building a Remote Portlet in the WebLogic Workshop online help system, at:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportlets/conWsrpConsumer.html

This exercise will show you how to use the Portlet Wizard to create a remote portlet and populate it with an application from a Producer. It will also show you how to add the portlet to a portal and view the portal and the new remote portlet in a browser.

Working with a Remote Portlet

In addition to Building a Remote Portlet, described above, the WebLogic Workshop online help system contains other vital information for developing and using WSRP-compliant portlets. These topics include:

Modifying a Remote Portlet, at:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportlets/portletModProxy.html

This topic describes how to add states and modes to a remote portlet,

Customizing a Remote Portlet, at: 

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportlets/portletConsumerCust.html

This topic tells you where to find complete information about and procedures for changing the appearance of a remote portlet.

Disabling A Producer, at:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportlets/portletDisableProd.html

This topic describes how to modify the Producer configuration file so that Producer application cannot be consumed by a remote portlet.

 

Note on Localization of Remote Portlets

In service pack 3 of WebLogic Portal 8.1, you cannot localize remote portlets. This feature will be available in a subsequent release of the product.

 

Skip navigation bar  Back to Top Previous Next