I am writing a JCA resource adapter. I, as well as myself, are trying to fully understand the communication management part of the JCA specification. As a thought experiment, pretend that the only client for this adapter will be the Swing Java Java client located on another machine. Also assume that the resource adapter will communicate with its "corporate information system" (EIS) over the network.
As far as I understand the JCA specification, the .rar file is deployed to the application server. The application server creates an implementation .rar of the ManagedConnectionFactory interface file. He then asks to create a factory connection, which is an opaque object that is deployed to JNDI for use by the user to obtain a connection to the resource. (In the case of JDBC, the factory connection is javax.sql.DataSource.)
The requirement that the factory connection maintain a link to the ConnectionManager server that comes with the application, which in turn must be Serializable. This makes sense - in order for the factory connection to be stored in JNDI, it must be serializable, and for it to maintain a reference to the ConnectionManager, the ConnectionManager must also be serializable. So wonderful, this small graph of objects is installed in the application JNDI client tree.
That's where I start to get nauseous. Is ConnectionManager the part supplied by the application server that should handle connection management, sharing, federation, etc. - be fully present on the client at this stage? One of his tasks is to instantiate ManagedConnection, and ManagedConnection does not require Serializable, and the user connection that processes it does not have to be Serializable either. This tells me that the whole pooling mechanism is supplied in bulk for the application client and populated with its JNDI tree.
Does this mean that client-side JCA interaction bypasses the server component of the application server? Where are the network boundaries in the JCA API?