SESION 1

Java

La tecnología Java es tanto un lenguaje de programación como una plataforma. El lenguaje

de programación Java es un lenguaje orientado a objetos de alto nivel que tiene una sintaxis
y un estilo particulares. Una plataforma Java es un entorno particular en el que se ejecutan
aplicaciones de lenguaje de programación Java.1

* A partir de Java SE 8 se incluye la programación funcional.

Plataformas del lenguaje Java

Hay cuatro plataformas del lenguaje de programación Java:

 Standar Edition (Java SE).

 Enterprise Edition (Java EE).
 Micro Edition (Java ME).
 JavaFx.

Java SE

Cuando la mayoría de la gente piensa en el lenguaje de programación Java, piensa en la API

de Java SE. La API de Java SE proporciona la funcionalidad principal del lenguaje de
programación Java. Define todo, desde los tipos y objetos básicos del lenguaje de
programación Java hasta las clases de alto nivel que se utilizan para redes, seguridad,
acceso a bases de datos, desarrollo de interfaz gráfica de usuario (GUI) y análisis de XML.

Java EE

La plataforma Java EE está construida sobre la plataforma Java SE. La plataforma Java EE
proporciona una API y un entorno de tiempo de ejecución para desarrollar y ejecutar
aplicaciones de red seguras, escalables, confiables y de múltiples niveles.

Está orientada a aplicaciones basadas en la Web.2

EJB

Enterprise Java Beans: Es un componente de negocio Java Enterprise, y para su ejecución

necesita un contenedor EJB/JEE (JBoss, WAS, OAS, etc). El hecho de usar EJB’s te da acceso
a los servicios del Contenedor EJB (manejo de transacciones, seguridad ,persistencia, etc)
que simplifican bastante la construcción de soluciones empresariales.

Con la tecnología JEE Enterprise Java Beans es posible desarrollar componentes (Enterprise
beans) que luego puedes reutilizar y ensamblar en distintas aplicaciones que tengas que
hacer para la empresa.

El contenedor EJB es algo así como el sistema operativo en el que éstos residen.

Cuando estés trabajando con componentes tendrás que dedicarle tanta atención al
despliegue (deployment) del componente como a su desarrollo. Entendemos por despliegue
la incorporación del componente a nuestro contenedor EJB y a nuestro entorno de trabajo
(bases de datos, arquitectura de la aplicación, etc.). El despliegue se define de forma
declarativa, mediante un fichero XML (descriptor del despliegue, deployment descriptor) en
el que se definen todas las características del bean. 3

1
Extraído de https://docs.oracle.com/javaee/6/firstcup/doc/gkhoy.html
2
Extraído del libro ¿Cómo programar? Autor Deitel Paul, Deitel Harvey Décima Edición
3
Extraído de http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-2003-2004/ejb/sesion01-
apuntes.htm
Enterprise JavaBeans (EJB) es una arquitectura de componentes de servidor que simplifica el
proceso de construcción de aplicaciones de componentes empresariales distribuidos en java.

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.
Debido a que el contenedor de aplicaciones libera al programador de realizar las
tareas del nivel del sistema, la escritura de un enterprise bean es casi tan sencilla
como la escritura de una clase Java. El desarrollador no tiene que preocuparse de
temas de nivel de sistema como la seguridad, transacciones, multi-threading o la
programación distribuida. Como resultado, el desarrollador de aplicaciones se
concentra en la lógica de negocio y en el dominio específico de la aplicación.

3. Son reusables.
Una aplicación EJB está formada por componentes enterprise beans. Cada enterprise
bean es un bloque de construcción reusable. Hay dos formas esenciales de reusar un
enterprise bean a nivel de desarrollo y a nivel de aplicación cliente. Un bean
desarrollado puede desplegarse en distintas aplicaciones, adaptando sus
características a las necesidades de las mismas. También un bean desplegado puede
ser usado por múltiples aplicaciones cliente.

4. Se pueden adaptar y configurar en el despliegue.

A diferencia del uso de anotaciones al utilizar el archivo de despliegue xml se puede
realizar modificaciones en dicho archivo y actualizar el despliegue sin tener que
volver a compilar.

5. Portabilidad de la aplicación. Una aplicación EJB puede ser desplegada en cualquier

servidor de aplicaciones que soporte J2EE.

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).

El contenedor EJB proporciona varios servicios:

- Gestión de la persistencia
- Mensajería asíncrona
- Seguridad de acceso
- Gestión de transacciones
- Balanceo de carga

Existen tres tipos de EJB : Entity Beans, Session Beans y Message-driven Beans.

Entity Beans:

Los Entity Beans representan entidades de negocio y proveen acceso a datos a través de
métodos. Se basan en la idea del mapeo objeto/relacional (ORM). Son de dos tipos: BMP
(Bean Managed Persistence) donde se delega las tareas de persistir, buscar y recuperar
entidades y CMP (Container Managed Persistence) donde la persistencia la gestiona el
contenedor de forma en el que el desarrollador no se preocupa de las sentencias SQL de
inserción, recuperación, etc.

En EJB 3.0, los beans de entidad fueron reemplazados por la API de persistencia de Java
(que posteriormente se separó por completo a su propia especificación a partir de EJB 3.1).
Los Entity Beans se han marcado como candidatos para poda a partir de Java EE 6 [1] [2] y,
por lo tanto, se consideran una tecnología obsoleta

Session Beans:
Los Session Beans gestionan la lógica de negocio para un cliente. Son de dos tipos: Stateless
Session Beans no mantienen el estado entre invocaciones y Stateful Session Beans guardan
el estado entre invocaciones de un mismo cliente. Ejemplo: Un usuario ingresa a una compra
virtual, su estancia durante la aplicación puede durar entre un y varios minutos, un EJB de
tipo sesión stateful permite guardar el estado del EJB durante toda la estadia del cliente, sin
embargo, un EJB de tipo sesión stateless solo estaria activo por cada invocación de selección
de un articulo.

Un carrito de compras por ejemplo utiliza Stateful Session Beans para mantener el estado
entre invocaciones.

Message-driven Beans:
Permiten modelar la lógica de negocio mediante colas JMS. 4
Un Message-Driven Bean o MDB (EJB dirigido por mensajes) es un oyente de mensajes que
puede consumir mensajes de una cola. Dichos mensajes pueden ser enviados por cualquier
componente JavaEE (cliente, otro EJB o una componente Web como un servlet).
Conceptualmente se diseñaron para que el servidor de aplicaciones proporcione facilidades
de multi-threading, esto es que múltiples consumidores procesen mensajes
concurrentemente sin necesidad de desarrollar código adicional.
Así, los MDBs proporcionan dicha facilidad al manejar los mensajes entrantes mediante
múltiples instancias de beans alojados en el pool del servidor de aplicaciones.

MDB se basa en un método onMessage que se invoca automáticamente a la llegada de un

mensaje. Estos componentes en el contenedor EJB realiza automáticamente varias tareas de
inicialización que implementamos a mano del cliente, como:

- Crear un consumidor asíncrono para recibir el mensaje. En vez de crear el

consumidor en el código fuente, con un MDB asociamos el destino y la factoría de
conexiones durante el despliegue.
- Registrar el listener de mensajes. El MDB registra el listener automáticamente sin
que haya que codificar una llamada a setMessageListener.

Un Message-Driven Bean usa la anotación @MessageDriven para especificar las propiedades

del bean o de la factoría de conexión, tales como el tipo de destino, la suscripción duradera,
selector de mensajes o el modo de acuse de recibo.

Con respecto a otros EJBs, la diferencia fundamental con cualquier otro EJB es que el MDB
no tiene interface local o remota. Solo la clase bean. Se parece a un Stateless Session Bean
(SSB) porque sus instancias son short-lived y no retienen estado para un cliente específico.
Pero sus variables pueden contener información de estado entre los diferentes mensajes de
cliente: por ejemplo, un conexión a una base de datos, o una referencia a un EJB, etc..

Middleware Orientado a Mensajes

JMS

JMS es la solución de Sun para los sistemas de mensajes, empecemos por saber que es un
sistema de mensajes empresarial:

En las comunicaciones cliente servidor, los datos que se intercambian entre las dos partes
necesitan de una comunicación sincrona, es decir, que las dos partes esten presentes en el
momento de la comunicación. Los sistemas de mensajes aportan una serie de mejoras a la
comunicación entre aplicaciones que no tienen por que residir en la misma máquina.

JMS se situa como middleware en medio de la comunicación de dos aplicaciones. En entornos

cliente servidor, cuando la aplicación A quiere comunicarse con la Aplicación B, necesita
saber donde esta B (su IP por ejemplo) y que B esté escuchando en ese momento. Cuando
4
Extraído de http://oraclejuniors.blogspot.com/2014/10/que-son-los-ejb-enterprise-javabeans.html
se usa JMS (o cualquier otro sistema de mensajes), la aplicación A envía un mensaje, el
sistema de mensajes lo recibe y se lo envía a B cuando se conecte al servicio. De esta
manera se consigue una comunicación asíncrona entre A y B, es decir no hace falta que B
este presente en el momento del envío del mensaje, y no por ello va a dejar de recibirlo.

La anterior es una de las ventajas de JMS, pero no la única. La comunicación anterior tiene
dos extremos, el productor (A) y el consumidor (B). JMS soporta otro tipo de comunicaciones
que Sun denomina Publisher/Subscriber, traducido seria Publicador (Publicante)/Suscriptor.
En este tipo de comunicación, la aplicación A publica su mensaje en el servicio JMS y lo
reciben todas las aplicaciones que esten suscritas al servicio JMS al que se envió el mensaje,
esta forma de comunicación es exactamente igual que la que se produce el los chats del IRC.

Otra de las ventajas de usar JMS (o cualquier otro sistema de mensajes) es que las
aplicaciones se pueden cambiar simplemente asegurándose que la nueva aplicación entiende
los mensajes que se intercambian.

Arquitectura de JMS

Una aplicación JMS consta de los siguientes elementos:

Clientes JMS Aplicaciones que envian o reciben mensajes a través de JMS

Mensajes Los mensajes que se intercambian

Objetos administrados Los objetos JMS a los que se dirigen las comunicaciones

Objetos administrados

Los objetos administrados son el punto al que se comunican los clientes JMS para enviar o
recibir mensajes, se denominan objetos administrados por que los crea el administrador (en
la implementación de referencia mediante j2eeadmin). Implementan las interfaces JMS y se
sitúan en el espacio de nombres de JNDI (Java Naming and Directory Interface) para que los
clientes puedan solicitarlos.

Hay dos tipos de objetos administrados en JMS:

ConnectionFactory: Se usa para crear una conexión al proveedor del sistema de mensajes.

Destination: Son los destinos de los mensajes que se envían y el recipiente de los mensajes
que se reciben.

Mensajes

Es el corazón del sistema de mensajes. Estan formados por tres elementos:

Header: Es la cabecera del mensaje, contiene una serie de campos que le sirven a los
clientes y proveedores a identificar a los mensajes. Aquí tines la lista de campos completa :

Campo Tipo de Dato Descripcion

JMSMessageID String Un numero que identifica univocamente al mensaje. Solo se puede

consultar una vez que esta enviado el mensaje.

JMSDestination Destination El destino a donde se envia el mensaje.

JMSDeliveryMode int Puede ser de tipo PERSISTENT, entonces se envia una unica
vez, o de tipo NON_PERSISTEN, de manera que se envia como mucho una vez, lo cual
incluye tambien que no sea enviado nunca. PERSISTENT y NON_PERSISTENT estan definidas
como constantes.
JMSTimestamp long Pues eso, la hora a la que se envio el mensaje.

JMSExpiration long La hora hasta la cual el mensaje es valido, si es 0 quiere decir que no
caduca nunca.

JMSPriority int Prioridad del mensaje de 0 a 9, siendo 0 la mas baja.

JMSCorrelationID String Este campo se usa para relaccionar una respuesta a un

mensaje, se copia aqui el id de mensaje del mensaje al que se esta respondiendo.

JMSReplyTo Destination Especifica el lugar a donde se deben enviar las respuestas al

mensaje actual.

JMSType String Este campo lo puede usar el programa de mensajeria para almacenar
el tipo del mensaje.

