5 Replies Latest reply on Feb 22, 2010 1:40 PM by ljnelson

    Network boundaries in JCA?

    ljnelson

      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

        • 1. Re: Network boundaries in JCA?
          ben.cotton2

          ljnelson wrote:


          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.

           

          The JCA specification does not explicitly address accommodating a remote client application's JNDI lookup() of a ConnectionFactory reference that bridges to a provider's ConnectionFactory implementation via that provider's resource adapter.  Accommodating a remote client application in this way would be a value added feature above and beyond what the spec requires for the ConnectionFactory bridge.  Though it is not a strict JCA requirement, some JEE app servers do accommodate this capability (but some don't).

           

          Some similar recent discussion w.r.t.  JBoss AS 5.1 and this issue takes place here:

           

          http://community.jboss.org/message/525226 ,

          http://community.jboss.org/thread/72803?tstart=0

          1 of 1 people found this helpful
          • 2. Re: Network boundaries in JCA?
            ljnelson

            First, thanks for your answer.

             

            But doesn't this happen all the time?  Most application servers I know about, for example, implement DataSources on top of the JCA.  That means whenever I look up a DataSource in a remote client (come to think of it, I can't remember the last time I did this...maybe it's not all that common....) I am getting a connection factory that somehow keeps a "tether" back to the application server.  I hear you and agree with you that indeed the specification does not mention this--hence my question--but how would you allow for this as an RA developer?

             

            Muddled thinking on my part; I know.  Still wrapping my head around this.  Thanks again.

            • 3. Re: Network boundaries in JCA?
              vickyk

              ljnelson wrote:

              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.

              It is referencable since the CF needs to be bound to JNDI and implements seriablizable so that the remove clients can get the refernce over wire. The JCA specs explicitity indicates that the CF should implement Referencable interface.

               

              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).

               

              It is at the deployment time that the CF implemeting the Serializable interface gets bound to the JNDI, and during the usage of the CF by remote client at run time CF would be serialized over wire.

               

              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.

               

              Yes it is a n/w call. The JCA infrastruture like the pooling implementation does not passed to the remote client. The remote client should get the proxy of the CF via JNDI along with the proxy of CM. Check the implemetation of the jdbc RA in Jboss, check this class

               

              https://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/connector/src/main/org/jboss/resource/connectionmanager/ConnectionFactoryBindingService.java

               

               


               

              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.

               

              You should get the Connection Proxy and the MCF/MC calls will happen on server.

              The Connection implementation should implement the Serializable interface, it does if you check the jdbc rar implementation in Jboss

              https://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/connector/src/main/org/jboss/resource/adapter/jdbc/WrapperDataSource.java

              https://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/connector/src/main/org/jboss/resource/adapter/jdbc/WrapperConnection.java

               

              Finally the usage of JCA is not intended to be used remotely, it is suppsoed to used by the jee components so that they get the infrastruture benefit  like pooling,tx and security. In your case your need seems to get conneted to the EIS via JCA for a standalone java client, you could do it without the JCA tier.

              Ideally from the standalone application you should make a SLSB call which would delegate the calls to the JCA.

               

              In case of jdbc RAR you could use the thin client to connect to the EIS and need not to go via JCA tier, similar approach should be applicable with other EIS.

               

               

              Regards,

              Vicky

              1 of 1 people found this helpful
              • 4. Re: Network boundaries in JCA?
                ljnelson

                Yes it is a n/w call. The JCA infrastruture like the pooling implementation does not passed to the remote client. The remote client should get the proxy of the CF via JNDI along with the proxy of CM. Check the implemetation of the jdbc RA in Jboss, check this class

                Ah, OK, now I get it.  That means the specification is very badly under-specific about the contract that a connection handle must have with the caller.  It also means the specification is very badly under-specific about the return values from methods on the connection factory.

                 

                What I mean is, if an application server is always going to provide a connection factory proxy (I assume you mean a java.lang.reflect.Proxy?), then any operations that the client performs on that Proxy that return values must return Serializable values.  That would, presumably, include the connection handle implementation.

                 

                The Connection implementation should implement the Serializable interface

                This certainly follows, but it is not mentioned in the specification.  (Then again, neither is it mentioned that application servers will construct Proxy instances of the ConnectionFactory and ConnectionManager classes.)

                 

                Finally the usage of JCA is not intended to be used remotely, it is suppsoed to used by the jee components so that they get the infrastruture benefit  like pooling,tx and security.

                I am talking about an application client, which is a "jee component" in a fully managed environment.

                 

                If only I could find Rahul Sharma and ask him these questions directly!  :-)

                 

                Best,

                Laird

                • 5. Re: Network boundaries in JCA?
                  ljnelson

                  I followed up with the specification authors, and they said this:

                  The Java EE spec [Table EE.6-1 in the Java EE 6 platform spec] does not require support for Connectors in application clients and the Connectors specification also doesn't address in any detail how application servers may support managed usage of a Connector in a Java EE application client.

                  Some implementations (like GlassFish) will provide a local managed environment for a Connector in the application client's VM (ie replicate the pooling and other runtime infrastructure surrounding Connection mananement in the appclient's VM) and some others provide a proxy Connection handle in the application client that is a proxy to ManagedConnections in the server. The latter implementations may provide their own proxy that implements the Connection interface to the app-client and wire all method invocations on it to a valid "Connection" in the server or use other techniques thereby obviating the need to pass a non-serializable ManagedConnection to the application client's VM.

                   

                  I thought this would be helpful to other readers.

                   

                  Best,

                  Laird