MODELO DE COMPONENTES DE APLICACION

Un componente es una unidad de software reutilizable que puede ser integrada en una aplicación.
Los clientes interactuan con los componentes via a un contrato bien definido. En java, la forma mas
simple de un componente de software es un JavaBean comunmente llamado como bean. Los beans
son componentes implementados en terminos de una sola clase cuyos contratos estan definidos.

En el mundo empresarial, los componentes se enfocan en la implementacion de servicios del

negocio, con el contrato del componente definidos en terminos de operaciones de negocios que
pueden ser llevadas acabo por el componente.

SESSION BEANS

Los session beans son componentes tecnologicos diseñados para encapsular servicios del negocio.
El cliente accede a esas operaciones soportadas por el servicio que pueden ser definidos usando un
interface java o en la ausencia de una interface se establece el metodo como publico en la clase que
hace una implementacion de bean. El significado del nombre session bean tiene que ver con la
manera como el cliente accede e interactua con ellos. Una vez que el cliente obtiene una referencia
a un session bean desde el servidor, el servidor inicia un session con aquel bean y puede invocar las
operaciones de negocios del bean.

Hay tres tipos de session bean: stateless, stateful, singleton.

La interaccion con un bean stateless session inicia al inicio de una llamada de un metodo de negocio
y termina cuando la llamada al metodo se completa. No hay estado que se conserve de una
operación de negocio a otro.
Una interaccion con un session bean statefull viene a ser mas una conversacion que empieza desde
el momento que el cliente adquiere una referencia al session bean y termina cuando el cliente
explicitamente libera el bean de regreso al servidor. Las operaciones de negocio en un session bean
stateful pueden mantener el estado de la instancia bean durante la llamada.
CHAPTER 03 – APLICACIONES EMPRESARIALES

Modelo de Componentes de Aplicacion

Un componentes es una unidad de software reutilizable y autonoma que puede integrarse en una
aplicación.

SESSION BEANS

Son una tecnologia de componentes diseñada para encapsular servicios comerciales. El cliente
accede a las operaciones soportadas por el servicio y se pueden definir utilizando una interface java.
La importancia del session bean tiene que ver con la forma en que los clientes acceden e interactuan
con el bean. Una vez que el cliente obtiene una referencia a un bean de sesion, inicia una sesion con
ese bean y puede invocar operaciones comerciales en el.

Session Bean Stateless

Están pensados para modelar los procesos de negocios que tienden naturalmente a una única
interacción, por tanto no requieren de mantener un estado entre múltiples invocaciones. Después de
la ejecución de cada método, el container puede decidir mantenerlo, destruirlo, limpiar toda la
información resultante de ejecuciones previas, o reutilizarlo en otros clientes. La acción a tomar
depende de la implementación del container.

Un stateless session bean sólo debe contener información que no es específica a un cliente como
una referencia a una fuente de recursos, que es guardada en una variable privada y que puede ser
eliminada en cualquier instante por el container. Por tanto sólo puede definir un método sin
parámetros para su creación, llamado ejbCreate(), ya que no es necesario que reciba un valor del
cliente para ser inicializado.
Los métodos independientes y que están determinados sólo por los parámetros entregados por el
cliente son candidatos a ser representados en este tipo de bean. Por ejemplo un método que realice
un cálculo matemático con los valores entregados y retorne el resultado, o un método que verifique
la validez de un número de tarjeta de crédito son posibles métodos implementables por stateless
session beans.
Un bean Stateless session se define en dos partes:

• Cero o mas interfaces de negocios que definen que metodos puede invocar un cliente en el
bean. Cuando no se define ninguna interface, el conjunto de metodos publicos en la clase de
implementacion del bean forma una interface logica del cliente
• Una clase que implementa estas interfaces, llamada la clase bean debe estar marcada con la
anotacion @Stateless

Ciclo de vida de CallBacks

