Este capítulo introduce el concepto de Arquitectura Orientada a Servicios (SOA), definiéndola como un paradigma arquitectónico que permite a las organizaciones construir sistemas mediante la composición de servicios autónomos e independientes. Explica los cuatro principios clave del diseño de servicios y presenta un modelo abstracto de referencia para SOA compuesto por exposición, composición y consumo. Finalmente, describe las capacidades arquitectónicas recursivas que ofrece SOA, como mensajes, flujos de trabajo y datos.

1. i
La Arquitectura
Orientada a
Servicios (SOA)
en el Mundo Real
John Evdemon
Editorial “Capitán San Luis”
Traducción: Carlos de Armas García
Revisión: Dr. Leonel Iriarte Navarro

3. Nota del traductor
El desarrollo de la informática facilitará la conexión con la mayor parte del universo de
objetos, a través de la denominada Internet de las cosas, la que ofrecerá la capacidad real de
interconectar y seguir el movimiento de millones de objetos mediante el empleo del IPV6 y
otras tecnologías como RFID.
Sin embargo, para poder garantizar el acceso real a la diversidad de objetos físicos, será
necesario construir las interfaces estándares que los conviertan en elementos
consumibles desde las nuevas aplicaciones. Para lograr dicho propósito, el enfoque orientado
a servicios, tratado en este libro, adquiere especial importancia.
Este enfoque tiene su base tecnológica en la programación orientada a objetos, donde se
dio un importante paso en la reusabilidad del código y la separación de la interfaz con
respecto a la implementación. Los modelos Corba y DCOM se propusieron entonces recorrer
la última yarda hacia esta meta e introdujeron el concepto de llamada a procedimientos
remotos que ha sido uno de los pilares de todo el desarrollo posterior.
A partir de todas estas premisas surge SOA, con todas sus bondades para el descubrimiento,
la auto descripción y la carga dinámica. Entonces, la reusabilidad se ha transformado en
interoperabilidad en entornos totalmente heterogéneos en los cuales, una solución
informática puede entonces estar conformada por bloques que residen en equipos distantes
con plataformas de hardware que pueden ser distintas y sobre sistemas operativos que
pueden ser también diferentes.
Microsoft ha trabajado intensamente en el desarrollo de plataformas orientadas a servicios
desde la década de los 90 del pasado siglo. En el 2007, después de alcanzar una madurez
notable en este enfoque, encomendó la publicación del libro electrónico gratuito “SOA in the
Real World”, cuya traducción al castellano presentamos ahora, precisamente teniendo en
cuenta la importancia que concedemos a la generalización de estos conceptos entre los
desarrolladores de hoy y mañana.
El autor del texto, John Evdemon, es un experto en los temas de SOA, BPM y XML, que por el
tiempo en que este libro fue publicado, pertenecía al equipo de estrategias en arquitecturas
de Microsoft. Actualmente se encuentra involucrado en proyectos de computación en la nube,
SOA y arquitecturas orientadas a eventos.
El libro está dividido en 6 capítulos. Los dos primeros tienen un carácter introductorio acerca
de la tecnología. Estos examinan los principios que Microsoft propone para SOA, introducen
el modelo abstracto de referencia para SOA, así como el modelo de madurez SOA (ESOMM),
discuten los aspectos relacionados con el ciclo de vida de un servicio, ofrecen la taxonomía
de un servicio y describen los escenarios SOA.
Los capítulos subsiguientes, tratan diferentes aspectos relacionados con la aplicabilidad
del enfoque SOA en el manejo de los flujos de trabajo, los procesos y los datos, así como en
la interacción con el usuario, y el control de la identidad y el acceso.
Todos los aspectos son conceptualmente tratados de modo general, y luego son
contextualizados a través de estudios de casos, que muestran cómo estos aspectos son
considerados por los productos y tecnologías de Microsoft, en el mundo real.

4. Para la conformación del libro que ponemos ahora en manos del lector, además de la
traducción del material original, se han introducido algunos cambios que es necesario
comentar. En primer lugar, por la forma en que apareció este trabajo originalmente en
Internet, como una serie de artículos, hemos decidido unificar las secciones de
agradecimientos y referencias, en apartados únicos al inicio y final del texto, respectivamente.
Por otra parte, se ha adicionado un apéndice con un glosario de acrónimos (siglas) al final de
los capítulos originales, ya que el contenido se encuentra saturado de este tipo de
referencias, y pudiera resultar engorroso al lector la búsqueda por todo el texto de los
significados de cada acrónimo, si este solo se mostraba en la primera aparición, como es
usual en la literatura técnica.
La Habana, diciembre de 2011
Carlos de Armas García

5. Agradecimientos del autor
La mayor parte del contenido de este libro está tomado de una amplia variedad de fuentes.
Parte del contenido es nuevo, mientras que otra parte puede haber aparecido en otros
materiales en diferentes formatos.
Muchos de los conceptos tratados en el Capítulo 1 se basan en esfuerzos anteriores ya
publicados. Queremos agradecer a las siguientes personas por su trabajo en esta área: Don
Box (los cuatro principios), John Devadoss (capacidades recurrentes de la arquitectura), y
Kris Horrocks (Exposición/Composición/Consumo).
El capítulo 2 está conformado a partir del trabajo de los siguientes individuos: Mark Baciak
(ciclo de vida), Atanu Bannerjee (OBA), Shy Cohen (Taxonomía), William Oellermann
(Modelo de madurez SOA), and Brenton Webster (Caso de estudio).
El capítulo 3 está conformado por el trabajo de Dave Green (conceptos, semántica, valor y
capacidades, Windows Workflow Foundation) y de John Evdemon (conceptos, términos y
manifiesto de flujo).
Los conceptos discutidos en el capítulo 4 han sido elaborados a partir de materiales
presentados en este mismo espacio1. Queremos agradecer a las siguientes personas por su
trabajo en esta área: Roger Wolter (aspectos relacionados con los datos, generalidades de
MDM, Arquitectura de los conectores en MDM), Kirk Haselden (MDM).
El capítulo 5 se basa en las presentaciones y notas aportadas por Simon Guest.
Los conceptos discutidos en el capítulo 6 han sido tomados completamente de esfuerzos
anteriores en este mismo espacio. Deseamos agradecer a las siguientes personas por su
trabajo en esta área: Kim Cameron (Las leyes de la identidad) y Fred Chong (términos,
conceptos y escenarios de identidad federada, y diseño de subsistemas de confianza).
1
Hace referencia a MSDN Blogs, sitio en que apareció originalmente este libro y otros materiales precedentes.

7. Tabla de Contenido
Capítulo 1: Arquitectura Orientada a Servicios (SOA) .......................1
Guía para el lector .................................................................................................. 1
Introducción a SOA ................................................................................................. 2
El elefante SOA. .............................................................................................................. 2
Una simple definición para SOA ...................................................................................... 3
SOA, Mitos y realidades .................................................................................................. 5
La evolución de SOA ....................................................................................................... 6
¿Por qué debo estar informado acerca de SOA? ............................................................ 8
Entendiendo los servicios ..................................................................................... 10
Los principios del diseño de servicios ........................................................................... 11
Principio 1: Las fronteras son explícitas. ....................................................................... 11
Principio 2: Los servicios son autónomos...................................................................... 13
Principio 3: Los servicios comparten el esquema y el contrato, no las clases .............. 14
Principio 4: La compatibilidad de los servicios se basa en políticas .............................. 16
Un modelo abstracto de referencia para SOA ...................................................... 17
Exposición ..................................................................................................................... 18
Composición .................................................................................................................. 18
Consumo ....................................................................................................................... 18
Capacidades arquitectónicas recursivas ............................................................... 20
Mensajes y servicios...................................................................................................... 20
Flujos de trabajo y procesos .......................................................................................... 21
Datos ............................................................................................................................. 21
Interacción con el usuario .............................................................................................. 21
Identidad y acceso ......................................................................................................... 21
Gestión .......................................................................................................................... 21
Soporte para las capacidades arquitectónicas comunes .............................................. 22
Las capacidades arquitectónicas comunes y el modelo abstracto de referencia para
SOA ...................................................................................................................... 23
Exposición ..................................................................................................................... 23
Composición .................................................................................................................. 25
Consumo ....................................................................................................................... 27
Resumen............................................................................................................... 29
Capítulo 2: Mensajes y Servicios .......................................................31
Guía para el lector ................................................................................................ 31

8. Entendiendo los servicios ..................................................................................... 32
Un modelo de madurez de SOA (¿algún otro?) ............................................................ 32
Taxonomía de un servicio ..................................................................................... 36
Servicios de Utilidades .................................................................................................. 38
Servicios de Aplicaciones .............................................................................................. 39
Servicios de Entidades .................................................................................................. 39
Servicios de Capacidades ............................................................................................. 41
Servicios de Actividades ................................................................................................ 43
Servicios de Procesos ................................................................................................... 44
Ciclo de vida de un servicio .................................................................................. 46
Análisis del servicio ....................................................................................................... 46
Desarrollo del servicio ................................................................................................... 46
Verificación del servicio ................................................................................................. 47
Aprovisionamiento del servicio ...................................................................................... 47
Operación del Servicio................................................................................................... 47
Consumo del servicio .................................................................................................... 48
Gestión de los cambios del servicio .............................................................................. 48
Desactivación del servicio ............................................................................................. 48
Escenarios SOA .................................................................................................... 49
Integración de la información......................................................................................... 49
Integración de sistemas heredados ............................................................................... 49
Gobernabilidad de procesos .......................................................................................... 49
Acceso consistente ........................................................................................................ 50
Virtualización de los recursos ........................................................................................ 50
Externalización de procesos .......................................................................................... 50
Otros escenarios............................................................................................................ 50
SOA y el usuario final............................................................................................ 51
¿Qué son las aplicaciones compuestas? ...................................................................... 53
¿Qué parece una aplicación compuesta? ..................................................................... 56
Beneficios esperados de la composición y como alcanzarla......................................... 58
Resumen............................................................................................................... 59
Estudio de caso SOA: Banco del Commonwealth en Australia ............................ 60
Capítulo 3: Flujos y procesos .............................................................61
Guía para el lector ................................................................................................ 61
Entendiendo los flujos ........................................................................................... 62
¿Qué es un flujo? .......................................................................................................... 62
Terminología utilizada en los flujos de trabajo............................................................... 62

