Preguntas Orientadoras
Preguntas Orientadoras
Preguntas Orientadoras
¿Cuáles son las características y principios que orientan una arquitectura orientada a servicios?
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.
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?
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:
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.
Esta integración puede ser realizada mediante la descomposición de los sistemas existentes en:
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.
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
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 ]
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.
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/
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.