Bulk Model Retriever Pattern


J2EE patterns: Bulk Model Retriever Pattern

  1. Bulk Model Retriever Pattern (1 messages)

    Many people are considering the well-known Sun's Pet Store application as a valuable guide. I am also among them. I would not say that I like it completely, but it seems to me that there are a lot of useful things. For me one of the most valuable one from there is pseudo event-based
    communication between web and server tiers, which ends up with receiving a updated model list and following notification of registered listeners. Usually such listener represents a client view of a corresponding entity or sessison stateful ejb and perfoms update retriving a appropriate value data object from its remote colleague. But such call means one more round trip per listener and results in multiply server accesses for just one event. Moreover because a web model family reflects more or less a server business domain model family it will be more consistent to get such multiply updates in the range of just one transaction avoiding risk of incompatibilty between web objects.
    No surprise that such functionaliy can be implemented in a session stateless ejb. One also should slighly change the web tier notification mechanism so as to split it on two stages.
    During the first stage the ModelUpdateListener notifies all listeners about a change and collects from them some structure (RetrieveRequest object) what describes how to get a corresponging
    value object (or something else) from a corresponding associate ejb. Then the ModelUpdateListener submits these collected requests to a session bean and obtaints as result collection of value objects. At the second stage it iterates again through listeners giving
    each a corresponding data object.

    The actors could be described as following:

    BulkModelRetriever session stateless ejb:
    public interface BulkModelRetriever extentds EJBObject {
      // no problem to implement this method using reflection.
      // each member of retrieveRequests collection is a RetrieveRequest object.
      Collection retrieveModels(Collection retrieveRequests) RemoteException;

    Modified ModelUpdateNotifier:
    public class ModelUpdateNotifier {
        public void notifyListeners(Collection updatedModelList) {
          // iterate through registered listeners and collect requests from them.
          // get a BulkModelRetriever ejb instance and submit collected requests to it.
          // distribute resulting data object among listeners.

    Modified ModelUpdateListener:
    public interface ModelUpdateListener {
        // called by ModelUpdateListener during 1. stage
        public RetrieveRequest getRequest();
        // called by ModelUpdateListener during 2. stage
        public void performUpdate(Object dataObject);

    RetrieveRequest transport object:
    public RetrieveRequest implements Serializable {
      EJBObject associate;
      String methodName;
      Object[] methodParameters;

    Alex Sarhovsky

    P.S. Sorry for my poor English.

  2. Bulk Model Retriever Pattern[ Go to top ]

    Within the scope of a typical Http request the petstore makes two EJB container round trips. One is to deliver the event object, and another during presentation time to check for updated models. It was quite obvious to see the need to reduce the network traffic, however looking deeper into the implementation I questioned whether or not this would work across VM Processes. The listener classes that the pet store uses are regular classes, and I was unsure if the callback mechanism that they use would work if say your web tier and ejb tiers ran in separate machines.
    My solution to both problems was drastically simple. I made the ejb tier return a serializable response object that contains the actual model objects that have been modified. The web tier then updates a HashMap that takes the place of the model manager in the petstore. My HashMap uses the putAll() method to replace stale models with the newly updated ones. Typically the number of models that are affected by each event are few. Additionally the response object can provide information about the outcome of the event to the presentation tier which may eliminate any rogue ejb accesses that a developer may be inclined to make from say a jsp custom tag.