9. ¿Por qué flujos?............................................................................................................. 63
Un modelo de flujos de trabajo ...................................................................................... 64
Contratos en los flujos de trabajo .................................................................................. 65
Colaboración en la resolución de problemas................................................................. 66
Operaciones de secuencias de comandos .................................................................... 68
Regla y política .............................................................................................................. 69
Valor de la plataforma de flujos de trabajo .................................................................... 71
Explotación más semántica ........................................................................................... 73
Características de la plataforma .................................................................................... 74
Una plataforma común de tiempo ejecución para flujos de trabajo ............................... 75
Atacando los problemas ................................................................................................ 77
Manifiesto de un flujo de trabajo ........................................................................... 78
Agilidad .......................................................................................................................... 78
Abstracción .................................................................................................................... 78
Los flujos de trabajo están en todas partes ................................................................... 79
Los flujos de trabajo son expresivos.............................................................................. 83
Los flujos de trabajo son fluidos .................................................................................... 85
Los flujos de trabajo son inclusivos ............................................................................... 86
Los flujos de trabajo son transparentes ......................................................................... 86
Comprendiendo la relación entre BizTalk Server y WF......................................... 87
Resumen............................................................................................................... 88
Estudio de caso SOA: Grupo Dollar Thrifty Automotive ........................................ 89
Capítulo 4: Datos..................................................................................91
Guía para el lector ................................................................................................ 91
Desafíos que enfrenta SOA en relación con los datos .......................................... 92
Generalidades ............................................................................................................... 92
Aspectos relacionados con la integración de datos ....................................................... 92
Escalabilidad de la Base de Datos ................................................................................ 94
Gestión de Datos Maestros (MDM) ....................................................................... 98
¿Qué es MDM? ............................................................................................................. 98
Integración de Datos de los Clientes (CDI) ................................................................... 99
Gestión de la Información de Productos (PIM) .............................................................. 99
Arquitectura de concentradores de la Gestión de Datos Maestros (MDM) ................... 99
Estilos de arquitecturas para concentradores ............................................................. 100
Aspectos arquitectónicos ............................................................................................. 104
Versiones y jerarquías ................................................................................................. 105
Población y sincronización .......................................................................................... 110

10. Publicación de las actualizaciones .............................................................................. 116
Integridad y confiabilidad de los datos......................................................................... 118
Metadatos .................................................................................................................... 118
Administración y gobernabilidad .................................................................................. 119
Perfilado de los datos .................................................................................................. 120
Exportación .................................................................................................................. 120
Reportería .................................................................................................................... 120
Flujos de trabajo y reglas de negocio .......................................................................... 120
Herramientas ............................................................................................................... 121
Resumen............................................................................................................. 122
Estudio de caso SOA: Bolsa de valores de Londres ........................................... 123
Capítulo 5: Interacción con el usuario .............................................125
Guía para el lector .............................................................................................. 125
¿Qué es la arquitectura?..................................................................................... 126
Introducción de una plataforma para UX............................................................. 128
Interfaz ......................................................................................................................... 128
Interacción ................................................................................................................... 135
Infraestructura.............................................................................................................. 140
Resumen............................................................................................................. 149
Estudio de caso SOA: Aeropuerto de Zúrich ...................................................... 150
Capítulo 6: Identidad y acceso .........................................................151
Guía para el lector .............................................................................................. 151
Identidad y Acceso .............................................................................................. 152
Generalidades ............................................................................................................. 152
Diseño del subsistema de confianza ................................................................... 154
Prácticas actuales........................................................................................................ 155
Diseño del subsistema de confianza ........................................................................... 160
Extensiones de procesos para el subsistema de confianza ........................................ 162
Políticas del subsistema de confianza ......................................................................... 163
Trasmisión de los reclamos de identidad .................................................................... 164
Mapeo identidad/credencial ......................................................................................... 167
Beneficios del diseño ................................................................................................... 167
Un metasistema de identidad .............................................................................. 169
¿Qué es el metasistema de identidad? ....................................................................... 169
Las identidades funcionan en contexto ....................................................................... 170

11. Las leyes de la identidad ............................................................................................. 171
Roles dentro del metasistema de identidad................................................................. 172
Componentes del metasistema de identidad............................................................... 172
Beneficios del metasistema de Identidad .................................................................... 174
Una arquitectura para el metasistema de identidad: los servicios Web WS-* ............. 175
Implementación del metasistema de identidad............................................................ 176
Resumen............................................................................................................. 179
Estudio de caso SOA: OTTO .............................................................................. 180
Apéndice A. Glosario de acrónimos ................................................181
Referencias .........................................................................................187

13. 1
Capítulo 1: Arquitectura Orientada a Servicios (SOA)
“Las SOAs son como copos de nieve – no hay dos iguales.”
- David Linthicum
Consultor
Guía para el lector
Los lectores de este capítulo aprenderán acerca de algunos de los conceptos generales
asociados con la Arquitectura Orientada a Servicios (SOA). El capítulo ofrece varias
analogías para la comprensión del concepto de orientado a servicios y algunas
recomendaciones de alto nivel para el diseño de servicios. En este capítulo se ofrece un
modelo abstracto para describir SOA y se introduce un conjunto de capacidades de la
arquitectura que se analizarán en los capítulos siguientes del libro.

14. 2 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
Introducción a SOA
El elefante SOA.
SOA se ha convertido en un acrónimo muy conocido y además algo polémico. Si uno pide a
dos personas una definición de SOA, es probable que reciba dos respuestas muy diferentes,
posiblemente en conflicto. Algunos describen a SOA como una infraestructura de TI
(tecnologías de la información) para la implementación del negocio, mientras que otros ven a
SOA como la vía para aumentar la eficiencia de las TI.
En muchos sentidos, SOA es un poco como el poema de John Godfrey Saxe sobre los ciegos
y el elefante. Seis hombres ciegos de Indostán encuentran un elefante. Cada uno de los
hombres, a continuación, describe al elefante de una manera ligeramente diferente, ya que
están influenciados por sus experiencias personales:
 El hombre que toca la trompa cree que es una serpiente.
 El hombre que toca un colmillo cree que es una lanza.
 El hombre que toca la oreja cree que el elefante es un abanico.
 El hombre que toca el dorso del elefante cree que es una pared.
 El hombre que toca la cola cree que es una cuerda.
 El hombre que toca las patas cree que son árboles.
Figura 1: Elefante de Saxe
Los ciegos entonces se enzarzan en una serie de debates acerca de lo que creen estar
enfrentando:
“…¡Y así estos hombres de Indostán
discutieron largo y tendido,
cada uno con su propia opinión
excediéndose en fuerza y tesón,
aunque cada uno estaba parcialmente en lo cierto,
y todos estaban equivocados!”
En muchos sentidos, el poema de Saxe se ha convertido en una profecía para SOA. Analistas

15. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 3
del sector, expertos, blogeros y reporteros se enfrentan unos con otros en un proceso
continuo e interminable acerca de lo que es o no es SOA. Como los ciegos de Saxe, la gente
ha identificado correctamente muchas de las capacidades de SOA, pero la mayoría no es
capaz de expresar el concepto como un todo. El reto de la definición de SOA se ha vuelto tan
importante que diversos fabricantes y organizaciones de normalización han lanzado
iniciativas para tratar de responder a la pregunta: ¿Qué es SOA?
Una simple definición para SOA
Para los propósitos de este libro definiremos SOA como:
Una arquitectura de acoplamiento flexible diseñada para satisfacer las necesidades de
negocio de la organización.
A primera vista, esta definición parece demasiado simplista – ¿dónde se metieron SOAP, los
servicios Web, WSDL, WS-* y otros estándares asociados? SOA no requiere necesariamente
del uso de servicios Web – los servicios Web son, para la mayoría de las organizaciones, el
enfoque más simple para implementar una arquitectura de acoplamiento flexible. En el
pasado, las arquitecturas de acoplamiento flexible se han basado en otras tecnologías como
CORBA y DCOM, o en enfoques basados en documentos como EDI, para la integración B2B.
Muchas de estas tecnologías tienen todavía un uso bastante generalizado y se han ampliado,
sustituido o extendido con los servicios Web.
Nuestra definición funciona, no porque el foco no está en la tecnología SOA, sino porque
tiene en cuenta las necesidades de la organización. En términos más simples, la SOA de una
organización puede parecerle a otra nada más que un montón de Servicios Web (u otras
tecnologías). Puede haber algunas capacidades de la infraestructura comunes, como el
registro y la autenticación, pero en la mayor parte de los casos la arquitectura SOA de una
organización, será muy diferente de la SOA utilizada por otra.
Muchos analistas y expertos de la industria han confundido el concepto de arquitectura
orientada a servicios con implementaciones orientadas a servicios. Esto sólo ha añadido más
confusión a la asociada con SOA y sus conceptos afines y puede llevar a resultados
desastrosos.
La misteriosa mansión Winchester, enclavada cerca de San José, California, es una
atracción turística muy interesante en los EE.UU. La mansión fue el hogar de la heredera de
la fortuna de Winchester (acumulada por la venta de los rifles Winchester). Según la
leyenda, la heredera fue a ver a un adivino y supo que estaba condenada a ser perseguida
por los espíritus de aquellas personas, de todo el mundo, asesinadas por un rifle Winchester.
La única manera de evitar la maldición era construir una mansión, y mientras se mantuviera
construyéndola los espíritus la dejarían en paz.
La mujer contrató rápidamente a 147 constructores (y ningún arquitecto), todos los cuales
comenzaron a trabajar en la mansión de forma simultánea. Los constructores trabajaron en
la mansión hasta que la heredera falleció, 38 años después.
El resultado de sus esfuerzos es un clásico ejemplo de una implementación sin arquitectura:
 La mansión tiene 160 habitaciones, 40 cuartos, 6 cocinas, 2 sótanos y 950 puertas.

