Conceptos Básicos (SOA)

Arquitecturas Orientadas a Servicios

Este primer Blog va dirigido  a todos los amantes SOA en el cuál reflexionaremos sobre algunos conceptos básicos y los principales atributos de calidad que resuelve este tipo de enfoque de arquitectura.

Siempre como Consultores y más que todo como Arquitectos de Software involucrados en la implementación de soluciones tecnológicas y sistemas de información, estamos obligados a trabajar en el dominio de aplicaciones y en cómo es la mejor forma que estas se integren para que lograr un verdadero soporte tecnológico al negocio para el cual estamos construyendo una solución o un sistema de información.  Normalmente nos dedicamos a publicar servicios sobre la plataforma en la cual trabajamos  y consumir otros servicios que otras aplicaciones nos proveen. Para esto, afortunadamente SOA se ha convertido en el estándar de facto en la industria para la implementación de arquitecturas orientadas a servicios de tal manera que casi cualquier tipo de aplicación ya construida o desarrolla en Java o en otras plataformas, encontramos variedad de frameworks, herramientas, servidores web  y métodos de desarrollo para publicar y consumir servicios web. 

Arquitecturas Orientadas a Servicios (SOA)

Aunque se hable mucho de SOA y sea un tema de moda es bueno que revisemos algunos conceptos para aquellas personas que apenas se inician en este mundo de SOAP y WS.

SOA es un estilo de arquitectura, que define principios de diseño y prácticas en donde la idea fundamental es conformar una arquitectura formada por unidades lógicas de negocio estandarizadas e independientes entre sí, pero que a la vez puedan ser relacionadas a través de un proceso de negocio.

SOA se ha convertido en el estilo de arquitectura que ha revolucionado los sistemas de información actuales alrededor del mundo al ofrecernos una solución que nos permite soportar los modernos y cambiantes modelos de negocio, así cómo la heterogeneidad de los sistemas de información que existen en las empresas.  Nos permite la automatización de los procesos de negocios con base en unidades lógicas independientes, estandarizadas y bajamente acopladas, las cuales reciben el nombre de Servicios. Estos servicios pueden implementarse en varias tecnologías, pero los servicios web, debido sus bases altamente estandarizadas, entre los cuales se encuentra XML, han logrado convertirse en la tecnología más apropiada para implementar Servicios.   Una idea muy común es pensar que SOA es lo mismo servicios web; no entendamos SOAP como Web Services, sino a los servicios web, como una tecnología moderna  y flexible muy útil al  momento de implementar arquitecturas orientadas a servicios.  Thomas Erl en su libro Servicie Oriented Arquitecture -  Concepts, Technology and Design, comenta lo siguiente:

"No necesitas Web Services para construir SOA !"  Estas dos palabras las oirás muy seguido para explicar SOA.  Sin embargo, esta afirmación también está seguidamente por algo equivalente a  ------ "pero usar Web Services, para construir SOA es claramente una muy buena idea de implementación".

En este blog quiero mostrar también un pequeño escenario de negocio que  va a dirigido tanto a personas que ya hayan tenido algún contacto con SOA y Web Services para que me ayuden a ampliar en lo posible esta reflexión.  Sin embargo, es importante aclarar que  le he incluido un alto nivel de detalle importante para que otras personas no tan familiarizadas en el tema puedan leerlo si así lo desean y nos cuenten también su opinión. 

¿Cuál es el Requerimiento a cubrir? Por qué usar SOAP – Web Services?   

SOAP-WS al parecer se ha convertido en una moda muy “chic”  y aunque puede que esto sea cierto, no es esta la razón que nos debe llevar a implementar o gritar siempre SOA! como primera solución.  También es cierto, que actualmente la mayoría de las soluciones de negocios que implementamos llevan su cuota de SOA, estoy segura que no es simplemente por “moda” o porque es lo “in”.  El requerimiento de negocio es quien nos debe guiar a decidir si la solución a implementar  requiere la utilización de SOAP-WS, pero resulta que hoy en día casi cualquier  requerimiento de negocio requiere un pequeño aporte de SOA y de Web Services, ya que la flexibilidad y reusabilidad como atributos de calidad del software, entre muchos otros,  son los más evaluados hoy en día al momento de dar una solución a los requerimientos del negocio, y adivinen quien nos provee una manera de dar solución a esto?  Bueno precisamente, SOA y Web Services.

A la hora de decidirnos por Web Services, debemos tener en cuenta si nuestra solución debe cumplir con los siguientes requerimientos no funcionales, ahora entendidos como atributos de calidad: 

1. ·      Flexibilidad
2. ·         Facilidad de Cambio
3. ·         Alta Disponibilidad (Comunicación en Línea)
4. ·         Reusabilidad
5. ·         Bajo acoplamiento

Si es así, entonces claramente estamos hablando de SOA para una solución a nivel de arquitectura  y Web Services como mecanismo más útil de implementación de servicios.

Escenario de negocio: Contexto del problema

En un requerimiento típico de integración, la sincronización de los datos desde una base de datos a maestra, a una base de datos operacional, constituye uno de los problemas que frecuente resolvemos a través de Web Services.  En este caso en particular, tenemos un CRM, como sistema operacional de Call Center, el cual debe estar en la capacidad de tener actualizada la información de las cuentas comerciales que atiende.  Para esto, es indispensable que éstas estén sincronizadas con los datos que se  encuentran en el sistema transaccional, que manipula la información de las cuentas del negocio, tanto a nivel contable como comercial.  Debido a la alta importancia de estos datos para el negocio y para la gestión de estas cuentas que representan los clientes, es necesario que cualquier operación sobre los datos de las cuentas, en el sistema externo se vean reflejados de manera inmediata en el CRM, de tal forma que si en un futuro el sistema externo es reemplazado, el proceso  pueda seguir funcionando de la misma manera sobre cualquier plataforma sin tener mayor impacto en los procesos de negocio.

La solución a implementar claramente debe basarse en los conceptos de arquitectura orientada a servicios que comentábamos anteriormente.  Para ello es necesario exponer un servicio de negocio en el CRM, que pueda ser usado por el sistema externo para actualizar en línea, y de manera automática e instantánea la información de una cuenta comercial (Cliente).   En este artículo, veremos cómo se lleva a cabo la exposición de un servicio en Siebel usando la tecnología de WS, y como este servicio puede ser consumido por otra plataforma, en nuestro ejemplo una página jsp de Java, y así poder ver claramente como un estándar como SOAP nos permite la integración de dos plataformas totalmente distintas, a través del uso de SOA y WS.

Tecnologías SOA y atributos de calidad

En una arquitectura de solución SOA existen “proveedores de servicios” – componentes que ofrecen servicios que serán usados por otros- y “consumidores de servicios” – componentes que usan los servicios publicados por otros-.  Estas categorías no son mutuamente exclusivas, es decir, pertenecer a la categoría de “proveedor” no implica que el mismo componente pueda actuar como “consumidor”, por lo tanto, un “proveedor de servicios” puede usar muchos servicios publicados por otros componentes.

Cada una de las interacciones entre un proveedor de servicios y un consumidor de servicios puede ser implementada de forma distinta.  Las alternativas de implementación que seleccionemos impacta de manera importante en los atributos de calidad del sistema, cómo lo son la interoperabilidad y la flexibilidad.  Sin embargo, el arquitecto podría optar por obviar SOAP –del cual hemos hablado en todo este artículo- y usar una aproximación más simple cómo lo son los servicios REST (Representational State Transfer),  estos últimos se diferencia mucho de los mecanismos y forma de implantación utilizados por SOAP. Otras opciones también incluyen usar sistemas especializados en mensajería como  Microsoft MSMQ  IBM WebSphere MQ  (antes conocido como MQSeries).  Estas alternativas tienen una estrecha relación con los atributos de calidad del sistema, las cuales podríamos estudiar en un artículo posterior. 

Es importante que desde el punto de vista de arquitectura, las arquitecturas orientadas a servicios también deban ser evaluadas.  El SEI (Software Engineering Institute) ha publicado un reporte en el cual propone una metodología con la cual los arquitectos pueden llevar a cabo la evaluación de una arquitectura SOA de acuerdo con los atributos de calidad que ésta debe cumplir.  Cuando se diseña una arquitectura SOA se deben tener en cuenta el análisis de “tradeoff” de los atributos de calidad.  Por ejemplo, existen muchas decisiones de seguridad que deben ser evaluadas y que muchas veces pueden tener puntos de conflicto entre los requerimientos y las políticas de seguridad del área de TI, no sólo para los componentes que proveen los servicios sino para los componentes que los van a consumir.