JMSRedelivered boolean Indica que el mensaje ha sido enviado con

anterioridad pero el destino no lo ha procesado, por lo que se reenvia.

Properties: Son propiedades personalizadas para un mensaje en particular. Aquí tienes la

lista completa:

Propiedad Tipo de Dato Descripcion

JMSXUserID String El usuario que envia el mensaje.

JMSXApplID String La aplicacion que envia el mensaje.

JMSXDeliveryCount int El numero de veces que se ha intentado enviar el mensaje

JMSXGroupID String Identificador del grupo al que pertenece el mensaje.

JMSXGroupSeq int Numero de secuencia en el grupo de mensajes.

JMSXRcvTimestamp long La hora a la que JMS le entrego el mensaje al/los

destinatario/s.

JMSXState int Para uso del proveedor de mensajeria.

JMSX_<nombre_del_proveedor> - Reservado para propiedades particulares del

proveedor.

Body: Es el mensaje en si, hay distintos tipos:

StreamMessage: Contiene un stream de datos que se escriben y leen de manera secuencial.

MapMessage: Contiene pares nombre-valor.

TextMessage: Contiene un String.

ObjectMessage: Contiene un objeto que implemente la interfaz Serializable.

BytesMessage: Contiene un stream de bytes.

Dominios de mensajería
Existen dos modelos/dominios de mensajería:

 Punto a Punto (PTP), en la que un mensaje se consume por un único

consumidor.
 Publicación/Subscripción (Pub/Sub), en la que un mensaje se consume por
muchos consumidores.
Destacar que no todos los proveedores implementan ambos. Posteriormente veremos
como JMS ofrece diferentes APIs para estos dos modelos.

Punto a Punto
Como hemos mencionado, bajo el modelo PTP, un mensaje se consume por un único
consumidor (1:1), pero pueden haber varios emisores. El destino del mensaje es
un cola definida y con un nombre (de manera opuesta a un tópico bajo el modelo Pub/Sub).
Dicho de otra manera, se trata de un modelo FIFO, en el cual el mensaje encolado será el
primero en salir de la cola (suponiendo que tienen el mismo nivel de prioridad).

Así pues, bajo el modelo punto a punto, el emisor envía un mensaje a una cola definida (con
nombre) con un nivel de prioridad, y el receptor extrae el mensaje de la cola. Al extraer el
mensaje, el receptor envía un acuse de recibo a la cola para confirmar su correcta recepción
(ACK).

Una aplicación PTP se construye bajo el concepto de colas de mensajes, productores y

consumidores. A los emisores se les conoce como productores, y a los receptores como
consumidores. Cada mensaje se envía a una cola específica, y los consumidores extraen los
mensajes de la(s) cola(s) definidas. Estas colas retienen todos los mensajes enviados hasta
que son consumidos o hasta que expiren.

¿Por qué utilizar MDB?

Por las siguientes características:

- Multihilo: Pueden procesar mensajes de forma concurrente. Gestionan los mensajes

entrantes mediante múltiples instancias de beans (dentro de un pool), y tan pronto
como un nuevo mensaje llega al destino, una instancia de MDB sale del pool para
manejar el mensaje.
 - Código de mensajería simplificado
Los MDBs evitan la necesidad de codificar los aspectos mecánicos asociados al
procesamiento de mensajes (como buscar las factorías de conexiones o los destinos,
crear las conexiones, abrir sesiones, crear consumidores y adjuntar listeners).
Mediante EJB 3, el uso de situaciones por defecto para las circunstancias más
comunes elimina gran parte de la configuración. En el peor caso, tendremos que
ofrecer la información de configuración via anotaciones o mediante el descriptor de
despliegue

- Reglas de programación:
Los MDB son POJOs que siguen un conjunto de reglas y que en ocasiones tienen
anotaciones:

