federated-portal-cache2.html

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

What's the Catch?

At first glance, this proposed solution seems to meet the requirements of the loan application. However, it has a number of drawbacks that eliminate it as an optimal solution.

The most obvious problem is that the solution makes excessive use of the central database to store what is conceptually transient data. Each WSRP request will require up to three accesses to the database: a read and a write by the Producer during the WSRP request and a read by the Consumer at the conclusion of the request. Not only does this limit the performance and scalability of the application with regard to processing loan application data, but it will also negatively affect the performance of the application as a whole, especially if the application makes substantial use of the database. This could result in poor application performance, reduced scalability, and increased cost.

In addition to excessive database access, the proposed solution requires CPU-intensive conversions between the LoanApplication object and a database-friendly format, such as XML. This consumes valuable CPU resources and may negatively affect performance. As a result, it may be necessary to purchase additional software licenses and/or hardware.

Finally, to avoid an additional read to the database at the beginning of each HTTP request, the LoanApplication object itself is written to the user's HTTP session. In a clustered environment, this will require the LoanApplication object to be serialized to a backup server at the conclusion of any HTTP request that modifies the object. This could result in excessive network traffic and additional serialization and deserialization overhead, especially if the object is quite large.

The Optimal Solution

The sequence diagram in Figure 3 illustrates a modification of the previous approach, which offers a number of significant improvements.

Figure 3. An optimal solution utilizing Coherence (click for a full-size image)

The proposed solution can be greatly improved by using a Tangosol Coherence distributed cache, rather than a central database, to store shared loan application data:

When a new user HTTP session starts, the Consumer application creates an initial LoanApplication object and stores it in a clustered Coherence NamedCache keyed by session identifier.
```
LoanApplication application = new LoanApplication();
NamedCache cache = CacheFactory.getCache("loan-application");

cache.put(session.getId(), application);
```
Since this data must be scoped to the user's HTTP session, the application creates a class that implements the HttpSessionBindingListener interface. Upon being unbound from the session, this object removes the corresponding LoanApplication object from the NamedCache in which it is stored. Note that the object stored in the session is not the LoanApplication object itself but an object that serves as a representative (or handle) of the LoanApplication. As such, this object can be very small and efficiently serialized and deserialized:
```
public class LoanApplicationHandle
        implements HttpSessionBindingListener, Serializable
    {
    public void valueBound(HttpSessionBindingEvent event)
        {
        }

    public void valueUnbound(HttpSessionBindingEvent event)
        {
        String sId = event.getSession().getId();
        CacheFactory.getCache("loan-application").remove(sId);
        }        
    }
```

The Consumer then adds an instance of the LoanApplicationHandle class to the HTTP session:

session.setAttribute("loan-application-handle", 
                        new LoanApplicationHandle());

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. This information is also very small and is efficiently transmitted by the underlying SOAP transport:

public boolean preRender(HttpServletRequest req, 
                                       HttpServletResponse res)
    {
    HttpSession       session = req.getSession(true);
    SimpleStateHolder state   = new SimpleStateHolder();

    state.addParameter("session-id", session.getId());
    req.setAttribute(MarkupRequestState.KEY, state);

    return super.preRender(req, res);
    }

When a Producer needs to access the shared LoanApplication object, it can extract the HTTP session identifier from the WSRP request and use it to retrieve the LoanApplication directly from the NamedCache:

SimpleStateHolder state = (SimpleStateHolder)
                        req.getAttribute(MarkupRequestState.KEY);

String sId = (String) state.getParameter("session-id");
NamedCache cache = CacheFactory.getCache("loan-application");
LoanApplication application = (LoanApplication) cache.get(sId);

When a Consumer needs to access the shared LoanApplication object, it can use the HTTP session identifier to retrieve the LoanApplication directly from the NamedCache:
```
String sId = session.getId();
NamedCache cache = CacheFactory.getCache("loan-application");
LoanApplication application = (LoanApplication) cache.get(sId);
```

If a Producer or a Consumer needs exclusive access to the LoanApplication object, it can obtain a cluster-wide lock on the object through one of the lock() methods on the NamedCache in which it is stored:

NamedCache cache = CacheFactory.getCache("loan-application");

cache.lock(sId, -1);
try
  {
   LoanApplication application = (LoanApplication) cache.get(sId);

   // Perform logic that requires exclusive access to the
   // LoanApplication
   }
finally
   {
   cache.unlock(sId);
   }

Download

This example demonstrates how to combine BEA WebLogic Portal's Custom Data Transfer WSRP extension with Tangosol Coherence to create, view, modify, and control concurrent access to shared, scoped data from WSRP Consumers and Producers. The package includes source code, configuration files, and a pre-built library. You can find installation instructions in the README.txt file at the root of the archive file.

Download the example (68Kb): coherence-wsrp.zip

Conclusion

BEA's extension to the WSRP specification allows applications to introduce additional state to WSRP requests and responses. This, coupled with a shared data store, enables data to be federated along with user interface and content. Using Coherence as a shared data store gives applications scalable, reliable, and highly performant access to federated data. In the example in this article, the addition of Coherence completely eliminates all access to the central database for shared loan application data. Furthermore, the application no longer needs to be burdened with converting the LoanApplication object to and from an intermediate format before storing it in the Coherence NamedCache. In addition, the potentially expensive HTTP replication of LoanApplication objects is completely avoided. Finally, this solution eliminates a number of error-prone tasks, such as guaranteeing exclusive access to a loan application in the database and cleaning up any orphaned loan applications from the database.