tags:

views:

136

answers:

1

Hi,

We have been using a JCA to interface with a low-level network resource from within WebSphere, however we have a requirement to be able to access the same network resource externally from Tomcat (i.e. not in a managed environment). The network communication and protocol layouts is very verbose, so we would rather not copy/paste several thousand lines of code (and then have to maintain them separately).

From reading the JCA spec, there is supposedly some support to execute the code in a non-managed environment (such as Tomcat). Unfortunately, I have no idea what the interfaces are supposed to do, or how to call them from outside a managed environment (the spec is pretty vague).

Are there any implementation examples out there that show how to modify a JCA to be usable in a non-managed environment?

Thanks!

+1  A: 

We had similar case, where we developed a connector to access external WebDav storage, and wanted to use it also from a stand alone application (non-managed).

I do believe that the easiest way is to solve this at the design level, and organize your code in a way that the connector's core logic is JCA-agnostic and can be reused easily. Then you can wrap this with JCA-specific code that exposes the connector to the AS. It could probably even be packaged in two jar -- That's at least the solution we choose (but we packaged all in one .jar).

Otherwise, a JCA connector is the "glue" between the following three parties:

  1. the Application Server
  2. the EIS
  3. the Application Component.

It should be possible to simulate the AS with a lightweight implementation of the necessary classes, and then use the JCA connector directly.

One main job of the AS with respect to a JCA connector is to manage the pooling of connections, and from what I remember, the corresponding interface that you should then implement is ConnectionManager.

The JCA connector receive a reference to a ConnectionManager, but the implementation is AS-specific. Writing a lightweight implementation that provides rudimentary pooling (or no pooling at all) sounds feasible.

I had written once a sequence diagram of the connection allocation mechanism. Maybe you will find it useful. Another interface is ResourceAdapter where you define the startup/shutdown, but that's easy to invoke manually.

(There is probably a bit more than that, and it of course depends on what your JCA connector uses. For instance, if it use Work and the WorkManager, then it becomes a lot more complicated to mock. Same remark if the connector is transactional. But it doesn't seem to be your case.)

Otherwise, I think that Spring has some support for JCA, it may be worth having a look how they did it.

From reading the JCA spec, there is supposedly some support to execute the code in a non-managed environment

Can you mention the specific part of the spec you are referring about?

ewernli
My reference to the spec is based on the various sub-sections such as 3.4, 5.3.8, 6.4.2 and the like in the JCA 1.5 specification. Thank you for your help. Unfortunately it looks like our code it too tightly wound in all the wrong places to the managed portions of the spec.
Paul Kuykendall