This is an old revision of the document!
Cada proceso de un servidor de aplicaciones tiene dos contenedores (como weblogic, jboss, websphere). Contenedor web y contenedor ejb En el primero podemos utilizar protocoloes http y https. En el segundo se usa el protocolo rmi
servlets java server pages
struts, jsf, adf (son frameworks del contenedor web) Aquí se despliegan los war
Los jar se despliegan en el contenedor ejb
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) y message driven beans(2) (1) Lógica de negocio reutilizable - 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…)
(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
Distribución basada en componentes, desplegados en diferentes procesos
Cada componente de la aplicación se modela como un servicio independiente, coordinados entre intercambios de mensajes
Cada servicio debe tener las siguiente propiedades:
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.
Estrategias de transición:
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.