Remote polling in ManagedBean and notify client-view via push

jakarta-ee, jsf, timer

Solution

Based on my experience, I can recommend two routes, Spring Integration and CDI Events. I'd recommend the Spring route, but based on your current stack, I think CDI events have you covered. They cleanly help you achieve the Observer/Observable pattern and you can pull of a clean separation of tiers too. I must warn you though, this approach is effective only for a small-medium use case. Consider the following:

Design and implement an `Event` class that encapsulates all the information that is required to be delivered to consumers. Let's call it a `FundsTransfer` event Your event implementation should contain enough information to enable listeners filter only for events of interest. A simple POJO

class FundsTransfer {

    BigDecimal transferValue;
    Date transferDate;
    int transferCurrencyCode;

    public FundsTransfer(BigDecimal transferValue, Date date, int currencyCode) {
        //set accordingly
    }
    //setters and getters
}

Implement a business object at the business layer, call it `Notifier`. The function of polling should be delegated to this object. It will be in charge of creating and publishing objects of type `event` in response to changes on the server side. Depending on your requirements, this object could be a singleton to handle all `Event` types or you could have a group of `Notifier` types polling for different events.

//A sample implementation of your Observer object :
@Singleton //Defines a singleton EJB
public class PollerService {

    @Inject
    Event fundsTranferNotifier;

    //this annotation specifies that the polling method should run every second.
    @Schedule(second = "*/1", minute = "*", hour = "*", persistent = false)
    public void pollIt() {
        boolean found = this.pollingMethod(); // pollingMethod() will do the actual polling
        if (found) {     //based on the outcome of the polling method, fire the notifier  method
            blowWhistleOnTransfer();
        }
    }

    public void blowWhistleOnTransfer() {
        //this is the broadcast event.
        fundsTransferNotifier.fire(new FundsTransfer(new BigDecimal("100000", new Date(), 855));
    }
}

In the code above, I've used a `Timer` EJB as my Observer. See this for an introduction to EJB timers. Again, the `Observer` object will live in the app tier

The client tier will each have access to an listener object that will be notified when an event of interest occurs (that is has been published by a `Notifier` type). Then the listener can issue a `push` based on this event. Your listener object could be a POJO with `@Named` CDI annotation. In your listener object, simply implement a method with an `@Observes` annotation, with a parameter of the type of event the listener is interested in:

public void onNewTransfer(@Observes FundsTransfer transfer) {
    if (transfer.compareTo(new BigDecimal("150000")) > 0) {
        //push to view.
    }
}

The above filtering is still quite crude compared to the message filtering options that CDI provides. As you can see from the tutorial I referenced earlier, you could create CDI qualifiers that can give you finer grained filtering on messages. Like I stated earlier, this is a bit heavy for large scale deployment, in which case I'd advise the spring integration route, if you're up to take the dependency on.

In summary, the model of the system will be:

            One Poller(Notifier) Object (In the app layer)
                    |
                    |
                    |
            Multiple Listener Objects (In the web tier)
---------------------------------------------------
|   |    |    |    |   |   |     |   |    |    |  |  

Problem

Original source

Related problems

• Spawning threads in a JSF managed bean for scheduled tasks using a timer
• EJB dependency injection of remote service fails on Glassfish