El objeto proxy en EJB

Question

Estoy leyendo el libro Enterprise JavaBeans 3.1 y me pregunto si he entendido correctamente el concepto del objeto proxy EJB. Ahora sé que sigue el patrón de proxy y he leído algo al respecto.

Cuando hacemos las interfaces para los beans, lo hacemos porque queremos que se implemente el patrón de proxy. Esto nos ayuda porque a los clientes solo les preocupa lo que podemos hacer y no estar atados directamente a una clase, sino una interfaz que puede actuar como si fuera el objeto real.

Entonces, el contenedor probablemente instancia los objetos proxy que implementan la interfaz correspondiente y agrega algún código mágico (código de red) antes de invocar el EJB real para nosotros, porque el objeto proxy se hace automáticamente ¿verdad?

¿He entendido mal el concepto? Si ese es el caso, ¿alguien podría decirme qué pasa?

Answer 1

Correcto. Las interfaces que está escribiendo para sus beans habrían sido suficientes si su aplicación estuviera confinada a una JVM local. En este caso, no se necesitaría ningún proxy, ya que la clase implementadora podría crearse una instancia y suministrarse directamente.

Los clientes de EJB no pueden trabajar en sus clases de implementación, ya que no las tienen en su classpath. Los EJB son transparentes a la ubicación, puede llamarlos a través de la red o desde otra aplicación ubicada en el mismo servidor, pero aislados por diferentes cargadores de clases. En tales casos, debe tener objetos proxy para ordenar, enviar a través de la red y desglosar los parámetros que proporciona a las llamadas EJB y los resultados de estas llamadas que recibe. Y en el lado del cliente, necesita una implementación de interfaz EJB ficticia, que reenvía sus llamadas al servidor donde está instalado este EJB.

Los proxies también manejan otras funciones, como iniciar/finalizar transacciones en las llamadas al método EJB.

EDIT: si tiene curiosidad acerca de qué EXACTAMENTE tales proxies podrían hacer, eche un vistazo a las vistas generales de RMI en Java y AOP (ya sea en AspectJ o Spring). Le dará la idea de qué tipos de tareas se pueden implementar de esta manera.

Answer 2

¿Se refiere a las interfaces de proxy para beans de sesión sin estado (y con estado) y beans controlados por mensajes?

Si es así, creo que su comprensión es correcta. Lo único que parece haber perdido es el concepto de conjuntos de instancias para beans sin estado. El contenedor no los instancia por solicitud, sino que proporciona una implementación cuando es necesario.

Además, el uso de proxies permite que el recipiente cosas a tener lugar logró: gestión de transacciones, gestión de hilos asíncrono etc.