A diferencia de una clase Java normal utilizada en un aplicación, el servidor gestiona el ciclo de
vida de un session bean stateless. El servidor decide cuando crear y eliminar las instancias del bean
y cuando debe inicializarse los servicios para una instancia del bean despues de que se construye,
pero antes de invocar la logica de negocio del bean. Es posible que el bean tenga que adquirir un
recurso, como un origen de datos JDBC, antes de poder utilizar los metodos comerciales. Sin
embargo, para que el bean adquiera un recurso, el servidor primero debe haber completado la
inicializacion de sus servicios para el bean.
Para permitir que tanto el servidor como el bean alcancen sus requisitos de inicializacion, los EJB
son compatibles con los metodos de lifecycle callback que el servidor invoca en varios momentos
del ciclo de vida del bean. Para los Session Bean Stateless hay dos devoluciones de llamada
PostConstruct y PreDestroy. El servidor invocara el callback PostConstruct tan pronto como haya
completado la inicializacion de todos los servicios de contendor para el bean. En efecto, esto
reemplaza al constructor como la ubicación de la logica de inicializacion porque solo aquí se
garantiza que los servicios de contenedor estaran disponibles. El servidor invoca al callback
PreDestroy inmediatamente antes de que el servidor libere la instancia de bean para que sea
recolectada. Todos los recursos adquiridos durante PostConstruct que requieren el cierre explicito se
debe liberar durante PreDestroy

STATEFUL SESSION BEAN

En el caso de los bean sin estado, la interaccion comienza y finaliza con una unica llamada a un
metodo, en ocasiones los clientes necesitan emitir multiples solicitudes que cada solicitud pueda
acceder o considerar los resultados de solicitudes anteriores. Los beans de session estan diseñados
para manejar este escenario proporcionando un servicio dedicado a un cliente que se inicia cuando
el cliente obtiene una referencia al bean y finaliza cuando el cliente elige finalizar la conversacion.

El session bean stateful por excelencia es el carrito de compras de una aplicación de comercio
electronico. El cliente obtiene una referencia al carrito de compras, comenzando la conversacion.
Durante el periodo de session de usuario, el cliente agrega o elimina elementos del carrito de
compras, que mantiene el estado especifico del cliente, luego cuando se completa la sesion, el
cliente completa la compra, lo que hace que se elimine el carrito.

Algunas diferencias en este Stateful session bean y los Stateless session bean. La primera diferencia
es que la clase ShoppingCart tiene campos de estado que son modificados por los metodos de
negocio del bean. Esto esta permitido porque el cliente que usa el bean de manera efectiva tiene
acceso a una instancia privada del bean de sesion en el cual realizar cambios.

La segunda diferencia es la presencia de la anotacion de @Remove , estos son los metodos que el
cliente utilizara para finalizar la conversacion con el bean. Despues de que se haya invocado uno de
estos metodos, el servidor destruira la instancia del bean y la referencia del cliente arrojará una
excepcion si se realiza otro intento para invocar los metodos de negocio. Cada stateful session bean
debe definir al menos un metodo marcado con la anotacion @Remove

CallBack Lifecyle

El session bean con estado admite callbacks para facilitar la inicializacion y limpieza del bean.
Tambien soporta dos callback adicionales que permiten al bean controlar passivation y la activacion
de la instancia del bean. Passivation es el proceso mediante el cual el servidor serializa la instancia
del bean y que puede almacenarse offline para liberar recursos o replicarse en otro servidor en un
cluster. Activación es el proceso de de-serializar una instancia de un session bean pasivo y hacerlo
activo en el servidor nuevamente. Como los session bean de estado mantienen el estado y nombre
del cliente y no se eliminan hasta que el cliente invoca uno de los metodos de eliminacion en el
bean, el servidor no puede destruir una instancia de bean para liberar recursos. La pasivacion
permite que el servidor recupere recursos temporalmente mientras preserva el estado del bean.

Antes que un bean sea pasivado, el servidor invocara la devolucion de llamada PrePassive. El bean
usa esta devolucion de llamada para preparar el bean para la serializacion, normalmente al cerrar
cualquier conexión en vivo a otros recursos del servidor. El metodo PrePassive se identifica
mediante la anotacion @PrePassivate. Despues de que se ha activado un bean, el servidor invocará
al callback PostActivate. Con las instancia del bean restaurada, el bean debe volver a adquirir
cualquier conexión a otros recursos de lo que pueden depender de los metodos de negocio del bean.
El metodo PostActivate se identifica mendiante la anotacion de marcador @PostActovate.

SINGLETON SESSION BEAN

Proporciona una sola instancia del bean compartida a la que se puede acceder simultaneamente y
usar como mecanismo para el estado compartido. Los bean de sesion singleton comparten los
mismo ciclos de vida callbacks como un session bean sin estado. Una vez creado el session bean
singleto continuara existiendo hasta que el contenedor lo elimine, independientemente de las
excepciones que se produzcan durante la ejecucion del metodo de negocio. Esta es una diferencia
clave con respecto a otros session beans porque la instancia del bean nunca volvera a ser creada en
el caso de una excepcion del sistema.

El session bean se hace ideal para almacenar el estado de una aplicación, ya sea de solo lectura o
lectura y escritura.