Desarrollo y Despliegue de soluciones multi-tenant entregadas a través de la Web utilizando el middleware de IBM: Parte 4: Patrones de diseño para la distribución de recursos en aplicaciones multi-tenant (para múltiples usuarios) de una sola instancia

Este artículo es el cuarto de una serie que analiza cómo desarrollar las aplicaciones entregadas a través de la Web que son eficientes en costos, seguras y configurables mediante el apalancamiento del modelo multi-tenancy. Este modelo permite una instancia de aplicaciones única y distribuida con la capacidad de dar soporte a múltiples organizaciones de clientes (o tenants) simultáneamente, de manera que se pueda lograr la eficiencia en costos mediante la distribución de la infraestructura y de los recursos operativos a los tenants.

Bo Gao, Researcher, WSO2 Inc

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.



Zhi Hu Wang, Research Engineer, WSO2 Inc

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).



Chang Jie Guo, Manager, Services Delivery Efficiency, WSO2 Inc

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.



Wen Hao An, Software Engineer, WSO2 Inc

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, WSO2 Inc

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 este artículo analizaremos una aplicación de muestra, EasyOA, para ilustrar de qué manera diseñar una arquitectura de capacidad multi-tenant de instancia única. EasyOA es una aplicación simple de automatización de oficinas desarrollada para las pequeñas empresas. Presentaremos los patrones de diseño multi-tenant para varios tipos de recursos de distribución primaria. Además, pronto publicaremos una serie de artículos sobre developerWorks para brindar información más detallada sobre cada uno de los temas analizados en las siguientes secciones de este artículo.


Mecanismo de autenticación y autorización multi-tenant

Esta sección se centra en la resolución de dos problemas: (1) Cómo diseñar un patrón organizativo de almacenamiento/acceso de datos en un contexto multi-tenant, e implementar el mecanismo correspondiente de autenticación que reconoce a los usuarios, y (2) Cómo mejorar el mecanismo de autorización basado en Java Authentication and Authorization Service (JAAS) para permitirles a los tenants el acceso y la personalización de sus listas de control de acceso y privilegios específicos de manera aislada.

Figura 1. Arquitectura para la autenticación y autorización de múltiples usuarios
Arquitectura para la autenticación y autorización de múltiples usuarios

Como hemos podido observar en la Figura 1, hay cuatro componentes en la arquitectura que propusimos para implementar el mecanismo de autorización y autorización en la aplicación de múltiples usuarios.

  • Las estructuras organizativas de los usuarios y los datos de control de acceso son almacenados en un servidor Lightweight Directory Access Protocol (LDAP) y en un servidor de bases de datos respectivamente con un esquema de árbol y modelos de datos de múltiples usuarios;
  • Un servicio de autorización les permite a los usuarios tenant conectarse con la aplicación y mantener la información relacionada con los tenants de los usuarios conectados actualmente en el token de la sesión de seguridad;
  • Un servicio de autorización da soporte a la validación del permiso de ejecución de los usuarios tenants actualmente conectados;
  • Un servicio de utilización da soporte a los tenants para mantener y configurar su estructura organizativa y los datos de control de acceso específicos.

Diseño de las estructuras organizativas y proceso de autenticación de usuarios múltiples (multi-tenant)

A cada tenant se le asigna una ID de tenant única y un subárbol de la estructura organizativa almacenada en un servidor LDAP distribuido y aislado por la ID del tenant durante la incorporación. En la práctica, el subárbol puede implementarse de modo físico o virtual.

Las siguientes imágenes (Figuras 2-4) muestran la estructura organizativa multi-tenant EasyOA en el servidor LDAP

Figura 2. Árbol de la estructura organizativa multi-tenant virtualizada
Árbol de la estructura organizativa multi-tenant virtualizada
Figura 3. Captura de pantallas de la estructura organizativa virtualizada EasyOA en el servidor LDAP
Captura de pantallas de la estructura organizativa virtualizada EasyOA en el servidor LDAP
Figura 4. Árbol de estructura organizativa física multi-tenant
Árbol de estructura organizativa física multi-tenant

Las figuras 2 y 3 representan la implementación de una estructura organizativa virtualizada, en la cual el proceso de autenticación en un contexto multi-tenant es el siguiente:

  • En la página de conexión, el usuario tenant ingresa su nombre y contraseña con el nombre de tenant suministrado, ya sea explícitamente mediante su ingreso o implícitamente a través de la URL. Una vez enviado, la página de conexión combina el nombre de tenant y el nombre de usuario como la cadena userSecurityName que WebSphere Application Server (WAS) de IBM puede comprender, y llama al módulo de conexión WAS a través de la API o de un formulario.
  • El módulo de conexión WAS llama al WAS LDAP User Registry para realizar la autenticación, por ejemplo validar el usuario o la contraseña a través del subárbol correspondiente de la estructura organizativa almacenada en el servidor LDAP del tenant.

Una vez que realizada la autenticación, el módulo de conexión WAS crea el token de una sesión de seguridad y almacena en su interior la información sobre la sesión actuales y el tenant de usuario de conexión (por ejemplo Nombre de Tenant, ID de Tenant, Nombre de Usuario, ID de Usuario, privilegios etc.), a los que se puede acceder fácilmente mediante otros módulos de la aplicación EasyOA al momento de la ejecución llamando a la API del servicio de autenticación.

Mientras que en la implementación de la estructura organizativa física presentada en la Figura 4, cada tenant posee un subárbol dedicado en el servidor LDAP. En este caso, podemos apalancar la nueva función del Virtual Member Manager (VMM) suministrada por WAS v6.1 – el almacén federado de usuario.

En esencia, este dispositivo brinda la capacidad de correlacionar las entradas desde múltiples almacenes de usuarios individuales de diferentes tenants en un único almacén virtual a través de la configuración -- en lugar del desarrollo. Los almacenes pueden ser completamente externos o en el caso de LDAP, un subárbol dentro del almacén. La raíz de cada almacén se correlaciona con algo denominado entrada de base dentro del almacén federado, que es básicamente un punto de partida dentro del espacio del nombre jerárquico del dominio virtual. Si desea más información, puede consultar el artículo, IBM WebSphere Developer Technical Journal: Amplíe las opciones de registro de usuario con un almacén federado en WebSphere Application Server V6.1, en la sección Recursos.

Diseño del modelo de datos para el permiso y el proceso de autorización multi-tenant

La Figura 5 muestra como un multi-tenant flexible accede a un modelo de diseño de control basado en la especificación JAAS estándar.

Figura 5. Modelo de control de acceso multi-tenant
Modelo de control de acceso multi-tenant

Los privilegios atómicos están agrupados en un grupo denominado privilegeGroup. Los roles y usuarios están aislados entre los tenants mediante la incorporación de un nuevo objeto de tenant. Basándose en el modelo, los administradores de tenant pueden definir flexiblemente sus roles específicos, las relaciones de correlación de roles y PrivilegeGroup, y las relaciones entre el rol y el usuario a través del A&A Utilization Service.

Cuando un usuario se conecta a EasyOA, el plug-in del registro de usuario WAS recupera todos los privilegios atómicos que posee el usuario conectado, y los almacenará en el token de la sesión de seguridad, y luego serán utilizados por la API del servicio de autorización y otros componentes WAS para realizar la validación del servicio al momento de la ejecución.


Acceso a los dispositivos J2EE comunes en un contexto multi-tenant

Además de la autenticación y la autorización, hay todavía muchos dispositivos J2EE comunes que deberían aislarse (cache, registro, archivo, I/O, variables estáticas globales etc.) y personalizarse (elementos JSP tales como el logotipo, las páginas de conexión, el estilo de registro, etc.) en el contexto multi-tenant. En esta sección, le mostramos cómo un mecanismo básico basado en un filtro puede ayudarlo a aislar y a personalizar estos recursos entre los tenants de manera implícita.

Figura 6. Mecanismo de aislamiento basado en filtros implícitos
Mecanismo de aislamiento basado en filtros implícitos

En este patrón que se muestra en la Figura 6, cuando la aplicación EasyOA desea acceder a ciertos recursos distribuidos en representación de un tenant, ésta puede simplemente elevar la solicitud como una aplicación tradicional de tenant único sin necesidad de considerar la implementación detallada del servicio multi-tenancy de acceso /almacenamiento de recursos. En lugar de ejecutarse directamente, la solicitud es delegada a un módulo común de acceso al recurso que tiene los privilegios para acceder a los recursos de todos los tenants. La clave de este mecanismo es el módulo delegado que implícitamente recupera la información del tenant del dueño de las solicitudes del token de la sesión de seguridad, y luego compone un filtro específico orientado al tenant de acuerdo con algunas normas predefinidas. El filtro será utilizado por el módulo delegado para evitar que el usuario intercepte los recursos de otros tenants.

Existen algunos filtros comunes y prácticos para diferentes tipos de recursos, por ejemplo:

  • La subsentencia de SQL como “where tenant_id is xxx”
  • El archivo de registro específico del tenant y formato con Log4j Appender
  • El prefijo específico de tenant para los objetos empresariales en caché
  • Las carpetas y los archivos específicos de tenant con prefijo
  • El contenido/alcance XML específico del tenant en el archivo de configuración
  • Un parámetro o dimensión adicional que reconoce el tenant del conjunto de normas if/then o el cuadro de decisiones sobre las normas empresariales

Para que aquellos recursos sean personalizados entre los tenants (por ejemplo el logotipo, la página de conexión, las normas, etc.), podemos crear un almacén para extraer y guardar los metadatos de los puntos configurables de manera que los tenants queden aislados. Luego el módulo delegado puede componer fácilmente los recursos correspondientes para el filtro y el acceso mediante el apalancamiento de los servicios de configuración que reconocen los tenants. Las Figuras 7 y 8 muestran a EasyOA en este sentido.

Figura 7. Personalización de la página de conexión entre los tenants
Personalización de la página de conexión entre los tenants
Figura 8. Aislamiento de las variables estáticas entre los tenants
Aislamiento de las variables estáticas entre los tenants

Patrones de diseño de nivel de datos multi-tenant

Esta sección presenta el diseño de arquitectura multi-tenant y se ocupa del nivel de los datos mostrando una variedad de patrones de diseño que incluye algunos aspectos de la distribución de recursos, el aislamiento de seguridad, y la personalización. Si desea más información, puede consultar el artículo Integración de los Datos y Servicios Empresariales Compuestos, Parte 3: Crear un estrato de datos multi-tenant con control y seguridad de acceso, cuyo enlace se encuentra en la sección Recursos.

Patrón de distribución de los recursos de pilas de datos

Como se puede observar en la Figura 9, hay tres niveles de distribución de los recursos de los niveles de los datos.

  • Totalmente aislados: Bases de datos separadas por tenant
  • Parcialmente distribuidos: Base de datos distribuida, esquema separado
  • Totalmente distribuidos: misma base de datos, mismo esquema
Figura 9. Patrones de distribución de los recursos de los niveles de los datos en el contexto multi-tenant
Patrones de distribución de los recursos de los niveles de los datos en el contexto multi-tenant

Patrones de aislamiento de seguridad de las pilas de datos

En un contexto multi-tenant, el mecanismo de aislamiento de seguridad es muy importante para evitar que otros tenants puedan acceder ilegalmente a un tenant. Teniendo en cuenta el patrón distribuido de esquemas /cuadros, existen por lo general dos tipos de enfoques para el aislamiento del control del acceso, como puede observarse en la Figura 10.

  • Control de acceso de los niveles de las aplicaciones: Todos los tenants comparten una cuenta común de base de datos delegada y poseen los privilegios para acceder a todos los datos de un tenant determinado en los cuadros compartidos. Un filtro (por ejemplo, la subcláusula de una sentencia SQL) se utiliza para filtrar los registros de los datos que no pertenecen al tenant actual.
  • Control de acceso de los niveles de DBMS: cada tenant accede a los esquemas de su base de datos o de cuadro dedicados con su cuenta dedicada a través del apalancamiento de los dispositivos de seguridad de DB2, como lattice-based access control (LBAC). Este enfoque puede eliminar por completo la posibilidad del ataque de inyección SQL
Figura 10. Patrón de aislamiento de seguridad de los niveles de los datos en el contexto multi-tenant
Patrón de aislamiento de seguridad de los niveles de los datos en el contexto multi-tenant

Patrones de personalización de los niveles de los datos

Con respecto a la personalización de los datos hay también varios grados de flexibilidad para una aplicación multi-tenant que va desde la personalización de un esquema complejo hasta la extensión simple de los campos. Obviamente, para los patrones de aislamiento de las bases de datos o cuadros /esquemas dedicados, esto no representa problema ya que los esquemas de los tenants se encuentran separados. Los cambios en el modelo de los datos de un tenant pueden realizarse directamente en sus bases de datos/cuadros específicos sin afectar a otros tenants. Sin embargo, para el patrón de aislamiento de cuadros /esquemas compartidos, dado que se encuentran distribuidos, sólo puede dar soporte a las extensiones de campos de datos, cuyo grado de flexibilidad se mide por la cantidad máxima de campos de la extensión. Los principales patrones de implementación son presentados en las Figuras 11 - 13, y son los tres patrones de personalización en el modelo de cuadro/esquema compartido. Estos incluyen los siguientes elementos:

  • Campo de cuadro extendido reservado: Predefine una cantidad fija de columnas de datos adicionales en cada cuadro con un tipo de columna genérica (por ejemplo varchar).
  • Subcuadro extendido dinámico: Un subcuadro relacionado con el cuadro principal a través de la columna de la ID de registro, se crea para almacenar todos los campos extendidos de los registros en el cuadro principal.
  • Campo de cuadro extendido XML: Este enfoque apalanca los nuevos dispositivos XML suministrados por DB v9. Todos los datos extendidos son almacenados en un único campo XML.
Figura 11. Patrón del campo del cuadro extendido reservado
Patrón del campo del cuadro extendido reservado
Figura 12. Patrón del subcuadro extendido dinámico
Patrón del subcuadro extendido dinámico
Figura 13. Campo del cuadro extendido XML
Campo del cuadro extendido XML

Como indicamos más arriba, la aplicación easyOA está diseñada para dar soporte a una gran cantidad (miles) de pequeñas compañías, cada una de ellas con una cantidad de datos relativamente pequeña. Por lo tanto, EasyOA hace uso del patrón de cuadro/esquema compartido para reducir el costo. La tecnología MDC (multiple dimension clustering) -por favor consulte la sección de Recursos si desea más información- se aplica para mejorar la performance en este patrón. EasyOA además apalanca LBAC para implementar la seguridad del nivel de DBMS, para evitar así el acceso a los datos no válidos por parte de los tenants. Para los requisitos de personalización, utiliza un patrón híbrido: varios campos de datos fijos son reservados para cada cuadro predeterminado, pero todavía da soporte a los patrones del subcuadro. Este enfoque tiene claros beneficios. Puede proporcionar tanto una buena performance para los tenants con requisitos de personalización limitados como más flexibilidad a los tenants que necesitan campos más extendidos.


Aislamiento y personalización de las normas para la selección de personas/roles de los procesoes empresariales

En el nivel de proceso /área del trabajo empresarial, las plantillas son los recursos más importantes. Para dar soporte al desarrollo de aplicaciones multi-tenant, hay dos opciones:

  • Patrón de plantillas de procesos separados: en este caso, cada tenant posee un conjunto dedicado de plantillas de procesos. Las solicitudes de acceso de un tenant determinado deberían rutearse o enviarse a su plantilla o instancia de procesos correspondiente. Este enfoque permite realizar el aislamiento y la personalización al nivel del tenant más fácilmente. Sin embargo, presenta problemas evidentes de costos. Por ejemplo, si una aplicación posee 20 procesos BPEL, para dales soporte a 1.000 tenants, debería haber más de 20.000 plantillas de procesos.
  • Patrón de plantillas de proceso compartido: Todos los tenants comparten el mismo conjunto de plantillas de procesos. Éste es el enfoque que utilizaremos nosotros. El desafío es cómo aislar y personalizar aquellos dispositivos compartidos relacionados con el proceso, como el "verb" para las tareas humanas, la norma empresarial y el esquema de procesos.

En esta sección se describe un mecanismo específico para el aislamiento de resolución del personal para las plantillas de los procesos y las tareas humanas que puede seleccionar automáticamente y claramente los correspondientes roles/personas que pertenecen al mismo tenant con el iniciador de procesos. Puede dar soporte también a un tenant que personaliza sus propias normas de resolución de personal sin afectar a otros tenants.

En WebSphere Process Server, “Verb” (verbo) se utiliza para hacer la selección de personas/roles para las tareas humanas o procesos. Al momento de la ejecución, “Verb” es determinado por “Staff Resolution Plug-in” analizando sintácticamente los parámetros y consultado el almacén subyacente de los usuarios para elegir los roles adecuados. Generalmente, hay tres tipos de Staff Resolution Plug-ins que se envían con WPS, System, LDAP, UR, y algunos “Verbs” estándares predeterminados como “User, Group Members, Search etc.”

Sin embargo, en el contexto multi-tenant, si todos los tenants comparten el mismo conjunto de plantillas de procesos, los "verbs" y conectores estándares no funcionan bien dado que no comprenden la estructura organizativa y el almacén de usuario multi-tenant subyacente.

La Figura 14 muestra nuestros enfoques para resolver este problema desde los aspectos referido al tiempo de diseño, al tiempo de ejecución y a la administración:

  • En el momento de la creación, brindamos una serie de "verbs" de capacidad multi-tenant y un plug-in de resolución de personal multi-tenant correspondiente para que los desarrolladores los apalanquen en el diseño de las plantillas de procesos.
  • En el momento de la ejecución, el plug-in de diseño específico obtendrá en primer lugar la ID del tenant correspondiente del iniciador de la instancia de procesos, y luego consultará a las personas/los roles de la estructura organizativa dentro del alcance específico del tenant. Es importante señalar que todo esto se ejecuta implícitamente.
  • Con respecto a la administración, el administrador de un tenant puede personalizar fácilmente las normas de selección específicas de las personas/los roles para cualquier proceso o tarea humana eligiendo entre un conjunto de normas predeterminadas, sin afectar a otros tenants.
Figura 14. Plug-in de "verbs" y resolución del personal multi-tenant
Plug-in de

Las Figuras 15 y 16 muestran a EasyOA en el estrato de procesos para mostrar el resultado del apalancamiento de los mecanismos de aislamiento y personalización que hemos analizado anteriormente.

Figura 15. Aislamiento de selección de las personas/los roles
Aislamiento de selección de las personas/los roles
Figura 16. Personalización de la selección de las personas/los roles
Personalización de la selección de las personas/los roles

Conclusión

El patrón de diseño multi-tenant (por ejemplo, cuando se utiliza una única instancia de aplicaciones distribuidas para darles soporte a múltiples tenants simultáneamente) es muy importante para las aplicaciones entregadas a través de la Web en cuanto a la eficiencia en costos. En este artículo se analizó el diseño de la arquitectura de la aplicación única de instancia multi-tenant. Hemos presentado patrones de diseño multi-tenant desde cuatro aspectos diferentes incluyendo el mecanismo de seguridad, los dispositivos de J2EE, el modelo de datos y el proceso empresarial. Más adelante publicaremos más información sobre este tema en otros artículos.

Recursos

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=SOA y servicios web
ArticleID=507212
ArticleTitle=Desarrollo y Despliegue de soluciones multi-tenant entregadas a través de la Web utilizando el middleware de IBM: Parte 4: Patrones de diseño para la distribución de recursos en aplicaciones multi-tenant (para múltiples usuarios) de una sola instancia
publish-date=08262010