Desarrollar e implementar soluciones multiempresa entregadas a través de la Web usando middleware de IBM, Parte 1: Desafíos y patrones arquitectónicos

Las soluciones entregadas a través de la Web que siguen un modelo de entrega de “software como un servicio” (SaaS)—en el que los clientes se suscriben a un software y acceden a él desde un sitio del proveedor de servicios en lugar de obtener licencias y hacer instalar el software en sus equipos—pueden ofrecer un indiscutible valor de negocios a empresas de cualquier tamaño. Tanto los desarrolladores que crean nuevas soluciones o transforman las soluciones existentes como los proveedores de servicios que implementan tales soluciones deben hacer frente a numerosos desafíos técnicos. Un ejemplo de ello es la multiempresa, donde una única instancia de software se ejecuta en las instalaciones del proveedor de servicios y sirve a organizaciones múltiples. Esta serie de artículos describe diferentes patrones para abordar estos desafíos, usando frecuentemente técnicas de Arquitectura Orientada a Servicios. Aprenda también cómo los productos de software de IBM® pueden ayudarlo a crear e implementar soluciones multiempresa entregadas a través de la Web que sean escalables, configurables y rentables.

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.



05-08-2011

¿Qué es la multiempresa y cuáles son sus ventajas y desventajas?

La capacidad de entregar software a múltiples organizaciones cliente (o arrendatarios) a partir de una única instancia compartida de software es un requisito importante para las soluciones entregadas a través de la Web. Considere, por ejemplo, una simple aplicación bancaria ofrecida como un servicio por un proveedor de servicios bancarios. La multiempresa, en este contexto, se refiere a la capacidad de ofrecer el servicio bancario a múltiples bancos a partir de una única instancia compartida de la aplicación bancaria. La Figura 1 ilustra un servicio bancario multiempresa ofrecido a dos bancos—1st Bank N.A. y 2nd Canada Bank—desde servidores de aplicaciones, bases de datos, sistemas operativos y servidores físicos compartidos.

Muestra de servicio bancario multiempresa entregado a través de la Web y creado usando middleware y hardware compartido

El principal beneficio de la multiempresa es su rentabilidad. El hecho de compartir software, hardware, desarrollo de aplicaciones y costos de mantenimiento entre los arrendatarios puede hacer disminuir los costos para cada uno de los arrendatarios. Asimismo, el hecho de compartir una única instancia de una aplicación entre arrendatarios puede ofrecer beneficios adicionales, por ejemplo, que todos los arrendatarios obtengan una actualización simultánea cada vez que se actualice la aplicación.

Sin embargo, la multiempresa también acarrea inconvenientes potenciales, tales como:

  • Aislamiento: Dado que los arrendatarios comparten la misma instancia del software y del hardware, es posible que un arrendatario afecte la disponibilidad y el desempeño del software de otros arrendatarios. Por ejemplo, si el software compartido no tiene las medidas de seguridad adecuadas, podría suceder que el usuario de un arrendatario haga caer el software compartido, privando de este modo del servicio a todos los arrendatarios que compartan esa instancia.
  • Seguridad: Si el software compartido no tiene las medidas de seguridad adecuadas, podría suceder que los usuarios de un arrendatario puedan acceder a datos pertenecientes a otro arrendatario.
  • Personalización: Dado que el software se comparte entre los arrendatarios, puede no ser posible personalizar el software para cada uno de ellos. Por ejemplo, si no se cuenta con puntos de extensión adecuados, puede no ser viable que un arrendatario proporcione su propia implementación de un proceso de negocios.
  • Las actualizaciones de las aplicaciones pueden causar problemas a los arrendatarios: La actualización simultánea del software compartido puede no ser deseable para todos los arrendatarios.
  • Recuperación: El hecho de compartir la base de datos entre los arrendatarios dificulta la tarea de salvaguardar y restaurar separadamente los datos de cada arrendatario.

Si bien hay múltiples enfoques para construir una arquitectura multiempresa, ese artículo se centra principalmente en las técnicas que permiten compartir una única instancia del middleware y de la base de datos, así como aplicaciones entre múltiples arrendatarios.

Otros enfoques de la multiempresa incluyen la virtualización a nivel del sistema operativo (SO). Por ejemplo, VMWare, Xen u OpenVZ permiten que se ejecuten instancias virtuales múltiples del SO en una instancia compartida de hardware. Cada instancia virtual del SO puede ejecutar el software para un arrendatario diferente. Otro enfoque puede ser establecer límites a nivel del SO para cada arrendatario. Por ejemplo, la aplicación de cada arrendatario podría estar ejecutándose en una nueva instancia (diferente proceso del SO) de IBM WebSphere® Application Server.


Desafíos técnicos de la multiempresa

Los desafíos técnicos de las aplicaciones multiempresa se pueden categorizar en términos de las principales organizaciones e individuos que enfrentan tales desafíos: los desarrolladores de soluciones y los proveedores de servicios.

Los desafíos técnicos que enfrentan los desarrolladores de soluciones incluyen:

  • Control de acceso: ¿Cómo pueden compartirse los recursos de aplicaciones—, por ejemplo, portales virtuales, tablas de bases de datos, flujos de trabajo, servicios web o artefactos Java™2Platform, Enterprise Edition (J2EE)—entre los arrendatarios, de manera tal que los usuarios que pertenezcan a un arrendatario determinado puedan acceder sólo a las instancias que pertenezcan a ese arrendatario? Por ejemplo, ¿cómo puede uno asegurarse de que los usuarios de un banco (como el 1st Bank N.A.) no puedan acceder a los recursos (como el portal virtual) de otro banco (como el 2nd Canada Bank)?
  • Personalización:
    • Base de datos: ¿Cómo se puede personalizar un esquema compartido de base de datos para un arrendatario sin afectar a los restantes? Por ejemplo, ¿cómo podría introducir el 2nd Canada Bank un nuevo campo de datos en la tabla compartida de la base de datos para sus perfiles de cliente sin que esto tenga impacto en la definición del esquema para el 1st Bank N.A.?
    • Interfaz de usuario: ¿Cómo es posible habilitar la personalización de la apariencia del sitio Web a través de la configuración solamente (es decir, sin cambios en el código)? Por ejemplo, ¿cómo es posible asegurarse de que los administradores del 1st Bank N.A. y del 2nd Canada Bank puedan configurar diferentes diseños y mostrar campos adicionales en sus portlets de perfil de cliente?
    • Lógica de negocios: ¿Cómo es posible permitir la personalización de la lógica de negocios para cada arrendatario sin hacer cambios en el código? Por ejemplo, ¿cómo puede usar el 1st Bank N.A. una puntuación de crédito mínima para rechazar automáticamente solicitudes de préstamos (la cual es diferente a la del 2nd Canada Bank)?
    • Flujos de trabajo: ¿Cómo se puede permitir que los bancos arrendatarios personalicen la asignación de las tareas humanas y otras tareas condicionales en flujos de trabajo compartidos? Por ejemplo, ¿cómo podría asegurar el 1st Bank N.A. que sus tareas de aprobación de préstamos en flujos de trabajo compartidos se asignaran solamente a los empleados del 1st Bank N.A.?
  • Aprovisionamiento de arrendatarios: ¿Cómo es posible automatizar el aprovisionamiento de un nuevo arrendatario? Por ejemplo, cómo es posible incorporar un nuevo banco, el 3rd Fairfield Trust, con sólo unos pocos pasos manuales (esto es, ¿cómo pueden automatizarse pasos tales como la creación de un nuevo subárbol o base de datos LDAP, la construcción de un nuevo portal virtual, la implementación de nuevas instancias de portlets y el registro de nuevos esquemas IBM DB2® XML?)
  • Medición basada en el uso: ¿Cómo registrar el uso de los servicios de manera que a cada arrendatario se le pueda cobrar sólo el uso de un determinado servicio? Por ejemplo, ¿cómo puede medir el administrador del proveedor del servicio bancario el uso del servicio para cada uno de los arrendatarios, 1st Bank N.A. y 2nd Canada Bank, según el número de veces que sus clientes hayan invocado el servicio de solicitud de préstamos?

Los desafíos técnicos que enfrentan los proveedores de servicios incluyen:

  • El intercambio de bases de datos, la personalización, la salvaguarda (creación de copias de seguridad) y la restauración de datos específicos del arrendatario: ¿Cómo pueden elegir los proveedores de servicios entre diferentes esquemas de partición de bases de datos en base a criterios de desempeño, administración y escalabilidad? Por ejemplo, ¿cómo puede adecuar el proveedor del servicio los requisitos de recuperación de datos en caso de desastres del 2nd Canada Bank, de manera de salvaguardar sólo sus datos en las tablas compartidas entre múltiples arrendatarios?
  • Habilitación rápida de la multiempresa en servicios web existentes: ¿Cómo es posible permitir las implementaciones de servicios web para un único arrendatario dentro de la multiempresa con sólo unos pocos cambios en el código o incluso sin hacer cambios en el mismo? Por ejemplo, ¿cómo se podría habilitar la multiempresa para un servicio de comprobación de crédito para un único arrendatario sin hacer cambios en el código con respecto a la interfaz y la implementación del servicio web?
  • Administración de la conectividad entre un gran número de proveedores de servicios de terceras partes y los consumidores de servicios departamentales en una gran empresa: Las líneas de negocio (LOB) dentro de las grandes empresas exhiben muchas de las características de un arrendatario en una aplicación entregada a través de la Web. Las diferentes LOB de la misma empresa pueden consumir servicios de terceras partes distintas o de proveedores internos de servicios. Tener una gran cantidad de proveedores de servicios puede dar lugar a problemas de administración para el departamento central de TI de la empresa. Por ejemplo, diferentes LOB (tales como los departamentos de líneas de crédito y préstamos hipotecarios) de la empresa proveedora de servicios bancarios pueden usar diferentes proveedores de servicios de comprobación de créditos. ¿Cómo hace entonces el departamento central de TI para monitorear, autorizar y medir el uso de servicios múltiples de comprobación de créditos brindados por diferentes LOB dentro de la empresa?
  • Escalabilidad, uso mejorado del hardware y calidad de servicio (QoS) específica del arrendatario: ¿Cómo pueden mejorar los proveedores de servicios el uso del hardware que se comparte entre diferentes arrendatarios y a su vez proporcionar escalabilidad? ¿Cómo pueden ofrecer los proveedores de servicios QoS diferenciadas para diferentes arrendatarios? Por ejemplo, ¿cómo adecuaría usted los requisitos diferenciados de QoS del 2nd Canada Bank de manera que sus servicios se alojen en un hardware dedicado, a cambio de mayores tarifas por el uso de los servicios?

Patrones para abordar los desafíos técnicos de la multiempresa

Usted puede aplicar varias técnicas de SOA para abordar los desafíos técnicos relacionados con la multiempresa.

Patrones para desarrolladores de soluciones

  • Comience en pequeño con middleware de nivel inicial basado en estándares: Un próximo artículo de esta serie le explicará cómo desarrollar una aplicación multiempresa entregada a través de la Web usando middleware de nivel inicial de IBM. Esta pila de middleware de nivel inicial incluye IBM WebSphere Application Server Community Edition, IBM DB2 Express-C y OpenLDAP. Las soluciones desarrolladas para la pila de nivel inicial pueden dar a los proveedores de servicios la opción de comprar soporte de IBM. Mire una demostración y descargue el código de muestra correspondiente a una aplicación creada usando la pila de nivel inicial. La Figura 2 ilustra las diferentes capas funcionales de la aplicación multiempresa de muestra. En los próximos artículos de esta serie se le explicará cómo combinar la pila de nivel inicial con algunos productos de la pila de nivel empresarial como Tivoli® Usage and Accounting Manager y WebSphere Application Server, Extended Edition de IBM, de manera de dar soporte a la medición, la escalabilidad y el aislamiento. Capas funcionales de una aplicación multiempresa de muestra creada usando middleware de IBM
  • Pásese a middleware de nivel empresarial: Si bien puede ser más sencillo empezar con una pila de nivel inicial, a menudo las cuestiones que atañen a las características avanzadas, la escalabilidad, el desempeño y la integración suelen abordarse de manera inadecuada con este enfoque. Por lo tanto, si se necesita construir aplicaciones entregadas a través de la Web que sean críticas para la misión, es conveniente usar middleware de nivel empresarial. En una serie de demostraciones registradas, a las que usted puede acceder a través de la serie de demostraciones de SaaS, describimos las características múltiples de una pila de middleware de IBM de nivel empresarial y las técnicas que se pueden usar para desarrollar soluciones multiempresa entregadas a través de la Web. Los detalles técnicos adicionales para cada demostración se incluyen en un conjunto de artículos incluidos en la sección Recursos. Los tópicos presentados en la serie de demostraciones incluyen:

La Figura 3 muestra cómo abordan estas capas funcionales los diferentes productos de middleware de IBM de la pila de nivel inicial y de la pila de nivel empresarial.

Productos de middleware de IBM usados para implementar las capas funcionales en la aplicación multiempresa de muestra, creada usando middleware de IBM

Esta serie de artículos se basa en los artículos y las demostraciones anteriores, y describe algunas técnicas avanzadas para construir aplicaciones multiempresa usando middleware de IBM. Por ejemplo, un artículo explica cómo aislar las tareas humanas en flujos de trabajo multiempresa compartidos en WebSphere Process Server. Otro artículo describe cómo usar Tivoli Usage and Accounting Manager para proporcionar mediciones basadas en el uso y soluciones de facturación.

Patrones para el proveedor de servicios

  • Elija el nivel adecuado de aislamiento del nivel de datos para la personalización y facilidad de manejo de datos de arrendatarios: Los proveedores del servicio pueden elegir entre:
    • Aislar los datos para cada arrendatario en bases de datos diferentes.
    • Aislar los datos para cada arrendatario en tablas separadas y un esquema.
    • Compartir el mismo juego de tablas y esquema entre todos los arrendatarios.
    Al compartir el esquema entre arrendatarios, la personalización de los campos de datos para cada arrendatario representa un desafío. En un próximo artículo de esta serie se evaluará un conjunto de patrones para abordar este desafío desde muchas dimensiones, incluyendo el desempeño, la administración y la escalabilidad. La TI pone en evidencia también algunas técnicas para mejorar la manejabilidad, por ejemplo, mostrando cómo adecuar la salvaguarda y el restablecimiento de datos específicos de arrendatarios al compartir el esquema entre todos los arrendatarios.
  • Habilitar rápidamente la multiempresa para los servicios web existentes usando los instrumentos de SOA WebSphere Enterprise Service Bus, WebSphere Business Services Fabric o WebSphere DataPower® de IBM: Los proveedores de servicios pueden necesitar habilitar rápidamente la multiempresa para la implementación de un servicio web existente. El hecho de hacer cambios en el código de implementaciones existentes para dar soporte a la multiempresa partiendo desde cero puede requerir un esfuerzo considerable. De manera alternativa, es posible construir una capa de mediación basada en middleware para habilitar diferentes puntos finales de servicios web a las solicitudes de servicio para diferentes arrendatarios. En este caso, no es necesario modificar la implementación del servicio web existente. Un próximo artículo de esta serie le mostrará cómo es posible implementar este patrón usando los instrumentos de SOA WebSphere Business Services Fabric, WebSphere Enterprise Services Bus y WebSphere DataPower.
  • Enrutar invocaciones de servicios SaaS de terceras partes en grandes empresas a través de una capa de mediación central: El departamento de TI de una empresa puede usar una capa de mediación central para enrutar todas las invocaciones de servicios de terceras partes desde los diferentes departamentos de una organización. Este tipo de capa de mediación puede proporcionar funciones adicionales como autorización, monitoreo y medición para el uso de servicios. Un próximo artículo de esta serie le explicará cómo un patrón de mediación basado en un bus de servicio empresarial (ESB) puede dar soporte a este tipo de requisitos.
  • Escale con middleware de nivel inicial y mejore el uso del hardware usando WebSphere Application Server, Extended Edition de IBM: Los requisitos de escalabilidad suelen no recibir al comienzo la consideración adecuada. Cuando estos requisitos se vuelven significativos, los proveedores de servicio generalmente escalan horizontalmente con un gran número de servidores pequeños y de bajo costo. Sin embargo, el hecho de escalar horizontalmente podría generar otros desafíos. Por ejemplo, este enfoque podría:
    • Llevar a un exceso de aprovisionamiento de hardware para soportar picos de carga infrecuentes para unos pocos arrendatarios.
    • Aumentar la complejidad de la administración debido a un gran número de instancias de middleware.
  • Aislar aplicaciones para diferentes arrendatarios y dar soporte a los requisitos de QoS específicos de cada arrendatario con WebSphere Application Server, Extended Edition: Los proveedores de servicios pueden aislar la aplicación de un arrendatario en un hardware dedicado, ejecutando a la vez las aplicaciones de otros arrendatarios en un hardware compartido, explotando la política de aislamiento del servidor de WebSphere Extended Deployment de IBM. Asimismo, los desarrolladores de soluciones pueden aprovechar el modelo de programación de la característica WebSphere Partitioning Facility de WebSphere Extended Deployment para crear aplicaciones habilitadas para multiempresa. Un próximo artículo le mostrará cómo usar WebSphere Extended Deployment para dar soporte a requisitos de QoS específicos de cada arrendatario y a aplicaciones de partición para la multiempresa.

Conclusión

La multiempresa escalable es un requisito importante para las soluciones entregadas a través de la Web (SaaS). Sin embargo, crear soluciones multiempresa exige abordar numerosos desafíos técnicos. A través del middleware de IBM, los desarrolladores de soluciones y proveedores de servicios pueden crear e implementar soluciones multiempresa escalables, personalizables, manejables y rentables. Esta serie de artículos presenta algunas de las características y técnicas del middleware de IBM y describe cómo aplicar las mismas para abordar los desafíos técnicos anteriormente citados. ¡Manténgase en sintonía!

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=SOA y servicios web , Lotus
ArticleID=965744
ArticleTitle=Desarrollar e implementar soluciones multiempresa entregadas a través de la Web usando middleware de IBM, Parte 1: Desafíos y patrones arquitectónicos
publish-date=08052011