¿Dónde están los límites de la red en Java Connector Architecture (JCA)?

Question

Estoy escribiendo un adaptador de recursos JCA. También soy, como voy, tratando de entender completamente la parte de gestión de conexión de la especificación JCA. Como un experimento mental, pretender que el único cliente de este adaptador será una oscilación del cliente de aplicación Java se encuentra en un equipo diferente. Supongamos también que el adaptador de recursos se comunicará con su "sistema de información empresarial" (EIS) a través de la red también.

A mi entender la especificación JCA, el archivo .rar se implementa en el servidor de aplicaciones. El servidor de aplicaciones crea la implementación del archivo .rar de la interfaz ManagedConnectionFactory. A continuación, le pide que para producir una fábrica de conexiones, que es el objeto opaco que se implementa a JNDI para el usuario a utilizar para obtener una conexión con el recurso. (En el caso de JDBC, la fábrica de conexiones es una javax.sql.DataSource.)

Es un requisito que la fábrica de conexiones de mantener una referencia a la ConnectionManager suministrado por la aplicación del servidor, el cual, a su vez, se requiere para ser Serializable. Esto tiene sentido - a fin de que la fábrica de conexiones que se almacena en JNDI, debe ser serializable, y con el fin de que para mantener una referencia a la ConnectionManager, ConnectionManager también debe ser serializable. Así bien, este pequeño gráfico de objetos se instala en el árbol JNDI del cliente de la aplicación.

Aquí es donde empiezo a tener náuseas. Es la ConnectionManager - la pieza suministrada por el servidor de aplicaciones que se supone que debe manejar la gestión de la conexión, el compartir, la puesta en común, etc .-- totalmente presente en el cliente en este momento? Una de sus tareas es crear instancias ManagedConnection, y una ManagedConnection no está obligado a ser Serializable, y la conexión de usuario se encarga de que vends tampoco están obligados a ser Serializable. Eso me hace pensar que toda la maquinaria de agrupación de conexiones se envía al por mayor al cliente de la aplicación y se la metió en su árbol JNDI.

Qué significa todo esto que las interacciones JCA de la circunvalación de lado del cliente el conjunto de componentes de servidor del servidor de aplicaciones? ¿Dónde están los límites de la red en la API JCA?

Answer 1

  

¿Todo esto significa que la JCA   interacciones desde el lado del cliente   omitir el conjunto de componentes del lado del servidor de   el servidor de aplicaciones? ¿Dónde están los   límites de la red en la API JCA?

Que yo sepa, sí. Habrá un JNDI local y el JNDI locales volverán conexiones locales. Lo mismo si cierto para otro tipo de objeto en el JNDI, un valor tal configuración (env-entry). Por supuesto, si se mira un EJB, la fábrica devuelve un proxy para el grano a distancia, pero el JNDI sigue siendo local, que yo sepa.

El cliente incorpora su propia piscina. Esto significa, como usted ha señalado, que las conexiones obtenidos en el cliente escaparán a la maquinaria del lado del servidor.

Se vuelve aún peor cuando comenzamos a jugar con las transacciones distribuidas. Un cliente puede obtener una UserTransaction para iniciar y detener las transacciones distribuidas en el lado del cliente (no toda aplicación. Servidor soporta esto, sin embargo). El contexto de transacción se propagan durante las llamadas a EJB remoto. Una transacción distribuida puede entonces atravesar las conexiones del cliente y las conexiones del lado del servidor.

De acuerdo con la filosofía J2EE, un cliente de aplicación normalmente no debería utilizar las transacciones y obtener la conexión directamente; debe comunicarse únicamente con EJB remoto.

Las especificaciones no son muy claros acerca escenario más complicado y no hay información de que muchos alrededor. La especificación do, por ejemplo, no obliga al servidor de aplicaciones para exponer la UserTransaction al cliente.

Lo que escribí aquí se aplica a GlassFish al menos, pero no se basaría en una aplicación coherente de tales características en todos los servidores de aplicaciones.