Arquitectura de Infraestructura

Aprenda la disciplina, ejerza el arte y contribuya con sus ideas en
www.ArchitectureJournal.net Recursos que sirven de base
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
Arquitecturas de alta disponibilidad para hosting masivo

Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael Johnson
Descubra los secretos para la creacin de infraestructuras de hosting escalables, confiables, seguras y fcil de mantener.
Brindar informtica integral de alta productividad

Por Marc Colmes y Simon Cox
Explore una solucin tcnica para la creacin de un servicio HPC distribuido, orientado al servicio.
Infraestructuras orientadas a pruebas

Por Mario Cardinal
Los equipos de infraestructura tienen la oportunidad de aprender de los equipos de desarrollo el modo de expresar las decisiones de arquitectura utilizando secuencias de comando de prueba.
19
Perfil del Architecture Journal: Don Ferguson

Don Ferguson es Asociado Tcnico de Microsoft en Plataformas y Estrategia en la dependencia del CTO. Actualcese sobre su carrera y sus pensamientos sobre la arquitectura.
24
Resolver el dilema de la integracin

Por Jim Wilt
Aprenda una definicin del dilema de integracin y lo que puede hacer para evitarlo en su entorno.
26
Ontologa y Taxonoma de los Servicios en una Arquitectura Orientada a Servicios

Por Shy Cohen
Los servicios se pueden obtener en diversas formas y tamaos. Vea un modo de utilizar una ontologa y taxonoma comn para describirlos
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
que sirven de base. www.architecturejournal.net
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
THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net
Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael Johnson
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?
www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Debido a estos cambios en la industria, las empresas de tecnologa de software que ofrecan la base para estos servicios se dieron cuenta que sus actuales sistemas operativos no podan satisfacer las necesidades del los hosters. Todava se necesitaba un alto nivel de interaccin con el administrador del sistema para que las operaciones siguieran ejecutndose con la menor cantidad de problemas posible. Los ingenieros de la industria y los proveedores de servicios independientes tomaron conciencia de la carencia que haba en los servicios en relacin con software/hardware y emprendieron su propio objetivo desarrollando tecnologas que cubran las carencias al mismo tiempo que se beneficiaban. En ese momento los hosters comenzaron a considerar la creacin de plataformas que fueran ms escalables y que pudieran lograr una mayor densidad. Tambin deban ser de fcil gestin. Un buen comienzo al construir este tipo de arquitectura es analizar los varios servicios que el hoster necesita soportar y administrar. Consideraciones al planificar arquitecturas de alta disponibilidad para hostings masivos Cuando el hoster reflexiona y comienza a pensar en las tecnologas que podra agrupar y el modo de crear una plataforma para soportar varios servicios y sitios de Web, se le ocurren varios requisitos claves. Estos requisitos abarcan desde la cantidad de aplicaciones o usuarios hasta el tipo de funciones y servicios que deberan soportarse y su impacto sobre el sistema subyacente ASP.NET, PHP, SQL y dems y finalmente el costo por aplicacin o sitio 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. Separamos estos servicios en amplios segmentos, con las siguientes piezas principales de arquitectura: IIS clster(es), SQL clster(es), servicios de infraestructura de soporte, como servicios del Active Directory, System Center Operations Manager, almacenamiento centralizado, ya sea en una red de rea de almacenamiento o en un almacenamiento conectado a la red, clsteres SSL de descarga, clsteres FTP, y otros clsteres similares. La separacin de estos servicios en varios segmentos le permite al hoster escalar la arquitectura de diferentes modos. Un hoster podra escalar un clster de SQL de un modo diferente que un clster de Web y presentar un conjunto diferente de problemas de arquitectura. Otro factor que forma parte de la arquitectura es el requisito de legado, cuyo mejor ejemplo son las Extensiones del Servidor de FrontPage (FPSE). Miles de clientes todava las utilizan y son necesarias si la plataforma de hosting masivo espera atraerlos. Por lo general, estas extensiones las utilizan pequeos negocios para crear sitios simples. Todava se utilizan para herramientas de desarrollo como Visual Studio y Visual Web Developer por su funcionalidad de carga para HTTP, a pesar del desaliento por parte de Microsoft. Los componentes de legado, como FPSE, no pueden ser eliminados de un modo simple por grandes hosts sin una prdida de la base de clientes. Analicemos ahora algunos de estos clsteres dentro de la arquitectura. La pieza ms grande es el clster de Web y el segundo es el clster de SQL. Es importante recordar que un diferenciador clave entre lo que hacen los hosters frente a lo que hacen otras empresas como departamentos internos de TI, es que intentarn colocar la mayor cantidad posible de sitios o bases de datos en un clster. Por este motivo, ciertas soluciones empresariales no funcionan para ellos. Adems, no siempre controlan el tipo de aplicaciones que se colocan en un servidor y por lo tanto, no pueden definir la capacidad del mismo modo que lo pueden hacer las empresas tpicas. Figura 1: Modelo de distribucin de carga de la aplicacin
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.

Figura 2: Escenario del grupo de aplicacin uno-a-uno
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.

Existe una preocupacin y es que las aplicaciones y sitios de Web en un grupo de aplicaciones compartidas podran potencialmente dar a algunos usuarios acceso a los datos de otros. Se deben realizar ciertas migraciones para garantizar que estas aplicaciones y sitios de Web estn asegurados. Por ejemplo, es necesario que cada sitio de Web tenga un usuario annimo nico y se debe aplicar una lista de control de acceso a los archivos de la Web. Tambin, las aplicaciones ASP.Net se deben configurar con seguridad de acceso al cdigo y se deben ajustar a un nivel medio de confianza. Estos pasos ayudarn a garantizar que las aplicaciones y los sitios de Web en el servidor sean seguros, an en un grupo de aplicaciones compartidas. Debido a que todas las aplicaciones se ejecutan bajo el mismo proceso de grupo de aplicaciones compartidas es que carecen del aislamiento que varios proveedores de hosting necesitan. Esto puede ser una preocupacin en escenarios de alta disponibilidad ya que un problema afecta a todos los otros sitios de Web y aplicaciones del mismo grupo. Por ejemplo, una aplicacin podra causar que un grupo de aplicaciones se reinicie o an peor, que se cierre completamente. Tambin es ms difcil para los administradores del sistema identificar un problema cuando hay varios sitios y aplicaciones en un nico grupo. Si bien hay herramientas disponibles que permiten al host aislar los problemas dentro del grupo de aplicaciones, esta tarea se logra con mayor facilidad cuando se utiliza un grupo de aplicaciones uno-a-uno para modelar un sitio de Web. Planificacin de un grupo de aplicaciones con alta disponibilidad El desafo de los hoster es lograr un equilibrio entre lograr altos niveles de aislamiento y maximizar la escala. Debido a esto, varios de ellos se ven obligados a utilizar el escenario de grupo de aplicaciones hbridas que mencionamos anteriormente. Un escenario tpico incluira mltiples grupos de aplicaciones, cada uno de los cuales cumple un propsito especfico. Por ejemplo, los sitios de Web que slo poseen contenido esttico, podran colocarse todos en un nico grupo de aplicaciones compartidas. Esto es posible ya que el contenido esttico no est asociado con los problemas de rendimiento y seguridad que surgen con el contenido dinmico. Todos los otros grupos de aplicaciones estaran dedicados a sitios que tengan contenido dinmico. Esto permite que el hoster asigne mayores recursos para estos sitios. Esta configuracin es ms frecuente en entornos de hosting compartido en los que una nica plataforma debe brindar servicio a clientes que poseen tanto contenido esttico como dinmico. placa. Las secciones que se detallan a continuacin dividen las diferentes arquitecturas de almacenamiento que son comunes entre las compaas de hosting. Almacenamiento directamente conectado (DAS) DAS es uno de los mtodos de almacenamiento ms comunes y clsicos que utilizan las compaas de hosting de Web. Se trata de servidores de Web autnomos en los que el contenido se ubica de forma local. El beneficio principal es que si un nico servidor autnomo deja de funcionar, toda la base del cliente no queda sin conexin. La desventaja es que los clientes estn sujetos a cualquier tipo de falla del hardware, no simplemente a una falla del subsistema del disco. Adems, este tipo de configuracin presenta problemas como lmites de densidad, problemas de migracin y falta de alta disponibilidad para los sitios de Web y distribucin de la carga.
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

Las compaas de hosting pueden construir sistemas de correo y SQL escalables de alta disponibilidad, como por ejemplo Exchange, si utilizan las capacidades de una SAN como el almacenamiento centralizado para estos tipos de clsteres. Adems, cuanto ms avanzada es la SAN, ms opciones tiene la compaa de hosting para realizar tareas como gestin de recuperacin y captura de imgenes dentro del SQL o Exchange. Uno de los principales inconvenientes para un sistema de almacenamiento empresarial es el costo en el que incurre el hoster. Los hosters son cuidadosos al asegurar que el producto que van a implementar tenga un rendimiento de la inversin (ROI) lo suficientemente alto como para justificar el costo de un SAN. Deben brindar un alto grado de servicio para mantener la lealtad del cliente y lograr sus objetivos comerciales. Los proveedores de servicios buscan la forma de producir la plataforma de Web milagrosa que ayude a reducir el costo total de propiedad (TCO) y brindar a sus clientes una respuesta de forma efectiva y eficaz. Cuando hacemos referencia a una solucin de plataforma de Web compuesta de servicios de Web, almacenamiento de datos y almacenamiento de bases de datos, inevitablemente ocurre un problema dentro de alguno de estos componentes. Una solucin es tan slida como su punto ms dbil. Fundamentalmente, cada componente de una solucin debe ser escalable a nivel exterior y de forma ascendente y tambin debe ser rentable. Este artculo no trata las tecnologas (cdigo abierto o cdigo cerrado) que pueden cumplir el objetivo o lo han cumplido en algunas reas, sino que trata los problemas bsicos de arquitectura que no se tienen en cuenta como primordiales cuando se desarrollan tecnologas. En la actualidad, no es suficiente crear tecnologa porque s con el objeto de ocupar una posicin. Slo mediante la estrategia, planificacin y desarrollo de soluciones de gran escala podremos respaldar requisitos de gran escala. El mundo est creciendo, las necesidades son cada vez mayores y slo tiene sentido que las infraestructuras tambin.
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.
Brindar informtica integral de alta productividad

Por Marc Holmes y Simon Cox
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
Informtica de alta productividad

los ltimos tiempos (de ficcin). Dada una pregunta simple (Cul es la respuesta a la vida, el universo y todo lo dems?), arroj una respuesta simple (42), aunque, despus de varios millones de aos de procesamiento y una pequea pausa desconcertadora al final del proceso. Existe, por supuesto, un modo simple de mejorar el valor de una solucin de HPC: Hacerla ms rpido. Sin embargo, para problemas de suficiente complejidad informtica, en cierto punto, pasa a ser poco provechoso continuar el intento de mejorar la solucin debido a las limitaciones de la tecnologa. Los esfuerzos para intentar mejorar la velocidad de los procesamientos se pueden representar mediante el ciclo que se muestra en el Figura 1. Para mejorar la velocidad de los procesamientos, un equipo de desarrollo debe:
Figura 1: Los esfuerzos para mejorar la velocidad del procesamiento se agrupan en tres zonas interrelacionadas, formando un ciclo.
Hardware
Utilizar ms o mejor hardware. Los beneficios de los procesadores
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

soluciones para proporcionar interfaces y controles que posibiliten una ejecucin eficaz del proceso total, permitiendo a los investigadores e ingenieros realizar sus tareas de un modo ms rpido y eficaz. Definir el problema y la solucin Utilizar la cartera disponible de tecnologas de Microsoft nos permite crear una arquitectura ms completa para una solucin de HPC y posibilita la realizacin de funciones que brindan valor adicional a los equipos que utilizan la solucin. Adems, el uso de estas tecnologas puede construir de un modo integrado e interactuar con las infraestructuras existentes. Esta seccin del artculo describe una arquitectura posible y algunas caractersticas de esta arquitectura as como tambin el valor que proporcionan. Escenarios del problema Es difcil generalizar completamente una solucin de HPC debido a las necesidades especficas de un dominio individual y a los procesos comerciales que surgen como parte de los desafos de ingeniera que se presentan normalmente. Sin embargo, podramos considerar tres situaciones posibles para la solucin. La primera es la situacin bsica del usuario: finalizar una tarea de informtica. Las otras dos situaciones posibles son administracin y creacin y soporte para este proceso.
Ciencia ambiental de alta productividad integral

El proyecto de modelo del sistema Grid-ENabled Integrated Earth (GENIE) proporciona una estructura accesible por red que facilita la integracin, ejecucin y administracin de los modelos componentes para el estudio del sistema terrestre sobre escalas de tiempo milenarias. Los simulacros basados en la estructura GENIE deben seguir procedimientos de operaciones complicados entre diferentes modelos y recursos informticos heterogneos. El proyecto GENIE ha desarrollado una estructura para la composicin, ejecucin y administracin de modelos integrados del sistema terrestre. Los cdigos componentes (ocano, atmsfera, superficie terrestre, hielo marino, capas de hielo, biogeoqumica, y dems) de complejidad y resolucin variada pueden unirse de un modo flexible para formar una serie de modelos del clima, eficaces, que sean capaces de simular sobre escalas de tiempo milenarias. El proyecto rene un grupo distribuido de cientficos del medio ambiente con un inters en comn por el desarrollo y uso de los modelos GENIE para comprender el sistema terrestre. Los simulacros del sistema terrestre comprenden muchos datos as como tambin mucha informtica. La estructura GENIE se ha diseado para soportar la ejecucin de estos simulacros entre mltiples recursos informticos y datos distribuidos por un perodo de tiempo extenso. Aprovechamos la variedad de recursos heterogneos, incluyendo la Red Nacional del Reino Unido de recursos informticos en paralelo (que ejecuta Linux y Windows Compute Cluster Server) y el aprovechamiento de los ciclos de escritorio en sitios distribuidos. Nuestro almacn de datos de infraestructura informtica utiliza Oracle 10G para almacenar metadatos sobre nuestros simulacros y el servidor SQL para coordinar el seguimiento de persistencia de nuestros flujos de trabajo en ejecucin. (Ver Figura 1)
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
Interfaz de Web del cliente
Figura 3: Escenario de autora general

Escenario de autora Desarrollar Actividades Autor Algoritmos Configuracin Publicar Catlogo
Figura 4: Escenario de administracin general

Escenario de administracin Administrar Monitoreo
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:
Inicio de sesin: El usuario debe poder iniciar la sesin de la
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:
Automtico: Si bien es probable que los resultados de la tarea
Carga: Un usuario debe poder cargar o acceder a grupos de datos
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:
Preproceso: El paso de preproceso para un trabajo puede realizar
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
Actividades: Un desarrollador puede querer construir actividades o
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

Flujo de trabajo: Un desarrollador de usuarios avanzados puede
representar los requisitos para una solucin de HPC y considerando el valor descripto al comienzo en la construccin de una solucin de HPC, podemos ahora considerar algunos escenarios de la solucin para cumplir con estos requisitos. Informtica de alto rendimiento con la edicin de Microsoft "Compute Cluster Server El servicio fundamental necesario para la solucin es la capacidad de los clsteres de la Informtica de Alto Rendimiento en s. La edicin de Microsoft Compute Cluster Server (CCS) ofrece capacidades de clsteres para cumplir con el paso Proceso del escenario del problema. (Ver Figura 5) CCS brinda capacidades de clsteres para una versin reducida de Windows Server 2003 que permiten, por ejemplo, el uso de procesamientos paralelizados, aprovechando varios procesadores para completar procesamientos particularmente complejos o intensivos como aquellos que se basan en estadsticas generales. El control de un clster de CCS es realizado por un nodo principal que se comunica con los nodos del clster para impartir instrucciones y coordinar una serie de tareas sobre un trabajo especfico. Los nodos del clster pueden estar en una red privada, para un desempeo ptimo, y probablemente sea una red de tiempo de espera mnimo para asegurar que el tiempo de espera de red no tenga un impacto sobre el tiempo del procesamiento. La seccin de recursos al final de este documento contiene vnculos hacia artculos tcnicos sobre la configuracin e implementacin del CCS. El nodo principal posee un programador de tareas que permite la insercin de una tarea de procesamiento dentro de una cola para que se ejecute cuando la cantidad necesaria o deseada de procesadores estn disponibles para completar la tarea. Se proporciona una base de datos pequea al nodo principal para mantener un seguimiento de la cola de tareas en curso. Se puede acceder al programador de tareas mediante una interfaz en el nodo principal, va lnea de comando, que se puede parametrizar o ejecutar con una definicin de XML de los parmetros, o va API (CCS API) para interaccin programtica. Un clster CCS puede controlar diferentes tipos de trabajos como los que se detallan a continuacin:
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:
Catlogo: Despus del desarrollo de actividades, algoritmos y
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:
Monitoreo: Por lo general, los clsteres son recursos compartidos

administrados por personal especializado. Ellos deben controlar que las instalaciones proporcionen funcionalidad y rendimiento, por ejemplo, analizar las colas de trabajo y las tendencias de consumo de recursos. Cuenta: Es recomendable justificar el uso de la utilizacin de recursos por parte de ciertas cuentas. Esto ayuda cuando los clsteres son financiados y utilizados por varios grupos. Facturacin: Es posible crear modelos de cargo al usuario para facturar su uso de un modo explcito.
Trabajo en serie: sta es una tarea de procesamiento habitual que

simplemente ejecuta un programa necesario. tareas/programas en potencia.
Escenario de la solucin Despus de haber detallado varios escenarios generales que pueden
Flujo de tareas: Varios trabajos en serie compuestos de mltiples
Figura 5: Microsoft Cluster Compute Server Edition satisface el paso del proceso.
Acceso Inicio de sesin Solicitud Carga Proceso Preproceso Anlisis Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Usuario Aprobacin Postproceso Descarga
11
Consideracin de la cadena de valor

Por lo general, los usuarios de soluciones de informtica de alta productividad son altamente cualificados y son recursos muy preciados para los equipos de investigacin y desarrollo. Sus habilidades y experiencia profesional son necesarias para brindar aportes en los procesos, algoritmos para los clculos y el anlisis del producto resultante. Sin embargo, se debe permitir que estos recursos trabajen lo ms eficaz y eficientemente posible. La creacin de soluciones poco claras, de un modo u otro, afectaran esto de varios modos posibles: La compresin de la cadena de valor en lo que respecta a tiempo y costo debe ser la inquietud principal para la provisin de la solucin. Dados los problemas detallados con mejoras en la velocidad para el trabajo informtico, las mejoras deben identificarse fuera de este mbito y en otras reas del proceso. Candidatos ideales para la reduccin del costo en el proceso son, ampliamente, todos los aspectos de la cadena de valor con la probable excepcin de la creacin del algoritmo, que es la invencin y propiedad intelectual de la solucin. La reduccin de costos se divide en dos partes: el costo para utilizar la solucin y el costo de administracin. Mejorar el proceso para la publicacin y uso de algoritmos, y brindar soporte analtico podra reducir el costo total del proceso. A partir de la consideracin de la cadena de valor, un conjunto de soluciones debe estar compuesto de herramientas que proporcionen dos caractersticas fundamentales: simplificar la finalizacin de la tarea y oportunidades para la interaccin mejorada. Una cadena de valor mejorada Proporcionar una solucin basada en HPC utilizando una arquitectura similar a la descripta puede tener varios beneficios para la cadena de valor total. (Figura 2) Existen varias reas que podran estar afectadas inicialmente:
Es posible que el usuario deba tener cierto conocimiento del
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
Planificacin para un trabajo de larga ejecucin. Las reducciones de
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.
Acceso Inicio de sesin
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:
Anlisis paramtrico: Este tipo de trabajo podra ejecutar varias
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:
Flujos de trabajo de estado y en secuencia: El tiempo de ejecucin
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
Comunicacin del clster. Es posible crear una actividad
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:
Biblioteca de flujos de trabajo y actividades para controlar el clster

Arquitectura de componentes (con protocolos de comunicacin)
Interfaz de usuario
Autora
Visual Studio 2005 Extensiones WF SCC API
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
Almacn de archivos Callogo de flujos de trabajo DB Persistencia 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:
La experiencia de usuario principal para planificar y ejecutar un
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.
Actividades del trabajo de clster fuertemente tipeados, de ms
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

eventos y rellamadas del clster y luego realizar actividades nuevas dentro de un flujo de trabajo. Por ejemplo, el servicio de monitoreo puede examinar una excepcin durante el procesamiento o se puede utilizar para cancelar un procesamiento que se est ejecutando sobre el clster. Se podran construir servicios adicionales junto con estos. Un ejemplo sera un servicio de facturacin que monitorea las duraciones del uso del procesador y factura a un usuario en consecuencia. Seguridad y poltica WF posee un motor de reglas de encadenamiento progresivo eficaz que puede utilizarse dentro de una instancia de flujo de trabajo. Se pueden crear reglas en cdigo, o de forma declarativa, y luego compilarlas junto con el flujo de trabajo para su ejecucin. Servicios WF ofrece varios servicios que pueden utilizarse en la medida que sean necesarios mediante la asignacin de la implementacin del servicio al tiempo de ejecucin del flujo de trabajo. Tres de los ms tiles para HPC son: Las reglas y las polticas pueden tener diversos usos:
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.
Identidad del usuario. Podra concederse acceso a recursos del
Servicio de seguimiento. Utiliza la nocin de perfiles de
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
Figura 8: Escenario de informtica con Microsoft Office SharePoint Server

Acceso Inicio de sesin
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.
Escenario de Administracin Administrar Monitoreo
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:
Capa de datos 40-60.
Acceso e Inicializacin. Las capacidades de usuario y de inicio de
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.
HPC 10% 90%
Datos 40% 60%
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
Proporcin Genrica - Especfica
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

Monitoreo con Microsoft Operations Manager y PowerShell El producto principal para monitorear el buen funcionamiento del sistema es Microsoft Operations Manager (MOM). Se puede utilizar el MOM para monitorear el buen funcionamiento del clster del CCS del mismo modo que se puede utilizar para otros entornos de servidores. Adems, con PowerShell, se puede proporcionar un monitoreo simple del usuario para los usuarios finales (Ver Figura 9). Ofrecer una experiencia de autora con Visual Studio 2005 Por ltimo, se puede ofrecer una experiencia de autora de primera clase a travs de Visual Studio 2005, algunas de las cuales son estndar y algunas necesitan desarrollo (Figura 10). Desarrollar La codificacin es necesaria para los algoritmos y las actividades de autora, por lo tanto, Visual Studio 2005 es un entorno ideal para utilizar la estructura .NET para extender las actividades o modificar la interfaz de usuario, as como tambin para utilizar Microsoft MPI y pilas en C++ para la codificacin de algoritmos en paralelo. Para el desarrollo de flujos de trabajo, Visual Studio 2005 tambin es la opcin preferida, aunque puede no ser tan adecuado para los usuarios avanzados como lo es para los desarrolladores, debido a la complejidad de la interfaz. Para los usuario avanzados contamos con otras opciones:
Figura 12: Arquitectura tcnica de HPC
Interfaz de usuario (Portal de Sharepoint, Formularios de Windows)
Capa de aplicacin (Windows Workflow Foundation)
Servicio de datos (Servidor SQL)
Servicio de cmputos (Windows CCS)
limitando las actividades disponibles para un usuario avanzado.
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.
Realojamiento del diseador. El diseador del flujo de trabajo
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
Figura 10: Escenario de autora con Visual Studio 2005

Escenario de autora Desarrollar Actividades Autor Algoritmos Configuracin Publicar Catlogo
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
Figura 11: La superposicin de roles reduce costos
Autor
Usuario avanzado
Usuario
Disminuye el costo de la capacidad
17

de trabajo pasando un tipo que se ajuste al flujo de trabajo dentro del tiempo de ejecucin para crear una instancia del flujo de trabajo. Sin embargo, un flujo de trabajo puede ejecutarse desde un archivo de marcado declarativo archivo XAML si es necesario, o compilado sobre la marcha desde un XAML, junto con reglas. Esto es til ya que permite que el autor de un flujo de trabajo alguien con conocimiento sobre la codificacin de los flujos de trabajo cree un flujo de trabajo que no es totalmente vlido tal vez le falten algunos parmetros y lo guarde dentro de un archivo de marcado. El archivo de marcado puede entonces ser modificado por un usuario avanzado que le incorpora los parmetros necesarios (pero tal vez no edite el flujo de trabajo en s). Una vez que el flujo de trabajo es vlido, puede ser presentado, compilado y ejecutado por la capa de la aplicacin. Estos pasos pueden disminuir el costo de la ejecucin del proceso permitiendo que los roles se superpongan (Figura 11); las tcnicas de autora costosas no deben tomar parte en el paso de ejecucin del proceso en el que se pueden aplicar tcnicas de configuracin menos costosas. Arquitectura tcnica Los escenarios de la solucin pueden agregarse dentro de una arquitectura tcnica (Figura 12). Conceptualmente, CCS debe considerarse una puerta de enlace de servicios del mismo modo que el servidor SQL brinda servicios a una aplicacin la solucin no est centrada en CCS pero utiliza sus capacidades, segn sean necesarias. De igual modo, estos servicios se abstraen desde una interfaz de usuario mediante algn tipo de control de la aplicacin o capa de lgica de negocios. Por lo tanto, dada la naturaleza de las interacciones con la solucin HPC flujos de trabajo humano WF es una eleccin adecuada como controlador para estos servicios. WF tambin posee otros beneficios. Est diseado para ser alojado segn sea necesario, por lo tanto, la capa de interfaz del usuario podra ser una aplicacin de Windows o de Web confeccionada especficamente para la tarea. En el ejemplo detallado anteriormente, describimos Microsoft Office SharePoint Server como una interfaz adecuada porque posee fuertes conexiones para WF y la integracin con Office, incluido InfoPath, y las caractersticas de colaboracin de MOSS, podran ser tiles en los dominios cientficos y de ingeniera. La eleccin, por supuesto, debe estar basada en los requisitos de un dominio determinado. Conclusin El diseo de informtica de alta productividad no es simplemente cuestin de garantizar el mejor rendimiento para computar resultados lo ms rpido posible esto es ms una expectativa que una caracterstica del diseo. En el contexto de la cadena de valor total, la arquitectura debe proporcionar valor desde otras reas, como por ejemplo, facilitar el acceso y disminuir los costos de las habilidades especializadas para operar el sistema. Una arquitectura exitosa para las soluciones de informtica de alta productividad requiere la consideracin del proceso total junto con actividades intensivas de informtica y, por lo tanto, tal vez utilicen varios componentes integrados para desempear aspectos individuales del proceso. Microsoft Cluster Compute Server Edition es fcil de incluir como una puerta de enlace de servicio dentro de una estructura de aplicacin general de n-niveles y es simple para integrar a travs de conexiones API o lneas de comando. Otras tecnologas disponibles pueden brindar la base para una solucin HPC. En particular, Windows Workflow Foundation es ideal para proporcionar una interfaz de aplicacin al CCS ya que las funciones y la extensibilidad del WF, como persistencia y registro, son propicias para los requisitos de soluciones basadas en HPC. El uso de WF tambin ofrece opciones disponibles de tecnologas de experiencia de usuario para que sean aplicadas en un dominio determinado. Recursos adicionales Los siguientes recursos pueden ser tiles al considerar las tecnologas que abarcan la solucin propuesta en el presente artculo: Microsoft Compute Cluster Server 2003, http://www.microsoft.com/hpc Microsoft SQL Server 2005 (incluyendo SQL Server Integration Services), http://www.microsoft.com/sql Microsoft Windows Workflow Foundation, http://wf.netfx.com Microsoft Windows Communication Foundation, http://wcf.netfx3.com Microsoft Windows Presentation Foundation, http://wpf.netfx3.com/ Microsoft Office SharePoint Server 2007, http://www.microsoft.com/sharepoint/ Microsoft Operations Manager, http://www.microsoft.com/mom Microsoft Windows PowerShell, http://www.microsoft.com/powershell Otros recursos a los que se hace referencia en este artculo: CCS 2003 Technical Articles, http://technet2.microsoft.com/WindowsServer/en/library/9330fdf8c680-425f-8583-c46ee77306981033.mspx?mfr=true Essential Windows Workflow Foundation, http://www. awprofessional.com/bookstore/product.asp?isbn=0321399838&rl=1 Implementing the WF design surface in ASP.NET (with AJAX), http://www.netfxlive.com/ Whitepaper on WF Performance, http://msdn2.microsoft.com/enus/library/Aa973808.aspx Agradecimiento Meter Williams (Microsoft Consulting Services, lectura) Sobre los autores Marc Holmess es arquitecto evangelista para el Centro de Tecnologa de Microsoft en Valley Park, Reino Unido, donde se especializa en trabajos de prueba de conceptos, arquitectura y diseo con una variedad de clientes, socios y fabricantes de software independientes. Recientemente, antes de unirse a Microsoft, Marc lider un equipo de desarrollo importante como Jefe de Aplicaciones y de Web en BBC Worldwide. Marc es el autor de Expert .Net Delivery with NAnt and CruiseControl .Net (APress) y posee un blog en http://www.marcmywords.org. Puede contactarlo en marc.holmes@microsoft.com. Simon Cox es profesor de mtodos computacionales en Computacional Engineering Design Research Group dentro de la facultad de Ciencias de la Ingeniera de la Universidad de Southampton. Posee un premio MPV por Windows Server System Arquitecto de Infraestructura, dirige el Instituto de Microsoft para Informtica de alto Rendimiento en la Universidad de Southampton y ha publicado ms de 100 artculos. Actualmente es jefe de un equipo que desarrolla y aplica la informtica en proyectos de ingeniera y ciencia informtica interdisciplinaria de colaboracin, como electromagntica informtica, cristales lquidos, modelado del sistema terrestre, bases de datos biomolecurales, algoritmos informticos aplicados e informtica orientada a servicios distribuidos.
18

Por Mario Cardinal
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

Se deber realizar una copia de seguridad de la base de datos del Servidor SQL todas las noches. En caso de restauracin, volveremos a Figura 1: Modelo de secuencias de comando de prueba para validar almacenar la ltima copia de seguridad. decisiones de diseo Esta redaccin es mejor que la original pero todava existen zonas poco claras. Puedo volver a escribir la descripcin una y otra vez y proporcionar cada vez ms detalles para los implementadores. Terminara redactando una especificacin detallada formal. Sin embargo, una documentacin narrativa no ofrece un consenso explcito sobre lo que es una implementacin exitosa. An con la mejor de las intenciones, por lo general, los implementadores no comprenden bien los subttulos de mi especificacin formal. Por ejemplo, supongamos que la solucin que propuse era realizar copias de seguridad en cintas y olvid dejarlo explcito. Qu sucede si los implementadores realizan las copias de seguridad de la base de datos del servidor SQL en discos? A menos que yo descubra esto durante la revisin del diseo, no lo sabr hasta que el disco del servidor SQL y el disco que posee la copia de seguridad se daen el mismo da. En cambio, si escribiera un comando de prueba, podra establecer un consenso explcito sobre el cumplimiento. Un comando de prueba tiene xito o falla. Las pruebas permiten que los implementadores y los arquitectos definan explcitamente el cumplimiento de requisitos a partir de las especificaciones de arquitectura. Los implementadores que desean aprender sobre la arquitectura pueden analizar los comandos de prueba. Los comandos de prueba son artefactos operativos que poseen menos probabilidad de incumplimiento de los requisitos de la implementacin y por lo tanto, poseen menos probabilidad de estar desactualizados. Consenso explcito El comando de prueba es una combinacin del procedimiento de prueba y los datos de prueba. Los comandos de prueba son grupos de pasos escritos que deben realizarse de forma manual o automtica. Reflejan caractersticas que son fundamentales para el xito de la arquitectura. Estas caractersticas pueden indicar el uso apropiado o inapropiado de la arquitectura as como tambin los comportamientos negativos que se deben detectar. Como ejemplo concreto, la Figura 1 muestra dos comandos de prueba simples que validan la siguiente decisin de diseo irreversible: 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. Un comando de prueba tiene xito o falla. Debido a que valida el propsito del arquitecto, proporciona un consenso explcito sobre el cumplimiento. Secuencia de prueba 1 Intento: Recuperar falla del disco duro del Servidor SQL Pasos: 1. Reemplazar disco duro defectuoso 2. Instalar base de datos en el servidor SQL 3. Recuperar copia de seguridad del da anterior desde la cinta (crear esquema y datos) Criterio de xito: Puedo encontrar al menos una orden con su campo de actualizacin configurado para el da anterior en la tabla orden Secuencia de prueba 2 Intento: Recuperar corrupcin de datos Pasos: 1. En una base de datos del servidor SQL existente, recuperar la copia de seguridad de la cinta del da anterior (sobrescribir datos) Criterio de xito: No hay rdenes que posean su campo de actualizacin configurado para el da de hoy y puedo encontrar al menos una orden con su campo de actualizacin configurado para el da anterior en la tabla orden
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?
Figura 2: Fuentes potenciales de las variaciones del tiempo de ejecucin

Nodo de tiempo de ejecucin
Presentacin Estilo Implementacin perspectiva del usuario Nodo de tiempo de ejecucin
Procesamiento Procedimiento, OO, norma, declarativo Simultneo/paralelo Transaccional Operacin y monitoreo
Administraci n del estado OO, relacional, XML Ubicacin Vigencia
Presentacin
Administracin Procesamiento del estado
Operacin y monitoreo
Comunicacin
Nodo de tiempo de ejecucin Operacin y monitoreo
Presentacin Administracin Procesamiento del estado
Transportar Cambiar Formatear
Nodo de tiempo de ejecucin
Presentacin
Administracin Procesamiento del estado
La Figura 2 es un diagrama que muestra todos los orgenes potenciales de las variaciones del tiempo de ejecucin.
20

Los arquitectos protegen el sistema contra la inestabilidad del tiempo de ejecucin mediante la construccin de abstracciones. Las pruebas deben validar estas abstracciones. Por ejemplo, en los requisitos de alta disponibilidad, una solucin demostrada para la proteccin contra defectos de un servidor fsico es poner en prctica un sistema de fallas. El sistema de fallas posee la capacidad de pasar de un modo automtico a un servidor informtico en espera a partir de la finalizacin anormal o falla del anterior servidor activo. Utilizacin. Estos son los asuntos de tiempo de carga. En esta categora, los arquitectos de infraestructura deben prestar atencin a las variaciones de registro y configuracin. Por ejemplo, para proteger contra los cambios en mecanismos de autenticacin cuando se utiliza Windows como una plataforma, una solucin demostrada es almacenar las credenciales del usuario en Microsoft Windows Active Directory. Implementacin. Las variaciones ms importantes de tiempo de diseo estn relacionadas con inestabilidad en la planificacin y la organizacin (personas). Por ejemplo, los equipos de infraestructura han aprendido el modo de protegerse contra equipos de desarrollo inestables. La implementacin de componentes de mala calidad en la produccin puede ser grave para los acuerdos de nivel de servicio. Una solucin demostrada es establecer un mecanismo de feedback para restaurar rpidamente el sistema al estado estable anterior. No slo se deben documentar los procesos de feedback sino que tambin se deben confeccionar pruebas para expresar el cumplimiento sin ambigedad.
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
Figura 3: Prueba automatizada de PowerShell
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

llegue al cliente. Cuanto antes se detecten los problemas, ms bajo es el costo para solucionarlos ya que el rea de superficie del cambio en menor (es decir, la cantidad de cambios desde la ltima prueba ser limitada). Garantiza fiabilidad: Las pruebas realizan exactamente las mismas operaciones cada vez que se ejecutan, sin ambigedad. Esto puede tener xito o fallar. Proporciona un consenso explcito sobre el cumplimiento y valida continuamente el objetivo del arquitecto. Elimina el error humano y evita el factor de esfuerzo que implican las pruebas manuales en la medida que se acercan las fechas lmite. Genera confianza: La automatizacin brinda un feedback concreto sobre el sistema ya que se puede probar el modo en el que reacciona el software a ejecuciones repetidas de las mismas operaciones. Evita riesgos: Las pruebas automatizadas demuestran la integridad del sistema dentro de un plazo sensato. Las pruebas pueden ejecutarse una y otra vez con menos gastos generales. Mejora la capacidad de mantenimiento: Confeccionar pruebas primero influye en la estructura y crea sistemas modulares. Reduce en gran medida el acoplamiento entre los componentes, disminuyendo el riesgo de que el cambio en un componente obligue un cambio en otro componente. Proporciona documentacin actualizada de un modo sistemtico: Las pruebas son un artefacto operativo que no puede ser excluido de la sincronizacin. Si las pruebas se alejan de la realidad, es imposible ejecutarlas con xito. Las pruebas desactualizadas siempre fallan.
Figura 4: Tabla de Excel y comando de prueba para el servicio meteorolgico de Web
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:
Permite el cambio. En la medida que el sistema de software es ms

grande, se vuelve cada vez ms difcil realizar cambios sin afectar cosas. El riesgo comercial para esta situacin es que uno puede encontrarse en una situacin en la que los clientes piden cosas o el mercado evoluciona de un modo que provoca la necesidad de cambio. Una gran cantidad de comandos de prueba automatizados da libertad a los arquitectos para hacer muchas cosas interesantes. Los arquitectos tendrn menos temor de cambiar las decisiones de diseo existentes. Con la prueba automatizada como una red segura pueden refactorizar la arquitectura, o agregar o cambiar funciones, por ejemplo, sin preocuparse. Lo que descubrir, al invertir en pruebas automatizadas, es que su organizacin realmente avanza ms rpido de lo que sola hacerlo. Puede responder a los cambios del mercado con ms rapidez, introducir funciones de un modo ms dinmico y contar con una organizacin ms slida. La prueba automatizada lo ayuda a: Reducir costos: La prueba automatizada detecta los problemas lo antes posible de un modo eficaz, mucho antes de que el software
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

familia utilizando TikiWiki y PHP. Instal los productos, pero para m no estaban listos para usar inmediatamente. Por lo tanto, tuve que modificarlos. Fue interesante. Otro ejemplo es el jardn de infantes al que asiste mi hija. Me pidieron que configura un sitio de Web utilizando FrontPage, que fue otra experiencia de aprendizaje. Tercero, la capacidad para comunicarse tiene importancia. En realidad la tiene. Es realmente importante comprender el modo de escribir bien y cmo presentar bien. Finalmente, lo ms importante es conectarse con los clientes. Pasar el mayor tiempo posible con ellos. Conocer lo que tratan de hacer y analizar lo que funciona y lo que no. Ayudarlos a utilizar sus productos. No hay nada mejor que dedicar tiempo a los clientes y ayudarlos a resolver sus problemas. Al hacer esto, con frecuencia, nos enterbamos que los clientes utilizaban cosas de un modo que jams hubiramos imaginado que lo haran. Tambin, se nos ocurran nuevas ideas asombrosas. AJ: Quin es la persona ms importante que ha conocido y qu hizo que esta persona sea tan significativa? DF: Cuando me inici en el mundo acadmico y en la Divisin de Investigacin, mi consejero para la tesis (Yechiam Yemini) fue realmente importante. l me ense dos cosas: Las personas perseverantes y decididas a tener xito solemos subestimar la calidad de lo que hacemos. Somos muy exigentes con nosotros mismos. Pensamos que nuestras ponencias no son muy buenas y que nuestra investigacin no es novedosa. Mi consejero me ayud con perspectiva. Segundo, me ense que estas cosas pueden ser entretenidas simplemente divirtanse y disfruten de lo que estn haciendo. l tena un entusiasmo infantil muy contagioso. Adems de mi consejero, hay varias personas en IBM que llegaron a ser grandes amigos y ejemplos a seguir. Tony Storey fue el ms importante. Yo sola analizar a quienes respetaba y con frecuencia trataba de deducir el modo en el que realizaban sus trabajos. Conscientemente trataba de ser como ellos. AJ: Hay algo en su carrera de lo que se arrepiente? Qu aprendi de eso? DF: Wow! Incluso, no s por dnde empezar! Voy a comentar dos: Mi grupo anterior me dio un casco de Darth Vader, por el modo en el que trabajaba los primeros das. Hazlo a mi modo o har explotar tu planeta. El enfoque de Darth Vader no funciona. No se puede hacer que personas inteligentes hagan cosas que no desean hacer. Las personas hacen bien lo que desean hacer. Para m esto era un epitafio. Por qu yo era tan brusco y dominante? Estaba ocupado y en todo lo que poda pensar era Tengo que hacer estas 20 cosas Por qu esta persona no har lo que quiero? Me di cuenta que este enfoque nunca funciona, no importa cunto uno lo intente. Las personas merecan mi tiempo y yo les deba el tiempo. Segundo, muchas personas que trabajan en la tecnologa sufren de la falacia del final del juego Somos todos bastante inteligentes. Dedicamos tiempo a muchos clientes. Analizamos lo que estn haciendo y luego trazamos una lnea hacia el punto en el que estarn en algunos aos. Sin embargo, una vez que se hace esto, es muy tentador construir lo que necesitarn en cinco aos, y no lo que necesitan prximamente o para lo que estn preparados ahora. A veces digo que no tiene sentido construir la Ciudad Esmeralda sin construir el Camino Amarillo de Ladrillos y primero se debe construir el camino. Con frecuencia, haca las cosas muy complicadas, anticipando sus futuras necesidades. Uno de los ejecutivos senior sola decir La visin sin ejecucin es alucinacin y esto es verdad. AJ: Cmo es el futuro de Don? DF: Para responder a esto, tengo otro consejo. Cuando me pregunto esto a m mismo, siempre pongo en primer lugar las realizaciones personales y en segundo lugar las realizaciones profesionales. Si uno no est realizado personalmente, nunca se realizar en su trabajo.
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

Por Jim Wilt
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:
Mantenga una relacin laboral cercana con sus equipos operativos

y de infraestructura desde el comienzo del proyecto ya que ellos pueden identificar anticipadamente potenciales problemas operativos y de seguridad. Varios de los problemas agobiantes que encuentran los desarrolladores de integracin son habituales para un recurso de infraestructura, por eso, utilice su experiencia para agilizar la identificacin y resolucin del problema.
Reconocida y categorizada Comprendida con las repercusiones resultantes Tratada proactivamente

La regla del 90/10 El 90 por ciento de la actividad centrada en soluciones de integracin es de preparacin, configuracin y optimizacin adecuada del entorno de infraestructura y debida seguridad. Los Sistemas Operativos, Servicios de Web, Directorios y Configuracin de las Propiedades de la Aplicacin, as como tambin los Grupos de Aplicaciones, usuario de procesos de host, Inicio de Sesin nico, Permisos de Directorio, Seguridad, etc., todos desempean una funcin en la ejecucin y contribuyen a la frustracin, generalmente asociada con la implementacin de la integracin. Varios desarrolladores de paquetes extensibles y aplicaciones se protegen de tener que preocuparse sobre claves con nombre seguro, el GAC, certificados, encriptacin, hosts en proceso vs. procesos de host aislados y otros tantos factores en los que un desarrollador de integracin debe adquirir mucho dominio y experiencia profesional. El beneficio es que la experiencia de desarrollo de integracin mejorar en gran medida el enfoque del desarrollador progresando con soluciones de aplicacin futuras [normales]. Es decir, las habilidades del desarrollador se afianzan al finalizar una solucin de integracin. El 10 por ciento restante, en la regla del 90/10, queda para que el desarrollador de la integracin resuelva el problema de integracin en
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:
Duplique su LDAP/Active Directory e instale aplicaciones,
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

El mejor lugar de partida para resolver problemas de infraestructura de integracin es la seguridad a travs de permisos y accesibilidad. A para B vs. A para C Las soluciones de integracin, por lo general, comprenden diversos contextos de sistemas. Es bueno comprender los dos tipos principales de problemas de integracin, cmo se resuelven y su complejidad relativa. Problemas de A para B: Una casa, dos sistemas Las caractersticas de los problemas A para B se dan cuando un Sistema B desea comunicarse con un Sistema A. Por lo general, estn en la misma infraestructura, pero no estn limitados a sta (pueden incluir un WAN, VAN, Internet). deben realizar esto mediante un intermediario externo, comn o norma de la industria formato B. Las ubicaciones, por lo general, estn en infraestructuras separadas (Figura 2). Un ejemplo de esta situacin comn se da cuando los socios comerciales utilizan un formato comercial comn XCBL, HIPAA o ANSI X.12 para comunicarse entre ellos, a veces, mediante un VPN. Con frecuencia, el esquema intermediario es de 10 a 100 veces ms grande que el esquema interno que utiliza el Sistema A o C. Estos esquemas intermediarios pueden ser de 1-2MB, lo que da como resultado problemas de estabilidad y rendimiento cuando se incorporan a herramientas de estructuras de integracin empaquetadas en especial, es frustrante cuando el promedio de la carga til de mensajes es slo de 20K (Figura 3). Aparte de estos problemas ms tcnicos, es posible que los dos socios comerciales deban realizar conjeturas para decidir el lugar en el formato intermediario B en el que debe colocar su informacin y en qu lugar su socio comercial ubicar la suya. Adems del hecho de que un formato intermediario, por lo general, contiene duplicaciones que normalmente producen ms confusin respecto de la ubicacin apropiada de la informacin, estas imprecisiones pueden dar lugar a que se cuestione el valor en esta forma de integracin (por supuesto, existe valor, pero a veces puede parecer cuestionable). Esto factores tienden a causar que los problemas de A para C sean mucho ms difciles de resolver, requiriendo una comunicacin mucho mayor entre los socios comerciales para resolver las diferencias de interpretacin con el formato intermediario B. Solucionar los problemas de A para B y A para C
Sistema legado A
Figura 1: Problema de A para B: Dos sistemas, una casa
Sistema distribuido B
Documentar claramente sus expectativas para el formato

intermediario B, proporcionando ejemplos.
Reducir el tamao del formato intermediario B mediante el trabajo

en conjunto con los socios comerciales para acordar un esquema de subconjuntos que incluya slo aquellos componentes que utilizan todos los socios comerciales. Duplicar o triplicar las proyecciones de prueba de los socios comerciales para compensar las interpretaciones errneas del formato intermediario 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
Figura 2: Problema de A para C: Dos sistemas, dos casas
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.
Figura 3: Los escenarios de A para C por lo general comprenden un formato intermediario B
Sistema legado A
Sistema distribuido C
A mapea hacia el formato intermediario B
C mapea desde el formato intermediario B
VAN Formato cannico B Formato estndar de la industria (ANSI, XCBL, HIPAA, HL7, etc.)
Formato intermediario B por lo general inflado, demasiado redundante
27

Los siguientes ejemplos ilustran el modo en el que esto puede suceder: Campos mal utilizados en depsitos de datos El socio comercial A debe proporcionar datos de identidad para el esquema B en el formato que se muestra en la Tabla 1. Lo suficientemente simple, pero el socio comercial A utiliza con creatividad el campo de la Inicial del Segundo Nombre para almacenar aos de datos de servicio, en el que 0-9 representa la cantidad de aos y A representa 10 aos o ms. Cuando se utiliza la Inicial del Segundo Nombre mediante una identidad, el socio
Producir o evaluar informacin que simplemente no existe en ningn

depsito de datos interno.
Interrupcin del trabajo de otros miembros del equipo sobre otras

partes de la solucin cuando se interrumpe un mapeo. Los mapeos del mundo real tienen una apariencia ms parecida a la Figura 5. Las novedades significativas para herramientas de mapeo en el mundo real, como el nuevo XSLT Mapper de BizTalk, han sido demostradas y se ofrecen para mitigar esta tarea tediosa, pero el desafo va ms all de lo que cualquier herramienta determinada est en condiciones de realizar (Ver Recursos). Repeticiones interminables En el desarrollo normal de las aplicaciones, las repeticiones son algo bueno. Con frecuencia, se puede determinar la cantidad de iteraciones que sern permitidas o decidir sobre una tolerancia a la funcin/forma aceptable que desencadenar los prximos pasos. Por lo general, la funcionalidad parcial es aceptable y se pueden utilizar fases para incorporar posteriormente la funcionalidad que falta. Sin embargo, 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. Figura 4: Demo del mapeo de software de integracin
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:
Solucionar el mapeo en el pozo de la desesperacin
No realice suposiciones sobre la dificultad para mapear; siempre
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

Trate sus herramientas de integracin del mismo modo. No todas las soluciones necesitan una Orquestacin. Existen consecuencias de rendimiento cuando se utiliza una Orquestacin. Los mapas se pueden utilizar en Puertos as como tambin en Orquestaciones. A veces, es bueno experimentar la implementacin de varios prototipos de soluciones utilizando varias combinaciones del conjunto de herramientas para comprender las diferencias de rendimiento, mantenimiento y utilizacin. Conozca sus herramientas y utilice slo las necesarias (BizTalk) Haga mejor uso de los modelos de suscripcin/publicacin basados en Puertos; ya que no existe la Orquestacin, este modelo, por lo general, no se tiene en cuenta. Las Orquestaciones son ms eficaces para los flujos de trabajo; a pesar de que poseen una sobrecarga. Las Orquestaciones poseen un gran propsito y son muy eficaces cuando se utilizan para los flujos de trabajo. Realice mapeos dentro de Puertos, no simplemente orquestaciones; sta es otra capacidad que se pasa mucho por alto. Los pipelines pueden ser rpidos y efectivos, considere un Pipeline Component personalizado en vez de una orquestacin reduce las entradas y salidas del buzn de mensajes y elimina la sobrecarga de la orquestacin. Las clases serializadas y el cdigo administrado son con frecuencia una alternativa eficaz para los mensajes y mapas.
Figura 5: Mapeo de datos del mundo real
Comprenda y respete los criterios de ejecucin relacionados con el

mapeo (por ejemplo, debido a que los mapas son secuencias de comandos XSLT, nunca utilice cdigo administrado desde un mapa).
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
Ontologa y Taxonoma de los Servicios en una Arquitectura Orientada a Servicios

Por Shy Cohen
Sntesis Este artculo describe una ontologa y taxonoma para los servicios de una Arquitectura Orientada a Servicios (SOA); analiza la naturaleza y las interrelaciones de los diferentes tipos de servicio, describe un diseo genrico para los sistemas basados en SOA y proporciona orientacin sobre la construccin y administracin de los servicios. La ontologa y taxonoma que se describe aqu brinda un lenguaje comn para arquitectos, ingenieros y personas responsables de la toma de decisiones y facilita la comunicacin dentro y entre las diferentes disciplinas y organizaciones.
servicios existentes mediante el uso de un repositorio de servicios) que adems pueden promover la reutilizacin. Si analizamos la composicin desde el punto de vista comercial, una ontologa y taxonoma comn apropiada puede ayudar en la toma de decisiones relacionadas con el negocio, por ejemplo, cmo obtener una capacidad (Construir vs. Comprar vs. Contratar), cmo administrar servicios (administracin central vs. por aplicacin) y dems. Categoras y tipos de servicios En la medida que examinamos los tipos de servicios observamos dos tipos principales: aquellos que son infraestructurales por naturaleza y proporcionan prestaciones comunes que no se consideraran parte de la aplicacin, y aquellos que son parte de la aplicacin y proveen los bloques de construccin de la aplicacin. Las aplicaciones de software utilizan una variedad de prestaciones comunes que van desde servicios de bajo nivel ofrecidos por el sistema operativo, como administracin de memoria y manejo de I/O, hasta servicios especficos de entorno de tiempo de ejecucin de alto nivel, como la Biblioteca en Tiempo de Ejecucin (RTL), la plataforma Java o la estructura .NET. Las soluciones que se construyen utilizando un SOA, tambin usan prestaciones comunes, como una estructura para la creacin de servicios (por ejemplo, Windows Communication Foundation de Microsoft) y un conjunto de servicios que son parte de la infraestructura informtica distribuida de soporte. Llamaremos a este conjunto de servicios Bus de Servicios (a veces, tambin se los denomina servicios de infraestructura). El Bus de Servicios adems se divide en Servicios de Comunicacin, que brindan la posibilidad de transferir mensajes como publicacin-suscripcin y enrutamiento de mensajes, y Servicios de Utilidad, que proporcionan capacidades no relacionadas con la transferencia de mensajes como deteccin de servicios y federacin de la identidad. La eficacia del desarrollo de aplicaciones de software aumenta an ms mediante la utilizacin de bloques de construccin de alto nivel, de aplicacin general. Los entornos de programacin RAD que surgieron repentinamente en la era orientada al componente (como Delphi de Borland o Visual Basic de Microsoft) brindaban la posibilidad de componer fcil y rpidamente la funcionalidad y capacidades provistas por los bloques de construccin existentes con cdigo de aplicacin especfico para crear nuevas aplicaciones. Ejemplos de estos componentes abarcan desde las abstracciones de acceso a bases de datos y estructuras GUI ms genricas hasta los servicios ms especficos, como por ejemplo el registro de eventos o grficos. Las aplicaciones compuestas en SOA tambin utilizan bloques de construccin de esta naturaleza en su modelo de composicin. Llamaremos a estos bloques de construccin Servicios de Aplicacin. Los Servicios de Aplicacin se dividen en Servicios de Entidad, que exponen y permiten la manipulacin de entidades de negocios; Servicios de Capacidad y Servicios de Actividad, que implementan los bloques de construccin funcionales de la aplicacin (a veces, denominados componentes o mdulos); y Servicios de
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
Categoras de servicios en SOA

atrs y hacia adelante a travs de una barrera de red (es decir, vinculando dos redes de algn modo desconectadas) o a travs de una barrera de protocolo (como trasladar mensajes en cola entre el sistema de cola WebSphere MQ de IBM y el sistema de cola MSMQ de Microsoft). Los ejemplos de Servicios de Comunicacin incluyen retransmisiones/puentes/enrutadores/puertas de enlace, servicios de publicacin-suscripcin y colas. Los Servicios de Comunicacin no contienen ningn estado de la aplicacin, pero en algunos casos estn configurados para trabajar en conjunto con las aplicaciones que los utilizan. Una aplicacin particular puede necesitar establecer o configurar un Servicio de Comunicacin respecto del modo de transmisin de los mensajes que circulan dentro de esa aplicacin, de manera tal que, la comunicacin entre los componentes sea posible en una arquitectura de estructura flexible. Por ejemplo, un enrutador basado en el contenido puede necesitar que la aplicacin proporcione instrucciones de enrutamiento de modo que el enrutador conozca el lugar al que debe enviar un mensaje. Otro ejemplo podra ser un servicio de publicacin-suscripcin que debe enviar mensajes a los suscriptores registrados basndose en un filtro que puede aplicarse al contenido del mensaje. Este filtro deber ser establecido por la aplicacin. En ambos casos, el Servicio de Comunicacin no procesa el contenido del mensaje sino que (opcionalmente) utiliza partes de ste, del modo establecido por la aplicacin, para determinar la ubicacin a la que debe ir. Adems de los requisitos especficos de la aplicacin, las restricciones que impone la seguridad, las normativas y otras fuentes de limitacin, pueden dictar que, para utilizar las prestaciones que Bus de Servicios ofrece un Servicio de Comunicacin particular, los usuarios debern Los Buses de Servicios son prestaciones comunes que no aportan procesar ciertos permisos. Estos permisos pueden establecerse en el ningn valor comercial explcito, sino que ms bien son parte de la mbito de la aplicacin (permitiendo que una aplicacin utilice el infraestructura necesaria para la implementacin de cualquier proceso servicio sin tener en cuenta el usuario que usa la aplicacin), en el de negocio en SOA. Los Buses de Servicios son componentes que mbito del usuario (permitiendo que un usuario especfico utilice el sirven a aplicaciones mltiples, por lo general, construidos de forma servicio sin tener en cuenta la aplicacin que est usando el usuario) o central o adquiridos, y en consecuencia, se administran centralmente. en ambos mbitos (permitiendo que un usuario especfico acceda al servicio mientras ejecuta una aplicacin especfica). Por ejemplo, un Servicios de Comunicacin servicio de publicacin-suscripcin puede estar configurado para Los Servicios de Comunicacin transportan mensajes hacia, fuera de restringir el acceso a temas especficos, permitiendo que slo se y dentro de los sistemas, sin tener en cuenta el contenido de los suscriban usuarios especficos. mensajes. Por ejemplo, un puente puede trasladar mensajes hacia Otras prestaciones al nivel de la aplicacin que pueden ofrecer los Servicios de Comunicacin estn vinculadas al monitoreo, diagnstico y monitoreo de las actividades del negocio (BAM). Los Figura 1: Ejemplo de composicin de servicios en las categoras de servicios Servicios de Comunicacin pueden proporcionar informacin esttica sobre la Servicios de aplicacin, como un anlisis del patrn de Proceso Utilidad Actividad 1 trfico del mensaje (cantidad de mensajes Nube de Internet que circulan a travs de un puente por Capacidad Descubrir minuto), informes de la tasa de error Actividad 2 (cantidad de errores de SOAP que se Identificar envan a travs de un enrutador por da) o indicadores del rendimiento del nivel del Actividad 3 Capacidad 2 Capacidad 3 ... negocio (cantidad de rdenes de compra que ingresan mediante una puerta de Entidad 1 Entidad 2 Entidad 3 enlace de un socio). Si bien pueden ser especficas para una aplicacin en particular, estas capacidades no son diferentes a las propiedades de configuracin que se utilizan para controlar el flujo de mensajes. Habitualmente, esta informacin es proporcionada mediante Bus de Servicios Publicaruna funcin genrica del Servicio de Enrutamiento Cola ... Suscribir Comunicacin, que generalmente debe ser Proceso, que componen y organizan la entidad, capacidad y Servicios de Actividad para implementar procesos de negocio. La Figura 1 exhibe una muestra de la composicin de servicios en las categoras de servicio para la implementacin de un proceso de negocio. En este contexto a modo de ejemplo, se muestra que un Servicio de Proceso organiza tres Servicios de Actividad y dos Servicios de Capacidad. Es bastante normal para los Servicios de Proceso asociar otros varios servicios para implementar un proceso de negocio complejo. En el diagrama, uno de los Servicios de Actividad (Actividad 2) utiliza un Servicio de Capacidad (Capacidad 3) como lo indica la lnea que los conecta. Un motivo posible para esto es que la Actividad 2 puede estar implementando una actividad de pasos mltiples sobre el Servicio de Capacidad, o exponiendo una interfaz de servicio diferente a la del Servicio de Capacidad subyacente. Los Servicios de Capacidad 2 y 3 se implementan sobre los Servicios de Entidad 2 y 3 (respectivamente). Es interesante observar que los Servicios de Entidad 2 y 3 estn accediendo al mismo almacn de datos subyacente. Esto puede darse para exponer diferentes entidades desde un almacn subyacente o para exponer la misma entidad de diferentes formas para que se adhieran a los distintos requisitos que poseen los Servicios de Capacidad 2 y 3 con respecto al modelo de datos. En este contexto a modo de ejemplo, tambin podemos ver que la Capacidad 1 se encuentra fuera del entorno organizacional (como lo indica la nube de Internet), y acta como un recurso interno que est integrado dentro del proceso de negocio que se implementa mediante el Servicio de Proceso.
31

configurada por la aplicacin. La informacin estadstica que se proporciona, por lo general, debe ser consumida por una parte especfica de la aplicacin que sepa lo que hacer con ella (por ejemplo, activar un alerta de seguridad en el centro de datos o actualizar un diagrama relacionado con el BAM en la pantalla de la computadora del CFO). La Tabla 1 resume las caractersticas de los Servicios de Comunicacin. Tabla 1: Resumen de la categora de Servicios de Comunicacin
Servicios de comunicacin Objetivo principal Transporte de mensajes Interfaz No procesa los mensajes de la aplicacin. Puede tener interfaces de administracin y monitoreo Administracin del estado No administra el estado de la aplicacin Transacciones No se aplica (porque no procesa mensajes de la aplicacin) Manejo de errores No se manejan errores relacionados con la aplicacin Seguridad Usuario/Aplicacin/Ambos Gestin/Gobierno Centralizados Modo de construccin Se compra o se construye de modo central
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
Tabla 2: Resumen de la categora de Servicios de Utilidad

Servicios de Utilidad Objetivo principal Interfaz Funcionalidad infraestructural genrica (no especfica de la aplicacin) Interfaz del servicio para exponer la funcionalidad del servicio. Tambin puede tener interfaces de administracin y monitoreo No se administra el estado de la aplicacin. Puede tener su propio estado. Por lo general, no poseen soporte No se manejan errores relacionados con la aplicacin o se realiza con limitaciones Usuario/Aplicacin/Ambos Centralizados Normalmente se compran
Administracin del estado Transacciones Manejo de errores Seguridad Gestin/Gobierno Modo de construccin
32

separadas y proyectar esta informacin como una entidad nica. Tabla 3: Resumen de la categora de Servicios de Entidad En algunos casos, generalmente por Servicios de entidad conveniencia, los implementadores del servicio de Objetivo principal Exponer y administrar las entidades de negocio entidad optan por exponer los datos subyacentes Interfaz Operaciones especficas de dominio y CRUD en el mbito de la entidad como conjuntos de datos en vez de datos de XML Administracin del estado La administracin del estado de la aplicacin es el objetivo principal muy esquematizados. Si bien los conjuntos de datos Transacciones Atmica y/o Patrn de Reserva no son entidades en el sentido estricto, estos Manejo de errores Compensacin del error limitada (Afecta SLE y SLA) servicios an se consideran Servicios de Entidad por Seguridad Usuario/Aplicacin/Ambos razones de clasificacin. Gestin/Gobierno Centralizados Los usuarios de Servicios de Entidad pueden Modo de construccin Interno/compra/contratacin necesitar que se les configure un permiso para utilizar el servicio, ya sea en el mbito del usuario, de la aplicacin o de la aplicacin-usuario. Estos permisos pueden realizan mediante tarjeta de crdito, o un bloque de construccin de aplicar restricciones sobre los cambios y/o acceso a datos en el nivel valor agregado como un servicio de evaluacin que puede procesar y de la fila (entidad) o la columna (elemento de la entidad). Un calcular la evaluacin del usuario respecto de cualquier cosa que pueda ejemplo de restriccin en el nivel de la columna sera que una ser evaluada (sin la necesidad de una pgina de ayuda, un libro, un aplicacin HR pudiera tener acceso a ambos elementos de la entidad proveedor, etc.) en cualquier aplicacin que utiliza evaluaciones. Los del empleado, seguridad social y domicilio particular, mientras que un Servicios de Capacidad pueden dividirse an ms por el tipo de servicio servicio de impresin de cheques slo tendra acceso al elemento de que brindan (por ejemplo, interfaz de terceros o bloques de domicilio particular. Un ejemplo de restriccin en el nivel de la fila construccin de valor agregado), pero esta distincin complementaria sera una aplicacin de informe de gastos que permite a los gerentes est fuera del alcance de este anlisis. ver y aprobar informes de gastos para los empleados que les rinden Los Servicios de Capacidad exponen una interfaz de servicio cuentas, pero no para los empleados que no les rinden cuentas. especfica para la capacidad que representan. En algunos casos, una La compensacin de error en los Servicios de Entidad, en la capacidad de negocio recientemente adquirida o existente (legado) mayora de los casos, est limitada a buscar fuentes alternativas de puede no cumplir con el modo que posee la organizacin de exponer datos, si las hubiera. Por ejemplo, si un Servicio de Entidad no puede capacidades como servicios, o incluso, puede no exponer una interfaz acceder a una base de datos local, puede tratar de obtener una copia de servicio en absoluto. En estos casos, la capacidad normalmente se remota de la base de datos para conseguir la informacin necesaria. empaqueta con una capa de servicio ligera que expone el API de la Para soportar la consistencia del estado del sistema, los Servicios de capacidad utilizando una interfaz de servicio que se adhiere al modo de Entidad pueden admitir transacciones atmicas distribuidas exponer capacidades que tiene la organizacin. Por ejemplo, algunas estrechamente acopladas. Los servicios que admiten transacciones empresas que prestan servicios de procesamiento de tarjetas de atmicas distribuidas participan en transacciones que les circulan los crdito presentan un API basado en HTML que requiere que el usuario solicitantes y estn sujetas a cualquier cambio de estado en el complete un formulario basado en la Web. Una capacidad como sta almacn de datos subyacente para el resultado de estas sera empaquetada a travs de una fachada del servicio administrada y transacciones atmicas distribuidas. Para permitir un grado menor de creada de un modo interno que proporciona un fcil acceso acoplamiento en el cambio de estado, los Servicios de Entidad pueden programtico a la capacidad. La fachada del servicio es poco clara y brindar soporte para Patrones de Reserva de estructura ms flexible, oculta la verdadera naturaleza de la capacidad detrs de ella hasta el ya sea adems de o en vez de admitir transacciones atmicas punto en el que la capacidad subyacente puede ser reemplazada sin distribuidas. cambiar la interfaz de servicio que se utiliza para accederla. Por lo Los Servicios de Entidad con frecuencia se construyen de un modo tanto, se considera que la fachada del servicio es el Servicio de interno, como un contenedor, sobre una base de datos existente. Capacidad y la capacidad subyacente es simplemente un detalle de Estos servicios, por lo general, se implementan mediante la escritura implementacin de la fachada de servicio. de cdigo para distribuir registros de las bases de datos hacia Por lo general, los Servicios de Capacidad no administran entidades y exponerlos en una interfaz de servicio o mediante el uso directamente el estado de la aplicacin; para realizar cambios de de una fbrica de software para generar el cdigo de distribucin y la estado en la aplicacin, utilizan Servicios de Entidad. Si un Servicio de interfaz de servicio. La Fabrica de Software de Servicios de Web del Capacidad no administra el estado, normalmente, el estado es grupo de Prcticas y Patrones de Microsoft es un ejemplo de esta transitorio y dura por un perodo de tiempo menor que el tiempo fbrica de software. En algunos casos, la base de datos (por ejemplo, necesario para completar el proceso de negocio en el que participa este el SQL Server 2005 de Microsoft) o la aplicacin centrada en datos Servicio de Capacidad. Por ejemplo, un Servicio de Capacidad que (por ejemplo, SAP) pueden brindar de forma nativa prestaciones que brinda presupuestos para el envo de productos podra registrar el permiten el acceso a los datos a travs de una interfaz de servicio, hecho de que los pedidos de presupuestos fueron enviados a quienes eliminando la necesidad de generar y mantener un Servicio de realizan los envos hasta que se devuelva una respuesta, despus de lo Entidad por separado. cual se elimina ese registro. Adems, un Servicio de Capacidad que se Los Servicios de Entidad por lo general se utilizan en ms de una implementa como un flujo de trabajo podr administrar el estado aplicacin compuesta y, por lo tanto, habitualmente se administran transitorio durable de la ejecucin para todas las instancias de ese flujo de forma central. La Tabla 3 resume las caractersticas de los de trabajo que se estn ejecutando actualmente. Si bien la mayora de Servicios de Entidad. las capacidades son sin estado, existen, por supuesto, capacidades como registro de eventos que administran y encapsulan el estado por Servicios de Capacidad naturaleza. Los Servicios de Capacidad implementan las capacidades de la Los usuarios de los Servicios de Capacidad pueden necesitar que se organizacin en el nivel del negocio y representan los bloques de les configure un permiso para poder utilizar el servicio, ya sea en el construccin (accin atmica) centrados en la accin que conforma nivel de la aplicacin, del usuario o de aplicacin-usuario. El acceso a los procesos de negocio de la organizacin. Algunos ejemplos de los un Servicio de Capacidad, por lo general, se concede en el nivel de la Servicios de Capacidad incluyen servicios de interfaz de terceros, aplicacin. Los permisos por usuario, habitualmente, son administrados como un servicio de procesamiento de tarjetas de crdito que se mediante Servicios de Proceso que utilizan los Servicios de Capacidad puede utilizar para la comunicacin con una puerta de enlace de pago para simplificar la administracin del acceso y prevenir fallas de acceso externo en cualquier aplicacin compuesta en la que los pagos se mientras se realiza el proceso.
33