16. 4 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
 De las 950 puertas, 65 abren hacia paredes, 13 escaleras fueron construidas y
abandonadas y 24 tragaluces fueron instalados en pisos que no daban al techo.
 Ningún plano arquitectónico de la mansión fue jamás elaborado.
Figura 2: La misteriosa mansión Winchester
La confusión de la arquitectura con la implementación genera resultados caóticos e
impredecibles, al igual que en la misteriosa mansión Winchester. Artículos que tratan de
explicar SOA e inmediatamente saltan a un tutorial para la creación de Servicios Web, están
brindando realmente orientación para la programación, no para la arquitectura. Esta es una
de las muchas razones por las que SOA es tan mal entendido hoy en día - la prisa por
promover arquitecturas de acoplamiento flexible se centra en los árboles y no en el bosque.
Los conceptos arquitectónicos asociados a SOA no son nuevos - muchos han evolucionado a
partir de ideas introducidas originalmente por CORBA, DCOM, DCE y otras. A diferencia de
estas iniciativas previas, la promesa esencial de SOA es permitir procesos de negocio ágiles
a través de una interoperabilidad abierta basada en estándares. Si bien estos estándares son
importantes, debemos recordar que las especificaciones no son la arquitectura, y la
arquitectura no es la implementación. Al final del día, es la implementación de una
arquitectura bien diseñada la que va a generar beneficios para el negocio, no la propia
arquitectura.
SOA es un enfoque arquitectónico para la creación de sistemas construidos a partir de
servicios autónomos. Con SOA, la integración es previsión en lugar de reflexión a posteriori -
es probable que la solución final se compondrá de los servicios desarrollados en diferentes
lenguajes de programación, alojados en distintas plataformas con una variedad de modelos
de seguridad y de procesos de negocio. Si bien este concepto suena increíblemente
complejo, no es nuevo – pudiera decirse que SOA ha evolucionado a partir de las
experiencias asociadas con el diseño y desarrollo de sistemas distribuidos basados en
tecnologías ya disponibles. Muchos de los conceptos asociados a SOA, como los servicios, el
descubrimiento y el enlace tardío estaban asociados a CORBA y DCOM. Del mismo modo, la
mayoría de los principios de diseño de los servicios, tienen mucho en común con técnicas
anteriores como OOA/OOD basadas en la encapsulación, la abstracción y las interfaces
claramente definidas.
¿Significa el bullicio en torno a SOA y los servicios que las TI no fueron orientadas a servicios

17. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 5
en el pasado? No – las TI (subcontratadas o no) sólo existen para potenciar los negocios. Sin
TI los negocios tendrían enormes dificultades tanto en la ejecución como en la competencia.
Sin embargo, si las TI no pueden responder a las necesidades y oportunidades de negocio lo
suficientemente rápido, entonces serán percibidas como un limitante de la empresa en lugar
de un facilitador.
SOA promete ayudar a las TI a responder a las condiciones del mercado de manera
oportuna. SOA, sin embargo, es una filosofía de arquitectura y no necesariamente un
concepto implementable. Muchos analistas y revistas especializadas han confundido a la
arquitectura con la implementación, lo que nos lleva a creer que una aplicación es, de hecho,
una arquitectura, y esto puede conducir a resultados desastrosos.
Las organizaciones tienen diferentes requerimientos y expectativas con respecto a SOA
dadas las enormes diferencias en cuanto a sus necesidades de negocio y metas. Este simple
hecho es una de las razones por las que describir a SOA es un gran desafío. SOA, como
cualquier iniciativa, debe proporcionar un cierto valor de uso a la organización - de lo contrario
no serviría de nada ni siquiera considerarla. La mejor manera de asegurar que las inversiones
en SOA proporcionarán un retorno a la organización es alinear SOA con los líderes del
negocio en la organización. A pesar de esta evidencia, todavía hay mucha confusión acerca
de SOA.
SOA, mitos y realidades
Hay varios mitos relacionados con SOA que es muy importante comprender antes de
continuar penetrando en ella. La siguiente tabla describe algunos de los mitos de SOA y los
hechos que permiten desenmascararlos.
Mito Hecho
SOA es una tecnología SOA es una filosofía de diseño independiente de
cualquier proveedor, producto, tecnología o tendencia
de la industria. Ningún proveedor podrá ofrecer una
SOA completa porque las necesidades SOA varían de
una organización a otra. La compra de la
infraestructura SOA a un solo proveedor va en contra
del propósito de invertir en SOA.
SOA requiere de servicios Web Las SOAs pueden ser implementadas a través de
servicios Web, pero los servicios Web no se requieren
necesariamente para implementar SOA.
SOA es nueva y revolucionaria EDI, CORBA y DCOM son ejemplos conceptuales de
SOA.
SOA asegura el alineamiento de SOA no es una metodología.
las TI con el negocio.
Una arquitectura de referencia Las SOAs son como los copos de nieve – no hay dos
SOA reduce los riesgos de iguales. Una arquitectura de referencia SOA no tiene
implementación por qué brindar la mejor solución para su organización.
SOA requiere una revisión SOA debe ser incremental y conformarse sobre la
completa de la tecnología y los base de sus inversiones en curso.
procesos de negocio.
Necesitamos construir una SOA. SOA es un medio, no una meta.
Enfóquese en ofrecer una solución, no una SOA. SOA es un medio de suministrar la solución
y no debe ser una meta.

18. 6 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
La evolución de SOA
La orientación a servicios (SO) es la evolución natural de los actuales modelos de desarrollo.
Los años 80, vieron modelos orientados a objetos, y luego vino el modelo de desarrollo
basado en componentes en los años 90, y ahora tenemos la orientación a servicios. La
orientación a servicios mantiene los beneficios del desarrollo basado en componentes (la
auto-descripción, la encapsulación, el descubrimiento y la carga dinámica), pero hay un
cambio en el paradigma desde métodos de objetos invocados remotamente, a uno de paso
de mensajes entre los servicios. Los esquemas describen no sólo la estructura de los
mensajes, sino también los contratos de comportamiento para definir patrones de
intercambio de mensajes y políticas para definir la semántica de servicios. Esto promueve la
interoperabilidad, y por lo tanto ofrece los beneficios de la adaptación, ya que los mensajes
pueden ser enviados desde un servicio a otro sin tener en cuenta cómo ha sido implementado
el servicio de manejo de los mensajes.
Figura 3: Comunicaciones simples entre servicios Web basadas en SOAP.
La orientación a servicios proporciona un enfoque evolutivo a la construcción de software
distribuido que facilita la integración del acoplamiento flexible con la resistencia al cambio.
Con la llegada de los servicios Web WS-*, la arquitectura ha hecho viable el desarrollo de
software orientado a servicios, en virtud de la avalancha de herramientas de desarrollo de
apoyo, y la interoperabilidad de todo el sector. Aunque implementadas más frecuentemente
utilizando los servicios Web estándares, la orientación a servicios es independiente de la
tecnología y los patrones arquitectónicos, y se puede utilizar para conectar con los sistemas
legados.
Desafortunadamente, los beneficios ofrecidos por la orientación a servicios y SOA han sido
oscurecidos por el bombo y la confusión que rodean cada vez más estos términos. Si bien el
conocimiento y el entusiasmo en torno a SOA han aumentado, las líneas claras que una vez
definieron la orientación a servicios, se han desdibujado. Sin embargo, SO ofrece algunas
ventajas específicas cuando se utiliza para el propósito correcto. Hay tres observaciones
importantes sobre SO:
1. Es evolutivo: Los principios del desarrollo orientado a servicios se basan en décadas de
experiencia en la construcción de aplicaciones distribuidas del mundo real. SO incorpora
conceptos como la auto-descripción de las aplicaciones, la encapsulación explícita, y la
carga dinámica de las funcionalidades en tiempo de ejecución – principios introducidos
por primera vez en las décadas de 1980 y 1990 a través del desarrollo orientado a objetos
y basado en componentes. Lo que cambia con SO es la metáfora con la que los
desarrolladores obtienen estos beneficios. En lugar de utilizar la invocación de métodos

19. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 7
en un objeto de referencia, la orientación a servicios cambia la conversación al paso de
mensajes - una metáfora probada para la integración escalable de software distribuido.
2. No es un producto o tecnología: Se trata de un conjunto de principios de arquitectura
expresados independientemente de cualquier producto. De la misma forma que
conceptos de desarrollo como el polimorfismo y la encapsulación son independientes de
la tecnología, también lo es la orientación a servicios. Si bien los servicios Web en los
últimos años han facilitado el desarrollo de aplicaciones orientadas a servicios, realmente
no son imprescindibles para hacerlo.
3. Es incremental: Por último, la orientación a servicios puede y debe ser un proceso gradual
- que a menudo se puede hacer en casa. Los clientes no deberían estar obligados a
rediseñar radicalmente sus negocios, para alcanzar los beneficios de la orientación a
servicios. Por el contrario, deberían ser capaces de aprovechar sus activos de TI al
hacerlo. El desarrollo orientado a servicios a menudo se puede lograr utilizando las
habilidades y tecnologías que ya tenemos hoy en día.
El bloque de construcción fundamental de la arquitectura orientada a servicios es el servicio.
Un servicio es un programa con el que se puede interactuar a través del intercambio de
mensajes bien definidos. Los servicios deben ser diseñados de modo que garanticen la
disponibilidad y la estabilidad. Los servicios están construidos para durar mientras las
configuraciones y las agregaciones de servicios no cambien.
La agilidad se promueve a menudo como uno de los mayores beneficios de SOA; en efecto,
una organización con procesos de negocio implementados sobre una infraestructura de
acoplamiento flexible, es mucho más abierta a los cambios que una organización limitada por
las aplicaciones monolíticas subyacentes, que requieren semanas para implementar el
cambio más pequeño. Los sistemas con acoplamiento flexible resultan en procesos de
negocio de acoplamiento flexible, ya que los procesos de negocio ya no están restringidos
por las limitaciones de la infraestructura subyacente.
Los servicios y sus interfaces asociadas deben permanecer estables, lo que les permite
volver a ser configurados o re-agregados para satisfacer las necesidades siempre
cambiantes de los negocios. Los servicios se mantienen estables apoyándose en interfaces
basadas en estándares y mensajes bien definidos -por ejemplo, usando SOAP y esquemas
XML para la definición de los mensajes. Los servicios diseñados para realizar funciones
granulares simples, con un conocimiento limitado de cómo los mensajes se transmiten hacia
o desde estos, son mucho más propensos a ser reutilizados en una infraestructura SOA.
La orientación a servicios no requiere necesariamente la reescritura de las funciones desde
cero. Siguiendo los cuatro principios (ver más abajo) se pueden reutilizar los activos de las TI
existentes, envolviéndolos en servicios modulares que pueden conectarse a cualquier
proceso de negocio que usted diseñe. Las metas para hacer esto deben ser:
 Conectarse a lo que ya existe - Gestión de la capa de procesos de negocio, flujos de
trabajo colaborativos, y reportes sobre los activos de TI existentes.
 Extraer más valor de lo que ya existe – Permitir que las aplicaciones existentes puedan
ser reutilizadas en nuevas formas.
 Extender y evolucionar lo que ya tenemos - Crear soporte de TI para los nuevos procesos

20. 8 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
de negocio inter-funcionales que se extienden más allá de las fronteras determinadas por
lo que las aplicaciones existentes se han diseñado para hacer.
Uno de los beneficios clave de la orientación a servicios es el acoplamiento flexible. No hay
discusión de los servicios Web que sea completa sin una referencia a las ventajas del
acoplamiento flexible de los extremos (aplicaciones) facilitado por el uso de protocolos para
los servicios Web. El principio radica en la utilización de un recurso sólo a través del servicio
publicado y no direccionando la implementación subyacente. De esta forma, los cambios
realizados por el proveedor del servicio en la implementación no deben afectar al consumidor
del servicio. Al mantener una interfaz consistente, el consumidor de un servicio podría elegir
una instancia alternativa del mismo tipo de servicio (por ejemplo, cambiar de proveedor del
servicio) sin modificar la aplicación consumidora excepto en la dirección de la nueva
instancia. El consumidor y el proveedor del servicio no tienen que tener las mismas
tecnologías para la implementación, la interfaz, o la integración, cuando se usan servicios
Web (aunque ambos están obligados a utilizar los mismos protocolos para el servicio Web).
¿Por qué debo estar informado acerca de SOA?
La Arquitectura Orientada a Servicios (SOA) es importante para diferentes roles:
 Para los desarrolladores y arquitectos de soluciones, la orientación a servicios es un
medio para la creación de aplicaciones dinámicas y colaborativas. Mediante el soporte en
tiempo de ejecución de la selección de los proveedores, la orientación a servicios permite
que las aplicaciones sean sensibles al contenido y al contexto de un proceso de negocio
específico, y a la incorporación de nuevos proveedores en el tiempo.
 Para el director de TI, la orientación a servicios es un medio para la integración efectiva
de los diversos sistemas típicos de los modernos centros de datos empresariales. Al
proporcionar un modelo para la agregación de la información y la lógica de negocio de
múltiples sistemas en una única interfaz, la orientación a servicios permite a sistemas
diversos y redundantes, integrarse a través de un conjunto común y coherente de
interfaces.
 Para el CIO (responsable de la información), la orientación a servicios es un medio para
proteger inversiones existentes en TI sin inhibir el despliegue de nuevas capacidades. Al
encapsular una aplicación de negocios detrás de interfaces basadas en capacidades, el
modelo de servicio permite el acceso controlado a aplicaciones

22. 10 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
adaptarse a nuevos servicios ofrecidos después del despliegue. La disponibilidad y
estabilidad de estos servicios resulta, por tanto, un factor crítico.
Entendiendo los servicios
El primer paso en cualquier proyecto SOA es identificar claramente los problemas críticos o
retos del negocio. Mientras más precisa sea la forma en que estos se definan, más fácil será
determinar el alcance y dirección de cada proyecto SOA. Estableciendo una visión clara
desde arriba, será más fácil contar con la aceptación de los proyectos que son inter
funcionales por naturaleza.
Una vez que los gestores de negocio de la organización se definen, el proceso de análisis de
los servicios puede comenzar. El análisis de los servicios es uno de los varios pasos que
componen el ciclo de vida de los servicios (el capítulo 2 ofrece más información acerca del
ciclo de vida de los servicios). El ciclo de vida de los servicios presenta los pasos que una
organización debe seguir para definir, desarrollar, desplegar y operar un servicio.
Los servicios son usados muchas veces para exponer inversiones en TI tales como sistemas
legados y aplicaciones de líneas de negocio. Los servicios pueden ser ensamblados (o
compuestos) dentro de los procesos de negocio, y quedar disponibles para el consumo por
los usuarios, sistemas u otros servicios. El proceso es un ciclo iterativo de creación
(“exposición”) de nuevos servicios, la agregación (“composición”) de estos servicios en
aplicaciones compuestas, y hacer que las salidas estén disponibles para su consumo por el
usuario.
Figura 5: Un enfoque incremental de SOA, orientado a los negocios.
Fundamental para el modelo de servicio es la separación entre la interfaz y la
implementación. El invocador de un servicio sólo necesita (y solo debe necesitar) conocer la
interfaz, la implementación puede evolucionar con el tiempo sin afectar a los clientes del
servicio. Varios beneficios claves de la orientación a servicios se derivan de esta abstracción
de la capacidad con respecto a la forma en que la capacidad se ofrece. Esto significa que, la
misma interfaz puede ser ofrecida por muchas implementaciones, o por el contrario, que las
implementaciones pueden cambiar sin afectar a la aplicación agregada. En su forma más
abstracta, la orientación a servicios lo ve todo – ya sea una aplicación de mainframe o una
impresora o un expedidor en un muelle o una compañía de entregas nocturnas - como
proveedores de servicios. El modelo de servicios es “fractal”: el proceso recién formado es
también un servicio, que expone una nueva capacidad agregada.

23. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 11
¿Qué es un servicio? En este libro vamos a evitar el uso del término “servicio Web”,
simplemente porque todos los servicios no son necesariamente servicios Web. Un servicio
también puede manifestarse como un proceso específico del sistema operativo, por ejemplo,
un demonio en Unix o un servicio de Windows. Un servicio también pudiera ser una
aplicación que utiliza un contrato bien definido basado o no en servicios Web.
Independientemente de cómo un servicio dado se desarrolle, debe ser capaz de participar en
una arquitectura de acoplamiento flexible. Hay cuatro principios que pueden ayudar a
conformar una arquitectura de acoplamiento flexible. Estos principios se definen a
continuación:
Los principios del diseño de servicios
El acrónimo SOA plantea una pregunta obvia - ¿qué es, exactamente, un servicio? En pocas
palabras, un servicio es un programa con el que se puede interactuar a través del intercambio
de mensajes bien definidos. Los servicios deben ser diseñados para asegurar disponibilidad
y estabilidad. La agilidad se promueve a menudo como uno de los mayores beneficios de
SOA - una organización que ha implementado los procesos de negocio sobre una
infraestructura de acoplamiento flexible es mucho más abierta a los cambios que una
organización limitada por aplicaciones monolíticas subyacentes, que requieren semanas
para implementar el cambio más insignificante. Los sistemas de acoplamiento flexible derivan
en procesos de negocio de acoplamiento flexible, ya que estos últimos no están limitados por
las restricciones de la infraestructura subyacente.
Los servicios y sus interfaces asociadas deben permanecer estables, posibilitando que sean
reconfigurados o agregados para satisfacer las necesidades siempre cambiantes de los
negocios. Los servicios se mantienen estables cuando responden a interfaces basadas en
estándares y mensajes bien definidos - en otras palabras, esquemas SOAP y XML para la
definición de los mensajes. Los servicios diseñados para realizar funciones granulares
simples, con un conocimiento limitado de cómo los mensajes se transmiten hacia o desde
estos, son mucho más propensos a ser reutilizados en una infraestructura SOA. Como se ha
dicho anteriormente, recordar los principios básicos del diseño orientado a objetos con
respecto a la encapsulación y el diseño de interfaces, nos será muy útil al diseñar y construir
servicios Web reutilizables. Podemos extender estos principios de la orientación a objetos al
mundo de los servicios Web con una comprensión profunda de los “cuatro principios” de la
orientación a servicios.
Principio 1: Las fronteras son explícitas.
Los servicios interactúan a través del paso de mensajes explícitos a través de fronteras bien
definidas. El cruce de las fronteras de los servicios puede ser costoso, en dependencia de
factores geográficos, de confianza o de ejecución. Una frontera representa el límite entre la
interfaz pública del servicio y su implementación interna privada. La frontera de un servicio se
publica a través de WSDL y puede incluir formulaciones que establezcan las expectativas del
servicio. Se supone que el cruce de las fronteras es una tarea costosa por varias razones,
algunas de las cuales se enumeran a continuación:
 La ubicación física del servicio puede ser un aspecto desconocido.
 Es probable que los modelos de seguridad y confianza cambien con cada cruce de
frontera.

24. 12 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
 La determinación de las referencias y el casteado de los datos entre las representaciones
públicas y privadas de un servicio pueden requerir apoyarse en recursos adicionales -
algunos de los cuales pueden ser externos al propio servicio.
 Mientras que los servicios se construyen para durar, las configuraciones de los servicios
se preparan para el cambio. Este hecho implica que un servicio confiable de repente
puede experimentar degradaciones de rendimiento debido a la reconfiguración de la red o
la migración a otra ubicación física.
 Los consumidores de los servicios generalmente no están conscientes de cómo han sido
implementados los procesos internos privados. El consumidor de un determinado servicio
tiene un control limitado sobre el rendimiento de los servicios que consume.
El patrón de integración orientado a servicios nos dice que “las invocaciones de servicio están
sujetas a la latencia de la red, a fallos en la red, y a los fallos del sistema distribuido, pero una
implementación a nivel local no lo está. Debe escribirse una cantidad importante de lógica de
detección y corrección de errores para prever las consecuencias del uso de interfaces con
objetos remotos”. Aunque debemos asumir que el cruce de fronteras es un proceso costoso,
también hay que tener cuidado en el despliegue de métodos locales diseñados para reducir al
mínimo los cruces de frontera. Un sistema que implementa métodos y objetos locales
monolíticos puede ganar en el rendimiento pero duplicar la funcionalidad de un servicio
previamente definido (esta técnica se conoce como “cortar y pegar” en la programación
orientada a objetos y comparte los mismos riesgos que el versionado del servicio).
Hay varias cuestiones a tener en cuenta con respecto al primer principio de SO:
 Conozca sus límites. Los servicios proporcionan un contrato para definir las interfaces
públicas que ofrecen. Toda la interacción con el servicio se produce a través de la interfaz
pública. La interfaz se compone de los procesos públicos y representaciones públicas de
los datos. El proceso público es el punto de entrada en el servicio, mientras que la
representación pública de los datos está conformada por los mensajes usados por el
proceso. Si se utiliza WSDL para representar a un contrato simple, <message>
representa los datos públicos, mientras que <portType> representa el (los) proceso (s)
público (s).
 Los servicios deben ser fáciles de consumir. Al diseñar un servicio, los desarrolladores
deben hacer que sea fácil consumirlo por otros desarrolladores. La interfaz del servicio
(contrato) también debe diseñarse para permitir la evolución del servicio, sin romper los
contratos con los consumidores actuales.
 Evite las interfaces de tipo RPC. El paso de mensajes explícitos debe tener prioridad
sobre un modelo RPC. Este enfoque aísla al consumidor de las interioridades de la
implementación del servicio, liberando a los desarrolladores de evolucionar sus servicios
al mismo tiempo que reducen al mínimo el impacto en los consumidores de los servicios
(encapsulado a través de mensajes públicos en lugar de los métodos a disposición del
público).
 Mantenga pequeña la superficie del servicio. Mientras más interfaces públicas un servicio
expone más difícil será su consumo y mantenimiento. Proporcione pocas y bien definidas
interfaces públicas a su servicio. Estas interfaces deben ser relativamente simples,
diseñadas para aceptar un mensaje de entrada bien definido y responder con un mensaje

25. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 13
de salida igualmente bien definido. Una vez que estas interfaces se han diseñado deben
permanecer estáticas. Estas interfaces proporcionan el requerimiento de diseño
“constante” que los servicios deben soportar, sirviendo como la cara pública a la
implementación interna privada del servicio.
 Los detalles de la implementación interna (privada) no deben filtrarse fuera de la frontera
del servicio. Las fugas de detalles de la implementación a través de la frontera del servicio
traen como resultado vínculos más estrechos entre el servicio y los consumidores del
servicio. Los consumidores de servicios no debe estar enterados de las interioridades de
la implementación de un servicio, ya que esto limita las opciones para el control de
versiones o la mejora del servicio.
Principio 2: Los servicios son autónomos
Los servicios son entidades que están desplegados, versionados, y administrados de manera
independiente. Los desarrolladores deben evitar hacer suposiciones sobre el espacio entre
los límites del servicio ya que este espacio es mucho más probable que cambie que las
propias fronteras. Por ejemplo, los límites del servicio deben ser estáticos para minimizar el
impacto del control de versiones para el consumidor. Mientras que los límites de un servicio
son bastante estables, las opciones de implementación del servicio en relación con la política,
la ubicación física o la topología de la red es probable que cambien.
Los servicios se direccionan de forma dinámica a través de URLs, lo que permite que la
localización subyacente y las topologías de implementación puedan cambiar o evolucionar en
el tiempo con muy poco impacto en el servicio (esto también se aplica a los canales de
comunicación de un servicio). Si bien estos cambios pueden tener poco impacto sobre el
servicio, pueden tener un impacto devastador sobre las aplicaciones que consumen el
servicio. ¿Qué sucede si un servicio que se utiliza hoy en día en EEUU se traslada a una red
en Nueva Zelanda mañana? El cambio en el tiempo de respuesta puede tener efectos no
planeados o inesperados en los consumidores del servicio. Los diseñadores de servicios
deben adoptar una visión pesimista de la forma en que sus servicios serán consumidos - los
servicios fallarán y su comportamiento (los niveles de servicio) está sujeto a cambios.
Cualquier invocación de servicio debe tener asociados niveles adecuados de manejo de
excepciones y lógicas de compensación. Además, los consumidores de servicios pueden
tener que modificar sus políticas para declarar los tiempos mínimos de respuesta de los
servicios que consumen. Por ejemplo, los consumidores de un servicio pueden requerir
diferentes niveles de servicio en materia de seguridad, rendimiento, transacciones, y muchos
otros factores. Una política configurable permite que un servicio en particular soporte
múltiples Acuerdos sobre el Nivel de Servicio (SLA) con respecto a la invocación del servicio
(y otras políticas pueden centrarse en las versiones, la localización y otras cuestiones). El
intercambio acerca de las expectativas de desempeño a nivel de servicio preserva la
autonomía, ya que los servicios no tienen que estar familiarizados con las implementaciones
internas de los otros servicios.
Los consumidores de servicios no son los únicos que deben adoptar visiones pesimistas
acerca del rendimiento - los proveedores de los servicios deben ser igualmente pesimistas al
estimar cómo sus servicios van a ser consumidos. Debe esperarse que los consumidores de
los servicios fallen, a veces sin avisar al servicio. Los proveedores de servicios no pueden

26. 14 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
confiar en que los consumidores “hacen las cosas correctamente”. Por ejemplo, los
consumidores pueden tratar de comunicarse mediante mensajes mal conformados o
maliciosos, o intentar violar las políticas de otra índole necesarias para la interacción exitosa
con el servicio. La implementación interna del servicio debe tratar de compensar el uso
inadecuado, sea cual fuere la intención del usuario.
Si bien los servicios están diseñados para ser autónomos, no hay servicio que sea una isla.
Una solución basada en SOA es fractal, y consiste en una serie de servicios configurados
para garantizar una solución específica. Pensando de forma autónoma, nos damos cuenta
rápidamente que no hay autoridad que presida en un entorno orientado a servicios - el
concepto de un conductor de la orquesta es fallido (implicando que el concepto de rollback a
través de los servicios sea también deficiente, pero este es un tema que se sale del alcance
de este material). Las claves para la implementación de servicios autónomos son el
aislamiento y la desconexión. Los servicios se diseñan y despliegan independientemente
unos de los otros y sólo pueden comunicarse mediante mensajes y políticas establecidas
contractualmente.
Al igual que con otros principios de diseño de los servicios, podemos aprender de nuestras
experiencias pasadas con el diseño orientado a objetos. El trabajo de Peter Herzum y Oliver
Sims sobre las fábricas de componentes de negocio, ofrece algunas ideas interesantes sobre
la naturaleza de los componentes autónomos. Si bien la mayor parte del trabajo es más
apropiado para soluciones basadas en componentes de grano grueso, los principios básicos
de diseño siguen siendo aplicables para el diseño de servicios.
Teniendo en cuenta estas consideraciones, he aquí algunos principios de diseño simples que
ayudan a asegurar el cumplimiento del segundo principio de la orientación a servicios:
 Los servicios deben ser desplegados y versionados independientemente del sistema en
el que se implementan y consumen.
 Los contratos deben ser diseñados con la premisa de que una vez publicados, no se
pueden modificar. Este enfoque obliga a los desarrolladores a introducir flexibilidad en el
diseño de sus esquemas.
 Los servicios deben ser aislados de los fallos mediante la adopción de una perspectiva
pesimista. Desde la perspectiva del consumidor, planee teniendo en cuenta niveles no
confiables de disponibilidad del servicio y rendimiento. Desde la perspectiva del
proveedor, espere el mal uso de su servicio (deliberadamente o no), espere que los
consumidores de sus servicios fallen - tal vez sin notificar a su servicio.
Principio 3: Los servicios comparten el esquema y el contrato, no las clases
Como se dijo anteriormente, la interacción de los servicios debe estar basada únicamente en
las políticas, el esquema y el comportamiento basado en contratos. El contrato de un servicio
se define generalmente a través de WSDL, mientras que los contratos para la agregación de
servicios se pueden definir utilizando BPEL (que a su vez utiliza WSDL para cada servicio
agregado).
La mayoría de los desarrolladores define clases para representar las distintas entidades
dentro de un espacio de problemas determinado (por ejemplo, cliente, pedido y producto).

27. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 15
Las clases combinan el comportamiento y los datos (mensajes) en un único ensamblado con
un lenguaje de programación o plataforma específica. Los servicios rompen este modelo para
maximizar la flexibilidad y la interoperabilidad. Los servicios comunicándose a través de
mensajes basados en esquemas XML, son agnósticos con respecto al lenguaje de
programación y la plataforma, lo que garantiza mayor nivel de interoperabilidad. El esquema
define la estructura y el contenido de los mensajes, mientras que el contrato del servicio
define su comportamiento.
En resumen, el contrato de un servicio se compone de los siguientes elementos:
 Formatos de intercambio de mensajes definidos usando esquemas XML.
 Patrones de intercambio de mensajes (MEP) definidos a través de WSDL.
 Capacidades y requisitos definidos con políticas de WS.
 BPEL puede ser utilizado como un contrato a nivel de procesos de negocio para la
agregación de múltiples servicios.
Los consumidores de servicios se basan en un contrato de servicios para invocar e
interactuar con un servicio. Teniendo en cuenta esta dependencia, el contrato de un servicio
debe permanecer estable en el tiempo. Los contratos deben ser diseñados lo más
explícitamente posible, aprovechando la naturaleza extensible del esquema XML (xsd: any) y
del modelo de procesamiento SOAP (encabezados opcionales).
El mayor reto del tercer principio es su permanencia. Una vez que un contrato de servicio se
ha publicado, se convierte en extremadamente difícil de modificar reduciendo al mínimo el
impacto sobre los consumidores de servicios existentes. La línea entre las representaciones
de datos internos y externos es fundamental para el éxito del despliegue y la reutilización de
un servicio determinado. Los datos públicos (los transmitidos entre los servicios) deben
basarse en estándares organizacionales o verticales, lo que garantiza una amplia aceptación
entre los diferentes servicios. La información privada (los datos dentro de un servicio) se
encapsula dentro de un servicio.
En cierto modo, los servicios son como pequeñas representaciones de una organización que
realiza transacciones de comercio electrónico. Al igual que una organización debe mapear
una orden de compra externa a su formato interno, un servicio también debe mapear una
representación de los datos basada en un contrato acordado a su formato interno. Una vez
más, nuestras experiencias con la encapsulación de datos orientada a objetos pueden ser
reutilizadas para ilustrar un concepto similar - la representación de los datos internos de un
servicio sólo pueden manipularse a través del contrato del servicio.
Teniendo en cuenta estas consideraciones, he aquí algunas recomendaciones simples de
diseño para ayudar a garantizar el cumplimiento del tercer principio de orientación a servicios:
 Asegúrese que el contrato de un servicio se mantiene estable para minimizar el impacto
sobre los consumidores del servicio. El contrato se refiere, en este sentido, a la
representación pública de los datos, el patrón de intercambio de mensajes (WSDL) y las
capacidades y niveles de servicio configurables (la política).
 Los contratos deben ser diseñados para ser lo más explícitos que sea posible, y así
minimizar las malas interpretaciones. Además, los contratos deben ser diseñados para
dar cabida a versiones futuras del servicio a través de la capacidad de ampliación, tanto

28. 16 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
de la sintaxis XML como del modelo de procesamiento de SOAP.
 Evite diluir la línea entre las representaciones de los datos públicos y privados. El formato
de los datos internos de un servicio debe ser ocultado de los consumidores, mientras que
su esquema de datos público debe ser inmutable (de preferencia basado en un estándar,
ya sea organizacional, de facto, o de la industria).
 Versione los servicios cuando los cambios en el contrato sean inevitables. Este enfoque
minimiza el impacto sobre las implementaciones existentes de los consumidores.
Principio 4: La compatibilidad de los servicios se basa en políticas
Si bien este se considera a menudo el menos entendido de los principios de diseño, es quizás
uno de los más potentes en cuanto a la implementación de servicios Web flexibles. No es
posible comunicar algunos requisitos para la interacción de los servicios usando solamente
WSDL. Expresiones políticas se pueden utilizar para separar la compatibilidad estructural (lo
que se comunica) de la compatibilidad semántica (¿cómo o con quien se comunica un
mensaje?).
Los requisitos operacionales para los proveedores de servicios pueden manifestarse en
forma de expresiones que pueden ser evaluadas por la computadora. Las expresiones de
política proporcionan un conjunto configurable de semánticas interoperables que rigen el
comportamiento y las expectativas de un servicio determinado. La especificación de políticas
de WS define una infraestructura de políticas de lectura mecánica capaz de expresar políticas
a nivel de servicio, lo que les permite ser descubiertos o mejorados en tiempo de ejecución.
Por ejemplo, un servicio de seguridad del gobierno puede requerir la aplicación de una
política reforzando un nivel de servicio específico (por ejemplo, las fotos de pasaporte que
cumplen con ciertos criterios establecidos deben ser cotejadas con un sistema de
identificación de terroristas). La información de política relacionada con este servicio podría
ser utilizada en una serie de otros escenarios o servicios relacionados con la realización de
una verificación de antecedentes. Las políticas de WS se pueden utilizar para hacer cumplir
estos requisitos sin necesidad de una sola línea de código adicional. Este escenario muestra
cómo una infraestructura de políticas proporciona información adicional acerca de los
requerimientos de un servicio, al mismo tiempo que también proporciona un modelo de
programación declarativa para la definición y ejecución del servicio.
Un planteamiento de la política identifica un comportamiento que es un requerimiento (o
capacidad) de un tema de política. (En el escenario anterior el planteamiento es la
verificación de antecedentes contra el sistema de identificación de terroristas.) Los
planteamientos proporcionan semánticas de dominio específico y eventualmente se definirán
dentro de especificaciones de dominio específico independientes, para una variedad de
industrias verticales (estableciendo el concepto de infraestructura de políticas de WS).
Si bien los servicios gestionados por políticas están todavía en evolución, los desarrolladores
deben asegurarse de que sus planteamientos de política sean tan explícitos como sea
posible con respecto a las expectativas y compatibilidades semánticas de los servicios.
Los cuatro principios han sido concebidos principalmente para ayudarle en el diseño y
desarrollo de sus servicios.

29. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 17
Un modelo abstracto de referencia para SOA
Si bien un proyecto SOA bien planificado y ejecutado puede ayudar a las organizaciones a
obtener mayor capacidad de respuesta en un mercado cambiante, no todos los esfuerzos
orientados a los servicios han tenido éxito. Los proyectos SOA pueden experimentar un éxito
limitado cuando son gestionados desde abajo hacia arriba por desarrolladores que no están
familiarizados con las necesidades estratégicas de la organización. La construcción de SOA
por SOA, sin hacer referencia al contexto de los negocios es un proyecto sin principios y
directrices de organización. El resultado es una implementación caótica que no tiene ninguna
relevancia empresarial. Por otro lado, tomando un enfoque de SOA de arriba hacia abajo
requiere inversiones tan grandes de tiempo que para el momento en que el proyecto está
completo, la solución ya no se ajusta a las necesidades del negocio. (¡Este es, por supuesto,
uno de los problemas que se supone SOA debe resolver!)
Por el contrario, Microsoft aboga por un enfoque intermedio, que combina metodologías de
arriba abajo y de abajo arriba. En este enfoque, los esfuerzos de SOA son conducidos por la
visión estratégica y las necesidades de la empresa, y se alcanzan a través de proyectos SOA
incrementales e iterativos que se han diseñado para alcanzar los objetivos de negocio uno
por uno. Microsoft ha estado utilizando esta técnica para ayudar a los clientes con sus
iniciativas SOA, desde que la infraestructura .NET fue lanzada por primera vez en 1999.
El concepto de SOA puede ser visto desde varias perspectivas. Si bien ninguna perspectiva
individual o conjunto de perspectivas representa un punto de vista definitivo de una SOA,
desde una visión holística estas perspectivas ayudan a comprender los requisitos
arquitectónicos subyacentes. Microsoft cree que hay tres capas de capacidades abstractas
expuestas dentro de una SOA. Un ejemplo de estas categorías y las relaciones entre estas
aparece a continuación:
Figura 6: Un modelo abstracto de referencia para SOA

30. 18 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
Exposición
La exposición se centra en cómo las inversiones en TI existentes se exponen como un
conjunto de servicios abiertos y basados en estándares, permitiendo que estas inversiones
estén al alcance de un conjunto más amplio de consumidores. Es probable que las
inversiones existentes estén basadas en un conjunto heterogéneo de plataformas y
proveedores. Si estas aplicaciones son incapaces de soportar de forma nativa los servicios
Web, se requerirá de un conjunto de aplicaciones o adaptadores de protocolos específicos.
La creación de servicios puede ser de grano fino (un servicio se mapea a un único proceso de
negocio), o de grano grueso (múltiples servicios se agrupan para llevar a cabo un conjunto de
funciones de negocio afines). La exposición también se ocupa de cómo se implementan los
servicios. La funcionalidad de los recursos de TI subyacentes puede estar disponible de
forma nativa si ya habla el lenguaje de los servicios Web, o pueden estar disponibles como
servicios Web a través del uso de un adaptador. Una arquitectura de implementación de
servicios describe cómo los servicios se desarrollan, implementan y gestionan.
Composición
Una vez que los servicios se crean, estos se pueden combinar en servicios más complejos,
aplicaciones o procesos de negocio de funciones cruzadas. Como los servicios existen
independientemente unos de otros, se pueden combinar (o “componer”) y volver a utilizar con
la máxima flexibilidad. A medida que los procesos de negocio evolucionan, las reglas y las
prácticas de negocio se pueden ajustar sin las restricciones que imponen las limitaciones de
las aplicaciones subyacentes. Las composiciones de servicios permiten que se creen nuevos
procesos de funciones cruzadas, lo que permite a la empresa adoptar nuevos procesos de
negocio, ajustar los procesos para lograr una mayor eficacia, o mejorar los niveles de servicio
a clientes y socios.
Una arquitectura de integración de servicios describe un conjunto de capacidades para la
composición de servicios, y otros componentes en ensamblados mayores como pueden ser
los procesos de negocio. La composición de servicios requiere de algún tipo de flujo de
trabajo o mecanismo de orquestación. Microsoft ofrece estas capacidades a través de
BizTalk Server 2006 (BTS) o Windows Workflow Foundation (WF). Si bien puede parecer que
BTS y WF satisfacen las mismas necesidades, en realidad son muy diferentes. WF y BTS son
tecnologías complementarias diseñadas para satisfacer dos necesidades muy diferentes:
 BTS es un producto con licencia diseñado para implementar flujos de trabajo
(“orquestaciones”) a través de diferentes aplicaciones y plataformas.
 WF es una infraestructura de desarrollo diseñada para exponer capacidades de flujo de
trabajo desde una aplicación. No hay cuotas o restricciones de licencia asociadas con el
uso o el despliegue de WF.
Examinaremos el flujo de trabajo, la orquestación y la utilización de BizTalk/WF en el Capítulo
3 (flujos de trabajo y procesos de negocio).
Consumo
Cuando se crea una nueva aplicación o proceso de negocio, esa funcionalidad debe ponerse
disponible para el acceso (consumo) por los sistemas de TI, por otros servicios y por los

31. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 19
usuarios finales. El consumo se centra en el suministro de nuevas aplicaciones que permitan
una mayor productividad y una mayor penetración en el rendimiento del negocio. Los
usuarios pueden consumir servicios “compuestos” a través de un amplio número de puntos
de salida incluyendo portales web, aplicaciones cliente de interfaz enriquecida, aplicaciones
ofimáticas (OBA), y dispositivos móviles. Los servicios “compuestos” pueden ser utilizados
para desplegar con rapidez aplicaciones que se traducen en nuevas capacidades de negocio
o una mejora en la productividad. Estas nuevas aplicaciones se pueden utilizar para medir el
retorno de la inversión (ROI) en una SOA.
Una arquitectura de aplicaciones orientadas a servicios describe cómo poner disponibles
para el consumo los “servicios compuestos”, a través de procesos de negocio, nuevos
servicios o nuevas aplicaciones finales. Este concepto se denomina a veces aplicaciones
compuestas, ya que implica el consumo de servicios por aplicaciones finales. Las
aplicaciones ofimáticas de Microsoft (OBA) soportan la noción de aplicación compuesta en
los sistemas transaccionales al mismo tiempo que amplían el alcance de la interacción del
usuario a través del familiar entorno del Office.
Si bien las arquitecturas descritas en los epígrafes exposición/composición/consumo pueden
ser interdependientes, están diseñadas para su acoplamiento flexible. Esto permite que los
servicios sean gestionados, versionados y configurados independientemente de la forma en
que han sido expuestos.

32. 20 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
Capacidades arquitectónicas recurrentes
Como vimos anteriormente, el modelo de arquitectura SOA es fractal. Esto significa que un
servicio puede ser utilizado para exponer activos TI (por ejemplo, un sistema de una línea de
negocios), componerse en flujos de trabajo o procesos de negocio (cada uno de los cuales
también puede ser expuesto como un servicio) y consumirse por usuarios finales, sistemas
u otros servicios. SOA es un modelo fractal y no un modelo en capas. Si bien el modelo
abstracto de referencia SOA proporciona una visión integral de varios importantes conceptos
de SOA, las secciones exponer/componer/consumir del modelo no deben ser interpretadas
como capas (a pesar de su aspecto en el modelo).
El diseño de una arquitectura SOA como un conjunto bien definido de niveles (o capas)
limitará el valor y la flexibilidad de sus servicios, lo que resultará en dependencias entre
componentes no relacionados. Esta es la razón por la que las secciones
exponer/componer/consumir del modelo pueden ser consideradas como iniciativas
arquitectónicas independientes, denominadas respectivamente como arquitectura de
implementación de servicios (exposición), arquitectura de integración de servicios
(composición) y arquitectura de aplicaciones (consumo). Aunque estas arquitecturas han
sido diseñadas para ser independientes entre sí, comparten un conjunto de cinco funciones
comunes.
Figura 7: Capacidades arquitectónicas recurrentes
Mensajes y servicios
Mensajes y servicios se centra en cómo se lleva a cabo el intercambio de mensajes entre
emisores y receptores. Hay una amplia gama de opciones y modelos disponibles - desde
publicación/subscripción y asincrónica, hasta los patrones de interacción de mensajes y
servicios. Los servicios proporcionan un enfoque evolutivo a la construcción de software
distribuido que facilita la integración del acoplamiento flexible y la resistencia al cambio.
El advenimiento de la arquitectura de servicios Web WS-* ha hecho factible el desarrollo de
software orientado a servicios, en virtud del soporte de las herramientas de desarrollo y la
amplia interoperabilidad en el sector. Si bien se implementa frecuentemente utilizando
servicios Web estándares, la orientación a servicios es independiente de la tecnología y los
patrones arquitectónicos, y se puede utilizar también para conectarse con los sistemas
legados. Los mensajes y servicios no son un nuevo enfoque en el diseño de software -
muchas de las ideas detrás de estos conceptos han existido por años.
Un servicio se implementa generalmente como entidad de software de grano grueso que
puede ser descubierta y que existe como una instancia única e interactúa con las

33. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 21
aplicaciones

34. 22 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
 Diferencias en la interfaz (por ejemplo, la interfaz ampliada, pero el mismo objeto de
negocio).
 Diferencias semánticas con la misma interfaz (objetos de negocio modificados).
 Diferencias en la calidad de servicio (por ejemplo, más lento pero más barato o muy
disponible, pero más caro).
La gestión de servicios incluye muchas capacidades, algunas de las cuales se enumeran a
continuación:
 Una solución completa para la gestión de los cambios y la configuración, permitiendo a
las organizaciones ofrecer a los usuarios software y el servicio de actualizaciones
correspondiente de forma rápida y rentable.
 Reducción de la complejidad asociada con la gestión de la infraestructura de TI,
enfocándose en la disminución del costo de las operaciones.
 Servicios centralizados de salva de los archivos modificados en disco. Las copias
centralizadas de seguridad deben permitir la recuperación rápida y fiable desde disco,
proporcionando al usuario final la recuperación sin intervención del personal de TI.
 Planificación de las capacidades previo al despliegue, conjuntamente con una guía de
buenas prácticas y conocimientos específicos de hardware, para ayudar a los
profesionales de TI en la toma de las mejores decisiones arquitectónicas.
 Almacenamiento de datos y reportes para ayudar en la toma de decisiones corporativas,
mejorar la calidad del servicio prestado, y lograr una mejor administración de los recursos
a través de capacidades mejoradas de reportes y la integración de datos provenientes de
una amplia variedad de recursos.
Soporte para las capacidades arquitectónicas comunes
La plataforma SOA de Microsoft soporta las cinco capacidades arquitectónicas discutidas
más arriba. El resto del libro discute estas capacidades en mayor detalle, comenzando con
los mensajes y servicios en el Capítulo 2.
Figura 8: Capacidades SOA en la plataforma Microsoft

35. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 23
Las capacidades arquitectónicas comunes y el modelo abstracto de
referencia para SOA
También podemos pensar en estas cinco capacidades arquitectónicas comunes como un
conjunto de perspectivas para entender el modelo abstracto de SOA. Las cinco capacidades
arquitectónicas nos ayudan a comprender mejor los desafíos asociados con la exposición
como servicios de las inversiones existentes en TI, la composición de los servicios en los
procesos empresariales y el consumo de estos procesos en toda la organización.
Exposición
Habilitación de los servicios
La exposición se centra en cómo diseñar y exponer nuestros servicios. Lo más probable es
que se comience por exponer las inversiones en TI como servicios Web.
A medida que nuestra organización madure va a añadir nuevos servicios, lo más probable
que como representantes (proxies) de otros recursos dentro de la organización.
Una de las partes más difíciles de la implementación de los servicios es decidir por dónde
empezar. Hay una variedad de opciones, y no hay una recomendación única que funcione
para todos. La metodología Motion de Microsoft proporciona una guía para la identificación
de las capacidades empresariales que podrían exponerse como servicios.
¿Cuáles son algunas de los criterios que se deben seguir cuando se exponen inversiones en
TI como servicios?
 Pensar en grande, pero empezar con poco.
 Mostrar resultados en cada paso del camino.
 Adoptar un enfoque intermedio, ni de arriba hacia abajo ni de abajo hacia arriba.
 Ser pragmáticos.
 Cortes verticales.
 Mitigación de los riesgos.
 Demostrar los beneficios en iteraciones rápidas.
 Nuevos enfoques de desarrollo.
 El éxito de los clientes produce el efecto de “bola de nieve”.
Las capacidades arquitectónicas recurrentes nos proporcionan una serie de consideraciones
al exponer las inversiones en TI como servicios. Echemos un rápido vistazo a algunas de las
consideraciones asociadas con cada capacidad para la exposición de servicios (no es una
lista completa):
Mensajería y servicios
Determinar qué exponer y cómo - evite caer en la trampa de la granularidad. Centrarse en
la satisfacción de los requerimientos del negocio.
Contrato para la operación del servicio.
Contratos para los mensajes y datos.
Configuración, comportamiento y control.

36. 24 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
SLAs.
Gobernabilidad.
Control de versiones.
Flujos y procesos
Servicios de coordinación para procesos distribuidos de larga duración.
Servicios de seguimiento capaces de registrar eventos específicos dentro de un flujo.
Servicios de compensación.
Datos
Servicios de entidades.
Servicios de agregación de entidades: actúan como un punto de acceso único a la
información que pueda existir en múltiples sistemas. Un servicio de agregación de
entidades tiene las siguientes responsabilidades:
 Actúa como una fuente unificada de entidades.
 Proporciona una visión integral de la entidad.
 Proporciona una visión integral del modelo de las entidades – las entidades y sus
relaciones con otras entidades.
 Proporciona transparencia con respecto a la ubicación - los consumidores de la capa
de agregación de entidades no tienen que saber a quién pertenece la información.
 Hace cumplir las reglas de negocio que determinan los segmentos de las entidades
recuperadas en un contexto dado.
 Determina el sistema de registro para cada elemento de datos que constituye una
entidad.
 Enriquece el modelo de datos combinado a través de los sistemas - el todo es mejor
que la suma de sus partes.
 Factorización de entidades.
La MDM (gestión de datos maestros) se centra en la exposición de los datos a través de
las fronteras corporativas o departamentales. Hablaremos de MDM con mayor detalle en
el Capítulo 4.
Interacción con el usuario
Servicios especializados de soporte a las interfaces de usuario (recursos de
almacenamiento en caché, comunicaciones entre la interfaz de usuario y los servicios,
etc.). Los envoltorios (wrappers) de servicios proporcionan interfaces de grano grueso
para el consumo por los usuarios de las aplicaciones, mashups2 ligeros, etc.
2
En desarrollo web, un mashup es una página web o aplicación que usa y combina datos, presentaciones y
funcionalidad procedentes de una o más fuentes para crear nuevos servicios. Es tratado más adelante en el
texto. (Nota del traductor)

37. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 25
Identidad y acceso
Gestión de Identidad.
Servicios de suplantación y delegación de identidad.
Subsistema de confianza - Un modelo de subsistema de confianza implica que los
servicios son de confianza para realizar tareas específicas, tales como el procesamiento
de los pedidos de los clientes.
Autenticación (Kerberos, SSL).
Control de acceso basado en roles (RBAC).
Creación/revocación de las relaciones de confianza.
Los servicios deben tomar decisiones de autorización, como la aprobación del envío de
una solicitud antes de realizar la transacción comercial.
El servicio debe conocer la identidad del usuario final que envía la solicitud.
La necesidad de enrutar la identidad del usuario final es una propiedad inherente del
modelo de delegación, que no es así para el modelo de subsistema de confianza, y debe
hacerse un esfuerzo especial para incluir esta característica.
Para apoyar la noción de confianza, como se define en el modelo, los servicios deben ser
capaces, al menos, de:
 Autentificar/verificar la identidad de los servicios.
 Decidir si el servicio es un subsistema de confianza para funciones específicas
(incluida la propagación de reclamos de identidad).
 Proteger la integridad de los datos que se trasmiten entre los subsistemas de
confianza y los servicios.
Además de los datos de aplicación, los datos de las aplicaciones de infraestructura, tales
como los reclamos de identidad del usuario original, también deben ser protegidos para
que ningún operador humano en el camino pueda modificar la información de identidad
que está en tránsito.
Composición
Composición de servicios
La composición se centra en cómo podemos combinar o agregar servicios granulares en
procesos más complejos. Seguramente vamos a empezar por usar los servicios que exponen
nuestras actuales inversiones en TI. La composición de servicios resulta en una nueva
instancia de servicio que el resto de la organización puede usar. La composición ofrece
capacidades tales como la invocación asincrónica correlacionada de servicios, procesos de
larga duración y otras capacidades para la orquestación de servicios autónomos.
Las capacidades arquitectónicas recurrentes nos proporcionan un conjunto de
consideraciones a la hora de componer los servicios granulares en procesos más complejos.
Echemos un rápido vistazo a algunas de las consideraciones asociadas con cada capacidad
para la composición de los servicios (que no es de ningún modo una lista completa):

38. 26 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
Mensajería y servicios
Patrones de interacción de servicios.
Exposición de las orquestaciones como servicios.
Patrones de invocación asincrónica de servicios.
Flujos y procesos
Transacciones.
Alta frecuencia de cambio.
Reglas de negocio.
Orquestación de servicios.
Patrones de interacción de servicios.
Externalización de procesos.
Procesos de larga duración.
Auditoría y análisis.
Datos
Seguimiento del estado de una instancia de flujo de trabajo determinada.
Transformación de los datos (ETL).
Procesamiento y almacenamiento confiable de los datos.
Replicación.
Sincronización.
Repositorio de metadatos y su gestión.
Reconciliación de instancias.
Reconciliación de esquemas.
Replicación de documentos.
Sindicación/Agregación.
Interacción con el usuario
Aplicaciones compuestas (aplicaciones ofimáticas).
Flujos de trabajo humanos (MOSS).
Las orquestaciones invocan flujos de trabajo humanos a través de un adaptador
SharePoint.
Definición de los flujos de trabajo (pageflows).
Identidad y acceso
Suplantación y delegación de identidad.
Aprovisionamiento.
Sincronización del repositorio de identidades.
Flujos de aprobación.

39. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 27
Consumo
Interacción con el usuario
El consumo se centra en cómo los servicios y procesos orquestados (que pueden ser
expuestos a su vez como servicios) son consumidos por otros servicios, aplicaciones y
usuarios finales. Cualquier recurso capaz de interactuar con los servicios puede ser
considerado como un “consumidor”. Los consumidores pueden aparecer en la organización
en varias formas:
 Aplicaciones ligeras basadas en navegadores.
 Las aplicaciones Web de interfaz enriquecida (RIA) son aplicaciones basadas en un
navegador que pueden direccionar y hacer cache de recursos locales y remotos.
 Interacciones configurables con los usuarios basadas en portales.
 Aplicaciones que se instalan en la máquina local (tales como una aplicación Windows).
 Aplicaciones empresariales corporativas con extensiones específicas (como el Office de
Microsoft con paneles para actividades específicas)
 Aplicaciones diseñadas para dispositivos móviles.
 Los servicios pueden actuar como consumidores de otros servicios.
Recordemos que el modelo de SOA es fractal – los servicios pueden ser consumidos por
otros servicios y las composiciones de servicios pueden ser expuestas como nuevos
servicios.
En los dos últimos años una “nueva raza" de consumidores ha emergido, permitiendo a los
consumidores agregarse y consumirse por otros consumidores. Esta “nueva raza” de
consumidores se le llama generalmente “mashup”. Un mashup es un conjunto de servicios,
sitios Web o aplicaciones que combinan el contenido de múltiples recursos en una interacción
con el usuario integrada. El contenido utilizado por los mashups procede típicamente de un
tercero (un servicio o sitio Web) a través de una interfaz pública o API. Algunos de los
métodos alternativos de suministro de contenido para mashups son las fuentes de noticias y
bloques JavaScript (JSON).
Las capacidades recurrentes de la arquitectura nos proporcionan una serie de criterios para
la interacción con el usuario. Echemos un vistazo a algunas de las consideraciones
asociadas con cada capacidad (no pretende ser una lista completa):
Mensajería y servicios
Consumo de servicios desde formularios.
Web parts3.
Registro de servicios – check in /check out/búsqueda.
AJAX, REST.
3
Se denomina así a una sección (ventana) dentro de una página Web en los sitios desplegados con la
tecnología SharePoint de Microsoft. Representa, desde el punto de vista de la programación, un control
dentro de la interfaz de usuario. (Nota del traductor).

40. 28 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
Flujos y procesos
Flujos de trabajo humano (MOSS).
Intermediación de eventos (CAB).
Definición de los flujos de trabajo (pageflows).
Datos
Entidades (Catálogo de datos en aplicaciones ofimáticas).
Vista única del problema del cliente.
JSON.
Experiencia del usuario
Aplicaciones compuestas (aplicaciones ofimáticas).
Personalización, perfiles de usuario.
Portales.
Inteligencia de negocios.
Reportes.
Agregación de contenido.
Interacciones con el usuario declarativas.
Identidad y acceso
Single Sign-On (sincronización de contraseñas).
Identificación del usuario.
Acceso basado en roles (RBAC).
Servicios de directorio.
Gestión de contraseñas.
Privacidad (firewalls, cifrado).
Conformidad.

41. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 29
Resumen
En este capítulo se han proporcionado algunas analogías útiles para entender la naturaleza
fractal de SOA. Los servicios son los pilares fundamentales de SOA, aunque los servicios no
necesariamente tienen que ser servicios Web. En el caso ideal, estos servicios siguen los
cuatro principios de diseño de los servicios que describen un conjunto de buenas prácticas
para el ámbito, las dependencias, las comunicaciones y la configuración basada en políticas
de los servicios. Si bien estos principios se centran en el diseño de servicios, es importante
comprender que los servicios, por sí solos, no son necesariamente la arquitectura de la
solución - Microsoft utiliza un modelo de referencia abstracto para describir los diversos
aspectos de la arquitectura SOA. El modelo abstracto de referencia para SOA proporciona
tres conceptos fundamentales para ayudar a la mayoría de las organizaciones a entender el
papel que pueden desempeñar los servicios en las arquitecturas de sus soluciones:
 La exposición se centra en cómo las inversiones en TI existentes se exponen como un
conjunto de servicios generales basados en estándares, permitiendo que estas
inversiones estén a disposición de un amplio conjunto de los consumidores. La
arquitectura de implementación de servicios describe cómo se desarrollan, implementan
y administran los servicios.
 La composición se centra en la combinación de los servicios en aplicaciones o procesos
de negocio de funciones cruzadas. La arquitectura de integración de servicios describe
un conjunto de capacidades para la composición de servicios y otros componentes en
ensamblados mayores como los procesos de negocio.
 El consumo se centra en ofrecer nuevas aplicaciones que permiten una mayor
productividad y una mayor penetración en el rendimiento del negocio. La arquitectura de
aplicaciones orientadas a servicios describe cómo “servicios compuestos” se ponen a
disposición para el consumo a través de procesos de negocio, nuevos servicios o nuevas
aplicaciones de usuario final.
Cada aspecto del modelo abstracto de referencia de exposición/composición/consumo
abarca un conjunto de cinco funciones arquitectónicas recurrentes: mensajería y servicios,
flujos de trabajo y procesos, datos, interacción con el usuario, y la de identidad y acceso. Las
cinco funciones arquitectónicas sirven como un conjunto de puntos de vista para comprender
mejor los desafíos asociados con la exposición de inversiones existentes en TI como
servicios, la composición de los servicios en los procesos empresariales y el consumo de
estos procesos en toda la organización.

42. 30 Capítulo 1: Arquitectura Orientada a Servicios (SOA)