This chapter provides:
An overview of Web Services for Remote Portlets (WSRP).
A terminology list.
A scenario of how to implement portlet producers and consumers.
Considerations for WSRP and server cluster configuration.
WSRP is a web services protocol that is used to bring together content and interactive web applications from remote sources. WSRP incorporates standards such as XML, Simple Object Access Protocol (SOAP), and Web Service Description Language (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, he or she requests a WSDL document to determine the location of the service, the associated function calls, and how to access them. The administrator then uses this information in the WSDL to form a SOAP request and send it via HTTP to the external system endpoint.
Oracle provides support for:
Consuming portlets using WSRP technology.
Producing WSRP portlets through Pagelet Wizard.
Producing WSRP portlets for PeopleSoft pages and iScripts.
Implementing WS-Security for single signon with third -party portals that support WSRP and WS-Security.
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 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 applies 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, they 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 that 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. These portlets then invoke the performBlockingInteraction operation to process user interactions to the producer.
WSRP also specifies the following optional interfaces:
Registration Interface: Provides an in-band mechanism for a consumer to register with a producer. It enables the producer to customize its behavior for each consumer based on registration information. WSRP also allows out-of-band registrations and no registration.
Portlet Management Interface: Enables 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.
By implementing the WS-Security standard, Oracle enables you to leverage emerging XML security technologies to address web services security requirements. WS-Security provides:
A way for applications to construct secure SOAP message exchanges.
A general-purpose mechanism for associating security tokens with SOAP messages.
XML message integrity and confidentiality.
With 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:
Single signon solution between WSRP consumer and producer.
The web services consumer passes the appropriate identification to a producer as part of the SOAP message so that the producer can verify the identity to run requested web services on behalf of the user without requiring a user to sign in. Single signon between the web services consumer and producer is currently supported in PeopleSoft WSRP Portal, PeopleSoft Integration Broker, and the BPEL product.
SOAP message integrity. This ensures that no one has tampered with the messages.
SOAP message confidentiality. This guarantees that messages are protected against eavesdroppers.
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 and password or user authentication using user name and digital signature through the use of Web Services Security: Username Token Profile and SAML Token.
Note. Oracle provides multiple levels of security for WSRP. These levels, or options, are discussed in the following chapter. Oracle recommends that you determine the level that is appropriate for your needs before implementing WS-Security. Using SSL (Secure Sockets Layer) connections to secure transmissions may be sufficient.
See Improving Same-Server Performance Under SSL, Configuring WS-Security for WSRP Consumption and Production.
Apache Software Foundation.
A Java software module that conforms to the Portlet API.
Java Community Process: Established for the development of Java technology.
Java Specification Request: Each submission to the JCP gets assigned a unique JSR number.
The JCP specification that describes the Portlet API.
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.
Simple Object Access Protocol: An XML-based messaging protocol framework for building and exchanging distributed, structured information in a decentralized and distributed environment.
Web Service Description Language: An 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.
Web Services for Remote Portlets: A web services protocol for bringing together content and interactive web applications from remote sources.
Web Services Security Language: Supports security mechanisms, each using implementation and language-neutral XML formats, which include the use of:
The ASF WSRP reference implementation project.
Extensible Markup Language: Describes data and focuses on what data is. XML is designed to structure, store, and send information.
This scenario depicts interactions between two companies: Oracle America (a WSRP producer), and Kane Consulting (a WSRP consumer).
In this scenario, Kane Consulting is an online company providing personalized financial services to clients by subscription. Oracle America wants to host a number of financial applications, including a web-based inventory planning application. Kane Consulting wants to offer this application to its clients via its web pages.
Without WSRP, to offer the inventory planning application to clients, Oracle America and Kane Consulting must agree on the following procedure:
Oracle America 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.
A client visits Kane Consulting's web site and clicks a link to the inventory planning application.
Kane Consulting then transmits a request to Oracle America to obtain the initial view of the application. Oracle America responds by returning HTML markup that represents the first page of the application.
Kane Consulting processes the returned markup and prepares it for conversion. If the returned markup has links, Kane Consulting transforms the markup so that when the links are activated, they return to the Kane Consulting web site.
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.
The client reviews the page and finds a form to submit a new vendor ID. The client then enters the ID number and other details and submits the entry.
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 Oracle America to process the client transaction.
Oracle America processes the transaction, adds the vendor ID to the clients plan, and returns a new state for the plan.
Kane Consulting then sends a request to get the changed markup based on the current state of the plan. Oracle America generates the markup and returns it to Kane Consulting.
Kane Consulting then repeats steps 4 and 5.
The client receives a new page containing the updated plan.
Instead of developing a protocol to achieve the preceding procedure, Oracle America and Kane Consulting can use WSRP as the protocol. Oracle America 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, Oracle America and Kane Consulting use WSRP to define various interactions, with Oracle America 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, Oracle America 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 Oracle America (Step 7).
By implementing the preceding interfaces and agreeing to conform to WSRP, both Oracle America and Kane Consulting can use a standard process to offer and consume portlets. In addition, Oracle America can offer the same portlets to company X as long as company X adheres to WSRP, and Kane Consulting can consume additional portlets offered by company Y provided that company Y also implements WSRP interfaces.
Support for web server clustering with session replication is supported. However, the open source products that the application 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.