Posts Tagged ‘EJB


Mapping JavaEE and .NET stack components

Recently I started to research how to develop on .NET as I’ve been developing for JavaEE.
First thing that came to my mind as a JavaEE architect was: “Okay, IIS and ASP.NET are some of the presentation tier alternative I have for .NET but what for business tier?” or rephrasing as someone that has
been using JavaEE for a long time: “What would be the .NET EJB?”.
JavaEE-DotNETComparisonFirst thing I missed was the concept of the MDB that in .NET stack that seems to be replaced by an MSMQ message trigger.

Another major .NET difference is that even though it seems to have the concept of the VM process (as Java does) it has the concept of a shared library, or the Global Assembly Cache. If you think in terms of Java then you have to either manually replicate the jar or share them using a shared storage and having it on the classpath.

As we are on the classpath subject, .NET and its CLR seems to avoid (and limit it to J#) the concept of a ClassLoader. Although sometimes problematic, the Java concept of the ClassLoader allows very sofisticate scenarios of application composition and also for hot code generation (by the application) at runtime.

I hope this post has helped anyone in the situation as I were before and I also hope it does not sound as a comparison of which platform is better as you might guess that I sincerely know that each one has its applications, strengths and weaknesses.


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.


Java Connector Architecture (JCA)

Long time since my last post but job was demanding way too much time from me. Anyways today I’ll start a series of posts about the Java Connector Architecture. Chances are that you have already used a JCA Connector but never needed to write one by yourself. But, why would someone need to write one? Picky question but the JavaEE specification is very clear, you can’t open ServerSockets, Threads, to name a few.

But why would I need a Thread inside an EJB container if it is already built around a Threaded model? Answer is, you need it everytime your component has a sofisticate interaction with an external system for example. To make things clearer let me use the scenario I faced weeks ago.

Communication with Legacy application using Sockets

One of the requisites of the application I am working on is to communicate with a legacy application written in C. If the communication was always started by my application and I didn’t needed a Pooling model I could stick easily with a ClientSocket inside my EJB (since specification only mandates that ServerSockets and Threads are denied inside an EJB), but, since the legacy application sometimes sends a “ping” request and I needed pooling for low latency I had to create my own JCA connector.

First Steps

For those who are starting I’d suggest a few tutorials around the net:

Introduction to the J2EE Connector Architecture

Tutorial: Deploying a JCA Resource Adapter for an EJB Application

Connect the enterprise with the JCA, Part 2

I agree, what is the point of this post if I am only referencing some other tutorials? I only wanted to make a briefing about the posts to come. Personally during the development of my JCA connector I found some dificulties that I think are worthy posting over here.

So, if you are interested in JCA, start reading the tutorials mentioned and take a quick look at the JCA 1.5 specification as well and keep an eye on this blog for the next weeks.

Update for the original post:

Another good reason for learning how to implement a JCA Connector: Aqualogic Service Bus, one of the foundations of Oracle Fusion suite, heavily relies on JCA Connectors for communicating with every kind of application you can imagine. So, if your company is moving to Service Orientation (SOA) and depending on the systems you’ll be integrating you’ll have to roll your own connector.

Complete post series

Outbound connector related posts:

Outbound JCA connectors introduction
Connection request flow on outbound JCA connector
matchManagedConnections short tip
Future updates to the JCA tutorial

Inbound connector related posts:

Inbound JCA Connectors Introduction
Anatomy of an inbound JCA connector


Blog Stats

  • 353,192 hits since aug'08

%d bloggers like this: