User development,
A new message was posted in the thread "Network boundaries in JCA?":
http://community.jboss.org/message/525508#525508
Author : Laird Nelson
Profile :
http://community.jboss.org/people/ljnelson
Message:
--------------------------------------------------------------
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.
Best,
Laird
--------------------------------------------------------------
To reply to this message visit the message page:
http://community.jboss.org/message/525508#525508