3.0 Servidores de Tecnología JEE

37
Servidores de Tecnología JEE Tipos de servidores Como cada servidor afecta las cualidades sistemáticas del entorno de las aplicaciones

description

hh

Transcript of 3.0 Servidores de Tecnología JEE

Servidores de Tecnología JEE

Tipos de servidores

Como cada servidor afecta las cualidades sistemáticas del entorno de las aplicaciones

Tipos de Servidores

• Los servidores son elementos fundamentales de un sistema de tecnología JEE.

• Típicamente la tecnología JEE esta compuesta por los siguientes sistemas

– Web Server – Maneja los requerimientos– Aplication Server – Provee servicios de software– Resourse Server - Permite la integración de sistemas

flexibles, acceso a datos fiables, y el uso seguro

Web Servers

• La función original, fue la de un simple servidor de páginas estáticas HTML.

• Hoy en día, estos manejan ambientes dinámicos y muchos proveen manejo de JSP y funcionalidades de servlets.

• Un Web Server debe manejar muchos requerimientos concurrentes ya sea de páginas estáticas o dinámicas.

• Cada requerimiento y respuesta individual es un hecho aislado

• Cada vez mas se pasa un identificador de estado de la conversación, denominados cookies.

Web Servers

• Las cookies son pequeños archivos que los sitios web colocan en el disco duro del equipo cuando los visita por primera vez.

• Debido a la naturaleza esencialmente sin estado del ciclo de solicitud y respuesta HTTP, la conexión TCP / IP que lleva la petición y la respuesta es creada y destruida por cada solicitud.

• En las nuevas versiones del protocolo HTTP se pude hacer que la conexión sea retenida ( llamada keepalive).

• Son vulnerables a ataques.

Aplication Servers

• Implementa un estructura que provee servicos esenciales para el software que se ejecuta dentro de él, como son:

• Seguridad - Provee mecanismos de seguridad, que no necesitan ser entendidos para ser usados.

• Manejo de transacciones – Tiene un simple API que se encarga del manejo de transacciones

• Manejo de recursos – Incrementa el desempeño de un sistema mientras simplifica la codificación del mismo

Resource Servers

• Provee acceso a recursos para aplicaciones de tecnología JEE.

• Se puede comprar algunos servidores de recursos como componentes disponibles en el mercado, mientras que otros servidores de recursos requieren un desarrollo de código en la casa.

• Los tipo servidores de recurso son:• Servidores LDAP• Servidor de Seguridad• Legacy server (JDBC, Java Mail, CORBA)

Como seleccionar el servidor de aplicación

• La decisión de usar un servidor de aplicación es una pregunta de análisis de costo-beneficio.

• Priorice sus necesidades y compare con las prioridades futuras del servidor de aplicación.

• Incluya todos los costos, incluyendo costos ocultos como: administración, capacitación, mejoras, etc.

• Examine características de tiempo de ejecución del servidor de contenedores y opciones de conectividad.

Aplicaciones JEE Mult. capa

• Los componentes de la capa Cliente se ejecutan en la máquina cliente.

• Los componentes de la capa Web se ejecutan sobre el servidor J2EE.

• Los componentes de la capa de Negocio se ejecutan sobre el servidor J2EE.

• La capa EIS (Enterprise Information Server) se ejecuta sobre el servidor EIS.

Aplicaciones JEE Mult. capa

Servicios proporcionados por el contenedor EJB

• Un contenedor EJB envuelve y proporcionando una capa de servicios añadidos. Los servicios más importantes son los siguientes: – Manejo de transacciones: apertura y cierre de transacciones

asociadas a las llamadas a los métodos del bean. – Seguridad: comprobación de permisos de acceso a los métodos

del bean. – Concurrencia: llamada simultánea a un mismo bean desde

múltiples clientes. – Servicios de red: comunicación entre el cliente y el bean en

máquinas distintas. – Gestión de recursos: gestión automática de múltiples recursos,

como colas de mensajes, bases de datos o fuentes de datos en aplicaciones heredadas que no han sido traducidas a nuevos lenguajes/entornos y siguen usándose en la empresa.

Funcionamiento de los componentes EJB

Funcionamiento de los componentes EJB

• En primer lugar, se puede ver que el cliente realiza peticiones al bean y que el servidor que contiene el bean puede estar ejecutándose en máquinas virtuales Java distintas.

• El cliente nunca se comunica directamente con el enterprise bean, sino que el contenedor EJB proporciona un EJBObject que hace de interfaz .

• Por último, el bean realiza las peticiones correspondientes a la base de datos

Ejemplo del flujo de llamadas

• Supongamos que tenemos una aplicación de bolsa y el bean proporciona una implementación de un Broker. La interfaz de negocio del Broker está compuesta de varios métodos, entre ellos, por ejemplo, los métodos compra o vende. Supongamos que desde el objeto cliente queremos llamar al método compra. Esto va a provocar la siguiente secuencia de llamadas:

Funcionamiento de los componentes EJB

1. Cliente: "Necesito realizar una petición de compra al bean Broker."

2. EJBObject: "Espera un momento, necesito comprobar tus permisos."

3. Contenedor EJB: "Sí, el cliente tiene permisos suficientes para llamar al método compra."

4. Contenedor EJB: "Necesito un bean Broker para realizar una operación de compra. Y no olvides comenzar la transacción en el momento de instanciarlos."

5. Pool de beans: “Busca una conexión disponible". 6. Contenedor EJB: "Ya tengo un bean Broker. Pásale la

petición del cliente."

Tipos de EJB – Definición

• Un "Java Bean" es un componente utilizado en Java que permite agrupar funcionalidades para formar parte de una aplicación.

• Un "Enterprise Java Bean" también agrupa funcionalidades para una aplicación, sin embargo, a diferencia de un "Java Bean" un "Enterprise Java Bean" es un "deployable component", el término "deployable component" implica que existe un ambiente de ejecución , éste ambiente es precisamente un "EJB(Enterprise Java Bean) Container" parte de un java application server .

Tipos de EJB

• Entity beans

• Session beans– Stateless Session Beans– Stateful Session Beans

• Message-driven beans

• Data Acces Objects

• Transfer Objects

• Session Beans facade

Entity Beans

• Representan un objeto concreto que tiene existencia en alguna base de datos de la empresa. Una instancia de un Entity bean representa una fila en una tabla de la base de datos.

• Representan “cosas”: objetos del mundo real como hoteles, habitaciones, expedientes, estudiantes, y también puede representar cosas abstractas como una reserva.

• Es mucho más fácil, por ejemplo, cambiar el nombre de un estudiante llamando a student.setName() que ejecutando un comando SQL contra la base de datos

Session beans

• Estos representan sesiones interactivas con uno o más clientes.

• Pueden mantener un estado, pero sólo durante el tiempo que el cliente interactúa con el bean.

• Los beans de sesión no almacenan sus datos en una base de datos después de que el cliente termina el proceso. Por ello se suele decir que los beans de sesión no son persistentes.

• A diferencia de los Entity beans, éstos no se comparten entre más de un cliente, sino que existe una correspondencia uno-uno entre beans de sesión y clientes. Por esto, el contenedor EJB no necesita implementar mecanismos de manejo de concurrencia en el acceso a estos beans.

Stateless Session Beans

• Los métodos que ponen a disposición de las aplicaciones clientes son llamadas que reciben datos y devuelven resultados, pero que no modifican internamente el estado del bean.

• Un único bean puede estar asignado a múltiples clientes, ya que la asignación sólo dura el tiempo de invocación del método solicitado por el cliente.

• El contenedor EJB no tiene que mover sesiones de la memoria a un almacenamiento secundario para liberar recursos, simplemente puede obtener recursos y memoria destruyendo las instancias.

• Los Stateless Session Beans se usan en general para encapsular procesos de negocio.

Stateful Session Beans

• Almacenan 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.

• Ejemplos– Un ejemplo típico es un carrito de la compra, en

donde el cliente va guardando uno a uno los ítem que va comprando.

– Un enterprise bean que reserva un vuelo y alquila un auto en un sitio Web de una agencia de viajes.

Stateful Session Beans

• Debido a que el bean guarda el estado conversacional con un cliente determinado, no le es posible al contenedor crear un almacén de beans y compartirlos entre muchos clientes. Por ello, el manejo de beans de sesión con estado es más pesado que el de beans de sesión sin estado.

• Use un bean de sesión con estado si – El estado del bean representa la interacción entre el bean y un

cliente específico. – El bean necesita mantener información del cliente a lo largo de

un conjunto de invocaciones de métodos. – El bean hace de intermediario entre el cliente y otros

componentes de la aplicación.

Message-driven beans

• Estos beans permiten que las aplicaciones J2EE reciban mensajes JMS de forma asíncrona. Así, el hilo de ejecución de un cliente no se bloquea cuando está esperando que se complete algún método de negocio de otro enterprise bean.

• Un único bean dirigido por mensajes puede procesar mensajes de múltiples clientes

Cuando usar Servlets o JSP

Servlets• Los servlets son adecuados en las siguiente

situaciones:– Funciones de aplicación de bajo nivel; por ejemplo

la generación dinámica de datos binarios, tales como imágenes

– Una arquitectura bien diseñada dejaría las JSP como vistas, los Servlets como controladores y JavaBeans o EJBs para la capa de negocio.

– Los Servlets solo saben el QUE HACER nunca el COMO HACERLO

Cuando usar Servlets o JSP

• Los JSP son usados en las siguientes situaciones:

• Centrados en la presentación. Las páginas JSP su codificación es parecida a las páginas HTML.

• Manejan lógica de aplicación a través del uso de componentes JavaBeans

• Los Jsp hacen mas fácil la construcción de páginas que los servlets.

Creando la arquitectura del software

• La arquitectura es la responsable de identificar los componentes del sistema y sus relaciones, para asegurar que el sistema cumple con los requerimientos no funcionales.

• Aquí se deben considerar tres modelos– Diagrama de despliegue de alto nivel– Diagrama de despliegue a nivel de detalle– Diagrama de niveles y capas de paquetes

• DisplinaArquitectura.pdf (pag. 22)

Diagráma de Paquetes

• Un paquete es un mecanismo de propósito general para la organización deelementos dentro de grupos.

• Los paquetes se pueden anidar dentro deotros paquetes.

• Se puede colocar cualquier elemento de UML en el paquete.

Diagráma de Paquetes

Diagrama de Componentes

• Muestra la organizaciones y dependencias entre los componentes

• Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes

• Contiene elementos de software (componentes) y sus relaciones y dependencias

Tipos de componentes

1.Ejemplo Diagrama de Componentes

2.Ejemplo Diagrama de Componentes

3.Ejemplo Diagrama de Componentes

Ejemplo de un Diagrama de Deployment Detallado

Modelo de tres dimensiones

Capa de Cliente y Presentación

Capa de Negocio

Capa de Integración y Recursos