La motivación aquí es que la mayoría de las implementaciones EJB funcionan en servidores proxy. No estarías demasiado lejos como para pensarlo como el AOP de la vieja escuela. La interfaz de negocios es implementada por el contenedor EJB, con bastante frecuencia a través de un simple java.lang.reflect.Proxy, y este objeto se entrega a todos en el sistema que solicitan el ejb a través de la búsqueda de @EJB o JNDI.
El proxy está conectado al recipiente y todas las llamadas en que se vaya directamente al recipiente que se realice pruebas de seguridad, iniciar/detener/suspender las transacciones, invocar interceptores, etc., etc., y, finalmente, delegar la llamada a la Instancia de bean - y por supuesto hacer cualquier limpieza requerida debido a cualquier excepción lanzada - y finalmente entregar el valor de devolución a través del proxy a la persona que llama.
Llamar a this.foo() directamente, o pasar 'esto' a la persona que llama para que también puedan hacer llamadas directas, omitirá todo eso y el contenedor se eliminará efectivamente de la imagen. El 'getBusinessObject (Clase)' método permite que la instancia del bean para obtener esencialmente un proxy para sí lo que puede invocar sus propios métodos y hacer uso de los servicios de gestión de contenedores asociados a ella - interceptores, gestión de transacciones, control de seguridad, etc.
¡Una explicación muy clara, David! Gracias ! – stratwine
¿Puede alguien también confirmar que al usar SessionContext.getBusinessObject() garantizamos que los métodos @Asynchronous se ejecutarán en diferentes subprocesos? –