Beruflich Dokumente
Kultur Dokumente
Arquitectura de Infraestructura
Arquitecturas de alta disponibilidad para hosting masivo Brindar informtica integral de alta productividad Infraestructuras orientadas a pruebas Perfil del Architecture Journal: Don Ferguson Resolver el dilema de la integracin Ontologa y Taxonoma de los Servicios en una Arquitectura Orientada a Servicios Versionado en SOA
Contenidos
Prlogo
Por Simon Guest
1 2
Descubra los secretos para la creacin de infraestructuras de hosting escalables, confiables, seguras y fcil de mantener.
19
24
26
30
Versionado en SOA
Por Boris Lublinsky
La idea de versionado de servicios es simple, pero la implementacin requiere mucha reflexin y planificacin. Aprenda diversos enfoques para permitir esto en su organizacin.
36
Recursos
Fundador Arvindra Sehmi Microsoft Corporation Jefe Editor Simon Guest Microsoft Corporation Consejo Editorial de Microsoft Gianpaolo Carraro John deVadoss Neil Hutson Eugenio Pace Javed Sikander Philip Teale Jon Tobey Editor Comercial Lisa Slouffman Microsoft Corporation Diseo, Impresin y Distribucin: CMP Technology Contract Publishing Chris Harding, Director Gerente Angela Duarte, Gerente de Publicacin Lisa Broscritto, Gerente de Proyecto Kellie Ferris, Directora Corporativa de Servicios Creativos Jimmy Pizzo, Director de Produccin
Prlogo
Estimado arquitecto:
Bienvenido al Journal 11, cuyo tema es Arquitectura de Infraestructura. Hace algunos aos, uno de mis colegas anteriores, Pat Helland, propuso una analoga de arquitectura llamada Metrpolis. Su planteamiento era crear un paralelo utilizando la arquitectura de construccin y planificacin de una sociedad para dar sentido a los desafos complejos en la arquitectura de software. Una de las cosas que siempre recuerdo de la Metrpolis es que, como arquitectos de TI, por lo general, dedicamos proporcionalmente demasiado tiempo a nuestras propias construcciones. Muchos de nosotros somos culpables de obsesionarnos con la apariencia que tendr nuestra construccin y cmo se desempaar. Sin embargo, como resultado, a veces nos olvidamos de la visin ms global. Por ejemplo, el modo en el que nuestra construccin se adecuar a la ciudad. Para la arquitectura de la construccin, una construccin debe ajustarse a los planos de la ciudad en una cantidad de reas, incluidos los planos de carreteras, utilidades, transporte, etc. Teniendo esto en cuenta para la edicin de nuestro Journal, quera analizar los mismos desafos del modo que se relacionan con nuestra industria. Para encabezar esta edicin, contamos con un grupo de autores, Shaun Hirschman, Matthew Baldwin, Tito Leverette y Michael Jonson, quienes han escrito un artculo sobre arquitecturas de alta disponibilidad para hosting masivo. En este artculo, el grupo comparte aspectos fundamentales para crear una arquitectura de hosting que sea resistente y escalable. A continuacin, tenemos a Marc Colmes y Simon Cox con una nueva visin de HPC que llaman Informtica de Alta Productividad. Marc y Simon han trabajado juntos sobre el anlisis de las consideraciones integrales y de infraestructura para HPC. Sigue Mario Cardinal con un artculo llamado Infraestructuras orientadas a pruebas. Mario es un gran defensor del Desarrollo orientado a Pruebas (TDD, sus siglas en ingls) y en este artculo describe en lneas generales el modo en el que el TDD puede aplicarse al nivel de la infraestructura. Para continuar con la serie de Perfiles del Architecture Journal, para esta edicin tuve la exclusiva oportunidad de reunirme con Don Ferguson y preguntarle lo que significa ser arquitecto. Para quienes no lo saban, Don sola ser Asociado de IBM y Arquitecto Principal en el Grupo de Software de IBM, recientemente antes de unirse a Microsoft. Despus de la entrevista con Don, contina un artculo de Jim Kilt sobre Resolver el dilema de la integracin. Jim comparte algunos de sus desafos de integracin adems de presentarnos un Mapeo en el pozo de la desesperacin! Para completar esta edicin, tenemos dos artculos grandiosos sobre el tema de la Arquitectura Orientada a Servicios (SOA) del mundo real. Comienza Shy Cohen con una ontologa y taxonoma de servicios que puede encontrarse en SOA, varios de los cuales se ajustan bien dentro del espacio de la infraestructura. El ltimo artculo de esta edicin es Versionado en SOA, de Boris Lublinsky. Boris toma un desafo que pueden enfrentar varios arquitectos en la actualidad y analiza mltiples enfoques para el versionado de servicios. Bien, este es todo el contenido que hemos tratado en esta edicin. Espero que estos artculos le ayuden a considerar no slo el tipo de construcciones que prepara para su Metrpolis, sino tambin la infraestructura que se necesita para ayudar a las personas a que lleguen a ella. Hasta la prxima edicin!
La informacin contenida en The Arquitecture Journal (Journal) se brinda slo con fines informativos. El material publicado en el Journal no constituye la opinin o asesoramiento de Microsoft Corporation (Microsoft) o de CMP Media LLC (CMP) y no debe basarse en ningn tipo de material publicado en este Journal sin antes buscar asesoramiento independiente. Microsoft y CMP no proveen garanta o representacin alguna respecto de la precisin o aptitud de los fines de cualquier material del Journal y en ningn caso Microsoft o CMP aceptan responsabilidad de ningn tipo, incluyendo responsabilidad por culpa (excepto por dao contra los derechos personales del individuo o fallecimiento), por cualquier tipo de daos o perjuicios o prdidas (incluyendo, sin limitacin, prdida del negocio, rdito, ganancias o prdida consiguiente) de cualquier ndole o naturaleza que resultare del uso del presente Journal. El Journal puede contener imprecisiones tcnicas y errores de tipografa. El Journal se actualizar de vez en cuando y podr otras veces estar desactualizado. Microsoft y CMP no aceptan responsabilidad alguna por mantener la informacin de este Journal actualizada ni por el incumplimiento del hecho. Este Journal contiene material propuesto y creado por terceros. Hasta el alcance mximo permitido por la ley aplicable, Microsoft y CMP excluyen toda responsabilidad por cualquier acto ilegal que surgiera de un error, omisin o imprecisin en este Journal y Microsoft y CMP no se responsabilizan del material suministrado por terceros. Las siguientes marcas comerciales son marcas registradas de Microsoft Corporation: BizTalk, Microsoft, SharePoint, SQL Server, Visual Studio, Windows, Windows NT y Windows Server. Cualquier otra marca comercial es propiedad de sus respectivos propietarios. Todos los derechos del autor, marcas registradas y cualquier otro tipo de propiedad intelectual del material contenido en el Journal pertenecen y son licencia exclusiva de Microsoft Corporation. Queda totalmente prohibida la copia, reproduccin, transmisin, almacenamiento, adaptacin o modificacin de la forma o contenido del presente Journal sin previo consentimiento por escrito por parte de Microsoft Corporation y los autores individuales. 2005 Microsoft Corporation. Todos los derechos reservados.
Simon Guest
Sntesis Escalabilidad y alta disponibilidad son propiedades esenciales y a la vez opuestas para las infraestructuras de hosting. Ya sea ingeniero de programas de cdigo abierto, consumidor de soluciones comerciales o ingeniero TI de Microsoft, parece que no existe la solucin milagrosa. Al investigar diferentes aspectos de una infraestructura de hosting, podemos encontrar tecnologas existentes que se pueden agrupar para crear la solucin milagrosa. Este proceso tambin ayudar a detectar las diferencias que debemos reducir. La plataforma de la solucin milagrosa debe ofrecer una infraestructura que permita una gran cantidad de cuentas de clientes y debe ser escalable y con alto grado de redundancia. Este artculo se centrar en los componentes necesarios para la construccin de un entorno exclusivo que sea escalable, confiable, seguro y fcil de mantener y que al mismo tiempo ofrezca alta disponibilidad (HA, sus siglas en ingls). Los proveedores de aplicaciones solitarias, hasta hosters compartidos de alta densidad, se beneficiaran de esta solucin. Pero, Existe? De lo contrario, Cules son los desafos que nos bloquean en la actualidad? y Cunto podemos aproximarnos a esto?.
Estos mdulos son fciles de imaginar y de rpida implementacin, en especial, si se venden paquetes bsicos a clientes que slo desean alojar muy pocas pginas y nada ms complicado. En la media que este tipo de plataforma creca, comenzaron a surgir varios problemas: necesidad de restauracin y backup, uso de un espacio costoso para un centro de datos, capacidad para el servidor, clientes con alta carga y administracin general. A los problemas de plataforma se sumaban una demanda cada vez mayor por parte de los clientes y progresos en la nueva tecnologa de Web. Surgieron tecnologas como PHP, Cold Fusion, ASP, JSP y ASP.NET que ofrecan plataformas ms complejas impulsadas por el deseo de los clientes de una funcionalidad ms rica y mejores negocios. Esto, a su vez, produjo nuevas aplicaciones que requeran almacenes de datos como SQL y otras tecnologas relacionadas. En la medida que se creaban nuevas aplicaciones, el potencial comercial que ofrecan estas aplicaciones se volvi ms evidente y ms solicitado. Los hosters, en el intento de maximizar los resultados y simplificar la gestin, continuaron con la gestin de todos servicios requeridos para soportar a sus clientes sobre un servidor autnomo. Esto cre una mayor carga en un nico servidor, obstaculizndolo y reduciendo la cantidad de sitios Web que poda servir. La demanda del consumidor aument de un modo ms rpido de lo que la tecnologa de hardware poda soportar. Los hosters tuvieron que escalar a nivel exterior, aislando y separando los servicios en varios servidores en vez de escalar de forma vertical con un hardware ms rpido.
Historia de la industria del hosting y problemas actuales Para comprender totalmente las complejidades de la plataforma de Web hosting, primero debemos comprender el modo en el que se inicio el mercado del hosting y cmo evolucion hasta su estado actual. Antes de que el hosting tradicional comenzara a tomar forma, los simples sitios de Web estticos eran populares y relativamente nuevos para el pblico en general. La infraestructura que se construy para respaldar este movimiento era igualmente bsica y se concentr en obtener la mayor cantidad posible de clientes en vez de brindar servicios de ltima generacin, como aplicaciones interactivas y alta disponibilidad. Comencemos con la descripcin de la arquitectura clsica que han utilizado en el pasado los hosters basados en Microsoft. Un nico servidor de Web autnomo, con servicios de FTP, que ejecuta IIS con contenido alojado localmente en el servidor. Cada sistema autnomo tiene un cierto costo hardware, software, licencias, redes, energa, espacio en gabinete y dems. Algunos hosters, an han llevado esto al extremo alojando todos los servicios en un servidor nico para una cantidad x de clientes. Por ejemplo, tienen servidores con IIS, SQL, software para servidor de correo de terceros y almacenamiento local para el contenido alojado.
EL OBJETIVO PRIMARIO AL DISEAR UNA PLATAFORMA ALOJADA ES OPTIMIZAR LA ESCALABILIDAD, DISPONIBILIDAD, DENSIDAD Y PARIDAD DE PRECIOS AL MISMO TIEMPO QUE SE SIGUE UN NIVEL DE SEGURIDAD LO MS GRANULAR POSIBLE AISLANDO LOS CLIENTES ENTRE S.
La industria del hosting continu saturndose de compaas competitivas en respuesta a la alta demanda de servicios en la Web como sitios de Web dinmicos y carritos de compras para el comercio electrnico. Este mercado prspero oblig a los hosters a diferenciar sus servicios de los otros mediante la creacin de acuerdos de nivel de servicio (SLAs). No slo los hosters deben ofrecer sus servicios a un bajo costo, sino que tambin deben estar siempre disponibles. Esto se confirma con la creciente dependencia que poseen los clientes y negocios sobre la Web y sus demandas de aplicaciones ms interactivas y complejas. La produccin de servicios altamente disponibles, por lo general, da como resultado ms servidores para soportar la redundancia as como tambin nuevos requisitos de rendimiento, seguridad y gestin. De qu manera pueden los hosters escalar y respaldar estos servicios con la arquitectura de software y hardware ofrecida?
Firewall
Balanceador de la carga
Contenido esttico
Contenido dinmico
Modelos de distribucin de carga Debido a que hay mltiples usuarios de Web, los arquitectos de hosting deben considerar diversas opciones para distribuir la configuracin entre todos los servidores de Web. Esta configuracin depende del tipo de modelo de distribucin de carga que se elige. Existen varios modelos para distribuir la carga entre los mltiples usuarios de Web. Analizaremos dos que son comunes para las posibles situaciones de hosting: distribucin de carga de aplicacin y distribucin de carga conjunta. Distribucin de carga de aplicacin La distribucin de carga de aplicacin describe un modelo en el que la carga se distribuye entre mltiples nodos de usuarios de Web basndose en la funcin del servidor. Este modelo por lo general est basado en la solicitud y utiliza las capacidades de enrutamiento de la capa de aplicacin que varios balanceadores de carga de red soportan en la actualidad. Este modelo permite a los hosters dividir el grupo de servidores basndose en las cargas de trabajo del servidor. Al analizar una implementacin tpica de este modelo, veremos que los servidores se separan de aquellos que tratan contenido dinmico como ASP.NET o se disea un PHP para el contenido esttico (Figura 1). Se puede agregar an ms granularidad a esta configuracin si se dividen ms los servidores dinmicos de acuerdo a su funcin especfica. Esto implica la creacin de subgrupos de servidores ms pequeos para cada tipo de aplicacin. Todo el trfico de ASP.NET sera enrutado hacia un subgrupo de servidores de ASP.NET y todo el contenido de PHP sera enrutado hacia otro subgrupo de servidores. Debido a que los servidores de contenido dinmico normalmente necesitan ms recursos, el diseo permite al hoster utilizar para esos sitios una clase diferente de hardware del que se necesitara para el contenido esttico. La mayora de los hosters deben considerar el costo al disear sus plataformas; por lo tanto, el modelo de distribucin de carga de aplicacin tal vez no siempre sea posible simplemente porque este modelo aumenta la cantidad de servidores requeridos. La aplicacin de carga de distribucin tambin incrementa la complejidad al administrar los servidores y se basa en gran medida en los equipos de conexin de redes.
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%Aislamiento Escala
Compartido Uno a uno
Distribucin de carga conjunta Para mantener un costo mnimo y tambin para lograr que la administracin de la plataforma sea menos compleja, un hoster puede elegir implementar un modelo de distribucin de carga conjunta. Denominamos modelo de distribucin de carga conjunta a aqul en el que todos los servidores comparten exactamente la misma configuracin. Cada servidor en el centro de servidores tambin es capaz de servir tanto el contenido esttico como el dinmico. En los sistemas que ejecutan IIS, el diseo del grupo de aplicaciones es indispensable para maximizar la escala en este tipo de modelo. Ajustar Microsoft IIS para el hosting masivo Dentro de una compaa de hosting masivo que se centra en la plataforma de Microsoft, existe una constante presin de un nivel ms alto de densidad sobre cada servidor del grupo. Con una arquitectura alta disponibilidad compleja, el hoster aumenta su modelo de densidad; sin embargo, an aparecen obstculos en el desempeo, en particular, con los grupos de aplicaciones. En IIS, el diseo del grupo de aplicaciones es fundamental para lograr la mxima densidad. Si no se dedica tiempo a planificar de un modo apropiado el diseo del grupo de aplicaciones, esto puede causar problemas inesperados de estabilidad y rendimiento. Los grupos de aplicaciones tratan verdaderamente el aislamiento y existe una correlacin directa entre el nivel de aislamiento que se elige y la cantidad de aplicaciones que se colocan en el servidor. Al disear grupos de aplicaciones se debe comparar la necesidad de seguridad con la estabilidad deseada. Los hosters deben elegir entre dos escenarios de grupos de aplicaciones, un escenario de grupo de aplicaciones compartidas uno-a-muchos o un escenario uno-a-uno. Es importante observar que en la Figura 2, el escenario del grupo de aplicaciones uno-a-uno muestra una tendencia ms hacia el aislamiento pero lejos de la escala. Por otro lado, el escenario del grupo de aplicaciones compartidas, muestra una tendencia hacia niveles superiores de la escala mientras que se aleja del aislamiento. En el mejor de los casos, el hoster elegira una solucin que le permitiera maximizar la escala sin sacrificar el aislamiento y la seguridad. Anlisis de tendencias: Aislamiento vs. Escala El escenario de aislamiento uno-a-uno se define con un grupo
de aplicaciones asignado a una aplicacin nica o en un escenario de hosting de Web compartido para un sitio de Web nico. Esto permite que un hoster logre un alto nivel de aislamiento ya que cada aplicacin o sitio de Web se ejecuta dentro de un proceso nico y no comparte recursos con otros en el servidor. sta es una solucin ptima para un proveedor de software independiente o hoster que debe asegurar a sus clientes que otros en el mismo servidor no tendrn acceso a sus datos importantes. Sin embargo, este escenario es limitado en un escenario de hosting masivo. Si bien brinda el nivel deseado de aislamiento y seguridad debido a los requisitos de memoria, no cumple el objetivo de proporcionar a los hosters la escala que desean. Ya que cada grupo de aplicaciones ejecuta la memoria de sus consumidores y finalmente se produce un embotellamiento. La incorporacin de cdigo dinmico dentro de la plataforma aade un nuevo nivel de complejidad. Por ejemplo, las aplicaciones ASP.NET aumentan la cantidad de memoria necesaria para el grupo de aplicaciones. Esto se vuelve un problema para el hoster porque limita la cantidad de sitios de Web dinmicos que pueden ejecutarse en un servidor. Comienzan a observar que pueden escalar dentro de cientos de sitios en vez de miles de sitios, que es el punto de referencia para la mayora de los progresos en la tecnologa del hardware. Concretamente, la incorporacin de la arquitectura de 64-bits le ha permitido a varios hosters darse el lujo de agregar enormes cantidades de memoria a sus servidores. Si bien esto les permite ir ms all de obstculos potenciales, tambin se pueden descubrir otros problemas. Escenario del grupo de aplicaciones compartidas Un escenario del grupo de aplicaciones compartidas describe una situacin en la que ms de una aplicacin o sitio de Web reside en el mismo grupo de aplicaciones. Existen dos configuraciones diferentes para grupos de aplicaciones compartidas. La primera es uno-para-N en la que el proveedor de hosting dedica un nico grupo de aplicaciones a una cantidad predefinida de sitios de Web. La segunda es una configuracin uno-para-todos en la que el host coloca todos los sitios de Web en un nico grupo de aplicaciones. Un escenario del grupo de aplicaciones compartidas permite escalar mejor ya que no somete al sistema a las limitaciones de la memoria impuestas por un diseo de grupo de aplicaciones uno-a-uno.
LA INCORPORACIN DE LA ARQUITECTURA DE 64BITS LE HA PERMITIDO A VARIOS HOSTERS DARSE EL LUJO DE AGREGAR ENORMES CANTIDADES DE MEMORIA A SUS SERVIDORES. SI BIEN ESTO LES PERMITE IR MS ALL DE OBSTCULOS POTENCIALES, TAMBIN SE PUEDEN DESCUBRIR OTROS PROBLEMAS.
Almacenamiento conectado a la red (NAS) La mayora de los host que han elegido plataformas altamente escalables han optado por utilizar NAS como el almacenamiento remoto centralizado para todos sus clientes. En entornos de Windows altamente disponibles, NAS se accede mediante el Sistema Comn de Archivos de Internet (CISS), generalmente entre una red de almacenamiento dedicado. El contenido de Web de los clientes se almacena centralmente en el NAS con la ruta hacia el NAS almacenada como ruta lgica utilizando un sistema de archivos distribuido (DFS). La combinacin de NAS y DFS permite que un hoster basado en Windows distribuya los clientes entre mltiples subsistemas de almacenamiento NAS, impidiendo que un problema global, afecte a esos clientes. Optimizar CISS, TCP/IP y el NAS contribuye en gran medida respecto de lo escalable que es el NAS con la cantidad de sitios de clientes simultneos para los cuales puede estar sirviendo contenido. Si el NAS posee una escasa optimizacin, los hosts pueden presentar problemas que pueden afectar toda la base del cliente. Sin embargo, los hosts mitigan esto utilizando mltiples subsistemas de NAS para Duplicacin de la configuracin Otro requisito fundamental para el hosting masivo en entornos de alta diferentes segmentos de clientes y dedicando interfaces y redes de almacenamiento para este tipo de trfico. disponibilidad, es mantener el estado y la configuracin entre todos Varios subsistemas de NAS poseen capacidades de duplicacin y los usuarios de Web del grupo. Si bien hay otras configuraciones que deben existir en cada usuario, la ms importante es la del servidor de captura de imagen. Los hosters utilizan estas tecnologas para ofrecer un proceso consistente para la recuperacin y emergencias en Web. Algunos servidores de Web poseen soporte para un almacn de especial, si se considera que el sistema de almacenamiento podra configuracin centralizada. Para quienes no lo poseen, se debe contener cientos de miles de clientes. implementar alguna solucin de software para duplicar la Un problema con el subsistema de almacenamiento NAS puro es que configuracin entre los servidores. debido a que tecnologas como SQL no admiten el almacenamiento remoto de sus bases de datos entre los CISS, esto limita al hoster Almacenamiento del contenido respecto del tipo de servicio que puede ofrecer. Uno de los principios centrales para las plataformas de hosting masivo, altamente escalables que enfrentan los arquitectos es Red de rea de almacenamiento (SAN) determinar la ubicacin del contenido del cliente que ser Varios sistemas de almacenamiento de las empresas pueden operar almacenado. En la mayora de los casos, se trata contenido que est tanto una SAN como un NAS, con una diferencia clave que es el dentro de SQL o en el disco. Ya que el punto de inicio de la mtodo que se utiliza para conectarlos. En el caso de una SAN, los arquitectura es un clster configurado con miles de sitios, no es mtodos ms importantes son el Canal de Fibra (FC) y iSCSI. prctico ubicar el contenido en discos directamente conectados a la
NO EXISTE UN MODO RENTABLE DE CONSTRUIR UNA PLATAFORMA DE CLSTER DE SQL COMPACTA, DE ALTA DISPONIBILIDAD Y ESCALABLE. CADA TOPOLOGA DEL CLSTER TIENE SUS DESVENTAJAS JUNTO CON EL HECHO DE QUE LOS HOSTS NO TIENEN CONTROL SOBRE EL DISEO DE LA APLICACIN DE LOS CLIENTES.
Clster de SQL SQL es un servicio importante que ofrecen varios hosters a la mayora de sus clientes. Sin embargo, es una de las reas claves que muchos hosts no implementan como un clster. Existen varias razones para esto y la ms importante es el costo y la licencia. No obstante, los hosts que eligen un cluster de SQL altamente disponible deben disear su arquitectura de modo que seleccionen el tipo correcto de metodologa de clster que soporte diversas bases de datos. A diferencia de otras empresas en las que el clster de SQL est compuesto de una cantidad relativamente pequea de bases de datos, las compaas de hosting implementarn cientos, sino miles, de bases de datos para un nico clster de base de datos. Este clster debe ser resistente tanto en rendimiento como en tiempo de actividad. Debido a que las compaas de hosting no tienen control sobre la forma en la que sus clientes escriben sus aplicaciones, se presentan algunos problemas nicos al disear un clster para un hosting masivo. En un entorno de hosting, cada cliente posee 1-n bases de datos asignadas a l. Estas bases de datos pueden almacenarse en un nico clster o distribuirse entre mltiples clsteres. El clster ms comn que un hoster construira para un hosting SQL masivo es el clster de SQL activo-pasivo estndar. Sin embargo, en la medida que los hosts entran en un hosting de software como servicio (SaaS), los requisitos del clster de SQL se convierten de redundancia del nodo a redundancia de datos. Esto agrega ms problemas ya que estos mismos sistemas an alojarn numerosas bases de datos. No existe un modo rentable de construir una plataforma de clster de SQL compacta, de alta disponibilidad y escalable. Cada topologa del clster tiene sus desventajas junto con el hecho de que los hosts no tienen control sobre el diseo de la aplicacin de los clientes. El clster de SQL ideal permitira a los hosts realizar una distribucin de carga, adems de duplicar la base de datos, sin tener que ocuparse de los problemas de colisin de datos mientras mantienen una gran cantidad de bases de datos entre los clsteres. Conclusin Los proveedores de servicios deben enfrentar continuamente desafos para cumplir con la creciente demanda de los clientes de nuevos servicios que ofrecen mayor valor para las pequeas y medianas empresas, desarrolladores, consumidores y diseadores.
Sobre los autores Shaun Hirschman ha trabajado en el rea del hosting por casi ocho aos y est muy en sintona con los desafos de la tecnologa y los negocios inherentes. Antes de unirse a Microsoft en el 2006, Shaun comenz en la industria del hosting como soporte tcnico y ascendi a la posicin de administrador senior de sistemas Windows. Posee un gran conocimiento tcnico y experiencia en los sistemas basados en Microsoft. En su mayora, le gusta experimentar con tecnologas de hardware y software de ltima generacin para apaciguar su deseo por aprender. Mathew Baldwin ha trabajado en el rea de servicios alojados en los ltimos diez aos. En el pasado, ha cumplido funciones como arquitecto, ingeniero de sistemas senior, solucionador de problemas regular y consultor para plataformas basadas en Microsoft con mltiples compaas de servicios alojados. Contribuy positivamente para lanzar al mercado la primera plataforma de hosting compartida, agrupada de alta disponibilidad Windows 2003 y trabaj estrechamente con Microsoft en varias iniciativas. En la actualidad trabaja como arquitecto senior para Affinity Internet. Tito Leverette ha trabajado en el rea de hosting por ms de ocho aos. Comenz su carrera con Interland Inc, actualmente Web.com. Antes de unirse a Microsoft, Tito fue arquitecto en el equipo de plataforma de Web de SunTrust Inc., el noveno banco ms grande de los Estados Unidos de Amrica. Tito posee aos de experiencia en el diseo, creacin e implementacin de infraestructuras de Web para grandes empresas as como tambin para clientes de hosting. Es graduado del Instituto de Tecnologa de Georgia (Georgia Tech). Michael Johnson dedic ms de siete aos como empleado en el rea de proveedor de servicios de Web donde desarroll y dise soluciones y aplicaciones altamente escalables sobre productos de Microsoft. En la actualidad trabaja como arquitecto experto de Web para Microsoft.
Sntesis En la actualidad, realizar un clculo informtico complejo cientfico y de ingeniera significa mucho ms que simplemente comprar una gran supercomputadora. Si bien tradicionalmente HPC significa High Performance Computing (Informtica de Alto Rendimiento), creemos que la solucin integral real debera ser Informtica de Alta Productividad. A lo que queremos referirnos con Informtica de Alta Productividad es a toda la estructura de manipulacin de datos e informtica y tambin a las herramientas, tecnologas y plataformas necesarias para coordinar, procesar y monitorear este clculo integral. Muchos desafos estn asociados con la produccin de una solucin general de Informtica de Alta Productividad (HPC) para problemas de dominio cientficos y de ingeniera. En este artculo tratamos estos desafos basados en los requisitos tpicos de estos problemas, proponemos varias soluciones y demostramos el modo en el que han sido implementados para usuarios a travs de un modelo cientfico especfico del entorno, siguiendo el proceso desde el comienzo hasta el final. Nuestra solucin tcnica general se podr poner en prctica para cualquier solucin que requiera capas de interfaz y control para un servicio de HPC orientado al servicio distribuido.
La solucin tiene en cuenta la cadena de valor total para las soluciones de HPC y utiliza la tecnologa de Microsoft para superar esta cadena de valor ms all de simples mejoras del rendimiento en el hardware, software y algoritmos que, como se describe, no siempre es una opcin posible. La clave de nuestra solucin es la capacidad de integrarse con otros sistemas mediante estndares abiertos. Requisitos para soluciones de informtica de alta productividad En los dominios de ingeniera y ciencia, las soluciones HPC pueden utilizarse para resolver problemas matemticos complejos en una diversidad de reas, como clculos estadsticos para epidemiologa gentica, clculos de dinmica de fluidos para la industria aeroespacial y modelado del medio ambiente global. Cada vez ms, el desafo est en integrar todos los componentes requeridos para componer, procesar y analizar los resultados de problemas de manipulacin de datos e informtica de gran escala. An con diferencias tan diversas en los problemas, los requisitos para las soluciones poseen las mismas caractersticas debido al contexto del dominio y la complejidad del problema en cuestin.
Diseada para una solucin a un problema especfico Debido a que las interacciones de la industria y los clculos son diversos, no hay proveedores de soluciones particulares para un problema determinado, lo que da como resultado soluciones altamente individualizadas que surgen de empresas o departamentos de investigaciones que necesitan estos clculos. Esta individualidad se compone de una pequea cantidad de equipos que realmente buscan resolver estos problemas y tal vez necesitan mantener la propiedad intelectual de los algoritmos u otros aspectos de procesos especficos. La individualidad en s misma no es un problema puede ser algo muy bueno pero debido a que las soluciones tcnicas son medios para lograr un objetivo, es probable que estas soluciones individuales no sean productizadas y por lo tanto, probablemente sean difciles de relacionar y poco claras. Procesos y clculos de larga ejecucin El avance tecnolgico de la infraestructura requerida para realizar procesamientos a gran escala y administrar cantidades masivas de datos ha brindado oportunidades para desempear procesos que anteriormente eran poco prcticos desde el punto de vista de la informtica. El desarrollo de nuevos algoritmos y la paralelizacin del cdigo para que se ejecuten de modo simultneo sobre varios clsteres informticos pueden tener un efecto radical, reduciendo el tiempo de procesamiento en diversos rdenes de magnitud. Por lo tanto, un procesamiento interminable, tal vez, podra ejecutarse en varias semanas o meses. Este xito ha permitido a las industrias lograr importantes resultados y aprovechar estas posibilidades para ofrecer ms orientacin a los desarrollos. Requisitos para la informacin documentada En reas de investigacin, existe una necesidad muy importante de registrar la informacin por varios motivos. Puede simplemente existir la necesidad de volver a ejecutar algoritmos para asegurar que se produzcan los mismos grupos de resultados como un ejercicio de tranquilidad, pero muy probablemente, esto ser requerido como parte de prueba y de backup cientfico para publicar una investigacin. Pueden tambin existir razones estatutarias para esta informacin documentada: en la industria aeroespacial, en el caso de una investigacin de accidente areo, los ingenieros que toman decisiones determinadas de ingeniera pueden ser responsables de la causa del accidente y estar sometidos a procesos penales. Por lo tanto, la necesidad de recrear estados especficos y grupos de resultados segn sea necesario y de seguir los pasos de decisin hacia estas elecciones es de extrema importancia. La complejidad de estas tareas es an mayor cuando uno considera que el ciclo de vida del diseo de un avin podra ser de 50 aos. Volmenes significativos de datos y movimiento de datos Deep Thought desempe una de las tareas ms grandes de HPC en
Figura 1: Los esfuerzos para mejorar la velocidad del procesamiento se agrupan en tres zonas interrelacionadas, formando un ciclo.
Hardware
Algoritmos
Software
Sin embargo, la realidad es que es muy probable que los clculos significativos que requieren una gran cantidad de procesamiento impliquen importantes cantidades de datos a lo largo de todo el ciclo de vida del clculo. An, con la simplicidad del ingreso de datos y el resultado del estilo de Deep Thought, los grupos de datos operativos dentro del espacio de problema durante el clculo, pueden ser significativos. Se deben desarrollar estrategias para administrar estos datos y sus metadatos. Dada la necesidad de la informacin documentada, estas estrategias deben ser flexibles y eficaces, y deben estar integradas dentro procesos de flujo de trabajo utilizados para coordinar los clculos. Mejorar el valor de las soluciones de informtica de alta productividad Debido a la complejidad de los problemas de dominio y los requisitos descriptos anteriormente, la conclusin final es que las soluciones generalmente se disean para obtener resultados. Esto, es en cierto modo un logro y, en primer lugar, deja de lado el esfuerzo intelectual que implica el desarrollo de algoritmos informticos y soluciones conceptuales. Figura 2: Escenario de informtica general
ms rpidos, discos ms rpidos, mayor memoria, etc., podran estar limitados por la capacidad del software o los algoritmos para utilizar el hardware disponible. Tambin, est limitado por los ciclos de lanzamiento de hardware de nueva generacin y probablemente est muy limitado por el presupuesto. Utilizar ms o mejor software. Es ms probable que los algoritmos en s mismos sean un problema que el software subyacente, pero a veces, pueden existir mejoras en la manipulacin de datos u otras funciones para proporcionar un avance til. Esto tambin puede estar afectado por restricciones presupuestarias. Utilizar mejores algoritmos. Mejores algoritmos requieren invencin que simplemente puede no ser posible y es probablemente menos predecible que las mejoras de software o hardware, aunque cuando ocurre puede brindar la mejora ms importante de todas. Por lo tanto, el desafo ante mejoras continuas de plataforma sobre un nivel bsico es fcil de comprender pero difcil de lograr. Como resultado, los equipos que utilizan soluciones de HPC tienden a ser pragmticos respecto de la cantidad de tiempo que les lleva completar los clculos ya que comprenden que estn aprovechando al mximo las tecnologas disponibles y, como mencionamos anteriormente, pueden sentirse satisfechos por al menos haber completado la operacin. Una vez que se han reducido los tiempos informticos hasta ser lo ms prcticos posible, entonces, mejorar el valor de estas soluciones es cuestin de considerar el proceso total y las repercusiones de realizar clculos para reducir an ms el tiempo total en nuevas comprensiones cientficas o de la industria. Dada la naturaleza de la investigacin/ingeniera de los problemas, entonces el proceso total generalmente implica un flujo de trabajo humano antes o despus de la tarea informtica. Tambin se trata del desarrollo de un grupo de
Escenario de informtica
Acceso Inicio de sesin Solicitud Carga Proceso Preproceso Anlisis Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Usuario
Aprobacin
Postproceso
Descarga
En Supercomputing 2006, en Tampa, Fla., mostramos el modo en el que la aplicacin de la metodologa de flujo de trabajo descripta en el articulo puede proporcionar los simulacros de GENIE con un entorno de Figura 1: La Ciencia Ambiental de alta productividad integral soporta: (a) Interfaz de Web para rpida composicin de simulacros y un clientes utilizando Windows Presentation Foundation, (b) Windows Workflow Foundation para crear y entorno de hosting eficaz para coordinar coordinar simulacros y (c) Infraestructura heterognea compuesta de Recursos Informticos de su ejecucin. Los cientficos que Windows y Linux y almacenamiento de datos de Oracle y SQL Server. participan en la colaboracin, estn investigando el modo en el que la Base de circulacin termosalina en el Atlntico datos Tiempo de ejecucin del la densidad del agua marina es NGS persistente flujo de trabajo DB controlada por la temperatura (termo) y Flujo de trabajo Servicios Oracle la salinidad (salina) y las diferencias de MS http(s) Configuracin del 10g SQL densidad impulsan la circulacin experimento Recopilacin Servicio de DB ocenica responde a los cambios de de secuencias IE 7 Web Recurso de comandos Procesamiento niveles de dixido de carbono en la Almacenamiento de archivos Geodise Cliente del Cliente de MS MQ atmsfera e intenta comprender, en explorador programacin Infraestructura heterognea particular, las estabilidad de las Control Trabajo cientfica Servicio de Eventos corrientes ocenicas ms importantes Servicio de Red (Matlab, Python, ...) Web de Windows y API/CMD Post Nacional bajo distintos contextos de cambios Windows Presentation Procesamiento Servicio de llamadas Microsoft CCS climticos. Foundation WS Communication Web
Grupo Condor Clster de Linux Recursos informticos Globus SSH Interfaces
Foundation
Clientes alternativos
Microsoft Institute of High Performance Computing: Matthew J. Fairman, Andrew R. Price, Gang Xue, Marc Molinari, Denis A. Nicole, Kenji Takeda, and Simon J. Cox Colaboradores externos:: Tim Lenton (Facultad de Ciencias Ambientales, Universidad de East Anglia) y Robert Marsh (Centro Nacional de Oceanografa, Universidad de Southampton)
Simulacro
Flujo de trabajo
Administrador
Cuenta
Usuario avanzado
Flujos de trabajo
Produccin
Escenario de informtica. El proceso informtico se divide en cuatro pasos fundamentales para un usuario tpico que aseguran la finalizacin de la tarea: acceso, solicitud, proceso y anlisis. (Ver Figura 2) Acceso:
solucin y deber identificarse como usuario vlido. Es posible que entonces puedan ver slo la informacin relevante a su funcin y/o grupo. Inicializacin: Antes de realizar una solicitud del trabajo, puede existir la necesidad de configurar un panel de control para ejecutar la tarea. Dada la naturaleza de la informtica de larga ejecucin, una ejecucin del proceso puede considerarse un proyecto. Solicitud:
los datos pueden ser propicios para ser computados dentro de porciones totalmente aisladas, como situaciones que pasara si o un anlisis paramtrico. Esta fase puede ocurrir durante un tiempo potencialmente significativo. Lo ideal sera que se proporcione algn comentario al usuario final durante este tiempo. Post-proceso: El paso final en el procesamiento en s es similar al del preprocesamiento en el sentido de que es posible que se complete algn trabajo con los datos obtenidos. Esto puede comprender movimientos de datos hacia almacenes, agregacin de datos de nodos separados, operaciones de depurado, tareas de visualizacin, etc. Anlisis:
que estn previstos para ser utilizados como parte de un trabajo. Los grupos de datos pueden ser grandes, no homogneos o de origen externo, por lo tanto, se necesita un paso especfico en el flujo de trabajo para obtener estos datos y dividirlos entre el nodo del clster de manera que equilibre la cantidad prevista de trabajo. Insercin de datos: un usuario debe poder aadir parmetros y metadatos asociados para garantizar que el trabajo se ejecute exitosamente. Estos parmetros se capturan para reutilizacin y auditora. Aprobacin: despus de aadir parmetros y cualquier otra informacin requerida, es probable que se pida aprobacin antes de presentar el trabajo. Entonces, probablemente se producir algn tipo de flujo de trabajo de aprobacin, seguido de una presentacin del trabajo del usuario. Proceso
necesiten intervencin especializada para comprenderlos verdaderamente, es posible realizar un anlisis automtico, en particular, en el caso de un anlisis estadstico en el que los patrones son importantes y fciles de automatizar. Con conexin: El usuario debe poder realizar un anlisis bsico sin tener que solicitar todo el grupo de datos. Esto puede presentarse como herramientas con paradigmas de inteligencia comercial segmentacin y separacin, etc. Descarga: Por ltimo, el usuario debe poder recuperar los grupos de resultados para la manipulacin avanzada sin conexin, segn sea necesario. Escenario de autora: El escenario de autora trata los aspectos del proceso total para proporcionar capacidades para que un usuario final complete un trabajo de clculos. En trminos generales, el autor de un proceso debe poder desarrollar nuevas capacidades y procesos y publicarlos para el consumo de los usuarios finales. La Figura 3 muestra el escenario de autora para dos participantes: autores y usuarios avanzados. La diferencia entre estas funciones es que un autor probablemente desarrolle cdigo, mientras que un usuario avanzado posiblemente configure el cdigo existente. El escenario de autora puede describirse de la siguiente manera: Desarrollo:
diversas cosas. Probablemente traslade los grupos de datos a los nodos del clster y tal vez realice un grupo de procesamientos iniciales, como la generacin de medidas analticas para ser utilizadas en el procesamiento principal. Tambin puede inicializar estructuras de datos y evaluar todos los datos para su validacin antes de ejecutarlos. Proceso: Esta fase representa el procesamiento paralelo en s. Cada nodo ejecutar una porcin y puede ser necesario pasar resultados intermedios a otros nodos para que se complete el proceso total (trabajo de paso de mensajes). Otra opcin es que
elementos del proceso diferenciados que puedan utilizarse como parte del proceso total de una tarea de informtica. Un ejemplo podra ser una actividad genrica para llevar a cabo un FTP del conjunto de resultados. Algoritmos: El desarrollador puede crear los algoritmos reales para que se utilicen en el paso de clculos del proceso del usuario final.
10
definir flujos de trabajo de clculos especficos mediante la unin de actividades y algoritmos para crear un paso de cmputos total compuesto de pre y post procesamientos as como tambin de la tarea de cmputos en s.
Publicacin:
flujos de trabajo, el autor desear realizar un catlogo del desarrollo para que lo utilicen otros autores o usuarios finales. Configuracin: Es posible que se requiera la configuracin de algunas actividades o flujos de trabajo, como restriccin de acceso u otras normas que regulen el uso de la tarea desarrollada. Publicacin: Por ltimo, el autor debe presentar la tarea desarrollada cuando est lista para utilizar. Lo ideal sera que esto no requiera ningn esfuerzo de administracin informtica. Escenario de administracin. Finalmente, se necesita la administracin de la plataforma de HPC. En este caso, consideramos que las tareas principales para respaldar al usuario final comprenden el monitoreo y la contabilidad y excluyen otras tareas de administracin bsicas como configuracin del clster y otras actividades generales de infraestructura informtica. (Ver Figura 4) El escenario de administracin se puede describir de la siguiente manera: Publicacin:
Escenario de la solucin Despus de haber detallado varios escenarios generales que pueden
Figura 5: Microsoft Cluster Compute Server Edition satisface el paso del proceso.
Escenario de informtica
Acceso Inicio de sesin Solicitud Carga Proceso Preproceso Anlisis Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
11
sistema que va ms all de lo que habitualmente se esperara. Por ejemplo, necesito saber los principios bsicos de un control remoto para poder operar mi televisor, pero para mirar televisin, no necesito saber el voltaje requerido para activar su pantalla de LCD. Los expertos que han participado de una solucin individual pueden encontrar difcil liberarse de eso. Por ejemplo, si Alicia ha codificado un algoritmo para la solucin, puede encontrar que est muy involucrada en la operacin diaria de la solucin porque slo ella comprende el mejor modo de interactuar con el sistema para utilizar el algoritmo. Ella debera realmente dedicarse a crear algoritmos an mejores. El resultado despus de una o dos creaciones de mejoras no slo representa un alto costo en la operacin de la solucin, sino tambin un problema de riesgo ya que Alicia se ha vuelto un componente fundamental de la solucin. La solucin tambin puede ser un problema en lo que respecta a la administracin para los equipos fundamentales de informtica. Una solucin de HPC creada con gran destreza por expertos en dominio podra fcilmente ser anloga para las soluciones de hojas de clculo vinculadas del equipo de ventas que puede ser problemtico para cualquier desarrollo interno o para los equipos de soporte.
Costo
Tiempo reducido mediante la automatizacin
Publicar
Publicar
tiempo y gastos son posibles mediante el uso de interfaces intuitivas, validacin y otra lgica para garantizar la captura de informacin adecuada. Adems, los administradores o codificadores especializados pueden ya no ser necesarios en esta instancia del proceso. Publicar un trabajo de larga ejecucin. Tanto el tiempo como los gastos se pueden reducir debido a que la informacin es capturada El diagrama de la Figura 1 representa el proceso de alto nivel para la por el sistema y, por lo tanto, la publicacin del trabajo provisin y uso de una solucin de HPC. puede automatizarse completamente Figura 1: Cadena de valor original Costo de la informtica. El costo se reduce mediante la Cadena de valor original Ejecucin del flujo de trabajo (interactivo debido a regs de las especializacin de las funciones secuencias de comandos) Costo el monitoreo puede ocurrir desde Tiempo la perspectiva de un usuario de final y el costo total entre varios Crear flujo de trabajo Crear actividad Analizar trabajo trabajos puede reducirse Tiempo mediante el reconocimiento Tiempo mejorado de trabajos errneos o de Publicar Publicar espera fallas que pueden cancelarse antes de haber finalizado la Costo ejecucin. Este reconocimiento Ahorro neto = rea de la cadena original - rea de la cadena nueva mejorado es nuevamente proporcionado por el uso del monitoreo y mecanismos de feedback que se presentan a la Figura 2: Cadena de valor mejorada interfaz del usuario. Anlisis. El anlisis se puede Feedback anterior va visualizadores Cadena de valor nueva iniciar de un modo ms rpido si Costo reducido mediante la Simplificacin mediante especificacin del rol sistema consolidado la interfaz del usuario presenta Cost informacin durante la ejecucin Tiempo de del trabajo; puede estar Crear trabajo Analizar Crear flujo de algoritmo disponible algn anlisis Ejecucin del flujo de trabajo Tiempo trabajo automtico que reduce los costos Tiempo Ejecucin Ejec. iniciales antes de que se necesite del flujo de del de Costo reducido mediante la trabajo FT intervencin especializada. espera especificacin del rol
Ejecucin del flujo de trabajo
Publicar
12
Figura 6: Workflow Foundation puede brindar una capa de aplicacin completa que abarque la mayora de las reas en los pasos de Solicitud, Proceso y Anlisis.
Escenario de informtica
Solicitud Carga
Proceso Preproceso
Anlisis Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
instancias de un nico programa pero con una serie de parmetros diferentes, permitiendo varios resultados en el mismo perodo de tiempo como una tarea nica. Tarea de interfaz de paso de mensajes: El trabajo ms sofisticado sera el uso de una Interfaz de Paso de Mensajes (MPI) para paralelizar un algoritmo y dividir el trabajo del procesamiento entre varios procesadores que se coordinan para proporcionar aumentos de velocidad en procesamientos complejos y largos. Varios o todos estos tipos de trabajo se pueden encontrar dentro de un nico proceso de informtica. CCS debe poder ofrecer una plataforma slida para cualquiera de las tareas de pre- o postprocesamiento as como tambin la tarea principal de procesamiento. Lgica de aplicacin con Windows Workflow Foundation Ya que podemos considerar que el proceso informtico total es una instancia de un flujo de trabajo de mquinas y personas de larga duracin, podemos considerar a Windows Workflow Foundation (WF) como el punto de inicio para la construccin de una estructura y capa de aplicacin de la solucin de HPC. En realidad, HPC posee varios componentes que se pueden utilizar para proporcionar una capa de aplicacin completa para la solucin de HPC. Las reas particulares (pero no exhaustivas) que puede cubrir el WF se muestran en la Figura 6. WF forma una parte fundamental del marco de trabajo .NET 3.0 y ofrece un motor de flujo de trabajo completo que se puede alojar en varios entornos. La seccin de recursos de este artculo contiene varios vnculos para obtener ms informacin sobre el Windows Workflow Foundation. Algunas de las caractersticas principales del WF para considerar son las siguientes:
servidor muy eficaces (por ejemplo, Microsoft Office SharePoint Server 2007), estos productos poseen actividades bsicas para utilizar dentro del WF. Finalmente, las actividades se pueden construir en la medida que sean necesarias para crear una biblioteca individualizada y cumplir con un requisito especfico. Motor de reglas: WF posee un variado motor de reglas de encadenamiento progresivo que se puede utilizar para la toma de decisiones dentro de un flujo de trabajo, pero tambin se puede ejecutar fuera de las instancias del flujo de trabajo. Las actividades se disean para que funcionen con este motor de reglas. Diseador y realojamiento: WF tambin posee una superficie de diseo completa de arrastrar y soltar que se utiliza dentro de Visual Studio 2005 pero tambin puede ser realojada dentro de, por ejemplo, una aplicacin de formularios de Windows. Servicios en tiempo de ejecucin: El tiempo de ejecucin del WF puede contar con servicios que han sido incluidos antes de la ejecucin del flujo de trabajo para interceptar la ejecucin de un flujo de trabajo y desempear acciones como persistencia o seguimiento. Los servicios tambin se pueden construir en la medida que sean necesarios. Lenguaje de Marcado de Aplicaciones Extensible (XAML): Por ltimo, WF utiliza en gran medida el XAML para describir flujos de trabajo y conjuntos de reglas, lo que significa que la serializacin es trivial y que realmente es posible la generacin de administradores de reglas y superficies de diseo individualizadas.
Dadas estas caractersticas, podemos ahora ver el modo en el que WF ofrece capacidad a la arquitectura. Bibliotecas de actividades Las bibliotecas de actividades son los bloques de construccin necesarios para la solucin del HPC. Algunos ejemplos son los siguientes:
del WF puede administrar flujos de trabajo orientados al estado y secuenciales, por lo tanto, se pueden describir una gran variedad de procesos. Estos flujos de trabajo tambin pueden gestionar excepciones y reintentos. Bibliotecas de actividades: Los flujos de trabajo estn compuestos de actividades como toma de decisiones, ejecucin de bucles y ejecuciones en paralelo, as como tambin, actividades de cdigo arbitrario y varias de estas actividades estn listas para usar en el .NET 3.0. Adems, debido a que el WF se utiliza para productos de
personalizada que utilice la interfaz de programacin de la aplicacin CCS para comunicarse con el programador de tareas y crear o cancelar trabajos en el clster. Esta actividad personalizada puede entonces ser utilizada por cualquier flujo de trabajo que necesite comunicarse con el programador de tareas y proporcionar un nivel ms alto de abstraccin para los usuarios avanzados quienes pueden necesitar crear nuevos flujos de trabajo o corregir los existentes sin conocimiento detallado de programacin.
13
Arquitectura de Componentes
La arquitectura principal se parece a la conocida arquitectura de aplicacin de n-capas y, en lneas generales, ste es de hecho el caso. La organizacin de la funcionalidad es bastante lgica. La Figura 1 muestra los componentes necesarios para la arquitectura. Figura 1: Componentes Capa de aplicacin La capa de aplicacin est compuesta por el tiempo de ejecucin del WF alojado como un servicio NT. Esta capa se utiliza principalmente para comunicarse con el programador de tareas del clster, pero ofrece una variedad de funciones:
Ejecucin
MO SS 2007 WPF ASP NET
Formularios de Windows
Administracin
PowerShell Administrador de operaciones de Microsoft
Ejecucin
(PCT) FCW
Tiempo de ejecucin del flujo de trabajo Biblioteca de actividades Registro Persistencia (PCT) FCW (PCT) FCW
PCT
Formularios de Windows
y realizar movimientos de datos y otros pasos pre y post procesamiento. Motor de reglas y polticas para administrar el acceso a un clster y, potencialmente, proporcionar prioridades y capacidades de metaprogramacin y seguridad. Informacin de seguimiento para la ejecucin de trabajos brindando informacin documentada, segn sea necesario. Informacin de persistencia que permita escalar la solucin y proporcionar eficacia a los flujos de trabajo de larga duracin y, potencialmente, la capacidad de volver a ejecutar un flujo de trabajo desde un estado en particular. Servicio de datos El servicio de datos contiene bases de datos de soporte como almacenes persistentes y seguimiento para el tiempo de ejecucin del flujo de trabajo. En esta arquitectura, tambin es probable que exista un almacn que contenga resultados o agregados a resultados. Es posible que los archivos de entrada y salida de datos se traten como archivos para mover de un modo ms fcil los clsteres hacia los nodos de proceso respectivos. Finalmente, hay una base de datos que contiene un catlogo de los flujos de trabajo disponibles para su ejecucin. Servicio de cmputos El servicio de cmputos es el ms simple de la arquitectura y est compuesto de un clster de x nodos en una configuracin determinada. Comunicacin La comunicacin en todo el proceso de arquitectura se gestiona utilizando Windows Communication Foundation mediante un TCP (conexin remota) o un canal HTTP. Esto mantiene a la arquitectura escalable y desacoplada y ofrece beneficios para las interfaces de usuario diferentes, segn requisitos del usuario (autora, ejecucin, emisin de informes). Seguridad En una estructura distribuida orientada al servicio, que potencialmente pasa por varios dominios de seguridad, es fundamental la federacin de identidades para permitir el control de acceso a nivel del usuario y el inicio de sesin nico para todos los aspectos de la arquitectura de componentes. Las tecnologas que ofrecen estas capacidades son aquellas que estn basadas en certificados, federacin de directorio activo (junto con extensiones para integrarse con los sistemas Unix) y Windows CardSpace de Microsoft.
Servicio de datos
Servidor SQL Resultados DB Registro DB
(PCT) FCW
Servicio de cmputos
Programador de tareas C, C++, MPI
Interfaz de usuario La experiencia de la interfaz de usuario puede dividirse en tres partes. Cada una desempea una funcin diferente de la solucin general:
procesamiento puede proporcionarse mediante varias tecnologas. Algunos ejemplos podran ser Windows Forms, Windows Presentation Foundation, ASP.NET o Microsoft Office SharePoint Server. La eleccin de la tecnologa debe ser apropiada para las caractersticas de un entorno particular (por ejemplo, el uso de tecnologas de Web en las que se requiere amplia disponibilidad o WPF en el que se necesita una interaccin muy variada). La experiencia de autora del flujo de trabajo es proporcionada por Visual Studio 2005 que utiliza la superficie de diseo de autora del Windows Workflow Foundation (WF). El uso del modelo code beside (cdigo al lado) de los flujos de trabajo en desarrollo permite utilizar una nueva interfaz API de Control de Cdigo Fuente para enviar archivos XAML de WF hacia un depsito de bases de datos central, por ejemplo, para ejecutar en la interfaz de usuario. Para los administradores informticos, el Microsoft Operations Manager puede utilizarse para controlar el buen funcionamiento y el estado del clster de HPC, si bien para los usuarios finales de un sistema HPC, se pueden poner a disposicin observaciones ms comprensibles para el usuario mediante el uso de Windows PowerShell.
alto nivel que tratan archivos ejecutables especficos (en vez de arbitrarios). Actividades para los movimientos de datos en la red, posiblemente, utilizando WF para controlar los servicios de integracin del servidor SQL. Carga de datos y actividades FTP, para resultados del movimiento. Recuperacin en el caso de que ocurra alguna falla en el proceso. Actividades de notificacin para eventos durante el proceso. Actividades basadas en reglas para controlar la optimizacin automatizada del proceso o privilegios de acceso.
Los flujos de trabajo para escenarios informticos especficos se pueden juntar utilizando una combinacin de estas actividades genricas y alguna actividad especfica para posibilitar el escenario deseado. Las actividades del flujo de trabajo cumplen todas las reglas habituales de legado, por eso, vale la pena tener en cuenta que es posible confeccionar un entorno heterogneo para una interfaz general y luego seleccionarlo (en el momento del diseo o tiempo de ejecucin) para permitir la ejecucin de un determinado clster. Un ejemplo conveniente para esto sera crear una actividad que permita la ejecucin de un procesamiento MPI sobre una mquina local tal vez, utilizando dos procesadores para la evaluacin.
14
Figura 7: Con el uso de la capa de aplicacin basada en WF, Windows Presentation Foundation (izquierda) y Microsoft Office Sharepoint Server (derecha) ofrecen experiencias de usuario diversas.
seguimiento y un esquema de base de datos estndar para controlar las ocurrencias en un flujo de trabajo. Esto se puede ampliar en caso de ser necesario o reemplazar completamente con una implementacin personalizada. El servicio listo para usar, por lo general, es suficiente para proporcionar una auditora bien detallada de la ejecucin del flujo de trabajo. Servicio de persistencia. Utiliza un esquema de base de datos estndar para comprimir o expandir las instancias del flujo de trabajo, en la medida que lo necesite el tiempo de ejecucin, o segn lo especifique el host. La expansin de un flujo de trabajo en ejecucin sucede cuando ocurre un evento en ese flujo de trabajo, haciendo que el WF sea un controlador ideal para flujos de trabajo de larga duracin, como semanas, meses o grandes procesamientos. La persistencia tambin proporciona escalabilidad entre las mltiples aplicaciones de control y permite el uso de grupos de cambio para restaurar un flujo de trabajo a una posicin almacenada anteriormente y volver a ejecutarlo desde all. Potencialmente, esto posee beneficios significativos para procesamientos complejos de varias etapas y para volver a ejecutar procesamientos de investigacin cientfica en un determinado estado. Servicio de monitoreo del clster. Este servicio puede registrar
sistema o a tipos de recursos basndose en la identidad, o se podran agregar y eliminar pasos en un flujo de trabajo o servicios segn la identidad. Optimizacin. Se podra proporcionar cierta automatizacin para un proceso de negocio u optimizacin mediante el uso de reglas combinadas con inteligencia comercial u otros parmetros conocidos para finalizar o eliminar pasos en un flujo de trabajo, segn sea necesario. Metaprogramacin. CCS no posee en la actualidad un metaprogrmador, pero el WF podra utilizarse para designar la ejecucin de clsteres particulares segn los parmetros, como cantidad necesaria de procesadores o estado actual de los clsteres disponibles, o identidad del usuario. Por lo tanto, WF posee una flexibilidad y eficacia significativa. Tambin analizaremos ms adelante el modo en el que podemos utilizar las funciones del WF para ofrecer una experiencia de autora. Experiencia del usuario con Microsoft Office SharePoint Server Si utilizamos el WF para proporcionar la lgica de la aplicacin y el control del proceso significa que podemos utilizar cualquier tecnologa para almacenar la lgica de la aplicacin desde ASP.NET para Formularios de Windows hasta Windows Presentation Foundation (WPF). Las imgenes capturadas de la Figura 4 muestran el uso de
Solicitud Carga
Proceso Preproceso
Anlisis Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
15
Figura 9: El Administrador de Operaciones de Microsoft puede monitorear el buen funcionamiento del sistema del clster CCS
Implementacin genrica?
Si bien los aspectos de la arquitectura propuesta estn previstos para la reutilizacin, es poco probable que la arquitectura pueda ser muy genrica para simplemente ser reutilizada de escenario en escenario. Es ms probable que la arquitectura represente un enfoque shell o ball-and-socket: el desarrollo ser requerido en cada escenario pero con varios enfoques y componentes reutilizables. En siguiente Figura se muestra una proporcin especulativa (basada en la experiencia de desarrollo) para componentes genricos a especficos. Estas proporciones se podran explicar del siguiente modo: Interfaz de usuario 50-50. Los aspectos ms importantes de la interfaz de usuario controles de movimiento de archivos, controles sobre la ejecucin del trabajo y monitoreo con mucha probabilidad sean inmediatamente reutilizables y aplicables a varios escenarios. La especializacin ser necesaria, al igual que con la interfaz de usuario, para cualquier proceso determinado, en particular con escenarios tan diversos como los procesamientos HPC. Capa de aplicacin 80-20. La capa de aplicacin est compuesta de una serie de flujos de trabajos y actividades que se pueden volver a vincular y organizar para un proceso particular. Con cierto trabajo, es posible que varias de estas actividades y elementos lgicos puedan ser reutilizados con ciertos datos nuevos. Los ejemplos podran incluir actividades para el movimiento de archivos, integracin de CCS, poltica y metaprogramacin. Tambin, varias herramientas de autora podran ser vlidas para usuarios avanzados en cualquier escenario. Capa de HPC 10-90. Muy poco de la capa de HPC Implementacin estndar posee alguna reutilizacin ya que cada algoritmo Interfaz de ser nico. Sin embargo, usuario los procesos de 50% 50% instalacin y monitoreo son reutilizables y coinciden con los Aplicacin paradigmas existentes de 80% 20% Microsoft.
Administrador
Cuenta
WPF y Microsoft Office SharePoint Server (MOSS), utilizando respectivamente la misma capa de aplicacin basada en WF, aunque ofrecen experiencias de usuario muy diferentes. El uso de Microsoft Office SharePoint Server (MOSS) brinda un nivel de solucin que contempla reas en los pasos de Acceso, Solicitud y Anlisis (Figura 8). Los motivos son los siguientes: Colaboracin. La investigacin y otros usos tpicos de HPC giran en torno a actividades de colaboracin, y MOSS es extremadamente variado en funciones en lo que respecta a permitir la colaboracin en referencia con el concepto de sitios. Acceso. Los grupos de investigacin pueden estar separados geogrficamente, por lo tanto, una interfaz basada en la Web ayuda a garantizar que la plataforma est disponible para todos los usuarios. Se podra generar un valor comercial significativo si se proporciona a usuarios remotos acceso a una plataforma HPC. Extensibilidad. MOSS se puede ampliar de diversas formas, desde la bsqueda y catalogacin de informacin hasta la construccin de partes de Web que se inserten en la aplicacin principal. Esta extensibilidad tambin proporciona una plataforma de desarrollo y paradigma de usuario slidos y una estructura para toda la solucin. Flujo de trabajo. MOSS tambin es potenciado por WF, por lo tanto, la sinergia entre las dos tecnologas es muy clara. Una ventaja es que el tipo de habilidades que poseen los equipos que manejan flujos de trabajo HPC y que manejan otros flujos de trabajo comerciales es totalmente transferible. Para cubrir los niveles necesarios podemos aprovechar varias funciones de MOSS:
Una vez ms, las estructuras de datos exclusivas sern necesarias para cualquier procesamiento determinado, pero las bases de datos de facturacin, persistencia y seguimiento, por ejemplo, sern todas aplicables de escenario a escenario.
sesin nico de MOSS proporcionarn efectivamente funcionalidad para el acceso estndar. La inicializacin puede facilitarse extremadamente mediante la creacin de sitios individualizados que representen tipos de trabajos de informtica. Por lo tanto, un usuario puede generar un sitio que represente un proyecto o un trabajo y recibir la configuracin necesaria de las partes de Web para solicitar, ejecutar o analizar un trabajo de informtica. Adems, se pueden aprovechar las caractersticas de colaboracin como los wiki o controles de presencia. Solicitud y Ejecucin. Se podran disear formularios de Web especficos para permitir la insercin de parmetros y realizar solicitudes, pero, una mejor solucin, en lo que se refiere a capacidad y flexibilidad, podra ser utilizar InfoPath. InfoPath ofrece capacidades sofisticadas para formularios de Web y capacidades de autora bien desarrolladas. Debido a que utiliza XML para mantener la definicin del formulario y los datos para el formulario, tambin
puede aprovechar los servicios de Web para la presentacin, y el uso de servicios de Web permite que los flujos de trabajo activen aprobaciones a solicitudes de trabajo y ejecuciones de trabajo. WF en s mismo puede utilizarse para definir flujos de trabajo de aprobacin necesarios y est incorporado como parte de MOSS. Anlisis. MOSS tambin es capaz de alojar servicios de generacin de informes y el Business Scorecard Manager (pronto ser PerformancePoint) para la emisin de informes del estilo de un panel de informacin. Adems, los servicios de Excel se pueden acceder va MOSS, haciendo que sea una plataforma ideal para realizar el anlisis inicial.
16
Desarrollo del diseador. Por otro lado, debido a que las definiciones
de las reglas y el flujo de trabajo se pueden describir en XAML, se podra construir toda una superficie de diseo nueva para representar la construccin del flujo de trabajo. Una superficie de diseo nueva es una gran opcin para un dominio que posee un modo particular de diagramar procesos o en los que se requieren otras opciones de alojamiento, por ejemplo, utilizar Windows Presentation Foundation o las capacidades de Web de AJAX. La seccin de recursos contiene un vnculo a una implementacin de ASP.NET AJAX de la superficie de diseo.
completo puede realojarse dentro de una aplicacin de Formularios de Windows. Esta aplicacin podra contar con una serie de funciones simplificadas, especficas, para garantizar que un usuario avanzado pueda construir y configurar con facilidad plantillas para el flujo de trabajo. Tambin se puede utilizar para ofrecer cierta garanta de calidad adicional a las estructuras del flujo de trabajo
Desde la perspectiva del desarrollo, podemos consolidar eficazmente todos los desarrollos de plataforma en un entorno y especializar ciertos aspectos mediante el uso de XAML para la definicin de los flujos de trabajo. El uso de XAML tambin ofrece la posibilidad de publicar. Publicar En el caso de las actividades y algoritmos, el paradigma de publicacin es efectivamente la produccin de un software, ya que es necesario distribuir los binarios en consecuencia, aunque, debido al software muy especfico que se est generando, se podra construir un mecanismo de distribucin para recuperar las bibliotecas de un modo especfico, segn sea necesario. Tambin, puede valer la pena investigar la tecnologa ClickOnce de Microsoft para la distribucin de una aplicacin de autora de un usuario avanzado cliente pesado para automatizar las actualizaciones de la biblioteca. En el caso de la autora de flujos de trabajo, la publicacin podra ser tan simple como transmitir las definiciones XAML resultantes a una base de datos central y catalogar estas definiciones. El flujo de trabajo puede ser recuperado por un usuario final desde la misma base de datos o simplemente podra invocarse como el resultado de una seleccin sobre la interfaz de usuario y luego compilarse y ejecutarse, segn sea necesario. Como se describe en la prxima seccin, la implementacin de este concepto significa que nuevos flujos de trabajo podran potencialmente publicarse muy rpido ya que no se necesita liberar cdigo (por lo tanto, no existen requisitos administrativos o ciclos de produccin). Esta capacidad se podra ofrecer como parte de una aplicacin individualizada de usuario avanzado, o como un complemento de Visual Studio 2005. Compilacin del flujo de trabajo Los flujos de trabajo de WF, por lo general, se compilan dentro de conjuntos, y luego son procesados por el tiempo de ejecucin del flujo
Usuario avanzado
Flujos de trabajo
Produccin
Autor
Usuario avanzado
Usuario
17
18
Sntesis Las empresas de software informtico deben cumplir dos funciones construir y ejecutar software. Cada funcin requiere un conjunto de habilidades diferentes. La diferencia entre construir y ejecutar casi siempre se observa con claridad en el organigrama. En el mbito de la arquitectura, por un lado, hay arquitectos de aplicaciones que participan en el desarrollo de software (construir), y por el otro, arquitectos de infraestructura que participan en la operacin del software (ejecutar). Como arquitecto de aplicaciones, creo que ambos equipos deben aprender las mejores prcticas del otro. Una de las mejores prcticas que un equipo de infraestructura debe aprender del equipo de desarrollo de software es expresar las decisiones de arquitectura utilizando comandos de prueba.
Documentar la arquitectura es explcitamente comunicar, sin ambigedad, los conjuntos de decisiones de diseo irreversibles. Documentacin no ambigua La documentacin de las decisiones de arquitectura facilita la comunicacin entre los interesados. stas son las personas que poseen un inters legtimo en la solucin. Existen dos clases interesados con diferentes necesidades en lo que respecta a especificaciones de arquitectura. La primera clase de interesados son las personas que toman decisiones, quienes necesitan saber sobre la arquitectura para comprender las restricciones y limitaciones de la solucin. Ejemplos de estos interesados son gerentes, clientes y usuarios. La segunda clase de interesados es la de los implementadores, quienes deben saber sobre estas mismas decisiones para construir y ejecutar la solucin. Ejemplos de estos interesados son los desarrolladores, ingenieros de sistemas y administradores de sistemas. Una especificacin narrativa escrita como un documento es la documentacin perfecta para la primera clase de interesados. Para ellos, hasta una especificacin sin formalidad publicada como un PowerPoint de Microsoft es suficiente. Esto les proporciona una visin de alto nivel de la arquitectura casi sin ambigedad en lo que respecta a las restricciones y limitaciones de la solucin. Sin embargo, una especificacin narrativa no es la documentacin adecuada para la segunda clase de interesados. Esto no proporciona a los implementadores informacin concisa sobre las decisiones de diseo. Y, en caso de hacerlo en una especificacin formal muy abundante, este documento no ser de inters para quienes toman decisiones. La primera clase no est muy interesada en la estructura interna de los componentes de arquitectura fundamentales. Sin embargo, los implementadores s. En mi experiencia como arquitecto de aplicaciones, he descubierto que el modo ms fcil de comunicar toda la complejidad de una decisin de diseo irreversible no es confeccionar un documento narrativo sino confeccionar una prueba que explique el modo en el que validara una buena implementacin. Cuando slo se utilizan las palabras, es muy difcil para los arquitectos e implementadores comprenderse entre s con confianza. Siempre existe una diferencia en la forma en la que cada parte comprende el significado de una palabra especfica. A continuacin detallo un ejemplo simple para demostrar mi idea. Supongamos que escribo, en la especificacin de arquitectura, la siguiente decisin de diseo: Se recuperarn datos slo del da anterior en caso de que haya una avera en el disco o corrupcin de datos. Los usuarios debern volver a insertar los datos perdidos para el da en curso. Obviamente, los implementadores necesitan aclaraciones sobre mi objetivo para poder implementar mi especificacin correctamente. A continuacin, la misma decisin redactada para ellos:
Decisiones de arquitectura La disciplina de arquitectura de software est basada en la idea de reducir la complejidad mediante abstraccin y separacin de asuntos. El arquitecto es la persona responsable de identificar la estructura de los componentes fundamentales que por lo general se los considera difciles de cambiar, as como tambin de simplificar las relaciones entre esos componentes. El arquitecto reduce la complejidad dividiendo el espacio del problema en un conjunto de componentes e interfaces que sern cada vez ms difciles de cambiar en la medida que el proyecto se desarrolla. La nica forma de simplificar el software es estructurar todas las interacciones de los componentes principales mediante interfaces y aceptar el hecho de que estas interfaces ahora son casi imposibles de cambiar. Si se selecciona un componente de software, entonces se puede hacer fcil de cambiar. Sin embargo, el desafo es que es casi imposible hacer que todo sea fcil de cambiar sin incrementar el nivel de complejidad, como lo expres Ralph Johnson en el artculo que Martin Fowler escribi para IEEE Software: Hacer que algo sea fcil de cambiar hace que el sistema global sea un poco ms complejo y hacer que todo sea fcil de cambiar, hace que el sistema completo sea muy complejo. Establecer interacciones de componentes globales mediante interfaces es hacer que las decisiones de diseo sean irreversibles. Este conjunto de decisiones de diseo sobre la estructura fsica y lgica de un sistema, en caso de hacerlas de un modo incorrecto, pueden provocar que el proyecto sea cancelado. La clave del xito es proteger el sistema contra la inestabilidad. Los buenos arquitectos conocen el modo de identificar reas de cambio en requisitos existentes y la forma de protegerlas contra la irreversibilidad de la arquitectura.
19
Proteccin contara el cambio Los comandos de prueba que expresan las decisiones de arquitectura claves estn siempre relacionados con cosas que cambian. Las principales reas de cambio se pueden dividir en tres categoras: 1. Ejecucin: En esta categora, las variaciones sobre el monitoreo y las operaciones son la mayor inquietud de los arquitectos de infraestructura. Afectan todos los otros asuntos de ejecucin como presentacin, procesamiento, comunicaciones y administracin de estado: Presentacin: Interesados que interactan con el sistema. Cmo implementamos la interfaz de usuario? Necesitamos muchos puntos de entrada? Son importantes los factores de calidad como posibilidad de uso, composicin y simplicidad? Procesamiento: Instrucciones que cambian el estado del sistema. Cmo implementamos el procesamiento? Necesitamos soporte transaccional? Y concurrencia?Son importantes los factores de calidad como disponibilidad, escalabilidad, rendimiento y fiabilidad? Comunicacin: Distribucin de estado entre los nodos fsicos del sistema. Cmo interactuamos? En qu formato viajan los datos? Sobre qu medio se realiza la comunicacin? Son importantes los factores de calidad como la seguridad y la manejabilidad? Administracin de estado: Ubicacin, vigencia y forma de los datos. Necesitamos un estado transitorio o duradero? Cmo guardamos el estado? Son importantes los factores de calidad como disponibilidad, capacidad de recuperacin, integridad y extensibilidad?
Presentacin
Operacin y monitoreo
Comunicacin
Nodo de tiempo de ejecucin Operacin y monitoreo
Presentacin Administracin Procesamiento del estado
Operacin y monitoreo
Presentacin
La Figura 2 es un diagrama que muestra todos los orgenes potenciales de las variaciones del tiempo de ejecucin.
Operacin y monitoreo
20
2.
function test-connection { $pingtest = ping $args[0] -n 1 if ($pingtest -match TTL=) { write-host $true } else { write-host $false } } Usage: test-connection MyServer01.domain.com
A diferencia de un documento narrativo, un conjunto de comandos de prueba automatizados es un artefacto operativo. Siempre se mantiene actualizado y valida continuamente el cumplimiento del objetivo del arquitecto. Diseo con capacidad de pruebas La capacidad de pruebas significa contar con interfaces apropiadas y seguras para orientar la ejecucin y verificacin de los comandos de prueba. No se puede lograr la capacidad de prueba si se confeccionan pruebas despus del diseo y la implementacin. Construir pruebas durante el diseo es el nico enfoque posible para lograr la capacidad de prueba. Al abstraer la implementacin, si se confeccionan primero las pruebas se reduce en gran medida el vnculo entre los componentes. Las decisiones irreversibles de diseo ahora se pueden probar de un modo mucho ms exhaustivo que antes, dando como resultado una arquitectura de ms alta calidad que es tambin ms fcil de mantener. De este modo, los beneficios mismos comienzan a producir dividendos para el arquitecto, creando un ciclo ascendente perpetuo en apariencia para la calidad. El hecho de confeccionar pruebas durante la etapa de diseo brinda un doble beneficio: 1. 2. Valida el cumplimiento del objetivo del arquitecto. Lo hace de un modo explcito.
3.
El proceso de descubrimiento de decisiones de diseo irreversibles est compuesto de la revisin de todas estas reas susceptibles al cambio y la construccin de las pruebas apropiadas. Artefactos operativos En la actualidad, los comandos de prueba pueden ser manuales, automticos o una combinacin de ambos. La ventaja que posee la prueba automatizada sobre la manual es que es fcilmente repetible. Por lo tanto, se las prefiere cuando se realizan pruebas de regresin. Cuando se modifica el software, ya sea para realizar un cambio en la funcionalidad o para solucionar defectos, la prueba de regresin vuelve a ejecutar las pruebas finalizadas anteriormente. Esto garantiza que las modificaciones no hayan causado involuntariamente un descuido de las decisiones de diseo. Un comando de prueba automatizado es un programa breve escrito en un lenguaje de programacin. Los arquitectos de infraestructura no necesitan ser programadores para escribir una prueba automatizada. Los lenguajes de secuencias de comandos pueden realizar el trabajo eficazmente. Cuando se utiliza Windows como plataforma, PowerShell, el nuevo lenguaje de secuencia de comandos y shell de comando de Microsoft, es ideal para estos propsitos debido su soporte para las estructuras de control, manejo de excepciones y acceso a clases del sistema .NET. A continuacin se detallan algunos ejemplos de prueba para los que se podra utilizar PowerShell:
Las pruebas son un proceso de requisitos, no simplemente un proceso de validacin. Diseo con automatizacin La experiencia ha demostrado que durante el mantenimiento de software es muy comn la reaparicin de fallas. A veces, la solucin a un problema puede ser frgil, es decir, no respeta caractersticas que son primordiales para el xito de la arquitectura. Por lo tanto, se considera una buena prctica registrar una prueba y volverla a ejecutar regularmente despus de cambios posteriores en el programa. Si bien esto se puede realizar mediante una prueba manual, con frecuencia se realiza utilizando herramientas de prueba automatizadas. Estas herramientas intentan descubrir errores en la regresin. Estos errores ocurren siempre que la funcionalidad de un software que anteriormente funcionaba segn lo deseado, deja de funcionar o no funciona ms del mismo modo. Por lo general, los errores en la regresin ocurren como consecuencia involuntaria de cambios en el programa. La prueba de regresin es una parte integral de la metodologa de desarrollo de software gil, como eXtreme Programming. Esta metodologa promueve la automatizacin de pruebas para construir mejor software, ms rpido. Esto requiere que se escriba una prueba de la unidad automatizada, definiendo los requisitos del cdigo fuente,
Prueba de implementacin. Crea un comando que verifica que la produccin haya sido como se esperaba; verifica los procesos en ejecucin, servicios, metadatos de la base de datos, contenido de la base de datos, versiones de los archivos de aplicacin, contenidos del archivo de configuracin, etc. Prueba de infraestructura. Crea un comando que verifica el hardware, sistema operativo, servicios en ejecucin, procesos en ejecucin, etc.
Por ejemplo, a continuacin se muestra una breve funcin del PowerShell para probar la conectividad hacia un servidor:
21
set-psdebug -strict -trace 0 # Ensure that group App_Setup is defined in Windows Active Directory function TestActiveDirectoryGroup { $objGroup =[ADSI]LDAP://localhost:389/CN=App_Setup,OU=HR,dc=NA,dc=org1,dc=com AssertNotNull $objGroup App_Setup group is required to install application xxx. RaiseAssertions } # run the function library that contains the PowerShell Testing Functions # the functions are defined as global so you dont need to use dot sourcing if (!(Test-Path variable:_TESTLIB)) { ..\src\TestLib.ps1 } # run the function defined above that demonstrates the PowerShell Testing Functions TestActiveDirectoryGroup
antes de cada aspecto del cdigo mismo. Las pruebas de unidad se utilizan para usar otro cdigo fuente llamando directamente rutinas, pasando parmetros apropiados y luego, si se han incluido Assert statements, probando los valores producidos en comparacin con los valores esperados. Las estructuras de prueba de unidad, como xUnit, ayudan a automatizar la prueba en cualquier etapa del ciclo de desarrollo. La estructura xUnit se present como un concepto fundamental de eXtreme Programming en 1998. Introdujo un mecanismo eficaz que ayud a los desarrolladores a incorporar pruebas de unidad automatizadas, eficaces y estructuradas dentro sus actividades normales de desarrollo. Desde entonces, esta estructura ha evolucionado como el estndar de facto para las estructuras de prueba de unidad automatizadas. La estructura xUnit ejecuta todos los comandos de prueba en intervalos especficos e informa cualquier regresin. Estrategias comunes son ejecutar ese sistema despus de cada construccin exitosa (integracin continua), cada noche o una vez por semana. Esto facilita el proceso de prueba de unidad y prueba de regresin. Por lo general, es posible realizar la prueba sin el soporte de las estructuras de xUnit mediante la confeccin de cdigo de cliente que pruebe las unidades y utilice declaraciones, excepciones y mecanismos de salida anticipada para indicar la falla. Sin embargo, los arquitectos de infraestructura no necesitan confeccionar su propia estructura de prueba. Las conocidas estructuras de prueba de xUnit han sido desarrolladas para una gran variedad de lenguajes, incluido el lenguaje de secuencia de comandos comnmente utilizado por el administrador del sistema. Sobre la plataforma de Windows, PowerShell Scripts for Testing, una biblioteca de funciones que implementa el conocido xUnit-style asserts para el nuevo shell de comando y lenguaje de secuencia de comandos de Microsoft, puede descargarse gratis de CodePlex, un sitio de Web que aloja proyectos de cdigo abierto (Ver Recursos). En la Figura 3 se muestra un modelo de prueba automatizada con Powershell. Las pruebas automatizadas intentan descubrir, lo antes posible, descuidos de las decisiones de diseo que son primordiales para el xito de la arquitectura. Las pruebas automatizadas son:
Estructuradas Auto-documentadas Automticas y repetibles Basadas en datos conocidos Diseadas para probar acciones positivas y negativas Ideales para probar la implementacin entre diferentes mquinas Documentacin operativa de configuracin, implementacin y ejecucin.
Prueba orientada a los datos La automatizacin de la prueba, en especial en los niveles ms altos de prueba como las pruebas de arquitectura, puede parecer costosa. Debe existir un argumento econmico para respaldar el esfuerzo. El modelo econmico puede debilitarse si no se simplifica el proceso de confeccin de pruebas. La prueba orientada a los datos es un modo de disminuir los costos de la automatizacin de pruebas. Permite que el personal de pruebas se concentre en la provisin de ejemplos mediante de combinaciones de pruebas aportadas y resultados esperados. Uno disea la prueba mediante la creacin de una tabla que contiene todos los datos de la prueba (aportes y resultados esperados) y luego confecciona un programa que transforma una fila de la tabla en una llamada al servicio bajo prueba (SUT). Uno logra el ndice de alto rendimiento en virtud de no tener nunca que confeccionar el comando ms all de escribir el programa. La estructura proporciona el comando de forma implcita, y lo ejecuta. En la ltima versin de PowerShell Scripts for Testing, esta estructura de xUnit posibilita el uso de Excel como fuente de datos para respaldar la prueba orientada a datos. Existe una nueva funcin en DataLib.ps1 llamada start-test que toma como entrada un nombre de libro, un nombre de hoja de trabajo, un nombre de mbito y un conjunto de nombres de campos y ejecuta las pruebas que se describen en el mbito. Esto se realiza mediante la llamada a una funcin que posee el mismo nombre que el mbito. El uso del start-test se muestra en una prueba de rendimiento modelo en el blog complementario de PSExpect. La Figura 4 muestra una tabla de Excel y comando de prueba proporcionado por el servicio meteorolgico de Web.
22
Recursos Who needs an architect? Martin Fowler, IEEE Software Magazine, Volume 20, Issue 5 (Septiembre 2003) http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf CodePlex PowerShell Scripts for Testing http://www.codeplex.com/psexpect Companion blog for PSExpect: http://testfirst.spaces.live.com Conclusin La prueba automatizada combinada con la prueba de regresin no slo documenta las decisiones de arquitectura en el nivel adecuado para los implementadores sino que tambin valida continuamente el cumplimiento del objetivo del arquitecto. Los beneficios de confeccionar pruebas automatizadas son los siguientes:
Sobre el autor Mario Cardinal es consultor senior independiente especializado en arquitectura de aplicacin empresarial. Dedica la mayor parte de su tiempo a la construccin de aplicaciones.NET empresariales bien diseadas con procesos giles. Cuenta con ms de quince aos de experiencia en el diseo de sistemas de informacin a gran escala. Por segundo ao consecutivo ha recibido de Microsoft el Premio al Profesional ms Valioso (MVP) por sus cualidades como Arquitecto de Software. El nombramiento de MPV se otorga a verosmiles expertos en tecnologa quienes se encuentran entre los miembros ms destacados de la comunidad dispuestos a compartir sus experiencias para ayudar a otros individuos a desarrollar su potencial. Lidera el grupo de inters sobre arquitectura en el Montreal Visual Studio User Group y en la sede de la Asociacin Internacional de Arquitectos de Software (IASA, por sus siglas en ingls) en Montreal. Tambin es moderador tcnico de la seccin de Arquitectura para DevTeach Conference. Adems, es anfitrin de un programa de debate en Internet sobre el desarrollo de software con Microsoft .NET (Visual Studio Talk Show). Mario posee diplomas de Licenciatura en Ingeniera Informtica y Master de Administracin de Tecnologa otorgados por Ecole Polytechnique en Montreal, Canad. Tambin posee los ttulos de Certified ScrumMaster (CSM) y Microsoft Certified Solution Developer (MCSD.Net). (Puede contactar a Mario a travs de su sitio de Web, www.mariocardinal.com)
23
Para esta edicin, como parte de la serie Perfil del Architecture Journal tuvimos la oportunidad de ponernos al da con Don Ferguson, Asociado Tcnico de Microsoft. Le preguntamos a Don algunas cosas sobre su carrera y le pedimos consejos para las personas de desean ser arquitectos o para quienes hoy estn interesados en la arquitectura.
entre los productos. Un poco de mejora en varios lugares hace la diferencia. Un ejemplo real de esto es el trabajo que pude realizar sobre los estndares de los Servicios de Web. Creo que ayud a hacerlos un poco ms coherentes, fcil de componer y de comprender. AJ: Con tanta responsabilidad Cmo se mantiene informado sobre la tecnologa? DF: Buena pregunta! Lo primero que hago es trabajar realmente mucho. Cuando no estoy con los nios, a menudo, como, duermo, trabajo, hago karate y a veces, dormir es opcional. Segundo, realizo muchas investigaciones sobre aviones en las que no hay conferencias telefnicas ni interrupciones. Siempre que puedo, trato conscientemente de mantenerme alejado del correo electrnico. Tambin trato de no aprender la informacin tcnica nueva leyendo artculos o presentaciones. El mejor modo es descargar, instalar, utilizar y codificar. Con el paso de los aos, una de las cosas que aprend a hacer bien es sintetizar el modo en el que las cosas deben funcionar con slo un poco de informacin. En general, las personas son inteligentes. Con slo un poco de informacin, a menudo puedo averiguar lo que habran hecho las personas inteligentes. Cmo habran diseado esto las personas inteligentes? Con este proceso, si bien no conozco el tema con detalle, a menudo puedo deducir la forma en la que deberan funcionar las cosas y contribuir en el debate. En IBM, por lo general, sola tener cerca de 10-12 iniciativas sobre las cuales trabajaba en cualquier momento. Sola dedicar algunos meses para cada proyecto, multiplexando entre las iniciativas. Finalmente, cada iniciativa prosperaba o no tena xito. Se ve muchsimo de esto en los trabajos estndares en los que particip. Estaba incluido como colaborador para varios de los primeros artculos, pero con el tiempo desaparec. Muchas buenas personas comenzaron a liderar y realizar los trabajos tcnicos intensos, y yo, pas a hacer otras cosas. AJ: Qu consejo le dara a alguien que desea ser un arquitecto en la actualidad? DF: Creo esta respuesta se divide en cuatro partes. En primer lugar, en IBM tenamos un Consejo de Arquitectos en el Grupo de Software que me ayud a formar una red. Me llev un tiempo comprender la importancia de una red. Al ser de Nueva Inglaterra, sola ser un poco reservado e independiente. Nunca se debe subestimar la importancia de una red social. Uno no sabe lo que no conoce. Uno no sabe lo que alguien puede decir que tal vez puede presionar el botn de reinicio en nuestras mentes y nos puede hacer pensar de un modo diferente. Segundo, como arquitecto de software, nunca dejo de codificar. Escribo cdigo. No es que sea buen cdigo o particularmente profundo, pero creo cdigo. Mucho de esto es educativo y est relacionado con las actividades de mi tiempo libre. Por ejemplo, recientemente estuve trabajando en un portal que conecta a mi
AJ: Quin es y de dnde viene? DF: Soy Don Ferguson. Antes de unirme a Microsoft a principios de este ao, era Asociado de IBM. Hay aproximadamente 200.000 ingenieros en IBM y cerca de 50 Asociados, por lo tanto, fue un gran honor para m ser uno de ellos. Cuando me un a IBM Research, jams pens que algn da sera Asociado. Tal vez algn da podra ser lder de proyecto esto ya sera un gran logro. Hay muchsimas personas talentosas e inteligentes y yo slo esperaba poder ser uno de ellos. AJ: Qu se siente al llegar a ser un Asociado de IBM? DF: El da que llegu a ser Asociado fue uno de los mejores das de mi vida. Sin embargo, en verdad, me senta un poco avergonzado con la condecoracin. Senta que haba algunas personas que lo merecan ms que yo. Entonces, poco despus de la noticia llegu a ser defensor de esas personas y, con el paso de los prximos pocos aos, puede ayudar a tres o cuatro de ellos a que lleguen a ser Asociados. De alguna manera, estaba ms feliz cuando ellos recibieron la condecoracin que cuando yo recib la propia. Cuando le sucede a uno mismo, es muy confuso, pero cuando les sucede a los otros es una gran satisfaccin. AJ: Cmo era un da tpico para usted? DF: Yo era Arquitecto Principal del Grupo de Software en IBM. Haba cientos de productos y proyectos. Ser Arquitecto Principal significa que uno no puede disear cada componente. Existen realmente demasiados productos y productos para que esto sea una meta realista. Una gran parte de mi da sola dedicarla a realizar mucho trabajo de revisin. Revisaba varios diseos de productos o proyectos, concentrndome en algunas cosas de nivel ms alto. Haca especial hincapi sobre los nuevos productos. Por lo general, me enfocaba en la integracin de productos cruzados, temas comunes, etc. Por ejemplo, Posee el producto del portal la interfaz correcta para conectarse a este producto de seguridad? Soporta el producto los estndares correctos? Sola referirme en broma a esto como Pastorear gatos. En las diapositivas de las presentaciones que daba, con frecuencia sola utilizar el ttulo Encargado de pastorear gatos. Al principio, este trabajo era poco gratificante demasiado abstracto, muy superficial, muy general. Pero despus, tuve una epifana. Analizar las diversas partes ms como un todo, en vez de considerarlas por separado, tena un efecto significativo, en especial,
24
El Dr. Donald Ferguson es Asociado Tcnico de Microsoft en Plataformas y Estrategias en la Oficina del CTO. Don se enfoca en la funcin evolutiva as como tambin en la funcin revolucionaria de la informtica en los negocios. Microsoft espera que Don participe de una serie de proyectos con miras al futuro. Antes de unirse a Microsoft, Don fue Asociado de IBM y Arquitecto Principal para el Grupo de Software de IBM (SWG). Don brind liderazgo tcnico absoluto para WebSphere, Tivoli, DB2, Rational y Lotus. Tambin presidi el SWG Architecture Board (SWG AB). El SWG AB se centraba en la integracin de productos, iniciativas de producto cruzado y tecnologas emergentes. Algunas de las reas de inters general eran los servicios de Web, patrones, Web 2.0 y el desarrollo orientado a negocios. Don dirigi la arquitectura y estrategia de IBM para los servicios de Web y SOA y ha sido co-autor de varias de las especificaciones de servicios de Web iniciales. Tengo cinturn negro en Karate (Kenpo) y quiero mejorar en esto. Quiero tomar otra disciplina Jujitsu. Me gustara ensear Kenpo. La realizacin personal debe estar en primer lugar. En lo que respecta a la realizacin profesional y las cosas que me entusiasman, imagino un punto en el futuro en el que todos puedan programar. Esto no se trata tanto de utilizar Fortran y C#, sino, por el contrario, otra definicin de programar. Parece raro, pero djeme explicarle: Toda persona que ha terminado la escuela secundaria ha hecho algo de programacin incluso algo simple como un sitio de Web PHP. stas son habilidades bsicas en la actualidad simplemente del mismo modo que aprend a hacer una gran cuenta de dividir a mano (si bien podra debatir que los estudiantes de hoy en da ya no pueden hacer ms grandes cuentas de dividir a mano). Estos programadores ocasionales sern parte de los trabajadores. Tal vez necesitemos ampliar nuestra definicin de programar. Cul es la herramienta de programacin principal para los profesionales de negocios? PowerPoint. Si los profesionales de negocios pueden utilizar PowerPoint, yo me pregunto si podramos estimularlos para que utilicen otra herramienta para disear modelos de negocios. Ellos ya disean modelos de negocio, pero lo hacen utilizando documentos que se pasan a los programadores. Los programadores adivinan lo que significan los documentos y no suceden buenas cosas cuando los programadores adivinan. Me pregunto si podramos hacer algo ms inteligente. En las escuelas de negocios ensean una disciplina denominada Ingls estructurado y varias tcnicas de diagramacin. Tal vez esto podra formar la base para los servicios comerciales de programacin. Para m, la realizacin profesional sera analizar el modo en el que podemos cambiar la naturaleza fundamental de la Web. Web 2.0, las aplicaciones de Web hbridas y los alimentadores son interesantes, pero son procesos de uno o dos pasos. La Web de la actualidad es modelo push. Las personas escriben contenido que es transferido a las personas que lo leen. Los programadores confeccionan aplicaciones de Web que utilizan los usuarios finales. Las personas confeccionan aplicaciones de Web hbridas o secuencias de comandos para acceder al contenido transferido. Estas aplicaciones se ejecutan en la actualidad en una PC, pero creo que podran migrar dentro de Internet. Internet llega a ser un Internet programable y puede ejecutar las aplicaciones por m. La consigna es Internet es la computadora. Ya vemos esto en lugares emergentes con Google, Amazon, MSN, etc. Todos los que ahora poseen servicios que se pueden llamar. Junto con una gran variedad de habilidades de programacin, veo un acercamiento entre el entorno comercial y el personal. Esto es realmente lo que me interesa.
25
Sntesis Paquetes basados en estructuras extensibles. Estn por todos lados. Desde portales hasta comercio electrnico. Desde administracin de contenido hasta mensajera. Son eficaces? En varios casos, s, absolutamente. Pienso en varias aplicaciones exitosas que constru sobre la base de las estructuras que brindan estos productos. Incentivan la productividad, aumentan la calidad, mejoran las caractersticas y reduce en gran medida el tiempo de llegada al mercado. Por lo tanto, Por qu las soluciones de integracin no experimentan las mismas mejoras? Independientemente del modo en el que trate de formular una solucin de integracin con una estructura o herramienta determinada, parece que no avanza al mismo ritmo que experiment con mi solucin de portal o aplicacin de Web. Esto es lo que defino como Dilema de Integracin.
s. Esto es causa de mucha frustracin tanto para los equipos de desarrollo como para la administracin, al igual que la dedicacin del noventa por ciento, por lo general, no se aplica de ningn modo al problema de integracin real en cuestin. Esto se magnifica, como veremos en las prximas secciones, en la medida en que el problema de integracin en s es generalmente ms difcil que lo previsto, requiriendo mucho ms tiempo para resolverlo que lo que permite el diez por ciento restante. La integracin en estructuras como Microsoft Biztalk Server es como jugar al bowling con topes en la canaletas. Sus interfaces por lo general evitan que se daen demasiado sus soluciones, guindolo con interfaces de implementacin y un diseo rico en caractersticas. A diferencia de los desafos de seguridad e infraestructura, esta herramienta realmente ayudar a dirigir la solucin. Sin embargo, esta experiencia de integracin positiva constituye slo el diez por ciento del esfuerzo realizado. Resolver la Regla del 90/10 Sus equipos operativos y de infraestructura son sus nuevos mejores amigos:
Por naturaleza, la integracin en s y por s misma es un problema difcil de resolver. Examinaremos los factores que contribuyen para que puedan ser:
EL DESARROLLO DE INTEGRACIN, POR LO GENERAL, POSEE TOLERANCIA CERO: UNO REPITE HASTA LOGRAR LA PERFECCIN. LAS FASES Y LA FUNCIONALIDAD PARCIAL, CON FRECUENCIA, NO SON UNA OPCIN. POR LO TANTO, LA INTEGRACIN LLEGA A SER EL ORIGEN DE DEMORA DE VARIOS PROYECTOS Y EXCESOS DE PRESUPUESTO.
Haga que su entorno de desarrollo imite a su entorno de produccin:
servidores y paquetes utilizando el mismo modelo de seguridad que el de produccin (o lo ms parecido posible). Nunca desarrolle o ejecute sus soluciones como administrador. Cuando deba hacer un cambio al entorno durante el desarrollo, analice el cambio con su equipo operativo/de infraestructura y documente la modificacin en su documentacin de utilizacin.
26
Sistema distribuido B
Por ejemplo, el Sistema B podra ser un sistema distribuido que accede a informacin almacenada en el Sistema A, un sistema legado (Figura 1). El mapeo directo de informacin desde A hacia B requiere conocimiento detallado de A y de B, pero debido a que el conocimiento del dominio de los dos sistemas, por lo general, est disponible dentro de la compaa, existen menos conjeturas sobre qu elementos y campos de datos en A se relacionan con B. Problemas de A para C: Mltiples casas, mltiples sistemas Un problema de A para C describe contextos en los que el socio comercial A desea comunicarse con el socio comercial C, pero ambos
Mapeo en el pozo de la desesperacin Varias soluciones de integracin en s mismas poseen un crecimiento constante que nunca se planea pero que aumenta la desesperacin a partir de los excesos de tiempo en la administracin del presupuesto. Esto se conoce mapeo en el pozo de la desesperacin. Una vez que se han resuelto todos los problemas de entornos operativos, infraestructura y seguridad al punto en el que los datos en s se mueves desde el punto A hacia el punto B (o C), las interpretaciones de los cientos de miles de campos desde un esquema al prximo se vuelven el punto central principal. Muy frecuentemente, los datos requeridos por un punto no son fciles de conseguir en otro, o el significado previsto para un campo se utiliza para algo completamente diferente. Los peores problemas imprevistos, por lo general, aparecen en la fase del mapeo.
Sistema legado A
Sistema distribuido C
VAN Formato cannico B Formato estndar de la industria (ANSI, XCBL, HIPAA, HL7, etc.)
27
Tabla 1: Formato de los datos de identidad Primer nombre Inicial del segundo nombre Apellido Char* Char 1 Char*
comercial A simplemente la coloca como parte del primer nombre. La Tabla 2 representa la forma en la que el socio comercial A puede almacenar los datos. Esto ya no es tan simple, verdad? El socio comercial A debe analizar el campo Primer Nombre para determinar si la inicial del segundo nombre existe. El algoritmo de anlisis debe distinguir entre un primer nombre de dos palabras, Tory Ann, y una inicial real del segundo nombre, Mary A. Un anlisis incorrecto puede dar como resultado la confusin entre Mary A. Anderson con 2 aos de servicio y Mary Anderson con 10 ms aos de servicio. Una mala eleccin del campo para almacenar aos de datos de servicio (probablemente, una decisin tomada muchos aos antes de tener la intencin de compartir estos datos) simplemente duplica o triplica el tiempo de mapeo desde el esquema del socio comercial A hacia el esquema del socio comercial B. Mapeo del mundo real Cuando los proveedores de software de integracin demuestran el mapeo, por lo general, tiene una presentacin parecida a la de la Figura 4. El mapeo del mundo real es un problema muy diferente que comprende:
Cientos de miles de campos. Diferencias jerrquicas en los formatos de los campos que pueden
requerir algoritmos de ejecucin de bucles complicados para colocar los datos de forma adecuada. Grandes flujos de datos que requieren bucles complicados para dividir los mensajes. Las herramientas de integracin extravagantes a veces llevan a los desarrolladores a aplicar una solucin grfica para un problema que es mucho ms complicado para esta herramienta. Extraer datos desde mltiples fuentes internas (a veces, de un modo asncrono).
Tabla 2: Tabla de datos almacenada por el socio comercial A Nombre John Tory Ann Mary A Mary Inicial del segundo nombre 5 8 2 A Apellido Smith Wilson Anderson Anderson
investigue completamente las fuentes para identificar aquellos problemas ocultos imprevistos. Establezca un contrato para pruebas/depuracin con los socios comerciales especificando la frecuencia de pruebas y proporcione un criterio de aceptacin con rutas de escalacin adecuadas. En especial, cuando trabaja con socios comerciales externos, es imprescindible establecer y definir contratos de pruebas con rutas de escalacin adecuadas para que cuando ocurran interrupciones en procedimientos de prueba necesarios (que con toda seguridad ocurrirn), todas las personas afectadas sean notificadas lo antes posible para comunicar de forma adecuada las demoras potenciales en la entrega de la solucin. Utilice las mejores prcticas de Desarrollo guiado por pruebas para poder defender y probar completamente su lado de la integracin y reducir/prevenir el tiempo fuera de servicio para otros miembros del equipo. Para mapeos complicados, considere el uso de cdigo y secuencias de comandos sobre paradigmas de interfaz de usuario extravagantes (ms fciles de leer y depurar). Divida los mensajes antes de realizar el mapeo. Utilice cdigo administrado en vez de mapeos, cuando sea necesario (por ejemplo, para jerarquas complicadas y un mejor desempeo). Esto se logra con el uso de clases serializadas.
28
El rendimiento importa El rendimiento siempre es importante, en especial cuando se dice que no importa. Solucionar asuntos de rendimiento (BizTalk) Reduzca las entradas y salidas del Buzn de Mensajes. Disminuya la dependencia sobre la orquestacin lo que puede causar que su solucin se ejecute de un modo mucho ms lento. El desarrollo orientado al rendimiento implica mtricas de medicin durante todas las etapas del desarrollo para identificar los obstculos lo antes posible. Utilice instrucciones de optimizacin del rendimiento del producto se han publicado algunas instrucciones excelentes sobre BizTalk (Ver Recursos). Listo para usar no est optimizada para su solucin. Existen varias posibilidades para adaptar el rendimiento, por lo tanto es importante comprender todos los componentes de la solucin y optimizarlos de forma adecuada para lograr una operacin ptima. Las clases serializadas y el cdigo administrado pueden ser ms rpidos que los mensajes y los mapas, considere su uso para componentes fundamentales de rendimiento en la solucin. Considere sus herramientas como un grupo de Legos Una vez que un equipo adopta un conjunto de herramientas o paquete para ayudar en la implementacin de sus soluciones de integracin, un error comn es utilizar cada herramienta del conjunto para cada solucin de integracin. En la mayora de los casos, no es necesario utilizar todas las herramientas. De hecho, utilizar todas las herramientas puede afectar negativamente el rendimiento de la solucin general. Una mejor prctica es considerar su conjunto de herramientas como un grupo de Legos. Los Legos vienen en varios tamaos y colores. No es necesario utilizar todos los tamaos y todos los colores en las creaciones. A veces puede querer utilizar slo Legos blancos y verdes, mientras que otras veces puede centrarse en el azul y el rojo. Todo depende de resultado que se desee.
Conclusiones Piense que sus herramientas de integracin son una Ferrari (con cambios manuales) en su garaje. Al menos que slo pueda manejar una con cambios automticos, esta Ferrari ser el vehculo ms lento y frustrante que jams haya conocido. Sin embargo, una vez que logre dominar los cambios manuales, demostrar por s mismo que verdaderamente es un auto de carreras de alto rendimiento, calibrado con precisin. Las herramientas adecuadas junto con las prcticas y habilidades correctas pueden con toda seguridad resolver el dilema de la integracin. Recursos Eddie Churchill, BizTalks sexy new XSLT Mapper http://channel9.msdn.com/Showpost.aspx?postid=126990 BizTalk guidelines http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ bts_2004wp/html/87f447a2-09ce-4a30-9f94-584684310051.asp
Sobre el autor Jim Kilt dedic su experiencia y capacidad a resolver problemas con el objeto de ayudar a los clientes a disear las mejores soluciones posibles para que tengan xito en sus necesidades relacionadas con el diseo de sistemas, colaboracin, datos, integracin e inteligencia comercial. Es arquitecto de soluciones con credencial MCA de Microsoft y ha recibido varios premios de la industria, incluyendo 1993 Industry Week Technology of the Year Award y Burroughs Achievement Award for Excellence. Tambin es Microsoft Most Valuabe Professional Visual Developer Solutions Architect, miembro del Microsoft MCA Board of Directors, la Central Michigan University Collage of Science and Technology Alumni Advisory Board y es Central Michigan University Distinguished Alumni.
29
Taxonoma de Servicios Las economas orientadas a servicios prosperan mediante la promocin de la composicin. En SOA, se pueden crear nuevas soluciones mediante la composicin de nueva funcionalidad y lgica de negocios de aplicacin especfica, con capacidades comerciales existentes, recombinantes. En la actualidad, estas capacidades comerciales se construyen en su mayora de un modo interno o se compran para implementarlas en el sitio como una solucin empaquetada. Sin analizamos el futuro cercano, observamos un crecimiento constante en el modelo de Software como Servicio (SaaS) como una opcin para brindar a las organizaciones la posibilidad de contratar soluciones componentizadas y capacidades comerciales, enriqueciendo de este modo el conjunto de componentes que pueden ser incluidos en las aplicaciones compuestas de la organizacin. Una ontologa es un modelo de datos que representa un conjunto de conceptos dentro de un dominio y las relaciones entre esos conceptos. Una taxonoma es una clasificacin de las cosas as como tambin de los principios subyacentes de esa clasificacin. Una taxonoma jerrquica es una estructura en forma de rbol de las clasificaciones de un grupo de objetos determinados. Este artculo define las categoras de servicios en SOA, las relaciones entre esas categoras y los principios que subyacen la clasificacin de diferentes tipos de servicio dentro de distintas categoras. Adems de definir, clasificar y proporcionar los principios de clasificacin, trata la arquitectura de software y los aspectos relacionados con la empresa relevantes para la construccin y administracin de aplicaciones compuestas en SOA. Si analizamos la composicin desde un punto de vista de arquitectura de software, una ontologa y taxonoma comn nos permite identificar las caractersticas comunes de los servicios que constituyen una categora particular. Estas caractersticas afectan la arquitectura y el diseo de soluciones basadas en SOA desde el nivel de servicio individual hasta la aplicacin compuesta completa. La categorizacin soporta la composicin mediante la aclaracin de roles de los distintos componentes, ayudando de este modo a analizar las relaciones entre los componentes. La categorizacin tambin contribuye con la deteccin de servicios (por ejemplo, bsqueda de
30
31
organizacin que se autenticaron utilizando una identidad federada), tasa de error que impacta el negocio (cantidad de rdenes de compra o transformaciones al formato del mensaje que fallaron debido a mensajes entrantes mal formateados), etc. Como es el caso del los Servicios de Comunicacin, estas prestaciones, por lo general, son caractersticas genricas del Servicio de Utilidad y deben ser configuradas y consumidas por la solucin particular en la que estn siendo utilizadas. La Tabla 2 resume las caractersticas de los Servicios de Utilidad. Servicios de Aplicacin Los Servicios de Aplicacin son servicios que participan en la implementacin de un proceso de negocios. Proporcionan un valor comercial explcito y existen sobre una escala que comienza en un extremo con servicios genricos que se utilizan en cualquier aplicacin compuesta de la organizacin y finaliza en el otro extremo con servicios especializados que son parte de una nica aplicacin compuesta, y en el medio, posee servicios que pueden ser utilizados por dos o ms aplicaciones. Servicios de Entidad Los Servicios de Entidad descubren y manifiestan las entidades de negocio en el sistema. Pueden considerarse como componentes centrados en datos (nombres) del proceso de negocio: empleado, cliente, orden de venta, etc. Los ejemplos de Servicios de Entidad incluyen un servicio al cliente que administra la informacin del cliente o un servicio de rdenes que administra los pedidos del cliente. Los Servicios de Entidad abstraen almacenes de datos (como SQL Server o Active Directory) y exponen la informacin almacenada en el sistema en uno o ms almacenes de datos mediante una interfaz de servicio. Por lo tanto, se puede decir que los Servicios de Entidad administran el estado persistente del sistema. En algunos casos, la informacin que administran trasciende un sistema especfico y es utilizada en varios, o incluso todos, los sistemas de la organizacin. Es muy comn que los Servicios de Entidad soporten una interfaz CRUD (crear, leer, actualizar y eliminar) en el nivel de la entidad, e incorporan operaciones adicionales especficas de dominio necesarias para tratar dominios problemticos y soportar los casos de uso y caractersticas de la aplicacin. Un ejemplo de una operacin especfica de dominio es un servicio al cliente que expone un mtodo llamado FindCustomerByLocation que puede localizar el ID del cliente si se proporciona la direccin del cliente. La informacin que administran los Servicios de Entidad, por lo general, existe por un perodo de tiempo que es mayor al de cualquier proceso de negocio nico. La informacin que exponen los Servicios de Entidad es normalmente estructurada, a diferencia de los almacenes de datos jerrquicos o relacionales que son ofrecidos por el servicio. Por ejemplo, un servicio puede agregar la informacin almacenada en varias tablas de bases de datos o incluso varias bases de datos
Servicios de Utilidad Los Servicios de Utilidad proporcionan servicios genricos, de aplicacin agnstica que tratan aspectos que no estn relacionados con la transmisin de mensajes de la aplicacin. Al igual que los Servicios de Comunicacin, la funcionalidad que ofrecen es parte de la infraestructura base de un SOA y no est relacionada con ningn proceso de negocio o lgica de la aplicacin especfica. Por ejemplo, un servicio de deteccin puede ser utilizado por componentes en una aplicacin compuesta de estructura flexible para detectar otros componentes de la aplicacin basados en algn criterio particular (por ejemplo, un servicio que se implementa dentro de un entorno de preproduccin puede buscar otro servicio que implemente una cierta interfaz necesaria para el primer servicio y que tambin se implementa en el entorno de preproduccin). Los ejemplos de Servicios de Utilidad incluyen Servicios de idEntity y seguridad (por ejemplo, un Servicio de Identidad Federada o un Servicio de Credenciales de Seguridad), servicios de deteccin (como un servidor UDDI) y servicios de transformacin de mensajes. Al igual que los Servicios de Comunicacin, los Servicios de Utilidad tambin pueden ser instruidos o configurados por una aplicacin particular respecto del modo de realizar una operacin en su representacin. Por ejemplo, un servicio de transformacin de mensajes puede transformar mensajes desde un esquema de mensajes hacia otro basndose en un mapeo de trasformacin que proporciona la aplicacin utilizando el servicio de transformacin de mensajes. Si bien los Servicios de Utilidad no contienen ningn estado de la aplicacin, el estado de un Servicio de Utilidad puede estar afectado por los cambios de estado del sistema. Por ejemplo, un usuario nuevo que se agrega a la aplicacin puede requerir una actualizacin de las opciones de credencial en el Servicio de Credenciales de Seguridad. A diferencia de los Servicios de Comunicacin, los Servicio de Aplicacin interactan directamente con los Servicios de Utilidad que procesan y, si es necesario, responden los mensajes que los Servicios de Aplicacin les enviaron. Los usuarios de Servicios de Utilidad pueden requerir la configuracin de un permiso para utilizar el servicio, ya sea en el mbito de la aplicacin, del usuario o de la aplicacin-usuario. Por ejemplo, un servicio de deteccin tal vez slo trabaje con usuarios de dominio autenticados (usuarios que poseen credenciales vlidas emitidas por un controlador de dominio de Windows). Al igual que los Servicios de Comunicacin, los Servicios de Utilidad pueden brindar prestaciones en el mbito de la aplicacin para el monitoreo, diagnstico, BAM y dems. Esto puede incluir informacin estadstica sobre patrones de uso (cantidad de usuarios de otra
Administracin del estado Transacciones Manejo de errores Seguridad Gestin/Gobierno Modo de construccin
32
33
34
Versionado en SOA
Por Boris Lublinsky
Sntesis La Arquitectura Orientada al Servicio (SOA) est tomando un primer plano en la arquitectura empresarial. SOA hace posible el desarrollo paralelo en varios equipos distintos, cada uno con su propio programa de mantenimiento y produccin. En este artculo analizar los enfoques para el control de versiones de servicios que permiten desarrollar implementaciones de servicios sin afectar a los consumidores existentes, logrando que las implementaciones de SOA posean una estructura ms flexible. La idea bsica del versionado de servicios es muy simple, pero su implementacin requiere un control estricto. Expondr unidades de versionado: enfoques de acceso/implementacin de versin, consideraciones sobre el ciclo de vida de la versin del servicio, creacin de una nueva versin y cambios en el servicio. La creacin de versiones basadas en el mtodo que se propone aqu permite minimizar el impacto del versionado y reduce la cantidad de cdigo implementado. La mensajera semntica para las definiciones de interfaz del servicio permite que la implementacin del servicio sea ms flexible para el cambio.
Si hay algo constante en las implementaciones informticas, es el cambio. Las condiciones comerciales cambian, por consiguiente, requieren que las implementaciones informticas cambien. Las nuevas tcnicas y patrones permiten una mejor implementacin de las cualidades del servicio, como sistema de fallas y balanceo de carga, seguridad y dems. La informtica en s misma cambia continuamente con la presentacin de nuevos sistemas operativos, lenguajes de programacin y servidores de aplicacin, por ejemplo, que simplifican la creacin y mantenimiento de nuevas soluciones. De hecho, un estmulo en la implementacin de una solucin de informtica es la capacidad de hacer frente a estos cambios inevitables. En la era de aplicaciones monolticas, los cambios se trataban sobre la base de aplicacin-por-aplicacin. La implementacin del cambio, ya sea para un nuevo negocio o infraestructura por ejemplo, la incorporacin de un requisito o poltica de seguridad, o trasladar una aplicacin a una nueva plataforma de software se realizaba para una aplicacin completa, consumiendo importantes cantidades de tiempo y dinero hasta su finalizacin. Por otro lado, debido a que cada aplicacin era desarrollada por un nico equipo e independiente, este enfoque no permita los cambios. En la medida que se presentaban nuevas versiones de una aplicacin, la versin anterior quedaba en desuso y poda eliminarse. Uno de los beneficios principales del estilo de arquitectura orientada a servicios es la capacidad de tratar los cambios de un modo eficaz. SOA est basada en la descomposicin de recursos informticos de la empresa y la separacin de artefactos informticos
estables (servicios) desde artefactos modificables (procesos de negocio) que organizan los servicios hasta soluciones informticas (procesos). Como consecuencia, por lo general, es posible cumplir con los cambios de requisitos comerciales, ya sea mediante cambios en los procesos existentes o la creacin de nuevos procesos de negocio empresariales basados en los servicios existentes. Este enfoque permite un mejor soporte (ms rpido y econmico) de los cambios requeridos a travs de la (re)composicin de una solucin basada en los servicios empresariales reutilizables. Los servicios empresariales ser convierten en recursos, que pueden ser compartidos por mltiples soluciones empresariales, permitiendo el desarrollo autnomo paralelo masivo a varios equipos diferentes, cada uno con su propio programa de mantenimiento y produccin. Debido a que cada servicio, en este caso, es utilizado de forma simultnea en varias soluciones empresariales, un cambio en un servicio empresarial puede tener un impacto significativo sobre varias implementaciones existentes y en consecuencia, puede requerir cambios en cada una de ellas. Esto no slo es extremadamente costoso (requiere una gran coordinacin entre los equipos de desarrollo y las pruebas para garantizar que ninguno de los mltiples consumidores del servicio sea afectado), sino que tambin va en contra de uno de los principios fundamentales de SOA: los servicios son autnomos. La autonoma es el principio fundamental de la orientacin al servicio. Los servicios se deben implementar y modificar/mantener sin tener en cuenta los otros servicios ni los sistemas que los utilizan.
LA AUTONOMA ES EL PRINCIPIO FUNDAMENTAL DE LA ORIENTACIN AL SERVICIO. LOS SERVICIOS SE DEBEN IMPLEMENTAR Y MODIFICAR/MANTENER SIN TENER EN CUENTA LOS OTROS SERVICIOS NI LOS SISTEMAS QUE LOS UTILIZAN..
El problema de trabajar con componentes compartidos que pueden cambiar, no es nuevo. Por ejemplo, el sistema operativo de Windows y las aplicaciones basadas en Windows dependen de los componentes COM/ActiveX compartibles. En el caso de COM, se considera que los componentes son inalterables y cualquier cambio funcional requiere la introduccin de un nuevo componente con un Identificador Global nico (GUID). Este enfoque permite la coexistencia simultnea de varios componentes/versiones. En este artculo, analizar los enfoques para el control de versiones de servicios que permiten desarrollar implementaciones de servicios sin afectar a los consumidores existentes. Introduccin al versionado de servicios Uno de los enfoques ms conocidos para tratar los cambios es el versionado. El versionado implica la existencia simultanea de
36
Versionado en SOA
Figura 1: Coexistencia de versiones servicios mltiples profesionales proponen el versionado de servicios (incluyendo todas sus operaciones) como un todo. Si bien este enfoque se alinea bien con las prcticas de desarrollo basado en componentes (DBC) y orientado al objeto (OO) de la actualidad, parece que no siempre es apropiado para el caso de servicios agrupados. (Para una comparacin adicional de SOA y OO, ver Recursos Defining SOA as an Architectural Style). Cuando las personas hablan del versionado en sus conversaciones diarias, por lo general, hablan de cambios y versionado de los mtodos, no de un servicio en s mismo. Por ejemplo, consideremos un servicio de cuentas que implementa tres operaciones: retiro de dinero, depsitos y transferencias. Normalmente, la conversacin gira en torno a los cambios de la operaciones individuales (Ej.: retiro de dinero) no del servicio de cuentas en s mismo. Por lo tanto, otra opcin es definir las operaciones del servicio individual (mtodos) como una unidad de versionado. Independientemente, las operaciones del servicio de versionado poseen los siguientes beneficios:
invoca
invoca
invoca
invoca
invoca
Consumidor del servicio
Cambio
Consumidor del servicio
invoca
mltiples (diferentes) implementaciones de la misma cosa, donde cada implementacin es distinguible y se puede tratar de un modo individual. En el caso de SOA, el versionado de servicios iguala a la coexistencia mltiples versiones del mismo servicio que permite que cada consumidor utilice la versin que se les dise y prob (Ver Figura 1). En este caso, se crea una nueva versin de un servicio basada en los requisitos de uno o ms consumidores, quienes pueden comenzar a usar esta versin inmediatamente. No es necesario que
EL VERSIONADO DE SERVICIOS BASADO EN EL MTODO BRINDA UNA FLEXIBILIDAD OPTIMIZADA Y UNA MEJOR ALINEACIN DE LAS VERSIONES DEL SERVICIO CON LAS PRCTICAS DE VERSIONADO HABITUALES DE LOS LENGUAJES DE PROGRAMACIN.
otros consumidores de este servicio comiencen a utilizar la ltima versin inmediatamente, sino que pueden continuar utilizando las versiones del servicio que se les dise y prob. Pueden comenzar a utilizar la ltima versin del servicio basados en su propio programa de desarrollo y evaluacin. Las mltiples versiones coexistentes del mismo servicio en el sistema permiten el ciclo de vida independiente de los servicios y sus consumidores y minimizan el impacto total de la incorporacin de cambios. Si bien la necesidad de este mecanismo de versionado puede ser obvia para cualquier persona que siempre ha trabajado con servicios, este tema an no se ha incorporado en la corriente principal de implementaciones y publicaciones de SOA. La idea bsica del versionado de servicios es muy simple y clara, pero su implementacin requiere la definicin de lo siguiente:
adicionales (versiones del mtodo), algunos de los cuales pueden ser desaprobados con el paso del tiempo, pero el servicio en s mismo, su nombre y clasificacin, nunca cambia. Este esquema se parece a los enfoques de versionado de los lenguajes de programacin conocidos, como Java o C#, en los que los mtodos sobre las clases se agregan y se desaprueban con mucha frecuencia mientras que las clases existentes que se utilizan mucho, rara vez cambian. Minimiza el impacto de cambios en el servicio sobre los consumidores. El cambio slo afecta a los consumidores que utilizan un mtodo en particular en vez de a todos los consumidores del servicio. Reduce la cantidad total de cdigo implementado. Slo los mtodos que poseen una nueva versin se vuelven a implementar en el proceso de introduccin de la nueva versin. Los cdigos que implementan mtodos que no han cambiado, permanecen sin cambios. Tambin posee las siguientes desventajas:
independiente con su propia direccin del servicio. (Si bien este enfoque de implementacin no es convencional en la actualidad, posee algunas ventajas, como brindar diferentes acuerdos de nivel de servicio (SLAs) para diferentes mtodos dentro del mismo servicio). Requiere un esquema diferente de direccionamiento para invocar el servicio, un poco ms complejo. En este caso, el consumidor del servicio, en vez de especificar el servicio que desea invocar, debe especificar explcitamente el servicio, la operacin y la versin de la operacin que necesita. A pesar de los requisitos para el enrutamiento/invocacin del servicio no estndar, el versionado de servicios basado en el mtodo brinda una flexibilidad optimizada y una mejor alineacin de las versiones del servicio con las prcticas de versionado habituales de los lenguajes de programacin. Tambin minimiza la cantidad de cdigo que se debe volver a implementar para soportar la nueva versin. Estas caractersticas hacen que la creacin de versiones basadas en el mtodo sea un enfoque de versionado de servicios eficaz. Definiciones de versin Definir lo que constituye una nueva versin del servicio (mtodo) requiere el anlisis de los cambios posibles, su impacto potencial sobre la ejecucin de los consumidores as como tambin la identificacin de
Unidades de versionado Cambios en el servicio, creacin de una nueva versin Consideraciones del ciclo de vida de la versin del servicio Enfoques de acceso/implementacin de la versin
Unidades de versionado Existen dos opciones principales para definir las unidades de versionado, cada una con sus propias ventajas y desventajas. Segn las prcticas actuales de Servicios de Web (la tecnologa de implementacin de SOA ms conocida en la actualidad), varios
37
Versionado en SOA
aquellos que afectarn. Cualquier cambio en el servicio, ya sea un cambio en la interfaz o implementacin, que pueda impactar en la ejecucin del consumidor, debe producir la creacin de la nueva versin del servicio (mtodo). Si bien la definicin anterior no es muy precisa y fcil de interpretar, brinda un buen punto de inicio para la creacin de la nueva versin. Analizar ms en detalle los componentes principales de la definicin del servicio (definiciones de mensaje e interfaz) y las implementaciones para determinar las situaciones particulares que pueden llevar a la creacin de una nueva versin. Cambios en la interfaz del servicio Despus de la adopcin de un modelo semntico de mensajera, las firmas del mtodo de un servicio nunca cambian (todos los cambios se reflejan en los cambios del modelo semntico). La interfaz del mtodo del servicio, en el caso de la mensajera semntica, es la siguiente: cada mtodo se trata e implementa de forma individual en un esquema de versionado basado en el mtodo, se pueden incorporar mtodos adicionales al servicio sin afectar a los consumidores del servicio existente. Finalmente, puesto que todos los cambios de interfaz estn contenidos en el modelo de mensajera, la eliminacin del mtodo (desaprobacin del uso), en este caso, es equivalente a la eliminacin de alguna funcionalidad de la empresa y debe suceder muy rara vez. Desde el punto de vista del consumidor, esta situacin requiere modificaciones (potencialmente significativas), que implican la implementacin interna de la funcionalidad requerida o el uso de un servicio completamente diferente. En este caso, el mtodo del servicio se define como desaprobado y se guarda, mientras que cada uno de sus consumidores podr dejar de utilizarlo (ver Consideraciones sobre el ciclo de vida de versiones del servicio ms adelante en este artculo). Cambios en el mensaje Como se defini anteriormente, en el caso de la mensajera semntica, los cambios en la interfaz del servicio estn contenidos en los cambios de mensajes semnticos. Estos mensajes se definen utilizando esquemas que describen su contenido. El uso de esquemas de mensajera para la definicin de cambios potenciales de la interfaz
representacin de un esquema porque el versionado ocurre en la raz del esquema. Las herramientas de validacin del esquema XML no son necesarias para validar las instancias que utilizan el atributo de la versin; el atributo se proporciona puramente para documentacin y no es aplicable por los analizadores de XML. Debido a que no se necesitan los analizadores de XML para validar el uso del atributo de la versin, se requiere un procesamiento personalizado adicional (adems del analizador y la validacin) para asegurar que la versin del esquema prevista sea referenciada por la instancia. La serializacin/deserializacin de datos de documentos de XML rara vez realiza utilizando manipulacin directa del rbol DOM. El enfoque habitual para la serializacin de datos es la generacin de clases que soporten la serializacin de datos automtica con el uso de herramientas como WSDL2Java, Castor, EMF, SDO, XSD, XSDObjectGenerator y dems. En este caso, las clases se generan en paquetes en Java o espacios de nombres en C#, basadas en los espacios de nombres del esquema, no en la versin del esquema. Otra opcin para indicar las versiones del esquema es el uso de espacios de nombre de XML. En este enfoque, un espacio de nombre nuevo de XML se utiliza para todas las producciones de versiones
de la versin principal) para todas las versiones principales de cada esquema. Indicacin de todas las versiones secundarias como una versin del esquema en un espacio de nombres de la versin principal. Debido a que las versiones secundarias son compatibles con versiones anteriores, el cdigo serializado generado, tambin lo ser.
38
Versionado en SOA
alinea este enfoque con las tcnicas de versionado del esquema de XML (Ver la seccin Versionado en esquemas XML), y por lo tanto, permite la representacin directa del versionado en los mensajes del servicio. En trminos generales, los cambios en el esquema se pueden definir en tres categoras principales: Las Revisiones representan los cambios en el esquema del documento. Por ejemplo, un cambio en un espacio en blanco, formateo, documentacin no normativa, comentarios y dems. La revisin de una versin que ya ha sido publicada no debe afectar la funcionalidad de los consumidores ni de las implementaciones del servicio. Adems, el desarrollo gradual inicial de un esquema semntico, antes de que se publique para uso productivo, tambin se puede tratar como una revisin de la misma versin. Los cambios secundarios representan los cambios compatibles con versiones anteriores en el esquema del documento. Los ejemplos de cambios secundarios en el esquema incluyen: Cambios en la implementacin Una creencia errnea comn es que, debido a que los servicios se definen a travs de la interfaz, no de la implementacin, los cambios en la implementacin del servicio no afectarn a los consumidores del servicio y no requieren la creacin de versiones. En realidad, la adherencia a la interfaz no constituye la capacidad de cambio de las implementaciones. La capacidad de cambio no est definida por la interfaz sola, sino ms bien por el contrato, que incluye la interfaz, pre y post condiciones y ciertos SLAs sobre los cuales se basa el consumidor del servicio. Por consiguiente, el versionado se requiere cuando los cambios en la implementacin del servicio afectan el contrato sobre el cual se basa un consumidor del servicio particular. Debido a que los diferentes consumidores del servicio pueden basarse en diferentes partes del contrato de servicio, cada cambio en la implementacin del servicio debe ser validada para todos los consumidores del servicio existente para garantizar que no se incumplan los contratos.
Agregar un tipo o elemento global Agregar elementos opcionales a tipos existentes Cambiar el tipo de un elemento global o local a un tipo nuevo,
derivado del original, agregando/restringiendo elementos opcionales.
Los cambios importantes representan cambios no compatibles con versiones anteriores en el esquema del documento. Ejemplos de cambios principales en el esquema incluyen:
UNA CONSIDERACIN IMPORTANTE DEL VERSIONADO ES DEFINIR LA CANTIDAD DE TIEMPO QUE SE CONSERVAR UNA VERSIN DEL SERVICIO (MTODO). EL CICLO DE VIDA ADECUADO PARA LAS VERSIONES DEL SERVICIO (MTODO) VARA SIGNIFICATIVAMENTE Y EST DEFINIDA POR LA CAPACIDAD DE LA ORGANIZACIN DE HACER FRENTE A LOS CAMBIOS.
A continuacin se detallan algunos ejemplos de cambios en la implementacin (mtodo) del servicio puede llevar a cambios en el contrato:
Segn las definiciones anteriores, tanto las revisiones como los cambios secundarios en el esquema de mensajera ofrecen compatibilidad con versiones anteriores y no afecta el contrato del servicio. Como consecuencia, no impacta la implementacin del consumidor ni del servicio y no requieren el versionado de servicios. En cambio, los cambio importantes requieren el versionado del esquema de mensajera y por consiguiente, de los servicios.
Implementacin Versin 1
interfaz (funcionalidad), pero cambia el tiempo de ejecucin (SLA). Si un consumidor del servicio invoca este servicio (mtodo) sincronizadamente, ese cambio puede afectar significativamente la ejecucin del consumidor del servicio. Como resultado, es posible que se necesite la creacin de versiones. (Curiosamente, volver a implementar un servicio existente, con cambios en su implementacin, puede producir los mismos resultados). La nueva implementacin del servicio soporta la misma interfaz, pero cambia las validaciones de los parmetros entrantes (precondiciones). En este caso, algunas solicitudes que se han procesado de un modo exitoso, ahora sern rechazadas, requiriendo la introduccin de un nuevo servicio. La nueva implementacin del servicio introduce una nueva implementacin de seguridad (precondicin), que por lo general no se refleja en la interfaz del servicio, sino ms bien a travs de las opciones de configuracin. (Ver Recursos Web Services Handbook for WebSphere Application Server Version 6.1 by Wahli et al. and Web Service Security by Hogg et al). En este caso, los consumidores del servicio existente necesitarn enviar credenciales de seguridad se requiere un cambio en la implementacin y la creacin de una nueva versin. Cada uno de estos escenarios requiere el anlisis de los consumidores del servicio existente y potencialmente, pruebas exhaustivas. Como resultado, un modo ms simple de decidir si es necesario crear una nueva versin del servicio (mtodo) cuando cambia la implementacin del servicio, es mantener una definicin del contrato del servicio (mtodo) y crear una nueva versin cuando cambia el contrato, sin tener en cuenta qu consumidor depende de qu parte del contrato. Ante la duda, por lo general es ms simple crear una nueva versin.
Implementacin Versin 2
...
Implementacin Versin n
39
Versionado en SOA
problema puede ser an ms complejo que el versionado de servicios. Se puede lograr una mejora an mayor si se reemplaza con un agente externo (mediador) el enrutador local que realiza el envo entre la implementacin de las versiones del servicio. En este caso, todas las versiones se pueden implementar de un modo independiente y es responsabilidad del mediador establecer un vnculo de forma Consumidor 1 Servicio 1 dinmica con la direccin terminal de la versin del servicio deseado y (utiliza Invoca Mtodo 1 enviar todos los mensajes de acuerdo con esto. Sin embargo, a pesar Servicio 1 Versin 1 de que los intermediarios (mediaciones) son promocionados en las Mtodo 1 publicaciones ESB como la solucin para la mayora de los problemas Versin 1) de transformacin/enrutamiento que se encuentran en la Arquitectura Orientada al Servicio, existen inconvenientes asociados con ellos. Servicio 1 Normalmente, disminuyen el rendimiento. Tambin debe soportar el Mtodo 1 SLA ms estricto de todos los servicios que se acceden a travs de Versin 2 ste, que podra ser un requisito muy fuerte. Direcciones terminales mltiples. En este caso, al igual que con Consumidor 2 la implementacin del mediador, cada versin de una operacin (utiliza determinada se implementa en su propia direccin terminal. La Invoca Servicio 2 diferencia aqu es que cada direccin terminal se expone directamente Servicio 1 Mtodo 2 para un consumidor del servicio (Ver Figura 3). Mtodo 1 Versin 2) Las direcciones terminales mltiples implican que un consumidor del Versin n servicio puede establecer un vnculo con una direccin terminal (por lo general, utilizando un registro del servicio) para una versin necesaria Consideraciones sobre el ciclo de vida de versiones del servicio basada en la informacin de la versin/mtodo/servicio. La ventaja de Una de las consideraciones ms importantes del versionado es definir este esquema es una separacin completa de la implementacin de versiones mltiples del mtodo. La desventaja es un paradigma de la cantidad de tiempo que se conservar una versin del servicio direccionamiento ms complejo que requiere soporte de registro del (mtodo). Extender este perodo produce la necesidad de conservar servicio para establecer un vnculo con la direccin terminal. cantidades excesivas de versiones del servicio. Por otro lado, reducir El enfoque de direccin terminal mltiple, habitualmente, brinda una el perodo, limita el tiempo para que los consumidores del servicio implementen las actualizaciones necesarias. El ciclo de vida adecuado mejor escalabilidad (un salto menos de red) y disminuye el acoplamiento entre las versiones mltiples de la misma operacin. para las versiones del servicio (mtodo) vara significativamente y est definida por la capacidad de la organizacin de hacer frente a los Versionado de la Infraestructura del servicio cambios. Una variante para la creacin de versiones de servicios es el versionado de la infraestructura del servicio, que puede requerir lo siguiente: Enfoques de acceso/implementacin de la versin Figura 3: Implementacin de versiones utilizando direcciones terminales expuestas directamente
...
Existen dos enfoque comunes para la implementacin de las Cambios en el transporte, por ejemplo, cambiar el transporte de versiones del servicio: HTTP a Java Message Service (JMS). Pacto o Parmetro de la versin. Un pacto es un acuerdo if Cambios en el cdigo del mensaje, por ejemplo, actualizando el then-else (si t haces esto, entonces yo hago esto). En este caso, empaquetado propietario con el Protocolo de Acceso a Objetos hay una direccin terminal nica para todas las versiones del servicio Simple (SOAP). (mtodo), como se muestra en la Figura 2. El pacto realmente implementa el enrutamiento basado en el Cambios en el esquema de direccionamiento, por ejemplo, contexto, toma un mensaje entrante y lo enruta (basado en un introduccin del Direccionamiento de Servicios de Web para parmetro de la versin, incorporado en el mensaje de invocacin) especificar la direccin de respuesta. hacia la versin adecuada del servicio. El beneficio de este enfoque es que simplifica el direccionamiento del servicio, Figura 4: Interoperabilidad entre infraestructuras del servicio desde el punto de vista del consumidor. El consumidor, en este caso, utiliza una direccin terminal nica para Fachada del Fachada del Consumidor Proveedor acceder a todas las versiones proveedor proveedor del servicio del servicio de un determinado servicio del servicio del servicio Infraestructura Infraestructura (mtodo) y codifica el del Servicio 1 del Servicio 2 mtodo necesario en el Adaptador mensaje de invocacin. Una direccin terminal implementa un soporte de enrutamiento, invocando una versin En este caso, siempre se prefiere implementar la compatibilidad con requerida. versiones anteriores asegurando que la nueva infraestructura pueda Si bien el enfoque del pacto minimiza el impacto de incorporar comprender y soportar los mensajes que produce la infraestructura nuevas versiones sobre el consumidor del servicio, tambin presenta anterior y pueda producir mensajes compatibles con sta. En realidad, la complejidad de combinar mltiples versiones de un mtodo de esto puede ser muy costoso o an imposible desde el punto de vista servicios. Esto puede provocar colisiones de nombres de clase, tcnico. colisiones de nombres de bases de datos, etc. Asimismo, este Trasladar todos los consumidores e implementaciones del servicio enfoque realmente requiere una estrategia de versionado, no slo existente a la nueva infraestructura es por lo general bastante costoso para los servicios en s mismos, sino tambin para los componentes y se le debe dedicar demasiado tiempo, requiriendo soporte del que se utilizan en las implementaciones de los servicios. Si se tiene versionado que proporciona interoperabilidad entre dos infraestructuras en cuenta el alto grado de acoplamiento entre los componentes, este de servicio diferentes. La solucin ms usada para este problema es un
40
Versionado en SOA
adaptador del servicios (Ver Figura 4). En este caso, cuando el consumidor del servicio, que tiene soporte de la infraestructura del servicio 1, invoca al proveedor del servicio, con soporte de la infraestructura del servicio 2, la llamada pasa por el adaptador realizando una mediacin entre las infraestructuras del servicio. Desde el punto de vista del consumidor del servicio, el adaptador funciona como un proveedor de servicios. El adaptador entonces invoca al proveedor del servicio, actuando como un consumidor del servicio. La implementacin se puede combinar con la topologa de implementacin de versionado de servicios (Figura 4) para brindar soporte en el versionado tanto a los servicios as como tambin a los consumidores del servicio entre infraestructuras diferentes. Conclusin Enfrentar los cambios, nunca es sencillo y, por lo general, la complejidad aumenta con la dimensin de la implementacin. Habitualmente, las implementaciones ms grandes tienen ms partes movibles interdependientes, y por consiguiente, los efectos del cambio son ms generales. Las implementaciones de SOA, en especial las implementaciones que afectan a toda la empresa, no son la excepcin. Los enfoques de versionado de servicios que se describen en este artculo, llevan a la creacin de implementaciones de SOA de estructura mucho ms flexible. La introduccin de versiones mltiples del servicio implementadas de forma simultnea permiten que tanto los consumidores del servicio como los proveedores evolucionen de modo independiente, con sus propios programas de implementacin y desarrollo. El versionado independiente de los mtodos del servicio minimiza el impacto de la creacin de versiones y reduce la cantidad de cdigo implementado. Finalmente, el uso de mensajera semntica para las definiciones de interfaz del servicio hace que las implementaciones del servicio sean ms flexibles al cambio. Agradecimientos El autor agradece a Jim McKune, Dmitry Tyomkin, Kiran Achen y Luc Clement por sus contribuciones. Recursos Defining SOA as an Architectural Style, Boris Lublinsky, IBM developerWorks, Enero 2007 http://www-128.ibm.com/developerworks/architecture/library/ ar-soastyle/ Principles of Service Design: Service Patterns and Anti-Patterns, John Evdemon, MSDN, Agosto 2005 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dnbda/html/SOADesign.asp Best Practices for Web Services Versioning, Kyle Brown, Michael Ellis, IBM developerWorks, 2004 http://www-128.ibm.com/developerworks/webservices/library/ ws-version/ A SOA Version Covenant, Rocky Lhotka http://www.theserverside.net/articles/showarticle.tss?id= SOAVersioningCovenant XFire User Guide, Versioning Best Practices http://docs.codehaus.org/display/XFIRE/Versioning Architecting Industry Standards for Service Orientation, Sobre el autor Boris Lublinsky posee ms de 25 aos de experiencia en arquitectura tcnica e ingeniera del software. Desde hace varios aos se dedica a la Arquitectura Empresarial, SOA y Administracin de Procesos. A lo largo de toda su carrera, el Dr. Lublinsky ha sido autor y orador tcnico asiduo. Posee ms de 40 publicaciones tcnicas en diferentes revistas que incluyen: Avtomatika i telemechanica, IEEE Transactions on Automatic Control, Distributed Computing, Nuclear Instruments and Methods, Java Developers Journal, XML Journal, Web Services Journal, JavaPro Journal, Enterprise Architect Journal y EAI Journal. Actualmente, el Dr. Lublinsky trabaja para una gran Compaa de Seguros en la que sus responsabilidades incluyen el desarrollo y mantenimiento de estructuras y estrategias de SOA. Puede contactarlo en blublinsky@hotmail.com. Josh Lee, Microsoft 2005 http://msdn.microsoft.com/architecture/thinkahead/default.aspx? pull=/library/en-us/dnbda/html/aisforsoa.asp Principles of Service Design: Service Versioning, John Evdemon, Microsoft 2005 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dnbda/html/SOADesignVer.asp Web Services Handbook for WebSphere Application Server Version 6.1 (Draft IBM Redbook), Ueli Wahli, Owen Burroughs, Owen Cline, Alec Go, Larry Tung http://www.redbooks.ibm.com/redpieces/abstracts/sg247257. html?Open Web Service Security. Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0, Jason Hogg, Don Smith, Fred Chong, Dwayne Taylor, LonnieWall, y Paul Slater (Microsoft Press, 2005) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dnpag2/html/wssp.asp Patterns: Implementing an SOA using an Enterprise Service Bus in WebSphere Application Server V6, Martin Keen, Oscar Adinolfi, Sarah Hemmings, Andrew Humphreys, Kanthi Hanumanth, Alasdair Nottingham, IBM Redbooks, 2005 http://www.redbooks.ibm.com/abstracts/sg246494.html?Open Supporting Policies in Service-Oriented Architecture, Boris Lublinsky, IBM developerWorks, 2004 http://www-128.ibm.com/developerworks/webservices/library/ ws-support-soa/ Toward a Pattern Language for Service-Oriented Architecture and Integration, Part 1: Build a service eco-system, Ali Arsanjani, IBM developerWorks, Julio 2005 http://www-128.ibm.com/developerworks/webservices/library/wssoa-soi/
41
098-107719