Según cuenta, lo principal es mantener una taxonomía simple basada en 4 tipos de servicios básicos que solo debería extenderse según las necesidades de cada empresa y siempre de una manera muy justificada y como medio para asegurar el entendimiento de todas las partes (negocio, técnicos, etc…).

Los tipos básicos son:

Servicios de Negocio : Servicios core de la empresa y del negocio, identificados por usuarios normalmente no técnicos y que cuando se coreografían representan casos de uso o escenarios de usuario. Se implementan con un lenguaje de definición de contrato (WSDL normalmente) y se nombran por alguno de los típicos verbos CRUD (Create, Read, Update y Delete). Un ejemplo sería, “recuperarCliente”.

Servicios de Empresa : Son servicios que implementan servicios de negocio (relaciones 1 a N o N a N). Identificados normalmente por Arquitectos IT son producto de orquestación de servicios. Además, para la transformación de los modelos de datos entre los servicios de empresa y los de negocio, se utilizan transformadores (como XSLT) normalmente en un bus de servicios. Un ejemplo sería “calcularCreditoBancario”.

Servicios de Aplicación : Servicios dentro del contexto de las aplicaciones (y que por tanto no se comparten al mismo nivel que los servicios de empresa o de negocio), que representan funciones específicas como validaciones o transferencias de datos. Son identificados por los desarrolladores de las aplicaciones. Un ejemplo sería “añadirDireccion”.

Servicios de Infraestructura : Servicios que dan soporte a nivel de toda la empresa, tales como logging, auditoría, seguridad… Normalmente son identificados por los desarrolladores de las aplicaciones o equipos de soporte a infraestructuras. Un ejemplo sería “escribeLog”.

Podeis leer todo el artículo aquí.

A la hora de diseñar servicios web que luego sirvan como base para crear orquestación de los mismos (y así generar valor añadido a las empresas con los procesos de negocio), para que sean fácilmente reorganizados o reorquestados según surjan las necesidades (en este punto, es donde SOA muestra su potencial); es necesario que tengan una base de datos totalmente orientados a negocio. Así, cuando hablemos de datos a este nivel, deberíamos hablar de conceptos totalmente relacionados con el negocio de la empresa, a un nivel lógico y funcional (tipos de datos como “cliente”, “contrato” o “servicio”).

La abstracción con una capa de datos permite ocultar la complejidad de los mismos, permitiendo una estructura totalmente organizada a nivel del middleware. El resultado de esto, es que una aplicación o servicio puede pedir datos a nivel lógico y de una manera totalmente organizada sin preocuparse por la capa más física.

Normalmente esta capa de datos, se construye con XML, pues es un estándar muy fácil de utilizar y que permite generar datos complejos (a la granularidad deseada) independientes de la capa física.
Para ello, se utilizan esquemas de datos XML (conocido como XSD).
Existen ya estructuras de datos XML a nivel de negocio totalmente “estandarizadas” por distintas empresas (ejemplos como ACORD para seguros, HR-XML para Recursos Humanos, etc…), aunque la definición de una estructura totalmente orientada al negocio de una empresa por la gente que tiene el conocimiento de la misma suele ser la mejor opción (a partir de una estructura de datos particular, si fuera necesario, siempre existen maneras de transformar los datos a otras estructuras sean más “estándar de facto” o no que la propia de cada uno).

Por esto generalmente la creación de una capa de datos en la creación de una Arquitectura SOA es un beneficio a la misma, ya que en caso de ser necesario reordenar los datos a nivel físico (cosas como por ejemplo, la restructuración de una base de datos) no debería afectarle a nivel lógico y por tanto tampoco a las aplicaciones y servicios construidos por encima.

Y es en este punto cuando nos planteamos como realizar pruebas correctas de la arquitectura para comprobar que realmente estamos construyendo una arquitectura orientada a servicios y no una simple aplicación muy cara.

La verdad, cuando hablamos de testear una Arquitectura SOA, tenemos que plantearnos ciertas cuestiones y elegir las herramientas adecuadas; ya que difiere bastante de la forma tradicional de probar aplicaciones normales.

Es importante tener en mente la arquitectura, sus partes, sus dominios; e intentar dividir la misma en partes pequeñas que sean más faciles de probar; para posteriormente ir probando la integración de las mismas hasta llegar a un punto de arquitectura más o menos global.

Por ello, ante todo, tenemos que tener en mente unos objetivos a conseguir durante las pruebas de nuestra arquitectura:

1. Los servicios son y deben ser siempre reutilizables. Es una de las máximas de SOA y si no conseguimos eso, posiblemente la arquitectura estará abocada al fracaso.
2. Agilidad en los cambios: los procesos y la orquestación de servicios buscan la facilidad de composición de los mismos. Un cambio debería ser rápido y fácil de hacer si la capa base de servicios es la correcta y funciona correctamente.
3. Monitorización : ey! eso que llaman BAM. Es importante tener siempre visible nuestra arquitectura, en tiempo real; para detectar errores, cuellos de botella y otros factores que indiquen la necesidad de un cambio para la optimización de la misma.
4. Interoperabilidad : SOA habla de reutilización y como tal nuestra arquitectura al nivel más alto posible debería ser así. No solo se trata de que nuestros servicios sean reutilizables en referencia a nuestra arquitectura; sino que incluso lo sean de cara al exterior. Las posibilidades de reutilización entre empresas debe ser importante: por ello, cuanto más estándar, mejor que mejor.

Testear una arquitectura SOA pasa por tener en cuenta los dominios de la misma que debemos asegurar en fiabilidad y consistencia; esto es, que debemos probar:

1. Pruebas a nivel de servicio: Son la base de SOA y por tanto la base de toda la arquitectura. Probarlos a nivel de su funcionalidad es importante; pero más importante es probarlos asegurandonos su reutilización (incluso habrá ya servicios como composición de otros).
   Es importante, tener en cuenta que los servicios no son aplicaciones en sí mismas y por tanto deben ser probados atendiendo a ese factor (son independientes, aislados, sin estados, etc…). La mejor manera para probarlos es definir los casos de prueba de los servicios y ejecutarlos para comprobar su correcto funcionamiento.
   Además, hay que tener en cuenta que los servicios son autónomos (sin dependencias de otros servicios) y con una granularidad adecuada (no se trata de que sean ni muy atómicos ni muy complejos; las necesidades determinarán en cada caso como deben ser; pero es importante que tengan un sentido a nivel funcional para la empresa).
2. Pruebas a nivel de seguridad: intentar probar los servicios con una capa de seguridad añadida desde el principio puede ser más complejo de lo que parece. Es mejor probarlos de manera simple y aislados y luego probar la capa de seguridad que tenga nuestra arquitectura añadida a los servicios.
3. Pruebas de orquestación: como estamos hablando de composición; en algún momento tendremos orquestación de servicios y este dominio debería ser probado a partir de unos servicios fiables y seguros. En este momento estaremos hablando de pruebas que determinan la correcta comunicación entre servicios; el trabajo de manera conjunta.
   Estaremos hablando también de procesos de negocio (pruebas a nivel BPM) por lo que debemos verlo como una capa superior a probar.
4. Pruebas de gobernabilidad: la gobernabilidad de SOA es algo muy importante y en buena medida puede ser determinante para la consecución satisfactoria de nuestra arquitectura. Es importante probar las políticas de las distintas capas que se hayan definido, los ciclos de vida y cualquier concepto de gobernabilidad que se haya introducido y deba ser probado.
5. Pruebas de integración: bueno, más o menos tenemos todo probado; solo quedaría verlo en producción sin ningún error.
   Antes de eso es importante hacer pruebas de integración de nuestra arquitectura. El objetivo de estas pruebas es principalmente, determinar el correcto funcionamiento de las interfaces de comunicación de los distintos componentes.

Aunque no lo parezca, probar una arquitectura SOA definiendo diversos niveles y dominios de aplicación es realmente importante; ya que sino podemos encontrarnos con desagradables sorpresas.

Por ello, es recomendable que esta fase de pruebas (el Plan de Pruebas) este siempre presente en la planificación de cualquier arquitectura de este tipo.

Articulos Interesantes:

What is SOA test?
SOA Testing
SOA World – Approaching SOA Testing
Ready to Test SOA, Web Services, ESBs and BI?

Dependiendo de las necesidades que tengamos de comunicación (sincronía vs. asincronía; comunicación 1 a 1, 1 a N o N a N; mensajes erroneos o correctos; mensajería por eventos, etc…) vamos a definir la forma de intercambio de los mensajes entre las distintas aplicaciones / sistemas de nuestra arquitectura.

Petición / Respuesta (Request / Response)

Es la más utilizadas de todas las formas de intercambios de mensajes (también llamada Request / Reply). Básicamente, consiste en la petición por parte de un cliente a un proveedor de un servicio y la espera de la respuesta en un tiempo determinado.
La principal característica de este patrón de mensajería es que resulta síncrono y bloqueante, por lo que durante el tiempo de ejecución del servicio, el cliente queda bloqueado a la espera. De hecho, es útil el manejo de timeouts para manejar la situación en que no haya respuesta por parte del servidor.
Este tipo de mensajería es el indicado para la petición de ejecución de servicios que suelen ser rápidos o cuando del lado del cliente no se puede seguir la ejecución por necesitar obligatoriamente la respuesta del servidor.
Desde el punto de vista del cliente, es una llamada de tipo RPC (Remote Procedure Call), ya que es bloqueante hasta la llegada de la respuesta.
El protocolo de comunicación más utilizado para este tipo de mensajería es HTTP.

Sólo Petición (One-Way)

Es un tipo de mensajería asíncrono y no bloqueante. Suele utilizarse cuando el cliente no necesita la respuesta inmediata por parte del servidor y puede seguir ejecutándose. En estos casos puede utilizarse tanto HTTP (sin respuesta) como JMS (quizá más apropiado) para la implementación de este tipo de mensajería (también pueden utilizarse otros protocolos como FTP, SMTP, etc…)
En este punto, es importante diferenciar entre Petición / Respuesta y One-way en ambos sentidos.
En el primero de los casos, implica un bloqueo por parte del cliente a la espera de la respuesta del servidor.
En el segundo de los casos, la Petición / Respuesta se implementa como dos llamadas one-way asíncronas, por lo que durante el tiempo de ejecución del servicio, el cliente no queda bloqueado y puede ejecutar otra lógica diferente. De hecho, esta segunda forma requiere que el cliente sea a la vez consumidor y proveedor (ya que necesita implementar algúna forma de binding para ser invocado por parte del servidor en la respuesta). Esta opción es bastante útil cuando se realiza una comunicación con un servidor del que se necesita la respuesta, pero dada la duración de ejecución del mismo, el cliente puede aprovechar para realizar otras tareas programadas. El protocolo de comunicación más utilizado para este tipo de mensajería es JMS por sus características asíncronas.

Request / Callback

Es un tipo de mensajería request / response asíncrona. Normalmente, el cliente puede realizar una invocación al proveedor del servicio y seguir ejecutando otro código. La diferencia con la petición one-way en ambos sentidos, radica en que en la petición, se pasa la información del callback o manejador de la respuesta. Es decir, a nivel del cliente existe una parte que es la encargada de realizar la petición al servicio y otra parte que es la encargada de manejar la respuesta.
La principal complejidad de este patrón de mensajería consiste en que la función de callback debe ser capaz de manejar el contexto o la información de instancia para correlacionar los mensajes de respuesta correctamente con los de la petición.

Publicación / Suscripción (Publish / Subscribe)

Cuando se realiza una petición que no necesita de una respuesta, suele utilizarse el patrón de mensajería conocido como publicación / suscripción. A diferencia del patrón one-way, con Publish / Subscribe se permite la comunicación 1 a N entre el cliente y los distintos consumidores de los mensajes (que se "suscriben" a la publicación del mensaje en cuestión).
Este tipo de mensajería suelen ser implementados por medio de protocolos JMS, que permiten la asincronía y la persistencia de mensajes hasta su procesamiento.
Un ejemplo de Publicación / Suscripción sería la notificación que hace un sistema a otros N sistemas de un cambio en el primero (con un modelo Request / Response o One-Way implicaría notificar 1 a 1 a los sistemas implicados; mientras que con el patrón Publish / Subscribe se puede realizar en un solo paso).

Mensajes de Error (Fault Messages)

Normalmente, en los casos de comunicación que hemos descrito anteriormente, admitimos que los mensajes enviados son correctos y que contienen la información necesaria para su ejecución satisfactoria.
No obstante, a veces, es necesario definir como se realiza el intercambio de mensajes para resultados incorrectos o no esperados.
En el caso de mensajería Petición / Respuesta, la información que devuelve el proveedor del servicio puede ser la de un mensaje de error. En estos casos, la forma en que está definido el mensaje es dependiente del protocolo o el formato a utilizar. Por ejemplo, si utilizamos SOAP como medio de mensajería, se puede definir (aparte del formato de mensaje de la respuesta correcta) un formato para SOAP-Fault como mensajería para casos de excepciones.
En el caso de mensajería asíncrona, la respuesta de un mensaje con excepción puede resultar más complicada, ya que el envío de una petición no implica la llegada de una respuesta. Por ello, se suelen utilizar colas JMS como protocolo de comunicación asíncrona, ya que nos permite implementar medios de asegurar la recepción/envio de los mensajes por medio de reintentos y persistencia de los mismos en las colas.

EDA (Event-Driven Architecture)

La mensajería por eventos, es un tipo de mensajería que se ha puesto de moda con lo que ha venido a llamarse EDA o la evolución de SOA. Consiste basicamente en "automatizar" la generación de mensajes y el envío de los mismos por medio de eventos (que ocurren cuando se produce un cambio en el sistema generador de los mismos, por un timer que se ejecuta cada cierto tiempo, etc…).
Normalmente, un proceso de negocio orquesta la comunicación con los distintos sistemas/aplicaciones implicadas definiendo el orden en que se ejecutan y como se produce la mensajería o comunicación con los mismos.
Con EDA, esa orquestación queda asumida por los propios procesos de cada sistema o aplicación. Es decir, los servicios de negocio que permiten la integración con los sistemas finales tienen un tiempo de ejecución y además, definen cual es el siguiente servicio a ejecutarse en esa "cadena de eventos" que conforman los procesos en una arquitectura EDA.

Links interesantes:

SOAP Version 1.2 Part 1: Messaging Framework
Web Services Message Exchange Patterns
Message Exchange Pattern Wikipedia Definition
Message Exchange Pattern

El primero de estos artículos va a tratar sobre el ESB, cómo usarlo, sus aplicaciones reales más comunes, etc…

Comenzemos pues, definiendo el ESB como un elemento de integración que combina mensajería, servicios web, transformación de datos, enrutación, políticas de seguridad, etc… y que permite la interacción entre diversas aplicaciones o sistemas de una Architectura Empresarial.
El ESB se ha convertido en una de las partes más importantes de una Arquitectura SOA ya que se presenta como el "pegamento" multiprotocolo y multipropósito para dicha arquitectura.

Las aplicaciones y características más comunes del ESB son las siguientes:

Enrutación basada en contenido:

Generalmente, el ESB cumple un cometido de enrutación entre sistemas o aplicaciones. Esa enrutación o decisión del punto final (endpoint) que debe invocarse se puede hacer en función del contenido del mensaje. Para ello, el mensaje en cuestión debe llevar información asociada que permita determinar el endpoint en cuestión (es lo que suele llamarse metadatos o metainformación del mensaje).

