Understanding Web Services For Remote Portlets (WSRP)

This chapter provides an overview of Web Services for Remote Portlets (WSRP), a terminology list, and a scenario of how to implement portlet producers and consumers.

Click to jump to parent topicUnderstanding WSRP

WSRP is a web services protocol, which is used to bring together content and interactive web applications from remote sources. WSRP incorporates standards such as XML, SOAP, and WSDL to serve as a foundation, while allowing for the implementation of evolving standards.

A WSDL document is an XML file that contains information about the interface, semantics and other details of a call to a web service. When someone wants to use a service, they request a WSDL document to find out the location of the service, the associated function calls and how to access them. They then use this information in the WSDL to form a Simple Object Access Protocol (SOAP) request and send it via HTTP to the external system endpoint.

PeopleSoft provides support for:

The terms Producer and Consumer are used to describe parties implementing the WSRP protocol.

Producer: A web service that offers one or more portlets and implements various WSRP interfaces. A producer may offer just one portlet, or may provide a container for deploying and managing several portlets.

Consumer: A web service client that invokes producer-offered WSRP web services and provides an environment for users to interact with portlets offered by one or more producers.

Most PeopleSoft pages, portlets, and iScripts are WSRP-compliant and available for consumption in WSRP-compliant portals; this refers to existing definitions and newly created definitions. While these PeopleSoft items, by default, are available for WSRP consumption, an administrator controls which items are actually produced, or exposed, for WSRP consumption.

This functionality enables you to incorporate PeopleSoft application pages, pagelets, and iScripts into a portal of your choice. When users in the non-PeopleSoft portal interact with the WSRP portlet, depending on how the portlet is configured, users can interact directly within the portlet or they can be transferred to the PeopleSoft portal where the portlet originated.

To enable components for WSRP production, you select the WSRP Compliant option on the Internet tab of the Component Properties dialog box.

See Setting Internet Properties.

WSRP Interfaces and Operations

A producer must implement the following WSRP interfaces:

Service Description Interface: Provides metadata of itself and the list of portlets it offers. The Consumer invokes the getServiceDescription operation of this interface to obtain the metadata.

Markup Interface: Generates markup and processes interaction requests. The Consumer invokes the getMarkup operation of this interface to obtain the portlets markup. They then invoke the performBlockingInteraction operation to process users interactions to the Producer.

WSRP also specifies the following optional interfaces:

Registration Interface: Registration interface provides an in-band mechanism for a Consumer to register with a Producer. It lets the Producer customize its behavior for each Consumer based on registration information. WSRP also allows out-of-band registrations and no registration.

Portlet Management Interface: Allows Consumers to clone or destroy portlets, as well as customize portlets by changing any associated properties.

Note. The registration interface and portlet management interfaces are not used by the PeopleSoft producer. Consumers are therefore not required to register with the PeopleSoft producer.

WS-Security

By implementing the WS-Security standard, PeopleSoft provides the ability to leverage emerging XML security technologies to address web services security requirements. WS-Security provides:

By providing WS-Security capabilities, you can leverage the standard set of SOAP extensions, that you use when building secure web services, to implement message content integrity and confidentiality. WS-Security provides a way to insert and convey security tokens in SOAP messages. The ability to leverage WS-Security standards provides for better interoperability and improved usability, enabling the implementation of robust security within a WSRP-capable environment. The solutions being provided through the PeopleSoft WS-Security implementation include:

WS-Security UsernameToken Profile defines a standard way to associate user ID and password information in the SOAP messaging for web services interoperability.

The Security Assertion Markup Language (SAML) Token defines assertions, protocols, bindings, and profiles.

The PeopleSoft portal solution provides support for WS-Security for single-signon with third party applications—limited to user authentication using user name/password or user authentication using user name and digital signature through the use of Web Services Security: Username Token Profile and SAML Token.

Note. PeopleSoft provides multiple levels of security for WSRP. These levels, or options, are discussed in the following chapter. PeopleSoft recommends that you determine the level that is appropriate for your needs before implementing WS-Security. Using SSL connections to secure transmissions may be sufficient.

See Improving Same-Server Performance Under SSL, Configuring WS-Security For WSRP Consumption and Production.

Click to jump to parent topicTerminology

ASF

Apache Software Foundation.

Java Portlet

A java software module that conforms to the Portlet API.

JCP

Java Community Process: Established for the development of java technology.

JSR

Java Specification Request: Each submission to the JCP gets assigned a unique JSR number.

JSR 168

The JCP specification that describes the Portlet API.

SAML

Security Assertion Markup Language: An XML standard for exchanging authentication and authorization data between entities.

SAML provides a standard security token—a SAML assertion—that can be used with standard web services security frameworks.

See http://www.oasis-open.org/glossary/index.php

SOAP

Simple Object Access Protocol: An XML-based messaging protocol framework for building and exchanging distributed, structured information in a decentralized and distributed environment.

WSDL

Web Service Description Language: A XML language for describing web services; it defines the core language that can be used to describe web services based on what the services offer.

WSRP

Web Services for Remote Portlets: A web services protocol for bringing together content and interactive web applications from remote sources.

WSS

Web Services Security Language: Supports security mechanisms, each using implementation and language-neutral XML formats. They include the use of:

  • XML signature to provide SOAP message integrity.

  • Use of XML encryption to provide SOAP message confidentiality.

  • Attaching and referencing security tokens and associating signatures with security tokens.

WSRP4J

The ASF WSRP reference implementation project.

XML

Extensible Markup Language: Describes data and focuses on what data is. XML is designed to structure, store, and send information.

Click to jump to parent topicImplementing WSRP Protocol Scenario

This scenario discusses interactions between two companies; PeopleSoft, Inc. (a WSRP producer), and Kane Consulting (a WSRP Consumer).

In this example, Kane Consulting is an online company, providing personalized financial services to clients by subscription. PeopleSoft, Inc. would like to host a number of financial applications, including a web based inventory planning application. Kane Consulting would like to offer this application to its clients via its web pages.

Without WSRP, in order to offer the inventory planning application to clients, PeopleSoft, Inc. and Kane Consulting must agree on the following procedure:

  1. PeopleSoft, Inc. makes the metadata of the inventory planning application available to Kane Consulting. Kane Consulting uses this metadata to create a page that clients can use to manage their plans.

  2. A client visits Kane Consulting's web site and clicks on a link to the inventory planning application.

  3. Kane Consulting then transmits a request to PeopleSoft, Inc. to obtain the initial view of the application. PeopleSoft Inc. responds by returning HTML markup that represents the first page of the application.

  4. Kane Consulting processes the returned markup and prepares it for conversion. If the returned markup has links, Kane Consulting transforms the markup such that when they are activated they return to the Kane Consulting web site.

  5. Kane Consulting converts the markup into a web page, writes it into the response of the browser's connection, and transmits the page to the client's browser.

  6. The client reviews the page, and finds a form to submit a new vendor ID. The client then fills in the ID number and other details and submits the entry.

  7. Kane Consulting receives the request containing the new data. Upon determining that the request is for the inventory planning application, Kane Consulting transmits another request to PeopleSoft, Inc. to process the client transaction.

  8. PeopleSoft, Inc. processes the transaction, adds the vendor ID to the clients plan and returns a new state for the plan.

  9. Kane Consulting then sends a request to get the changed markup based on the current state of the plan. PeopleSoft Inc. generates the markup and returns.

  10. Kane Consulting then repeats steps 4 and 5.

  11. The client receives a new page containing the updated plan.

Instead of developing a protocol to achieve the above preceding procedure, PeopleSoft Inc. and Kane Consulting can use WSRP as the protocol. PeopleSoft Inc. is a WSRP Producer offering portlets, and Kane Consulting is a WSRP Consumer consuming portlets and aggregating portlets for clients to access aggregated portlet pages. The inventory planning application is a portlet offered by the WSRP Producer.

To implement the preceding procedure PeopleSoft Inc. and Kane Consulting uses WSRP to define various interactions, with PeopleSoft Inc. implementing the following required WSRP interfaces and operations.

Service Description Interface: Provides metadata of itself and the list of portlets it offers. Kane Consulting invokes the getServiceDescription operation of this interface to obtain this metadata. (Step 1 of the procedure).

Markup Interface: To generate markup and to process requests, PeopleSoft Inc. implements the markup interface specified by WSRP. Kane Consulting, invokes the getMarkup operation to obtain the portlet's markup (steps 3 and 9), and invokes performBlockingInteraction to generate the client's interactions to PeopleSoft Inc. (Step 7).

By implementing the preceding interfaces, and agreeing to conform to WSRP, both PeopleSoft Inc. and Kane Consulting can use a standard process to offer and consume portlets. In addition PeopleSoft Inc. can offer the same portlets to company X as long as X adheres to WSRP, and Kane Consulting can consume additional portlets offered by company Y provided Y also implements WSRP interfaces.

Click to jump to parent topicWSRP and Server Cluster Configuration Considerations

Support for web server clustering with session replication is supported. However, the open source products Enterprise PeopleSoft uses for WSRP functionality, Apache Pluto and WSRP4J, do not support serialization. If you intend to implement web server clustering with session replication and WSRP functionality, you must set up two separate web server environments. The web server environment servicing WSRP functionality cannot have session replication enabled.