SCBCD - Vida, obra y muerte de un Stateless Session Bean

Ahora toca hablar de ciclo de vida de una instancia EJB, y en este post específicamente de los Stateless Session Beans. La imagen es cortesiá de la guía SCBCD de Mikalai Zaikin y como está en Inglés y no me dan muchas ganas de traducirla (el Paint y yo andamos peleados xD); aquí una descripción de la vida de un EJB desde que nace que muere (no... ellos no se reproducen)

1. Los stateless session beans se mantienen en un pool (creo que poner piscina sería un tanto fuera de lugar), y son utilizados de este pool por los clientes EJB cuando lo requieren. Entonces, todo inicia cuando el contenedor decide que necesita más instancias, e instancia un stateless SB que es agregado al pool
1. Recordar que después de instanciar el EJB, se produce la inyección de dependencia de estar presente, y luego se llama a los métodos anotados con @PostConstruct para inicializar recursos. Siempre se invoca al método @PostConstruct antes de la primera invocación a métodos de negocio.
   
2. Para que un cliente acceda a los servicios del stateless SB, debe obtener una referencia a la interfaz de negocio del EJB (recordar que clientes interactúan a través de esta interfaz) mediante JNDI (o inyección de dependencia...que al final es un lookup JNDI)
3. Una vez que el cliente obtiene la referencia mediante JNDI, puede invocar al método de negocio de la interfaz de negocio EJB. Ésta a su vez invoca al método correspondiente en la clase Wrapper (generada por el contenedor).
4. Antes de invocar al método en la instancia presente en el pool , el contenedor nos ayuda con los servicios middleware necesarios (gestión de transacciones, seguridad, etc)
5. Ahora si llamamos a la instancia EJB, invocamos al método y obtenemos el resultados. También se proveen servicios middleware necesarios después de la invocación.
   
6. Los resultados pasan al cliente a través de la interfaz de negocio. Tenemos un cliente feliz :)
7. El tiempo pasa...las cosas cambian ...
   
8. El contenedor decide que tiene demasiadas instancias en el pool; por lo que decide eliminar del mapa a algunas.
9. Se invoca al método del bean anotado como @PreDestroy (para liberar recursos antes del fin...como conexiones a base de datos).
10. Se remueve la instancia del bean. Que en paz descanse.