Approach to developing Resource Adapters using J2CA

One of my friend, Karthik had asked me to write something about J2EE Connector Architecture (JCA). I have a year or so experience in JCA, was part of team developing RDBMS Adapter for Weblogic Platform.
The below section is part of my write-up given to my boss on JCA. The first part is on Overview of JCA, which I did not think was that important/cruicial to post it here. You can find lot of primers on J2CA. The seeker seeks it.
The second part of the write-up is bascially the title of this blog, which is based on my limited experience and knowledge.
Here it goes...

Approach to developing Resource Adapters using J2CA

JCA is an interface definition. There are no specific guidelines or approaches/reference implementations provided by SUN in creating resource adapters.

The approaches broadly fall under two categories:

• Non-Framework based approach
• Framework based approach

Before we decide on one of the above approaches, it is recommended to have a technology proof of concept (POC) implementing a basic adapter to connect to each type of EIS to mitigate any technical risks as early as possible.This is important as we are integrating J2EE systems with disparate Legacy /EIS systems. This technology POC single out & eliminate main elements of risk. The goal can be to implement a single requirement be it a connection related or transaction related using the technology that we would like to prove

The below outline of development approach for building resource adapters apply

• Research EIS requirements

Identify the required EIS and appropriate services that need to be exposed
Identify the expensive Connection object
Implement a POC
Identity security needs
Identity type of transaction (XA-Txn, Local Txn or No Txn)

• Development environment configuration

Set up file/directory structureSet up build proces

• Implement Service provider interface

Implement the interfaces that comprise the SPI, at least the following three interfaces:
ManagedConnectionFactory, which supports connection pooling by providing methods for matching and creating a ManagedConnection instance.
ManagedConnection, which represents a physical connection to the underlying EIS
ManagedConnectionMetaData, which provides information about the underlying EIS instance associated with a ManagedConnection instance

• Implement Client Connection Interface (optional)

Implement the interfaces that comprise the CCI including the Connection interface and the Interaction interface

• Package the Adapter

Package the adapter into rar file.
Deploy the Adapter on the target application server platform

• Test Adapter

Test the adapter for functionality & performance on desired platforms/EIS versions

• Release the adapter

Non-Framework based approach

This approach is primarily useful if we are implementing only one of type of Resource adapter. Here everything needs to implemented from scratch i.e. all the outlined steps above are executed. If an adapter factory is envisaged, the framework based approach is recommended.

Framework based approach

When there is a need to create resource adapters for more than one EIS, development effort can be greatly reduced by defining a generic adapter framework. This is because the common features applicable for all adapters can be built into the framework.
The framework can also implement some default behavior which can be extended as needed by the developer. For example, the JCA specification requires that the InteractionSpec implementation class provide getter and setter methods that follow the JavaBeans design pattern. To support the JavaBeans design pattern, support for PropertyChangeListeners and VetoableChangeListeners in required in the implementation class. The framework can take care of this and other low level details allowing the adapter developer to focus on implementing the EIS-specific details of the adapter.

The common features for the resource adapters that can be implemented by the framework include but are not limited to

• Basic support for internationalization and localization of exception and log messages for an adapter
• Logging tool kit support
  -that allows you to log localized messages to multiple output destinations.
• Getter and setter methods for standard connection properties (username, password, server, connectionURL, and port) as the connection properties are common to all the EIS
• License checking facility (applicable for EIS vendors who market the adapters)
• Default Connection event listeners for logging connection-related events
• Simplifying the clean-up and destruction of Connections
  -destroying Connection instances when a connection-related error occurs
• Exception handling for
  -providing a generic exception handling
• Base implementation of the primary Interfaces for abstract implementation of the interfaces

Instead of investing lot of effort and time in planning/designing a custom framework from scratch, there are many frameworks available from popular application server vendors which can be used right away. For e.g. BEA has Adapter Development Toolkit, IBM has its own Connector framework; SUN has Sun ONE Connector Builder etc. These are best used for their respective application servers as they are designed for those and there can be difficulty in porting to other application servers. But definitely a lot can be benefited by studying these frameworks’ documentation which can aid in building your own custom framework.

In conclusion, the approach depends on factors such as business drivers, time to market, complexity, and available developer skill set etc. Having a framework in place adds structure and consistency to the process and product, reducing recurring development/enhancements and maintenance costs.