Posts Tagged ‘MDB

01
Dec
09

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.

Advertisements
14
Mar
09

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.

24
Dec
08

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.




ClustrMaps

Blog Stats

  • 361,261 hits since aug'08

%d bloggers like this: