Cada proceso de un servidor de aplicaciones tiene dos contenedores (como weblogic, jboss, websphere):

• 1.- Contenedor web
  • Se pueden utilizar protocolos http y https
  • Se usan servlets, java server pages, struts, jsf, adf (frameworks del contenedor web)
  • Se despliegan los war
• 2.- Contenedor ejb
  • Se usa el protocolo rmi
  • Se despliegan los jar

Un ear es un compendio entre un war y un jar para poder desempaquetarlos juntos.

Se pueden hacer servlets basados en otros protocolos como ftp. Todos heredan de httpservlet (o el que corresponda).

Los jsp se pasan a java y luego se compilan como si fuera otro servlet.

Los controladores son servlets, y las vistas son jsp o jspx, facelet (no se permite utilizar java)

Tomcat únicamente implementa los contenedores web, no implementan los ejb. Existe TomEE que incorpora el contenedor de ejb

EJB:

• Session beans(1)
  • Lógica de negocio reutilizable
  • Pueden ser:
    • - Stateless (no se recuerda otras peticiones ni dos hilos de ejecución a dos métodos en el mismo objeto)
    • - Stateful (recuerda las peticiones y pertenece a cada cliente)
    • - Singleton (todos los usuarios de la app reciben la referencia de la misma instancia. Puede haber varios usuarios accediendo a la vez)

Para el patrón “session facade” se utilizan beans del tipo stateless

Una aplicación enterprise (corporativa) permite el acceso al modelo (ejb) por más d eun interfaz (web, aplicación de escritorio…)

• message driven beans(2)

(2) jms ⇒ servicios de mensajería de java. Se separan completamente productores de consumidores, permitiendo un modelo de comunicación asíncrono @MessageDriven

Dentro de los servidores de aplicaciones se implementa un servicio de nombres(jndi). Se asocian con una clave

Si está empaquetado en un paquete, totalmente acoplada es monolítica. La capa de interfaz de usuario y de acceso a datos está acopladas en una misma plataforma y programa. La comunicación es local y es más rápida que en la versión distribuida. La aplicación resultante es independiente, pero sus componentes tienen un acoplamiento muy fuerte.

Separación de los componentes volátiles de los estables.

Capa de presentación: Servlets, jsp, struts Capa de negocio: ejbs Capa de integración: dao o jpa

• El tamaño de la aplicación dificulta su comprensión
• Cualquier cambio en el software hace falta una nueva versión
• Es difícil de escalar
• El despliegue es complejo

Distribución basada en componentes, desplegados en diferentes procesos

• Necesaria la transparencia de ubicación
• Concurrencia soportada por la arquitectura
• Compartición de recursos
• La comunicación entre componentes es remota (implica más lentitud)
• Se requiere un sistema de llamadas estables
• En el modelo SOAP con cada cambio implica recompilar y cambiar los clientes
• En el modelo REST pueden coexistir diferentes versiones del servicio al mismo tiempo

Cada componente de la aplicación se modela como un servicio independiente, coordinados entre intercambios de mensajes

Cada servicio debe tener las siguiente propiedades:

• Cada servicio debe representar una actividad de negocio
• Los servicios no tienen estado
• Tienen bajo acoplamiento
• Todo se orquesta mediante Enterprise Service Bus (está centralizado) o Service Mesh (está distribuído).
• Hay pocas llamadas que retornan mucha información.
• Los cambios de versión afectan al sistema (está pensado para SOAP)

Enfoque para llevar aplicaciones a gran escala. Crea infraestructuras más flexibles y adaptables. Cada microservicio se puede utilizar en su propio proceso y con su propia base de datos.

• Hay muchas llamadas con poca información
• Se utiliza REST.
• Diferentes versiones del servicio pueden coexistir
• La traza de logs se debería centralizar en un solo repositorio

• Proporciona una infraestructura enfocada en la innovación continua y agilidad
• Es posible recomponer servicios
• Cada microservicio puede ser tecnológicamente independiente
• Existen estándares como RAML (RestFUl API Modeling Language)
  • Service to service: Mediante HTTP, TCP, gRPC
  • Comunicación asíncrona: Mediante eventos (Apache kafka, RabiitMQ, AWS…)

Estrategias de transición:

• Ice cream scoop: ir dando cucharadas a la aplicación monolítica y pasarla a microservicios. Es fundamental la rotación entre el equipo y es lento
• Lego: capa de microservicios por encima del monolito. El problema es que el monolito tiene que seguir coexistiendo con el resto del código
• Nuclear option: Reescribir la aplicación completamente.

Se prefiere empezar con una versión monolítica y a partir de ahí separar en microservicios. La capa de acceso a datos también deberá desacoplarse. Cada microservicio debería tener su propio repositorio de datos. Un servicio como Apache Kafka puede propagar los cambios. Cada microservicio es accesible mediante un API, y son agnósticos a cómo son implementados internamente.