Desarrollo y despliegue de soluciones multi-tenant entregadas a través de la Web usando middleware de IBM: Parte 3: Distribución, aislamiento y personalización de recursos en aplicaciones multi-tenant (para múltiples clientes) de instancia única

Este artículo se centra en la instancia de aplicaciones única compartida basada en el modelo de capacidad multi-tenancy. Presenta los mecanismos para la distribución, el aislamiento y la personalización de recursos multi-tenant, de aquellos dispositivos J2EE importantes en dichos patrones. También apalanca una aplicación de muestra para ilustrar cómo diseñar una aplicación J2EE de capacidad multi-tenant basada en el software de middleware de IBM.

Bo Gao, Researcher, IBM

Bo GaoBo Gao es ingeniero de investigación y trabaja en servicios de última generación en el China Research Lab de IBM en Beijing, China. Actualmente se dedica a la tecnología masiva multi-tenant en el área de SaaS (Software as a Service). Posee amplia experiencia en IBM SOA Software Stack típicas.



Chang Jie Guo, Manager, Services Delivery Efficiency, IBM

Chang Jie GuoDr. Chang Jie Guo es miembro del equipo de investigación y trabaja en los servicios de investigación de última generación en el China Research Lab de IBM en Beijing, China. En los últimos años se ha dedicado a algunas de las principales tecnologías del área de Software as a Service (SaaS), incluyendo el servicio masivo multi-tenant, el ágil business process mangement (BPM), Web 2.0 etc.



Zhi Hu Wang, Research Engineer, IBM

Zhi Hu WangZhi Hu Wang es ingeniero de investigación y trabaja en los servicios de última generación en el China Research Lab de IBM en Beijing, China. Actualmente se dedica a la tecnología masiva multi-tenant en el área de SaaS (Software as a Service).



Wen Hao An, Software Engineer, IBM

Wen Hao AnWen Hao An es ingeniero de software y trabaja en los servicios de última generación en el China Research Lab de IBM en Beijing, China. Actualmente se dedica a la tecnología masiva multi-tenant en el área de SaaS (Software as a Service).



Wei Sun, Researcher, IBM

El Dr. Wei Sun es miembro del equipo de investigación y trabaja en los servicios de última generación del China Research Lab de IBM en Beijing, China. En los últimos años, el Dr. Sun ha estado trabajando en proyectos de investigación relacionados con Business Process Services, Software as Services y Web 2.0.



26-08-2010

Introducción

En el segundo artículo de esta serie ("Desarrollo y despliegue de las soluciones multi-tenant entregadas a través de la Web usando el middleware de IBM, Parte 2: Una taxonomía de los enfoques actuales para permitir la capacidad multi-tenancy, analizamos los tres tipos de enfoques que permiten la capacidad multi-tenancy: la virtualización, la mediación y la distribución. Este artículo, Parte 3 de la serie, se centra en el tercer enfoque y trata sobre el modo de apalancar una instancia de aplicaciones única compartida para soportar múltiples organizaciones de los clientes (o tenants) simultáneamente, de manera que se alcance el objetivo de la eficiencia en cuanto a costos. Explora una arquitectura para desarrollar una aplicación multi-tenant configurable, segura y eficiente en costos usando el middleware de IBM. Nos centramos principalmente en tres aspectos fundamentales del diseño y la implementación de las aplicaciones multi-tenant:

  • El mecanismo para la distribución de recursos para reducir el costo del hardware, del software y de la administración de cada tenant
  • El mecanismo de aislamiento de seguridad para evitar posibles accesos no válidos, conflictos e interferencias entre los tenants
  • El mecanismo de personalización para darle soporte al modelo de UI por tenant, de control de acceso, de proceso y de datos a través de los enfoques de configuración

Para una mayor comprensión, hemos designado una aplicación de muestra, EasyOA, que debería ayudar a ilustrar el modo de implementar el modelo multi-tenancy usando los productos de middleware de IBM, especialmente WebSphere Application Server (WAS), DB2, Tivoli Directory Server (TDS) y WebSphere Process Server (WPS) de IBM.


Distribución de recursos basada en enfoques de la capacidad multi-tenancy

Como se puede observar en la Figura 1, hay por lo general dos tipos de recursos para la distribución basada en patrones de capacidad multi-tenancy: 1) aplicación de múltiples instancias, y 2) aplicación de instancia única compartida. El primero da soporte a cada tenant con su aplicación de instancia dedicada en el hardware compartido, un operating system (OS) o el servidor de middleware en un entorno de hosting, mientras que el último puede dar soporte a muchos tenants mediante una aplicación de instancia única compartida en diversos recursos de hosting. Estos dos patrones tienen una escala diferente en términos de la cantidad a la que le pueden dar soporte. Las instancias múltiples adoptadas para dar soporte a varios (hasta docenas) de tenants, cada uno de los cuales puede tener cientos de usuarios con un conjunto de servidores. La instancia única compartida se utiliza para dar soporte a una cantidad mucho más grande de pequeños tenants, que generalmente oscilan desde los cientos hasta los miles, o más aún.

Figura 1. Patrón de instancias de aplicaciones múltiples versus patrón de instancias de aplicaciones únicas compartidas
Patrón de instancias de aplicaciones múltiples versus patrón de instancias de aplicaciones únicas compartidas

La selección de los patrones de intercambio de recursos depende de los escenarios específicos de las aplicaciones y de los requisitos de los clientes destino. Generalmente, una empresa grande puede preferir pagar un recargo por múltiples instancias para evitar los posibles riesgos relacionados con la distribución de los recursos. Para la mayoría de los servicios destinados a los clientes de SMB con presupuestos pequeños para una subscripción de servicio, con el fin de alcanzar economías de escala, el modelo empresarial debe aumentar los ingresos incorporando una gran cantidad de clientes y reduciendo el costo promedio de entrega de los servicios por cliente brindándoles a los clientes una infraestructura multi-tenant altamente eficiente y escalable. En estos casos, el patrón de múltiples instancias no resulta práctico dado que el pequeño ingreso generado de cada tenant no justifica la asignación de recursos de hardware/software dedicados para el tenant.

A pesar de ser muy eficientes en costos, las aplicaciones multi-tenancy que se analizan en este artículo enfrentarán muchos desafíos, especialmente en lo que respecta al aislamiento y a la personalización.

En primer lugar, deberíamos dar soporte al nivel de aislamiento de las aplicaciones entre los diferentes clientes. Aunque todos los tenants básicamente comparten la misma infraestructura e instancia de aplicaciones, desde el punto de vista de la experiencia del usuario, el Quality of Service (QoS) y la administración, el tenant naturalmente desearía acceder al servicio y utilizarlo como si hubiera tenants dedicados. Por lo tanto, se debería considerar detenidamente el aislamiento en casi todas las partes del diseño de la arquitectura, tanto desde el nivel no funcional como desde el funcional para aspectos como la seguridad, la performance, la disponibilidad, y la administración.

En segundo lugar, deberíamos darles soporte a los tenants que personalizan su propio servicio en el momento de la ejecución sin afectar a otros. Tradicionalmente, la personalización implicaría modificaciones de código y redespliegue de las aplicaciones. Sin embargo, este patrón de personalización no es práctico en un entorno de servicio de capacidad multi-tenancy. Cuando todos los tenants comparten la misma instancia de aplicaciones, una vez realizada la personalización para un tenant determinado, los servicios para todos los tenants se verán afectados, y posiblemente interrumpidos durante la actualización. Cuando la cantidad de tenants aumenta, las interrupciones son más frecuentes y provocan problemas de disponibilidad muy serios. Por lo tanto, la personalización para un tenant sin afectar a otros clientes durante el momento de la ejecución debería ser uno de los principales requisitos de las aplicaciones multi-tenant.


Recursos Multi-tenant: mecanismo de distribución, aislamiento y personalización de dispositivos J2EE

Para las aplicaciones J2EE/SOA, hay muchas clases de recursos que son accesibles, así como dispositivos de tiempo de ejecución ubicados en múltiples pilas, por ejemplo interfaz de usuarios, lógica empresarial, proceso/flujo de trabajo, y modelo de datos. Para diseñar una aplicación multi-tenant altamente eficiente, debemos administrar con cuidado estos elementos observando los siguientes pasos:

  • Identificar todos los tipos de recursos que puedan estar distribuidos entre los tenants.¨Priorizarlos conforme a la estimación del grado del costo de ahorro que se puede obtener a través de algunos mecanismos de distribución
  • Para cada tipo de recurso distribuible, haga una lista de los posibles puntos para el aislamiento y la configuración. Evalúe y resuma los enfoques más adecuados para el aislamiento y la personalización de diferentes escenarios multi-tenant

El cuadro 1 brinda un breve resumen de las fuentes importantes y de los mecanismos correspondientes de distribución, aislamiento y personalización que utilizan. Los presentaremos en detalle en los próximos artículos de esta serie.

Cuadro 1. Visión general de los mecanismos multi-tenant de distribución, aislamiento y personalización de los recursos
ComponentesRecursos distribuidosEnfoques de aislamientoEnfoques configurables
Modelo de datos persistentes   
Servidor de base de datos (JDBC, SDO etc.)

Fuente de datos, agrupamiento de conexiones

cuenta de BD

Base de datos/Esquema/Cuadro/Agrupación de buffers, etc.

Aislamiento de almacenamiento: Cuadro/esquema dedicado o base de datos versus Cuadro/esquema dedicado

Aislamiento del acceso: control del acceso al nivel del DBMS a través de la fuente de datos y la conexión dedicadas versus control de acceso al nivel de aplicaciones a través de filtro

Esquemas de base de datos/cuadros

Campos reservados fijos

Subcuadros extendidos

Campo XML extendido

Archivo y E/S

Directorio

Archivo

Directorio/archivo dedicado

Archivos compartidos con filtro específico de tenant

Estructura del directorio o formato del archivo

Servidor del directorio (LDAP)

Árbol del directorio

Esquema

Subárbol dedicado por tenant

Compartir árbol con filtro específico de tenant

Definición de la estructura del árbol de directorio y de esquema

Lógica empresarial   
Autenticación / Autorización

Estructura de la organización / Almacén de privilegios

Módulos de registro / autorización

Almacén aislado según almacenamiento de datos persistente específico (LDAP, DB etc.)

Plug-in de registro de usuarios con amplio conocimiento

Estructura de la organización, roles, privilegios y sus relaciones de correlación

Objeto Global Java

Variable estática

variable de clase Singleton

variable (estática) dedicada por tenant usando objeto contenedor

N/A

Acceso remoto (Socket/Http, RMI, CORABA, JNDI, Servicio de la Web)

Servicios remotos

Parámetros de conexión como URI, puerto, nombre de usuario, contraseña etc.

Servicio remoto dedicado

Servicio remoto compartido, difusión de la información de los usuarios a servicios remotos

Parámetros de la conexión

EJB

Instancia de estado de EJB

Conexión de fuente de datos, cuadro de Bean de entidad

Cola, identidad de remitente de MDB

Instancia dedicada de estado EJB, MDB, Cola por tenant

Bean de entidad compartida con filtro específico de tenant

MDB compartida, Cola con identidad de tenant integrada en el mensaje

Atributos reservados del bean de identidad compartida

Formato de mensajes personalizables

Registros

Ubicación, contenido, formato y configuración del archivo de registros

Archivo de registros dedicado

Archivo de registros compartido con filtro específico de tenant

Formato de registro y parámetros de configuración

Cache

Contenedor de Cache

Contenedor de caché dedicado

Contenedor de cache compartido con filtro específico de tenant

Parámetros de configuración de Cache

UI   
JSP

Variable de alcance de las aplicaciones (etiqueta, bean de uso, contexto de aplicación, etc.)

Variable de declaraciones

Logotipo, estilo, diseño, etc.

Filtro específico de tenant para la variable de alcance de las aplicaciones

Variable de declaración dedicada

CSS, Diseño, Imagen, etc..

Servlet

Single-thread servlet

contexto del servidor

Servlet dedicado para el single-thread servlet

Filtro específico de tenant para variable de contexto de servlet

N/A

Proceso/Flujo de trabajo   
Plantilla del proceso BPEL

atributo del nivel de plantilla, actividad, condición del enlace, etc.

Plantilla de proceso dedicado

Plantilla de proceso compartido con filtro específico de tenant en instancias de proceso

Esquema de las plantillas de proceso

Tarea humana

Verbo, Task UI, etc.

Verbo extendido para aislar los mecanismos de la selección de personas conforme a la información de tenant del iniciador

Elementos UI y configuración de tareas compartidas

Reglas para la selección de personas

Norma empresarial

Normas

Normas empresariales dedicadas

Norma empresarial dedicada con filtro específico de tenant como parámetro de la norma

Configuración de los valores de las normas de las normas empresariales


EasyOA, una aplicación de muestra

EasyOA es una aplicación simple para la automatización de oficinas desarrollada para las pequeñas empresas. La aplicación principlamente incluye un proceso de aplicaciones de vacaciones, en el cual los empleados pueden elevar las solicitudes de vacaciones y consultar el histórico de las mismas, mientras que un gerente aprueba las solicitudes de los empleados. El administrador tiene algunos privilegios para visualizar los registros de las operaciones de todos los usuarios de su compañía.

EasyOA es una aplicación común J2EE basada en el siguiente middleware de IBM:

  • IBM WebSphere Application Server V6.02
  • IBM WebSphere Process Server V6.02
  • IBM Tivoli Directory Server V6.0
  • IBM DB2 V8.2
Figura 2. Arquitectura general y dispositivos de habilitación multi-tenancy de EasyOA
Arquitectura general y dispositivos de habilitación multi-tenancy de EasyOA

EasyOA ha sido diseñada con habilitación multi-tenancy. Como puede observarse en la Figura 2, los principales dispositivos multi-tenant soportados son los siguientes:

  • autenticación y autorización presentan cómo diseñar la estructura organizativa y acceder a los patrones control del acceso/almacenamiento de datos (privilegios). Estos también mejoran los módulos /procesos de Java Authentication and Authorization Service (JAAS) en el contexto multi-tenant.
  • Dispositivos J2EE comunes presenta cómo aislar y personalizar los recursos de las interfaces de usuarios y de la lógica empresarial a través de un mecanismo basado en filtro implícito entre los tenants.
  • El modelo de datos persistentes identifica y evalúa todos los posibles patrones de diseño multi-tenant de almacenamiento/acceso de datos desde el punto de vista del aislamiento, de la seguridad, de la personalización y de la performance.
  • Proceso empresarial presenta cómo aislar y personalizar la selección de personas/roles de tareas humanas o procesos entre los tenants en un patrón de plantillas de proceso compartido

Una descripción general de la arquitectura e implementación de estos dispositivos se brindará en la cuarta parte de esta serie.


Conclusión

El patrón de diseño multi-tenant - usando una única instancia de aplicaciones compartidas para dar soporte a múltiples tenants simultáneamente - es muy importante para las aplicaciones entregadas a través de la Web en términos de eficiencia en costos. En este artículo, analizamos los principios generales del diseño de la arquitectura y las técnicas relacionadas con los mismos para el desarrollo de una aplicación multi-tenant configurable usando el middleware de IBM. En la visión general de una próxima serie de artículos se brindará información más detallada sobre este tema.

Recursos

Aprender

Obtener los productos y tecnologías

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=Lotus, SOA y servicios web
ArticleID=964232
ArticleTitle=Desarrollo y despliegue de soluciones multi-tenant entregadas a través de la Web usando middleware de IBM: Parte 3: Distribución, aislamiento y personalización de recursos en aplicaciones multi-tenant (para múltiples clientes) de instancia única
publish-date=08262010