Hello, fellow JBoss users. I have a question related mostly to the JCA specification, but I am hoping that the implementors will jump in with their expertise.
I am writing a resource adapter to a back end system. But I realized about halfway through that I don't know where all the network boundaries are in the JCA specification. I was hoping you all could help fill in some gaps.
To best illustrate, assume we have a Java Application Client on another machine, connecting to the app server. Suppose that client looks up my resource adapter from its JNDI implementation which of course is supplied correctly by the application server in accordance with the Java EE spec.
Now, the JCA specification says that upon deployment, over on the server side, my .rar file will help the application server to create an instance of my ManagedConnectionFactory implementation, which, in turn, will create a connecton factory (little c, little f) that will be installed in JNDI. It is for this reason of course that the connection factory (little c, little f) needs to be both Serializable and Referenceable. All fine and good.
So the client asks its JNDI implementation to look up my connection factory. This all takes place, I presume, on the client VM. What I mean to say is that when the lookup completes, the client will have an instance of my connection factory, which was serialized over the wire, either at lookup time or at deployment time (doesn't really matter to me, although I'm curious here too).
Now the client asks my connection factory for a connection handle. In accordance with the JCA specification, my connection factory retains a reference to the ConnectionManager that was supplied to it at construction time. (ConnectionManager is supplied by the application server, and is serializable, so presumably it crossed the wire with my connection factory, and was not some kind of stub.) Also in accordance with the spec, my connection factory now calls connectionManager.allocateConnection().
Question #1: Is this guaranteed to be a network call? Is ConnectionManager a remote stub? Or does it drag along the entire connection pooling machinery with it when it crosses the wire?
ConnectionManager#allocateConnection() now brings the flow back into the application server, which roots around, does some matching algorithms, and finally results in my ManagedConnectionFactory implementation having its createManagedConnection() method called.
Question #2: Does this call take place on the server, or on the client? If it takes place on the server, why is ManagedConnection not mandated to be Serializable? Or my user connection implementation, for that matter? Neither needs to be Serializable, which tells me that therefore they don't need to cross the wire. And since the user connection needs to be on the client side, then because it retains a reference to its ManagedConnection, then that also tells me that the ManagedConnection is on the client side.
Now that the application server has found a ManagedConnection (and I'm unclear at this point whether we're on the client or the server), it eventually calls its getConnection() method, whose purpose is to return a connection handle (little c, little h), which is of course what the user wanted all along. The connection handle it returns does not have to be Serializable, which suggests that it did not get shipped over the wire. That means that the ManagedConnection that produced it did not get shipped over the wire, which means that the ManagedConnectionFactory that produced IT did not get shipped over the wire, which means that unless I'm very wrong the entire application server connection pooling machinery is present on the client VM.
I'm sure I have blown something here, but I don't know what. Any enlightenment is gratefully appreciated.