[jboss-user] [JCA] New message: "Re: Network boundaries in JCA?"

Vicky Kak do-not-reply at jboss.com
Thu Feb 11 00:03:53 EST 2010


User development,

A new message was posted in the thread "Network boundaries in JCA?":

http://community.jboss.org/message/525640#525640

Author  : Vicky Kak
Profile : http://community.jboss.org/people/vickyk

Message:
--------------------------------------------------------------

> 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

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/525640#525640




More information about the jboss-user mailing list