Suitability of Java EE Connector Architecture

Question

Hi
I'm designing the architecture for an enterprise system which will be essentially "information and control" in nature, in that it will be required to interact with a large number of external systems that will provide/accept information and/or accept control requests. For example, my system will be connected via TCP to a number of devices that are constantly feeding in realtime information, and will also be connected via UDP to a number of devices that can be controlled. For each interface, the message transfer/content protocol will generally be a proprietary format. There will be any number of such external systems using any number of different message protocols.
My system will use Java EE technology. My understanding of the Java EE Connector Architecture (JCA) is that it is intended to support integration between Java EE app servers and EISs. What I'm wondering is whether in my environment, I could/should consider my "external systems" to be EISs. Looking at the JCA spec and elsewhere, a typical EIS is an ERP or a mainframe transaction processing system or a legacy database - whereas my external systems are just "things" with which my system will exchange messages. Are the two things the same? Is it practical to go for a JCA solution on the assumption that:
- I'll have to write all of my own resource adaptors, one for each type of interface;
- I can dispense with a lot of the 'fancy' JCA features such as transactions and security (if I can see no need for them).
Any suggestions or guidance gratefully received.

Answer 1

Yes, your architecture is well suited to the java connector approach. It doesn't really
matter whether your backend external system is categorized as an "EIS". The fact
that it communicates via a proprietary format means you don't want to have to
write application code in a Java EE component that directly processes it. The
advantage of the inbound portion of the Java Connector architecture is that it
lets you plug in a piece of system code specifically tailored to communicate with
your backend system. Because it's a piece of system code, you have access to
many lower-level plumbing services such as threads that would not be available
to application code.
Likewise, once you process the appropriate lower-level communication details,
it's much more desirable to delegate to an application component in the
form of a Message-Driven bean that can then perform the business logic
needed in the enterprise tier.
--ken