1. La clase MDB debe directamente (mediante la palabra clave implements en la

declaración de la clase) o indirectamente (mediante anotaciones o descriptores)
implementar una interfaz de listener de mensajes.
2. La clase MDB debe ser concreta, ni abstracta ni final.
3. La clase MDB debe ser un POJO y no una subclase de otro MDB.
4. La clase MDB debe declararse pública.
5. El constructor de la clase MDB no debe tener argumentos. Si no se tiene un
constructor, el compilador implementará un constructor por defecto. El
contenedor usa ese constructor para crear instancias de MDBs.
6. No se puede definir un método finalize. Si es necesario algun código de limpieza,
se debería definir un método designado como PreDestroy.
7. Los MDBs deben implementar los métodos de la interfaz MessageListener y estos
métodos deben ser públicos, nunca estáticos o finales.
8. Está prohibido lanzar javax.rmi.RemoteException o cualquier excepción de
ejecución. Si se lanza un RuntimeException, la instancia MDB finalizará.

Mejores prácticas

- Modulariza: La lógica no debe ser incluida dentro de los métodos del listener de
mensajes. La lógica de negocio debe estar modularizada y desacoplada de los
aspectos específicos de la mensajería.
- Elige el tipo de mensaje con cuidado: La elección del tipo de mensaje no siempre es
tan obvia como puede parecer. Se podría utilizar tipo texto XML esto conlleva que el
acoplamiento entre sistemas sea débil, si se utiliza un objeto XML estaremos
obligados a que conozcan dicho objeto.
- Cuidado con los mensajes venenosos: Un mensaje venenoso es un mensaje que
recibe el MDB para el cual no está preparado. Por ej. Nuestro MDB está desarrollado
para recibir un objectMessage y recibimos texto XML.

T3 es un protocolo optimizado usado para transportar datos entre el servidor

WebLogic y otros programas Java, incluyendo clientes y otros servidores WebLogic.
El servidor WebLogic no pierde l apista de cada máquina virtual Java (JVM) con que
conecta, y crea una sola conexión T3 para llevar todo el tráfico con una JVM.
 Por ejemplo, si un cliente Java tiene acceso a un bean enterprise y a un almacen de
conexiones JDBC en el servidor WebLogic, se establece una sola conexión de red
entre el servidor WebLogic y la JVM del cliente. Los servicios de EJB y de JDBC
pueden ser escritos como si tuvieran uso único de una conexión de red dedicada
porque el protocolo T3 multiplexa invisiblemente los paquetes en la sola conexión. T3
es un protocolo eficiente para las aplicaciones Java-a-Java porque evita eventos
innecesarios de conexión a red y utiliza pocos recursos del SO. El protocolo también
tiene mejoras internas que reducen al mínimo el tamaño de los paquetes

Vamos a la práctica

Concepto de MDB: http://www.jtech.ua.es/j2ee/publico/mens-2010-11/sesion04-

apuntes.html

http://www.jtech.ua.es/j2ee/2004-2005/modulos/ejb/apendice01-apuntes.htm

https://www.ibm.com/support/knowledgecenter/es/SSEQTP_9.0.5/com.ibm.websphere.base
.doc/ae/tejb_mdb.html

Protocolo T3:

https://programacion.net/articulo/bea_weblogic_introduccion_129/5#:~:text=El
%20contenedor%20EJB%20de%20WebLogic,y%20beans%20dirigidos%20por%20mensajes.

JMS:

https://www.oscarblancarteblog.com/2014/07/25/java-message-service-jms/

Introducción a JMS
Universidad Politécnica de Valencia
https://www.youtube.com/watch?v=fUxy-hSHXoU
SESION 2

Diferencia entre ejb-jar.xml y weblogic-ejb-jar.xml

El archivo ejb-jar.xml describe la información estructural sobre todos los enterprise beans
incluidos en ese paquete y sus relaciones. Su descripción se puede aplicar a cualquier
servidor de aplicaciones JEE.

El archivo “weblogic-ejb-jar.xml” describe los elementos EJB que son exclusivos de WebLogic
Server.

¿Por qué usar EJB con Spring Framework?

Hay muchas razones para usar tanto EJB 3 como Spring. Los EJB tienen beneficios que
Spring no brinda: integración con cosas como Servlets y etiquetas JSP, mejor integración con
el contenedor para monitoreo y administración, soporte de herramientas, etc. Spring
también tiene beneficios; en particular, no necesita el contenedor, pero también obtiene más
control sobre el ciclo de vida del bean. Juntos son un buen complemento.