Journal12 Spanish

Aprenda la disciplina, ejerza el arte y contribuya con sus ideas en
www.ArchitectureJournal.net Recursos que sirven de base
Arquitectura de Web
Web 2.0 en la empresa Entrega de software eficaz a travs de plataformas de distribucin de servicios Comunicacin segura entre dominios en el explorador Modelo orientado a aplicaciones para datos relacionales Perfil del Architecture Journal: Pat Helland Confianza en los datos a travs de la Web Complementos administrados: control avanzado de versiones y hosting confiable
Contenido
Prlogo
Por Simon Guest
1 2
Web 2.0 en la empresa

Por Michael Platt
Descubra los elementos para las personas, datos y tecnologas de una arquitectura de Web 2.0 y el modo en el que se pueden utilizar dentro y fuera de la empresa.
Entrega de software eficaz a travs de plataformas de distribucin de servicios

Por Gianpaolo Carraro, Fred Chong y Eugenio Pace
Explore el uso de una plataforma de distribucin de servicios para posibilitar la entrega de software eficaz para la Web.
Comunicacin segura entre dominios en el explorador

Por Danny Thorpe
14
Los exploradores en la actualidad no funcionan de forma eficaz a travs de mltiples dominios. Aprenda una nueva tcnica para desarrollar sitios de Web que pueden compartir informacin.
Modelo orientado a aplicaciones para datos relacionales

Por Michael Pizzo
Con frecuencia, la forma de los datos en una base de datos no coincide con la aplicacin con la que interactan. Vea el modo en el que se puede utilizar un modelo conceptual para superar esto.
19
Perfil del Architecture Journal: Pat Helland
26
Pat Helland es arquitecto en el grupo de Visual Studio de Microsoft. Actualcese sobre su carrera y sobre sus pensamientos respecto de llegar a ser arquitecto.
Confianza en los datos a travs de la Web

Por Peter Hammond
Existen varios patrones para el intercambio de datos a travs de la Web. Conozca a partir de una serie de experiencias las recomendaciones y los riesgos que se pueden evitar.
28
Complementos administrados: control avanzado de versiones y hosting confiable

Por Jesse Kaplan
33
Entrese sobre algunos de los conceptos avanzados de arquitectura con los que cuenta la prxima versin de .NET Framework que admite un modelo de complementos confiable y flexible.
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:
Bienvenidos a la edicin 12 del Journal. El tema esta vez es Arquitectura de Web. Estoy seguro que no es necesario explicarles la importancia que ha adquirido la Web en los ltimos aos para los arquitectos de casi todas las organizaciones. Sin embargo, despus de haber hablado con varias personas sobre el diseo para la Web, he descubierto que un tema comn es la necesidad de adaptar, de tomar los principios de arquitectura que se han aplicado en el pasado y refactorizarlos para la Web. Como consecuencia, trat de tener esto presente cuando seleccion los artculos para esta edicin. Comenzamos esta edicin con el tema de Web 2.0 en la empresa, con un autor habitual, Michael Platt. Michael analiza algunos de los principios de las personas, datos y tecnologas de la Web 2.0 y a continuacin los clasifica de acuerdo al modo en el que se pueden utilizar dentro y fuera de la empresa. Sigue un artculo de Michael, Gianpaolo Carrazo, Fred Chong y Eugenio Pace en el que presentan el concepto de una Plataforma de Distribucin de Servicios. Basados en su trabajo en el rea de Software como Servicio, tratan lo que es necesario para posibilitar la entrega de software eficaz a travs de la Web de hoy en da. Danny Thorpe del equipo de Windows Live contina con un artculo que explora algunas de las complejidades de la comunicacin entre dominios en el explorador. Mediante el uso de una analoga novedosa, Danny analiza una serie de tcnicas que se pueden utilizar para superar este desafo. Tambin contamos con un artculo excelente de Michael Pizzo sobre un modelo orientado a aplicaciones para datos relacionales. Siendo los datos una enorme parte de varias aplicaciones en la Web, Michael nos lleva a travs de algunos desafos que presentan los esquemas de aplicaciones y bases de datos de la actualidad e introduce un marco para integrarlos de un mejor modo. En la introduccin de la ltima edicin, mencion un colega mo del pasado, Pat Helland. Para esta edicin, me puse al da con Pat, quien recientemente ha regresado a Microsoft como arquitecto en el equipo de Visual Studio. Le pregunt a Pat el rol que va a desempear y algunos de sus originales pensamientos sobre la forma de llegar a ser arquitecto. A continuacin de la entrevista de Pat, contamos con un artculo de Peter Hammond. Peter nos transporta en un viaje a travs de los ltimos 10 aos mediante un anlisis de algunos problemas de datos con los cuales se relacionarn varias personas y presenta una tcnica para el intercambio confiable de datos a travs de la Web actual. Para concluir esta edicin, tenemos la fortuna de contar con un artculo de Jesse Kaplan. Jesse nos lleva a travs de algunas consideraciones de arquitectura de la prxima versin de .NET Framework y presenta un modelo para la creacin de complementos confiables y flexibles. Bien, esto finaliza otra edicin. Hablando de adaptacin, en The Architecture Journal siempre probamos cosas nuevas, mucho en funcin de sus opiniones. Si tienen algn comentario o ideas para los prximos temas y artculos, esperamos con mucho gusto sus noticias para brindarles una mejor publicacin. Pueden contactarnos en editors@architecturejournal.net.
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: Access, Excel, Microsoft, Outlook, Power Point, SQL Server, Visual Studio, Windows, Windows Server y Xbox LIVE. 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. 2007 Microsoft Corporation. Todos los derechos reservados.
Simon Guest
THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Por Michael Platt
Sntesis Los modelos tradicionales sobre cmo las personas publicaban y consuman informacin en la Web han trascendido radicalmente en los ltimos tiempos. En vez de simplemente visualizar informacin en pginas de Web estticas, en la actualidad, los usuarios publican su propio contenido mediante blogs, wikis y sitios para compartir videos y fotos. Las personas colaboran, intercambian opiniones y forman comunidades en lnea y tambin combinan datos, contenido y servicios desde mltiples fuentes para crear aplicaciones y experiencias personalizadas. Comn y colectivamente denominados Web 2.0, estos nuevos sitios para compartir contenido, reas de colaboracin e intercambio de opiniones y mashups o patrones de diseo de aplicaciones estn transformando la Web del consumidor. Tambin representan una oportunidad significativa para que las organizaciones diseen nuevos sistemas de negocios, productividad y colaboracin social y basada en la Web y para que mejoren el rendimiento de los ingresos y los gastos. Este artculo analizar cmo la tecnologa, los datos y las personas se unen para formar la Web 2.0; la manera en la que se utiliza en la actualidad la Web 2.0 en el espacio del consumidor y la forma en la que estas tcnicas y conceptos se pueden utilizar dentro y fuera de la empresa para brindar nuevas oportunidades de negocios y productividad.
comprensin colectiva de que la capacidad de utilizar la Web para escribir y leer contenido enriquecido, junto con el soporte para redes sociales y la rpida difusin del acceso de banda ancha, permite a los usuarios interactuar con la Web, con el contenido en lnea, as como tambin, entre ellos. Esto representa un cambio fundamental en la forma en la que las personas interactan con el contenido, las aplicaciones y otros usuarios, la nueva Web es una plataforma para aprovechar y fomentar la inteligencia colectiva. Las personas ya no son simplemente consumidores de contenido y aplicaciones: son participantes, que crean contenido e interactan con diferentes servicios y personas. Cada vez ms, las personas crean sus blogs y a la vez aportan bases de conocimiento como Wikipedia y utilizan tecnologas punto a punto (P2P). Muchas veces, denominado el efecto de la red, este aumento de participacin y creacin de contenido presenta nuevas oportunidades para que el usuario participe ms intensamente, de formas ms significativas. Tim OReilly originalmente defini las caractersticas de Web 2.0: La Web como plataforma Aprovechamiento de la inteligencia colectiva Los datos son el prximo Intel inside Fin de los ciclos de versiones de software Modelos livianos de programacin Software no limitado a un solo dispositivo Experiencia de usuario enriquecida
Estas caractersticas se pueden agrupar en tres reas: uso de la Web como plataforma, la Web como un lugar para leer y escribir abundante contenido y el uso colaborativo y social de la Web. La Web como plataforma Los sistemas de Web 2.0 usan la Web como plataforma, como una gran variedad de dispositivos interconectados que pueden brindar un nuevo nivel de experiencia enriquecida e inmersiva para el usuario, un modelo de programacin liviano y fcil de utilizar para el desarrollador y un mecanismo de implementacin rpido y flexible para el proveedor. Web 2.0 vuelve a concebir Internet desde la perspectiva del usuario, el desarrollador y el proveedor, cada uno de los cuales permite nuevos y creativos usos de Internet. El concepto de servicio se aplica para todos los sistemas conectados, incluida, por supuesto, la Web 2.0. Un sistema basado en servicios se basa en el principio de separacin de incumbencias mediante el uso de paso de mensajes o acoplamiento escaso. El acoplamiento escaso permite que la funcionalidad se cree como un servicio y se entregue sobre una red, por ejemplo, en el mundo de Web 2.0, se puede brindar funcionalidad diaria mediante un motor de blog y se puede entregar como un servicio para el usuario final o los bloggers en Internet. Esta entrega de funcionalidad de software
Web 2.0 Las aplicaciones de Web han experimentado importantes cambios en la ltima dcada; diez aos atrs, no existan las aplicaciones o sitios de intercambio en la Web, simplemente, haba sitios compuestos de pginas estticas o aplicaciones de comercio electrnico. Las compaas que tenan sitios de Web orientados a clientes podan conectarse con consumidores expertos en Internet y utilizar sus sitios de Web como canales para ingresar al mercado y vender sus productos; las intranets corporativas se utilizaban principalmente para publicar noticias y polticas de la compaa. Ms recientemente, los sitios de Web se han convertido en destinos para que las comunidades de usuarios creen y compartan datos complejos y muy variados, como por ejemplo, msica, imgenes y videos y para que analicen y evalen ese contenido. Este fenmeno se denomin Web 2.0 en un documento de anlisis de gran influencia de Tim OReilly, en septiembre de 2005, y sigue expandindose en la actualidad. En resumen, Web 2.0 es la
www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

en Internet comnmente se denomina Software como Servicio (SaaS) y soporta la mayora de los sistemas Web 2.0 de la actualidad. Cuando se considera Internet como una plataforma, se observa que debe ofrecer una cantidad importante de elementos de plataforma, como por ejemplo, independencia de dispositivos, interfaz de usuario comn y enriquecida, una interfaz de programacin comn y un mecanismo de gestin e implementacin de servicios y software. Software no limitado a un solo dispositivo Es muy comn que el software de un servidor brinde servicios para el software de una PC (en Windows o en un explorador) que a continuacin se consumen o exhiben. Si bien ste es un modelo bien conocido, no incluye una cantidad de casos comunes, como por ejemplo, los sistemas P2P o la entrega para dispositivos que no sean PC como reproductores de msica, telfonos o dispositivos de navegacin. Se necesita un modelo que incluya estos casos y comprenda un nivel de servicio ms alto que el HTTP bsico para conectarlos, es necesario tratar los conceptos de un servicio de msica como iTunes o Napster o un servicio de telefona como Skype. El modelo debe poder contemplar el software por sobre el nivel de un solo dispositivo y un servicio nico, pero a la vez, debe incluir servicios de alto nivel, enriquecidos que interconecten una red de diferentes tipos de dispositivos de forma simtrica. Probablemente, el mejor ejemplo para este tipo de servicio de alto nivel sea Xbox Live, en el que los servicios para el juego se proporcionan entre dispositivos de hardware especializado que trabajan punto a punto. Este modelo es el caso de propsito general de la informtica basada en servicios y es lo que Microsoft denomina modelo de informtica de Software y Servicios. Experiencia de usuario enriquecida El valor de la experiencia de usuario inmersiva y enriquecida se ha comprendido bien en el mundo de la PC desde la llegada de Windows y ha sido por varios aos el objetivo de las aplicaciones basadas en un explorador, junto con la presentacin de JavaScript y DSTML como formas ligeras de ofrecer la funcin de programacin en el cliente y una experiencia de usuario ms rica en lo que comnmente se denomina Rich Internet Applications (RIA). La capacidad de la Web para brindar esta funcionalidad de RIA fue primero demostrada por Outlook Web Access (OWA) que utilizaba JavaScript y DHTML para proporcionar una total interactividad equivalente a la de Windows en el explorador. La recopilacin de tecnologas que se utilizaban para proporcionar estos sistemas dinmicos y enriquecidos, basados en un explorador, se denomina Ajax, que significa JavaScript Asncrono y XML. Ajax no es una sola tecnologa, ni tampoco un conjunto de nuevas tecnologas, sino varias tecnologas que se incorporan de formas poderosas, completamente nuevas para proporcionar la funcionalidad de RIA. Ajax incorpora: Presentacin basada en estndares con el uso de XHTML y CSS Visualizacin e interaccin dinmicas mediante el Modelo de Objetos de Documento Intercambio y manipulacin de datos mediante XML y XSLT Recuperacin asncrona de datos, con el uso de XMLHttpRequest JavaScript como nexo de unin de todas estas tecnologas. Ajax es el componente clave de la mayora de las aplicaciones de Web 2.0 y brinda la capacidad de crear aplicaciones de Web tan ricas y dinmicas como las aplicaciones de Web basadas en Windows, de hecho, esperamos la llegada de aplicaciones basadas en Ajax que funcionen an desconectadas de Internet y, por lo tanto, que proporcionen funcionalidad sin conexin similar a la de clientes basados en Windows, como Outlook. Adems de Ajax, existen otros tipos de tecnologas que aumentan el valor de la experiencia del usuario en reas como comunicaciones, voz y video. La mensajera instantnea (MI) se utiliza en gran medida en las aplicaciones de Web 2.0 para ofrecer comunicaciones instantneas y existe una gran variedad disponible de opciones de entrega y agentes para los sistemas MI. Los sistemas de protocolo de voz sobre Internet (VOIP) permiten la comunicacin de voz y teleconferencia sobre Internet como parte de la experiencia del usuario. Y por ltimo, la transmisin de videos en tiempo real, almacenados, completa la experiencia del usuario. La variedad, riqueza y flexibilidad que proporcionan estas tecnologas transforman la interfaz de usuario ms all de una interfaz de usuario dinmica hacia una total experiencia visual auditiva interactiva, y an se analizan nuevas formas poderosas para que las personas interacten con los sistemas y entre s. Modelos livianos de programacin En Web 2.0, las tcnicas, conceptos y modelos de programacin son muy diferentes de aquellos que se han utilizado en la empresa. Si bien estn basados en servicios y fundamentalmente en el concepto de paso de mensajes, utilizan los protocolos de transferencia de estado representacional (REST- Representational State Transfer) y tratan la simplicidad y facilidad de uso. La programacin en Web 2.0 est basada en el concepto de separacin de incumbencias a travs del uso de un modelo de paso de mensajes, de estructura flexible, por sobre un conjunto de protocolos de comunicacin estndar, basados en Internet (HTTP), que por lo general se denomina programacin RESTful. Esto comprende actos de sindicacin y composicin en los que se proveen servicios sin conocimiento de su uso. Esto es muy diferente de un sistema convencional, orientado al objeto, transaccional y estrechamente acoplado. Posee beneficios diferentes, como por ejemplo, flexibilidad y rapidez de implementacin, as como tambin distintos desafos, como integridad y administracin. Los lenguajes, como Perl, Python y Ruby, y las estructuras que se utilizan en la Web 2.0, son simples y dinmicos, lo que a su vez ofrece pocos obstculos para la entrada y reutilizacin as como tambin una alta productividad. Las estructuras poseen soporte incorporado para los patrones comunes de diseo, como Modelo, Vista y Controlador (MVC) y metodologas, como desarrollo de software gil. Son rpidas y fcil de aprender y usar y permiten lograr importantes resultados en la productividad. Las aplicaciones de Web 2.0 son componibles y agrupables por naturaleza; debido a que se crean con modelos de programacin livianos y servicios basados en estndares, se pueden crear nuevas aplicaciones mediante la composicin o agrupacin de los servicios y aplicaciones existentes. Los mashups son aplicaciones y servicios que se componen en la IU; la composicin es el caso ms general de servicios que se reutilizan, pero ambos se admiten con facilidad en la programacin de Web 2.0. Fin de los ciclos de versiones de software Los conceptos detrs de Web 2.0 logran un nuevo equilibrio entre la facilidad administrativa y control de los sistemas centralizados y la integracin del usuario y flexibilidad de los sistemas distribuidos. Las aplicaciones de Web, por naturaleza, se implementan de modo central, por lo tanto, los servicios centrales pueden administrar aplicaciones y escritorios completos de forma automtica. SaaS se basa en este concepto para proporcionar la idea de entrega de servicios y software en Internet. Web 2.0 toma como base SaaS para brindar servicios sociales y de contenido sobre un mecanismo de SaaS. Este uso de SaaS a travs de Web 2.0, como una metodologa de liberacin e implementacin, brinda todos los beneficios conocidos de SaaS: implementacin simple, administracin y gestin minimizadas y

probablemente lo ms importante: actualizacin continua. Por lo tanto, una de las caractersticas ms difundidas de Web 2.0 (y de SaaS) es el concepto de que los sistemas se actualizan y mejoran constantemente, por lo general, en tiempo real como respuesta a las solicitudes de los usuarios. Por supuesto, el problema con esta beta constante es que la comunidad de Web 2.0 an debe resolver el modo en el que los servicios o aplicaciones sin conexin o posteriores pueden verse afectados cuando los servicios o datos sobre los cuales depende una aplicacin de Web 2.0, desaparecen o cambian. Web de lectura/escritura La segunda rea importante de Web 2.0 es el nfasis sobre los datos y el contenido, y en particular, la capacidad de las personas de crear e interactuar con contenido enriquecido en vez de simplemente consumirlo. Si la Internet original proporcionaba acceso de lectura a datos, entonces, Web 2.0 proporciona acceso de lectura y escritura a los datos desde cualquier fuente. Esta capacidad para que cualquier persona cree contenido ha causado un aumento vertiginoso de la disponibilidad del contenido de cualquier fuente, y de todo tipo de calidad, y al mismo tiempo, ha creado un nuevo grupo de problemas sobre vandalismo, propiedad intelectual e integridad de los datos. A medida que aumenta la disponibilidad de banda ancha para el usuario final, la riqueza del contenido que se puede enviar por Internet es cada vez mayor. La Internet original se trataba de texto; la Web 2.0 comenz con msica e imgenes y avanz hacia voz y video. En la actualidad, la televisin y las pelculas son las reas de contenido que se investigan como parte de Web 2.0. A medida que las personas y organizaciones buscan, cargan y descargan todo este contenido y datos explcitos en la Web, al mismo tiempo crean una gran cantidad de datos implcitos sobre lo que hacen y hacia dnde se dirigen. Estos datos implcitos o de navegacin de Web 2.0 se pueden utilizar para predecir el comportamiento futuro o para proporcionar nuevas caractersticas basadas en esos datos. ste es el modo en el que funcionan la mayora de los motores de bsqueda; siguen de cerca las consultas que realizan las personas y utilizan estos datos para prever lo que las personas buscarn en el futuro. Por supuesto, la recopilacin, almacenamiento y uso de estos datos implcitos aumenta las cuestiones desafiantes sobre titularidad, privacidad y propiedad intelectual (PI) que an se deben tratar de un modo satisfactorio. Otro problema que surge con la gran cantidad de datos en la Web es encontrar las cosas y las formas de navegarlas. Los motores de bsqueda utilizan datos implcitos, o clasificacin de pginas, para encontrar datos de texto, pero esto no funciona muy bien con los datos de audio o imgenes. Adems, en varios casos, el motor de bsqueda no posee la suficiente informacin contextual como para brindar un resultado vlido. En esto casos, el etiquetado de los datos se vuelve una forma valiosa de colaborar con la navegacin de los datos. Las aplicaciones de Web 2.0 utilizan mucho el etiquetado y las nubes de etiquetas como un modo de encontrar y navegar a travs de la gran cantidad de datos disponibles en la Web. Una etiqueta es informacin acerca de datos, o metadatos, y uno de los problemas ms importantes con los datos y el contenido en la Web es el que provoca la falta de estndares para los metadatos y esquemas. Es imposible cortar y pegar algo tan simple como una direccin en la Web porque no existe un formato estndar para las direcciones. Es necesario comprender los distintos niveles de metadatos as como tambin contar con estndares de lo que significan esos metadatos para poder liberar datos en la Web, y en particular, permitir aplicaciones para los datos compuestos. Esta estandarizacin de metadatos en la Web es lo que trata de brindar la organizacin Microformats. Web social y colaborativa El tercer elemento clave de los sistemas de Web 2.0 es el concepto de debate, colaboracin, comunidad y redes sociales. Las personas, por naturaleza, desean comunicarse, compartir y debatir; esta comunicacin es parte fundamental de la comprensin, el aprendizaje y la creatividad. El elemento exclusivo que aporta la Web 2.0 es el de comunidad y redes sociales que, por lo general, se implementan mediante blogs, grupos de debate y wikis. En la Web 2.0, la mera escala y cantidad de personas en Internet crean una arquitectura de participacin en la que la interaccin entre las personas genera informacin y sistemas que mejoran cuanto ms se usan y cuanto ms personas los utilizan. Este aprovechamiento de la inteligencia colectiva crea sistemas que poseen ms y mejor informacin de la que cualquier persona podra generar; brinda la sabidura de las masas. Existen diferentes tipos de colaboracin que pueden ocurrir en los sistemas de Web 2.0: Basada en el contenido: Las personas se renen y colaboran sobre noticias o contenido, por lo general, en entornos como espacios o blogs. Basada en el grupo: Las personas se renen de acuerdo a una idea o inters, como por ejemplo un hobby, y debaten en un foro. Basada en el proyecto: Las personas trabajan en conjunto sobre un proyecto o tarea comn, como por ejemplo un proyecto de desarrollo, un libro, o incluso, algo tan grande como una enciclopedia que utiliza wikis.
Estos tres tipos de colaboracin son todos admitidos por los sistemas de Web 2.0. Web 2.0 en la empresa Las organizaciones de todo tipo y dimensin, desde nuevos emprendimientos hasta las 100 mejores empresas incluidas en Fortune y todos los sectores verticales de la industria han experimentado el crecimiento vertiginoso en la Web de sitios sociales y colectivos en el espacio del consumidor, como por ejemplo MySpace, YouTube y el diluvio de sitios Web 2.0. Las empresas han visto los avances que realizaron los protagonistas ms importantes como Amazon, eBay, Live, Google y Yahoo para incluir elementos sociales y colectivos, y el inters y la demanda que esto ha generado. En la actualidad, realizan una investigacin activa y en varios casos, crean nuevos negocios y portales que se basan en la comunidad, para sus propias organizaciones. Web 2.0 avanza hacia la empresa. Las organizaciones estn interesadas en el uso de tcnicas de Web 2.0, fundamentalmente en dos reas: dentro de la organizacin para mejorar la eficiencia y productividad y desde la organizacin hacia los clientes, para mejorar la satisfaccin de los clientes y los ingresos. El uso de Web 2.0 dentro de las organizaciones se denomina Empresa 2.0 y probablemente sea la primer rea en la que las organizaciones utilicen Web 2.0. El uso de la Web 2.0 en las empresas para enfrentarse a los clientes y consumidores es similar a la actividad de Empresa a Consumidor (B2C) pero con un objetivo social y colectivo, por lo tanto, se denomina Empresa a Comunidad, o B2C 2.0. El inters de este uso de comunidad como cliente crece rpidamente. Empresa 2.0 Empresa 2.0 Web 2.0 en la empresa es un trmino acuado por el Profesor MacAfee de la Hardvard Business School en el 2006 que describe el uso de las tcnicas de Web 2.0 dentro de la organizacin para mejorar la productividad y eficiencia. Mediante la adopcin de las tcnicas de Web 2.0, los trabajadores de informacin, al igual que sus homlogos consumidores, pueden controlar sus propias experiencias de usuario con menos orientacin por parte de la informtica, y por lo tanto, pueden crear para ellos mismos un entorno de trabajo ms intuitivo y eficaz. El resultado final es la satisfaccin, moral y productividad del trabajador mejorada. Si se comprenden y se implementan de forma adecuada, los patrones, mtodos y tecnologas de Web 2.0 se pueden utilizar en la empresa con muy buenos resultados, lo que mejora la eficiencia y productividad de

toda la organizacin. En esta seccin, analizamos algunos elementos de Web 2.0 que posibilitan esto. Experiencia de usuario enriquecida Brindar a los usuarios una nica experiencia de usuario para todas sus necesidades aumenta la productividad, disminuye los costos de capacitacin y estimula un uso y adopcin ms intensos. Esto incluye el acceso a informacin, ya sea con o sin conexin, con el uso de un dispositivo mvil o una laptop o con el uso de un cliente liviano o inteligente. El soporte para la experiencia de usuario enriquecida que proporcionan Ajax y los subsistemas de grficos, como Silverlight, hacen posible la experiencia de usuario enriquecida que las personas esperan de los sistemas actuales. Modelos livianos de programacin Uno de los principios de Web 2.0 es el concepto de aplicaciones creadas por el usuario o mashups, de aplicaciones generadas por el usuario con el uso de modelos livianos de programacin. Esto promete brindar un cambio radical a las limitaciones y obstculos asociados con aplicaciones que genera la informtica. Con las tcnicas de Web 2.0, los usuarios pueden crear con facilidad aplicaciones especficas para sus propias necesidades. Sin embargo, muchas estrategias actuales de aplicacin compuesta no cumplen con las expectativas ya que se enfocan simplemente en colocar aplicaciones en una interfaz Ajax (IU) y no brindan una verdadera aplicacin para el usuario. Para aprovechar la oportunidad de aplicaciones orientadas al usuario, las empresas deben proporcionar a los departamentos y a los usuarios un entorno administrado y herramientas conocidas que les permitan crear o personalizar con facilidad sus propias soluciones y espacios de trabajo. Fin de la implementacin y ciclos de versiones de software El uso bsico de Internet como plataforma en la Web 2.0 permite la distribucin simple, rpida y flexible de aplicaciones y datos en toda la organizacin, lo que libera al usuario de ciclos de actualizaciones informticas determinados e inflexibles y permite un nuevo nivel de sensibilidad y soporte organizacional para el usuario. Web de lectura/escritura Los datos y documentos son fundamentales para cualquier organizacin y los sistemas basados en servicios como Web 2.0 permiten la creacin, modificacin e intercambio de datos y documentos con una complejidad muy reducida y facilidad de uso mejorada. Los sistemas de colaboracin, administracin de contenido y provisin de datos que pueden admitir el formato de contenido enriquecido y tcnicas sociales de la Web 2.0 son fundamentales para el uso de la Web de lectura/escritura en la empresa. Web colaborativa Las empresas que tienen grandes bases de empleados, asociados y clientes durante mucho tiempo se han dado cuenta del valor que posee el conocimiento que existe en las mentes de los empleados, as como tambin en bases de datos y documentos sin estructura que se encuentran en toda la organizacin. En el pasado, se han realizado con distintos grados de xito, varios intentos de recopilar esta informacin dentro de sistemas de administracin, pero las tecnologas de Web 2.0, como blogs, wikis y bsquedas empresariales de personas y datos pueden facilitar la administracin del conocimiento y proporcionar una nueva plataforma para la colaboracin en tareas creativas y complejas. Sin embargo, debe tenerse en cuentea que el obstculo real para la administracin del conocimiento se debe ms a problemas sociales y de valor de la organizacin que a problemas tcnicos (las tecnologas de Web 2.0 no tratan estos obstculos, por lo tanto, no est claro si Web 2.0 posibilitar de un modo exitoso la administracin del conocimiento en la organizacin). En conclusin, se pueden utilizar varias tecnologas de Web 2.0 en organizaciones, en reas como las de desarrollo rpido de aplicaciones mediante el uso de una administracin del conocimiento basada en wikis, blogs y mushups. Empresa a comunidad (B2C 2.0) Las reas de uso de Web 2.0 en la empresa que poseen el mximo potencial de impacto desde la perspectiva organizacional y de ingresos son las reas de la organizacin que tratan con el cliente; es posible que con el uso de las tcnicas de Web 2.0 cambie todo el ciclo CRM (Gestin de Relacin con el Cliente), ventas y contacto con el cliente. En marketing, la oportunidad de brindar una interactividad estrecha con el cliente y medios de comunicacin interactivos y enriquecidos mediante wikis y blogs proporcionar nuevas formas de contactar y participar con posibles clientes. En ventas, el uso de nuevos dispositivos con factor de forma, como telfonos celulares, para interactuar con el cliente durante todo el proceso de venta, es otra rea importante para el nuevo desarrollo. En atencin al cliente, la participacin de expertos de la comunidad que ayuden con la resolucin de problemas a travs de grupos de debate, crea modelos de soporte totalmente nuevos. Las razones para este inters son: Crecimiento e ingresos. Se pueden crear nuevas fuentes de ingresos y presentar fuentes de ingresos mejoradas mediante una red social y colectiva. En particular, la contencin de costos de los ltimos cinco aos ha dado paso a que los negocios se interesen por el crecimiento e ingresos basados en la innovacin. El rpido crecimiento e innovacin en el espacio de Web 2.0 es visto como algo que las compaas desean imitar. Economas de escala basadas en la Web. Las compaas ven que pueden reducir radicalmente los gastos de personas y equipos de capital mediante el uso de un modelo de entrega basado en la Web para las comunidades de sus clientes. Las compaas B2C 2.0 planean soportar a cientos de miles de clientes con slo cientos de empleados. Modelos flexibles de empleo. El uso de personal de agencias y contratos para la entrega permite flexibilidad y agilidad. El personal por contrato y de agencias puede concebirse como otra comunidad especializada y puede respaldarse con las tcnicas de Web 2.0, al igual que los clientes. Creacin de la comunidad como evangelismo y soporte. Los clientes son la mejor organizacin del desarrollo, soporte, marketing y ventas de una empresa. La creacin de comunidades realmente terceriza estos centros de costos, sin costo alguno. De hecho, con la incorporacin a la comunidad de publicidad especfica, varios de estos centros de costos presentes pueden llegar a ser centros de beneficios. Ventaja lder para la comunidad. La dinmica de la comunidad es tal que la primera comunidad exitosa es con mucha diferencia, la ms poderosa y la organizacin que posee esa comunidad es la que controla el espacio. Si los competidores de una organizacin son los primeros en el espacio de la comunidad, contarn con ventajas competitivas muy importantes.
Existen cinco reas en las que se pueden utilizar las tcnicas de Web 2.0 en el trabajo con comunidades de clientes para proporcionar una Empresa a Comunidad:

Desarrollo de nuevos productos e innovacin Un gran porcentaje de las ideas de nuevos productos e innovacin en la organizacin surgen de los clientes y proveedores ms que del desarrollo e investigacin internos de las organizaciones. Es muy probable que estas ideas de nuevos productos que generan los clientes tengan xito ya que han surgido de los usuarios finales del producto. Es evidente que las organizaciones que creen un sistema que junte estas ideas pueden obtener beneficios significativos. El uso de comunidades de proveedores y clientes basados en Web 2.0, como por ejemplo foros de debate y grupos de anlisis de marketing para la incubacin e ideas de productos nuevos es una tcnica poderosa para reunir ideas de un modo simple y rentable. Muchas organizaciones investigan activamente el uso de grupos de debate y foros para comunidades en el proceso de desarrollo de productos. Un beneficio adicional de este desarrollo de nuevos productos basados en la comunidad es que los clientes poseen una mejor comprensin del producto o servicio que se les entrega si participan de su desarrollo y por lo tanto, la aceptacin del cliente hacia el nuevo producto se mejorar de forma significativa. Marketing Probablemente, la aplicacin ms conocida de las tcnicas de Web 2.0 en la organizacin est en los departamentos de marketing como marketing viral. Los ejemplos de comunidad y contenido enriquecido, como los videos que se utilizan para generar y difundir euforia sobre los productos, son innumerables. Existen dos elementos para este marketing viral: generacin de inters inicial y a continuacin, difusin del virus. La generacin de inters inicial se logra de mejor manera con el uso de contenido de pelculas y video e imgenes novedosas; no es raro obtener millones de descargas de un video creativo a las horas o das de haberlo publicado, y se puede mantener el inters constante sobre un producto si se incorpora al contenido un elemento tutorial o divulgativo. La divulgacin de este material en general la realiza la comunidad de Internet mediante el uso de MI, correo electrnico y foros de la comunidad. Una vez ms, esta divulgacin puede ser muy rpida y de gran alcance. Un video atractivo de un nuevo producto o servicio puede pasarse a millones de personas en horas y puede aparecer en los medios de comunicacin ms conocidos, como la televisin o diarios, en das. Sin embargo, existen algunas advertencias sobre el marketing viral: Primero, se debe comprender bien el pblico al que va dirigido, y an as, el material puede no generar la atraccin e inters de la comunidad. Segundo, una organizacin puede no controlar la divulgacin o uso del material; el uso de las tcnicas de marketing viral que realiza la comunidad de modos imprevistos est bien documentado y puede crear importantes problemas para una organizacin. Ventas El costo de la venta es, por lo general, una parte significativa del costo total de un producto o servicio. En una organizacin Empresa a Comunidad 2.0, la comunidad acta como el personal de ventas, por lo tanto, el costo de ventas disminuye radicalmente, en varios casos a cero. Los mismos clientes actan como interlocutores y vendedores para la organizacin. En empresas basadas en la comunidad, no hay necesidad de programar ventas de alto costo o tcticas de alta presin; en varios casos, esto es contraproducente y de hecho, frustra las ventas. Soporte Soporte es la segunda rea ms conocida para el uso de las tcnicas de Web 2.0. Primero, existe el uso de tcnicas de chat o mensajera instantnea para que la organizacin cuente con soporte en tiempo real de los productos. Segundo, cuenta con el uso de captura de imgenes y videos para la resolucin y comunicacin de los problemas. El uso de grupos de debate de autoayuda y expertos del producto basados en la comunidad es la tercera y ms importante rea: se ha demostrado que la autoayuda funciona muy bien en las comunidades y es una forma de muy bajo costo para brindar soporte de altsima calidad. Sin embargo, al igual que con la mayora de los sistemas basados en la sociedad, el procedimiento real de estos grupos de autoayuda no es simple y requiere mucha experiencia profesional y reflexin. Capacitacin y educacin Probablemente, el uso menos analizado de Web 2.0 en la empresa es el de capacitacin y educacin. La disponibilidad de videos e imgenes de alta calidad proporciona un modo simple y econmico de brindar capacitacin y material de demostracin. La integracin de este contenido de alta calidad con expertos en la materia de la comunidad y grupos de debate activos proporciona un entorno de capacitacin y educacin simple y poderoso. Si bien en la actualidad ha habido relativamente poca actividad en el rea de capacitacin y educacin, con seguridad crecer de manera notable en el futuro. Las organizaciones estn aprendiendo a ver a sus clientes y empleados como comunidades con las cuales mantienen una relacin en lnea, as como tambin fuera de lnea, en un ciclo de ventas basado en una comunidad variada: Un establecimiento comercial de especialidad minorista puede tener una presentacin interna que llevar a cabo un experto nacional y crea una comunidad en lnea sobre un tema de inters que moderar ese experto. Como parte del debate en lnea, los miembros de la comunidad visitan el establecimiento comercial para ver elementos de inters particular y a continuacin, piden esos elementos en lnea dentro de un esquema de beneficios para la comunidad. Conclusin En resumen, las reas de comunidad y contenido rico de Web 2.0 son en la actualidad utilizadas por las organizaciones de un modo exitoso, ya sea de forma interna, para la reutilizacin y captura del conocimiento, as como tambin de forma externa para crear comunidades de clientes. Si bien la mayora del inters en la actualidad reside en la reutilizacin y captura de conocimiento, an existen importantes problemas sociales y culturales para implementar estos sistemas de forma exitosa, que las tcnicas de Web 2.0. no resuelven. El rea que menos se investig del uso de comunidades de clientes posee una promesa mucho mayor para las organizaciones, e incluso est acompaada de sus propios riesgos asociados sobre PI y vandalismo, que an deben tratarse. En general, el uso de las tcnicas de Web 2.0 en la empresa promete tener un efecto profundo y de gran repercusin sobre el modo en el que las organizaciones trabajan de forma interna y externa, lo que posibilitar la creacin de medios completamente nuevos y poderosos para obtener, vender y respaldar clientes como comunidades. Sobre el autor Michael Platt es director de Estrategia de Arquitectura de Web para el grupo de estrategia de arquitectura de Microsoft Corp. en Redmond. Posee amplia experiencia en el diseo de aplicaciones empresariales y de Web para grandes empresas multinacionales, y tambin 30 aos de experiencia en la industria informtica. Michael ha estado en Microsoft por 10 aos en diversas funciones de gestin, estrategia, pre-venta y consultora. Posee un Diploma con Honores en Ingeniera en Electricidad y Electrnica, as como tambin varias patentes y disertaciones publicadas.
Entrega de software eficaz a travs de plataformas de distribucin de servicios

Por Gianpaolo Carraro, Fred Chong y Eugenio Pace
Sntesis La entrega de software como servicio (SaaS) ha cobrado gran impulso. Uno de los motivos por el cual este modelo de entrega uno-a-muchos es atractivo es que posibilita nuevas economas de escala. Incluso, la economa de escala no surge automticamente, debe disearse de forma explcita dentro de la solucin. Un patrn de arquitectura tpico que permite la economa de escala es multi-alquiler de instancia nica y muchos Vendedores Independientes de Software (ISVs, sus siglas en ingls) que ofrecen SaaS han cambiado a esta arquitectura, con diversos niveles de xito. Sin embargo, existen otros medios para mejorar la eficacia que los ISVs no han adoptado con el mismo entusiasmo: el uso de una Plataforma de Distribucin de Servicios (SDP) subyacente. La adopcin ha sido lenta principalmente debido a que las plataformas de distribucin de servicios que se optimizan para la distribucin de aplicaciones de lnea de negocio an se encuentran en sus inicios. Pero ambos protagonistas, nuevo y existente, en el espacio de hosting crean capacidades atractivas con rapidez. Este artculo investiga las metas, capacidades y motivaciones para la adopcin de una SDP y describe la tecnologa y procesos relacionados con la entrega de software eficaz a travs de una SDP.
Economas de escala y arquitectura de aplicaciones Los sistemas operativos evolucionaron como un modo de simplificar la administracin, operaciones y desarrollo de aplicaciones. En vez de requerir que cada aplicacin (re)cree el grupo completo de subsistemas necesarios para que se ejecuten con los niveles de calidad esperados, un sistema operativo proporciona una infraestructura en la que los servicios de aplicacin de propsito general, comunes se codifican y se reutilizan. Por lo general, estos servicios son complejos desde el punto de vista tcnico y requieren destrezas especializadas y experiencia profesional para el desarrollo. Los ISVs comprendieron con rapidez la propuesta de valor de un sistema operativo y estandarizaron su desarrollo en funcin de uno o dos sistemas operativos. El aprovechamiento de la infraestructura subyacente comn les permiti dedicar ms tiempo a la parte de dominio especfico de la aplicacin, que a fin de cuentas, es por lo que pagan quienes compran software. Hay casos en los que las necesidades especficas de una aplicacin van ms all de lo que ofrece un sistema operativo de propsito general. En estas circunstancias se reemplazan partes del sistema operativo con mdulos desarrollados a medida que proporcionan el nivel de soporte especfico. Por ejemplo, las bases de datos habitualmente crean sus propios sistemas de archivos, y en el caso del Servidor SQL de Microsoft, su propia gestin de memoria y programador. Pero estas necesidades especficas son escasas. Las empresas y los ISVs continuamente extraen desde sus soluciones hacia estructuras de aplicacin horizontal. Estas estructuras brindan componentes (y procedimientos) adicionales, compartidos, comunes, abstrados, que producen una mayor reutilizacin y productividad y, en general, un entorno operativo y de desarrollo ms predecible.
EL FLUJO DESCENDENTE DE LAS CAPACIDADES HORIZONTALES DESDE EL PLUMBING DEL ISV HACIA ESTRUCTURAS Y HACIA PLATAFORMAS PRINCIPALES, PUEDE GENERALIZARSE AN MS PARA ABARCAR LOS ESCENARIOS DE SOFTWARE QUE SE DISTRIBUYE COMO SERVICIO. EN ESTE SENTIDO, UNA SDP SE VUELVE UN SISTEMA OPERATIVO PARA LA DISTRIBUCIN DEL SERVICIO.
El problema de crear estructuras enriquecidas es que con frecuencia no contribuyen directamente para el valor del software en s mismo. Son un mal necesario que facilitan el mantenimiento de la aplicacin a ms largo plazo y los ISVs y empresas prefieren que otro se encargue de ellos. Esto reafirma una situacin beneficiosa para ambas partes en la que plumbers pueden vender y concentrarse en funcionalidades horizontales para que los expertos de dominio se concentren en funcionalidades verticales en las que la propuesta de valor para el comprador es mayor. Seamos realistas, nadie compra una solucin porque tiene un mejor mecanismo de manejo de excepciones. Como muestra la Figura 1, existe un proceso continuo y natural de extraccin y generalizacin de funcionalidad desde aplicaciones hacia estructuras y desde estructuras hacia componentes de la plataforma principal. Al aumentar la cantidad de componentes compartidos, este flujo mejora las economas de escala. El flujo descendente de las capacidades horizontales desde el plumbing del ISV hacia estructuras y hacia plataformas principales, puede generalizarse an ms para abarcar los escenarios de software que se distribuye como servicio. En este sentido, una SDP se vuelve un sistema operativo para la distribucin del servicio, que se especializa en los requisitos y caractersticas horizontales de las aplicaciones que se distribuyen como SaaS. Las compaas de hosting tradicionales son candidatos naturales para implementar y ofrecer una SDP debido a su trayectoria, experiencia profesional, conjunto de habilidades y base instalada. Sin embargo, es posible que otros participantes consideren ingresar a este espacio emergente. Los ISVs que en la actualidad hostean ellos mismos sus soluciones de SaaS podran considerar la
Plataformas de distribucin de servicios

Figura 1: Extraccin de concordancia dentro de una plataforma reutilizable
Una Apl Otra Apl
Una Apl IU + BizLogic Una Apl IU + BizLogic + Infraestructura de la Apl Infraestructura de la Apl SO
Almacena miento
Otra Apl IU + BizLogic Infraestructura de la Apl
IU + BizLogic
IU + BizLogic
Estructura de la aplicacin comn SO
Almacena miento
Seguridad
..
Seguridad
...
Almacena miento
Seguridad
...
HW
HW
HW
monetizacin del entorno de hosting propio que crearon para ellos mismos si lo ofrecen como un entorno de distribucin de Saas de propsito general. Los integradores de sistemas que poseen excelencia operativa de nivel mundial obtenida a travs de sus ofertas de tercerizacin de procesos de negocio podran aprovechar este conocimiento en el espacio de SaaS de rpido crecimiento.
rampa, documentacin completa, SDKs e interfaces bien diseadas, cdigo de muestra, plantillas, asistentes y contenido para capacitacin. Cabe observar que los cuatro atributos mencionados previamente no estn hechos para representar un modelo de madurez. Las observaciones de las ofertas de SDP existentes parecen indicar que se ofrecen actualmente dos estrategias: una estrategia de amplitud, optimizada para brindar una plataforma integral, exhaustiva que abarca cada paso del ciclo de vida tpico de una aplicacin distribuida a travs de SaaS (Ver Figura 2), aunque con cobertura secundaria en algunas capacidades; una estrategia de profundidad, que trata slo ciertas etapas, pero ofrece caractersticas sofisticadas sobre stas. El mismo estudio tambin indica que el atributo de facilidad de uso an no est totalmente incorporado en las ofertas ya que varios de ellos dependen de procesos especficos e intensivos de humanos. Arquetipo de aplicacin: Puede una SDP aplicarse a todas las aplicaciones empresariales? Las aplicaciones empresariales se pueden clasificar en diferentes arquetipos segn sus caractersticas y requerimientos. Algunos ejemplos de estos arquetipos son los siguientes: Sistemas de procesamiento transaccional en lnea (OLTP): Se caracterizan por el corto tiempo de espera, alta sensibilidad, integridad de datos, flujos de trabajo predefinidos de IU. Ejemplos de estos arquetipos son: sitios de comercio electrnico, sistemas de banca electrnica y sistemas de CRM. Sistemas de anlisis o procesamiento analtico en lnea (OLAP): Se caracterizan por su capacidad para producir consultas analticas complejas y altamente adaptables a las necesidades del usuario sobre un conjunto de datos multidimensional, con tiempo de respuesta mnimo. Los sistemas BI forman parte de esta categora. Sistemas por lotes: Son capaces de realizar operaciones sobre grandes conjuntos de datos de un modo eficaz, lo que permite la coordinacin de trabajos para maximizar la utilizacin del CPU con polticas de recuperacin para las excepciones. Cada uno de estos grupos de aplicaciones posee sus propias limitaciones, caractersticas y patrones ptimos de diseo que se pueden aplicar para resolver los desafos que presentan. Con mucha
EL PUNTO CLAVE ES QUE LA EFICACIA DE SDP DEPENDE EN GRAN MEDIDA DEL ARQUETIPO QUE SE SIRVI. CUANTO MS CONOCIMIENTO DE LA APLICACIN POSEE UNA SDP, MAYOR ES SU CAPACIDAD PARA AUMENTAR LA EFICACIA AL EJECUTARLA Y OPERARLA Y MAYOR ES EL GRADO DE USO COMPARTIDO.
Factores de xito de una SDP El factor de xito de una SDP est determinado por los siguientes atributos: 1. Capacidades operativas bsicas: Capacidad para brindar Acuerdos de Nivel de Servicios (SLAs) slidos sobre requisitos no funcionales como disponibilidad (tiempo de funcionamiento y tolerancia a fallas), escalabilidad y recuperacin de desastres y sobre caractersticas de servicio genricas, como presencia geogrfica mltiple, atencin al cliente 24/7 y seguridad fsica en mltiples capas. 2. Profundidad de los servicios: Grado de sofisticacin de los servicios que se brindan, por ejemplo, soporte de facturacin para mltiples opciones de pago. 3. Amplitud de los servicios: Integridad de la plataforma, en otras palabras, el soporte para las diferentes etapas del ciclo de vida de una aplicacin distribuida a travs de SaaS, como servicio de facturacin, organizacin de la aplicacin, servicios para la planificacin de la capacidad y mtodos para la revisin y actualizacin de aplicaciones. 4. Facilidad de uso: Capacidad de uso desde la perspectiva del ISV; en otras palabras, el costo de aprender y utilizar los servicios que proporciona la SDP. Las SDPs de fcil uso poseen poco tiempo de
Plataforma de propsito general
Especializacin de la abstraccin

ofrecen la mayora de los hosters tradicionales en la actualidad. Estos servicios se concentran principalmente en componentes de infraestructura muy genricos, bsicos, como por ejemplo: ISV desarrolla, prueba, verifica una aplicacin proporcionada por SaaS CPU, acceso a la red, caractersticas de El hoster proporciona APIs, herramientas y Diseadores para que los ISVs seguridad en Internet y almacenamiento desarrollen sus aplicaciones sobre la SDP Creacin (discos y bases de datos); y comnmente se las denomina pin, power and pipe. La economa de escala en este escenario est limitada al uso compartido de los niveles ms bajos de infraestructura: ISV desarrolla una nueva aplicacin sobre una SDP, define SLAs y parmetro creacin de centros de datos e operativos infraestructura informtica como equipos El hoster verifica el cumplimiento de las polticas de la SDP El hoster instala la aplicacin en el centro de datos de red y servidores. ImplemenEl hoster proporciona APIs, herramientas y Diseadores para que los ISVs to En este escenario bsico, las aplicaciones tacin desarrollen sus aplicaciones sobre la SDP de los ISVs implementadas utilizan sus propios estndares para la arquitectura de aplicaciones y poco de esto se expone al hoster o es conocido por ste. Se espera El cliente descubre la aplicacin en el mercado del hoster que los ISVs desarrollen y proporcionen su El cliente averigua sobre la aplicacin propia infraestructura de gestin El cliente prueba y compra la aplicacin del ISV multiclientes, infraestructura de seguridad, El agregador empaqueta la aplicacin con otras Venta gestin de clientes, etc. El revendedor vuelve a darle una marca a una aplicacin de etiqueta blanca Los pedidos de servicios de infraestructura, como el registro de un dominio nuevo, un sitio de Web o directorio virtual nuevo, creacin de una nueva base El cliente usa la aplicacin de datos, asignacin de almacenamiento, El cliente personaliza una aplicacin El integrador del sistema personaliza una aplicacin para el cliente por lo general, ser realizan de forma El hoster controla y administra la aplicacin para que cumpla con los SLAs manual o se automatizan con secuencias Uso acordados de comandos personalizadas. El hoster informa y deriva incidentes al ISV Es necesario que el ISV proporcione al hoster instrucciones detalladas para la instalacin e implementacin de la solucin; se requiere el ajuste no estndar mltiple (como manejo de archivos de ISV actualiza la aplicacin configuracin de XML, claves de registro, Servicio de ISV revisa la aplicacin rutas de archivos, cadenas de conexin) ya El hoster actualiza y revisa la SDP mantenique muy poco de la arquitectura de miento aplicaciones es conocida o expuesta al hoster. Estos procedimientos especficos impiden que el hoster ample sus procedimientos hacia miles de aplicaciones frecuencia, estos desafos tienen metas opuestas. Por ejemplo: OLTP ya que debe tratar cada uno como una excepcin.Cada aplicacin es se optimizar para lograr un tiempo de espera mnimo, mientras que, una caja negra de componentes potencialmente opuestos que para los sistemas por lote, el tiempo de espera no es tan importante. compiten de forma inadecuada por recursos compartidos (y limitados), OLTP se expande mejor de forma horizontal y se beneficia de una motivo por el cual varios ISVs solicitan servidores dedicados que arquitectura sin estado, mientras que los sistemas por lote se garanticen el aislamiento total de otras aplicaciones. Sin embargo, los expanden de forma vertical y tienden a ser con estado. Por lo tanto, servidores dedicados van directamente en contra de la meta de eficacia la infraestructura y servicios que soportan a cada una son a travs de una infraestructura compartida. significativamente diferentes. El hoster slo puede observar y actuar sobre amplios indicadores El punto clave es que la eficacia de SDP depende en gran medida para supervisar la solucin. Slo pueden medir contadores de del arquetipo que se sirvi. Cuanto ms conocimiento de la aplicacin rendimiento amplio, general como cantidad de trabajo de memoria y posee una SDP, mayor es su capacidad para aumentar la eficacia al CPU, banda ancha, conflictos con SQL; y tal vez algunos contadores de ejecutarla y operarla y mayor es el grado de uso compartido. rendimiento especficos de la aplicacin que el ISV proporciona segn sean necesarios. Hay muy pocos o ningn mecanismo estndar Capacidades de una plataforma de distribucin de servicios preestablecido para la administracin ms detallada de la aplicacin. La Figura 2 ilustra un ciclo de vida tpico para una aplicacin que se No obstante, muy llamativo, que an con muy poco o sin distribuye a travs de Saas. Cada etapa del ciclo de vida se conocimiento de lo que realiza la aplicacin, los hosters por lo general caracteriza por una cantidad de actividades que realizan el ISV, el pueden proporcionar al ISV informacin detallada sobre el rendimiento hoster y otros participantes que sern ms relevantes en la medida de la base de datos. Esto se debe a que los artefactos de las bases de en que el grado de sofisticacin de las SDPs aumenta (por ejemplo, datos son comunes para todos los ISVs (cada aplicacin posee tablas, integradores de sistemas, revendedores de valor agregado). procedimientos almacenados, ndices, disparadores, vistas, etc.) y la Los cuatro escenarios que se detallan a continuacin describen las plataforma en la que estos artefactos se instancian (el servidor mismo capacidades y experiencias posibles mediante SDPs cada vez ms de la base de datos, como el Servidor SQL) se instrumenta en ese nivel sofisticadas. de abstraccin. Por lo tanto, los hosters pueden proporcionar informes detallados de rendimiento, bloqueo y conflictos e incluso pueden Escenario A: Plataforma de distribucin de Servicios Bsica sugerir mejoras sobre esos artefactos. Las capacidades de la SDP ms simple son bsicamente aquellas que Figura 2: Ciclo de vida tpico de una aplicacin proporcionada por SaaS y actividades asociadas.
Figura 3: Impulsar economas de escala a travs de una infraestructura compartida mejorada

