Errai: The browser as a platform

Thursday, August 19, 2010

Enjoy the benefits of the Java EE 6 component model using GWT as an alternative view layer technology.


 

The CDI integration module offers seamless integration of CDI backend components with GWT client applications. Build as an extension to the Errai core framework, it allows you to transparently access CDI beans while harnessing the power of the core framework.

Beans that are deployed to a CDI container (i.e. JBoss 6) will automatically be registered with Errai and exposed to your GWT client application. Communication between GWT client components and CDI beans can be done in several ways:
  • RPC style invocations on beans through a typed interface
  • Access beans in a publish/subscribe manner
  • Wiring up your GWT application with the CDI event subsystem
RPC Style Invocations
When chosing RPC style invocations on beans, you basically rely on a typed java interface the CDI managed bean needs to expose. A GWT client component can then create an invocation proxy based on this interface. For more information see chapter on RPC mechanism.

Publish/Subscribe with CDI managed components
If you chose publish/subscribe then your CDI bean needs to implement the MessageCallback interface, as described in chapter 'Messaging'. Any bean exposed in this way can be accessed through the MessageBuilder API.

Integration with the CDI event subsystem
Any CDI managed component may produce and consume events. This allows beans to interact in a completely decoupled fashion. Beans consume events by registering for a particular event type and qualifier. The Errai CDI extension simply extends this concept into the client tier. A GWT client application can simply register an Observer for a particular event type and thus receive events that are produced on the server side. Likewise GWT clients can produce events that are consumed by a server side component.

Let's take a look at an example GWT component:

public class FraudClient extends LayoutPanel {

@Inject
public Event event; (1)

private HTML responsePanel;

public FraudClient() {
super(new BoxLayout(BoxLayout.Orientation.VERTICAL));

Button button = new Button("Create activity", new ClickHandler() {
public void onClick(ClickEvent clickEvent) {
event.fire(new AccountActivity());
}
});

responsePanel = new HTML();

add(button);
add(responsePanel);
}


public void processFraud(@Observes Fraud fraudEvent) { (2)
responsePanel.setText("Fraud detected: " + fraudEvent.getTimestamp());
}
}
Two things are notable in this example:
  1. Injection of an event dispatcher proxy
  2. Creation of an Oberserver method for a particular event type
Event dispatcher proxy
The event dispatcher is responsible to send events created on the client side to the server side event subsystem (CDI container). This means any event that is fired through a dispatcher will eventually be consumed by a CDI managed bean. If there is an Observer registered for it on the server side.

Client side observer methods
In order to consume events that are created on the server side you need to declare an Observer method for a particular event type. In case an event is fired on the server side this method will be invoked with an event instance of the type you declared.

To complete this exercise, let's look at the corresponding CDI managed bean as well:

@ApplicationScoped
public class AccountService {
@Inject @Any
Event event;

public void watchActivity(@Observes @Inbound AccountActivity activity) {
Fraud payload = new Fraud(System.currentTimeMillis());
event.fire(new Outbound(payload));
}
}

Whetting your appetite? Here are some links to get you going:

No comments:

Post a Comment