Preguntas orientadoras

¿Cuáles son las características y principios que orientan una arquitectura orientada a servicios?

La arquitectura orientada a servicios permite que la funcionalidad de la aplicación se exponga y se

consuma como servicios. Los servicios SOA proveen interfaces con alcance de aplicación en vez de
interfaces del nivel de componente u objeto.

El estilo SOA tiene las siguientes características que lo identifican:

 La interacción con los servicios es desacoplada

 Puede involucrar procesos de negocios que se convierten en servicios interoperables
 Clientes y otros servicios pueden acceder a servicios locales que se ejecutan en el mismo nivel
 Clientes y otros servicios acceden a servicios remotos sobre una red que los conecta
 Estos servicios pueden usar un rango de protocolos y formatos de datos para comunicar
información

Del estilo SOA también se destacan principios fundamentales como:

 Los servicios son autónomos. Cada servicio SOA es mantenido, desarrollado, instalado y
versionado de forma independiente
 Los servicios son distribuibles. Los servicios SOA pueden ser localizados en cualquier parte sobre
la red, local o remotamente en tanto que la red soporte los protocolos de comunicación
requeridos.
 Los servicios son desacoplados. Cada servicio SOA es independiente de los otros y puede ser
reemplazado o actualizado sin romper con las aplicaciones que lo consumen en tanto que la
interface siga siendo compatible.
 Los servicios comparten esquemas y contratos no clases. Los servicios SOA comparten contraltos
y esquemas cuando se comunican, no clases internas.
 La compatibilidad está basada en políticas. Política en este caso significa la definición de
características como transporte, protocolo y seguridad.

[ CITATION Jua09 \l 9226 ]

¿Qué proceso se puede seguir para identificar los servicios SOA?

Para la identificación de los servicios SOA se pueden aplicar seis enfoques:

Enfoque Caracterización del proyecto Clasificación

Orientado a procesos de Los procesos de negocio necesitan TOP-DOWN
negocio explotar los recursos disponibles y
cada actividad requiere invocar
una funcionalidad de IT. Para ello
cada funcionalidad debe estar
disponible de manera flexible

MDA (Model-Driven Se modela el negocio y luego las TOP-DOWN

Architecture, basada en herramientas generan el detalle
herramientas)
Empaquetado de Se ha realizad o una inversión BOTTON-UP
sistemas legados importante en los sistemas
existentes, pero estos no son
flexibles, no se pueden agregar
funcionalidades en forma rápida,
son sistemas con funciones
"cautivas"

Composición de Descomponer los sistemas legados BOTTON-UP

sistemas legados en módulos
Orientado a datos Proveer acceso a los datos usando DAT A-FOCUSED
servicios, sin exponer esquemas o
consideraciones de
implementación
Message-driven Se necesita integrar sistemas, SERVICE-ORIENTED
comunicándolos mediante INTEGRATIONS OF
protocolos estándar no APPLICATIONS AND
propietarios SYSTEMS

Para la identificación de servicios se pueden usar las técnicas:

Análisis de documentos

Esta técnica involucra la revisión de los modelos de negocio y la documentación de los sistemas
existentes para el proceso de negocio y pueden surgir preguntas como:

¿Los factores que motivan el proyecto SOA y sus objetivos, han sido expresados y son medibles en
términos de los indicadores de desempeño del negocio?

¿Los procesos de negocio que van a ser materializados, han sido definidos y descritos a nivel de detalle
suficiente para la toma de decisiones de la arquitectura de TI?

¿Existen puntos críticos pendientes de resolución en la documentación de requerimientos no

funcionales?
Si los modelos de negocio y los documentos de sistemas existentes no son suficientes, se deben
planificar actividades de análisis adicionales, ya que no es ideal avanzar con el modelado sin una base
documental sólida.

Descomposición de dominio

Esta técnica parte de los procesos de negocio a alto nivel, y progresivamente mejora el nivel de detalle
hasta llegar a la identificación de los servicios necesarios para la implementación de los procesos, lo
pasos a seguir son:

 Identificación de los procesos de negocio a implementar

 Modelado de los procesos para la captura de los requerimientos
 Aplicación de técnicas de análisis orientado a objetos para identificar y definir los servicios
requeridos

Debe mantenerse la perspectiva de alto nivel en el proceso, ya que el análisis orientado a objetos de un
proceso puede resultar en un modelo demasiado grande. Pueden aplicarse técnicas tradicionales de
modelado de procesos y análisis de requerimientos. Durante el proceso se debe construir un glosario de
uso común entre los analistas de negocio y de TI y deben identificarse relaciones entre sus términos.

Síntesis de sistemas existentes

Es el escenario más usual, la identificación de servicios es motivada por la necesidad de integración de

sistemas.

Esta integración puede ser realizada mediante la descomposición de los sistemas existentes en:

 Flujos de procesos de negocio

 Reglas de negocio
 Componentes potencialmente reutilizables

Por medio de esta descomposición es posible sintetizar un conjunto de servicios candidatos a partir de
los componentes identificados y sintetizar otros a partir de la adaptación de los flujos de procesos
descubiertos.

¿Cómo se especifica un servicio SOA?

Para cada servicio identificado se realiza un contrato funcional, especificando para cada interface
definida los métodos a ser implementados para proveer el servicio acordado para la interface. Para cada
operación se debe especificar:

 Nombre de método
 Parámetros requeridos por el método, nombre y tipo de descripción
 Valor retornado, indicando el nombre tipo y descripción
 Lista de excepciones levantadas
 Breve descripción de la funcionalidad provista
 Precondiciones requeridas para la ejecución exitosa de la operación
 Post condiciones validas luego de la ejecución del método

¿Qué es un catálogo de servicios?

Constituye la parte más tangible de la implantación de una estrategia SOA. Publica y recopila de forma
ordenada los servicios del negocio y de la infraestructura, teniendo en cuenta estándares.

Los servicios deben ser agrupados y ordenados por criterios abstractos de utilidad (funcionalidades,
ámbitos y capítulos) que faciliten la búsqueda de los servicios disponibles por procesos y sistemas de
información. [ CITATION Man20 \l 9226 ]

¿Cómo se elabora un canvas de agrupamiento de servicios?

Las capacidades de los servicios se suelen traducir como métodos u operaciones de los servicios. Según
las normas de análisis y diseño de la empresa el modo de agrupar puede variar, sin embargo, para llevar
a cabo la descomposición para definir y conceptualizar los negocios, se tienen en cuenta cuatro tipos de
lógica:

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.

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

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.

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. 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.

Posterior a la clasificación se puede realizar el análisis Canvas para cada una de las clasificaciones
generadas.

¿Cómo se documenta una arquitectura orientada a servicios?

Es importante definir para cada uno de los ciclos de vida de un servicio el requisito que obligue a llevar
asociada una documentación que describa el modo y momento para utilizarse, se puede incluir que esta
documentación sea aprobada por los usuarios que van a consumir los servicios.
A continuación, se describe el ciclo de vida:

Referencias
Morales, M. J. (2020). El Catálogo de Servicios SOA. Obtenido de modusoperantic web site:
https://www.modusoperantic.com/es/el-catalogo-de-servicios-soa/

Pelaez, J. C. (2009). Arquitectura Orientada a Servicios (SOA). Obtenido de Geeks web site:
https://geeks.ms/jkpelaez/2009/05/30/arquitectura-orientada-a-servicios-soa/

García Millán, L. A. (2014). Marco referencial para el análisis y planeación en la construcción de un

sistema orientado a servicios (SOA) (Bachelor's thesis, Universidad Piloto de Colombia).

Delgado, A., González, L., & Piedrabuena, F. (2006). Desarrollo de aplicaciones con enfoque SOA
(Service Oriented Architecture). Reportes Técnicos 06-16.

Matsumura, M., Brauel, B., & Shah, J. (2009). Adopción de SOA para Dummies. M. Matsumura, B.
Brauel, & J. Shah, Adopción de SOA para dummies.