1. i La Arquitectura Orientada a Servicios (SOA) en el Mundo RealJohn EvdemonEditorial Capitn San LuisTraduccin: Carlos de Armas GarcaRevisin: Dr. Leonel Iriarte Navarro

2. Nota del traductorEl desarrollo de la informtica facilitar la conexin con la mayor parte del universo deobjetos, a travs 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 tecnologas como RFID.Sin embargo, para poder garantizar el acceso real a la diversidad de objetos fsicos, sernecesarioconstruir lasinterfaces estndares que los conviertan en elementosconsumibles desde las nuevas aplicaciones. Para lograr dicho propsito, el enfoque orientadoa servicios, tratado en este libro, adquiere especial importancia.Este enfoque tiene su base tecnolgica en la programacin orientada a objetos, donde sedio un importante paso en la reusabilidad del cdigo y la separacin de la interfaz conrespecto a la implementacin. 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 descripcin y la carga dinmica. Entonces, la reusabilidad se ha transformado eninteroperabilidad en entornos totalmente heterogneos en los cuales, una solucininformtica puede entonces estar conformada por bloques que residen en equipos distantescon plataformas de hardware que pueden ser distintas y sobre sistemas operativos quepueden ser tambin diferentes.Microsoft ha trabajado intensamente en el desarrollo de plataformas orientadas a serviciosdesde la dcada de los 90 del pasado siglo. En el 2007, despus de alcanzar una madureznotable en este enfoque, encomend la publicacin del libro electrnico gratuito SOA in theReal World, cuya traduccin al castellano presentamos ahora, precisamente teniendo encuenta la importancia que concedemos a la generalizacin de estos conceptos entre losdesarrolladores de hoy y maana.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, perteneca al equipo de estrategias en arquitecturasde Microsoft. Actualmente se encuentra involucrado en proyectos de computacin en la nube,SOA y arquitecturas orientadas a eventos.El libro est dividido en 6 captulos. Los dos primeros tienen un carcter introductorio acercade la tecnologa. 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 taxonomade un servicio y describen los escenarios SOA.Los captulos 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 interaccin 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 travs de estudios de casos, que muestran cmo estos aspectos sonconsiderados por los productos y tecnologas de Microsoft, en el mundo real. 3. Para la conformacin del libro que ponemos ahora en manos del lector, adems de latraduccin 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 artculos, 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 apndice con un glosario de acrnimos (siglas) al final delos captulos originales, ya que el contenido se encuentra saturado de este tipo dereferencias, y pudiera resultar engorroso al lector la bsqueda por todo el texto de lossignificados de cada acrnimo, si este solo se mostraba en la primera aparicin, como esusual en la literatura tcnica.La Habana, diciembre de 2011Carlos de Armas Garca 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 Captulo 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 (Exposicin/Composicin/Consumo).El captulo 2 est conformado a partir del trabajo de los siguientes individuos: Mark Baciak(ciclo de vida), Atanu Bannerjee (OBA), Shy Cohen (Taxonoma), William Oellermann(Modelo de madurez SOA), and Brenton Webster (Caso de estudio).El captulo 3 est conformado por el trabajo de Dave Green (conceptos, semntica, valor ycapacidades, Windows Workflow Foundation) y de John Evdemon (conceptos, trminos ymanifiesto de flujo).Los conceptos discutidos en el captulo 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 captulo 5 se basa en las presentaciones y notas aportadas por Simon Guest.Los conceptos discutidos en el captulo 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 (trminos,conceptos y escenarios de identidad federada, y diseo de subsistemas de confianza).1Hace referencia a MSDN Blogs, sitio en que apareci originalmente este libro y otros materiales precedentes. 5. Tabla de ContenidoCaptulo 1: Arquitectura Orientada a Servicios (SOA) .......................1Gua para el lector .................................................................................................. 1Introduccin a SOA ................................................................................................. 2 El elefante SOA. .............................................................................................................. 2 Una simple definicin para SOA ...................................................................................... 3 SOA, Mitos y realidades .................................................................................................. 5 La evolucin de SOA ....................................................................................................... 6 Por qu debo estar informado acerca de SOA? ............................................................ 8Entendiendo los servicios ..................................................................................... 10 Los principios del diseo de servicios ........................................................................... 11 Principio 1: Las fronteras son explcitas. ....................................................................... 11 Principio 2: Los servicios son autnomos...................................................................... 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 polticas .............................. 16Un modelo abstracto de referencia para SOA ...................................................... 17 Exposicin ..................................................................................................................... 18 Composicin .................................................................................................................. 18 Consumo ....................................................................................................................... 18Capacidades arquitectnicas recursivas ............................................................... 20 Mensajes y servicios...................................................................................................... 20 Flujos de trabajo y procesos .......................................................................................... 21 Datos ............................................................................................................................. 21 Interaccin con el usuario .............................................................................................. 21 Identidad y acceso ......................................................................................................... 21 Gestin .......................................................................................................................... 21 Soporte para las capacidades arquitectnicas comunes .............................................. 22Las capacidades arquitectnicas comunes y el modelo abstracto de referencia paraSOA ...................................................................................................................... 23 Exposicin ..................................................................................................................... 23 Composicin .................................................................................................................. 25 Consumo ....................................................................................................................... 27Resumen............................................................................................................... 29Captulo 2: Mensajes y Servicios .......................................................31Gua para el lector ................................................................................................ 31 6. Entendiendo los servicios ..................................................................................... 32 Un modelo de madurez de SOA (algn otro?) ............................................................ 32Taxonoma 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 ................................................................................................... 44Ciclo de vida de un servicio .................................................................................. 46 Anlisis del servicio ....................................................................................................... 46 Desarrollo del servicio ................................................................................................... 46 Verificacin del servicio ................................................................................................. 47 Aprovisionamiento del servicio ...................................................................................... 47 Operacin del Servicio................................................................................................... 47 Consumo del servicio .................................................................................................... 48 Gestin de los cambios del servicio .............................................................................. 48 Desactivacin del servicio ............................................................................................. 48Escenarios SOA .................................................................................................... 49 Integracin de la informacin......................................................................................... 49 Integracin de sistemas heredados ............................................................................... 49 Gobernabilidad de procesos .......................................................................................... 49 Acceso consistente ........................................................................................................ 50 Virtualizacin de los recursos ........................................................................................ 50 Externalizacin de procesos .......................................................................................... 50 Otros escenarios............................................................................................................ 50SOA y el usuario final............................................................................................ 51 Qu son las aplicaciones compuestas? ...................................................................... 53 Qu parece una aplicacin compuesta? ..................................................................... 56 Beneficios esperados de la composicin y como alcanzarla......................................... 58Resumen............................................................................................................... 59Estudio de caso SOA: Banco del Commonwealth en Australia ............................ 60Captulo 3: Flujos y procesos .............................................................61Gua para el lector ................................................................................................ 61Entendiendo los flujos ........................................................................................... 62 Qu es un flujo? .......................................................................................................... 62 Terminologa utilizada en los flujos de trabajo............................................................... 62 7. Por qu flujos?............................................................................................................. 63 Un modelo de flujos de trabajo ...................................................................................... 64 Contratos en los flujos de trabajo .................................................................................. 65 Colaboracin en la resolucin de problemas................................................................. 66 Operaciones de secuencias de comandos .................................................................... 68 Regla y poltica .............................................................................................................. 69 Valor de la plataforma de flujos de trabajo .................................................................... 71 Explotacin ms semntica ........................................................................................... 73 Caractersticas de la plataforma .................................................................................... 74 Una plataforma comn de tiempo ejecucin para flujos de trabajo ............................... 75 Atacando los problemas ................................................................................................ 77Manifiesto de un flujo de trabajo ........................................................................... 78 Agilidad .......................................................................................................................... 78 Abstraccin .................................................................................................................... 78 Los flujos de trabajo estn 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 ......................................................................... 86Comprendiendo la relacin entre BizTalk Server y WF......................................... 87Resumen............................................................................................................... 88Estudio de caso SOA: Grupo Dollar Thrifty Automotive ........................................ 89Captulo 4: Datos..................................................................................91Gua para el lector ................................................................................................ 91Desafos que enfrenta SOA en relacin con los datos .......................................... 92 Generalidades ............................................................................................................... 92 Aspectos relacionados con la integracin de datos ....................................................... 92 Escalabilidad de la Base de Datos ................................................................................ 94Gestin de Datos Maestros (MDM) ....................................................................... 98 Qu es MDM? ............................................................................................................. 98 Integracin de Datos de los Clientes (CDI) ................................................................... 99 Gestin de la Informacin de Productos (PIM) .............................................................. 99 Arquitectura de concentradores de la Gestin de Datos Maestros (MDM) ................... 99 Estilos de arquitecturas para concentradores ............................................................. 100 Aspectos arquitectnicos ............................................................................................. 104 Versiones y jerarquas ................................................................................................. 105 Poblacin y sincronizacin .......................................................................................... 110 8. Publicacin de las actualizaciones .............................................................................. 116 Integridad y confiabilidad de los datos......................................................................... 118 Metadatos .................................................................................................................... 118 Administracin y gobernabilidad .................................................................................. 119 Perfilado de los datos .................................................................................................. 120 Exportacin .................................................................................................................. 120 Reportera .................................................................................................................... 120 Flujos de trabajo y reglas de negocio .......................................................................... 120 Herramientas ............................................................................................................... 121Resumen............................................................................................................. 122Estudio de caso SOA: Bolsa de valores de Londres ........................................... 123Captulo 5: Interaccin con el usuario .............................................125Gua para el lector .............................................................................................. 125Qu es la arquitectura?..................................................................................... 126Introduccin de una plataforma para UX............................................................. 128 Interfaz ......................................................................................................................... 128 Interaccin ................................................................................................................... 135 Infraestructura.............................................................................................................. 140Resumen............................................................................................................. 149Estudio de caso SOA: Aeropuerto de Zrich ...................................................... 150Captulo 6: Identidad y acceso .........................................................151Gua para el lector .............................................................................................. 151Identidad y Acceso .............................................................................................. 152 Generalidades ............................................................................................................. 152Diseo del subsistema de confianza ................................................................... 154 Prcticas actuales........................................................................................................ 155 Diseo del subsistema de confianza ........................................................................... 160 Extensiones de procesos para el subsistema de confianza ........................................ 162 Polticas del subsistema de confianza ......................................................................... 163 Trasmisin de los reclamos de identidad .................................................................... 164 Mapeo identidad/credencial ......................................................................................... 167 Beneficios del diseo ................................................................................................... 167Un metasistema de identidad .............................................................................. 169 Qu es el metasistema de identidad? ....................................................................... 169 Las identidades funcionan en contexto ....................................................................... 170 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 Implementacin del metasistema de identidad............................................................ 176Resumen............................................................................................................. 179Estudio de caso SOA: OTTO .............................................................................. 180Apndice A. Glosario de acrnimos ................................................181Referencias .........................................................................................187 10. 1Captulo 1: Arquitectura Orientada a Servicios (SOA)Las SOAs son como copos de nieve no hay dos iguales. - David Linthicum ConsultorGua para el lectorLos lectores de este captulo aprendern acerca de algunos de los conceptos generalesasociados con la Arquitectura Orientada a Servicios (SOA). El captulo ofrece variasanalogas para la comprensin del concepto de orientado a servicios y algunasrecomendaciones de alto nivel para el diseo de servicios. En este captulo se ofrece unmodelo abstracto para describir SOA y se introduce un conjunto de capacidades de laarquitectura que se analizarn en los captulos siguientes del libro. 11. 2Captulo 1: Arquitectura Orientada a Servicios (SOA)Introduccin a SOAEl elefante SOA.SOA se ha convertido en un acrnimo muy conocido y adems algo polmico. Si uno pide ados personas una definicin de SOA, es probable que reciba dos respuestas muy diferentes,posiblemente en conflicto. Algunos describen a SOA como una infraestructura de TI(tecnologas de la informacin) para la implementacin del negocio, mientras que otros ven aSOA como la va 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 Indostn encuentran un elefante. Cada uno de loshombres, a continuacin, describe al elefante de una manera ligeramente diferente, ya queestn 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 Indostndiscutieron largo y tendido, cada uno con su propia opinin excedindose en fuerza y tesn, aunque cada uno estaba parcialmente en lo cierto,y todos estaban equivocados!En muchos sentidos, el poema de Saxe se ha convertido en una profeca para SOA. Analistas 12. Captulo 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 mayora no escapaz de expresar el concepto como un todo. El reto de la definicin de SOA se ha vuelto tanimportante que diversos fabricantes y organizaciones de normalizacin han lanzadoiniciativas para tratar de responder a la pregunta: Qu es SOA?Una simple definicin para SOAPara los propsitos de este libro definiremos SOA como:Una arquitectura de acoplamiento flexible diseada para satisfacer las necesidades denegocio de la organizacin.A primera vista, esta definicin parece demasiado simplista dnde se metieron SOAP, losservicios Web, WSDL, WS-* y otros estndares asociados? SOA no requiere necesariamentedel uso de servicios Web los servicios Web son, para la mayora de las organizaciones, elenfoque ms simple para implementar una arquitectura de acoplamiento flexible. En elpasado, las arquitecturas de acoplamiento flexible se han basado en otras tecnologas comoCORBA y DCOM, o en enfoques basados en documentos como EDI, para la integracin B2B.Muchas de estas tecnologas tienen todava un uso bastante generalizado y se han ampliado,sustituido o extendido con los servicios Web.Nuestra definicin funciona, no porque el foco no est en la tecnologa SOA, sino porquetiene en cuenta las necesidades de la organizacin. En trminos ms simples, la SOA de unaorganizacin puede parecerle a otra nada ms que un montn de Servicios Web (u otrastecnologas). Puede haber algunas capacidades de la infraestructura comunes, como elregistro y la autenticacin, pero en la mayor parte de los casos la arquitectura SOA de unaorganizacin, 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 slo ha aadido msconfusin a la asociada con SOA y sus conceptos afines y puede llevar a resultadosdesastrosos.La misteriosa mansin Winchester, enclavada cerca de San Jos, California, es unaatraccin turstica muy interesante en los EE.UU. La mansin fue el hogar de la heredera dela fortuna de Winchester (acumulada por la venta de los rifles Winchester). Segn laleyenda, la heredera fue a ver a un adivino y supo que estaba condenada a ser perseguidapor los espritus de aquellas personas, de todo el mundo, asesinadas por un rifle Winchester.La nica manera de evitar la maldicin era construir una mansin, y mientras se mantuvieraconstruyndola los espritus la dejaran en paz.La mujer contrat rpidamente a 147 constructores (y ningn arquitecto), todos los cualescomenzaron a trabajar en la mansin de forma simultnea. Los constructores trabajaron enla mansin hasta que la heredera falleci, 38 aos despus.El resultado de sus esfuerzos es un clsico ejemplo de una implementacin sin arquitectura: La mansin tiene 160 habitaciones, 40 cuartos, 6 cocinas, 2 stanos y 950 puertas. 13. 4Captulo 1: Arquitectura Orientada a Servicios (SOA) De las 950 puertas, 65 abren hacia paredes, 13 escaleras fueron construidas yabandonadas y 24 tragaluces fueron instalados en pisos que no daban al techo. Ningn plano arquitectnico de la mansin fue jams elaborado. Figura 2: La misteriosa mansin WinchesterLa confusin de la arquitectura con la implementacin genera resultados caticos eimpredecibles, al igual que en la misteriosa mansin Winchester. Artculos que tratan deexplicar SOA e inmediatamente saltan a un tutorial para la creacin de Servicios Web, estnbrindando realmente orientacin para la programacin, no para la arquitectura. Esta es unade las muchas razones por las que SOA es tan mal entendido hoy en da - la prisa porpromover arquitecturas de acoplamiento flexible se centra en los rboles y no en el bosque.Los conceptos arquitectnicos 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 travs de una interoperabilidad abierta basada en estndares. Si bien estos estndares sonimportantes, debemos recordar que las especificaciones no son la arquitectura, y laarquitectura no es la implementacin. Al final del da, es la implementacin de unaarquitectura bien diseada la que va a generar beneficios para el negocio, no la propiaarquitectura.SOA es un enfoque arquitectnico para la creacin de sistemas construidos a partir deservicios autnomos. Con SOA, la integracin es previsin en lugar de reflexin a posteriori -es probable que la solucin final se compondr de los servicios desarrollados en diferenteslenguajes de programacin, alojados en distintas plataformas con una variedad de modelosde seguridad y de procesos de negocio. Si bien este concepto suena increblementecomplejo, no es nuevo pudiera decirse que SOA ha evolucionado a partir de lasexperiencias asociadas con el diseo y desarrollo de sistemas distribuidos basados entecnologas ya disponibles. Muchos de los conceptos asociados a SOA, como los servicios, eldescubrimiento y el enlace tardo estaban asociados a CORBA y DCOM. Del mismo modo, lamayora de los principios de diseo de los servicios, tienen mucho en comn con tcnicasanteriores como OOA/OOD basadas en la encapsulacin, la abstraccin y las interfacesclaramente definidas.Significa el bullicio en torno a SOA y los servicios que las TI no fueron orientadas a servicios 14. Captulo 1: Arquitectura Orientada a Servicios (SOA)5en el pasado? No las TI (subcontratadas o no) slo existen para potenciar los negocios. SinTI los negocios tendran enormes dificultades tanto en la ejecucin como en la competencia.Sin embargo, si las TI no pueden responder a las necesidades y oportunidades de negocio losuficientemente rpido, entonces sern 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 filosofa de arquitectura y no necesariamente unconcepto implementable. Muchos analistas y revistas especializadas han confundido a laarquitectura con la implementacin, lo que nos lleva a creer que una aplicacin 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 desafo. SOA, comocualquier iniciativa, debe proporcionar un cierto valor de uso a la organizacin - de lo contrariono servira de nada ni siquiera considerarla. La mejor manera de asegurar que las inversionesen SOA proporcionarn un retorno a la organizacin es alinear SOA con los lderes delnegocio en la organizacin. A pesar de esta evidencia, todava hay mucha confusin 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.MitoHecho SOA es una tecnologa SOA es una filosofa de diseo independiente de cualquier proveedor, producto, tecnologa o tendencia de la industria. Ningn proveedor podr ofrecer una SOA completa porque las necesidades SOA varan de una organizacin a otra. La compra de la infraestructura SOA a un solo proveedor va en contra del propsito de invertir en SOA. SOA requiere de servicios Web Las SOAs pueden ser implementadas a travs 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 deSOA no es una metodologa. las TI con el negocio. Una arquitectura de referenciaLas SOAs son como los copos de nieve no hay dos SOA reduce los riesgos de iguales. Una arquitectura de referencia SOA no tiene implementacinpor qu brindar la mejor solucin para su organizacin. SOA requiere una revisin SOA debe ser incremental y conformarse sobre la completa de la tecnologa y los base de sus inversiones en curso. procesos de negocio. Necesitamos construir una SOA.SOA es un medio, no una meta.Enfquese en ofrecer una solucin, no una SOA. SOA es un medio de suministrar la soluciny no debe ser una meta. 15. 6 Captulo 1: Arquitectura Orientada a Servicios (SOA)La evolucin de SOALa orientacin a servicios (SO) es la evolucin natural de los actuales modelos de desarrollo.Los aos 80, vieron modelos orientados a objetos, y luego vino el modelo de desarrollobasado en componentes en los aos 90, y ahora tenemos la orientacin a servicios. Laorientacin a servicios mantiene los beneficios del desarrollo basado en componentes (laauto-descripcin, la encapsulacin, el descubrimiento y la carga dinmica), pero hay uncambio en el paradigma desde mtodos de objetos invocados remotamente, a uno de pasode mensajes entre los servicios. Los esquemas describen no slo la estructura de losmensajes, sino tambin los contratos de comportamiento para definir patrones deintercambio de mensajes y polticas para definir la semntica de servicios. Esto promueve lainteroperabilidad, y por lo tanto ofrece los beneficios de la adaptacin, ya que los mensajespueden ser enviados desde un servicio a otro sin tener en cuenta cmo ha sido implementadoel servicio de manejo de los mensajes.Figura 3: Comunicaciones simples entre servicios Web basadas en SOAP.La orientacin a servicios proporciona un enfoque evolutivo a la construccin de softwaredistribuido que facilita la integracin 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 ms frecuentementeutilizando los servicios Web estndares, la orientacin a servicios es independiente de latecnologa y los patrones arquitectnicos, y se puede utilizar para conectar con los sistemaslegados.Desafortunadamente, los beneficios ofrecidos por la orientacin a servicios y SOA han sidooscurecidos por el bombo y la confusin que rodean cada vez ms estos trminos. Si bien elconocimiento y el entusiasmo en torno a SOA han aumentado, las lneas claras que una vezdefinieron la orientacin a servicios, se han desdibujado. Sin embargo, SO ofrece algunasventajas especficas cuando se utiliza para el propsito correcto. Hay tres observacionesimportantes sobre SO:1. Es evolutivo: Los principios del desarrollo orientado a servicios se basan en dcadas de experiencia en la construccin de aplicaciones distribuidas del mundo real. SO incorpora conceptos como la auto-descripcin de las aplicaciones, la encapsulacin explcita, y la carga dinmica de las funcionalidades en tiempo de ejecucin principios introducidos por primera vez en las dcadas de 1980 y 1990 a travs del desarrollo orientado a objetos y basado en componentes. Lo que cambia con SO es la metfora con la que los desarrolladores obtienen estos beneficios. En lugar de utilizar la invocacin de mtodos 16. Captulo 1: Arquitectura Orientada a Servicios (SOA)7en un objeto de referencia, la orientacin a servicios cambia la conversacin al paso demensajes - una metfora probada para la integracin escalable de software distribuido.2. No es un producto o tecnologa: 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 encapsulacin son independientes de la tecnologa, tambin lo es la orientacin a servicios. Si bien los servicios Web en los ltimos aos han facilitado el desarrollo de aplicaciones orientadas a servicios, realmente no son imprescindibles para hacerlo.3. Es incremental: Por ltimo, la orientacin a servicios puede y debe ser un proceso gradual - que a menudo se puede hacer en casa. Los clientes no deberan estar obligados a redisear radicalmente sus negocios, para alcanzar los beneficios de la orientacin a servicios. Por el contrario, deberan ser capaces de aprovechar sus activos de TI al hacerlo. El desarrollo orientado a servicios a menudo se puede lograr utilizando las habilidades y tecnologas que ya tenemos hoy en da.El bloque de construccin fundamental de la arquitectura orientada a servicios es el servicio.Un servicio es un programa con el que se puede interactuar a travs del intercambio demensajes bien definidos. Los servicios deben ser diseados de modo que garanticen ladisponibilidad y la estabilidad. Los servicios estn 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 organizacin con procesos de negocio implementados sobre una infraestructura deacoplamiento flexible, es mucho ms abierta a los cambios que una organizacin limitada porlas aplicaciones monolticas subyacentes, que requieren semanas para implementar elcambio ms pequeo. Los sistemas con acoplamiento flexible resultan en procesos denegocio de acoplamiento flexible, ya que los procesos de negocio ya no estn 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 apoyndose en interfacesbasadas en estndares y mensajes bien definidos -por ejemplo, usando SOAP y esquemasXML para la definicin de los mensajes. Los servicios diseados para realizar funcionesgranulares simples, con un conocimiento limitado de cmo los mensajes se transmiten haciao desde estos, son mucho ms propensos a ser reutilizados en una infraestructura SOA.La orientacin a servicios no requiere necesariamente la reescritura de las funciones desdecero. Siguiendo los cuatro principios (ver ms abajo) se pueden reutilizar los activos de las TIexistentes, envolvindolos en servicios modulares que pueden conectarse a cualquierproceso de negocio que usted disee. Las metas para hacer esto deben ser: Conectarse a lo que ya existe - Gestin de la capa de procesos de negocio, flujos detrabajo colaborativos, y reportes sobre los activos de TI existentes. Extraer ms valor de lo que ya existe Permitir que las aplicaciones existentes puedanser reutilizadas en nuevas formas. Extender y evolucionar lo que ya tenemos - Crear soporte de TI para los nuevos procesos 17. 8Captulo 1: Arquitectura Orientada a Servicios (SOA)de negocio inter-funcionales que se extienden ms all de las fronteras determinadas porlo que las aplicaciones existentes se han diseado para hacer.Uno de los beneficios clave de la orientacin a servicios es el acoplamiento flexible. No haydiscusin 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 utilizacin de un recurso slo a travs del serviciopublicado y no direccionando la implementacin subyacente. De esta forma, los cambiosrealizados por el proveedor del servicio en la implementacin no deben afectar al consumidordel servicio. Al mantener una interfaz consistente, el consumidor de un servicio podra elegiruna instancia alternativa del mismo tipo de servicio (por ejemplo, cambiar de proveedor delservicio) sin modificar la aplicacin consumidora excepto en la direccin de la nuevainstancia. El consumidor y el proveedor del servicio no tienen que tener las mismastecnologas para la implementacin, la interfaz, o la integracin, cuando se usan serviciosWeb (aunque ambos estn 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 orientacin a servicios es unmedio para la creacin de aplicaciones dinmicas y colaborativas. Mediante el soporte entiempo de ejecucin de la seleccin de los proveedores, la orientacin a servicios permiteque las aplicaciones sean sensibles al contenido y al contexto de un proceso de negocioespecfico, y a la incorporacin de nuevos proveedores en el tiempo. Para el director de TI, la orientacin a servicios es un medio para la integracin efectivade los diversos sistemas tpicos de los modernos centros de datos empresariales. Alproporcionar un modelo para la agregacin de la informacin y la lgica de negocio demltiples sistemas en una nica interfaz, la orientacin a servicios permite a sistemasdiversos y redundantes, integrarse a travs de un conjunto comn y coherente deinterfaces. Para el CIO (responsable de la informacin), la orientacin a servicios es un medio paraproteger inversiones existentes en TI sin inhibir el despliegue de nuevas capacidades. Alencapsular una aplicacin de negocios detrs de interfaces basadas en capacidades, elmodelo de servicio permite el acceso controlado a aplicaciones 18. 10 Captulo 1: Arquitectura Orientada a Servicios (SOA)adaptarse a nuevos servicios ofrecidos despus del despliegue. La disponibilidad yestabilidad de estos servicios resulta, por tanto, un factor crtico.Entendiendo los serviciosEl primer paso en cualquier proyecto SOA es identificar claramente los problemas crticos oretos del negocio. Mientras ms precisa sea la forma en que estos se definan, ms fcil serdeterminar el alcance y direccin de cada proyecto SOA. Estableciendo una visin claradesde arriba, ser ms fcil contar con la aceptacin de los proyectos que son interfuncionales por naturaleza.Una vez que los gestores de negocio de la organizacin se definen, el proceso de anlisis delos servicios puede comenzar. El anlisis de los servicios es uno de los varios pasos quecomponen el ciclo de vida de los servicios (el captulo 2 ofrece ms informacin acerca delciclo de vida de los servicios). El ciclo de vida de los servicios presenta los pasos que unaorganizacin 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 lneas 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 creacin(exposicin) de nuevos servicios, la agregacin (composicin) de estos servicios enaplicaciones compuestas, y hacer que las salidas estn 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 separacin entre la interfaz y laimplementacin. El invocador de un servicio slo necesita (y solo debe necesitar) conocer lainterfaz, la implementacin puede evolucionar con el tiempo sin afectar a los clientes delservicio. Varios beneficios claves de la orientacin a servicios se derivan de esta abstraccinde 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 aplicacin agregada. En su forma msabstracta, la orientacin a servicios lo ve todo ya sea una aplicacin de mainframe o unaimpresora o un expedidor en un muelle o una compaa de entregas nocturnas - comoproveedores de servicios. El modelo de servicios es fractal: el proceso recin formado estambin un servicio, que expone una nueva capacidad agregada. 19. Captulo 1: Arquitectura Orientada a Servicios (SOA) 11Qu es un servicio? En este libro vamos a evitar el uso del trmino servicio Web,simplemente porque todos los servicios no son necesariamente servicios Web. Un serviciotambin puede manifestarse como un proceso especfico del sistema operativo, por ejemplo,un demonio en Unix o un servicio de Windows. Un servicio tambin pudiera ser unaaplicacin que utiliza un contrato bien definido basado o no en servicios Web.Independientemente de cmo 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 acontinuacin:Los principios del diseo de serviciosEl acrnimo SOA plantea una pregunta obvia - qu es, exactamente, un servicio? En pocaspalabras, un servicio es un programa con el que se puede interactuar a travs del intercambiode mensajes bien definidos. Los servicios deben ser diseados para asegurar disponibilidady estabilidad. La agilidad se promueve a menudo como uno de los mayores beneficios deSOA - una organizacin que ha implementado los procesos de negocio sobre unainfraestructura de acoplamiento flexible es mucho ms abierta a los cambios que unaorganizacin limitada por aplicaciones monolticas subyacentes, que requieren semanaspara implementar el cambio ms insignificante. Los sistemas de acoplamiento flexible derivanen procesos de negocio de acoplamiento flexible, ya que estos ltimos no estn 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 enestndares y mensajes bien definidos - en otras palabras, esquemas SOAP y XML para ladefinicin de los mensajes. Los servicios diseados para realizar funciones granularessimples, con un conocimiento limitado de cmo los mensajes se transmiten hacia o desdeestos, son mucho ms propensos a ser reutilizados en una infraestructura SOA. Como se hadicho anteriormente, recordar los principios bsicos del diseo orientado a objetos conrespecto a la encapsulacin y el diseo de interfaces, nos ser muy til al disear y construirservicios Web reutilizables. Podemos extender estos principios de la orientacin a objetos almundo de los servicios Web con una comprensin profunda de los cuatro principios de laorientacin a servicios.Principio 1: Las fronteras son explcitas.Los servicios interactan a travs del paso de mensajes explcitos a travs de fronteras biendefinidas. El cruce de las fronteras de los servicios puede ser costoso, en dependencia defactores geogrficos, de confianza o de ejecucin. Una frontera representa el lmite entre lainterfaz pblica del servicio y su implementacin interna privada. La frontera de un servicio sepublica a travs 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 continuacin: La ubicacin fsica del servicio puede ser un aspecto desconocido. Es probable que los modelos de seguridad y confianza cambien con cada cruce defrontera. 20. 12 Captulo 1: Arquitectura Orientada a Servicios (SOA)La determinacin de las referencias y el casteado de los datos entre las representaciones pblicas 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 reconfiguracin de la red o la migracin a otra ubicacin fsica.Los consumidores de los servicios generalmente no estn conscientes de cmo 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 patrn de integracin orientado a servicios nos dice que las invocaciones de servicio estnsujetas a la latencia de la red, a fallos en la red, y a los fallos del sistema distribuido, pero unaimplementacin a nivel local no lo est. Debe escribirse una cantidad importante de lgica dedeteccin y correccin de errores para prever las consecuencias del uso de interfaces conobjetos remotos. Aunque debemos asumir que el cruce de fronteras es un proceso costoso,tambin hay que tener cuidado en el despliegue de mtodos locales diseados para reducir almnimo los cruces de frontera. Un sistema que implementa mtodos y objetos localesmonolticos puede ganar en el rendimiento pero duplicar la funcionalidad de un serviciopreviamente definido (esta tcnica se conoce como cortar y pegar en la programacinorientada 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 lmites. Los servicios proporcionan un contrato para definir las interfaces pblicas que ofrecen. Toda la interaccin con el servicio se produce a travs de la interfaz pblica. La interfaz se compone de los procesos pblicos y representaciones pblicas de los datos. El proceso pblico es el punto de entrada en el servicio, mientras que la representacin pblica de los datos est conformada por los mensajes usados por el proceso. Si se utiliza WSDL para representar a un contrato simple, representa los datos pblicos, mientras que representa el (los) proceso (s) pblico (s).Los servicios deben ser fciles de consumir. Al disear un servicio, los desarrolladores deben hacer que sea fcil consumirlo por otros desarrolladores. La interfaz del servicio (contrato) tambin debe disearse para permitir la evolucin del servicio, sin romper los contratos con los consumidores actuales.Evite las interfaces de tipo RPC. El paso de mensajes explcitos debe tener prioridad sobre un modelo RPC. Este enfoque asla al consumidor de las interioridades de la implementacin del servicio, liberando a los desarrolladores de evolucionar sus servicios al mismo tiempo que reducen al mnimo el impacto en los consumidores de los servicios (encapsulado a travs de mensajes pblicos en lugar de los mtodos a disposicin del pblico).Mantenga pequea la superficie del servicio. Mientras ms interfaces pblicas un servicio expone ms difcil ser su consumo y mantenimiento. Proporcione pocas y bien definidas interfaces pblicas a su servicio. Estas interfaces deben ser relativamente simples, diseadas para aceptar un mensaje de entrada bien definido y responder con un mensaje 21. Captulo 1: Arquitectura Orientada a Servicios (SOA)13de salida igualmente bien definido. Una vez que estas interfaces se han diseado debenpermanecer estticas. Estas interfaces proporcionan el requerimiento de diseoconstante que los servicios deben soportar, sirviendo como la cara pblica a laimplementacin interna privada del servicio. Los detalles de la implementacin interna (privada) no deben filtrarse fuera de la fronteradel servicio. Las fugas de detalles de la implementacin a travs de la frontera del serviciotraen como resultado vnculos ms estrechos entre el servicio y los consumidores delservicio. Los consumidores de servicios no debe estar enterados de las interioridades dela implementacin de un servicio, ya que esto limita las opciones para el control deversiones o la mejora del servicio.Principio 2: Los servicios son autnomosLos servicios son entidades que estn desplegados, versionados, y administrados de maneraindependiente. Los desarrolladores deben evitar hacer suposiciones sobre el espacio entrelos lmites del servicio ya que este espacio es mucho ms probable que cambie que laspropias fronteras. Por ejemplo, los lmites del servicio deben ser estticos para minimizar elimpacto del control de versiones para el consumidor. Mientras que los lmites de un servicioson bastante estables, las opciones de implementacin del servicio en relacin con la poltica,la ubicacin fsica o la topologa de la red es probable que cambien.Los servicios se direccionan de forma dinmica a travs de URLs, lo que permite que lalocalizacin subyacente y las topologas de implementacin puedan cambiar o evolucionar enel tiempo con muy poco impacto en el servicio (esto tambin se aplica a los canales decomunicacin 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 da en EEUU se traslada a una reden Nueva Zelanda maana? El cambio en el tiempo de respuesta puede tener efectos noplaneados o inesperados en los consumidores del servicio. Los diseadores de serviciosdeben adoptar una visin pesimista de la forma en que sus servicios sern consumidos - losservicios fallarn y su comportamiento (los niveles de servicio) est sujeto a cambios.Cualquier invocacin de servicio debe tener asociados niveles adecuados de manejo deexcepciones y lgicas de compensacin. Adems, los consumidores de servicios puedentener que modificar sus polticas para declarar los tiempos mnimos 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 poltica configurable permite que un servicio en particular soportemltiples Acuerdos sobre el Nivel de Servicio (SLA) con respecto a la invocacin del servicio(y otras polticas pueden centrarse en las versiones, la localizacin y otras cuestiones). Elintercambio acerca de las expectativas de desempeo a nivel de servicio preserva laautonoma, 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 cmo 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. 14 Captulo 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 polticas de otra ndole necesarias para la interaccin exitosacon el servicio. La implementacin interna del servicio debe tratar de compensar el usoinadecuado, sea cual fuere la intencin del usuario.Si bien los servicios estn diseados para ser autnomos, no hay servicio que sea una isla.Una solucin basada en SOA es fractal, y consiste en una serie de servicios configuradospara garantizar una solucin especfica. Pensando de forma autnoma, nos damos cuentarpidamente 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 atravs de los servicios sea tambin deficiente, pero este es un tema que se sale del alcancede este material). Las claves para la implementacin de servicios autnomos son elaislamiento y la desconexin. Los servicios se disean y despliegan independientementeunos de los otros y slo pueden comunicarse mediante mensajes y polticas establecidascontractualmente.Al igual que con otros principios de diseo de los servicios, podemos aprender de nuestrasexperiencias pasadas con el diseo orientado a objetos. El trabajo de Peter Herzum y OliverSims sobre las fbricas de componentes de negocio, ofrece algunas ideas interesantes sobrela naturaleza de los componentes autnomos. Si bien la mayor parte del trabajo es msapropiado para soluciones basadas en componentes de grano grueso, los principios bsicosde diseo siguen siendo aplicables para el diseo de servicios.Teniendo en cuenta estas consideraciones, he aqu algunos principios de diseo simples queayudan a asegurar el cumplimiento del segundo principio de la orientacin a servicios:Los servicios deben ser desplegados y versionados independientemente del sistema en el que se implementan y consumen.Los contratos deben ser diseados con la premisa de que una vez publicados, no se pueden modificar. Este enfoque obliga a los desarrolladores a introducir flexibilidad en el diseo de sus esquemas.Los servicios deben ser aislados de los fallos mediante la adopcin 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 interaccin de los servicios debe estar basada nicamente enlas polticas, el esquema y el comportamiento basado en contratos. El contrato de un serviciose define generalmente a travs de WSDL, mientras que los contratos para la agregacin deservicios se pueden definir utilizando BPEL (que a su vez utiliza WSDL para cada servicioagregado).La mayora de los desarrolladores define clases para representar las distintas entidadesdentro de un espacio de problemas determinado (por ejemplo, cliente, pedido y producto). 23. Captulo 1: Arquitectura Orientada a Servicios (SOA) 15Las clases combinan el comportamiento y los datos (mensajes) en un nico ensamblado conun lenguaje de programacin o plataforma especfica. Los servicios rompen este modelo paramaximizar la flexibilidad y la interoperabilidad. Los servicios comunicndose a travs demensajes basados en esquemas XML, son agnsticos con respecto al lenguaje deprogramacin 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 travs de WSDL. Capacidades y requisitos definidos con polticas de WS. BPEL puede ser utilizado como un contrato a nivel de procesos de negocio para laagregacin de mltiples 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 diseados lo msexplcitamente 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 difcil de modificar reduciendo al mnimo elimpacto sobre los consumidores de servicios existentes. La lnea entre las representacionesde datos internos y externos es fundamental para el xito del despliegue y la reutilizacin deun servicio determinado. Los datos pblicos (los transmitidos entre los servicios) debenbasarse en estndares organizacionales o verticales, lo que garantiza una amplia aceptacinentre los diferentes servicios. La informacin privada (los datos dentro de un servicio) seencapsula dentro de un servicio.En cierto modo, los servicios son como pequeas representaciones de una organizacin querealiza transacciones de comercio electrnico. Al igual que una organizacin debe mapearuna orden de compra externa a su formato interno, un servicio tambin debe mapear unarepresentacin de los datos basada en un contrato acordado a su formato interno. Una vezms, nuestras experiencias con la encapsulacin de datos orientada a objetos pueden serreutilizadas para ilustrar un concepto similar - la representacin de los datos internos de unservicio slo pueden manipularse a travs del contrato del servicio.Teniendo en cuenta estas consideraciones, he aqu algunas recomendaciones simples dediseo para ayudar a garantizar el cumplimiento del tercer principio de orientacin a servicios: Asegrese que el contrato de un servicio se mantiene estable para minimizar el impactosobre los consumidores del servicio. El contrato se refiere, en este sentido, a larepresentacin pblica de los datos, el patrn de intercambio de mensajes (WSDL) y lascapacidades y niveles de servicio configurables (la poltica). Los contratos deben ser diseados para ser lo ms explcitos que sea posible, y asminimizar las malas interpretaciones. Adems, los contratos deben ser diseados paradar cabida a versiones futuras del servicio a travs de la capacidad de ampliacin, tanto 24. 16Captulo 1: Arquitectura Orientada a Servicios (SOA) de la sintaxis XML como del modelo de procesamiento de SOAP.Evite diluir la lnea entre las representaciones de los datos pblicos y privados. El formato de los datos internos de un servicio debe ser ocultado de los consumidores, mientras que su esquema de datos pblico debe ser inmutable (de preferencia basado en un estndar, 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 polticasSi bien este se considera a menudo el menos entendido de los principios de diseo, es quizsuno de los ms potentes en cuanto a la implementacin de servicios Web flexibles. No esposible comunicar algunos requisitos para la interaccin de los servicios usando solamenteWSDL. Expresiones polticas se pueden utilizar para separar la compatibilidad estructural (loque se comunica) de la compatibilidad semntica (cmo 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 depoltica proporcionan un conjunto configurable de semnticas interoperables que rigen elcomportamiento y las expectativas de un servicio determinado. La especificacin de polticasde WS define una infraestructura de polticas de lectura mecnica capaz de expresar polticasa nivel de servicio, lo que les permite ser descubiertos o mejorados en tiempo de ejecucin.Por ejemplo, un servicio de seguridad del gobierno puede requerir la aplicacin de unapoltica reforzando un nivel de servicio especfico (por ejemplo, las fotos de pasaporte quecumplen con ciertos criterios establecidos deben ser cotejadas con un sistema deidentificacin de terroristas). La informacin de poltica relacionada con este servicio podraser utilizada en una serie de otros escenarios o servicios relacionados con la realizacin deuna verificacin de antecedentes. Las polticas de WS se pueden utilizar para hacer cumplirestos requisitos sin necesidad de una sola lnea de cdigo adicional. Este escenario muestracmo una infraestructura de polticas proporciona informacin adicional acerca de losrequerimientos de un servicio, al mismo tiempo que tambin proporciona un modelo deprogramacin declarativa para la definicin y ejecucin del servicio.Un planteamiento de la poltica identifica un comportamiento que es un requerimiento (ocapacidad) de un tema de poltica. (En el escenario anterior el planteamiento es laverificacin de antecedentes contra el sistema de identificacin de terroristas.) Losplanteamientos proporcionan semnticas de dominio especfico y eventualmente se definirndentro de especificaciones de dominio especfico independientes, para una variedad deindustrias verticales (estableciendo el concepto de infraestructura de polticas de WS).Si bien los servicios gestionados por polticas estn todava en evolucin, los desarrolladoresdeben asegurarse de que sus planteamientos de poltica sean tan explcitos como seaposible con respecto a las expectativas y compatibilidades semnticas de los servicios.Los cuatro principios han sido concebidos principalmente para ayudarle en el diseo ydesarrollo de sus servicios. 25. Captulo 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 estnfamiliarizados con las necesidades estratgicas de la organizacin. La construccin de SOApor SOA, sin hacer referencia al contexto de los negocios es un proyecto sin principios ydirectrices de organizacin. El resultado es una implementacin catica 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 estcompleto, la solucin 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 metodologas dearriba abajo y de abajo arriba. En este enfoque, los esfuerzos de SOA son conducidos por lavisin estratgica y las necesidades de la empresa, y se alcanzan a travs de proyectos SOAincrementales e iterativos que se han diseado para alcanzar los objetivos de negocio unopor uno. Microsoft ha estado utilizando esta tcnica 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 visin holstica estas perspectivas ayudan a comprender los requisitosarquitectnicos subyacentes. Microsoft cree que hay tres capas de capacidades abstractasexpuestas dentro de una SOA. Un ejemplo de estas categoras y las relaciones entre estasaparece a continuacin: Figura 6: Un modelo abstracto de referencia para SOA 26. 18Captulo 1: Arquitectura Orientada a Servicios (SOA)ExposicinLa exposicin se centra en cmo las inversiones en TI existentes se exponen como unconjunto de servicios abiertos y basados en estndares, permitiendo que estas inversionesestn al alcance de un conjunto ms amplio de consumidores. Es probable que lasinversiones existentes estn basadas en un conjunto heterogneo 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 especficos.La creacin de servicios puede ser de grano fino (un servicio se mapea a un nico proceso denegocio), o de grano grueso (mltiples servicios se agrupan para llevar a cabo un conjunto defunciones de negocio afines). La exposicin tambin se ocupa de cmo 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 travs del uso de un adaptador. Una arquitectura de implementacin deservicios describe cmo los servicios se desarrollan, implementan y gestionan.ComposicinUna vez que los servicios se crean, estos se pueden combinar en servicios ms 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 mxima flexibilidad. A medida que los procesos de negocio evolucionan, las reglas y lasprcticas 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 integracin de servicios describe un conjunto de capacidades para lacomposicin de servicios, y otros componentes en ensamblados mayores como pueden serlos procesos de negocio. La composicin de servicios requiere de algn tipo de flujo detrabajo o mecanismo de orquestacin. Microsoft ofrece estas capacidades a travs 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 sontecnologas complementarias diseadas para satisfacer dos necesidades muy diferentes:BTS es un producto con licencia diseado para implementar flujos de trabajo (orquestaciones) a travs de diferentes aplicaciones y plataformas.WF es una infraestructura de desarrollo diseada para exponer capacidades de flujo de trabajo desde una aplicacin. No hay cuotas o restricciones de licencia asociadas con el uso o el despliegue de WF.Examinaremos el flujo de trabajo, la orquestacin y la utilizacin de BizTalk/WF en el Captulo3 (flujos de trabajo y procesos de negocio).ConsumoCuando se crea una nueva aplicacin o proceso de negocio, esa funcionalidad debe ponersedisponible para el acceso (consumo) por los sistemas de TI, por otros servicios y por los 27. Captulo 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 penetracin en el rendimiento del negocio. Losusuarios pueden consumir servicios compuestos a travs de un amplio nmero de puntosde salida incluyendo portales web, aplicaciones cliente de interfaz enriquecida, aplicacionesofimticas (OBA), y dispositivos mviles. 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 inversin (ROI) en una SOA.Una arquitectura de aplicaciones orientadas a servicios describe cmo poner disponiblespara el consumo los servicios compuestos, a travs 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 ofimticas de Microsoft (OBA) soportan la nocin de aplicacin compuesta enlos sistemas transaccionales al mismo tiempo que amplan el alcance de la interaccin delusuario a travs del familiar entorno del Office.Si bien las arquitecturas descritas en los epgrafes exposicin/composicin/consumo puedenser interdependientes, estn diseadas para su acoplamiento flexible. Esto permite que losservicios sean gestionados, versionados y configurados independientemente de la forma enque han sido expuestos. 28. 20Captulo 1: Arquitectura Orientada a Servicios (SOA)Capacidades arquitectnicas 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 lnea denegocios), componerse en flujos de trabajo o procesos de negocio (cada uno de los cualestambin 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 visin 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 diseo 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 razn por la que las seccionesexponer/componer/consumir del modelo pueden ser consideradas como iniciativasarquitectnicas independientes, denominadas respectivamente como arquitectura deimplementacin de servicios (exposicin), arquitectura de integracin de servicios(composicin) y arquitectura de aplicaciones (consumo). Aunque estas arquitecturas hansido diseadas para ser independientes entre s, comparten un conjunto de cinco funcionescomunes. Figura 7: Capacidades arquitectnicas recurrentesMensajes y serviciosMensajes y servicios se centra en cmo se lleva a cabo el intercambio de mensajes entreemisores y receptores. Hay una amplia gama de opciones y modelos disponibles - desdepublicacin/subscripcin y asincrnica, hasta los patrones de interaccin de mensajes yservicios. Los servicios proporcionan un enfoque evolutivo a la construccin de softwaredistribuido que facilita la integracin 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 estndares, la orientacin a servicios es independiente de la tecnologa y lospatrones arquitectnicos, y se puede utilizar tambin para conectarse con los sistemaslegados. Los mensajes y servicios no son un nuevo enfoque en el diseo de software -muchas de las ideas detrs de estos conceptos han existido por aos.Un servicio se implementa generalmente como entidad de software de grano grueso quepuede ser descubierta y que existe como una instancia nica e interacta con las 29. Captulo 1: Arquitectura Orientada a Servicios (SOA) 21aplicaciones 30. 22 Captulo 1: Arquitectura Orientada a Servicios (SOA)Diferencias en la interfaz (por ejemplo, la interfaz ampliada, pero el mismo objeto de negocio).Diferencias semnticas con la misma interfaz (objetos de negocio modificados).Diferencias en la calidad de servicio (por ejemplo, ms lento pero ms barato o muy disponible, pero ms caro).La gestin de servicios incluye muchas capacidades, algunas de las cuales se enumeran acontinuacin:Una solucin completa para la gestin de los cambios y la configuracin, permitiendo a las organizaciones ofrecer a los usuarios software y el servicio de actualizaciones correspondiente de forma rpida y rentable.Reduccin de la complejidad asociada con la gestin de la infraestructura de TI, enfocndose en la disminucin del costo de las operaciones.Servicios centralizados de salva de los archivos modificados en disco. Las copias centralizadas de seguridad deben permitir la recuperacin rpida y fiable desde disco, proporcionando al usuario final la recuperacin sin intervencin del personal de TI.Planificacin de las capacidades previo al despliegue, conjuntamente con una gua de buenas prcticas y conocimientos especficos de hardware, para ayudar a los profesionales de TI en la toma de las mejores decisiones arquitectnicas.Almacenamiento de datos y reportes para ayudar en la toma de decisiones corporativas, mejorar la calidad del servicio prestado, y lograr una mejor administracin de los recursos a travs de capacidades mejoradas de reportes y la integracin de datos provenientes de una amplia variedad de recursos.Soporte para las capacidades arquitectnicas comunesLa plataforma SOA de Microsoft soporta las cinco capacidades arquitectnicas discutidasms arriba. El resto del libro discute estas capacidades en mayor detalle, comenzando conlos mensajes y servicios en el Captulo 2.Figura 8: Capacidades SOA en la plataforma Microsoft 31. Captulo 1: Arquitectura Orientada a Servicios (SOA) 23Las capacidades arquitectnicas comunes y el modelo abstracto dereferencia para SOATambin podemos pensar en estas cinco capacidades arquitectnicas comunes como unconjunto de perspectivas para entender el modelo abstracto de SOA. Las cinco capacidadesarquitectnicas nos ayudan a comprender mejor los desafos asociados con la exposicincomo servicios de las inversiones existentes en TI, la composicin de los servicios en losprocesos empresariales y el consumo de estos procesos en toda la organizacin.ExposicinHabilitacin de los serviciosLa exposicin se centra en cmo disear y exponer nuestros servicios. Lo ms probable esque se comience por exponer las inversiones en TI como servicios Web.A medida que nuestra organizacin madure va a aadir nuevos servicios, lo ms probableque como representantes (proxies) de otros recursos dentro de la organizacin.Una de las partes ms difciles de la implementacin de los servicios es decidir por dndeempezar. Hay una variedad de opciones, y no hay una recomendacin nica que funcionepara todos. La metodologa Motion de Microsoft proporciona una gua para la identificacinde las capacidades empresariales que podran exponerse como servicios.Cules 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 pragmticos. Cortes verticales. Mitigacin de los riesgos. Demostrar los beneficios en iteraciones rpidas. Nuevos enfoques de desarrollo. El xito de los clientes produce el efecto de bola de nieve.Las capacidades arquitectnicas recurrentes nos proporcionan una serie de consideracionesal exponer las inversiones en TI como servicios. Echemos un rpido vistazo a algunas de lasconsideraciones asociadas con cada capacidad para la exposicin de servicios (no es unalista completa):Mensajera y serviciosDeterminar qu exponer y cmo - evite caer en la trampa de la granularidad. Centrarse enla satisfaccin de los requerimientos del negocio.Contrato para la operacin del servicio.Contratos para los mensajes y datos.Configuracin, comportamiento y control. 32. 24 Captulo 1: Arquitectura Orientada a Servicios (SOA) SLAs. Gobernabilidad. Control de versiones. Flujos y procesos Servicios de coordinacin para procesos distribuidos de larga duracin. Servicios de seguimiento capaces de registrar eventos especficos dentro de un flujo. Servicios de compensacin. Datos Servicios de entidades. Servicios de agregacin de entidades: actan como un punto de acceso nico a la informacin que pueda existir en mltiples sistemas. Un servicio de agregacin de entidades tiene las siguientes responsabilidades: Acta como una fuente unificada de entidades. Proporciona una visin integral de la entidad. Proporciona una visin integral del modelo de las entidades las entidades y sus relaciones con otras entidades. Proporciona transparencia con respecto a la ubicacin - los consumidores de la capa de agregacin de entidades no tienen que saber a quin pertenece la informacin. 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 travs de los sistemas - el todo es mejor que la suma de sus partes. Factorizacin de entidades. La MDM (gestin de datos maestros) se centra en la exposicin de los datos a travs de las fronteras corporativas o departamentales. Hablaremos de MDM con mayor detalle en el Captulo 4. Interaccin 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.2En desarrollo web, un mashup es una pgina web o aplicacin que usa y combina datos, presentaciones yfuncionalidad procedentes de una o ms fuentes para crear nuevos servicios. Es tratado ms adelante en eltexto. (Nota del traductor) 33. Captulo 1: Arquitectura Orientada a Servicios (SOA) 25Identidad y accesoGestin de Identidad.Servicios de suplantacin y delegacin de identidad.Subsistema de confianza - Un modelo de subsistema de confianza implica que losservicios son de confianza para realizar tareas especficas, tales como el procesamientode los pedidos de los clientes.Autenticacin (Kerberos, SSL).Control de acceso basado en roles (RBAC).Creacin/revocacin de las relaciones de confianza.Los servicios deben tomar decisiones de autorizacin, como la aprobacin del envo deuna solicitud antes de realizar la transaccin comercial.El servicio debe conocer la identidad del usuario final que enva la solicitud.La necesidad de enrutar la identidad del usuario final es una propiedad inherente delmodelo de delegacin, que no es as para el modelo de subsistema de confianza, y debehacerse un esfuerzo especial para incluir esta caracterstica.Para apoyar la nocin de confianza, como se define en el modelo, los servicios deben sercapaces, al menos, de: Autentificar/verificar la identidad de los servicios. Decidir si el servicio es un subsistema de confianza para funciones especficas(incluida la propagacin de reclamos de identidad). Proteger la integridad de los datos que se trasmiten entre los subsistemas deconfianza y los servicios.Adems de los datos de aplicacin, los datos de las aplicaciones de infraestructura, talescomo los reclamos de identidad del usuario original, tambin deben ser protegidos paraque ningn operador humano en el camino pueda modificar la informacin de identidadque est en trnsito.ComposicinComposicin de serviciosLa composicin se centra en cmo podemos combinar o agregar servicios granulares enprocesos ms complejos. Seguramente vamos a empezar por usar los servicios que exponennuestras actuales inversiones en TI. La composicin de servicios resulta en una nuevainstancia de servicio que el resto de la organizacin puede usar. La composicin ofrececapacidades tales como la invocacin asincrnica correlacionada de servicios, procesos delarga duracin y otras capacidades para la orquestacin de servicios autnomos.Las capacidades arquitectnicas recurrentes nos proporcionan un conjunto deconsideraciones a la hora de componer los servicios granulares en procesos ms complejos.Echemos un rpido vistazo a algunas de las consideraciones asociadas con cada capacidadpara la composicin de los servicios (que no es de ningn modo una lista completa): 34. 26Captulo 1: Arquitectura Orientada a Servicios (SOA) Mensajera y servicios Patrones de interaccin de servicios. Exposicin de las orquestaciones como servicios. Patrones de invocacin asincrnica de servicios. Flujos y procesos Transacciones. Alta frecuencia de cambio. Reglas de negocio. Orquestacin de servicios. Patrones de interaccin de servicios. Externalizacin de procesos. Procesos de larga duracin. Auditora y anlisis. Datos Seguimiento del estado de una instancia de flujo de trabajo determinada. Transformacin de los datos (ETL). Procesamiento y almacenamiento confiable de los datos. Replicacin. Sincronizacin. Repositorio de metadatos y su gestin. Reconciliacin de instancias. Reconciliacin de esquemas. Replicacin de documentos. Sindicacin/Agregacin. Interaccin con el usuario Aplicaciones compuestas (aplicaciones ofimticas). Flujos de trabajo humanos (MOSS). Las orquestaciones invocan flujos de trabajo humanos a travs de un adaptador SharePoint. Definicin de los flujos de trabajo (pageflows). Identidad y acceso Suplantacin y delegacin de identidad. Aprovisionamiento. Sincronizacin del repositorio de identidades. Flujos de aprobacin. 35. Captulo 1: Arquitectura Orientada a Servicios (SOA) 27ConsumoInteraccin con el usuarioEl consumo se centra en cmo 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 organizacinen varias formas: Aplicaciones ligeras basadas en navegadores. Las aplicaciones Web de interfaz enriquecida (RIA) son aplicaciones basadas en unnavegador 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 mquina local (tales como una aplicacin Windows). Aplicaciones empresariales corporativas con extensiones especficas (como el Office deMicrosoft con paneles para actividades especficas) Aplicaciones diseadas para dispositivos mviles. 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 aos 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 mltiples recursos en una interaccincon el usuario integrada. El contenido utilizado por los mashups procede tpicamente de untercero (un servicio o sitio Web) a travs de una interfaz pblica o API. Algunos de losmtodos 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 interaccin con el usuario. Echemos un vistazo a algunas de las consideracionesasociadas con cada capacidad (no pretende ser una lista completa):Mensajera y serviciosConsumo de servicios desde formularios.Web parts3.Registro de servicios check in /check out/bsqueda.AJAX, REST.3Se denomina as a una seccin (ventana) dentro de una pgina Web en los sitios desplegados con latecnologa SharePoint de Microsoft. Representa, desde el punto de vista de la programacin, un controldentro de la interfaz de usuario. (Nota del traductor). 36. 28Captulo 1: Arquitectura Orientada a Servicios (SOA) Flujos y procesos Flujos de trabajo humano (MOSS). Intermediacin de eventos (CAB). Definicin de los flujos de trabajo (pageflows). Datos Entidades (Catlogo de datos en aplicaciones ofimticas). Vista nica del problema del cliente. JSON. Experiencia del usuario Aplicaciones compuestas (aplicaciones ofimticas). Personalizacin, perfiles de usuario. Portales. Inteligencia de negocios. Reportes. Agregacin de contenido. Interacciones con el usuario declarativas. Identidad y acceso Single Sign-On (sincronizacin de contraseas). Identificacin del usuario. Acceso basado en roles (RBAC). Servicios de directorio. Gestin de contraseas. Privacidad (firewalls, cifrado). Conformidad. 37. Captulo 1: Arquitectura Orientada a Servicios (SOA) 29ResumenEn este captulo se han proporcionado algunas analogas tiles para entender la naturalezafractal de SOA. Los servicios son los pilares fundamentales de SOA, aunque los servicios nonecesariamente tienen que ser servicios Web. En el caso ideal, estos servicios siguen loscuatro principios de diseo de los servicios que describen un conjunto de buenas prcticaspara el mbito, las dependencias, las comunicaciones y la configuracin basada en polticasde los servicios. Si bien estos principios se centran en el diseo de servicios, es importantecomprender que los servicios, por s solos, no son necesariamente la arquitectura de lasolucin - Microsoft utiliza un modelo de referencia abstracto para describir los diversosaspectos de la arquitectura SOA. El modelo abstracto de referencia para SOA proporcionatres conceptos fundamentales para ayudar a la mayora de las organizaciones a entender elpapel que pueden desempear los servicios en las arquitecturas de sus soluciones: La exposicin se centra en cmo las inversiones en TI existentes se exponen como unconjunto de servicios generales basados en estndares, permitiendo que estasinversiones estn a disposicin de un amplio conjunto de los consumidores. Laarquitectura de implementacin de servicios describe cmo se desarrollan, implement