i La Arquitectura Orientada a Servicios (SOA) en el Mundo Real                                John Evdemon        Editoria...
Nota del traductorEl desarrollo de la informática facilitará la conexión con la mayor parte del universo deobjetos, a trav...
Para la conformación del libro que ponemos ahora en manos del lector, además de latraducción del material original, se han...
Agradecimientos del autorLa mayor parte del contenido de este libro está tomado de una amplia variedad de fuentes.Parte de...
Tabla de ContenidoCapítulo 1: Arquitectura Orientada a Servicios (SOA) .......................1  Guía para el lector ........
Entendiendo los servicios ..................................................................................... 32     Un ...
¿Por qué flujos?.............................................................................................................
Publicación de las actualizaciones .............................................................................. 116     ...
Las leyes de la identidad ............................................................................................. 17...
1Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                    “Las SOAs son como copos de nieve...
2                                                Capítulo 1: Arquitectura Orientada a Servicios (SOA)Introducción a SOAEl ...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                       3del sector, expertos, blogeros...
4                                                  Capítulo 1: Arquitectura Orientada a Servicios (SOA)   De las 950 puer...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                              5en el pasado? No – las ...
6                                                 Capítulo 1: Arquitectura Orientada a Servicios (SOA)La evolución de SOAL...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                          7    en un objeto de referen...
8                                                  Capítulo 1: Arquitectura Orientada a Servicios (SOA)    de negocio inte...
10                                                 Capítulo 1: Arquitectura Orientada a Servicios (SOA)adaptarse a nuevos ...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                         11¿Qué es un servicio? En est...
12                                                   Capítulo 1: Arquitectura Orientada a Servicios (SOA)    La determina...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                          13    de salida igualmente b...
14                                                 Capítulo 1: Arquitectura Orientada a Servicios (SOA)confiar en que los ...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                         15Las clases combinan el comp...
16                                                  Capítulo 1: Arquitectura Orientada a Servicios (SOA)     de la sintaxi...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                      17Un modelo abstracto de referen...
18                                                Capítulo 1: Arquitectura Orientada a Servicios (SOA)ExposiciónLa exposic...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                      19usuarios finales. El consumo s...
20                                                Capítulo 1: Arquitectura Orientada a Servicios (SOA)Capacidades arquitec...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)   21aplicaciones
22                                                 Capítulo 1: Arquitectura Orientada a Servicios (SOA)    Diferencias en...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                     23Las capacidades arquitectónicas...
24                                                       Capítulo 1: Arquitectura Orientada a Servicios (SOA)     SLAs.   ...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                       25    Identidad y acceso    Ges...
26                                                  Capítulo 1: Arquitectura Orientada a Servicios (SOA)     Mensajería y ...
Capítulo 1: Arquitectura Orientada a Servicios (SOA)                                                     27ConsumoInteracc...
28                                                  Capítulo 1: Arquitectura Orientada a Servicios (SOA)     Flujos y proc...
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Soa in the real world   traducido
Upcoming SlideShare
Loading in …5
×

Soa in the real world traducido

2,321 views

Published on

