Sharing Data among Federated Portals: Using WebLogic Portal, Tangosol Coherence and WSRP

by Jason Howes


The Web Services for Remote Portlets (WSRP) protocol was designed to support the federation of portals hosted by arbitrary portal servers and server clusters. Developers use WSRP to aggregate content and the user interface (UI) from various portlets hosted by other remote portals. By itself, though, WSRP does not address the challenge of implementing scalable, reliable, and high-performance federated portals that create, access, and manage the lifecycle of data shared by distributed portlets. Fortunately, BEA WebLogic Portal provides an extension to the WSRP specification that—when coupled with Tangosol Coherence—allows WSRP Consumers and Producers to create, view, modify, and control concurrent access to shared, scoped data in a scalable, reliable, and highly performant manner.

An Example

To win business, banks have moved the loan application process online—including loan approval. Consider a banking application built with WebLogic Portal that includes an online loan application with automated approval processing. The application architecture calls for a clustered gateway portal application that is directly accessed by end users but that aggregates portlets deployed in separate WebLogic Portal clusters that are not directly accessible by end users. These portlets include: one that gathers basic applicant information, such as name, address, Social Security Number (SSN), and income; one that performs applicant name and SSN verification; one that performs a credit check; and one that performs a risk analysis on the completed application.

The gateway portal coordinates the loan application process by dynamically assembling content and UI from the remote portlets using WSRP. By definition, the gateway application is a WSRP Consumer, and the remote portlet applications are WSRP Producers. During the loan application process, the Producers are sometimes rendered together by the Consumer; at other times they are rendered separately. The process is initiated by the WSRP Consumer, which creates an instance of the LoanApplication class. This object is scoped to the end user's HTTP session. The various Producers subsequently will access and modify information contained in this LoanApplication object:

  • During processing, some of the Producers require read-only access to the LoanApplication object while others require exclusive write access.
  • Since the LoanApplication object is potentially very large, each Producer must be able to access it at near-memory speed.
  • While the LoanApplication object is being populated, it is important that data is not lost if any one WebLogic Portal JVM terminates prematurely.

When an approved loan application is complete, the Consumer gateway writes information from the LoanApplication object to a central database, for example, as an XML document.

Figure 1 illustrates the logical architecture of the application.

Figure 1
Figure 1. The Logical Architecture of the application (click for a full-size image)

The Problem

For the Producer applications to access shared data, it must be possible to pass information between the Consumer and Producers during each WSRP request. However, the current WSRP specification does not provide a mechanism for arbitrary data transfer via a WSRP request. Therefore, WSRP is not a suitable mechanism for passing shared data between Consumers and Producers.

Even if WSRP had provisions for exchanging data, WSRP would not be an optimal mechanism for repeatedly moving a large amount of data between a Consumer and its Producers, if for no other reason than the inefficiency of the underlying SOAP transport. SOAP is best used for transmitting a relatively small amount of textual data between two endpoints. Furthermore, serializing and deserializing the LoanApplication object to and from an XML document would be time-consuming and resource-consuming, and the resultant XML document likely would be very large in size.

The Solution

WebLogic Portal includes a WSRP Custom Data Transfer extension that allows application developers to pass data between Consumers and Producers. To enable custom data transfer, a portal developer creates a JspBacking implementation that adds any custom request state to the current HTTP request in the relevant lifecycle method, and bind the custom JspBacking implementation to the Consumer proxy portlet.

Within the Producer portlets, the portlet retrieves any necessary custom request state from the HTTP request, and adds any custom response state to the HTTP request.

Within the Consumer's custom JspBacking implementation, it is then possible to retrieve any custom response state from the HTTP request.

The Custom Data Transfer mechanism converts the custom state to text and adds it to the WSRP SOAP XML document during the WSRP request and response; therefore, it is best used for transmitting small amounts of data. In this example, however, the shared information does not necessarily have to be the LoanApplication data itself—it could be a key or "cookie" that can be used to pull the document from an external data store, such as the central database. Of course, this would require converting the object to a data store-friendly format when writing it to the data store, and then converting it back into a Java object when reading it from the data store.

A Naïve Implementation

The sequence diagram in Figure 2 shows the steps involved in a naïve approach to implementing this solution.

Figure 2
Figure 2. A naïve implementation (click for a full-size image)

Using this approach, the LoanApplication object could be shared between Consumer and Producers using the following strategy:

  1. When a new user HTTP session starts, the Consumer application creates an initial LoanApplication object and stores it in the user's session. The application also writes the object to the central database in a table that stores "in-process" loan application records keyed by the session identifier.
  2. Since this data must be scoped to the user's HTTP session, the LoanApplication object must implement the HttpSessionBindingListener interface and remove itself from the database on being unbound from the session. Alternatively, a periodic scan of the "in-process" loan application table could remove expired records from the database.
  3. During a WSRP request, the custom JspBacking implementation adds the user's HTTP session identifier to the WSRP request using the WebLogic Portal Custom Data Transfer mechanism.
  4. When a Producer needs to access the shared LoanApplication object, it can extract the HTTP session identifier from the WSRP request and retrieve the object from the central database.
  5. If a Producer needs exclusive access to the LoanApplication object, it can obtain an exclusive write lock on the object through the central database while processing the object.
  6. If the Producer modifies the LoanApplication object, it must write it back to the database and add custom response state to the WSRP response that indicates the object has been changed by the Producer.
  7. At the conclusion of the WSRP request, the Consumer checks for custom response state indicating that the LoanApplication object has been updated and, if found, replaces its version of the object with the one that is currently stored in the database and stores the updated object in the user's HTTP session.

Pages: 1, 2

Next Page »