En una arquitectura orientada a servicios los Servicios son una parte fundacional de dicha arquitectura. Un error común en las implementaciones de SOA es pensar que las aplicaciones exponen servicios de manera espontánea, típicamente implementaciones Web Services.

Este es una aproximación inocente, que lleva a tener problemas en el largo plazo porque genera un universo de conexiones punto a punto no administradas que sube los costos de integración y operación de los sistemas.

Por esta razón es necesario definir cómo los servicios serán expuestos en la plataforma de integración.

Definición de Servicio

Para poder enfrentar un proyecto SOA se necesita acordar que es un Servicio para evitar problemas de interpretación cuando los proveedores de las aplicaciones construyan servicios para la plataforma.

Existen las operaciones de servicios que son funcionalidades que las aplicaciones consumen. Estas operaciones se agrupan en contextos lógicos. Estos contextos lógicos son Servicios. Un ejemplo de esto sería:

Ø      Contexto Lógico: Servicio Información Indicadores Financieros

Ø      Operaciones se Servicios:

o       Valor UF

o       Valor UTM

Este ejemplo muestra la diferencia entre operaciones y servicios.

Diferencia entre Servicios de Negocio y Aplicación

Después de diferencia operaciones de servicios el siguiente paso es hacer la diferencia entre Servicios de Negocio y de Aplicación. Esta es una definición suave, porque no existe un criterio absoluto para la definición de que es un servicio de aplicación y cual es de Negocio.

Los Servicios de Aplicación son los servicios que exponen operaciones (funciones) de las aplicaciones para que la plataforma de integración use. Estos servicios son puestos a disposición de la plataforma de integración no de las aplicaciones clientes.

Los Servicios de Negocio son los servicios que exponen operaciones en la plataforma de integración para que las aplicaciones clientes consuman. Estas operaciones deben ser de una granularidad mayor, porque implementan funcionalidad de negocio muchas veces transversal a las aplicaciones.

En el desarrollo de software todo el mundo sabe que existe una disciplina de análisis que tiene como objetivo lograr un entendimiento profundo de los requerimientos que en software debe satisfacer y proponer la solución a nivel conceptual que después las tareas de diseño volverán en una solución concreta, lista para ser implementada.

 Lo primero que hay que tener claro sobre el análisis de Servicios en SOA, es que el objetivo de está disciplina es obtener los Servicios Candidatos. Son sólo candidatos, porque en el contexto de integración hay muchas cosas que pueden hacer imposible que ese candidato se convierta en un servicio en producción. Por ejemplo, la tecnología de la aplicación, quien administra esas aplicaciones, conocimiento de cómo funcionan, etc.

 Segundo, existe una confusión en la definición de un servicio. Por ejemplo, Obtener el valor de la UF en un día del año ¿es un servicio? En mi opinión no lo es, sólo es una operación de un servicio. Un Servicio es una agrupación de Operaciones de Servicios. Esta agrupación que llamamos servicio es un “contexto lógico” que agrupa.

 Tercero, existe una confusión en los analistas sobre la granularidad de los servicios. Antes de todo, no existe una regla que se pueda usar para determinar la granularidad adecuada de un servicio. Pero sí existe una diferencia entre un Servicio de Negocio y un Servicio de aplicación. Un Servicio de negocio nace para satisfacer necesidades de un proceso de negocio, típicamente están ubicados en el bus de servicios y son implementados usando lógica de una o más aplicaciones. Los Servicios de Aplicaciones nacen con un objetivo distinto, apoyar con lógica de esa aplicación a un servicio de negocios. Estos servicios son acotados al contexto de la aplicación.

 Después de revisar estos tres puntos fundamentales, se tiene una base para poder revisar el análisis de los servicios de negocio dentro de una iniciativa SOA.

 Análisis de servicios, pasos fundamentales.

 Cuando se están modelando los servicios de una arquitectura orienta a servicios es fundamental abstraerse de los sistemas y aplicaciones existentes. Primero es lo primero, ¿por qué está implementando SOA? No es por iniciativa de los Developer que aprendieron ha hacer servicios Web. La razón fundamental es agilizar la implementación de procesos de negocio.

 Por eso, hay que partir con la definición de los requerimientos de negocio. Esto quiere decir que se debe seleccionar el proceso de negocio a implementar. Además de seleccionar, se debe tener bien definido y documentado este proceso de negocio que sea información útil para la definición de servicios candidatos.

 Después de tener el requerimiento de negocio “identificado”, se deben descomponer el proceso para encontrar los “actores” de este proceso. Los actores del proceso son todos los sistemas, aplicaciones y personas que actúan en el proceso. En este punto no es el objetivo identificar servicios de aplicación cadidatos, solo identificar actores.

 Siguiendo estos dos pasos previos ya se cuenta con las necesidades del negocio y los actores que deben ser incluidos en el análisis de los servicios candidatos. Es ahora que se comienza con el modelamiento de los servicios candidatos.

 Este paso tiene como resultado dos entregables concretos:

Ø      Identificación de Operaciones de Servicios de Negocio Candidatos

Ø      Agrupación de las operaciones en Servicios de Negocio Candidatos.

 En resumen los pasos a seguir el análisis orientado a servicios son:

1. Definición de los requerimientos de negocio.
2. identificación de los actores.
3. Modelado de Servicios Candidatos.

 Modelado de Servicios Candidatos.

 Este punto es el núcleo del trabajo del análisis SOA, ya que pone foco en la generación de los Servicios Candidatos. Los pasos anteriores también son parte del análisis de cualquier sistema, mientras que este es especifica de un proyecto SOA.

 [Continuará en el próximo POST]