Archive for August, 2008


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


Business Delegate for EJB 2.1 using Dynamic Proxies

Those who still use EJB 2.1 and had already the oportunity of tasting EJB 3 might miss the liberty of not having to declare the throwing of RemoteException in every remote method. Back to old school and EJB 2.1 we had the Business Delegate pattern that freed us from polluting UI code with RemoteExceptions but still writing a Business Delegate class by hand was tedious and error prone.

J2SE 1.3 brought a powerful feature: Dynamic Proxies but still we have one thing to follow, the DRY (or Don’t Repeat Yourself) principle.

Enough theory… let’s get to the sample. Imagine you had to develop a Foo EJB. You would start by declaring its Local and Remote interfaces. First tip for EJB 2.1 users (like myself) to avoid deploy time surprises: use a POJO interface and make your EJB implement it and also your Local and Remote interfaces extend it. It saves you a lot of time cause chances that you skip a method on your EJB are incredibly high.

So thats the class diagram we have now:

Class Diagram FooEJB

Class Diagram FooEJB

First thing to pay attention, FooLocal and FooRemote interfaces only extend IFoo, unfortunately FooLocal will end up throwing RemoteExceptions. On the other hand IFooDelegate overwrites the method hiding the RemoteException that was thrown in the base interface. You could argue that your Local Interface could override the methods as well removing the RemoteException but then you’d end up writing three interfaces.

FooBean as expected implements the IFoo interface to avoid missing some method. So, enough interfaces and EJB now we have to tie the things together with the Dynamic Proxy.

package foo;
import foo.util.EJBFactory;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class FooDelegateFactory {
    public static IFooDelegate getInstance() {
        return FooProxy.newInstance(EJBFactory.getFoo());

class FooProxy implements InvocationHandler {
    private IFoo foo;

    public static IFooDelegate newInstance(IFoo realFoo) {
        return (IFooDelegate) Proxy.newProxyInstance(FooProxy.class.getClassLoader(), new
            Class[]{IFooDelegate.class}, new FooProxy(realFoo));

    private FooProxy(IFoo realFoo) { = realFoo;

    public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable {
        try {
            return method.invoke(foo, args);
        } catch (InvocationTargetException e) {
            throw e.getTargetException();

One of the tricky parts about the Dynamic Proxies is the exception handling. Since the method is reflective called you need to fetch the original Exception through the InvocationTargetException and rethrow it. Pay attention that the invoke method declares that it may throw anything.
So, with this you have a Business Delegate that only takes you to construct the proxy and replicate the method on that interface.


Blog Stats

  • 375,197 hits since aug'08

%d bloggers like this: