h1

SOA (Parte 2)

09/11/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En el anterior post describimos de manera general qué es un SOA, cuáles son sus orígenes y sus elementos más característicos. En esta ocasión nos enfocaremos en la parte funcional del SOA: qué elementos arquitectónicos lo componen y cómo interactúan entre sí. Adicionalmente veremos los frameworks SOA comerciales más fuertes en el mercado y revisaremos sus principales ventajas y desventajas.

Los elementos arquitectónicos de un SOA

Como comentamos anteriormente, un SOA es un modelo de diseño de arquitecturas empresariales; sin embargo, la implementación del mismo no sólo consiste en publicar web services y ya: aunque en un principio esto puede funcionar para facilitar la adopción de SOA, poco a poco conforme vayamos publicando más y más servicios, volveremos a un esquema desordenado. Así entonces, tarde o temprano el volumen de servicios será tal que:

• Será difícil encontrar los servicios que se necesitan. Esto es progresivamente más frecuente conforme publiquemos un más servicios.

• No será posible realizar una efectiva administración de los servicios y forzar su adhesión a un estándar organizacional, incluyendo características tales como seguridad o políticas de publicación y consumo.

Comúnmente este tipo de problemas son resueltos sobre la marcha, sin embargo es importante considerarlos y atacarlos desde la fase de diseño del SOA para evitar futuros cuellos de botella, facilitando la adopción del nuevo paradigma y lograr ver desde un principio los beneficios asociados a este tipo de arquitecturas:

Un esquema que muestra los componentes del SOA y las relaciones (publicación, descubrimiento, consumo) entre éstos.

[Click en imagen para ver a mayor escala]

A continuación se describen los componentes del SOA en mayor detalle:

• Capa aplicativa. Este elemento contiene las interfaces de usuario final; principalmente las aplicaciones web o cliente-servidor que consumen los procesos construidos a través del Gestor de Procesos y aquellos servicios que han sido publicados por terceros. La capa aplicativa es más dependiente de lenguajes o frameworks de desarrollo (por ejemplo, interfaces web desarrolladas en Java o aplicaciones que interactúan con sistemas legados desarrolladas en C/C++).

• Capa de servicios de terceros. Son los servicios publicados por organizaciones ajenas a la nuestra (por ejemplo, el servicio SOAP publicado por Google para explotar su motor de búsquedas). Dichos servicios son consumidos por la Capa Aplicativa y el Gestor de Servicios, siendo publicados en el Directorio de Servicios[1].

• Orquestador de Datos/Gestor de Servicios. El gestor de servicios u orquestador de datos[2] es el componente cuya función principal es la construcción de los procesos de negocio que utilizará la organización en su capa aplicativa mediante el uso de los servicios que han sido publicados en el Service Registry, incluyendo los servicios publicados por terceros[1]. Adicionalmente, este elemento interactúa con el Directorio de Servicios para extraer los metadatos de los servicios que se integrarán, aunque también hace uso de otro tipo de características como monitoreo o gestión del ciclo de vida de los procesos generados. Por otro lado, es frecuente que este componente incluya una interfaz de usuario que permita construir los procesos mediante la representación diagramática de BPEL (Business Process Execution Language – Lenguaje de Ejecución de Procesos de Negocio)[3].

• Directorio de Servicios. Este elemento es en su forma más simple un repositorio de los servicios publicados así como una "sección amarilla" que utilizará el Gestor de Servicios para construir los procesos de negocio. En versiones más sofisticadas incluye un componente de gestión y gobierno de los servicios incluyendo características tales como gestión del ciclo de vida de los servicios, versionamiento y gobernabilidad (es decir, adhesión a las políticas de negocio y seguridad que permean toda la arquitectura).

• Adaptadores ESB/ETL/EAI y Conexión XDMS[4]. No todas las fuentes de datos o lógica de negocio son fácilmente convertibles a servicios. En algunos casos, es necesario primero utilizar conectores o drivers nativos que son accedidos mediante "servicios empaquetadores" (wrapper services) para su uso por el resto de la arquitectura. Un ejemplo clásico es extraer la información de una AS400 utilizando un adaptador basado en la especificación JCA (Java EE Connector Architecture).

• Repositorio de Datos. Son las fuentes de información como Bases de Datos o archivos planos así como de lógica de negocio, incluyendo sistemas de Planeación de Recursos Empresariales (Enterprise Resource PlanningERP) como SAP R/3. Como se vio en el punto anterior, algunas de estas fuentes de datos no cuentan con interfaces de extracción de datos homogéneas que puedan usarse en un SOA, por lo que la extracción de la información de éstas requiere de adaptadores[4] para su explotación.

El Enterprise Service Bus

Un tema que no hemos visto hasta ahora ha sido, de entre todos estos componentes, ¿quien funciona como el "pegamento" que los une y permite su interacción? ¿Quién realiza la validación de mensajes entre servicios, reforzando las políticas de negocio y seguridad definidas? ¿Quién se dedica a realizar las transformaciones de los mensajes del formato seleccionado para nuestro SOA a los formatos utilizados por la capa aplicativa?

Presentamos el Enterprise Service Bus (o Bus de Servicios Empresariales – ESB) cuya función principal, de manera análoga al bus de las placas base o motherboards, es conectar los diferentes componentes del SOA, permitiendo el intercambio de información entre todos los elementos de la arquitectura:

Vista esquemática del Enterprise Service Bus. Éste es el middleware que gestiona el transporte, ruteo y seguridad de los mensajes entre los consumidores y publicadores de los servicios.

[Click en imagen para ver a mayor escala]

Como puede verse en el diagrama, el ESB es un bus de datos que facilita el transporte de los mensajes entre los consumidores y los publicadores de servicios realizando la tarea de mediación entre éstos:

• Transformaciones: conversiones XML a XML, búsquedas en base de datos y agregaciones (jerarquías de documentos).

• Validación de Mensajes: verificación de campos de datos o combinación de éstos contra reglas específicas de negocio.

• Selecciones de servicio de contenido o calidad: Selección de servicios basada en el contenido o calidad del servicio requeridos. En pocas palabras, balanceo de carga y failover.

• Ruteo basado en contenido: Como ejemplo, si los parámetros del servicio contienen información del país de origen, la petición puede ser redirigida al proveedor designado para ese país.

• Logueo personalizado: Este es un requerimiento legal que puede ser necesario para algunas interacciones entre servicios.

• Monitoreo y métricas de funcionamiento: Un bus debe poseer los puntos de control necesarios para controlar su comportamiento y de los servicios integrados:

Consola de monitoreo del AquaLogic Enterprise Service Bus de BEA/Oracle. (Original obtenido de BEA AquaLogic Service Bus 2.1 Documentation > User Guide > Monitoring )

[Click en imagen para ver a mayor escala]

• Comportamiento automático: Debe existir alguna funcionalidad que permita la auto-configuración, alta disponibilidad y optimización de recursos.

• Administración de políticas: Descripción de las reglas de comportamiento requeridas por todos los puntos anteriores y fácilmente configurables a través de archivos de metadatos basados en XML o algún otro lenguaje descriptivo.

Visto desde el punto de vista de implementación, el ESB es el framework de desarrollo o producto comercial con el cual construiremos nuestro SOA, siendo tan sencillo o tan complejo como deseemos; la mejor opción es utilizar frameworks que contengan todos los elementos de un SOA ya integrados para facilitar la adopción de la nueva arquitectura, como veremos en la siguiente sección.

Implementaciones SOA/ESB

Actualmente existen de manera dominante tres suites, frameworks o implementaciones comerciales del middleware SOA/ESB que permiten la adopción de una arquitectura orientada a servicios:

• AquaLogic de BEA/Oracle.

• Java Composite Application Platform Suite (Java CAPS) de Sun Microsystems.

• Connected Services Framework (CSF) de Microsoft.

Adicionalmente existen otras implementaciones (Como OpenESB) pero su principal limitante es el escaso soporte que ofrecen, un punto muy importante en un proyecto tan complejo como puede ser SOA y que podría requerir una alta curva de aprendizaje; por otro lado a menos que el presupuesto de migración a SOA sea muy reducido[5], es mejor contar con las soluciones que estos proveedores ofrecen.

Ahora bien, haciendo la comparación entre las tres plataformas:

•  AquaLogic es el mejor producto de su clase pero el precio que manejan, aún con el modelo de ventas utilizado por Oracle[6], es astronómico.

• El producto de Sun es muy bueno, pero le falta un poco de pulido a sus interfaces de usuario (esencialmente porque en ocasiones la construcción de procesos puede volverse una pesadilla de micromanagement y "necesitamos" un monitor de 24 pulgadas):

Interfaz de usuario del Process Manager (vista de alto nivel de un proceso, sin detallar los servicios individuales) en el Java CAPS. (Original obtenido de From Java CAPS 5.1.x to Java CAPS 6 and Open ESB – Reuse or Rewrite)

[Click en imagen para ver a mayor escala]

• Finalmente CSF tiene que ver con la penetración de la tecnología Microsoft: si nuestra infraestructura está montada en una arquitectura Wintel, adelante; de lo contrario estamos saltando de la sartén al fuego.

Conclusiones

Hemos visto que la implementación de un SOA no sólo es publicar y consumir web services: se trata de hacer disponibles los servicios de datos y lógica de negocio de una manera estandarizada para que puedan ser utilizados por las diferentes áreas de una organización; todo ello mediante un marco tecnológico – el Enterprise Service Bus – que nos permita realizar de manera efectiva las tareas de gestión, transporte y mediación de los servicios y procesos que componen nuestro SOA. Por otro lado, hemos visto que Sun, BEA/Oracle y Microsoft son los proveedores de soluciones tecnológicas de implementación SOA más importantes del mercado, siendo AquaLogic la mejor pero más cara, JCAPS la de mayor curva de aprendizaje y Microsoft una solución efectiva si disponemos de una infraestructura Wintel.

Notas y pies de página

1. ¿Por qué publicar servicios de terceros en nuestro Directorio de Servicios? Porque adicionalmente a la "sección amarilla" que ofrece, incluye otras funcionalidades como el cache y versionamiento de servicios; características que pueden ser útiles cuando hay que integrar a terceros en nuestros procesos de negocio.

2. Se denomina orquestador de datos porque en su forma más pura, éste componente sólo utiliza servicios de extracción de datos para conformar – orquestar – los procesos de negocio que requiere la capa aplicativa.

3. BPEL es un lenguaje basado en XML que posee una representación diagramática (ver aquí un ejemplo de un algoritmo de transformación) que permite la construcción de procesos de negocio y que fue originalmente desarrollado por la Organización para el Avance de Estándares Estructurados de Información (Organization for the Advancement of Structured Information StandardsOASIS). Actualmente, en la versión 2.0, dicho leguaje ha sido tomado por proveedores para desarrollar sus implementaciones de ESB y frameworks SOA.

4. Los adaptadores ESB (Enterprise Service Bus) son aquellos que de manera nativa pueden ser utilizados para un SOA (por ejemplo, si nuestro protocolo es HTTP y nuestro formato es SOAP, implicaría que nuestra fuente de datos puede regresar queries en forma de documentos XML). Los adaptadores ETL (Extract, Transform and Load – Extraer, Transformar y Cargar) son aplicaciones que obtienen consultas de las fuentes de información y las transforman de manera no nativa al formato que estamos buscando. Los adaptadores EAI (Enterprise Application Integration – Integración de Aplicaciones Empresariales) son, en resumidas cuentas, aquellos que se conforman a un estándar de integración como JCA. Finalmente, XDMS (XML Document Management Server – Servidor de Gestión de Documentos XML) es el equivalente a una base de datos que en vez de almacenar esquemas entidad-relación, almacena jerarquías de documentos XML.

5. Sin embargo, queda la interrogante: si el cliente escatima en un proyecto de tal envergadura – que por poner un ejemplo, puede consistir de unas 20,000 horas/hombre – ¿no es probable que no esté entendiendo el alcance de SOA o los beneficios que ofrece?

6. El modelo de ventas de Oracle es en resumidas cuentas: el costo de licencia por cada producto se multiplica por el número de CPUs en los que está corriendo, considerando los siguientes tabuladores: si el CPU es específicamente un Sun UltraSPARC T1 con 4, 6 u 8 cores, las licencias se multiplican 0.25 por cada core; en el caso de AMD es 0.5 por cada core y en el caso de cualquier otro fabricante multicore – es decir, Intel o alguno de sus partners – se multiplica 0.75 por cada core. Para procesadores de un solo core se contabiliza una licencia por CPU.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: