Arquitectura SOA y Composición de Servicios

17/2/2021 Arquitectura SOA y Composición de Servicios - Disrupción Tecnológica
 
Disrupción Tecnológica

Blog de divulgación de Ciencia y Tecnología
Inicio » Ingenieria » Arquitectura SOA y Composición de Servicios
  INGENIERIA / INTEROPERABILIDAD / TECNOLOGIA
Arquitectura SOA y Composición de Servicios

por Jose Ramon Pascual | Publicada 4 enero, 2020 | 2 Comentarios
El enorme crecimiento de las tecnologías y aplicación de las TIC ha generado en los últimos
años en un sinfín de aplicaciones. En muchas ocasiones, aplicaciones distintas pero con
funciones comunes, agrupadas en bibliotecas que se compilaban en un todo. La
heterogeneidad y el acoplamiento entre funcionalidades que podrían ser reutilizables ha
forzado el estudio de nuevas estrategias de diseño. La forma de ver estas funciones como
servicios comunes a distintos propósitos ha concluido en un nuevo paradigma de diseño
arquitectónico denominado Arquitectura SOA.
La arquitectura SOA proporciona exibilidad, reducción de costes y reutilización de

componentes y procesos de negocio. Aún está adquiriendo madurez en su proceso de
implantación en la industria, pero ya tiene una gran aceptación.
No es un concepto nuevo, sino que comenzó a tomar forma ya a mediados de los años 80, con
la computación distribuida y las llamadas a procedimientos remotos. Pero estas arquitecturas
distribuidas de los 90, como OSF, OMG o CORBA, no llegan a tener el impacto esperado en el
mercado.
Esto fue formando la base de un paradigma de arquitectura que Gartner describirá en 1996 ya
con el nombre de SOA. Sin embargo, no será hasta 2003, con el desarrollo de los servicios web,
cuando irrumpa en el mercado, convirtiéndose en una disrupción tecnológica que a día de hoy
está transformando el mundo empresarial.
Contenidos 
1. ¿Qué es SOA?
1.1. Principios SOA
2. Componentes Arquitectónicos de SOA
2.1. Componentes arquitectónicos
2.2. Patrón de interacción SOA
3. Bene cios de una arquitectura SOA
4. De nición de Servicio 
Esta web utiliza cookies propias y de terceros
5. para su correcto
Diseño funcionamiento
orientado a Servicios y para nes analíticos. Al hacer clic en el botón Aceptar, aceptas el uso de estas
tecnologías y el procesamiento
5.1. Identi de tus datos para estos propósitos. Ver
cación de Servicios
5.1.1. Aproximación Ascendente Bottom-Up
RECHAZAR ACEPTAR
5.1.2. Aproximación Descendente Top-Down
https://www.disrupciontecnologica.com/arquitectura-soa-y-composicion-de-servicios/ 1/16
5.1.3. Bottom-Up vs Top-Down

5.2. Diseño del Servicio 
5.3. Implementación
6. Servicios web y Arquitectura SOA
7. Composición de Servicios
7.1. WorkFlow
7.2. Tipos de coordinación en la composición de servicios
7.3. Orquestación
7.3.1. Lenguaje de modelado de procesos BPEL
7.3.1.1. Primitivas
7.3.1.2. Estructuradas
7.3.1.3. Estructura de un documento BPEL
7.3.1.3.1. <partnerLinks>
7.3.1.3.2. <variables>
7.3.1.3.3. <sequence>
7.4. Coreografía
7.4.1. Lenguaje de modelado de procesos CDL
7.5. Orquestación vs Coreografía
¿Qué es SOA?
SOA son las siglas en inglés de «Service Oriented Architecture» que signi ca Arquitectura
Orientada a Servicios. Este paradigma de ende un concepto de diseño de software que
promueve la utilización de servicios como soporte de las reglas de negocio. Se trata, por tanto
de la atomicidad y reutilización de estos servicios, que permitan componer distintas
aplicaciones con las mismas piezas.
Cuando hablamos de atomicidad a lo que nos referimos es a la indivisibilidad del servicio, a la

complejidad mínima. Es decir, si un servicio se puede descomponer en otros servicios, no es
atómico.
De esta manera, un diseño arquitectónico basado en servicios se centra en la integración,

interoperabilidad, modularidad, reutilización y composición a un nivel funcional de granularidad
elevada. Todo ello sujeto a la conformidad con estándares.
El nivel de granularidad se podría de nir como el nivel de detalle de una especi cación
funcional. En otros términos, la amplitud de la descripción del comportamiento esperado para
el software en una especi cación funcional.
Principios SOA
Este paradigma arquitectónico se basa en unos principios que deben servir de guía para de nir
las reglas de diseño:
Encapsulación: Los servicios ocultan su lógica de negocio, y exponen un interfaz

público para interactuar con el consumidor.
Contrato: Los servicios están adscritos a un acuerdo de nido en el documento de

descripción del servicio.
Servicios autocontenidos, con la lógica que encapsulan controlada.
Débil acoplamiento y cohesión elevada, minimizando las interdependencias entre los

propios servicios.
Abstracción: Los servicios ocultan la lógica al exterior, haciendo de «caja negra» para
el consumidor, que permite una mayor abstracción del sistema. 
Esta web utiliza cookies propias y de terceros para su correcto funcionamiento
Reutilización: y para
La división nes analíticos.
del negocio Al hacer clic enpromueve
en componentes el botón Aceptar, aceptas elde
la capacidad uso de estas
tecnologías y el procesamiento de tus datos para estos propósitos. Ver
utilizarse en distintas funcionalidades, o composiciones de lo mismos.
RECHAZAR ACEPTAR
Disrupción TecnológicaComposición: Al objeto de reutilización se añade la necesidad de ensamblarse unos

servicios con otros. Componerse en niveles superiores que permitan realizar 
Blog de divulgación de Ciencia y Tecnología funcionalidades de menor granularidad.
Descubrimiento: El diseño debe ser descriptivo y localizable mediante mecanismo de

descubrimiento.
Esto resume los principios descritos en el mani esto SOA. En este texto, elaborado por algunos
de los mayores expertos en orientación a servicios, se propone los valores y principios rectores
a seguir.
Componentes Arquitectónicos de SOA

Un diseño arquitectónico SOA constituye así un sistema distribuido, donde los componentes
desplegados son servicios, abstraídos como componentes autónomos, débilmente acoplados,
dentro de la red formada por proveedores y consumidores. De esta manera, el despliegue
distribuido, permite la deslocalización de los servicios, que pueden estar también físicamente
distribuidos.
Dentro de un concepto de arquitectura SOA hay que diferenciar los siguientes elementos:
Roles: Cada entidad de la red de componentes puede desempeñar un papel en la

misma, que en relación a la función que desempeñan puede ser:
Proveedor: Cuando la entidad publica sus servicios en el registro para que

puedan ser descubiertos, y ofrece cierta funcionalidad para demanda de los
consumidores.
Consumidor: Aquella entidad de la red de componentes en la arquitectura

SOA que demanda funcionalidad proporcionada por un servicio.
Registro: Es una entidad responsable de la publicación y descubrimiento de

servicios disponibles en la red, así como de los interfaces de los mismos.
Operaciones: Una entidad puede desempeñar las siguientes operaciones en la red de

componentes:
Publicar: El proveedor de servicios realiza la publicación de uno de ellos

para los consumidores puedan descubrirlos y usarlos.
Descubrir: Un consumidor localizará un servicio que cumpla con un cierto

criterio funcional mediante la consulta al registro de servicios.
Invocar o Usar: Una vez descubierto un servicio que satisface la necesidad

funcional, el consumidor usará dicho servicio para ejecutar una pieza
funcional teniendo en cuenta la descripción del mismo.
Artefactos: Los artefactos en una arquitectura SOA pueden ser:
Servicio: Es el componente que realiza una función sin estado,

autocontenida, y pública a través de su interfaz de descripción de servicio.
Descripción de servicio: Información del servicio descriptiva de la forma en

la que el consumidor podrá interactuar con el proveedor, incluyendo las
precondiciones, post-condiciones y/o niveles de calidad de servicio (QoS).
Componentes arquitectónicos
Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para nes analíticos. Al hacer clic en el botón Aceptar, aceptas el uso de estas
RECHAZAR ACEPTAR
Una arquitectura SOA está caracterizada básicamente por tres componentes arquitectónicos
principales: 
En primer lugar el Servicio software, que provee una funcionalidad relevante,
reutilizable y expuesta a otros sistemas a través de las interfaces basadas en
estándares.
Consumidor del Servicio: El cliente software que utilizará la funcionalidad provista por
el Servicio.
Una infraestructura de comunicaciones que conecta a los dos anteriores, y que incluye
un mecanismo de publicación y descubrimiento del Servicio.
Patrón de interacción SOA

El patrón de interacción SOA entre estos tres componentes, teniendo en cuenta los elementos
descritos anteriormente será así:
Patrón de interacción SOA
Bene cios de una arquitectura SOA

En el ámbito empresarial es esencial poderse adaptar a los cambios con agilidad, a la vez de
reducir los costes a niveles que se puedan asumir. Ahí es donde muestra la potencia el diseño
arquitectónico orientado a servicios, ofreciendo una agilidad, exibilidad y adaptabilidad a
cambios que otros diseños mas rígidos y monolíticos no pueden ofrecer.
De esta manera, las principales ventajas que ofrece SOA serán:
Composición e Integración de procesos: La arquitectura SOA proporciona un nivel de

abstracción a través de los servicios autocontenidos, con reglas de negocio
encapsuladas que permite componer nuevos procesos de negocio a partir de servicios
existentes. Esto a su vez facilita la integración.
Flexibilidad y adaptabilidad: Una arquitectura SOA crea sistemas altamente

escalables. La capacidad de generar nuevos procesos de negocio a partir de la
composición de otros existentes otorga gran exibilidad de la arquitectura, y
adaptabilidad a cambios. Esto genera a su vez ventajas evidentes:
Reutilización de activos existentes.


Costes reducidos.
Reduccióndedel
tecnologías y el procesamiento tus tiempo deestos
datos para respuesta frente
propósitos. Vera un cambio.
RECHAZAR ACEPTAR
Disrupción TecnológicaMejora de la Interoperabilidad entre plataformas y lenguajes: El nivel de abstracción de

la arquitectura permite la independización de lenguajes y plataformas. El punto de 
Blog de divulgación de Ciencia y Tecnología integración es la especi cación del servicio, no la implementación. Esto mejora la
interoperabilidad con otras plataformas y lenguajes a través del intercambio mediante
los estándares de nidos.
Es importante reseñar que la encapsulación de servicios a través de interfaces permite que su

invocación sea transparente, usando protocolos interoperables. Realmente esto es lo que
proporciona una mayor exibilidad y reutilización en el uso de una arquitectura de servicios.
Con todo esto resulta evidente que en el centro del enfoque de una arquitectura orientada a
servicios está el servicio. Todo gira entorno al servicio en SOA, por lo que debemos tener claro
en qué consiste.
De nición de Servicio
Desde el punto de vista del patrón de Arquitectura SOA un servicio es una funcionalidad
empaquetada como componente distribuido, auto-contenido y reutilizable, con una de nición
de su interfaz accesible, explícita y pública.
Esto viene a decir que un servicio es un recurso con la capacidad de realizar alguna tarea
concreta y proporcionar una funcionalidad a otras entidades solicitantes.
Así mismo, se puede abstraer un servicio como un componente débilmente acoplado en una
red de proveedores y consumidores siguiendo el patrón de interacción descrito anteriormente.
SOA distribuido
Si vemos una arquitectura de componentes como un puzzle, un servicio sería una pieza
software de las que lo componen y que proporciona una utilidad. El puzzle completo no sería
otra cosa que una composición de servicios, una composición de piezas, con un objetivo
concreto y una cohesión evidente.
En el concepto SOA de Servicio se tienen los siguientes aspectos que debe cumplir:
Un servicio encapsula funciones de negocio con un objetivo evidente de ser

reutilizadas.
Un servicio debe de nir una interfaz explícita.
Para su invocación se utilizan protocolos de comunicación enfocados en la

interoperabilidad y transparencia en cuanto a su localización.
Para poder consumir la funcionalidad que proporciona un servicio, es evidente que tiene que
existir un interfaz que las entidades solicitantes puedan utilizar. Esto se denomina «contrato». 
Una de lasybazas
tecnologías mas importantes
el procesamiento depara
de tus datos la arquitectura SOAVer
estos propósitos. es precisamente la capacidad de
interoperar servicios distribuidos. Estos servicios no tienen porqué estar construidos en la
RECHAZAR ACEPTAR
misma tecnología o lenguaje, sólo permitir la interacción en algún protocolo a través de
contrato. Es decir, una arquitectura SOA puede estar compuesta de servicios desarrollados en
.NET, Java, o Python, conectados a través de Soap, por ejemplo. 
Diseño orientado a Servicios

En esencia una arquitectura orientada a servicios constituye un sistema distribuido, donde los
componentes distribuidos son servicios independientes, abstraídos como unidades autónomas
en una red de proveedores y consumidores.
Atendiendo a esta perspectiva, y teniendo en cuenta los principios SOA vistos, podremos
introducir el proceso de diseño de servicios en SOA a través de tres etapas:
Etapas del diseño de servicio
Identi cación de Servicios

El primer paso en el diseño en una arquitectura SOA es la identi cación de funcionalidades que
puedan ser expuestas como servicios. Para ello es importante detectar las funcionalidades de
granularidad alta que cumplan los criterios para ser candidatas:
1. Fácilmente independizables y que permitan un bajo acoplamiento.
2. Alto potencial de reutilización.
Existen dos enfoques principales para abordar esta difícil e importantísima tarea de
identi cación de los servicios útiles, mediante una aproximación ascendente (Bottom-Up) y
aproximación descendente (Top-Down).
Aproximación Ascendente Bottom-Up

A partir de aplicaciones o sistemas legacy, heredadas o ya existentes en la organización, se
analizan las funcionalidades candidatas a ser expuestas como servicios.
La principal ventaja de esta aproximación es la obtención rápida de servicios de negocio, a


partir de los ya existentes. Por otro lado, los detractores de esta aproximación avisan del riesgo
de llegar ayuna
tecnologías situación denominada
el procesamiento ABOS
de tus datos para (a propósitos.
estos buch of services).
Ver Esto es, un montón de
servicios sin orden ni concierto, y con un gran número de servicios duplicados, que no se
corresponde con RECHAZAR ACEPTAR
una arquitectura SOA.
Aproximación Descendente Top-Down


Blog de divulgación de Ciencia y Tecnología En este caso el enfoque está en un análisis de los procesos de negocio, descomponiendo el
requisito de negocio en los elementos del nivel mas bajo de granularidad. Es decir, desde el
proceso de negocio, hasta llegar a procesos, subprocesos y tareas.
Por lo general, esta aproximación parte de los casos de uso como candidatos a servicios de
negocio para la exposición de funcionalidad en la plataforma SOA.
Bottom-Up vs Top-Down
Existe un activo debate entre cual de estas dos aproximaciones es la más óptima, o la mas
correcta. Por un lado, la aproximación Bottom-Up puede ser la más ágil, mientras que Top-
Down debería ser la mas el a los principios de SOA. Entre los detractores de Bottom-Up se
dice que, si se comienza a construir un servicio a partir de lo que ya tiene, se tiene un alto
riesgo de acabar con lo que ya tiene, en lugar de lo que los consumidores necesitan. Por otro
lado, entre los detractores de Top-Down, se dice que requiere una amplia plani cación y
estricto cumplimiento de las políticas, por lo que lleva un tiempo mucho mayor para conseguir
resultados.
Finalmente, un enfoque mixto, que utilice ambas aproximaciones, parece ser lo que mas
adeptos ha llegado a tener.
El método SOMA (Service Oriented Modeling and Architecture) de IBM, por ejemplo, incluye el
enfoque «Meet in the middle«, que se basa en la descomposición del proceso empresarial en
elementos granulares para su correlación con las aplicaciones existentes.
También es frecuente el llamado enfoque «Middle out» que combina simultáneamente los
enfoques Top-Down y Bottom-Up. Esto es, de nir los procesos de negocio respondiendo a los
requisitos de negocio, a la vez que se de nen servicios que aprovechan los sistemas
existentes.
La principal tendencia actual se basa en el uso de ambas, con una primera fase Bottom-Up que
a ore y exponga los servicios existentes, para pasar a una fase posterior de Top-Down, donde
se analicen los procesos de negocio, y se asegure su alineación con la estrategia de la
organización.

RECHAZARSOA
Aproximaciones ACEPTAR
Una vez identi cados, tanto los servicios existentes como los nuevos servicios que respondan
a los procesos de negocio, se confecciona un inventario de servicios. En él se indicarán las
Blog de divulgación de Ciencia y Tecnología relaciones entre servicios y objetivos de la empresa, evitando la duplicidad o inconsistencia en
los nuevos servicios.
Diseño del Servicio

Una vez identi cados los servicios, se realizarán las tareas de la fase de diseño, donde:
De nir los contratos de cada servicio, incluyendo:
La interfaz y parámetros.
Descripción de la funcionalidad.
Políticas.
Restricciones.
Clasi car y Categorizar en función de su naturaleza. Por ejemplo en servicios

estratégicos para la empresa, servicios básicos, servicios de soporte, etc.
Diseño arquitectónico del sistema que permita satisfacer los requisitos, y establecer la
estructura mas adecuada a nivel lógico y físico, evitando confundir capas y niveles:
Una arquitectura monolítica.
O bien arquitectura Cliente/Servidor.
Arquitectura en tres capas.
Implementación
Finalmente, se selecciona la tecnología mas adecuada que permita la implementación y
despliegue de la funcionalidad identi cada como servicio. Esta etapa lleva a cabo la
construcción o suscripción, adaptación o integración de una funcionalidad existente a la
arquitectura tecnológica seleccionada.
Durante todo el proceso es evidente que se deben respetar los principios SOA, y hacer efectivo
en el diseño y la implementación los criterios de bajo nivel de acoplamiento, independencia y
reutilización. Uno de los objetivos de SOA es aislar al servicio de la plataforma, sistema
operativo, hardware, lenguaje, protocolo, localización, etc. En resumen, minimizar el
acoplamiento de la uniadad funcional.
Servicios web y Arquitectura SOA

Hay una confusión bastante frecuente entre WebServices y SOA. Se tiende a asemejar ambos
conceptos que, no son lo mismo, debido a que, frecuentemente, se utilizan Web Services para
la implementación SOA. Pero SOA no involucra a una tecnología concreta. Es decir, no tiene
porqué implementarse sobre WebServices, y un sistema implementado con Web Services no
tiene por qué ser una arquitectura SOA.
SOA es un estilo arquitectónico, un paradigma de diseño, mientras que Web Service es una
tecnología. Por tanto, es posible que una implementación con servicios web dé soporte
tecnológico a una arquitectura SOA. Sin embargo, podríamos tener una arquitectura SOA sin

que exista ni un solo servicio web.
Composición de Servicios
RECHAZAR ACEPTAR
La composición de servicios es uno de los principios de diseño en arquitectura SOA. De hecho,

es lo que da sentido a una arquitectura orientada a servicios. Viene a ser, la construcción de

Blog de divulgación de Ciencia y Tecnología funcionalidades complejas, en un nivel de abstracción menor, a partir de elementos atómicos
de un nivel de abstracción mayor.
Como piezas LEGO, y esto inspira la imagen de portada, construir un nuevo proceso como la
composición de servicios existentes.
En el diseño de un nivel de funcionalidad es posible que exista alguna agregación de servicios

existentes para constituir un proceso de negocio de mayor envergadura (agregado).
La composición de servicios permite agregar servicios de un nivel de abstracción menor, o

integrar servicios existentes, para el desarrollo de nuevos procesos de negocio.
Es frecuente que un nuevo proceso de negocio se pueda descomponer en etapas o una serie
de actividades. Dichas actividades podrían realizarse a través de servicios ya existentes.
El ejemplo más fácil lo podemos tener en un buscador de viajes que ofrece la posibilidad de
contratar un paquete integral. Dicho buscador puede ofrecer la reserva de vuelo, hotel y
transporte local. El proceso viene a descomponerse en distintos servicios, y la secuencia de
subprocesos, en este caso servicios, que describen el proceso mayor se denomina work ow.
WorkFlow Reserva de viaje
WorkFlow
El work ow o ujo de proceso es un modelo de proceso empresarial representado con
diagramas UML, o con la notación BPMN (Business Process Modeling Notation). Es el estudio
de lo relativo a las operaciones que se desarrollan en una actividad o proceso. Estas
operaciones pueden incluir, por ejemplo, sincronización de tareas, el orden de las mismas, la
forma en que se realizan o cómo uye la información a lo largo del proceso.
Se trata por tanto de la descripción de un trabajo colaborativo.

En un work ow se distinguen tres tipos de actividades diferentes:
1. Colaborativas: En aquellas donde un conjunto de entidades trabajan sobre el mismo
repositorioRECHAZAR ACEPTAR
de datos para obtener un resultado común. El trabajo de cada una de ellas
tiene entidad en sí mismo.

2. Cooperativas: En este caso, cada entidad trabaja sobre su propio conjunto de datos
Blog de divulgación de Ciencia y Tecnología particular, y se establece un mecanismo de cooperación entre ellos. El trabajo de
ninguna una de ellas tiene entidad, salvo desde el punto de vista del resultado nal.
3. Actividades de coordinación: Donde distintas entidades se coordinan entre sí para

realizar un determinado trabajo.
Tipos de coordinación en la composición de servicios

La composición de servicios no es una tarea simple, ya que, en la ejecución del work ow de un
proceso compuesto se puede requerir interacciones intermedias. Estas interacciones entre
servicios pueden contemplar manejo de excepciones, errores, ujos condicionales o
bifurcaciones, lo que puede complicar el ujo.
Para el proceso de composición de servicios se deben establecer los requisitos de

composición, y la identi cación, selección y creación de procesos. Para ello se utiliza un
lenguaje de composición que permita especi car todos los aspectos de la misma.
Además, un punto determinante en la composición está relacionado con el tipo de

coordinación de los servicios para llegar a formar un proceso de negocio. En este aspecto
podemos encontrar dos enfoques: Orquestación y Coreografía.
Orquestación
El concepto de orquestación de servicios tiene mucha relación con el concepto que tenemos
de una orquesta musical. En una orquesta existe un director, y un conjunto de instrumentos.
Todos los instrumentos participan de alguna manera en la música, de forma coordinada, y es el
director quien coordina.
En una orquestación de servicios, existe un proceso central que lleva el control del resto de
servicios implicados en la realización de una tarea. Coordina la el ujo de ejecución de las
diferentes operaciones.
Los servicios orquestados no conocen su implicación en un proceso de composición de una

tarea de nivel superior. No saben que están siendo coordinados como pieza de una tarea de
nivel mas alto. Únicamente el coordinador es quien conoce el objetivo a obtener, y por tanto la
orquestación está centralizada en operaciones, y en el orden en que invocar los servicios
¿Recuerdas la película Cube…?

Orquestación
RECHAZAR ACEPTAR
Lenguaje de modelado de procesos BPEL


Blog de divulgación de Ciencia y Tecnología WS-BPEL 2.0, conocido como BPEL (Business Process Execution Language) es un lenguaje de
orquestación de servicios basado en XML. Soporta las principales tecnologías de servicios
Web, tales como SOAP, WSDL, UDDI, WS-Reliable messaging, WS-Addressing, WS-Transaction y
WS-Coordination.
BPEL se mantiene por OASIS desde el 2004, con un fuerte apoyo de la industria. Ser una
con uencia de dos lenguajes de work ow anteriores: WSFL, de IBM, y XLANG, de Microsoft,
proporciona dicho apoyo. Sin embargo, BPEL está diseñado especí camente como lenguaje
para la de nición de procesos de negocio, soportando dos tipos:
Procesos de negocio ejecutables: Especi can todos los detalles de los procesos de
negocio implicados.
Procesos abstractos de negocio: Solo especi can el intercambio de mensajes

