Extienda contenedores Java EE con características de nube

Estrategias y patrones para extender contenedores /aplicaciones JEE con paralelismo, elasticidad, multitenencia y seguridad

En este artículo, los autores describen las características básicas de las aplicaciones en nube y las aplicaciones Java™ Enterprise Edition, comparan sus similitudes y contrastan sus diferencias, y luego definen un conjunto de estrategias y proporcionan patrones para extender contenedores Java EE y aplicaciones con tales características de nube como paralelismo, elasticidad, multitenencia y seguridad.

Jayakrishnan Ramdas, Senior Technology Architect, Infosys LTD

Jayakrishnan Ramdas tiene más de 15 años de experiencia en la industria de las TI trabajando para Infosys LTD, un reconocido proveedor de servicios de software. Con más de 6 años de experiencia en arquitectura, Ramdas completó el TOGAF (una infraestructura de arquitectura estándar de la industria) así como varios programas de certificación IBM.



J. Srinivas, Principal Architect, Infosys LTD

J. Srinivas tiene 16 años de experiencia en la industria y actualmente está liderando el grupo de enfoque en tecnología para la unidad de Mercados de Capitales y Banca de Infosys LTD para Europa. Ha trabajado en la administración de proyectos y en secuencias de arquitectura y le apasionan los procesos, la tecnología y crear equipos motivados. Es miembro central del equipo de procesos ágiles de Infosys y es promotor de la computación en nube con Infosys.



08-06-2011

La arquitectura Java Enterprise Edition (JEE) se basa en componentes con recursos que manejan efectivamente transacciones y preservación de estado de aplicaciones, multienlazamiento y agrupación de recursos. Una aplicación JEE es más fácil de escribir, incluso con requerimientos complejos, ya que la lógica de negocios está organizada en componentes reutilizables y el servidor proporciona los servicios subyacentes — en forma de un contenedor— para cada tipo de componente.

Pensamos que sería una idea novedosa agregar incluso más potencia al concepto de servicios de contenedor en el JEE añadiendo soporte para algunas de las poderosas ideas de la computación en nube — que son paralelismo, elasticidad, multitenencia y seguridad. Este artículo describe las estrategias y patrones para extender contenedores y aplicaciones JEE con características de computación en nube. Incluye:

  • Una descripción de cada característica de nube que integramos.
  • Un esquema de las características existentes de las aplicaciones JEE.
  • Una descripción de nuestro enfoque para extender el contenedor JEE hacia la nube.
  • Una estrategia de diseño para este tipo de migración, una que incluye los conceptos de paralelismo, sincronización, almacenamiento, elasticidad, multitenencia y seguridad.

Características de la nube

La Figura 1 explica lo que es la nube y los diferentes modelos de implementación de la nube.

Figura 1. Vista rápida de los modelos de servicio en nube y de sus componentes
Vista rápida de los modelos de servicio en nube y de sus componentes

En la base de la pila de la nube está el nivel de Infraestructura como un Servicio (IaaS). Aquí la infraestructura de ha movido hacia la nube y ahora la nube facilita la implementación de software incluyendo aplicaciones de negocios. No obstante, la IaaS no tiene un entorno de desarrollo de aplicaciones ni servicios de pruebas. Como muestra la figura, el nivel superior de abstracción es elasticidad, implementación automática y computación de utilidades.

El nivel de Plataforma como un Servicio (PaaS) ofrece un entorno para la creación, implementación y mantenimiento de software de aplicación. El proveedor de PaaS debe proporcionar los servicios del ciclo de vida básico, como compilar, implementar, probar y crear servicios en bloque como administración de estado, transacción y seguridad, así como servicios de administración de recursos, durante el tiempo de ejecución.

El nivel de Software como un Servicio (SaaS) proporciona un entorno para que el usuario final accese a una aplicación y la utilice.

Las características básicas de nube que una aplicación necesita soportar son elasticidad y multitenencia. Otras características, como aprovisionamiento y automatización, son soportadas a través de los recursos de implementación del servidor de aplicaciones y no tienen mucho impacto en el código. El paralelismo, las necesidades de almacenamiento distribuido y las mejoras en seguridad, actúan como características que necesitan ser resueltas para lograr elasticidad y multitenencia.

Observemos cada uno detalladamente.

Elasticidad

La elasticidad es la capacidad de escalar hacia arriba y hacia abajo en la infraestructura con base en la necesidad. Durante los periodos de pico de carga, se agregan más instancias al clúster y cuando la carga disminuye el número de instancias se reduce. Esto debe hacerse dinámicamente. Esta función es habilitada por recursos del servidor de aplicaciones para soportar técnicas de clustering dinámico.

La elasticidad no sólo es una solución de servidor de aplicaciones; la aplicación en sí debe poder soportar la elasticidad. Esto significa que la aplicación necesita estar diseñada para manejar todos los recursos que utiliza para soportar concurrencia. Al diseñar o personalizar una aplicación para que soporte elasticidad, usted implica que también está implementando paralelismo, ausencia de estado y soporte de transacción en su aplicación.

La sección de estrategia de diseño describe cómo implementar una elasticidad donde todos los recursos soporten ausencia de estado en ejecución y paralelismo.

Multitenencia

Multitenencia quiere decir que su aplicación tiene la capacidad para que una instancia de aplicación individual atienda a múltiples clientes; esto significa que si cinco clientes están usando un servicio de administración de contenido, entonces todos los cinco clientes pueden usar la misma instancia de aplicación con segregación adecuada y parámetros de ejecución. Para soportar multitenencia, su aplicación necesita vincular almacenamiento distribuido, paralelismo, seguridad y acoplamiento ligero.

Hay dos enfoques para soportar multitenencia:

  • Un almacenamiento físico para todas las tenencias.
  • Múltiples recursos de almacenamiento físico para todas las tenencias.

Paralelismo y soporte de transacción

En el contenido de este artículo, paralelismo es la capacidad para ejecutar múltiples solicitudes o para dividir un conjunto de datos grande en múltiples sub-tareas que se ejecutan en paralelo. Esto hace un mejor uso de los recursos disponibles. El uso de paralelismos tiene un impacto positivo en los resultados y en el desempeño. El soporte de transacciones asegura la confiabilidad al garantizar que los cambios en el estado de cualquier recurso se sincronizan. Estos dos conceptos están en los dos extremos opuestos del espectro - si usted realiza más de uno, estará haciendo menos del otro.

La mezcla correcta de soporte de paralelismo y transacción es esencial para balancear estas características opuestas. Las sección de estrategias presenta cuatro estrategias, dos para soporte de paralelismo y dos para soporte de transacciones:

  • En enfoque sincronizado y asíncrono para el paralelismo.
  • Un enfoque de completamiento de hilos y uno de sincronización de llegada de datos para soporte de transacciones.

La estrategia de migración descrita sigue enfoques no funcionales del paralelismo, pero hay algunos que requieren cambios funcionales. Como la infraestructura MapReduce de Google; MR describe una forma de implementar paralelismos usando la funciónMap que divide una gran cantidad de datos en múltiples pares clave-valor. (Vea Recursos para leer artículos sobre MapReduce y la nube).

Acoplamiento ligero y ausencia de estado

El acoplamiento ligero asegura que cada llamada a un servicio se haga mediante una interfaz estándar; esto permite cambiar al componente llamado y al componente que lo llama sin que tengan impacto en el otro. El acoplamiento ligero es introducido por un proxy cuando invoca la llamada. La ausencia de estado es una propiedad de acoplamiento simple en la que ningún llamado de servicio depende de la llamada anterior. Esto se logra mediante la administración de los cambios de estado en un almacenamiento persistente.

Ambas son características complementarias que hacen que las llamadas de sistema sean más independientes de las dependencias.

Almacenamiento distribuido

El almacenamiento distribuido es un medio para que los datos persistan de manera que la ubicación de los datos no es importante. También significa que hay diferentes lugares en los que algunos datos se pueden almacenar. Esta característica mejora la elasticidad y la ausencia de estado, pero puede afectar negativamente el soporte de transacción, por lo cual necesitará de una acción de balanceo.

Las cuatro estrategias para almacenamiento distribuido incluyen:

  • Nodos replicados: Los datos están disponibles en diferentes nodos y son replicados inmediatamente hacia otros nodos.
  • Replicación on-demand: Hay desencadenantes definidos que causan replicación de datos, manual o automáticamente.
  • Replicación en un sentido con failover: El plan de nodos principal-a-hijo; durante una falla de nodo principal, las tareas de replicación de asignan a un hijo específico.
  • Sistema de archivos compartido: Se utiliza cuando la replicación es costosa como con recursos de sistemas de archivos.

Seguridad

La seguridad de aplicación en nube impacta fuertemente ciertas características: La multitenencia, el paralelismo y al acoplamiento ligero presentan nuevas necesidades de seguridad. Y si su aplicación es implementada como un híbrido (por ejemplo, un componente en nube y un componente en sistema local), usted necesita asegurar capacidades de inicio de sesión único entre dominios, lo cual acarrea implicaciones de seguridad adicionales.

También hay problemas de seguridad con el almacenamiento distribuido, el paralelismo y el transporte.

ahora que usted está familiarizado(a) con las características de aplicación en nube, observemos la estructura del contenedor Java EE.


Características de aplicación del contenedor Java EE

Las aplicaciones tradicionales del JEE dependen de los servicios de contenedor y de su uso:

  • Sesiones adhesivas para administración de estados de conexión
  • RDBMS, directamente a través de SQLs o mediante procedimientos almacenados utilizando
  • objetos ORM JMS indirectamente

También pueden usar beans dirigidos por mensajes, beans de sesión y servicios Web implementados, usando la infraestructura proporcionada por el contenedor. Las aplicaciones recientemente construidas pueden usar procesamiento asíncrono, y también servicios de caché o servicios JavaMail.

Examinemos detalladamente algunos atributos y funciones de aplicaciones de contenedor JEE.

Datos y operación

Cada bit de lógica de programación puede abstraerse hacia una parte relacionada con data- (o memory-) y una parte relacionada con operation- (o execution-) que interactúan entre sí para que la aplicación trabaje con los datos y estos sean usados por la operación. Todo el paquete JEE, contenedor y aplicación, puede abstraerse de la misma manera.

Contenedor

La calidad del aspecto datos es medida por la capacidad para asegurar confiabilidad de los datos a los que se accede, disponibilidad de los datos a que se accede, siendo posible permitir concurrencia así como seguridad de los datos en almacenamiento. La calidad del aspecto de operación se mide al ser posible asegurar la capacidad de un escucha para escuchar la llegada de los datos, la capacidad para invocar una llamada remota y el control de acceso y la seguridad en el transporte.

Tabla 1. Proporcionando calidad para el aspecto de operación de una aplicación JEE
Atributo de calidadAtributo de implementaciónImplementación
DatosConfiabilidadTransacciónTransacciones proporcionando acceso sincronizado a los datos.
DisponibilidadPersistenciaEl tipo de persistencia determina la disponibilidad de los datos.
ConcurrenciaAdministración de estadoEl mecanismo de administración de estado asegura cuántas solicitudes concurrentes se pueden procesar.
SeguridadSeguridadEl cifrado en almacenamiento y tránsito.
OperaciónComunicación asíncronaEscuchaEl desencadenante de llamados asíncronos.
Comunicación sincronizadaInvocación remotaLa llamada sincronizada externa al proceso actual.
SeguridadSeguridadLa verificación de control de acceso y la seguridad del transporte.

La responsabilidad del contenedor es doble:

  1. Tener un mecanismo para asegurar que se preserven los atributos de calidad de datos y operación.
  2. Controlar la utilización de los recursos del sistema como memoria de almacenamiento dinámico, número de hilos de ejecución, etc.

Esto lleva a dos patrones diferentes por los cuales usted debería preocuparse — el patrón de recursos administrados y el patrón de tareas administradas.

Patrón de recursos administrados

Un recurso administrado proporciona un servicio relacionado con datos e implementa administración de sesión, transacción, persistencia y seguridad. El interlocutor utiliza el directorio de nombres para ubicar al gestor de recursos. El gestor de recursos usa la agrupación de objetos proporcionado por el contenedor, para administrar los recursos del sistema. Un recurso administrado típico tiene el patrón que puede ver en la Figura 2.

Figura 2. Patrón de recursos administrados
Patrón de recursos administrados