La compensacin de error en los Servicios de Capacidad est limitada a cumplir las Expectativas Tabla 4: Resumen de la categora de Servicios de Capacidad de Nivel de Servicio (SLE) y los Acuerdos de Nivel Servicios de capacidad de Servicio (SLA). Por ejemplo, un servicio de envo Objetivo principal Implementar una capacidad de negocios de valor agregado genrica que normalmente compara los precios y tiempos de Interfaz Interfaz del servicio para exponer la funcionalidad principal entrega de cuatro proveedores (FedEx, UPS, DHL y Administracin del estado Por lo general no contienen estado especfico de la aplicacin un servicio de entregas local de la ciudad, por Transacciones Al no contener estado no hay necesidad de transacciones. Puede ejemplo) puede compensar la falta de disponibilidad implementar el Patrn de Reserva y/o transaccin atmica sobre un de un proveedor ignorando la falla y continuando servicio de entidad con la comparacin de precios que poda obtener, Manejo de errores Compensacin del error limitada (Afecta SLE y SLA) siempre y cuando, recibiera al menos dos Seguridad En el nivel de la aplicacin presupuestos. Este ejemplo demuestra que la Gestin/Gobierno Centralizados Modo de construccin Interno/compra/contratacin compensacin puede dar como resultado un rendimiento ms bajo. Esta degradacin se puede expresar segn el tiempo de espera, calidad del Recursos Humanos y acceda la base de datos protegida del servicio y otros tantos aspectos, y por lo tanto, es necesario departamento de RH para evaluar la elegibilidad para vacaciones. Un describirlos en el SLE y el SLA para el servicio. ejemplo de un Servicio de Actividad que se utiliza para compartir Los Servicios de Capacidad pueden admitir transacciones atmicas funcionalidad sera un servicio de morosos que brinda informacin distribuidas y/o Patrones de Reserva. La mayora de los Servicios de sobre el estado de mora de un cliente para que esta informacin pueda Capacidad no administran recursos cuyo estado debe administrarse ser utilizada por varios Servicios de Proceso dentro de una solucin. utilizando transacciones atmicas, pero un Servicio de Capacidad Al igual que los Servicios de Capacidad, los Servicios de Actividad puede transmitir una transaccin atmica en la que est incluida para exponen una interfaz de servicio especfica para la capacidad que los Servicios de Entidad que utiliza. Los Servicios de Capacidad implementan. Un Servicio de Actividad puede empaquetar una unidad tambin se usan para implementar un Patrn de Reserva sobre de funcionalidad existente, en especial, en casos de transicin en los Servicios de Entidad que no admiten este patrn, y en un grado que un sistema existente con funcionalidad implementada existente mucho menor sobre Servicios de Capacidad que no admiten ese est siendo actualizado para o incluido en una solucin basada en SOA. patrn. Del mismo modo que los Servicios de Capacidad, los Servicios de Los Servicios de Capacidad se pueden desarrollar y administrar de Actividad, por lo general, no manejan directamente el estado de la forma interna, se pueden comprar a terceros y administrar de forma aplicacin; en caso de que lo manejen, ese estado es transitorio y interna, o se pueden contratar a un proveedor externo y consumir existe por un perodo de tiempo menor que el tiempo de duracin del como SaaS que se desarrolla, mantiene y administra de forma proceso de negocio en el que participa el servicio. Sin embargo, ya que externa. Cuando se desarrollan de forma interna, los Servicios de Capacidad su granularidad es un poco mayor y debido a que en algunos casos los Servicios de Actividad se utilizan para empaquetar un sistema pueden implementarse utilizando cdigo imperativo o un flujo de existente, es muy probable que un Servicio de Actividad maneje y trabajo declarativo. Si se implementan como un flujo de trabajo, un encapsule el estado de la aplicacin. Servicio de Capacidad puede ser modelado como una actividad de Los Usuarios de Servicios de Actividad pueden requerir que se les negocio de ejecucin breve (atmica, no episdica). Las actividades configure un permiso para utilizar el servicio, ya sea en el mbito de la de negocio de larga duracin, en las que las cosas pueden fallar o aplicacin, del usuario o aplicacin-usuario. Como en el caso de los necesitar compensacin, por lo general, se incluyen dentro de la Servicios de Capacidad, el acceso a un Servicio de Actividad categora del Servicio de Proceso. Un Servicio de Capacidad es casi siempre utilizado por aplicaciones normalmente se concede en el nivel de la aplicacin y se administra para cada usuario mediante los Servicios de Proceso que estn compuestas mltiples y, por lo tanto, es normalmente administrado utilizando el Servicio de Actividad. de modo central. La Tabla 4 resume las caractersticas de los Los Servicios de Actividad poseen las mismas caractersticas para Servicios de Capacidad. compensacin de error y soporte de transaccin que los Servicios de Capacidad. Los Servicios de Actividad normalmente se desarrollan y Servicios de Actividad administran de un modo interno y pueden implementarse utilizando Los Servicios de Actividad implementan las capacidades en el nivel del negocio o algn otro elemento de lgica de negocio centrado en la cdigo imperativo o un flujo de trabajo declarativo. Como en el caso de accin (bloques de construccin) que son nicos para una aplicacin un Servicio de Capacidad, si se implementa como un flujo de trabajo, particular. La diferencia principal entre los Servicios de Actividad y los un Servicio de Actividad puede ser modelado como una actividad de negocio de ejecucin breve. Servicios de Capacidad es el mbito en el que se los utiliza. Si bien Los Servicios de Actividad, por lo general, son utilizados por una los Servicios de Capacidad son un recurso organizacional, los solucin o aplicacin nica y por lo tanto, normalmente, se administran Servicios de Actividad se utilizan en mbitos mucho ms pequeos, de forma individual, por ejemplo, en el nivel departamental. Si un como una aplicacin compuesta nica o una solucin nica Servicio de Actividad evoluciona en un Servicio de Capacidad, la (compuesta de varias aplicaciones). Con el paso del tiempo y con la administracin del servicio, habitualmente, pasa a un servicio de suficiente reutilizacin en la organizacin, un Servicio de Actividad administracin central. La Tabla 5 resume las caractersticas de los puede evolucionar en un Servicio de Capacidad. Servicios de Actividad. Los Servicios de Actividad normalmente se crean para facilitar la descomposicin de un proceso complicado o para permitir la Servicios de Proceso reutilizacin de una unidad de funcionalidad especfica en diversos lugares en un Servicio de Proceso particular o incluso entre diferentes Los Servicios de Proceso relacionan los bloques de construccin centrados en datos y centrados en la accin para implementar los Servicios de Proceso en la aplicacin. Las fuerzas que impulsan la procesos de negocio de la organizacin. Estos servicios componen la creacin de Servicios de Actividad pueden provenir de diversas funcionalidad que brindan los Servicios de Actividad, Servicios de fuentes, como fuerzas organizacionales, requisitos de seguridad, Capacidad y Servicios de Entidad y los relacionan con la lgica de requisitos normativos y dems. Un ejemplo de un Servicio de negocio que est dentro del Servicio de Proceso para crear el proyecto Actividad que se crea en un contexto de descomposicin es un servicio de confirmacin de elegibilidad para vacaciones que, debido a que define la operacin del negocio. Un ejemplo de Servicios de Proceso es un servicio de procesamiento de rdenes de compra que requisitos de seguridad, separa una parte especfica del recibe una orden de compra, la verifica, controla el servicio de clientes comportamiento de la aplicacin de autorizacin de las vacaciones para que esa parte se ejecute detrs del firewall del departamento de morosos para asegurarse de que es un cliente apto, verifica el crdito
34

