INSTITUTO TECNOLOGICO DE TEPIC

INGENIERIA EN SISTEMAS COMPUTACIONALES

APLICACIONES EMPRESARIALES
MODELO DE COMPONENTES EJB MAESTRO: ING. ISRAEL ARJONA VIZCAINO
ALUMNOS: CARLOS ALDAIR CARRILLO DE HARO ERNESTO LUQUIN MENDOZA LUIS ANDRES COVARRUBIAS YAEZ 2/FEBRERO/2012

TEPIC, NAYARIT

MODELO DE COMPONENTES EJB

Desarrollo basado en componentes Los componentes (Enterprise beans) permiten reusar cdigo y datos. Los componentes se despliegan en un servidor (contenedor EJB). Componente = objeto + servicios del contenedor EJB Ventajas del desarrollo basado en componentes: Reusabilidad Modularidad Interoperabilidad Un Enterprise bean es un componente de lado del servidor que encapsula la lgica del negocio de una aplicacin. Como un modelo de componentes EJB define tres tipos de objetos que los desarrolladores pueden crear y personalizar, de la siguiente manera: Session Beans.- es para las operaciones de servicio de negocio y orquestar la transaccin y el comportamiento del control de acceso. Message-driven beans (MDBs).- se invoca de forma asincrnica en respuesta a eventos externos, a travs de la asociacin con una cola de mensajes o tema. Entities.- son objetos que tienen identidades nicas y representan los datos de negocio persistentes.

Beans de sesin (Session Beans)

Un session Bean representa un nico cliente dentro de un Servidor de Aplicaciones. Comnmente, un cliente invoca un mtodo de un session bean y ste ejecuta las tareas de negocio, ocultndole al cliente la implementacin (ya sea de la lgica del negocio como tambin de la complejidad de la comunicacin remota). Un Session Bean no es compartido, solo puede pertenecer a un solo cliente y no es persistente. Cuando el cliente termina la sesin, el EJB es desasociado del cliente y termina. Beans de sesin sin estado Ejecutan una peticin del cliente sin guardar ninguna informacin del mismo. Un stateless session bean no mantiene un estado conversacional con el cliente. Cuando un cliente invoca un mtodo en un bean stateless, el bean puede contener valores en sus variables de instancia especficas al cliente, pero solo durante la invocacin al mtodo. Cuando la llamada al mtodo finaliza, el estado se pierde. Cabe destacar, que utilizar variables de instancia en un EJB Session Bean Stateless es un error de diseo. Debido a que los stateless beans soportan mltiples clientes, ofrecen una mejor escalabilidad para las aplicaciones que requieren un gran nmero de clientes concurrentes. Los session beans stateless pueden implementar web services, mientras que los otros tipos de EJB no. Beans de sesin con estado Definen variables de instancia que almacenan datos especficos del cliente. Estos datos se guardan con operaciones denominadas setXXX como setNombre o setDireccion. Se suelen usar para implementar mtodos de negocios que requieren mltiples pasos de ejecucin. El estado del bean dura el tiempo de sesin y no es persistente

Beans de entidad (Entity Beans)

Los beans de entidad representan datos de Negocio. Proporcionan una vista orientada a objetos de una base de datos Una instancia de un bean de entidad corresponde a una fila de una tabla (o de ms de una si estn normalizadas). Los datos del bean se guardan en sus variables de instancia y se leen y escriben en la base de datos cuando el contenedor lo requiere Con persistencia gestionada por el bean (BMP) El programador se encarga de escribir el cdigo que gestiona la actualizacin del bean y de la base de datos Con persistencia gestionada por el contenedor (CMP)

Comenzamos con un JavaBean simple. Esta clase tiene propiedades como definido por el estndar de JavaBeans. Cada establecimiento en el JavaBean se representa al mundo exterior del bean a travs de un par de mtodos de acceso de propiedad. Para cada propiedad, un mtodo get recupera los datos y un mtodo setter le asigna. Los nicos cambios que se necesitaban para aadir la @Entity y las anotaciones @ Id. Estos son los requisitos mnimos de metadatos para transformar esta clase en una entidad.

La anotacion @Entity La anotacin @ Entity es necesario para identificar esta clase como una entidad en el momento de la entidad se ha implementado. Cuando las entidades se utilizan en un archivo de persistencia (archivo JAR), que puede ser acompaado de las clases de no entidad. Esta anotacin, o su equivalente en la declaracin archivo orm.xml, le dice al contenedor para buscar anotaciones ms en la clase, y de otra manera manejar su O / R mappings, que pueda participar en las consultas y relaciones persistentes con otras entidades, y se someten a byte tejido u otros procedimientos cuando son ms instancia por el proveedor de persistencia. Todas las clases que no estn marcados como entidades ignoradas por el contenedor durante la implementacin. La anotacion @Id

La anotacin @ Id indica que el campo (puede haber varios) es el principal entidad clave o identificador. El valor en el campo identificador (o campos) debe ser nico en todas las instancias de la entidad del cliente tipo de entidad de forma que puede identificar a esta entidad. En el caso de que la clave primaria abarca varias columnas en la tabla, uno primario compuesto clave es necesaria, y los campos Id @ podrn ser sustituidos por un nico campo que se anota@ EmbeddedId.

Beans dirigidos por mensajes (Message Driven Beans)

Los message-driven beans son componentes detalladas en EJB 2.0 que pueden recibir y consumir mensajes asncronamente. Un message-driven bean es invocado por el container como resultado de la recepcin de un mensaje enviado por un cliente utilizando Java Message Service (JMS). Un cliente no ejecuta directamente un message-driven bean, si no que slo debe utilizar la API de JMS para enviar mensajes. Por esto, un messagedriven bean no tiene una clase home ni interfaz local o remota ni retorna valores o excepciones al cliente. El cliente no espera que su mensaje sea respondido si no que continan su ejecucin una vez enviado. Los message-driven beans slo reciben mensajes JMS, sin conocer de antemano la informacin sobre contenido del mensaje recibido. Por esta razn slo tienen un mtodo con lgica de negocio llamado onMessage(), que recibe un Message JMS que puede representar todos los tipos de mensajes existentes en JMS como mensajes de bytes, de texto y de objetos serializables. Luego hay que discriminar el tipo de mensaje recibido utilizando el operador instanceOf. Los message-driven beans son stateless ya que no mantienen estados de conversacin entre cada procesamiento de mensajes recibidos, por lo cual las instancias de la misma clase son equivalentes entre s y deben implementar solo un mtodo ejbCreate() sin parmetros.

La API Java Message Service (en espaol servicio de mensajes Java), tambin conocida por sus siglas JMS, es la solucin creada por Sun Microsystems para el uso de colas de mensajes. Este es un estndar de

mensajera que permite a los componentes de aplicaciones basados en la plataforma Java2 crear, enviar, recibir y leer mensajes. Tambin hace posible la comunicacin confiable de manera sncrona y asncrona. El servicio de mensajera instantnea tambin es conocido como Middleware Orientado a Mensajes (MOM por sus siglas en ingls) y es una herramienta universalmente reconocida para la construccin de aplicaciones empresariales. Existen dos modelos de la API JMS, los cuales son: Modelo Punto a Punto (point to point): Este modelo cuenta con solo dos clientes, uno que enva el mensaje y otro que lo recibe. Este modelo asegura la llegada del mensaje ya que si el receptor no esta disponible para aceptar el mensaje o atenderlo, de cualquier forma se le enva el mensaje y este se agrega en una cola del tipo FIFO para luego ser recibido segn haya entrado. Modelo Publicador/Suscriptor (Publish/Subscribe): Este modelo cuenta con varios clientes, unos que publican temas(tpicos) o eventos, y los que ven estos tpicos, a diferencia del modelo punto a punto este modelo tiende a tener ms de un consumidor.

MODELO DE DESARROLLO SIMPLIFICADO

INJECCION DE DEPENDENCIA Inyeccin de Dependencias (en ingls Dependency Injection, DI) es un patrn de diseo orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. La forma habitual de implementar este patrn es mediante un "Contenedor DI" y objetos POJO. El contenedor inyecta a cada objeto los objetos necesarios segn las relaciones plasmadas en un fichero de configuracin. Tpicamente este contenedor es implementado por un framework externo a la aplicacin (como Spring o uno propietario), por lo cual en la aplicacin tambin se utilizar inversin de control al ser el contenedor

(almacenado en una biblioteca) quien invoque el cdigo de la aplicacin. sta es la razn por la que los trminos de inversin de control e inyeccin de dependencias se confunden habitualmente entre s.

CALLBACK METHODS Los mtodos Callback son mtodos del bean (no expuestos en la interfaz) que el contenedor llama para notificar la transicin del ciclo de vida de un bean. Cuando el evento ocurre el contenedor invoca al mtodo callback correspondiente y los mtodos pueden ser utilizados para mejorar rendimiento. Cuando se necesita implementar lgica en alguno o todos los puntos del ciclo de vida de los EJB, se utilizan anotaciones para indicar los mtodos del bean que respondern ante los mismos, los mtodos deben respetar una asignatura particular. Esto resulta en un modelo mucho ms flexible y menos intrusivo

@PostConstruct: invocado luego de creada la instancia del bean y resuelta la inyeccin de dependencias (Stateless, Stateful) @PreDestroy: invocado previa a la eliminacin de la instancia del bean (Stateless, Stateful) @PrePasivate: invocado previo a la pasivacin del bean (Stateful) @PostActivate: invocado luego de la activacin del bean (Stateful)

 @Remove: invocado al momento de destruir la instancia del bean. Finaliza con la vida de un session stateful

POJOS
POJO son las iniciales de "Plain Old Java Object", que puede interpretarse como "Un objeto Java Plano y a la Antigua". Un POJO es una instancia de una clase que no extiende ni implementa nada en especial. Por ejemplo, un Controller de Spring tiene que extender de SimpleFormController, e implementar los mtodos abstractos de ese tipo: por eso, no es un POJO. Un Servlet, tiene que extender de HttpServlet tampoco es un POJO. En cambio, si defines una clase Persona (o la clase EstoEsUnBean que est ms abajo) con atributos y unas cuantas operaciones, tienes un simple y modesto POJO.

MODELO DE COMPUTACION DISTRIBUIDA

Esencial para cualquier aplicacin empresarial es la capacidad para ejecutar tareas y ejecutar componentes por separado en las discusiones de Java o procesos. A travs de la RMI basada en remoto los servicios, los clientes en un cliente de nivel de aplicacin puede acceder a los EJB se ejecuta en un servidor de aplicaciones en cualquier lugar en la red.

EJB Roles La especificacin EJB define siete roles para los individuos involucrados en las diferentes etapas de la definicin. un bean de empresa o entidad, o en la prestacin de los servicios y la ejecucin de la API del EJBs. El proveedor de Enterprise Bean El proveedor de Enterprise Bean, tambin conocido como el proveedor del

bean, tiene la responsabilidad de definicin y aplicacin de la lgica de negocio y la estructura de un bean enterprise. Este incluye la definicin de la clase Java, la aplicacin de los mtodos de servicio, especificando las transacciones y seguridad de la informacin de forma declarativa en el grano y su inyeccin de mtodos, o la bsqueda de de los recursos necesarios, y cualquier cosa que se puede aplicar a la clase enterprise bean.

El ensamblador de la aplicacin El ensamblador de la aplicacin combina EJBs en mdulos EJB y entidades en la persistencia archivos, y luego combina estos mdulos, junto con otros mdulos de Java EE para producir una aplicacin. Esta tarea requiere la resolucin de referencias entre los EJBs y entidades. El ensamblador de la aplicacin debe trabajar con las interfaces y los metadatos definido para el EJB y los componentes de entidad, pero no necesita estar familiarizado con los detalles implementacin.

El Implementador El implementador lleva una aplicacin que ha sido montado por el ensamblador de la aplicacin y que utiliza para un determinado contenedor EJB. El Implementador debe resolver todos los externos dependencias definidas por el componente EJB, los mapas de recursos concretos instalado en el entorno de servidor de aplicaciones.