Traduccion al español del libro "SOA in the Real World"

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,321
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
208
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Soa in the real world traducido

  1. 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íaRevisión: Dr. Leonel Iriarte Navarro
  2. 2. Nota del traductorEl desarrollo de la informática facilitará la conexión con la mayor parte del universo deobjetos, a través de la denominada Internet de las cosas, la que ofrecerá la capacidad real deinterconectar y seguir el movimiento de millones de objetos mediante el empleo del IPV6 yotras 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 elementosconsumibles desde las nuevas aplicaciones. Para lograr dicho propósito, el enfoque orientadoa servicios, tratado en este libro, adquiere especial importancia.Este enfoque tiene su base tecnológica en la programación orientada a objetos, donde sedio un importante paso en la reusabilidad del código y la separación de la interfaz conrespecto a la implementación. Los modelos Corba y DCOM se propusieron entonces recorrerla última yarda hacia esta meta e introdujeron el concepto de llamada a procedimientosremotos 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 eninteroperabilidad en entornos totalmente heterogéneos en los cuales, una solucióninformática puede entonces estar conformada por bloques que residen en equipos distantescon plataformas de hardware que pueden ser distintas y sobre sistemas operativos quepueden ser también diferentes.Microsoft ha trabajado intensamente en el desarrollo de plataformas orientadas a serviciosdesde la década de los 90 del pasado siglo. En el 2007, después de alcanzar una madureznotable en este enfoque, encomendó la publicación del libro electrónico gratuito “SOA in theReal World”, cuya traducción al castellano presentamos ahora, precisamente teniendo encuenta la importancia que concedemos a la generalización de estos conceptos entre losdesarrolladores de hoy y mañana.El autor del texto, John Evdemon, es un experto en los temas de SOA, BPM y XML, que por eltiempo en que este libro fue publicado, pertenecía al equipo de estrategias en arquitecturasde 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 acercade la tecnología. Estos examinan los principios que Microsoft propone para SOA, introducenel 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íade un servicio y describen los escenarios SOA.Los capítulos subsiguientes, tratan diferentes aspectos relacionados con la aplicabilidaddel enfoque SOA en el manejo de los flujos de trabajo, los procesos y los datos, así como enla 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 soncontextualizados a través de estudios de casos, que muestran cómo estos aspectos sonconsiderados por los productos y tecnologías de Microsoft, en el mundo real.
  3. 3. Para la conformación del libro que ponemos ahora en manos del lector, además de latraducción del material original, se han introducido algunos cambios que es necesariocomentar. En primer lugar, por la forma en que apareció este trabajo originalmente enInternet, como una serie de artículos, hemos decidido unificar las secciones deagradecimientos 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 delos capítulos originales, ya que el contenido se encuentra saturado de este tipo dereferencias, y pudiera resultar engorroso al lector la búsqueda por todo el texto de lossignificados de cada acrónimo, si este solo se mostraba en la primera aparición, como esusual en la literatura técnica. La Habana, diciembre de 2011 Carlos de Armas García
  4. 4. Agradecimientos del autorLa 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 otrosmateriales en diferentes formatos.Muchos de los conceptos tratados en el Capítulo 1 se basan en esfuerzos anteriores yapublicados. Queremos agradecer a las siguientes personas por su trabajo en esta área: DonBox (los cuatro principios), John Devadoss (capacidades recurrentes de la arquitectura), yKris 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 ycapacidades, Windows Workflow Foundation) y de John Evdemon (conceptos, términos ymanifiesto de flujo).Los conceptos discutidos en el capítulo 4 han sido elaborados a partir de materialespresentados en este mismo espacio1. Queremos agradecer a las siguientes personas por sutrabajo en esta área: Roger Wolter (aspectos relacionados con los datos, generalidades deMDM, 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 esfuerzosanteriores en este mismo espacio. Deseamos agradecer a las siguientes personas por sutrabajo 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.
  5. 5. Tabla de ContenidoCapí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............................................................................................................... 29Capítulo 2: Mensajes y Servicios .......................................................31 Guía para el lector ................................................................................................ 31
  6. 6. 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 ............................ 60Capí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
  7. 7. ¿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 ........................................ 89Capí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
  8. 8. 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 ........................................... 123Capí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 ...................................................... 150Capí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
  9. 9. 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 .............................................................................. 180Apéndice A. Glosario de acrónimos ................................................181Referencias .........................................................................................187
  10. 10. 1Capítulo 1: Arquitectura Orientada a Servicios (SOA) “Las SOAs son como copos de nieve – no hay dos iguales.” - David Linthicum ConsultorGuía para el lectorLos lectores de este capítulo aprenderán acerca de algunos de los conceptos generalesasociados con la Arquitectura Orientada a Servicios (SOA). El capítulo ofrece variasanalogías para la comprensión del concepto de orientado a servicios y algunasrecomendaciones de alto nivel para el diseño de servicios. En este capítulo se ofrece unmodelo abstracto para describir SOA y se introduce un conjunto de capacidades de laarquitectura que se analizarán en los capítulos siguientes del libro.
  11. 11. 2 Capítulo 1: Arquitectura Orientada a Servicios (SOA)Introducción a SOAEl elefante SOA.SOA se ha convertido en un acrónimo muy conocido y además algo polémico. Si uno pide ados 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 aSOA 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 ciegosy el elefante. Seis hombres ciegos de Indostán encuentran un elefante. Cada uno de loshombres, a continuación, describe al elefante de una manera ligeramente diferente, ya queestá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 SaxeLos ciegos entonces se enzarzan en una serie de debates acerca de lo que creen estarenfrentando: “…¡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
  12. 12. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 3del sector, expertos, blogeros y reporteros se enfrentan unos con otros en un procesocontinuo e interminable acerca de lo que es o no es SOA. Como los ciegos de Saxe, la genteha identificado correctamente muchas de las capacidades de SOA, pero la mayoría no escapaz de expresar el concepto como un todo. El reto de la definición de SOA se ha vuelto tanimportante que diversos fabricantes y organizaciones de normalización han lanzadoiniciativas para tratar de responder a la pregunta: ¿Qué es SOA?Una simple definición para SOAPara 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, losservicios Web, WSDL, WS-* y otros estándares asociados? SOA no requiere necesariamentedel uso de servicios Web – los servicios Web son, para la mayoría de las organizaciones, elenfoque más simple para implementar una arquitectura de acoplamiento flexible. En elpasado, las arquitecturas de acoplamiento flexible se han basado en otras tecnologías comoCORBA 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 porquetiene en cuenta las necesidades de la organización. En términos más simples, la SOA de unaorganización puede parecerle a otra nada más que un montón de Servicios Web (u otrastecnologías). Puede haber algunas capacidades de la infraestructura comunes, como elregistro y la autenticación, pero en la mayor parte de los casos la arquitectura SOA de unaorganización, será muy diferente de la SOA utilizada por otra.Muchos analistas y expertos de la industria han confundido el concepto de arquitecturaorientada a servicios con implementaciones orientadas a servicios. Esto sólo ha añadido másconfusión a la asociada con SOA y sus conceptos afines y puede llevar a resultadosdesastrosos.La misteriosa mansión Winchester, enclavada cerca de San José, California, es unaatracción turística muy interesante en los EE.UU. La mansión fue el hogar de la heredera dela fortuna de Winchester (acumulada por la venta de los rifles Winchester). Según laleyenda, la heredera fue a ver a un adivino y supo que estaba condenada a ser perseguidapor 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 mantuvieraconstruyéndola los espíritus la dejarían en paz.La mujer contrató rápidamente a 147 constructores (y ningún arquitecto), todos los cualescomenzaron a trabajar en la mansión de forma simultánea. Los constructores trabajaron enla 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.
  13. 13. 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 WinchesterLa confusión de la arquitectura con la implementación genera resultados caóticos eimpredecibles, al igual que en la misteriosa mansión Winchester. Artículos que tratan deexplicar SOA e inmediatamente saltan a un tutorial para la creación de Servicios Web, estánbrindando realmente orientación para la programación, no para la arquitectura. Esta es unade las muchas razones por las que SOA es tan mal entendido hoy en día - la prisa porpromover 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 apartir de ideas introducidas originalmente por CORBA, DCOM, DCE y otras. A diferencia deestas iniciativas previas, la promesa esencial de SOA es permitir procesos de negocio ágilesa través de una interoperabilidad abierta basada en estándares. Si bien estos estándares sonimportantes, debemos recordar que las especificaciones no son la arquitectura, y laarquitectura no es la implementación. Al final del día, es la implementación de unaarquitectura bien diseñada la que va a generar beneficios para el negocio, no la propiaarquitectura.SOA es un enfoque arquitectónico para la creación de sistemas construidos a partir deservicios 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 diferenteslenguajes de programación, alojados en distintas plataformas con una variedad de modelosde seguridad y de procesos de negocio. Si bien este concepto suena increíblementecomplejo, no es nuevo – pudiera decirse que SOA ha evolucionado a partir de lasexperiencias asociadas con el diseño y desarrollo de sistemas distribuidos basados entecnologías ya disponibles. Muchos de los conceptos asociados a SOA, como los servicios, eldescubrimiento y el enlace tardío estaban asociados a CORBA y DCOM. Del mismo modo, lamayoría de los principios de diseño de los servicios, tienen mucho en común con técnicasanteriores como OOA/OOD basadas en la encapsulación, la abstracción y las interfacesclaramente definidas.¿Significa el bullicio en torno a SOA y los servicios que las TI no fueron orientadas a servicios
  14. 14. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 5en el pasado? No – las TI (subcontratadas o no) sólo existen para potenciar los negocios. SinTI 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 losuficientemente rápido, entonces serán percibidas como un limitante de la empresa en lugarde un facilitador.SOA promete ayudar a las TI a responder a las condiciones del mercado de maneraoportuna. SOA, sin embargo, es una filosofía de arquitectura y no necesariamente unconcepto implementable. Muchos analistas y revistas especializadas han confundido a laarquitectura 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 SOAdadas las enormes diferencias en cuanto a sus necesidades de negocio y metas. Este simplehecho es una de las razones por las que describir a SOA es un gran desafío. SOA, comocualquier iniciativa, debe proporcionar un cierto valor de uso a la organización - de lo contrariono serviría de nada ni siquiera considerarla. La mejor manera de asegurar que las inversionesen SOA proporcionarán un retorno a la organización es alinear SOA con los líderes delnegocio en la organización. A pesar de esta evidencia, todavía hay mucha confusión acercade SOA.SOA, mitos y realidadesHay varios mitos relacionados con SOA que es muy importante comprender antes decontinuar penetrando en ella. La siguiente tabla describe algunos de los mitos de SOA y loshechos 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óny no debe ser una meta.
  15. 15. 6 Capítulo 1: Arquitectura Orientada a Servicios (SOA)La evolución de SOALa 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 desarrollobasado en componentes en los años 90, y ahora tenemos la orientación a servicios. Laorientación a servicios mantiene los beneficios del desarrollo basado en componentes (laauto-descripción, la encapsulación, el descubrimiento y la carga dinámica), pero hay uncambio en el paradigma desde métodos de objetos invocados remotamente, a uno de pasode mensajes entre los servicios. Los esquemas describen no sólo la estructura de losmensajes, sino también los contratos de comportamiento para definir patrones deintercambio de mensajes y políticas para definir la semántica de servicios. Esto promueve lainteroperabilidad, y por lo tanto ofrece los beneficios de la adaptación, ya que los mensajespueden ser enviados desde un servicio a otro sin tener en cuenta cómo ha sido implementadoel 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 softwaredistribuido 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 desoftware orientado a servicios, en virtud de la avalancha de herramientas de desarrollo deapoyo, y la interoperabilidad de todo el sector. Aunque implementadas más frecuentementeutilizando los servicios Web estándares, la orientación a servicios es independiente de latecnología y los patrones arquitectónicos, y se puede utilizar para conectar con los sistemaslegados.Desafortunadamente, los beneficios ofrecidos por la orientación a servicios y SOA han sidooscurecidos por el bombo y la confusión que rodean cada vez más estos términos. Si bien elconocimiento y el entusiasmo en torno a SOA han aumentado, las líneas claras que una vezdefinieron la orientación a servicios, se han desdibujado. Sin embargo, SO ofrece algunasventajas específicas cuando se utiliza para el propósito correcto. Hay tres observacionesimportantes 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
  16. 16. 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 demensajes bien definidos. Los servicios deben ser diseñados de modo que garanticen ladisponibilidad y la estabilidad. Los servicios están construidos para durar mientras lasconfiguraciones 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 deacoplamiento flexible, es mucho más abierta a los cambios que una organización limitada porlas aplicaciones monolíticas subyacentes, que requieren semanas para implementar elcambio más pequeño. Los sistemas con acoplamiento flexible resultan en procesos denegocio de acoplamiento flexible, ya que los procesos de negocio ya no están restringidospor las limitaciones de la infraestructura subyacente.Los servicios y sus interfaces asociadas deben permanecer estables, lo que les permitevolver a ser configurados o re-agregados para satisfacer las necesidades siemprecambiantes de los negocios. Los servicios se mantienen estables apoyándose en interfacesbasadas en estándares y mensajes bien definidos -por ejemplo, usando SOAP y esquemasXML para la definición de los mensajes. Los servicios diseñados para realizar funcionesgranulares simples, con un conocimiento limitado de cómo los mensajes se transmiten haciao 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 desdecero. Siguiendo los cuatro principios (ver más abajo) se pueden reutilizar los activos de las TIexistentes, envolviéndolos en servicios modulares que pueden conectarse a cualquierproceso 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
  17. 17. 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 haydiscusión de los servicios Web que sea completa sin una referencia a las ventajas delacoplamiento flexible de los extremos (aplicaciones) facilitado por el uso de protocolos paralos servicios Web. El principio radica en la utilización de un recurso sólo a través del serviciopublicado y no direccionando la implementación subyacente. De esta forma, los cambiosrealizados por el proveedor del servicio en la implementación no deben afectar al consumidordel servicio. Al mantener una interfaz consistente, el consumidor de un servicio podría elegiruna instancia alternativa del mismo tipo de servicio (por ejemplo, cambiar de proveedor delservicio) sin modificar la aplicación consumidora excepto en la dirección de la nuevainstancia. El consumidor y el proveedor del servicio no tienen que tener las mismastecnologías para la implementación, la interfaz, o la integración, cuando se usan serviciosWeb (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
  18. 18. 10 Capítulo 1: Arquitectura Orientada a Servicios (SOA)adaptarse a nuevos servicios ofrecidos después del despliegue. La disponibilidad yestabilidad de estos servicios resulta, por tanto, un factor crítico.Entendiendo los serviciosEl primer paso en cualquier proyecto SOA es identificar claramente los problemas críticos oretos 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 claradesde arriba, será más fácil contar con la aceptación de los proyectos que son interfuncionales por naturaleza.Una vez que los gestores de negocio de la organización se definen, el proceso de análisis delos servicios puede comenzar. El análisis de los servicios es uno de los varios pasos quecomponen el ciclo de vida de los servicios (el capítulo 2 ofrece más información acerca delciclo de vida de los servicios). El ciclo de vida de los servicios presenta los pasos que unaorganización debe seguir para definir, desarrollar, desplegar y operar un servicio.Los servicios son usados muchas veces para exponer inversiones en TI tales como sistemaslegados y aplicaciones de líneas de negocio. Los servicios pueden ser ensamblados (ocompuestos) dentro de los procesos de negocio, y quedar disponibles para el consumo porlos 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 enaplicaciones compuestas, y hacer que las salidas estén disponibles para su consumo por elusuario. 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 laimplementación. El invocador de un servicio sólo necesita (y solo debe necesitar) conocer lainterfaz, la implementación puede evolucionar con el tiempo sin afectar a los clientes delservicio. Varios beneficios claves de la orientación a servicios se derivan de esta abstracciónde la capacidad con respecto a la forma en que la capacidad se ofrece. Esto significa que, lamisma interfaz puede ser ofrecida por muchas implementaciones, o por el contrario, que lasimplementaciones pueden cambiar sin afectar a la aplicación agregada. En su forma másabstracta, la orientación a servicios lo ve todo – ya sea una aplicación de mainframe o unaimpresora o un expedidor en un muelle o una compañía de entregas nocturnas - comoproveedores de servicios. El modelo de servicios es “fractal”: el proceso recién formado estambién un servicio, que expone una nueva capacidad agregada.
  19. 19. 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 serviciotambié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 unaaplicació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 enuna arquitectura de acoplamiento flexible. Hay cuatro principios que pueden ayudar aconformar una arquitectura de acoplamiento flexible. Estos principios se definen acontinuación:Los principios del diseño de serviciosEl acrónimo SOA plantea una pregunta obvia - ¿qué es, exactamente, un servicio? En pocaspalabras, un servicio es un programa con el que se puede interactuar a través del intercambiode mensajes bien definidos. Los servicios deben ser diseñados para asegurar disponibilidady estabilidad. La agilidad se promueve a menudo como uno de los mayores beneficios deSOA - una organización que ha implementado los procesos de negocio sobre unainfraestructura de acoplamiento flexible es mucho más abierta a los cambios que unaorganización limitada por aplicaciones monolíticas subyacentes, que requieren semanaspara implementar el cambio más insignificante. Los sistemas de acoplamiento flexible derivanen procesos de negocio de acoplamiento flexible, ya que estos últimos no están limitados porlas restricciones de la infraestructura subyacente.Los servicios y sus interfaces asociadas deben permanecer estables, posibilitando que seanreconfigurados o agregados para satisfacer las necesidades siempre cambiantes de losnegocios. Los servicios se mantienen estables cuando responden a interfaces basadas enestándares y mensajes bien definidos - en otras palabras, esquemas SOAP y XML para ladefinición de los mensajes. Los servicios diseñados para realizar funciones granularessimples, con un conocimiento limitado de cómo los mensajes se transmiten hacia o desdeestos, son mucho más propensos a ser reutilizados en una infraestructura SOA. Como se hadicho anteriormente, recordar los principios básicos del diseño orientado a objetos conrespecto a la encapsulación y el diseño de interfaces, nos será muy útil al diseñar y construirservicios Web reutilizables. Podemos extender estos principios de la orientación a objetos almundo de los servicios Web con una comprensión profunda de los “cuatro principios” de laorientació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 biendefinidas. El cruce de las fronteras de los servicios puede ser costoso, en dependencia defactores geográficos, de confianza o de ejecución. Una frontera representa el límite entre lainterfaz pública del servicio y su implementación interna privada. La frontera de un servicio sepublica a través de WSDL y puede incluir formulaciones que establezcan las expectativas delservicio. 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.
  20. 20. 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ánsujetas a la latencia de la red, a fallos en la red, y a los fallos del sistema distribuido, pero unaimplementación a nivel local no lo está. Debe escribirse una cantidad importante de lógica dedetección y corrección de errores para prever las consecuencias del uso de interfaces conobjetos 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 almínimo los cruces de frontera. Un sistema que implementa métodos y objetos localesmonolíticos puede ganar en el rendimiento pero duplicar la funcionalidad de un serviciopreviamente definido (esta técnica se conoce como “cortar y pegar” en la programaciónorientada 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
  21. 21. 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ónomosLos servicios son entidades que están desplegados, versionados, y administrados de maneraindependiente. Los desarrolladores deben evitar hacer suposiciones sobre el espacio entrelos límites del servicio ya que este espacio es mucho más probable que cambie que laspropias fronteras. Por ejemplo, los límites del servicio deben ser estáticos para minimizar elimpacto del control de versiones para el consumidor. Mientras que los límites de un servicioson 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 lalocalización subyacente y las topologías de implementación puedan cambiar o evolucionar enel tiempo con muy poco impacto en el servicio (esto también se aplica a los canales decomunicación de un servicio). Si bien estos cambios pueden tener poco impacto sobre elservicio, pueden tener un impacto devastador sobre las aplicaciones que consumen elservicio. ¿Qué sucede si un servicio que se utiliza hoy en día en EEUU se traslada a una reden Nueva Zelanda mañana? El cambio en el tiempo de respuesta puede tener efectos noplaneados o inesperados en los consumidores del servicio. Los diseñadores de serviciosdeben adoptar una visión pesimista de la forma en que sus servicios serán consumidos - losservicios 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 deexcepciones y lógicas de compensación. Además, los consumidores de servicios puedentener que modificar sus políticas para declarar los tiempos mínimos de respuesta de losservicios que consumen. Por ejemplo, los consumidores de un servicio pueden requerirdiferentes niveles de servicio en materia de seguridad, rendimiento, transacciones, y muchosotros factores. Una política configurable permite que un servicio en particular soportemú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). Elintercambio acerca de las expectativas de desempeño a nivel de servicio preserva laautonomía, ya que los servicios no tienen que estar familiarizados con las implementacionesinternas de los otros servicios.Los consumidores de servicios no son los únicos que deben adoptar visiones pesimistasacerca del rendimiento - los proveedores de los servicios deben ser igualmente pesimistas alestimar cómo sus servicios van a ser consumidos. Debe esperarse que los consumidores delos servicios fallen, a veces sin avisar al servicio. Los proveedores de servicios no pueden
  22. 22. 14 Capítulo 1: Arquitectura Orientada a Servicios (SOA)confiar en que los consumidores “hacen las cosas correctamente”. Por ejemplo, losconsumidores pueden tratar de comunicarse mediante mensajes mal conformados omaliciosos, o intentar violar las políticas de otra índole necesarias para la interacción exitosacon el servicio. La implementación interna del servicio debe tratar de compensar el usoinadecuado, 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 configuradospara garantizar una solución específica. Pensando de forma autónoma, nos damos cuentarápidamente que no hay autoridad que presida en un entorno orientado a servicios - elconcepto de un conductor de la orquesta es fallido (implicando que el concepto de rollback através de los servicios sea también deficiente, pero este es un tema que se sale del alcancede este material). Las claves para la implementación de servicios autónomos son elaislamiento y la desconexión. Los servicios se diseñan y despliegan independientementeunos de los otros y sólo pueden comunicarse mediante mensajes y políticas establecidascontractualmente.Al igual que con otros principios de diseño de los servicios, podemos aprender de nuestrasexperiencias pasadas con el diseño orientado a objetos. El trabajo de Peter Herzum y OliverSims sobre las fábricas de componentes de negocio, ofrece algunas ideas interesantes sobrela naturaleza de los componentes autónomos. Si bien la mayor parte del trabajo es másapropiado para soluciones basadas en componentes de grano grueso, los principios básicosde diseño siguen siendo aplicables para el diseño de servicios.Teniendo en cuenta estas consideraciones, he aquí algunos principios de diseño simples queayudan 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 clasesComo se dijo anteriormente, la interacción de los servicios debe estar basada únicamente enlas políticas, el esquema y el comportamiento basado en contratos. El contrato de un serviciose define generalmente a través de WSDL, mientras que los contratos para la agregación deservicios se pueden definir utilizando BPEL (que a su vez utiliza WSDL para cada servicioagregado).La mayoría de los desarrolladores define clases para representar las distintas entidadesdentro de un espacio de problemas determinado (por ejemplo, cliente, pedido y producto).
  23. 23. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 15Las clases combinan el comportamiento y los datos (mensajes) en un único ensamblado conun lenguaje de programación o plataforma específica. Los servicios rompen este modelo paramaximizar la flexibilidad y la interoperabilidad. Los servicios comunicándose a través demensajes basados en esquemas XML, son agnósticos con respecto al lenguaje deprogramación y la plataforma, lo que garantiza mayor nivel de interoperabilidad. El esquemadefine la estructura y el contenido de los mensajes, mientras que el contrato del serviciodefine 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 einteractuar con un servicio. Teniendo en cuenta esta dependencia, el contrato de un serviciodebe permanecer estable en el tiempo. Los contratos deben ser diseñados lo másexplícitamente posible, aprovechando la naturaleza extensible del esquema XML (xsd: any) ydel modelo de procesamiento SOAP (encabezados opcionales).El mayor reto del tercer principio es su permanencia. Una vez que un contrato de servicio seha publicado, se convierte en extremadamente difícil de modificar reduciendo al mínimo elimpacto sobre los consumidores de servicios existentes. La línea entre las representacionesde datos internos y externos es fundamental para el éxito del despliegue y la reutilización deun servicio determinado. Los datos públicos (los transmitidos entre los servicios) debenbasarse en estándares organizacionales o verticales, lo que garantiza una amplia aceptaciónentre los diferentes servicios. La información privada (los datos dentro de un servicio) seencapsula dentro de un servicio.En cierto modo, los servicios son como pequeñas representaciones de una organización querealiza transacciones de comercio electrónico. Al igual que una organización debe mapearuna orden de compra externa a su formato interno, un servicio también debe mapear unarepresentación de los datos basada en un contrato acordado a su formato interno. Una vezmás, nuestras experiencias con la encapsulación de datos orientada a objetos pueden serreutilizadas para ilustrar un concepto similar - la representación de los datos internos de unservicio sólo pueden manipularse a través del contrato del servicio.Teniendo en cuenta estas consideraciones, he aquí algunas recomendaciones simples dediseñ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
  24. 24. 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íticasSi bien este se considera a menudo el menos entendido de los principios de diseño, es quizásuno de los más potentes en cuanto a la implementación de servicios Web flexibles. No esposible comunicar algunos requisitos para la interacción de los servicios usando solamenteWSDL. Expresiones políticas se pueden utilizar para separar la compatibilidad estructural (loque se comunica) de la compatibilidad semántica (¿cómo o con quien se comunica unmensaje?).Los requisitos operacionales para los proveedores de servicios pueden manifestarse enforma de expresiones que pueden ser evaluadas por la computadora. Las expresiones depolítica proporcionan un conjunto configurable de semánticas interoperables que rigen elcomportamiento y las expectativas de un servicio determinado. La especificación de políticasde WS define una infraestructura de políticas de lectura mecánica capaz de expresar políticasa 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 unapolítica reforzando un nivel de servicio específico (por ejemplo, las fotos de pasaporte quecumplen con ciertos criterios establecidos deben ser cotejadas con un sistema deidentificación de terroristas). La información de política relacionada con este servicio podríaser utilizada en una serie de otros escenarios o servicios relacionados con la realización deuna verificación de antecedentes. Las políticas de WS se pueden utilizar para hacer cumplirestos requisitos sin necesidad de una sola línea de código adicional. Este escenario muestracómo una infraestructura de políticas proporciona información adicional acerca de losrequerimientos de un servicio, al mismo tiempo que también proporciona un modelo deprogramación declarativa para la definición y ejecución del servicio.Un planteamiento de la política identifica un comportamiento que es un requerimiento (ocapacidad) de un tema de política. (En el escenario anterior el planteamiento es laverificación de antecedentes contra el sistema de identificación de terroristas.) Losplanteamientos proporcionan semánticas de dominio específico y eventualmente se definirándentro de especificaciones de dominio específico independientes, para una variedad deindustrias 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 desarrolladoresdeben asegurarse de que sus planteamientos de política sean tan explícitos como seaposible 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 ydesarrollo de sus servicios.
  25. 25. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 17Un modelo abstracto de referencia para SOASi bien un proyecto SOA bien planificado y ejecutado puede ayudar a las organizaciones aobtener mayor capacidad de respuesta en un mercado cambiante, no todos los esfuerzosorientados a los servicios han tenido éxito. Los proyectos SOA pueden experimentar un éxitolimitado cuando son gestionados desde abajo hacia arriba por desarrolladores que no estánfamiliarizados con las necesidades estratégicas de la organización. La construcción de SOApor SOA, sin hacer referencia al contexto de los negocios es un proyecto sin principios ydirectrices de organización. El resultado es una implementación caótica que no tiene ningunarelevancia empresarial. Por otro lado, tomando un enfoque de SOA de arriba hacia abajorequiere 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 dearriba abajo y de abajo arriba. En este enfoque, los esfuerzos de SOA son conducidos por lavisión estratégica y las necesidades de la empresa, y se alcanzan a través de proyectos SOAincrementales e iterativos que se han diseñado para alcanzar los objetivos de negocio unopor uno. Microsoft ha estado utilizando esta técnica para ayudar a los clientes con susiniciativas 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 perspectivaindividual 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 requisitosarquitectónicos subyacentes. Microsoft cree que hay tres capas de capacidades abstractasexpuestas dentro de una SOA. Un ejemplo de estas categorías y las relaciones entre estasaparece a continuación: Figura 6: Un modelo abstracto de referencia para SOA
  26. 26. 18 Capítulo 1: Arquitectura Orientada a Servicios (SOA)ExposiciónLa exposición se centra en cómo las inversiones en TI existentes se exponen como unconjunto de servicios abiertos y basados en estándares, permitiendo que estas inversionesestén al alcance de un conjunto más amplio de consumidores. Es probable que lasinversiones existentes estén basadas en un conjunto heterogéneo de plataformas yproveedores. Si estas aplicaciones son incapaces de soportar de forma nativa los serviciosWeb, 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 denegocio), o de grano grueso (múltiples servicios se agrupan para llevar a cabo un conjunto defunciones de negocio afines). La exposición también se ocupa de cómo se implementan losservicios. La funcionalidad de los recursos de TI subyacentes puede estar disponible deforma nativa si ya habla el lenguaje de los servicios Web, o pueden estar disponibles comoservicios Web a través del uso de un adaptador. Una arquitectura de implementación deservicios describe cómo los servicios se desarrollan, implementan y gestionan.ComposiciónUna 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 existenindependientemente unos de otros, se pueden combinar (o “componer”) y volver a utilizar conla máxima flexibilidad. A medida que los procesos de negocio evolucionan, las reglas y lasprácticas de negocio se pueden ajustar sin las restricciones que imponen las limitaciones delas aplicaciones subyacentes. Las composiciones de servicios permiten que se creen nuevosprocesos de funciones cruzadas, lo que permite a la empresa adoptar nuevos procesos denegocio, ajustar los procesos para lograr una mayor eficacia, o mejorar los niveles de servicioa clientes y socios.Una arquitectura de integración de servicios describe un conjunto de capacidades para lacomposición de servicios, y otros componentes en ensamblados mayores como pueden serlos procesos de negocio. La composición de servicios requiere de algún tipo de flujo detrabajo o mecanismo de orquestación. Microsoft ofrece estas capacidades a través deBizTalk Server 2006 (BTS) o Windows Workflow Foundation (WF). Si bien puede parecer queBTS y WF satisfacen las mismas necesidades, en realidad son muy diferentes. WF y BTS sontecnologí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ítulo3 (flujos de trabajo y procesos de negocio).ConsumoCuando se crea una nueva aplicación o proceso de negocio, esa funcionalidad debe ponersedisponible para el acceso (consumo) por los sistemas de TI, por otros servicios y por los
  27. 27. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 19usuarios finales. El consumo se centra en el suministro de nuevas aplicaciones que permitanuna mayor productividad y una mayor penetración en el rendimiento del negocio. Losusuarios pueden consumir servicios “compuestos” a través de un amplio número de puntosde salida incluyendo portales web, aplicaciones cliente de interfaz enriquecida, aplicacionesofimáticas (OBA), y dispositivos móviles. Los servicios “compuestos” pueden ser utilizadospara desplegar con rapidez aplicaciones que se traducen en nuevas capacidades de negocioo una mejora en la productividad. Estas nuevas aplicaciones se pueden utilizar para medir elretorno de la inversión (ROI) en una SOA.Una arquitectura de aplicaciones orientadas a servicios describe cómo poner disponiblespara el consumo los “servicios compuestos”, a través de procesos de negocio, nuevosservicios o nuevas aplicaciones finales. Este concepto se denomina a veces aplicacionescompuestas, ya que implica el consumo de servicios por aplicaciones finales. Lasaplicaciones ofimáticas de Microsoft (OBA) soportan la noción de aplicación compuesta enlos sistemas transaccionales al mismo tiempo que amplían el alcance de la interacción delusuario a través del familiar entorno del Office.Si bien las arquitecturas descritas en los epígrafes exposición/composición/consumo puedenser interdependientes, están diseñadas para su acoplamiento flexible. Esto permite que losservicios sean gestionados, versionados y configurados independientemente de la forma enque han sido expuestos.
  28. 28. 20 Capítulo 1: Arquitectura Orientada a Servicios (SOA)Capacidades arquitectónicas recurrentesComo vimos anteriormente, el modelo de arquitectura SOA es fractal. Esto significa que unservicio puede ser utilizado para exponer activos TI (por ejemplo, un sistema de una línea denegocios), componerse en flujos de trabajo o procesos de negocio (cada uno de los cualestambién puede ser expuesto como un servicio) y consumirse por usuarios finales, sistemasu otros servicios. SOA es un modelo fractal y no un modelo en capas. Si bien el modeloabstracto de referencia SOA proporciona una visión integral de varios importantes conceptosde SOA, las secciones exponer/componer/consumir del modelo no deben ser interpretadascomo 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 entrecomponentes no relacionados. Esta es la razón por la que las seccionesexponer/componer/consumir del modelo pueden ser consideradas como iniciativasarquitectónicas independientes, denominadas respectivamente como arquitectura deimplementación de servicios (exposición), arquitectura de integración de servicios(composición) y arquitectura de aplicaciones (consumo). Aunque estas arquitecturas hansido diseñadas para ser independientes entre sí, comparten un conjunto de cinco funcionescomunes. Figura 7: Capacidades arquitectónicas recurrentesMensajes y serviciosMensajes y servicios se centra en cómo se lleva a cabo el intercambio de mensajes entreemisores y receptores. Hay una amplia gama de opciones y modelos disponibles - desdepublicación/subscripción y asincrónica, hasta los patrones de interacción de mensajes yservicios. Los servicios proporcionan un enfoque evolutivo a la construcción de softwaredistribuido 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 desoftware orientado a servicios, en virtud del soporte de las herramientas de desarrollo y laamplia interoperabilidad en el sector. Si bien se implementa frecuentemente utilizandoservicios Web estándares, la orientación a servicios es independiente de la tecnología y lospatrones arquitectónicos, y se puede utilizar también para conectarse con los sistemaslegados. 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 quepuede ser descubierta y que existe como una instancia única e interactúa con las
  29. 29. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 21aplicaciones
  30. 30. 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 acontinuació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 comunesLa plataforma SOA de Microsoft soporta las cinco capacidades arquitectónicas discutidasmás arriba. El resto del libro discute estas capacidades en mayor detalle, comenzando conlos mensajes y servicios en el Capítulo 2. Figura 8: Capacidades SOA en la plataforma Microsoft
  31. 31. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 23Las capacidades arquitectónicas comunes y el modelo abstracto dereferencia para SOATambién podemos pensar en estas cinco capacidades arquitectónicas comunes como unconjunto de perspectivas para entender el modelo abstracto de SOA. Las cinco capacidadesarquitectónicas nos ayudan a comprender mejor los desafíos asociados con la exposicióncomo servicios de las inversiones existentes en TI, la composición de los servicios en losprocesos empresariales y el consumo de estos procesos en toda la organización.ExposiciónHabilitación de los serviciosLa exposición se centra en cómo diseñar y exponer nuestros servicios. Lo más probable esque 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 probableque 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óndeempezar. Hay una variedad de opciones, y no hay una recomendación única que funcionepara todos. La metodología Motion de Microsoft proporciona una guía para la identificaciónde las capacidades empresariales que podrían exponerse como servicios.¿Cuáles son algunas de los criterios que se deben seguir cuando se exponen inversiones enTI 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 consideracionesal exponer las inversiones en TI como servicios. Echemos un rápido vistazo a algunas de lasconsideraciones asociadas con cada capacidad para la exposición de servicios (no es unalista 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.
  32. 32. 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 yfuncionalidad procedentes de una o más fuentes para crear nuevos servicios. Es tratado más adelante en eltexto. (Nota del traductor)
  33. 33. 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ónComposición de serviciosLa composición se centra en cómo podemos combinar o agregar servicios granulares enprocesos más complejos. Seguramente vamos a empezar por usar los servicios que exponennuestras actuales inversiones en TI. La composición de servicios resulta en una nuevainstancia de servicio que el resto de la organización puede usar. La composición ofrececapacidades tales como la invocación asincrónica correlacionada de servicios, procesos delarga duración y otras capacidades para la orquestación de servicios autónomos.Las capacidades arquitectónicas recurrentes nos proporcionan un conjunto deconsideraciones 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 capacidadpara la composición de los servicios (que no es de ningún modo una lista completa):
  34. 34. 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.
  35. 35. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 27ConsumoInteracción con el usuarioEl consumo se centra en cómo los servicios y procesos orquestados (que pueden serexpuestos a su vez como servicios) son consumidos por otros servicios, aplicaciones yusuarios finales. Cualquier recurso capaz de interactuar con los servicios puede serconsiderado como un “consumidor”. Los consumidores pueden aparecer en la organizaciónen 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 porotros servicios y las composiciones de servicios pueden ser expuestas como nuevosservicios.En los dos últimos años una “nueva raza" de consumidores ha emergido, permitiendo a losconsumidores agregarse y consumirse por otros consumidores. Esta “nueva raza” deconsumidores 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óncon el usuario integrada. El contenido utilizado por los mashups procede típicamente de untercero (un servicio o sitio Web) a través de una interfaz pública o API. Algunos de losmétodos alternativos de suministro de contenido para mashups son las fuentes de noticias ybloques JavaScript (JSON).Las capacidades recurrentes de la arquitectura nos proporcionan una serie de criterios parala interacción con el usuario. Echemos un vistazo a algunas de las consideracionesasociadas 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 latecnología SharePoint de Microsoft. Representa, desde el punto de vista de la programación, un controldentro de la interfaz de usuario. (Nota del traductor).
  36. 36. 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.

×