públicos entre las partes implicadas.
Un proceso BPEL está compuesto por actividades. El lenguaje de ne dos tipos de actividades
para la composición de servicios: primitivas y estructuradas.
Primitivas
Las primitivas son actividades básicas para la construcción de una composición, y podemos
encontrar tareas como:
Invocación (Invoke): Permite invocar a un servicio web, tanto de forma síncrona

(request-response) como asíncrona (one-way)
Recepción (Receive): Permite bloquear un proceso mientras espera la llegada de un

mensaje.
Respuesta (Response): Se utiliza para enviar una respuesta a una solicitud o mensaje
previo.
Espera (Wait): Para forzar una espera en un proceso, durante un tiempo determinado.
Asignación (Assign): Permite asignar un valor a una variable.
Lanzamiento (Throw): Como en otros lenguajes, permite arrojar una excepción.
Finalización (End): Finalización de la orquestación en curso.
Estructuradas
Las actividades estructuradas combinan varias de las anteriores, y permiten un control del ujo
mas detallado. Por ejemplo, tenemos:
Sequence: De nir un conjunto de actividades que se realizarán de forma ordenada y

secuencial.
Swtich: Para incluir bifurcaciones del ujo.
While: Permite de nir bucles, repitiendo un grupo de tareas hasta cumplir la condición
de salida.
Flow: Para la paralelización de tareas.
Pick: Permite la selección de actividades a realizar de forma condicionada, según la

llegada de un mensaje, por ejemplo.

tecnologías yel
Realmente el lenguaje
procesamiento
BPELdeestá
tus datos para en
basado estos propósitos.
WSDL, Ver
de manera que, un proceso WS-BPEL puede
ser expuesto e invocado a través de su propio WSDL.
RECHAZAR ACEPTAR
Estructura de un documento BPEL


La estructura básica de un documento donde se de ne el proceso BPEL está compuesta de
tres secciones, además de la principal que de ne el proceso:
< PA RT N E R L I N K S >
PartnerLinks es la sección donde se de nen los agentes que interaccionan en el proceso BPEL.
Cada agente lleva un PartnerLink, y está de nido por un parterLinkType, además del rol.
El partnerLinkType especi ca la relación entre dos servicios, de niendo el portType donde cada
servicio va a recibir los mensajes.
< VA R I A B L E S >
En el identi cativo variables se declaran las variables que se utilizarán para almacenar y
transformar mensajes del proceso BPEL. Es decir, las variables se utilizarán para el envío y
recepción de mensajes a partners.
BPEL de ne tres tipos de variables:
WSDL Message Type: Indicado con el atributo messageType.
XML Schema Type: Con el atributo type.
XML Schema Element: Re ejado con el atributo element.
Cada variable se declarará en un <scope> donde tendrá visibilidad como global o local.
Deberán ser inicializadas antes de utilizarse, y para hacerlo podremos utilizar la actividad
<assign> para asignarle un mensaje.
<SEQUENCE>
Dentro de esta etiqueta contendrá las actividades que conforman el proceso BPEL.
1 <process name="nameProcess">
2 <partnerLinks>
3 
4 </partnerLinks>
5 <variables>
6 
7 </variables>
8 <sequence>
9 
10 </sequence>
11 </process>
Aunque BPEL no tiene una notación grá ca estándar, se utiliza BPMN para su especi cación,
con traducción a BPEL.
Coreografía
En la coreografía podríamos asimilar el concepto que tenemos de una coreografía de
bailarines, donde no existe un líder, no hay un coordinador. Un grupo de danza donde todos se
mueven de forma coordinada, conociendo la “coreografía”.
De igual manera, una coreografía de servicios no está coordinada por un proceso central, sino
que cada servicio implicado conoce el plan, el objetivo a conseguir, y el papel que le
corresponde. Cada servicio sabe cuando debe ejecutar sus operaciones y con qué otro servicio
debe interactuar.
Se trata de un trabajo colaborativo enfocado en el intercambio de mensajes en los procesos de 

negocio. Los servicios forman parte de un proceso de negocio, conocido por todos ellos.
RECHAZAR ACEPTAR

Coreogra a
Lenguaje de modelado de procesos CDL

WS-CDL (Web Services Choreography Description Languaje) ha sido el lenguaje basado en XML
utilizado para la de nición de servicios en composición por coreografía.
Este lenguaje describe la colaboración entre los servicios que conforman la composición
coreográ ca, en el conjunto. Es decir, bajo un punto de vista global y común de la composición.
WS-CDL no de ne procesos ejecutables, se trata de un lenguaje de de nición, sino que permite

de nir las interacciones entre los participantes.
Antes de WS-CDL se utilizaba WSDL para describir los comportamientos «observables» de los
servicios, pero WS-CDL vino a cubrir algunas carencias. Entre ellas, permitir la descripción de
elementos «no observables» como la integración entre dos servicios en el marco del objetivo
funcional propuesto.
El desarrollo de WS-CDL, que estuvo mantenido por la W3C, fue abandonado tras cerrar el
grupo de trabajo de la W3C Web Services Choreography Working Group en el 10 de Julio de
2009.
Orquestación vs Coreografía
Como hemos visto, la orquestación de servicios y la coreografía son dos tipos de coordinación
diferentes en una composición de servicios. El enfoque de coordinación con orquestación se
ha impuesto por diversas razones:
La orquestación es mas exible, al estar coordinados por un coordinador central los

servicios son mas fácilmente modi cables, sustituibles y reutilizables.
Los servicios se pueden incorporar a la composición sin ser conscientes de ello, sin
sufrir cambios.
Es más ágil crear escenarios alternativos en caso de cambio o fallo.
Para un enfoque Bottom-Up sólo es posible una composición con orquestación, que
permite incluso orquestar servicios legacy.
Comparte esto:

Esta web utiliza cookies propias y de terceros
 para su correcto
Facebook funcionamiento
 Twitter y para
 LinkedIn nes analíticos. Al hacer clic en el botón Aceptar, aceptas el uso de estas
WhatsApp
RECHAZAR ACEPTAR
Arquitectura
Disrupción Tecnológica Interoperabilidad SOA

Jose Ramon Pascual

Ingeniero Informático de Sistemas por la Universidad de Málaga. Grado en Ingeniería Informática por
AUTOR
la U. Internacional de La Rioja. Máster en Dirección de Proyectos, y Posgrados en Biotecnología,
Bioingeniería, e-Health y Telemedicina por UNED. Comencé trabajando en automatización industrial en
el sector de automoción, pero pronto pasé al sector sanidad, donde he trabajado durante 13 años en
proyectos de sistemas de información vinculados a 79 hospitales de España de los servicios de
sanidad de 15 comunidades autónomas, y Portugal. Tras 10 años de experiencia en interoperabilidad
en sanidad con HL7 y Mirth Connect, he decidido divulgar experiencias sobre este motor.
30 ENTRADAS
TAMBIÉN TE PUEDE INTERESAR
 
Publicada 1 diciembre, 2019 Publicada 2 abril, 2020
Arquitectura de Servicios Web Conectar Informix en Mirth Connect
2 Comentarios
Deja un comentario
Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *
C O M E N TA R I O

RECHAZAR ACEPTAR
*NOMBRE

*CORREO ELECTRÓNICO
WEB
GUARDA MI NOMBRE, CORREO ELECTRÓNICO Y WEB EN ESTE

N AV E G A D O R PA R A L A P R Ó X I M A V E Z Q U E C O M E N T E .
RECIBIR UN CORREO ELECTRÓNICO CON LOS SIGUIENTES

C O M E N TA R I O S A E S TA E N T R A D A .
R E C I B I R U N C O R R E O E L E C T R Ó N I C O C O N C A D A N U E VA E N T R A D A .
PUBLICAR EL COMENTARIO
2 ideas sobre “Arquitectura SOA y Composición de

Servicios”
2 Comentarios
Pau 15 enero, 2020, 2:57 pm

La arquitectura SOA no es la panacea, y conlleva un esfuerzo considerable para la organización
llevarla a cabo (las empresas españolas no son muy dadas a invertir en TIC), pero está claro que es
el futuro. Buen artículo introductorio. Saludos.
RESPONDER
Julian 17 enero, 2020, 3:05 pm

Hola. Estoy interesado en aprender BPEL ¿Saben alguna plataforma donde pueda probar desarrollos
de composición y orquestación de servicios con BPEL?
Me está entusiasmando la arquitectura SOA.
RESPONDER
 ARQUITECTURA DE SERVICIOS WEB  CONVERTIR XML A ER7 EN MIRTH CONNECT 
Etiquetas
Agujero negro (1) algoritmos (3) Arquitectura (3) buenas prácticas (3) Cambio horario (2) carcinógenos (1) Como (8)
Database (4) desinfección (1) disrupcion (1) e-Salud (7) ecologismo (4) epidemia (1) ER7 (2) Error (1)
Event horizont telescope (1) eventos (4) excel (1) HL7 (7) Horizonte de sucesos (1) Howto (8) Interoperabilidad (17)
IOT (1) JDBC (1) Layer (1) m87 (1) Medicamentos (1) Mirth Connect (10) modularización (1) Open Source (5)
optimización (2) Oracle (4) PL/SQL (2) productos químicos (1) Raspberry (1) riesgos (1) Salud (6) SOA (2) SQL (2)
Esta web utiliza

tecnologica (1) cookies propias
toxicidad (1)y de terceros para su (1)
Transcripción correctovacunas
funcionamiento
(1) yWeb
para Service
nes analíticos.
(2) Al
XMLhacer
(2)clic en el botón Aceptar, aceptas el uso de estas
© 2021 Disrupción Tecnológica – Todos los derechos reservados  

RECHAZAR ACEPTAR
Funciona con  – Diseñado con el Tema Customizr
Aviso Legal Política de Privacidad Política de Cookies 

RECHAZAR ACEPTAR

Arquitectura SOA y Composición de Servicios - Disrupción Tecnológica

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitectura SOA y Composición de Servicios - Disrupción Tecnológica

Cargado por

Copyright:

Formatos disponibles

17/2/2021 Arquitectura SOA y Composición de Servicios - Disrupción Tecnológica

Inicio » Ingenieria » Arquitectura SOA y Composición de Servicios

  INGENIERIA / INTEROPERABILIDAD / TECNOLOGIA

La arquitectura SOA proporciona exibilidad, reducción de costes y reutilización de

5.1.3. Bottom-Up vs Top-Down

Cuando hablamos de atomicidad a lo que nos referimos es a la indivisibilidad del servicio, a la

De esta manera, un diseño arquitectónico basado en servicios se centra en la integración,

Encapsulación: Los servicios ocultan su lógica de negocio, y exponen un interfaz

Contrato: Los servicios están adscritos a un acuerdo de nido en el documento de

Servicios autocontenidos, con la lógica que encapsulan controlada.

Débil acoplamiento y cohesión elevada, minimizando las interdependencias entre los

Disrupción TecnológicaComposición: Al objeto de reutilización se añade la necesidad de ensamblarse unos

Descubrimiento: El diseño debe ser descriptivo y localizable mediante mecanismo de

Componentes Arquitectónicos de SOA

Roles: Cada entidad de la red de componentes puede desempeñar un papel en la

Proveedor: Cuando la entidad publica sus servicios en el registro para que

Consumidor: Aquella entidad de la red de componentes en la arquitectura

Registro: Es una entidad responsable de la publicación y descubrimiento de

Operaciones: Una entidad puede desempeñar las siguientes operaciones en la red de

Publicar: El proveedor de servicios realiza la publicación de uno de ellos

Descubrir: Un consumidor localizará un servicio que cumpla con un cierto

Invocar o Usar: Una vez descubierto un servicio que satisface la necesidad

Artefactos: Los artefactos en una arquitectura SOA pueden ser:

Servicio: Es el componente que realiza una función sin estado,

Descripción de servicio: Información del servicio descriptiva de la forma en

Patrón de interacción SOA

Patrón de interacción SOA

Bene cios de una arquitectura SOA

De esta manera, las principales ventajas que ofrece SOA serán:

Composición e Integración de procesos: La arquitectura SOA proporciona un nivel de

Flexibilidad y adaptabilidad: Una arquitectura SOA crea sistemas altamente

Reutilización de activos existentes.

Disrupción TecnológicaMejora de la Interoperabilidad entre plataformas y lenguajes: El nivel de abstracción de

Es importante reseñar que la encapsulación de servicios a través de interfaces permite que su

Un servicio encapsula funciones de negocio con un objetivo evidente de ser

Un servicio debe de nir una interfaz explícita.

Para su invocación se utilizan protocolos de comunicación enfocados en la

Diseño orientado a Servicios

Etapas del diseño de servicio

Identi cación de Servicios

1. Fácilmente independizables y que permitan un bajo acoplamiento.

2. Alto potencial de reutilización.

Aproximación Ascendente Bottom-Up

La principal ventaja de esta aproximación es la obtención rápida de servicios de negocio, a

Aproximación Descendente Top-Down

Diseño del Servicio

De nir los contratos de cada servicio, incluyendo:

Clasi car y Categorizar en función de su naturaleza. Por ejemplo en servicios

Una arquitectura monolítica.

O bien arquitectura Cliente/Servidor.

Arquitectura en tres capas.

Servicios web y Arquitectura SOA

La composición de servicios es uno de los principios de diseño en arquitectura SOA. De hecho,

En el diseño de un nivel de funcionalidad es posible que exista alguna agregación de servicios

La composición de servicios permite agregar servicios de un nivel de abstracción menor, o

WorkFlow Reserva de viaje

Se trata por tanto de la descripción de un trabajo colaborativo.

tiene entidad en sí mismo.

3. Actividades de coordinación: Donde distintas entidades se coordinan entre sí para

Tipos de coordinación en la composición de servicios

Para el proceso de composición de servicios se deben establecer los requisitos de

Además, un punto determinante en la composición está relacionado con el tipo de

Los servicios orquestados no conocen su implicación en un proceso de composición de una