JAR (Java Archive)

Empaquetamiento en formato zip de un conjunto de clases

La estructura interna del fichero JAR

Ademas de esta carpeta con los paquetes nos encontramos con la carpeta META-INF que incluye el
fichero de Manifiesto (MANIFEST.MF) .Este fichero nos aporta información adicional sobre
nuestro fichero JAR. Uno de sus usos mas habituales es definir que clase de todas las que tenemos
ubicadas en el JAR es la clase que se debe ejecutar como programa principal.
Manifest-Version: 1.0
Main-Class: com.arquitecturajava.Principal
Estas lineas declaradas en el fichero de Manifiesto permitirá que cuando invoquemos en linea de
comandos el siguiente comando
java -jar milibreria.jar
Se ejecute el código de la clase Principal
WAR (Web Archive)

Assembly Root: Esta es la carpeta principal de la aplicación dentro de la cual todos los elementos
se ubican . Se denomina así porque normalmente cuando el WAR es descomprimido es cuando se
decide el nombre final de la carpeta por ejemplo Aplicacion1. Como carpeta principal se encarga
habitualmente de almacenar ficheros de tipo JSP ,HTML ,CSS y JS.
WEB-INF : Esta carpeta es obligatoria en la aplicación y se encarga de almacenar las carpetas de
lib y clases junto con el fichero de descriptor de despliegue conocido por todos como “web.xml”
lib : Esta carpeta se encarga de almacenar todos los ficheros JAR que nuestra aplicación necesita.
classes: Esta carpeta se encarga de almacenar todas las clases que tenga nuestra aplicación.
web.xml : Es el fichero de configuración de la aplicación en donde configuramos variables globales
,servlets filtros etc . Ojo hasta la version 2.5 era un fichero obligatorio y sin el la aplicación no era
capaz de arrancar . A partir de la versión 3.0 debido al uso de anotaciones pasa a ser opcional.
META-INF: Carpeta donde se ubican los ficheros de metadatos. En esta carpeta pueden ir ubicados
ficheros como persistence.xml que se encarga de configurar JPA .
MANIFEST.MF: Ver JAR.
Java Bean
Simplemente es un estándar o unas normas a seguir para crear una nueva clase, creado por Sun
Microsystems. Ellos mismos definen un JavaBean como un componente software reutilizable que
se puede manipular visualmente en una herramienta de construcción.

Un JavaBean debe cumplir las siguientes características para ser considerado como tal y conseguir
que sean realmente componentes reutilizables:
1. Debe implementar la interfaz Serializable o la interfaz Externalizable. Se suelen usar para
encapsular varios objetos en uno, de manera que implementando alguna de estas interfaces
se puede guardar el estado de cada objeto.
2. Debe tener un constructor vacío, sin argumentos, para instanciar un nuevo objeto de manera
estándar.
3. Todas las variables de la instancia deben ser privadas.
4. Debe implementar los getters y setters de las variables o propiedades, los cuales serán
públicos y son los que se utilizarán para acceder o actualizar las variables privadas.
Ejemplo sencillo con la estructura típica de un JavaBean:

Las anotaciones (@Entity, @Id) son opcionales

EJB (Enterprise Java Beans)
Las Enterprise JavaBeans son una de las interfaces de programación de aplicaciones (API) que
forman parte del estándar de construcción de aplicaciones empresariales J2EE (ahora JEE).
Los EJB proporcionan un modelo de componentes distribuido estándar del lado del servidor. El
objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los
problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia,
seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar
basado en componentes permite que éstos sean flexibles y sobre todo reutilizables.

Los EJB:
1. Se ejecutan en un contenedor EJB (en un servidor de aplicaciones).
2. Implementan la lógica de negocio de la aplicación.
3. Son reusables.
4. Se pueden adaptar y configurar en el despliegue. 
5. Son accedidos por medio de una interfaz. 
6. Su localización es generada por el Java Naming and Directory Interface (JNDI). 
7. Pueden ser accedidos remotamente por medio de Java Remote Method Invocation (RMI). 

Arquitectura básica de EJB2

Los EJB se disponen en un contenedor EJB dentro del servidor de aplicaciones. Cada EJB debe
facilitar una clase de implementación Java y dos interfaces Java.
Las interfaces Java son utilizadas por el código cliente del EJB. Las dos interfaces, conocidas como
interfaz "home" e interfaz remota, especifican las firmas de los métodos remotos del EJB. Los
métodos remotos se dividen en dos grupos:
 • Métodos que no están ligados a una instancia específica, por ejemplo aquellos utilizados
para crear una instancia EJB o para encontrar una entidad EJB existente. Estos métodos se
declaran en la interfaz "home".
• Métodos ligados a una instancia específica. Se ubican en la interfaz remota.

Las clases de implementación EJB las suministran los desarrolladores de aplicaciones, que facilitan
la lógica de negocio ("business logic") o mantienen los datos ("business data") de la interfaz de
objeto, esto es, implementan todos los métodos especificados por la interfaz remota y,
posiblemente, algunos de los especificados por la interfaz "home".

Existen tres tipos de EJB:

1. EJB de Entidad (Entity EJB): su objetivo es encapsular los objetos del lado del servidor
que almacena los datos. Los EJB de entidad presentan la característica fundamental de la
persistencia: (nota: en la documentación de Java para JEE 5.0, los entity beans desaparecen,
porque son remplazados por Java Persistence API o JPA)
◦ Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de
almacenar y recuperar los datos del objeto de entidad mediante el mapeo o vinculación
de las columnas de una tabla de la base de datos con los atributos del objeto.
◦ Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga,
mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los
que se refiere, por lo cual la responsabilidad de implementar los mecanismos de
persistencia es del programador.
2. EJB de Sesión (Session EJB): gestionan el flujo de la información en el servidor.
Generalmente sirven a los clientes como una fachada de los servicios proporcionados por
otros componentes disponibles en el servidor. Puede haber dos tipos:
◦ Con estado (stateful): en un bean de sesión con estado, las variables de instancia del
bean almacenan datos específicos obtenidos durante la conexión con el cliente. Cada
bean de sesión con estado, por tanto, almacena el estado conversacional de un cliente
que interactúa con el bean. Este estado conversacional se modifica conforme el cliente
va realizando llamadas a los métodos de negocio del bean. El estado conversacional no
se guarda cuando el cliente termina la sesión.
◦ Sin estado (stateless): los beans de sesión sin estado son objetos distribuidos que
carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente.
No se garantiza que los contenidos de las variables de instancia se conserven entre
llamadas al método.
3. EJB Dirigidos por Mensajes (Message-driven EJB): son los únicos beans con
funcionamiento asíncrono. Usando el Java Messaging System (JMS), se suscriben a un tema
(topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola.
No requieren de su instanciación por parte del cliente.
EJB 3.1
Es la última especificación del EJB, incluida en JavaEE 6 de diciembre del 2009.
JavaEE 6 provee diversas API's para la construcción de aplicaciones empresariales, entre ellas EJB,
JPA, JMS, y JAX-WS. Cada una de ellas se centra en un área específica, resolviendo así problemas
concretos. Además, cada API/especificación está preparada para funcionar en compañía de las
demás de forma nativa.
Desde la versión 3.0, EJB no impone ninguna restricción ni obligación a nuestros objetos de
negocio de implementar una API en concreto. Dicho de otro modo, podemos escribir dichos objetos
de negocio usando POJO's, facilitando entre otras cosas la reutilización de componentes y la tarea
de testearlos.
Una vez que un POJO definido como EJB haya sido desplegado en el contenedor, se convertirá en
uno de los tres siguientes componentes (dependiendo del como lo hayamos definido):
• Session Bean
• Message-Driven Bean
• Entity Bean

Session Bean
Los componentes Session Beans (Beans de Sesión) son los componentes que contienen la lógica de
negocio que requieren los clientes de nuestra aplicación. Son accedidos a través de un proxy
(también llamado vista, término que utilizaré en adelante) tras realizar una solicitud al contenedor.
Tras dicha solicitud, el cliente obtiene una vista del Session Bean, pero no el Session Bean real.
Esto permite al contenedor realizar ciertas operaciones sobre el Session Bean real de forma
transparente para el cliente (como gestionar su ciclo de vida, solicitar una instancia a otro
contenedor trabajando en paralelo, etc).
Los componentes Session Bean pueden ser de tres tipos:
• Stateless Session Beans
• Stateful Session Beans
• Singletons

Los componentes Stateless Session Beans (Beans de Sesión sin Estado, a partir de ahora SLSB) son
componentes que no requieren mantener un estado entre diferentes invocaciones. Un cliente debe
asumir que diferentes solicitudes al contenedor de un mismo SLSB pueden devolver vistas a objetos
diferentes. Dicho de otra manera, un SLSB puede ser compartido (y probablemente lo será) entre
varios clientes. Por todo esto, los SLSB son creados y destruidos a discreción del contenedor, y
puesto que no mantienen estado son muy eficientes a nivel de uso de memoria y recursos en el
servidor.
Los componentes Stateful Session Beans (Beans de Sesión con Estado, a partir de ahora SFSB), al
contrario que SLSB, si que mantienen estado entre distintas invocaciones realizadas por el mismo
cliente. Esto permite crear un estado conversacional (como el carrito de la compra en una tienda
online, que mantiene los objetos que hemos añadido mientras navegamos por las diferentes
páginas), de manera que acciones llevadas a cabo en invocaciones anteriores son tenidas en cuenta
en acciones posteriores. Un SFSB es creado justo antes de la primera invocación de un cliente,
mantenido ligado a ese cliente, y destruido cuando el cliente invoque un método en el SFSB que
esté marcado como finalizador (también puede ser destruido por timeout de sesión). Son menos
eficientes a nivel de uso de memoria y recursos en el servidor que los SLSB.
Los componentes Singleton son un nuevo tipo de Session Bean introducido en EJB 3.1. Un
Singleton es un componente que puede ser compartido por muchos clientes, de manera que una y
solo una instancia es creada. A nivel de eficiencia en uso de memoria y recursos son
indiscutíblemente los mejores, aunque su uso está restringido a resolver ciertos problemas muy
específicos.

Los EJB de sesión disponen de dos proxies (intermediarios) a través de los cuales accedemos a ellos
:

• Proxy Local : Es el intermediario que nos permite un acceso al EJB desde la misma
maquina virtual.
• Proxy Remoto :Es el intermediario que nos permite el acceso al EJB desde una maquina
virtual remota.
Estos proxies son los encargados de dar acceso al EJB a todos los servicios adicionales que soporta
el EJB Container como son Transaccionalidad, Seguridad etc. Para construir un EJB de Sesión
deberemos definir los interfaces de acceso local y remoto en los cuales los proxies se apoyarán.
Cada uno de estos interfaces se encarga de definir los métodos que estarán a disposición de los
clientes que los invocan.

Message-Driven Beans
Los componentes Message-Driven Beans (Beans Dirigidos por Mensajes, a partir de ahora MDB)
son componentes de tipo listener que actúan de forma asíncrona. Su misión es la de consumir
mensajes (por ejemplo eventos que se producen en la aplicación), los cuales pueden gestionar
directamente o enviar (derivar) a otro componente. Los MDB actuan sobre un proveedor de
mensajería, por ejemplo Java Messaging System (JMS es además soportado de forma implícita por
la especificacion EJB).
Al igual que los Stateless Session Beans, los Message-Driven Beans no mantienen estado entre
invocaciones.

Entity Beans
Los componentes Entity Beans (Beans de Entidad, a partir de ahora EB) son representaciones de
información (en forma de POJO's) que es almacenada en una base de datos. El encargado de
gestionar los EB es EntityManager, un servicio que es suministrado por el contenedor y que está
incluido en la especificación Java Persistence API (JPA - API de Persistencia en Java). JPA es parte
de EJB desde la versión 3.0 de esta última.
Al contrario que los Session Beans y los Message-Driven Beans, los Entity Beans no son
componentes del lado del servidor. En otras palabras, no trabajamos con una vista del componente,
si no con el componente real.
EAR (Enterprise Archive)
Este tipo de ficheros son desplegables en servidores de aplicaciones que soporten el stack completo
de JEE. Es decir contengan tanto un servlet container como un EJB Container.

Un EAR es capaz de albergar varios ficheros WAR cada uno de los cuales contiene una aplicación
web completa.
Aparte de albergar varias aplicaciones web también tiene la capacidad de contener EJBs que son
empaquetados en archivos JAR para su utilización en las distintas aplicaciones web.

Aparte de estos ficheros disponemos de la carpeta lib para almacenar JARs que contenga clases que
sean utilizadas o por los EJBS o por las aplicaciones web que tenemos empaquetadas.

Los EAR disponen del fichero application.xml (directorio META-INF) que define la estructura de
módulos incluidos en este tipo de empaquetamiento .Vamos a ver un ejemplo sencillo.
Como podemos ver nuestro Enterprise Archive esta compuesto de un módulo de EJB (EJB.jar) y un
módulo Web (Web01.war).