Apl A del ISV Apl A del ISV Apl A del ISV IU + BizLogic Gestin operativa Apl B del ISV IU + BizLogic Apl C del ISV IU + BizLogic
IU + BizLogic
Servicios empresariales Medicin
IU + BizLogic Gestin operativa

Servicios empresariales Medicin
ISV
Servicios empresariales
Facturacin Medicin Mercado Marca
Facturacin
Facturacin
Arquitectura de Apl Registro Excepciones

Almacenamiento en cach
Arquitectura de Apl Registro Excepciones

Almacenamiento en cach
Arquitectura de aplicacin
Registro Manejo de excepciones Vnculo de datos Vnculo de datos
Perfil
Perfil
Derivacin de incidentes
Servicios operativos
HOSTER
Servicios de red
Almacenamiento
Ejecucin
Seguridad
Servicios de red Supervisin de SLA
Almacenamiento
Ejecucin
Seguridad
Servicios operativos
Tolerancia a fallas
Base de datos
Herramientas de Infr.
Supervisin principal
Tolerancia a fallas
Base de datos
Supervisin principal
Planificacin de capacidad
Planificacin de capacidad
Derivacin de incidentes
Infraestructura principal y SO
Infraestructura principal y SP
Hardware
Servidores Discos Red
Hardware
Centro de datos
Centro de datos
AN CON MUY POCO O SIN CONOCIMIENTO DE LO QUE REALIZA LA APLICACIN, LOS HOSTERS POR LO GENERAL PUEDEN PROPORCIONAR AL ISV INFORMACIN DETALLADA SOBRE EL RENDIMIENTO DE LA BASE DE DATOS. ESTO SE DEBE A QUE LOS ARTEFACTOS DE LAS BASES DE DATOS SON COMUNES PARA TODOS LOS ISVS Y LA PLATAFORMA EN LA QUE ESTOS ARTEFACTOS SE INSTANCIAN SE INSTRUMENTA EN ESE NIVEL DE ABSTRACCIN.
El punto principal aqu es que estos artefactos existen en todas las aplicaciones que se basan en bases de datos, sin importar el ISV que las haya creado. A modo comparativo, con el uso de una aplicacin de Web como ejemplo, el nico artefacto que se comparte entre los diferentes ISVs es la pgina Web que se identifica mediante un URL, un elemento de aplicacin demasiado general como para ser administrado de forma eficaz. Preguntas como Qu parte de la pgina demora ms en cargar?, Qu componentes se instancian a travs de una pgina particular? o Cul de estos componentes dependientes causa problemas de contencin o en tiempo de ejecucin?, requieren inspeccin de cdigo, uso de herramientas avanzadas y/o un profundo conocimiento del modo en el que se creo la aplicacin, procedimientos que por naturaleza no se extienden a miles de aplicaciones. Actualizar todo (excepto sistemas operativos bsicos, equipos de red y otras infraestructuras bsicas) requiere procedimientos manuales as como tambin interacciones humanas (correos electrnicos, llamadas telefnicas) entre los hosters y los expertos de ISV.
Las aplicaciones de SaaS que operan en este entorno bsico, por lo general, se implementan mediante el uso de una gran variedad de bibliotecas y pilas de tecnologas no necesariamente compatibles. Por ejemplo, se puede encontrar una aplicacin de VB6 entregada y almacenada mediante Servicios de Terminal, una aplicacin de Web que utiliza diversos componentes en tiempo de ejecucin y estructuras disponibles. En otras palabras, la excepcin es la regla. Este escenario se caracteriza principalmente por el uso compartido de infraestructura operativa. En resumen, las economas de escala en este escenario estn limitadas a componentes de un nivel bastante bajo. Escenario B: Mejora de la eficacia a travs de un conocimiento ms profundo de la arquitectura de aplicaciones. Una cantidad mejorada de componentes compartidos produce niveles ms altos de eficacia, por lo tanto, la pregunta es Cules son los candidatos ms naturales para ser extrados desde aplicaciones hacia la SDP? Los candidatos evidentes son aquellos que hacen referencia a servicios de infraestructura de aplicaciones como por ejemplo: configuracin de aplicaciones, informe y manejo de excepciones en tiempo de ejecucin, registro y auditora, seguimiento, almacenamiento en cach. Cada aplicacin los necesita, incluso, con frecuencia, los ISVs los confeccionan una y otra vez. Un ejemplo de una estructura comn, estndar y ampliamente adoptada de infraestructura de aplicaciones es Enterprise Library de Microsoft. Al exponer pblicamente estos servicios bsicos, la SDP posee una capacidad mucho mayor para automatizar procedimientos comunes y brindar capacidades de gestin operativa ms avanzadas. Por lo tanto, dispone de ajustes ms detallados, personalizacin y resolucin de problemas. Cabe observar que el hoster no necesita comprender en detalle lo que hace la aplicacin, sino ms bien, el
10
Supervisin de SLA
HOSTER
ISV

Figura 4: Reutilizacin mejorada a travs de una infraestructura de aplicacin Escenario C: SDP ms all de la gestin operativa El escenario B es claramente una mejora del A, pero la SDP puede mejorarse an ms si se incorporan servicios de aplicacin ms sofisticados, por ejemplo, provisin de infraestructura avanzada, servicios relacionados con la seguridad (perfiles de usuario, roles de usuario, personalizacin) y nuevos servicios empresariales como: eventos empresariales, medicin de los recursos utilizados por la aplicacin e inteligencia de uso y facturacin. Debido a que los contratos entre servicios y aplicaciones pueden ser muy bien definidos, se pueden establecer SLAs en el nivel de la aplicacin. Los SLAs tradicionales en el nivel superior (como tiempo de actividad, banda ancha y utilizacin de CPU) son necesarios pero no son suficiente. Se pueden comerciar y negociar SLAs mucho ms refinados. Por ejemplo, se puede definir, supervisar e imponer un SLA que difina Crear un nuevo cliente en menos de X minutos. El SDP SDK se puede mejorar an ms para que abarque los nuevos servicios provistos, con implementaciones autnomas de los servicios que permiten el desarrollo fuera de lnea. Por ejemplo, es muy poco probable que el hoster comparta con el ISV el sistema de facturacin completo slo para el desarrollo. El ISV muy probablemente codifique contra un servicio de facturacin modelo con contratos e interfaces equivalentes y una mnima implementacin simulada. La meta aqu es la creacin de un entorno de desarrollo que imite todas las
ISVs
Apl A del ISV IU + BizLogic
Apl B del ISV IU + BizLogic
Apl C del ISV IU + BizLogic
Infraestructura de aplicacin
Registro Configuracin Manejo de excepciones Validacin
HOSTER
Supervisin principal Servicios de red Almacenamiento
Usuarios
Base de datos
Administracin de usuarios
Ejecucin
Seguridad
Hardware
Servidores Discos Redes
Centro de datos
modo en el que lo hace (por ejemplo, Dnde se encuentran las capacidades de SDP con mnima dependencia sobre cualquier cadenas de conexin para la base de datos almacenada? Cmo se implementacin concreta. Esto tambin evita la exposicin innecesaria al pblico de la propiedad intelectual y componentes internos de SDP. notifican y registran las excepciones en tiempo de ejecucin?). Debido a que posiblemente los ISVs desarrollen desde estos APIs, Para confirmar este escenario, se requiere una interaccin e integracin el hoster debe publicar un SDP SDK que incluya documentacin, mucho ms profunda entre el ciclo de vida de desarrollo de software muestras e incluso, algunas herramientas bsicas para que Figura 5: Ejemplo de productos diferenciados para la misma funcin descarguen y utilicen los ISVs. En este escenario, los hosters pueden Una Apl Una Apl claramente ampliar procedimientos operativos bsicos ya que todos ellos son comunes y los casos IU + BizLogic IU + BizLogic excepcionales se convierten en excepciones. Las aplicaciones que no cumplen con los estndares, por supuesto, pueden llegar a ser productos premium para aumentar la fuente de ingresos. Adems, los hosters pueden ofrecer una mayor variedad de servicios SDP Registro Registro diferenciados con diferentes esquemas de monetizacin. Por ejemplo, los hosters saben que todas las aplicaciones registrarn excepciones en tiempo de ejecucin mediante el uso de las mismas polticas y procedimientos, por lo tanto, podran ofrecer en el paquete de hosting bsico, un informe y registro de excepciones en tiempo de ejecucin Visor de registros bsicos, y la escalacin, notificacin y registro de excepciones en tiempo de ejecucin avanzados podran llegar a Panel de ser productos premium. (Ver Figura control 5). Es importante observar que con Producto bsico Producto premium este enfoque la aplicacin del ISV no cambia, ya que toda esta lgica (plumbing) reside en el lado de SDP.
Anlisis y notificacin
11
Figura 6: La implementacin incluye definiciones de cdigo y tiempo de ejecucin
Apl A del ISV
SLA+ Manifest. de implementacin
Apl C del ISV +
IU + BizLogic
Promocin
IU + BizLogic
Registro
Infraestructura de apl.
Manejo de excepciones
Registro
Infraestructura de apl.
Manejo de excepciones
Supervisin principal Servicios de red Almacenamiento Herram. de Infr. Ejecucin Usuarios Base de datos Adm. de usuarios
Supervisin principal Servicios de red Almacenamiento Herram. de Infr. Ejecucin Usuarios Base de datos Adm. de usuarios
Seguridad
Seguridad
Hardware
Hardware
Pre-produccin
EL CONTROL DE VERSIN, GESTIN INTEGRADA DE INCIDENTE, PROMOCIN DE LA VERSIN Y PRUEBA SE OFRECEN A TRAVS DE LA SDP. ESTA INFRAESTRUCTURA POSIBILITA QUE PROGRAMAS COMO BETA TESTERS SE EJECUTEN EN REGIONES CONTROLADAS DE LA SDP Y DE ESTE MODO SE PUEDEN RECOPILAR COMENTARIOS, PATRONES DE USO Y RESOLUCIN DE FALLAS, ANTES DE QUE LAS CARACTERSTICAS SE INCORPOREN A LA VERSIN FINAL.
(SDLC) propio del hoster y del ISV. Tambin en este escenario, la implementacin de soluciones dentro de SDP se realiza mediante procedimientos altamente automatizados y con mnima intervencin manual. Estos procedimientos incluyen caractersticas avanzadas para la configuracin y validacin automtica de los requisitos de la aplicacin (por ejemplo, prerrequisitos, ubicacin de servidores, cadenas de conexin). La implementacin en SDP va ms all de secuencias de configuracin y cdigo para incluir los SLAs negociados, requisitos operativos, como por ejemplo administracin de capacidad automtica y derivacin de incidentes, parametrizacin de la facturacin. La SDP tambin puede proporcionar entornos de prueba en los que se puede ejecutar y verificar la aplicacin antes de promoverla a produccin. Los entornos de prueba permiten simular la facturacin, creacin de clientes, fallas, etc., para permitir el modelado ms complejo de escenarios del mundo real. Esto puede considerarse como pruebas de unidad para los SLAs entre el hoster y el ISV. (Ver Figura 6). De un modo interesante, esto produce una nueva clase de servicios que se pueden ofrecer ms all del tiempo de ejecucin: por ejemplo, la simulacin de fallas, prueba de carga, anlisis de rendimiento, y
Produccin
optimizacin pueden ponerse a disposicin de los ISVs. Los ISVs ms pequeos podran tener acceso a recursos temporarios que seran demasiado costosos como para que los tengan. En la produccin, debido al profundo conocimiento del modo en el que funciona la aplicacin, la SDP puede ofrecer ajustes y capacidades de administracin de recursos automticos. Las SDPs ms avanzadas pueden asignar de forma dinmica nuevos equipos, incorporar CPUs a un clster, asignar mayor ancho de banda para la comunicacin, y cualquier otra infraestructura que sea necesaria para mantener la aplicacin conforme a los SLAs acordados. Ya que las aplicaciones se instrumentan completamente, los hosters pueden ofrecer inteligencia sobre los patrones de uso y un anlisis ms detallado del modo en que funciona y se desempea la aplicacin, lo que posibilita devolver esta informacin (probablemente como un servicio Premium) para el proceso de planificacin del producto de los ISVs. Debido a los procedimientos de implementacin y el aseguramiento de calidad altamente automatizado, los ISVs tienen la oportunidad de ofrecer mejoras para los productos casi en tiempo real sobre la base de la inteligencia recopilada y de mejorar sus productos de forma constante basndose en opiniones de usuarios ms precisas. La venta, marca, empaquetado y agregacin son posibles mediante reglas de composicin bien definidas, por lo tanto, el hoster puede crear productos empaquetados con servicios comunes a travs de diferentes soluciones (como inicio de sesin nico o administracin de roles comunes). Tambin, se permite el uso de etiquetas blancas para que los intermediarios y terceros creen productos personalizados, especializados a partir de la misma base de cdigo. Escenario D: La SDP perfecta La SDP perfecta an no existe. Esta seccin es un poco de extrapolacin y un poco de especulacin. En el escenario ms avanzado, adems de todas las caractersticas descriptas anteriormente, la SDP incluye servicios para la administracin completa del ciclo de vida de la aplicacin, lo que permite una integracin
12

adicional del desarrollo, versionado, implementacin, gestin, operaciones y soporte de una solucin que se distribuye a travs de SaaS, y de este modo posibilita un ecosistema ms amplio para contribuir y colaborar en la entrega de soluciones especializadas. Descubrimiento, conocimiento, intento, desarrollo, ampliacin, versionado, ajuste, son casos de uso que admite la SDP. Esto es una integracin completa del Ciclo de Desarrollo de Software (SDLC) del ISV y del Ciclo de Vida de las Operaciones del Software (SOLC) de SDP. En este escenario, los aspectos de desarrollo de software se ofrecen como servicios mismos: seguimiento de fallas, control de versin de software, prueba de rendimiento, etc. (Figura 7). Todas las capacidades de SDP se expresan en formatos legibles por mquinas. Los modelos de capacidades de la SDP y componentes de software se integran totalmente dentro de las herramientas. Los miembros independientes del ecosistema pueden realizar la verificacin, anlisis y simulacro de estos modelos: ISVs, terceros, intermediarios, empresas, y otros colaboraran en la creacin de sistemas complejos. Los metadatos de aplicacin incluyen no slo parmetros operativos, sino tambin informacin necesaria para promocionar la aplicacin en el mercado de la SDP (el equivalente del registro de aplicacin Agregar nuevo Software que se encuentra en Windows), proporcionar contenido para Ms informacin, contenido de ayuda, documentacin, capacitacin, servicios profesionales adicionales de valor agregado, etc. El control de versin, gestin integrada de incidente, promocin de la versin y prueba se ofrecen a travs de la SDP, lo que permite a los ISVs, intermediarios, integradores de sistemas desarrollar, personalizar y mantener productos simultneos diferentes. Esta infraestructura posibilita programas como beta testers y early adopters para que se ejecuten en regiones controladas de la SDP y de este modo se pueden recopilar comentarios, patrones de uso y resolucin de fallas, antes de que las caractersticas se incorporen a la versin final. El servicio de mercado que proporciona la SDP ofrece un mecanismo para descubrir, aprender y probar nuevos productos y se puede poner a disposicin con el uso de los metadatos que acompaan cada aplicacin. Como mencionamos, pasar algn tiempo para que estas SDPs avanzadas lleguen a ser populares. Conclusin Las SDPs representan una nueva oportunidad interesante para que los hosters tradicionales creen productos diferenciados, de alto valor, lo que reduce las exigencias de ingresos para que una mayor cantidad de ISVs ofrezcan soluciones con niveles operativos de primera clase. Los primeros en tomar la iniciativa en esta nueva categora de mercado atraern una gran cantidad de ISVs, en especial, aquellos en segmentos de pequeas a medianas empresas o nichos que no pueden econmicamente hostear ellos mismos debido a su conjunto de habilidades o factibilidad financiera de sus modelos de negocio. El Grupo de Estrategia de Arquitectura de Microsoft investiga de forma activa el desarrollo de guas de arquitectura para ayudar a los ISVs, hosters y empresas a que se beneficien de los servicios y software, mediante el aprovechamiento de la plataforma de Microsoft.
Recursos MSDN Architecture Development Center http://msdn.microsoft.com/architecture SaaS Section on MSDN Dev Center http://msdn.microsoft.com/architecture/saas LitwareHR A sample SaaS-delivered application developed, por Equipo de Estrategia de Arquitectura de Microsoft http://www.codeplex.com/litwarehr
Sobre los autores Gianpaolo Carraro es director de Entrega de Servicios, en el Equipo de Estrategia de Arquitectura de Microsoft. En su funcin, lidera el pensamiento SaaS y las mejores prcticas en arquitectura para Microsoft. Antes de desempearse en Microsoft, Gianpaolo fue cofundador y arquitecto jefe de un nuevo emprendimiento especializado en SaaS y ms atrs en el tiempo fue miembro del equipo tcnico de los Laboratorios Bell. Gianpaolo ha publicado varios trabajos y es orador frecuente en las conferencias de TI internacionales ms importantes. Descubra ms sobre su persona visitando su blog en http://blogs.msdn.com/gianpaolo Fred Chong es arquitecto en el Equipo de Estrategia de Arquitectura de Microsoft, es reconocido en la industria como un experto en el tema sobre arquitectura SaaS. Anteriormente, ha diseado e implementado protocolos de seguridad y componentes de red para soluciones cliente y productos de Microsoft. Fred ha realizado una investigacin en el Centro de Investigacin T.J. Watson de IBM y en la Universidad de California en San Diego. Consulte su blog en http://blogs.msdn.com/fred_chong Eugenio Pace es arquitecto en el Equipo de Estrategia de Arquitectura de Microsoft, responsable del desarrollo de guas de arquitectura para SaaS. Antes de desempearse en el Equipo de Estrategia de Arquitectura, fue gerente de productos para el Equipo de Patrones y Prcticas de Microsoft, responsable de la distribucin de guas de arquitectura para el cliente, incluidos clientes de Web, clientes inteligentes y clientes mviles. Durante ese tiempo, su equipo lanz al mercado el Bloque de Aplicacin de IU mixta y tres fbricas de software para clientes inteligentes de escritorio y mviles y para el desarrollo de Web. Antes de unirse al equipo de patrones y prcticas, fue arquitecto de Servicios de Consultora de Microsoft donde lider el desarrollo de varias soluciones empresariales en todo el mundo. Consulte su blog en http://blogs.msdn.com/eugeniop
Figura 7: Integracin del ciclo de vida operativo del hoster y SDLC de los ISVs en la SDP Perfecta
13
Comunicacin segura entre dominios en el explorador

Por Danny Thorpe
Sntesis Un comprador puede entrar virtualmente en cualquier tienda y realizar una compra con slo una tarjeta plstica y una identificacin con foto. No es necesario que el comprador y el comerciante compartan la misma moneda, nacionalidad o idioma. Los que comparten es un sistema de comunicacin global y una red global para operaciones bancarias que permite al comprador llevar sus servicios bancarios dondequiera que vaya y proporciona soporte de infraestructura para el comerciante. Qu sucedera si Internet pudiera brindar protecciones y servicios similares para que quienes navegan la Web y quienes administran los sitios compartan informacin?
Desarrollar aplicaciones activas dentro del explorador de Web se parece mucho a mirar vidrieras en Main Street: muchas tiendas para elegir cosas, muchas cosas maravillosas para mirar en las vidrieras de cada tienda, pero se no puede llegar a ninguna de ellas. Su madrastra malvada, Frau Browser, tira de la correa cada vez que usted se inclina demasiado hacia la vidriera. Ella dice que es por su bien, pero usted comienza a cuestionarse si la correa corta se debe ms a la conveniencia de ella o a su seguridad. Los exploradores de Web aslan pginas activas en diferentes dominios para prevenir que unos miren las notas de otros sobre el usuario final. En los comienzos de Internet, el modelo de aislamiento era adecuado porque pocos sitios colocaban lgica de aplicacin significativa en el cliente del explorador, e incluso aquellos que lo hacan, slo accedan a los datos desde su propio servidor. Cada servidor de Web era su propio silo, que tena vnculos slo de HTML hacia contenido externo. Internet en la actualidad no es as. La experiencia de Internet ha evolucionado hacia la agregacin de datos desde mltiples dominios. Esta agregacin se lleva a cabo mediante la personalizacin de sitios que realiza el usuario as como tambin sitios que agregan valor a travs de la agrupacin de combinaciones de diversas fuentes de datos. En este mundo, el modelo de aislamiento de dominio del explorador de Web se ha vuelto un enorme obstculo que dificulta el desarrollo de la aplicacin de Web del lado del cliente. Para evitar este obstculo, los diseadores de aplicaciones de Web han trasladado ms y ms lgica de aplicacin hacia sus servidores de Web, lo que sacrifica la escalabilidad del servidor slo para obtener resultados. Mientras tanto, la terminal sin procesamiento de 2GHz, 2GB del usuario final, permanece inactiva. Si las computadoras personales se construyeran como un explorador de Web, se podran guardar los datos en el disco, pero no se podran utilizar esos archivos con ninguna otra aplicacin de su equipo ni el equipo de otras personas. Si decidiera cambiar a una marca diferente de editor de fotos, no podra editar ninguna de sus fotos anteriores. Si se quejara con quienes crearon su editor de fotos
anterior, ellos menospreciaran la queja y diran: No sabemos lo que ese otro editor de fotos puede hacer con sus datos, puesto que no sabemos o confiamos en ese otro editor de fotos, por lo tanto, tampoco usted debera! Y no, no le permitiramos que use sus fotos con ellos, porque ya que proporcionamos el espacio de almacenamiento para esas fotos, realmente, en parte, son nuestras fotos. No podra ni siquiera encontrar sus archivos, a menos que conociera primero la aplicacin con la cual los creo. Qu editor de fotos us para las fotos del cumpleaos de Stevie? No puedo encontrarlas!. Y qu sucede cuando ese editor de fotos vanguardista y moderno desdichadamente quiebra y desaparece? Se lleva todas las fotos con l! Le suena familiar? Esto es algo cotidiano que nos sucede a todos cuando usamos aplicaciones de Web o sitios de Web en Internet. El aislamiento de dominios impide que utilice su lista de reproduccin de msica para comprar melodas similares en una tienda en lnea independiente (no relacionada con el fabricante de su reproductor de msica) o en un quisco que se encuentra dentro de una tienda minorista. El aislamiento de dominios tambin dificulta en gran medida la creacin de aplicaciones de Web livianas, de infraestructura limitada que segmenta y separa datos extrados desde diversos servidores de datos de una red corporativa. Un subdominio foo.bar.com de su red corporativa interna bar.com est aislado de bar.com y bee.bar.com del mismo modo que est aislado de direcciones externas como xyz.com. Sin embargo, uno no quiere vencer todos los obstculos y luego repartir flores. Las amenazas para la seguridad personal y de los datos contra las cuales protege la poltica estricta de aislamiento de dominio del explorador son reales y desagradables. Con infraestructura y consideracin detallada, se puede lograr una solucin intermedia que brinde al usuario mayores beneficios al mismo tiempo que mantiene las prcticas de seguridad necesarias. Los usuarios deben controlar la cantidad, tipo y momento en el que su informacin se pone a disposicin de un determinado sitio de Web. El objetivo aqu no es el libre flujo de informacin en todos los sentidos, sino la libertad de los usuarios para que utilicen sus datos en la situacin y momento en los que cumplen con sus objetivos, sin tener en cuenta el lugar en el que se encuentran estos datos. Se necesita una forma en la que el explorador admita el acceso vlido a datos entre dominios sin poner en riesgo la seguridad del usuario final y el control de sus datos. Un paso importante en este sentido es la propuesta de estndares de desarrollo que organiz Ian Hickson para ampliar xmlHttpRequest y de este modo admitir conexiones entre dominios con el uso de inclusiones/exclusiones voluntarias (opt-in/opt-out) basadas en el dominio por parte del servidor solicitado. (Ver Recursos). Si esto se aprueba despus de que lo evalen los expertos de la industria y si se implementa a travs de los exploradores ms importantes, ofrece la posibilidad de disminuir la barrera entre dominios para usos
14
Comunicacin segura entre dominios