Los Servicios de Proceso, por lo general, se desarrollan y se administran de modo interno debido a que capturan la esencia de valor agregado de la Servicios de actividad organizacin, el factor secreto que define el modo en Objetivo principal Implementar una capacidad de negocios especfica en el nivel el que la organizacin realiza sus negocios. Los de la aplicacin Servicios de Proceso se disean para posibilitar la Interfaz Interfaz del servicio para exponer la funcionalidad principal agilidad del proceso (es decir, para que se pueda Administracin del estado Por lo general no contienen estado especfico de la aplicacin actualizar fcilmente) y los procesos que pueden (A menos que contenga y exponga un sistema existente) implementar son normalmente episdicos por Transacciones Puede soportar transacciones atmicas y/o implementar el naturaleza (la ejecucin est compuesta de breves Patrn de Reserva sobre un sistema existente impulsos de actividades espaciados por largas esperas Manejo de errores Compensacin del error limitada (Afecta SLE y SLA) para que se completen las actividades externas). Por lo Seguridad En el nivel de la aplicacin Gestin/Gobierno Por aplicacin tanto, los Servicios de Proceso se implementan de Modo de construccin Interno mejor manera como flujos de trabajo declarativos utilizando un servidor de flujo de trabajo (como BizTalk de Microsoft) o una estructura de flujo de trabajo (como Windows Workflow Foundation de Microsoft). del cliente con el servicio de verificacin de crditos, incluye la orden Los Servicios de Proceso, con frecuencia, son utilizados por una en la lista de rdenes que administra el servicio de rdenes (entidad), reserva los productos con el servicio de inventario (entidad), asegura aplicacin nica y por lo tanto administrados de forma individual (por ejemplo, en el nivel departamental). En algunos casos, un proceso de el pago mediante el servicio de procesamiento de pagos, confirma la negocio reutilizable puede convertirse en un producto que puede reserva realizada con el servicio de inventario (entidad), programa el ofrecerse o consumirse como SaaS. La Tabla 6 resume las envo con el servicio de envos, notifica al cliente sobre la finalizacin exitosa de su pedido y la ETA de los productos a travs de un servicio caractersticas de los Servicios de Proceso. de puerta de enlace de correo electrnico y finalmente marca la orden como finalizada Tabla 6: Resumen de la categora de Servicios de Proceso en la lista de rdenes. Servicios de proceso Los Servicios de Proceso pueden estar Objetivo principal Implementar un servicio de negocios mediante la orquestacin de otros compuestos de flujos de trabajo u otros servicios Procesos de Servicio pero no pueden ser Interfaz Interfaz del servicio dirigida a aplicaciones que enfrentan usuarios recategorizados como capacidades o Administracin del estado Administra el estado del proceso Servicios de Actividad debido a su alcance y Transacciones No posee soporte para las transacciones atmicas. Puede usar su naturaleza de larga ejecucin. transacciones atmicas con los servicios que utiliza. Puede implementar Ya que los Servicios de Proceso un Patrn de Reserva implementan los procesos de negocio de la Manejo de errores El manejo de errores se implementa como parte de la lgica de negocios organizacin, con frecuencia, se los ofrece Seguridad Usuario Gestin/Gobierno Por aplicacin con una interfaz de usuario que inicia, Modo de construccin Interno controla y monitorea el proceso. La interfaz del servicio que exponen estos servicios, normalmente, se orienta hacia el consumo mediante una aplicacin de usuario final y brinda el Conclusin nivel de granularidad adecuado requerido para satisfacer los casos de Para el arquitecto, tener una buena comprensin de las diferentes categoras, ayuda a clasificar los servicios nuevos o existentes, as uso que implementa el usuario que enfrenta puntos de entrada. El como tambin a definir la funcionalidad adecuada que se debe incluir monitoreo del proceso de negocios, a veces, puede requerir una en un servicio especfico para promover la composicin y la interfaz de monitoreo separada que exponga informacin BAM. Por reutilizacin. El proyecto de arquitectura que se define aqu se puede ejemplo, el servicio de procesamiento de rdenes puede informar la utilizar para el diseo de nuevos sistemas as como tambin para la cantidad de rdenes pendientes, en proceso y finalizadas y alguna refactoracin de sistemas existentes. informacin estadstica sobre stas (tiempo medio dedicado al Para las personas que toman decisiones, comprender el valor procesamiento y a la orden, volumen promedio de la orden, etc.). comercial de un componente y su nivel de comoditizacin, facilita Los Servicios de Proceso, por lo general, administran el estado de tomar decisiones sobre construir vs. comprar vs. contratar y puede la aplicacin relacionado con un proceso especfico durante la exponer oportunidades comerciales para hacer que un servicio est duracin de ese proceso. Por ejemplo, el servicio de procesamiento disponible para otros. de rdenes de compra administra el estado de la orden hasta que se completa. Adems, un Servicio de Proceso mantiene y registra el paso en curso en el proceso de negocios. Por ejemplo, un Servicio de Proceso que se implementa como un flujo de trabajo contiene el estado de ejecucin para todas las instancias del flujo de trabajo que se estn ejecutando actualmente. Sobre el autor Los usuarios del Servicio de Proceso pueden requerir que se les Shy Cohen es gerente de programa en el grupo de Sistemas configure un permiso para utilizar el servicio. El acceso a un Servicio Distribuidos de Microsoft. Shy se uni a Microsoft en 1996 y ha de proceso, por lo general, se concede en el nivel del usuario. trabajado sobre diferentes tecnologas en diferentes grupos de la Los Servicios de Proceso muy rara vez soportan la participacin en compaa, siempre fiel a su gran pasin por la informtica distribuida. una transaccin atmica distribuida ya que proporcionan soporte para En los ltimos cinco aos, Shy ha dedicado su tiempo al diseo de actividades de negocio de larga ejecucin (transacciones de larga varios de los aspectos tcnicos y de arquitectura de Windows ejecucin) en las que la compensacin del error ocurre en el nivel de Communication Foundation (WCF). En la actualidad, dirige su atencin la lgica de negocio y la compensacin puede requerir flujos de hacia diversos aspectos relacionados con la creacin de sistemas trabajo humano. Los Servicios de Proceso pueden utilizar distribuidos y brinda orientacin sobre sistemas distribuidos, SOA, WCF transacciones atmicas distribuidas cuando recurren al servicio que y Servicios de Web as como tambin tecnologas de flujo de trabajo. usan. Tambin pueden implementar el patrn de reserva. Tabla 5: Resumen de la categora de Servicios de Actividad THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net 35
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:
Consumidor del servicio
invoca
invoca
invoca
Proveedor del servicio
invoca
invoca
Cambio
Proveedor 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
Permite servicios inalterables. El servicio puede brindar mtodos
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:
Esto requiere que cada mtodo se implemente de modo
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
servicemethod (XML in, XML out)

Por consiguiente, la interfaz del mtodo del servicio nunca cambia y no se debe considerar en la definicin del versionado. Debido a que
Versionado en esquemas XML

El modo ms simple de indicar versiones en esquemas XML es utilizar un atributo (opcional) en el elemento versin xs:schema. El modelo del contenido permite la clasificacin Dewey de los nmeros de versin major.minor (principal.secundaria) Ya que no se requieren analizadores de XML para validar las instancias que utilizan la versin, es posible implementar una representacin personalizada de la versin, permitiendo que el analizador la incluya en el proceso de validacin. Habitualmente, el uso de esta tcnica requiere la introduccin de un atributo de versionado como valor fijo, requerido para identificar una versin del esquema especfica. Sin embargo, este enfoque para el esquema de versionado no es muy prctico. Existen varias desventajas: principales. Este enfoque se ajusta bien con la generacin de cdigo serializado, permitiendo generar cdigo en diferentes paquetes (espacios de nombres), posibilitando, de este modo, que un consumidor del servicio nico trabaje simultneamente con varias producciones principales del esquema. Incluso, otra opcin es mantener constantes los valores de los espacios de nombres de XML y agregar un elemento especial para agrupar las extensiones personalizadas. Este enfoque contiene extensiones para el vocabulario subyacente dentro de un elemento de extensin especial. Est tcnica es favorecida por varios esquemas de la industria estndar. Por ejemplo, los Open Application Groups Business Object Documents (OAG BODs) incluyen un elemento <userarea> que define informacin personalizada que tal vez no es parte del vocabulario base. Este enfoque optimiza la extensibilidad de las estructuras del esquema (los esquemas pueden ser compatibles con versiones anteriores o futuras) sin la introduccin de espacios de nombres nuevos. Existen dos desventajas para este enfoque:
Una instancia de XML no podr utilizar mltiples versiones de la
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
Introduce significativamente niveles ms altos de complejidad dentro

del esquema.
No permite la implementacin de extensiones mltiples entre las

diferentes porciones de la instancia de XML ya que todas las extensiones deben agruparse dentro del contenedor de extensiones.
El enfoque ms escalable para el versionado de esquemas es el siguiente:
Componentizacin del esquema total en particiones lgicas utilizando

espacios de nombres mltiples, por lo tanto, contiene cambios.
Definicin de un espacio de nombres nuevo (que refleje informacin
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.
Cambiar la posibilidad de opcin de un elemento local o una

referencia de un elemento de requerido a opcional
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:
Cambiar el tipo de un elemento local o global a un tipo nuevo,

derivado del original, agregando/restringiendo elementos opcionales Cambiar la posibilidad de opcin de un elemento local o una referencia de un elemento de opcional a requerido Agregar o eliminar un valor de enumeracin Eliminar o dar un nuevo nombre a un elemento o tipo global.
La nueva implementacin del servicio soporta exactamente la misma
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.
Figura 2: Implementacin del versionado con el uso del pacto
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.
Invocar Servicio/ Mtodo/ Versin con carga til adecuada
Direccin terminal mtodo servicio
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

Arquitectura de Infraestructura

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Arquitectura de Infraestructura

Caricato da

Copyright:

Formati disponibili

Aprenda la disciplina, ejerza el arte y contribuya con sus ideas en

www.ArchitectureJournal.net Recursos que sirven de base

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

que sirven de base. www.architecturejournal.net

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Arquitecturas de alta disponibilidad para hosting masivo

Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael Johnson

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Arquitecturas de alta disponibilidad para hosting masivo

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Arquitecturas de alta disponibilidad para hosting masivo

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Arquitecturas de alta disponibilidad para hosting masivo

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Arquitecturas de alta disponibilidad para hosting masivo

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Brindar informtica integral de alta productividad

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Informtica de alta productividad

Utilizar ms o mejor hardware. Los beneficios de los procesadores

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Informtica de alta productividad

Ciencia ambiental de alta productividad integral

Interfaz de Web del cliente

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Informtica de alta productividad

Figura 3: Escenario de autora general

Figura 4: Escenario de administracin general

Inicio de sesin: El usuario debe poder iniciar la sesin de la

Automtico: Si bien es probable que los resultados de la tarea

Carga: Un usuario debe poder cargar o acceder a grupos de datos

Preproceso: El paso de preproceso para un trabajo puede realizar

Actividades: Un desarrollador puede querer construir actividades o

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Informtica de alta productividad

Catlogo: Despus del desarrollo de actividades, algoritmos y

Monitoreo: Por lo general, los clsteres son recursos compartidos

Trabajo en serie: sta es una tarea de procesamiento habitual que

Flujo de tareas: Varios trabajos en serie compuestos de mltiples

Usuario Aprobacin Postproceso Descarga

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Informtica de alta productividad

Consideracin de la cadena de valor

Es posible que el usuario deba tener cierto conocimiento del

Planificacin para un trabajo de larga ejecucin. Las reducciones de

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Informtica de alta productividad

Acceso Inicio de sesin

Usuario Aprobacin Postproceso Descarga

Anlisis paramtrico: Este tipo de trabajo podra ejecutar varias

Flujos de trabajo de estado y en secuencia: El tiempo de ejecucin

Comunicacin del clster. Es posible crear una actividad

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Informtica de alta productividad

Biblioteca de flujos de trabajo y actividades para controlar el clster

Almacn de archivos Callogo de flujos de trabajo DB Persistencia DB

La experiencia de usuario principal para planificar y ejecutar un

Actividades del trabajo de clster fuertemente tipeados, de ms