Identificación de Servicios en SOA

Una arquitectura basada en SOA está fuertemente basada en la interacción de distintos servicios que se componen y combinar para cumplir un determinado objetivo. Uno de los principales desafíos en el éxito de un emprendimiento SOA consiste en la manera de realizar la interacción entre los servicios. Esto último se define como orquestación. Una apropiada orquestación de servicios en una arquitectura SOA garantiza una adecuada reutilización de servicios, que es una de las máximas que se persiguen. Sin embargo, para lograr esto es necesario partir de una correcta identificación de servicios. Esto es, ¿qué servicios deben interactuar? ¿Cómo? ¿Por qué este esquema y no otros? Tales preguntas son abordadas en la referencia [1], y se describen a continuación las principales ideas.

Identificando servicios
Existen ciertos aspectos que deben considerarse al momento de definir e identificar los servicios dentro de una arquitectura SOA. Los más importantes mencionados en [1] son:

Flexibilidad. Un sistema es más flexible que otro cuando es más adaptable a cambios. En el mundo de los servicios, esto se logra especificando muchos servicios pequeños, con una única funcionalidad. De esta manera, los servicios pueden componerse fácilmente. Por otro lado, si se definen pocos servicios, “cargados” de funcionalidad, el sistema resultante será menos flexible y difícil de modificar.

Performance. La manera de combinar servicios repercute en la performance del sistema. Existen lenguajes como BPEL (Business Process Execution Language) que se utiliza para definir la orquestación de servicios, WDSL (Web Service Definition Language) para definir sus interfaces, y SOAP (Simple Object Access Protocol) para el intercambio de mensajes. Los mencionados lenguajes están basados en XML y favorecen la legibilidad. Sin embargo, crean una sobrecarga en la ejecución del sistema. Cuantos más servicios estén involucrados, mayor será la sobrecarga.

Reuso. Es importante es este punto tener un control centralizado de todos los servicios definidos, de manera de poder detectar rápidamente la posibilidad de utilizar un servicio ya definido en vez de reinventar la rueda implementándolo nuevamente. De la misma manera que lo analizado en flexibilidad, cuantos más pequeños sean los servicios, más chances habrá de reutilizarlos.

Estrategias posibles
La manera más natural según establece [1] es proceder siguiendo una metodología top-down. Una vez definidos los procesos involucrados, el paso siguiente es establecer qué servicios serán necesarios. En este punto deben considerarse los aspectos ya mencionados previamente: flexibilidad, performance y reuso. Como ya se estableció, muchos servicios pequeños favorecen el reuso y la flexibilidad, pero en detrimento de la performance. Luego, es importante destacar que no existe un balance ideal u óptimo. Ante cada sistema se deberá buscar la mejor manera de combinar todos los aspectos.

Sin embargo, existen heurísticas que pueden emplearse. La más conocida impulsa seleccionar aquellos procesos dentro de la arquitectura que logran hacer una diferencia frente a los competidores. Quizás algún servicio referido a un aspecto administrativo no sea tan distintivo frente a la competencia, pero sí posiblemente lo sea un servicio que afecte directamente la utilización del sistema por parte de los usuarios. Estos últimos servicios deben priorizarse para lograr flexibilidad y reuso, ya que son los que impulsarán la diferencia frente a la competencia. Vale la pena mencionar que esta es sólo una estrategia posible, que incluso puede no tener sentido en algunos sistemas. Ante cada nuevo desafío, se deben combinar de la mejor manera performance, reuso y flexibilidad.

Conclusiones
La identificación de los servicios involucrados forma un papel clave para el éxito de un emprendimiento SOA. No debe subestimarse la decisión de cuántos servicios definir, y la manera en que los mismos interactuarán, ya que de esto depende cuán flexible, performante y fácil de reusar será el sistema resultante.

Referencias:
[1] http://www.theenterprisearchitect.eu/blog/2007/04/26/soa-and-service-identification/