Por ejemplo, podemos hacer una invocación a un servicio web u otro por medio de sus endpoints (esto es, las url’s de invocación de los servicios) en función de algún parámetro del mensaje.
El caso práctico más común, es un mensaje con información sobre concesión de un préstamo de dinero para el sector bancario. La decisión de aceptación del préstamo puede definirse como automática para cantidades por debajo de un umbral o manuales si se supera dicho límite. El ESB sería capaz de analizar dicha cantidad (sería información inclusa en el mensaje) e invocar un servicio web de resolución automática o manual según el caso que esté manejando.

Transformación de mensajes:

La mayoría de los ESB suelen incorporar motores de transformación y parseadores de mensajes que permiten y facilitan la transformación de los mismos. La manera más común suele ser por medio de un fichero XSLT de Transformación de mensajes, aunque algunas herramientas utilizan otros sistemas, incluso propietarios.

Por ejemplo, disponemos de un modelo de datos común de nuestra arquitectura y queremos invocar un servicio web con un modelo de datos particular y único. El ESB nos permite realizar la transformación del mensaje de un modelo a otro por medio de un fichero XSLT (o cualquier otro sistema que utilice) y así desacoplar completamente la implementación de uno y otro. De esta manera, un futuro cambio de uno u otro modelo, solo debería, en principio, aceptar a la transformación del mensaje, nunca a las implementaciones de ambos modelos involucrados.

Configuración y no codificación:

Una de las cosas más ventajosas de un ESB es que suele realizarse todo por medio de configuración y no codificación. Independientemente del producto que estemos utilizando (hoy en día la mayoría incluyen IDE’s gráficos que facilitan la configuración de los elementos del ESB; aunque algunos pueden necesitar de configuración por medio de ficheros y manualmente) suele ser suficiente con la configuración de los componentes del ESB que vayamos a utilizar. No suele necesitarse la codificación, lo que limita el número de errores y da fiabilidad al bus que se monte.
No obstante, si fuera necesario, la codificación (sea por medio de Java, .NET, o cualquier otro lenguaje) suele ser posible para casos concretos en que los componentes del ESB manejado no implementen o faciliten la configuración deseada.

Proxy de Servicios:

Una de las mayores ventajas del ESB es la de crear una capa de proxy por encima del servicio. Ello, nos permite abstraer su implementación (que al final, puede ser como una caja negra, de la que solo disponemos la interfaz, normalmente su WSDL) y añadirle información o requisitos para su ejecución.

El caso más práctico sería el de un servicio web con dos operaciones. Una de ellas, permite la consulta online en una base de datos de libros. La otra operación permite la compra de un libro y por tanto requiere del manejo de información confidencial como puede ser una tarjeta de crédito.
El ESB nos permite generar un proxy por encima de dicho servicio y dar lugar a dos nuevos servicios (que serán los que realmente se permitan invocar a traves de aplicaciones cliente). Uno de los dos proxy’s podría ser el servicio con la operación de consulta (sin requisito adicional). El otro servicio podría resultar en un proxy con requisito de seguridad añadido sobre la operación del servicio original. El proxy podría ser requerído para su invocación, por ejemplo, por medio de HTTPS que llamaría finalmente a la operación del servicio original no securizada.

Conversión de protocolos:

Como ya hemos comentado, una de las características del ESB es su funcionalidad multiprotocolo. Esto es, que permite la conexión a distintas aplicaciones o sistemas por medio de numerosos protocolos. Además, suelen incorporar la posibilidad de añadir conectores a todo tipo de aplicaciones que pueden ser desarrollados por el mismo fabricante del ESB, por terceros o incluso por el propio desarrollador a través de un API estandarizada.

El ejemplo más práctico sería un servicio web por HTTP, al que se le quiere dar fiabilidad por medio de mensajería JMS. El ESB sería el encargado de exponer el servicio de manera fiable a través de un proveedor de JMS y luego realizar la conversión de protocolo necesaria para la invocación via HTTP.

Auditorías y Logs de Mensajes:

Otra característica importante del ESB es su función como auditor de mensajería y "logado" de mensajes. La comunicación de información a través del ESB nos permite centralizar sistemas de log y persistencia de información susceptible de ser auditada. Además, luego con herramientas de BAM o incluso Business Intelligence pueden explotarse dichos datos y realizar monitorizaciones exhaustivas que permitan la optimización del ESB, la Arquitectura SOA y en definitiva el negocio de la empresa.

Manejo de Excepciones:

Generalmente los servicios web tienen un comportamiento de respuesta correcta y en algunos casos pueden devolver excepciones de manera controlada (o no). El ESB nos permite gestionar las excepciones de una manera estandarizada (por ejemplo SOAP Fault) y realizar las correcciones oportunas al ocurrir dichos errores.

El ejemplo más práctico consistiría en definir un modelo estándar de nuestra arquitectura para el manejo de excepciones. Por medio del ESB podríamos tratar cualquier tipo de error (independientemente del protocolo o el modelo de datos de los servicios involucrados) de una manera común a todo nuestro entorno y así poder unificar criterios, facilitar la internacionalización de mensajes de error, etc…

Securización de Servicios:

Los servicios que suelen integrarse por medio de un ESB pueden o no estar securizados. A veces, la información es necesaria de securizarse en mayor o menor medida dependiendo del cliente externo que vaya a utilizarla. Por medio del ESB se pueden definir políticas de seguridad para los servicios y establecer más o menos requisitos para la invocación / ejecución de los mismos.

El ejemplo práctico consistiría en securizar con SSL un servicio sin seguridad (por ejemplo, un servicio adaptado de un sistema legado que carece de elementos securizantes) por medio de certificados digitales.

Acceso a Repositorio de Servicios:

Un Repositorio de Servicios (no confundir con UDDI) nos permite acceder a metainformación de los servicios integrados que facilita el control de los mismos y el poder aplicar políticas y condiciones de una manera centralizada y jerarquizada (entre muchas otras características, muy ligadas a veces con la gobernabilidad de la arquitectura).

Un ejemplo práctico consistiría en resolver de manera dinámica los endpoints de invocacion de los servicios por medio del acceso a un repositorio de servicios que nos diera dicha información en tiempo de ejecución. De esta manera, por ejemplo, cambiar a la invocación de un servicio en pruebas u otro de respaldo, sería automático por medio de configuración del propio repositorio.

Validación, Enriquecimiento, Transformación y Operación de Mensajes:

Se puede decir, que estas son las 4 características estrella de un ESB:

Validación de la información, de los mensajes entrantes, sobre los que se pueden aplicar distintas condiciones y verificaciones que hagan cumplir los requisitos establecidos.
Enriquecimiento de los mensajes, posiblidad de añadir información o metainformación adicional para cumplir las necesidades de integración en cada momento.
Transformación de los mensajes, normalmente entre los diversos modelos de datos del conjunto de servicios y aplicaciones a integrar.
Operación de los mensajes o enrutación en función de directivas preestablecidas o a partir de metainformación inclusa en la propia comunicación.

Estas son solo algunas de las principales características y usos de un ESB. Dependiendo del producto que vayamos a utilizar será más o menos fuerte en ciertas cosas u otras.

¿Qué otras experiencias reales teneis con ESB’s? ¿Veis que falte algo? ¿Cuál es el producto del mercado que creeis mejor se adapta a vuestras necesidades o que cumple en mayor medida con estos requisitos?

Links interesantes:

ESB Integration Patterns by Dave Chappel
Patterns: Implementing an SOA using an Enterprise Service Bus
Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture
Application Integration::Broker application pattern::Runtime patterns
Enterprise Service Bus (O’Reilly Safari Books Online)
ESB Patterns that "Click" (The Art and Science of Being an I/T Architect)