Posts Tagged ‘Java Connector Architecture


Connection request flow on outbound JCA connector

Continuing with the posts about outbound JCA connectors lets have a quick look at one of the main flows of an outbound JCA connector: the connection request flow.

By now you might be wondering: “What on earth is responsible for making my connectors poolable? Is there any dark magic involved?”.

First answer: “the ConnectionManager” and second answer: “Yes and it is container dependant!”. That’s the reason you should keep an instance of the ConnectionManager inside your ConnectionFactory when it is created, that’s how you delegate the connection creation to the pooling implementation of the container.

Enough explanation let’s have a look on a sequence diagram for a connection creation when we have no connections inside the pool.

First flow: connection request with no matching connections

First thing to take note, it is up to you to implement the matchManagedConnections, I’ve put a note on the next diagram that might help on this implementation: making the ManagedConnection be able to compare itself to a ConnectionRequestInfo makes the things easier. Also beaware that some Application Servers (eg.: WebSphere) skip the matchManagedConnections part if it detects by itself that the pool is empty or there isn’t any matching connection.

Sequence Diagram - No Matching Connection

Sequence Diagram - No Matching Connection

Another point about the specification is that it states that a single managed connection may be responsible for more than a single physical connection (FooConnectionImpl), this is required for scenarios where connection sharing is possible (refer to section of the specification).

Previously I tried implementing using a single handle but I noticed that it does not take much effort to make it fully adherent, in fact, it is only necessary to use a delegate (FooConnectionHandle) that implements the FooConnection interface and delegates almost all the methods to the FooConnectionImpl instance that is inside the FooManagedConnection instance (refer to sections and 6.8.1 of the specifications). The exception to the delegation is the close method that your connection must provide, this method in the delegate will be responsible for raising the Connection Closed Event, this is the way you signal the container that you are giving the connection back to the pool.
Second flow: connection request when there are matching connections inside the pool.

Sequence Diagram - Matching Connections

Sequence Diagram - Matching Connections

This flow is executed whenever the container guesses there are potential matching connections. The matchManagedConnection method is invoked with the minimal connection set that the container can identify. The connection set is a key point: specification states that the container is responbile for determining the minimal set that has a potential match to avoid degrading performance while looking for the connection. Also I noticed that some containers don’t check the connections inside this Set before sending them for matching.

Implementation Tips

Here are some decisions that might help on the implementation of the ManagedConnection and ManagedConnectionFactory.

  • Store the ConnectionRequestInfo that was passed to the ManagedConnectionFactory on the creation of the ManagedConnection as an attribute inside the ManagedConnection this leads to the next tip
  • Use the ConnectionRequestInfo stored in the ManagedConnection as argument to an overload of the equals method of the ManagedConnection class this helps in the implementation of the matchManagedConnection method
  • Never ever forget to include your ManagedConnection object on equals(Object) method implementation. The tip above may lead you to forget this details. Dont do this under any circumstance since specification requires this and some containers freak out after some use time if this method is not implemented (connection borrow time goes all way up if not implemented)

Next post I’ll focus on how to signal the container that something went wrong with the connection and how to validate the connection before it is returned to the requestor.


Outbound JCA connectors introduction

Continuing with the posts about JCA I’ll start with the project of an Outbound JCA Connector that I’ll call FooJCA. First of all and let make this clear, I am not stating that this design is an optimal JCA Connector design, what I can say is that I tried to make as compliant as possible from my understanding of the documentation.

Lets start with a overall view of the main classes and interfaces involved in a JCA Connector implementation.

Foo Connector Class Diagram

Foo Connector Class Diagram

First class to take note, the FooResourceAdapter, that’s one of the connector classes that is able to directly communicate with the container and use some priviledged services (eg.: scheduling Work instances or creating timers). This ability is provided by the BootstrapContext that is passed as a parameter of the start method by the container.

Another key class that also has the ability of interacting with the container is the FooManagedConnectionFactory. As you may have already noticed, this class isn’t always container dependant, or at least it may not be (that’s up to the developer the choice of providing functionality of the Connector outside the container). The difference (between working inside the container or outside it) is usually detected when the class method createConnectionFactory is called with or without the ConnectionManager. Talking about the ConnectionManager this is a Container implemented class that is responsible for pooling connections and related work. This Container work relies on the matchManagedConnections method that is provided by the ManagedConnectionFactory, so, pay much attention to this method implementation.

Moving on, the FooConnectionRequestInfo is a implementation of the ConnectionRequestInfo interface and is the class responsible for passing Connector dependant details about the request between the Container and the JCA Connector. One of the requisites of this class is that it implements equals and hashCode.

The FooManagedConnectionFactory as you may guess is the class responsible for creating the FooConnectionFactory instances and FooManagedConnection instances as well. It does not matter if the FooConnectionFactoryImpl instance will be Container dependent or not, it will be FooManagedConnectionFactory’s role of creating it.

At least but not last, the FooConnectionFactoryImpl will be the class responsible for creating FooConnectionImpl instances when requested (this will be treated in a separate post since it is a little long topic).

And, for finishing this post, FooManagedConnectionImpl is the class responsible for wrapping a FooConnectionImpl and returning delegates (FooConnectionHandle class) that implement FooConnection interface and notifies the container about the status of the ManagedConnection connection.

That’s enough for this post, keep on watching the blog for the rest of the implementation of the Outbound JCA Connector.


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,165 hits since aug'08

%d bloggers like this: