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.
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
LoanApplicationobject while others require exclusive write access.
LoanApplicationobject is potentially very large, each Producer must be able to access it at near-memory speed.
LoanApplicationobject 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.
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.
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
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.
The sequence diagram in Figure 2 shows the steps involved in a naïve approach to implementing this solution.
Using this approach, the
LoanApplication object could be shared between Consumer and Producers using the following strategy:
LoanApplicationobject 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.
LoanApplicationobject must implement the
HttpSessionBindingListenerinterface 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.
JspBackingimplementation adds the user's HTTP session identifier to the WSRP request using the WebLogic Portal Custom Data Transfer mechanism.
LoanApplicationobject, it can extract the HTTP session identifier from the WSRP request and retrieve the object from the central database.
LoanApplicationobject, it can obtain an exclusive write lock on the object through the central database while processing the object.
LoanApplicationobject, 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.
LoanApplicationobject 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