Posts Tagged ‘MessageDriven


Anatomy of an inbound jca connector

Continuing with the posts about JCA lets now have a look on the specifics of an Inbound JCA connector. As already mentioned in a previous post the term inbound is related to the flow of the call on your application.
The endpointActivation method plays a key role in an Inbound adapter. This is the method that is triggered by the container on each of the Activation Specs you have configured on your Application Server instance. This is also the point where you start your monitoring thread (FooMonitor in our example). Remember that this monitoring object has to have access to a number of key container classes such as MessageEndpointFactory implementation and also WorkManager.
Apart from container objects you’ll certainly need to have the ActivationSpec object passed on the endpointActivation method since it carries on the configuration provided for this activation spec (taking JMS as an example it’d be host, queue, username, …).
Another point to remember is that you’ll need to have a reference to the monitor threads that were activated since on container shutdown it’ll invoke the endpointDeactivation method and you’ll need to retrieve the related monitor thread and stop its execution.

Inbound Connector classes

Too much text lets now have a look on some diagrams:
As you may have already guessed, FooMonitor is the thread that will poll for events and schedule their notifications through the WorkManager. You should never use the monitor thread for the notification since it’ll be blocked during notification denying the sending of other notifications. That’s the reason you should schedule an asynchronous notification using WorkManager.

FooNotification implementation

Skipping to the FooNotification class, its implementation will be something like the following code:

public void run() {
	MessageEndpoint endpoint = null;
	try {
		endpoint =  messageEndpointFactory.createEndpoint(null);
		((FooListener) endpoint).onMessage(msg);
	} catch (Exception ex) {
		logger.error("Error on foo notification" ,ex);
	} finally {
		if (endpoint != null)

As already mentioned, that’s the point where the MessageEndpointFactory is used. It provides us proxies for FooMDB classes. Remember to ALWAYS invoke release after using this proxy otherwise your container may run out of proxies since it’ll think you are still using them.
Another aspect not really detailed is the msg parameter on the onMessage method: this one is dependent on your ResourceAdapter – You are the one responsible for defining it (unless you have chosen a regular API like JMS).


Avoiding method timeouts in EJB Containers using Command Pattern with a JMS Queue

If you ever needed to run a complex processing in EJB that would take for example two minutes you probably have already faced the container time limitation for SessionBean methods.

This timeout (in contrast to what most think) isn’t there only to developer’s life harder. Actually, it is exactly the opposite: it is there to avoid that someone inadvertly implement a code that takes the whole server down (including your beloved application).

But there are times when long running operations are really necessary, for example a cache warmup.

MDBs are an exception

As in our project a few operations would easily violate this limitation we had to research a smart way of circumventing this limitation. During our research we found out this post on /dev/websphere blog. So we already knew that we would end up using a JMS Queue but having one Queue, MDB and so ever for each task would be a mess (not to mention that it was way too much work and not ellegant). So, that was when we came to the conclusion that what we needed was an way of having multiple tasks on top of the same infra-structure.

Command Pattern to the Rescue

We realized that by using an ObjectMessage that carried our Command object we would end up having a single queue that would handle all of our long running tasks. If there is specific context for the task processing we can have it stored in the Command Object (eg.: id of a purchase transaction that needs to be processed, or even the purchase object itself).

Sequence Diagrams for the solution

Let’s have an example, suppose we have a long running cleanup of a database that needs to be run in a timely manner. We would end up having the following flow of method calls:

JOB Submission on Working Queue

JOB Submission on Working Queue

Having the Command object implement Runnable interface is a wise idea (to avoid having another interface that is almost a Runnable clone not to mention that future JavaEE Asynch beans will probably be implemented on top of Runnable interface).

The next important part is the JOB execution, which is depicted below:

JOB execution Working MDB

JOB execution Working MDB

As mentioned on the notes, you need to be aware that the Transactional Context for the MDB MUST be Never, otherwise you’d avoid method timeouts but would still have transaction timeouts.

Another tricky part is splitting the long running task in smaller chunks that can execute under the method timeout.

As stated in the diagram, the LongRunningJOB code inside the run method is called inside the execution context of the MDB which is free from the method timeout limitation.

Signalling JOB return code

If you need to be notified that the JOB has finished its execution you’d need to have either another JOB passed as parameter to this JOB and it’ll be responsible of executing the code that would inform its return status OR have a message sent on a Temporary Queue OR the last option would be to submit a reply in another queue and have a CorrelationID link the request and the response message.


Inbound JCA Connectors Introduction

After some posts about Outbound JCA connectors, let’s have a look at the concepts related to an Inbound JCA connector.

First question I always hear: “So, the server (legacy application) connects a client socket into a server socket on my J2EE server, right?” and I always answer: “depends”. People tends to think that the term inbound and outbound are related to TCP/IP connection, but, in fact, it is related to the flow of the process. In an outbound connector, our system is the actor and if you trace the flow of the call you’ll notice that it is leaving from our system to the legacy one; or perharps we could say outgoing. On the other hand, in an inbound connector, the actor is the legacy system that is triggering an ingoing message that is started outside our system and goes all the way into it.

Let’s see a sequence diagram of an inbound connector to make things clearer:

JCA Inbound Connector Sequence Diagram

JCA Inbound Connector Sequence Diagram

As you can see in the diagram, the component that ties the Application Server, the legacy system and the J2EE Application is the ActivationSpec.

Usually, instance configurations such as port, host and other instance related data is stored on the ActivationSpec, you may also have configuration in the ResourceAdapter itself, but remember that all the configurations placed on the ResourceAdapter will be shared across multiple ActivationSpecs that may be deployed on this ResourceAdapter.

The real class responsible for handling Enterprise Events is ResourceAdapter dependant and will be initialized during endpointActivation method call on a ResourceAdapter. These classes are usually implemented as a Thread or they implement the Work interface and are submitted to the container for execution through the WorkManager instance. If you opt to use a simple Thread, remember to daemonize it otherwise your application server wont be able to properly shutdown.

For the next weeks I’ll be posting some insights about how to implement an Inbound Connector using JCA.


Blog Stats

  • 353,165 hits since aug'08

%d bloggers like this: