Arquitectura orientada a servicios (SOA)
Un servicio
es el conjunto de actividades que buscan satisfacer los requerimientos de un
cliente.
SOA es una arquitectura de Tecnologías de la Información (TI) basada en el paradigma de la orientación a servicios, donde los clientes consumen servicios que les ofrecen los proveedores, permitiendo de esta manera la creación de sistemas de información altamente escalables con la lógica de negocio de la organización embebida a través de los procesos de negocio y con unos interfaces de servicio que permiten la interoperabilidad de sistemas sin importar en qué lenguaje hayan sido desarrollados.
Asimismo, la orientación a servicios es un paradigma, una forma de pensar, por el cual la organización alinea y acerca su mapa de procesos o cadena de valor a las TI mediante la automatización de los procesos de negocio implementada sobre una Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture).
SOA es una arquitectura de Tecnologías de la Información (TI) basada en el paradigma de la orientación a servicios, donde los clientes consumen servicios que les ofrecen los proveedores, permitiendo de esta manera la creación de sistemas de información altamente escalables con la lógica de negocio de la organización embebida a través de los procesos de negocio y con unos interfaces de servicio que permiten la interoperabilidad de sistemas sin importar en qué lenguaje hayan sido desarrollados.
La automatización de los procesos de negocio se
realiza mediante la descomposición de los procesos en servicios SOA que agrupan la lógica del proceso de negocio para posteriormente ser consumidos de una forma coordinada (orquestación de servicios) y permitiendo la colaboración con otros servicios o procesos (coreografía de servicios).
Para orientar las TI al negocio, la tecnología
debe estar sincronizada y alineada con el negocio desde un enfoque “Top-down”
partiendo de la visión, misión estrategia, cadena de valor, procesos de negocio
de la organización hasta llegar a los servicios y estos interoperar con los sistemas heredados o legados de la organización. Esta alineación se realiza durante
la fase de análisis, que precede a las de diseño, desarrollo y entrega de los servicios. Para
esta alineación y sincronización se utilizan lenguajes de modelado como el BPMN
2.0.
Los servicios SOA deben ser inventariados
para facilitar su identificación, descubrimiento, reutilización y evitar
duplicidades, permitiendo generar composiciones de servicios para automatizar
la lógica del negocio, es decir componer servicios SOA para automatizar los
procesos de negocio de la organización.
Ahora podemos definir un servicio como la unidad lógica de una
solución a la cual se le ha aplicado el paradigma de la orientación a
servicios. Una unidad lógica puede ser un proceso.
A cada servicio se le asigna su
propia funcionalidad con un conjunto de capacidades relacionadas en un contexto
específico, y es por esto, que un servicio puede ser considerado como un
contenedor de capacidades asociadas con un propósito común.
El análisis, diseño, desarrollo e implementación de este
paradigma de orientación a servicios sobre una arquitectura SOA se rige por los
principios descritos en el manifiesto
SOA y se divide en dos grandes etapas:
A. Análisis orientado a servicios (Modelado de servicios) se
inicia con la recopilación de información para ejecutar el modelado de servicios,
identificando, clasificando, agrupando y componiendo servicios candidatos por
medio de la descomposición de los procesos de negocio. Se realiza de forma
iterativa, la entrada es un proceso de negocio y la salida son servicios
candidatos.
Desde la visión “top-down” identificamos los procesos de la organización, es decir el alcance, y para cada uno de estos procesos llevamos a cabo la iteración mediante el modelado de servicios.
El modelado de servicios es un
subproceso del análisis de la orientación a servicios por el que siguiendo los
siguientes 12 pasos descomponemos los procesos de negocio en lógica y
posteriormente agrupamos esta lógica para modelar servicios:
1. Descomponer el proceso
de negocio o proceso de trabajo.
2. Filtrar la lógica no
apta para ser encapsulada en un servicio.
3. Identificar servicios
agnósticos candidatos.
4. Identificar lógica
específica del proceso de negocio.
5. Aplicar el paradigma
de la orientación a servicios.
6. Identificar
composiciones de servicios candidatos.
7. Analizar los
requerimientos del proceso.
8. Identificar
capacidades de servicios de utilidad candidatos.
9. Definir servicios de
utilidad candidatos.
10. Aplicar el paradigma
de la orientación a servicios.
11. Revisar composiciones
de servicios candidatos.
12. Revisar las
capacidades de los servicios candidatos.
B. Diseño orientado
a servicios (Contrato de servicio). El diseño orientado a servicios cuenta
con 8 principios de diseño que se aplican sobre cada uno de los servicios
modelados en la fase de análisis, estos principios de diseño son:
1. Contratos estandarizados: los contratos
del catálogo de servicios SOA deben cumplir los mismos estándares y normas de
diseño, usando documentos en lenguaje natural y técnico.
2. Bajo acoplamiento: los servicios evitan acoplarse a
la tecnología que los implementa.
3. Abstracción: los contratos presentan sólo la información
esencial expuesta en el
contrato, siendo transparente para el cliente como el proveedor ha implementado el servicio.
4. Reutilización o reusabilidad: servicios con lógica agnóstica que puede ser fácilmente reutilizada en diferentes procesos. Los servicios expresan y contienen lógica de negocio por lo que se convierten en activos de la organización.
5. Autonomía: un servicio no puede contener lógica que dependa de un artefacto externo al propio servicio (un modelo de datos, un sistema de información, etc).
6. Ausencia de estado: utiliza un protocolo de
comunicaciones sin estado, es decir cada petición es una transacción
independiente que no tiene relación con cualquier solicitud anterior, de modo
que la comunicación se compone de pares independientes
de solicitud y respuesta.
7. Capacidad de ser descubiertos: complementados con metadatos que hacen que puedan ser adecuadamente descubiertos e interpretados en términos de negocio.
7. Capacidad de ser descubiertos: complementados con metadatos que hacen que puedan ser adecuadamente descubiertos e interpretados en términos de negocio.
8. Capacidad de ser combinados para ser usados en
composiciones: formando lógicas más complejas. Los servicios pueden formar parte de
una composición sin importar el tamaño y complejidad de la misma
Los servicios van a soportar la
ejecución de los procesos, descomponiendo los procesos y agrupando lógica en
diferentes servicios.
Para llevar a cabo la descomposición de
procesos debemos usar técnicas para definir y conceptualizar servicios de
negocio, por lo que es de gran importancia realizar un buen análisis y diseño
para conceptualizar y definir los servicios de negocio.
Existen cuatro tipos de lógica:
1. Lógica de negocio. Expresa capacidades de negocio a
través de diferentes artefactos como pueden ser: BPM, BPMN, Taxonomías,
Ontologías, Modelos de datos, información, etc. Es la lógica que la
organización utiliza para aportar valor.
2. Lógica de utilidad. Soporta y procesa a través de recursos
tecnológicos las capacidades de negocio: acceso a datos, correo electrónico,
seguridad, servicios de firma electrónica, registro, etc. Es lógica de
aplicación, tecnológica; es de bajo nivel de aplicación o de sistemas de
información a través de recursos tecnológicos.
3. Lógica agnóstica. Lógica genérica con un alto potencial
de ser reutilizada por varios procesos de negocio (multipropósito) y con menos
probabilidad de cambio. Agnóstico (sin conocimiento), Ejemplo: La entidad
Cliente, permitirá consultar la información de un cliente y podrá ser
descubierta y reutilizada por otros procesos u otros servicios.
4. Lógica no-agnóstica. Lógica con funcionalidad específica
que por su naturaleza no tiene potencial de ser reutilizable, representa
típicamente los elementos de propósito particular de la lógica de procesos de
negocio susceptible de cambiar con facilidad. Esta lógica sí tiene un conocimiento
de lo que está haciendo, por ejemplo: Generar una orden de compra, generar una
factura, sí saben lo que están haciendo tienen lógica específica.
Los tipos de lógica permiten definir y
clasificar servicios. A la hora de llevar a cabo la descomposición de procesos
en servicios SOA se debe seguir ciertas técnicas que permitirán agrupar lógica en
servicios funcionales.
Estos tipos de lógica definirán modelos
de servicio es decir una clasificación de los servicios. Cuando tengamos los
diferentes tipos de servicio que existen clasificados atendiendo a los tipos de
lógica se definirán unas capas de servicios o vistas con unas responsabilidades
específicas, ingeniería de software con separación de responsabilidades.
Podemos definir un modelo de servicio como la clasificación que permite identificar a
qué tipo de lógica pertenece un servicio según los criterios de reutilización
de dicha lógica y el nivel de relación de servicio con dominios o ámbitos
específicos dentro de la organización.
La separación de la lógica agnóstica de
la lógica no-agnóstica en diferentes capas de servicios introduce la
abstracción que permite la reutilización de los servicios a la vez que los
protege de los impactos del cambio. Estas capas de abstracción ayudan a
facilitar el cambio evolutivo mediante la localización de los impactos del
cambio en áreas controladas.
El proveedor del servicio acordará con
el consumidor o cliente del servicio el contrato técnico del servicio publicado
en el catálogo dando a conocer la manera de interactuar con el servicio. El
poco acoplamiento de los servicios permite reducir las dependencias internas
que pueden afectar estos contratos técnicos, de tal forma que cuando se produce
un cambio, se evita la propagación del impacto hacia los servicios consumidores
con relación de dependencia.
Cada servicio será definido y
contextualizado atendiendo a la lógica que contenga, determinando el alcance y
la granularidad funcional del servicio.
Los servicios con granularidad funcional
gruesa pueden ser demasiado inflexibles para ser reutilizables. Sin embargo,
los servicios con granularidad muy fina pueden pesar y complicar la gobernanza
en una infraestructura TI y de negocio con mucho volumen de negocio y miembros.
Alcanzar este equilibrio entre alcance
funcional y granularidad requiere de experiencia en los dos ámbitos: negocio y
tecnología.
El análisis orientado a servicios es la
primera fase del ciclo de vida de los servicios, y se inicia con unos pasos
preparatorios de recopilación de información para ejecutar el modelado de servicios
donde se identifican, clasifican, agrupan y componen servicios candidatos por
medio de la descomposición de los procesos de negocio; es el método que permite
descomponer procesos de negocio o de trabajo definiendo:
·
Tipos de lógica.
·
Modelos de servicio.
·
Capas de servicio o vistas.
·
Inventario de servicios.
·
Catálogo de servicios.
·
Contrato del servicio.
Existen diversas metodologías y enfoques
para llevar a cabo la fase de análisis de orientación a servicios, teniendo
todas ellas en común que los límites funcionales de los servicios deben ser
normalizados para evitar la duplicidad. Pero los servicios normalizados no
necesariamente hacen que los servicios sean altamente reutilizables ya que
entran en juego otros factores como la granularidad del servicio, la autonomía,
la gestión del estado, la escalabilidad, la composición, y la medida en que la
lógica del servicio es suficientemente genérica para que se pueda reutilizar.
La descomposición de los procesos
atendiendo a la clasificación de los tipos de lógico, las piezas descompuestas
serán agrupadas en estos tipos de lógica y así se definirán los modelos de
servicios.
Existen tres tipos de modelos de
servicio o clasificación de servicios SOA:
Servicios de Tarea o
de procesos de negocio: Servicios con contexto funcional de negocio no
agnóstico. Por lo general, tiene un propósito único y específico asociado
a la lógica de un proceso de negocio padre.
Servicios de Entidad: Servicios reutilizables
con contexto funcional de negocio agnóstico. Por lo general, se asocia a una
entidad de negocio. Ejemplo: personal, cliente, etc.
Servicios de Utilidad: Servicios reutilizables
con contexto funcional de utilidad no agnóstico asociada a la generalidad de la
tareas tecnológicas. Ejemplo: servicio de conexión a una base de datos, correo,
proceso de impresión, proceso de seguridad, firma electrónica, registro, etc.
Un inventario de servicios es una
colección estandarizada y gobernada de servicios complementarios dentro una
organización creados bajo un modelo de implementación top-down que resulta
de la clasificación de los servicios o modelo de servicios y pertenecen a
dueños no relacionados.
Un inventario
de servicios facilita establecer un alto grado de interoperabilidad entre
funcionalidades, consiguiendo una visión clara a la hora de componer servicios
para dar solución a necesidades complejas, además de agilizar y flexibilizar la
respuesta a nuevos requerimientos del negocio.
En el análisis de orientación a servicios, los servicios candidatos son definidos para un nuevo o ya existente inventario de servicios.
Lo que descomponemos de los procesos
después lo agrupamos en lógica para definir servicios, esta fase de análisis de
orientación a servicios se realiza de forma iterativa.
El portafolio
de servicios o catálogo de servicios es el conjunto de servicios
existentes en la infraestructura de TI de la organización. Un portafolio por lo
general engloba uno o más inventarios de servicios, pudiendo representar a
todos los servicios responsabilidad de TI. La administración del portafolio de
servicios consiste en planificar, definir, puesta en producción y mantenimiento
correctivo y evolutivo de la colección o colecciones de servicios.
Un aspecto importantísimo en SOA es el contrato de servicio: documento técnico
de diseño que recoge toda la metainformación sobre su funcionalidad,
estableciendo la forma de descubrir y utilizar la información ofrecida por el
servicio.
Todos los contratos de servicio del
catálogo de servicios SOA deben cumplir los mismos estándares y normas de
diseño.
Un contrato de servicio debe servir
para:
Poner de acuerdo a dos partes, conociendo cada una de ellas lo que espera de la otra, indicando la funcionalidad, la interfaz del servicio (parámetros de entrada y de salida) y los códigos HttpCodes devueltos.
Validar el mensaje de entrada en tiempo de ejecución y devolver un mensaje de error en el caso de que la petición del cliente no cumple el contrato.
Facilitar el desarrollo al proveedor de un servicio y de la consumición del servicio al cliente, mediante herramientas de desarrollo que pudieran leer dicho contrato y generar el código necesario para poder invocar dicho servicio.
Todos los contratos del catálogo de
servicios SOA deben cumplir los mismos estándares y normas de diseño, usando
documentos en lenguaje natural y técnicos.
Como ejemplo de contratos técnicos y
atendiendo a la implementación del servicio podemos diferenciar:
Implementación del servicio como un servicio web: El contrato estará compuesto de un WSDL, Schemas XML y políticas de seguridad WS-Policy.
Implementación del servicio como un servicio RESTFul: El contrato debe tener una estructura uniforme, similar al protocolo HTTP.
Comentarios
Publicar un comentario