Enterprise Java

Java EE Revisits Design Patterns: Observer

Aside from being implemented in many languages and many applications, Observer Pattern has been a part of Java since version 1.0. Observer Pattern is also a good implementation of Hollywood Principle. Just like Agents in Hollywood like to callback the candidates for a role instead of being called daily to be asked about available jobs, most of the server side resources like the push the available data to the appropriate client instead of being asked for updates on a time interval.

Such time interval queries can be both consuming to much resource on the server and also cause more network traffic than actually needed. Although Java had support for Observer Pattern since day 0, it is always argued to be not the best implementation (Have a look at Observer and Observable). Being on JavaEE world may even complicate things. However JavaEE6 comes with an alternative.

JavaEE6 offers ‘@Observable’ annotation as an easy out of box implementation of Observer Pattern. Lets visit the previous post and extend it to use observers.

package com.devchronicles.observer;


import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.enterprise.event.Event;
import javax.inject.Inject;


/**
 *
 * @author Murat Yener
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    @Inject
    private String message;
    
    @Inject 
    Event<String> event;
    
    public void startService(){
        System.out.println("start service call "+message);
        event.fire("this is my "+message);
        System.out.println("done...");
    }
}

The EventService class will be injected an Event object of type String which can be used to fire String objects. If you had not read the previous post, message object is a String which will be produced by a factory and injected to the EventService class. To make it simpler you can just type any string constant to the variable called message.

Since we are already done with the observable part, now it is time to create an observer to listen our events.

package com.devchronicles.observer;


import javax.ejb.Stateless;
import javax.enterprise.event.Observes;


/**
 *
 * @author Murat Yener
 */
@Stateless
public class EventObserver {


    public void doLogging(@Observes String message){
        System.out.println("Observed:"+message);
    }
}

The Observes annotation marks the method as an observer for fired String events. If you run the server and fire up start service method, you will realize how magically a string will be injected to EventService class and than fired where it will be caughed (observed) by EventObserver class. Surprisingly that is all you need to implement the observer pattern in JavaEE6.

As seen before, JavaEE6 offers an easy way to implement the Observer Pattern. After publishing the post, I had receive few questions on how to differentiate string types that are fired and observed.

Although in real world scenarios you wouldn’t probably firing and observing plain strings but your own objects which would be observed by their type, still it is pretty easy to differentiate same type of objects and setup different observers to listen them.

First lets start with the part to differentiate plain strings.

package com.devchronicles.observer;


import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.inject.Qualifier;


/**
 *
 * @author Murat Yener
 */
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD,ElementType.PARAMETER})
public @interface MyEvent {
    
    Type value();
    
    enum Type{
        LOGGING, MESSAGE
    } 
}

The interface above will act as annotation to mark the string to be fired and later to be observed just by annotating the appropriate parts.

package com.devchronicles.observer;


import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.enterprise.event.Event;
import javax.inject.Inject;


/**
 *
 * @author Murat Yener
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    @Inject
    private String message;
    
    @Inject @MyEvent(MyEvent.Type.LOGGING)
    Event<String> event;


    @Inject @MyEvent(MyEvent.Type.MESSAGE)
    Event<String> anotherEvent;
    
    public void startService(){
        System.out.println("start service call "+message);
        event.fire("this is my "+message);
        System.out.println("done...");
        anotherEvent.fire("done with the service!");
    }
}

We just add MyEvent annotation with the desired type and later fire the events as we did before. The parts marked with red is all we added to the example in the previous post.

Now lets annotate the observer part. Again We will be just adding the red parts to the previous example.

package com.devchronicles.observer;

import javax.ejb.Stateless;
import javax.enterprise.event.Observes;

/**
 *
 * @author Murat Yener
 */
@Stateless
public class EventObserver {

    public void doLogging(@Observes @MyEvent(MyEvent.Type.LOGGING) String message){
        System.out.println("Observed:"+message);
    }



    public void doLogging(@Observes @MyEvent(MyEvent.Type.MESSAGE) String message){
        System.out.println("Observed another type of message:"+message);
    }
}

That would be all you would need to differentiate even the same type of objects to observe.

Reference: JavaEE Revisits Design Patterns: Observer , JavaEE Revisits Design Patterns: Observer Part 2 from our JCG partner Murat Yener at the Developer Chronicles blog.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Noah White
Noah White
12 years ago

You show one EJB which is the Event producer and another  EJB which is the Event consumer. Normally if the producer startService method called the consumer’s doLogging method directly the Transaction context would automatically propagate. Do TX contexts propagate when the consumer class’s method is called as the result of the Observable event or is that method in its own separate TX context and the original one is closed when the producer method exits? I am guessing they are not. Are observers called asynchronously? If so would it not be possible that the Observer code is called before the producer… Read more »

Back to top button