Desarrollo e implementación de soluciones de prestación a múltiples clientes vía Web usando middleware IBM: Parte 2: Enfoques para permitir la prestación a múltiples clientes

La Parte 1 de esta serie define a la prestación de servicios a múltiples clientes y presenta varios desafíos técnicos que surgen en la construcción e implementación de soluciones vía Web para múltiples clientes. En este artículo, se identifican cinco enfoques representativos que permiten la prestación de soluciones vía Web (también denominadas “software-as-a-service”, o “software como servicio”) a múltiples clientes, y se realiza una comparación de sus costos y beneficios.

Carl Osipov, Senior IT Architect, IBM

Carl Osipov es un arquitecto de software experimentado con la organización de Estrategia y Tecnología en IBM Software Group. Sus habilidades están en el área de la informática distribuida, desarrollo de aplicaciones de voz y entendimiento del lenguaje natural computacional. Ha publicado y presentado temas que incluyen la arquitectura orientada a servicios y la gestión del diálogo de conversación para iguales en la industria y la academia. Actualmente está enfocado en las analíticas y la optimización empresariales.



German Goldszmidt, Senior Technical Staff Member, IBM

Dr. German Goldszmidt is a Senior Technical Staff Member working in IBM Software Group, with focus on architecture of an integrated platform to deliver, customize, and deploy SOA composite applications to enable business services.



Mary Taylor, Senior IT Architect, IBM

Author Photo: Mary TaylorMary Taylor is a senior software engineer. She is working in the Strategic Technology Architecture and Incubation team, and she is currently working on an SOA CBS pilot. Her interests include DB2 and DataStage.



Indrajit Poddar, Advisory Software Engineer, IBM

Indrajit Poddar is a software architect for IBM Software Group Technical Strategy, where he leads incubation projects in strategic technology areas such as distributed cloud computing, DevOps, and software-defined infrastructure. He is an IBM Master Inventor and a recipient of three IBM Outstanding Technical Achievement awards.



05-08-2011

Introducción

Los proveedores de servicios que consideran la entrega de servicios web nuevos o existentes a múltiples clientes suelen enfrentarse con una serie de opciones de diseño. Hemos identificado cinco enfoques principales, los cuales se muestran en la Figura 1. El Enfoque 1 se basa en una única instancia de aplicación compartida, es decir que todos los clientes poseen los mismos servidores, middleware y aplicaciones. El Enfoque 5 se basa en instancias de aplicaciones específicas para cada cliente, que se ejecutan en servidores separados. Este último es el diseño que emplean actualmente muchos proveedores de servicios de aplicaciones (ASP). Entre estos dos extremos, se identificaron por lo menos tres enfoques de importancia que requieren de distintos grados de recursos compartidos y complejidad de desarrollo. Cada enfoque brinda distintos beneficios en base a sus eficiencias de escala y operativas, y distintos costos en relación con las complejidades de desarrollo y el tiempo en salir al mercado.

Figura 1. Cinco principales enfoques de la prestación de servicios a múltiples clientes
Cinco principales enfoques de la prestación de servicios a múltiples clientes

En este artículo, emplearemos los siguientes roles para describir los distintos enfoques de la prestación a múltiples clientes:

  1. Proveedor de servicios: responsable de proveer los servicios/la solución en el modelo de prestación vía Web
  2. Desarrollador de servicios: desarrollador de los servicios/la solución que se ofrece
  3. Cliente: cliente del proveedor de servicios
  4. Usuarios finales: un cliente puede tener uno o más usuarios finales del servicio/la solución

Los cinco principales enfoques que pueden utilizar los proveedores de servicios son:

  1. Middleware compartido con una única instancia de aplicación
  2. Middleware compartido con instancias de aplicación múltiples y espacios de direcciones compartidos
  3. Middleware compartido con instancias de aplicación múltiples y espacios de direcciones separados
  4. Virtualización con imágenes virtuales específicas para cada cliente
    a). Virtualización con un nivel de mediación
  5. Modelo ASP con instancias múltiples en servidores separados

Describiremos los cinco enfoques con mayor profundidad a lo largo de las siguientes secciones. Al momento de determinar el enfoque a adoptar, es útil comprender los costos y beneficios asociados a cada uno de ellos. Es por ello que, en una sección posterior, presentamos un análisis de costo/beneficio.


Enfoques de middleware compartido

Los enfoques 1, 2 y 3 representan diferentes grados de middleware y componentes de aplicaciones compartidos entre múltiples clientes. En los siguientes puntos mostraremos ejemplos de cada uno de estos enfoques.

Enfoque 1: middleware compartido con una única instancia de aplicación

Todos los clientes comparten el sistema operativo, los servidores y una misma instancia del middleware y la aplicación. Esto se logra a través de la parametrización de una única instancia de una aplicación con un parámetro de identificación del cliente. Por ejemplo, si la aplicación tiene interfaces e implementaciones de servicio web, se agregará un parámetro de ID de un cliente a las operaciones y los objetos de datos de la interfaz; o, si la aplicación usa tablas de bases de datos, se agregará una nueva columna que designe el ID del cliente a cada tabla de la base de datos. En este modelo, existen una serie de elementos de configuración que le son únicos a cada cliente. Por ejemplo, se configura un portal virtual con un aspecto visual distinto para cada cliente y cada cliente posee elementos de esquema de bases de datos únicos.

Figura 2. Ejemplo de topología del Enfoque 1; una única instancia de la aplicación y el middleware compartida entre múltiples clientes
Ejemplo de topología del Enfoque 1; una única instancia de la aplicación y el middleware compartida entre múltiples clientes

En la Figura 2 se observa una topología de muestra que emplea este enfoque. Existen tres clientes (A, B y C) quienes comparten un mismo código correspondiente a la Aplicación 1. La Aplicación 1 usa Tomcat y DB2 con ejecución en Windows en un servidor Blade, y un servidor HTTP Apache que se ejecuta en Linux en otro servidor físico. El middleware, el sistema operativo y los servidores se comparten entre todos los clientes. Puede descargar un código de muestra para un ejemplo de aplicación para múltiples clientes que emplea este enfoque desde “Building Web delivered SaaS applications on open source and entry level IBM middleware”. Cuando se ingresa un cliente, se crean configuraciones especificas para el cliente (ej.: archivos CSS para cada cliente), pero existe solo una instancia de la aplicación, que se comparte entre todos los clientes. Con este enfoque, la aplicación debe estar diseñada para brindar la capacidad de mantener los datos y las personalizaciones de cada cliente aislados de los de los otros clientes. Las Partes 3 y 4 de esta serie presentarán importantes consideraciones arquitectónicas necesarias para emplear este enfoque y permitir la prestación de servicios a múltiples clientes con IBM WebSphere Application Server.

Enfoque 2: Middleware compartido con instancias de aplicación múltiples y espacios de direcciones compartidos

Los clientes usan distintas instancias de la aplicación implementadas en una única instancia de middleware, las cuales comparten un único proceso de sistema operativo (espacio de direcciones). Los clientes comparten el sistema operativo y los servidores. La Figura 3 muestra una aplicación de ejemplo compartida por los clientes A, B y C que emplea este enfoque.

Figura 3. Ejemplo de topología del Enfoque 2; ejecución de diferentes instancias de aplicación para diferentes clientes en una única instancia de middleware
Ejemplo de topología del Enfoque 2; ejecución de diferentes instancias de aplicación para diferentes clientes en una única instancia de middleware

Cuando se ingresa un nuevo cliente, se crea una copia separada de la aplicación y se le da un nombre que incluye un identificador de cliente. Esta se implementa en una instancia compartida del servidor de aplicaciones. Por ejemplo, el archivo EAR correspondiente a Application App (App.ear) se copiará y nombrará App1.ear y App2.ear, respectivamente. De la misma manera, en el nivel de base de datos, una tabla de aplicaciones nombrada App_table se copiará en dos tablas App1_table y App2_table para los clientes A y B, respectivamente. Las personalizaciones específicas para cada cliente (ej.: archivos CSS y esquemas de tabla) se agregan a la copia de la aplicación y la tabla específica del cliente. Este modelo requiere mantener el aislamiento de clientes en el nivel de middleware.

Enfoque 3: Middleware compartido con instancias de aplicación múltiples y espacios de direcciones separados

Los clientes usan distintas instancias de la aplicación implementadas sobre diferentes instancias de middleware. Los clientes comparten el sistema operativo y los servidores. Debido a que la instancia de middleware es distinta, a cada cliente se le asigna su propio conjunto de procesos de sistema operativo (es decir, espacio de direcciones). En consecuencia, este modelo requiere mantener el aislamiento de clientes en el nivel de sistema operativo. Este enfoque soporta una menor cantidad de clientes que los enfoques 1 y 2 sobre un mismo servidor físico. De los tres enfoques de middleware compartido, éste es el que ofrece un mayor aislamiento entre clientes. Sin embargo, la problemática del aislamiento se mantiene en las capas de sistema operativo y de servidores, por lo que, por ejemplo, los usuarios de un cliente podrían consumir toda la CPU o memoria del servidor físico.

Figura 4. Ejemplo de topología del Enfoque 3; ejecución de diferentes instancias de aplicación para diferentes clientes en distintas instancias de middleware
Ejemplo de topología del Enfoque 3; ejecución de diferentes instancias de aplicación para diferentes clientes en distintas instancias de middleware

En el ejemplo de la Figura 4, vemos que cada cliente (A, B y C) ejecuta su propia copia física de la misma aplicación (App1, App2 y App3, respectivamente), en su propia copia física del middleware (M1, M2 y M3, respectivamente). Los clientes A y B ejecutan sus aplicaciones en Windows, mientras que el cliente C ejecuta su aplicación en Linux. De los tres enfoques de middleware compartido, éste es el que requiere de la menor cantidad de cambios sobre una aplicación existente, y, posiblemente esto permita una ejecución más rápida. En una próxima demostración de la serie SaaS Blueprints se mostrará un ejemplo de este enfoque usando WebSphere Smash y MySQL como middleware que ejecuta una aplicación bulletin board phpBB para múltiples clientes.


Enfoques de virtualización

La tecnología de virtualización se usa para ejecutar particiones de sistemas operativos múltiples con instancias de aplicación y middleware dedicadas a cada cliente en servidores compartidos.

Enfoque 4: Virtualización con imágenes de VM múltiples

Los clientes usan diferentes imágenes virtuales con diferentes instancias de aplicación, middleware y sistema operativo pero comparten los servidores físicos. En los últimos años, la virtualización de servidores ha gozado de una adopción generalizada en servidores basados en x86 y rápidamente se está convirtiendo en una tecnología commodity de bajo costo.

A diferencia del enfoque de middleware compartido, la virtualización de servidores no requiere de importante desarrollo de códigos para permitir la prestación a múltiples clientes. Una vez que se instala la virtualización de servidores en el servidor físico (host o anfitrión), el proveedor de servicios provee a cada cliente adicional instanciando un servidor virtual (huésped) para que hospede software específico para el cliente, incluyendo su middleware y aplicaciones.

Uno de los desafíos técnicos de la prestación a múltiples clientes es cómo proveer a los clientes nuevos. Para proveer a los clientes nuevos, los proveedores de servicios deben trabajar con pasos de instalación y configuración potencialmente extensos. Los dispositivos virtuales (ej.: VMWare Virtual Appliance for WebSphere Application Server Network Deployment V7.0 Open Beta) que ofrecen un sistema operativo-middleware específico para cada cliente preconfigurado ayudan a enfrentar este desafío.

La Figura 5 muestra un ejemplo de este enfoque en el que se instala un hipervisor nativo como VMWare ESX™ o Xen en servidores físicos. En este ejemplo, un servidor Blade físico de 2 CPU de 2 Ghz “A” (en el recuadro verde, al final) se particiona en 2 servidores Virtual Blade de CPU única de 2 Ghz: vBlade 1 y vBlade 2 (en el recuadro negro). Servidor Virtual Blade: vBlade 3 está formado por un único servidor de 4 CPU de 2Ghz “B”. Los servidores virtuales también comparten otros recursos del servidor físico, como la memoria, el espacio de disco y la conexión de red. Aplicaciones: App4, App5 para dos clientes distintos, implementadas en vBlade 1 y vBlade 2, y App6 implementada en vBlade 3. Tenga en cuenta que los clientes pueden tener distintos sistemas operativos.

Figura 5. Virtualización de servidores basada en un hipervisor nativo para prestación a múltiples clientes
Virtualización de servidores basada en un hipervisor nativo para prestación a múltiples clientes

Enfoque 4a: virtualización con un nivel de mediación

Un proveedor de servicios centraliza las funciones comunes a múltiples clientes como el enrutamiento, el control de accesos y la medición en un nivel proxy de mediación. Se puede usar un nivel de mediación en conjunto con un enfoque de virtualización a través de la integración con instancias de servicios específicas de cliente que se ejecuten en particiones de imágenes virtuales separadas. El nivel proxy de mediación se ubica entre el usuario final de la aplicación y los servicios dentro de la aplicación y enlaza o enruta dinámicamente solicitudes de servicio de los usuarios de un cliente hacia instancias específicas de cliente de los servicios, como muestra la Figura 6.

La Figura 6 también describe un ejemplo del enfoque de mediación en el cual el proveedor de servicios usa un dispositivo WebSphere DataPower SOA (WDP) para implementar un nivel proxy de mediación. En este ejemplo, las reglas de enrutamiento se configuran en un proxy de servicio web WDP para enrutar solicitudes de usuarios de dos clientes distintos (A y B) hacia la instancia de una aplicación específica del respectivo cliente. Además, las funciones de múltiples clientes como la medición, el control de accesos y la auditoría se agregan a través de la integración de otros componentes de middleware como Tivoli Access Manager y Tivoli Usage and Accounting Manager.

Figura 6. Ejemplo de un enfoque de mediación para la prestación a múltiples clientes usando dispositivos WebSphere DataPower SOA
Ejemplo de un enfoque de mediación para la prestación a múltiples clientes usando dispositivos WebSphere DataPower SOA

En las partes 5, 6, 7 y 8 de esta serie, se presentarán tres opciones alternativas para la implementación de este enfoque usando la siguiente combinación alternativa de productos:

  • WebSphere Business Services Fabric
  • Dispositivos WebSphere DataPower SOA con Tivoli Access Manager
  • WebSphere Enterprise Services Bus con WebSphere Service Registry and Repository

Enfoque 5: Modelo ASP con instancias múltiples en servidores separados

Los clientes comparten solo la infraestructura del centro de datos (ej: energía, refrigeración) pero usan diferentes instancias de aplicación, middleware, sistema operativo y servidores. La Figura 7 muestra un ejemplo en el cual los clientes A, B y C tienen tres diferentes instancias de aplicación (AppA, AppB y AppC) que se ejecutan en instancias de sistema operativo, servidores físicos e instancias de middleware específicos para el cliente. Este enfoque resulta más adecuado para cargas de trabajo y escenarios en los que se requiere de un alto grado de aislamiento y personalización para cada cliente.

Figura 7. Ejemplo de un modelo ASP que permite la prestación a múltiples clientes con instancias múltiples en servidores separados
Ejemplo de un modelo ASP que permite la prestación a múltiples clientes con instancias múltiples en servidores separados

Comparación costo-beneficio de los enfoques de prestación a múltiples clientes

El análisis costo-beneficio que se presenta en esta sección se realiza desde la perspectiva del proveedor de servicios y del desarrollador de servicios.

El enfoque 5 (es decir, el enfoque ASP) es el más costoso para el proveedor de servicios cuando se escala a un número elevado de clientes. En los otros cuatro enfoques, existe un mayor grado de recursos compartidos que conlleva a la mejora de las eficiencias de costos y genera economías de escala, como lo muestran las dos flechas amarillas de la Figura 1. Se pueden generar los siguientes tipos de costos específicos de clientes:

  • Servidor físico: Cada cliente requiere de servidores dedicados, espacio de disco y equipo auxiliar.
  • Administración: Los servidores y, en especial, el software, requieren de mantenimiento continuo que puede comprender la instalación de parches de seguridad, la actualización de versiones del sistema operativo y el middleware, la gestión de cuentas de usuarios y demás. Estas tareas deben llevarse a cabo de manera separada en las infraestructuras de cada cliente.
  • Operación: el funcionamiento de un centro de datos genera gastos de electricidad, refrigeración e inmobiliarios que crecen significativamente al agregar más clientes.

Sin embargo, este enfoque es el que resulta más económico para un desarrollador de servicios, ya que no se requiere de cambios de aplicaciones para permitir la prestación a múltiples clientes. Además, este enfoque ofrece el grado más alto de aislamiento entre clientes y de personalización de instancias específicas de clientes.

Los enfoques 1 a 3 (es decir, los enfoques de middleware compartido) poseen el menor costo operativo de los modelos de este tipo debido a que cuentan con una mayor cantidad de recursos compartidos (servidores, middleware y sistemas operativos) que conlleva a la existencia de un menor número de componentes a gestionar. Este enfoque también ofrece eficiencias de escala gracias a que permite una mayor densidad de clientes hospedados en un único servidor físico. El enfoque 1 (es decir, la instancia de aplicación única) podría resultar la opción más costosa para el desarrollador de servicios porque podría demandar un importante trabajo de rediseño de las aplicaciones existentes que se traduciría en extensos tiempos de desarrollo y altos costos. Además, este enfoque requiere de conocimientos de características y técnicas de servidores de aplicaciones avanzadas y desarrolladores expertos.

El enfoque 4 (es decir, imágenes virtuales múltiples) resulta más económico para el desarrollador de servicios que los enfoques de middleware compartido (enfoques 1 a 3) debido a que prácticamente no se requiere de cambios de aplicaciones. Esto permite una salida al mercado más rápida y conveniente. El agregar un nivel de mediación (enfoque 4a) al enfoque de virtualización también reduce la complejidad y el tiempo dedicado a integrar otras funciones que permitan la prestación a múltiples clientes como el control de accesos y la medición.

La Tabla 1 es un resumen de la comparación costo-beneficio entre los enfoques de middleware compartido (1 a 3) y el enfoque de virtualización (4 y 4a).

Tabla 1. Comparación costo-beneficio de tres enfoques principales de la prestación a múltiples clientes
Enfoques de middleware compartidoVirtualización y virtualization con mediación
Beneficios
  • Habilidad de ESCALAR a clientes adicionales rápidamente
  • EFECTIVO EN CUANTO A COSTOS ya que todos los clientes comparten la misma infraestructura
  • MENORES GASTOS GENERALESque un enfoque virtualizado o mediado
  • No se requiere de REDISEÑO
  • Algunos cambios menores de códigos de integración podría ser necesarios para lograr eficientes CARACTERÍSTICAS DE PRESTACIÓN A MÚLTIPLES CLIENTES COMUNES ADICIONALES como, por ejemplo:
    - Control de accesos
    - Medición
    - HETEROGENEIDAD y transformación en el protocolo y las interfaces en aplicaciones específicas de clientes
  • MÁS RÁPIDA salida al mercado MENORES costos iniciales
  • Aislamiento para una mejor SEGURIDAD y DISPONIBILIDAD para los clientes
  • Se ofrece un mayor grado de PERSONALIZACIÓN del hardware y el sistema operativo que en un ambiente compartido
    - Soporte a la HETEROGENEIDAD (sistema operativo, hardware) de las aplicaciones de clientes
  • Es más fácil REUBICAR la aplicación en otro proveedor de plataforma
  • Es más simple el BACKUP y la RECUPERACIÓN DE DESASTRES para cada cliente
Costos
  • Requiere de REDISEÑO de aplicaciones o CAMBIOS DE CÓDIGOS con respecto al único código de cliente existente en el enfoque 1
  • TIEMPO DE SALIDA AL MERCADO, impacto sobre esta variable debido a la rearquitectura de aplicaciones necesaria para la prestación a múltiples clientes
  • MAYORES COSTOS INICIALES cuando es necesario realizar cambios de códigos
  • SE REQUIERE DE PROGRAMADORES EXPERTOSpara implementar el enfoque 1
  • COMPLEJIDAD AGREGADA Para proveer características como backup y restauración personalizada para cada cliente
  • MENOR ESCALABILIDAD de la cantidad de clientes por servidor
  • MAYORES GASTOS GENERALES DE RENDIMIENTO
  • MAYORES COSTOS OPERATIVOS y COSTOS DE GESTIÓN debido a las instancias múltiples de imágenes de máquinas virtuales
  • MAYORES COSTOS DE IMPLEMENTACIÓN al implementarse en un nivel de mediación

Conclusión

La progresión desde un modelo de proveedor de servicios de aplicaciones tradicional hacia un modelo de prestación vía Web abarca muchos puntos/enfoques que presentan distintos costos y beneficios para el proveedor de servicios y el desarrollador de servicios. Hemos analizado cinco de esos puntos que difieren en grado de recursos compartidos y complejidad de desarrollo. Los objetivos de esta progresión son continuar mejorando las eficiencias de costos y reduciendo el costo total de propiedad. Este artículo muestra una serie de pros y contras a ser tomados en cuenta en la elección del punto correcto y la preparación de arquitecturas adecuadas para la realización de mejoras que se sumen para acercarse cada vez más al objetivo.


Agradecimientos

Los autores quisieran agradecer las contribuciones de Ajay Mohindra y Suresh N. Chari de IBM Research en la Figura ,1 que describe los principales enfoques de prestación a múltiples clientes.

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=966703
ArticleTitle=Desarrollo e implementación de soluciones de prestación a múltiples clientes vía Web usando middleware IBM: Parte 2: Enfoques para permitir la prestación a múltiples clientes
publish-date=08052011