Estoy tratando de entender cuál es el propósito y por qué necesitamos las diferentes vistas del cliente en EJB. ¿Alguien podría intentar explicarlo?
Respuestas:
Vista de cliente remoto
Cuando su EJB y sus clientes estén en un entorno distribuido, lo que significa que los EJB y los clientes residirán en máquinas virtuales Java independientes. Ejemplo: EJB alojados en un servidor de aplicaciones WebSphere y Servlets que consumen API de EJB alojadas en un servidor Tomcat.
Vista de cliente local
Solo cuando se garantiza que otros Enterprise Beans o clientes solo direccionarán el Bean dentro de una única JVM. Por ejemplo, los EJB y los servlets implementados en el mismo servidor de WebSphere.
Vista sin interfaz
Es casi igual a la vista del cliente local, pero hay diferencias. Su clase de bean no es necesaria para implementar interfaces de vista de cliente en este caso. Todos los métodos públicos de la clase bean se exponen automáticamente al llamador. la vista sin interfaz siempre adquiere una referencia EJB, al igual que las vistas locales o remotas, ya sea mediante inyección o búsqueda JNDI; pero, el tipo Java de la referencia EJB es el tipo de clase de bean en lugar del tipo de una interfaz local. Esta es una conveniencia introducida como parte de Java EE6.
Diferencia entre la vista de cliente local y la vista sin interfaz
En el caso de una vista sin interfaz, el cliente y el bean de destino deben estar empaquetados en la misma aplicación (EAR). En el caso de la vista local, el cliente se puede empaquetar en una aplicación separada de la aplicación empresarial. Por lo tanto, esto brinda más flexibilidad en términos de precisión en sus componentes.
Puede usar la vista de cliente local frente a la vista sin interfaz según el escenario de uso de la API. Es muy probable que la vista sin interfaz reciba funciones flexibles en futuras especificaciones.
Razón
Históricamente o de otro modo, se suponía que un cliente que deseaba utilizar servicios EJB "buscaba" el bean en el contenedor (con ciertos contextos iniciales). Eso se debió a que todas las invocaciones se realizan a través de una referencia EJB especial (proxy) proporcionada por el contenedor. Esto permite que el contenedor proporcione todos los servicios de bean adicionales, como agrupación, transacciones administradas por contenedor, etc. Por lo tanto, un cliente no puede instanciar explícitamente un EJB con el newoperador. La vista del cliente se proporciona a través de ciertas interfaces a las que el cliente tendría acceso. La realización del proxy en el lado del servidor se realiza en base a estas interfaces. Se definen diferentes vistas de cliente para adaptarse a diferentes escenarios de implementación como se mencionó anteriormente.
new, termina obteniendo una nueva instancia. Eso es todo. Esa nueva instancia no tendrá ningún "soporte" del contenedor en términos de agrupación, configuración de su contexto, etc. Se está ejecutando por su cuenta.
Según la Sección 3.2.2 de la Especificación EJB 3.1:
El acceso a un enterprise bean a través de la vista de cliente local solo debe ser compatible con los clientes locales empaquetados dentro de la misma aplicación que el enterprise bean que proporciona la vista del cliente local. Las implementaciones compatibles de esta especificación pueden admitir opcionalmente el acceso a la vista del cliente local de un bean empresarial desde un cliente local empaquetado en una aplicación diferente. Los requisitos de configuración para el acceso entre aplicaciones a la vista del cliente local son específicos del proveedor y están fuera del alcance de esta especificación. Las aplicaciones que dependen del acceso entre aplicaciones a la vista del cliente local no son portátiles.
La vista sin interfaz es solo una característica conveniente que permite que un bean exponga una vista de cliente local sin tener que declarar una interfaz separada.