EJB – Architectural Patterns – Message Facade

“How can an EJB client invoke the methods of multiple session or entity beans within one transaction, without the need to block and wait for responses from each bean?”

Asynchronous Behavior – From a J2EE Development standpoint, it is a behavior of a business use case logic can be executed separately from the client itself, e.i without requiring to wait for the execution to be complete. With design consideration of this behavior, we can allow clients to still interact with the user interface with the maximum response times. This is because they don’t need to sit and wait while the use case the initiated finishes. This approach allows a large system to scale, because use cases can be queued and operated on in a batch, transparent to the user, who instantly moves on to the next part of a UI. Portions of the system that actually execute the use cases can also be scaled up and go through system upgrades if backlogs of queued use cases begin to develop, all without changing the quality or availability of service for the clients.

For EJB: We can use message-driven beans to create a fault-tolerant, asynchronous façade. Clients should have access to message-driven beans only, not to entity beans.

I’ve previously posted a basic tutorial on how to create MDBs: https://alvinjayreyes.wordpress.com/2011/07/10/creating-message-driven-beans-total-strangers-can-work/

The advantages of the Message Facade pattern includes:

  • Instant response time/asynchronous communication. When a client sends a JMS message, it is free to continue processing without waiting for the server to complete the use case and respond. A lengthy, complex use case can thus be initiated while control flow instantly returns to the user.
  • Eliminates single points of failure. Using messaging will ensure that your application continues functioning even if the EJB server or some other subsystem it relies upon is down. For example, if the database is down, the MDB’s transaction will not complete, and the reserve seatmessage will remain on the queue and be retried later. If the EJB container is down, the message will again be stored. Such fail-over capabilities would not be possible if we used a synchronous model. Of course if your JMS server is not clustered and it goes down, this still represents a single point of failure, but at least the number of potential show stoppers is reduced.

Disadvantage of the Message Façade pattern includes:

  • Message-driven beans have weakly-typed input parameters. The role of a message-driven bean is to consume JMS messages, all of which appear identical at compile time. This is in contrast to session/entity beans, which leverage Java’s built-in strong typing of the methods and parameters of the remote and local interfaces to catch common errors at compile time. Extra care must be taken by the developer to load a JMS message with the appropriate contents required by its destined MDB. One solution to this problem is to encapsulate all the data from the JMS message into a custom data transfer object, and serialize this object into the JMS Message.

  • Message-driven beans do not have any return values. Since MDB invocations are asynchronous, Message Façade cannot be used for use cases that require a return value after execution. Using Message Façade is thus superficially similar to using Session Façade, in which all session bean methods simply return void. However, it is possible to get a response from a message-driven bean back to the message creator by using JMS as the transport mechanism, please refer to the book Mastering Enterprise Java Beans, Second Edition for a discussion of this mechanism.

  • Message-driven beans do not propagate exceptions back to clients. Unlike session/entity beans, message-driven beans cannot throw application exceptions or RemoteException from any of their methods. MDBs must therefore handle all the exceptions presented in some application-specific format (that is, emailing the user if something went wrong, logging errors to an admin log, and so on).

Key notes:
  • Consider asynchronous behavior when designing J2EE Application Modules.
  • Message Driven Beans is an enterprise ready EJB Component that allow asynchronous processes.
  • Session Facade (Session Beans) can be called from a MDB – thus, regardless if you use any functional design patterns, you can still wrap it around an MDB.
  • MDBs does not propagate exceptions back to clients – MDBs are “fire and forget” methods.
  • MDBs have weekly type input parameters – you usually put all data in a serializable object, pass it through a message for the JMS to be consumed.
I’ll try to create a more complex example of Message Facade pattern using EJB MDB and post it here. 🙂

3 thoughts on “EJB – Architectural Patterns – Message Facade

  1. Pingback: JavaPins

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s