![Capítulo 3: Flujos y procesos 65
primero la redacción del documento y segundo su revisión, y la organización indica que una
tarea debe seguir a la otra. Este concepto no es una idea radical. Un código que realiza
llamadas sucesivas a dos subrutinas es un ejemplo válido de este concepto. El interés radica
más bien en las formas que toma esta organización.
Para probar la hipótesis de la plataforma de flujo de trabajo, vamos a considerar una amplia
gama de aplicaciones del mundo real y explorar las características que una plataforma de
flujos de trabajo debe tener si ha de ser útil.
Un proceso de revisión documental toma como parámetro de entrada un conjunto de pares
[revisor, rol] que describen qué humanos están involucrados en el flujo de trabajo y en cuáles
roles. Los valores posibles para el rol son “requerido”, “opcional”, “aprobador final”, y
“propietario”. El proceso de revisión procede entonces hasta que todos los revisores hayan
realizado las funciones asignadas y notifiquen al propietario de los resultados.
Aquí, los elementos de trabajo son las revisiones del documento organizadas por el proceso
de revisión. Hay tres características interesantes que se pueden destacar, múltiples puntos
de interacción, la actividad humana y automatizada, y la necesidad de manejar el cambio
dinámico.
Contratos en los flujos de trabajo
El flujo de trabajo tiene múltiples puntos de interacción, o contratos. En primer lugar, existe un
contrato con un revisor. Este contrato consiste en pedir a un revisor que revise un documento,
aceptando el veredicto y los comentarios de revisión, y también decirle a un revisor que su
entrada ya no es necesaria (si la revisión se cancela, o tal vez si suficientes revisores han
votado afirmativamente). El contrato también podría permitir a un revisor delegar una
revisión. Luego hay un segundo contrato con el responsable de la aprobación final, que es
una especialización del contrato de revisor. En tercer lugar, existe un contrato con el dueño
de la revisión que permite al propietario cancelar la revisión y ser notificado de los resultados
de la revisión. Por último, existe un contrato con el iniciador del proceso de revisión, que crea
la instancia de revisión y suministra los parámetros requeridos.
Es típico de los flujos de trabajo que se conecten a varias partes a través de una variedad de
contratos (ver Figura 3). El flujo de trabajo de revisión de documentos es esencialmente un
coordinador, iniciado a través de un contrato que está coordinando una gran variedad de
participantes a través de uno o más contratos adicionales.
El flujo de trabajo de revisión de documentos guía la actividad humana. Sin embargo, también
podría conducir actividades automatizadas, como guardar versiones del documento en un
repositorio a medida que progresa la revisión. Desde el punto de vista del flujo de trabajo, no
hay diferencia esencial. Un flujo de trabajo puede imaginarse, en general, comunicándose
con servicios mediante contratos. Un caso especial de un servicio es otro flujo de trabajo.
Otro caso especial es un humano. De muchas maneras, un humano es el servicio asíncrono
original: uno nunca sabe si va a responder y cuando.](https://image.slidesharecdn.com/soaintherealworld-traducido-121221135919-phpapp01/85/Soa-in-the-real-world-traducido-77-320.jpg)
![116 Capítulo 4: Datos
entidad en el concentrador MDM actualmente no tiene una clave para la aplicación de
CRM, la clave para la entidad de entrada se agrega a la entidad del concentrador, y la
entidad entrante se transmite como una actualización al flujo de trabajo de aprobación.
4. Si la entrada no se encontró en el concentrador MDM, se pasa al proceso de aprobación
como una inserción. En este punto, los tres flujos convergen de nuevo, y un flujo de
trabajo automatizado comprueba los datos de actualización o inserción para verificar que
cumplen con tod4( )] TJ0696 669.4 Tm[3(t)5(o, )-149(l)] TJET5[( ) 669.4 TmTBT1 0 0 1 Tm[(ent)-2(r)5(an](https://image.slidesharecdn.com/soaintherealworld-traducido-121221135919-phpapp01/85/Soa-in-the-real-world-traducido-128-320.jpg)
Soa in the real world traducido
- 1. i La Arquitectura Orientada a Servicios (SOA) en el Mundo Real John Evdemon Editorial “Capitán San Luis” Traducción: Carlos de Armas García Revisión: Dr. Leonel Iriarte Navarro
- 3. Nota del traductor El desarrollo de la informática facilitará la conexión con la mayor parte del universo de objetos, a través de la denominada Internet de las cosas, la que ofrecerá la capacidad real de interconectar y seguir el movimiento de millones de objetos mediante el empleo del IPV6 y otras tecnologías como RFID. Sin embargo, para poder garantizar el acceso real a la diversidad de objetos físicos, será necesario construir las interfaces estándares que los conviertan en elementos consumibles desde las nuevas aplicaciones. Para lograr dicho propósito, el enfoque orientado a servicios, tratado en este libro, adquiere especial importancia. Este enfoque tiene su base tecnológica en la programación orientada a objetos, donde se dio un importante paso en la reusabilidad del código y la separación de la interfaz con respecto a la implementación. Los modelos Corba y DCOM se propusieron entonces recorrer la última yarda hacia esta meta e introdujeron el concepto de llamada a procedimientos remotos que ha sido uno de los pilares de todo el desarrollo posterior. A partir de todas estas premisas surge SOA, con todas sus bondades para el descubrimiento, la auto descripción y la carga dinámica. Entonces, la reusabilidad se ha transformado en interoperabilidad en entornos totalmente heterogéneos en los cuales, una solución informática puede entonces estar conformada por bloques que residen en equipos distantes con plataformas de hardware que pueden ser distintas y sobre sistemas operativos que pueden ser también diferentes. Microsoft ha trabajado intensamente en el desarrollo de plataformas orientadas a servicios desde la década de los 90 del pasado siglo. En el 2007, después de alcanzar una madurez notable en este enfoque, encomendó la publicación del libro electrónico gratuito “SOA in the Real World”, cuya traducción al castellano presentamos ahora, precisamente teniendo en cuenta la importancia que concedemos a la generalización de estos conceptos entre los desarrolladores de hoy y mañana. El autor del texto, John Evdemon, es un experto en los temas de SOA, BPM y XML, que por el tiempo en que este libro fue publicado, pertenecía al equipo de estrategias en arquitecturas de Microsoft. Actualmente se encuentra involucrado en proyectos de computación en la nube, SOA y arquitecturas orientadas a eventos. El libro está dividido en 6 capítulos. Los dos primeros tienen un carácter introductorio acerca de la tecnología. Estos examinan los principios que Microsoft propone para SOA, introducen el modelo abstracto de referencia para SOA, así como el modelo de madurez SOA (ESOMM), discuten los aspectos relacionados con el ciclo de vida de un servicio, ofrecen la taxonomía de un servicio y describen los escenarios SOA. Los capítulos subsiguientes, tratan diferentes aspectos relacionados con la aplicabilidad del enfoque SOA en el manejo de los flujos de trabajo, los procesos y los datos, así como en la interacción con el usuario, y el control de la identidad y el acceso. Todos los aspectos son conceptualmente tratados de modo general, y luego son contextualizados a través de estudios de casos, que muestran cómo estos aspectos son considerados por los productos y tecnologías de Microsoft, en el mundo real.
- 4. Para la conformación del libro que ponemos ahora en manos del lector, además de la traducción del material original, se han introducido algunos cambios que es necesario comentar. En primer lugar, por la forma en que apareció este trabajo originalmente en Internet, como una serie de artículos, hemos decidido unificar las secciones de agradecimientos y referencias, en apartados únicos al inicio y final del texto, respectivamente. Por otra parte, se ha adicionado un apéndice con un glosario de acrónimos (siglas) al final de los capítulos originales, ya que el contenido se encuentra saturado de este tipo de referencias, y pudiera resultar engorroso al lector la búsqueda por todo el texto de los significados de cada acrónimo, si este solo se mostraba en la primera aparición, como es usual en la literatura técnica. La Habana, diciembre de 2011 Carlos de Armas García
- 5. Agradecimientos del autor La mayor parte del contenido de este libro está tomado de una amplia variedad de fuentes. Parte del contenido es nuevo, mientras que otra parte puede haber aparecido en otros materiales en diferentes formatos. Muchos de los conceptos tratados en el Capítulo 1 se basan en esfuerzos anteriores ya publicados. Queremos agradecer a las siguientes personas por su trabajo en esta área: Don Box (los cuatro principios), John Devadoss (capacidades recurrentes de la arquitectura), y Kris Horrocks (Exposición/Composición/Consumo). El capítulo 2 está conformado a partir del trabajo de los siguientes individuos: Mark Baciak (ciclo de vida), Atanu Bannerjee (OBA), Shy Cohen (Taxonomía), William Oellermann (Modelo de madurez SOA), and Brenton Webster (Caso de estudio). El capítulo 3 está conformado por el trabajo de Dave Green (conceptos, semántica, valor y capacidades, Windows Workflow Foundation) y de John Evdemon (conceptos, términos y manifiesto de flujo). Los conceptos discutidos en el capítulo 4 han sido elaborados a partir de materiales presentados en este mismo espacio1. Queremos agradecer a las siguientes personas por su trabajo en esta área: Roger Wolter (aspectos relacionados con los datos, generalidades de MDM, Arquitectura de los conectores en MDM), Kirk Haselden (MDM). El capítulo 5 se basa en las presentaciones y notas aportadas por Simon Guest. Los conceptos discutidos en el capítulo 6 han sido tomados completamente de esfuerzos anteriores en este mismo espacio. Deseamos agradecer a las siguientes personas por su trabajo en esta área: Kim Cameron (Las leyes de la identidad) y Fred Chong (términos, conceptos y escenarios de identidad federada, y diseño de subsistemas de confianza). 1 Hace referencia a MSDN Blogs, sitio en que apareció originalmente este libro y otros materiales precedentes.
- 7. Tabla de Contenido Capítulo 1: Arquitectura Orientada a Servicios (SOA) .......................1 Guía para el lector .................................................................................................. 1 Introducción a SOA ................................................................................................. 2 El elefante SOA. .............................................................................................................. 2 Una simple definición para SOA ...................................................................................... 3 SOA, Mitos y realidades .................................................................................................. 5 La evolución de SOA ....................................................................................................... 6 ¿Por qué debo estar informado acerca de SOA? ............................................................ 8 Entendiendo los servicios ..................................................................................... 10 Los principios del diseño de servicios ........................................................................... 11 Principio 1: Las fronteras son explícitas. ....................................................................... 11 Principio 2: Los servicios son autónomos...................................................................... 13 Principio 3: Los servicios comparten el esquema y el contrato, no las clases .............. 14 Principio 4: La compatibilidad de los servicios se basa en políticas .............................. 16 Un modelo abstracto de referencia para SOA ...................................................... 17 Exposición ..................................................................................................................... 18 Composición .................................................................................................................. 18 Consumo ....................................................................................................................... 18 Capacidades arquitectónicas recursivas ............................................................... 20 Mensajes y servicios...................................................................................................... 20 Flujos de trabajo y procesos .......................................................................................... 21 Datos ............................................................................................................................. 21 Interacción con el usuario .............................................................................................. 21 Identidad y acceso ......................................................................................................... 21 Gestión .......................................................................................................................... 21 Soporte para las capacidades arquitectónicas comunes .............................................. 22 Las capacidades arquitectónicas comunes y el modelo abstracto de referencia para SOA ...................................................................................................................... 23 Exposición ..................................................................................................................... 23 Composición .................................................................................................................. 25 Consumo ....................................................................................................................... 27 Resumen............................................................................................................... 29 Capítulo 2: Mensajes y Servicios .......................................................31 Guía para el lector ................................................................................................ 31
- 8. Entendiendo los servicios ..................................................................................... 32 Un modelo de madurez de SOA (¿algún otro?) ............................................................ 32 Taxonomía de un servicio ..................................................................................... 36 Servicios de Utilidades .................................................................................................. 38 Servicios de Aplicaciones .............................................................................................. 39 Servicios de Entidades .................................................................................................. 39 Servicios de Capacidades ............................................................................................. 41 Servicios de Actividades ................................................................................................ 43 Servicios de Procesos ................................................................................................... 44 Ciclo de vida de un servicio .................................................................................. 46 Análisis del servicio ....................................................................................................... 46 Desarrollo del servicio ................................................................................................... 46 Verificación del servicio ................................................................................................. 47 Aprovisionamiento del servicio ...................................................................................... 47 Operación del Servicio................................................................................................... 47 Consumo del servicio .................................................................................................... 48 Gestión de los cambios del servicio .............................................................................. 48 Desactivación del servicio ............................................................................................. 48 Escenarios SOA .................................................................................................... 49 Integración de la información......................................................................................... 49 Integración de sistemas heredados ............................................................................... 49 Gobernabilidad de procesos .......................................................................................... 49 Acceso consistente ........................................................................................................ 50 Virtualización de los recursos ........................................................................................ 50 Externalización de procesos .......................................................................................... 50 Otros escenarios............................................................................................................ 50 SOA y el usuario final............................................................................................ 51 ¿Qué son las aplicaciones compuestas? ...................................................................... 53 ¿Qué parece una aplicación compuesta? ..................................................................... 56 Beneficios esperados de la composición y como alcanzarla......................................... 58 Resumen............................................................................................................... 59 Estudio de caso SOA: Banco del Commonwealth en Australia ............................ 60 Capítulo 3: Flujos y procesos .............................................................61 Guía para el lector ................................................................................................ 61 Entendiendo los flujos ........................................................................................... 62 ¿Qué es un flujo? .......................................................................................................... 62 Terminología utilizada en los flujos de trabajo............................................................... 62
- 9. ¿Por qué flujos?............................................................................................................. 63 Un modelo de flujos de trabajo ...................................................................................... 64 Contratos en los flujos de trabajo .................................................................................. 65 Colaboración en la resolución de problemas................................................................. 66 Operaciones de secuencias de comandos .................................................................... 68 Regla y política .............................................................................................................. 69 Valor de la plataforma de flujos de trabajo .................................................................... 71 Explotación más semántica ........................................................................................... 73 Características de la plataforma .................................................................................... 74 Una plataforma común de tiempo ejecución para flujos de trabajo ............................... 75 Atacando los problemas ................................................................................................ 77 Manifiesto de un flujo de trabajo ........................................................................... 78 Agilidad .......................................................................................................................... 78 Abstracción .................................................................................................................... 78 Los flujos de trabajo están en todas partes ................................................................... 79 Los flujos de trabajo son expresivos.............................................................................. 83 Los flujos de trabajo son fluidos .................................................................................... 85 Los flujos de trabajo son inclusivos ............................................................................... 86 Los flujos de trabajo son transparentes ......................................................................... 86 Comprendiendo la relación entre BizTalk Server y WF......................................... 87 Resumen............................................................................................................... 88 Estudio de caso SOA: Grupo Dollar Thrifty Automotive ........................................ 89 Capítulo 4: Datos..................................................................................91 Guía para el lector ................................................................................................ 91 Desafíos que enfrenta SOA en relación con los datos .......................................... 92 Generalidades ............................................................................................................... 92 Aspectos relacionados con la integración de datos ....................................................... 92 Escalabilidad de la Base de Datos ................................................................................ 94 Gestión de Datos Maestros (MDM) ....................................................................... 98 ¿Qué es MDM? ............................................................................................................. 98 Integración de Datos de los Clientes (CDI) ................................................................... 99 Gestión de la Información de Productos (PIM) .............................................................. 99 Arquitectura de concentradores de la Gestión de Datos Maestros (MDM) ................... 99 Estilos de arquitecturas para concentradores ............................................................. 100 Aspectos arquitectónicos ............................................................................................. 104 Versiones y jerarquías ................................................................................................. 105 Población y sincronización .......................................................................................... 110
- 10. Publicación de las actualizaciones .............................................................................. 116 Integridad y confiabilidad de los datos......................................................................... 118 Metadatos .................................................................................................................... 118 Administración y gobernabilidad .................................................................................. 119 Perfilado de los datos .................................................................................................. 120 Exportación .................................................................................................................. 120 Reportería .................................................................................................................... 120 Flujos de trabajo y reglas de negocio .......................................................................... 120 Herramientas ............................................................................................................... 121 Resumen............................................................................................................. 122 Estudio de caso SOA: Bolsa de valores de Londres ........................................... 123 Capítulo 5: Interacción con el usuario .............................................125 Guía para el lector .............................................................................................. 125 ¿Qué es la arquitectura?..................................................................................... 126 Introducción de una plataforma para UX............................................................. 128 Interfaz ......................................................................................................................... 128 Interacción ................................................................................................................... 135 Infraestructura.............................................................................................................. 140 Resumen............................................................................................................. 149 Estudio de caso SOA: Aeropuerto de Zúrich ...................................................... 150 Capítulo 6: Identidad y acceso .........................................................151 Guía para el lector .............................................................................................. 151 Identidad y Acceso .............................................................................................. 152 Generalidades ............................................................................................................. 152 Diseño del subsistema de confianza ................................................................... 154 Prácticas actuales........................................................................................................ 155 Diseño del subsistema de confianza ........................................................................... 160 Extensiones de procesos para el subsistema de confianza ........................................ 162 Políticas del subsistema de confianza ......................................................................... 163 Trasmisión de los reclamos de identidad .................................................................... 164 Mapeo identidad/credencial ......................................................................................... 167 Beneficios del diseño ................................................................................................... 167 Un metasistema de identidad .............................................................................. 169 ¿Qué es el metasistema de identidad? ....................................................................... 169 Las identidades funcionan en contexto ....................................................................... 170
- 11. Las leyes de la identidad ............................................................................................. 171 Roles dentro del metasistema de identidad................................................................. 172 Componentes del metasistema de identidad............................................................... 172 Beneficios del metasistema de Identidad .................................................................... 174 Una arquitectura para el metasistema de identidad: los servicios Web WS-* ............. 175 Implementación del metasistema de identidad............................................................ 176 Resumen............................................................................................................. 179 Estudio de caso SOA: OTTO .............................................................................. 180 Apéndice A. Glosario de acrónimos ................................................181 Referencias .........................................................................................187
- 13. 1 Capítulo 1: Arquitectura Orientada a Servicios (SOA) “Las SOAs son como copos de nieve – no hay dos iguales.” - David Linthicum Consultor Guía para el lector Los lectores de este capítulo aprenderán acerca de algunos de los conceptos generales asociados con la Arquitectura Orientada a Servicios (SOA). El capítulo ofrece varias analogías para la comprensión del concepto de orientado a servicios y algunas recomendaciones de alto nivel para el diseño de servicios. En este capítulo se ofrece un modelo abstracto para describir SOA y se introduce un conjunto de capacidades de la arquitectura que se analizarán en los capítulos siguientes del libro.
- 14. 2 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Introducción a SOA El elefante SOA. SOA se ha convertido en un acrónimo muy conocido y además algo polémico. Si uno pide a dos personas una definición de SOA, es probable que reciba dos respuestas muy diferentes, posiblemente en conflicto. Algunos describen a SOA como una infraestructura de TI (tecnologías de la información) para la implementación del negocio, mientras que otros ven a SOA como la vía para aumentar la eficiencia de las TI. En muchos sentidos, SOA es un poco como el poema de John Godfrey Saxe sobre los ciegos y el elefante. Seis hombres ciegos de Indostán encuentran un elefante. Cada uno de los hombres, a continuación, describe al elefante de una manera ligeramente diferente, ya que están influenciados por sus experiencias personales: El hombre que toca la trompa cree que es una serpiente. El hombre que toca un colmillo cree que es una lanza. El hombre que toca la oreja cree que el elefante es un abanico. El hombre que toca el dorso del elefante cree que es una pared. El hombre que toca la cola cree que es una cuerda. El hombre que toca las patas cree que son árboles. Figura 1: Elefante de Saxe Los ciegos entonces se enzarzan en una serie de debates acerca de lo que creen estar enfrentando: “…¡Y así estos hombres de Indostán discutieron largo y tendido, cada uno con su propia opinión excediéndose en fuerza y tesón, aunque cada uno estaba parcialmente en lo cierto, y todos estaban equivocados!” En muchos sentidos, el poema de Saxe se ha convertido en una profecía para SOA. Analistas
- 15. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 3 del sector, expertos, blogeros y reporteros se enfrentan unos con otros en un proceso continuo e interminable acerca de lo que es o no es SOA. Como los ciegos de Saxe, la gente ha identificado correctamente muchas de las capacidades de SOA, pero la mayoría no es capaz de expresar el concepto como un todo. El reto de la definición de SOA se ha vuelto tan importante que diversos fabricantes y organizaciones de normalización han lanzado iniciativas para tratar de responder a la pregunta: ¿Qué es SOA? Una simple definición para SOA Para los propósitos de este libro definiremos SOA como: Una arquitectura de acoplamiento flexible diseñada para satisfacer las necesidades de negocio de la organización. A primera vista, esta definición parece demasiado simplista – ¿dónde se metieron SOAP, los servicios Web, WSDL, WS-* y otros estándares asociados? SOA no requiere necesariamente del uso de servicios Web – los servicios Web son, para la mayoría de las organizaciones, el enfoque más simple para implementar una arquitectura de acoplamiento flexible. En el pasado, las arquitecturas de acoplamiento flexible se han basado en otras tecnologías como CORBA y DCOM, o en enfoques basados en documentos como EDI, para la integración B2B. Muchas de estas tecnologías tienen todavía un uso bastante generalizado y se han ampliado, sustituido o extendido con los servicios Web. Nuestra definición funciona, no porque el foco no está en la tecnología SOA, sino porque tiene en cuenta las necesidades de la organización. En términos más simples, la SOA de una organización puede parecerle a otra nada más que un montón de Servicios Web (u otras tecnologías). Puede haber algunas capacidades de la infraestructura comunes, como el registro y la autenticación, pero en la mayor parte de los casos la arquitectura SOA de una organización, será muy diferente de la SOA utilizada por otra. Muchos analistas y expertos de la industria han confundido el concepto de arquitectura orientada a servicios con implementaciones orientadas a servicios. Esto sólo ha añadido más confusión a la asociada con SOA y sus conceptos afines y puede llevar a resultados desastrosos. La misteriosa mansión Winchester, enclavada cerca de San José, California, es una atracción turística muy interesante en los EE.UU. La mansión fue el hogar de la heredera de la fortuna de Winchester (acumulada por la venta de los rifles Winchester). Según la leyenda, la heredera fue a ver a un adivino y supo que estaba condenada a ser perseguida por los espíritus de aquellas personas, de todo el mundo, asesinadas por un rifle Winchester. La única manera de evitar la maldición era construir una mansión, y mientras se mantuviera construyéndola los espíritus la dejarían en paz. La mujer contrató rápidamente a 147 constructores (y ningún arquitecto), todos los cuales comenzaron a trabajar en la mansión de forma simultánea. Los constructores trabajaron en la mansión hasta que la heredera falleció, 38 años después. El resultado de sus esfuerzos es un clásico ejemplo de una implementación sin arquitectura: La mansión tiene 160 habitaciones, 40 cuartos, 6 cocinas, 2 sótanos y 950 puertas.
- 16. 4 Capítulo 1: Arquitectura Orientada a Servicios (SOA) De las 950 puertas, 65 abren hacia paredes, 13 escaleras fueron construidas y abandonadas y 24 tragaluces fueron instalados en pisos que no daban al techo. Ningún plano arquitectónico de la mansión fue jamás elaborado. Figura 2: La misteriosa mansión Winchester La confusión de la arquitectura con la implementación genera resultados caóticos e impredecibles, al igual que en la misteriosa mansión Winchester. Artículos que tratan de explicar SOA e inmediatamente saltan a un tutorial para la creación de Servicios Web, están brindando realmente orientación para la programación, no para la arquitectura. Esta es una de las muchas razones por las que SOA es tan mal entendido hoy en día - la prisa por promover arquitecturas de acoplamiento flexible se centra en los árboles y no en el bosque. Los conceptos arquitectónicos asociados a SOA no son nuevos - muchos han evolucionado a partir de ideas introducidas originalmente por CORBA, DCOM, DCE y otras. A diferencia de estas iniciativas previas, la promesa esencial de SOA es permitir procesos de negocio ágiles a través de una interoperabilidad abierta basada en estándares. Si bien estos estándares son importantes, debemos recordar que las especificaciones no son la arquitectura, y la arquitectura no es la implementación. Al final del día, es la implementación de una arquitectura bien diseñada la que va a generar beneficios para el negocio, no la propia arquitectura. SOA es un enfoque arquitectónico para la creación de sistemas construidos a partir de servicios autónomos. Con SOA, la integración es previsión en lugar de reflexión a posteriori - es probable que la solución final se compondrá de los servicios desarrollados en diferentes lenguajes de programación, alojados en distintas plataformas con una variedad de modelos de seguridad y de procesos de negocio. Si bien este concepto suena increíblemente complejo, no es nuevo – pudiera decirse que SOA ha evolucionado a partir de las experiencias asociadas con el diseño y desarrollo de sistemas distribuidos basados en tecnologías ya disponibles. Muchos de los conceptos asociados a SOA, como los servicios, el descubrimiento y el enlace tardío estaban asociados a CORBA y DCOM. Del mismo modo, la mayoría de los principios de diseño de los servicios, tienen mucho en común con técnicas anteriores como OOA/OOD basadas en la encapsulación, la abstracción y las interfaces claramente definidas. ¿Significa el bullicio en torno a SOA y los servicios que las TI no fueron orientadas a servicios
- 17. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 5 en el pasado? No – las TI (subcontratadas o no) sólo existen para potenciar los negocios. Sin TI los negocios tendrían enormes dificultades tanto en la ejecución como en la competencia. Sin embargo, si las TI no pueden responder a las necesidades y oportunidades de negocio lo suficientemente rápido, entonces serán percibidas como un limitante de la empresa en lugar de un facilitador. SOA promete ayudar a las TI a responder a las condiciones del mercado de manera oportuna. SOA, sin embargo, es una filosofía de arquitectura y no necesariamente un concepto implementable. Muchos analistas y revistas especializadas han confundido a la arquitectura con la implementación, lo que nos lleva a creer que una aplicación es, de hecho, una arquitectura, y esto puede conducir a resultados desastrosos. Las organizaciones tienen diferentes requerimientos y expectativas con respecto a SOA dadas las enormes diferencias en cuanto a sus necesidades de negocio y metas. Este simple hecho es una de las razones por las que describir a SOA es un gran desafío. SOA, como cualquier iniciativa, debe proporcionar un cierto valor de uso a la organización - de lo contrario no serviría de nada ni siquiera considerarla. La mejor manera de asegurar que las inversiones en SOA proporcionarán un retorno a la organización es alinear SOA con los líderes del negocio en la organización. A pesar de esta evidencia, todavía hay mucha confusión acerca de SOA. SOA, mitos y realidades Hay varios mitos relacionados con SOA que es muy importante comprender antes de continuar penetrando en ella. La siguiente tabla describe algunos de los mitos de SOA y los hechos que permiten desenmascararlos. Mito Hecho SOA es una tecnología SOA es una filosofía de diseño independiente de cualquier proveedor, producto, tecnología o tendencia de la industria. Ningún proveedor podrá ofrecer una SOA completa porque las necesidades SOA varían de una organización a otra. La compra de la infraestructura SOA a un solo proveedor va en contra del propósito de invertir en SOA. SOA requiere de servicios Web Las SOAs pueden ser implementadas a través de servicios Web, pero los servicios Web no se requieren necesariamente para implementar SOA. SOA es nueva y revolucionaria EDI, CORBA y DCOM son ejemplos conceptuales de SOA. SOA asegura el alineamiento de SOA no es una metodología. las TI con el negocio. Una arquitectura de referencia Las SOAs son como los copos de nieve – no hay dos SOA reduce los riesgos de iguales. Una arquitectura de referencia SOA no tiene implementación por qué brindar la mejor solución para su organización. SOA requiere una revisión SOA debe ser incremental y conformarse sobre la completa de la tecnología y los base de sus inversiones en curso. procesos de negocio. Necesitamos construir una SOA. SOA es un medio, no una meta. Enfóquese en ofrecer una solución, no una SOA. SOA es un medio de suministrar la solución y no debe ser una meta.
- 18. 6 Capítulo 1: Arquitectura Orientada a Servicios (SOA) La evolución de SOA La orientación a servicios (SO) es la evolución natural de los actuales modelos de desarrollo. Los años 80, vieron modelos orientados a objetos, y luego vino el modelo de desarrollo basado en componentes en los años 90, y ahora tenemos la orientación a servicios. La orientación a servicios mantiene los beneficios del desarrollo basado en componentes (la auto-descripción, la encapsulación, el descubrimiento y la carga dinámica), pero hay un cambio en el paradigma desde métodos de objetos invocados remotamente, a uno de paso de mensajes entre los servicios. Los esquemas describen no sólo la estructura de los mensajes, sino también los contratos de comportamiento para definir patrones de intercambio de mensajes y políticas para definir la semántica de servicios. Esto promueve la interoperabilidad, y por lo tanto ofrece los beneficios de la adaptación, ya que los mensajes pueden ser enviados desde un servicio a otro sin tener en cuenta cómo ha sido implementado el servicio de manejo de los mensajes. Figura 3: Comunicaciones simples entre servicios Web basadas en SOAP. La orientación a servicios proporciona un enfoque evolutivo a la construcción de software distribuido que facilita la integración del acoplamiento flexible con la resistencia al cambio. Con la llegada de los servicios Web WS-*, la arquitectura ha hecho viable el desarrollo de software orientado a servicios, en virtud de la avalancha de herramientas de desarrollo de apoyo, y la interoperabilidad de todo el sector. Aunque implementadas más frecuentemente utilizando los servicios Web estándares, la orientación a servicios es independiente de la tecnología y los patrones arquitectónicos, y se puede utilizar para conectar con los sistemas legados. Desafortunadamente, los beneficios ofrecidos por la orientación a servicios y SOA han sido oscurecidos por el bombo y la confusión que rodean cada vez más estos términos. Si bien el conocimiento y el entusiasmo en torno a SOA han aumentado, las líneas claras que una vez definieron la orientación a servicios, se han desdibujado. Sin embargo, SO ofrece algunas ventajas específicas cuando se utiliza para el propósito correcto. Hay tres observaciones importantes sobre SO: 1. Es evolutivo: Los principios del desarrollo orientado a servicios se basan en décadas de experiencia en la construcción de aplicaciones distribuidas del mundo real. SO incorpora conceptos como la auto-descripción de las aplicaciones, la encapsulación explícita, y la carga dinámica de las funcionalidades en tiempo de ejecución – principios introducidos por primera vez en las décadas de 1980 y 1990 a través del desarrollo orientado a objetos y basado en componentes. Lo que cambia con SO es la metáfora con la que los desarrolladores obtienen estos beneficios. En lugar de utilizar la invocación de métodos
- 19. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 7 en un objeto de referencia, la orientación a servicios cambia la conversación al paso de mensajes - una metáfora probada para la integración escalable de software distribuido. 2. No es un producto o tecnología: Se trata de un conjunto de principios de arquitectura expresados independientemente de cualquier producto. De la misma forma que conceptos de desarrollo como el polimorfismo y la encapsulación son independientes de la tecnología, también lo es la orientación a servicios. Si bien los servicios Web en los últimos años han facilitado el desarrollo de aplicaciones orientadas a servicios, realmente no son imprescindibles para hacerlo. 3. Es incremental: Por último, la orientación a servicios puede y debe ser un proceso gradual - que a menudo se puede hacer en casa. Los clientes no deberían estar obligados a rediseñar radicalmente sus negocios, para alcanzar los beneficios de la orientación a servicios. Por el contrario, deberían ser capaces de aprovechar sus activos de TI al hacerlo. El desarrollo orientado a servicios a menudo se puede lograr utilizando las habilidades y tecnologías que ya tenemos hoy en día. El bloque de construcción fundamental de la arquitectura orientada a servicios es el servicio. Un servicio es un programa con el que se puede interactuar a través del intercambio de mensajes bien definidos. Los servicios deben ser diseñados de modo que garanticen la disponibilidad y la estabilidad. Los servicios están construidos para durar mientras las configuraciones y las agregaciones de servicios no cambien. La agilidad se promueve a menudo como uno de los mayores beneficios de SOA; en efecto, una organización con procesos de negocio implementados sobre una infraestructura de acoplamiento flexible, es mucho más abierta a los cambios que una organización limitada por las aplicaciones monolíticas subyacentes, que requieren semanas para implementar el cambio más pequeño. Los sistemas con acoplamiento flexible resultan en procesos de negocio de acoplamiento flexible, ya que los procesos de negocio ya no están restringidos por las limitaciones de la infraestructura subyacente. Los servicios y sus interfaces asociadas deben permanecer estables, lo que les permite volver a ser configurados o re-agregados para satisfacer las necesidades siempre cambiantes de los negocios. Los servicios se mantienen estables apoyándose en interfaces basadas en estándares y mensajes bien definidos -por ejemplo, usando SOAP y esquemas XML para la definición de los mensajes. Los servicios diseñados para realizar funciones granulares simples, con un conocimiento limitado de cómo los mensajes se transmiten hacia o desde estos, son mucho más propensos a ser reutilizados en una infraestructura SOA. La orientación a servicios no requiere necesariamente la reescritura de las funciones desde cero. Siguiendo los cuatro principios (ver más abajo) se pueden reutilizar los activos de las TI existentes, envolviéndolos en servicios modulares que pueden conectarse a cualquier proceso de negocio que usted diseñe. Las metas para hacer esto deben ser: Conectarse a lo que ya existe - Gestión de la capa de procesos de negocio, flujos de trabajo colaborativos, y reportes sobre los activos de TI existentes. Extraer más valor de lo que ya existe – Permitir que las aplicaciones existentes puedan ser reutilizadas en nuevas formas. Extender y evolucionar lo que ya tenemos - Crear soporte de TI para los nuevos procesos
- 20. 8 Capítulo 1: Arquitectura Orientada a Servicios (SOA) de negocio inter-funcionales que se extienden más allá de las fronteras determinadas por lo que las aplicaciones existentes se han diseñado para hacer. Uno de los beneficios clave de la orientación a servicios es el acoplamiento flexible. No hay discusión de los servicios Web que sea completa sin una referencia a las ventajas del acoplamiento flexible de los extremos (aplicaciones) facilitado por el uso de protocolos para los servicios Web. El principio radica en la utilización de un recurso sólo a través del servicio publicado y no direccionando la implementación subyacente. De esta forma, los cambios realizados por el proveedor del servicio en la implementación no deben afectar al consumidor del servicio. Al mantener una interfaz consistente, el consumidor de un servicio podría elegir una instancia alternativa del mismo tipo de servicio (por ejemplo, cambiar de proveedor del servicio) sin modificar la aplicación consumidora excepto en la dirección de la nueva instancia. El consumidor y el proveedor del servicio no tienen que tener las mismas tecnologías para la implementación, la interfaz, o la integración, cuando se usan servicios Web (aunque ambos están obligados a utilizar los mismos protocolos para el servicio Web). ¿Por qué debo estar informado acerca de SOA? La Arquitectura Orientada a Servicios (SOA) es importante para diferentes roles: Para los desarrolladores y arquitectos de soluciones, la orientación a servicios es un medio para la creación de aplicaciones dinámicas y colaborativas. Mediante el soporte en tiempo de ejecución de la selección de los proveedores, la orientación a servicios permite que las aplicaciones sean sensibles al contenido y al contexto de un proceso de negocio específico, y a la incorporación de nuevos proveedores en el tiempo. Para el director de TI, la orientación a servicios es un medio para la integración efectiva de los diversos sistemas típicos de los modernos centros de datos empresariales. Al proporcionar un modelo para la agregación de la información y la lógica de negocio de múltiples sistemas en una única interfaz, la orientación a servicios permite a sistemas diversos y redundantes, integrarse a través de un conjunto común y coherente de interfaces. Para el CIO (responsable de la información), la orientación a servicios es un medio para proteger inversiones existentes en TI sin inhibir el despliegue de nuevas capacidades. Al encapsular una aplicación de negocios detrás de interfaces basadas en capacidades, el modelo de servicio permite el acceso controlado a aplicaciones
- 22. 10 Capítulo 1: Arquitectura Orientada a Servicios (SOA) adaptarse a nuevos servicios ofrecidos después del despliegue. La disponibilidad y estabilidad de estos servicios resulta, por tanto, un factor crítico. Entendiendo los servicios El primer paso en cualquier proyecto SOA es identificar claramente los problemas críticos o retos del negocio. Mientras más precisa sea la forma en que estos se definan, más fácil será determinar el alcance y dirección de cada proyecto SOA. Estableciendo una visión clara desde arriba, será más fácil contar con la aceptación de los proyectos que son inter funcionales por naturaleza. Una vez que los gestores de negocio de la organización se definen, el proceso de análisis de los servicios puede comenzar. El análisis de los servicios es uno de los varios pasos que componen el ciclo de vida de los servicios (el capítulo 2 ofrece más información acerca del ciclo de vida de los servicios). El ciclo de vida de los servicios presenta los pasos que una organización debe seguir para definir, desarrollar, desplegar y operar un servicio. Los servicios son usados muchas veces para exponer inversiones en TI tales como sistemas legados y aplicaciones de líneas de negocio. Los servicios pueden ser ensamblados (o compuestos) dentro de los procesos de negocio, y quedar disponibles para el consumo por los usuarios, sistemas u otros servicios. El proceso es un ciclo iterativo de creación (“exposición”) de nuevos servicios, la agregación (“composición”) de estos servicios en aplicaciones compuestas, y hacer que las salidas estén disponibles para su consumo por el usuario. Figura 5: Un enfoque incremental de SOA, orientado a los negocios. Fundamental para el modelo de servicio es la separación entre la interfaz y la implementación. El invocador de un servicio sólo necesita (y solo debe necesitar) conocer la interfaz, la implementación puede evolucionar con el tiempo sin afectar a los clientes del servicio. Varios beneficios claves de la orientación a servicios se derivan de esta abstracción de la capacidad con respecto a la forma en que la capacidad se ofrece. Esto significa que, la misma interfaz puede ser ofrecida por muchas implementaciones, o por el contrario, que las implementaciones pueden cambiar sin afectar a la aplicación agregada. En su forma más abstracta, la orientación a servicios lo ve todo – ya sea una aplicación de mainframe o una impresora o un expedidor en un muelle o una compañía de entregas nocturnas - como proveedores de servicios. El modelo de servicios es “fractal”: el proceso recién formado es también un servicio, que expone una nueva capacidad agregada.
- 23. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 11 ¿Qué es un servicio? En este libro vamos a evitar el uso del término “servicio Web”, simplemente porque todos los servicios no son necesariamente servicios Web. Un servicio también puede manifestarse como un proceso específico del sistema operativo, por ejemplo, un demonio en Unix o un servicio de Windows. Un servicio también pudiera ser una aplicación que utiliza un contrato bien definido basado o no en servicios Web. Independientemente de cómo un servicio dado se desarrolle, debe ser capaz de participar en una arquitectura de acoplamiento flexible. Hay cuatro principios que pueden ayudar a conformar una arquitectura de acoplamiento flexible. Estos principios se definen a continuación: Los principios del diseño de servicios El acrónimo SOA plantea una pregunta obvia - ¿qué es, exactamente, un servicio? En pocas palabras, un servicio es un programa con el que se puede interactuar a través del intercambio de mensajes bien definidos. Los servicios deben ser diseñados para asegurar disponibilidad y estabilidad. La agilidad se promueve a menudo como uno de los mayores beneficios de SOA - una organización que ha implementado los procesos de negocio sobre una infraestructura de acoplamiento flexible es mucho más abierta a los cambios que una organización limitada por aplicaciones monolíticas subyacentes, que requieren semanas para implementar el cambio más insignificante. Los sistemas de acoplamiento flexible derivan en procesos de negocio de acoplamiento flexible, ya que estos últimos no están limitados por las restricciones de la infraestructura subyacente. Los servicios y sus interfaces asociadas deben permanecer estables, posibilitando que sean reconfigurados o agregados para satisfacer las necesidades siempre cambiantes de los negocios. Los servicios se mantienen estables cuando responden a interfaces basadas en estándares y mensajes bien definidos - en otras palabras, esquemas SOAP y XML para la definición de los mensajes. Los servicios diseñados para realizar funciones granulares simples, con un conocimiento limitado de cómo los mensajes se transmiten hacia o desde estos, son mucho más propensos a ser reutilizados en una infraestructura SOA. Como se ha dicho anteriormente, recordar los principios básicos del diseño orientado a objetos con respecto a la encapsulación y el diseño de interfaces, nos será muy útil al diseñar y construir servicios Web reutilizables. Podemos extender estos principios de la orientación a objetos al mundo de los servicios Web con una comprensión profunda de los “cuatro principios” de la orientación a servicios. Principio 1: Las fronteras son explícitas. Los servicios interactúan a través del paso de mensajes explícitos a través de fronteras bien definidas. El cruce de las fronteras de los servicios puede ser costoso, en dependencia de factores geográficos, de confianza o de ejecución. Una frontera representa el límite entre la interfaz pública del servicio y su implementación interna privada. La frontera de un servicio se publica a través de WSDL y puede incluir formulaciones que establezcan las expectativas del servicio. Se supone que el cruce de las fronteras es una tarea costosa por varias razones, algunas de las cuales se enumeran a continuación: La ubicación física del servicio puede ser un aspecto desconocido. Es probable que los modelos de seguridad y confianza cambien con cada cruce de frontera.
- 24. 12 Capítulo 1: Arquitectura Orientada a Servicios (SOA) La determinación de las referencias y el casteado de los datos entre las representaciones públicas y privadas de un servicio pueden requerir apoyarse en recursos adicionales - algunos de los cuales pueden ser externos al propio servicio. Mientras que los servicios se construyen para durar, las configuraciones de los servicios se preparan para el cambio. Este hecho implica que un servicio confiable de repente puede experimentar degradaciones de rendimiento debido a la reconfiguración de la red o la migración a otra ubicación física. Los consumidores de los servicios generalmente no están conscientes de cómo han sido implementados los procesos internos privados. El consumidor de un determinado servicio tiene un control limitado sobre el rendimiento de los servicios que consume. El patrón de integración orientado a servicios nos dice que “las invocaciones de servicio están sujetas a la latencia de la red, a fallos en la red, y a los fallos del sistema distribuido, pero una implementación a nivel local no lo está. Debe escribirse una cantidad importante de lógica de detección y corrección de errores para prever las consecuencias del uso de interfaces con objetos remotos”. Aunque debemos asumir que el cruce de fronteras es un proceso costoso, también hay que tener cuidado en el despliegue de métodos locales diseñados para reducir al mínimo los cruces de frontera. Un sistema que implementa métodos y objetos locales monolíticos puede ganar en el rendimiento pero duplicar la funcionalidad de un servicio previamente definido (esta técnica se conoce como “cortar y pegar” en la programación orientada a objetos y comparte los mismos riesgos que el versionado del servicio). Hay varias cuestiones a tener en cuenta con respecto al primer principio de SO: Conozca sus límites. Los servicios proporcionan un contrato para definir las interfaces públicas que ofrecen. Toda la interacción con el servicio se produce a través de la interfaz pública. La interfaz se compone de los procesos públicos y representaciones públicas de los datos. El proceso público es el punto de entrada en el servicio, mientras que la representación pública de los datos está conformada por los mensajes usados por el proceso. Si se utiliza WSDL para representar a un contrato simple, <message> representa los datos públicos, mientras que <portType> representa el (los) proceso (s) público (s). Los servicios deben ser fáciles de consumir. Al diseñar un servicio, los desarrolladores deben hacer que sea fácil consumirlo por otros desarrolladores. La interfaz del servicio (contrato) también debe diseñarse para permitir la evolución del servicio, sin romper los contratos con los consumidores actuales. Evite las interfaces de tipo RPC. El paso de mensajes explícitos debe tener prioridad sobre un modelo RPC. Este enfoque aísla al consumidor de las interioridades de la implementación del servicio, liberando a los desarrolladores de evolucionar sus servicios al mismo tiempo que reducen al mínimo el impacto en los consumidores de los servicios (encapsulado a través de mensajes públicos en lugar de los métodos a disposición del público). Mantenga pequeña la superficie del servicio. Mientras más interfaces públicas un servicio expone más difícil será su consumo y mantenimiento. Proporcione pocas y bien definidas interfaces públicas a su servicio. Estas interfaces deben ser relativamente simples, diseñadas para aceptar un mensaje de entrada bien definido y responder con un mensaje
- 25. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 13 de salida igualmente bien definido. Una vez que estas interfaces se han diseñado deben permanecer estáticas. Estas interfaces proporcionan el requerimiento de diseño “constante” que los servicios deben soportar, sirviendo como la cara pública a la implementación interna privada del servicio. Los detalles de la implementación interna (privada) no deben filtrarse fuera de la frontera del servicio. Las fugas de detalles de la implementación a través de la frontera del servicio traen como resultado vínculos más estrechos entre el servicio y los consumidores del servicio. Los consumidores de servicios no debe estar enterados de las interioridades de la implementación de un servicio, ya que esto limita las opciones para el control de versiones o la mejora del servicio. Principio 2: Los servicios son autónomos Los servicios son entidades que están desplegados, versionados, y administrados de manera independiente. Los desarrolladores deben evitar hacer suposiciones sobre el espacio entre los límites del servicio ya que este espacio es mucho más probable que cambie que las propias fronteras. Por ejemplo, los límites del servicio deben ser estáticos para minimizar el impacto del control de versiones para el consumidor. Mientras que los límites de un servicio son bastante estables, las opciones de implementación del servicio en relación con la política, la ubicación física o la topología de la red es probable que cambien. Los servicios se direccionan de forma dinámica a través de URLs, lo que permite que la localización subyacente y las topologías de implementación puedan cambiar o evolucionar en el tiempo con muy poco impacto en el servicio (esto también se aplica a los canales de comunicación de un servicio). Si bien estos cambios pueden tener poco impacto sobre el servicio, pueden tener un impacto devastador sobre las aplicaciones que consumen el servicio. ¿Qué sucede si un servicio que se utiliza hoy en día en EEUU se traslada a una red en Nueva Zelanda mañana? El cambio en el tiempo de respuesta puede tener efectos no planeados o inesperados en los consumidores del servicio. Los diseñadores de servicios deben adoptar una visión pesimista de la forma en que sus servicios serán consumidos - los servicios fallarán y su comportamiento (los niveles de servicio) está sujeto a cambios. Cualquier invocación de servicio debe tener asociados niveles adecuados de manejo de excepciones y lógicas de compensación. Además, los consumidores de servicios pueden tener que modificar sus políticas para declarar los tiempos mínimos de respuesta de los servicios que consumen. Por ejemplo, los consumidores de un servicio pueden requerir diferentes niveles de servicio en materia de seguridad, rendimiento, transacciones, y muchos otros factores. Una política configurable permite que un servicio en particular soporte múltiples Acuerdos sobre el Nivel de Servicio (SLA) con respecto a la invocación del servicio (y otras políticas pueden centrarse en las versiones, la localización y otras cuestiones). El intercambio acerca de las expectativas de desempeño a nivel de servicio preserva la autonomía, ya que los servicios no tienen que estar familiarizados con las implementaciones internas de los otros servicios. Los consumidores de servicios no son los únicos que deben adoptar visiones pesimistas acerca del rendimiento - los proveedores de los servicios deben ser igualmente pesimistas al estimar cómo sus servicios van a ser consumidos. Debe esperarse que los consumidores de los servicios fallen, a veces sin avisar al servicio. Los proveedores de servicios no pueden
- 26. 14 Capítulo 1: Arquitectura Orientada a Servicios (SOA) confiar en que los consumidores “hacen las cosas correctamente”. Por ejemplo, los consumidores pueden tratar de comunicarse mediante mensajes mal conformados o maliciosos, o intentar violar las políticas de otra índole necesarias para la interacción exitosa con el servicio. La implementación interna del servicio debe tratar de compensar el uso inadecuado, sea cual fuere la intención del usuario. Si bien los servicios están diseñados para ser autónomos, no hay servicio que sea una isla. Una solución basada en SOA es fractal, y consiste en una serie de servicios configurados para garantizar una solución específica. Pensando de forma autónoma, nos damos cuenta rápidamente que no hay autoridad que presida en un entorno orientado a servicios - el concepto de un conductor de la orquesta es fallido (implicando que el concepto de rollback a través de los servicios sea también deficiente, pero este es un tema que se sale del alcance de este material). Las claves para la implementación de servicios autónomos son el aislamiento y la desconexión. Los servicios se diseñan y despliegan independientemente unos de los otros y sólo pueden comunicarse mediante mensajes y políticas establecidas contractualmente. Al igual que con otros principios de diseño de los servicios, podemos aprender de nuestras experiencias pasadas con el diseño orientado a objetos. El trabajo de Peter Herzum y Oliver Sims sobre las fábricas de componentes de negocio, ofrece algunas ideas interesantes sobre la naturaleza de los componentes autónomos. Si bien la mayor parte del trabajo es más apropiado para soluciones basadas en componentes de grano grueso, los principios básicos de diseño siguen siendo aplicables para el diseño de servicios. Teniendo en cuenta estas consideraciones, he aquí algunos principios de diseño simples que ayudan a asegurar el cumplimiento del segundo principio de la orientación a servicios: Los servicios deben ser desplegados y versionados independientemente del sistema en el que se implementan y consumen. Los contratos deben ser diseñados con la premisa de que una vez publicados, no se pueden modificar. Este enfoque obliga a los desarrolladores a introducir flexibilidad en el diseño de sus esquemas. Los servicios deben ser aislados de los fallos mediante la adopción de una perspectiva pesimista. Desde la perspectiva del consumidor, planee teniendo en cuenta niveles no confiables de disponibilidad del servicio y rendimiento. Desde la perspectiva del proveedor, espere el mal uso de su servicio (deliberadamente o no), espere que los consumidores de sus servicios fallen - tal vez sin notificar a su servicio. Principio 3: Los servicios comparten el esquema y el contrato, no las clases Como se dijo anteriormente, la interacción de los servicios debe estar basada únicamente en las políticas, el esquema y el comportamiento basado en contratos. El contrato de un servicio se define generalmente a través de WSDL, mientras que los contratos para la agregación de servicios se pueden definir utilizando BPEL (que a su vez utiliza WSDL para cada servicio agregado). La mayoría de los desarrolladores define clases para representar las distintas entidades dentro de un espacio de problemas determinado (por ejemplo, cliente, pedido y producto).
- 27. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 15 Las clases combinan el comportamiento y los datos (mensajes) en un único ensamblado con un lenguaje de programación o plataforma específica. Los servicios rompen este modelo para maximizar la flexibilidad y la interoperabilidad. Los servicios comunicándose a través de mensajes basados en esquemas XML, son agnósticos con respecto al lenguaje de programación y la plataforma, lo que garantiza mayor nivel de interoperabilidad. El esquema define la estructura y el contenido de los mensajes, mientras que el contrato del servicio define su comportamiento. En resumen, el contrato de un servicio se compone de los siguientes elementos: Formatos de intercambio de mensajes definidos usando esquemas XML. Patrones de intercambio de mensajes (MEP) definidos a través de WSDL. Capacidades y requisitos definidos con políticas de WS. BPEL puede ser utilizado como un contrato a nivel de procesos de negocio para la agregación de múltiples servicios. Los consumidores de servicios se basan en un contrato de servicios para invocar e interactuar con un servicio. Teniendo en cuenta esta dependencia, el contrato de un servicio debe permanecer estable en el tiempo. Los contratos deben ser diseñados lo más explícitamente posible, aprovechando la naturaleza extensible del esquema XML (xsd: any) y del modelo de procesamiento SOAP (encabezados opcionales). El mayor reto del tercer principio es su permanencia. Una vez que un contrato de servicio se ha publicado, se convierte en extremadamente difícil de modificar reduciendo al mínimo el impacto sobre los consumidores de servicios existentes. La línea entre las representaciones de datos internos y externos es fundamental para el éxito del despliegue y la reutilización de un servicio determinado. Los datos públicos (los transmitidos entre los servicios) deben basarse en estándares organizacionales o verticales, lo que garantiza una amplia aceptación entre los diferentes servicios. La información privada (los datos dentro de un servicio) se encapsula dentro de un servicio. En cierto modo, los servicios son como pequeñas representaciones de una organización que realiza transacciones de comercio electrónico. Al igual que una organización debe mapear una orden de compra externa a su formato interno, un servicio también debe mapear una representación de los datos basada en un contrato acordado a su formato interno. Una vez más, nuestras experiencias con la encapsulación de datos orientada a objetos pueden ser reutilizadas para ilustrar un concepto similar - la representación de los datos internos de un servicio sólo pueden manipularse a través del contrato del servicio. Teniendo en cuenta estas consideraciones, he aquí algunas recomendaciones simples de diseño para ayudar a garantizar el cumplimiento del tercer principio de orientación a servicios: Asegúrese que el contrato de un servicio se mantiene estable para minimizar el impacto sobre los consumidores del servicio. El contrato se refiere, en este sentido, a la representación pública de los datos, el patrón de intercambio de mensajes (WSDL) y las capacidades y niveles de servicio configurables (la política). Los contratos deben ser diseñados para ser lo más explícitos que sea posible, y así minimizar las malas interpretaciones. Además, los contratos deben ser diseñados para dar cabida a versiones futuras del servicio a través de la capacidad de ampliación, tanto
- 28. 16 Capítulo 1: Arquitectura Orientada a Servicios (SOA) de la sintaxis XML como del modelo de procesamiento de SOAP. Evite diluir la línea entre las representaciones de los datos públicos y privados. El formato de los datos internos de un servicio debe ser ocultado de los consumidores, mientras que su esquema de datos público debe ser inmutable (de preferencia basado en un estándar, ya sea organizacional, de facto, o de la industria). Versione los servicios cuando los cambios en el contrato sean inevitables. Este enfoque minimiza el impacto sobre las implementaciones existentes de los consumidores. Principio 4: La compatibilidad de los servicios se basa en políticas Si bien este se considera a menudo el menos entendido de los principios de diseño, es quizás uno de los más potentes en cuanto a la implementación de servicios Web flexibles. No es posible comunicar algunos requisitos para la interacción de los servicios usando solamente WSDL. Expresiones políticas se pueden utilizar para separar la compatibilidad estructural (lo que se comunica) de la compatibilidad semántica (¿cómo o con quien se comunica un mensaje?). Los requisitos operacionales para los proveedores de servicios pueden manifestarse en forma de expresiones que pueden ser evaluadas por la computadora. Las expresiones de política proporcionan un conjunto configurable de semánticas interoperables que rigen el comportamiento y las expectativas de un servicio determinado. La especificación de políticas de WS define una infraestructura de políticas de lectura mecánica capaz de expresar políticas a nivel de servicio, lo que les permite ser descubiertos o mejorados en tiempo de ejecución. Por ejemplo, un servicio de seguridad del gobierno puede requerir la aplicación de una política reforzando un nivel de servicio específico (por ejemplo, las fotos de pasaporte que cumplen con ciertos criterios establecidos deben ser cotejadas con un sistema de identificación de terroristas). La información de política relacionada con este servicio podría ser utilizada en una serie de otros escenarios o servicios relacionados con la realización de una verificación de antecedentes. Las políticas de WS se pueden utilizar para hacer cumplir estos requisitos sin necesidad de una sola línea de código adicional. Este escenario muestra cómo una infraestructura de políticas proporciona información adicional acerca de los requerimientos de un servicio, al mismo tiempo que también proporciona un modelo de programación declarativa para la definición y ejecución del servicio. Un planteamiento de la política identifica un comportamiento que es un requerimiento (o capacidad) de un tema de política. (En el escenario anterior el planteamiento es la verificación de antecedentes contra el sistema de identificación de terroristas.) Los planteamientos proporcionan semánticas de dominio específico y eventualmente se definirán dentro de especificaciones de dominio específico independientes, para una variedad de industrias verticales (estableciendo el concepto de infraestructura de políticas de WS). Si bien los servicios gestionados por políticas están todavía en evolución, los desarrolladores deben asegurarse de que sus planteamientos de política sean tan explícitos como sea posible con respecto a las expectativas y compatibilidades semánticas de los servicios. Los cuatro principios han sido concebidos principalmente para ayudarle en el diseño y desarrollo de sus servicios.
- 29. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 17 Un modelo abstracto de referencia para SOA Si bien un proyecto SOA bien planificado y ejecutado puede ayudar a las organizaciones a obtener mayor capacidad de respuesta en un mercado cambiante, no todos los esfuerzos orientados a los servicios han tenido éxito. Los proyectos SOA pueden experimentar un éxito limitado cuando son gestionados desde abajo hacia arriba por desarrolladores que no están familiarizados con las necesidades estratégicas de la organización. La construcción de SOA por SOA, sin hacer referencia al contexto de los negocios es un proyecto sin principios y directrices de organización. El resultado es una implementación caótica que no tiene ninguna relevancia empresarial. Por otro lado, tomando un enfoque de SOA de arriba hacia abajo requiere inversiones tan grandes de tiempo que para el momento en que el proyecto está completo, la solución ya no se ajusta a las necesidades del negocio. (¡Este es, por supuesto, uno de los problemas que se supone SOA debe resolver!) Por el contrario, Microsoft aboga por un enfoque intermedio, que combina metodologías de arriba abajo y de abajo arriba. En este enfoque, los esfuerzos de SOA son conducidos por la visión estratégica y las necesidades de la empresa, y se alcanzan a través de proyectos SOA incrementales e iterativos que se han diseñado para alcanzar los objetivos de negocio uno por uno. Microsoft ha estado utilizando esta técnica para ayudar a los clientes con sus iniciativas SOA, desde que la infraestructura .NET fue lanzada por primera vez en 1999. El concepto de SOA puede ser visto desde varias perspectivas. Si bien ninguna perspectiva individual o conjunto de perspectivas representa un punto de vista definitivo de una SOA, desde una visión holística estas perspectivas ayudan a comprender los requisitos arquitectónicos subyacentes. Microsoft cree que hay tres capas de capacidades abstractas expuestas dentro de una SOA. Un ejemplo de estas categorías y las relaciones entre estas aparece a continuación: Figura 6: Un modelo abstracto de referencia para SOA
- 30. 18 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Exposición La exposición se centra en cómo las inversiones en TI existentes se exponen como un conjunto de servicios abiertos y basados en estándares, permitiendo que estas inversiones estén al alcance de un conjunto más amplio de consumidores. Es probable que las inversiones existentes estén basadas en un conjunto heterogéneo de plataformas y proveedores. Si estas aplicaciones son incapaces de soportar de forma nativa los servicios Web, se requerirá de un conjunto de aplicaciones o adaptadores de protocolos específicos. La creación de servicios puede ser de grano fino (un servicio se mapea a un único proceso de negocio), o de grano grueso (múltiples servicios se agrupan para llevar a cabo un conjunto de funciones de negocio afines). La exposición también se ocupa de cómo se implementan los servicios. La funcionalidad de los recursos de TI subyacentes puede estar disponible de forma nativa si ya habla el lenguaje de los servicios Web, o pueden estar disponibles como servicios Web a través del uso de un adaptador. Una arquitectura de implementación de servicios describe cómo los servicios se desarrollan, implementan y gestionan. Composición Una vez que los servicios se crean, estos se pueden combinar en servicios más complejos, aplicaciones o procesos de negocio de funciones cruzadas. Como los servicios existen independientemente unos de otros, se pueden combinar (o “componer”) y volver a utilizar con la máxima flexibilidad. A medida que los procesos de negocio evolucionan, las reglas y las prácticas de negocio se pueden ajustar sin las restricciones que imponen las limitaciones de las aplicaciones subyacentes. Las composiciones de servicios permiten que se creen nuevos procesos de funciones cruzadas, lo que permite a la empresa adoptar nuevos procesos de negocio, ajustar los procesos para lograr una mayor eficacia, o mejorar los niveles de servicio a clientes y socios. Una arquitectura de integración de servicios describe un conjunto de capacidades para la composición de servicios, y otros componentes en ensamblados mayores como pueden ser los procesos de negocio. La composición de servicios requiere de algún tipo de flujo de trabajo o mecanismo de orquestación. Microsoft ofrece estas capacidades a través de BizTalk Server 2006 (BTS) o Windows Workflow Foundation (WF). Si bien puede parecer que BTS y WF satisfacen las mismas necesidades, en realidad son muy diferentes. WF y BTS son tecnologías complementarias diseñadas para satisfacer dos necesidades muy diferentes: BTS es un producto con licencia diseñado para implementar flujos de trabajo (“orquestaciones”) a través de diferentes aplicaciones y plataformas. WF es una infraestructura de desarrollo diseñada para exponer capacidades de flujo de trabajo desde una aplicación. No hay cuotas o restricciones de licencia asociadas con el uso o el despliegue de WF. Examinaremos el flujo de trabajo, la orquestación y la utilización de BizTalk/WF en el Capítulo 3 (flujos de trabajo y procesos de negocio). Consumo Cuando se crea una nueva aplicación o proceso de negocio, esa funcionalidad debe ponerse disponible para el acceso (consumo) por los sistemas de TI, por otros servicios y por los
- 31. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 19 usuarios finales. El consumo se centra en el suministro de nuevas aplicaciones que permitan una mayor productividad y una mayor penetración en el rendimiento del negocio. Los usuarios pueden consumir servicios “compuestos” a través de un amplio número de puntos de salida incluyendo portales web, aplicaciones cliente de interfaz enriquecida, aplicaciones ofimáticas (OBA), y dispositivos móviles. Los servicios “compuestos” pueden ser utilizados para desplegar con rapidez aplicaciones que se traducen en nuevas capacidades de negocio o una mejora en la productividad. Estas nuevas aplicaciones se pueden utilizar para medir el retorno de la inversión (ROI) en una SOA. Una arquitectura de aplicaciones orientadas a servicios describe cómo poner disponibles para el consumo los “servicios compuestos”, a través de procesos de negocio, nuevos servicios o nuevas aplicaciones finales. Este concepto se denomina a veces aplicaciones compuestas, ya que implica el consumo de servicios por aplicaciones finales. Las aplicaciones ofimáticas de Microsoft (OBA) soportan la noción de aplicación compuesta en los sistemas transaccionales al mismo tiempo que amplían el alcance de la interacción del usuario a través del familiar entorno del Office. Si bien las arquitecturas descritas en los epígrafes exposición/composición/consumo pueden ser interdependientes, están diseñadas para su acoplamiento flexible. Esto permite que los servicios sean gestionados, versionados y configurados independientemente de la forma en que han sido expuestos.
- 32. 20 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Capacidades arquitectónicas recurrentes Como vimos anteriormente, el modelo de arquitectura SOA es fractal. Esto significa que un servicio puede ser utilizado para exponer activos TI (por ejemplo, un sistema de una línea de negocios), componerse en flujos de trabajo o procesos de negocio (cada uno de los cuales también puede ser expuesto como un servicio) y consumirse por usuarios finales, sistemas u otros servicios. SOA es un modelo fractal y no un modelo en capas. Si bien el modelo abstracto de referencia SOA proporciona una visión integral de varios importantes conceptos de SOA, las secciones exponer/componer/consumir del modelo no deben ser interpretadas como capas (a pesar de su aspecto en el modelo). El diseño de una arquitectura SOA como un conjunto bien definido de niveles (o capas) limitará el valor y la flexibilidad de sus servicios, lo que resultará en dependencias entre componentes no relacionados. Esta es la razón por la que las secciones exponer/componer/consumir del modelo pueden ser consideradas como iniciativas arquitectónicas independientes, denominadas respectivamente como arquitectura de implementación de servicios (exposición), arquitectura de integración de servicios (composición) y arquitectura de aplicaciones (consumo). Aunque estas arquitecturas han sido diseñadas para ser independientes entre sí, comparten un conjunto de cinco funciones comunes. Figura 7: Capacidades arquitectónicas recurrentes Mensajes y servicios Mensajes y servicios se centra en cómo se lleva a cabo el intercambio de mensajes entre emisores y receptores. Hay una amplia gama de opciones y modelos disponibles - desde publicación/subscripción y asincrónica, hasta los patrones de interacción de mensajes y servicios. Los servicios proporcionan un enfoque evolutivo a la construcción de software distribuido que facilita la integración del acoplamiento flexible y la resistencia al cambio. El advenimiento de la arquitectura de servicios Web WS-* ha hecho factible el desarrollo de software orientado a servicios, en virtud del soporte de las herramientas de desarrollo y la amplia interoperabilidad en el sector. Si bien se implementa frecuentemente utilizando servicios Web estándares, la orientación a servicios es independiente de la tecnología y los patrones arquitectónicos, y se puede utilizar también para conectarse con los sistemas legados. Los mensajes y servicios no son un nuevo enfoque en el diseño de software - muchas de las ideas detrás de estos conceptos han existido por años. Un servicio se implementa generalmente como entidad de software de grano grueso que puede ser descubierta y que existe como una instancia única e interactúa con las
- 33. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 21 aplicaciones
- 34. 22 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Diferencias en la interfaz (por ejemplo, la interfaz ampliada, pero el mismo objeto de negocio). Diferencias semánticas con la misma interfaz (objetos de negocio modificados). Diferencias en la calidad de servicio (por ejemplo, más lento pero más barato o muy disponible, pero más caro). La gestión de servicios incluye muchas capacidades, algunas de las cuales se enumeran a continuación: Una solución completa para la gestión de los cambios y la configuración, permitiendo a las organizaciones ofrecer a los usuarios software y el servicio de actualizaciones correspondiente de forma rápida y rentable. Reducción de la complejidad asociada con la gestión de la infraestructura de TI, enfocándose en la disminución del costo de las operaciones. Servicios centralizados de salva de los archivos modificados en disco. Las copias centralizadas de seguridad deben permitir la recuperación rápida y fiable desde disco, proporcionando al usuario final la recuperación sin intervención del personal de TI. Planificación de las capacidades previo al despliegue, conjuntamente con una guía de buenas prácticas y conocimientos específicos de hardware, para ayudar a los profesionales de TI en la toma de las mejores decisiones arquitectónicas. Almacenamiento de datos y reportes para ayudar en la toma de decisiones corporativas, mejorar la calidad del servicio prestado, y lograr una mejor administración de los recursos a través de capacidades mejoradas de reportes y la integración de datos provenientes de una amplia variedad de recursos. Soporte para las capacidades arquitectónicas comunes La plataforma SOA de Microsoft soporta las cinco capacidades arquitectónicas discutidas más arriba. El resto del libro discute estas capacidades en mayor detalle, comenzando con los mensajes y servicios en el Capítulo 2. Figura 8: Capacidades SOA en la plataforma Microsoft
- 35. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 23 Las capacidades arquitectónicas comunes y el modelo abstracto de referencia para SOA También podemos pensar en estas cinco capacidades arquitectónicas comunes como un conjunto de perspectivas para entender el modelo abstracto de SOA. Las cinco capacidades arquitectónicas nos ayudan a comprender mejor los desafíos asociados con la exposición como servicios de las inversiones existentes en TI, la composición de los servicios en los procesos empresariales y el consumo de estos procesos en toda la organización. Exposición Habilitación de los servicios La exposición se centra en cómo diseñar y exponer nuestros servicios. Lo más probable es que se comience por exponer las inversiones en TI como servicios Web. A medida que nuestra organización madure va a añadir nuevos servicios, lo más probable que como representantes (proxies) de otros recursos dentro de la organización. Una de las partes más difíciles de la implementación de los servicios es decidir por dónde empezar. Hay una variedad de opciones, y no hay una recomendación única que funcione para todos. La metodología Motion de Microsoft proporciona una guía para la identificación de las capacidades empresariales que podrían exponerse como servicios. ¿Cuáles son algunas de los criterios que se deben seguir cuando se exponen inversiones en TI como servicios? Pensar en grande, pero empezar con poco. Mostrar resultados en cada paso del camino. Adoptar un enfoque intermedio, ni de arriba hacia abajo ni de abajo hacia arriba. Ser pragmáticos. Cortes verticales. Mitigación de los riesgos. Demostrar los beneficios en iteraciones rápidas. Nuevos enfoques de desarrollo. El éxito de los clientes produce el efecto de “bola de nieve”. Las capacidades arquitectónicas recurrentes nos proporcionan una serie de consideraciones al exponer las inversiones en TI como servicios. Echemos un rápido vistazo a algunas de las consideraciones asociadas con cada capacidad para la exposición de servicios (no es una lista completa): Mensajería y servicios Determinar qué exponer y cómo - evite caer en la trampa de la granularidad. Centrarse en la satisfacción de los requerimientos del negocio. Contrato para la operación del servicio. Contratos para los mensajes y datos. Configuración, comportamiento y control.
- 36. 24 Capítulo 1: Arquitectura Orientada a Servicios (SOA) SLAs. Gobernabilidad. Control de versiones. Flujos y procesos Servicios de coordinación para procesos distribuidos de larga duración. Servicios de seguimiento capaces de registrar eventos específicos dentro de un flujo. Servicios de compensación. Datos Servicios de entidades. Servicios de agregación de entidades: actúan como un punto de acceso único a la información que pueda existir en múltiples sistemas. Un servicio de agregación de entidades tiene las siguientes responsabilidades: Actúa como una fuente unificada de entidades. Proporciona una visión integral de la entidad. Proporciona una visión integral del modelo de las entidades – las entidades y sus relaciones con otras entidades. Proporciona transparencia con respecto a la ubicación - los consumidores de la capa de agregación de entidades no tienen que saber a quién pertenece la información. Hace cumplir las reglas de negocio que determinan los segmentos de las entidades recuperadas en un contexto dado. Determina el sistema de registro para cada elemento de datos que constituye una entidad. Enriquece el modelo de datos combinado a través de los sistemas - el todo es mejor que la suma de sus partes. Factorización de entidades. La MDM (gestión de datos maestros) se centra en la exposición de los datos a través de las fronteras corporativas o departamentales. Hablaremos de MDM con mayor detalle en el Capítulo 4. Interacción con el usuario Servicios especializados de soporte a las interfaces de usuario (recursos de almacenamiento en caché, comunicaciones entre la interfaz de usuario y los servicios, etc.). Los envoltorios (wrappers) de servicios proporcionan interfaces de grano grueso para el consumo por los usuarios de las aplicaciones, mashups2 ligeros, etc. 2 En desarrollo web, un mashup es una página web o aplicación que usa y combina datos, presentaciones y funcionalidad procedentes de una o más fuentes para crear nuevos servicios. Es tratado más adelante en el texto. (Nota del traductor)
- 37. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 25 Identidad y acceso Gestión de Identidad. Servicios de suplantación y delegación de identidad. Subsistema de confianza - Un modelo de subsistema de confianza implica que los servicios son de confianza para realizar tareas específicas, tales como el procesamiento de los pedidos de los clientes. Autenticación (Kerberos, SSL). Control de acceso basado en roles (RBAC). Creación/revocación de las relaciones de confianza. Los servicios deben tomar decisiones de autorización, como la aprobación del envío de una solicitud antes de realizar la transacción comercial. El servicio debe conocer la identidad del usuario final que envía la solicitud. La necesidad de enrutar la identidad del usuario final es una propiedad inherente del modelo de delegación, que no es así para el modelo de subsistema de confianza, y debe hacerse un esfuerzo especial para incluir esta característica. Para apoyar la noción de confianza, como se define en el modelo, los servicios deben ser capaces, al menos, de: Autentificar/verificar la identidad de los servicios. Decidir si el servicio es un subsistema de confianza para funciones específicas (incluida la propagación de reclamos de identidad). Proteger la integridad de los datos que se trasmiten entre los subsistemas de confianza y los servicios. Además de los datos de aplicación, los datos de las aplicaciones de infraestructura, tales como los reclamos de identidad del usuario original, también deben ser protegidos para que ningún operador humano en el camino pueda modificar la información de identidad que está en tránsito. Composición Composición de servicios La composición se centra en cómo podemos combinar o agregar servicios granulares en procesos más complejos. Seguramente vamos a empezar por usar los servicios que exponen nuestras actuales inversiones en TI. La composición de servicios resulta en una nueva instancia de servicio que el resto de la organización puede usar. La composición ofrece capacidades tales como la invocación asincrónica correlacionada de servicios, procesos de larga duración y otras capacidades para la orquestación de servicios autónomos. Las capacidades arquitectónicas recurrentes nos proporcionan un conjunto de consideraciones a la hora de componer los servicios granulares en procesos más complejos. Echemos un rápido vistazo a algunas de las consideraciones asociadas con cada capacidad para la composición de los servicios (que no es de ningún modo una lista completa):
- 38. 26 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Mensajería y servicios Patrones de interacción de servicios. Exposición de las orquestaciones como servicios. Patrones de invocación asincrónica de servicios. Flujos y procesos Transacciones. Alta frecuencia de cambio. Reglas de negocio. Orquestación de servicios. Patrones de interacción de servicios. Externalización de procesos. Procesos de larga duración. Auditoría y análisis. Datos Seguimiento del estado de una instancia de flujo de trabajo determinada. Transformación de los datos (ETL). Procesamiento y almacenamiento confiable de los datos. Replicación. Sincronización. Repositorio de metadatos y su gestión. Reconciliación de instancias. Reconciliación de esquemas. Replicación de documentos. Sindicación/Agregación. Interacción con el usuario Aplicaciones compuestas (aplicaciones ofimáticas). Flujos de trabajo humanos (MOSS). Las orquestaciones invocan flujos de trabajo humanos a través de un adaptador SharePoint. Definición de los flujos de trabajo (pageflows). Identidad y acceso Suplantación y delegación de identidad. Aprovisionamiento. Sincronización del repositorio de identidades. Flujos de aprobación.
- 39. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 27 Consumo Interacción con el usuario El consumo se centra en cómo los servicios y procesos orquestados (que pueden ser expuestos a su vez como servicios) son consumidos por otros servicios, aplicaciones y usuarios finales. Cualquier recurso capaz de interactuar con los servicios puede ser considerado como un “consumidor”. Los consumidores pueden aparecer en la organización en varias formas: Aplicaciones ligeras basadas en navegadores. Las aplicaciones Web de interfaz enriquecida (RIA) son aplicaciones basadas en un navegador que pueden direccionar y hacer cache de recursos locales y remotos. Interacciones configurables con los usuarios basadas en portales. Aplicaciones que se instalan en la máquina local (tales como una aplicación Windows). Aplicaciones empresariales corporativas con extensiones específicas (como el Office de Microsoft con paneles para actividades específicas) Aplicaciones diseñadas para dispositivos móviles. Los servicios pueden actuar como consumidores de otros servicios. Recordemos que el modelo de SOA es fractal – los servicios pueden ser consumidos por otros servicios y las composiciones de servicios pueden ser expuestas como nuevos servicios. En los dos últimos años una “nueva raza" de consumidores ha emergido, permitiendo a los consumidores agregarse y consumirse por otros consumidores. Esta “nueva raza” de consumidores se le llama generalmente “mashup”. Un mashup es un conjunto de servicios, sitios Web o aplicaciones que combinan el contenido de múltiples recursos en una interacción con el usuario integrada. El contenido utilizado por los mashups procede típicamente de un tercero (un servicio o sitio Web) a través de una interfaz pública o API. Algunos de los métodos alternativos de suministro de contenido para mashups son las fuentes de noticias y bloques JavaScript (JSON). Las capacidades recurrentes de la arquitectura nos proporcionan una serie de criterios para la interacción con el usuario. Echemos un vistazo a algunas de las consideraciones asociadas con cada capacidad (no pretende ser una lista completa): Mensajería y servicios Consumo de servicios desde formularios. Web parts3. Registro de servicios – check in /check out/búsqueda. AJAX, REST. 3 Se denomina así a una sección (ventana) dentro de una página Web en los sitios desplegados con la tecnología SharePoint de Microsoft. Representa, desde el punto de vista de la programación, un control dentro de la interfaz de usuario. (Nota del traductor).
- 40. 28 Capítulo 1: Arquitectura Orientada a Servicios (SOA) Flujos y procesos Flujos de trabajo humano (MOSS). Intermediación de eventos (CAB). Definición de los flujos de trabajo (pageflows). Datos Entidades (Catálogo de datos en aplicaciones ofimáticas). Vista única del problema del cliente. JSON. Experiencia del usuario Aplicaciones compuestas (aplicaciones ofimáticas). Personalización, perfiles de usuario. Portales. Inteligencia de negocios. Reportes. Agregación de contenido. Interacciones con el usuario declarativas. Identidad y acceso Single Sign-On (sincronización de contraseñas). Identificación del usuario. Acceso basado en roles (RBAC). Servicios de directorio. Gestión de contraseñas. Privacidad (firewalls, cifrado). Conformidad.
- 41. Capítulo 1: Arquitectura Orientada a Servicios (SOA) 29 Resumen En este capítulo se han proporcionado algunas analogías útiles para entender la naturaleza fractal de SOA. Los servicios son los pilares fundamentales de SOA, aunque los servicios no necesariamente tienen que ser servicios Web. En el caso ideal, estos servicios siguen los cuatro principios de diseño de los servicios que describen un conjunto de buenas prácticas para el ámbito, las dependencias, las comunicaciones y la configuración basada en políticas de los servicios. Si bien estos principios se centran en el diseño de servicios, es importante comprender que los servicios, por sí solos, no son necesariamente la arquitectura de la solución - Microsoft utiliza un modelo de referencia abstracto para describir los diversos aspectos de la arquitectura SOA. El modelo abstracto de referencia para SOA proporciona tres conceptos fundamentales para ayudar a la mayoría de las organizaciones a entender el papel que pueden desempeñar los servicios en las arquitecturas de sus soluciones: La exposición se centra en cómo las inversiones en TI existentes se exponen como un conjunto de servicios generales basados en estándares, permitiendo que estas inversiones estén a disposición de un amplio conjunto de los consumidores. La arquitectura de implementación de servicios describe cómo se desarrollan, implementan y administran los servicios. La composición se centra en la combinación de los servicios en aplicaciones o procesos de negocio de funciones cruzadas. La arquitectura de integración de servicios describe un conjunto de capacidades para la composición de servicios y otros componentes en ensamblados mayores como los procesos de negocio. El consumo se centra en ofrecer nuevas aplicaciones que permiten una mayor productividad y una mayor penetración en el rendimiento del negocio. La arquitectura de aplicaciones orientadas a servicios describe cómo “servicios compuestos” se ponen a disposición para el consumo a través de procesos de negocio, nuevos servicios o nuevas aplicaciones de usuario final. Cada aspecto del modelo abstracto de referencia de exposición/composición/consumo abarca un conjunto de cinco funciones arquitectónicas recurrentes: mensajería y servicios, flujos de trabajo y procesos, datos, interacción con el usuario, y la de identidad y acceso. Las cinco funciones arquitectónicas sirven como un conjunto de puntos de vista para comprender mejor los desafíos asociados con la exposición de inversiones existentes en TI como servicios, la composición de los servicios en los procesos empresariales y el consumo de estos procesos en toda la organización.
- 42. 30 Capítulo 1: Arquitectura Orientada a Servicios (SOA)
- 43. 31 Capítulo 2: Mensajes y Servicios “SOA no es algo que usted compra, es algo que usted construye.” – Jason Bloomberg Analyst Guía para el lector Los lectores de este capítulo continuarán desarrollando los conceptos introducidos en el capítulo 1, centrándose concretamente en la capacidad arquitectónica de mensajería y servicios. Figura 1: Capacidades arquitectónicas recurrentes La capacidad arquitectónica de mensajería y servicios se centra en el concepto de orientación al servicio y cómo los diferentes tipos de servicios se utilizan para implementar SOA. En este capítulo también se aborda el papel de los usuarios - especialmente cómo un usuario interactúa con los servicios dentro de una SOA. Los temas discutidos en este capítulo incluyen: Un modelo de madurez para SOA. El ciclo de vida de los servicios. Escenarios de ejemplo de SOA. El rol del usuario dentro de una SOA. Los conceptos tratados en este capítulo no son necesariamente nuevos. Los modelos de madurez para SOA y los ciclos de vida de los servicios han sido publicados por una amplia variedad de proveedores, consultores y analistas de la industria. Al igual que SOA en sí misma, no hay un solo modelo de madurez o del ciclo de vida de los servicios con el que todo el mundo concuerde. Los lectores deben revisar varias de estas propuestas y sacar de ellas los aspectos que mejor se ajusten a sus necesidades organizacionales.
- 44. 32 Capítulo 2: Mensajes y Servicios Entendiendo los servicios Un modelo de madurez para SOA (¿otro más?) Hay una gran cantidad de modelos de madurez para SOA que han sido propuestos por vendedores, empresas consultoras, analistas y autores de libros. La mayoría de estos modelos de madurez están basados o inspirados en el Modelo de Madurez de Capacidades (CMM) del Instituto de Ingeniería de Software. Una búsqueda reciente acerca del tema “Modelo de Madurez para SOA” retornó casi 10.000 elementos relevantes (incluyendo artículos sobre lo que se debe buscar con un Modelo de Madurez). Dado el gran interés y la variedad de modelos de madurez disponibles, ¿por qué introducir otro? A diferencia de otros modelos de madurez, el que se discute aquí no trata de aplicar simplemente la orientación a servicios al CMM. ESOMM (Modelo de Madurez Empresarial de Orientación a Servicios) toma la noción de modelos de madurez conducidos por la capacidad de CMM y aplica estos principios a los paradigmas de la orientación a servicios, construyendo en esencia una hoja de ruta a partir de cero. A diferencia de CMMI, el Modelo de Madurez de ESOMM no se centra en los procesos debido a que la atención se centra en las capacidades de TI, no en la disposición de la organización o la adopción. Si bien hay algunas similitudes conceptuales con CMM, ESOMM es una aplicación totalmente distinta del concepto de modelo de madurez. Las capas, perspectivas y capacidades definidas en el ESOMM están diseñadas como una hoja de ruta para dar soporte a los servicios - no un servicio específico con un uso, implementación o aplicación específica, sino cualquier servicio, o más específicamente, cualquier conjunto de servicios. El desarrollo de una estrategia SOA para toda la empresa no es una tarea trivial y no debe ser entendida como un esfuerzo a corto plazo o de una sola vez. SOA es un intento de habilitar un nivel superior de agilidad para toda la organización que posibilite una respuesta oportuna a las necesidades del negocio y los clientes. Hay muchos aspectos de la arquitectura SOA que serán mucho más críticos a corto plazo, por lo que es importante alinear los esfuerzos de su grupo adecuadamente. Para hacerlo con éxito, el desarrollo de una hoja de ruta con prioridades debe tener una notable importancia en el plan. Un ESOMM puede proporcionar un modelo basado en las capacidades e independiente de la tecnología, para ayudar a identificar el nivel actual de madurez de la organización, los objetivos a corto y largo plazo, y las áreas con oportunidades de mejora. La figura 2 muestra una visión general de ESOMM. ESOMM define 4 niveles de madurez horizontales, 3 perspectivas verticales, y 27 capacidades necesarias para soportar SOA.
- 45. Capítulo 2: Mensajes y Servicios 33 Figura 2: Un modelo de madurez empresarial de orientación a servicios (ESOMM) La mayoría de las organizaciones no implementan completamente y de forma natural todas las capacidades de una capa antes de pasar a la siguiente en el modelo, pero saltar demasiado lejos puede ser riesgoso. Esto se hace muy evidente a medida que se reconoce que una mala decisión relativa a las capacidades claves en las capas inferiores puede afectar gravemente su capacidad para madurar en las capas superiores. Las capacidades se clasifican en una de tres perspectivas: implementación, consumo y administración. Las capacidades de implementación tienen como objetivo el desarrollo y despliegue de servicios Web desde la perspectiva del proveedor. Las capacidades de consumo son aquellas que consideran a los consumidores de sus servicios, haciendo que les sea más fácil la implementación y por tanto sean adoptados más amplia y exitosamente. Las capacidades de administración son las que facilitan los aspectos operacionales y de gobernabilidad de los servicios Web a lo largo de la organización. Si bien una organización puede optar por centrarse en una sola perspectiva, el nivel general de madurez, y por tanto el valor de su SOA, dependerá de un nivel adecuado de atención de las tres. ESOMM es una herramienta que se puede utilizar para: Simplificar la complejidad de una solución distribuida compleja. Identificar y discutir la adopción de la orientación a servicios por una organización. Comprender la evolución natural de la adopción de los servicios (por ejemplo, el hecho de que saltarse ciertas capacidades en los niveles inferiores entraña cierto riesgo). Proporcionar a los clientes un plan coherente y completo para la orientación a servicios basándose en sus objetivos. Alinear las actividades y prioridades de una organización con diferente nivel de valor, proporcionando beneficios específicos a través de capacidades específicas.
- 46. 34 Capítulo 2: Mensajes y Servicios En una evaluación de SOA, cada capacidad se analiza de forma independiente en los niveles de fuerza, idoneidad, o debilidad. El nivel de fuerza demuestra que la organización está bien posicionada para crecer con seguridad en el uso de los servicios Web sin el temor de que surjan dificultades en esta área en el camino. El nivel de idoneidad señala que una organización tiene capacidad suficiente para satisfacer las necesidades actuales, pero es vulnerable a un crecimiento de los servicios Web que puede causar problemas en esa área. El nivel de debilidad muestra deficiencias para el uso actual de los servicios Web y podría representar graves perjuicios en el futuro. Cualesquiera capacidades que obviamente no son parte de los objetivos de la organización y que tienen un impacto mínimo a corto plazo en su desempeño se clasifican como no aplicables. Estas áreas pueden convertirse rápidamente en debilidades si los objetivos técnicos o de negocio fueran a cambiar o acelerarse. Al igual que en el CMM, los niveles de las capacidades individuales producen un indicador global de la capa que oscila entre 1 y 5. El indicador se evalúa sobre la base de la madurez media de las capacidades dentro de la capa. Un valor de 5 representa el dominio de ese nivel, con poco o ningún espacio para la mejora. Un 4 representa una base sólida dentro de un área que puede ser construida con éxito. Un 3 se asigna cuando los esfuerzos se han realizado bien en esa capa, pero moverse para la siguiente capa tiene sus riesgos. 2 significa que sólo los esfuerzos iniciales se han realizado en el área de trabajo y se necesita mucho más para moverse a la siguiente capa. Una calificación de 1 representa que no ha habido ningún esfuerzo para hacer frente a las capacidades en esa capa. Ahora que hemos tenido la oportunidad de revisar brevemente los componentes de ESOMM, usted estará pensando en cómo se puede aplicar a su organización. Para ser claros, la aplicación de este modelo no debe ser vista como una actividad de una sola vez o un proceso a corto plazo. Por el contrario, el modelo será aprovechado mejor como un plan de trabajo que se puede modificar en el tiempo a medida que crece el uso de los servicios y su experiencia. Por desgracia, la desventaja de usar el término madurez en un modelo es que la gente inmediatamente va a querer saber en qué capa se encuentra su organización para tener una idea de su condición o identidad. Como suele suceder, no hay una forma adecuada de responder a la pregunta, "¿en cuál capa está mi organización?". En lugar de dar una calificación general sobre la base de una de las capas, tomamos el enfoque de dar a cada capa su propio nivel de madurez, que va desde uno a cinco, con incrementos de medio punto. ESOMM está destinada a ser utilizada como una hoja de ruta, más que un instrumento de evaluación del nivel de “alistamiento” para SOA. Si bien es importante saber dónde uno se encuentra, obtener una valoración exacta es menos importante que identificar las capacidades en que necesita trabajar para continuar avanzando en la habilitación de los servicios en su organización. En la medida que usted esté dispuesto a hacerse algunas preguntas difíciles de una manera objetiva en todos los grupos pertinentes, será capaz de obtener una buena valoración de sus desafíos actuales. Si aplica la estrategia y los objetivos de su organización, usted debe ser capaz de identificar las capacidades que tendrá que abordar a corto, mediano y largo plazo. ESOMM es uno de los muchos modelos de madurez que se puede utilizar para evaluar las capacidades de la empresa en la adopción e implementación de SOA. Es terriblemente difícil tener una conversación concisa y constructiva sobre habilitación de servicios en una
- 47. Capítulo 2: Mensajes y Servicios 35 empresa, sin algún nivel de concordancia acerca de las capacidades y la madurez - ESOMM es uno de los modelos de madurez que tratan de abordar esta cuestión. A diferencia de otros modelos de madurez, sin embargo, ESOMM también puede aprovecharse como una hoja de ruta con prioridades para ayudar a las empresas a identificar las capacidades necesarias para una implementación exitosa. El objetivo de ESOMM y otros modelos de madurez es apertrechar a su organización con las herramientas y la información necesaria para una implementación de SOA exitosa. De alguna manera, SOA hace que la preparación de la infraestructura sea más compleja, ya que es necesario desarrollar nuevas capacidades que no existían antes, como el registro y el repositorio. En cierto sentido, esto puede ser comparado con la construcción de una red de autopistas - seguro es más cara de construir, y los usuarios necesitarán mejorar sus medios de transporte para sacar el máximo partido de la infraestructura, pero el costo por viaje (en cuanto a tiempo y seguridad) se reduce significativamente. Mientras la red no alcanza una masa crítica, los conductores tienen que estar preparados para tener que salirse de la carretera para llegar a su destino. Muchas aplicaciones empresariales no han sido desarrolladas teniendo en cuenta a SOA, y son incapaces de aprovechar una infraestructura SOA, o tendrán que ser actualizadas para aprovechar sus ventajas. Sin embargo, con la creación coherente de nuevas aplicaciones, hay una gran oportunidad para reducir los nuevos costos de interoperabilidad, a medida que los vendedores de tecnología habilitan sus productos para SOA. El mayor reto para SOA es convencer a los propietarios de las aplicaciones para invertir más hoy y lograr así los ahorros prometidos a largo plazo. Si bien los modelos de madurez como ESOMM pueden ayudar a esclarecer las capacidades necesarias para SOA, los tipos de servicios que su organización va a necesitar permanecen, por lo general, sin respuesta. Por tanto, una taxonomía simple de los servicios puede ayudar a la mejor comprensión de la amplitud de servicios que normalmente existen dentro de una SOA.
- 48. 36 Capítulo 2: Mensajes y Servicios Taxonomía de un servicio A medida que examinamos los tipos de servicios percibimos dos tipos principales: los que están en la naturaleza de la infraestructura y proporcionan servicios comunes que no son parte de la aplicación, y los que forman parte de la aplicación y proporcionan los bloques para construirla. Las aplicaciones de software utilizan una variedad de funciones comunes que van desde los servicios de bajo nivel que ofrece el sistema operativo como la gestión de la memoria y la manipulación de E/S, hasta los de alto nivel tales como la biblioteca de tiempo de ejecución del lenguaje C (RTL), la plataforma Java, o la plataforma .NET. Las soluciones creadas utilizando SOA hacen uso también de funciones comunes, tales como la infraestructura de servicios temáticos (por ejemplo, Windows Communication Foundation) y un conjunto de servicios que forman parte de la infraestructura de computación distribuida. Vamos a nombrar a este conjunto de servicios como Servicios de Bus. Los Servicios de Bus se dividen, a su vez, en Servicios de Comunicaciones que ofrecen las instalaciones de transferencia de mensajes, como los mensajes de enrutamiento y los mecanismos de publicación y suscripción, y Servicios de Utilidades que proporcionan las capacidades no relacionadas con la transferencia de mensajes, como el servicio de descubrimiento y el de seguridad federada. La eficiencia del desarrollo de aplicaciones de software es aún mayor gracias a la reutilización de bloques de alto nivel de grano grueso. Los entornos de programación RAD que surgieron en la época de la programación orientada a componentes (como Delphi o Visual Basic) proporcionan la capacidad de componer de forma rápida y fácil las funcionalidades y capacidades proporcionadas por los bloques existentes usando código de aplicación específico para crear nuevas aplicaciones. Los ejemplos de tales componentes van desde las construcciones más genéricas de interfaces gráficas y las abstracciones en el acceso a bases de datos, hasta funcionalidades más específicas, como gráficos o registro de eventos. Las aplicaciones compuestas en una SOA también utilizan bloques de construcción de este tipo en su modelo de composición. Nombraremos a estos bloques de construcción Servicios de Aplicaciones. Los Servicios de Aplicaciones se dividen, a su vez, en Servicios de Entidad que exponen y permiten la manipulación de las entidades de negocio, Servicios de Capacidades y Servicios de Actividades que ejecutan los componentes funcionales de la aplicación (conocidos a veces como componentes o módulos), y Servicios de Procesos que componen y orquestan los servicios de capacidades y de actividades para implementar los procesos de negocio. El siguiente diagrama muestra una posible composición de los servicios en las categorías de servicios antes mencionadas.
- 49. Capítulo 2: Mensajes y Servicios 37 Figura 3: Servicios de bus Los Servicios de Bus son funcionalidades comunes que no aportan ningún valor explícito de negocio, sino más bien una infraestructura necesaria para la ejecución de cualquier proceso de negocio en una SOA. Los Servicios de Bus suelen ser componentes comprados o construidos centralmente que sirven a múltiples aplicaciones y que son, por tanto, administrados centralmente. Servicios de comunicaciones Los Servicios de Comunicaciones transportan mensajes hacia, desde, y dentro del sistema sin preocuparse por el contenido de los mensajes. Por ejemplo, un dispositivo Bridge puede mover los mensajes de ida y vuelta a través de una barrera de la red (es decir, conectando dos redes que de otra manera estarían desconectadas) o a través de una barrera de protocolo (esto es, moviendo los mensajes en cola entre WebSphere MQ y MSMQ). Ejemplos de Servicios de Comunicaciones pueden ser los siguientes: relés, sistemas de publicación-suscripción, enrutadores, colas y compuertas. Los Servicios de Comunicaciones no conservan ningún estado de la aplicación, pero en muchos casos están configurados para trabajar de conjunto con las aplicaciones que los utilizan. Una aplicación particular puede necesitar instruir o configurar los servicios de comunicaciones sobre la forma de mover los mensajes que fluyen en su interior de modo que la comunicación entre componentes sea posible en una arquitectura de acoplamiento flexible. Por ejemplo, un enrutador basado en el contenido puede solicitar a la aplicación que proporcione las instrucciones de ruta para saber dónde enviar los mensajes. Otro ejemplo puede ser un servidor de publicación-suscripción que distribuye mensajes a los suscriptores registrados basándose en un filtro que se aplica al contenido del mensaje. Este filtro es definido por la aplicación. En ambos casos el Servicio de Comunicaciones no procesa el contenido del mensaje, sino más bien (opcionalmente) usa algunas de las instrucciones de la aplicación para determinar dónde debe ir. Además de los requerimientos específicos de la aplicación, restricciones impuestas por la
- 50. 38 Capítulo 2: Mensajes y Servicios seguridad, u otro tipo de restricciones pueden determinar que los usuarios de un servicio de comunicaciones particular tendrán que tener ciertos permisos para utilizar las facilidades ofrecidas por este. Estos permisos se pueden establecer en el ámbito de la aplicación (es decir, permitir que una aplicación pueda utilizar el servicio sin importar el usuario específico que está utilizando la aplicación), en el ámbito del usuario (es decir, permitiendo a un usuario específico utilizar el servicio sin importar la aplicación que el usuario está utilizando), o en ambos ámbitos (esto es, permitiendo que el usuario específico acceda al servicio durante la ejecución de una aplicación específica). Por ejemplo, un servicio de publicación-suscripción puede ser configurado para restringir el acceso a temas específicos, permitiendo que sólo determinados usuarios puedan suscribirse a estos. Otras facilidades a nivel de aplicación que pueden ofrecer los Servicios de Comunicaciones tienen que ver con la vigilancia, el diagnóstico y el Monitoreo de la Actividad del Negocio (BAM). Los Servicios de Comunicaciones pueden proporcionar información estadística sobre la aplicación, como un análisis de los patrones de tráfico de mensajes, informes de la tasa de errores (por ejemplo, el número de errores SOAP que se envían a través de un enrutador por día), o indicadores de rendimiento de nivel empresarial (por ejemplo, el número de órdenes de compra que están llegando a través de la compuerta de un socio comercial). A pesar de que pueden ser específicas para una aplicación particular, estas capacidades no son diferentes a los ajustes de configuración para controlar el flujo de mensajes. Esta información se proporciona por una característica genérica del Servicio de Comunicaciones, que a menudo se debe configurar por la aplicación. La información estadística proporcionada tiene que ser consumida, por lo general, por una parte específica de la aplicación que sabe qué hacer con ella (por ejemplo, levantar una alerta de seguridad en el centro de datos o actualizar un gráfico relacionado con BAM en la pantalla del ordenador del director de finanzas). Servicios de Utilidades Los Servicios de Utilidades proporcionan servicios genéricos, independientes de la aplicación, que tienen que ver con los otros aspectos que no son el transporte de mensajes de la aplicación. Al igual que los Servicios de Comunicación, la funcionalidad que ofrecen es parte de la infraestructura básica de una arquitectura SOA y no están relacionados con la lógica específica de la aplicación o proceso de negocio. Por ejemplo, un servicio de localización puede ser utilizado por los componentes de una aplicación compuesta de acoplamiento flexible para descubrir otros componentes de la aplicación a partir de cierto criterio específico (por ejemplo, un servicio que se despliega en un entorno de pre-producción puede buscar otro servicio que implementa cierta interfaz que el primer componente necesita y que también está desplegado en el entorno de pre-producción). Ejemplos de los servicios de utilidades son los servicios de seguridad e identidad (por ejemplo, un servicio de identidad federada o un servicio de token de seguridad), los servicios de localización (por ejemplo, un servidor UDDI), y los servicios de transformación de mensajes. Como en el caso de los Servicios de Comunicaciones, los Servicios de Utilidades también pueden ser instruidos o configurados por una aplicación en particular sobre la manera de realizar una operación en su nombre. Por ejemplo, un servicio de transformación de mensajes puede transformar los mensajes de un esquema de mensajes a otro esquema basado en un mapeo de transformación que es proporcionado por la aplicación que utiliza el servicio de transformación de mensajes.
- 51. Capítulo 2: Mensajes y Servicios 39 A pesar de que los Servicios de Utilidades no conservan ninguna información sobre el estado de la aplicación, el estado de un Servicio de Utilidades puede verse afectado por los cambios del estado del sistema. Por ejemplo, un usuario nuevo que se añade a la aplicación, puede requerir una actualización de la configuración de las credenciales en el servicio de token de seguridad. Al contrario que en el caso de los Servicios de Comunicaciones, los servicios del cliente interactúan directamente con los Servicios de Utilidades, los cuales procesan y (si es necesario) responden a los mensajes que los clientes les envían. Los usuarios de los Servicios de Utilidades pueden requerir que sea configurado un permiso para que ellos puedan utilizar el servicio, ya sea una aplicación, un usuario, o un ámbito aplicación-usuario. Por ejemplo, un servicio de localización sólo puede servir a los usuarios autenticados en el dominio (es decir, usuarios que tienen credenciales válidas emitidas por un controlador de dominio de Windows). Al igual que los Servicios de Comunicaciones, los Servicios de Utilidades pueden proporcionar facilidades a nivel de aplicación para control, diagnóstico, BAM, etc. Estos pueden incluir información estadística sobre los patrones de uso (por ejemplo, el número de usuarios de otra organización autenticados con una identidad federada), tasas de error que afectan el negocio (por ejemplo, cuántas transformaciones del formato de mensaje de órdenes de compra fallaron debido a un formato de entrada inadecuado), etc. Como con los Servicios de Comunicaciones, estas funcionalidades suelen ser las características genéricas del Servicio de Utilidades y tienen que ser configuradas y consumidas por la solución particular en la que se utilizan. Servicios de Aplicaciones Los Servicios de Aplicaciones son los servicios que intervienen en la ejecución de un proceso de negocio. Proporcionan un valor comercial explícito, y existen en un amplio espectro que se inicia en un extremo con los servicios genéricos que se utilizan en cualquier aplicación compuesta en la organización, termina en el otro extremo con los servicios especializados que forman parte de una aplicación compuesta en particular, y cuenta además con servicios que pueden ser utilizados por dos o más aplicaciones entre ambos extremos. Servicios de Entidades Los Servicios de Entidades descubren y hacen emerger las entidades de negocio en el sistema. Pueden ser considerados como los componentes de datos ("nombres") del proceso de negocio: empleados, clientes, ventas, pedidos, etc. Ejemplos de estos servicios incluyen el servicio de clientes que gestiona la información de los clientes, el servicio de pedidos que controla y maneja los pedidos que envían los clientes, etc. Los Servicios de Entidades introducen un nivel de abstracción en los almacenes de datos (por ejemplo, SQL Server, Active Directory, etc.) y exponen la información almacenada en estos a través de una interfaz de servicios. Por lo tanto, es justo decir que los Servicios de Entidades gestionan el estado persistente del sistema. En algunos casos, la información gestionada trasciende las fronteras de un sistema específico y se utiliza en varios o incluso todos los sistemas de la organización. Es muy común que los Servicios de Entidades den soporte a una interfaz CRUD a nivel de entidad, y añadan otras operaciones necesarias para resolver el problema del dominio
- 52. 40 Capítulo 2: Mensajes y Servicios específico y den soporte a las funciones y casos de uso de la aplicación. Un ejemplo de una operación de dominio específico es un servicio de clientes que expone un método llamado FindCustomerByLocation que permite encontrar un identificador de cliente dada la dirección postal del mismo. La información que gestionan los Servicios de Entidades tiene normalmente una duración más larga que la de un simple proceso de negocio. La información que los Servicios de Entidades exponen suele estar estructurada, a diferencia de los almacenes de datos relacionales o jerárquicos que son representados por el servicio. Por ejemplo, un servicio puede agregar la información almacenada en varias tablas de una base de datos o incluso de varias bases de datos separadas y proyectar la información como una única entidad de clientes. En algunos casos, por lo general por motivos de conveniencia, los implementadores de los Servicios de Entidades optan por exponer los datos subyacentes como juegos de datos en lugar de datos XML regidos por esquemas. A pesar de que los juegos de datos no son entidades en el sentido estricto, estos servicios aún se consideran Servicios de Entidades a efectos de la clasificación. Los usuarios de los Servicios de Entidades pueden requerir que se configure un permiso para que puedan utilizar el servicio, ya sea en el ámbito de la aplicación, del usuario, o ambos. Estos permisos pueden aplicar restricciones al acceso de datos y /o a los cambios a nivel de “fila” (entidad) o de “columna” (elemento de entidad). Un ejemplo de restricción a nivel de “columna” sería una aplicación de recursos humanos que puede tener acceso tanto a la seguridad social como a los elementos de la dirección particular de la entidad empleado, mientras que un servicio de impresión de cheques sólo puede tener acceso al elemento de dirección de su casa. Un ejemplo de restricción a nivel de “fila” sería una aplicación de reporte de gastos, que permite a los administradores ver y aprobar los reportes de gastos de los empleados que dependen de ellos, pero no para los empleados que no dependen de ellos. La compensación de errores en los Servicios de Entidades se limita principalmente a la búsqueda de fuentes alternativas de datos. Por ejemplo, si un Servicio de Entidades no puede acceder a una base de datos local, puede tratar de llegar a una copia remota de la base de datos para obtener la información necesaria. Para asegurar la coherencia del estado del sistema, los Servicios de Entidades, por lo general, soportan transacciones atómicas distribuidas. Los servicios que soportan transacciones atómicas distribuidas participan en transacciones que se hacen fluir hacia ellos y que están sujetas a cambios del estado de los datos subyacentes como resultado de dichas transacciones atómicas distribuidas. Para permitir un menor grado de acoplamiento de los cambios de estado, los Servicios de Entidades pueden dar soporte a patrones de reservación de acoplamiento flexible, ya sea como complemento o en lugar de dar soporte a las transacciones atómicas distribuidas. Los Servicios de Entidades se construyen a menudo en la propia empresa como envoltura de una base de datos existente. Estos servicios se implementan normalmente programando código para mapear los registros de la base de datos a las entidades y exponerlos en una interfaz de servicio, o mediante el uso de una fábrica de software para generar el código de mapeo y la interfaz de servicio. La Fábrica de Software de Servicios Web del Grupo de Prácticas y Patrones de Microsoft es un ejemplo de fábrica de software. En algunos casos, la base de datos (por ejemplo, SQL Server) o la aplicación de gestión de los datos (por ejemplo,
- 53. Capítulo 2: Mensajes y Servicios 41 SAP) proporcionan de forma nativa funcionalidades que permiten el acceso a los datos a través de una interfaz de servicio, eliminando la necesidad de generar y mantener un Servicio de Entidades independiente. Los Servicios de Entidades se utilizan a menudo en más de una aplicación y por lo tanto suelen ser gestionados de forma centralizada. Servicios de Capacidades Los Servicios de Capacidades implementan las capacidades de la organización a nivel de negocio, y representan los bloques de construcción que componen los procesos de negocio de la organización. Algunos ejemplos de Servicios de Capacidades son los servicios de interconexión con terceros, tales como un servicio de procesamiento de tarjetas de crédito que puede ser utilizado para la comunicación con una pasarela externa de pagos, en una aplicación donde se efectúen los pagos con tarjeta de crédito, un elemento de valor añadido como puede ser un servicio de clasificación que puede procesar y calcular valoraciones de usuarios para cualquier cosa que pueda ser clasificada en una aplicación que utiliza valoraciones (por ejemplo, la utilidad de una página de ayuda, un libro, un proveedor, etc.), o un servicio de comunicaciones como un servicio de correo electrónico que se puede utilizar en cualquier aplicación que requiere el envío de correos electrónicos a clientes o empleados. Los Servicios de Capacidades se pueden clasificar por el tipo de servicio que ofrecen (por ejemplo, de interconexión con terceros, de valor agregado, o de comunicaciones), pero esta distinción está fuera del alcance de esta discusión. Los Servicios de Capacidades exponen una interfaz de servicios específica para la capacidad que ellos representan. En algunos casos, una capacidad de negocio existente (legada) o adquirida recientemente puede no cumplir con la forma en que la organización expone las capacidades como servicios, o incluso puede que no exponga una interfaz de servicio en lo absoluto. En estos casos, la capacidad suele ser envuelta con una capa delgada de servicios que expone la API de capacidades como una interfaz de servicio que se adhiere al protocolo de la organización para la exposición de capacidades. Por ejemplo, algunas empresas de servicios de procesamiento de tarjetas de crédito presentan una API basada en HTML que requiere que el usuario rellene un formulario Web. Una capacidad así sería envuelta por un servicio de fachada desarrollado y gestionado en la organización que proporciona un fácil acceso mediante programación a la capacidad. El servicio de fachada es opaco, y oculta la naturaleza real de la capacidad que está detrás de ella, hasta el punto que puede reemplazarse la capacidad subyacente sin tener que cambiar la interfaz de servicio utilizada para acceder a ella. Por lo tanto, el servicio de fachada es considerado como el Servicio de Capacidades, y la capacidad subyacente se convierte simplemente en un detalle de implementación del servicio de fachada. Los Servicios de Capacidades, por lo general, no manejan directamente el estado de la aplicación, para hacer los cambios de estado en la aplicación se utilizan los Servicios de Entidades. Si un Servicio de Capacidades gestiona el estado, ese estado es generalmente transitorio y demora un período de tiempo más corto que el necesario para completar el proceso de negocio en que este Servicio de Capacidades participa. Por ejemplo, un Servicio de Capacidades que ofrece cotizaciones de precios de envío de paquetes podría registrar el momento en que fueron enviadas las solicitudes de cotizaciones a los proveedores de transporte hasta que las respuestas retornan, borrando entonces dicho registro. Además, un
- 54. 42 Capítulo 2: Mensajes y Servicios Servicio de Capacidades que se implementa como un flujo de trabajo se encargará de gestionar el estado de ejecución transitoria para todas las instancias en ejecución del flujo de trabajo. Si bien la mayoría de las capacidades carecen de estado, es evidente que hay funciones como el registro de eventos que, naturalmente, gestionan y encapsulan el estado. Los usuarios de los Servicios de Capacidades pueden requerir que se configure un permiso para que ellos puedan utilizar el servicio, ya sea una aplicación, un usuario, o un ámbito de usuario de aplicación. El acceso a un Servicio de Capacidades suele ser otorgado a nivel de aplicación. Los permisos por cada usuario suelen ser gestionados por los Servicios de Procesos que hacen uso de los Servicios de Capacidades para simplificar la gestión de acceso y prevenir la ocurrencia de errores de acceso en medio de un proceso. La compensación de los errores en los Servicios de Capacidades se limita a satisfacer la Expectativa de Nivel de Servicio (SLE) de la capacidad y los Acuerdos sobre el Nivel de Servicio (SLA). Por ejemplo, el servicio de compuerta de correo electrónico puede poner en cola, silenciosamente, para su entrega diferida, una notificación por correo electrónico si hay un problema con el servicio de correo, y enviarla en un momento posterior, cuando la conectividad de correo electrónico esté restaurada. Un servicio de envío que regularmente compara las tarifas y plazos de entrega de cuatro proveedores (por ejemplo, FedEx, UPS, DHL, y un servicio courier4 local) puede compensar la falta de disponibilidad de un proveedor ignorando el error, y continuar con la comparación de las tarifas siempre que sea capaz de obtener al menos dos cotizaciones. Estos ejemplos vienen a ilustrar que las fallas pueden resultar en un menor rendimiento. Esta degradación puede ser expresada en términos de latencia (como en el caso de un Servicio de Coreos de Clientes), de calidad de servicio (por ejemplo, el servicio de envío sólo estaría comparando las dos mejores cotizaciones en lugar de 4), y de muchos otros aspectos, y por lo tanto debe ser descrito en el SLE y el SLA para el servicio. Los Servicios de Capacidades pueden dar soporte a las transacciones atómicas distribuidas y/o al patrón de reservación. La mayor parte de los Servicios de Capacidades no gestionan recursos en los que el estado tiene que gestionarse a través de transacciones atómicas, pero en un Servicio de Capacidades puede fluir una transacción atómica que esté incluida en los Servicios de Entidades que utiliza. Los Servicios de Capacidades también se utilizan para implementar un patrón de reservaciones a través de Servicios de Entidades que no son compatibles con ese modelo, y en mucha menor medida en otros Servicios de Capacidades que no son compatibles con ese modelo. Los Servicios de Capacidades se pueden desarrollar y gestionar en la empresa, se pueden comprar a un tercero y gestionarlos en la empresa, o se pueden arrendar a un proveedor externo para consumirse como SaaS, en cuyo caso se desarrolla, mantiene y gestiona externamente. Cuando se desarrollan en la empresa, los Servicios de Capacidades pueden ser implementados utilizando código imperativo o un flujo de trabajo declarativo. Si se implementan como un flujo de trabajo, el Servicio de Capacidades suele ser modelado como una actividad de negocio de corta duración (atómica, no episódica). Las actividades de negocio de larga duración, donde las cosas pueden fallar o requieren compensación, por lo 4 Se llama courier a una persona o empresa que se dedica a entregar mensajes, paquetería y correo con correspondencia y documentos. (Nota del Traductor).
- 55. Capítulo 2: Mensajes y Servicios 43 general caen en la categoría de Servicios de Proceso. Un Servicio de Capacidades es casi siempre usado por muchas aplicaciones, y por lo tanto se gestiona normalmente de forma centralizada. Servicios de Actividades Los Servicios de Actividades implementan las capacidades a nivel de negocio y algunos otros elementos de la lógica de negocio (bloques) que son únicos para una aplicación particular. La principal diferencia entre los Servicios de Actividades y los Servicios de Capacidades es el ámbito en el que se utilizan. Mientras que los Servicios de Capacidades son un recurso de la organización, los Servicios de Actividades se utilizan en un ámbito mucho más pequeño, como una aplicación o una solución (que consta de varias aplicaciones). En el transcurso del tiempo y con suficiente reutilización en toda la organización, un Servicio de Actividades puede convertirse en un Servicio de Capacidades. Los Servicios de Actividades se crean típicamente para facilitar la descomposición de un proceso complicado o para permitir la reutilización de una unidad de funcionalidad en varios lugares en un Servicio de Procesos en particular o incluso a través de diferentes Servicios de Procesos de la aplicación. Las fuerzas impulsoras para la creación de Servicios de Actividades pueden provenir de una variedad de fuentes, tales como fuerzas de la organización, requerimientos de seguridad, requerimientos reglamentarios, etc. Un ejemplo de un Servicio de Actividades creado en un escenario de descomposición es un servicio de confirmación de elegibilidad para vacaciones que, debido a los requisitos de seguridad, separa una parte específica
- 57. Capítulo 2: Mensajes y Servicios 45 Procesos seguirá el rastro del paso en que se encuentra el proceso de negocio. Por ejemplo, un Servicio de Procesos implementado como un flujo de trabajo mantendrá el estado de ejecución de todas las instancias del flujo de trabajo actualmente en ejecución. Los usuarios de los Servicios de Procesos pueden requerir que se configure un permiso para que ellos puedan utilizar el servicio, ya sea una aplicación, un usuario, o un ámbito de usuario de aplicación. El acceso a un Servicio de Procesos se otorga normalmente a nivel de usuario. Los Servicios de Procesos muy rara vez dan soporte a la participación en una transacción atómica distribuida, ya que proporcionan soporte a las actividades de negocio de larga duración (también conocidas como transacciones de larga duración) en las que la compensación de los errores ocurre en el nivel de lógica de negocio y la compensación puede incluir flujos de trabajo humanos. Los Servicios de Procesos pueden utilizar transacciones atómicas distribuidas al llamar a los servicios que utilizan. Los Servicios de Procesos se suelen desarrollar y gestionar en la empresa, ya que estos capturan la esencia de la organización, la “salsa secreta” que define la forma en que la organización realiza sus negocios. Los Servicios de Procesos están diseñados para permitir la agilidad de los procesos (es decir, que sean fácilmente actualizables) y los procesos que suelen implementar son episódicos por naturaleza (es decir, su ejecución se compone de pequeños momentos de actividad separados por largas esperas por la terminación de actividades externas). Por tanto, los Servicios de Procesos se implementan mejor como flujos de trabajo declarativos usando un servidor de integración (como BizTalk) o una plataforma de manejo de flujos de trabajo (como Windows Workflow Foundation). Los Servicios de Procesos se utilizan normalmente en una aplicación y por lo tanto pueden gestionarse de forma individual (por ejemplo, a nivel departamental). En algunos casos un proceso de negocio reutilizable puede convertirse en un producto que puede ser ofrecido o consumido como SaaS. En el diseño de software de gestión de negocios, debemos recordar que el objetivo es la entrega de sistemas ágiles de apoyo al negocio, no la orientación a servicios (SO). Más bien, la orientación a servicios es el enfoque y la tecnología que nos permite agilidad en los negocios, y no es un fin en sí mismo. Esto se debe tener en cuenta en particular con respecto a los servicios Web. Lograr la agilidad que tan a menudo acompaña a los servicios Web no es sólo una consecuencia de la adopción de protocolos de servicios Web en el despliegue de los sistemas, sino también de seguir los principios del buen diseño. En este capítulo se consideran una serie de principios de la arquitectura y el diseño de los servicios desde la perspectiva de su impacto en la agilidad y la adaptabilidad.
- 58. 46 Capítulo 2: Mensajes y Servicios Ciclo de vida de un servicio Ahora que hemos examinado los tipos de servicios que puedan existir dentro de una SOA, se requiere una mirada más integral a los servicios. El ciclo de vida de los servicios se puede utilizar para comprender las actividades, procesos y recursos necesarios para el diseño, construcción, despliegue y, finalmente, eliminación, de los servicios que componen una SOA. Un servicio viene a la vida, conceptualmente, como resultado de la racionalización de un proceso de negocio y de la descomposición y el mapeo de esos procesos de negocio en los activos de TI existentes, así como de los nuevos activos de TI que se requieran para llenar los vacíos existentes. Los nuevos activos de TI, una vez identificados, serán presupuestados y planificados para las actividades SDLC que resultarán en servicios de despliegue (suponiendo que nuestro objetivo es crear activos de TI reutilizables). En el gráfico a continuación se presentan varias actividades importantes que se producen (no necesariamente en ese orden) durante el tiempo de vida de un servicio desde la perspectiva del proveedor de servicios: Figure 4: Ciclo de vida de un servicio Análisis del servicio El análisis del servicio es la racionalización de las capacidades técnicas y de negocio con la idea expresa de habilitarlas a través de servicios. Se establecerán otros aspectos tales como los SLAs, la localización/globalización, y los contratos básicos de servicio para su uso futuro en el ciclo de vida. Desarrollo del servicio La racionalización de los contratos (esquemas XML) y el diseño de los nuevos contratos serán de las principales actividades en esta fase. Serán adquiridas o diseñadas bibliotecas
- 59. Capítulo 2: Mensajes y Servicios 47 de objetos para dar soporte a la implementación del servicio. Los resultados de esta fase serán las políticas de seguridad, las fronteras de confianza, la autentificación/autorización, la privacidad de los datos, la instrumentación, WSDL, etc. La decisión sobre si distribuir WSDL o representantes del servicio a los consumidores se decidirá durante esta fase. El servicio será desarrollado utilizando el IDE seleccionado, la colección de Servicios Web y el lenguaje de su elección. Verificación del servicio Los servicios se verificarán a todos los niveles utilizando desde pruebas unitarias hasta comprobaciones complejas con carga, para asegurar que se satisfacen todos los escenarios y rangos SLA de consumo del servicio. Aprovisionamiento del servicio Los metadatos del servicio, como se señala en el epígrafe “Consumo del servicio” serán desplegados en el directorio. Esto se asocia con un registro de despliegue en un repositorio que modela el entorno de despliegue. Las políticas SLA soportadas serán un metadato importante para la operación exitosa de un servicio. El servicio recibe un punto final para el despliegue en una infraestructura de producción debidamente diseñada. Los equipos de soporte serán entrenados y se establecerán los procesos apropiados para el soporte en los diversos roles (negocios vs TI). El acceso a las consolas y los reportes de servicio se autorizará para estos roles. Operación del Servicio Esta es la actividad más importante como el retorno de la inversión se realizará a través de la operación de los Servicios en la producción. La infraestructura de gestión hará lo siguiente: Virtualización del servicio. Medición del servicio (medición del uso de los clientes y medición de los recursos). Detección dinámica de los extremos del servicio. Tiempo de funcionamiento y gestión del rendimiento. Aplicación de políticas de seguridad (autenticación, autorización, privacidad de datos, etc.). Cumplimiento de los SLA sobre la base de la relación de aprovisionamiento. Generación de alertas de negocio así como tecnológicas para la operación simplificada del servicio. Suministro de interfaces de administración para diferentes roles. Generación de registros y bitácoras de auditoría. Aprovisionamiento dinámico (instancias adicionales del servicio si es necesario). Seguimiento de las transacciones y generación de estadísticas de COMMIT/ROLLBACK. Integración adecuada con las herramientas de gestión de sistemas. Versionado del servicio, el contrato y los metadatos. Cumplimiento de las políticas de desmantelamiento del servicio. Presentación de informes.
- 60. 48 Capítulo 2: Mensajes y Servicios Consumo del servicio Esta actividad es igualmente aplicable a los consumidores y proveedores de servicios ya que los proveedores también pueden consumir servicios. Durante esta actividad, los servicios se descubrirán para conocer lo siguiente: Las políticas de seguridad del servicio. Las políticas de SLA soportadas. La semántica del servicio (desde el ciclo de vida colateral hasta la definición del servicio). Las dependencias del servicio. El aprovisionamiento del servicio (será solicitado por el consumidor). Condiciones previas y posteriores para la invocación del servicio. Esquemas de desarrollo del servicio (proxies, muestras, etc.). Artefactos de descripción del servicio. Análisis de impacto del servicio. Otra documentación (legible por máquina, así como para el consumo humano). Durante esta actividad, los consumidores del servicio estarán autorizados para descubrir el servicio y sus metadatos. Los SLAs serán ajustados para alcanzar el nivel deseado de disponibilidad sobre la base del contrato negociado. Gestión de los cambios del servicio Los servicios, como cualquier otro activo de aplicaciones de TI, pasarán por varias iteraciones durante su vida útil. Los contratos de servicio van a cambiar, la seguridad del servicio, así como las políticas de SLA, cambiarán, la aplicación va a cambiar, y la plataforma tecnológica puede cambiar. Algunos de los cambios mencionados pueden ser cambios importantes. Por lo tanto, la infraestructura de gestión tiene que ser resistente a todas las mutaciones mediante el soporte necesario de despliegue en todas las dimensiones mencionadas. Desactivación del servicio Como resultado de un cambio en la estrategia de negocios, o como resultado de mejores alternativas, o como resultado de menor interés de los consumidores, un servicio podrá decidir su clausura. La gestión de la infraestructura debe ser capaz de hacer cumplir las políticas de jubilación sirviendo gentilmente a los consumidores hasta la última solicitud.
- 61. Capítulo 2: Mensajes y Servicios 49 Escenarios SOA Hay una serie de escenarios empresariales y técnicos en los que SOA proporciona un claro beneficio. En esta sección se enumeran varios de los escenarios más utilizados para SOA (no es una lista completa). Integración de la información El escenario de integración de la información se refiere a veces como la “vista unificada del problema del cliente”. La descripción completa del cliente puede estar distribuida a través de una docena de aplicaciones empresariales y bases de datos. Esta información está raramente sincronizada, y la integración de esta información para la interacción óptima del cliente (o socio o empleado) tiene un soporte pobre. Los servicios de integración de información son un medio eficaz tanto para la presentación de su portafolio de aplicaciones con una visión unificada de las entidades claves, y también para garantizar la coherencia de la información a través de todos sus sistemas de apoyo. Pueden ejecutarse proyectos de integración de la información desde la táctica a la estratégica general; haciendo gradualmente re-ingeniería del acceso a la información y la gestión de toda la empresa. Este escenario se asocia frecuentemente con los siguientes acrónimos de la industria (cada uno de los cuales se usa en muchos casos indistintamente): MDM: Gestión de Datos Maestros. Es un enfoque para proporcionar y mantener una visión coherente de las entidades empresariales de base de la organización (no sólo los clientes). EII: Integración de la Información Empresarial. Es un concepto más amplio que el MDM, con una abstracción de datos para afrontar los desafíos asociados típicamente con la heterogeneidad de los datos y el contexto. CDI: Integración de los Datos de los Clientes. Es la combinación de las tecnologías, procesos y servicios necesarios para crear y mantener una visión completa de los clientes en múltiples canales, líneas de negocio y empresas. CDI está normalmente asociada con los sistemas de CRM. En el capítulo 4 se discute en mayor detalle el escenario de integración de la información. Integración de sistemas heredados El escenario de integración de sistemas heredados se centra en el uso táctico de los servicios para preservar las inversiones existentes en aplicaciones de negocio, al mismo tiempo que se amplían las funcionalidades de las capacidades que ellos entregan. Por ejemplo, un servicio podría añadir soporte para cumplir con nuevas regulaciones frente a un paquete de ERP existente. Las aplicaciones serían rediseñadas para el intercambio de mensajes con el servicio, el cual extraería los datos relevantes para el cumplimiento y comunicaría la solicitud al paquete ERP. Gobernabilidad de procesos La gobernabilidad es mucho más amplia que la integración de información o de sistemas heredados. En un escenario de gobernabilidad, los elementos de "encabezado" se utilizan para comunicar metadatos claves del negocio, desde el tiempo de respuesta de las peticiones del cliente hasta la identidad de los que aprueban decisiones empresariales
- 62. 50 Capítulo 2: Mensajes y Servicios específicas. Estos metadatos son capturados por un Servicio de Utilidades (como se explicó anteriormente), para el análisis en tiempo real y/o agregado. Los "servicios nativos" de los procesos incluyen esta información en los encabezados SOAP, mientras que las aplicaciones no nativas tendrían que ser re-diseñadas para transmitir los metadatos como un mensaje al servidor de gobernabilidad. Acceso consistente El acceso constante es un escenario más técnico y sutilmente diferente que cualquiera de los escenarios anteriores. Este escenario habilita una capa de servicios para garantizar una aplicación coherente de varios requerimientos de funcionamiento, cuando un conjunto diverso de aplicaciones necesita conectarse a un recurso crítico de fondo. Al exigir que todos los accesos se enruten a través de un servicio de fachada, una organización pudiera reforzar la autorización coherente de acceso, la distribución de costos y el balance de carga. Virtualización de los recursos Un escenario de virtualización de recursos puede ser utilizado para ayudar a reforzar el acoplamiento flexible entre los recursos y los consumidores, aislando de manera eficaz a los consumidores de los detalles de implementación de los recursos involucrados. Ejemplos típicos de la virtualización de recursos pueden ser: Enrutamiento de solicitudes sensibles al contexto y al contenido, como el envío de una investigación de bienes raíces al agente de la región geográfica específica que se especializa en propiedades agrícolas. Enrutamiento de solicitudes para almacenes de información particionada (sin requerir que el solicitante comprenda los esquemas de partición). Balance de carga de las solicitudes entre los recursos disponibles, desde los representantes de los servicios cliente hasta flujos provenientes de señales de video. Externalización de procesos Los escenarios de externalización de procesos utilizan servicios Web para ayudar a negociar de forma segura procesos comunes como el procesamiento de la nómina, los reembolsos de gastos de los empleados, y el apoyo logístico. Los proveedores de servicios de telefonía celular y los portales de Internet suelen utilizar servicios Web para agregar contenido, mientras que las organizaciones que tratan directamente con clientes pueden utilizar servicios para construir ofertas compuestas (como paquetes de viajes que incluyen vuelos y renta de autos). La clave para el éxito de la externalización de procesos en el marco de las tecnologías de hoy, es la gestión de las expectativas propias. Acomode sus necesidades a los límites de las tecnologías existentes, de modo que usted no invierta sus ganancias o ahorros en la construcción de una infraestructura de servicios que va a tener que sustituir en un plazo de pocos años. Otros escenarios Hay demasiados escenarios SOA para documentarlos todos. Los escenarios expuestos anteriormente representan algunos de los escenarios más comunes en los que hemos visto a SOA tener éxito. Otro escenario común es la interacción humana. ¿Cómo pueden los servicios dentro de una SOA interactuar con los usuarios finales?
- 63. Capítulo 2: Mensajes y Servicios 51 SOA y el usuario final Figura 5: Comparando sistemas y usuarios La Integración de Aplicaciones Empresariales (EAI) se refiere por lo general a la integración de sistema a sistema, haciendo caso omiso de las interacciones humano-computadora. Las interacciones de sistema a sistema tienden a ser muy estructuradas en términos de procesos y datos - por ejemplo, un proceso de retiro de efectivo utiliza procesos bien definidos (Procesos de Orden de Compra) y documentos de negocio (Orden de Compra). Las interacciones de sistema a sistema rara vez reflejan el mundo real. Los procesos tienden a seguir lo que tradicionalmente se denomina el “feliz camino”, ya que las excepciones rara vez se manejan con eficacia. Como la gente trabaja en el mundo real es muy diferente - los procesos son ad-hoc y pueden cambiar con frecuencia dentro de un período de tiempo determinado. Los datos con los que trabajamos igualmente no están estructurados, ya que pueden tomar la forma de documentos de Office, vídeos, archivos de sonido, y otros formatos. La intersección de estos dos mundos representa la intersección de las interacciones de sistema a sistema, y los flujos de trabajo humanos (vamos a discutir este tema con mayor detalle en el capítulo 3). Las aplicaciones que dan un soporte efectivo a estos flujos de trabajo humanos pueden ser difíciles de diseñar y desarrollar. La gran mayoría de los usuarios finales utilizan hoy en día Microsoft Office para el correo electrónico y el trabajo con la información. Microsoft Office representa el resultado de muchos años de investigación e inversiones orientadas a un soporte efectivo de los flujos de trabajo humanos (tanto en términos de datos como de procesos). Microsoft Office 2007 ha evolucionado hasta convertirse en una plataforma de integración de primera clase, ofreciendo una interacción con el usuario familiar para el consumo de servicios, lo que permite: Modelos para muchos conceptos de negocio incluidas las entidades de negocios, eventos de negocio y reglas de negocio conducidas por eventos, asignación y cumplimiento de tareas, modelado de los flujos de trabajo, y muchos otros. Un modelo de ciclo de vida de la aplicación con personalización y control de versiones, auto despliegue con intervención humana nula, y gestión del ciclo de vida completo. Herramientas de soporte para la creación de modelos, la composición y la gestión de aplicaciones a todo lo largo del ciclo de vida, basadas en Visual Studio Tools for Office
- 64. 52 Capítulo 2: Mensajes y Servicios (VSTO) y otras herramientas de la plataforma. Microsoft Office soporta la gestión de eventos simples para las líneas de negocio (LOB) comunes, incluyendo eventos de sincronización de los flujos de trabajo. Como la mayoría de los requerimientos para la integración del contenido de LOB con Office giran en torno a las entidades empresariales como la cuenta, la factura, el presupuesto y el producto, las entidades de negocio de Office están expuestas de una manera que generan un valor único para el trabajador del conocimiento. Los modelos de entidad-relación no son nuevos. El diseño de las aplicaciones de negocio se ha basado tradicionalmente en las entidades de negocio, junto con las reglas de negocio y la lógica asociada a los datos. Las entidades de negocio de Office (OBE) tienen algunos aspectos especiales: Las OBEs pueden convertirse en contenido nativo de Office, manteniendo el vínculo con las fuentes de la LOB, al mismo tiempo que se exponen a todas las reglas y las características de la aplicación de Office en la que el contenido es nativo. Por ejemplo, una lista de piezas en una entidad de producto se puede insertar como una tabla en Word, manteniendo al mismo tiempo la capacidad de actualizar los datos de la fuente en la aplicación de LOB. Esta es una especie de etiqueta inteligente de auto-descripción que no tiene que ser especificada, lo que tiene de especial su comportamiento está integrado en el contenido. Las OBEs pueden ser tratadas como ciudadanos de primera clase del mundo Office. Las OBEs serán usadas fuera de línea, adjuntadas a un correo electrónico, creadas, correlacionadas, compartidas y editadas en entornos de colaboración como SharePoint y Groove5 con control del usuario sobre la relación de sus datos con los datos de las LOB fuentes. La mayor parte del trabajo con el conocimiento en un negocio ocurre en aplicaciones como Excel, Word y Outlook, antes, después y al margen de la creación de los datos, por ejemplo, una cotización que se crea o se actualiza debe ser manipulada por muchas personas antes de salvarse en el sistema. La labor empresarial es como un mundo tridimensional creativo y colaborativo, del que las aplicaciones transaccionales capturan una proyección bidimensional de los datos confirmados. Con el amistoso comportamiento tipo Office de las OBE, el ciclo de vida del uso de los datos puede mantener la coherencia sin recurrir a la práctica torpe y propensa a errores de cortar y pegar entre el mundo de los documentos y el mundo de las aplicaciones de negocios. Las OBEs están asociadas con las definiciones de interfaz de usuario reutilizables que pueden ser utilizadas en el desarrollo rápido de aplicaciones (RAD) para producir soluciones de negocio en un plazo breve. Las partes de la interfaz de usuario pueden estar asociadas con vistas de las OBE, que pueden ser usadas a su vez en una operación de arrastrar y soltar para explorar datos de la LOB dentro de Office. Las relaciones entre las partes de la interfaz de usuario pueden navegarse de forma dinámica con el uso de enlaces, creando una interacción tipo Web en torno a las entidades comerciales. El cliente de tiempo de ejecución también proporciona un modelo de programación declarativa que permite que la interacción del usuario sea movida por los eventos contextuales estándares de Office (como abrir elemento) con la interacción personalizada por parámetros tales como el rol y la configuración regional. El contenido de las OBEs se puede acotar al contenido de las entidades de Office, sin llegar a ser una parte de ella. Esto es más fácil de observar en los elementos de Outlook, 5 Producto orientado a la colaboración que fue el antecesor de SharePoint.
- 65. Capítulo 2: Mensajes y Servicios 53 donde, por ejemplo, un elemento de contacto en Outlook puede ser enlazado a un contacto del cliente en un sistema de CRM. Tanto la entidad de Outlook como la entidad CRM existen de forma independiente, cada una con su propia identidad y conducta, pero algunas de sus propiedades son compartidas conceptualmente por estar ligadas entre sí y sincronizarse automáticamente. Así, un híbrido de entidad Outlook/CRM se crea conceptualmente con correlación y sincronización de datos en lugar de compartir los datos. Esto se hace visible en Outlook como datos extendidos y la interacción del usuario con tales contactos híbridos; explorando datos y comportamiento de contactos CRM como una extensión de la interfaz de usuario de los contactos de Outlook. Las entidades híbridas crean una asociación profunda, pero no invasiva. El uso de entidades híbridas Office/LOB es más interesante para los elementos de Outlook actualmente, porque los elementos de Outlook poseen una firme identidad que es necesaria para la correlación con las OBE. Como el uso compartido de documentos se presenta en entornos SharePoint/Grove más controlados como parte de procesos como la compilación de documentos, basados por ejemplo en las plantillas de Word, tales como contrato o “RFP”, más entidades de Office ganarán nuevas identidades estables y estarán disponibles para la correlación de dos vías con las OBEs. Las entidades LOB, en muchos casos están fragmentadas en los silos de datos y los datos en estos silos son a menudo de dudosa calidad. Las OBEs pueden ocultar estos problemas, a medida que crean una rica interacción con el usuario muy vinculada al contexto de trabajo real del trabajador del conocimiento. ¿Qué son las aplicaciones compuestas? Una aplicación compuesta es una colección de activos de software que han sido ensamblados para ofrecer una capacidad de negocio. Estos activos son artefactos que se pueden implementar de manera independiente, permiten la composición, y aprovechan las capacidades específicas de la plataforma. En el pasado, los activos de software de una empresa eran, por lo general, un conjunto de aplicaciones independientes, monolíticas y mal integradas unas con otras. Sin embargo, para obtener los beneficios de negocio de la composición, una empresa debe tratar a sus activos de software de una manera más granular, y los diferentes niveles de la arquitectura requieren diferentes tipos de activos tales como activos de presentación, activos de aplicación, y activos de datos. Por ejemplo, un servicio Web puede ser un activo de aplicación, un cubo OLAP puede ser un activo de datos, y una pantalla de entrada de datos en particular, puede ser un activo de presentación. Un inventario de activos de software, por sí solo, no habilita las aplicaciones compuestas. Esto requiere de una plataforma con capacidad para la composición, es decir, una plataforma que ofrezca la capacidad de desplegar activos independientemente unos de otros, y en combinación con los demás. En otras palabras, estos activos deben ser componentes, y la plataforma debe proporcionar contenedores.
- 66. 54 Capítulo 2: Mensajes y Servicios Figura 6: Representación de alto nivel de una aplicación compuesta Los contenedores proporcionados por la plataforma deben ser de diferentes tipos, que se mapean a los diferentes niveles de la arquitectura. Las arquitecturas empresariales suelen descomponerse en tres niveles: presentación, aplicación (o la lógica de negocio), y los datos. De modo que la plataforma debe proporcionar contenedores para estos. Sin embargo, la arquitectura de 3 capas asume los procesos empresariales y los datos estructurados, donde todos los requisitos se dan a conocer durante el proceso de diseño y construcción del sistema. Por su propia naturaleza, las aplicaciones compuestas suponen que la composición de las soluciones puede ocurrir después que los activos se han construido y desplegado - y por tanto requieren tener en cuenta, de forma explícita, las interacciones entre los profesionales de la información que son esenciales para completar cualquier proceso de negocio. Por lo general, estas interacciones no son capturadas por procesos estructurados, o aplicaciones tradicionales de negocios, y por lo tanto, es fundamental agregar un cuarto nivel - el nivel de productividad - para tener en cuenta estas interacciones humanas. Esto se muestra en la Figura 7.
- 67. Capítulo 2: Mensajes y Servicios 55 Figura 7: Los cuatro niveles de una aplicación compuesta Las discusiones tradicionales acerca de la arquitectura de las aplicaciones de negocio tienden a centrarse en el nivel de aplicación como la conexión entre personas y datos. Típicamente, sin embargo, el nivel de aplicación contiene una lógica de negocio estructurada, y esto es válido para las discusiones en torno a Arquitecturas Orientadas a Servicios (SOA), a los Buses Empresariales de Servicios (ESB), a las Arquitecturas de Componentes de Servicios (SCA), o a la mayoría de las otras perspectivas arquitectónicas existentes en la industria hoy en día - incluyendo la primera generación de debates en torno a las aplicaciones compuestas. Sin embargo, la construcción de una aplicación compuesta requiere una mentalidad en la que no sólo la productividad es vista como un elemento crítico, sino que también contiene el valor del negocio. Para ampliar la comparación entre las aplicaciones compuestas y SOA, ambos apuntan a la flexibilidad y modularización. Sin embargo, SOA proporciona flexibilidad en un solo nivel: la lógica de negocio estructurada en el nivel intermedio. Las aplicaciones compuestas apuntan a la flexibilidad en los cuatro niveles. Dicho esto, una aplicación compuesta es una gran manera de explorar la información de una SOA, y teniendo expuestas las líneas de negocio (LOB) como servicios hace que sea más fácil dar el soporte a procesos de funciones cruzadas en una aplicación compuesta. Por lo tanto, para diseñar una aplicación compuesta, un arquitecto de soluciones debe: Elegir un arsenal de composición - Elija uno o más contenedores para cada nivel, y un conjunto de tipos de componentes que se despliegue en esos contenedores. Elegir los componentes - Defina el repositorio de activos que debe ser construido a partir de este conjunto de tipos de componentes, en base a las necesidades del negocio. Especificar la aplicación compuesta - Defina las formas en que los activos se conectarán, para proporcionar un determinado proceso multifuncional. La plataforma debe permitir que estas conexiones sean de acoplamiento flexible. Luego, después de la implementación, los usuarios tendrán la oportunidad de personalizar
- 68. 56 Capítulo 2: Mensajes y Servicios tanto los activos como las conexiones, de la misma forma que el arsenal de composición debería permitir esto a través del acoplamiento flexible y los mecanismos de extensibilidad. Figura 8: La arquitectura de una aplicación compuesta ¿Cuál es la apariencia de una aplicación compuesta? Una representación figurativa de una aplicación compuesta se muestra en la Figura 7, que muestra una representación muy abstracta de una solución empresarial. En la parte superior están los trabajadores de la información, que tienen acceso a la información empresarial y de los documentos a través de portales que son vistas específicas por roles en la empresa. Ellos crean documentos específicos durante el transcurso de sus actividades de negocio, y estas actividades son parte de procesos de negocio más grandes. Estos procesos coordinan las actividades de las personas y los sistemas. Las actividades de los sistemas se controlan a través de reglas de negocio específicas de los procesos que invocan las aplicaciones de LOB y recursos a través de interfaces de servicios. Las actividades de las personas se conectan a los procesos a través de eventos que ocurren cuando se crean o modifican documentos específicos del proceso. A continuación se aplican las reglas de negocio al contenido de esos documentos, para obtener información, transformarla, y transferirla a la siguiente etapa del proceso.
- 69. Capítulo 2: Mensajes y Servicios 57 Figura 9: Desarmando una aplicación empresarial Hoy en día la mayoría de las aplicaciones de línea de negocio (LOB) son una colección de recursos, procesos de negocio alambrados en el código, e interfaces de usuario inflexibles. Sin embargo, sobre la base de la sección anterior, queda claro que las soluciones de la empresa necesitan dividirse en un conjunto de activos granulares que se pueden ensamblar en aplicaciones compuestas. Un enfoque de alto nivel para hacer esto a cualquier proceso de negocio es el siguiente: 1. Descomponer la solución para un proceso de negocio en los activos de software correspondiente a los elementos mostrados en la Tabla 1. 2. Empaquetar todos los activos correspondientes a un proceso de negocio dado en un “paquete de procesos” para la redistribución y el despliegue. Este contendría los componentes de software y metadatos, y las plantillas de solución para combinarlos. El paquete de proceso contendría también definiciones de la interfaz de servicios que permiten las conexiones con otros sistemas TI. Estas conexiones se habilitarían implementando las interfaces de servicios, por ejemplo, para conectarse a las aplicaciones de LOB y los datos. El objetivo es ser capaz de crear fácilmente una capa de procesos de negocio estandarizados en cualquier entorno de TI heterogéneo. 3. Desplegar el paquete de procesos en una plataforma que proporcione contenedores para los tipos de activos en que se ha descompuesto la solución. La plataforma debe proporcionar capacidades para la rápida personalización, reconfiguración, y ensamblado
- 70. 58 Capítulo 2: Mensajes y Servicios de los activos. 4. Conectar los activos dentro del paquete de procesos, a los sistemas LOB existentes, y otros recursos de la empresa mediante la implementación de las interfaces de servicios. Estas conexiones podrían hacerse usando la tecnología de los servicios Web, otros tipos de adaptadores personalizados o incluso, potencialmente, protocolos de Internet como RSS. Documentos Pantallas de interfaz de usuario (UI) Flujos Conexiones de datos Actividades de negocio Autorizaciones Reglas de negocio Reportes Esquemas Métricas Interfaces para conectarse a los sistemas (APIs) Tabla 1: Lista de los activos de aplicación para composición Beneficios esperados de la composición y como alcanzarla El despliegue de aplicaciones empresariales debe estar vinculado a los beneficios del negocio en un sentido de Triple A (agilidad, adaptabilidad, alineación). Es necesario demostrar estos beneficios desde dos perspectivas: La perspectiva del proveedor de soluciones (o perspectiva del desarrollador) - Este es el punto de vista de la organización que construye una aplicación empresarial. Esta podría ser un vendedor de software independiente (ISV), o un integrador de sistemas (SI), o incluso un departamento de TI en la propia organización. La perspectiva del proveedor de la solución se ocupa principalmente de los beneficios obtenidos en las actividades relacionadas con el diseño, la implementación y el despliegue de las aplicaciones empresariales. La perspectiva del consumidor de la solución (o perspectiva del usuario) - Este es el punto de vista de la organización que utiliza una aplicación empresarial. Por lo general, esta es la unidad de negocio que encargó la aplicación empresarial. La perspectiva del consumidor de la solución se ocupa principalmente de los beneficios obtenidos por la empresa después que la solución ha entrado en producción. Los beneficios de la composición que se pueden esperar razonablemente en cada una de estas dos perspectivas figuran en esta lista, junto con algunas de las mejores prácticas de alto nivel para lograr estos beneficios esperados.
- 71. Capítulo 2: Mensajes y Servicios 59 Resumen En este capítulo se examina el concepto de SOA desde la perspectiva de los servicios: madurez arquitectónica y organizacional, tipos de servicios, ciclo de vida de los servicios, escenarios y el papel de los usuarios y las aplicaciones compuestas dentro de una iniciativa SOA. La arquitectura orientada a servicios (SOA) es un enfoque de diseño para la organización de los activos de TI existentes, de modo que los conjuntos heterogéneos de sistemas y aplicaciones complejas y distribuidas se puedan transformar en una red de recursos simplificados, integrados y altamente flexibles. Un proyecto SOA bien ejecutado alinea los recursos de TI de forma más directa con los objetivos empresariales, ayudando a las organizaciones a construir conexiones más fuertes con los clientes y proveedores, ofreciendo información de inteligencia de negocios más exacta y oportuna para que puedan tomarse mejores decisiones, y ayudando a las empresas a optimizar los procesos de negocio y el intercambio de información con vistas a aumentar la productividad de los empleados. El resultado neto es un aumento de la agilidad de la organización. En una arquitectura SOA, el concepto de aplicaciones todavía existe, especialmente si se considera una empresa con inversiones en TI. Sin embargo, el concepto de un fabricante que proporciona una “solución SOA” completa con un conjunto monolítico de productos está siendo sustituido por un enfoque de “lo mejor del mercado”, permitiendo a los clientes adoptar un enfoque basado en las capacidades para implementar sus requerimientos arquitectónicos. Las organizaciones deben permanecer enfocadas en la solución de sus problemas de negocio y evitar distraerse con las tendencias de integración y las palabras de moda. SOA debe ser un medio para hacer el negocio más ágil, no la meta final. El diseño y la implementación de SOA deben ser procesos graduales con despliegues rápidos y un retorno de la inversión adecuado. SOA no debe ser un esfuerzo de arriba hacia debajo de varios años “hirviendo el océano” - este tipo de proyectos rara vez tienen éxito porque son incapaces de mantenerse al día con las cambiantes necesidades de la organización. Los usuarios también sufrirán una transformación en la forma de trabajar con las aplicaciones. Dependiendo del tipo de aplicación, el usuario podría estar expuesto a tareas específicas de un proceso, por ejemplo, el trabajo en el contexto de un flujo de documentos en Microsoft Office SharePoint Server, o bien, una aplicación puede encapsular un proceso de negocio internamente, y permitir al usuario iniciar el proceso, pero no interactuar con él durante su ejecución.
- 72. 60 Capítulo 2: Mensajes y Servicios Estudio de caso SOA: Banco del Commonwealth en Australia Este estudio de caso describe cómo el Banco del Commonwealth en Australia diseñó, desarrolló e implementó su aplicación CommSee - una solución de relaciones de banca, desarrollada y personalizada por el Banco del Commonwealth en Australia usando Microsoft ® .NET. Esta solución fue desarrollada como un cliente inteligente desktop de Microsoft ® Windows ® que consume servicios Web .NET basados en estándares. Los servicios Web son responsables de orquestar los datos de una variedad de fuentes de datos, incluyendo mainframes, bases de datos, y varios sistemas legados. En el momento de escribir estas líneas, CommSee ha sido desplegado con éxito en más de 1.700 lugares de toda Australia atendiendo a más de 30.000 usuarios. Después de considerar las necesidades de negocio para las que CommSee fue diseñado, este caso de estudio examinará la arquitectura de la solución, los detalles técnicos del proyecto, y las mejores prácticas empleadas en este importante esfuerzo de desarrollo de software. Esquema arquitectónico general del CBA El estudio de caso completo se encuentra disponible en: http://msdn2.microsoft.com/en-us/library/bb190159.aspx. . Otros estudios de caso SOA pueden consultarse en: http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA.
- 73. 61 Capítulo 3: Flujos y procesos "El arte del progreso es mantener el orden en medio del cambio, y preservar el cambio en medio del orden." - Alfred North Whitehead Matemático, filósofo (1861-1947) Guía para el lector Los lectores de este capítulo continuarán desarrollando los conceptos introducidos en los capítulos previos, centrándose concretamente en la capacidad arquitectónica de flujos y procesos. Figura 1: Capacidades arquitectónicas recurrentes La capacidad arquitectónica de flujos y procesos se centra en el concepto de flujo y cómo se pueden utilizar los flujos para orquestar y agregar servicios granulares en ensamblados mayores que denominamos procesos. Los temas discutidos en este capítulo incluyen: Explicar los conceptos relacionados con los flujos. Aclarar la relación de BPM, SOA, orquestación y coreografía con los flujos. Describir las capacidades necesarias para dar soporte a los flujos. Exponer los beneficios de la adopción de un enfoque basado en modelos para los flujos.
- 74. 62 Capítulo 3: Flujos y procesos Entendiendo los flujos ¿Qué es un flujo? El concepto de flujo de trabajo no es nuevo. Las tecnologías de flujos surgieron por primera vez a mediados de 1970 con simples prototipos de automatización de oficinas en Xerox Parc y la Escuela de Negocios Wharton de la Universidad de Pennsylvania. El interés en los flujos de trabajo y la automatización de la oficina comenzó a decaer en la década de 1990 hasta que el libro Reingeniería de la Corporación reavivó el interés en los flujos de trabajo y procesos de negocio. La tendencia de reingeniería de la década de 1990 nos dio varios libros y metodologías para el análisis de procesos - por desgracia, las tecnologías como CASE y otras de esa especie estaban inmaduras y requerían una intervención manual importante, exponiendo a los proyectos y directivos a niveles significativos de riesgo. Peor aún, otros “productos de flujos de trabajo” fueron esfuerzos encubiertos para vender hardware, tales como escáneres, impresoras y otros periféricos. Claramente, se ha abusado del término “flujo de trabajo” para aprovecharse de la confusión en el mercado. Entonces, ¿qué es el flujo de trabajo? El flujo de trabajo consiste fundamentalmente en la organización del trabajo. Se trata de un conjunto de actividades que coordinan gente y/o software. La comunicación de esta organización para los humanos y los procesos automatizados es el valor añadido que proporciona el flujo de trabajo a nuestras soluciones. Los flujos de trabajo son fractales. Esto significa que un flujo de trabajo puede consistir en otros flujos de trabajo (cada uno de los cuales puede constar de servicios agregados). El modelo de flujo de trabajo fomenta la reutilización y la agilidad, dando lugar a procesos de negocio más flexibles. Terminología utilizada en los flujos de trabajo Como se ha mencionado antes, los flujos de trabajo tienen que ver con la organización del trabajo. Esto es una definición muy amplia y puede interpretarse de diferentes formas. Para evitar confusión identificaremos varios términos que se asocian comúnmente con el concepto de flujo de trabajo: Gestión de los procesos de negocio (BPM): BPM es una filosofía de negocios que ve los procesos como un conjunto de activos competitivos para ser gestionados. Los procesos que los negocios buscan para gestionar están compuestos dentro de una infraestructura SOA y son ejecutados por ella. SOA y BPM tienen varios objetivos en común: o Ambos está enfocados en hacer la organización más ágil. SOA se centra en proporcionar una infraestructura de acoplamiento flexible para la habilitación de los servicios mientras que BPM se enfoca en diseñar y gestionar procesos de negocio acoplados flexiblemente (los cuales son agregaciones de servicios granulares). o Ambos buscan hacer los negocios proactivos en lugar de reactivos. Un negocio proactivo es capaz de vislumbrar patrones de mercado, tendencias y amenazas competitivas antes de que puedan impactar negativamente en la organización. La simple identificación de una amenaza o una oportunidad no es suficiente – la organización tiene que ser capaz también de modificar proactivamente sus procesos para tomar ventaja de la oportunidad (o evitar la amenaza). Alcanzar este nivel de agilidad requiere procesos de negocio acoplados flexiblemente encima de los cuales hay una infraestructura SOA capaz de dar soporte a rápidas reconfiguraciones para
- 75. Capítulo 3: Flujos y procesos 63 satisfacer las necesidades de la organización. o Ambos se enfocan en los procesos en vez de centrarse en las capacidades funcionales. Los procesos ya no pueden estar restringidos por un conjunto limitado de capacidades funcionales - una infraestructura SOA es una fábrica de servicios configurables y componibles que se pueden ensamblar y desensamblar, o reconfigurarse para satisfacer las cambiantes necesidades de negocio de la organización. Orquestación: Los flujos de trabajo y las orquestaciones son efectivamente la misma cosa ya que cada uno está diseñado para componer y ejecutar una serie de funciones. Las orquestaciones requieren un “conductor” que se encarga siempre de la ejecución. El conductor se manifiesta típicamente como un servidor de integración (como BizTalk Server) que monitorea la ejecución, lanza eventos, crea bitácoras de ejecución y realiza otras tareas para asegurar que el proceso se ejecuta como se esperaba. Coreografía: La coreografía es un conjunto de relaciones punto a punto entre los participantes individuales. No hay “conductor” en una coreografía. Los participantes interactúan entre sí sobre la base de un conjunto de principios acordados o contratos. Por ejemplo, un proveedor podría entrar en un acuerdo con un minorista para despacharle un conjunto específico de bienes y servicios en un plazo determinado. Esto significa que el proveedor y el minorista deben acordar eventos empresariales, documentos comerciales, acuerdos sobre el nivel de servicio (SLAs) y penalizaciones si los SLAs no se cumplen. El proveedor puede establecer, a su vez, otro acuerdo con un fabricante para obtener las materias primas que necesita para satisfacer las demandas del minorista. Una coreografía suele implementarse dividiendola en varias orquestaciones (una para cada participante involucrado en la coreografía). Las discusiones sobre flujos de trabajo suelen mencionar con frecuencia alguno de los términos explicados anteriormente, sin embargo, la orquestación es el único término que es comparable con el concepto de flujo de trabajo. ¿Por qué flujos de trabajo? Los problemas en que se ha aplicado un enfoque de flujos de trabajo presentan a menudo tres características: el valor de negocio clave entregado es la coordinación, por ejemplo, en la organización de múltiples contribuciones para la preparación de una cotización o al conducir una revisión de documentos. En segundo lugar, cada instancia del proceso de negocio en cuestión es de larga duración, medido a menudo en días, semanas, o meses, en lugar de minutos. Finalmente, el proceso de negocio cuenta con participantes humanos, que por lo general aportan la mayor parte del trabajo. Sin embargo, sólo una pequeña proporción de los problemas de negocio de estas características se resuelven usando un enfoque de flujos de trabajo. Por lo general, los procesos de negocio no se almacenan como información legible por computadoras. Más bien, cada uno de los humanos que participa en el proceso de negocio interactúa con los sistemas que no están conscientes de la semántica del proceso en su conjunto, como un sistema de información de clientes, y con otros participantes humanos a través de canales de comunicación independientes del contenido como el correo electrónico. Cada actor humano utiliza un modelo mental de su participación en el proceso general de negocio para determinar su comportamiento.
- 76. 64 Capítulo 3: Flujos y procesos Tres beneficios claves que puede traer un modelo de flujo de trabajo son conocimiento, monitoreo y optimización. Un conjunto de modelos de flujos relacionados se puede utilizar para ganar conocimiento sobre el flujo de trabajo dentro de una organización. Para el monitoreo, el conocimiento de cuales individuos están aportando trabajo a cuales procesos de negocio es muy útil cuando se intenta comprender los costos y las cargas de trabajo. Para la optimización, tener un modelo de la labor que se está realizando, y ser capaz de utilizar el modelo para interpretar el comportamiento, hacen posible, de conjunto, razonar acerca de cómo optimizar los procesos de negocio. El concepto de que un enfoque basado en modelos es atractivo no es nada nuevo - los desarrolladores han estado usando UML y otras técnicas de modelado por muchos años antes de la maduración de las herramientas de desarrollo con flujos de trabajo. Los flujos de trabajo proporcionan tanto un modelo secuencial como de máquina de estado, que se utiliza para desarrollar, gestionar y dirigir el flujo de trabajo. Un modelo de flujos de trabajo Teniendo en cuenta estos importantes beneficios, ¿por qué no se han empleado más ampliamente los modelos de flujos de trabajo? La respuesta más probable es que el costo de su uso ha sido demasiado alto. Estos costos incluyen los costos del producto, esto es, el costo directo de la compra de un producto de flujo de trabajo, los costos de integración, donde los procesos modelados como flujos de trabajo deben ser integrados como parte de un sistema de negocios más grande, y los costos de la estandarización, donde es difícil para una organización grande estandarizar una tecnología de flujos de trabajo única. Las variaciones en los productos de flujos de trabajo también significan que las habilidades y la portabilidad del modelo son aspectos esenciales. Echemos un vistazo a la posibilidad de abordar estos problemas de bloqueo mediante la construcción de aplicaciones sobre una plataforma de flujos de trabajo que es de bajo costo, ubicua, uniforme y que se integra fácilmente en las aplicaciones. Para ser claros, la idea no es sustituir a los productos de flujo de trabajo. Por el contrario, la hipótesis es que resulta útil descomponer el soporte de algunos conceptos centrales de los flujos de trabajo en una plataforma en la que se puedan construir tanto los productos de flujo de trabajo como otras aplicaciones (ver Figura 2 más abajo). Figura 2: Flujo monolítico Un flujo de trabajo es un modelo, lo que significa que es una descripción legible por la computadora del comportamiento del negocio que no es código. El significado y las ventajas de este concepto en el contexto del valor de una plataforma de flujos de trabajo se discutirán más adelante. Un modelo de flujos de trabajo describe una organización en unidades de trabajo. Por ejemplo, supongamos que en un proceso de revisión de documentos se especifica que Joe escribe el documento y luego Fred lo revisa. En este caso, las unidades de trabajo son,
- 77. Capítulo 3: Flujos y procesos 65 primero la redacción del documento y segundo su revisión, y la organización indica que una tarea debe seguir a la otra. Este concepto no es una idea radical. Un código que realiza llamadas sucesivas a dos subrutinas es un ejemplo válido de este concepto. El interés radica más bien en las formas que toma esta organización. Para probar la hipótesis de la plataforma de flujo de trabajo, vamos a considerar una amplia gama de aplicaciones del mundo real y explorar las características que una plataforma de flujos de trabajo debe tener si ha de ser útil. Un proceso de revisión documental toma como parámetro de entrada un conjunto de pares [revisor, rol] que describen qué humanos están involucrados en el flujo de trabajo y en cuáles roles. Los valores posibles para el rol son “requerido”, “opcional”, “aprobador final”, y “propietario”. El proceso de revisión procede entonces hasta que todos los revisores hayan realizado las funciones asignadas y notifiquen al propietario de los resultados. Aquí, los elementos de trabajo son las revisiones del documento organizadas por el proceso de revisión. Hay tres características interesantes que se pueden destacar, múltiples puntos de interacción, la actividad humana y automatizada, y la necesidad de manejar el cambio dinámico. Contratos en los flujos de trabajo El flujo de trabajo tiene múltiples puntos de interacción, o contratos. En primer lugar, existe un contrato con un revisor. Este contrato consiste en pedir a un revisor que revise un documento, aceptando el veredicto y los comentarios de revisión, y también decirle a un revisor que su entrada ya no es necesaria (si la revisión se cancela, o tal vez si suficientes revisores han votado afirmativamente). El contrato también podría permitir a un revisor delegar una revisión. Luego hay un segundo contrato con el responsable de la aprobación final, que es una especialización del contrato de revisor. En tercer lugar, existe un contrato con el dueño de la revisión que permite al propietario cancelar la revisión y ser notificado de los resultados de la revisión. Por último, existe un contrato con el iniciador del proceso de revisión, que crea la instancia de revisión y suministra los parámetros requeridos. Es típico de los flujos de trabajo que se conecten a varias partes a través de una variedad de contratos (ver Figura 3). El flujo de trabajo de revisión de documentos es esencialmente un coordinador, iniciado a través de un contrato que está coordinando una gran variedad de participantes a través de uno o más contratos adicionales. El flujo de trabajo de revisión de documentos guía la actividad humana. Sin embargo, también podría conducir actividades automatizadas, como guardar versiones del documento en un repositorio a medida que progresa la revisión. Desde el punto de vista del flujo de trabajo, no hay diferencia esencial. Un flujo de trabajo puede imaginarse, en general, comunicándose con servicios mediante contratos. Un caso especial de un servicio es otro flujo de trabajo. Otro caso especial es un humano. De muchas maneras, un humano es el servicio asíncrono original: uno nunca sabe si va a responder y cuando.
- 78. 66 Capítulo 3: Flujos y procesos Figura 3: Diagrama del contrato para la revisión de documentos Una característica de este tipo de flujo de trabajo es que los participantes le pedirán cambios en el flujo de trabajo conforme se ejecuta. Por ejemplo, un revisor podría delegar una tarea de revisión a un colega o compartir el trabajo involucrado en una tarea de revisión con un subordinado. Hay dos maneras de hacer frente a este requerimiento. Uno de ellos es introducir una interpretación de todos los posibles cambios en el flujo de trabajo. Entonces, una solicitud de delegación se convierte en otra función del contrato entre el flujo de trabajo y el revisor. La otra posibilidad es ver el cambio como algo separado del flujo de trabajo, donde el cambio se implementa como una función externa que cambia el modelo de flujo de trabajo. En este enfoque, el resultado de la delegación es un nuevo modelo de flujos de trabajo idéntico a uno en que se le asignara al delegado la tarea de revisión desde el principio. La solicitud de un paso adicional de aprobación agregaría una nueva tarea de aprobación en el modelo de flujo de trabajo, que bien podría no haber contenido ningún paso de aprobación en su forma original. El flujo de trabajo ya no tiene que prever todas las posibles modificaciones, a lo sumo deberá ocuparse de restringir las áreas del modelo que están sujetas a cambio. Ambos enfoques son útiles. Introducir conocimiento en un flujo de trabajo es fácil de modelar y comprender. La generalización de las operaciones es más compleja de modelar, pero más potente y ágil. En un caso extremo pero interesante de este último enfoque, el flujo de trabajo inicia la ejecución con poco o ningún contenido, y el comportamiento requerido se añade de forma dinámica por los participantes en el flujo de trabajo. En este caso, las operaciones disponibles para modificar el flujo de trabajo se convierten en un vocabulario que un usuario puede utilizar para introducir la conducta deseada a medida que progresa el flujo de trabajo. Colaboración en la resolución de problemas Para ver un ejemplo específico de una aplicación de colaboración en la resolución de
- 79. Capítulo 3: Flujos y procesos 67 problemas, considere un déficit de inventario. Una línea de montaje está ensamblando un dispositivo, y el sistema indicó que había componentes suficientes en stock para este fin. Sin embargo, cuando el gerente de almacén fue a buscar los componentes para su entrega a la línea de montaje, fue descubierto un déficit de 10 componentes. Es necesaria entonces la colaboración entre el gerente de almacén, el gestor de la cuenta del cliente, el departamento de suministros, y el gerente de producción para resolver el problema. Cada rol en la colaboración puede tomar acciones características. El departamento de suministros podría pedir más componentes, usando tal vez un proveedor diferente o pagando un dinero extra a los proveedores existentes para acelerar la entrega. El gestor de la cuenta puede ir al cliente y solicitar entrega diferida o dividir la entrega en dos partes y asumir el costo de envío adicional. El gerente de producción podría desviar dispositivos montados para un pedido de otro cliente. El gerente de almacén puede buscar en el almacén, en un intento de encontrar los componentes perdidos. Cualquiera de estas acciones puede llevarse a cabo varias veces. Una limitación obvia es que la colaboración no se completa hasta que el déficit se resuelve mediante una combinación de las acciones anteriores. Hay a menudo también restricciones de negocio. Por ejemplo, podría haber una regla que dice que no está permitido el aplazamiento de la entrega a los clientes de oro. Asimismo, las acciones se afectan mutuamente. Por ejemplo, puede haber una política que establece que el coste adicional total de la acción correctiva no podrá exceder el 5 por ciento del costo original de producción. Por lo tanto, hacer un pedido para acelerar los suministros a un precio mayor puede impedir que el envío sea dividido. En este caso, los elementos de trabajo son las acciones que los distintos participantes pueden realizar en su intento de resolver el déficit de inventario. La organización, sin embargo, no es la misma que la requerida en la revisión de documentos. Los participantes no están obligados, sino que por el contrario, optan por cuales acciones realizar y deciden el momento de llevarlas a cabo. Sin embargo, estas opciones se ven limitadas por la organización del flujo de trabajo, que tiene dos aspectos: 1. Las acciones se centran en la consecución de un objetivo, en este caso, la solución del déficit de inventario. Un espacio de colaboración limitada se crea cuando se inicia la resolución del problema, y no se cierra hasta que el objetivo ha sido alcanzado. 2. Los participantes no son libres para llevar a cabo acciones arbitrarias. En cambio, las acciones posibles son determinadas por el rol del participante y el estado de la colaboración. El conjunto de acciones está determinado por las políticas relacionadas con el objetivo y las políticas globales, tales como la restricción en la entrega a los clientes de oro. Las acciones disponibles varían según avanza la colaboración. La experiencia de los participantes ya no es la de realizar las tareas asignadas. En cambio, un participante consulta las acciones disponibles actualmente para él o ella, realiza una o ninguna de estas acciones, y luego repite el ciclo. El principal requerimiento nuevo aquí, por tanto, es para una forma de organización de los elementos de trabajo que está basada esencialmente en los datos de estado y la meta a lograr. Hay también un requerimiento para dar soporte a un estilo de contrato de consulta/acción con los participantes del flujo de trabajo.
- 80. 68 Capítulo 3: Flujos y procesos Operaciones de secuencias de comandos Las operaciones de secuencias de comandos son simplemente un conjunto de operaciones que se componen con un guión. Un ejemplo podría ser una herramienta de desktop que permite al usuario definir y ejecutar una serie de tareas comunes, como copiar y anotar los archivos. Sería raro considerar el uso de un producto típico de flujos de trabajo para este propósito. Sin embargo, se ajusta al patrón de plataforma de flujos de trabajo correspondiente a un conjunto de unidades de trabajo organizadas por un modelo. En este caso el modelo es una secuencia, tal vez con el soporte para la ejecución de bucles y estructuras condicionales. Por lo tanto, si una plataforma de flujos de trabajo fuera lo suficientemente barata y ubicua, sería posible considerar su aplicación a este tipo de problema. ¿Agregaría algún valor hacerlo? Una de las características de las operaciones de secuencias de comandos que no se aborda en sus implementaciones típicas hoy en día es la cuestión del flujo de datos. Es común que los datos requeridos por una operación sean la salida de una operación anterior, pero esta información no suele ser modelada en el guión. Así, un usuario ensamblando tareas con una herramienta de escritorio que no se le puede decir, al crear un guión, que los datos requeridos en una tarea no han sido suministrados, y solo descubriría el error al ejecutar la secuencia. Un modelo de flujos de trabajo que puede describir estas dependencias de datos, aportaría un claro valor añadido para los autores de guiones. Un enfoque posible radica simplemente en incluir elementos de flujo de datos en el modelo de flujos de trabajo. Muy bien podría argumentarse que el modelo de flujos de trabajo básico debe incluir características estructurales básicas, tales como secuencias, condicionales y bucles, pero no está tan claro que el flujo de datos sea lo suficientemente universal como para ser representado por elementos de primera clase del modelo. Un enfoque alternativo es introducir el soporte estructurado en capas para el flujo de datos en la parte superior de un flujo de trabajo extensible básico. Un modelo de flujos de trabajo que puede ser enriquecido con abstracciones apropiadas a una variedad de dominios, encaja bien con la noción de plataforma de flujos de trabajo. Este enfoque evita tanto la complejidad creada mediante la inclusión en el modelo de base de una gran variedad de construcciones semánticas especializadas para los diferentes problemas, como también las limitaciones impuestas al restringir el modelo de flujos de trabajo a un conjunto fijo de construcciones. Ahora echemos un vistazo a una aplicación de usuario guiado. Un ejemplo es un sistema interactivo de respuestas de voz (IVR), y otro es un sistema para centros de llamadas que guía a los operadores telefónicos a través de guiones de soporte o ventas. La esencia de estas aplicaciones es guiar a los usuarios a través de la serie de operaciones necesarias para lograr su objetivo. La organización de estas operaciones se suele utilizar para conducir la presentación al usuario, ya sea una voz grabada o un conjunto de botones de comandos que se activan y desactivan en un formulario. Una característica de este tipo de aplicaciones es que el flujo de trabajo es la parte que más se cambia en la aplicación. Además, los patrocinadores del sistema están a menudo muy involucrados en la especificación de los cambios, por lo que es importante proporcionar un medio para que el personal de TI y de negocios se comuniquen de manera clara y eficaz acerca de los cambios. Un modelo de flujos de trabajo que expresa el propósito principal de la
- 81. Capítulo 3: Flujos y procesos 69 aplicación, despojado de cualesquiera detalles técnicos irrelevantes, es una forma efectiva para lograr esta comunicación. Estas aplicaciones también requieren flexibilidad en la estructura del flujo de trabajo. En una aplicación IVR el usuario normalmente estará muy limitado, moviéndose a través de un conjunto de menús estructurado jerárquicamente. Sin embargo, también habrá comandos para escapar, por ejemplo, "volver al menú raíz" o "saltar fuera del subárbol actual." Una aplicación de centro de llamadas tiene más flexibilidad que una aplicación IVR, cambiando las opciones que ofrece al usuario en respuesta al estado de un pedido o en respuesta a la entrada desde un cliente, como saltarse las preguntas de ventas si el cliente comienza a reaccionar negativamente. Este tipo de aplicación requiere disponer de soporte para una mezcla de diferentes organizaciones de los elementos de trabajo, combinaciones de secuencias, lazos, y condicionales con saltos de un estado a otro, y también el tipo de comportamiento conducido por los datos que fue visto en la sección de colaboración para la resolución de problemas. Regla y política Como se mencionó anteriormente, una forma en que el enfoque de flujos de trabajo puede aportar valor es mediante el aislamiento del foco de cambios en una aplicación. A menudo, este foco radica en la forma en que los elementos de trabajo están estructurados, pero en algunas aplicaciones del foco de cambios está en expresiones vinculadas a una estructura de evolución relativamente lenta. Un ejemplo de este foco es un sistema de cotización de pólizas de seguro, en el que se utiliza un conjunto de cálculos que cambian frecuentemente para la toma de decisiones en el proceso de cotización. El requerimiento es que el flujo de trabajo pueda modelar estas fórmulas, con dos beneficios principales: en primer lugar, los costes de las pruebas y el despliegue son mucho más bajos que los que normalmente se incurriría si las fórmulas estuvieran escritas en el código, ya que el modelo ofrece un fuerte recinto de seguridad que restringe el alcance de los posibles cambios. En segundo lugar, los cambios pueden ser realizados por personal que entiende la importancia para la empresa de las fórmulas, pero no tienen los conocimientos necesarios para entender el código técnico en el que la fórmula está escrita, y donde, inevitablemente, tendría que ser incorporada. El patrón de Modelo-Vista-Controladora (MVC) se utiliza a menudo para conectar una interfaz de usuario a un modelo de objetos subyacente (ver Figura 4). El modelo representa el comportamiento del sistema, independientemente de cualquier representación particular de la interfaz de usuario. El controlador es una parte de la capa de interfaz de usuario que se utiliza para mapear los eventos generados por la interfaz de usuario con las invocaciones de métodos necesarias para conducir el modelo. La interfaz de usuario no se contamina entonces con suposiciones sobre el modelo subyacente. Los flujos de trabajo considerados hasta ahora, vistos desde este punto de vista, entran todos en la categoría de modelos en el sentido de MVC. Sin embargo, el controlador también puede ser visto como flujo de trabajo. Los elementos de trabajo que organiza son los métodos que proporcionan los objetos del modelo. El controlador también interactúa con la interfaz de
- 82. 70 Capítulo 3: Flujos y procesos usuario y el modelo a través de contratos bien definidos. Un modelo de este tipo se denomina a menudo un flujo de páginas. Al igual que con las operaciones de secuencias de comandos, el flujo de páginas no se implementaría hoy utilizando un producto típico de flujos de trabajo. Hay dos razones a considerar en la construcción de un flujo de páginas utilizando una plataforma de flujos de trabajo. En primer lugar, un modelo puede ser representado visualmente con facilidad, ayudando a los desarrolladores y analistas a expresar y comunicar el comportamiento requerido. En segundo lugar, si el flujo de páginas cambia con frecuencia, entonces la abstracción del flujo de páginas como un modelo mejora la agilidad. Hay dos requerimientos principales, si este problema se va a abordar usando una plataforma de flujos de trabajo. La implementación de tiempo de ejecución del flujo de trabajo debe ser ligera, ya que un flujo de páginas puede estar corriendo en una pequeña aplicación de escritorio, y los contratos soportados deben incluir las características contractuales basadas en eventos de la interfaz de usuario, así como los contratos entre objetos y métodos que expone el modelo. Ahora vamos a ver un ejemplo de una aplicación de pruebas de grabación/reproducción. La intención de este último ejemplo es poner a prueba los límites de aplicabilidad de la hipótesis de la plataforma de flujos de trabajo. Figura 4: Aplicación MVC La aplicación en este caso es una herramienta para comprobar aplicaciones construidas como juegos de servicios. La herramienta utiliza un mecanismo de intercepción para registrar todas las interacciones entre servicios que se producen durante la ejecución manual de un caso de prueba de la aplicación. Esta grabación se puede reproducir posteriormente. Durante la reproducción, se generan mensajes de origen externo sin intervención manual, y se chequea la secuencia y contenido de los mensajes que se producen entre el juego de servicios que componen la aplicación contra la grabación original. El flujo de trabajo es el caso de prueba, organizando las unidades de trabajo que son los servicios participantes. El flujo de trabajo es a la vez activo, ya que simula el comportamiento de los mensajes externos, y pasivo, en el sentido de que controla las interacciones entre los servicios. Una característica única de esta aplicación es que el flujo de trabajo está escrito, no por un programador o un usuario, sino por un programa, como parte del acto de grabación de un
- 83. Capítulo 3: Flujos y procesos 71 caso de prueba. La creación de modelos de flujos de trabajo tiene que ser totalmente programable. También hay requerimientos para la extensibilidad y la actualización dinámica. La extensibilidad es necesaria porque las semánticas estructurales son ricas. Por ejemplo, el hecho de que dos mensajes lleguen a un servicio, uno tras otro en la grabación, no implica necesariamente que este orden deba ser preservado en una reproducción. Si no hay una dependencia causal entre los mensajes, entonces una repetición que invierte el orden de los mensajes es correcta. Por lo que las semánticas de secuencia en el modelo utilizado para grabar los casos de prueba deben incluir una noción de causalidad, que no es probable que sea una característica del modelo de secuencia del núcleo del flujo de trabajo. La actualización dinámica es necesaria debido a que se producirá interacción humana con el modelo durante la reproducción. Las discrepancias descubiertas durante la reproducción entre el comportamiento observado y grabado, se le presentan al probador. Si la discrepancia se debe a que un mensaje incluye una marca de tiempo que varía de una ejecución a otra, entonces el probador actualizaría el modelo para marcar el campo como "no importa". Si la discrepancia se produce en una prueba de regresión debido a que el software ha cambiado, entonces el probador podría aprobar el cambio y actualizar la prueba para esperar el nuevo comportamiento en todas las corridas posteriores. Valor de la plataforma de flujos de trabajo Un flujo de trabajo no tiene, por definición, el juego de características que ofrecen los productos típicos de flujos de trabajo actuales. En lugar de esto, la plataforma de flujos de trabajo considerada aquí se enfoca en el soporte del concepto de flujo de trabajo como un modelo de organización de los ítems de trabajo. Hemos visto que esta idea de una organización de los ítems de trabajo es aplicable a un amplio espectro de aplicaciones, pero el hecho de que una plataforma de flujos de trabajo pueda ser usada no implica que deba ser usada. Figura 5: Implementación de la revisión de documentos
- 84. 72 Capítulo 3: Flujos y procesos Hay que hacerse dos preguntas: ¿qué valor adicional se deriva del enfoque de plataforma de flujos de trabajo? y, ¿es práctico este enfoque? El valor del enfoque de plataforma de flujos de trabajo tiene que venir de la expresión de la organización del trabajo como un modelo, lo que discutiremos más adelante. Resumamos las características que debe mostrar una plataforma de flujos de trabajo práctica y efectiva. Para demostrar como difiere un modelo del código, el fragmento de código que se muestra a continuación es un flujo de trabajo válido de acuerdo a la definición usada aquí, esto es, una organización de las unidades de trabajo. Y, en un sentido, esto es un modelo. Es posible parsear este código y construir un árbol CodeDOM que lo represente. Sin embargo, las semánticas del modelo resultante son tan generales que son opacas. Es posible decir que el código contiene invocaciones de funciones, pero no es tan fácil distinguir una función que represente la invocación de un ítem de trabajo desde una función que convierte enteros en cadenas de caracteres. Un modelo de flujos de trabajo distingue explícitamente estas ideas. Típicamente, un elemento del modelo especializado se usa para representar la invocación de un ítem de trabajo, y las funciones de conversión no pueden ser expresadas directamente en el modelo. Un modelo de flujos de trabajo, entonces, es uno cuyo grafo se compone de elementos que tienen sentido en el dominio del flujo de trabajo. La riqueza semántica de dicho modelo puede explotarse de varias formas. Visualización. La representación visual del modelo - por lo general en forma gráfica - es útil al desarrollador, durante el desarrollo y el mantenimiento, y también a los usuarios del flujo de trabajo que desean conocer por qué se les ha asignado una tarea específica o un trabajador de operaciones de TI que quiera entender lo que debe hacer una aplicación que está funcionando mal. Penetración. El modelo de flujos de trabajo puede manipularse mediante la programación para una variedad de propósitos. Un ejemplo es el análisis estático para determinar las dependencias y los flujos a través de un modelo. También se podría usar el modelo para conducir una simulación que prediga las cargas de trabajo que se generarán por una nueva versión de uno de los procesos. Expresividad. La especialización del modelo de flujos de trabajo para el dominio de flujo de trabajo significa que los problemas característicos se pueden expresar con mayor rapidez y de forma más compacta. Es un lenguaje de dominio específico (DSL), especializado en dar soporte a los problemas característicos. Considere un proceso de revisión documental en el que tres votos positivos de las cinco revisiones significan que el documento es bueno, y el resto de las revisiones pendientes se pueden cancelar. Este proceso es bastante difícil de
- 85. Capítulo 3: Flujos y procesos 73 codificar, pero un modelo de flujos de trabajo puede proporcionar bloques estándares para abordar estos problemas. Explotación más semántica Como hemos visto en la discusión de las operaciones con secuencia de comandos, la extensión del modelo de flujos de trabajo para especializar el lenguaje de modelación es una técnica muy poderosa para incorporar valor agregado. Un ejemplo es la creación de un lenguaje dirigido a los usuarios finales, como en la revisión de documentos mostrada utilizando una definición mejorada del proceso de revisión que se discutió previamente. Ejecución. La especialización del modelo permite incluir soporte de tiempo de ejecución para problemas comunes. Un buen ejemplo es el estado de larga duración. De las aplicaciones descritas aquí, la gestión del estado de larga duración es necesaria para el proceso de revisión de documentos, para la colaboración en la resolución de problemas y en las aplicaciones de usuario con secuencia de comandos. La plataforma de flujos de trabajo para tiempo de ejecución puede resolver estos difíciles problemas utilizando elementos simples y expresivos del modelo liberando a los desarrolladores para que se centren en los problemas del negocio. Monitoreo. La existencia de un modelo hace posible la producción de un flujo de eventos con una semántica llena de contenido sin un esfuerzo adicional de los desarrolladores. De las aplicaciones descritas aquí, esta secuencia de eventos es muy útil en la revisión de documentos, en la colaboración para la resolución de problemas, en las pruebas de grabación/reproducción, y en las aplicaciones guiadas por el usuario. La secuencia de eventos puede ser usado para monitorear instancias de flujos de trabajo o construir vistas agregadas del estado de un gran número de instancias de flujos de trabajo. La estandarización del flujo de eventos hace que sea mucho más fácil construir estas vistas agregadas a través de flujos de trabajo que se desarrollaron independientemente unos de otros. Otra idea poderosa es la presentación de los errores usando una semántica de negocio. A menudo, un fallo técnico, como la no entrega de un mensaje conduce a una escalada para llegar a un experto técnico, ya que el significado de la falla no está claro sin una investigación especializada. Si el error se puede mapear a un modelo de flujos de trabajo – de modo que resulta claro que el error se refiere a una notificación de cambio no crítica, por ejemplo, - entonces la escalada puede ser restringida a los casos en que realmente sea necesario. Composición. Si una aplicación se descompone en unidades de trabajo, entonces estas unidades de trabajo, con sus interfaces bien conocidas, pueden ser reutilizadas por otros flujos de trabajo. Los flujos de trabajo también definen unidades de trabajo que también pueden ser utilizadas por otros flujos de trabajo. Personalización. Supongamos que un ISV (vendedor de software independiente) despacha un flujo de trabajo, que es personalizado por un VAR (revendedor de valor añadido), y luego de nuevo por un cliente. Volver a aplicar estas personalizaciones cuando el ISV envía una nueva versión es un serio problema de mantenimiento. El uso de un modelo compartido y bien conocido para el flujo de trabajo hace que la integración de las tres vías consecuentes sea mucho más manejable. La personalización y la composición, tomadas en su conjunto, habilitan sistemas en los que las definiciones de trabajos y flujos se convierten en artefactos
- 86. 74 Capítulo 3: Flujos y procesos compartidos o negociados. Manipulación. Como hemos visto en los debates relacionados con la revisión de documentos y las aplicaciones de pruebas de grabación/reproducción, a menudo hay requerimientos para inventar o modificar flujos de trabajo sobre la marcha. Esta modificación no se puede hacer con seguridad si es necesario código cambiante. El uso de un modelo hace posible que la manipulación dinámica sea controlable y comprensible. Estas ventajas representan una lista convincente, y demuestran claramente que la descripción de una organización de los elementos de trabajo como un modelo, tiene mucho que ofrecer. Características de la plataforma Debe haber soporte para los elementos estructurales básicos como son las secuencias, los condicionales y los bucles. Sin embargo, también tiene que haber soporte para tratar con situaciones menos estructuradas que aparecen en algunas aplicaciones, como la colaboración para la resolución de problemas y las que se basan en una secuencia de comandos guiada por el usuario. También es importante permitir que se añadan nuevos elementos semánticos para crear lenguajes ricos y especializados, tales como la composición de flujos de datos en las operaciones de secuencias de comandos. La adición de nuevos elementos semánticos podría ir tan lejos como para exigir la redefinición de ideas tan fundamentales como la secuencia, por ejemplo, en la aplicación para pruebas de grabación/reproducción. El flujo de trabajo también debe ser capaz de comunicarse usando una gran variedad de formas. Los flujos de trabajo responden a eventos de la interfaz de usuario, manipulan diferentes tipos de servicios (humanos, de programación, de otros flujos de trabajo), y soportan consultas sobre el estado actual de sus contratos, por ejemplo, cuando se determinan las acciones disponibles de un actor en una aplicación de colaboración para la resolución de problemas. Si la plataforma de flujo de trabajo se va a utilizar en todas las aplicaciones en las que aporta un valor añadido, tales como MVC, entonces debe ser ligera. Igualmente, requiere abordar los requerimientos de escala y el rendimiento implícitos en aplicaciones como la revisión de documentos. Además, el modelo de flujos de trabajo en sí debe ser completamente programable, lo que incluye la creación del modelo - como en la aplicación de pruebas de grabación/reproducción - y actualización dinámica de los modelos para dar soporte a cambios inesperados, como en la revisión de documentos y en aplicaciones de pruebas de grabación/reproducción. Ahora echemos un vistazo a la realización de estas características requeridas en Windows Workflow Foundation (WF). WF implementa la idea de flujo de trabajo como una organización de elementos de trabajo, abstraída de las ideas relacionadas con la cual ha estado integrada en los productos de flujos de trabajo tradicionales. Las abstracciones caen en tres categorías principales: diseño y visualización, hospedaje, y semántica.
- 87. Capítulo 3: Flujos y procesos 75 Diseño y visualización. Un flujo de trabajo en WF es un árbol de elementos de trabajo (llamadas actividades). Este árbol se puede manipular directamente como un modelo de objetos. Se proporciona un diseñador, pero su uso no es obligatorio. Es posible crear nuevos diseñadores especializados para comunidades de usuarios particulares u organizaciones particulares de los elementos de trabajo. También es posible especializar el diseñador proporcionado, que puede ser utilizado no sólo dentro de Visual Studio, sino también desde una aplicación cualquiera. Hospedaje. Las bibliotecas de tiempo de ejecución de WF son lo suficientemente ligeras como para ser alojadas en un contexto de cliente como un controlador en una aplicación de cliente enriquecido. También es suficientemente potente para dar respuesta cuando se incrusta en un servidor, como el servidor de SharePoint distribuido con el Office. Las expectativas de anfitrión de las bibliotecas de tiempo de ejecución de WF se abstraen como interfaces del proveedor de servicios en forma de multihilos, transacciones, persistencia, y comunicaciones. Se ofrecen implementaciones comerciales útiles, pero estas pueden ser sustituidas cuando sea necesario. Semántica. Diferentes problemas responden a diferentes semánticas del modelo. WF es compatible con tres estilos principales de flujos de trabajo: flujo, máquina de estados, y enfoque basado en los datos. El flujo es ideal para aplicaciones donde el flujo de trabajo está en control, como el ejemplo de las operaciones de secuencias de comandos. La máquina de estados es la mejor cuando el flujo de trabajo es conducido por eventos externos, como en las aplicaciones MVC o de usuario guiado. Un enfoque basado en los datos es adecuado para aplicaciones en las que las acciones dependen del estado, como en la colaboración para la resolución de problemas. Estas semánticas se pueden ampliar mediante la creación de actividades personalizadas para crear un vocabulario de dominio específico para usar en cualquiera de estos estilos. Sin embargo, como la propia estructura de un flujo de trabajo se expresa como un conjunto de actividades, el mismo enfoque puede utilizarse para definir nuevos estilos, y semánticas del todo novedosas, si es necesario. Una plataforma común de tiempo ejecución para flujos de trabajo El foco de las bibliotecas de tiempo de ejecución de WF es ofrecer las facilidades requeridas por cualquier flujo de trabajo, y por lo tanto, evitar la necesidad de re implementar una y otra vez en diferentes aplicaciones, pero sin comprometer la flexibilidad de la abstracción del flujo de trabajo. Estas facilidades comunes se agrupan en cuatro categorías principales: programación de actividades, transacciones y estado de larga duración, excepciones y compensación, y por último, comunicaciones. Echemos un vistazo a cada una de ellas con más detalle. Programación de actividades. Las bibliotecas de tiempo de ejecución de WF definen un protocolo de actividad que implementa todos los elementos de trabajo. Este protocolo define las actividades básicas del ciclo de vida (inicializado, en ejecución y cerrado) y los estados adicionales necesarios para manejar las excepciones (fallas, cancelación y compensación). Esta definición permite que las bibliotecas de tiempo de ejecución de WF proporcionen planificación del trabajo para todos los flujos de trabajo. Transacciones y estado de larga duración. Las bibliotecas de tiempo de ejecución de WF
- 88. 76 Capítulo 3: Flujos y procesos admiten la ejecución de transacciones ACID6. Estas transacciones son particularmente útiles para mantener la coherencia a lo largo del estado del flujo de trabajo y del estado externo, como el estado de la aplicación y los mensajes. Sin embargo, las transacciones ACID no son adecuadas para la gestión del estado de larga duración debido a sus recursos y las implicaciones de bloqueo. Las bibliotecas de tiempo de ejecución de WF implementan un amplio mecanismo de puntos de control y recuperación para manejar el estado de larga duración. Desde este punto de vista, las transacciones ACID se convierten en unidades de ejecución dentro de una infraestructura más amplia. El desarrollador no necesita hacer ningún trabajo para obtener los beneficios del soporte de WF para la gestión del estado de larga duración, ya que este es el comportamiento predeterminado. Sin embargo, si es necesario un control más detallado, existe un conjunto de elementos de modelo simple para este propósito. Excepciones y compensación. La idea familiar de un manejo de excepciones del tipo throw-try-catch es soportada por las bibliotecas de tiempo de ejecución de WF y representada en el modelo de flujos de trabajo. Sin embargo, las bibliotecas de tiempo de ejecución de WF también son compatibles con una visión más amplia de la gestión de fallos, que incluye la idea de una compensación por unidades transaccionales completadas con éxito. Comunicaciones. Como hemos visto, los flujos de trabajo necesitan comunicarse en una variedad de formas, que se reflejan en la WF y que soportan la comunicación a través de los métodos, interfaces de eventos e interfaces de servicios Web de .NET. El soporte para Windows Communication Fundation también estará disponible en el futuro. Por lo tanto, WF en efecto suscribe el enfoque de la plataforma de flujos de trabajo que aquí se propone. La figura 5 muestra el esquema de implementación de alto nivel de la aplicación de revisión de documentos, y cómo se une todo lo anterior. Una implementación utiliza a SharePoint como anfitrión de los flujos de trabajo. Las bibliotecas de tiempo de ejecución de WF utilizan el servicio de planificación predeterminado que se ofrece con WF. Sin embargo, la persistencia predeterminada y los servicios de comunicación son sustituidos por implementaciones especializadas de SharePoint. El servicio de persistencia almacena el estado de larga duración de los flujos de trabajo en la base de datos de SharePoint y el servicio de comunicaciones hace que las facilidades de una interacción enriquecida de los usuarios de SharePoint estén disponibles para los flujos de trabajo. Ambos servicios, de hecho, han sido liberados con el Microsoft Office 2007. Tres tipos de actividades se utilizan para definir el propio flujo de trabajo de revisión de documentos. En primer lugar, se utilizan las actividades de WF para proporcionar los elementos estructurales, tales como if-else y while. En segundo lugar, las actividades suministradas como parte de Office 2007, se utilizan para acceder a los servicios de comunicación de usuario de SharePoint. Tercero, se utilizan actividades personalizadas para implementar la semántica específica de la organización para el envío y la delegación de una manera estándar y reutilizable. El diseñador de WF se utiliza como un medio para definir el flujo de trabajo, y también proporciona al propietario del flujo de trabajo representaciones gráficas del estado de una instancia del flujo de trabajo de revisión de documentos. 6 En computación ACID (Atomic, Consistent, Isolation, Durable) es un conjunto de propiedades que garantiza que las transacciones en la base de datos se realicen de forma confiable (Nota del traductor).
- 89. Capítulo 3: Flujos y procesos 77 Encarando los problemas En resumen, la plataforma de flujos de trabajo soporta una abstracción de las ideas que han hecho de los productos de flujo de trabajo una forma atractiva de ataque a los problemas de negocio. Sin embargo, no sustituye a los productos de flujos de trabajo de hoy. Por el contrario, los descompone en plataforma y superestructura. La plataforma de flujos de trabajo incluye dos ideas claves: un flujo de trabajo es una organización de unidades de trabajo, y un flujo de trabajo es un modelo, es decir, una descripción legible por computadora pero que no es un programa. Estas ideas son valiosas en una amplia gama de aplicaciones, tanto dentro como fuera del dominio del problema abordado por los productos típicos de flujos de trabajo. Dicha plataforma de flujos de trabajo es más útil si es de bajo costo y ubicua. Los principales beneficios surgen de la expresión de una organización de elementos de trabajo como modelo, que tiene varias ventajas sobre una representación en código: Transparencia. Los objetivos de negocio del sistema están claros, permitiendo a los usuarios y al personal de TI comunicarse de manera efectiva acerca del comportamiento deseado y además le permite al personal de TI que se involucra con el proyecto, ponerse al día rápidamente. Aislamiento con respecto al cambio. Las áreas de la aplicación que es más probable que cambien se expresan como flujos de trabajo en lugar de líneas de programa. Al aislar las partes de la aplicación que se mueven rápidamente, los cambios pueden ser más fiables. Agilidad. La conjunción de todos estos beneficios es la agilidad del negocio. Si los usuarios del negocio pueden entender el sistema, los desarrolladores pueden ponerse al día rápidamente, y los riesgos asociados con el cambio se reducen al mínimo, entonces, el sistema puede llamarse ágil. Una plataforma de flujos de trabajo de amplia utilidad tiene que tener estas características: definir un modelo de flujos de trabajo central como una norma que es extensible y completamente programable en tiempo de diseño y tiempo de ejecución, ser capaz de comunicarse en una gran variedad de formas, ser ligera e integrable, y ser capaz de escalarse y ejecutar bien en entornos de alto volumen. WF es un producto que muestra todas estas características. Como un componente de. NET 3.0 y una parte de la plataforma Windows, WF también es de bajo costo y está en todas partes.
- 90. 78 Capítulo 3: Flujos y procesos Manifiesto de un flujo de trabajo El “manifiesto de los flujos de trabajo” es un conjunto de declaraciones diseñadas para ayudar a considerar la flexibilidad, valor y beneficios que los flujos de trabajo le pueden aportar a la arquitectura de una solución. La aparición de una infraestructura flexible y extensible como WF permite la implementación de soluciones orientadas a flujos de trabajo por vías que eran imposibles en el pasado. El “manifiesto de los flujos de trabajo” fue diseñado para ayudar a aclarar algunas de las posibilidades de aplicación y uso de los flujos de trabajo en la arquitectura de nuestras soluciones: Los flujos de trabajo están en todas partes. Los flujos de trabajo son expresivos. Los flujos de trabajo son fluidos. Los flujos de trabajo son incluyentes. Los flujos de trabajo son transparentes. Si bien cada una de estas declaraciones ofrece una perspectiva muy diferente de los flujos de trabajo, todas ellas comparten dos beneficios específicos en común: la agilidad y la abstracción. Antes de revisar las declaraciones del manifiesto con mayor detalle, vamos a entender mejor la razón por la que estos dos beneficios se comparten de una manera tan amplia. Agilidad La agilidad es un concepto clave tanto para las TI como para el negocio - una arquitectura de soluciones altamente flexible y extensible es mucho más probable que satisfaga las necesidades rápidamente cambiantes de la organización. Debido a que están basados en modelos, los flujos de trabajo son más adecuados para enfrentar el cambio que un enfoque puro de programación. Por ejemplo, los flujos de trabajo, por lo general, permiten a los desarrolladores añadir rápida y fácilmente nuevos pasos a una instancia de flujos de trabajo en tiempo de ejecución. Hacer lo mismo con un enfoque de programación pura, exige a los desarrolladores entender cómo usar una API de reflexión y manipular los componentes internos de bajo nivel de un conjunto determinado de clases. Este último enfoque expone la solución al riesgo y limita considerablemente la cantidad de desarrolladores de mantenimiento cualificados para trabajar en él. Los flujos de trabajo también proporcionan soporte para las reglas de negocio que se pueden modificar y re-desplegar en tiempo de ejecución, afectando el comportamiento de uno o varios flujos de trabajo y las instancias que utilizan las reglas de negocio asociadas. Nota: Si bien los flujos de trabajo son más adecuados para enfrentar el cambio que un enfoque de programación puro, los flujos de trabajo no están diseñadas necesariamente para reemplazar toda la programación. Los flujos de trabajo no son más que un conjunto de clases especializadas generadas por el entorno de modelado de los flujos de trabajo. Abstracción La abstracción es otro concepto clave de las TI y el negocio, pero por razones ligeramente
- 91. Capítulo 3: Flujos y procesos 79 diferentes. Desde la perspectiva de TI, la abstracción se puede utilizar para ocultar la complejidad, lo que puede reducir tanto el tiempo de desarrollo como los costos de mantenimiento a largo plazo. Desde la perspectiva de negocios, los costos de mantenimiento son atractivos mientras que el modelo de flujos de trabajo hace que sea más fácil para el personal no técnico entender el objetivo de un flujo de trabajo determinado, sin tener que revisar el código usado para implementar la solución. El ámbito de aplicación del modelo de flujos de trabajo también puede ser establecido por un analista de negocio antes de entregarlo a un desarrollador para su implementación. El concepto de un enfoque basado en modelos no es nuevo - los desarrolladores han estado usando UML y otras técnicas de modelado por muchos años antes de que maduraran las herramientas de desarrollo con flujos de trabajo. Los flujos de trabajo proporcionan tanto los modelos secuenciales como los de máquinas de estado que pueden ser utilizados para desarrollar, gestionar y dirigir el flujo de trabajo. Los desarrolladores usualmente prefieren trabajar con la representación textual (código), mientras que un analista de negocio puede verse abrumado por los detalles del modelo en sí mismo. La mayoría de los modelos de flujos de trabajo también permiten que el modelo mismo sea modificado para satisfacer las necesidades de la organización. Por ejemplo, la superficie de presentación de WF puede ser “disfrazada” para cambiar la apariencia de la superficie del modelo antes de su incorporación a la aplicación. En el resto de este capítulo se examinan las declaraciones del manifiesto de los flujos de trabajo con mayor detalle. Se incluyen también varios ejemplos de cada tema. Los flujos de trabajo están en todas partes Los flujos de trabajo no sólo viven en los centros de datos o en los servidores de integración. Cualquier secuencia de pasos o actividades puede ser representada como un flujo de trabajo. Estos pasos pueden ser manejados por procesos automatizados en un flujo de trabajo del tipo sistema a sistema (S2S), un flujo de trabajo de humano a humano (H2H), o un modelo fractal que toca los dos (véase más adelante). Los flujos de trabajo pueden ser utilizados para orquestar servicios a través de aplicaciones o en una sola aplicación, para la intermediación de eventos de usuario o la exposición de las capacidades de los flujos de trabajo a un usuario final. Los flujos de trabajo también se pueden utilizar dentro de dispositivos dedicados. Por ejemplo, las soluciones basadas en WF se pueden desplegar fácilmente en dispositivos basados en x86 en forma de soluciones embebidas en XP, tales como un punto de venta (POS) o un cajero automático de banco. Hay varios escenarios que pueden beneficiarse de un enfoque orientado a flujos de trabajo. Los dos escenarios que se examinarán son los flujos de la interfaz de usuario (UI) y la creación de servicios Web. Flujos de UI Un modelo de flujos de trabajo puede servir como controlador dentro de un Modelo-Vista-Controladora (MVC). El patrón MVC proporciona una separación de los objetos en una de tres categorías - los modelos para el mantenimiento de los datos, las vistas para mostrar la totalidad o una parte de los datos y los controladores para el manejo de eventos que pueden impactar el modelo o las vistas. Hay tres ejemplos de flujos de interfaz de usuario
- 92. 80 Capítulo 3: Flujos y procesos que vale la pena considerar: Ventanas de Windows: Un flujo de trabajo puede actuar como agente para los eventos de usuario comunes, tales como las pulsaciones de botón, la selección de datos, y otros. El estado de una instancia de flujo de trabajo determinada también se puede utilizar para configurar la interfaz de usuario. Por ejemplo, la Figura 6 muestra cómo el estado de un flujo de trabajo se utiliza para activar o desactivar los botones de una ventana Windows a partir de la interacción del usuario con una instancia de flujo de trabajo determinada. (El código para este ejemplo está disponible en la carpeta WF Samples después de descargar e instalar el SDK de Windows para .NET 3.0.) Figura 6: Las instancias de flujo conducen la interfaz de usuario de WinForms Bloque de interfaz de usuario en aplicaciones compuestas (CAB): CAB es un bloque de aplicación que proporciona un modelo de programación para crear aplicaciones clientes inteligentes basadas en el patrón de composición. El patrón de composición se aplica a la interfaz de usuario combinando varios componentes para crear interfaces de usuario complejas. Los componentes de interfaz de usuario individuales pueden ser desarrollados, probados y desplegados de forma independiente (conceptualmente similar al modelo de Web Parts de SharePoint). La implementación original de CAB se desarrolló antes de la llegada de WF y requiere una gran cantidad de código para la intermediación de eventos y la administración de los componentes que conforman la interfaz (en la Figura 7 se ofrece una visión general de CAB). CAB está siendo rediseñado para incluir WF para la intermediación de eventos y la administración de los componentes de interfaz de usuario (véase el área resaltada en la Figura 7).
- 93. Capítulo 3: Flujos y procesos 81 Figura 7: Bloques de aplicación en la UI compuesta Flujos de páginas: Un flujo de páginas es un directorio de ficheros de una aplicación Web que trabajan conjuntamente para implementar una interfaz de usuario. Una implementación de flujos de trabajo del lado del servidor se utiliza para controlar el orden en que las páginas se presentan al usuario, con la posibilidad de cambiar la interacción con del usuario sobre la marcha, basándose en eventos recibidos en la página actual. La lógica de navegación permanece en el flujo de trabajo, aislando de manera efectiva la navegación de la presentación. Si bien no hay manera “oficial” de implementar flujos de páginas con WF, el equipo de desarrollo de WF ha elaborado un ejemplo que se encuentra disponible en http://wf.netfx3.com/files/folders/sample_applications/entry10996.aspx El ejemplo ilustra cómo se puede implementar una infraestructura genérica de navegación con WF que es capaz de soportar tecnologías de interfaz de usuario como ASP.NET y WPF. Servicios Web Hay dos enfoques en los que podemos considerar la relación de los flujos de trabajo y los servicios Web. Un flujo de trabajo puede ser utilizado para orquestar varios servicios Web, con lo que podría potencialmente reasignar los valores de retorno de un servicio Web como valores de entrada a otro. Utilizando flujos de trabajo para invocar servicios Web simplifica el proceso de trabajar con servicios asíncronos ya que los requerimientos de invocación y correlación se pueden manejar por el propio flujo de trabajo. También podemos utilizar flujos de trabajo para crear servicios Web publicando el flujo de trabajo como un servicio Web. El modelo es fractal, ya que podemos utilizar flujos de trabajo tanto para crear como para consumir (orquestar) servicios Web. Como la mayoría de los servicios se han desarrollado y diseñado para funcionar de forma autónoma, integrarlos en una nueva composición de servicios (flujo de trabajo) requiere responder a varios retos. La figura 8 muestra algunos de los retos más comunes a que se enfrenta la orquestación de servicios.
- 94. 82 Capítulo 3: Flujos y procesos Figure 8: Capacidades para la composición de servicios La mayoría de los servidores de integración (como BizTalk Server) ofrecen soporte para las capacidades de la figura 7, liberando a los desarrolladores de tener que escribir, probar y mantener “códigos de ensamblado” que ofrecen poco valor a la organización. La figura 9 ilustra cómo un flujo de trabajo puede ser expuesto como un servicio y orquestar servicios. Figure 9: Flujos de trabajo y servicios Web En .NET 3.0, WF incluye tres actividades corrientes para el consumo o la publicacicencencen vicios
- 95. Capítulo 3: Flujos y procesos 83 soporte a los patrones de intercambio de mensajes (MEP) de un solo sentido o de petición-respuesta. Un flujo de trabajo con una actividad WebServiceReceive se publica como un servicio Web ASMX, simplemente haciendo clic derecho sobre el proyecto que contiene el flujo de trabajo y seleccionan la opción “Publicar flujos de trabajo como Servicios …” Una actividad WebServiceResponse se puede agregar a un flujo de trabajo que se publicará como un servicio Web con un MEP de solicitud-respuesta (no hay WebServiceResponse en un MEP de un solo sentido). WebServiceResponse incluye una propiedad ReceiveActitivityID que se utiliza para asociar el mensaje de respuesta con una actividad WebServiceReceive previamente definida. Las actividades del WF que viene con .NET 3.0 no ofrecen soporte para Windows Communication Foundation (WCF). WCF y WF están alineados más estrechamente en .NET 3.5, lo que le permite a usted exponer más fácilmente flujos de trabajo como servicios WCF y orquestar servicios WCF. El uso de WF para consumir o crear servicios Web proporciona un conjunto mucho más rico de opciones que un enfoque de “programación pura”. WF permite a los desarrolladores aprovechar diversas características como la orquestación de servicios, invocaciones asíncronas, persistencia/monitoreo del estado. En esta sección se ilustra cómo se puede utilizar los flujos de trabajo en las interfaces de usuario y cómo podemos utilizar flujos de trabajo para crear y consumir servicios Web. Algunos escenarios adicionales podrían ser la implementación de una capa de lógica de negocio dentro de sus aplicaciones, el soporte a procesos de larga duración y la exposición de un conjunto de reglas de negocio configurables que pueden ser modificadas en tiempo de ejecución. Cualquier secuencia de pasos o eventos puede ser representada como un flujo de trabajo. Los flujos de trabajo son expresivos Los flujos de trabajo pueden hacer prácticamente cualquier cosa que se puede hacer con el enfoque de “programación pura”, a un nivel superior de abstracción. Esto no significa necesariamente que usted deba reemplazar todo el código con flujos de trabajo. Lo que sí significa es que usted puede utilizar un enfoque orientado a flujos de trabajo para elevar el nivel de abstracción en sus soluciones, lo que podría elevar su nivel de productividad y reducir el mantenimiento y los costes a largo plazo. Vamos a examinar estas afirmaciones con mayor detalle. El modelo es el flujo de trabajo Dado que el modelo es una representación directa del flujo de trabajo real, no hay ninguna pérdida de fidelidad en la implementación del modelo. Este es un cambio importante a partir de las tecnologías anteriores basadas en modelos como el CASE y algunas herramientas de desarrollo basadas en UML. Estas herramientas han sufrido por el hecho de que sus entornos de modelado eran mucho más expresivos que sus capacidades de generación de código. Esto significaba que los modelos eran, de hecho, simples imágenes, ya que eran incapaces de generar el código necesario para implementar la solución. La transición entre un modelo de flujos de trabajo y su implementación es un proceso sin pérdidas - el modelo y el código son diferentes vistas del mismo flujo de trabajo. El modelo también hace que la comunicación y el mantenimiento del flujo de trabajo sean
- 96. 84 Capítulo 3: Flujos y procesos mucho más fáciles que con el enfoque de “programación pura”. El modelo se convierte en parte de la documentación del flujo de trabajo, y puede ser compartido con (o creado por) un analista de negocio para ilustrar el objetivo del flujo de trabajo. El modelo también puede ser utilizado por los programadores de mantenimiento para entender y mantener el flujo de
- 97. Capítulo 3: Flujos y procesos 85 Los flujos de trabajo son fluidos Debido a que están basados en modelos, los flujos de trabajo pueden ser modificados, interrogados o manipulados en tiempo de diseño o en tiempo de ejecución. Es decir, tanto los usuarios como los analistas participan en el diseño y las actualizaciones del flujo de trabajo. Los elementos del flujo de trabajo pueden cambiar con frecuencia, así como el orden de las operaciones, las llamadas a métodos, y los servicios, datos, o solicitudes a ser integrados. Por ejemplo, en una solución de hipotecas, las tarifas pueden cambiar en función del mercado, el tipo de préstamo, la historia del deudor, o varias otras razones. Puede ser que sea necesario que los cambios fluyan desde el diseño hasta la implementación en cuestión de minutos. Esto requiere un enfoque diferente al clásico de aplicaciones compiladas y distribuidas. Algunos sistemas de flujos de trabajo usan un repositorio de tiempo de ejecución de aplicaciones y reglas de negocio que exigen una actualización frecuente. Este enfoque permite a los sistemas de flujos de trabajo responder rápidamente a las condiciones del mercado y de la organización. La flexibilidad de los flujos de trabajo se puede maximizar mediante un uso juicioso de las reglas de negocio y las orquestaciones. Reglas de negocio Una aproximación a la fluidez radica en utilizar reglas de negocio. Las reglas de negocio rigen el comportamiento de los procesos de negocio. Los procesos de negocio tienden a permanecer invariantes en el tiempo, pero las reglas de negocio utilizadas por estos procesos son muy volátiles. La separación de las reglas del código de la aplicación permite a los usuarios invocar o cambiar las reglas en tiempo de ejecución, lo que resulta en una mayor flexibilidad del flujo de trabajo. Las reglas de negocio son las más utilizadas para: Evaluaciones y cálculos puntuales. Gran número de permutaciones a codificar en un flujo de control. Inferencia basada en hechos donde el flujo de control no puede ser predefinido. Orquestaciones Las orquestaciones son similares a las reglas de negocio, pero más formales. Usted las usaría en lugar de reglas de negocio, donde se requieran flujos de trabajo formales: Semánticas de larga duración Transacciones/Compensaciones Mensajería Las orquestaciones también se utilizan cuando hay un flujo de control reconocido que debe ser rigurosamente administrado para el desempeño o la escala, y resultan críticas la visibilidad y el monitoreo del estado de la orquestación. Tanto las reglas de negocio como las orquestaciones permiten que los flujos de trabajo sean modificados mejor y mucho más rápido con los cambios en la organización. Esta flexibilidad reduce los costos asociados normalmente con el desarrollo, el mantenimiento y la propiedad de un determinado proceso.
- 98. 86 Capítulo 3: Flujos y procesos Los flujos de trabajo son inclusivos La automatización en un entorno sistema a sistema (S2S) es bastante simple - los procesos tienden a ser fijos con un número finito de variaciones. Los datos procesados en un entorno S2S tienden a ser estructurados y representan mensajes del negocio bien conocidos tales como una orden de compra. Los usuarios, sin embargo, trabajan de una manera ad-hoc y
- 99. Capítulo 3: Flujos y procesos 87 Comprendiendo la relación entre BizTalk Server y WF En este capítulo se hacen numerosas referencias a Windows Workflow Foundation (WF). Cuando se anunció por primera vez a WF, mucha gente supuso incorrectamente que WF sería un reemplazo de BizTalk Server (BTS). WF y BTS son tecnologías complementarias diseñadas para servir a dos necesidades muy diferentes: BTS es un producto bajo licencia diseñado para implementar flujos de trabajo (“orquestaciones”) con aplicaciones dispares. WF es una infraestructura de desarrollo diseñada para exponer capacidades de los flujos de trabajo dentro de una aplicación. No hay pago de cuotas o restricciones de licencia asociadas con el uso o el despliegue de WF. Usar BizTalk Server si… Se necesita implementar flujos de trabajo sistema a sistema (S2S) a través de diferentes aplicaciones o plataformas. Se requiere una suite de BPM que permita transformaciones complejas, ofrezca soporte para los populares protocolos de aplicación y permita la integración con sistemas de líneas de negocio (LOB) como SAP, PeopleSoft, Oracle y JD Edwards. Se necesita interactuar con flujos de trabajo humano a humano (H2H). Se necesita aprovechar el Business Activity Monitoring (BAM). Se requiere mapear la información de autenticación entre sistemas Windows y no Windows (Single Sign-On). Se necesita configurar y gestionar los socios comerciales en un escenario B2B. Se necesita un conjunto completo de herramientas para la gestión de la infraestructura y la escalabilidad de la arquitectura de sus soluciones. Usar Windows Workflow Foundation si… Se necesita exponer las capacidades de los flujos de trabajo a los usuarios finales a través de una aplicación. Una aplicación sólo necesita un gestor de mensajes o eventos. Se necesita construir un flujo de trabajo humano a humano (H2H) capaz de interactuar con un flujo de trabajo sistema a sistema (S2S). (SharePoint Server 2007 incluye varios flujos de trabajo humanos predefinidos, construidos con WF). Usted sólo necesita flujos de trabajo o simples reglas de negocio y no está interesado en las otras características que proporciona el BizTalk Server.
- 100. 88 Capítulo 3: Flujos y procesos Resumen En este capítulo se examinó el concepto de flujo de trabajo y se discutieron otros términos y conceptos frecuentemente asociados con los flujos de trabajo. El flujo de trabajo es la organización del trabajo utilizando actividades que representan tanto a las personas como al software. Los modelos representan esta organización, proporcionando un nivel superior de abstracción y flexibilidad para nuestras soluciones. Este capítulo también aclaró las relaciones entre las capacidades orientadas a flujos de trabajo en la plataforma Microsoft (Windows Workflow Foundation y BizTalk Server). El capítulo 4 proporciona una discusión más detallada de la capacidad arquitectónica recurrente de Datos.
- 101. Capítulo 3: Flujos y procesos 89 Estudio de caso SOA: Grupo Dollar Thrifty Automotive El Grupo Dollar Thrifty Automotive oferta la renta de carros a través de dos sucursales: Dollar Rent A Car y Thrifty Car Rental. Aproximadamente 8,300 empleados de Dollar Thrifty despachan viajeros desde las oficinas centrales de la compañía en Tulsa, Oklahoma. Con una red siempre en expansión de locaciones norteamericanas e internacionales subcontratadas en 70 países, las dos sucursales operan en la mayoría de los principales mercados aeroportuarios de EEUU. A medida que Dollar Thrifty creció y se expandió, y la competencia en el negocio de la renta de carros se aceleró, los decisores de la compañía comenzaron a preocuparse por aspectos relacionados con su sistema de renta de carros basado en máquinas grandes (mainframes). Dollar Thrifty deseaba un sistema de renta de carros que fortaleciera la interacción con el cliente y ayudara a la compañía a ser más ágil de cara a la competencia, presente y futura. Los desarrolladores en Dollar Thrifty aprovecharon las ventajas de Windows Workflow Foundation (WF) para implementar validaciones en una aplicación de clientes inteligentes. WF proporciona el modelo de programación, el motor, y las herramientas para construir rápidamente aplicaciones que manejan flujos de trabajo. Dado que usaron WF, los desarrolladores no tuvieron que escribir la lógica de los flujos de trabajo o las validaciones desde cero. Los desarrolladores tuvieron la posibilidad de crear una interfaz flexible que les permite a los agentes trabajar de la forma que desean y al mismo tiempo satisfacer todas las reglas de negocio. Diagrama general de la arquitectura de Dollar Thrifty El estudio de caso completo se encuentra disponible en: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=1000003883. Otros estudios de caso SOA pueden consultarse en: http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA.
- 102. 90 Capítulo 3: Flujos y procesos
- 103. 91 Capítulo 4: Datos "Los datos son algo precioso y durarán mas que los sistemas mismos." - Tim Berners-Lee Inventor de la Web Guía para el lector Los lectores de este capítulo continuarán desarrollando los conceptos introducidos en los capítulos previos, centrándose concretamente en la capacidad arquitectónica de datos. Figura 1: Capacidades arquitectónicas recurrentes En este capítulo, vamos a discutir los aspectos que deben ser considerados cuando se concibe la arquitectura de la parte de datos del proyecto SOA. Los temas que se abordarán son los siguientes: Generalidades de los temas de datos. El fortalecimiento, la expansión y el escalado hacia afuera Estrategias de replicación y particionado. Integración de datos y gestión de datos maestros (MDM).
- 104. 92 Capítulo 4: Datos Desafíos que enfrenta SOA en relación con los datos Generalidades Cualquier proyecto SOA que ignore los problemas relacionados con los datos, es probable que falle. La sabiduría tradicional asegura que debe ser destinado a la integración de datos entre un 20 y un 40% del proyecto SOA, y mientras más alejado de la integración de datos usted se encuentra cuando elabora el plan del proyecto, más caro se vuelve. En esta sección vamos a discutir los temas que deben ser considerados cuando se diseña la parte de la arquitectura relacionada con los datos en un proyecto SOA. Una de las metas de SOA es transformar los sistemas fuertemente acoplados y de un solo propósito en un conjunto de servicios de acoplamiento flexible que puedan utilizarse y reutilizarse a lo largo de toda la empresa. Si una aplicación se divide en múltiples servicios se podría utilizar una transacción atómica de servicios Web (WS-AT) para simular una transacción distribuida. Este enfoque integra fuertemente los servicios involucrados en la transacción - si uno de los servicios no está disponible la operación completa fallará. Una forma de hacer la agregación de servicios más robusta es diseñar el servicio de modo que se ejecute de forma asíncrona dentro de su propia transacción atómica - de esta manera, si un servicio no está disponible, la operación mayor todavía se puede completar con éxito. La integridad de los datos requiere una garantía de que si el servicio no se realiza inmediatamente, este se completará de forma fiable cuando el servicio esté disponible. La mejor manera de asegurar esto es usar la mensajería transaccional de confianza entre servicios para asegurar que una vez que la transacción original se confirma, los mensajes necesarios para completar todas las demás partes de la operación también se han confirmado a una base de datos de modo que no se perderán si algo sale mal (nos referiremos brevemente a la ejecución confiable de servicios más adelante en este capítulo). La base de datos podría convertirse en un cuello de botella durante la reutilización de los servicios. Cuando los servicios legados se utilizan en una nueva solución a medida que la infraestructura de SOA se expande, la base de datos donde los servicios almacenan sus datos puede no ser capaz de manejar la carga adicional de llamadas de los nuevos servicios. Esto implica que los nuevos proyectos de SOA pudieran requerir una capacidad adicional en los sistemas de bases de datos existentes. Aspectos relacionados con la integración de datos La gente frecuentemente habla de usar SOA para romper los silos de datos con el objetivo de proporcionar una vista unificada de los datos. Usar los servicios para romper los silos de datos puede exponer datos inconsistentes y duplicados. Si los datos son inconsistentes o hay duplicados, se debe corregir estas
- 106. 94 Capítulo 4: Datos requiere reconsiderar cómo trabajan las transacciones en la base de datos. Por ejemplo, un sistema legado de entrada de pedidos puede almacenar la cabecera y las líneas del pedido en la base de datos, actualizar el registro del cliente, actualizar el inventario, crear un pedido de envío, y añadir un registro de cuentas por cobrar, todo en la misma transacción en la base de datos. La enumeración de los servicios como un conjunto de transacciones rompe el modelo de acoplamiento flexible. Si cualquiera de los servicios no está disponible, toda la operación fallará de modo que la agregación de servicios en una transacción distribuida de gran tamaño puede hacer que el sistema sea muy frágil. La manera de hacer esta agregación de servicios más robusta es asegurar que cada servicio se ejecute de forma asíncrona en su propia transacción - esto permite que la operación finalice con éxito, incluso si uno o dos de los servicios no están disponibles. La integridad de los datos requiere una garantía de que si el servicio no se completa inmediatamente, se completará de manera fiable cuando el servicio esté disponible. La mejor manera de asegurar esto es usar mensajería transaccional de confianza entre servicios, para asegurar que una vez que la transacción original se confirma, los mensajes necesarios para completar todas las otras partes de la operación también se han confirmado a una base de datos de modo que no se perderán si algo sale mal. Cuando se utilizan servicios en las nuevas aplicaciones a medida que la infraestructura de SOA se expande, la base de datos en que los servicios almacenan sus datos puede no ser capaz de manejar la carga adicional de nuevas llamadas de los servicios, de modo que un proyecto SOA puede requerir la adición de capacidades a los sistemas de bases de datos. Con frecuencia se espera que una SOA desglose las aplicaciones y los silos de datos, proporcionando una visión unificada de los datos - esto se refiere a veces como el problema de “la vista única del cliente”. Por ejemplo, el objetivo de un servicio al cliente puede ser la de proporcionar una visión única del cliente, pero si el mismo cliente aparece en 10 bases de datos diferentes con una dirección postal distinta en cada uno, el objetivo de brindar una visión única del cliente se convierte en imposible. Si los datos son inconsistentes o están duplicados, entonces los datos deben ser corregidos antes de poner los datos a disposición de otros servicios dentro de la empresa. Si todos los silos de datos tienen una copia del mismo cliente con datos ligeramente diferentes, la descomposición de los silos expone representaciones inconsistentes de los datos de los clientes – y esto es peor que el problema de los silos de datos, ya que en aquel caso cada uno utiliza una sola copia de los datos del cliente. El uso de SOA para integrar el acceso a los datos sin la integración previa de los datos conlleva a una visión confusa de datos inconsistentes y duplicados. Los datos inconsistentes representan una causa común de fracaso en la introducción de SOA. Escalabilidad de la Base de Datos Escalabilidad La escalabilidad es la capacidad de una aplicación de utilizar eficientemente más recursos con el fin de realizar más trabajo útil. Por ejemplo, una aplicación que puede dar servicio a cuatro usuarios en un sistema de un solo procesador puede ser capaz de dar servicio a 15 usuarios en un sistema de cuatro procesadores. En este caso, la aplicación es escalable. Si la adición de más procesadores no aumenta el número de usuarios atendidos (si la aplicación
- 107. Capítulo 4: Datos 95 es de un solo hilo, por ejemplo), la aplicación no es escalable. Hay dos tipos de escalabilidad: el escalado hacia arriba (fortalecimiento) y el escalado horizontal (expansión). El escalado hacia arriba significa mover los servicios de datos hacia servidores más grandes y más potentes (como mover los servidores de cuatro procesadores a servidores de 16 o de 32 procesadores). Esta es la forma más común de escalar las bases de datos. Cuando la base de datos se queda sin recursos con el hardware actual, usted sale y se compra una caja más grande con más procesadores y más memoria. El escalado hacia arriba tiene la ventaja de no requerir cambios significativos en la base de datos. En general, usted simplemente instala su base de datos en una máquina más grande y sigue ejecutando de la misma forma en que siempre lo ha hecho con más potencia de base de datos para manejar una carga más pesada. El escalado horizontal significa la expansión a varios servidores en lugar de un único servidor más grande. El escalado horizontal, por lo general, tiene algunas ventajas en cuanto al costo inicial del hardware – ocho servidores de cuatro procesadores generalmente cuestan menos que uno de 32 procesadores - pero esta ventaja suele perderse cuando se incluyen los costos de licenciamiento y mantenimiento. En algunos casos, la redundancia ofrecida por una solución de este tipo, también es útil desde una perspectiva de disponibilidad. Replicación y particionado Las dos técnicas más comunes para el escalado hacia arriba de los datos son la replicación y el particionado. La replicación requiere realizar varias copias de los datos y distribuirlas para lograr un mayor acceso a los datos. La replicación utiliza generalmente una sola copia de “escritura” de los datos (o “master”) con múltiples copias de distribución de solo lectura. El particionado divide la base de datos en múltiples bases de datos basándose en una columna de partición específica. Las bases de datos pueden segmentarse, a su vez, en áreas funcionales específicas de la organización, y lograr así un escalado aún mayor. Para ilustrar el impacto del particionado, vamos a examinar cómo podría particionarse una base de datos de pedidos. Una posibilidad podría ser particionar los pedidos sobre la base de lo que se ordenó, y así almacenar los pedidos de libros en una base de datos y los pedidos de ropa en otra. Aparte de las cuestiones obvias (por ejemplo, lo que ocurre con un pedido que incluye libros y ropa), este esquema no funcionaría bien si la mayoría de las consultas combinan pedidos de los clientes. El problema es que la consulta integrada tendría que revisar todas las bases de datos para seleccionar los pedidos. Un enfoque alternativo para la partición de una base de datos de pedidos sería la de dividir los pedidos por el número de pedido. Esto podría tener sentido si los pedidos son consultados más a menudo por número de pedido que por ubicación. Si hay una gran cantidad de consultas conjuntas con la tabla de clientes este esquema requeriría uniones distribuidas. La única manera de resolver el problema de las uniones sería particionar la base de datos de pedidos por número de cliente, ya que para un cliente determinado siempre se conoce la base de datos a utilizar. Esto es especialmente efectivo si la base de datos de clientes se divide y los pedidos de cada cliente están en la misma base de datos del cliente. Habrá otros datos que se deben unir a los datos del pedido y si es posible, estos datos deben ser particionados con el mismo esquema para evitar uniones distribuidas. Algunos de estos datos
- 109. Capítulo 4: Datos 97 El particionado de servicios se ilustra en la Figura 3 a continuación. Figura 3: Enrutamiento hacia las Bases de Datos desde clientes o servicios Uno de las promesas de SOA es la integración de datos. Cuando los servicios se comunican mediante mensajes con formatos y esquemas bien definidos el intercambio de datos entre los sistemas es fácil ¿no? Por desgracia no es tan fácil cuando se tiene en cuenta la integración de datos. Además de tener todos sus sistemas de acuerdo con respecto a lo que un mensaje del cliente parece, van a tener que ponerse de acuerdo sobre los identificadores de los clientes para los sistemas para poder intercambiar datos de una manera que tenga sentido. Por ejemplo, si yo aparezco como cliente en tres de sus sistemas, pero un sistema utiliza mi número de seguro social como identificación, otro utiliza mi dirección de correo electrónico y otro utiliza mi número de teléfono, lo más probable es que voy a aparecer como tres clientes diferentes, así que será casi imposible que su empresa me reconozca como su cliente. A medida que se construyen nuevos sistemas y se adquieren más datos de clientes a través de fusiones y adquisiciones, este problema se vuelve más difícil de resolver. Para resolver este problema necesitamos una manera de definir y gestionar representaciones de las entidades de nuestro negocio para toda la empresa. Este es el problema conocido como Gestión de Datos Maestros (MDM).
- 110. 98 Capítulo 4: Datos Gestión de Datos Maestros (MDM) La mayoría de los sistemas de software tienen listas de datos que son compartidos y utilizados por varias de las aplicaciones que componen el sistema. Por ejemplo, un sistema ERP típico tendrá un maestro de clientes, un maestro de artículos, y un maestro de cuentas contables. Estos datos maestros son a menudo uno de los principales activos de una empresa. No es inusual que una compañía sea adquirida principalmente por el acceso a los datos maestros de sus clientes. Los datos maestros son los sustantivos críticos de una empresa y caen generalmente en cuatro grupos: personas, cosas, lugares y conceptos. Categorizaciones más detalladas de dichos grupos se denominan áreas temáticas, zonas de dominio, o tipos de entidades. Por ejemplo, dentro de la categoría de personas, hay clientes, empleados y vendedores. Dentro de las cosas, hay productos, partes, almacenes y activos. Dentro de los conceptos, hay cosas como el contrato, la garantía, y la licencia. Por último, dentro de los lugares, hay oficinas y divisiones geográficas. Algunas de estas áreas de dominio se pueden dividir a su vez. El cliente puede ser segmentado en base a los incentivos y la historia. Una empresa puede tener clientes normales, así como clientes premier y ejecutivos. Los productos pueden ser segmentados por sector e industria. Los requisitos, el ciclo de vida, y el ciclo de CRUD para un producto en el sector de los bienes de consumo envasados son probablemente muy diferentes de los de la industria del vestuario. La granularidad de los dominios está determinada esencialmente por la magnitud de las diferencias entre los atributos de las entidades dentro de cada uno ellos. ¿Qué es MDM? A los efectos de este capítulo, vamos a definir la Gestión de Datos Maestros (MDM) como “la tecnología, herramientas y procesos necesarios para crear y mantener listas consistentes y precisas de los datos maestros”. Hay un par de cosas que cabe destacar en esta definición. Una de ellas es que MDM no es sólo una cuestión tecnológica. En muchos casos, se requerirán cambios fundamentales en el proceso de negocio para mantener la limpieza de datos maestros, y algunos de los temas más difíciles de MDM son más políticos que técnicos. El segundo aspecto a destacar es que MDM incluye tanto la creación como el mantenimiento de los datos maestros. Invertir mucho tiempo, dinero y esfuerzo en la creación de un sistema limpio y consistente de datos maestros es un esfuerzo inútil a menos que la solución incluya herramientas y procesos para mantener los datos maestros limpios y consistentes, a medida que es actualizada y ampliada. Si bien MDM es más eficaz cuando se aplica a todos los datos maestros de una organización, en muchos casos el riesgo y el costo de un esfuerzo de este tipo para toda la empresa son difíciles de justificar. Puede ser más fácil comenzar con unas pocas fuentes principales de los datos maestros y ampliar el esfuerzo, una vez que el éxito ha sido demostrado y las lecciones se han aprendido. Si usted empieza pequeño, debe incluir un análisis de todos los datos maestros que con el tiempo desee incluir, de modo que usted no tome decisiones de diseño o elija herramientas que le obliguen a empezar de nuevo cuando se trate de incorporar una nueva fuente de datos . Por ejemplo, si su implementación inicial del maestro de clientes sólo incluye a los 10.000 clientes de sus ventas directas, no querrá que las decisiones de diseño le impidan agregar sus 10.000.000 de clientes Web más tarde.
- 111. Capítulo 4: Datos 99 Si bien la Gestión de Datos Maestros es relativamente nueva, incluye dos subgrupos de gestión de datos que han existido por varios años: Integración de Datos de los Clientes (CDI) y Gestión de la Información de Productos (PIM). Integración de Datos de los Clientes (CDI) La Integración de Datos de los Clientes (CDI) se utiliza para proporcionar una visión única y consistente de los clientes de una organización. Esta parte de MDM es a menudo la primera en ejecutarse debido a que los datos del cliente son un aspecto sensible para muchas organizaciones. Por ejemplo, un banco que ha crecido a través de una serie de adquisiciones puede encontrar que tiene varios juegos de datos para el mismo cliente, si el cliente tiene cuentas o préstamos en más de uno de los bancos adquiridos. En un escenario de adquisición, los clientes pueden haber tenido ya cuentas y préstamos en ambos bancos. Cuando van a una oficina bancaria esperan poder acceder a todas sus cuentas con los dos bancos originales. El proyecto SOA debe incluir una aplicación de CDI para proporcionar esta integración. Una variación de la CDI es la gestión de los factores. Esto generaliza las técnicas de integración de datos del cliente a todos los “factores”, incluyendo clientes, proveedores, socios, empleados, distribuidores, proveedores, etc. Gestión de la Información de Productos (PIM) Otro elemento de la MDM es la Gestión de la Información de Productos (PIM). PIM unifica la información sobre los productos que una empresa maneja. Por ejemplo, un mayorista de autopartes que ha crecido con la adquisición de otros mayoristas, puede tener varios números de producto para las mismas piezas con descripciones y precios inconsistentes. PIM ayudará a detectar y corregir estas inconsistencias y proporcionar una vista unificada de las piezas en el inventario. En nuestro escenario, los “productos” son las cuentas, préstamos, y los instrumentos financieros aportados por los dos bancos. Proporcionar información consistente acerca de la oferta de productos de los bancos fusionados es el papel de un sistema de PIM. Arquitectura de concentradores de la Gestión de Datos Maestros (MDM) El concentrador de MDM es una base de datos con el software para gestionar los datos maestros que se almacenan en la base de datos, manteniéndola sincronizada con los sistemas transaccionales que usan los datos maestros. La figura 4 muestra la arquitectura de concentradores de un MDM típico.
- 112. 100 Capítulo 4: Datos Figure 4: Arquitectura de concentradores MDM El concentrador de MDM contiene las funciones y herramientas necesarias para mantener consistentes y precisas las entidades y jerarquías MDM. En esta arquitectura, los datos MDM se pueden acceder a través de una interfaz de servicios Web. La función de Sincronización de Datos Maestros es responsable de mantener los datos en el concentrador sincronizados con los datos en los sistemas transaccionales (representados en la parte superior de la Figura 4). Hay varios estilos alternativos de implementación utilizados para los concentradores de MDM. La siguiente sección describe tres de los estilos más utilizados. Estilos de arquitecturas para concentradores Hay tres estilos básicos de arquitectura utilizados para concentradores de MDM: el de repositorio, el de registro, y el enfoque híbrido. El enfoque híbrido es en realidad una combinación de enfoques entre los dos extremos de registro y repositorio, así que se dedicará más tiempo a los dos extremos. Repositorio En el enfoque de repositorio, la colección completa de los datos maestros de una empresa se almacena en una base de datos única. El modelo de datos de repositorio debe incluir todos los atributos requeridos por todas las aplicaciones que utilizan los datos maestros. Las aplicaciones que consumen, crean, o mantienen los datos maestros son modificadas para usar los datos maestros en el concentrador, en lugar de los datos maestros previamente mantenidos en la base de datos de cada aplicación. Por ejemplo, las aplicaciones de entrada de pedidos y CRM se modifican para utilizar el mismo conjunto de tablas de cliente en el concentrador principal de datos, en lugar de sus almacenes de datos propios. Las ventajas de este enfoque son bastante obvias. No hay problemas con el mantenimiento
- 113. Capítulo 4: Datos 101 de múltiples versiones del mismo registro de cliente en múltiples aplicaciones sincronizadas, ya que todas las aplicaciones utilizan el mismo registro. Hay menos posibilidades de registros duplicados, porque sólo hay un conjunto de datos, por lo que los duplicados son relativamente fáciles de detectar. Sin embargo, es evidente que no son imposibles, ya que situaciones como variantes ortográficas, sinónimos, diferentes ubicaciones para la misma empresa, errores tipográficos, y otras, son todavía posibles, y los concentradores MDM deben ser diseñados para tratar con ellos. Si bien el enfoque de repositorio tiene ventajas significativas para el mantenimiento de una fuente continua consistente de datos maestros, hay cuestiones importantes que deben considerarse al diseñar un concentrador de MDM basado en un repositorio: La cuestión más obvia es que no siempre es fácil o incluso posible cambiar las aplicaciones existentes para utilizar los datos maestros nuevos. Si usted no posee el código fuente de la aplicación, puede que no sea capaz de modificarla para utilizar el nuevo concentrador de datos maestros. Si el modelo de datos de la aplicación está muy cerca del modelo de datos del concentrador de MDM, usted puede ser capaz de utilizar vistas y servidores enlazados para que su aplicación crea que está hablando con sus propios datos, cuando en realidad está hablando con el concentrador de MDM. También he visto algunos sistemas que reducen el número de cambios necesarios en las aplicaciones mediante la creación de una aplicación independiente que hace parte del mantenimiento de los datos maestros, de modo que no toda la funcionalidad de la aplicación tiene que ser migrada para usar el concentrador de datos. Sin embargo, este enfoque es generalmente difícil de implementar de una manera que el usuario lo acepte. Probablemente, la adición de clientes en una aplicación diferente a la utilizada para las actualizaciones es inaceptablemente compleja. Por otro lado, una de las razones más comunes para la implementación de un concentrador de MDM es proporcionar datos limpios y consistentes para una implementación de SOA. Si usted está rescribiendo y envolviendo sus aplicaciones como servicios, puede que no sea absurdo crear nuevos servicios para gestionar los datos maestros. Otra cuestión que debe resolverse en la implementación de un concentrador de MDM de estilo repositorio es dar con un modelo de datos que incluya todos los datos necesarios, sin que sea tan grande que sea imposible de usar. Debido a que la base de datos del concentrador es utilizada por todas las aplicaciones en el modelo de repositorio, tiene que incluir toda la información necesaria para todas las aplicaciones. La respuesta simple a esto es hacer que la base de datos del concentrador sea un superconjunto de todos los modelos de datos de las aplicaciones. En este enfoque, un registro de cliente del concentrador incluye todos los atributos de los registros de clientes de todas las aplicaciones que utilizan el concentrador de MDM. Esto no es práctico, porque ignora muchos de los problemas que necesita resolver una solución de MDM. Por ejemplo, si hay cinco formatos para las direcciones, ocho formatos de números de teléfono, y seis identificadores de cliente diferentes, poner todas estas columnas en la base de datos de clientes del MDM haría que el concentrador de MDM fuera casi inutilizable. Cada consulta tendría que decidir qué dirección, número telefónico y número de cliente usar. Además, en muchos registros, sólo uno o dos formatos estarían poblados. La solución obvia a esto es establecer un estándar en toda la empresa para cada uno de
- 114. 102 Capítulo 4: Datos los elementos de datos en el concentrador de MDM, y modificar las aplicaciones de modo que consuman y produzcan los formatos estándares. Esto no es sólo un voluminoso trabajo para el departamento de TI, sino que la determinación del formato que debe ser el estándar es a menudo un problema político importante. Todos los propietarios de las aplicaciones creen que sus formatos de datos deben ser los elegidos - no porque sean mejores, sino porque los propietarios de las aplicaciones no quieren hacer los cambios necesarios para utilizar un formato diferente. No es inusual que las reuniones celebradas para establecer un modelo de datos estándar empleen tanto tiempo como el utilizado para la ejecución real del proyecto. Si hay elementos de datos que son utilizados por una sola aplicación, el esfuerzo de modelado de datos puede decidir eliminarlos, y esto podría implicar cambios significativos en la aplicación. Otro importante tema de modelado de datos es qué hacer con los elementos de datos que no son utilizados por todas las aplicaciones. Por ejemplo, un cliente agregado por una aplicación de entrada de pedidos es probable que tenga un número significativamente menor de atributos que un cliente añadido por la aplicación de CRM. O un producto añadido por marketing puede tener atributos que son muy diferentes de los de un producto añadido por ingeniería. En algunos casos, podría tener sentido asignar valores por defecto a los atributos no poblados, y, en otros casos, es posible que usted decida modificar la aplicación para rellenar los atributos extra. En una implementación de SOA, usted puede optar por llenar todos los atributos con el programa de servicio. En general, habrá casos en los que no sea deseable ni posible llenar todos los atributos de todas las aplicaciones. Un ejemplo típico es el de gestión de información de productos (PIM) que forma parte de un sistema MDM, en el que no tiene sentido mantener los mismos atributos para un producto que se compra para la reventa que para un producto que se fabrica en casa. Registro El enfoque de registro es lo contrario del enfoque de repositorio, ya que ninguno de los registros de datos maestros se almacena en el concentrador de MDM. Los datos maestros se mantienen en las bases de las aplicaciones, y el concentrador de MDM contiene listas de claves que se pueden utilizar para encontrar todos los registros relacionados con un ítem de un maestro de datos dado. Por ejemplo, si existen registros de un cliente en particular en el CRM, en la entrada de pedidos, y en las bases de datos del servicio a clientes, el concentrador de MDM contendrá un mapeo de las claves de estos tres registros a una clave común. Debido a que cada aplicación mantiene sus propios datos, los cambios en el código de la aplicación para implementar este modelo son mínimos, y los usuarios actuales de la aplicación generalmente no tienen que estar conscientes de la existencia del sistema MDM. La desventaja de este modelo es que todas las consultas contra los datos de MDM son consultas distribuidas en todas las entradas de datos deseados en todas las bases de datos de aplicación. Si la consulta se refiere a un cliente particular, esta probablemente es una consulta razonable. Pero si se desea una lista de todos los clientes que han ordenado un producto en particular en los últimos seis meses, es posible que tenga que hacer una unión distribuida con tablas de 5 o incluso 10 bases de datos. Hacer este tipo de consulta distribuida de gran envergadura de manera eficiente es bastante difícil. Este es el reino de la Integración de Información Empresarial (EII). Por lo tanto, a menos que sus necesidades sean
- 115. Capítulo 4: Datos 103 relativamente simples, es posible que deba ver las herramientas de consulta distribuida de EII para implementar el procesamiento de consultas en un concentrador de MDM de modelo de registro. Hay básicamente dos tipos de bases de datos de repositorio utilizadas para MDM. La primera tiene una fila de una tabla para cada entidad de datos maestros y las columnas para las claves de los sistemas de aplicación. Este es el más sencillo de implementar y el más eficiente en la operación, ya que todas las consultas distribuidas para un registro dado de MDM puede comenzar desde la primera base de datos. Un valor NULL para una clave particular, significa que la base de datos correspondiente no contiene un registro para la entidad dada del MDM. Hay dos problemas importantes con este esquema, sin embargo. En primer lugar, la adición de una aplicación al concentrador de MDM significa agregar columnas a la tabla de macheo de claves, lo cual no es un gran problema, pero también puede significar cambiar las consultas para incluir la nueva fuente de información. La segunda cuestión, más importante aún, es que este estilo supone que una determinada base de datos sólo tiene un registro para una entidad dada del MDM. Si bien esto sería lo ideal, es raro encontrarlo en una aplicación real. Una solución obvia sería primero limpiar las bases de datos de la aplicación, de modo que haya un sólo registro por cada elemento de los datos maestros. Este debe ser uno de los objetivos de cualquier proyecto de MDM, pero no siempre es posible hacer que la limpieza de la base de datos sea un requisito previo para la inclusión de una aplicación en el concentrador de MDM. Si no es práctico limpiar la base de datos de la aplicación antes de su integración en el concentrador de MDM, el repositorio puede ser diseñado con una fila para cada mapeo de la entidad MDM con un registro de aplicación. Por ejemplo, si Ford tiene 20 registros en la base de datos de CRM, el concentrador de MDM tendría 20 filas de mapeo de la identidad Ford del MDM con cada uno de los números de cliente diferentes del CRM. Este estilo resulta en consultas mucho más complejas y también plantea ciertos problemas, por ejemplo, cómo lidiar con 10 direcciones diferentes para el mismo cliente. En cualquier caso, podría ser un paso necesario en la evolución de su solución MDM. Saber que hay 20 registros de CRM para Ford es un primer paso necesario para consolidarlos en un registro único. Modelo híbrido Como su nombre indica, el modelo híbrido incluye características de ambos modelos, el de repositorio y el de registro. Este, por su parte, reconoce que, en la mayoría de los casos, no es práctico (en el corto plazo por lo menos) modificar todas las aplicaciones para que utilicen una única versión de los datos maestros, y también el hecho de que hacer todas las consultas del concentrador MDM como consultas distribuidas es muy complejo, y probablemente no va a proporcionar un rendimiento aceptable. El modelo híbrido deja los registros de datos maestros en las bases de datos de aplicación y mantiene llaves en el concentrador MDM, como se hace en el modelo de registro. Pero también replica los atributos más importantes de cada entidad principal en el concentrador MDM, de modo que un número significativo de las consultas al MDM pueden ser satisfechas directamente desde la base de datos del concentrador, y sólo las consultas que hacen
- 116. 104 Capítulo 4: Datos referencia a los atributos menos comunes tienen que acceder a la base de datos de la aplicación. Si bien al principio parece que el modelo híbrido tiene las ventajas de los otros dos modelos, es importante tener en cuenta que tiene características que no tiene ninguno de los otros modelos. Sólo el modelo híbrido incluye datos replicados (aparte de las claves), por lo que sólo el modelo híbrido puede hacer frente a conflictos de actualización y problemas de latencia de replicación. El modelo híbrido también plantea las mismas interrogantes relacionadas con el modelo de datos que el modelo de repositorio. ¿Qué atributos se almacenan en el concentrador?, ¿cuáles son llamados?, y ¿qué formatos deben tener? son cuestiones muy polémicas cuando el concentrador integra los datos de muchos sistemas diferentes. Aspectos arquitectónicos La siguiente es una breve discusión de algunos de los problemas de arquitectura que deben ser considerados en el diseño de la base de datos del concentrador MDM. Modelo de datos En los tres modelos, el proceso de diseño debe incluir un modelo de datos común para la base de datos del concentrador. En el modelo de repositorio, el modelo de datos del MDM se convierte en el modelo de datos de la base de datos del concentrador. El modelo incluye el mapeo de los modelos de datos de aplicación al modelo de datos MDM, pero estos mapeos sólo se utilizan para crear la base de datos del concentrador y definir los cambios necesarios en la aplicación para utilizar la base de datos del concentrador como la fuente de sus datos maestros. Los otros dos modelos de concentrador también requieren un modelo de datos MDM y los mapeos de las aplicaciones actuales, pero se utilizan de manera diferente. En el modelo de registro, el modelo de datos se utiliza para definir las consultas y las vistas, y el mapeo se usa para hacer las transformaciones necesarias para mapear los datos de aplicación con el modelo de datos MDM en cada consulta. En el modelo híbrido, los atributos comunes se replican en la base de datos del concentrador y los atributos no comunes se transforman como parte de las consultas, por lo que se utilizan ambos tipos de mapeos. Casi por definición, no habrá mapeos alternativos para algunos de los atributos y se deben definir reglas para definir cuales mapeos utilizar. Por ejemplo, la dirección postal de un cliente generalmente se almacena en varias bases de datos por lo que se deben definir reglas para controlar cual dirección uso en primera instancia y cual utilizar alternativamente si la dirección preferida no está disponible. (Estas reglas de negocio pueden llegar a ser bastante complejas si están integradas muchas bases de datos en el concentrador MDM. Vamos a tratar las reglas de negocio más adelante.) Los modelos de datos y las reglas de negocio se documentan en los metadatos del MDM y deben ser utilizados según sea necesario para la implementación del procesamiento conducido por los datos para poblar, dar mantenimiento y consultar los datos del concentrador MDM.
- 117. Capítulo 4: Datos 105 Modelo del concentrador MDM Hemos cubierto los tres modelos de bases de datos del concentrador, así que vamos a discutir la manera de decidir qué modelo usar. El modelo de repositorio es el más atractivo, ya que proporciona una fuente verdadera de los datos maestros que siempre está actualizada y consistente. Las otras opciones incluyen la replicación de datos, por lo que suele haber un poco de latencia entre las actualizaciones de datos y las actualizaciones del concentrador. Los datos maestros son por lo general bastante estáticos, por lo que un poco de latencia no es necesariamente inaceptable. Los otros enfoques diferentes del de repositorio también mantienen múltiples copias de algunos datos, por lo que la consistencia (manteniendo las copias iguales) es un problema que estos enfoques tienen que enfrentar. La desventaja del modelo de repositorio es que puede ser extremadamente costoso y puede requerir mucho tiempo para ponerse en práctica, ya que involucra cambios en las aplicaciones que mantienen y consumen los datos maestros. El modelo de repositorio tiene sentido si: el número de aplicaciones que participan en el proyecto de MDM es limitado, usted tiene suficiente control sobre las aplicaciones para realizar las modificaciones necesarias y la disponibilidad de datos maestros autoritativos y coherentes proporciona un valor de negocio suficiente para justificar el tiempo y los costos necesarios para construir un modelo de repositorio del concentrador MDM. Un modelo de registro del concentrador MDM es apropiado sólo cuando un número limitado de consultas, que no son críticas en cuanto al rendimiento, involucra el acceso a un número significativo de las bases de datos de aplicación integradas en el concentrador MDM. Los concentradores del modelo de registro son más baratos y rápidos de implementar y se pueden abordar para una fuente de datos a la vez, de modo que son buenas para la implementación gradual y proporcionan un retorno temprano de la inversión (ROI). Los modelos de registro no son buenos cuando las consultas de rutina devuelven atributos de muchas bases de datos de aplicación o cuando hay tanta duplicación de datos que es una decisión compleja la determinación de cuál de las fuentes alternativas de un atributo se ha de retornar. En estos casos, los datos pre-integrados y limpios proporcionados por un concentrador MDM de modelo híbrido, son una fuente más eficiente y consistente de datos maestros. Es importante señalar que el modelo híbrido no es un modelo único, sino un rango de opciones que se inician en el modelo de registro y continúan hasta el modelo de repositorio. Por esta razón, usted puede optar por empezar con una solución cercana al modelo de registro y ampliar gradualmente el número de atributos integrados en el concentrador MDM hasta que haya un repositorio de MDM implementado. Dado que los proyectos MDM pueden ser muy costosos y tomar mucho tiempo en una empresa grande con muchas aplicaciones, es bueno contar con una estrategia que permita realizar la implementación de forma incremental, aumentando gradualmente el número de atributos almacenados en el concentrador y adicionando progresivamente aplicaciones al concentrador. Esto le permite lograr un retorno de la inversión rápido para el proyecto de MDM, con un claro camino hacia una solución para toda la empresa a largo plazo. Versiones y jerarquías En la sección anterior se explicaron las opciones para la implementación de un concentrador MDM. Esta sección profundiza en esto un poco más, hablando de las versiones y las
- 118. 106 Capítulo 4: Datos jerarquías - dos características que son claves para la implementación de un concentrador MDM. Trata además por qué son importantes y presenta algunas opciones de implementación. Tablas de cruce En las opciones de implementación de estas dos características, me referiré frecuentemente a las tablas de cruce, así antes que todo voy a explicar a qué me refiero cuando digo tabla de cruce. (Si usted ya es un experto en tablas de cruce, puede pasar a la siguiente sección.) Uno de los conceptos fundamentales en las bases de datos relacionales es el uso de una clave externa para definir la relación entre filas relacionadas. Esto se hace mediante el almacenamiento de la clave de la fila relacionada, en una columna de la otra fila. Por ejemplo, si tengo una tabla de clientes y otra tabla de direcciones postales, puedo especificar la dirección de envío para un cliente, almacenando la clave primaria de la tabla de direcciones en una columna denominada "dirección-de-envío" en la tabla de clientes. Cuando usted quiere encontrar la dirección de envío de un cliente, utiliza el valor de la columna dirección-de-envío de ese cliente para buscar la dirección. Muchos clientes pueden utilizar la misma dirección usando la misma clave en su columna dirección-de-envío, pero no hay una manera de modelar el caso de un cliente con muchas direcciones de envío. En realidad, muchos clientes pueden tener la misma dirección, y un cliente puede tener muchas direcciones. Esto se llama una relación de muchos a muchos, y la forma más sencilla de modelarla es con una tabla de cruce. Una tabla de cruce se parece a lo mostrado en la Figura 5. Figura 5: Ejemplo simple de una tabla de cruce Otra característica útil de las tablas de cruce es que las columnas en la tabla de cruce pueden utilizarse para representar las propiedades de la relación. Por ejemplo, una relación entre clientes y direcciones podría representar una dirección de envío o una dirección de facturación para un cliente. Podríamos representar esto teniendo dos tablas de cruce diferentes - una para las direcciones de envío y una para las direcciones de facturación - o tener una tabla de cruce única para vincular a los clientes y las direcciones con una columna de tipo de conexión que se utiliza para diferenciar entre los enlaces asociados a la dirección de envío y la dirección de facturación, como se describe en la figura 6.
- 119. Capítulo 4: Datos 107 Figura 6: Tabla de cruce con tipo Téngase en cuenta que toda la información acerca de la relación se incluye en la tabla de cruce. Ninguna de las tablas que están enlazadas tiene alguna información sobre el enlace. Esto significa que usted puede crear una nueva relación entre tablas que forman parte de aplicaciones que no se pueden cambiar. Por ejemplo, puede crear una relación entre un registro de cliente en la aplicación de CRM y un registro de territorio en la aplicación de automatización de la fuerza de ventas, sin cambiar la base de datos. Versionado La gobernabilidad de datos y el cumplimiento de las normas son mucho más fáciles con un historial completo de versiones de todos los cambios en los datos maestros. A menudo no es suficiente con saber qué límite de crédito tiene un cliente hoy en día, sino que hay que saber cuál era su límite de crédito hace tres meses, cuando al cliente se le cobraba una tasa de interés alta por exceder su límite. Si bien este es un ejemplo sencillo, hay muchos casos en los que puede requerirse el conocimiento de los valores pasados de los atributos de los datos maestros. Esto muestra al versionado como una característica clave para sistemas de gestión de datos maestros. El versionado también se requiere para apoyar las actividades de administración y gobernabilidad de datos maestros. Cuando los datos maestros son modificados, se aplican reglas de negocio a las modificaciones para determinar si cumplen con las normas elaboradas por la organización de gobernabilidad de datos. Los administradores de datos también usan información de la versión para monitorear los resultados de las actualizaciones y, si es necesario, restaurar los valores originales. Cuando la mayoría de los desarrolladores piensa en el versionado, se imagina los sistemas de control de código fuente, que tienen capacidades plenas de ramificación y fusión. Si su concentrador MDM necesita este tipo de versionado, las versiones son implementadas generalmente con tablas de cruce que enlazan las filas en una tabla de versiones con una versión particular del registro de MDM. Un esquema simplificado de los enlaces podría parecerse a la Figura 7. Figura 7: Tabla de versiones de los enlaces Nótese que John Smith cambió en la versión 1.1, así que hay dos filas diferentes para John Smith, pero Sam Spade no ha cambiado, por lo que ambas versiones apuntan a la misma fila.
- 120. 108 Capítulo 4: Datos En este esquema, la adición de una nueva rama consiste en añadir una fila a la tabla de versiones y la creación de filas de la tabla VersionLink para cada cliente. A medida que los clientes se actualizan, se inserta una nueva fila por cada fila modificada del cliente y el vínculo se cambia para que apunte a la nueva fila. Aunque este método ofrece una gran flexibilidad, millones de clientes y cientos de ramas producen grandes tablas de cruce, por lo que la gestión del volumen de datos puede ser un problema. Además, incluso consultas bastante simples como "seleccionar todos los clientes con una factura vencida" involucran varias combinaciones para obtener la versión correcta de los registros de los clientes. En mi opinión, la mayoría de los sistemas de MDM no requieren este nivel de flexibilidad del versionado, y una flexibilidad reducida en favor de la simplicidad y el rendimiento, es una buena opción. Uno de los esquemas de control de versiones más simples es añadir una columna "EffectiveDate" para cada fila de datos maestros. Cuando un elemento de los datos maestros se modifica, una copia nueva de la fila se inserta con la fecha y hora que se hizo el cambio asignadas a la columna "EffectiveDate". (Bueno, tal vez debería ser "EffectiveDateTime.") Cuando usted desea consultar la versión más reciente de todos los clientes, debe buscar usando MAX (EffectiveDate). Si usted quiere conocer el contenido de un registro de cliente en una fecha determinada, busca la fila con el máximo EffectiveDate para aquellos registros en que el EffectiveDate es menor que la fecha que usted está buscando. Uno de los inconvenientes de mantener un historial de versiones de todas las entidades de los datos maestros es que incluso una consulta sencilla tiene que lidiar con las versiones para recuperar la versión correcta de los datos. Una forma de simplificar esto es crear una vista que exponga la versión más reciente de todos los objetos, de modo que los usuarios que sólo se preocupan por la última versión puedan escribir consultas simples, y sólo los usuarios que necesitan una versión particular estén obligados a lidiar con la complejidad de las versiones. Otra solución alternativa que también puede reducir la sobrecarga en la gestión de la base de datos del concentrador es, en lugar de insertar una nueva fila en la tabla de datos maestros cuando un registro se modifica, modificar realmente el registro maestro y poner la versión anterior en una tabla histórica. Esto puede hacer que sea menor el orden de magnitud de las tablas de datos maestros, además de hacer que las consultas que no involucran la versión, sean más simples de escribir. Debido a que los datos históricos se acceden con menor frecuencia que la última versión, aquellos se pueden almacenar en discos más lentos y más baratos para reducir el costo total del sistema. Otro problema que resuelve el enfoque de la tabla histórica es lo que sucede cuando cambia el esquema de los datos maestros. Por ejemplo, al agregar columnas a la tabla de clientes, ¿qué valor se pone en las nuevas filas de versiones antiguas del registro de usuario que no se incluyen las columnas? O, más importante aún, si se elimina una columna, ¿qué ocurre con la información almacenada en las versiones anteriores? Con las tablas históricas, cada versión de esquema se puede almacenar en una tabla histórica por separado con el esquema que estaba en uso en el momento en que las filas fueron creadas. Obviamente, esto hace que las consultas contra los datos históricos sean más complejos, ya que se necesita saber la tabla que contiene las versiones deseadas, pero proporciona una representación más precisa de la historia - otra compensación a considerar. La última opción para representar las versiones es el uso de registros de cambio similares a los deltas mantenidos en un sistema de control de código fuente. En este esquema, la versión
- 121. Capítulo 4: Datos 109 actual se almacena junto con un registro de los cambios que se hicieron para llegar a la versión actual. Para obtener una versión anterior, se empieza con la versión actual y se deshacen los cambios de la bitácora hasta llegar a la versión que se desea. Esta es obviamente mucho más compleja que las opciones anteriores, pero la cantidad total de datos almacenados en este caso es mucho menor. Usted no debe considerar este modelo si tiene que hacer una gran cantidad de consultas contra las versiones anteriores, ya que pueden ser muy costosas. Por ejemplo, obtener una lista de precios de los productos para todos los productos a partir del 2 de diciembre de hace dos años, requeriría la reconstrucción de todos los clientes a partir del registro de cambios. Jerarquías Para efectos de este capítulo, la gestión de jerarquía se define como: “la capacidad para definir y almacenar relaciones entre registros de los datos maestros en el concentrador MDM”. Las relaciones son una parte crítica de los datos maestros: los productos son vendidos por vendedores, los empleados trabajan para los gerentes, las empresas tienen filiales, los territorios de ventas contienen clientes, y los productos están hechos de piezas. Todas estas relaciones hacen que los datos maestros sean más útiles. Muchas relaciones existen en sus sistemas actuales. Por ejemplo, su sistema de recursos humanos puede saber quién trabaja para quién o qué organización paga su salario. Otro tipo de relaciones pueden ser definidas sólo porque el concentrador MDM integra los datos de múltiples sistemas. Por ejemplo, la vinculación de un cliente en el sistema CRM a un contrato de servicio en el sistema de servicio a clientes puede ser difícil de hacer si los sistemas no se conocen entre sí, pero si tanto los clientes como los contratos de servicio se almacenan en el concentrador MDM, se puede definir una tabla de cruce para el seguimiento de esta relación. Algunas jerarquías son temporales o de propósito especial. Por ejemplo, si sus equipos de desarrollo están organizados en una estructura matricial, los gastos y salarios pueden acumularse en una estructura de gestión del presupuesto y en una estructura de proyecto para el control de plazos y reportes de gastos. Las jerarquías MDM deben tener nombre, ser descubribles, versionadas, gobernadas, y compartidas. Por ejemplo, si deseo saber cómo se acumulan los gastos para el proyecto XYZ o quien le reporta a John Smith, debo ser capaz de seleccionar la adecuada jerarquía de una lista y saber si es autoritativa y cuando entró en vigor. Esto significa que cualquiera que mira a los gastos del proyecto utiliza la misma estructura, en lugar de estar todo el mundo usando una hoja de cálculo que se haya encontrado. Esto también significa que si un auditor quiere saber quién estaba trabajando en el proyecto el 2 de noviembre de 2004, hay un único lugar con autoridad para ofrecer la respuesta. A los ejecutivos les encanta esta variante, ya que ayuda a mantenerlos fuera de la cárcel. Para dar soporte a las relaciones entre las entidades sin necesidad de introducir cambios en las entidades, la mayoría de las jerarquías se implementan como tablas de cruce. Si los datos ya contienen relaciones importadas de los sistemas de origen, tiene sentido, por lo general, dejar sólo estas relaciones para mantener la fidelidad entre el concentrador MDM y el sistema de origen. Pero usted puede decidir convertirlas en jerarquías implementadas como tablas de cruce para aprovechar las características de gestión de jerarquías del concentrador, así como para proporcionar un formato estándar para las jerarquías.
- 122. 110 Capítulo 4: Datos La figura 8 muestra una vista simplificada de lo que podría ser un modelo de datos de gestión de jerarquías. Figura 8: Tabla de cruces para jerarquías En realidad, habría algo más de metadatos de la jerarquía y, probablemente, más propiedades en la filas de la tabla de cruces. Si usted implementa todas las jerarquías en la misma tabla o crea una tabla para cada jerarquía dependerá de qué tan uniforme y grandes sean sus jerarquías. Una jerarquía por tabla es la forma correcta de modelarlo, desde la perspectiva de la teoría relacional, pero si usted tiene cientos de jerarquías bastante pequeñas, la combinación de ellas puede simplificar el mantenimiento de la base de datos. Hay, así mismo, una serie de opciones intermedias. Por ejemplo, puede agrupar todas las jerarquías que utilizan el mismo par de claves en una tabla o agruparlas por el uso - contabilidad en una tabla, recursos humanos en otra, y CRM en una tercera. Población y sincronización En este momento usted debería tener una buena comprensión de los problemas arquitectónicos en torno a decidir cómo será la base de datos del concentrador MDM y qué tipo de datos se mantienen en el mismo. En esta sección, hablaremos de cómo poblar el concentrador de datos buenos y limpios, y cómo asegurar que los datos se mantengan limpios y consistentes. Esto implica poblar inicialmente la base de datos del concentrador desde los sistemas de origen, y - con la excepción de los concentradores de modelo de repositorio puro - mantener los sistemas de origen sincronizados con la base de datos del concentrador a medida que estos realicen cambios en los datos. Carga en lotes: ETL La población inicial de un concentrador MDM es muy similar a poblar las tablas de dimensiones en un almacén de datos relacionales. En muchos casos, se pueden utilizar las mismas herramientas para la extracción, transformación y carga (ETL) del concentrador MDM que las que se usan para poblar un almacén de datos. Muchas implementaciones de MDM utilizan herramientas estándar de ETL o herramientas derivadas de las herramientas de ETL. Un proceso de carga típico incluye los siguientes pasos: 1. Extraer los datos del sistema de origen. Esto se debe hacer un tema de cada vez, para facilitar las cosas. Esta es la parte del proceso que puede requerir que se adquiera o desarrolle un adaptador para conectarse al origen de datos. Y de nuevo, los mismos adaptadores que se utilizan para extraer los datos de las dimensiones en los almacenes
- 123. Capítulo 4: Datos 111 de datos deben trabajar aquí, a menos que usted esté utilizando una herramienta que no es compatible con los adaptadores estándares. Esta es básicamente una operación por lotes, por lo que muchas herramientas van a extraer hacia un archivo de intercambio, mientras que otras realizarán la extracción directamente hacia el flujo de ETL. 2. Transformar los datos al modelo del concentrador de datos. Como parte del proceso de diseño del concentrador, se definió un modelo de datos junto con el mapeo de cada fuente con el modelo común del concentrador. Este paso del proceso realiza los cambios necesarios para transformar la entidad principal de datos maestros del modelo de datos de la aplicación al modelo de datos del concentrador MDM. De nuevo, esto es algo estándar en ETL y podría incluir el cambio de nombres de columnas, cambiar los tamaños de campo, el cambio de formatos de campos como los números de teléfono y direcciones para que coincidan con los formatos estándares del concentrador de MDM, la combinación de varias columnas en una sola columna, y el desglose de los valores de una columna en varias columnas. 3. Comprobar si hay duplicados. Este proceso es la "receta secreta" de la mayoría de los sistemas MDM. Es a la vez la parte más difícil y la más importante del proceso de poblar el concentrador MDM. Si desea una vista única de sus clientes o de los productos, los registros que describen la misma entidad deben ser combinados en un registro único para cada entidad única, pero si su sistema MDM es demasiado agresivo en la búsqueda de duplicados, determinadas entidades podrían desaparecer cuando se determina incorrectamente que ya están en el sistema. Por ejemplo, el algoritmo de detección de duplicados puede decidir que George W. Bush y George H. W. Bush son la misma persona, de modo que la información sobre uno de ellos puede perderse. Esta es una de las razones por las que las dos versiones de los registros deben ser almacenadas en el historial de versiones, de modo que este tipo de error se pueda corregir si es necesario. Algunos de los algoritmos de comprobación de duplicados son bastante simples y chequean cosas como deletreos alternativos y la ausencia ciertas palabras, por ejemplo, John Smith, Mr. John Smith, J.T. Smith, y así sucesivamente. Si bien estos son adecuados para bases de datos razonablemente pequeñas, la posibilidad de cotejos falsos es alta. Algoritmos más sofisticados pudieran chequear a las personas con la misma dirección o con los mismos números telefónicos. Otros sistemas pudieran utilizar datos externos como los datos de la guía telefónica, o los listados de Dun & Bradstreet7 para encontrar coincidencias. Muchas herramientas se especializan en ciertos tipos de datos – por ejemplo, datos médicos de los pacientes, de bienes de consumo, o de piezas de automóviles. Si existe una herramienta disponible para el tipo de datos con que usted trabaja, estas herramientas especializadas pueden proporcionar cotejos muy precisos. Otras herramientas son más genéricas y, a menudo, le permiten especificar sus propias reglas de cotejo para adecuarse a datos específicos. Casi todas las herramientas de macheo proporcionan un indicador del "grado de confianza" para cada coincidencia que detectan, y su proceso de carga debe especificar qué nivel de confianza es necesario para aceptar una coincidencia. Por ejemplo, usted puede decidir que un nivel de confianza del 95 por ciento es suficiente para encontrar de 7 Dun & Bradstreet es una compañía estadounidense dedicada al suministro de información comercial, de riesgo y financiera de las empresas. (Nota del traductor)
- 124. 112 Capítulo 4: Datos forma automática una entidad, los casos con niveles de confianza entre un 80 y un 95 por ciento se deben marcar para el procesamiento manual, y un nivel por debajo del 85 por ciento no se considera una coincidencia. Los valores que usted elija dependerán de las consecuencias de un cotejo falso y de un registro perdido. Si el resultado de un error es el envío de dos folletos de marketing, cuando habría sido suficiente uno, el nivel de confianza no tiene que ser alto, pero si un error puede provocar que una persona sea arrestada por evasión de impuestos o que se aplique mal un tratamiento por una enfermedad, será bueno estar muy seguro. 4. Cargar la base de datos del concentrador MDM. Si un nuevo registro no está en la base de datos del concentrador, esto es sólo una cuestión de insertar los datos en las tablas adecuadas. Pero si es un duplicado, el proceso de carga debe revisar las reglas de negocio de esta entidad para decidir qué datos se actualizan con el registro de entrada. Por ejemplo, si no hay dirección de envío en el registro actual y el registro de entrada incluye una dirección de envío, la dirección se agrega. Si ya existe una dirección de envío y el registro de entrada también tiene uno, debe haber una regla específica para decidir cuál mantener o si ambas se deben mantener. Si las reglas de negocio no pueden resolver el conflicto, el registro de entrada debe ser puesto en una cola para su procesamiento manual. Si el concentrador MDM sigue un modelo de registro o híbrido, aunque ninguno de los datos del registro de entrada se utilice, la clave del registro debe añadirse a la base de datos para registrar la relación del registro del concentrador con el registro de origen. Esto puede usarse en las consultas para encontrar el registro de origen o por el concentrador para publicar actualizaciones del concentrador a los sistemas de origen. Consulte la siguiente sección con más información acerca de este tema. 5. Actualización de los sistemas fuente. Si cargando un nuevo récord cambia la base de datos del concentrador, puede ser necesario propagar el cambio a uno o más de los sistemas de origen. Por ejemplo, si se agrega una nueva dirección de envío a un registro de cliente, las aplicaciones que almacenan información acerca de este cliente quizás desean utilizar la nueva dirección. Digo quizás, porque hay casos en los que una aplicación necesita continuar usando la dirección antigua y hacer caso omiso de la nueva. Voy a cubrir este proceso con más detalle en la discusión de la sincronización, pero quería mencionarlo aquí solo por motivos de completamiento. Como he dicho al principio de esta sección, si el concentrador MDM utiliza el modelo de repositorio, reemplazará las bases de datos en los sistemas de origen, por lo que este paso no es necesario. El proceso de carga de los datos de una aplicación fuente en el concentrador MDM puede tomar mucho tiempo, si hay una gran cantidad de datos y si es necesaria una cantidad significativa de procesamiento manual para resolver los problemas de calidad de los datos. En muchos casos, es aconsejable cargar una aplicación de origen en el concentrador y utilizarla durante unos días o quizás semanas para asegurarse que todo funciona correctamente antes de cargar la siguiente aplicación. El proceso de carga funciona mejor si las fuentes de información más autorizadas y completas se cargan primero, de manera que las cargas posteriores impliquen relativamente pocos cambios en los datos existentes en el concentrador. Prioritariamente, sin embargo, lo mejor es comenzar por registrar los duplicados y sincronizar los datos de la aplicación con los datos del concentrador. Cargando las bases de datos más críticas primero también conduce a una rápida valorización del proceso, lo que puede ser importante en la justificación de la inversión MDM.
- 125. Capítulo 4: Datos 113 Sincronización Ahora que el concentrador MDM se ha poblado con una versión única y autorizada de los datos maestros, es necesario desarrollar un proceso para mantenerlos limpios y autoritativos. Esto significa la implementación de un método de cambios en los datos existentes e inserción de nuevos datos maestros en el concentrador MDM, manteniendo el mismo nivel de limpieza de los datos que se logró durante la carga del concentrador desde las aplicaciones originales. Una forma de mantener la base de datos del concentrador MDM es impedir que las aplicaciones de origen realicen cambios en las entidades de los datos maestros y por lo tanto forzar que todas las adiciones y cambios a los datos maestros se hagan en la base de datos del concentrador. Esta es la técnica más sencilla de implementar y administrar, ya que sólo una base de datos se actualiza y todas las actualizaciones pueden ser estrechamente vigiladas y controladas para asegurar la conformidad con las reglas de negocio. La principal dificultad con la implementación de esta técnica para el mantenimiento de los datos maestros, es que se requiere que ninguna de las aplicaciones de origen haga cambios a los datos maestros. Por ejemplo, nadie puede agregar a un cliente en el sistema CRM y nadie puede cambiar la definición de un producto en el sistema ERP. Todos los cambios deben pasar por el sistema MDM nuevo. En muchas organizaciones, el reentrenamiento y los cambios operacionales necesarios para hacer este trabajo son difíciles de llevar a la práctica. Por otro lado, si este proyecto MDM es parte de una iniciativa SOA, la implementación de nuevos servicios para gestionar los datos maestros pueden incorporarse en el conjunto del proyecto SOA. No voy a gastar mucho tiempo en exponer la manera de construir este servicio, ya que es, en general, un servicio básico de mantenimiento de datos. Si usted tiene acceso a los sistemas de origen, es posible que desee utilizar una versión modificada de los mejores procedimientos de mantenimiento de datos maestros que tiene actualmente o, al menos, utilizar las reglas de negocio y la lógica de validación de los sistemas de origen. La única cosa a recordar aquí es que tener una base de datos maestros única no significa que usted no tiene que preocuparse de los duplicados. Es posible todavía que un usuario cree una nueva entidad en lugar de modificar una ya existente (y, en algunos sistemas, en realidad es más fácil crear una nueva entrada que encontrar y modificar una ya existente), por lo que el servicio del concentrador MDM debe seguir verificando las posibles entradas duplicadas. Si el traslado de todo el mantenimiento de los datos maestros al concentrador MDM es técnica u organizacionalmente imposible, se puede considerar un proceso de sincronización que transfiera los registros de datos maestros cambiados desde la aplicación de origen que hizo el cambio hacia el concentrador MDM. El concentrador MDM luego procesa el cambio con la misma lógica que se utilizó originalmente para poblar el concentrador. Esto introduce la posibilidad de que los cambios e inserciones de múltiples sistemas entren en conflicto, y se introduce un poco de latencia entre el momento de hacer un cambio y el momento en que este aparece en la base de datos del concentrador MDM, por lo que la empresa debe entender las limitaciones de este sistema.
- 126. 114 Capítulo 4: Datos En la mayoría de los sistemas, la tasa de cambios en una determinada entidad de datos maestros es bastante baja, por lo que los conflictos de actualización deben ser bastante raros y por lo tanto resulta razonable resolverlos de forma manual o con las reglas de negocio. Esto es especialmente cierto para los atributos de datos que representan entidades del mundo real. Por ejemplo, la posibilidad de que dos cambios conflictivos en el número de teléfono o la dirección de un cliente ocurran el mismo día es bastante remota. Para reducir aún más las posibilidades de conflictos de actualización, es posible introducir el concepto de fuente preferida de datos. Por ejemplo, si no es factible cambiar el proceso de mantenimiento de la información de producto por un nuevo servicio de mantenimiento de los datos del producto, aún puede ser posible limitar el mantenimiento de cualquier producto a un solo sistema. Esto elimina conflictos de actualización, sin necesidad de una renovación total del proceso de mantenimiento de los productos. El reto técnico más importante en la transferencia de los cambios en los datos maestros desde las aplicaciones de origen hacia el concentrador MDM es detectar los cambios en el sistema de origen. Si usted tiene acceso al sistema de origen, pudiera añadir un poco de lógica para enviar cada cambio de los datos maestros al concentrador MDM a medida que se produce en la base de datos de la aplicación. Otra opción es utilizar disparadores de la base de datos para detectar los cambios, si tiene suficiente conocimiento y control de la base de datos de la aplicación como para hacer esto. La replicación también pudiera ser una buena alternativa, si las entidades son lo suficientemente simples como para determinar cuál es el cambio en una entidad dentro de los datos replicados. Desafortunadamente, es posible que ninguna de estas opciones funcione en su situación, por lo que tendría que recurrir a consultar periódicamente la aplicación o incluso acudir al análisis de los registros de auditoría para detectar los cambios. Después de haber detectado un cambio en el sistema de origen, debe ser enviado al concentrador MDM lo más rápidamente posible para reducir la latencia de actualización. En general, recomiendo utilizar mensajería confiable para esta tarea, con el objetivo de asegurar que los cambios no se pierdan en fallos de red o de sistema. Microsoft BizTalk Server y Microsoft SQL Server 2005 Service Broker son, probablemente, las mejores alternativas para esto en la plataforma de Microsoft, pero dado que las aplicaciones de origen pueden ejecutar en una variedad de plataformas, otras alternativas pudieran ser adecuadas. Por otro lado, si usted está utilizando el concentrador MDM principalmente para la presentación de reportes y la gestión de la jerarquía en un ambiente de inteligencia de negocios (BI), puede ser que la latencia no sea un gran problema, de modo que la carga de los cambios en la base de datos del concentrador con herramientas MDM orientadas a lotes proporcionará adecuada frescura de los datos, con un nivel de sobrecarga y complejidad significativamente menores. La Figura 9 muestra una aplicación de CRM adicionando un cliente al concentrador MDM llamando al Servicio CreateEntity.
- 127. Capítulo 4: Datos 115 Figura 9: Servicio CreateEntity La adición de un nuevo cliente al concentrador MDM típicamente requiere seis pasos: 1. Los datos de entrada se mapean al modelo de datos del MDM, utilizando las mismas transformaciones usadas en el proceso de ETL que se describió anteriormente. Esto hace más fácil el chequeo de duplicados y pone el registro en un formato común que se puede utilizar en el resto del proceso. 2. El concentrador busca la entidad en la base de datos del concentrador para ver si ya está ahí. Esto no es una simple consulta SQL, sino que incluye toda la lógica difusa del proceso de eliminación de duplicados que se utilizó al crear la base de datos del concentrador. Por esta razón, es bueno buscar una herramienta que pueda realizar la búsqueda de duplicados en modo de procesamiento en lotes, y también hacer la búsqueda de una entidad de cada vez. Como he explicado en la sección de ETL, hay tres posibles resultados de la búsqueda: entrada duplicada encontrada, no existe la entrada, y no se sabe. Si la respuesta es que no se sabe, la entidad se pone en una cola para ser analizada por el administrador de datos (la administración será tratada en una sección posterior). 3. Si se encuentra un duplicado, otra aplicación ya ha añadido esta entidad, por lo que esta inserción se cambiará por una actualización. La entidad en el concentrador se revisa para ver si ya existe una entrada de esta entidad en la aplicación CRM. Si es así, esta entrada es un duplicado de la base de datos CRM, por lo que la entidad que ya está en la base de datos CRM se actualiza con los nuevos datos, y la entidad que la aplicación de CRM está tratando de agregar será eliminada para cancelar la duplicación. Por otro lado, si la
- 128. 116 Capítulo 4: Datos entidad en el concentrador MDM actualmente no tiene una clave para la aplicación de CRM, la clave para la entidad de entrada se agrega a la entidad del concentrador, y la entidad entrante se transmite como una actualización al flujo de trabajo de aprobación. 4. Si la entrada no se encontró en el concentrador MDM, se pasa al proceso de aprobación como una inserción. En este punto, los tres flujos convergen de nuevo, y un flujo de trabajo automatizado comprueba los datos de actualización o inserción para verificar que cumplen con tod4( )] TJ0696 669.4 Tm[3(t)5(o, )-149(l)] TJET5[( ) 669.4 TmTBT1 0 0 1 Tm[(ent)-2(r)5(an
- 129. Capítulo 4: Datos 117 datos limpios a todas las aplicaciones de origen. Si usted determina que es necesario publicar las actualizaciones de los datos maestros, la siguiente decisión es si se deben propagar los cambios a las aplicaciones de origen, o se debe permitir que las aplicaciones de origen saquen los cambios del concentrador. Sacar es generalmente más fácil de implementar y administrar, pero propagar reduce el tiempo entre el momento en que el concentrador se actualiza y el momento en que las actualizaciones están disponibles en las aplicaciones de origen. Sacar también es generalmente más fácil de implementar entre sistemas heterogéneos. Si el concentrador MDM se implementa sobre SQL Server y uno de los sistemas de origen está sobre mainframe, probablemente será mucho más fácil hacer que el mainframe lea un archivo de cambios que escribir una aplicación para propagar los cambios en la aplicación del mainframe. Este es el clásico compromiso de capacidad versus complejidad, y el factor decisivo es por lo general el requerimiento de actualización de los datos maestros ponderado contra la dificultad de lograr la integración. La opción de propagar se parece a la replicación en la superficie y, en algunos casos, la réplica puede ser la mejor manera de propagar los cambios. Esto funciona si el modelo de datos de la aplicación de origen está muy cerca del modelo de datos del concentrador MDM y hay una conexión de réplica disponible. Si los dos modelos de datos son significativamente diferentes, si la replicación no está disponible entre las bases de datos, o si la actualización directa de la base de datos de la aplicación de origen no está permitida, un servidor de integración (como BizTalk Server) es probablemente la mejor opción. Si es necesario, esto puede incluir transformaciones complejas de los datos e incluso una orquestación para hacer la actualización en varios pasos. La orquestación también se puede utilizar para publicar las actualizaciones de forma selectiva, sólo a las aplicaciones que lo requieran. Por ejemplo, sólo los sistemas CRM que contienen un registro para un cliente recibirán las actualizaciones correspondientes a ese cliente. Si va a publicar desde una base de datos SQL Server hacia otra base de datos SQL Server, SQL Service Broker (SSB) es una buena opción para una conexión asíncrona fiable y la aplicación transaccional de los cambios requeridos. Si el esfuerzo y la complejidad de implementar y mantener una solución de propagación son excesivos, puede que tenga que implementar una solución de sacar. La solución de sacar más simple es permitir a la aplicación consultar directamente la base de datos del concentrador MDM (o preferiblemente vistas de sólo lectura de la base de datos), para obtener los datos requeridos. Si la cantidad de datos maestros es bastante pequeña, la aplicación puede actualizar periódicamente sus datos maestros por completo, pero en la mayoría de los casos, la aplicación deseará actualizar sólo lo que ha cambiado. La introducción de columnas con marcas de tiempo es el método más común para abordar este problema. Cada aplicación mantiene un registro de la última vez que lo ha hecho y solo recupera los datos con marcas de tiempo mayores que el valor recordado. La desventaja de extraer datos directamente desde la base de datos es que, si se hace con frecuencia por un gran número de aplicaciones, esto puede causar una degradación importante del rendimiento. Una alternativa de extracción que hace que sea fácil para las aplicaciones aplicar los cambios y reduce la carga sobre la base de datos del concentrador MDM, es escribir los cambios en un diario o bitácora. Esta puede ser una tabla de la base de datos o un archivo plano. Si las actualizaciones están numeradas secuencialmente, una aplicación puede seguir las
- 130. 118 Capítulo 4: Datos actualizaciones que ya se han procesado. Si el número de aplicaciones de extracción de datos es relativamente pequeño, podría tener sentido generar una bitácora independiente por cada aplicación. Esto puede significar un montón de E/S extra, pero hace que sea más fácil de manejar si cada aplicación puede gestionar su propia bitácora - borrando los registros que ha procesado, por ejemplo. Por otro lado, es posible que usted desee mantener un diario de cambios con fines de auditoría, por lo que este diario puede cumplir una doble función. En una arquitectura de extracción, la aplicación podría sacar las actualizaciones por sí misma o utilizar una herramienta externa, ya sea desarrollada ad hoc o implementada con una herramienta ETL, para leer periódicamente los cambios y ejecutarlos en la aplicación de origen. Algunas bases de datos tienen la característica de capturar los datos modificados, lo que significa que registran en un fichero o tabla todos los cambios ocurridos en un conjunto específico de tablas, de modo que un sistema de extracción puede leer periódicamente los cambios capturados en lugar de tratar de determinar lo que ha cambiado. También es posible hacer ambas cosas, propagación y extracción, si su aplicación lo requiere. Por ejemplo, uno de los destinos a los que se propagan los cambios podría ser un servicio que escribe una bitácora para dar soporte a las aplicaciones de extracción. Integridad y confiabilidad de los datos Cuando se diseña una infraestructura MDM se debe tener en cuenta que el proceso complejo que ocurre de fondo para dar soporte diseña
- 132. 120 Capítulo 4: Datos Los aspectos técnicos de la administración de datos involucran un conjunto de herramientas que ayudan a un administrador a buscar, analizar y solucionar los problemas de calidad de los datos. Estas herramientas están integradas generalmente en una "consola de administración" que incorpora las herramientas de perfilado de datos, de análisis de datos, y de modificación de datos en una interfaz de usuario (UI) única. Si los administradores de datos son hombres de negocio, la consola de administración debe ser simple y altamente automatizada. En las organizaciones con complejas reglas de gobierno y procesos de aprobación, los flujos de trabajo pueden ser una parte útil de la consola de administración. Básicamente, las actualizaciones de los datos maestros que no se pueden aprobar automáticamente, se colocan en una cola para resolverse por el administrador apropiado. Un flujo de trabajo humano soportado por la automatización puede manejar los procesos de enrutamiento y aprobación de estos cambios. Perfilado de los datos Las herramientas de perfilado de datos pueden explorar los datos en busca de violaciones de las reglas de negocio, valores perdidos, valores incorrectos, registros duplicados, y otros problemas de calidad de datos. El perfilado de los datos en los sistemas de origen es un buen lugar para comenzar un proyecto de MDM, de modo que usted pueda averiguar la cantidad de problemas que existen. El perfilado puede ayudarle a elegir la fuente autoritativa de los datos y a diseñar la lógica ETL necesaria para limpiar y cargar los datos en el concentrador MDM. El perfilado también se debe hacer periódicamente después que el sistema MDM esté implantado, para determinar los problemas relacionados con la calidad de los datos que el sistema MDM no está resolviendo. Exportación Tan pronto como usted tiene una fuente limpia y precisa de datos maestros, tendrá que ser capaz de exportarla a otros sistemas que lo requieran. Por ejemplo, puede que tenga que exportar periódicamente los datos maestros de los productos para ser utilizados en un banco de datos o una campaña de marketing. (La mayoría de los gestores de bases de datos incluyen herramientas para la exportación de datos en un formato determinado o un esquema XML) Reportería La reportería incluye informes sobre los propios datos maestros - listas de clientes, información de productos, esquemas de organización, y así sucesivamente - incluidos los informes sobre la salud del concentrador MDM. Cosas como el número de violaciones de reglas detectadas, el número de intervenciones manuales necesarias, y la latencia media de las actualizaciones de los datos maestros, ayudará a la organización de TI a descubrir los problemas lo suficientemente temprano para evitar problemas mayores. Un sistema de información sólido que produce reportes "enlatados" y permite al usuario diseñar sus propios informes es una parte importante del concentrador MDM. Flujos de trabajo y reglas de negocio Un motor de reglas de negocio es fundamental para el éxito de un concentrador MDM. En muchos casos, las reglas son establecidas por administradores de datos relativamente poco sofisticados, por lo que un sencillo asistente o una interfaz de usuario para la elaboración de
- 133. Capítulo 4: Datos 121 las reglas pueden ser suficientes. Las reglas a menudo implican recuperar y manipular los datos de la base de datos, por lo que un motor de reglas que tenga buena integración con las bases de datos también sería útil. Herramientas Un proyecto de MDM también necesitará herramientas de modelado de datos para el almacenamiento de los modelos de datos de las aplicaciones de origen y el concentrador MDM. Si usted tiene un repositorio, la herramienta de modelado debe integrarse con el repositorio. También son necesarias herramientas de ETL para cargar los datos del concentrador, herramientas de calidad de datos, herramientas de creación de perfiles y herramientas de integración de aplicaciones. Si el concentrador utiliza un modelo de registro o híbrido, una herramienta de consulta distribuida puede ser necesaria para las consultas contra las entidades maestras, cuando algunas partes de los datos estén almacenadas en los sistemas de origen. Se requiere finalmente una herramienta para la definición y el mantenimiento de las jerarquías.
- 134. 122 Capítulo 4: Datos Resumen En este capítulo se presentó un resumen de algunos de los problemas comunes asociados con la gestión de datos y la integración en SOA. Hemos revisado una serie de estrategias de expansión, escalado, replicación y partición de bases de datos. Cerramos con una revisión de MDM y cómo un concentrador MDM puede ayudar en las estrategias de gestión de datos. MDM es una implementación bastante sencilla de tecnologías que probablemente ya estén disponibles en la mayoría de las grandes organizaciones. Si su organización ya tiene una función de administración de datos o al menos algunos modeladores y arquitectos de datos razonablemente competentes, es probable que tenga las capacidades necesarias para tener éxito. La mayoría de las grandes organizaciones tienen importantes cantidades de datos maestros, de modo que conseguir que todo esté bajo control llevará un tiempo. Comience con algo que tenga un alcance limitado, pero que tenga un gran valor para la organización. El éxito temprano es importante, no sólo para conseguir que la dirección decida continuar el proyecto, sino también para que el equipo del proyecto obtenga la satisfacción y la confianza que trae el despliegue de algo que tiene un impacto significativo. Tan pronto como usted tenga una parte del problema resuelto, debe aprender de las experiencias obtenidas, y repetir el ciclo tantas veces como sea necesario para completar el proceso de MDM. El capítulo cinco brinda un análisis detallado de la capacidad arquitectónica de interacción con el usuario.
- 135. Capítulo 4: Datos 123 Estudio de caso SOA: Bolsa de valores de Londres
- 136. 124 Capítulo 4: Datos
- 137. Capítulo 5: Interacción con el usuario 125 Capítulo 5: Interacción con el usuario “El diseño es inevitable. La alternativa al buen diseño es el mal diseño, no la ausencia de diseño." - Douglas Martin Autor Guía para el lector Los lectores de este capítulo continuarán desarrollando los conceptos introducidos en los capítulos previos, centrándose concretamente en la capacidad arquitectónica de interacción con el usuario. Figura 1: Capacidades arquitectónicas recurrentes La capacidad arquitectónica de interacción con el usuario se centra en la mejora de la interacción con el usuario8 (UX) asociada con aplicaciones y soluciones. Los tópicos discutidos en este capítulo incluyen: El impacto de una mala interacción con el usuario (UX) Priorización del diseño de UX Fricción cognitiva Una infraestructura para la UX 8 En lo adelante aparece frecuentemente en el texto el término “user experience” para el cual no he encontrado en este momento una traducción satisfactoria, por lo que he adoptado esta. (Nota del traductor)
- 138. 126 Capítulo 5: Interacción con el usuario ¿Qué es la arquitectura? Alguien dijo una vez “la arquitectura es el balance entre el arte y la ingeniería”. Si pensamos en la arquitectura de un edificio, como la Acrópolis, por ejemplo, se puede ver allí la mezcla de arte e ingeniería. Es hermoso, pero una gran cantidad de principios y conceptos de la ingeniería están presentes en ella. ¿Se aplica lo mismo a la arquitectura de software? ¿Existe también un equilibrio entre el arte y la ingeniería? En el caso de la ingeniería es obvio, la mayoría de los arquitectos con que hablas hoy en día tienen preocupaciones diferentes en ingeniería ya sea SOA, ESB, o una base de datos. Gran parte de la arquitectura de hoy se centra en la ingeniería y la infraestructura. De modo que la pregunta no es: “¿Qué es la arquitectura?”, la verdadera pregunta es: “¿Dónde está el arte en la arquitectura de software?“ ¿Hay arte y se cumple la analogía? Algunas personas dicen que el arte está en la belleza del diseño, o la belleza de un diagrama Visio en particular. Esto es incorrecto - el arte debe estar en la interacción con el usuario (UX). Debe estar en la interfaz que le damos a los usuarios y las aplicaciones que le damos. Esto nos lleva al problema central: la UX a menudo ocupa el último lugar en los proyectos. Hay arquitectos o equipos, que trabajan el 80-90% del proyecto en la infraestructura de la solución, asegurándose de que los servicios Web están funcionando bien y la base de datos está disponible permanentemente. Hacia el final del cronograma del proyecto se produce una loca carrera para pasar la solución a producción, y entonces alguien se da cuenta de que la interfaz de usuario todavía tiene que ser desarrollada. Esto se traduce en otro maratón para desarrollar una interacción de usuario (UX) simple en una semana o algo así. La UX es el componente de la solución que da la cara al usuario - ¿por qué no se le dedica más tiempo? Todos hemos visto buenos ejemplos de malas UX. Las m
- 139. Capítulo 5: Interacción con el usuario 127 cuenta de cómo se deben usar nuestras aplicaciones - cuando no deberían tener que pensar en el uso de la aplicación en primer lugar. ¿Por qué tiene la UX una prioridad baja en la mayoría de los proyectos? La mayoría de las organizaciones conoce su entorno, sus usuarios y el hardware y el software desplegados en toda la organización. Muchas organizaciones también tienen un personal de desarrollo dedicado. Estos son desarrolladores con un empleo a tiempo completo para la creación de aplicaciones que aportan valor a la organización. La mayoría de las organizaciones también tienen capacidades de negocio estables (por ejemplo, los productos fabricados esta semana es muy probable que continúen fabricándose la próxima semana, el mes que viene, incluso dentro de seis meses). Estas no suelen ser organizaciones que fabrican productos una semana y se transforman en una organización de servicios a la siguiente. Las aplicaciones tienden a reflejar de forma bastante estándar y bastante estable las capacidades del negocio. Algunas de estas organizaciones reaccionan ante las malas UX contratando diseñadores. Lamentablemente los diseñadores suelen aparecer al final del proyecto, mucho después de haber tomado las grandes decisiones de UI. Los diseñadores deben ser convocados al comienzo del proyecto para maximizar el impacto que pueden tener en la UX. En algunas organizaciones, las malas UX hacen que los usuarios se disculpen. Los usuarios sienten la necesidad de disculparse por no entender cómo utilizar las aplicaciones que les han entregado. Si un usuario no entiende cómo utilizar una aplicación, lo más probable es que el problema sea la UX, no el usuario.
- 140. 128 Capítulo 5: Interacción con el usuario Introducción de una plataforma para UX Tenemos que solucionar este problema - necesitamos una nueva perspectiva. Necesitamos una nueva forma de pensar no sólo para UX, sino para UX cuando se habla a la audiencia de arquitectura. El objetivo de este capítulo es introducir una infraestructura que se pueda utilizar para enfrentar estos problemas. La infraestructura de UX se ilustra en la Figura 3. Figura 3: Una plataforma para pensar en la UX Una forma de construir una infraestructura de UX es hacer preguntas a los usuarios sobre sus problemas e inquietudes. El año pasado llevamos a cabo un estudio interno pidiendo a los usuarios este tipo de preguntas - y hemos recibido algunas respuestas bastante sorprendentes. Aquí hay un par de las que recibimos: "¿Esta aplicación fue diseñada para mí o para un ingeniero? No entiendo cómo usarla." "El rendimiento es horrible. Esta aplicación es totalmente inutilizable. " Veamos una perspectiva detallada de las capas de la infraestructura de UX. Figura 4: Los tres aspectos de la capa de interfaces Interfaz Muchos de los tipos de preguntas que hacemos podrían clasificarse como “interfaz”. La interfaz es la brecha entre lo que se ve en la pantalla y lo que los usuarios realmente hacen. Hay tres aspectos a considerar dentro de la categoría de interfaz: Los personajes, la productividad y el rendimiento. Veremos estos aspectos en mayor detalle a continuación: Personajes Cuando un grupo TI piensa acerca de la UX se topará con el concepto de un usuario individual, genérico (por ejemplo, "El usuario no podrá hacer esto, lo que el usuario realmente
- 141. Capítulo 5: Interacción con el usuario 129 quiere es esto."). Esto significa que todos en el equipo de desarrollo tienen su propia idea acerca de quién es este usuario. La infraestructura de UX recomienda el uso de personajes en lugar de un usuario genérico. Un personaje es una persona ficticia que se basa en tantas características del mundo real como sea posible. Aquí se presenta un buen ejemplo: Sally es una “guerrera del camino”. He aquí un resumen de sus características: 38 años, casada 2 niños 5 años de experiencia en informática, mayormente en Windows/Office, habilidades en PowerPoint tiene entre 10 y 20 clientes – una mezcla de pequeñas y medianas empresas participa en pre-ventas se apoya en una computadora portátil y un dispositivo móvil Una vez que se desarrolla un perfil, es fácil construir una imagen de lo que sus personajes pueden y no pueden hacer. Mediante el uso de personajes en su proyecto usted tiende a centrarse en las cosas que realmente importan a los usuarios. Por ejemplo, si estamos diseñando una aplicación para un centro de llamadas, y sabemos que Sally pasa la mayor parte del día con los clientes – entonces también sabemos que necesita estar conectada con un teléfono móvil o a través de los quioscos de Internet. También podemos desarrollar otras personalidades - por lo general se desarrollan múltiples personajes para las soluciones. He aquí tres ejemplos adicionales: Derek es un operador del centro de llamadas. He aquí es un resumen de sus características: pasa 8 horas al día hablando por teléfono con los usuarios, en su mayoría con agravantes necesita ser muy productivo - Si puede tener acceso a los registros de llamadas más rápido se puede ahorrar unos pocos segundos en cada llamada, atendiendo a más clientes Jim es un ejecutivo. He aquí un resumen de sus características: pasa 8 horas al día pensando en los clientes, observando el panorama general piensa mucho en lo que se debe hacer a continuación, qué tipo de estrategia la organización debe seguir necesita un punto de vista abstracto, con el suministro de información de primer nivel lo más rápido posible Peter es un administrador de sistemas. He aquí un resumen de sus características: miembro del grupo de TI va a tener que dar soporte a nuestra aplicación responsable de mantener todo actualizado pasa el día entero apoyando a los usuarios necesita hacer cosas muy complejas utilizando la menor cantidad de tiempo (con el uso de scripts, si es posible)
- 142. 130 Capítulo 5: Interacción con el usuario ¿Por qué no basta con utilizar usuarios reales? A diferencia de los usuarios reales, los personajes le permiten abstraerse un poco, cambiando los perfiles de los personajes para satisfacer las necesidades de la aplicación. También es importante comprender que los usuarios reales a menudo no saben muy bien lo que quieren. Si bien esto puede sonar un tanto pomposo es definitivamente cierto - los usuarios a menudo no son capaces de articular sus necesidades, y no necesariamente tienen una buena comprensión de lo que sucede en una buena UX. Los personajes nos permiten ser abstractos y pensar de forma original y creativa acerca de la UX. Los personajes nos permiten pasar de las afirmaciones del tipo “la mayor parte de los usuarios tendrán acceso a una impresora en esa pantalla” a “Derek tendrá acceso a una impresora ya que trabaja en el centro de llamadas, pero Sally trabaja en la calle, así que necesita otra opción para imprimir”. Los personajes hacen pensar en las personas diferentes de manera diferente. Los personajes nos permitan avanzar de afirmaciones como “esto sería más rápido de desarrollar que una aplicación Web” a otras como “para Sally y Peter una interfaz Web puede tener sentido, sin embargo, Derek tiene un montón de atajos de teclado a los que está acostumbrado, así que tal vez deberíamos pensar en algo diferente para él.” Recomendaciones sobre los personajes 1. La definición de los personajes debe ser el primer paso para cualquier diseño de interacción. 2. Los personajes pueden ayudar a resolver los debates en el equipo de desarrollo, y ayudar a determinar cuáles errores hay que depurar y cuales opciones deben eliminarse. Productividad Cuando se entrega una nueva pieza de software a un usuario se verá normalmente una curva de productividad similar a la que se muestra en la Figura 5. Figura 5: Productividad versus tiempo para la UX Inicialmente, la productividad cae a medida que el usuario se acomoda a una nueva aplicación. Con el tiempo el usuario se familiariza con la nueva aplicación y se eleva su productividad como resultado del uso de la aplicación (preferiblemente a un nivel más alto que antes que la aplicación se desplegara).
- 143. Capítulo 5: Interacción con el usuario 131 Esta curva de productividad en la Figura 5 se define en tres etapas: Descubrimiento - jugando con las opciones Aprendizaje – adaptarse a la nueva aplicación y a la forma de hacer el trabajo Maestría - aumento de la productividad con el uso de la nueva aplicación La caída de la productividad en la figura 5 se puede reducir haciendo las aplicaciones más familiares para los usuarios, reduciendo así el nivel de fricción cognitiva. Una interacción con el usuario bien diseñada puede reducir la caída de la productividad que se produce normalmente cuando una nueva aplicación se ha desplegado (Figura 6). Figura 6: La reducción de la caída de la productividad con elementos familiares Podemos ver evidencias de la reducción en la caída de la productividad comparando la UX de sitios Web no relacionados. Muchos sitios Web utilizan pestañas, búsquedas y carritos de la compra – lo que hace que sea más fácil para un usuario interactuar con el sitio, incluso si nunca lo han visitado anteriormente. A continuación se muestran dos de estos sitios: Figura 7: Numerosos sitios usan elementos familiares
- 144. 132 Capítulo 5: Interacción con el usuario No es necesario leer un manual de uso de estos sitios porque los conceptos que utilizan son familiares. Como arquitectos, a menudo nos olvidamos de la familiaridad. Buscamos componentes hermosos y oscuros, y construimos interfaces que nadie ha visto antes. Tenemos que abordar este problema y encontrar la manera de hacer las cosas más familiares. La figura 8 ilustra un escenario típico - una organización que utilizaba el CRM de Seibel no estaba contenta con el cliente por defecto de Siebel. Figura 8: Una aplicación típica El cliente siguió un proyecto interno para mover todos los datos de CRM a la Web mediante una capa de servicios Web de cara a la base de datos de Siebel. Luego expusieron sus datos usando una interfaz personalizada ASP.net (Figura 9). Figura 9: Un primer intento con una UX mejor Poco después que la aplicación fue desplegada el cliente comprendió que, a pesar de ser la última tecnología (SOA, Web), nadie la estaba usando. El cliente aprendió tarde que sus operadores estaban usando un enfoque completamente diferente para trabajar con la aplicación CRM. Los comerciales, al recibir una llamada, introducían la información en Outlook en lugar de volver a introducir información en la nueva aplicación Web. El proyecto fue rediseñado para alimentar servicios Web directamente en Outlook. Esto presentó inicialmente algunos problemas técnicos interesantes. Los datos del CRM de Siebel se utilizaron para crear un conjunto de objetos dentro de Outlook. Estos objetos se parecían y actuaban como las carpetas, contactos y elementos de calendario normales de Outlook. El resultado final fue una interfaz de CRM que estaba integrada mejor con la forma en que los
- 145. Capítulo 5: Interacción con el usuario 133 comerciales realmente llevaban a cabo su trabajo. Figura 10: Refactorización de la aplicación hacia una interfaz familiar El nuevo enfoque evita la caída de la productividad que se mencionó anteriormente, porque la UX se llevó a cabo utilizando el ambiente familiar de Outlook. El tiempo de entrenamiento cambió de 1,5 días para el cliente de Siebel, a 20 minutos con la nueva UX integrada en el Outlook. La gente ya sabía cómo hacer un contacto, cómo arrastrar y soltar elementos de la agenda, de modo que no necesitaban formación, sólo necesitaban tener la aplicación. Todo lo que necesitaban eran los clientes y en eso de buscarlos eran muy buenos. Si nos remontamos a los personajes por un momento, vale la pena señalar que podemos tomar los personajes y mapearlos a las curvas de productividad. Considere el personaje de Sally. Sally ha estado usando computadoras por cinco años – ella va a experimentar un descenso promedio en la productividad con esta aplicación debido a su relativamente bajo nivel de experiencia con la computadora. El personaje de Derek representa un usuario de la computadora con mucha más experiencia. Derek es mucho más competente y tendrá una caída mucho menor en la productividad. El personaje de Jim puede experimentar una caida más profunda en la productividad en función a su habilidad con Outlook. Jim en realidad puede dejar de tratar de utilizar la nueva aplicación - es un tipo muy ocupado con poco tiempo para aprender nuevas aplicaciones. Tal vez ayudemos mejor a Jim con una mirada más cercana a su perfil y ofrecerle una interfaz diferente, más ágil (como un asistente, un portal o UX similar, que sería más provechosa para él). Recomendaciones sobre la productividad 1. A menudo las interacciones de usuario más productivas no son las más elegantes ni las de mejor aspecto. Las pantallas verdes de los mainframes no eran muy bonitas, pero los atajos de teclado utilizados por esas pantallas le permitían a los usuarios ser mucho más productivos que una elegante GUI orientada al uso del ratón. 2. Definir los personajes que tienen sentido para su aplicación y las curvas del mapa de la productividad de su personajes para ayudar a determinar las cuestiones o problemas que puede experimentar la UX. 3. Analizar las experiencias existentes para ver si hay algo que se puede extender. Si la gente ya está utilizando Outlook u Office u otra aplicación, ¿hay algo que se pueda ligar
- 146. 134 Capítulo 5: Interacción con el usuario allí para que sean más productivos, en lugar de empezar desde cero? Rendimiento El tercer y último aspecto de la capa de interfaz es el rendimiento. Resulta interesante porque muchos de los análisis de rendimiento tienden a centrarse en la ingeniería (por ejemplo, “necesitamos que este servicio y este cliente tengan una latencia de x milisegundos” o “no hay forma de que podamos sobrevivir con más de 1,2 segundos entre estas actualizaciones.”). Si bien este tipo de acuerdos a nivel de servicio (SLAs), puede ser válido para industrias como la de los servicios financieros, o la manufactura, el rendimiento tiene que ver a menudo con la tolerancia, no la latencia. La tolerancia en este sentido significa centrarse en lo que los usuarios podrán o no tolerar. Hay dos tipos de tolerancias de usuario en la mayoría de los proyectos: La tolerancia de dominio específico es cuando la gente sabe que algo debe suceder con rapidez (o más rápido) y no lo hace. La experiencia de dominio permite a los usuarios saber cómo deben trabajar las herramientas que utilizan - si no trabajan en la manera que se espera comenzarán a preguntarse por qué la aplicación es tan lenta. La tolerancia que no es de dominio específico es cuando un usuario no sabe realmente lo que está pasando. La tolerancia para dominios no específicos es mayor, causando que los usuarios con el tiempo comiencen a preguntarse cuánto tiempo la aplicación necesita para responder. Cuando se analizan el rendimiento y las aplicaciones, asegúrese de verificar los números y ver si hay niveles de servicio que se deben cumplir. También vale la pena revisar los componentes de la aplicación desde la perspectiva de la tolerancia. ¿Cuán tolerante va a ser este usuario o personaje para esta función particular? En ocasiones podemos abordar los problemas de tolerancia, en la parte frontal, mediante tecnologías como AJAX (Asynchronous JavaScript and XML). AJAX es un conjunto de técnicas Web que permiten una mayor interacción y granularidad en el navegador. Sin AJAX las páginas web son construidas directamente en el navegador – y por tanto los refrescamientos de la UX requieren costosas interacciones con el servidor. Con AJAX, la página se visualiza en el explorador, pero el comportamiento se maneja en el trasfondo. Podemos dar a la gente más información y mostrarles lo que está sucediendo de una manera mucho mejor. Es interesante señalar aquí que Microsoft lanzó el Microsoft Remote Scripting Toolkit en 1999, dando soporte efectivo con las mismas tecnologías, conceptos y enfoques arquitectónicos utilizados por AJAX hoy día. Recomendaciones sobre el rendimiento 1. Evitar verse envuelto en conversaciones acerca del tiempo de respuesta de tantos “milisegundos”. Si bien los tiempos de respuesta por debajo de los “milisegundos” pueden representar un SLA válido, las perspectivas de la UX tienen que ver más con la tolerancia del usuario, que con la latencia de las aplicaciones. Puede haber áreas de la UX que se pueden modificar para permitir una mayor tolerancia del usuario. 2. Los principios que soportan AJAX se remontan mucho antes de 2004. El acrónimo es
- 147. Capítulo 5: Interacción con el usuario 135 bastante nuevo, pero la tecnología detrás de ella no lo es. Interacción La interacción no tiene que ver con aquello con lo cual el usuario interactúa, sino con la forma en que interactúa. La capa de interacción de la plataforma de UX se centra en los siguientes tipos de preguntas: "¿Por qué esta aplicación no me ayuda a hacer mi trabajo?" “Si no fuera por esta aplicación, haría esto de manera diferente." (Obligando a la gente a trabajar de cierta forma). "Bueno, algo ha salido mal, ¿a quién llamo?" Estos tipos de problemas caen en una capa media llamada interacción. La capa de interacción se centra en tres aspectos: propósitos, preferencias y pro actividad. Veremos estos aspectos en mayor detalle a continuación: Figura 11: Los tres aspectos de la capa de interacción Propósitos La mayoría de las aplicaciones y los arquitectos se confunden por las diferencias entre las tareas y los objetivos. Necesito crear un nuevo documento, escribir el texto, formatear el texto, y enviarlo a mi editor. ¿Es esta una tarea o una meta? En realidad es ambas cosas. Cada uno de estos pasos es una tarea distinta, pero mi objetivo final es enviar algo a mi editor. Office XP proporcionaba menús dinámicos que sólo mostraban las opciones de menú más utilizadas, ocultando todas las demás. Esto era una mala UX, ya que filtraba la capacidad de hacer tareas específicas, basándose en la frecuencia en que estas tareas se realizaban. Office 2007 solucionó este problema mediante la aplicación del contexto para cada tarea. Por ejemplo, si inicia Word y empieza a escribir un texto, la cinta de interfaz de usuario muestra las opciones de texto para esa función particular (estilos de negrita, etc.). Si a continuación, inserta un diagrama, la cinta cambia automáticamente para mostrar los formatos de diagrama y las opciones de edición. Una vez que usted comience a escribir de nuevo, la cinta vuelve a la visualización de las opciones de fuentes de caracteres. Este es un buen ejemplo de cómo se puede conmutar entre los diferentes contextos de la interfaz de usuario, sin ocultarle cosas. La cinta de interfaz de usuario también puede ser personalizada o reutilizada por los ISVs (vendedores de software independientes), permitiendo que cualquiera pueda manejar los contextos y las reglas en las aplicaciones cliente.
- 148. 136 Capítulo 5: Interacción con el usuario Recomendaciones sobre los objetivos 1. No permita que los clientes confundan las tareas y las metas en las aplicaciones. 2. Céntrese en la aplicación completa - piense en el contexto de cada paso. Eche un vistazo a las licencias para interfaz de usuario de Office, y vea si las cintas se acomodan a sus aplicaciones. Preferencias Las preferencias tienen que ver con la posibilidad de que haya múltiples maneras de hacer la misma cosa, alcanzando los mismos objetivos con el conjunto adecuado de tareas. Si se ha establecido un objetivo, probablemente hay múltiples maneras de alcanzarlo. El sistema de facturación interna de Microsoft se llama MS Invoice. Cuando usted compra algo de un proveedor externo recibe una factura y un correo electrónico. Para la investigación de una factura, los usuarios deben abrir una nueva instancia de Internet Explorer y entrar en MS Market (sito de mercadeo de Microsoft). Una vez en MS Market es necesario copiar y pegar el número de factura de MS Invoice en MS Market, y entonces navegar a través de varias pantallas para encontrar el pedido original. El usuario tiene entonces que utilizar Alt + Tab para retornar a MS Invoice, navegar a través de varias pantallas adicionales, y aprobar el pago de la factura. Todo el proceso suele durar 25 minutos o más. El objetivo de un usuario en este escenario es obtener más información acerca de una factura, antes de aprobar o rechazar la misma. Las aplicaciones MS Invoice y MS Market obligan a los usuarios a trabajar de una manera específica. Si estas aplicaciones no existieran los usuarios probablemente sólo utilizarían el teléfono, Outlook, o enviarían un mensaje instantáneo a la persona que hizo el pedido original. La mensajería instantánea se está convirtiendo en un medio privilegiado de comunicación dentro de la empresa. Es posible que la mensajería instantánea sea la UX en otro contexto. Por ejemplo, el robot de Encarta es un "amigo" que se agrega a su lista de mensajería instantánea del Windows Messenger. Este robot de Encarta es una interfaz de secuencias de comandos, que interactúa con la base de datos de Encarta. Si usted le hace alguna pregunta este intentará responderle utilizando la base de datos de Encarta. Por ejemplo, si usted pregunta "¿Quién es el presidente?" el robot preguntará “¿en qué país?”. Si usted responde entonces "EE.UU.", él responderá "George Bush"9 (vea la figura 12 más abajo). Lo que la aplicación puede hacer entonces es ofrecerme más interacción, por lo que me lleva a una página Web en el mismo contexto que el cliente Web, y me muestra una foto de George Bush. 9 Téngase presente que el libro fue escrito y publicado en 2007. (Nota del traductor).
- 149. Capítulo 5: Interacción con el usuario 137 Figura 12: Interactuando con el motor de búsqueda de Encarta Podríamos utilizar una UX similar para hacerle más fácil a los usuarios la investigación y aprobación de facturas. Cuando un usuario chequea el e-mail, un robot de facturas podría notificarle que existe una nueva factura y preguntarle cómo proceder. Un ejemplo de esta UX mejorada aparece a continuación: Figura 13: Usando un motor de búsqueda especializado para una UX contextual Esto encaja completamente con el contexto, y encaja completamente con lo que estamos haciendo. Este enfoque mueve el trabajo duro de hacer las búsquedas desde el usuario hacia el trasfondo (donde corresponde). Este es un ejemplo de una UX que se ajusta a lo que estamos haciendo y lo que queremos hacer.
- 150. 138 Capítulo 5: Interacción con el usuario Figura 14: Arquitectura original de facturas de Microsoft En el sistema original había algunos servicios, un servidor Web que exponía el sitio de MS Invoice y un servidor de Exchange que envía recordatorios por correo electrónico. Si nos movemos a una solución más natural basada en mensajería instantánea, la arquitectura se vuelve mucho más simple. Figura 15: Arquitectura del motor de búsqueda contextual Recomendaciones sobre las preferencias 1.
- 151. Capítulo 5: Interacción con el usuario 139 Pro actividad El tercer y último aspecto de la interacción es la pro actividad. Todos hemos pasado por esto, liberamos una revisión de nuestra aplicación y nos sentimos muy bien al respecto. ¡La aplicación es un éxito! O al menos creemos que fue un éxito. No se oye nada de nuestros clientes, así que suponemos que no hay ningún problema. Este escenario plantea un punto interesante, porque la retroalimentación reactiva es muy común. Cuando escuchamos algo proveniente de los clientes, por lo general son malas noticias de nuestras aplicaciones (por ejemplo, "esto no funciona" o "esto no se instala"). Que no haya noticias no es necesariamente una buena noticia - en escenarios como éste debemos ser proactivos. Hay varias maneras en que usted puede ser proactivo y abrir canales de información a los usuarios. El primer enfoque es muy simple - una escala de calificación de usuario para una aplicación. Cada pantalla de la aplicación tiene una calificación de 1 a 5 (similar a cómo usted puede evaluar un libro en Amazon.com). Este enfoque permite a los usuarios proporcionar una respuesta inmediata (por ejemplo, "No me gusta mucho esta, es un 1" o "Realmente me encantó, es un 5."). Un promedio de las puntuaciones a través de varias pantallas se puede utilizar para determinar lo que se debe mejorar en la próxima versión de la aplicación. Cuando Microsoft envió Vista a un número de familias para probar el sistema operativo, incluyó una opción llamada "enviar una sonrisa." Esta opción mostraba pequeños iconos de una carita roja o verde, que aparecían en la bandeja del sistema. Cuando los usuarios encontraban algo que realmente le gustaba, hacían clic en el emoticono verde. Cuando había algo que no les gustaba, hacían clic en la carita roja. Independientemente de qué color se activara, aparecía una pantalla que se enviaba directamente a Microsoft con un texto explicativo. Este es un gran ejemplo de una UX no intrusiva para la recopilación de información, de conjunto con la pantalla de captura de la UX. Figura 16: Un enfoque proactivo a la captura de retroalimentación acoplada con el contexto Otra forma de obtener retroalimentación de manera proactiva es tener eventos y estados que se envíen automáticamente a un servidor del personal de soporte. Esto evita que los usuarios tengan que llamar al Help Desk, y cortar y pegar información del estado de los procesos en un mensaje de correo electrónico. La tercera cosa es pensar en actualizaciones efectivas del estado. ¿Qué puede hacer en su aplicación para que los usuarios sepan lo que ha salido mal? Las cosas pueden ir mal. La gente naturalmente va a aceptar eso, pero hay algo que usted puede hacer para ser mejor, tal vez les envía un e-mail, o tal vez en otra aplicación les da algún tipo de información de
- 152. 140 Capítulo 5: Interacción con el usuario estatus. Usted no tiene idea del tipo de retroalimentación positiva que se obtiene de los usuarios que dicen "Me doy cuenta de que algo anda mal, pero ahora tengo una expectativa de que esto va a mejorar, y una idea de cuándo." Recomendaciones sobre la pro actividad 1. Piense en cómo los usuarios van a proporcionar información proactiva. Piense en los tipos de canales que se pueden abrir. 2. Piense en una estrategia para cuando las cosas vayan mal. Las cosas van a ir mal. ¿Qué se necesita para evitar eso? 3. Siempre que sea posible proporcione información sobre el estado. Que la gente sepa lo que es bueno y lo que anda mal, y cuáles deben ser sus expectativas. Infraestructura El conjunto final de preocupaciones se centra en la infraestructura de la aplicación. Estos son los comentarios típicos de los usuarios asociados con la infraestructura: "Para ser honesto, yo no pude encontrar esa maldita cosa instalada." "Se bloqueó la primera vez que lo usé. No creo que vaya a intentarlo de nuevo. " "Esta cosa está fea." Este tipo de problemas cae en una capa fundacional llamada infraestructura. La infraestructura se centra en tres aspectos: plataforma, confiabilidad y personal (los desarrolladores y diseñadores). Veremos estos aspectos en mayor detalle a continuación. Figura 17: Los tres aspectos de la infraestructura. Plataforma La infraestructura comienza con la plataforma. Una vez que hayamos cubierto las otras áreas, ¿cómo debemos crear nuestra aplicación? Hay un número fenomenal de opciones hoy: Win32, Windows Forms, Flash, Java Swing, y Windows Presentation Foundation (WPF). WPF es interesante a nivel técnico, pero hay tres aspectos que vale la pena revisar: WPF añade un nuevo motor - la evolución de GDI y GDI plus. El nuevo motor se basa en 3D piping. WPF es una infraestructura para los desarrolladores y diseñadores. Integración: WPF está plenamente integrada en la plataforma.
- 153. Capítulo 5: Interacción con el usuario 141 Figura 18: La plataforma WPF WPF ofrece novedades que se pueden agregar a sus aplicaciones actuales - nimbus, halo, arrastrar y soltar, y más. WPF también habilita aplicaciones que no se habían podido construir antes. Por ejemplo, el aeropuerto de Zurich, mapeado en WPF para los controladores de tráfico, les permitió alejarse y obtener una visión de todo el aeropuerto. Esta es una UX muy rica que no podría haber sido construida fácilmente por los desarrolladores de aplicaciones antes de la llegada de la WPF (véase el caso de estudio al final de este capítulo para más información). Figura 19: Separación de estilo, diseño, y datos en WPF La separación de estilo, diseño, y datos es un concepto importante. WPF utiliza un lenguaje de marcado llamado XAML. XAML tiene una relación de dos vías con el código subyacente - el XAML se puede mantener como XML, o con código individual. XAML también se puede cargar directamente en el navegador usando XBAP (aplicación XAML del explorador). XBAP es una nueva tecnología de Windows que se utiliza para crear aplicaciones RIA.
- 154. 142 Capítulo 5: Interacción con el usuario Hay dos formas principales de implementación de una aplicación WPF: Puede crear un archivo ejecutable de cliente que se ejecuta independiente, o un XBAP que se ejecuta en el contexto de un navegador. Independientemente de las implicaciones técnicas de la selección de uno sobre el otro, hay una serie de implicaciones de diseño asociadas a cada uno, que deben ser considerados. Dependiendo de los requisitos de su aplicación, un XBAP puede ofrecer la mejor interacción con el del usuario ya que es la forma más fácil de desplegar una aplicación (aunque hay compromisos de seguridad cuando se ejecuta en un entorno basado en navegador). El despliegue, sin embargo, es sólo un aspecto de una aplicación. Pasar de una aplicación de Windows Forms a un XBAP basado en navegador plantea una serie de consideraciones de diseño. Por ejemplo, la aplicación cliente original puede haberse basado en "menús contextuales de clic derecho". Si bien esta funcionalidad es bastante simple para simular en un XBAP, la mayoría de los usuarios puede comprender que pueden hacer clic derecho en una página Web y no obtener el menú contextual estándar del navegador. Recomendaciones sobre la plataforma 1. WPF es una plataforma declarativa, basada en vectores e independiente de la resolución, para la creación de interacciones de usuario ricas (basadas en el navegador a través de XBAP o incorporada en una aplicación Windows tradicional). 2. Cuando piense acerca del despliegue, medite en los elementos y principios de diseño subyacentes y asegúrese de que se satisfacen en toda la línea. Sólo porque usted puede ofrecer una interacción diferente desde un punto de vista técnico, no significa que usted puede confiar en los mismos principios subyacentes de interacción con el usuario (por ejemplo, menús contextuales en una aplicación basada en navegador). Confiabilidad La infraestructura también incluye una serie de elementos que se refieren a las pruebas. La prueba tiene que ver con la fiabilidad y cómo hacer que una aplicación sea confiable. Este es el tipo de pregunta que muchos de nosotros recibimos todos los días. La pregunta debería ser: ¿cómo podemos hacer esta aplicación más probada? En última instancia, la fiabilidad es una prueba mala. Uno de los mayores obstáculos para la construcción de la confianza, o hacer que su aplicación esté probada, es el tiempo. No se puede desplegar la versión 1, 2 ó 3 de la aplicación y decir “vaya, esto es muy fiable” debido a que lleva días, semanas o meses construir ese nivel de prueba. Una vez que la confianza se pierde, dado que la aplicación se bloquea, se muere o no funciona como se espera, es muy difícil de recuperar. Por ejemplo, uno de nuestros arquitectos compró un nuevo ordenador portátil, con la última versión del BIOS, pero sin sistema operativo. Se buscó una versión limpia de Vista, la instalación fue satisfactoria, pero la máquina presentó una pantalla azul en el inicio de la primera sesión. En este momento el usuario perdió la confianza en esa máquina. Puede que no vuelva a suceder, pero es como descubrir que su esposa era una espía. Sigues amando a tu esposa, pero nunca estarás seguro en el futuro si ciertas cosas que ocurran están relacionadas con el espionaje, o relacionadas con tu relación con ella. Hay tres cosas que hacer cuando se piensa en hacer las aplicaciones más probadas, más
- 155. Capítulo 5: Interacción con el usuario 143 confiables a los ojos de los usuarios: instalación confiable, manejo de excepciones, y las pruebas. Así que, primero, piense en la instalación. Los usuarios odian que los desarrolladores se pasen doce meses en el proceso de desarrollo de la aplicación, y sólo dos horas en el diseño del proceso de instalación. Es como tener un teléfono móvil muy caro, y envolverlo en papel de periódico. El producto puede ser grandioso, pero si la instalación es problemática, esa la primera impresión que tenemos que superar. Es la única funcionalidad que todos los clientes siempre van a utilizar, por lo que si la instalación es mala, si deja un montón de cosas en su escritorio, o si se descomprime, luego se cierra y usted tiene que buscarla para ejecutar el programa “setup.exe” a partir de ahí, esto le deja una impresión realmente muy negativa. Mucha gente no tiene en cuenta la importancia de la instalación como parte de la interacción con el usuario en general. La instalación es la primera impresión de una pieza de software. Tiene que ser elegante, impecable, simple, y debe funcionar - y si no funciona la retroalimentación va a ser inmediata. Aquí se presenta una lista de las diez cosas que deben tenerse en cuenta al crear su propio software instalable: 1. Pre-requisitos para el software de instalación. Paquetes con una mala instalación tienen muchos pre-requisitos (algunas versiones de los controles, componentes, librerías, etc.). Esto puede ser malo - sobre todo si los usuarios se ven obligados a salir del instalador para resolver estos pre-requisitos primero! 2. La necesidad de reiniciar. A veces es necesario un reinicio de la máquina, especialmente si se va a cambiar parte del núcleo que no puede ser detenido. Ha habido muchos instaladores que exigen un reinicio "solo para estar seguros." No haga que su instalador exija un reinicio de la máquina sólo porque se trata de una simple casilla de verificación que se puede habilitar - si usted necesita que ciertos componentes se reinicien después de su instalación, encuentre la manera de hacer esto sin un reinicio completo de la máquina. 3. Animaciones y/o menús fastidiosos. Pocas personas se sentirán impresionadas por la forma visualmente interesante del menú de instalación. Hágalo simple, limpio y elegante. 4. Demasiadas opciones. Este es el error asesino para la mayoría de los instaladores – una opción tras otra opción tras otra opción. Los buenos Instaladores descubren, hacen suposiciones básicas y mantienen las preguntas en su mínima expresión. ¿A la mayoría de sus usuarios les preocupa realmente donde va a residir su aplicación? Al menos, personalice la instalación para diferentes personajes (por ejemplo, el usuario básico y el avanzado). 5. Desinstalación. Todos hemos visto archivos, llaves de registro, ficheros de inicialización, iconos, menús y otros elementos que son dejados atrás por un instalador malo. Asegúrese de que su instalación se limpia a sí misma si el usuario decide quitar el software. 6. Obtención de los permisos. Si el instalador requiere un permiso de administrador (especialmente importante en los cambios de UAC en Vista) hágaselo saber al usuario antes de empezar a instalar nada. Salir a la mitad del camino de una instalación (por ejemplo, por un “mensaje MSI -2869”) no es indicador de buena instalación.
- 156. 144 Capítulo 5: Interacción con el usuario 7. Aplicaciones que necesitan terminar. Si una instalación requiere que una aplicación esté terminada antes que la instalación pueda continuar, emita el aviso correspondiente al usuario y, en solo si es imprescindible, cierre el instalador. No salga del instalador sólo porque el usuario tiene un navegador abierto. 8. Contabilización precisa de tiempo restante. Si usted ofrece un cuadro de progreso en un instalador, por favor no lo reinicie o divida en varios pedazos desconocidos. ¿De qué sirve una barra de progreso si no ilustra de manera precisa el progreso de la instalación? 9. Desembalaje de la instalación. Si usted proporciona un paquete que tiene que descomprimir algunos archivos temporales, por favor, ejecuta automáticamente el fichero "setup.exe" después de haber completado la descompresión - no descomprimir sólo los archivos, y dejar al usuario que averigüe lo que hay que ejecutar a continuación. Asegúrese de que el instalador limpia los archivos temporales una vez finalizada la instalación. 10. ¿Usted realmente necesita un instalador? Si va a distribuir algo ligero - una extensión o complemento, ¿por qué no crear una pieza de software individual y encontrar la manera de que funcione y coexista en la máquina del usuario sin una rutina de instalación? Piense en cómo se manejan las excepciones. Mostrar una excepción Web de system.NET es bastante fácil de lograr, pero ¿qué sentido tiene dejar que el usuario lo vea?, ¿qué tan difícil es para nosotros capturar eso? Relacionado con las excepciones está el hecho de cómo se van a reintentar las cosas. Si algo sucede, ¿vale la pena simplemente volver a intentarlo otra vez? Tal vez una conexión de red se perdió. ¿Su instalador tiene que ser tan frágil que lanza excepciones a la primera señal de un error? Es probable que haya una regla del 80/20 en la que si intentamos otra cosa, probablemente podríamos solucionar el 80% de los problemas rápidamente. La tercera cuestión a pensar es las pruebas. Las pruebas de usuario tienden a ser lo mismo hoy que como fueron siempre. Conseguimos una habitación llena de usuarios durante una hora y tal vez les compramos un poco de pizza, les damos algunas pruebas - que pueden ser sofisticadas o básicas - recogemos la información de retroalimentación, y luego hacemos las modificaciones correspondientes. Grandioso, sin duda hay que hacer eso, y así las cosas serán más fiables.
- 157. Capítulo 5: Interacción con el usuario 145 Figura 20: Pruebas típicas de usuario Esta es realmente la mejor manera de hacer las pruebas. Los desarrolladores de juegos utilizan una técnica conocida como prueba de RITE: prueba y evaluación iterativa rápida10. Así es como funciona RITE: tome un usuario, póngalo a pasar una prueba, recoja los comentarios, y luego haga la modificación. Luego toma la versión modificada y se la da a un segundo usuario. Repita el procedimiento con un tercero, un cuarto, y así sucesivamente. Figura 21: Pruebas de usuario RITE Lo que se encontró con esta metodología es que se está usando la misma cantidad de usuarios, y aunque la longitud entre las pruebas es más larga debido a que necesitan realizar las modificaciones, la cantidad de errores que pueden solucionar es exponencialmente mayor. La primera persona coge toda la fruta que cuelga baja, entonces la siguiente persona la que está en un nivel superior, y así sucesivamente. 10 download.microsoft.com/download/5/c/c/5cc406a0-0f87-4b94-bf80-dbc707db4fe1/mgsut_MWTRF02.doc.doc
- 158. 146 Capítulo 5: Interacción con el usuario Recomendaciones sobre las pruebas 1. La confianza toma tiempo. No se arriesgue con la liberación de una versión con errores sólo para poner las cosas en la calle. Si las cosas van mal, esto va a causarle daños a largo plazo. 2. Incluya los procedimientos de instalar y desinstalar como parte de la aplicación. De hecho, si no se instala correctamente, no se podrá utilizar. 3. Explore la metodología RITE. Si usted está involucrado en las pruebas de usuario, esta es una manera excelente y fácil de encontrar más errores más rápido. El personal El último aspecto de la capa de infraestructura es la gente. Este tema se refiere a todos los que participan en el diseño y desarrollo de la aplicación, esencialmente en el ciclo de vida para el desarrollo de software (SDLC). Un SDLC típico se muestra en la Figura 22: Figura 22: SDLC típico Un proyecto sigue el modelo ilustrado en la Figura 22. Hay dos problemas fundamentales en este ejemplo: uno es que TI es propietaria de la mayoría del proyecto. Si bien las TI deben estar involucradas, los interesados/propietarios no quedan claros. El otro problema es que tan tarde en el programa se crea la interfaz de usuario. El diseño y desarrollo de la interfaz de usuario está simplemente atornillado al final del cronograma del proyecto. Muchas organizaciones sacan fuera rápidamente la primera versión de su interfaz de usuario, obtienen comentarios de los usuarios, y deciden que lo que tienen que arreglar. Se trae un diseñador, pero ya es demasiado tarde para agregar valor a la UX (como se dijo anteriormente). Las manos del diseñador están realmente atadas por el estado de la aplicación. Necesitamos una nueva metodología, más exitosa, que reconozca la UX como un ciudadano de primera clase en el SDLC. Un escenario de UX más exitoso aparece en la Figura 23 a continuación:
- 159. Capítulo 5: Interacción con el usuario 147 Figura 23: Un escenario UX mejorado En la Figura 23, el proyecto se inicia con el desarrollo de los casos de uso, los escenarios y los personajes. En la fase de prototipo, dividimos el proyecto en dos partes - un prototipo de TI para los servicios Web, y un prototipo de usuario por separado. El prototipo de usuario puede utilizar técnicas como la creación de maquetas de papel, y la realización de entrevistas con los usuarios finales para asegurarse que la UX satisface sus necesidades. Las TI se centran en el desarrollo de los servicios y el lado de la infraestructura, mientras que el diseñador trabaja con los usuarios, los analistas de negocio y de TI, para el diseño de la UX. En una metodología ágil habría puntos en los que se combinan estas iniciativas para la revisión y la realización de pruebas con usuarios. Eventualmente, el proyecto se une al final para su terminación. ¿Son todos los diseñadores iguales? Los diseñadores pueden tener habilidades diferentes, ¿pero son sus funciones diferentes? Cuando se trata de diseño, hay dos personajes diferentes. Un diseñador gráfico aparece para elegir el tono correcto de azul o la imagen de la interfaz. Un diseñador de interacción es el desarrollador que piensa acerca de cómo el usuario interactúa con la aplicación. La herramienta Microsoft Expression Blend puede ser utilizada por los diseñadores para delinear los distintos componentes de la UX. El verdadero desafío es compartir los criterios de diseño con los desarrolladores. Figure 24: Interacción entre diseñadores y desarrolladores
- 160. 148 Capítulo 5: Interacción con el usuario Este producto de Microsoft almacena los diseños en XAML de modo que se pueden compartir con los desarrolladores de la UX en Visual Studio, asegurando que no haya pérdida de fidelidad entre el diseño y la implementación. Desde la perspectiva de un arquitecto tenemos que pensar en las siguientes consideraciones de diseño desde el principio: Los eventos y funciones en Blend van a requerir una comprensión a nivel de código. Un diseñador podría ser capaz de utilizar Blend para marcar una página, pero ¿qué pasa si el diseño tiene que ser más interactivo? ¿Se espera que los diseñadores sepan escribir código C # o VB? Van a existir debates entre desarrolladores y diseñadores acerca de quién es el dueño de los artefactos XAML. Si ambas partes tienen que trabajar con la misma pieza de XAML ¿quién se impone sobre quien cuando hay que hacer un cambio? Este tipo de interacción en el diseño dará lugar a segmentos de interfaz para la comunicación. ¿Surgirán patrones o guías para ayudar a los desarrolladores y diseñadores a comunicarse mejor? Recomendaciones sobre el personal 1. Eche un vistazo a SDLC y a proyectos de clientes. Normalmente, un buen SDLC posibilita realmente una buena UX. 2. Determine qué tipos de los diseñadores va a requerir y soportar el modelo SDLC. 3. Apoye las interacciones entre los desarrolladores y diseñadores.
- 161. Capítulo 5: Interacción con el usuario 149 Resumen En este capítulo se presentó una infraestructura de UX para los arquitectos. Los tres puntos principales a recordar son: 1. Si usted es un arquitecto experimentado, use la infraestructura para mejorar la posición de la UX con respecto a los clientes con que está involucrado. 2. Si usted es un aspirante a arquitecto, use la infraestructura para poner la UX en un contexto más amplio. A medida que piense en la arquitectura de su solución, piense también en el impacto que tendrá la UX sobre sus usuarios. 3. Use la infraestructura para promover la UX, como un ciudadano de primera clase en el dominio de la arquitectura de software. El capítulo 6 ofrece una mirada detallada a la capacidad arquitectónica de Identidad y Acceso.
- 162. 150 Capítulo 5: Interacción con el usuario Estudio de caso SOA: Aeropuerto de Zúrich En un solo día, más de 60.000 viajeros pasan por el aeropuerto de Zurich. Cada año, aproximadamente 20 millones de turistas, diplomáticos y residentes viajan a través de este ocupado nudo de comunicaciones de Suiza. Se necesita una infraestructura de 24.000 empleados y 180 empresas para dar soporte al aeropuerto de Zurich. La supervisión de todo la lleva a cabo Unique, una empresa privada contratada por la Federación Suiza para gestionar todo el complejo. Para garantizar un buen funcionamiento general del aeropuerto, Unique, de conjunto con Microsoft, construyó un sistema de monitoreo integrado. El objetivo era ofrecer un panorama visual de alto nivel de todo lo que sucede en el aeropuerto en todo momento. Se utilizó WPF para desarrollar un mapa completamente interactivo capaz de proporcionar vistas de la información operacional clave en tiempo real, incluidas las previsiones de pasajeros, la ubicación de los aviones, los datos de los vuelos, las condiciones ambientales, las cargas de equipaje, los resúmenes de gestión, y otros reportes en vivo . El soporte nativo para animación avanzada de WPF permitió a los desarrolladores poder escribir unas pocas líneas de código para ilustrar los movimientos de las aeronaves en las pistas del aeropuerto. Los usuarios pueden ampliar el plano, desplazar el puntero del ratón sobre él, y ver globos emergentes con información sobre el vuelo indicado. Las áreas en rojo representan el movimiento de aviones y pasajeros en el aeropuerto de Zúrich El estudio de caso completo se encuentra disponible en: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=200365. Otros estudios de caso SOA pueden consultarse en: http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA.
- 163. 151 Capítulo 6: Identidad y acceso “Tu identidad es tu bien más preciado – protégelo. Si algo sale mal, usa tus poderes." - La Niña Elástica, De la película “Los increíbles” Guía para el lector Los lectores de este capítulo continuarán desarrollando los conceptos introducidos en los capítulos previos, centrándose concretamente en la capacidad arquitectónica de Identidad y Acceso. Figura 1: Capacidades arquitectónicas recurrentes En este capítulo los lectores aprenderán acerca de la estrategia de Microsoft para la identidad y el acceso. Vamos a discutir las leyes de la identidad - un conjunto de lineamientos aprendidos en el uso de sistemas de identidad reales que operan en el mundo. También se describirá un metasistema de identidad que puede conducir a que la informática en Internet sea más segura y confiable. Los temas tratados en este capítulo incluyen: Términos y conceptos asociados con la identidad y el acceso. Las leyes de la identidad. Escenarios de la identidad federada. Subsistemas de confianza. Un metasistema de identidad.
- 164. 152 Capítulo 6: Identidad y acceso Identidad y Acceso Generalidades La identidad y el acceso se centran en la gestión de las identidades con soporte para los siguientes aspectos: Gestión de múltiples roles (identidades): Un empleado puede servir en diferentes roles dentro de una organización - cada uno de estos roles debe ser cumplido adecuadamente de acuerdo al contexto, el proceso y otros factores. Propagación de las identidades: La propagación de las diversas identidades utilizadas por los procesos de negocio tanto simples y complejos puede ser un desafío. Las identidades deben pasar entre cada servicio involucrado en el proceso de negocio de una manera sencilla. A las identidades utilizadas por un determinado proceso también se les debe conceder los derechos de acceso adecuados a los recursos necesarios para que el proceso se complete correctamente. Integración a través de las fronteras: Los procesos de negocio pueden abarcar departamentos, empresas y países. Colaboración entre departamentos dispares y entre empresas, independientemente de la ubicación de los recursos y los empleados. Aplicación y gestión de las reglas de negocio a las identidades: Junto a la creación y la gestión de las identidades, se necesitan normas que definan cómo estas identidades deben ser manejadas (por ejemplo, limitaciones en el almacenamiento en caché o en el tiempo, y otras cuestiones). Delegación de funciones de gestión a las unidades de negocio: Las identidades transmiten mucha más información que un simple par nombre de usuario/contraseña. La responsabilidad con el contenido de la identidad, las reglas y la gestión se está convirtiendo en una función de negocio en lugar de una función administrativa para TI. Las unidades de negocio deben ser capaces de gestionar y mantener sus identidades en forma autónoma. La mayoría de las grandes organizaciones tienen múltiples sistemas de seguridad desplegados. Los proyectos de SOA necesitan aprovechar las inversiones existentes en TI en la organización, es decir, la nueva solución tendrá que interactuar con una amplia gama de sistemas de seguridad. Sin una estrategia global de integración de seguridad concebida, la organización tendrá que determinar los requerimientos de seguridad, identidad y acceso, caso por caso. Esto conduce a mayores tiempos de desarrollo e implementación, así como a cuestiones de seguridad específicas para la aplicación. Si las aplicaciones no tienen en cuenta estos problemas entonces la carga para interactuar con diferentes sistemas de seguridad recae en el usuario, resultando en una interacción muy compleja con el usuario, una menor productividad y un mayor riesgo. La integración de la seguridad está relacionada con los siguientes cinco aspectos: ¿Quiénes son los usuarios? ¿Cómo lo demuestran? ¿Qué pueden acceder? ¿Qué nivel de privacidad se requiere? ¿Cómo y cuándo son concedidos, extendidos o revocados los privilegios de acceso?
- 165. Capítulo 6: Identidad y acceso 153 La solución a estos problemas es adoptar una infraestructura que oculte de manera efectiva los detalles de seguridad de las nuevas soluciones. Una vez que esta infraestructura se ha establecido las aplicaciones legadas de la organización deben adaptarse a hacer uso de ella. Deberán ser adoptadas políticas para las nuevas aplicaciones para garantizar que las nuevas soluciones también usen la infraestructura de integración de seguridad. Hay varios beneficios adicionales que la organización puede derivar de una infraestructura de integración de seguridad estandarizada: Los trabajadores ya no estarán obligadas a manejar varios juegos de usuario/contraseña, evitando la pérdida de productividad y posibles vulnerabilidades de seguridad. Los nuevos empleados no tienen que esperar mucho tiempo para que sus cuentas sean creadas. La seguridad corporativa y las políticas de privacidad se aplican de manera consistente y eficaz. Como se dijo anteriormente, la integración de la seguridad y la gestión de la identidad son temas críticos que deben ser abordados por una solución SOA. Las organizaciones que adoptan una integración de seguridad coherente y una estrategia de gestión de identidad son: Más eficientes: Las organizaciones pueden conectarse y colaborar mejor con sus clientes, socios y proveedores. Más productivas: Los usuarios pueden ser más productivos ya que las demoras en acceder a los sistemas o recursos se reducen al mínimo. La gestión de identidades de usuarios es también más productiva derivado de que la provisión de acceso a los sistemas necesarios se reducen (por ejemplo, como se mencionó, las múltiples solicitudes de contraseña son manejadas por las mismas aplicaciones). Más eficientes desde el punto de vista de los costos operacionales: Una integración consistente de la seguridad y una estrategia de gestión de la identidad permiten que las tareas comunes, como el restablecimiento de las contraseñas para ser opciones de auto servicio controladas por el usuario, reduce, en general, el volumen de llamadas al equipo de soporte. Más seguras: La integración coherente de la seguridad y las estrategias de gestión de la identidad permiten implementar políticas corporativas y gubernamentales que pueden aplicarse a nivel de la empresa en lugar de hacerlo departamento por departamento. Ahora que tenemos algún conocimiento de los beneficios que una organización puede derivar de una estrategia de gestión de identidad consistente, vamos a echar un vistazo a algunos de los principios de la gestión de identidad en un gran sistema distribuido. Cada vez más las organizaciones están implementando o utilizando soluciones que usan Internet. Algunas de estas soluciones utilizan Internet para comunicarse con sus socios comerciales, mientras que las soluciones basadas en SaaS pueden ser distribuidas a través de Internet.
- 166. 154 Capítulo 6: Identidad y acceso Diseño del subsistema de confianza Si bien la descomposición de las aplicaciones en múltiples capas facilita ciertas actividades de diseño y despliegue, también introduce retos en el desarrollo de las diferentes facetas de las soluciones. De estas cuestiones de diseño, las recurrentes tienen que ver con el control y la contabilidad del acceso a los datos empresariales y los recursos informáticos expuestos por cada nivel de aplicación. Figura 2: Control de acceso y requerimientos de auditoria para aplicaciones multicapas En la Figura 2 vemos un típico sistema distribuido Los sistemas como este plantean típicamente los siguientes tipos de preocupaciones: 1. ¿Quién puede invocar las interfaces del servicio Web 2? 2. ¿Quién puede conectarse a la base de datos del negocio? 3. ¿Cómo deben filtrarse los datos del negocio con respeto a la privacidad y los requerimientos de las políticas regulatorias del negocio? 4. ¿Cómo se audita y mantiene un registro del acceso a los datos? Vamos a utilizar el escenario que se ilustra en la Figura 2 para explicar estas consideraciones de diseño. La figura 2 muestra una aplicación genérica de varias capas que es una buena representación de la generación actual de aplicaciones de líneas de negocio (LOB). En este escenario, una aplicación inicia una solicitud a través de un método en el servicio Web 1. El servicio Web 1 es un servicio de fachada que, a su vez, llama a otro método del servicio Web 2 para procesar la solicitud del usuario. El método del servicio Web 2 implementa la lógica de negocio interna. Parte del procesamiento de la lógica de negocio requiere de datos que se deben obtener de una base de datos de apoyo. Antes de responder a la llamada del servicio Web 1, la implementación de la lógica de negocio también registra el evento en un registro de auditoría por razones de contabilización. En este escenario pueden presentarse entonces los requerimientos de control de acceso y contabilización siguientes: ¿Cómo debemos controlar el acceso a los recursos informáticos que brindan los servicios que implementan la lógica de negocio (como el servicio Web 2) y a la base de datos que proporciona los servicios de gestión de datos? El servicio Web 2 implementa una importante lógica de negocio que es fundamental para la aplicación de políticas y procesos de negocio. Las empresas pueden restringir la capacidad de ejecutar código de misión crítica, a un subconjunto de las identidades. Del mismo modo, en la base de datos es donde residen las
- 167. Capítulo 6: Identidad y acceso 155 joyas de la corona de la empresa. Los derechos para conectarse a la base de datos deben ser manejados juiciosamente. ¿A quién se debe permitir el acceso a los datos? Los requisitos de privacidad de los datos o las políticas de negocio pueden limitar la información de negocio que puede ser vista y manipulada por el usuario de las aplicaciones. Por ejemplo, las agencias de seguros pueden restringir la visualización de los datos del cliente al agente de seguros asignado. En este caso, la lógica de negocio tendrá que tomar decisiones de autorización basadas en la identidad del usuario de la aplicación (por ejemplo, el agente de seguros) y los datos del cliente recuperados de la base de datos. Este reforzamiento se conoce algunas veces como titularidad de los datos. ¿Quién ya ha accedido a los datos? Los requerimientos reglamentarios pueden imponer a las empresas que mantengan un registro de auditoría de todas las actividades relacionadas con los datos, específicamente quién accede qué información y cuándo. En nuestro escenario, el servicio Web tendrá que conocer la identidad de los usuarios de las aplicaciones para mantener registros precisos. Prácticas actuales En la actualidad, hay dos modelos prevalecientes para satisfacer las necesidades descritas anteriormente: Suplantación y delegación. Subsistema de confianza. Vamos a describir los dos modelos conceptualmente y explicar cómo las implementaciones actuales de los modelos se utilizan para resolver los problemas de control de acceso y de auditoría mencionados anteriormente. Entonces se detallarán algunas limitaciones con los enfoques actuales para luego aplicar un conjunto de principios de diseño del subsistema de confianza para obtener una solución alternativa. Suplantación y delegación La delegación es el proceso de permitir a un tercero a actuar en nombre de una identidad. Este proceso confiere a una de las partes los derechos y privilegios de la otra parte para llevar a cabo un conjunto de tareas. La suplantación de identidad puede verse como la forma más relajada de delegación de tal manera que a una identidad se le asigna el conjunto completo de permisos de la identidad suplantada. Hay dos formas comunes de aplicación de la delegación: 1. Una identidad crea una declaración firmada con un conjunto de permisos que le asigna a la parte declarada por una duración específica de tiempo, de modo que la parte declarada puede presentar la declaración firmada y actuar en nombre de la identidad. 2. Un tercero de confianza emite declaraciones firmadas para establecer que las partes permiten a las otras partes declaradas actuar en nombre de otra identidad por una cierta cantidad de tiempo.
- 168. 156 Capítulo 6: Identidad y acceso El primer modelo es más fácil de implementar cuando el sujeto que delega los derechos, está consciente de las partes que están realizando tareas en su nombre. Sin embargo, en el entorno actual de computación distribuida de varios niveles, esto no es lo más común. Las más de las veces, un usuario final no tiene conocimiento de los servicios que están interactuando para responder a las peticiones del usuario. En estos casos se utiliza una forma más adecuada de delegación, un tercero autoriza las solicitudes que se hacen en nombre de otros. El protocolo de seguridad Kerberos es una implementación popular de un esquema de este tipo. El modelo de delegación de Kerberos no supone que el usuario final conoce de antemano acerca de todos los servicios que están en cooperación. Con Kerberos, el Centro de Distribución de Kerberos (KDC) emite tickets “transferibles” que permiten a los servicios actuar en representación de cada usuario. Utilizando la suplantación de Windows y el enfoque de delegación Kerberos, un servicio que quiera propagar la identidad del que llama debe en primer lugar hacer una solicitud al sistema operativo Windows para suplantar al usuario a nivel local. Nótese que la suplantación se considera una función muy restringida y la identidad del proceso de aplicación debe poseer el privilegio Trusted Computing Base (TCB) para suplantar a un usuario. Este derecho sólo puede ser asignado por el administrador del sistema en la máquina local. Cuando el proceso de aplicación suplanta a un usuario, todo lo que haga a nivel local será autorizado y auditado con la identidad del usuario suplantado. Esto significa que un proceso de aplicación también puede adquirir privilegios del usuario que no tendría normalmente cuando no está suplantando a un usuario. La delegación Kerberos permite que un proceso de aplicación adquiera un ticket de servicio de Kerberos en nombre del usuario suplantado y la identidad del usuario suplantado se transfiere en el ticket de servicio adquirido. El proceso de aplicación puede entonces invocar el servicio remoto mediante el ticket de servicio adquirido de Kerberos. El flujo de servicios que se invocan procesará la solicitud de acuerdo con la identidad que está en el ticket de servicio de Kerberos. Así, a través del proceso de delegación, la identidad del usuario (original) se propaga a los servicios siguientes. En el escenario anterior, usando la suplantación de Windows y la delegación Kerberos, es posible hacer fluir la identidad del usuario original, de modo que la lógica de negocio del servicio Web pueda realizar la autorización de forma más detallada, como la titularidad a nivel de los datos, así como registrar la identidad del usuario suplantada en la bitácora de auditoría. Además de permitir a las aplicaciones de múltiples capas tomar decisiones de autorización, el uso de la suplantación de Windows y la delegación Kerberos también mejora la seguridad del entorno de aplicaciones a través de las siguientes características: Con la delegación restringida de Kerberos, los administradores pueden configurar las políticas de delegación para que los servicios puedan ser restringidos a actuar en nombre de usuarios solo para un conjunto dado de servicios. El protocolo Kerberos permite la autenticación mutua, lo que significa que los servicios pueden autenticarse unos con otros, reduciendo así los riesgos de interacción con servicios maliciosos. La suplantación y la delegación de Kerberos son capacidades disponibles que están integradas en el sistema operativo Windows. Esto significa que las empresas que tienen
- 169. Capítulo 6: Identidad y acceso 157 una infraestructura de servicios de directorio activo pueden reutilizar la misma infraestructura de seguridad para habilitar la seguridad de las aplicaciones. A pesar de estas ventajas, también hay limitaciones en el uso del modelo de suplantación y delegación: Los usuarios suplantados a nivel de procesos del sistema operativo pueden elevar los privilegios del proceso, lo que puede tener consecuencias no deseadas como resultado de ataques de seguridad de elevación de privilegios. La delegación de Kerberos requiere que el proceso de aplicación contacte con el KDC para obtener un ticket de servicio en nombre del usuario antes de acceder e invocar un flujo de servicios. Para las aplicaciones que tienen acceso a recursos en nombre de un gran número de usuarios, esta negociación de seguridad con el KDC introduce una latencia de comunicación adicional que puede no ser aceptable. La solución obvia de usar una caché para estos contextos de seguridad entre las distintas peticiones, viola las recomendaciones de los servicios de alto rendimiento. Algunas aplicaciones optimizan su rendimiento compartiendo un pool 11 de canales de comunicación pre-creados para la conexión y comunicación con el flujo de servicios. Por ejemplo, muchos servicios de la capa de lógica de negocio tienen un pool de conexiones de base de datos que los servicios reutilizan para comunicarse con la base de datos. Para cumplir con los requisitos de seguridad, cada una de estas conexiones de base de datos requiere autenticación. Cuando se utiliza suplantación/delegación para propagar el contexto de seguridad del que llamó originalmente, se crea una conexión de base de datos autenticada para cada usuario suplantado y la técnica del pool de conexiones no se puede utilizar para optimizar el rendimiento de las aplicaciones. El acceso a servicios tales como los servicios Web de la lógica de negocio debe ser garantizado mediante la identidad del usuario suplantado. En otras palabras, es necesario conceder permisos a los usuarios finales para llamar a código de misión crítica. En muchos casos, esto no es una hipótesis aceptable, desde las siguientes perspectivas: Viola el punto de vista particular de la defensa en profundidad que reduce gradualmente el número de identidades que pueden tener acceso a activos de mayor valor. La analogía de la fortaleza es bastante apropiada aquí. Capas de paredes defensivas protegen el núcleo central de mando y control. Cada vez menos funcionarios de confianza de los rangos más altos se les permite el acceso a medida que avanzamos hacia el núcleo interior de la fortaleza. Cumplir con este principio significa que la capacidad de invocar la lógica de negocio interno debe limitarse a un pequeño conjunto de identidades de la aplicación. Cuando los usuarios finales también pueden invocar estos servicios, la seguridad de estos servicios también depende de (y está a merced de) la eficiencia del usuario final en el proceso de aprovisionamiento. Dando a los usuarios finales la posibilidad de invocar servicios de lógica de negocio también aumenta la complejidad de la gestión de control del acceso para el servicio. En lugar de sólo tener que gestionar los derechos de acceso de algunas identidades de una 11 En diversas áreas de la informática se utiliza “pool” para hacer referencia a recursos compartidos. Por ejemplo, en el caso de las Bases de Datos se emplea para una colección de conexiones abiertas de manera que puedan ser reutilizadas al realizar múltiples consultas o actualizaciones.
- 170. 158 Capítulo 6: Identidad y acceso aplicación, ahora se tiene que lidiar con las identidades de los usuarios finales. Subsistema de confianza Las limitaciones del modelo de suplantación y delegación proporcionan la motivación para considerar el modelo de subsistema de confianza. Por definición, el modelo de subsistema de confianza implica que los servicios de aplicación son de confianza para llevar a cabo un conjunto específico de tareas de la aplicación, tales como el procesamiento de pedidos de los clientes. Con frecuencia, los flujos de servicios necesitan tomar decisiones de autorización de aplicaciones, como la aprobación del envío de un pedido antes de realizar la transacción comercial. Para ello, el servicio debe conocer la identidad del usuario final que envía el pedido. Si bien la capacidad de hacer fluir la identidad del usuario final es una propiedad inherente del modelo de delegación, no es así para el modelo de subsistema de confianza y debe hacerse un esfuerzo especial para incluir esta característica. La noción de “confianza” no viene de forma gratuita. Para apoyar la noción de confianza como lo define el modelo de los Servicios debe al menos ser capaz de: Autenticar y verificar la identidad del servicio anterior o posterior con que se está comunicando dentro del flujo. Decidir si el servicio identificado es un subsistema de confianza para un conjunto específico de funciones de la aplicación, incluyendo la propagación de los reclamos de identidad. Proteger la integridad de los datos que se comunican entre el subsistema de confianza y el flujo de servicios. Además de los datos de aplicación, los datos de tráfico, tales como los reclamos de identidad del usuario original, también deben ser protegidos para que nadie en el medio pueda modificar la información de identidad que está en tránsito. Sin embargo, muchas implementaciones actuales de presuntos “subsistemas de confianza”, no cumplen con estos requisitos mínimos de seguridad. Vamos a sustentar esta afirmación con algunas observaciones sobre la forma en que algunos subsistemas de confianza actuales están propagando el contexto del usuario original. Una práctica común en la actualidad es propagar la identidad del que llama como un encabezamiento HTTP o SOAP personalizado. El flujo de servicios busca en el encabezamiento HTTP o SOAP personalizado cuando necesita la identidad de la llamada original. Dado que la propagación de la identidad ocurre frecuentemente dentro de la organización, muchos administradores de aplicaciones ingenuamente asumen que es seguro propagar los datos sin protección. En realidad, muchas, si no la mayoría, de las violaciones de seguridad de aplicaciones se producen dentro de las redes internas de la organización. La adición de protección a nivel de la capa de transporte, como el uso de SSL/TLS con autenticación del cliente y del servidor, puede reducir la superficie de ataques de seguridad de forma significativa. En los entornos de servicios Web donde los extremos de los servicios Web pueden abarcar múltiples saltos de transporte, añadiendo seguridad en la capa de servicios Web puede reducir las posibilidades de ataques intermedios. Esto se logra exigiendo que los servicios se autentiquen mutuamente la integridad, y protegiendo el encabezado SOAP personalizado.
- 171. Capítulo 6: Identidad y acceso 159 También podemos apoyarnos en una infraestructura de clave pública (PKI) del estándar X509 para ayudar al flujo de servicios a decidir si un servicio entrante es un subsistema de confianza. Por ejemplo, se puede definir un OID de certificado personalizado de uso para un subsistema de confianza de manera que se emitan los certificados que contengan el OID de uso del subsistema de confianza. El certificado expedido también puede contener el cliente y el servidor de autenticación OID, de modo que el mismo certificado también pueda usarse para la autenticación HTTPS o de servicios Web con el perfil de símbolo del certificado X509. Hasta este punto, las soluciones propuestas son las frutas de las ramas más bajas que los subsistemas de confianza existentes pueden incorporar para añadir protección de seguridad adicional. Metas de diseño del subsistema de confianza En la siguiente sección, se describe el diseño de una infraestructura que nos permite cumplir con los requerimientos del subsistema de confianza que se han establecido anteriormente. Además, este diseño de subsistemas de confianza también satisface un conjunto adicional de atributos de seguridad para el flujo de reclamos de identidad. Los objetivos de diseño para este subsistema se resumen a continuación. 1. Habilitar al flujo de servicios para autorizar invocaciones de servicios basadas en las identidades de las aplicaciones en lugar de las identidades del usuario final. Este requisito ayuda a simplificar la gestión de accesos de la interfaz de servicios. 2. Habilitar un servicio del flujo para identificar positivamente una llamada entrante y determinar si el que llama es también un subsistema de confianza para las funciones específicas de la aplicación. El diseño no debe asumir que todos los servicios de aplicación son subsistemas de confianza. Por el contrario, debe utilizar los mecanismos de la política de seguridad para especificar y determinar el tipo de funciones de aplicación que un servicio puede realizar. 3. Habilitar un servicio de entrada para proteger su comunicación con los servicios de salida de modo que los datos puedan ser protegidos contra la manipulación y otros ataques. 4. Habilitar un servicio de entrada para propagar la identidad del invocador original a los servicios de salida. El contexto de identidad del invocador original se utiliza frecuentemente por los servicios de aplicación para autorizar tareas de negocio y auditar las acciones de un individuo. El diseño debe poner estos datos de identidad a disposición de la aplicación. 5. A diferencia del modelo de suplantación y delegación, el diseño no debe operar bajo la premisa de “actuación en representación” del usuario original, cambiando por tanto la identidad del proceso o hilo de aplicación. La solución debe permitir a los subsistemas de confianza funcionar de la misma forma que los representantes de las líneas aéreas que ejecutan el procedimiento de check-in a los viajeros identificados en los mostradores correspondientes. Los representantes de los servicios no utilizan la suplantación o la actuación en nombre de los viajeros. Por el contrario, son las personas que están autorizadas para llevar a cabo los procedimientos de check-in a los viajeros en los mostradores de check-in. El diseño de subsistemas de confianza, no requiere que una aplicación asuma otra identidad para realizar su función. 6. En ciertos casos, un servicio de salida, recibiendo una identidad propagada de un subsistema de confianza también puede necesitar pruebas adicionales para aceptar la
- 172. 160 Capítulo 6: Identidad y acceso identidad y proceder con la solicitud de la aplicación. El requerimiento del proceso aquí es similar al proceso de solicitud de tarjeta verde en EE.UU12. En muchas empresas, los abogados corporativos ayudan a iniciar la preparación de la solicitud de tarjeta verde para los empleados extranjeros. Después que el proceso de preparación inicial se ha completado, el documento de solicitud elaborado por el departamento legal se envía a la oficina federal de inmigración, junto con otros documentos oficiales, tales como el pasaporte del solicitante. El pasaporte es la pieza adicional de información que la oficina de inmigración federal va a utilizar para comprobar la identidad del solicitante. De la misma manera, los servicios de salida podrán exigir pruebas adicionales de un tercero que no sea el subsistema de confianza o el usuario para dar soporte a los reclamos de identidad recibidos de los subsistemas de confianza. Para este requerimiento, nuestro diseño tiene en cuenta las siguientes evidencias específicas que pueden ser necesarias: Debe ser posible para un servicio de salida verificar que el propietario del reclamo de identidad propagado ha sido autenticado recientemente por un tercero de confianza. Esto reduce la ventana de tiempo disponible para que un servicio de confianza comprometido pueda propagar falsos reclamos de identidad. Para reducir aún más las posibilidades de propagaciones de identidad falsa, el servicio debe ser capaz de verificar con hechos tangibles (por ejemplo, la firma del invocador original) que una llamada específica se originó a partir de la identidad previamente identificada y a través del conjunto de reclamos propagado. Este requerimiento se basa en el anterior. 7. Desacoplar las credenciales que se utilizan para la autenticación de las que se utilizan para hacer los reclamos al subsistema de confianza. Este requerimiento facilita la gestión de las políticas de seguridad. Por ejemplo, las credenciales de autenticación, como los certificados X509, por lo general tienen una vida útil más larga, mientras que el reclamo de un servicio con respecto a ser un subsistema de confianza, puede tener una vida útil más corta, lo que depende de la ubicación del servicio en el entorno de aplicación. Diseño del subsistema de confianza Hay dos requisitos importantes que se deben cumplir en el proceso de identificación de un subsistema de confianza: 1. Los servicios que interactúan entre sí deben saber que se están comunicando con la parte que pretenden. 2. En situaciones en que no todos los servicios de aplicación se consideran como subsistemas de confianza, debe haber una manera que permita que un servicio diferencie los servicios que son de confianza de los que no lo son, para propagar las identidades. En la sección anterior, ya hemos descrito algunas formas en que los servicios pueden autenticarse mutuamente. Es ciertamente posible aprovechar las tecnologías existentes para llevar a cabo la autenticación mutua, como el uso de HTTPS con certificados X509 en el cliente y el servidor, o el protocolo Kerberos. 12 La Tarjeta de Residencia Permanente en Estados Unidos, conocida popularmente como Green Card, es un documento de identidad para residentes permanentes en los Estados Unidos que no posean la nacionalidad estadounidense.
- 173. Capítulo 6: Identidad y acceso 161 Además de estas soluciones, también es posible el uso de tecnologías emergentes basadas en servicios Web, como un servicio de token de seguridad que proporciona la autenticación negociada de terceros a un grupo de aplicaciones basadas en servicios Web. Más allá de los servicios de autenticación y SSO que son prestados por dichos servicios de autenticación negociada, se muestra aquí cómo es posible ampliar la infraestructura para que los servicios también se puedan montar en el mecanismo de autenticación para autorizar servicios como subsistemas de confianza. Figura 3: Diseño de un subsistema de confianza La Figura 3 muestra el diseño de un subsistema de confianza que se basa en un servicio de token de seguridad y proporciona la autenticación y el servicio de SSO. Los protocolos de seguridad subyacentes que respaldan este tipo de infraestructura pueden componerse usando especificaciones de seguridad de servicios Web existentes tales como WS-Security, WS-Trust y WS-SecureConversation. Este diseño muestra un escenario de aplicación de varias capas en el que dos usuarios, Alice y Bob, están utilizando dos instancias de aplicaciones de servicios Web para acceder a un servicio Web de fachada. El servicio Web de fachada se comunica con un servicio Web de salida para completar la petición de la aplicación. La sección siguiente proporciona información general que describe cómo se puede esperar que funcione una típica infraestructura de SSO para servicios Web. La información tiene como objetivo proporcionar la infraestructura básica que se extenderá para implementar el diseño de subsistemas de confianza.
- 174. 162 Capítulo 6: Identidad y acceso Infraestructura básica de SSO para servicios Web En referencia al escenario que se muestra en la Figura 3, Alice y Bob se autentican con el servicio de tokens de seguridad para adquirir un token de sesión de la STS, como una prueba de autenticación. Posteriormente, Alice y Bob pueden utilizar sus respectivos token de sesión con la STS para solicitar el token de acceso al servicio Web de fachada sin tener que volver a autenticarse con sus credenciales primarias (por ejemplo, contraseñas o certificados). El token de acceso a servicio se utiliza para negociar las claves de sesión y demostrar conocimiento de los secretos para establecer la autenticación mutua. La misma infraestructura de SSO utilizada por Alice y Bob para autenticar y lograr SSO con el servicio Web de fachada se utiliza también por los servicios Web para autenticarse mutuamente. Por ejemplo, antes de que el servicio Web de fachada pueda comunicarse con el servicio Web de salida, se requiere la autenticación con la STS para adquirir un token de sesión STS y un token de acceso al servicio Web de salida. Ambos servicios Web luego se autentican mutuamente y establecen una sesión segura entre sí. El protocolo de enlace (handshaking) 13 de sesión segura se puede configurar aprovechando los bloques de construcción de los protocolos de los servicios Web, tales como el protocolo WS-SecureConversation. Este proceso de negociación de sesión segura sólo se tiene que hacer una vez durante la vida útil del token de acceso al servicio. Cuando el token de acceso al servicio ya no es válido, puede ser renovado y la sesión segura debe ser renegociada. Tal infraestructura resulta muy útil para las grandes categorías de aplicaciones distribuidas y servicios que se implementan en las empresas de hoy día. Las sesiones de seguridad con autenticación mutua mejoran la seguridad al mismo tiempo que reducen al mínimo el gasto de recursos, dado que la negociación inicial de seguridad puede ser amortizada en las múltiples solicitudes de aplicaciones y las respuestas tramitadas a través de los servicios Web. También es importante tener en cuenta que el concepto de sesiones de seguridad es ortogonal a la aplicación del paradigma de la comunicación. A primera vista, puede parecer que esta infraestructura de SSO sólo es útil para las aplicaciones distribuidas que se comunican de forma sincrónica. Esto no es cierto. La misma infraestructura también se puede utilizar para aplicaciones distribuidas seguras que sirven transacciones asíncronas de larga duración. Extensiones de procesos para el subsistema de confianza Volviendo al tema de un subsistema de confianza, proponemos una extensión de la infraestructura genérica de SSO introduciendo la noción de políticas del subsistema de confianza. El modelo y lenguaje exacto de la política del subsistema de confianza puede tomar muchas formas, y no es el objetivo de este documento especificar o limitar los mecanismos que se pueden utilizar con este nivel de diseño de la infraestructura. En el paso 2 del proceso de alto nivel que se muestra en la Figura 3, la STS comprueba en un repositorio de políticas de subsistema de confianza para saber si el servicio Web de fachada que solicita un token de acceso al servicio Web de salida es un subsistema de confianza para el servicio Web de salida. Si es así, la STS incluye el reclamo de subsistema de confianza en 13 El protocolo de enlace es un conjunto de instrucciones predefinido que asegura la correcta secuencia e integridad de los datos transmitidos notifica a la terminal que envía cuando se reciben datos erróneos.
- 175. Capítulo 6: Identidad y acceso 163 el token de acceso emitido al servicio Web de fachada. El reclamo de subsistema de confianza y el resto de los datos del token son firmados por la STS de modo que el servicio Web de salida pueda comprobar la parte (STS) que autoriza el reclamo. Cuando el servicio Web de salida procesa el token de acceso enviado por el servicio Web de fachada en el paso 3, verifica la autenticidad del reclamo de subsistema de confianza y toma nota de que el servicio Web de fachada es un subsistema de confianza. Dependiendo de la naturaleza específica del reclamo, el servicio Web de salida podrá aceptar las identidades propagadas en las solicitudes de aplicación subsiguientes del servicio Web de fachada. Téngase en cuenta que el servicio Web de salida aún puede cumplir los requisitos de pruebas adicionales que soportan las identidades propagadas. Vamos a discutir el cumplimiento de este requisito posteriormente. Políticas del subsistema de confianza Además de la emisión, procesamiento, validación y ejecución de créditos del subsistema de confianza, también hay un componente de gestión para la manipulación de las políticas del subsistema de confianza. Las políticas del subsistema de confianza pueden tomar muchas formas. Los modelos existentes de autorización como “autorización basada en roles” también pueden ser usados para especificar las políticas del subsistema de confianza. El ejemplo que se muestra en la Figura 4 ilustra la modelación de diferentes servicios (servicios de flujo de trabajo y servicios de adaptador de datos) como recursos de aplicación. Figura 4: Un ejemplo de subsistema de políticas de confianza usando representación basada en roles
- 176. 164 Capítulo 6: Identidad y acceso Cada uno de los servicios de los recursos de aplicación puede permitir a los servicios de entrada que realicen determinadas acciones en función del rol que tiene asignado el servicio de acceso. Por ejemplo, el rol de subsistema de confianza se define para el flujo de trabajo y los servicios de adaptador de datos, de modo que los servicios de confianza que pertenecen a estos roles estén autorizados a difundir las identidades de los servicios de los recursos de la aplicación. A continuación, se pueden asignar servicios individuales a sus respectivos roles de subsistema de confianza definidos para estos servicios de recursos de la aplicación. Cuando el STS recibe una solicitud de token de acceso a servicio para un servicio de salida en particular, se comprueba si el servicio solicitante pertenece al rol de subsistema de confianza definido para el servicio de salida. Por otra parte, la STS también puede comprobar si al servicio solicitante se le permite propagar identidades al servicio de salida. Si el resultado de la verificación de la política afirma que el servicio solicitante es un subsistema de confianza, el STS inserta el reclamo de subsistema de confianza en el token de acceso emitido. Es importante para el token emitido tener elementos de alcance definido de tal manera que el reclamo de subsistema de confianza sólo se aplique al servicio de salida en particular que el chequeo de la política ha aprobado. Hay muchas maneras en que el reclamo de subsistema de confianza puede ser transportado en el interior del token de acceso a servicio. Por ejemplo, si el token de acceso a servicio es un token SAML 1.1, el reclamo de subsistema de confianza podría ser una declaración de decisión de autorización SAML dentro del token SAML: <saml:AuthorizationDecisionStatement Decision=”Permit” Resource=”http://downstreamservicio.multitierwebservicio.com”> <saml:Actions Namespace=”http://... ”> <saml:Action>PropagateIdentities</saml:Action> </saml:Actions> <saml:Subject> <saml:NameIdentifier Name=”http://frontendservicio.multitierwebservicio.com”/> </saml:Subject> </saml:AuthorizationDecisionStatement> En el ejemplo anterior, el servicio entrante identificado por la URL http://frontendservicio.multitierwebservicio.com es un subsistema de confianza autorizado para propagar identidades al servicio de salida identificado por la URL http://downstreamservicio.multitierwebservicio.com Trasmisión de los reclamos de identidad En la sección anterior mostramos cómo los subsistemas de confianza pueden ser autorizados a propagar la identidad del invocador original a los servicios de salida. Al comienzo de este capítulo, también se mencionó el requerimiento de que los servicios de salida podrán requerir pruebas adicionales para verificar y soportar la autenticidad de los reclamos trasmitidos. Las evidencias adicionales son reclamos generados por terceros diferentes del subsistema de confianza de entrada inmediato, ya que diferentes partes pueden ser de confianza para hacer valer un conjunto limitado de reclamos. Estas capacidades habilitan a los servicios de salida para ensamblar pruebas adicionales para procesar la solicitud de forma segura. Por ejemplo, para que un servicio de salida procese
- 177. Capítulo 6: Identidad y acceso 165 una transacción financiera de alto valor, como una transferencia de $ 500,000, es necesario saber que la solicitud, efectivamente, ha sido iniciada por el sujeto identificado en el reclamo trasmitido. No queremos subsistemas de confianza comprometidos que sean capaces de generar estas solicitudes bajo la apariencia de cualquier usuario. En esta sección vamos a mostrar cómo los subsistemas de confianza pueden dar soporte a estos requerimientos describiendo las categorías de los tokens de identidad propagados. Categorías de tokens trasmitidos Los siguientes tipos de tokens pueden ser propagadas por el subsistema de confianza: 1. Tokens de identidad generados por el subsistema de confianza. 2. Tokens de identidad generados por terceros. 3. Tokens auto firmados por el usuario. El primer tipo de token de identidad propagada se genera y emite por el subsistema de confianza trasmitiendo los reclamos de identidad. Este token puede ser tan simple como un token nombre de usuario de WS-security sin el elemento contraseña, o tan complicado como un token de identidad personalizado que contiene reclamos no estándares introducidos por el subsistema de confianza. En todos los casos, el subsistema de confianza señaliza el token de identidad antes de propagar el token generado a los servicios de salida. En los ejemplos siguientes, utilizamos el elemento XML <OriginalCaller> para contener las identidades propagadas. En este ejemplo concreto, UsernameToken se utiliza para propagar el contexto del invocador original. <OriginalCaller> <UsernameToken> <Username>...</Username> </UsernameToken> </OriginalCaller> Un ejemplo más complicado de un token personalizado generado por uyn subsistema de confianza sería como se muestra aquí: <OriginalCaller> <CustomUserContextToken Issuer=”http://trustedsubsystem1.multitierwebservicios.com”> <Username>...</Username> <Roles>…</Roles> </CustomUserContextToken> </OriginalCaller> Además del nombre de la persona que llama originalmente, el token personalizado emitido también contiene los roles de aplicación a que el usuario pertenece. Esta información puede ayudar a los servicios de salida a tomar decisiones sobre el acceso. El segundo tipo de tokens propagados proviene de un tercero que es de confianza para llevar a cabo un conjunto de funciones especializadas, como un servicio de tokens de seguridad que proporciona autenticación y servicios SSO a los servicios Web.
- 178. 166 Capítulo 6: Identidad y acceso El siguiente ejemplo muestra un subsistema de confianza propagando un token SAML firmado que es emitido por un STS que proporciona servicios SSO: <OriginalCaller> <saml:Assertion AssertionId="SecurityToken-745d68f1-9c63-4216-9fd5-9ebd96fab986" MajorVersion="1" MinorVersion="1" Issuer=”http://sso-sts.multitierwebservicios.com” …> … <ds:signature>…</ds:signature> </saml:Assertion> </OriginalCaller> La tercera categoría de tokens propagados es generada y firmada por el usuario que originó la llamada. La firma del token permite a los subsistemas de confianza y servicios de salida verificar los reclamos incluidos en el token. He aquí un ejemplo de un token de usuario auto firmado que se puede utilizar para correlacionar una solicitud de aplicación con el invocador original: <OriginalCaller> <CallerEvidenceToken> <Subject> <X509CertficateToken>…</X509CertificateToken> </Subject> <Timestamp>…</Timestamp> <MessageID>uuid: 5b19a5f5-426c-4cfa-b953-d5dc200e9508</MessageID> <Signature>…</Signature> </CallerEvidenceToken> </OriginalCaller> Al invocador original se adjunta un certificado X509 de modo tal que el sujeto en el certificado X509 se puede identificar como el invocador original. Dentro de la evidencia firmada, una marca de fecha y hora indica el momento en que la evidencia se genera y un identificador de mensaje se usa para identificar la cadena de solicitudes de aplicación iniciada por el invocador original. La marca de fecha y hora y el identificador de mensaje se firman entonces usando la clave privada asociada con el certificado X509. También es posible identificar al sujeto en la evidencia a través de otros medios de tokens. De hecho, podemos utilizar un token de nombre de usuario (sin contraseña) con una firma generada usando una clave derivada a partir de la contraseña y algunos otros datos al azar. La Tabla 1 resume las condiciones que pueden llevar a utilizar un tipo de token en lugar de otro: Tipo de token Condiciones de uso Token generado por Cuando el flujo de servicios confía en el subsistema de confianza el subsistema de para establecer la identidad del que llama originalmente sin confianza necesidad de evidencia adicional de terceros. Token generado por Cuando el flujo de servicios confía en el subsistema de confianza terceros para establecer reclamaciones acerca del que llama originalmente
- 179. Capítulo 6: Identidad y acceso 167 de conjunto con evidencia de terceros que satisface un conjunto adicional de requerimientos de seguridad. Por ejemplo, el flujo de servicios puede querer saber si el usuario origen fue autenticado recientemente por un tercero de confianza. En este caso, el token propagado puede ser un token SAML emitido por un STS que brinda un servicio SSO. Token autofirmado Cuando el subsistema de confianza está autorizado a ejecutar un de usuario conjunto de funciones de aplicación y cuando tiene que haber evidencia del que llamó originalmente de que el que llama inició la solicitud. Tabla 1: Tipos de tokens y condiciones de uso Mapeo identidad/credencial Con el mapeo identidad/credencial, un servicio toma una determinada identidad, y con o sin la ayuda de un tercero (como sería un servicio SSO), mapea la identidad dada en otro conjunto de credenciales relacionado. El conjunto de credenciales mapeada puede o no contener los datos de autenticación, como la contraseña de inicio de sesión. Los servicios usan entonces este conjunto de nuevas credenciales para obtener acceso a los recursos de salida. Consideramos que esto es una función especial del rol subsistema de confianza, donde el objetivo es transformar una identidad en otra identidad relacionada (puede ser un cambio en el tipo o el namespace) con el propósito de acceder a los recursos de salida que sólo reconocen la identidad transformada. Es importante tener en cuenta que los tipos de tokens de identidad propagada que hemos discutidos anteriormente no excluyen tipos de tokens que resultan del proceso de mapeo de la identidad o la credencial. Beneficios del diseño En vista de los requerimientos de las aplicaciones que hemos discutido, el nuevo enfoque descrito en este documento trae los siguientes beneficios: Considera que las actuales técnicas de optimización de aplicaciones que se centran en el intercambio de recursos, como el pool de conexiones, son tales que un diseñador de aplicaciones puede reducir al mínimo los costes de equilibrio entre seguridad y rendimiento. En nuestro modelo, el subsistema de confianza mantiene una sesión de seguridad con los servicios de salida. Se establece un contexto de seguridad para el subsistema de confianza que permite a los servicios de salida autorizar exactamente y determinar el alcance de la confianza. Posteriormente, la identidad se trasmite con uno de los tres tipos de tokens mencionados. No es necesario que los servicios establezcan el contexto de seguridad individualmente para cada usuario como lo requiere el modelo de suplantación/delegación. Separa claramente los conceptos de seguridad y los objetivos de “acción-en-nombre-de” versus “autorizado a realizar”. Nuestra solución de subsistema de confianza esboza los requerimientos y pasos que son necesarios para el diseño de sistemas “autorizado a realizar”, que es el modelo necesario para asegurar un gran número de las aplicaciones multicapas desplegadas actualmente. Las aplicaciones que requieran la delegación deberán continuar utilizando protocolos existentes como Kerberos.
- 180. 168 Capítulo 6: Identidad y acceso Nuestro diseño responde a la necesidad frecuente de los sistemas de salida a conocer la identidad del invocador original implementando la propagación segura de los reclamos de identidad del invocador original. El comportamiento del subsistema de confianza es administrado y conducido a través de políticas, permitiendo una mayor flexibilidad en la configuración y seguridad de las capas entre aplicaciones. El mismo servicio de aplicación se puede configurar para ser un subsistema de confianza al comunicarse con un servicio de CRM y no de confianza al comunicarse con un servicio de facturación. Esta flexibilidad fomenta la reutilización de componentes de servicio de acoplamiento flexible. Las credenciales para demostrar reclamos del subsistema de confianza están desacopladas de las que se utilizan para autenticar e identificar a los servicios. Las credenciales de autenticación suelen ser de larga vida, mientras que los roles de servicios de aplicación puede ser diferentes dependiendo de cómo el servicio está siendo utilizado en el contexto más amplio de aplicaciones distribuidas. Nuestro diseño permite una mayor flexibilidad para el cambio de las capacidades de servicio sin la introducción de gastos de gestión adicionales ni la necesidad de revocar y volver a emitir credenciales de autenticación. Los principios de diseño y la implementación de infraestructura para facilitar las comunicaciones de los subsistemas de confianza y la propagación de los reclamos de identidad son algunas de las áreas más necesitadas y menos investigadas en seguridad de aplicaciones. El diseño que se discute está en plena sintonía con el paradigma actual de la computación orientada a servicios, donde los límites explícitos de los servicios, el acoplamiento flexible, y el comportamiento basado en políticas son los principales atributos de diseño. Con nuestro enfoque de diseño, los servicios no hacen suposiciones a priori sobre si un servicio es de confianza, los servicios no están firmemente unidos a un conjunto específico de servicios de confianza o configuraciones de seguridad, y el alcance del servicio de confianza se puede ajustar a través de políticas configurables de tiempo de ejecución. Hay varios importantes requerimientos de seguridad que son fundamentales para el diseño de subsistemas de confianza, que son los siguientes: La capacidad de los servicios de identificarse mutua y positivamente entre sí. La capacidad de los servicios para determinar si se debe confiar en los reclamos de identidad propagada desde otro servicio. La capacidad de un servicio de proteger la integridad de los datos de las aplicaciones y los reclamos de identidad tramitados a través de subsistemas de confianza.
- 181. Capítulo 6: Identidad y acceso 169 Un metasistema de identidad Para los usuarios y las empresas, Internet resulta cada vez más valiosa. Cada vez son más las personas que están utilizando la web para las tareas diarias, desde las compras, la banca y el pago de facturas hasta los medios de consumo y entretenimiento. El comercio electrónico está creciendo, con las empresas distribuyendo más servicios y contenido a través de Internet, comunicándose y colaborando en línea, e inventando nuevas formas de conectar unos con otros. Pero a medida que el valor de lo que se hace en línea ha aumentado, la propia Internet se ha vuelto más compleja, criminalizada y peligrosa. El robo de identidad en línea, el fraude y las preocupaciones sobre la privacidad van en aumento, como resultado de prácticas cada vez más sofisticadas, tales como la “suplantación de identidad”. La multiplicidad de cuentas y contraseñas que los usuarios deben tener, y la variedad de métodos de autenticación en diferentes sitios resulta no sólo en la frustración del usuario, conocida como “fatiga de contraseñas”, sino también en prácticas inseguras como la reutilización del mismo nombre de cuenta y contraseña en muchos sitios. La raíz de estos problemas es que Internet fue diseñada sin un sistema de identidad digital en mente. Como parte de los esfuerzos para hacer frente a esta deficiencia, numerosos sistemas de identidad digital se han introducido, cada uno con sus propias fortalezas y debilidades. Sin embargo, ningún sistema por si solo satisface las necesidades de todos los escenarios de identidad digital. E incluso si fuera posible crear un sistema que lo hiciera, la realidad es que muchos sistemas de identidad diferentes están en uso hoy en día, mientras que otros continúan siendo inventados. Como resultado, el estado actual de la identidad digital en Internet es un mosaico incoherente de soluciones ad hoc que carga a las personas con una interacción de usuario diferente en cada sitio web, hace que el sistema en su conjunto sea frágil, y limita la plena realización de la promesa del comercio electrónico. ¿Qué es el metasistema de identidad? Dado que la adopción universal de un sistema o tecnología única de identidad digital es improbable que ocurra, una solución de identidad exitosa y que se emplee masivamente en Internet requiere de un enfoque diferente - uno con la capacidad de conectar los sistemas de identidad existentes y futuros en un metasistema de identidad. Este metasistema o sistema de sistemas, permitiría aprovechar los puntos fuertes de los sistemas de identidad que lo conforman, proporcionar la interoperabilidad entre ellos, y permitir la creación de una coherente e intuitiva interfaz de usuario para todos ellos. Las mejoras resultantes en el ciberespacio beneficiarían a todos, haciendo de Internet un lugar más seguro con el potencial para impulsar el comercio electrónico, el combate a la suplantación de identidades, y resolver otros problemas de la identidad digital. En el mundo desconectado, la gente lleva múltiples formas de identificación en sus carteras, como la licencia de conducir u otro documento oficial de identidad, tarjetas de crédito y
- 182. 170 Capítulo 6: Identidad y acceso tarjetas de fidelización14. Las personas controlan qué tarjeta usar y la cantidad de información a revelar en cualquier situación dada. Del mismo modo, el metasistema de identidad hace que sea más fácil que los usuarios estén seguros y en control cuando acceden a los recursos de Internet. Permite a los usuarios seleccionar de entre una cartera de sus identidades digitales y usarlas en servicios de Internet de su elección que las acepten. El metasistema de identidad permite que identidades proporcionadas por la tecnología de un sistema de identidad puedan ser utilizadas en sistemas basados en tecnologías diferentes, siempre que exista un intermediario que entienda ambas tecnologías, esté dispuesto, y se le tiene confianza para hacer las traducciones necesarias. Es importante tener en cuenta que el metasistema de identidad no compite o reemplaza los sistemas de identidad que conecta. Por el contrario, juega un papel análogo al del Protocolo de Internet (IP) en el ámbito de las redes. En la década de los 70 y principios de los 80, antes de la invención de la IP, las aplicaciones distribuidas se vieron obligadas a tener un conocimiento directo de la conexión de la red, ya fuera Ethernet, Token Ring, ArcNet, X.25 ó Frame Relay. Sin embargo, IP ha cambiado el paisaje, ofreciendo un metasistema independiente de la tecnología que pone las aplicaciones al margen de las complejidades de las tecnologías de red individuales, proporcionando una interconectividad sin fisuras y una plataforma para la inclusión de redes aún no inventadas (por ejemplo, 802.11 15 ) en el metasistema de la red. De la misma manera, los objetivos del metasistema de identidad son la conexión de los sistemas de identidad individuales, permitiendo una interoperabilidad sin fisuras entre ellos, para proporcionar aplicaciones con una representación de las identidades independiente de la tecnología, y para proporcionar una interacción con el usuario mejor y más consistente con todos ellos. Lejos de competir con o sustituir los sistemas de identidad con que se conecta, el metasistema se basa en los sistemas individuales para hacer su trabajo. Las identidades funcionan en contexto Las identidades en manos de una persona en el mundo real pueden variar desde las importantes, como los certificados de nacimiento, pasaportes y licencias de conducir, hasta las triviales, como las tarjetas de visita o las tarjetas de comprador frecuente de café. La gente utiliza sus diferentes formas de identificación en los diferentes contextos en que se aceptan. Las identidades pueden estar dentro o fuera de contexto. Las identidades utilizadas fuera de contexto por lo general no traen el resultado deseado. Por ejemplo, tratar de usar una tarjeta de café para cruzar la frontera está claramente fuera de contexto. Por otro lado, una tarjeta de crédito en un cajero automático, un documento oficial de identidad en una frontera, una tarjeta de café en un puesto de café, y una cuenta Windows Live ID (anteriormente. NET Passport) en MSN Hotmail, están todas claramente en su contexto. 14 La tarjeta de fidelización o fidelidad, que también se conoce como tarjeta de beneficios y descuentos, es el soporte físico de programas que ofrecen bonificaciones (descuentos, premios etc.) al titular cuando consume productos o servicios de la empresa emisora de la tarjeta. (Nota del traductor). 15 El estándar 'IEEE 802.11' define el uso de los dos niveles inferiores de la arquitectura OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una red de área local inalámbrica (WLAN). (Nota del traductor).
- 183. Capítulo 6: Identidad y acceso 171 En algunos casos, la distinción es menos clara. Usted posiblemente podría usar un documento oficial de identidad en el cajero automático, en lugar de una tarjeta emitida por el banco, pero si esto se traduce en que el gobierno tiene conocimiento de cada transacción financiera, algunas personas pudieran sentirse incómodas con esto. Se puede usar un número de Seguro Social como un número de identificación del estudiante, pero esto tiene importantes repercusiones en la privacidad, incluso facilitando el robo de identidad. Y usted puede utilizar las cuentas Passport en algunos sitios que no son de Microsoft, ya que algunos sitios lo han posibilitado; sin embargo, aun cuando fuera posible, solo pocos usuarios lo harían porque consideran que la participación de Microsoft en estas interacciones está fuera de contexto. El estudio de la experiencia de Passport y otras iniciativas de identidad digital en toda la industria nos ha llevado a trabajar con una amplia gama de expertos para codificar un conjunto de principios que creemos que son fundamentales para la creación de un sistema permanente y exitoso de identidad digital en Internet, ampliamente adoptado y duradero. Hemos llamado a estos principios, “las leyes de la identidad”. Las leyes de la identidad Las “leyes de la identidad” están destinadas a establecer un conjunto de principios fundamentales que deben cumplir las arquitecturas de identidad, que sean sostenibles y universalmente aceptados. Las leyes se han propuesto, debatido y perfeccionado a través de un largo diálogo abierto y continuando a través de Internet. En su conjunto, las leyes definen la arquitectura del metasistema de identidad. Ellas son: 1. Control y consentimiento del usuario: Los sistemas de identidad sólo deben revelar información que identifique a un usuario con el consentimiento del mismo. 2. Divulgación mínima para un uso limitado: El sistema de identidad debe divulgar la menor cantidad de información de identificación posible, ya que es la solución más estable y duradera. 3. Partes justificables: Los sistemas de identidad deben estar diseñados de modo tal que la divulgación de información de identificación se limite a las partes que tengan un rol necesario y justificable en una relación de identidad determinada. 4. Identidad dirigida: Un sistema de identidad universal debe soportar ambos, los identificadores “omnidireccionales” para su uso por las entidades públicas y “unidireccionales” para su uso por parte de entidades privadas, lo que facilita el descubrimiento, al mismo tiempo que evita la liberación innecesaria de manipuladores de correlación. 5. El pluralismo de operadores y tecnologías: Una solución de identidad universal debe utilizar y permitir la interoperabilidad de múltiples tecnologías de identidad proporcionadas por diferentes proveedores de identidad. 6. Integración humana: Los sistemas de identidad deben definir al usuario humano como un componente del sistema distribuido, integrado a través de mecanismos no ambiguos de comunicación entre hombre y máquina, ofreciendo protección contra ataques a la identidad. 7. Experiencia consistente a través de contextos: El metasistema de identidad unificado debe garantizar a sus usuarios una interacción sencilla y coherente, al tiempo que permite la separación de los contextos a través de múltiples operadores y tecnologías.
- 184. 172 Capítulo 6: Identidad y acceso Para profundizar en el tema de las leyes de identidad visite: http://www.identityblog.com. Roles dentro del metasistema de identidad Diferentes partes participan en el metasistema de maneras diferentes. Los tres roles en el metasistema se describen a continuación: Proveedores de identidad, que emiten las identidades digitales. Por ejemplo, los proveedores de tarjetas de crédito podrían emitir identidades que habilitan el pago, las empresas podrían emitir identidades a sus clientes, los gobiernos podrían emitir identidades para los ciudadanos, y las personas podrían utilizar la auto-emisión de identidades en contextos como la firma de los sitios web. Partes dependientes, que requieren las identidades. Por ejemplo, un sitio web o servicio en línea, que utiliza identidades ofrecidas por otras partes. Sujetos, que son los individuos y otras entidades sobre las cuales se hacen reclamos. Ejemplos de sujetos son los usuarios finales, las empresas y las organizaciones. En muchos casos, los participantes en el metasistema deben jugar más de un rol, y muchas veces los tres. Componentes del metasistema de identidad Para construir un metasistema de identidad, son necesarios cinco componentes claves: 1. Una forma de representar identidades mediante reclamos. 2. Un medio para negociar los proveedores de identidad, las partes que dependen, y los sujetos. 3. Un protocolo de encapsulación, para obtener reclamos y requerimientos. 4. Un medio para enlazar la tecnología y los límites de la organización, mediante la transformación de los reclamos. 5. Una interacción de usuario consistente, a través de múltiples contextos, tecnologías y operadores. Identidades basadas en reclamos Las identidades digitales consisten en un conjunto de reclamos hechos sobre el sujeto de la identidad, donde los “reclamos” son piezas de información sobre el sujeto que el emisor afirma son válidos. Esto es análogo a las identidades utilizadas en el mundo real. Por ejemplo, los reclamos de una licencia de conducir pueden incluir el estado de emisión, el número de la licencia de conducir, nombre, dirección, sexo, fecha de nacimiento, condición de donante de órganos, la firma y la fotografía, los tipos de vehículos que el sujeto puede conducir, y las restricciones a los derechos de conducción. El estado de emisión afirma que estos reclamos son válidos. Los reclamos de una tarjeta de crédito podrían incluir la identidad del emisor, el nombre del sujeto, el número de cuenta, la fecha de caducidad, el código de validación, y una firma. El emisor de la tarjeta afirma que estos reclamos son válidos. Los reclamos de una identidad auto emitida, donde el proveedor de identidad y el sujeto son una y la misma entidad, pueden incluir el nombre del sujeto, la dirección, el número telefónico y la
- 185. Capítulo 6: Identidad y acceso 173 dirección de correo electrónico, o tal vez sólo el conocimiento de un secreto. Para las identidades auto emitidas, el sujeto afirma que estos reclamos son válidos. Negociación La negociación permite a los participantes en el metasistema adoptar los acuerdos necesarios para que puedan conectarse entre sí dentro del metasistema. La negociación se utiliza para determinar las tecnologías, reclamos y necesidades mutuamente aceptables. Por ejemplo, si una de las partes entiende reclamos X.509 y SAML, y otro entiende reclamos Kerberos y X.509, las partes negocian y deciden utilizar reclamos X.509 entre ambos. Otro tipo de negociación determina si los reclamos que necesita una parte dependiente pueden ser suministrados por una identidad particular. Ambos tipos de negociación son simples ejercicios de macheo, se compara lo que una de las partes puede dar con lo que la otra necesita para determinar si cotejan. Protocolo de encapsulado El protocolo de encapsulado proporciona una forma, neutral con respecto a la tecnología, para intercambiar reclamos y requerimientos entre los sujetos, los proveedores de identidad, y las partes dependientes. Los participantes determinan el contenido y el significado de lo que se intercambia, no el metasistema. Por ejemplo, el protocolo de encapsulado permitiría a una aplicación recuperar reclamos codificados con SAML sin necesidad de entender o implementar el protocolo SAML. Transformadores de reclamos Los transformadores de reclamos enlazan las fronteras organizativas y técnicas, traduciendo reclamos entendidos en un sistema, en reclamos entendidos y de confianza en otro sistema, aislando de esta forma a la masa de clientes y servidores de las complejidades de la evaluación del reclamo. Los transformadores de reclamos también pueden transformar o refinar la semántica de estos. Por ejemplo, un reclamo que afirma “es un empleado” puede ser transformado en el nuevo reclamo “puede comprar libros”. El reclamo “nacido el 22 de marzo de 1960” podría transformarse en el reclamo “la edad es mayor de 21 años”, que intencionalmente ofrece menos información. Los transformadores de reclamos también se pueden utilizar para cambiar los formatos de los reclamos. Por ejemplo, los reclamos hechos en formatos tales como X.509, Kerberos, SAML 1.0, SAML 2.0, SXIP, y otros podrían ser transformados en reclamos expresados con diferentes tecnologías. Los transformadores de reclamos proporcionan la interoperabilidad necesaria actualmente, además de la flexibilidad necesaria para incorporar nuevas tecnologías. Interacción consistente con el usuario Muchos de los ataques a la identidad tienen éxito porque el usuario se deja engañar por algo que se presenta en la pantalla, y no a causa de tecnologías de comunicación inseguras. Por ejemplo, los ataques de suplantación de identidad no se producen en el canal seguro entre los servidores Web y los navegadores - un canal, que podría extenderse por miles de kilómetros -, sino en los dos o tres pies entre el navegador y el ser humano que lo utiliza. El metasistema de identidad, por lo tanto, busca capacitar a los usuarios para tomar decisiones informadas y razonables de identidad, permitiendo el desarrollo de una interfaz de usuario consistente, comprensible e integrada, para tomar esas decisiones.
- 186. 174 Capítulo 6: Identidad y acceso Una de las claves para asegurar el sistema en su conjunto es la presentación de una interfaz de usuario fácil de aprender y predecible, que se vea y funcione de la misma forma sin importar las tecnologías de identidad subyacentes que se empleen. Otra clave es hacer que resulte obvio cual es la información importante - por ejemplo, mostrar la identidad del sitio al que se está autenticando de una manera que haga que los intentos de suplantación de identidad sean evidentes. El usuario debe ser informado de cuales elementos de información personal le está solicitando la parte dependiente, y con qué fines. Esto permite a los usuarios tomar decisiones informadas sobre si debe o no divulgar esta información. Por último, la interfaz de usuario proporciona un medio para que el usuario consienta de forma activa en la divulgación, si está de acuerdo con las condiciones. Beneficios del metasistema de Identidad Microsoft reconoce que el metasistema de identidad sólo logrará la adopción generalizada si los participantes de todos los roles en el metasistema se benefician con su participación. Afortunadamente, este es el caso. Los principales beneficios del metasistema de identidad son: Mayor control y flexibilidad del usuario. Los usuarios deciden la cantidad de información que revelan, a quién y bajo qué circunstancias, de modo que pueden proteger mejor su privacidad. Una fuerte autenticación de dos vías de los proveedores de identidad y las partes dependientes ayuda a combatir la suplantación de identidad y otros tipos de fraude. La identidad y la información personal acompañante puede ser almacenada y administrada de forma segura en una variedad de maneras, incluyendo el servicio de proveedores de identidad en línea que elija el usuario, o en el PC del usuario, o en otros dispositivos, como memorias USB , tarjetas inteligentes, PDAs, y teléfonos móviles. Una interacción con el usuario más segura y comprensible. El metasistema de identidad permite una interacción de usuario predecible y uniforme, a través de múltiples sistemas de identidad. Se extiende y se integra a los usuarios humanos, contribuyendo así a asegurar el canal hombre-máquina. Aumenta el alcance de los sistemas de identidad existentes. El metasistema de identidad no compite con ni reemplaza a los sistemas de identidad que conecta, sino que preserva y se basa en las inversiones de los clientes en sus soluciones de identidad vigentes. Ofrece la oportunidad de utilizar las identidades existentes, tales como la identidad emitida a nivel corporativo y las identidades emitidas por las empresas en línea, en los nuevos contextos en los que no podrían haber sido empleadas anteriormente. Fomenta la innovación en el sistema de identidad. El metasistema de identidad debería hacer más fácil la rápida adopción y generalización de las tecnologías y sistemas de identidad de nuevo desarrollo. Los transformadores de reclamos pueden permitir a nuevos sistemas participar, aun cuando la mayoría de los participantes no entiendan los formatos nativos y protocolos de los reclamos. Permite la adaptación frente a los ataques. Las nuevas tecnologías son necesarias para mantenerse a la vanguardia de los delincuentes que atacan las tecnologías de identidad existentes. El metasistema permite a las nuevas tecnologías de identidad ser rápidamente desplegadas y utilizadas en el metasistema como sea necesario.
- 187. Capítulo 6: Identidad y acceso 175 Crea nuevas oportunidades de mercado. El metasistema de identidad permite implementaciones interoperables e independientes de todos los componentes del metasistema, lo que significa que las oportunidades de mercado sólo están limitadas por la imaginación de los innovadores. Algunas de las partes optarán por entrar en el negocio de los proveedores de identidad. Otros, ofrecerán servicios de certificación de identidades. Algunos implementarán el software de servidor. Otros implementarán software de cliente. Los fabricantes de dispositivos y reproductores de telefonía móvil pueden alojar las identidades en sus plataformas. Nuevas oportunidades de negocio se crean para los corredores de identidad, donde los intermediarios de confianza transforman los reclamos de un sistema a otro. En resumen, las nuevas oportunidades de negocio abundan. Un beneficio que todos compartimos a medida que el metasistema de identidad se despliega ampliamente, es un Internet más seguro y más confiable. El metasistema suministrará la solución de identidad ampliamente aceptada que la red necesita tan desesperadamente. Los participantes en el metasistema de identidad pueden incluir a cualquier persona o cualquier cosa que utilice, participe en, o se base en la identidad de alguna manera, incluyendo (pero no limitado a) los sistemas de identidad existentes, la identidad corporativa, la identidad del gobierno, las federaciones Liberty16, los sistemas operativos, los dispositivos móviles, los servicios en línea y las tarjetas inteligentes. Una vez más, las posibilidades están sólo limitadas por la imaginación de los innovadores. Una arquitectura para el metasistema de identidad: los servicios Web WS-* Microsoft ha trabajado durante los últimos años con socios de la industria en una arquitectura componible de extremo a extremo para los servicios Web. El conjunto de especificaciones que componen esta arquitectura ha sido nombrado por la industria como arquitectura de servicios Web WS-* (véase http://msdn.microsoft.com/webservices/). Esta arquitectura soporta las exigencias del metasistema de identidad. El protocolo de encapsulado que se usa para la transformación de los reclamos es WS-Trust. Las negociaciones se llevan a cabo utilizando WS-MetadataExchange y WS-SecurityPolicy. Estos protocolos permiten la construcción de un metasistema de identidad de neutralidad tecnológica y conforman el “plano posterior” del metasistema de identidad. Al igual que otros protocolos de servicios Web, estos también permiten que nuevos tipos de identidades y tecnologías sean incorporados y utilizados, a medida que se desarrollan y adoptan por la industria. Para fomentar la interoperabilidad necesaria para una amplia adopción, las especificaciones de WS-* se han publicado y están disponibles gratuitamente, han sido o serán presentadas a los organismos de normalización, y permiten el desarrollo de implementaciones sin el pago de derechos de autor. Los despliegues de las tecnologías de identidad existentes pueden ser aprovechados en el metasistema mediante la implementación del soporte para los tres protocolos WS-* mencionados más arriba. Ejemplos de tecnologías que podrían ser utilizados a través del metasistema incluyen los esquemas X.509 de reclamos LDAP (que se usan en tarjetas 16 Hace referencia a la Liberty Alliance que es una organización fundada en 2001 para establecer estándares abiertos, guías y buenas prácticas, en el tema de la gestión de identidad. (Nota del traductor).
- 188. 176 Capítulo 6: Identidad y acceso inteligentes), Kerberos (que se utiliza en Active Directory y algunos entornos UNIX), y SAML (un estándar que se utiliza en los escenarios de federación inter empresarial). Diagrama arquitectónico del metasistema de identidad La figura a continuación ilustra una muestra de las relaciones entre un sujeto, los proveedores de identidad, y las partes dependientes, mostrando algunas de las tecnologías utilizadas por el metasistema y los sistemas específicos utilizados a través del metasistema. El servidor de tokens de seguridad implementa el protocolo WS-Trust y proporciona soporte para la transformación de los reclamos. Las partes dependientes ofrecen declaraciones de requisitos, expresadas en términos de la especificación WS-SecurityPolicy, y expuestas a través de WS-MetadataExchange. El selector de identidad implementa la interacción de usuario consistente. Después de haber sido invocado por una aplicación, realiza la negociación entre la parte dependiente y el (los) proveedor (es) de identidad (es), muestra al sujeto (por ejemplo, el usuario final) la identidad de los proveedores de identidad “macheados” y las partes dependientes, obtiene los reclamos, y los libera para la aplicación bajo la supervisión del sujeto. Figure 5: Un metasistema de identidad Implementación del metasistema de identidad .NET 3.0 incluye los siguientes componentes de software para la participación en el metasistema de identidad: Selector de identidad: CardSpace es un componente de .NET 3.0 que proporciona la interacción de usuario consistente que es requerida por el metasistema de identidad. Está especialmente blindado contra la manipulación y el engaño, para proteger la identidad digital del usuario final y mantener al usuario en control. Cada identidad digital administrada por “InfoCard” está representada por una “Information Card” visual en la interfaz de usuario del cliente. El usuario selecciona las identidades representadas por “InfoCards” para autenticar a los servicios participantes. Variante simple auto emitida por el proveedor de identidad: CardSpace también incluye
- 189. Capítulo 6: Identidad y acceso 177 un proveedor de identidades simple que permite a los usuarios individuales de PC crear y utilizar identidades auto-emitidas, habilitando la autenticación fuerte sin contraseña a las partes dependientes. Una identidad auto emitida es aquella donde el usuario avala la información que está proporcionando, algo muy parecido a lo que los usuarios hacen hoy al registrarse en un sitio Web. Estamos implementando el proveedor simple de identidades auto emitidas para ayudar a arrancar el metasistema de identidad, ya que consideramos que las identidades auto emitidas seguirán siendo aceptadas por ciertos tipos de servicios. Las identidades alojadas en el proveedor simple de identidades auto emitidas, no incluirán o almacenarán información personal sensible, como los números de Seguro Social (u otros números de identidad personal si son desarrollados) ni números de tarjetas de crédito. Las identidades auto emitidas no están destinadas a proporcionar toda la gama de características que un proveedor de identidad administrada puede ofrecer - el mercado está abierto a empresas que proporcionen soluciones de gestión de identidad para los consumidores. Proveedor de identidad de Active Directory: Este es un proveedor de identidad administrada integrado con Active Directory. Incluye un conjunto completo de controles de políticas para administrar el uso de identidades del Active Directory en el metasistema de identidad. El Active Directory Federation Services, una nueva funcionalidad del componente Active Directory en Windows Server 2003 R2, es el primer paso para la integración de las identidades de Active Directory con el metasistema de identidad. WCF: Los servicios Web de Windows Communication Foundation proporcionan a los desarrolladores una manera de crear y desplegar rápidamente aplicaciones distribuidas, incluyendo los servicios de las partes dependientes en el metasistema de identidad. El metasistema de identidad preserva y se basa en las inversiones de los clientes en las soluciones de identidad existentes, como Active Directory y otras. La implementación de Microsoft será completamente interoperable a través de los protocolos WS-* con otras implementaciones del selector de identidad, con otras implementaciones de las partes dependientes, y con otras implementaciones del proveedor de identidades. Las aplicaciones de otros proveedores tienen la misma capacidad de utilizar CardSpace para gestionar sus identidades que las aplicaciones de Microsoft. Otros pueden crear toda una implementación de extremo a extremo del metasistema, sin ningún tipo de software de Microsoft, sin pagar a Microsoft, y sin usar ningún servicio de identidad en línea de Microsoft. ¿Qué ha sido de Passport? El esfuerzo de identidad más conocido de Microsoft es casi seguramente el Windows Live ID (anteriormente conocido como Passport). Microsoft ha aprendido mucho de la construcción de uno de los servicios de autenticación en Internet más grande a escala mundial, y ha aplicado estas lecciones en el desarrollo de las Leyes de Identidad, el metasistema de identidad, y varios de sus productos. Passport fue pensado originalmente para resolver dos problemas: ser un proveedor de identidad para el MSN y las propiedades de Microsoft, y ser un proveedor de identidad para Internet. Tuvo éxito en la primera, con más de 250 millones de cuentas de Passport activas y
- 190. 178 Capítulo 6: Identidad y acceso más de mil millones de autenticaciones por día. En cuanto a la segunda de las metas originales, se hizo evidente para nosotros a través del continuo compromiso con los socios, consumidores y con la industria, que en muchos casos no tenía sentido para Microsoft desempeñar este papel en las transacciones entre, por ejemplo, una empresa y sus clientes. Además de su impacto en nuestra forma de pensar sobre las leyes de identidad, vale la pena mencionar que el funcionamiento del servicio Passport ha ayudado a Microsoft a ganar una comprensión profunda de los retos técnicos y operativos que enfrentan los grandes proveedores de identidad. Estas experiencias nos han ayudado a asegurar que nuestros productos de identidad satisfacen las necesidades de los despliegues a gran escala. El metasistema de identidad es diferente de la versión original de Passport, en varios aspectos fundamentales. El metasistema no almacena información personal, dejando a los proveedores de identidad individual decidir cómo y dónde almacenar la información. El metasistema de identidad no es un proveedor de identidad en línea para Internet, de hecho, proporciona un medio para que todos los proveedores de identidad convivan con los demás y compitan entre sí, en igualdad de condiciones dentro del metasistema. Por último, si bien Microsoft ha cobrado los servicios de usar la versión original de Passport, no se le cobrará a nadie por participar en el metasistema de identidad. El sistema Passport también ha evolucionado en respuesta a estas experiencias. Ya no almacena información personal más allá de las credenciales de usuario/contraseña. Passport es ahora un sistema de autenticación orientado a los sitios de Microsoft y los de los socios más cercanos - un rol que está claramente en contexto y con el que nuestros usuarios y socios están muy cómodos. Passport y MSN planean implementar el soporte para el metasistema de identidad como un proveedor de identidad en línea para MSN y sus socios. Los usuarios de Passport conseguirán una mayor seguridad y facilidad de uso, y los socios de MSN en línea serán capaces de interoperar con Passport a través del metasistema de identidad.
- 191. Capítulo 6: Identidad y acceso 179 Resumen En este capítulo hemos discutido brevemente los beneficios de una estrategia de identidad y acceso. También discutimos un juego de principios de diseño para facilitar un subsistema de confianza. El capítulo cerró con un vistazo detallado a las capacidades de un metasistema de identidad. Estas capacidades están presentes actualmente en .NET 3.0. Muchos de los problemas que enfrenta Internet hoy en día, desde los ataques de suplantación de identidad hasta las interfaces de usuario inconsistentes, se derivan de la naturaleza de parches de las soluciones de identidad digital que los fabricantes de software han construido, dada la ausencia de un sistema unificado y una arquitectura para la identidad digital. Un metasistema de identidad, tal como se define en las leyes de identidad, suministraría un tejido unificador de la identidad digital, utilizando los sistemas de identidad existentes y futuros, proporcionando interoperabilidad entre ellos, y permitiendo la creación de una interfaz de usuario coherente y sencilla entre todos ellos. Basando sus esfuerzos en las leyes de la identidad, Microsoft está trabajando con otros actores de la industria para construir el metasistema de identidad, utilizando los protocolos publicados de WS-*, que hacen que las implementaciones de Microsoft sean totalmente compatibles con las producidas por otros.
- 192. 180 Capítulo 6: Identidad y acceso Estudio de caso SOA: OTTO Desde su primer catálogo de pedidos por correo en 1950, OTTO siempre ha buscado la innovación en las ventas minoristas mediante la introducción de nuevos métodos de distribución, canales de atención, y experiencia de compra. Hoy en día, OTTO es el número uno mundial de las compañías de pedidos por correo y el segundo minorista en línea. OTTO decidió construir una tienda virtual de ropa de moda, que trascendería las limitaciones tradicionales del comercio electrónico y fomentaría unas relaciones más estrechas con los clientes. OTTO también quería introducir características totalmente nuevas del comercio electrónico, tales como herramientas de colaboración, y controles de usuario del tipo arrastrar y soltar. OTTO construyó entonces la tienda virtual OTTO Store utilizando Microsoft .NET Framework 3.0. OTTO Store es un cliente inteligente que aprovecha las ventajas del hardware y los recursos locales de software, para una interacción con el usuario rica y sensible, pero también se integra profundamente con los recursos de la Web. OTTO Store utiliza Windows CardSpace para las funciones de autenticación de aplicaciones. Windows CardSpace proporciona a los usuarios una experiencia de compra más fácil y segura, ahorrándoles la molestia de escribir los nombres de usuario y contraseñas. OTTO está considerando la posibilidad de usar Windows CardSpace en sus operaciones de comercio electrónico, incluyendo las futuras versiones de su sitio Web líder de ventas. El estudio de caso completo se encuentra disponible en: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=200504 Otros estudios de caso SOA pueden consultarse en: http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA
- 193. 181 Apéndice A. Glosario de acrónimos Sigla Significado Notas AJAX Asynchronous JavaScript And Es una técnica de desarrollo web para crear aplicaciones XML interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. API Application Programming Es el conjunto de funciones, procedimientos o métodos, Interface en la programación orientada a objetos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Son usadas generalmente en las bibliotecas (también denominadas comúnmente "librerías"). ASN1 Abstract Syntax Notation One Es una norma para representar datos con independencia de la máquina que se esté usando y sus formas de representación interna. Es un protocolo de nivel de presentación en el modelo OSI. B2B Business-to-Business Es la transmisión de información referente a transacciones comerciales realizadas electrónicamente, por lo general utilizando tecnología como la Electronic Data Interchange (EDI), presentada a finales de los años 1970 para enviar electrónicamente documentos tales como pedidos de compra o facturas. BAM Business Activity Monitoring Software que ayuda en el monitoreo de las actividades de negocio, a medida que dichas actividades son implementadas en sistemas computacionales. El término fue lanzado inicialmente por la consultora Gartner, y se refiere a la agregación, análisis y presentación de información en tiempo real acerca de las actividades del negocio. BPEL Business Process Execution Es un lenguaje estandarizado por OASIS para la Language composición de servicios Web. Básicamente, consiste en un lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio añadida que ayuda a la programación en gran escala. BPM Business Process Metodología corporativa cuyo objetivo es mejorar la Management eficiencia a través de la gestión de los procesos de negocio, que se deben modelar, organizar, documentar y optimizar de forma continua. Como su nombre sugiere, BPM se enfoca en la administración de los procesos dentro de una organización. CDI Customer Data Integration Es el proceso de consolidación y manejo de información del cliente desde todas las fuentes disponibles para una organización, incluyendo detalles del contacto, datos de referencia del valor del cliente y la información recopilada a partir de diversas interacciones, como acciones de marketing directo, por ejemplo.
- 194. 182 Apéndice A. Glosario de acrónimos CMM Capability Maturity Model Es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA). Para cada área de proceso, a su vez, se define un conjunto de buenas prácticas. CORBA Common Object Request Es un estándar definido por el Object Management Broker Architecture Group (OMG), que permite trabajar integradamente con los componentes de software escritos en múltiples lenguajes de programación y que se ejecutan en múltiples equipos con diferentes plataformas. CRM Customer Relationship CRM es una filosofía corporativa en la que se busca Management entender y anticipar las necesidades de los clientes existentes y también de los potenciales, que actualmente se apoya en soluciones tecnológicas que facilitan su aplicación, desarrollo y aprovechamiento. En pocas palabras, se trata de una estrategia de negocio enfocada en el cliente y sus necesidades. CRUD Create, Read, Update, Delete Es usado para referirse a las funciones básicas en bases de datos o en la capa de persistencia en un sistema de software. DCE Distributed Computing Es un sistema de software desarrollado en la década de Environment 1990 por un consorcio que incluía a Apollo Computer (luego parte de Hewlett-Packard), IBM, DEC, y otros. El DCE proporciona un conjunto de servicios que pueden utilizarse separadamente o en combinación, en ambientes de desarrollo de computación distribuida. DCOM Distributed Component Object Es una tecnología propietaria de Microsoft para Model desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Extiende el modelo COM y proporciona el sustrato de comunicación entre la infraestructura del servidor de aplicaciones COM+. Ha sido abandonada en favor del framework .NET. DSL Domain-Specific Language Es un lenguaje de programación o especificación de un lenguaje dedicado a resolver un problema en particular, representar un problema específico y proveer una técnica para solucionar una situación particular. El concepto no es nuevo pero se ha vuelto más popular debido al aumento del uso de modelado específico de dominio. EAI Enterprise Application Es el proceso de conectar unas aplicaciones con otras Integration para intercambiar información operativa o financiera. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor, en lugar de enfocarse en la coordinación de labores operativas. EDI Electronic Data Interchange EDI puede definirse formalmente como la transferencia de datos estructurados entre organizaciones, de un sistema informático a otro, sin intervención humana y basándose en estándares de mensajes.
- 195. Apéndice A. Glosario de acrónimos 183 EII Enterprise Information Es un proceso de integración de la información usando la Integration abstracción de los datos para proporcionar una interfaz unificada (conocida como acceso uniforme a los datos). El objetivo de la EII es conseguir que un gran número de fuentes de datos heterogéneas se presenten como una única fuente de datos homogéneos. ERP Enterprise Resource Planning Sistemas de información gerenciales que integran y manejan muchos de los aspectos asociados con las operaciones de producción y distribución de una compañía en la producción de bienes o servicios. ESB Enterprise Service Bus Consiste en una solución de software que proporciona los servicios fundamentales para arquitecturas complejas a través de un sistema de mensajes (el bus) basado en estándares y que responde a eventos. Los desarrolladores normalmente implementan un ESB utilizando tecnologías de productos de infraestructura de capa media que se basan en normas reconocidas. ETL Extract, Transform and Load Es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos, data mart, o data warehouse, o en otro sistema operacional para apoyar un proceso de negocio. GDI Graphics Device Interface Es uno de los tres componentes o subsistemas de la interfaz de usuario de Microsoft Windows. Trabaja junto con el núcleo y la API de Windows. Esta Interfaz de programación de aplicaciones se encarga del control gráfico de los dispositivos de salida como los monitores o las impresoras. IPV6 Internet Protocol Version 6 IPv6 está destinado a sustituir a IPv4, cuyo límite en el número de direcciones de red admisibles está empezando a restringir el crecimiento de Internet y su uso, especialmente en China, India, y otros países asiáticos densamente poblados. ISV Independent Software Vendor Es un término comercial para compañías que se especializan en la fabricación o la venta de software, diseñado para la comercialización en masa o para nichos de mercado. JSON JavaScript Object Notation Es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML en AJAX. LDAP Lightweight Directory Access Protocolo a nivel de aplicación el cual permite el acceso Protocol a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos (aunque su sistema de almacenamiento puede ser diferente) a la que pueden realizarse consultas. MOSS Microsoft Office SharePoint Plataforma de aplicaciones Web desarrollada por Server Microsoft. Lanzada inicialmente en 2001, SharePoint se asocial habitualmente a la gestión de contenido y de documentos, pero es actualmente una plataforma mucho más amplia de tecnologías Web que puede ser configurada en un amplio rango de áreas.
- 196. 184 Apéndice A. Glosario de acrónimos MVC Model-View-Controller Es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. El patrón de llamada y retorno MVC, se ve frecuentemente en aplicaciones Web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es la Base de Datos y la lógica de negocio, y el controlador es el responsable de recibir los eventos. OLAP On-Line Analytical Processing Es una solución utilizada en el campo de la llamada Inteligencia empresarial cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales. Se usa en informes de negocio de ventas, marketing, informes de dirección, minería de datos y áreas similares. OOA Object-Oriented Analysis Es el proceso de análisis de una tarea, para desarrollar un modelo conceptual. En un modelo típico de OOA se describen los programas informáticos que podrían ser utilizados para satisfacer el conjunto de requisitos definidos por el cliente. OOD Object Oriented Design Durante el diseño orientado a objetos (OOD), un desarrollador de aplicaciones aplica restricciones de implementación al modelo conceptual producido en el análisis orientado a objetos (OOA). PDA Personal Digital Assistant También denominado ordenador de bolsillo u organizador personal, es una computadora de mano originalmente diseñado como agenda electrónica (calendario, lista de contactos, bloc de notas y recordatorios) con un sistema de reconocimiento de escritura. RIA Rich Internet Application Aplicaciones web que buscan una combinación de las ventajas que ofrecen las aplicaciones Web y las aplicaciones tradicionales para escritorio. El objetivo final es mejorar la interacción con el usuario. RAD Rapid Application Es un proceso de desarrollo de software, desarrollado Development inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE. Tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. REST Representational State Es una técnica de arquitectura de software para sistemas Transfer hipermedia distribuidos como la Web. El término se originó en el año 2000 y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. Si bien se refería originalmente a un conjunto de principios de arquitectura, en la actualidad se usa en un sentido más amplio para describir cualquier interfaz Web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como SOAP. RFID Radio Frequency Es un sistema de almacenamiento y recuperación de IDentification datos remotos. El propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto (similar a un número de serie único) mediante ondas de radio.
- 197. Apéndice A. Glosario de acrónimos 185 ROI Return Of Investment El índice de retorno sobre la inversión es un indicador financiero que mide la rentabilidad de una inversión, es decir, la tasa de variación que sufre el monto de una inversión (o capital) al convertirse en utilidades (o beneficios). RPC Remote Procedure Call Es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC. RSS Really Simple Syndication Formato XML para sindicar o compartir contenido en la web. Se utiliza frecuentemente para difundir información actualizada a usuarios que se han suscrito a la fuente de contenidos. SaaS Software as a Service Es un modelo de distribución de software donde el software y los datos que maneja se alojan en servidores de la compañía de tecnologías de información y las comunicaciones (TIC) y se accede con un navegador web o un cliente especializado a través de internet. SAML Security Assertion Markup Es un protocolo basado en XML que utiliza tokens de Language seguridad que contienen declaraciones para pasar información sobre un principal (por lo general un usuario final) entre un proveedor de identidad y un servicio Web. SDLC Systems Development Life Es el proceso de creación o modificación de los Cycle sistemas, modelos y metodologías que la gente usa para desarrollar estos sistemas de software. En ingeniería de software el concepto de SDLC sostiene muchos tipos de metodologías de desarrollo de software que constituyen el marco para la planificación y el control. SLA Service Level Agreement Es un contrato escrito entre un proveedor de servicio y su cliente con el objeto de fijar el nivel acordado para la calidad de dicho servicio. SOAP Simple Object Access Es un protocolo estándar que define cómo dos objetos Protocol en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros, y está actualmente bajo el auspicio de la W3C. SSO Single Sign-On Es un procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación. SXIP La Red SXIP es una red de cooperación pública para la identidad, que usa un protocolo abierto, con el propósito de construir una solución equilibrada que satisfaga las necesidades de toda la comunidad. UDDI Universal Description, Es uno de los estándares básicos de los servicios Web Discovery and Integration cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.
- 198. 186 Apéndice A. Glosario de acrónimos UML Unified Modeling Language Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. URL Uniform Resource Locator Es una secuencia de caracteres, de acuerdo a un formato modélico y estándar, que se usa para nombrar recursos en Internet para su localización o identificación, como por ejemplo documentos textuales, imágenes, vídeos, presentaciones, presentaciones digitales, etc. VAR Value-Added Reseller Es una compañía que añade una o varias características a uno o varios productos ya existentes y después los revende (normalmente a usuarios finales) como un producto integrado o como una solución "llave en mano" completa. Esta práctica es común en la industria de componentes electrónicos, donde por ejemplo, una aplicación software puede ser añadida a un hardware ya existente. WSDL Web Services Description Describe la interfaz pública de los servicios Web. Está Language basado en XML y define la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. X.509 En criptografía, X.509 es un estándar de la Unión Internacional de Telecomunicaciones (UIT) para infraestructuras de claves públicas. Especifica, entre otras cosas, formatos estándares para certificados de claves públicas y un algoritmo de validación de la ruta de certificación. XAML eXtensible Application Markup Es un lenguaje declarativo basado en XML, optimizado Language para describir gráficamente interfaces de usuarios visuales ricas desde el punto de vista gráfico, tales como las creadas por medio de Adobe Flash. XAML fue diseñado para soportar las clases y métodos de la plataforma de desarrollo .NET que tienen relación con la interacción con el usuario, en especial el despliegue en pantalla. XML eXtensible Markup Language Es un metalenguaje extensible de etiquetas desarrollado por W3C. Es una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil.
- 199. 187 Referencias 1. Enabling “Real World” SOA through the Microsoft Platform, A Microsoft White Paper, Diciembre 2006. Disponible en: http://www.microsoft.com/biztalk/solutions/soa/whitepaper.mspx 2. Service Oriented Integration Pattern. Disponible en: http://msdn2.microsoft.com/en-us/library/ms978594.aspx 3. Business Component Factory, Peter Herzum y Oliver Sims, John Wiley & Sons, 1999. 4. Enabling the Service-Oriented Enterprise, Architecture Journal, Abril 2006. Disponible en: http://msdn2.microsoft.com/en-us/library/bb245664.aspx 5. Ontology and Taxonomy of Services in a Service-Oriented Architecture, Architecture Journal, Abril 2007. Disponible en: http://msdn2.microsoft.com/en-us/library/bb491121.aspx 6. Office Business Applications: Building Composite Applications Using the Microsoft Platform, Diciembre 2006. Disponible en: http://msdn2.microsoft.com/en-us/library/bb220800.aspx 7. Service Oriented Infrastructure, Mark Baciak. Disponible en: http://msdn2.microsoft.com/en-us/architecture/aa973773.aspx 8. Service Orientation and Its Role in Your Connected Systems Strategy. Disponible en: http://msdn.microsoft.com/architecture/solutions_architecture/servicio_orientation/default.as px?pull=/library/en-us/dnbda/html/srorientwp.asp 9. Building Applications on a Workflow Platform, Dave Green, Architecture Journal, Abril 2006. Disponible en: http://msdn2.microsoft.com/en-us/library/bb245670.aspx. 10. Portal Integration Pattern. Disponible en: http://msdn2.microsoft.com/en-us/library/ms978585.aspx 11. Scaling Out SQL Server with Data Dependent Routing, Man Xiong y Brian Goldstein. Disponible en: http://www.microsoft.com/technet/prodtechnol/sql/2005/scddrtng.mspx 12. The What, Why, and How of Master Data Management, Roger Wolter y Kirk Haselden. Disponible en: http://msdn2.microsoft.com/en-us/architecture/bb190163.aspx 16. Master Data Management (MDM) Hub Architecture, Roger Wolter. Disponible en: http://msdn2.microsoft.com/en-us/library/bb410798.aspx#mdmhubarch_topic5 17. User Experience for Enterprise Applications, Simon Guest, 2006. Más información sobre UX disponible en: http://msdn2.microsoft.com/en-us/architecture/aa699447.aspx
- 200. 188 Referencias 18. How To: Use Impersonation and Delegation in ASP.NET 2.0, August 2005, J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan, Patterns and Practices. Disponible en: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000 023.asp 19. Authentication and Authorization, January 2004, Patterns and Practices. Disponible en: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod03. asp 20. Developing Identity-Aware ASP.NET Applications, Identity and Access Management services, July 2004. Disponible en: http://www.microsoft.com/technet/security/topics/identitymanagement/idmanage/P3ASP D_1.mspx