El contenedor o aplicación puede obtener un descriptor de contenido en el gestor de recursos mediante JNDI. El gestor de recursos implementa la agrupación de objeto y obtiene el recurso administrado que implementa persistencia, administración de estado de seguridad y transacción.

Patrón de tareas de administrador

Una tarea administrada proporciona servicios relacionados con la operación que implementan invocación remota, escucha y seguridad, y utiliza los servicios de agrupación de hilos y directorio de nombres proporcionados por el contenedor. Adicionalmente, una tarea administrada muy probablemente encapsula uno o más de los recursos administrados con los que trabaja. La escucha administrada es activada por el contenedor con base en la llegada de datos — los datos pueden estar en forma de tiempo, mensaje o solicitud. También puede ser activado por la aplicación.

Figura 3. El patrón de tarea administrada
El patrón de tarea administrada

Cada servicio que proporciona el contenedor puede descomponerse en alguno de los patrones o en una combinación de dos patrones. Por ejemplo, el Java Message Service (JMS) tiene un patrón de recursos administrados para destinos JMS y un patrón de tareas administradas para el JMS MessageListener. De forma similar, JDBC Connection se administra como un patrón de recursos administrados.

Ahora que hemos cubierto cómo funciona la aplicación de contenedor JEE, observemos cómo extender una aplicación de contenedor hacia la nube.


Extendiendo contenedores: El acercamiento básico

El enfoque para extender un contenedor hacia la nube es:

  1. Descomponer las características de la nube en los atributos de implementación y luego
  2. Mejorar el patrón de recurso administrado y el patrón de tarea administrada con los cambios relacionados a los atributos de la implementación.

La sección de estrategia muestra cómo el patrón de recursos administrados se extiende al patrón de recursos de la nube y el patrón de tarea administrada se extiende al patrón de tarea en la nube.

El patrón de recursos administrados emplea las siguientes extensiones para crear el patrón de recursos de la nube (ver Figura 4):

  • CloudResource
  • Isolator
  • Replicator
  • LockManager
  • LockDataResource
  • StateDataResource

De manera similar, el patrón de tarea administrada se extiende con Proxy y StateManager para crear el patrón de tarea de la nube (ver Figura 5).

Hablemos sobre algunos de estos componentes.

Patrón de recursos de la nube

l patrón de recursos de la nube incluye la lista de extensiones que se acaban de mencionar. Esta es una descripción de cada componente y de sus interacciones con las demás.

CloudResource
CloudResource extiende el recurso administrado para incluir transacciones distribuidas y lógicas de persistencia de estado, si se necesita.

StateDataResource
StateDataResource es una instancia de CloudResource que representa un cambio de estado para el recurso nube dado. La lógica de persistencia de estado en sí es ejecutada de una forma sin estado.

Isolator
Isolator utiliza un campo de control en la entrada para identificar a quien tiene al cliente y aplica la lógica de seguridad y de partición relevante para almacenarlas en el lugar correcto. El Isolator asegura que el código de la aplicación no se atasque con estrategias de almacenamiento multitenedor y asegura que se aplique la estrategia multitenedor. El Isolator es una colección de CloudResources.

Replicator
El Replicator se utiliza únicamente si se utilizan estrategias almacenamiento de nodos replicados y replicación on-demand. El Replicator asegura que los datos sean persistidos en todos los nodos replicados como una transacción distribuida simple. La diferencia entre el Isolator y el Replicator es que el Isolator asegura que los datos vayan hacia el almacenamiento correcto con base en quién los tiene, y el Replicator asegura que los datos vayan hacia todos los almacenamientos replicados para el mismo tenedor.

LockManager y LockDataResource
La funcionalidad de LockManager es bloquear un dato particular para un hilo de un proceso para todos los Replicators. El LockManager asegura la misma visualización de estado en todos los nodos replicados. Esto quiere decir que si los datos son bloqueados para un hilo en un proceso de servidor en el servidor 1, el proceso del servidor 2 verá el estado como bloqueado, incluso si se ve como una réplica de almacenamiento. Este recurso sólo se necesita para estrategias de almacenamiento de nodos replicados y de replicación on-demand.

Los cambios generales al patrón pueden resumirse como sigue (Figura 4):

  • El gestor de recursos ahora proporciona Isolators que a su vez proporcionan un CloudResource directamente, o un Replicator dependiendo de la estrategia de almacenamiento.
  • El recurso de nube ahora soporta transacciones distribuidas y la administración de estado ahora también maneja la persistencia de estado.
Figura 4. El patrón de recursos en nube ahora soporta transacciones distribuidas
El patrón de recursos en nube ahora soporta transacciones distribuidas

Patrón de tarea en nube

El patrón de tarea en nube extiende el patrón de tarea administrada con las extensiones Proxy y StateManager. Proxy determina la estrategia de paralelismo e instruye al StateManager para que controle la persistencia de estado para la ejecución.

Proxy
Proxy es el empaquetador alrededor de la tarea administrada con lógica pre-procesos y post-procesos. La lógica pre-procesos incluye seguridad de mensaje, seguida por el formateo de la entrada con base en el protocolo y en el desempeño de la tarea. Después de la ejecución de la tarea, la lógica post-proceso decide qué hacer con el resultado.

StateManager
La ejecución sin estado d una tarea es para asegurar que la entrada a la tarea sea el estado inicial y que toda información relacionada con el estado final esté presente en el resultado. Por lo tanto, StateManager se encarga de la entrada y la salida y de moverlas como un CloudResource.

Figura 5. StateManager del patrón de tarea de nube mueve las E/S como CloudResource
StateManager del patrón de tarea de nube mueve las E/S como CloudResource

La Tabla 2 muestra los detalles sobre cómo cada característica de nube y su correspondiente estrategia de diseño, impacta a cada atributo de implementación JEE y qué patrones están referenciados.

Tabla 2. Características de nube y su impacto en la estrategia de diseño e implementación
Características de la nubeEstrategia de diseñoAtributo de implementaciónPatrónExtensiones de patrón
Ausencia de estadoAusencia de estado mediante persistencia de estadoEscucha, invocador remotoTarea nubeStateManager
StatelessnessAusencia de estado mediante persistencia de estadoAdministración de estadoRecurso nubeStateDataResource
Almacenamiento distribuidoNodos replicados Replicación on-demandPersistenciaRecurso nubeReplicator, LockManager, LockDataResource
Almacenamiento distribuidoNodos replicados Replicación on-demandTransacciónRecurso nubeCloudResource
Paralelismo y sincronizaciónTodas las estrategiasEscucha, invocador remotoTarea nubeProxy
El acoplamiento ligeroTodas las estrategiasEscucha, invocador remotoTarea nubeProxy
MultitenenciaTodas las estrategiasPersistenciaRecurso nubeIsolator
SeguridadCifradoPersistenciaRecurso nubeIsolator
SeguridadCifradoEscucha, invocador remotoTarea nubeProxy

Extendiendo contenedores: Enfoque para servicios de contenedor comunes

Modificar los servicios de contenedor existentes para que coincidan con los patrones de recurso nube y de tarea nube y acopla los a la aplicación de la manera menos invasiva posible. En una cáscara de nuez, convertimos todos los servicios al patrón de recursos nube; cuando la aplicación interactúa con el patrón de recursos nube, convierte ese patrón en el patrón de tarea nube y queda listo para ir a la nube. La siguiente lista muestra el servicio, el método original y el enfoque que utilizamos.

  • Servicio:JDBC Database Connections
    Método legado: Recursos administrados. Enfoque: Apuntar a las versiones más altas que soporten transacciones distribuidas (confirmación de dos fases), conexión compartible que soporte agrupación de hilos e invocación sin estado. Con base en las versiones más altas que existan, la funcionalidad restante puede proporcionarse usando un patrón de recursos en nube.
  • Servicio:objetos ORM JMS indirectamente
    Método legado: Los Senders y Receivers JMS son tareas y mensajes JMS y los destinos son objetos.
    Enfoque: El mismo enfoque que para las JDBC Database Connections. La configuración se puede cambiar para asegurar que el JMS Server también esté presente en todos los nodos donde también está presente el cliente JMS para ayudar a la elasticidad.
  • Servicio:Objetos de caché
    Método legado: Actualmente se soportan servicios caché en memoria o distribuidos.
    Enfoque: Todas las caché necesitan convertirse a caché distribuido para aprovechar un intercambio efectivo. Los servicios caché pueden ser empaquetados opcionalmente por un adaptador de recursos cloud.
  • Servicio:Sesión
    Método legado: La mayoría de aplicaciones utilizan sesiones adherentes.
    Enfoque: El código puede ser cambiado de forma no intrusiva teniendo un filtro para todas las solicitudes y dejando que el filtro cree un HttpServletRequestWrapper personalizado que pueda alterar temporalmente getSession() para entregarlo como recurso nube. También elimine la sesión adherente.
  • Servicio:Estrategias de persistencia
    Método legado: La persistencia administrada por contenedor y basada en ORM será benéfica.
    Enfoque: La persistencia administrada por contenedor basada en Correlacionamiento de Relacional de Objeto no obstruye el código de la aplicación con la naturaleza relacional del almacenamiento. Esto también permite un intercambio fácil de la capa de persistencia para una DB no relacional. Los Hibernate Shards también permiten almacenamiento distribuido y funcionan como el Replicator en el patrón de recursos de nube. Si la aplicación utiliza un DAO (data access object) con SQLs dinámicas y procedimientos almacenados, el objeto de valor que se pasa al DAO puede declararse como recurso nube usando anotaciones.
  • Servicio:Variable
    Método legado: Tratamiento de variables.
    Enfoque: Todas las variables públicas y variables estáticas, todas las entradas/salidas de archivos, y todas las escrituras de registro se modifican para que tengan que usarse como un recurso nube.
  • Servicio:Llamados de método
    Método legado: Tratamiento de llamados de método.
    Enfoque: Todos los llamados de método relevantes son convertidos en una tarea de nube.

Impacto en las estrategias de diseño

Finalmente, veamos cómo habilitar características de nube en su aplicación puede afectar las estrategias de diseño. Vamos a examinar lo siguiente:

  • Paralelismo sincronizado y asíncrono.
  • Sincronización de llegada de datos y completado de hilos.
  • Nodo replicado, replicación on-demand, replicación en un sentido con failover y sistema de archivos compartido del lado del almacenamiento.
  • Acoplamiento ligero y ausencia de estado.
  • Elasticidad.
  • Multitenencia de almacenamiento individual y separado.
  • Seguridad.

Paralelismo

Como se mencionó anteriormente, paralelismo implica la capacidad de procesamiento paralelo de una tarea cuando la tarea se divide en diferentes sub-tareas con consolidación al final. Se ofrecen dos estrategias para paralelismo, sincronizada y asíncrona.

Sincronizada
Aquí el interlocutor espera que se complete la ejecución antes de proceder con la siguiente tarea. Cada tarea se desencadena usando un llamado de servicio. La tarea espera que el interlocutor retorne. El paralelismo se introduce ejecutando los hilos de programación hijos del hilo principal para cada tarea, de manera que las tareas se ejecuten concurrentemente mientras cada hilo ejecuta la tarea asíncronamente.

La estrategia sincronizada se ajusta mejor para agregación de datos. Cuando la aplicación necesita información de diferentes fuentes, se pueden tomar datos de cada fuente sincronizadamente, pero cada fuente puede captarse concurrentemente.

Asíncrona
Aquí el interlocutor usa mensajería para invocar una tarea de forma asíncrona. Cuando la tarea se completa, el resultado de la tarea se mantiene en un área de almacenamiento persistente para que la próxima tarea la tome.

Esto se ajusta mejor para tareas de orquestación. Cada tarea de orquestación se invoca asíncronamente y cada una de ellas llama tareas de agregación de datos usando la estrategia sincronizada.

Estrategias de sincronización

Las estrategias de sincronización aseguran soporte de transacciones y por lo tanto, confiabilidad en la tarea. Esto asegura que las tareas relevantes y los datos relevantes se pongan a disposición antes de que se procese la siguiente tarea. Hay dos estrategias de sincronización, sincronización basada en la llegada de datos y otra basada en completado de hilos.

Basada en llegada de datos
La sincronización por llegada de datos implica que una tarea se inicia tras la llegada de un dato particular proveniente de una ubicación particular. Esto es especialmente importante cuando se utiliza invocación asíncrona donde la tarea que hace el llamado no tiene que buscar el resultado de la tarea llamada que aparece en una ubicación particular para continuar.

Un hilo sondea el área de datos y verifica la llegada de los datos. Este envía un mensaje para que la tarea inicie tan pronto lleguen los datos. MessageListener es una implementación de la sincronización de llegada de datos.

Basada en completado de hilos
En la sincronización por completado de hilos, un monitor de recursos observa los hilos concurrentes y sincroniza la ejecución de las tareas mientras accede a ese recurso. La misma estrategia puede aplicarse para un recurso que deba ser compartido entre instancias usando una combinación de la estrategia de llegada de datos y de la estrategia por completado de hilos.

Esta estrategia se aplica generalmente a los hilos con una JVM individual. Para recursos externos, este enfoque es una extensión de la sincronización por llegada de datos, donde el estado del monitor son los datos y la escucha trae los datos al hilo que se está ejecutando en el JVM actual.

Almacenamiento

Hay diferentes tipos de almacenamiento; las bases de datos, sistemas de archivos, datos en memoria y dispositivos de persistencia como directorios nativos, son sólo algunos ejemplos. La necesidad crítica para una estrategia de almacenamiento es asegurarse de que la aplicación JEE tenga una forma de crear un objeto de red verdadero, un objeto cuyo cambio de estado se refleje en todas las JVMs del clúster y tener una forma para migrar hacia una fuente de datos distribuidos cuando el SQL RDBMS no funcione. Adicionalmente, la estrategia de almacenamiento constituye un componente importante del paralelismo y la multitenencia.

Nodos replicados
La estrategia de nodos replicados implica que los mismos datos están disponibles en diferentes nodos y son replicados inmediatamente hacia otros nodos. Las estrategias de replicación en caliente y a 'temperatura media' aplican a las bases de datos. Las otras áreas de almacenamiento necesitan usar la estrategia aplicada en la confirmación de dos fases.

Hay dos hilos para el soporte de ejecución, como mínimo. Un hilo tiene la acción Save/Update que invoca de forma sincronizada. Este envía los datos mediante conexiones de socket hacia otros nodos y después de obtener la respuesta, emite la confirmación que en actualiza efectivamente en todos los nodos. El hilo de escucha presta atención a los cambios de otros nodos y responde a ellos. La conexión de socket puede ser reemplazada por mensajería o servicios basados en http.

La replicación se ajusta mejor para datos de sólo lectura con menos actualizaciones. La replicación es costosa. Toda la caché y los datos en memoria pueden rediseñarse como almacenamiento basado en nodos replicados.

Replicación on-demand
Esta es una variación de la estrategia de replicación, donde las confirmaciones regulares son para el nodo actual y el código puede desencadenar replicación a un punto local. La replicación también puede desencadenarse sobre la base de según-se-necesite, utilizando las estrategias de sincronización.

La replicación on-demand ayuda en el escenario en el que cada nodo trabaje con diferentes piezas de datos y se combinará en pasos lógicos. Un modelo de programación estilo MapReduce puede usar esta estrategia.

Replicación en un solo sentido con failover
Otra variación de la replicación es asignar un nodo maestro y todos los datos son replicados desde nodos principales a nodos hijos. Durante el failover, uno de los hijos se convierte en el nodo principal y toda la replicación comienza a fluir desde ese nodo. La aplicación siempre trabaja con el nodo maestro. Esta estrategia funciona con la estrategia de sistema de archivos compartido para diseños con alta disponibilidad.

Sistema de archivos compartido
Este se utiliza comúnmente para recursos basados en sistema de archivos donde la replicación es costosa. Aquí el sistema de archivos en sí se mueve alrededor de diferentes nodos para hacer balanceo de carga. Esto no proporciona una opción de disponibilidad infalible, pero está lo suficientemente cerca a ello. Los sistemas de archivos de bases de datos relacionales pueden manejarse de esta manera.

Acoplamiento ligero y ausencia de estado

La ausencia de estado se logra al asegurar que todos los datos necesarios para la llamada estén disponibles y cuando no hay dependencia de la máquina que procesa la solicitud. El acoplamiento ligero se asegura de que un llamado se pueda reemplazar. Un llamado de servicio REST o Web basado en HTTP puede asegurar ambas cosas.

Elasticidad

La elasticidad se logra al asegurar la mezcla correcta de soporte de paralelismo y soporte transaccional y aún más importante, que la ejecución sea sin estado y por lo tanto repetible. El estado de cada ejecución se persiste separadamente. La misma instancia de un objeto puede tener múltiples hilos en ejecución; cada hilo tiene un área separada para el objeto. Esto reduce la necesidad de múltiples objetos en la agrupación. Algunos de los proveedores de bases de datos ya ofrecen conexiones que se pueden compartir para encargarse de este recurso. Esto quiere decir que alrededor de 2 o 3 conexiones son suficientes para manejar 20 o 30 transacciones de lectura concurrentes, en promedio.

Entre más corta sea la duración de la transacción, mejor es para elasticidad. Entonces tiene sentido dividir una tarea de ejecución larga en numerosas tareas sin estado y repetibles, para reducir el tamaño de transacción.

Multitenencia

La multitenencia implica que una instancia de la aplicación en realidad puede servir a múltiples clientes con separación adecuada de datos. Hay diferentes consideraciones de diseño para multitenencia, pero la crítica, que puede enfrentarse sin refactorización de código, es resolver almacenamiento individual vs. separado para diferentes tenedores.

Almacenamiento individual para múltiples tenedores
Esto quiere decir que sólo hay un recurso de almacenamiento para todos los clientes. Esta configuración se puede mantener mejor y es más escalable porque sólo hay una agregación lógica y por lo tanto, cada elemento de datos individual puede cifrarse por una clave separada. El esquema y la partición proporcionan separación lógica de los datos para bases de datos, y los espacios de nombre proporcionan la separación lógica de los datos para XML.

Almacenamiento separado e individual para cada tenedor
Cada cliente obtiene su propio almacenamiento. Aquí hay segregación física de los datos. Este modelo se ajusta a aplicaciones donde la política dicta que los datos son sensibles por naturaleza. A este almacenamiento separado debe accederse usando un servicio de enrutamiento para evitar que la complejidad abarrote la lógica de programación.

Seguridad

Debido al almacenamiento distribuido y a la multitenencia se generan necesidades adicionales de seguridad. La estrategia de seguridad necesita responder a seguridad de almacenamiento, mensajería y transporte. Adicionalmente, una implementación de nube híbrida o de nube virtual privada necesitará una opción de inicio de sesión único entre dominios, por lo cual la federación también jugará un papel.

Las necesidades adicionales de seguridad son una derivación de las características de nube específicas según aplicación, por lo cual esto puede implementarse sin que tenga impacto en el resto de la funcionalidad ni del código.


En conclusión

La metodología que hemos descrito proporciona estrategias y patrones de diseño para ayudarle a habilitar características de nube en servicios de contenedor y para ayudarle a migrar aplicaciones a la nube. El patrón de recursos de nube y el patrón de tareas de nube están diseñados para ser reutilizados y no hacemos suposiciones sobre la estrategia que usted escoja.

Hemos examinado las características que hacen únicas a las aplicaciones en nube, así como las características correspondientes de contenedores y aplicaciones Java EE. Hemos adaptado los patrones de recurso administrado y tarea administrada hacia patrones de recurso en nube y tarea en nube para mostrarle cómo extender servicios de contenedor para que sean usados por aplicaciones de nube.

Además, también hemos señalado el impacto de integrar contenedores JEE para aplicación en nube en sus estrategias de diseño de aplicación en nube.

Finalmente, nos gustaría destacar que la JEE Connector Architecture (JCA) es una de las opciones para implementar las extensiones a patrones de recursos administrados y tareas administradas. La JEE Connector Architecture proporciona la infraestructura para definir un recurso con trabajo, ciclo de vida, conexión y administración de transacciones, así como mejorar la arquitectura en seguridad, las comunicaciones entrantes y el flujo de entrada de mensajes.

Recursos

Aprender

Obtener los productos y tecnologías

  • Consulte la sección imágenes de producto disponible en el IBM Smart Business Development y haga Pruebas en la Nube IBM.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing, tecnologia Java
ArticleID=678820
ArticleTitle=Extienda contenedores Java EE con características de nube
publish-date=06082011