host y sus propiedades. Sin embargo, si el URL fuente del iframe posee un dominio diferente al de la pgina host, el host no podr ver los contenidos del iframe y el iframe no podr ver los contenidos de la pgina host. Si bien el host no puede leer el atributo src del elemento del iframe, sin embargo, puede escribirlo. La pgina host no conoce lo que el iframe exhibe en ese momento, pero puede forzar al iframe para que muestre algo ms. Cada vez que se asigna un nuevo URL para el atributo src del iframe, el iframe realizar todos los pasos normales de carga de una pgina, incluida la activacin del evento onLoad. Contamos ahora con todas las piezas requeridas para pasar datos desde el host hacia el iframe en el URL. (Ver Figura 1) la pgina host en el dominio foo.com puede incrustar un paquete de datos codificado en URL sobre el final de un URL de documento existente en el dominio bar.com. Los datos pueden transportarse en el URL como parmetro de consulta si se utiliza el carcter ? (http://bar.com/receiver.html?datadatadata) o como marcador con el uso del carcter # (http://bar.com/receiver.html#datadatadata). Existe una gran diferencia entre estos dos tipos de URL que analizaremos enseguida.
Figura 1: Paso de datos del URL del iframe
legtimos, mientras que an se protege contra usos ilegtimos. Aunque, en realidad, pasaran varios aos antes de que esta propuesta se implemente con los exploradores ms importantes y en todas partes del campo. Qu se puede hacer ahora? Existen patrones de comportamiento admitidos por todos los exploradores que permiten que el cdigo JavaScript que reside en el contexto del dominio de un explorador observe los cambios que se realizan a travs del JavaScript que reside en otro contexto de dominio dentro de la misma instancia del explorador. Por ejemplo, los cambios que se realizan en las propiedades de alto y ancho de un iframe se pueden observar dentro, y fuera del iframe. Otro ejemplo es la propiedad iframe.src. El cdigo que se encuentra fuera de un iframe no puede leer el URL del atributo src del iframe, pero puede escribir para el URL del src del iframe. Por lo tanto, el cdigo que se encuentra fuera del iframe puede enviar datos dentro del iframe a travs del URL del iframe. Esta tcnica de URL ha sido utilizada por diseadores de Web desde que los iframes se introdujeron por primera vez en HTML, pero los usos son por lo general primitivos, especficos y se improvisan de forma precipitada. Lo que es peor, el paso de datos a travs del URL src iframe puede crear un vector de explotacin y de este modo permitir que el cdigo malintencionado dae el estado de la aplicacin de Web al tirar basura en el iframe. En el explorador, cualquier cdigo en cualquier contexto puede escribir para el atributo .src del iframe y el iframe receptor no tiene conocimiento del lugar del cual vienen los datos del URL. En la mayora de las situaciones, no se debe confiar en los datos de origen desconocido. Este artculo analizar los problemas y tcnicas de solucin del canal de datos entre dominios seguro del lado del cliente que desarroll el grupo Windows Live Developer Platform. Tcnica del URL para el Iframe Un iframe es un elemento de HTML que encapsula y muestra un documento HTML completo dentro de s mismo, lo que permite insertar un documento HTML dentro de otro. Llamaremos elemento primario del iframe a la pgina exterior o pgina host y contenido del iframe a la pgina interior. La pgina interior del iframe se especifica mediante la asignacin de un URL para el atributo src del iframe. Cuando el URL fuente del iframe posee el mismo nombre de dominio que la pgina host/exterior, el JavaScript de la pgina host puede navegar a travs del DOM interior del iframe y ver todos los contenidos. En cambio, el iframe puede explorar hacia arriba a travs de su cadena principal y ver todos sus DOM relacionados en la pgina
EL AISLAMIENTO DE DOMINIOS TAMBIN DIFICULTA EN GRAN MEDIDA LA CREACIN DE APLICACIONES DE WEB LIVIANAS, DE INFRAESTRUCTURA LIMITADA QUE SEGMENTA Y SEPARA DATOS EXTRADOS DESDE DIVERSOS SERVIDORES DE DATOS DE UNA RED CORPORATIVA. SIN EMBARGO, UNO NO QUIERE VENCER TODOS LOS OBSTCULOS Y LUEGO REPARTIR FLORES.
La pgina host asigna este url al atributo src del iframe. El iframe carga la pgina y activa el controlador de eventos onLoad de la pgina. El controlador de eventos onLoad de la pgina puede examinar su propio URL, encontrar el paquete de datos incrustado y decodificarlo para decidir lo que realizar a continuacin. En pocas palabras, sta es la tcnica de paso de datos del URL del iframe. El host crea una cadena de direccin URL desde un documento url desconocido + carga de datos, lo asigna el atributo src del iframe, el iframe se reactiva en el controlador de eventos onLoad y recibe la carga de datos. Qu ms se podra pedir? En realidad, mucho ms. Existen algunas advertencias para esta tcnica simple: Sin acuse de recibo. La pgina host no sabe si el iframe recibi los datos con xito. Sobrescritura de mensajes. El host no conoce el momento en el que el iframe finaliza el procesamiento del mensaje anterior, por lo tanto, no sabe el momento seguro en el que debe enviar el prximo mensaje. Lmites de capacidad. Una direccin de URL slo puede tener una extensin limitada y el lmite de la extensin vara de acuerdo al grupo del explorador. Firefox admite URLs con un lmite aproximado de 40k pero IE establece un lmite de menos de 4k. Cualquier
15

tamao mayor a ste se acortar o ignorar. Los datos tienen origen desconocido. El iframe no sabe quin puso los datos en el URL. Los datos pueden ser de la conocida pgina host foo.com o pueden ser de evil.com que lanza bolitas de papel en bar.com para que algo se adhiera o estalle. Sin respuestas. No existe forma para que las secuencias de comandos del iframe vuelvan a pasar los datos a la pgina host. Prdida de contexto. Debido a que la pgina se vuelve a cargar con cada mensaje, la pgina interior del iframe no puede mantener un estado global a travs de los mensajes. Datos ocultos en marcadores Se debe utilizar ? o # para aadir datos en el final del URL del iframe? Aunque bastante inofensivas en apariencia, existen en realidad algunas diferencias importantes en el modo en el que los exploradores manejan URLs con parmetros de consulta en oposicin a URLs con marcadores. Dos URLs con la misma ruta de base pero con diferentes parmetros de consulta se tratan como URLs diferentes. Aparecern de forma separada en la lista del historial del buscador, sern entradas separadas en la cach de pginas del buscador y generarn solicitudes de red separadas a travs de la conexin. Los marcadores del URL se disearon para hacer referencia a etiquetas de hipervnculo especialmente marcadas dentro de una pgina. El explorador considera dos URLs con la misma ruta de base pero con texto del marcador diferente despus del carcter # para que sean la misma direccin de URL segn el historial del explorador y las cachs. Los diferentes marcadores simplemente indican diferentes partes de la misma pgina (URL), pero no obstante, es la misma pgina. Figura 2: Equivalencia de cach de URLs del marcador
SE DEBE UTILIZAR ? O # PARA AADIR DATOS EN EL FINAL DEL URL DEL IFRAME? AUNQUE BASTANTE INOFENSIVAS EN APARIENCIA, EXISTEN EN REALIDAD ALGUNAS DIFERENCIAS IMPORTANTES EN EL MODO EN EL QUE LOS EXPLORADORES MANEJAN URLS CON PARMETROS DE CONSULTA EN OPOSICIN A URLS CON MARCADORES.
El explorador considera que las URLs http://bar.com/page.html#one, http://bar.com/page.html#two y http://bar.com/page.html#three son cachs equivalentes a http://bar.com/page.html. Si se utilizaran parmetros de consulta, el explorador considerara tres URLs diferentes y tres recorridos diferentes a travs de la conexin de red. Sin embargo, con el uso de marcadores se tiene como mucho un recorrido a travs de la conexin de red, las solicitudes subsiguientes se respondern desde la cach local del explorador (Ver Figura 2). Para los casos en los que es necesario enviar una gran cantidad de mensajes a travs del URL del iframe con el uso de la misma direccin URL base, los marcadores son ideales. Las cargas de datos que se encuentran en la porcin del marcador del URL no aparecern en el historial o la cach de pginas del explorador. Incluso, las cargas de datos nunca pasarn por la conexin de red despus de que la carga inicial de la pgina se almacena en cach. Los datos que se pasan entre la pgina host y el iframe no pueden ser vistos por ningn otro elemento DOM en la pgina host ya que el iframe
Explorador
Historial del explorador

Agregar historial
Cach del explorador
Servidor de Web
Consulta: http:// bar.com/page.html?one Consulta: http:// bar.com/page.html?two Consulta: http:// bar.com/page.html?three
Llenado de cach
Internet
Consulta: http:// bar.com/page.html#one Consulta: http:// bar.com/page.html#two Consulta: http:// bar.com/page.html#three
Llenado de cach Aciertos en la cach
Aciertos en la cach
16

est en un contexto de dominio diferente al de la pgina host. Los datos no aparecen en la cach del explorador y tampoco pasan por la conexin de red, por lo tanto, es razonable decir que los paquetes de datos se pueden observar slo a travs del iframe receptor u otras pginas servidas desde el dominio bar.com. Identificacin del remitente Tal vez, el mayor problema de seguridad con la simple tcnica de paso de datos a travs del URL del iframe es no saber con confianza la procedencia de los datos. Insertar el nombre del remitente o alguna forma de identificacin de aplicacin, no es la solucin, ya que los imitadores pueden copiarlos con facilidad. Se necesita un modo para que el mensaje identifique de forma implcita al remitente de modo que no se pueda copiar con facilidad. La primera solucin que se les ocurre a la mayora de las personas es utilizar alguna forma de encriptacin mediante el uso de claves que slo poseen el remitente y el destinatario. Esto por supuesto funcionara, pero es una solucin muy poco til, en especial si se requiere de JavaScript. Existe otra forma que aprovecha la importancia crtica de la identidad del nombre de dominio en el entorno del explorador. Si se puede enviar un mensaje secreto a una persona con el uso del nombre de dominio de esa persona y a continuacin se recibe ese secreto como parte de un paquete de datos, se puede deducir de modo razonable que ese paquete de datos viene del dominio de esa persona. La nica forma de que el secreto provenga del dominio de un tercero es que el dominio, el explorador del usuario o el DNS hayan sido accedidos de forma ilegal. Todo es posible si el dominio o el explorador han sido accedidos de forma ilegal. Si la vulnerabilidad del DNS es una preocupacin real, se pueden utilizar https para validar que el servidor que responde solicitudes de un nombre de dominio determinado, sea en realidad el servidor legtimo. Si el remitente proporciona un secreto al destinatario y el destinatario proporciona un secreto al remitente y ambos secretos se transportan en cada paquete de datos que se enva a travs del canal de datos del URL del iframe, entonces, ambas partes pueden confiar en la procedencia de cada mensaje. Las bolitas de papel que lanza evil.com se pueden reconocer y eliminar con facilidad. Este intercambio de secretos se inspira en el protocolo de acuerdo de tres vas de SSL/https. No es necesario que estos secretos sean complejos o encriptados ya que los paquetes de datos que se envan a travs del canal de datos del URL del iframe no pueden ser vistos por ningn tercero. Los nmeros al azar son suficiente como secreto, con una advertencia: El generador de nmeros aleatorios de JavaScript (Math.random()) no es seguro desde el punto de vista criptogrfico, por lo tanto, representa un riesgo para la produccin de secuencias de nmeros predecibles. Firefox ofrece un generador de nmeros aleatorios seguro desde el punto de vista criptogrfico (crypto.random()), pero IE no. Como consecuencia, en nuestra implementacin optamos por generar nmeros aleatorios seguros en el servidor de Web y enviarlos al cliente segn sea necesario. Envo al remitente La mayora de los problemas asociados con la tcnica de paso de datos a travs del URL del iframe se deben a la generacin de una respuesta. La confirmacin de los paquetes requiere que el destinatario enve una respuesta al remitente. El intercambio de secretos requiere respuestas en ambas direcciones. El control de mensajes y la divisin de grandes cargas tiles de datos en varios mensajes ms pequeos requiere un acuse de recibo. Por lo tanto, De qu modo puede el iframe responder a la pgina host? No yendo hacia arriba, sino hacia abajo. El iframe no puede asignar nada en su primario ya que el iframe y el primario residen en diferentes contextos de dominio. Pero el iframe de bar.com (A) puede contener otro iframe (B) y A puede asignarle al atributo src de B una direccin del URL en el dominio de la pgina host (foo.com) la pgina host foo.com contiene el iframe bar.com (A) que contiene el iframe foo.com (B). Aunque, Qu puede hacer ese iframe interno? No puede hacer mucho con su primario, el iframe bar.com. Pero puede ir un nivel ms hacia arriba y lograr lo que buscaba: el primario del primario de B es la pgina host en foo.com. La pgina de B est en foo.com, B.parent.parent est en foo.com, por lo tanto, B puede acceder a cualquier cosa en la pgina host y llamar a las funciones de JavaScript en el contexto de la pgina host. La pgina host puede pasar datos al iframe A mediante la escritura de una direccin de URL para el atributo src de A. A puede procesar los datos y enviar una confirmacin al host a travs de la escritura de una direccin de URL para el atributo src de B. B se activa en su evento onLoad y pasa el mensaje a su primario del primario, la pgina host. Problema resuelto. Confirmacin de ida y vuelta desde una serie de pipes conectados entre ellos de manera que podra diverter a Felix Klein, matemtico y creador de botellas. Destinatario con estado Para mantener un estado global en el contexto bar.com a travs de los mltiples mensajes que se envan al iframe, se deben usar dos iframes con pginas bar.com. Uno de los iframes se debe utilizar como destinatario de mensajes sin estado, de modo que recarga y pierde su estado con cada mensaje que recibe. La lgica de aplicacin con estado se debe colocar para el lado del contenedor de bar.com del otro iframe. Se debe reducir la lgica de pgina del mensajero del iframe al mnimo
Figura 3: Mensaje en una Botella de Klein
17

SI SE PUEDE ENVIAR UN MENSAJE SECRETO A UNA PERSONA CON EL USO DEL NOMBRE DE DOMINIO DE ESA PERSONA Y A CONTINUACIN SE RECIBE ESE SECRETO COMO PARTE DE UN PAQUETE DE DATOS, SE PUEDE DEDUCIR DE MODO RAZONABLE QUE ESE PAQUETE DE DATOS VIENE DEL DOMINIO DE ESA PERSONA. SI LA VULNERABILIDAD DEL DNS ES UNA PREOCUPACIN REAL, SE PUEDEN UTILIZAR HTTPS PARA VALIDAR QUE EL SERVIDOR QUE RESPONDE SOLICITUDES DE UN NOMBRE DE DOMINIO DETERMINADO, SEA EN REALIDAD EL SERVIDOR LEGTIMO.
Integracin del usuario Apenas 40 aos atrs, un comprador en Main Street, USA deba realizar grandes esfuerzos para convencer a un vendedor que acepte un pago de otra forma que no fuera efectivo. Si no se tena dinero, y mucho, muy probablemente no se hubiera tenido suerte. Si se tenan divisas extrajeras, hubiera sido necesario encontrar un banco grande en una ciudad grande para cambiar esas divisas por moneda local. Los cheques de otras ciudades, rara vez se aceptaban y se ofreca crdito slo a los residentes locales. En la actualidad, los compradores y comerciantes comparten un sistema global de comunicaciones y una red bancaria global que le permite a los compradores contar con sus servicios bancarios en cualquier lugar que vayan y ayuda a los comerciantes a realizar ventas que de lo contrario hubieran perdido. La red bancaria tambin ofrece soporte de infraestructura para el comerciante y de este modo lo ayuda a convertir divisas lo que lo protege del riesgo crediticio y reduce las prdidas por fraude. Por lo tanto, Por qu no puede Internet ofrecer opciones y protecciones similares para quienes navegan la Web y servicios de infraestructura para quienes administran los sitios? Llevar los datos y experiencia con uno de sitio en sitio (del mismo modo que una tarjeta de crdito permite usar los servicios bancarios cuando se realizan compras), proporcionar informacin a los administradores de sitios slo a criterio propio. Internet va a lograr esto, slo se trata de lo bien y lo rpido que lo logre.
indispensable requerido para transportar los datos recibidos hacia el iframe bar.com con estado. Un iframe no puede enumerar los secundarios de sus primarios para encontrar otros relacionado bar.com, pero puede buscar un iframe relacionado con el uso de windows.parent.frames[] si conoce el nombre del iframe relacionado. Cada vez que vuelve a cargarse para recibir datos nuevos en el URL, el mensajero del iframe puede buscar su iframe relacionado bar.com con estado mediante el uso de window.parent.frames[] y llamar a una funcin en el iframe con estado para pasar los nuevos datos del mensaje dentro del iframe con estado. De este modo, el contexto de dominio de bar.com en la memoria del explorador puede acumular fragmentos de mensajes a Agradecimientos travs de mltiples mensajes para reconstruir una carga mayor que la Gracias a Scott Issacs por el concepto original de paso de datos del extensin mxima del URL del explorador. URL de iframe. Muchas gracias a Yaron Goland y Bill Zissimopoulos por su gran colaboracin en las primeras implementaciones y depuracin Aplicacin de ideas del cdigo de canal y a Gabriel Corverra y Koji Kato por su trabajo en El equipo Window Live Developer Platform ha desarrollado estas ideas las etapas ms recientes. Es una locura total, pero puede funcionar! en una biblioteca canal de JavaScript. Estos canales entre dominios se utilizan en la implementacin de controles de Web de Windows Live Spaces y contratos de Windows Live (http://dev.live.com), con la Recursos intencin de que residan en pginas de Web de terceros pero que se XMLHttpRequest 2, Ian Hickson ejecuten en un iframe seguro en el contexto de dominio de live.com. http://www.mail-archive.com/public-webapi@w3.org/msg00341.html Los controles brindan a los sitios de terceros un acceso controlado del http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012.html usuario para sus datos de Windows Live, como por ejemplo, lista de contratos de usuarios o el lbum de fotos de Spaces. El objeto del Anne van Kesterens weblog canal admite el envo arbitrario de grandes cantidades de datos a http://annevankesteren.nl/2007/02/xxx travs de los lmites de dominio del iframe con acuse de recibo, control y segmentacin de mensajes e identificacin del remitente, y todos ocurren sin ser percibido. Nuestro objetivo es formar este cdigo de canal en una biblioteca Sobre el autor reutilizable, disponible para los colaboradores internos de Microsoft Danny Thorpe es desarrollador en el equipo de Windows Live as como tambin para terceros que sean desarrolladores de Web. Si Developer Platform. Su credencial dice SDE principal, pero prefiere bien el cdigo se ejecuta bien en sus contextos actuales, an Windows Live Quantum Mechanic ya que dedica la mayor parte de su debemos realizar algunas tareas en el rea de autodiagnstico y tiempo a coaccionar pequeos bits obstinados para que migren a resolucin de problemas, si se logran configurar los puntos finales del travs de barreras impenetrables. En el pasado trabaj sobre canal de forma correcta, funciona muy bien, pero puede ser una undisclosed browser technology en Google y antes fue Cientfico Jefe pesadilla real averiguar lo que no es correcto cuando se lo trata de en Borland y Arquitecto Jefe del compilador Delphi. En Borland tuvo la configurar por primera vez. El obstculo principal es el explorador gran suerte de trabajar bajo la tutora de Anders Hejlsberg, Chuck mismo, tratar de ver lo que sucede, o no, en diferentes contextos de Jazdzewski, Eli Boling y otros tantos legendarios de Borland. Antes de dominio es un cierto desafo cuando el explorador no muestra lo que unirse a Borland, era demasiado joven como para recordar algo. Visite hay del otro lado del muro. su blog en: http://blogs.msdn.com/dthorpe
18
Modelo orientado a aplicaciones para datos relacionales

Por Michael Pizzo
Sntesis La mayora de las aplicaciones tratan con datos de algn u otro tipo, para los que la fuente de esos datos, por lo general, reside en una base de datos. Sin embargo, por varios motivos, la forma de esos datos en la base de datos, con frecuencia, es diferente al modelo con el cual interacta la aplicacin. Este artculo describe la forma de trabajar con datos que se encuentran en una base de datos mediante un modelo conceptual virtual ms apropiado para la aplicacin.
aplicacin se desarrolla, o para aplicaciones que se crean desde el comienzo como parte de una estructura empresarial ms grande, la lgica de acceso a datos, con frecuencia, se divide en una capa de abstraccin de datos separada, o DAL. Ya sea parte de la aplicacin o un componente separado, supuestos implcitos codificados de forma rgida sobre el esquema de base de datos, relaciones, normas de uso y patrones de acceso hacen que el mantenimiento o extensin de este cdigo de acceso a datos sea cada vez ms difcil con el paso del tiempo, en especial, desde la perspectiva de cambios en el esquema subyacente. Analicemos algunos de estos problemas con ms detalle. Normalizacin de esquemas de bases de datos Los datos en una base de datos, por lo general, se distribuyen en una vista normalizada, como lo describi el Dr. Codd, con tablas de disposicin rectangular, homogneas, separadas que contienen columnas de valores escalares nicos. Reduce la redundancia para mejorar la integridad de los datos a travs del movimiento de valores especficos que no sean fila dentro de una tabla separada. Los datos de estas tablas individuales se combinan mediante uniones que se basan en el conocimiento de aplicacin implcito sobre los diferentes valores que representan dentro de las columnas. Se pueden utilizar o no claves externas entre tablas de informacin relacionada como una forma de forzar an ms la integridad de datos, pero no definen en s mismas rutas de navegacin o condiciones de unin.
Modelos de aplicacin versus esquemas de almacenamiento Las aplicaciones modernas, en particular las aplicaciones de Web, tratan fundamentalmente la exposicin y manipulacin de datos de un tipo u otro. Los datos pueden tener la forma de resultados de bsqueda, catlogo de bienes, perfil de usuarios, informacin de cuentas, informacin financiera, informacin personal, coordenadas de mapas, meteorologa, etc., pero son todos datos y por lo general se almacenan en algn lugar en una base de datos. No obstante, los datos que se almacenan en bases de datos, con frecuencia, no tienen la forma ms adecuada como para que la aplicacin los manipule o exponga al usuario. El modelo de datos relacionales del esquema de bases de datos, por lo general y de forma correcta, se optimiza segn incumbencias de almacenamiento e integridad, no para el uso de la aplicacin. Como explica el Dr. Peter Chen en su artculo vanguardista en el que introdujo el Modelo Entidad-Relacin: El modelo relacional...puede lograr un alto grado de independencia de datos, pero puede perder cierta informacin semntica importante sobre el mundo real. Esta ponencia continua con la descripcin de un Modelo Entidad-Relacin alternativo que ...adopta la percepcin ms natural del mundo real que consiste en entidades y relaciones. (Ver Recursos). En pocas palabras, las aplicaciones orientadas a objetos en la actualidad, sin olvidar a los usuarios finales, tienden a razonar sobre los datos en trminos ms ricos que las filas y columnas planas de una base de datos relacional. El mundo real incluye una nocin fuerte del tipo del objeto, su identidad y sus relaciones con otros objetos. Si dejamos de lado por un momento los asuntos de expresividad, incluso si todos los conceptos de aplicaciones pudieran representarse mediante un modelo relacional, quien crea aplicaciones, por lo general, no posee control sobre el esquema de base de datos. An peor, el esquema podra cambiar con el tiempo para optimizar diferentes patrones de uso, lo que invalida supuestos implcitos, asignaciones y rutas de acceso no modificables. Las aplicaciones pequeas, habitualmente, comienzan directamente con la incrustacin de la lgica para asignar el esquema relacional a los objetos de datos de la aplicacin. A medida que la
LAS APLICACIONES ORIENTADAS A OBJETOS EN LA ACTUALIDAD, SIN OLVIDAR A LOS USUARIOS FINALES, TIENDEN A RAZONAR SOBRE LOS DATOS EN TRMINOS MS RICOS QUE LAS FILAS Y COLUMNAS PLANAS DE UNA BASE DE DATOS RELACIONAL.
Analicemos un ejemplo. Imaginemos la direccin de un muelle deportivo que vende embarcaciones usadas y desea registrar el inventario en una base de datos que expondr a los clientes a travs de una aplicacin de Web. La informacin que se debe almacenar para cada boat es: registration, make, year, length y width. Para las embarcaciones con engines se desea almacenar: make, model, year, horsepower, type of fuel y SerialNumber of the engine. Un esquema totalmente normalizado dividira la informacin del motor en tres tablas separadas, una tabla contendra la informacin de un tipo de motor particular (make, model, horsepower y type of fuel; make y model constaran de una clave compuesta); otra para cada motor en s (SerialNumber, year, make y model) y otra para asociar embarcaciones y motores. El esquema resultante podra ser similar al de la Figura 1. Para poder mostrar una pgina de inventario relativamente simple que contenga boat registration number, year, y make, adems de
19
Modelo de datos orientado a aplicaciones

Figura 1: Esquema completamente normalizado Boats RegNum WN123AB WN234CD WN345EF WN456GH WN567IJ WN678KL Year 1977 1999 1962 1957 1997 1996 Make Hunter Calabria Del Mar Harvey Seadoo Bayliner Length 25 23 16 13.5 9 47 Engines SerialNum C1075 M30099 M3060 T5090 R8596 H31096A H31096B Year 1975 1999 1962 1990 1997 1996 1996 Make Clinton Mercruiser Mercury Tohatsu Rotax Hino Hino Model K990 350MagMPI Mark30 M50CEPTS 720CC W06DTA W06DTA Beam 8 87 6 510 310 1411 Make Clinton Mercruiser Mercury Tohatsu Rotax Hino EngineTypes Model K990 350MagMPI Mark30 M50CEPTS 720CC W06DTA HP 9.9 300 30 50 85 310 Fuel Gas Gas Gas Gas Gas Diesel
Boat Engines EngineSerialNum C1075 M30099 M3060 T5090 R8596 H31096A H31096B BoatID WN123AB WN234CD WN345EF WN456GH WN567IJ WN678KL WN678KL
informacin relacionada con el engine, para todas las motor boats, la aplicacin de Web podra utilizar la siguiente consulta:
SELECT Boats.RegNum, Boats.Year AS Boat_Year, Boats.Make AS Boat_Make, BoatEngine.SerialNumber, BoatEngine.Year AS Engine_Year, BoatEngine.Make AS Engine_Make, BoatEngine.Model AS Engine_Model, BoatEngine.HP FROM Boats INNER JOIN ( SELECT EngineType.Make, BoatEngines.BoatID, EngineTypes.HP FROM EngineTypes INNER JOIN (Engines INNER JOIN BoatEngines ON Engines.SerialNumber = BoatEngines.EngineSerialNum) ON EngineTypes.Model = Engines.Model AND EngineTypes.Make = Engines.Make ) AS BoatEngine ON Boats.RegNum = BoatEngine.BoatID
Esta consulta no slo es demasiado compleja, sino que tambin requiere (e incluye) una comprensin implcita del modo en el que se relacionan las tablas; que las columnas Make y Model de la tabla Engines se relacionan con las columnas Make y Model de la tabla EngineTypes y que las columnas EngineSerialNum y BoatID de la tabla BoatEngines se relacionan con las columnas SerialNum y
RegNum de las tablas Engines y Boats, respectivamente. Tambin, la consulta intenta devolver slo datos sobre motorboats, y no sobre sailboats al realizar una unin interna entre embarcaciones y motores. Por supuesto, esta consulta omitira todas las embarcaciones a motor que se vendieron sin el motor y si bien la consulta excluira las embarcaciones a vela pequeas, las embarcaciones ms grandes, incluida la embarcacin a vela Hunter de 25, por lo general tienen motor. Por lo tanto, si bien el supuesto puede ser vlido cuando se crea la aplicacin, segn el esquema y datos en ese momento, incrustar este tipo de lgica implcita en consultas dentro de la aplicacin introduce dependencias sutiles en los datos y el esquema que son difciles de registrar y mantener. Claramente, a pesar de que el esquema est muy bien normalizado desde la perspectiva de una base de datos, no es una forma muy conveniente para la aplicacin. Lo que es peor, para poder recuperar la informacin deseada, sin mencionar posibles actualizaciones como mover un motor a una embarcacin diferente, se debe incrustar en la aplicacin el conocimiento implcito sobre las relaciones entre las tablas. Los cambios en el esquema, por ejemplo combinacin de las tablas Engines y BoatEngines (un grado razonable de desnormalizacin que un DBA puede considerara para mejorar el rendimiento), causan que la aplicacin se divida de formas difciles de anticipar y resolver. Representacin de herencia Ahora supongamos que se desea incluir informacin adicional en el esquema. Primero, se hace explcita la diferencia entre embarcaciones a vela y diferentes tipos de embarcaciones a motor a travs de la inclusin de una columna Style en la tabla. A continuacin, para salivotas se incluye type of Keel (Fixed, Swing o Dagger) y number of sails. Para skiboats, se incluye si posee ski pylon y/o tower, y para MotorYachts se desea incluir si posee o no flybridge.
20
Figura 2: Representacin de jerarqua en una tabla nica Boats
Boats RegNum WN123AB WN234CD WN345EF WN456GH WN567IJ WN678KL Year 1977 1999 1962 1957 1997 1996 Make Hunter Calabria Del Mar Harvey Seadoo Bayliner Style Sail Ski Motor Motor PWC Yacht Length
25 23 16 13.5 9 47
KeelType Fixed Null Null Null Null Null
Beam
8
NumSails
3
SkiPylon Null Yes Null Null Null Null
Tower Null No Null Null Null Null
Flybridge Null Null Null Null Null Yes
87 6 13.5 310 1411
Null Null Null Null Null
Esto se vuelve un desafo con el modelo de datos relacionales porque cada pieza adicional de informacin slo aplica para un subconjunto de filas dentro de la tabla Boats. Una forma de representar esto es mediante la extensin de la tabla de base Boats con miembros para cada tipo derivado, mediante el uso de valores nulls para las filas en las que no se aplican. Por ejemplo, esta informacin podra expresarse en una tabla dispersa simple Boats como muestra la Figura 2. Como se puede observar, cuantas ms propiedades se incluyen para cada tipo derivado, ms aumenta el esquema de la tabla total y ms se completan campos no relevantes con valores nulos. Una forma alternativa para representar esta misma informacin sera dividir la informacin adicional de Sailboats, Ski Boats y Motor Yachts en tablas separadas como se muestra en la Figura 3. Esta distribucin evita la necesidad de incluir columnas dispersas en la tabla de base para cada propiedad del tipo derivado, pero realizar una consulta se vuelve an ms complejo ya que cada consulta debe unir las tablas adicionales para incluir la informacin completa de cada tipo derivado. Por ejemplo, para que devuelva boat registration, year, make e informacin relacionada con el engine para todos los motor boats sin tower, se puede escribir una consulta parecida a la que se muestra a continuacin:
FROM (Boats LEFT OUTER JOIN ( SELECT EngineTypes.Make, BoatEngines.BoatID, EngineTypes.HP FROM EngineTypes INNER JOIN (Engines INNER JOIN BoatEngines ON Engines.SerialNumber = BoatEngines.EngineSerialNum) ON EngineTypes.Model = Engines.Model AND EngineTypes.Make = Engines.Make ) AS BoatEngine ON Boats.RegNum = BoatEngine.BoatID ) LEFT JOIN SkiBoats ON Boats.RegNum = SkiBoats.RegNum WHERE Boats.Style In (Ski,Motor,PWC,Yacht) AND (SkiBoats.Tower=False OR SkiBoats.Tower IS NULL)
Cabe observar que la tabla Boats debe unirse con la tabla Skiboats para poder obtener la informacin de Tower, y se debe justificar el valor NULL en el predicado para las filas que no estn en Ski boats. Cambios en el esquema A medida que la tabla aumenta, el DBA puede decidir refactorizar el
SELECT Boats.RegNum, Boats.Year AS Boat_Year, Boats.Make AS Boat_Make, BoatEngine.SerialNumber, BoatEngine.Year AS Engine_Year, BoatEngine.Make AS Engine_Make, BoatEngine.Model AS Engine_Model, BoatEngine.HP
Figura 3: Almacenamiento de informacin extendida en tablas separadas Boats RegNum WN123AB WN234CD WN345EF Year 1977 1999 1962 Make Hunter Style Sail Length 25 23 16 13.5 9 47 Beam 8 87 6 510 310 1411 RegNum SkiBoats SkiPylon Tower No MotorYachts RegNum WN678KL Flybridge Yes RegNum WN123AB SailBoats KeelType Fixed NumSails 3
Calabria Ski Del Mar Harvey Seadoo Bayliner Motor Motor PWC Yacht
WN456GH 1957 WN567IJ WN678KL 1997 1996
WN234CD Yes
21
Figura 4: Tablas completamente separadas para cada Boat Type MotorBoats RegNum WN345EF WN456GH Year 1962 1957 Make Del Mar Harvey Length 16 13.5 Beam 6 510 RegNum WN678KL Year 1996 MotorYachts Make Bayliner Length 47 Beam 1411 Flybridge Yes
PWC RegNum WN567IJ Year 1997 Make Seadoo Length 9 Beam 310 RegNum WN234CD SailBoats RegNum WN123AB Year 1977 Make Hunter Length 25 Beam 8 KeelType Fixed Year 1999 Make Calabria
SkiBoats Length 23 Beam 87 SkiPylon Yes Tower No
NumSails 3
esquema como por ejemplo que toda la informacin para un tipo particular de boat est en una tabla, como se muestra en la Figura 4. Este esquema se optimiza para consultas con un type of boat simple a expensas de consultas entre types of boats. Y, por supuesto, esto significa que las consultas en la aplicacin deben cambiar. La consulta para informacin sobre engine y boat sera:
Cabe observar que para consultar a travs de todos los types of boats, incluida la columna tower especfica para SkiBoats, se debe proyectar de forma explcita un valor null para ese campo de otras tablas dentro de UNION ALL. Entidades de ADO.NET Cada uno de estos ejemplos pone de manifiesto algunos de los desafos que enfrentan los desarrolladores de aplicaciones en la actualidad cuando tratan de exponer, manipular y almacenar modelos interesantes del mundo real en un esquema relacional plano. El hecho de que el esquema puede no ser propiedad del desarrollador de la aplicacin y puede cambiar con el tiempo, ayuda a comprender el motivo por el cual el acceso a datos goo puede ocupar esa parte desproporcionada de una aplicacin o marco en lo que respecta a cdigo, desarrollo y costo de mantenimiento. Llegada del Marco de Entidades de ADO.NET El Marco de Entidades de ADO.NET se lanzar al mercado en la primera mitad del 2008 como una extensin del Marco .NET que es parte del Visual Studio code name Orcas de Microsoft y representa el primer producto en una Plataforma de Datos de Entidad de Microsoft para trabajar con datos segn un Modelo de Datos de Entidad comn, enriquecido. El Marco de Entidades de ADO.NET es una implementacin del Modelo Entidad-Relacin del Dr. Chen adems de datos relacionales. En vez de permitir que la representacin de almacenamiento imponga el modelo de aplicaciones, la escritura para un modelo conceptual comn permite a las aplicaciones mayor expresividad en el modelado de datos mediante el uso de conceptos del mundo real que se pueden asignar de forma flexible a una variedad de representaciones de almacenamiento. (Para ms informacin sobre el Marco de Entidades ADO.NET, consulte la seccin Recursos) El Marco de Entidad utiliza un mecanismo de Vistas Cliente para ampliar las consultas y actualizaciones que se escriben contra el modelo conceptual en consultas contra el esquema de almacenamiento. Las consultas ampliadas se evalan completamente en la base de datos; no existe el procesamiento de consultas del lado del cliente. Estas Vistas Cliente se pueden compilar dentro de la aplicacin para el rendimiento, o se pueden generar en tiempo de ejecucin a partir del mapeo de metadatos que se proporcionaron segn archivos de XML, lo que permite que las aplicaciones que se implementan funcionen contra esquemas de almacenamiento diferentes o en desarrollo sin volver a compilarlas.
SELECT Boats.RegNum, Boats.Year AS Boat_Year, Boats.Make AS Boat_Make, BoatEngine.SerialNumber, BoatEngine.Year AS Engine_Year, BoatEngine.Make AS Engine_Make,BoatEngine.Model AS Engine_Model, BoatEngine.HP FROM ( (SELECT RegNum, Year, Make, Tower FROM SkiBoats UNION ALL SELECT RegNum, Year, Make, NULL As Tower FROM MotorBoats UNION ALL SELECT RegNum, Year, Make, Null AS Tower FROM PWC UNION ALL SELECT RegNum, Year, Make, Null AS Tower FROM MotorYachts ) AS Boats LEFT OUTER JOIN ( SELECT EngineTypes.Make, BoatEngines.BoatID, EngineTypes.HP FROM EngineTypes INNER JOIN (Engines INNER JOIN BoatEngines ON Engines.SerialNumber = BoatEngines.EngineSerialNum) ON EngineTypes.Model = Engines.Model AND EngineTypes.Make = Engines.Make ) AS BoatEngine ON Boats.RegNum = BoatEngine.BoatID ) WHERE (Boats.Tower=False OR Boats.Tower IS NULL)
22
Figura 5: Modelo conceptual orientado a la aplicacin
El Marco de Entidades permite exponer este modelo conceptual a la aplicacin mediante el uso de conceptos de aplicacin como por ejemplo, establecimiento inflexible de tipos, herencia y relaciones sobre cualquier esquema de bases de datos descripto anteriormente. El hecho de que la asignacin se realiza de forma declarativa, fuera de la aplicacin, significa que si el esquema de la base de datos evoluciona con el tiempo para optimizar diferentes patrones de acceso, slo debe cambiar la asignacin; la aplicacin puede continuar con el uso de las mismas consultas y recuperar los mismos resultados en el mismo modelo conceptual. Veamos el modo en el que el uso de este modelo conceptual simplifica los patrones de aplicacin. Realizar consultas al modelo conceptual Dado este modelo conceptual, realizar consultas sobre un nico conjunto de boats polimrfico se vuelve ms simple. Por ejemplo, el cdigo que se muestra a continuacin utiliza este esquema conceptual para consultar informacin sobre registration year, make y engine de todos los motorboats sin tower.
SELECT boat.RegNum, boat.Year, boat.Make, boat.Engines FROM Boats AS boat WHERE boat IS OF (Motorboat) AND (Boat IS NOT OF (SkiBoat) OR TREAT(boat AS SkiBoat).Tower = False)
Cabe observar que no se requieren uniones en la consulta; las entidades poseen establecimiento inflexible de tipos, las relaciones se recorren a travs de propiedades y las recopilaciones se pueden filtrar de acuerdo a los tipos de la jerarqua. Resultados anidados En cada una de las tres primeras consultas escritas directamente contra el esquema de bases de datos, los resultados seran algo parecido a la Figura 6. Se debe tener en cuenta que el ltimo boat (1996 BayLiner) aparece dos veces. Si se observan los datos, se puede ver que el 1996 Bayliner es un MotorYacht con dos Hino 310 engines. Debido a que los datos relacionales son planos, no hay una buena forma de representar mltiples engines en una nica fila del resultado, por lo tanto, se devuelven dos filas para el mismo boat; una para cada engine. La consulta en el modelo conceptual devuelve una columna Engines con una nica fila para cada boat que contiene la recopilacin de engines como muestra la Figura 7. Por otro lado, si slo se desea un subconjunto de datos para cada engine (Por ejemplo, Make y HP), esa informacin se puede proyectar de la siguiente manera:
Modelo de aplicacin La Figura 5 muestra un modelo de datos orientado a aplicaciones ms apropiado para la aplicacin de Web descripta. Cabe observar que, si bien se utiliz un diagrama de clase para representar el modelo, los objetos son slo de una forma para exponer el modelo conceptual a la aplicacin en el Marco de Entidades. El mismo modelo conceptual podra destinarse directamente mediante el uso de gramtica SQL extendida y podra devolverse como registros jerrquicos, polimrficos. Lo primero que notamos en este modelo es que no se parece en nada con ninguno de los esquemas de almacenamiento anteriores. Por ejemplo: 1. La clase Engine contiene informacin de la tabla EngineTypes (Make, Horsepower y Fuel) y de la tabla Engines (Year y SerialNumber). 2. En vez de una propiedad BoatID, la clase Engine contiene referencia para Boat. 3. Boats contienen un grupo variado de cero o ms engines. 4. Ms que exponer una propiedad de Style sobre Boat, o de tener tablas diferentes para cada uno, se utiliz un concepto de herencia ms natural para distinguir los distintos tipos de boats.
Figura 6: Resultados anidados devueltos como una tabla rectangular
RegNum WN234CD WN345EF WN456GH WN567IJ WN678KL WN678KL
Boat_Year 1999 1962 1957 1997 1996 1996
Boat_Make Calabria Del Mar Harvey Seadoo Bayliner Bayliner
SerialNum M30099 M3060 T5090 R8596 H31096A H31096B
Engine_Year 1999 1962 1990 1997 1996 1996
Engine_Make Mercruiser Mercury Tohatsu Rotax Hino Hino
Engine_Model 350MagMPI Mark30 M50CEPTS 720CC W06DTA W06DTA
HP 300 30 50 85 310 310
23
Figura 7: Devolucin de resultados como una tabla anidada RegNum WN234CD Year 1999 Make Calabria Engines SerialNum M30099 SerialNum M3060 SerialNum T5090 SerialNum R8596 SerialNum H31096A H31096B Year 1999 Year 1962 Year 1990 Year 1997 Year 1996 1996 Make Mercruiser Make Mercury Make Tohatsu Make Rotax Make Hino Hino objetos en vez de manipular valores de claves externas escalares. Los objetos de negocio, opcionalmente, pueden estar resueltos por identidad y registrados por cambios. A continuacin se ilustra un ejemplo de cdigo para el uso del modelo conceptual a travs de objetos de negocio. Este ejemplo muestra la forma de realizar consultas en el modelo conceptual para que devuelva boats como objetos, explore a travs de propiedades hacia la recopilacin de engines y para que elimine todos los engines que no poseen el mismo year que boat. Los cambios se guardan en la base de datos mediante la llamada a SaveChanges(). Model 350MagMPI Model Mark30 Model M50CEPTS Model 720CC Model W06DTA W06DTA HP 300 HP 30 HP 50 HP 85 HP 310 310
WN345EF
1962
Del Mar
WN456GH
1957
Harvey
WN567IJ
1997
Seadoo
WN678KL
1996
Bayliner
SELECT boat.RegNum, boat.Year, boat.Make, SELECT engine.Make, engine.HP FROM boat.Engines AS engine FROM Boats AS boat WHERE boat IS OF (Motorboat) AND (Boat IS NOT OF (SkiBoat) OR TREAT(boat AS SkiBoat).Tower = False)
Cabe observar que esa consulta no requiere que el desarrollador escriba uniones; los campos relevantes del engine se proyectan como una columna anidada que utiliza boat.Engines como el origen de la subconsulta. Distintas vistas para diferentes aplicaciones Las estructuras de las aplicaciones de Web en particular, por lo general, exponen distintas vistas de los mismos datos mediante aplicaciones de Web diferentes. Por ejemplo, los datos que se exponen a clientes de Web no autenticados podran ser un subconjunto de datos expuestos a miembros preferenciales, que pueden estar modelados de forma diferente a los datos que se exponen para aplicaciones de emisin de informes y administracin interna. De igual modo, el esquema de los datos con el que se trabaja dentro de la estructura de la aplicacin puede ser muy diferente al esquema de datos que se intercambia en transacciones interempresariales. El marco de entidades ADO.NET facilita este tipo de escenarios, de modo tal que permite que mltiples modelos conceptuales se asignen al mismo esquema de bases de datos. Modelado de resultados como objetos El ejemplo anterior muestra la devolucin de resultados como registros. En el caso del marco de entidades ADO.NET esto implica la devolucin de resultados como un DataReader que se ha extendido para admitir informacin de tipo, polimorfismo, anidamiento y valores complejos. Con entidades, tambin es posible escribir consultas en el mismo modelo conceptual y obtener una devolucin de resultados como objetos de negocio no modificables. Si se modelan los resultados como objetos de negocio, las relaciones se pueden explorar y actualizar mediante la insercin de propiedades sobre los
// Specify query as an eSQL string string eSql = SELECT VALUE boat FROM Boats AS boat + WHERE EXISTS( + SELECT engine from boat.Engines AS engine + WHERE engine.Year != boat.Year);
BoatInventory inventory = new BoatInventory(); ObjectQuery<Boat> motorizedBoats = inventory.CreateQuery<Boat>(eSql); // Include Engines in results motorizedBoats.Span.Include(Engines); // Loop through Engines for each Boat foreach(Boat boat in motorizedBoats) { foreach(Engine engine in boat.Engines) { if(engine.Year!= boat.Year) boat.Engines.Remove(engine); // alternatively // engine.Boat = null; } } inventory.SaveChanges();
24

EL HECHO DE QUE EL ESQUEMA PUEDE NO SER PROPIEDAD DEL DESARROLLADOR DE LA APLICACIN Y PUEDE CAMBIAR CON EL TIEMPO, AYUDA A COMPRENDER EL MOTIVO POR EL CUAL EL ACCESO A DATOS GOO PUEDE OCUPAR ESA PARTE DESPROPORCIONADA DE UNA APLICACIN O MARCO EN LO QUE RESPECTA A CDIGO, DESARROLLO Y COSTO DE MANTENIMIENTO.
Cabe observar que al igual que en los ejemplos anteriores de consultas conceptuales, no se necesitan uniones en la consulta. Los resultados del objeto poseen establecimiento inflexible de tipos y se pueden actualizar y la navegacin y modificacin de las relaciones entre los diferentes tipos se realiza a travs de propiedades y mtodos en vez de actualizar valores claves escalares. La misma consulta se podra escribir con el uso de las nuevas extensiones de Consultas Integradas en los Lenguajes (LINQ) que se introducirn en la prxima versin de Microsoft Visual Studio y el .NET Framework (codename Orcas) como se muestra a continuacin: 6. El esquema de la base de datos puede cambiar con el paso del tiempo, lo que perjudica aplicaciones que directamente se escribieron para ese esquema. El marco de entidades ADO.NET permite que las aplicaciones se orienten hacia un modelo conceptual mediante el uso de conceptos de aplicacin como por ejemplo establecimiento inflexible de tipos, herencia y relaciones. Este modelo conceptual se puede asignar a una variedad de esquemas de almacenamiento. Debido a que la asignacin se realiza de forma declarativa, fuera de la aplicacin, los cambios que se realizan con el paso del tiempo en el esquema de la base de datos para optimizar diferentes patrones de acceso slo requieren que la asignacin cambie; la aplicacin puede continuar con el uso de las mismas consultas, recuperar los mismos resultados y realizar cambios en el mismo modelo conceptual.
Recursos Next-Generation Data Access: Making the Conceptual Level Real, J. Blakeley, D. Campbell, J. Gray, S. Muralidhar y A. Nori (MSDN, Junio de 2006) http://msdn2.microsoft.com/en-us/library/aa730866(VS.80).aspx The ADO.NET Entity Framework Overview (MSDN, Junio de 2006) http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx The LINQ Project (MSDN, Enero de 2007) http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx
BoatInventory inventory = new BoatInventory(); // Include Engines in queries for Boats inventory.Boats.Span.Include(Engines);
// Specify query through LINQ var motorizedBoats = from boat in inventory.Boats where boat.Engines.Any(e => e.Year != boat.Year) select boat;
Visual Studio Future Versions (MSDN, Enero de 2007) http://msdn2.microsoft.com/en-us/vstudio/aa700830.aspx Dr. Peter Chen: Entity Relationship Model - Past, Present and Future, Abril de 2007 http://channel9.msdn.com/Showpost.aspx?postid=298587 The Entity-Relationship Model Toward a Unified View of Data, P.P.S. Chen. ACM Transactions on Database Systems (TODS), 1976. A Relational Model of Data for Large Shared Data Banks, E. Codd. Communications of the ACM, 1970.
// Loop through Engines for each Boat foreach(Boat boat in motorizedBoats) { foreach(Engine engine in boat.Engines) { if(engine.Year != boat.Year) boat.Engines.Remove(engine); // alternatively // engine.Boat = null; } } inventory.SaveChanges();
Conclusin En resumen, existen al menos seis motivos por los cuales escribir aplicaciones directamente en el esquema de almacenamiento de bases de datos puede ser problemtico: 1. Es posible que no se tenga control sobre el esquema de almacenamiento o modelo del objeto de la aplicacin. 2. El grado de normalizacin del esquema de la base de datos puede dificultar el consumo directo desde una aplicacin. 3. Ciertos conceptos de modelado del mundo real no se pueden representar directamente en un esquema relacional. 4. Es posible que la aplicacin sea forzada a incrustar conocimiento implcito sobre el modo en el que se utilizan los campos en el esquema de bases de datos, lo que dificulta la realizacin de un seguimiento y es difcil de mantener. 5. Las diferentes aplicaciones pueden querer exponer distintas vistas de los mismos datos.
Sobre el autor Michael Pizzo ha trabajado ms de 17 aos en el diseo y entrega de APIs y soluciones de acceso a datos en Microsoft. Michael se inici en el acceso a datos como gerente de programacin para Microsoft Excel en 1989 y particip en el diseo y entrega de ODBC junto con la Herramienta de Consulta de Microsoft basada en ODBC que se lanz al mercado con Microsoft Office. Ha sido parte activa de las organizaciones de desarrollo de normas, como presidente del grupo SQL Access, y trabaj con X/Open sobre la especificacin CAE para Data Management: ASL-Call Level Interface (CLI), donde se desempe como representante de Microsoft para el Comit de Bases de Datos X3H2 de ANSI y tambin fue elegido representante de ANSI para las reuniones del Comit ISO que defini y adopt la Parte 3 de la norma ANSI/ISO SQL para Call-Level Interface (SQL/CLI). Michael fue lder y diseador clave de las API OLE DB de Microsoft y posteriormente estuvo a cargo del diseo y entrega de la versin 1.0 de ADO.NET. En la actualidad es arquitecto de software en el equipo Data Programmability en Microsoft y contribuye en la arquitectura y diseo de la prxima versin de ADO.NET y bloques de construccin fundamentales para la nueva plataforma de datos de entidad de Microsoft, el Marco de Entidades de ADO.NET.
25
Perfil del Architecture Journal: Pat Helland
Hace muy poco, el Architecture Journal se detuvo en la oficina del arquitecto de Microsoft, Pat Helland, para ponerse al da con l y peguntarle acerca de sus pensamientos sobre arquitectura y el modo en el que se puede llegar a ser arquitecto.
aire. Pero debe tener el suficiente conocimiento en estas reas para interactuar con los expertos e integrar esto en un todo cohesivo. De igual modo, un arquitecto de software debe conocer bastante sobre los diferentes aspectos del sistema ms general que se organiza para poder interactuar con los especialistas respectivos. AJ: Mucho de esto puede resultar conocido para las personas que han odo sobre la Metrpolis, verdad? (Ver Recursos) PH: S y an estoy muy interesado en el tema de la Metrpolis. Analicemos brevemente la historia del desarrollo urbano y la forma en la que han cambiado las ciudades cuando a mediados del siglo diecinueve lleg el ferrocarril. El rpido traslado de mercaderas y personas permiti, y ocasion, que ocurrieran en las ciudades los mismos cambios que en la actualidad vemos en las oficinas comerciales de informtica a medida que las diferentes computadoras y servicios se interconectan con Internet. La capacidad de comunicar y transportar datos y solicitudes de forma remota para lograr una mejor funcionalidad comercial, provoca presin en la estandarizacin. Hace que el trabajo se divida en partes y despus se conecte con estndares. Estos estndares no slo tratan la forma de transportar datos de un sitio a otro, sino que tambin responden preguntas sobre lo que es un servicio y el modo en el que se puede pensar en la operacin que se desea proporcionar. Nuevamente, esto tiene mucho que ver con lo que veamos en las ciudades cuando un fabricante se desvinculaba de un minorista que reparta mercaderas. Esto no se puede lograr a menos que se estandaricen las SKUs (Unidades Especficas de Inventario). Cuando se habla de dividir la fabricacin y hacer que los fabricantes construyan partes de cosas ms grandes, se habla de estandarizacin. Se ven muchas similitudes cuando se observan las ciudades y el desarrollo de centros de informtica ampliamente distribuidos. AJ: Estoy totalmente de acuerdo. Al trabajar en la divisin de desarrolladores, estoy seguro que debe tener que mantenerse actualizado con las ltimas tecnologas. Cmo lo logra? PH: Para m, soy una persona relativamente social y encuentro el momento para hablar con las personas que son expertas en el rea, consultarles sus perspectivas y comparar sus puntos de vista con otros expertos con los que hablo. A fin de cuentas, slo hay que leer. Se debe pensar. Es realmente un enorme desafo tratar de equilibrar el tiempo en el que se habla e interacta con las personas y uno se beneficia y ayuda de tantas formas diferentes y encontrar el tiempo para retirarse a pensar. Una vez ms, hay que leer, integrarse, permitirse reflexionar sobre las cosas y tratar de averiguar el tipo de cambios importantes, extensos que se pueden realizar y despus hay que tratar de popularizarlos. Es asombroso cunto del trabajo de un arquitecto est en evangelizar, socializar, lograr que las personas compartan el sueo. A veces, las personas me preguntan cul es mi trabajo y yo les respondo: Componer cosas y convencer a las personas para que las construyan Ese es el trabajo de un arquitecto!
AJ: Quin es y dnde trabaja? PH: Mi nombre es Pat Helland y trabajo en el equipo de Visual Studio en la Divisin de Desarrolladores. Llegu a Microsoft en 1994 y ayud a fundar el equipo que construy el Servidor de Transaccin de Microsoft y el Coordinador de Transacciones Distribuidas. En 1998, comenc a comprender que la informtica de n niveles no trataba todos los problemas que tenan nuestros clientes y particip de forma activa en lo que hoy se denomina arquitectura orientada al servicio, que sola denominarse informtica autnoma. Esto nos incentiv a trabajar sobre la conexin de servicios con mensajera confiable y colabor en el inicio de un proyecto que se lanz al mercado en SQL Server 2005 denominado SQL Service Broker. A partir del ao 2003, dediqu ms tiempo a trabajar en DPE en la evangelizacin de clientes de nuestra empresa. (Consulte la nota del recuadro para obtener ms informacin sobre la larga carrera de Pat y sus proyectos variados). AJ: Como arquitecto con varios aos de experiencia Qu consejo le dara a alguien que desea ser arquitecto? PH: La arquitectura es un rea muy interesante. Comparemos esto con la arquitectura de edificios. Si uno se detiene a reflexionar y piensa en lo que debe realizar un arquitecto de edificios, antes que nada deben pensar en una necesidad comercial y comprender el modo de crear un edificio que cumpla con esa necesidad comercial. An ms, el edificio debe transmitir cierta sensacin. Cuando alguien se detiene y mira el edificio, se transmite cierta emocin. Al mismo tiempo, se debe tratar un sin fin de pragmtica: el modo en el que circular el aire por todo el edificio; la forma en la que las personas se desplazarn por los ascensores; la manera de lograr que esto sea seguro y que cumpla con las consideraciones restantes del entorno. Se tiene a cargo el funcionamiento del edificio, el objeto utilitario, junto con el cumplimiento de las necesidades comerciales y con el efecto que esta estructura particular tendr sobre los seres humanos. Si analizamos esto desde el punto de vista del software, vemos similitudes exactas. El objetivo principal de un arquitecto de software es comprender y resolver el modo de satisfacer la necesidad comercial. A la vez, el arquitecto quiere que el software se relacione con las personas y con sus sentimientos respecto de su uso. Mientras eso se lleva a cabo, se debe tratar con todos los aspectos trascendentes necesarios para que esa cosa funcione de forma correcta y pragmtica. Un arquitecto de edificios que se ocupa de la construccin de un gran edificio puede no ser un experto en ascensores o circulacin de
26
Perfil del Architecture Journal: Don Ferguson

AJ: Me gusta esa definicin. Usted mencion socializarse y mantenerse actualizado con las personas. Cul es la persona ms importante que ha conocido y por qu? PH: Importante dentro del contexto del campo de la informtica? Yo dira mi estimado amigo Jim Gray, a quien conozco desde 1982 y hace muy poco ha desaparecido, una situacin muy difcil para muchas personas. El motivo por el cual lo estimo y lo cito como mentor es que se preocupa apasionadamente por las personas. No le importa si la persona posee un alto cargo jerrquico o si es un estudiante ambicioso, simplemente se preocupa por ellos como personas. En relacin con esto, Jim posee una extraordinaria capacidad para mirar a alguien, escucharlos unos minutos y rpidamente pasar a un nivel en el que ellos puedan comprender lo que se debate. No les habla de forma demasiado sencilla ni tampoco los abruma con tecnologa y conceptos que no comprenden. Y lo he visto hacer esto una y otra vez. Lo he observado hacer esto durante 25 aos y siempre he sido muy, muy respetuoso con esto. AJ: Si, esto es maravilloso, un gran hombre. PH: Esto le permiti crear una enorme red. He notado que Jim vea que alguien necesitaba algo y haca un poco de intermediario para contactarlo con otra persona. La combinacin que se crea a partir de esto puede ser muy poderosa y da como resultados excelentes tecnologas y maravillosos avances en la comunidad de tecnologa. Jim trabaja constantemente para ayudar a que las personas mejoren, y a la vez estudia la forma en la que puede mejorar la tecnologa y el negocio. Esta combinacin de ayudar a crecer a las personas y al mismo tiempo cumplir los objetivos comerciales al crear excelente software es una alegra inmensa y es lo que ha llevado a que Jim gane tanto respeto en la industria. AJ: Si hacemos un anlisis de su carrera Qu es de lo que ms se arrepiente? PH: De no haber seguido el consejo de Jim y haber escrito ms. No siempre tengo la disciplina que me gustara tener en lo que se refiere a obligarme a escribir todas las cosas que estn en mi mente. Tomar todas las ideas que dan vueltas en el vaco cavernoso que se encuentra sobre mis hombros y lograr escribirlas es algo que tambin deseo hacer con ms frecuencia. Jim siempre me deca: Escribe ms, comuncate ms. No s como sera para cualquier otra persona, pero s que para m es difcil tomarme el tiempo para crear un documento comunicativo, consistente, a menos que estipule una fecha lmite o que me presione a m mismo. Por lo tanto, tendra que retirarme unos das, aislarme y decir: Por dios! Tengo que hacer esto sino algo malo va a suceder! Tengo que obligarme a terminarlo, sin volver una y otra vez sobre el documento y directamente publicarlo, a pesar del que el perfeccionista que hay en m deseara volver a escribirlo. Esto es algo que me hubiera gustado haber hecho mejor y an trato de que esto suceda ms a menudo. AJ: La funcin forzadora, creo que muchas personas enfrentan esta lucha? PH: Si. Los arquitectos somos seres humanos. Slo se debe descubrir la forma de poder lograrlo. AJ: Cmo sern los prximos aos? Qu espera lograr como parte de su trabajo? PH: Mi objetivo es averiguar el modo de identificar una cierta rea de caractersticas de productos y llevarlas a un nuevo nivel. Es decir, exactamente lo que ser, slo hace cinco semanas que volv y por lo tanto, an no he formulado completamente ideas determinadas, pero quiero incluir algunas cosas interesantes en nuestro conjunto de productos.
Pat Helland posee casi 30 aos de experiencia en sistemas de bases de datos y transacciones escalables. En 1978, Pat trabaj en BTI Computer Systems donde cre un lenguaje de implementacin, generador de analizadores, sistema de rbol binario, recuperacin de transaccin y el mtodo de acceso secuencial indexado (ISAM, Indexed Sequential Access Method). A partir de 1982, Pat fue arquitecto principal e implementador senior del diseo de instalacin de supervisin de transacciones (TMF, Transaction Monitoring Facility) que implement la recuperacin/registro de bases de datos y transacciones distribuidas para el NonStop Guardian System de Tandem. Esto brind un acceso escalable y altamente disponible para datos que posean un sistema basado en mensajes tolerantes a fallas, incluida la replicacin y transacciones distribuidas para fallas de centros de datos. En 1991, Pat se traslad a HaL Computer Systems, donde descubri que poda trabajar en la arquitectura del hardware. Impuls el diseo e implementacin de un multiprocesador CC-NUMA (Cache Coherent NonUniform Memory Architecture) y una interfaz 64-MMU (Memory Management Unit). Hacia 1994, Microsoft convoc a Pat y le pidi que trabajara en la creacin de un middleware para la empresa. l se uni y dirigi la arquitectura de MS-DTC (Distributed Transaction Coordinator) y MTS (Microsoft Transaction Server). Posteriormente, Pat se interes en lo que hoy se denomina SOA (Service Oriented Architecture) e inici un proyecto que proporcion mensajera con garanta de entrega exactamente una vez y en orden, de alto rendimiento muy integrada con la base de datos de SQL. Esto se lanz con SQL Server 2005 como SQL Service Broker. Despus, Pat trabaj en WinFS y pas un tiempo evangelizando DPE para nuestros clientes corporativos ms importantes. En los ltimos dos aos, Pat ha trabajado para Amazon en las reas de exploracin, bsqueda, probabilidad de compra y catlogo. Tambin inici y dirigi una serie semanal de seminarios internos. Est muy entusiasmado en volver a su hogar, Microsoft, y trabajar en el equipo de Visual Studio. A la vez, me gustara dedicar de forma gradual ms tiempo a presentaciones, a participar en blogs, a escribir documentos que ayuden a las personas a comprender las diversas cosas sobre las que he pensado. Tambin, simplemente trabajar con personas dentro y fuera de Microsoft para ayudarlas a resolver sus problemas es lo que me hace feliz, realmente hacer una diferencia. Creo que para esto Microsoft es especial en el sentido de que se puede tener gran influencia. Aunque a decir verdad, es un lugar interesante en el que suceden muchas cosas y hay mucho caos aqu y all. A veces, las cosas en las que se trabaja no se logran y no todos son conscientes de las increbles emociones que implica la ingeniera. Las personas invierten sus esfuerzos en cosas que pueden o no tener xito. Estoy interesado en el modo de ayudar a evitar el problema que esto causa y la forma en la que puedo potenciar la alegra. Tambin me interesa ayudar a que las ideas de las personas sean conocidas. Esto es lo que me esfuerzo por lograr. Recursos Metropolis http://www.pathelland.com/presentation_overview/index.htm
27

Por Peter Hammond
Sntesis El intercambio de datos exitoso siempre ha sido y es la funcin integral ms importante de las aplicaciones. Este artculo destaca algunas experiencias desde el punto de vista de un usuario final, un desarrollador principiante, un consultor profesional y el equipo de desarrollo que se llevaron a cabo durante el transcurso de los ltimos diez aos. He tenido algunos xitos fantsticos y fracasos nefastos, y he adquirido varios puntos de vista en el camino. En este artculo detallo el modo en el que la arquitectura del pasado, combinada con la tecnologa de hoy en da, ha producido el intercambio de datos exitoso a travs de la Web.
Durante el otoo de 1994, fui transferido a la Base de la Fuerza Area Fairchild en el estado de Washington despus de una visita de cuatro meses a la maravillosa Base Area de Aviano, Italia. Una de mis responsabilidades como sargento de guardia de la polica de seguridad, una mezcla entre un despacho de la polica y un operador de la lnea 911, era documentar las actividades durante mi turno. En Aviano, esto constaba de un informe compuesto de algo ms de 12 pginas escritas a mquina con 10 copias en papel carbnico, cada una de las cuales se distribua al comando para revisin diaria. En caso de que se tuviera que arreglar alguna parte del informe, se tena que volver a escribir el informe completo y se deban distribuir otra vez las copias en papel carbnico. Matbamos muchos rboles. Se podrn imaginar mi emocin en Fairchild cuando me presentaron el nuevo Sistema de Automatizacin de la Polica de Seguridad (SPAS) basado en Windows para los informes de la polica. Posteriormente aprend que las siglas podan predecir futuros problemas. Esta aplicacin servidor/cliente en red construida sobre la base de FoxPro era algo maravilloso ya que se podan escribir todos los informes, corregir cualquier problema que se encontrara y distribuir al comando de forma digital. No moriran ms rboles en vano. Al menos eso pareca. Lamentablemente, a medida que pas el tiempo y aument la cantidad de datos, el SPAS comenz a tener muchos problemas. Despus de pasar horas escribiendo notas detalladas sobre un incidente, al hacer clic en guardar, sola titilar un mensaje de error, difcil de descifrar, que deca ndice daado. Si bien el trabajo todava estaba en la pantalla, en realidad, haba desaparecido, aunque poda no tenerse conocimiento de esto hasta que el comando llamaba y solicitaba que uno vuelva a la oficina, despus de haberse retirado, porque el informe se haba perdido. Las consecuencias fueron rpidas. Todos comenzaron a dudar del SPAS. Surgieron supersticiones respecto de lo que provocaba la falla del sistema. Se estara haciendo clic ms de una vez para guardar? o Sera por la gran cantidad de texto que se tena? o tal vez Sera porque estaba parado sobre una pierna mientras escriba con un ojo cerrado? Nadie saba con certeza. Al final, comenzamos a imprimir nuevamente todo el informe, por si acaso. De este modo comenc a comprender la importancia de confiar en los sistemas de datos. Si no se confa en las comunicaciones de datos importantes, los usuarios (y los rboles) sufren terribles consecuencias. Comenc a crear mis informes en Microsoft Word y a continuacin,
los cortaba y pegaba en el SPAS. Lograba realizar mi trabajo de forma ms rpida ya que no tena que volver a escribir todo lo que haba ingresado, incluso, si surga un error de ndice daado, rpidamente me daba cuenta que tena tiempo para solucionarlo. Comprend que el valor de contar con tecnologa funcionaba a mi favor y no en mi contra. Dediqu mi tiempo libre a aprender ms sobre los productos Office de Microsoft. Afortunadamente, tuve la oportunidad de comenzar a realizar desarrollo ligero y creaba programas de capacitacin basados en la informtica en Microsoft PowerPoint para el curso sobre Operaciones en la Base Area (ABO). Creaba presentaciones que incluan grficos, sonido y videos, lo que haca que la capacitacin sea un gran xito. Si necesitbamos realizar un seguimiento de las personas que haban finalizado la capacitacin, en vez de utilizar una planilla de firmas en papel, yo escriba un programa de pruebas que poda realizar un seguimiento de las personas que haban asistido a la capacitacin. La primera opcin que eleg fue Microsoft Excel porque pareca ser la aplicacin con la que todos registraban datos, desde vacunas antigripales hasta registros de capacitacin o resultados de la evaluacin, etc. Al usar Excel, poda especificar las preguntas en una hoja y las respuestas en otra, podra crear rpidamente un formulario de pruebas y demostrar esto con xito a mi supervisor. Todo pareca funcionar bien hasta que surgieron algunos problemas obvios. Publicamos la evaluacin de Excel en una red compartida para permitir que varias personas realicen el examen y descubrimos que slo lo poda abrir una persona por vez para el modo de edicin y todos los dems podan abrir el modo de slo lectura. Utilizaba hojas ocultas para solucionar el problema de seguridad y almacenaba las preguntas y las respuestas en el mismo archivo. Estas medidas no tuvieron xito ya que las personas consideraban que era ms rpido utilizar los formularios de evaluacin impresos que esperar a que un nico archivo est disponible y algunos usuarios descubrieron el modo de ver las hojas con respuestas que estaban ocultas. S, sufrieron ms rboles. Ni me imaginaba que mi bautismo de fuego con las dificultades de utilizar el acceso a red para tenencia de multiusuario y garantizar la seguridad real de los datos era slo la punta del iceberg. Descubr Microsoft Access que prometa resolver estos problemas y ms, ya que contaba con soporte para mltiples usuarios simultneos, seguridad basada en el usuario, as como tambin la facilidad de Excel al definir tablas, la capacidad de tener esquemas de datos complejos y el diseador de formularios avanzados. La nueva base de datos para evaluaciones de Access fue un gran xito y se me otorg espacio en el servidor torre CD de la base en el centro de redes para que toda la base pudiera completar las evaluaciones y capacitacin obligatoria de forma remota. Rpidamente se obtuvieron gran cantidad de resultados exitosos y la capacitacin pareca funcionar muy bien, desafortunadamente, demasiado bien. Resulta que me di cuenta que todos obtenan el 100 por ciento sobre las evaluaciones la primera vez. Durante el diseo, haba incluido en la respuesta de cada usuario una fecha de registro de creacin y modificacin. Saba que algo andaba mal cuando ejecutaba un informe y usaba la diferencia entre la fecha de registro de creacin y modificacin en las respuestas. La mayora de los usuarios terminaban la evaluacin de 30 preguntas en menos de 27 segundos. Se imaginarn mi asombro, cuando descubr que se
28

copiaban! Como las preguntas de la evaluacin tenan la misma secuencia, alguien haba creado una plantilla con las soluciones en papel, estoy seguro. Seleccionar las preguntas de forma aleatoria ayud a garantizar que las evaluaciones se realizaran legtimamente. Sin embargo, ahora que las personas no se copiaban, tena nuevos problemas. Se demoraba ms tiempo para completar las evaluaciones, por lo tanto, ms personas accedan a las evaluaciones en el mismo momento. La base de datos de Access me hizo comprender la dura realidad de lo que significaba la (falta de) escalabilidad. Aparentemente, el servidor CD comenz a arrojar un Error de tiempo de espera de bloqueo de registro. Cada uno produca un timbre de notificacin que era bastante molesto para los administradores de red, quienes no estaban muy contentos con la idea de que yo, un polica de seguridad, desempeara la funcin de desarrollador. De modo que, desconectaron el timbre. Como aument la cantidad de usuarios y tambin la cantidad de errores de tiempo de espera de bloqueo de registros, ocurri lo inevitable: mi pequea base de datos de Access perdi contacto con el servidor torre CD y se perdieron muchas evaluaciones en proceso, incluidas las de varios oficiales muy implacables. Esto fue especialmente desastroso por s solo, sin embargo, el impacto tuvo gran repercusin debido a que la base estaba en el medio de un enorme proceso de implementacin de Office 95 y de Windows 95 desde el servidor CD. Resolv este problema limitando la cantidad de usuarios simultneos; sin embargo, las lecciones de escala, recursos de red, integridad de datos y simultaneidad de mltiples usuarios no fueron un desperdicio para m. Al final, el curso de ABO fue un gran xito y la capacitacin se recibi bien. Continu con la creacin de otros tantos programas de bases de datos con Access, de modo tal que disfrutaba de sus caractersticas de rpido desarrollo pero siempre estaba alerta de sus limitaciones. WORMS, ARROW y Servidor de SQL Una vez que termin mi segundo reclutamiento, decid intentar desempearme en el sector civil como consultor profesional. Encontr mucho trabajo en la reparacin y actualizacin de un sin fin de sistemas que se basaban en Excel y Access. Pareca que el mundo se ejecutaba en Excel, y no muy bien. Con el tiempo, comenc a utilizar Visual Studio lo que me permiti usar Access como servidor y cdigo para resolver la mayora de sus problemas. Se me present la oportunidad de trabajar en el Sistema de Gestin Remota de rdenes de Trabajo (WORMS-Work Order Remote Management System). WORMS estaba basado en el Servidor SQL 6.5 de Microsoft y era un sistema increble. Su escala era enorme ya que ofreca servicio a cientos de usuarios y procesaba miles de registros. Pero el sistema no funcionaba bien. Aparentemente, WORMS perda registros al azar. La prdida ocurra en algn lugar entre la base de datos del servidor SQL local y el sistema Oracle de la compaa principal. Como medida provisional, todas las rdenes de trabajo se impriman en papel durante la maana y a continuacin se ingresaban a mano en una base de datos de Access por separado que se copiaba para la organizacin todos los das para conciliar los registros perdidos. Adivin, no se confiaba en los datos y se mataban ms rboles en un solo da y por lo tanto, desperdici toda mi carrera militar. Mi trabajo era cuidar el sistema mientras se desarrollaba su reemplazo, el Enrutamiento Remoto Automtico de rdenes de Trabajo (ARROW-Automatic Remote Routing of Workorders). A medida que localizaba los registros perdidos, ms me sorprenda con las capacidades de diagnstico de SQL, desde seguimiento hasta registros de eventos, poda realizar un seguimiento de todos los datos de un extremo al otro. Con este nivel de diagnstico avanzado, pude determinar la causa y la repar y posteriormente encontr los registros y perd mi trabajo, todo de una vez. La reparacin funcionaba tan bien que se cuestionaban si realmente el cliente necesitaba reemplazar el sistema ARROW y rpidamente me sacaron del proyecto para asegurar que no reparara nada ms. Sin importar el resultado, estaba entusiasmado. El Servidor de SQL era la respuesta que haba estado buscando y a continuacin comenzaron las preguntas reales. A medida que progresaba con el Servidor de SQL, los xitos continuaban. Las aplicaciones basadas en el servidor/cliente eran importantes, fcil de crear, rpidas para averiguar y resolver problemas y los usuarios estaban encantados porque cuando presionaban sobre el botn para guardar, guardaba. Confianza en los datos era igual a aplicaciones exitosas. Los aos posteriores, me contrataron para trabajar en un proyecto que registraba la capacitacin que realizaba Microsoft como academia de intranet. Mediante el uso de Microsoft .NET y el Servidor SQL 2000, rpidamente creamos una aplicacin cliente/servidor que satisfaca todas las necesidades del usuario extremadamente bien. Sin embargo, con el tiempo, aument de forma notoria la cantidad de problemas de soporte ya que las personas intentaban utilizar la aplicacin de forma remota. Puesto que deba cargar todos los registros desde el servidor cada vez que se iniciaba, el rendimiento sobre una conexin VPN era terrible. No obstante, los usuarios estaban conformes porque confiaban en que sus cambios se almacenaban de inmediato y con todos los registros cargados en la memoria, la interfaz del usuario era muy receptiva. La aplicacin se utiliz por aos. Con el tiempo, los requisitos de los recursos, problemas de conectividad de red y la explosin de Internet dieron lugar a que la popularidad de la arquitectura cliente/servidor desapareciera. Las implementaciones de n-niveles junto con los servicios de Web se consideraban el santo grial de las aplicaciones de red para el intercambio de datos en lnea. Servicios de Web y CyberSavvy Nos embarcamos de un salto sin mirar atrs. Y digo nos porque yo haba iniciado CyberSavvy, una empresa que brindaba servicios de consultora de alta calidad. Contrat lo mejor de lo mejor, algunos con quienes haba tenido el privilegio de trabajar durante el transcurso de los aos o slo por referencia. Nuestro objetivo especfico era crear las mejores soluciones para los problemas comerciales internos ms difciles de Microsoft. Las aplicaciones de Web eran la atraccin, pero las interfaces de Web que perdan todos los datos cuando la pgina produca algn error o la conexin dejaba de funcionar no generaban confianza en los datos. En cambio, nos dedicamos a crear aplicaciones de cliente inteligente con el uso de Microsoft .NET. Estas aplicaciones brindaban caractersticas de alta calidad necesarias para aplicaciones que trataban problemas empresariales complejos que implicaban datos relacionales complejos desde cualquier fuente y que requeran resultados inmediatos as como tambin la capacidad de funcionar con o sin conexin. Durante los ltimos cinco aos, creamos 15 aplicaciones de cliente inteligente para Microsoft y establecimos una slida relacin con los equipos de ClickOnce, .NET, ADO y SQL de Microsoft. La mayora de estas aplicaciones se centraban en resolver problemas que enfrentaban las fuerzas de ventas y comerciales de Microsoft. Estrategia del producto empresarial Una de las soluciones ms interesantes que creamos para Microsoft ayuda a mantener al campo actualizado con informacin de lanzamiento de nuevos productos. Puesto que las fuerzas de ventas por lo general trabajan en entorno desconectados, ya sea en trnsito o en las oficinas del cliente, la necesidad de capacidad sin conexin no permite el uso de una aplicacin de Web o solucin cliente/servidor tpica. Los requisitos para realizar rpidas bsquedas, clasificaciones y filtros a travs de todos los productos de Microsoft para presentaciones personalizadas requirieron que todos los datos se alojen de forma local y a la vez que estn actualizados. La necesidad adicional para lograr alta seguridad, debido a que cierta informacin del producto tena que ser filtrada mediante funciones granulares, requera permisos basados en filas. Al utilizar el Servidor SQL, servicios de Web y un cliente inteligente distribuido con ClickOnce obtuvimos fantsticos resultados en todos los sectores. (Ver Figura 1). La estrategia del producto empresarial (EPR-Enterprise Product Roadmap, no confundir con ERP) se adopt con rapidez en el sector, escal increblemente bien, era segura, funcionaba con o sin conexin y se destac como una implementacin modelo de Microsoft. Una desventaja era tratar de crear y mantener un diseo de servicio
29

perfeccionadas que los usuarios elogiaban mucho. Nuestras implementaciones se consideraban implementaciones modelo de Microsoft y se utilizaban en el campo para ayudar a vender el potencial de las tecnologas de Microsoft. Sin tener Entorno del servidor en cuenta los xitos anteriores, EBT pronto descubrira y pondra de manifiesto un problema Base de Servicio de Web importante, lo que implicara mucho esfuerzo. Si datos pensamos en el pasado, es claro que la mayora de La capa de datos La capa de negocios empaqueta todo acceso a proporciona lgica nuestros proyectos eran aplicaciones de consultas la base de datos para centra para interactuar y emisin de informes, principalmente de slo exponer sobrecargas en con la capa de datos, diversas consultas y lectura. EBT era un tipo de programa muy incluida cualquier norma mtodos de actualizacin. comercial que requiera diferente y los problemas relacionados con l iban la generacin de a recordarme una leccin que ya haba aprendido Conjunto de datos registros adicionales, Esquema del conjunto de como por ejemplo, haca tiempo. datos de ADO.NET registros de seguridad. completamente tipificado EBT era un programa de captura de datos as Equipo del cliente Los datos, que se proporcionan como diffgrams XML ADO.NET para como tambin de emisin de informes, compuesto reducir el trfico y la sobrecarga, pueden ser una actualizacin de tres sistemas separados que combinamos en completa o un diffgram de cambios a partir de un punto SQL determinado en el tiempo una nica solucin. La promesa de una nica Server Cliente Conjunto de datos Servicios de 2005 XML serializados inteligente aplicacin que ofreciera bsqueda avanzada y Almacenamiento Web Beta2 .NET 1.0 sin conexin acceso sin conexin fue anticipada en gran medida encriptado por los usuarios. Lanzamos la aplicacin con un gran despliegue publicitario, confiados en el xito de la solucin. Desconocamos completamente los Directorio horrores que se produciran. Usuario activo Al principio todo funcionaba muy bien. La mayora de los usuarios se conectaban a la infraestructura corporativa y al mismo de Web que utilizaba varios mtodos de Web para seleccionar y tiempo utilizaban EBT y realizaban cambios en los datos. La cantidad publicar datos en cada tabla individual (EPR tena un poco ms de 20 de cambios que se realizaba en un solo DiffGram publicado para el tablas). Estandarizamos sobre procedimientos almacenados de servicio de Web era muy pequea. A medida que las cosas seleccionar, insertar, actualizar y eliminar automatizados que se progresaban, ms usuarios trabajaban sin conexin por perodos ms utilizaban para crear un DiffGram del conjunto de datos de ADO.NET largos de tiempo y pronto comenzaron los problemas de soporte. dinmico y serializar en XML un servicio de Web que slo tena dos Al igual que con todas nuestras otras aplicaciones, EBT almacenaba mtodos. sus datos a travs de conjuntos de datos de ADO.NET en la memoria. El mtodo de Web para seleccionar consultaba todos los datos de Esto funcionaba relativamente bien para pequeas cantidades de las tablas EPR a las que haba accedido el usuario y devolva una datos. Sin embargo, los conjuntos de datos de EBT de casi ms de fecha y hora del servidor que haca referencia al momento en el que 60mb, al ser serializados en el disco provocaban una ejecucin lenta ya se consultaron los datos. El uso posterior por parte del mismo usuario que tenamos que deserializar todos los datos dentro de la memoria al dara como resultado un conjunto de datos del DiffGram, que cargarlos. Los problemas en realidad comenzaron cuando volvamos a contena un XML que representaba los datos nuevos o actualizados serializarlos en el disco al final del proceso. as como tambin lo que se haba eliminado. Utilizbamos DiffGrams sobre el cliente del mismo modo que el El mtodo de Web para publicar tomaba un DiffGram con cambios servidor para comunicar los cambios pendientes de una parte a otra. pendientes. Posteriormente, estos cambios se clasificaban de acuerdo Debido a que los DiffGrams de cambios pendientes se almacenaban al a las relaciones de claves externas y tipos de cambio para que se final del proceso, si las aplicaciones o el sistema operativo llegaban a pudieran asignar a la base de datos de SQL en la secuencia correcta. producir un error antes de que pudieran finalizar, los cambios que se De este modo tenamos mtodos de Web que no requeran cambios si haban guardado se perderan. A veces, la falla ocurra despus de se modificaba el esquema. Sin embargo, a medida que se revisaba el haber cerrado la interfaz del usuario, por lo tanto, el usuario no saba esquema, an debamos revisar la capa de datos de la cual dependan que haba un problema hasta la prxima vez que la ejecutaba y se estos dos mtodos de Web. Para cada columna o tabla nueva, era daba cuenta que los cambios se haban perdido. Tratamos de necesario revisar los procedimientos almacenados, esquemas de compensar esto y realizamos acciones de guardar incrementales conjuntos de datos y cdigo de la capa de datos del servicio de Web mientras la aplicacin se ejecutaba, pero esto caus otros tantos para que stos concuerden; un proceso que automatizamos con el problemas, como por ejemplo, demoras en el rendimiento. Sin importar tiempo. Este modelo permita rpidas actualizaciones en la cach de lo bien que lo hiciramos, esto no sola tratar el 100 por ciento de los datos del cliente inteligente mediante el uso de ADO.NET para realizar casos. todo el trabajo difcil. Obtuvimos un xito extraordinario con esto en varias aplicaciones, Concurrencia de multiusuario es decir, hasta que lo probamos con Emerging Business Team Tracker El prximo gran problema fue la concurrencia de multiusuario. Como (EBT). los DiffGrams eran bsicamente secuenciales, acciones de Insertar/Actualizar/Eliminar, si cualquier parte de los pasos fallaba al Emerging Business Team Tracker aplicarse al servidor, fallaba todo el DiffGram. Esto se manifest en s Con varias implementaciones exitosas de esta arquitectura en nuestro mismo cuando un usuario que trabajaba sin conexin por varios das y haber, nos dedicamos a EBT con gran confianza. Habamos creado realizaba grandes cantidades de cambios, al sincronizar, uno de sus procesos de automatizacin para desarrollar de forma dinmica las primeros cambios era rechazado debido a una infraccin de capas de servicios de Web y datos a partir de nuestros concurrencia porque otra persona haba actualizado la fila mientras procedimientos almacenados estandarizados. Nuestra seguridad ellos trabajaban sin conexin. estaba totalmente integrada con Active Directory con capacidad para Esto provoc las acciones posteriores para que todo fallara para el filtrar los datos del usuario en el nivel de las filas. Creamos cliente. Tratamos de resolver el problema de forma automtica, pero el aplicaciones de cliente robusto a travs de WinForms con todas las lado del cliente, por lo general, estaba demasiado desactualizado con el caractersticas extravagantes de aplicaciones altamente servidor, los cambios del usuario complicaron una serie de conflictos Figura 1: Arquitectura original para la Estrategia del producto empresarial hasta .NET 2.0 Beta 1
30

que daaron el DiffGram local. Por lo tanto, el usuario forzara una opcin para Restablecer todos los datos, de modo tal que borrara su cach y obtendra una nueva copia. Por supuesto, esto tambin provocara que se pierdan todos los cambios pendientes. Creamos cada vez ms diagnsticos basados en los reclamos y cada vez ms lgica para volver a intentar la conmutacin por error, pero los usuarios perdieron la confianza en que sus trabajos realmente se guardaran. Lo peor an estaba por llegar El uso de las aplicaciones y la cantidad de cambios que se aplicaban a travs del servidor y del cliente aument de forma exponencial. La cantidad de cambios para Insertar/Actualizar/Eliminar que deba reconciliar al mismo tiempo a travs de ADO.NET comenz a tener algunos de los problemas tan conocidos. Podrn imaginar mi desesperacin cuando un usuario enviaba un problema de soporte con la captura de pantalla de un enorme cuadro de dilogo de error en EBT con el maldito ndice daado. No poda creer que era el responsable de volver a crear el SPAS. estaban perdidos. No tan crtico como imprimirlo en papel pero perjudicial de todos modos para el xito del sistema. Cuantas ms cosas reparbamos y ms soluciones aplicbamos, ms obvio era que crebamos procesos personalizados para tratar datos en la sincronizacin de servicios de Web, que habamos decidido no hacer a favor del uso de DiffGrams de ADO.NET listos para usar. Tampoco podamos enfocarnos en la creacin de las caractersticas restantes de la aplicacin que requeran los clientes, lo que dificultaba an ms la adopcin del usuario. Duplicacin de mezcla de SQL En busca de respuestas, hicimos partcipe al equipo de ADO.NET y realizamos revisiones exhaustivas de la arquitectura. Sin lugar a duda, habamos hecho todo exactamente segn lo establecido. Los elementos bsicos de la arquitectura funcionaban para implementaciones ms pequeas o para aquellas que eran de slo lectura. Sin embargo, se determin que el uso de ADO.NET con DiffGrams para comunicar los cambios era poco recomendable debido a la combinacin de tamao y complejidad de datos, requisitos de seguridad del nivel de la fila y el modelo sin conexin con el ingreso de los datos. A medida que buscbamos nuevas formas de resolver los problemas que encontrbamos, se evidenci la necesidad de un motor de bases de datos del lado del cliente para tratar los datos de forma local y necesitaramos crear un nivel intermedio confiable para garantizar una comunicacin segura. Analizamos la duplicacin de SQL y veamos que era esencialmente lo que hacamos. Para m, la duplicacin siempre haba sido representada como una gran idea, pero una realidad terrible. Trabajamos con el equipo de SQL y nos unimos al Programa de Adopcin de Tecnologa (TAP-Technical Adoption Technology) de Yukon. La duplicacin de mezcla de SQL para sincronizar desde el servidor de SQL hacia la instancia SQLExpress del cliente pareca ptima, pero Funcionara realmente?. Durante el transcurso de dos meses, eliminamos completamente los diversos niveles de capas de datos, transformaciones de datos y servicios de Web de la aplicacin de cliente y servidor. A continuacin, volvimos a crear el cliente EBT para trabajar directamente junto a la instancia SQLExpress local y que dependiera nicamente de la duplicacin del Servidor de SQL para el transporte de los datos. Capacidad sin conexin, escala verdadera, tenencia de multiusuario, simplicidad de servidor/cliente El xito fue inmediato. Los cambios del usuario se guardaban directamente en una base de datos SQLExpress local, lo que permiti lograr en el cliente la misma confiabilidad que aportaba la versin completa de SQL al servidor. La reduccin de la lgica personalizada en mltiples niveles y la incorporacin de diagnsticos robustos del SQL y registros de eventos nos permiti brindar soluciones rpidas para casi todos los problemas que recibamos de soporte de datos. A medida que aumentaba la confianza del usuario en la integridad de los datos, tambin aumentaban sus demandas sobre nuestra arquitectura. Para nuestro gran alivio, SQL supero cada situacin e hizo frente a todos los nuevos desafos completamente. De un usuario de EBT el 23/12/2005: Lo siento pero esta aplicacin es muy poco digna de confianza en este momento y me pregunto si debera descargar todo lo que hago en los documentos de Word. Del mismo usuario de EBT, cinco meses despus, el 1/5/2006 despus de la nueva versin que usa duplicacin de SQL: Por ahora todo va bien. He realizado casi todas las combinaciones de uso de infraestructura que habitualmente generaran problemas para la duplicacin o estabilidad y no he tenido ningn inconveniente. Felicitaciones!
A MEDIDA QUE AUMENTABA LA CONFIANZA DEL USUARIO EN LA INTEGRIDAD DE LOS DATOS, TAMBIN AUMENTABAN SUS DEMANDAS SOBRE NUESTRA ARQUITECTURA. PARA NUESTRO GRAN ALIVIO, SQL SUPERO CADA SITUACIN E HIZO FRENTE A TODOS LOS NUEVOS DESAFOS COMPLETAMENTE.
Por casi un ao, asum la responsabilidad de reparar los errores y hacer que EBT funcionara, desde crear copias de seguridad de las bases de datos asncronas hasta identificar varios errores de ADO.NET insignificantes con DiffGrams de gran escala as como tambin construir diagnsticos de registros avanzados para casi todos los pasos del servicio de Web. Comenzamos a explorar mapas de memoria y conjuntos de datos binarios. Confeccionamos una utilidad administrativa que poda volver a cargar los distintos DiffGrams individuales desde sus archivos de XML y volver a crear el grupo de cambios completo en memoria. A continuacin, probbamos y analizbamos los cambios del conjunto de datos, fila por fila y los envibamos uno por uno al servicio de Web para descubrir el que realmente haba infringido una restriccin, provocado error en algn asunto de seguridad o simplemente no funcionaba por algn motivo indeterminado. Una vez que se identificaban los cambios se podan eliminar y se intentaba volver a enviar el resto del DiffGram. Esto con frecuencia fallaba ya que los cambios eran independientes debido a la estructura compleja de los datos y la seguridad. Al final, la mayora de los intentos eran en vano, la naturaleza jerrquica de los errores combinada con el aspecto sin conexin de los cambios haca que sea casi imposible diagnosticar la causa original de los problemas sin capturar el estado del cliente y el servidor al mismo tiempo. Posteriormente, descubrimos que los mismos problemas de hecho ocurran tambin con nuestras aplicaciones anteriores, como EPR. Pero como utilizaban datos de slo lectura, cuando ocurra un problema de concurrencia, se aplicaba automticamente un nuevo conjunto de datos sobre el errneo y el usuario no saba que algo haba ocurrido. Con EBT, la experiencia del usuario era catastrfica ya que el nuevo conjunto de datos poda eliminar cualquier cambio pendiente que tuvieran. Los incidentes de soporte ascendieron vertiginosamente y la mayora de las veces el problema haba avanzado demasiado y era muy tarde para tratar de repararlo. Los usuarios literalmente nos maldecan, y lo peor de todo, comenzaron a guardar capturas de pantallas de sus modificaciones de datos y despus las usaban para volver a ingresar los cambios cuando
31

Figura 2: Arquitectura de DataPlace
Equipo del cliente Servicio de Web Entorno del servidor alojado Servicio de Web Fbrica de bases de datos 100% Automatizacin Creacin y mantenimiento de bases de datos, tablas, procedimientos almacenados, vistas, publicaciones y artculos Filtro de artculos
Implementacin de seguridad en el nivel de la fila, basada en el grupo y en el usuario
ClickOnce & AutoUpdate Publishing Point Acceso a travs de Dataplace DataProvider o directamente para la instancia SQLExpress mediante el uso de SNAC, OLEDB, etc.
DataPlace DataProvider
V1.0 V1.5 V2.0 V2.5
Aplicacin personalizada
Servicio de Web Duplicacin de Web SQL 2005
DataPlace Editor SmartClient
SQL Express
.NET Replication Manager
Todo el trfico sobre SSL va https://
Confianza en los datos Continuaban los beneficios con el nuevo diseo. Por ejemplo, el reemplazo de los conjuntos de datos de ADO.NET en memoria con un motor de consulta verdadero nos permiti eliminar todo el cdigo de procesamiento de datos extremadamente complicado que era necesario para representar las distintas vistas de datos que el cliente deseaba con el SQL estndar. De este modo, pudimos aprovechar el DBA para la funcionalidad del cliente y eliminar mucho cdigo personalizado que era difcil de mantener. En algunos casos, la dimensin del cdigo se redujo a ms de un tercio. A medida que se avanzaba con la duplicacin de SQL, la transferencia segura de datos por intranet e Internet era una inquietud. Una de las promesas de los servicios de Web era la idea de que el diseo poda usarse para comunicar datos a travs de la Web. Una vez ms, la duplicacin de SQL brind la respuesta, ya que vena con una implementacin lista para usar del componente de duplicacin de Web. El uso del componente REPLISAPI, esquemas, datos y actualizaciones para ambos, permita retransmitir de forma segura y confiable a travs de los https. Habamos tenido un xito tan grande con la duplicacin de SQL que ahora proporcionamos una lnea de productos de Software como Servicio (SaaS) que se denomina DataPlace (Ver Figura 2). DataPlace expone el tremendo potencial de la duplicacin y Servidor de SQL para los usuarios finales, desarrolladores principiantes, consultores profesionales y equipos de desarrollo sin la complejidad de tener que configurarlo para ellos mismos. Proporciona una fbrica de bases de datos para disear, desarrollar, implementar y utilizar de forma dinmica el potencial de las bases de datos de SQL en un entorno completamente alojado. Es la solucin que utilizamos para crear todas nuestras ltimas aplicaciones de cliente inteligente. Este artculo relata nuestras experiencias durante el transcurso de varios aos y el modo en el que dedicamos una cantidad considerable de tiempo y esfuerzo a tratar de resolver los problemas complejos relativos al trabajo con datos a travs de la Web de forma repetible, confiable, escalable, segura y para mltiples usuarios. Estas experiencias no son poco comunes entre los desarrolladores e ilustran la necesidad de productos fiables as como tambin del conocimiento para utilizarlos. La duplicacin del Servidor de SQL 2005 de Microsoft ha brindado una respuesta importante para estos problemas tcnicos complejos. Ahora, mi equipo y yo, finalmente podemos enfocarnos en lo que comenzamos a resolver, Los problemas comerciales de nuestros clientes! 32
Recursos Aviano Air Base, Italia http://www.aviano.af.mil/ Fairchild AirForce Base http://www.wafair.ang.af.mil/ Configuring and Maintaining Replication http://msdn2.microsoft.com/en-us/library/ms151247.aspx Microsoft.NET http://msdn2.microsoft.com/en-us/netframework/aa663309.aspx Smart Client Community http://msdn.microsoft.com/smartclient/community/scfaq/default.aspx Microsoft Case Study Smart Client Sales Application Saves Time and Cuts Deployment Costs http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=49078 CyberSavvy.NET DataPlace (informacin y prueba gratuita) http://www.cybersavvy.net/dataplace
Sobre el autor Peter Hammond es presidente de CyberSavvy, proveedor preferido de Microsoft. Cumpli dos reclutamientos en la Fuerza Area de EE.UU., perodo durante el cual se interes en la programacin. Despus de su servicio, adquiri experiencia del mundo real a travs de su desempeo en varios roles, desde soporte de red hasta consultora de desarrollo en diversas compaas, incluida Microsoft. En 2002, Peter reclut un equipo de profesionales excepcionales que se dedic a crear soluciones de implementacin modelo con las ltmas tecnologas de Microsoft. CyberSavvy ha creado ms de una docena de aplicaciones empresariales, en especial Enterprise Product Roadmap, que utilizaron ms de 10.000 empleados de Microsoft por ms de cinco aos. Puede contactar a Peter en peter@cybersavvy.biz.
Complementos administrados: Control avanzado de versiones y hosting confiable

Por Jesse Kaplan
Sntesis Se introducir en Microsoft .NET Framework 3.5 una nueva arquitectura y caractersticas para un nuevo modelo de complementos administrados que se lanzar al mercado simultneamente con Visual Studio Orcas. La prxima versin del Framework contina nuestra estrategia de brindar versiones aditivas, ms nuevas, a un ritmo ms rpido que al que lanzamos revisiones completas del tiempo de ejecucin subyacente. Ya que la versin 3.0 era un conjunto de ensamblajes adicionales sobre la versin 2.0, 3.5 ser un nuevo conjunto de ensamblajes sobre 3.0. Los arquitectos de soluciones y desarrolladores de aplicaciones que desean agregar extensibilidad enfrentan un conjunto comn de obstculos tcnicos. Los ensamblajes del System.Addin que se introducen en esta prxima versin intentan tratar dos clases de problemas que surgen al agregar extensibilidad. En este artculo, describimos el modo en el que el nuevo modelo de complementos administrados y los ensamblajes tratan cada grupo de problemas. Posteriormente, explicamos algunas tcnicas de hosting avanzado que se pueden utilizar para garantizar la resistencia y confiabilidad ante complementos que no funcionan correctamente.
Los arquitectos de soluciones y desarrolladores de aplicaciones, por lo general, estn interesados en la extensibilidad por varios motivos. Un motivo comn es que cada uno de sus clientes solicita caractersticas muy especficas para las cuales la aplicacin misma nunca puede adaptarse, es por eso que ofrecen extensibilidad para permitir que los clientes cubran las necesidades ellos mismos o que compren soluciones a un tercero. Otro motivo comn para ofrecer extensibilidad es la creacin de un ecosistema de comunidades enriquecidas sobre el producto. Si se ofrece una aplicacin extensible, se puede hacer participar a la comunidad con el producto y de este modo se brinda la posibilidad de contribuir con ste a travs de esas extensiones. Independientemente de los motivos por los cuales se desee la extensibilidad, una vez que los desarrolladores de aplicaciones deciden elegir ese camino, enfrentan un conjunto comn de obstculos tcnicos. A partir de la prxima versin de .NET Framework, Microsoft presentar los ensamblajes System.AddIn para tratar dos clases de problemas que afectan a varios clientes cuando tratan de incorporar extensibilidad en sus aplicaciones, denominados problemas de Version 1 y V.Next. Los problemas de Version 1 hacen referencia a un conjunto de problemas con los cuales se enfrenta un desarrollador cuando incorpora extensibilidad por primera vez a una aplicacin. Esto incluye tareas comunes como el descubrimiento, activacin, delimitacin y aislamiento de los componentes. Por otro lado, los problemas de V.Next se refieren a un conjunto de problemas que enfrenta el desarrollador a medida que la aplicacin cambia: mantener el funcionamiento de complementos existentes en hosts nuevos, obtener nuevos complementos para ejecutarlos en hosts existentes e incluso tomar complementos que se construyeron para un host y ejecutarlos en un host diferente. El nuevo modelo de complementos administrados, y la arquitectura que definen, trata estos problemas de V.Next y las caractersticas de nuestros nuevos ensamblajes System.AddIn hacen que sea ms fcil resolver los problemas de Version 1. Creacin de versiones y arquitectura del modelo de componentes administrados Una vez que se ha distribuido una aplicacin, en realidad, con frecuencia esto sucede antes de distribuirla, los desarrolladores por lo general comienzan a planificar todos los cambios, mejoras e incorporaciones que desean realizar para la prxima versin de la aplicacin. El problema que enfrentan los desarrolladores de aplicaciones extensibles es que necesitan ingenirselas para encontrar el modo de realizar estas cosas y al mismo tiempo deben lograr que todos los complementos que se escribieron para las versiones de host anteriores funcionen en la nueva versin. Por lo general, en la actualidad, en los mejores casos esto se logra al definir nuevas interfaces que se heredan de las anteriores y tienen el host nuevo y los complementos nuevos en prueba/conversin para ver si los objetos que obtienen, en realidad heredan de las nuevas interfaces o simplemente de las anteriores. El problema es que esto obliga tanto al host como a los complementos a tener profundo conocimiento del hecho de que estas interfaces han cambiado con el transcurso del tiempo, y ambos deben asumir la complejidad de ser conscientes y flexibles ante las mltiples versiones. En el modelo de complementos administrados, se incorpora una nueva arquitectura que permite que los hosts y complementos de cada programa se comparen con su vista del modelo del objeto y proporcione a los desarrolladores una forma de colocar la lgica de adaptacin de versin-a-versin en un ensamblaje separado y aislado. Arquitectura del proceso La figura 1 muestra la arquitectura que se cre para facilitar la comunicacin versionable entre hosts y complementos. El objetivo es proporcionar una vista estable del modelo del objeto tanto para los hosts como para los complementos con capas que abstraigan el modo en el que esta vista se transporta a travs del lmite de aislamiento, la forma en la que se versiona e incluso, el modo en el que se consume del otro lado. Cada cuadro de la Figura 1 en realidad representa un ensamblaje que contiene varios tipos diferentes. Por lo general, para cada tipo de objeto personalizado que se intercambia entre el complemento y el host, habr al menos un tipo correspondiente en cada componente de contrato, adaptador y vista. El host y los complementos son las entidades que agregan funcionalidad real al sistema, mientras que los otros componentes estn para representar el modelo del objeto, transportarlo a travs del lmite de aislamiento y adaptarlo en caso de ser necesario. Si se analiza la Figura 1, comienzan a aparecer varias propiedades
33
Modelo de complementos administrados

Figura 1: Proceso de comunicacin del host/complemento
Lmite de aislamiento
Host
Vista del host
Adaptador del lado del host
Contrato
Adaptador del lado del complemento
Vista del complemento
Complemento
Dependencia esttica
muy importantes de esta arquitectura. Lo primero y principal es el hecho de que el host/complemento slo depende de su vista; la vista no tiene dependencias sobre otros componentes de la comunicacin. Esto proporciona una barrera de abstraccin que permite que el host permanezca completamente agnstico al modo en el que el complemento, y el mecanismo de comunicacin entre ellos, se implementa realmente y viceversa. De hecho, si se observan las dependencias estticas se puede ver que toda la parte del centro, de adaptador a adaptador, se puede reemplazar completamente sin que el host o el complemento ni siquiera tengan conocimiento de esto. Otro aspecto importante de esta arquitectura es que este modelo es en realidad completamente simtrico en todo el lmite de aislamiento, como se muestra en la Figura 2. Esto significa que desde el punto de vista arquitectnico no existe diferencia entre el modo en el que se comunican los hosts y los complementos y se versionan con el transcurso del tiempo. En realidad, en nuestro modelo, la nica diferencia real entre un host y un complemento es que el host resulta ser que es el que activa a los otros: Una vez que ocurre la activacin, llegan a tener casi la misma importancia en el sistema. Ahora que ya hemos descripto la arquitectura global, podemos profundizar los detalles concretos de cada tipo de componente del proceso y su funcin en el sistema. Componente de Vista. El componente de vista representa, de forma bastante literal, las vistas de cada uno de los otros hosts y complementos y los tipos que intercambian entre ellos. Estos componentes contienen las interfaces y clases de base abstractas contra las cuales programar cada lado y son bsicamente el SDK de cada lado para el otro. Los hosts y los complementos estn sujetos de forma esttica a una versin particular de estos ensamblajes de la vista y por lo tanto, se garantiza que podrn codificar contra esta vista esttica sin importar el modo en el que se haya implementado el otro lado. En V1 de una aplicacin, estos ensamblajes de la vista pueden ser muy similares, de hecho, pueden ser el mismo ensamblaje, pero con el paso del tiempo pueden cambiar, en realidad, incluso en algunas aplicaciones de V1 puede ser muy til tener una vista radicalmente diferente para Figura 2: Simetra del proceso de comunicacin
cada lado. Es tarea de los componentes asegurar que an los ensamblajes de vistas radicalmente diferentes se puedan comunicar entre ellos. Componente del contrato. El componente del contrato es el nico componente cuyos tipos cruzan de hecho el lmite de aislamiento. Su tarea es bastante extraa en el sentido de que realmente no es un contrato entre el host y el complemento: No podra serlo, ya que los hosts y el complemento nunca saben que componente del contrato realmente se utiliza. En cambio, el componente del contrato en realidad representa un contrato entre los dos adaptadores y facilita la comunicacin entre ellos a travs de lmite de aislamiento. Debido a que ste es el nico ensamblaje que se carga en ambos lados del lmite, es importante que el ensamblaje del contrato en s mismo nunca cree versiones: Si el adaptador de un lado esperara una versin de un contrato y el adaptador del otro lado esperara una versin diferente, se interrumpira el contrato y la comunicacin fallara. Si bien decimos que un contrato nunca puede crear versiones, no estamos diciendo que el host y el complemento siempre deben utilizar el mismo. Debido a que el contrato es un contrato entre los adaptadores y no entre el host/complemento, se puede cambiar el contrato siempre que se desee; simplemente es necesario crear nuevos adaptadores que puedan tratar ese nuevo contrato. La funcin especial del contrato en nuestro sistema requiere restricciones sobre los tipos que se permiten contener en el interior. En un alto nivel, todos los tipos que se definen en el ensamblaje del contrato deben ser interfaces que implementen la propiedad System.AddIn.Contract.IContract o deben ser tipos de valor serializables mediante la implementacin de una serializacin tolerante a versiones. Adems, los miembros de estos tipos, ms especficamente valores devueltos y parmetros sobre sus mtodos, deben tambin ser tipos que obedezcan las mismas reglas. Estas restricciones garantizan que todos los tipos de referencia que cruzan el lmite implementen al menos el conjunto de funcionalidad base que requiere el sistema y que los tipos de valor sean serializables y se puedan serializar a travs de las versiones. Componente del adaptador. La funcin del componente del adaptador es realizar una adaptacin entre los tipos de vista y los tipos de contrato. En realidad, existen dos tipos de adaptadores en cada componente del adaptador: vista-para-contrato y contratopara-vista. En casi todos los casos, los adaptadores del host y del complemento contienen ambos tipos ya que, en la mayora de los modelos de objetos, los objetos se pasan tanto desde el host al complemento as como tambin del complemento al host. El adaptador cumple su funcin a travs de la implementacin del tipo de destino segn su tipo de origen. Los adaptadores de vista-para-contrato deben adaptar desde un tipo de vista y hacia un tipo de contrato y por lo tanto, tomarn el tipo de vista dentro de su constructor e implementarn la interfaz del contrato a travs de una llamada a esa vista. Si los valores devueltos o ingresos para los mtodos de las interfaces del contrato no son tipos bsicos que se puedan directamente pasar hacia la vista y devolver desde la vista, entonces ser tarea del adaptador realizar llamadas a otros adaptadores para que traten esos tipos. El adaptador de contrato-para-vista cumple exactamente la funcin opuesta a la del adaptador de vista-para-contrato, usa el contrato dentro de su constructor e implementa la vista a travs de una llamada a ese contrato. Tambin, asume la responsabilidad de llamar a otros adaptadores cuando los tipos de devolucin/ingreso lo justifiquen. Ahora que ya hemos definido las partes individuales del proceso y sus funciones, podemos agrupar todo y demostrar el modo en el que se transfiere un tipo de un lado al otro. Comienza con la instancia del tipo que se debe pasar: que se define a travs del host o el complemento.
Host/ complemento
Vista
Adaptador
Contrato
34

Host existente / Complemento nuevo. Es posible escribir un AddInSideAdapter que convierta un AddInView ms nuevo para contratos existentes. Estas transformaciones sern muy similares a las que se requieren para lograr que los complementos existentes se ejecuten sobre hosts ms nuevos. (Ver Figura 5). Otros escenarios del proceso. Adems de estos escenarios de compatibilidad con versiones anteriores/posteriores, esta arquitectura permite otros escenarios interesantes. Uno de estos escenarios sera para que el desarrollador del proceso cree dos procesos separados para los mismos tipos de vista y los optimice para diferentes lmites de aislamiento: por ejemplo, crear un proceso que sea muy rpido y se utilice para los complementos aislados de AppDomain y usar uno diferente para las situaciones fuera de proceso que trata los problemas del subproceso. Tambin, se puede ir en la direccin opuesta: en vez de crear un proceso para conectar una versin de un host a complementos que se crearon para una versin diferente, crear uno que conecte complementos que se crearon para un host hacia un host completamente diferente. Este escenario destaca una propiedad importante de esta arquitectura: El desarrollador del proceso puede ser independiente tanto del host como del complemento, y de este modo permite que terceros traten otros problemas. Si el desarrollador del host decide dejar de admitir compatibilidad con los complementos anteriores, simplemente debe dejar de crear adaptadores para estos, pero un cliente del nuevo host (o un contratista) podra an crear e instalar ese adaptador y de este modo permite extender la vida del complemento original. Mantenimiento de SystemAddIn para el hosting de complementos administrados Definir un modelo del objeto y facilitarlo para el desarrollo de complementos Cuando se piensa en exponer puntos de extensibilidad en las aplicaciones, las primeras inquietudes de varios desarrolladores se refieren a la definicin del modelo del objeto que desean exponer y a tratar de garantizar que la experiencia para los desarrolladores de complementos sea lo ms fcil posible. Creemos en gran medida que la implementacin de la aplicacin del host debe estar separada del modelo del objeto que expone a sus complementos: Esta creencia naturalmente lleva a un diseo en el que el modelo del objeto que se expone reside en un ensamblaje separado fuera del host (denominado ensamblaje de vista) y contiene un grupo de clases, por lo general interfaces y clases de base abstractas, que representa las vistas del host y del complemento entre s y de los objetos que se intercambian entre ellos. Esta definicin de un ensamblaje de vista con interfaces y clases de base abstractas lleva a un modelo de programacin para complementos que es fcil y posee baja sobrecarga: Simplemente incorpora una referencia en el ensamblaje de la vista y a continuacin hereda desde/implementa la interfaz o clase de base abstracta que el host defini. La interfaz o clase de base que el host del complemento especifica ser de donde se heredan los complementos, se denomina AddInBase. En el caso ms simple, los desarrolladores de complementos slo compilan los ensamblajes y los colocan en un directorio que busca el host. Figura 4: Compatibilidad anterior: Complemento V1 sobre host V2
Figura 3: Va de activacin
Host
Vista complemento host
Adaptador del host
ContratoI
Adaptador del complemento
Vista del complemento
Complemento
Herencia
Argumento del constructor
Pasa la instancia al adaptador escrita como su vista. Construye un adaptador de vista-para-contrato con la instancia. Pasa el adaptador a travs del lmite de aislamiento escrito como el contrato. Construye un adaptador de contrato-para-vista mediante el uso del contrato. Pasa nuevamente el adaptador hacia el otro lado escrito como la vista.
Esto puede parecer mucha sobrecarga, pero en realidad slo comprende dos instancias de objetos. En el contexto de una llamada a travs de un lmite de aislamiento (AppDomain o Proceso) la sobrecarga del rendimiento es por lo general mucho menor que el margen de error de las mediciones. En el estado constante, todos los pasos mencionados anteriormente, se tratan a travs de la cadena de adaptadores activada previamente en las conexiones entre el host y el complemento. El sistema en s mismo slo interviene para activar el complemento, pasarlo de nuevo al host y de este modo crear la primera conexin. Este paso de activacin es slo un ejemplo de un objeto que se pasa desde el lado del complemento hacia el host (Figura 3). Observen que este diagrama en realidad tiene nombres un poco diferentes para algunos de los cuadros ya que se refiere a tipos especficos dentro de cada componente del proceso. Estos nombres slo se usan para los tipos que se utilizan en la va de activacin ya que son los nicos tipos en los ensamblajes de los cuales la infraestructura del sistema realmente se ocupa de forma directa.
Escenarios interesantes de creacin de versiones Habitualmente, la vista del host cambia con el tiempo a medida que se publican nuevas versiones de la aplicacin. Puede requerir informacin o funcionalidad adicional de sus complementos o los tipos de datos que pasa pueden tener mayor o menor cantidad de campos y funciones. Anteriormente, debido al acoplamiento estrecho entre el host y los complementos (y sus tipos de datos), esto por lo general significaba que los complementos que se creaban a partir de una versin de una aplicacin que no se podan utilizar en versiones posteriores y viceversa. Nuestra nueva arquitectura se dise desde cero para proporcionar las capas de abstraccin adecuadas que permitan que los hosts y complementos se relacionen con los modelos de objetos radicalmente diferentes para comunicarse y conectarse entre s. Host nuevo / Complemento existente. El primer escenario de creacin de versiones en el que piensa cualquier persona es un host nuevo, con un modelo de objeto revisado, que trata de ejecutar complementos que se crearon para versiones anteriores del host (Ver Figura 4). Con nuestro nuevo modelo, si la vista del host cambia de una versin a la prxima, el desarrollador slo debe crear un segundo AddinSideAdapter, que se hereda desde el nuevo contrato y convertirlo a la versin de AddInView. El beneficio de este enfoque es que los complementos existentes simplemente seguirn funcionando, an con los nuevos cambios. La aplicacin misma no debe mantener un registro de las diferentes versiones de los complementos y slo se ocupa de una nica vista de host; los diferentes componentes del proceso se conectan tanto a la vista anterior como a la nueva. En estos casos, el host est estrechamente acoplado a una vista diferente, pero la creacin de versiones an es posible ya que esas vistas no estn acopladas de forma estrecha entre s.
Vista del host V2 Host V2 Vista del host V2
Adaptador del lado del host V2
Contrato V2
Adaptador del lado del complemento V1->V2
Vista del complemento V1
Complemento V1
Contrato V2
Adaptador del lado del complemento V2
Complemento V2
35

Por lo general, el desarrollador de complementos tambin aplicar un atributo personalizado para identificarlo para el host, lo que proporciona al host informacin sobre el complemento antes de que decida activarlo.
Descubrimiento y activacin Una vez que el desarrollador de aplicaciones ha definido el modelo del objeto, los prximos pasos son averiguar el modo de descubrir complementos disponibles y activar los que se desea. Habitualmente, las aplicaciones desempean estas acciones al iniciarse o en respuesta a una peticin del usuario, por lo tanto, el rendimiento de estas operaciones es importante. Otro requerimiento comn para el descubrimiento es poder consultar el sistema respecto de los complementos disponibles y obtener informacin sobre cada complemento antes de decidir los complementos que se activarn. System.AddIn expone esta funcionalidad a travs de dos clases principales: AddInStore y AddInToken. AddInStore contiene un conjunto de mtodos estticos que se utilizan para encontrar los complementos disponibles a partir del tipo de complemento solicitado y un conjunto de ubicaciones para buscar los complementos. Estos mtodos devuelven una recopilacin de AddInTokens que representan los complementos disponibles y proporcionan informacin sobre esos complementos. Una vez que se han decidido los AddInTokens que se activarn, simplemente se debe realizar una llamada al mtodo Activate sobre el AddInToken y recibir un complemento del tipo solicitado. De un modo ms simple, el descubrimiento y la activacin se pueden llevar a cabo con slo unas pocas lneas (en verdad, en la siguiente muestra se omite una lnea de cdigo): Figura 5: Compatibilidad posterior: Complemento V2 sobre host V1
Vista del host V1 Host V1 Vista del host V1
Contrato V1
Adaptador del lado del complemento V1
Complemento V1
Adaptador del lado del hostV1
Contrato V1
Adaptador del lado del complemento V2 V1
Complemento V2
Si el rendimiento del inicio es crtico, la aplicacin puede decidir slo realizar una llamada a FindAddIns o requerir que los desarrolladores de complementos utilicen AddInUtil como parte de su instalacin o brinden a los usuarios la posibilidad de iniciar una actualizacin de la cach y de los complementos disponibles. Por otro lado, el desarrollador de aplicaciones puede decidir aceptar una disminucin del rendimiento que slo ocurra cuando se instalan nuevos complementos y realizar una llamada a AddInStore.Update al iniciar.
Aislamiento/Sandboxing Por supuesto, descubrir los complementos y decidir activarlos es slo una parte de la historia: Tambin es necesario garantizar que los complementos se activen en el entorno deseado. A continuacin se detallan varios tems que constituyen este entorno.
Nivel de aislamiento In-AppDomain Cross-AppDomain Cross-Process Agrupamiento En dominios con otros complementos que especifica el host token.Activate<AddInType>( En su propio dominio AddInSecurityLevel.Internet); Cross-process en un dominio con otros complementos que especifica } el host Cross-process en su propio dominio con otros dominios en el proceso En System.AddIn, se asegura que las aplicaciones puedan incluir externo que aloja otros complementos. el descubrimiento y la activacin de complementos en sus rutas de inicio e incluso que cuenten con una buena experiencia de usuario. El Cross-process en su propio dominio, sin ningn otro complemento que se ejecute en ese proceso. mtodo FindAddIns, por lo general, es seguro para realizar una llamada al iniciar ya que en realidad no carga ningn ensamblaje (ni Nivel de seguridad tampoco los lee desde el disco); en cambio, busca en un archivo de Una de las opciones predeterminadas del sistema: Internet, la cach el directorio especificado. Este archivo de la cach incluye Intranet, FullTrust informacin sobre todos los complementos disponibles en un PermissionSet personalizado que determina el host. directorio especfico as como tambin el AddInBase de cada complemento. De este modo, FindAddIns puede enumerar Si se analizan las sobrecargas disponibles en AddInToken.Activate, se rpidamente todos los complementos disponibles de un tipo puede observar lo fcil que es para el host determinar en entorno determinado en cada directorio provisto a travs del anlisis de un deseado. En el caso ms simple, el host slo debe pasar un valor de nico archivo de la cach en vez de analizar todos los ensamblajes enumeracin que especifique Internet, Intranet o FullTrust y deber de cada directorio y enumerar los tipos en cada ensamblaje que crear un AppDomain con ese nivel de confianza, activar el buscan complementos. complemento en l y a continuacin volverlo a pasar. El nivel de Por supuesto, ya que FindAddIns brinda la seguridad de que slo dificultad depende de la cantidad de control que desee el host: en el analiza un archivo de la cach, la pregunta es: Cundo se genera nivel ms alto de control, puede crear un AppDomain por s solo, este archivo de la cach? Aqu es cuando interviene la lnea que se ajustarlo con precisin conforme a sus necesidades y despus pasarlo omiti: para su activacin.
IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(AddInType), addinPath); foreach (AddInToken token in tokens) {
AddInStore.Update(addinPath);
AddInStore.Update, en primer lugar determinar si la cach de la ubicacin que se proporcion est actualizada. Si la cach est actualizada, entonces el mtodo realizar una devolucin muy rpida; de lo contrario, ser necesario volver a crear la cach. Tambin se proporciona una herramienta como parte del framework (AddInUtil.exe) que facilita la actualizacin de la cach como parte de un programa de instalacin. Al separar FindAddIns y Update, y proveer una herramienta de lnea de comandos que desempea la misma funcin, brindamos mucha flexibilidad a las aplicaciones del host. 36
Tcnicas de hosting confiable Hosting confiable Uno de los problemas de importancia fundamental para los desarrolladores de aplicaciones extensibles es la capacidad de mantener la confiabilidad del host al enfrentarse con complementos que poseen fallas. En algunos casos, esto es importante porque la aplicacin del

host en s misma es fundamental y no puede aceptar la posibilidad de tiempo de inactividad que puede provocar un complemento; en otros casos, el desarrollador del host simplemente no puede permitirse el costo del mantenimiento de clientes que se dirigen a ellos para solicitar ayuda debido a errores en extensiones de terceros. Algunos hosts slo deben poder identificar y desactivar el complemento que causa el error, mientras que otros, deben garantizar que el host siga en ejecucin, sin importar lo que hagan los complementos. Se deben evaluar los requisitos de confiabilidad de cada host. Por lo general, existen tres categoras de incumbencias APRA los desarrolladores de hosts cuando se trata de confiabilidad: dao de estado del equipo, excepciones no controladas (errores) y agotamiento de recursos del equipo. Cada categora posee sus propios problemas exclusivos y requieren que se tomen diferentes medidas.
Dao de estado del equipo De alguna manera, el dao de estado del equipo puede ser el problema ms fcil de tratar ya que el sistema en s mismo posee el mayor soporte para prevenirlo. Por lo general, todos lo que los hosts deben hacer es conceder sus complementos al PermissionSet de seguridad de la forma ms limitada posible y el sistema de seguridad de acceso a cdigo de .NET Frameworks garantizar que el complemento permanezca dentro de esos lmites. Los APIs en System.AddIn facilitan esto an ms ya sea al brindar posibilidad a los hosts para que utilicen uno de los niveles de seguridad definidos por el sistema o permitindoles definir su porpio PermissionSet personalizado. Cuantos ms recursos del sistema se desean proteger de los complementos, menos permisos poseen esos complementos cuando se ejecutan. Excepciones no controladas Las excepciones no controladas son ms interesantes ya que en realidad existen dos tipos de excepciones no controladas por las cuales debe preocuparse el host. El primer tipo incluye las excepciones que se envan al host durante una llamada que realiza el host al complemento y en el mismo subproceso. Para tratar estas excepciones el host debe agregar un bloque try/catch sobre las llamadas que realiza a los complementos y debe reaccionar de forma adecuada cuando se produce una excepcin. Las otras excepciones son ms difciles de tratar ya que en realidad es imposible que un host las capture. Estas son excepciones que ocurren en subprocesos que se originan a partir de complementos o en subprocesos en los que el host no est por debajo de la pila. A partir de la versin 2.0 del Tiempo de Ejecucin en Lenguaje Comn (CLR), estas excepciones no controladas siempre sern fatales para el proceso; por lo tanto, si no se tiene cuidado, es muy fcil que un complemento con errores, tambin dae al host. Si el requisito de confiabilidad del host slo requiere que se desactiven los complementos problemticos (con frecuencia, una solucin perfectamente aceptable para soluciones de cliente), el host puede beneficiarse de lo que en la clase AppDomain se denomina evento de UnhandledException. Este evento se activa cuando un subproceso que se origina en el AppDomain destino produce una excepcin no controlada que est por bloquear el proceso. Si el host slo desea identificar el complemento que no funciona bien y desactivarlo, puede aceptar estos eventos sobre los AppDomains en los cuales se ejecutan sus complementos; cuando el evento se activa, puede registrar el complemento que se ejecutaba en ese AppDomain. El host no puede impedir que el proceso sea bloqueado, pero podr incorporar el complemento en una lista desactivada y luego reiniciar el host. Si el host debe garantizar que un complemento con error no pueda bloquear el host, entonces deber tomar medidas adicionales y aislar sus complementos en procesos diferentes. Existe una disminucin en el rendimiento asociada, pero el aislamiento asegura que slo el proceso del complemento deje de funcionar en el caso de error. Agotamiento de recursos del equipo La ltima categora de problemas de la cual debe tener conocimiento el host es el agotamiento de recursos del sistema que provoca el complemento. Esto puede consistir en el uso de cantidades excesivas de memoria o incluso, ciclos del CPU. Dentro de un proceso, no hay forma de limitar los recursos de los complementos que se ejecutan en diferentes AppDomains, pero tan pronto como se los traslada a un proceso diferente, se puede utilizar el sistema operativo para limitar esos complementos. Una vez que se activ el complemento fuera de proceso, slo se requieren algunas lneas adicionales de cdigo para lograr esta limitacin:
AddInProcess addInProcess = new AddInProcess(); AddInType addIn = token.Activate<AddIntype>(addInProcess, AddInSecurityLevel.FullTrust); Process tmpAddInProcess = Process.GetProcessById(addInProcess.ProcessId); //Lower the priority of the add-in process below that of the host tmpAddInProcess.PriorityClass = ProcessPriorityClass.BelowNormal; //Limit the add-in process to 50mb of physical memory tmpAddInProcess.MaxWorkingSet = (IntPtr)50000000;
Incluso, los hosts pueden dar ms de s y utilizar el sistema operativo para controlar todo, desde el tiempo total de CPU que consume el proceso hasta la cantidad de solicitudes de E/S a disco que se realizan por segundo, y a continuacin, tomar las medidas adecuadas.
Conclusin Con la incorporacin de ensamblajes de System.AddIn y la arquitectura que soportan, Microsoft .NET Framework 3.5 brinda un modelo completo de complementos administrados, ya antes prometido en PDC 2005. Se puede esperar ver algunas incorporaciones a nuestro conjunto de caractersticas en betas futuras y an ms, en futuras versiones, pero todo lo que se necesita para crear hosts totalmente extensibles, versionables y confiables est disponible ahora y listo para usar. Para obtener ms informacin sobre los temas que se tratan en este artculo o para consultar informacin general sobre este modelo de complementos, visite el blog del equipo de complementos en MSDN (Ver Recursos).
Recursos adicionales CLR Add-In Team Blog http://blogs.msdn.com/clraddins/
CLR InsideOut: .Net Application Extensibility, Jack Gudenkauf y Jesse Kaplan, MSDN Magazine, febrero y marzo, 2007 Parte 1, http://msdn.microsoft.com/msdnmag/issues/07/02/CLRInsideOut/ Parte 2, http://msdn.microsoft.com/msdnmag/issues/07/03/CLRInsideOut/ Visual Studio Code Name Orcas http://msdn.microsoft.com/vstudio/future
Sobre el autor Jesse Kaplan es gerente de programa para versionado en tiempo de ejecucin y extensibilidad de aplicaciones en el equipo de Tiempo de Ejecucin en Lenguaje Comn. Sus reas de responsabilidad anteriores incluyen compatibilidad, interoperabilidad (COM) navito-gestionado y metadatos.
37
098-108021
Suscrbase en www.architecturejournal.net

Journal12 Spanish

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Journal12 Spanish

Uploaded by

Copyright:

Available Formats

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

www.ArchitectureJournal.net Recursos que sirven de base

Web 2.0 en la empresa

Entrega de software eficaz a travs de plataformas de distribucin de servicios

Comunicacin segura entre dominios en el explorador

Modelo orientado a aplicaciones para datos relacionales

Perfil del Architecture Journal: Pat Helland

Confianza en los datos a travs de la Web

Complementos administrados: control avanzado de versiones y hosting confiable

que sirven de base. www.architecturejournal.net

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Web 2.0 en la empresa

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Web 2.0 en la empresa

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Web 2.0 en la empresa

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Web 2.0 en la empresa

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Web 2.0 en la empresa

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Entrega de software eficaz a travs de plataformas de distribucin de servicios

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Plataformas de distribucin de servicios

Otra Apl IU + BizLogic Infraestructura de la Apl

Estructura de la aplicacin comn SO

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Plataforma de propsito general

Plataformas de distribucin de servicios

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Plataformas de distribucin de servicios

Figura 3: Impulsar economas de escala a travs de una infraestructura compartida mejorada

IU + BizLogic Gestin operativa

Arquitectura de Apl Registro Excepciones

Arquitectura de Apl Registro Excepciones

Servicios de red Supervisin de SLA

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Plataformas de distribucin de servicios

Apl A del ISV IU + BizLogic

Apl B del ISV IU + BizLogic

Apl C del ISV IU + BizLogic

Supervisin principal Servicios de red Almacenamiento

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Plataformas de distribucin de servicios

Figura 6: La implementacin incluye definiciones de cdigo y tiempo de ejecucin

Apl A del ISV

SLA+ Manifest. de implementacin

Apl C del ISV +

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Plataformas de distribucin de servicios

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Comunicacin segura entre dominios en el explorador

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Comunicacin segura entre dominios

Figura 1: Paso de datos del URL del iframe

THE ARCHITECTURE JOURNAL Journal 12 www.architecturejournal.net

Comunicacin segura entre dominios

Historial del explorador

Cach del explorador

Consulta: http:// bar.com/page.html?one Consulta: http:// bar.com/page.html?two Consulta: http:// bar.com/page.html?three

Consulta: http:// bar.com/page.html#one Consulta: http:// bar.com/page.html#two Consulta: http:// bar.com/page.html#three

Llenado de cach Aciertos en la cach

www.architecturejournal.net - Journal 12 THE ARCHITECTURE JOURNAL

Comunicacin segura entre dominios