• WarNov Developer Evangelist

    EntityFramework Interoperable

    • 0 Comments

    Sabemos que una de las tareas más costosas en el desarrollo de una solución de software, es la creación de la capa de acceso a datos. Como ya sabemos, Microsoft hoy en día nos ofrece una brillante alternativa en cuanto a ORM. El EntityFramework, que soporta originalmente en el fondo a MS Sql Server. Sin embargo, en este artículo veremos cómo nuestras tecnologías están abiertas a ser interoperables con otros motores de bases de datos como MySql y PostgreSQL.

    Para este post, me he permitido invitar a Emerson Perdomo. Ingeniero de Sistemas de la Universidad Distrital de Bogotá. Gran colaborador en nuestra subsidiaria de Microsoft Colombia quien ha estudiado bastante el tema de ORM y creación automática de formularios basados en clases. Las siguientes instrucciones fueron creadas por él, para ayudarnos a comprender el proceso de conectar el EntityFramework a otras fuentes de datos.

    PostgreSQL

    Npgsql - .Net Data Provider for Postgresql es un conjunto de DLLs que se agregan a Visual Studio .Net pero no se integran con el Wizard del Visual Studio .Net porque no hay soporte oficial de Npgsql, sin embargo, se pueden agregar en cada uno de los proyectos sin ningún problema; el inconveniente es que al intentar usarlas hay que generar el modelo desde "Visual Studio 2008 Command Prompt" e incluir los dos archivos ".cs" que genera al proyecto.
    A Continuación doy los pasos para poder usarlo en un ejemplo sencillo.

    PASO 1:

    Descargue de la página oficial de Npgsql
    http://pgfoundry.org/frs/?group_id=1000140

    El archivo:
    Npgsql2.0.8-bin-ms.net3.5sp1.zip

    Npgsql2.0.8-bin-ms.net3.5sp1.zip

    Descargue la Última versión de PostgreSQL
    http://www.enterprisedb.com/products/pgdownload.do#windows

    Obviamente hay que tener
    Visual Studio 2008 Professional Edition Trial con SP1
    http://www.microsoft.com/express/Downloads/

    .Net Framework 3.5
    http://www.microsoft.com/downloads/details.aspx?FamilyID=d0e5dea7-ac26-4ad7-b68c-fe5076bba986&displaylang=es

    PASO 2:

    Instalamos el PostgreSQL , el Visual Studio, .NET Framework 3.5 y descomprimimos el Npgsql2.0.8-bin-ms.net3.5sp1.zip recomiendo que lo descompriman en C:\ para que no estén buscando la ubicación.
    Ahora vamos a registrar nuestras DLL de Npgsql en el GAC de Visual Studio.
    Primero hay que abrir nuestro "Visual Studio 2008 Command Prompt" que se encuentra por lo general en "Inicio -> Microsoft Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Prompt "
    Ahí ejecutamos las siguientes líneas de código:
    gacutil -i c:\ubicacion de la dll Npgsql\Npgsql.dll
    gacutil -i c:\ubicacion de la dll Mono.Security\ Mono.Security.dll
    en mi caso
    gacutil -i c:\ Npgsql2.0.8-bin-ms.net3.5sp1\bin\Npgsql.dll
    gacutil -i c:\ Npgsql2.0.8-bin-ms.net3.5sp1\bin\Mono.Security.dll

    PASO 3:

    Ahora hay que agregar una línea de código XML al archivo machine.config del Framework que por lo general se encuentra en C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\
    Abrimos el Archivo machine.config con el editor de su preferencia.
    Y agregamos en el área de <DbProviderFactories> </DbProviderFactories>
    la Siguiente línea de código

    <DbProviderFactories>
    <add name="Npgsql Data Provider" invariant="Npgsql" support="FF" description=".Net Framework Data Provider for Postgresql Server" type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.8.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" />
    </DbProviderFactories>

    PASO 4:

    Ahora abrimos el motor de base de datos PostgrsSQL y creamos una base de datos sencilla
    Base de datos Test
    http://www.megaupload.com/?d=2XS1OYGU
    Recuerda que la base de datos esta sin datos hay que alimentarla.

    PASO 5:

    Ahora ejecutamos la siguiente línea de código en el "Visual Studio 2008 Command Prompt".
    c:\> edmgen.exe /provider:Npgsql /mode:fullgeneration /c:"string de conexion" /project:NombreQueQuiera /language:CSharp
    En mi caso
    c:\> edmgen.exe /provider:Npgsql /mode:fullgeneration /c:"DATABASE=test;HOST=127.0.0.1;PORT=5432;PASSWORD=yta;USER ID=postgres" /project:TestPostgreSQL /language:CSharp
    Los Archivos van a quedar en esta Ubicación
    C:\Program Files\Microsoft Visual Studio 9.0\VC
    De ahí lo pasas al proyecto que estés trabajando y Solo agregas los archivos ".cs":

    Insertando modelo de Postgresql en solución VS

    Puedes encontrar más información sobre los Archivos de extensión.
    CSDL en :
    http://msdn.microsoft.com/es-mx/library/bb399169.aspx

    MSL en :
    http://msdn.microsoft.com/es-mx/library/bb399202.aspx

    SSDL en :
    http://msdn.microsoft.com/es-mx/library/bb399559.aspx
    No te preocupes si salen errores de referencia en el siguiente paso especificamos cuales son.

    PASO 6:

    Ahora hay que agregar unas referencias:
    System.Data.Entity
    System.Runtime.Serialization

    Después de esto Tendrás que crear el App.Config y configurar la cadena de conexión.
    Y listo ahora es posible hacer CRUD a la base de datos, para ver el ejemplo terminado dejo el SourceCode.
    http://www.megaupload.com/?d=CORN5YVQ
    __________________________________________________________________________________________________________________________________________

    MySql

    MySql Entity Framework es fácil de configurar ya que solo tienes que descargar el Mysql Connector de la página oficial http://dev.mysql.com/downloads/connector/net/
    Instalarlo y listo, lo puedes Usar exactamente igual que Entity Framework para Sql Server.

    Claro está que debes tener previamente instalado el Visual Studio 2008 con SP1

  • WarNov Developer Evangelist

    Programando para Office 2010 usando WPF y Visual Studio 2010

    • 2 Comments

    En este video, observaremos la manera de crear un panel para usar dentro de Word, que contendrá fragmentos de texto a los que luego de hacerles doble click podremos insertar dentro del documento a través de Visual Studio Tools for Office (VSTO)

    El panel fue diseñado usando Blend 3 y aprovechando las características de DataBound de WPF. Se aprovecha la DLL WindowsFormsIntegration para obtener un objeto de tipo ElementHost que permite agregar dentro de Windows Forms tradicional, elementos de WPF. Luego este contenedor se agrega a un UserControl y este UserControl se agrega a Office a través de un Custom Panel.

    El video explica todo el proceso y de aquí se puede descargar la solución finalizada:

     

  • WarNov Developer Evangelist

    Entity Framework vs. LINQ como ORM

    • 6 Comments

    LINQ inició siendo una teconología que servía tanto para consultar objetos en memoria, como para mapear tablas de bases de datos SQL a objetos de memoria. Así que luego de hacer el mapeo, con nuestro mismo lenguaje de programación sin necesidad de escribir comandos SQL a través de LINQ tendríamos la posibilidad de hacer consultas y manipulaciones sobre estas entidades en memoria sin mucho problema.

    Visto esto, observamos que con LINQ tenemos dos alcances: Como lenguaje de consultas integrado y como ORM.

    LINQ fue primero que EntityFramework; al principio LINQ "quizo" ser el ORM de Microsoft, pero demostró algunas deficiencias en ciertos aspectos como la conexión a distintos repositorios. Luego vino el EntityFramework a mejorar esas cosas en las que LINQ tenía debilidades. Pero OJO! EntityFramework solo se ocupa de las operaciones de un ORM. Y el hecho de que haya aparecido, no significa la desaparición de LINQ, dado que LINQ aparte de tener esas caractarísticas de ORM, es un potente lenguaje de consultas integrado que permite consultar tanto entidades (como las arrojadas por EntityFramework, el mismo LINQ o cualquier otro ORM), como objetos personalizados, XML, ActiveDirectory y en general cualquier estructura de datos .NET en memoria que implementen IQueryable (http://msdn.microsoft.com/en-us/library/bb546158.aspx)


    En últimas, yo recomendaría usar EntityFramework para hacer ORM y luego usar LINQ para ejecutar consultas muy sencillamente sobre las entidades generadas por el ORM. (Y sobre cualquier otra colección de datos).

  • WarNov Developer Evangelist

    Entornos Laborales Virtuales Microsoft para Emprendedores

    • 0 Comments

    Tengo un gran amigo. Emprendedor y entusiasta de las tecnologías Microsoft. Se ha independizado y gran parte de su operación se ha beneficiado de todos los recursos que hoy en día tiene Microsoft que son gratis o de muy bajo costo. Empezando con BizSpark (todo el software por 3 años y 100 dólares no más), herramientas de virtualización gratuitas como Virtual PC, etc.

    En este post, de su nuevo blog:
    http://rickersilva.wordpress.com/2010/01/25/virtual-office,
    nos enseña como logró establecer su empresa sin oficinas y usando todas estas herramientas.

  • WarNov Developer Evangelist

    Curso Gratuito de XNA en Colombia

    • 0 Comments

    Microsoft Colombia te reta a aplicar tu imaginación, pasión y creatividad en innovaciones de tecnología que puedan hacer una diferencia en el mundo. Participa en Imagine Cup 2010.

    El Diseño de juegos es en dónde el arte y la ciencia se unen. A través de Imagine Cup, puedes aprender y avanzar hacia una carrera cómo desarrollador o empresario de juegos. Únete hasta con 3 amigos y construye una experiencia de juego completa, usando XNA Game Studio 3.0 o posterior, Visual Studio o Silverlight.

    ¿Quieres aprender XNA Game Studio y participar en Imagine Cup 2010?

    1. Aquí encuentras toda la información sobre la competencia. No olvides revisar con detenimiento las reglas.

    2. Regístrate en Imagine Cup 2010 y escoge la categoría de Diseño de Juegos.

    3. Envíanos a más tardar el 30 de enero el usuario con el cual te inscribiste, a acadcol@microsoft.com.

    4. El próximo 5 y 6 de Febrero podrás asistir sin ningún costo, al curso de XNA Game Studio dictado por especialistas en Desarrollo de Juegos con la plataforma XNA, que hacen parte de la más activa comunidad de desarrollo de Bogotá: BogotaDotNet (http://bogotadotnet.org/). Este curso lo estaremos dictando para los estudiantes que se hayan registrado en la competencia. El curso será presencial en Bogotá (cupos limitados) y se transmitirá vía Live Meeting. No importa en cuál ciudad del país estés, puedes participar.

    5. El día del curso te daremos acceso gratuito al software que requieres para desarrollar tu juego.

    6. Busca inspiración para tu proyecto en los Objetivos de Desarrollo del Milenio de las Naciones Unidas y empieza a crear tu producto. La primera ronda del concurso se cierra el 15 de Marzo de 2010.

    La tecnología es la fuerza más poderosa para transformar las ideas brillantes en soluciones reales y sabemos que eres talentoso en programación de software, desarrollo de hardware, diseño, pero sobre todo, que eres visionario.

    Apuéstale a representar al país en la final mundial de la competencia, que será en Polonia.

    ¡Te esperamos!

    Esta iniciativa es válida para Estudiantes mayores de 16 años, que residan en cualquier ciudad de Colombia.

  • WarNov Developer Evangelist

    Open Data Protocol (OData)

    • 2 Comments

    Si como desarrolladores alguna vez hemos tenido la necesidad de exponer los datos de nuestra aplicación a otras aplicaciones; o lo que es peor, usar datos de otras aplicaciones, deberíamos saber que éstas actividades de compartimiento de información son de las más complicadas en el proceso de desarrollo.

    Es cierto que hoy en día existen los gloriosos Web Services: montados sobre los más aceptados protocolos y estándares: TCP/IP, HTTP, SOAP, XML, XSD, WSDL…

    Pero a pesar de ello, la comunicación sigue siendo complicada. Sobre todo para aquellos que tienen que crear proxies manualmente (Afortunadamente el SDK del Framework.NET ayuda a alivianar estas tareas con herramientas como wsdl.exe y xsd.exe que se integran transparentemente con Visual Studio). Casos por ejemplo en que un cliente java requiere acceder a un Web Service creado con .NET. y viceversa, requieren de mucha mano de obra y configuración por parte del cliente. Y ni se hable cuando de WCF se trata! Es bien sabido que WCF da toda la flexibilidad que requerimos para acceder a cualquier fuente de datos, montados sobre cualquier protocolo de transmisión y con cualquier tipo de mensaje; pero configurar un WCF sin mucha experiencia, puede resultar ciertamente más dispendioso que crear las operaciones en sí.

    Dado que la mayoría de aplicaciones necesitan acceder a los datos a través de HTTP, es justo entonces que se defina un protocolo simplificado que aproveche todas las ventajas de HTTP y que permita a múltiples clientes (esto es: clientes creados con distintas tecnologías) acceder a múltiples fuentes de datos, todo usando el mismo mecanismo.

    El camino ya había estado bastante trabajado con arquitecturas como REST, protocolos como ATOM y lenguajes como JSON.

    Teniendo todas estas bases y las necesidades que ya he descrito, Microsoft decidió crear OData; un protocolo para la consulta y actualización de una variedad de fuentes de datos que incluye pero no se limita a bases de datos relacionales, sistemas de archivos, CMS y sitios web tradicionales.

    OData fue liberado bajo la promesa Open Specification Promise (OSP) para permitir a cualquier persona interoperar libremente con cualquier implementación OData. A futuro, se espera que OData empiece a ser parte de AtomPub.

    Como lo mencioné OData ha sido creado específicamente para trabajar sobre web y es un protocolo centrado en HTTP. Usa las URIs para identificar los recursos con los que se desea trabajar. Los resultados, aunque se pueden trabajar con el formato AtomPub basado en XML, también se pueden trabajan con JSON, para simplificar la integración con clientes HTML y JavaScript.

    Para trabajar con OData hoy en día se ofrecen toolkits gratuitos para .NET (WCF Data Services), JAVA, AJAX y PHP y se aplica no solo en sitios web personalizados, sino en productos como SharePoint, Excel (PowerPivot), SQL Server, Windows Azure Storage, WebSphere eXtreme Scale, etc.

    Más información, en la página oficial del protocolo: http://www.odata.org. Allí encontraremos links de la especificación FORMAL del protocolo. Pero como toda especificación FORMAL, para nosotros desarrolladores que necesitamos agilidad, es poco práctica. De hecho la practicidad que tiene este protocolo para nosotros, es en el uso de WCF Data Services y es por eso, que he dedicado mi próximo post a ese tema. Pero para entenderlo mejor, es necesario comprender que existe OData y que está basado en REST.

  • WarNov Developer Evangelist

    REST (Representational State Transfer)

    • 2 Comments
    Creado en el 2000 hace referencia a “Representational State Transfer” o transferencia representacional de estados.

    Si uno se deja guiar por el nombre pareciera como si no tuviese nada que ver con lo que medio se ha oído por ahí acerca del tema: “que sirve para acceder a servicios sencillamente a través de URLs”, por ejemplo.

    Pero estudiándolo bien uno nota que al final si hay cierta congruencia.

    En REST participan básicamente dos roles. Un cliente y un servidor. El cliente es el sujeto de los dichosos cambios de estados. Entonces imagine el cliente como su navegador web en un estado específico (una página web). Un cambio de estado obviamente significa la transferencia a otra página web.
     
    Una transferencia representacional en web, no es más que la transferencia lograda sencillamente a través de URLs. Y es precisamente allí donde se encadena todo.

    La idea es que las acciones o verbos que originan los cambios de estado del cliente en REST están completamente definidos. Es decir, REST propone un vocabulario de acciones fijo; que permite obtener recursos del servidor, que una vez interpretados por el cliente, hacen que este cambie de estado.

    Esto último es lo que más diferencia a REST por ejemplo del tradicional SOAP. Ya que en SOAP, se le dice a cada desarrollador que defina un vocabulario nuevo y arbitrario de verbos, de acuerdo a los requerimientos de la aplicación (obtenerUsuarios(), almacenarOrden(…), etc. Todos sobreusando el verbo POST de HTTP). Paradójicamente, esto que siempre se vio como una gran ventaja, va en contravía con muchos de los aspectos inherentes del HTTP que es base de SOAP. Así que aspectos como la autenticación, caching, negociación de contenidos y demás, no se aprovechan.

    Aunque hasta aquí todo lo ejemplifiqué usando HTTP, REST es un mecanismo que no depende de ese protocolo. Las aplicaciones REST pueden basarse en otros protocolos, siempre y cuando éstas provean un vocabulario uniforme preestablecido para las aplicaciones que se construirán sobre ella. Recordemos que la idea principal de REST es maximizar el uso de las capacidades predefinidas de la plataforma que los soporte. HTTP como tal, proporciona un rico vocabulario completamente establecido y estandarizado que se ajusta perfectamente a este objetivo. Es por esto, que hoy en día al hablar de REST uno automáticamente piensa en su implementación sobre HTTP.

    Principios

    REST se fundamenta en seis principios básicos:
    • Cliente y Servidor plenamente identificados y separados
    • No hay almacenamiento de estado en las transiciones (Stateless)
    • Respuestas “cacheables” (Para mejorar las interacciones y el performance)
    • Capas: Pueden haber varias capas de servidores intermedios
    • Código por demanda: La funcionalidad de un cliente se puede extender con código trasmitido por el servidor (por ejemplo con JavaScript). Este es el único requerimiento opcional.
    • Interfaz uniforme: La misma que se discutió anteriormente.

    Objetivos

    Los principios anteriormente mencionados, están diseñados para lograr los siguientes objetivos:
    • Escalabilidad de componentes
    • Generalidad de Interfaces
    • Distribución Independiente de componentes
    • Existencia de componentes intermediaros que reducen latencia, aumentan la seguridad y encapsulan sistemas de legado.

    Recursos

    Los recursos se definen como fuentes de información específica y son muy importantes en REST. Un cliente accede a los recursos que el servidor dispone. Imagine una aplicación empresarial con información de recursos humanos. En este caso, la lista de empleados es un recurso del servidor y para acceder a ellos, se requiere un identificador único (por ejemplo una URI), que es usado por el cliente para referenciarlo y una interfaz de comunicación estandarizada (por ejemplo HTTP). Obviamente, aparte de tener claro el objeto de una acción, se debe tener clara la acción a ejecutar sobre ese objeto. Así pues, una aplicación interactúa con los recursos sabiendo su identificador único y la acción a ejecutar sobre este. Por ejemplo: Recurso: Empleado con Id:3520. Acción: Borrar. Los recursos generalmente son transmitidos entre el servidor y el cliente usando formatos como HTML, XML o JSON. No obstante, los recursos también pueden ser imágenes, texto plano o cualquier otro formato.

    Servicios Web REST

    No son más que servicios WEB implementados usando HTTP y los principios de REST que comprenden una colección de recursos de acuerdo a los siguientes aspectos:

    • Una URI base para el nombre del servicio: http://example.com/miservicio/
    • El tipo MIME de los datos soportados por el servicio
    • El conjunto de operaciones soportadas.
    • En REST sobre HTTP, lo más normal es tener estas operaciones
      • POST: Crea nuevos recursos. Como retorno, se ofrece el ID automáticamente creado
      • GET: Lista un recurso
      • PUT: Reemplaza un recurso con otro (Útil para el update)
      • DELETE: Elimina un recurso

    Entonces por ejemplo si se quisiera eliminar el empleado con ID 3520 se haría un request con DELETE a la siguiente URL desde el cliente:/span>
    http://example.com/miservicio/empleados/3520

    Conclusión

    REST, que es una arquitectura y no un protocolo como SOAP, se basa en acciones sobre recursos, para permitir la interacción de un cliente con un servidor. La implementación sobre HTTP es la más común y ha permitido la creación de otras tecnologías. Por ejemplo Microsoft, que se ha basado en este tipo de implementación REST para generar el estándar OData (Open Data) sobre el cual se construyó WCF Data Services (antes conocido como ADO.NET Data Services), y que permite simplificar el acceso interoperable a las capas de datos en aplicaciones n-tier.



  • WarNov Developer Evangelist

    Mono Tools for Visual Studio

    • 4 Comments

    Cada vez que encuentro noticias como esta me siento bastante agradado pues nunca me ha gustado cuando dicen por ahí que la tecnología Microsoft es cerrada y para nada extensible a otras plataformas. Y el agrado surge básicamente de que obtengo cada vez más argumentos para demostrar lo contrario.

     

     

    En esta ocasión, la gente de Novell llega con este brillante producto. Aquél que nos permitirá a nosotros desarrolladores de software cuyo cubil de trabajo no es otro más que Visual Studio, tener nuestras creaciones en Linux, Unix y hasta MacOS, sin necesidad de aprender lenguajes ni plataformas nuevas.

    image

    Es un Add-In comercial (versión gratuita de evaluación) que se instala en Visual Studio y que permite entre otras cosas hacer escaneos de nuestras aplicaciones para ver si podrán correr bien sobre el Framework Mono (versión del Framework.Net para plataformas no Windows), hacer pruebas de nuestras aplicaciones usando Mono en Windows o en una imagen virtual de Linux, hacer debug remoto en Linux, empaquetar para Linux estándar o mediante un Appliance para SUSE Linux que proveerá un servicio de deployment muy sencillo para nuestra aplicación.

     

     

    Imaginen entonces qué cantidad de trabajo nos podremos ahorrar a la hora de programar nuevas aplicaciones .NET que queramos que corran en las plataformas no Windows, pero sobretodo la posibilidad de poder reusar todos los componentes que ya existen!

     

     

    Todo esto nos permitirá a nosotros, a los ISVs y proveedores de servicios de desarrollo expandir nuestras oportunidades de mercado de una manera muy sencilla. Sobretodo viendo que en el mercado actual, hay muchas instalaciones no Windows.

    image

    Además, para aquellos acostumbrados a desarrollar en otras plataformas, puede ser una oportunidad para explorar nuevas formas de desarrollo (Con Visual Studio) que de seguro harán que vean todas sus ventajas sobre los modelos de desarrollo que han usado siempre para llegarle a plataformas como Linux o MacOS. El sitio oficial de Mono Tools for Visual Studio se encuentra en este link.

     

     



  • WarNov Developer Evangelist

    Sistemas POS que piensan en la Nube

    • 2 Comments

    Antes que nada, veamos algunos requerimientos urgentes de los sistemas POS, dadas las condiciones económicas de hoy en día:

    ·         Puntos con funcionalidad extendida, pero con máxima velocidad y disponibilidad

    ·         Conexión directa con un ERP central para permitir decisiones óptimas y oportunas

    ·         Apertura para la colaboración con partners y otros servicios para reducir costos

    ·         Desarrollo y despliegue de software rápido y económico

    ·         Nada de inversiones iniciales en infraestructura

    En primera medida uno pensaría en SaaS como una alternativa. Pero usualmente los thin clients (browsers) no son capaces de trabajar offline. De esta manera se hace obvia la necesidad de un Front Store o repositorio en cada cliente. Además los browsers no pueden garantizar el manejo de periféricos ni pueden garantizar las velocidades requeridas en las cajas.

    Por todo esto, la mejor elección es usar Smart Clients con un caché de datos local usando por ejemplo SQL CE en cada cliente. El deployment se puede implementar usando ClickOnce. Sumado a esto pueden estar los protocolos WS-* que permiten una seguridad máxima sin tener que recurrirse a VPN u otras complicadas configuraciones de Firewall, así que las instalaciones serían muy sencillas.

    BEDIN Shop Systems, un ISV italiano creó la solución aKite enfocada a crear POS usando esta metodología. En un principio toda esta solución era auto hosteada y aunque solucionaba los problemas descritos, presentaba problemas a la hora de manejar picos de consumo y sobretodo de generar un esquema centralizado de integración con otros sistemas como el ERP, CRM, BI, Logística y demás...

    Con la llegada de Azure a producción, este ISV decidió migrar su aplicación y lo logro en solo tres meses sin mayores problemas, según su reporte.

    Esquema de POS comunicado con Azure

    Lograron crear un Hub Inteligente que remueve la complejidad técnica y facilita compartir datos entre los POS y otros sistemas. Por ejemplo en el caso de tarjetas de fidelidad y de regalo, se logró una inmediatez total, un mejor servicio y sobretodo menor riesgo de fraude.

    Además gracias al esquema nativo de Azure, los picos de uso dejaron de ser problema y sobretodo, cuando un cliente va a implementar su sistema POS, el up-front (o inversión inicial) es nulo, pues toda la infraestructura ya existe.

    Las ventas en este sistema pueden efectuarse desde todos los continentes, con distintos lenguajes, monedas e impuestos. Luego de esto, a través de los “Retail Web ServicesaKite RWS-” (creados por el ISV y hospedados en Azure usando SQL Azure) los datos se envían a un ERP central para actualizar el inventario y la contabilidad. Las estadísticas de ventas también se hacen inmediatamente disponibles, pero no solo en el ERP, sino también en los sistemas de Back Store.

    aKite RWS es un conjunto de servicios WCF que explotan muchas características de esta tecnología. De esta manera, solo fue necesario crear un conjunto claro de servicios, cuya configuración se adapta a cualquiera de los puntos de conexión requeridos. Por ejemplo, solo bastó con configurarlos para el uso con Smart Clients, y quedaron listos para usarse en los clientes POS.

    Como si fuera poco, la migración de estos servicios a Azure, generó valores agregados como un balanceo de carga automático (nativo de Azure), asegurando gran escalabilidad y una subdivisión más equitativa de los recursos entre las tareas. Antes eso era manejado por una aplicación bastante compleja y difícil de mantener.

    El proyecto fue dividido en un Web Role y cuatro Worker Roles que se comunican entre ellos usando Queues y Blobs. BEDIN declara que en la migración de datos y código de ORM no tuvo ningún problema, dado que Sql Azure demostró ser completamente compatible con el código de Sql Server que ya se tenía, aun cuando este había sido generado con un ORM de un tercero (LLBL GenPro)

    Como ISV, BEDIN también confirmó los siguientes beneficios:

    ·         Ausencia de costos iniciales en Hardware

    ·         Costos proporcionales en relación al número de usuarios

    ·         Ahorros que se pueden destinar a mercadeo, ampliación de funcionalidad y costos que se transfieren al usuario final en forma clara

    ·         Monitoreo automático

    ·         Auto recuperación de desastres

    En conclusión, Windows Azure permitió a BEDIN Shop Systems concentrarse en su aplicación y habilidades arquitecturales y en ofrecer un valor máximo a sus usuarios. Es una empresa con más de 20 años de experiencia en el desarrollo de POS. Fueron los pioneros en implementar .NET con aplicaciones para el Retail. (: www.bedin.it  www.akite.net )

     

  • WarNov Developer Evangelist

    DLLs de VB6 que no trabajan en x64

    • 0 Comments

    Tiene usted una biblioteca que le ha servido por años y que está escrita en el viejo VB6?

    Se ha visto enfrentado a tener que usarla a hora para una aplicación creada con Visual Studio para correrla en 64bits?

    Entonces ha de ser muy probable que cuando la ejecute allí, obtenga un error como:

    Retrieving the COM class factory for component with CLSID {XXXXXXX} failed due to the following error: 80040154.

    Tal vez luego de esto trató por mucho medio de ver que pasaba, pero sin encontrar solución.

    Aquí lo que sucede es que  el código creado en Visual Basic, definitivamente tiene tipos no compatibles con la arquitectura x64.

    Cuando se crean soluciones en Visual Studio, este por defecto las compila con la opción “Active CPU”. Es decir que cuando el JIT compiler pasa el MSIL a lenguaje nativo de máquina, hace la compilación con la arquitectura en la que se está desplegando la solución. 

    Así que cuando una aplicación que tiene referenciada una DLL de VB6 que solo soporta 32bits se ejecuta en x86, ésta se compila y ejecuta correctamente. Pero en bien se pasa a x64, todo pasa a 64 bits. Y como la dll de Visual Basic 6 no soporta esa conversión, por lo tanto se genera el error. (Aún cuando originalmente se haya compilado en una máquina de 32 bits. Recuerden que la opción por defecto es "Active CPU").

    La solución consiste entonces en especificar para cada proyecto que referencie la DLL en cuestión ( y cualquier otra que falle) que la compilación se debe hacer explícitamente a x86. Así aun cuando se corra el código en una máquina de x64, el código final estará en 32 bits y por ende será compatible con la dll.

    Aunque esta es la única solución aparte de tener que migrar todo el código de VB (cosa completamente aconsejable a mediano plazo), ha de tenerse en cuenta que si su aplicación tiene utilidades muy atadas a 64bits (cosa que no creo), entonces estas dejarán de funcionar.

  • WarNov Developer Evangelist

    Antivirus Gratuito: Microsoft Security Essentials

    • 0 Comments

    Cansado de buscar un antivirus gratuito en el que en verdad pueda confiar?

    Ya no es necesario buscar más! Microsoft ofrece uno completamente gratis y no solo es un antivirus, sino toda una suite de seguridad que respeta la libre elección de sus usuarios, su privacidad y no exige registro ni identificación alguna:

    Se trata de Microsoft Security Essentials que brinda seguridad en la que usted puede confiar;  es fácil de obtener y utilizar y brinda una protección silenciosa que no interfiere con el performance de su máquina. Brinda protección en tiempo real para atender las necesidades de seguridad continua de un PC con Windows, lo que ayuda a protegerlo contra virus, spyware y otras amenazas maliciosas. 

    Cualquier usuario del HOGAR con Windows versiones Windows XP, Windows Vista o Windows 7 que tenga una versión ORIGINAL de Windows lo puede descargar GRATUITAMENTE de la RED y usarlo indefinidamente. Es Gratuito y exclusivo para los usuarios con una versión Original de Windows. (Para entornos empresariales está disponible el producto Microsoft Forefront). 

    Los únicos requisitos para correr este software son: Cualquiera de las versiones de 32 o 64 bits de Windows XP SP2 y superior, Windows Vista y Windows 7 incluyendo el modo XP.

    La idea de ofrecer disponibilidad gratuita de este producto únicamente con copias originales de Windows, obedece a que la protección en tiempo real como aquella que se encuentra en Microsoft Security Essentials es una gran herramienta en la lucha contra software malicioso conocido; sin embargo para mejorar el estado general del ecosistema también se requiere tratar el malware en la fuente de distribución. Las fuentes de software falsificado y soluciones temporales de activación maduran con el malware. Una vez infectados, los PC con software no original están más propensos a convertirse en hosts de malware, que propagan software malicioso a otras máquinas en el ecosistema. Conducir más sistemas al software original tiene el potencial de atender mejor las necesidades comerciales y de seguridad del ecosistema en general. Si el PC no aprueba la validación de originalidad, la instalación de Microsoft Security Essentials termina y al usuario se le envía a información sobre cómo resolver los problemas relacionados con software original.

    Uno de los detalles especiales de este producto, es que los usuarios de Microsoft Security Essentials contarán con acceso al soporte de la comunidad y de correo electrónico sin costo alguno.

    Microsoft Security Essentials no estará disponible como una descarga crítica de Windows. El instalador estará disponible como una descarga individual sin costo pero utilizará el servicio Microsoft Update tanto para las descargas de firmas como para las actualizaciones de producto.

    Se puede descargar de http://www.microsoft.com/security_essentials y no se requiere que los consumidores ingresen una ID de Windows Live ni registro para descargar la solución.

    Microsoft ya ha liberado productos para proteger el software de programas malintencionados como Windows Defender que detecta y elimina sólo spyware conocido (tecnología que ayuda a recopilar información acerca de una persona u organización sin su conocimiento o consentimiento). Sin embargo, no está diseñado para brindar protección contra la gama completa de software malicioso, y en específico no evita que virus, gusanos, troyanos, y otro software malicioso infecten su máquina. La nueva solución sin costo será una solución antimalware completa que se encarga de estas amenazas. Esto no significa que Microsoft Security Essentials esté diseñado para reemplazar a Windows Defender. Pero si usted ejecuta Microsoft Security Essentials, no necesita ejecutar Windows Defender. Microsoft Security Essentials deshabilita Windows Defender para administrar la protección en tiempo real del PC, incluyendo antivirus, rootkits, troyanos y spyware.

    Aparte de ser gratuito y ofrecer tantas ventajas, Microsoft cree en la elección del cliente. Al ofrecer Microsoft Security Essentials como una descarga individual e independiente, Microsoft ofrece a los usuarios de Windows la opción de elegir, gratis o de otro tipo, la solución de seguridad de PC que se ajusta mejor a sus necesidades individuales. Además también protege la privacidad de sus usuarios, Microsoft Security Essentials no desencadena un cambio en el estado del PC con Windows sino que lee el valor de originalidad almacenado en la máquina donde está disponible, o de otra manera invoca una API para que valide dónde no exista un estado local. No se ve ni recopila información personal como parte de la validación de originalidad.

    Conózcanlo, instálenlo y recomiéndenlo a sus conocidos para evitarles tediosas búsquedas de antivirus gratuitos!

  • WarNov Developer Evangelist

    Stairway to Azure (3): Componentes de Cómputo y Almacenamiento

    • 4 Comments
    Descarga la presentación PowerPoint de este Post.
     En mi post anterior, vimos por qué en determinado momento, es ventajoso tener alguien que se preocupe por el manejo de la infraestructura de nuestras aplicaciones en vez de nosotros. Y observamos que esto nos dejaría libres para preocuparnos únicamente por desarrollar la lógica de nuestras aplicaciones. Ya no es necesario comprar, instalar y operar sistemas de IT. Además solo pagaríamos por el cómputo y almacenamiento usado (como con los servicios públicos) y no una tasa fija que solo se requiere para ciertos picos. Finalmente, si enfocamos correctamente nuestras aplicaciones, estas pueden escalar muy fácil tomando ventaja de los enormes centros de datos que ofrece Microsoft para hospedar nuestras aplicaciones. Por ejemplo; si decidiéramos crear el siguiente “Facebook” sería muy últi Windows Azure ya que soporta trabajos de presentación (Web Role) y trabajos de proceso (Worker Role). Además si es una iniciativa con poco presupuesto inicial, es ideal ya que a medida de que se tengan más usuarios y se requiera escalar el sistema, se tendrán más recursos para adquirir dentro de Windows Azure.  

    Nuevamente, eso no implica que todo lo desplegaremos en Azure. La idea no es tener únicamente  SaaS sino también S+S. Así que por ejemplo las aplicaciones que hoy en día corren dentro de una organización (on-premises) podrían almacenar datos en la nube o usar otros servicios de la misma. Aplicaciones que corren en el escritorio o teléfonos móviles pueden usar los servicios de la nube para hacer sincronización de datos. 

    Toda esta maravilla requiere de aplicaciones que la exploten! Y para lograr dichas aplicaciones, necesitamos de una plataforma para construirlas. Esta plataforma es provista por Windows Azure y está compuesta por un grupo de tecnologías que nos proveen servicios a nosotros como desarrolladores.  

     

     

    Componentes de Azure

    En Windows Azure básicamente encontramos tres componentes principales:

    Windows Azure

    Ambiente basado en Windows (en esta edición es Server 2008), para ejecutar aplicaciones y almacenar datos en los centros de datos de Microsoft.

    SQL Azure

    Provee servicios de datos basados en SQL Server

    .NET Services

    Infraestructura distribuida para usar con aplicaciones locales y hospedadas en la nube.

    Estos componentes los podemos apreciar en la siguiente ilustración. En este post exploraremos en detalle el componente Windows Azure (Cómputo y Storage) y posteriormente observaremos Sql Azure y .NET Services.

    Windows Azure

    Comencemos entonces con Windows Azure:

    Overview

    Como podemos observar en la gráfica, este componente se subdivide en tres elementos: la estructuta principal o Fabric, el componente de cómputo y el componente de almacenamiento (storage). Empecemos viendo en detalle el componente de cómputo.

    Servicios de Cómputo

    Windows Azure corre sobre una gran cantidad de máquinas, todas ubicadas en los datacenter de Microsoft y accesibles vía internet. Todas estas máquinas conforman un todo que le da el poder y escalabilidad necesarios. Aunque al principio solo se iban a poder ejecutar aplicaciones .NET hoy en día, esta plataforma permite ejecutar aplicaciones nativas de Windows (esto lógicamente comprende todos los lenguajes de programación tradicionales que hoy en día sirvan para correr aplicaciones sobre Windows Server 2008).
    En Windows Azure, una aplicación típicamente tiene múltiples instancias y cada una corre una copia de todo o una parte de la aplicación. Cada instancia corre en su propia máquina virtual. Estas VMs están sobre Windows Server 2008 x64. Las aplicaciones se instancian en uno de dos roles, según escoja el desarrollador. Web Role, o Worker Role:

     

    Azure

     El Web Role corre sobre IIS7 y acepta los llamados HTTP o HTTPS (tecnologías: ASP.NET, WCF, todas las que trabajen con IIS). El balanceo de carga es automático, gracias al Load Balancer incluido en la plataforma.
    El Worker Role no puede aceptar peticiones directas desde el mundo exterior. Típicamente estos roles adquieren sus entradas a través de colas en el Windows Azure storage. Estos mensajes sí pueden provenir de una aplicación exterior o de un Web Role. Son procesados y la respuesta se puede poner en una cola, o enviarse directamente al mundo exterior (esto último sí es permitido).
    Independientemente del tipo de rol en una VM, siempre existe un Agente de Azure que permite la interacción del rol con el resto de la aplicación y la plataforma.
    Aunque es algo que puede cambiar en el futuro, en la actualidad Windows Azure mantiene una relación 1:1 entre VMs y cores físicos de procesador. Esto obviamente garantiza el performance de la aplicación que sea predictible (cada instancia tiene su propio core dedicado; esto también significa que no hay un límite arbitrario en el tiempo de proceso concedido a una instancia en especial). Sin embargo si se desea aumentar el performance, el dueño de la aplicación podría decidir crear más instancias de la misma, solo modificando el archivo de configuración. De esta manera, Windows Azure detecta el requerimiento y ajusta una nueva VM con su respectivo core. Si en algún momento alguna instancia falla, Azure lo detecta e inicia una nueva.

    Esto genera una notoria implicación: Para ser escalable, las instancias de Windows Azure Web role, deben ser stateless (no manejar estado en sesión o aplicación por ejemplo). Todo estado requerido ha de ser escrito en los mecanismos de storage de Windows Azure, o pasados al usuario final por medio de cookies por ejemplo. Además debido al load balancer, no hay forma de garantizar que múltiples peticiones de un mismo usuario sean enviadas a un mismo Web Role.
    Este tipo de implicaciones hace que el pasar aplicaciones a la nube o crearlas destinadas para ellas, no sea completamente transparente comparado con el modelo on-premises. Sin embargo, los cambios son muy sutiles (usar ADO.NET Data Services –compatible con Azure Storage-, tener en cuenta el modelo de colas para los Worker Role, etc.)
    Por esto, para los desarrolladores, trabajar con Windows Azure, es muy similar a crear aplicaciones tradicionales Windows. Microsoft provee templates para Visual 2008 que permiten crear Web Roles, Worker Roles y combinaciones de los dos. Los desarrolladores son libres de usar cualquier lenguaje de programación Windows. Todo esto viene en un SDK de Azure que también contiene una versión de ambiente Windows Azure que corre en la máquina del desarrollador. Este ambiente es conocido como Windows Azure Development Fabric e incluye Windows Azure Storage, un agente Windows Azure y todo el resto de tecnologías que requiere una aplicación para correr en la nube.
    Un desarrollador puede crear y depurar su aplicación usando este simulacro local y luego desplegar la aplicación a Windows Azure, cuando ésta esté lista, aunque en la nube hay cosas que son realmente diferentes. Por ejemplo, no es posible hacer el attach de un debugger a una aplicación en la nube. Así que básicamente para hacer el debugging de una aplicación en la nube, el mecanismo principal sería la escritura a los logs de Windows Azure, vía el agente de Azure.
    Otros servicios provistos incluyen por ejemplo el envío de mensajes desde los agentes a Windows Azure, quien los captura y reenvía por medio de emails, mensajería instantánea o cualquier otro mecanismo especificado. Además también se puede especificar a Windows Azure que detecte fallas automáticamente y envíe alertas. También está disponible información acerca de consumo de recursos tales como tiempo de proceso, ancho de banda entrante y saliente y almacenamiento.

    Cuando el desarrollador ha depurado completamente su aplicación de manera local, ésta ha de ser instalada en un proceso de dos etapas. Primero se sube la aplicación al área de staging en Azure. En este momento, la aplicación queda identificada con un nombre DNS que tiene la forma <GUID>.cloudapp.net, donde <GUID> representa un identificador asignado por Windows Azure. Este nombre es asociado con una dirección IP virtual (VIP) que identifica al balanceador de carga a través del cual la aplicación será accedida. En el momento en que se decide pasar ya la aplicación a producción, se usa el portal de Windows Azure para solicitar el paso a producción. En este caso, Azure automáticamente cambia la entrada en sus servidores DNS para asociar la VIP con el nombre de producción que el desarrollador ha escogido; por ejemplo: myapp.cloudapp.net. (Es posible usar un nombre de dominio personalizado, sencillamente creando un DNS alias usando un CNAME estándar). Otro punto para resaltar aquí: las IPs reales de las aplicaciones jamás son reveladas.

    Esto brinda un fuerte componente de seguridad.

    Servicios de Almacenamiento

    Esta parte de la plataforma también provee un tipo de almacenamiento: Azure Storage. Que es distinto a SQL Azure (otra parte de la plataforma). El almacenamiento Azure no es relacional. Su lenguaje de consulta tampoco es SQL. Es un almacenamiento mucho más sencillo, pero más escalable y más rápido que un almacenamiento relacional. Básicamente hay tres tipos de almacenamiento Azure:

    Storage

     

    1.       BLOBS:  (Binary Large Objects). Prácticamente, archivos. Los requerimientos de File System de nuestras aplicaciones en la nube, se suplen con los blobs. Un blob puede ser de hasta 50Gb de espacio y se encuentra dividido en bloques, de manera que cuando se hacen transferencias y ocurren fallos, la transferencia puede continuar desde el último bloque transferido correctamente.

    2.     Tablas: Los Blobs son la opción justa para algunas situaciones. Pero para otras son muy poco estructurados. Son muy sencillos de entender; pero para permitir a las aplicaciones trabajar con datos de una manera más formal se proveen las tablas. Estas tablas no son tablas relacionales y tienen su complejidad:
           
            Tables

    De hecho, a pesar de que se llaman tablas, los datos que ellas contienen realmente se encuentran almacenados en una jerarquía simple de entidades que contienen propiedades. Cada propiedad tiene un nombre, un tipo y un valor. Varios tipos son permitidos incluidos: Binary, Bool, DateTime, Double, GUID, Int, Int64 y String. Una propiedad puede tomar diferentes tipos dependiendo de los valores almacenados en ella. De hecho, no hay obligación de que todas las propiedades en una entidad tengan el mismo tipo. El tamaño para cada entidad puede ser de hasta 1MB y siempre es accesada como una unidad. Cuando se lee una entidad se retornan todas sus propiedades y al escribir una, esto se hace atómicamente de manera que se reemplazan todas sus propiedades. Y en vez de usar SQL, una aplicación accesa los datos de una tabla usando las convenciones definidas por ADO.NET Data Services (no ADO.NET convencional), o REST. La razón para este tipo de solución, es que nos permite escalar el almacenamiento de una forma tal, que podemos distribuir nuestros datos en distintas máquinas (muchas más de las que se posibilitan con bases de datos relacionales tradicionales); de hecho, una sola tabla en SQL Azure puede ser de terabytes!

    3.    QUEUES: Los blobs y las tablas están enfocados en almacenamiento y acceso de datos. La tercera opción en Windows Azure son las colas, que tienen un propósito muy distinto. Una función principal de las colas es proveer un mecanismo para que las instacias de tipo Web Role se puedan comunicar con las instancias de tipo Worker role. En la siguiente gráfica, se describe el funcionamiento de las colas. En un escenario típico, un rol acepta trabajos de los usuarios (paso 1). Para pasar esos requerimientos a los worker role, se escribe un mensaje en la cola (paso 2). Este mensaje, puede ser de hasta 8kb y es posible usarlo para que contenga URIs apuntanto a blobs o entidades en tablas en caso de que se requiera transmitir más información. El worker lee los mensajes de su cola (paso 3) y ejecuta el trabajo como tal. Una vez leído el mensaje, éste no se borra. En vez de esto, el mensaje se hace invisible a otros lectores por un período de tiempo (por defecto 30 seg). Cuando el worker ha completado su trabajo, en ese momento se borra explícitamente de la cola. (paso 5)
            QUeues


    Separar las instancias web de las worker tiene sentido porque libera al usuario de tener que esperar a que una tarea larga sea procesada y también hace la escalabilidad más simple, dado que solo sería necesario agregar más instancias. Pero por qué hacer que las instancias borren explícitamente los mensajes? Esto se hace para manejar fallos. De esta manera si  un worker que está haciendo el trabajo indicado falla, el mensaje no se borrará de la cola.  Así que cuando vuelva a estar visible, el mensaje reaparece en la cola para ser leído por otro worker. Y de esta manera se proteje el mensaje de fallos.

    Independientemente del tipo de almacenamiento, todo dato almacenado es replicado tres veces, para garantizar redundancia de datos y tolerancia a fallos.

    El storage de Windows Azure puede ser accedido por aplicaciones de Windows Azure o cualquier otra. En ambos casos, todos los tres tipos de storage pueden consultarse a través de REST. Todo es nombrado usando URIs y accesado con operaciones HTTP estándares. No obstante, un cliente .NET podría usar ADO.NET Data Services o LINQ para acceder más cómodamente a esta información. Pero un cliente java  usaría REST estándar. Por ejemplo, un blob puede ser leído con un HTTP GET contra un URI formateado así:

    http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>

    De manera similar, una consulta sobre una tabla sería:

    .table.core.windows.net/?$filter=http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>

    y una cola se accesaría:

    .queue.core.windows.net/http://<StorageAccount>.queue.core.windows.net/<QueueName>

    La Estructura (Fabric)

    Todas las aplicaciones de Windows Azure y todos sus datos en el Storage, residen en alguno de los centros de datos de Microsoft. Dentro de ese centro de datos, el conjunto de máquinas dedicadas a Windows Azure se organizan en una fábrica tal como lo muestra la siguiente gráfica:

     

    Fabric

     

    Tal como se aprecia, la Estructura Azure es un gigantesco grupo de máquinas administrado por un componente de software llamado Fabric Controller. Este controlador es replicado a través de un grupo de 5 a 7 máquinas y es dueño de todos los recursos en la estructura: computadoras, switches, balanceadores de carga y más. Dado que el controlador se comunica con un “Fabric Agent” en cada máquina, también tiene información de cada aplicación en la estructura. Como punto a resaltar, puedo mencionar que el Storage también aparece ante el controlador como una aplicación más. Así que el controlador no conoce los detalles del storage; esto último indica obviamente que el almacenamiento es autocontrolado. Es decir; el Storage, es solo una aplicación más dentro de la estructura, que se administra autónomamente.

    Este amplio conocimiento le da la capacidad al Fabric Controller de cumplir múltiples funciones como monitorear todas las aplicaciones que están corriendo y de esta manera ser capaz de dar información en vivo, de qué es lo que está pasando en la estructura. Administra los sistemas operativos teniendo en cuenta aspectos como las actualizaciones de los Windows Server 2008 que corren en las VMs de Azure. También decide dónde deben correr las aplicaciones, escogiendo los servidores físicos para optimizar la utilización del hardware. Para lograr esto, el controlador depende del archivo de configuración que es subido con cada aplicación a la nube. Este archivo provee una descripción basada en XML de las necesidades de la aplicación: cuántos roles web necesitará, cuantos roles de trabajo y otros detalles. Cuando el controlador recibe una nueva aplicación, éste usa su archivo de configuración para determinar cuántos roles de cada tipo ha de crear. Una vez creadas estas VMs, el controlador las monitorea. Si una aplicación requiere 5 instancias de Web Role y una muere, el controlador automáticamente reiniciará una nueva.

    Esta creación de instancias debe realizarse inteligentemente. Por ejemplo, suponiendo que además de las 5 instancias web el desarrollador pide cuatros instancias worker. Una asignación ingenua podría poner todas estas instancias en máquinas en el mismo rack servidos por el mismo switch. Si el rack o el switch fallara, la aplicación entera quedaría no disponible. Dadas las metas de alta disponibilidad de Windows Azure, hacer que una aplicación dependa de puntos sencillos de falla como este, no es una buena idea.

    Para evitar esto, el controlador agrupa las máquinas en conjuntos llamados “Dominios de Falla”. Cada dominio es parte de un data center que independizaría las fallas únicamente a su contenido. Eso se ilustra en la siguiente gráfica:

    Failure

    En este ejemplo sencillo, la aplicación está corriendo en dos instancias Web y el datacenter está dividido en dos Dominios de Falla. Cuando el controller despliega la aplicación, se establece una instancia de Web Role en cada uno de los dominios. Este arreglo significa que una falla en el hardware no va a provocar que toda la aplicación se caiga.

    Hasta aquí vimos todo lo relacionado al componente de Windows Azure. En mi post Stairway to Azure (4): Sql Azure y .NET Services, veremos la descripción de estos otros dos componentes.

  • WarNov Developer Evangelist

    Métodos Parciales (Partial Methods)

    • 0 Comments

    Una gran adición del Framework 2.0 en cuanto a codificación, fueron las clases parciales. Surgieron como una excelente solución sobretodo para los generadores automáticos de código, pues anteriormente cuando no habían clases parciales y uno trabajaba sobre una clase generada por alguna herramienta, el trabajo ejecutado se perdía cada vez que se regeneraba dicha clase.

    Gracias a las clases parciales entonces, uno podía generar un archivo "paralelo" que hacía referencia a la misma clase, pero que no se veía afectado en las regeneraciones automatizadas. Todo esto con la gran ventaja de que a pesar de que estuvieran en archivos distintos, la clase aparecían al resto del mundo como una sola (intellisense, compilación, etc).

    Otro uso interesante, es la posibilidad de dividir grandes clases en unidades con funcionalidades comunes, para obtener una mayor administrabilidad de las mismas y para permitir que varios desarrolladores estuviesen trabajando sobre una misma clase (en las versiones parciales en archivos distintos)  al mismo tiempo.

    Ya para el Framework 3.5 se incluyeron los métodos parciales que van un paso más allá con este concepto.

    La idea es que en una clase parcial se incluye la firma del método (tiene que ser privado y con tipo de retorno void) y en otra clase se "implementa". Lo pongo entre comillas, porque implementar me lleva a pensar en una interfaz, donde obligatoriamente se tiene que implementar los métodos establecidos por ella. Con los métodos parciales no existe esa OBLIGACION. El desarrollador decide si quiere "implementar" o no los métodos parciales que define la clase parcial.

    Para saber qué metodos parciales incluye una clase, basta con recurrir al intellisense y escribir "partial" y dar espacio; inmediatamente saldrán todos los métodos parciales disponibles.

    Esto resulta muy últil también en el proceso de personalización de código generado automáticamente, tal como pasa con la generación del modelo de datos que ofrece el Entity Framework. Las clases generadas por este framework, agregan métodos parciales para que se puedan controlar los cambios a los atributos en las clases generadas. Entonces si el desarrollador quiere establecer un control granular sobre estos cambios, implementa los métodos parciales en sus clases parciales externas.

    Qué ventajas ofrece esta metodología comparada con una de Interfaces?

    Si se fuera a autogenerar código con una herramienta como el Entity Framework, basado en una interfaz o en una clase base (con métodos virtuales o abstractos), obviamente la implementación de los métodos dictados por la interfaz quedarían en el código autogenerado o se haría muy complicado el proceso de escoger el archivo donde se quiere generar estos métodos y si se quieren generar o no pues tal vez ya han sido modificados.

    Además hay otra ventaja y es que cuando los métodos parciales no son implementados, entonces ni sus firmas ni sus llamados se incluyen en la compilación del código, lo que hace el proceso de compilación y el resultado de la misma, mucho más liviano que cuando se usan interfaces, o cuando se crean métodos virtuales o abstractos.

    En conclusión, vemos como muchas de las innovaciones del Framework .NET tienden a hacer más práctica la programación, sin perder el formalismo que lo ha caracterizado a través de su historia. La aparición de métodos parciales son una buena noticia y entender muy bien su uso nos permitirá desarrollar excelentes piezas de  código con muy poco esfuerzo.

    Pueden encontrar información de referencia aquí.

     

  • WarNov Developer Evangelist

    Stairway to Azure (2) Adquiriendo las cuentas de acceso.

    • 0 Comments

    En la primera entrega de esta serie de posts acerca de Windows Azure, estuve recorriendo todo el camino en la historia de Software más Servicios y relacioné un video que muestra de forma muy rápida esta historia y nos deja listos para comenzar a usar Windows Azure como alternativa de S+S propuesta por Microsoft.

    Vimos como Windows Azure permite hospedar en la nube servicios de negocio y de base de datos y que tiene puntos de conexión para comunicarnos con las aplicaciones "on-premises".

    Cuando trabajamos con Windows Azure, básicamente nos descargamos un SDK y unas herramientas que se instalan sobre nuestro Visual Studio y IIS, con el fin de generar un Windows Azure "Local" sobre el cual podemos hacer pruebas de los desarrollos para Windows Azure. Obviamente, los servicios de Azure tienen su costo (posteriormente estaemos hablando de esto). Pero como también es obvio, necesitamos tener la oportunidad de probar la experiencia, antes de pagar por una suscripción.

    Por este motivo, Windows Azure ofrece un trial, para que podamos poner en el Windows Azure real las aplicaciones que desarrollemos usando el Azure Virtual Local. Para acceder a estas cuentas trial, es necesario solicitar un token, que se toma su tiempo en ser asignado a nosotros (algunos días). Para solicitarlo, primero es necesario registrar nuestra cuenta de Windows Live Id (anteriormente Passport.NET) en el sitio de Microsoft Connect. Y luego de esto, llenar una información de registro específica para acceder al token. Después, esperamos algun tiempo mirando ansiosamente el correo todos los días, hasta que descubrimos que tenemos el tan preciado token. Una vez con ese token en nuestro poder, procedemos a redimirlo en el sitio de Windows Azure de acuerdo a las instrucciones que vienen en el correo y en adelante, podremos subir nuestras soluciones a la nube.

    He querido postear esta información antes de explicar realmente como programar para Azure, pues me gustaría que la audiencia vaya adelantando el proceso de adquisición de tokens, para que cuando ya sepan cómo y tengan desarrollos para Windows Azure, ya hayan redimido su token y puedan probar sus aplicaciones online. Para este fin, también he publicado un video, que muestra más detalladamente los pasos a seguir:

    Los espero en una nueva entrega donde comenzaremos con el típico "Hola (mundo) Nube"

  • WarNov Developer Evangelist

    Ecosistema de Desarrollo Microsoft

    • 0 Comments

    Hace muchos años se creó alrededor del nombre Microsoft como tecnología, un mito que hoy en día en numerosos ambientes sigue vigente basado en hechos que ya no son reales y que provoca que los profesionales en tecnologías de diseño y desarrollo de software pierdan grandes oportunidades o a veces tengan que ejecutar más trabajo del que realmente deberían estar haciendo.


    Este mito dice que las tecnologías Microsoft son tecnologías cerradas, costosas y para nada integrables con el mundo Open Source. Otras versiones a veces agregan opiniones acerca de la calidad de los productos generados con nuestras tecnologías. Pero el éxito de las aplicaciones creadas con nuestra plataforma a nivel mundial habla por sí solo.
    En síntesis, hoy el mito está absolutamente roto. Y en este artículo describiremos por qué. Cómo nuestra plataforma ahora es integrable con el resto del mundo de software y lo mejor de todo, al mejor precio posible: $0.


    Ahora Microsoft ofrece un poderoso conjunto de herramientas, servidores y tecnologías en forma completamente gratuita para poder construir WebSites, Servicios y Aplicaciones. Habilitando a los estudiantes, emprendedores y personas que deseen iniciarse en nuestra plataforma de punta sin costo inicial y con la posibilidad de poder trabajar con muchas de las tecnologías con las que ya se encuentran familiarizados.

    En el siguiente video hacemos un recorrido rápido sobre toda la plataforma gratuita de Microsoft y en el resto del artículo hablamos de ello:

    Este ecosistema ya se encuentra totalmente unificado y reside en un solo sitio web, desde donde se puede descargar gratuitamente y comprende:


    1. HERRAMIENTAS

    a.      Visual Web Developer 2008 Express: Disponible para usar tecnologías como ASP.NET, Entity Framework, LINQ, Dynamic Data, AJAX, Silverlight y muchas más, para permitir por ejemplo crear Aplicaciones Orientadas a Datos automáticamente, sin una línea de código. Y en interoperabilidad, ofreciendo alternativas como soporte completo en el editor de código (coloreado de sintaxis, autocompletado de código, tips de métodos, depuración para Javascript) y librerías de última generación como JSon y JQuery. Como si fuera poco, nos ofrece todo un entorno integrado que no solo nos permite administrar nuestra solución de software como tal, sino también Bases de Datos, sitios FTP y aplicaciones para desplegar nuestra solución en los servidores web.

    b. Internet Explorer 8: Con sus herramientas para desarrolladores y diseñadores incluidas, hace eficiente y fácil el proceso de creación de sitios web, permitiendo la manipulación del DOM y el HTML dentro del browser, así como hacer Tracing de los estilos css usados, y perfilamiento y depuración de Javascript. Además incluye soporte completo para CSS 2.1, características de HTML5 como navegación AJAX, DOM Store y más características de CSS3 como texto vertical. También permite la creación de características únicas como buscadores personalizados, WebSlices, y Aceleradores para mejorar la experiencia de navegación de los usuarios.

    2. SERVIDOR DE BASES DE DATOS:

    Una versión gratuita del exitoso Microsoft SQL Server se encuentra disponible para ser descargada y servir como fuente de datos para sitios de producción; ya sea el próximo MySpace, o una aplicación corporativa. Disponemos de una excelente consola de administración para este motor; también gratuita, que nos permite administrar, crear, consultar y modificar las bases de datos muy fácilmente. En cuanto a interoperabilidad, provee su propio conector con PHP, para poder desplegar todo su poder sobre nuestro SQL Server.

    3. TECNOLOGIA:

    Nuestro nuevo framework, sobre el cual corre toda la plataforma, como siempre sigue siendo gratuito. Y esta vez viene con mejoras inigualables que van a permitirnos ser productivos con realmente muy poco esfuerzo:

    a. MVC: El modelo que realmente permitirá construir aplicaciones completamente estándar, al darnos control total sobre la forma en que se muestran nuestros sitios. Además permite un desarrollo orientado a pruebas, y una alta facilidad de administración en proyectos de gran magnitud gracias a su naturaleza puramente desacoplada.

    b. Dynamic Data: Creación automática de la capa de acceso a datos y aún de las interfaces de usuario para implementar las operaciones CRUD en nuestros sitios Web, todo esto soportado por templates que permiten dinamizar la apariencia del resultado final para que se ajuste a nuestros requerimientos.

    c. AJAX: Un completo framework integrado que nos permite crear aplicaciones web dinámicas de alta respuesta que funcionan como aplicaciones de escritorio.

    d. LINQ: Consulta y manipula CUALQUIER tipo de fuente de datos con un mismo lenguaje, con todos los beneficios de trabajar con lenguajes .NET Nativos como C# o VB.

    e. Entity Framework: La tecnología que nos permite mapear nuestras bases de datos a objetos en memoria en un abrir y cerrar de ojos, para ser totalmente productivos enfocándonos en desarrollar nuestro negocio y no en labores repetitivas.

    4. PLATAFORMA DE SERVICIOS:

    Internet Information Services 7 (IIS 7.0) ya no es solo un servidor web. Es toda una plataforma para hospedar sitios web, servicios y aplicaciones. Nos brinda la oportunidad de personalizarlo sin perder disponibilidad ni seguridad. Le podemos personalizar o agregar características como Intelligent Media Streaming a través de extensiones gratuitas de IIS, maximizar la seguridad web y ejecutar aislamiento automático de aplicaciones. Nos permite un despliegue simplificado de aplicaciones .NET y PHP en el mismo servidor. Incrementa la velocidad de nuestros sitios Web a través de técnicas únicas de caching dinámico y compresión de datos mejorada e implementa una infraestructura escalable con el balanceo de carga basado en HTTP sumado a un manejo de peticiones y ruteo inteligente.

    Y por si no se los he mencionado, todo esto es gratis!

    Para tener todo este ecosistema en nuestras máquinas de desarrollo y producción, lo único que necesitamos es visitar: http://www.microsoft.com/web

    Allí encontraremos más detalles de toda la nueva plataforma, así como un link directo al PI (Platform Installer) que nos permite descargar todo este contenido unificadamente, para tener en nuestras manos todo el poder de la plataforma en un santiamén.

    Además de esto, en este sitio encontraremos completos tutoriales que nos enseñarán a usar la plataforma de principio a fin para lograr rápidamente tener un sitio en producción. Tal es el caso del tutorial del sitio de ejemplo NerdDinner que incluye libro en PDF, video, y por supuesto código fuente.

    Por si fuera poco aquí también se nos enseña el proceso de Hosting de nuestros sitios, si es que no somos muy diestros en este tema. Pero eso no es todo! También podremos obtener hosting GRATIS para las aplicaciones que hagamos con la nueva plataforma; de esta manera cubrimos todo el proceso gratuitamente, desde la creación hasta la implementación de nuestras aplicaciones.


    Muchos otros recursos se encuentran referenciados en este portal, para que tengamos la posibilidad de extender más aún nuestro conocimiento: Links a los sitios de aprendizaje de Silverlight, IIS y ASP.NET, Links a Blogs de los escritores de nuestra tecnología más influyentes y muchos temas más.

    Hay más en este portal? Claro que sí. Nuestra tecnología es completamente abierta. Y es por eso que en este portal encontramos un enorme listado de aplicaciones Open Source creadas con la plataforma y en muchos caos PHP, listas para ser usadas aun comercialmente sin ningún costo: WordPress, DotNetNuke, MojoPortal, SugarCRM, Umbraco y muchas más.

    Con todo lo anterior, es muy fácil iniciarnos en la plataforma y los productos que podemos llegar a crear con ella. Tanto así, que rápidamente podremos convertirnos en empresarios de tecnología a través de todos estos recursos. Dado lo anterior, en el portal también se ofrece la alternativa de entrar a hacer parte de programas para profesionales en tecnologías Microsoft como WebSpark o BizSpark, en los cuales por unas tarifas súper reducidas para apoyar el emprendimiento (US$100 por tres años) se puede tener acceso a la mayoría del licenciamiento de los productos Microsoft requeridos para sacar nuestra empresa adelante. Hasta acceso a soporte tenemos desde el portal de nuestra plataforma!

    Nuevamente: El mito está roto!

    Visite http://www.microsoft.com/web y observe como puede empezar a ser productivo muy rápido, sin un solo peso invertido y con la posibilidad de integrarse sin problema al mundo Open Source. El Ecosistema de Microsoft, ofrece tecnologías para todos!

    Descargar el Video: Descargar la presentación:


  • WarNov Developer Evangelist

    Stairway to Azure

    • 2 Comments

     

    El objetivo de esta serie de posts, es tender una escalera a la nube (Azure), de tal manera que nosotros, desarrolladores hispanoparlantes tengamos una manera rápida de comenzar con todo lo relacionado con esta tecnología.

    Para introducirnos rápidamente en el mundo de Azure, primero que todo es necesario que entendamos los conceptos de SOA, SaaS y S+S. Para este fin, he preparado este video que nos dejará muchas cosas claras:

     

    Luego del video, es mucho más fácil entrar en materia:

    GENESIS

    Al principio todo era código estructurado. Y miles de líneas de código se entrecruzaban como espagueti dentro de aterradores GoTo’s y Labels. Y la interoperabilidad de aplicaciones era así:

    Arquitectura Spagueti

     

    Todos los sistemas estaban altamente acoplados y hacer un arreglo o un cambio era toda una pesadilla. Era la época de oscuridad en el desarrollo de software. Se desarrollaba sin ciencia. Se administraba con sufrimiento.

    Servicios y SOA

    Después nació el servicio. Y los programadores se dieron cuenta de que era bueno. No tenían que pasar días tratando de hacer un cambio, porque las funcionalidades estaban bien distribuidas independientemente. Además tampoco se duplicaban. Entonces, nació SOA o Arquitectura Orientada a Servicios. Con la cual se hizo mucho más fácil la administración del software y los procesos más eficientes.

    El milagro de SOA hizo que las empresas progresaran mucho y que cada vez requirieran más servicios; sus sistemas de software crecían y obviamente así el hardware que los soportaban. Y el crecimiento de hardware trajo consigo un purgatorio para el personal de IT. Administrar decenas de servidores y estar pendientes de los nuevos requerimientos de infraestructura para estos grandes sistemas de software se hizo cada vez más doloroso. Los costos también aumentaban exponencialmente cada vez que crecían los sistemas. Además el negocio en crecimiento obligaba a viajar a los empleados de las empresas, quienes en sus viajes de negocio requerían tener acceso al software. Pero el software estaba internado en el centro de datos empresarial. Los empleados estaban atados a la ubicación física de la empresa. Todo fue un caos!

    SaaS

    Entonces apareció el evangelista promulgando el uso de los servicios de Hosting. Empresas encargadas de mantener los centros de datos para otras empresas sumergidas en el caos del manejo de IT. Y aparecieron grandes centros de datos que a pesar de estar fuera de las instalaciones de los clientes, podían albergar todas sus soluciones  de software. Las empresas se ahorraron costos y dolores de cabeza, porque ya no tenían que estar pendientes de la administración de IT. La comunicación entre el servicio de hosting y las empresas fue posible gracias a la explosión de internet y el ancho de banda; así que los empleados ya no estaban atados a la casa matriz; todo mundo se olvidó de los detalles no funcionales y se dedicó más enfocadamente a su negocio… Los gerentes vieron que todo esto era muy bueno! Así que se dedicaron solo a producir servicios para ser hosteados y ese fue el origen del SaaS (Software as a Service) o software como servicio.

    Entonces todo mundo comenzó a adorar al nuevo modelo de conexión al software (la internet). Y nadie volvió a conectarse al interior de la empresa. Siempre era necesario tener internet para poder trabajar. Así que si había un problema de conectividad, se perdía la productividad. Además las aplicaciones tuvieron que estandarizarse para poder visualizarse desde todos los browsers y se perdieron las características especiales y únicas de las aplicaciones de escritorio. Entonces los negocios que un día crecieron vertiginosamente, comenzaron a decaer por la limitante de funcionalidad. Esto sumado a que los proveedores de servicios de hosting también estaban a tope y tardaban mucho en escalarse, empeoró aún más la situación. El oscurantismo cayó de nuevo por el uso excesivo de una novedad.

    S+S

    El desarrollador reflexionó; y se dio cuenta que el modelo de software tradicional instalado al interior de la empresa que había desechado, tenía grandes ventajas sobre el nuevo ídolo. Y que sin embargo SaaS también conservaba características brillantes. Entonces observó que la solución no era irse por un único camino. Sino tomar el mejor camino de acuerdo a cada tipo de aplicación. Así decidió que parte de su software iba a ser software como tal y otra parte iba a ser servicio. Esto dio origen a S+S: Software más Servicios. Desarrolladores y gerentes se dieron cuenta que esto era bueno y se mantiene hasta nuestros días.

    AZURE (PaaS)

    Microsoft también observó que todo esto era bueno. Y decidió hacerlo aún mejor! Así que está poniendo a disposición de sus clientes los servicios de hosting, almacenamiento y procesamiento de datos; tal cual como lo hacen los actuales proveedores; pero esta vez, ofreciendo estadios completos de servidores que hacen más fácil lograr la escalabilidad y disponibilidad que requieren algunas de las aplicaciones de misión crítica de los clientes. En síntesis, Azure cubre la parte de software como servicio; pero como se observa al mirar en detalle la tecnología, se ofrece todo un framework para poder conectarnos con las aplicaciones al interior de la empresa y otras hospedadas por los proveedores de servicios de hosting convencionales que seguirán trabajando con muchas de las aplicaciones que actualmente manejan sin problemas. Concluyendo, la nueva tecnología Azure basa su desarrollo en la interoperabilidad limpia y eficiente con las fuentes de software que han demostrado ser muy adecuadas hasta ahora: al interior de las empresas (Software – On Premises) y hosteadas por terceros (Servicios).

    Una vez recorrido el camino necesario para entender la historia y el porqué de Azure, esperen en próximos blogs una inmersión especial a la plataforma y todas sus características!

  • WarNov Developer Evangelist

    Problemas con el Connection Pool de ADO.NET

    • 0 Comments
    Cuando se crea una conexión SQL en ASP.NET, por defecto siempre irá al POOL de conexiones administrado por el framework. Es así como ni al cerrarla ni haciéndole dispose, esa conexión realmente se cierra en el SQL Server como tal. El pool de conexiones existe para mejorar en general el rendimiento de las aplicaciones, dado que el hecho de abrir una conexión es bastante costoso. Así que aunque lógicamente la conexión está ConnectionString es requerida, se sirve una de las ya existentes en el pool de una manera más rápida que creandola desde 0 (from the scratch).

    Si no se desea este comportamiento, basta con incluir en la conexión o en el WebConfig POOLING=FALSE

    El pool para un ConnectionString en particular se puede configurar con el número máximo y mínimo de conexiones. Jugar con estos valores puede mejorar o empeorar el rendimiento de la aplicación. El valor por defecto es de 100.

    Existe un error bastante grotesco que puede asustar mucho si no se entiende de connection pools:

    A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)

    Ocurre por ejemplo si en el pool no hay conexiones disponibles, debido a que han sido terminadas por un ente distinto a la aplicación (alquien desconectó el cable de red, apagaron el server, le hicieron kill a las conexiones, etc.)

    No ocurre porque la operación esté tardando demasiado. Y el que ocurran excepciones por éste último motivo no se arregla aumentando el timeout de la conexión. El timeout de la conexión se refiere al tiempo de espera para logran conexión con el server de db, antes de que una excepción sea lanzada.

    El tiempo de timeout por defecto es de 15 segundos. Y en el connectionstring está medido siempre en segundos. Siempre ha tener valores positivos o 0. De lo contrario una excepción surge. Si es 0, significa que nunca se lanzará excepción por incapacidad de alcanzar al server. Esto no es buena idea, porque el sistema se puede volver irresponsivo, y no habría indicios de por qué sucede esto.

    Para que los pool funcionen correctamente, debe existir un manejo responsable de las conexiones. Cómo se manejan responsablemente? Cerrándolas cada vez que no se vayan a requerir más.

    SqlConnection conn = new SqlConnection(myConnectionString);
    try
    {
      conn.Open();
      doSomething(conn);
    }
    finally
    {
      conn.Close();
    }


    Como se vé si hay un fallo, igual se cierra la conexión.

    Teniendo en cuenta: http://www.15seconds.com/issue/040830.htm

    "Close and Dispose methods of Connection object are equivalent. Neither one gives you any specific advantages over the other. "

    Por tanto se puede usar también de una forma más elegante y ostentosa:
     

    using (SqlConnection conn = new SqlConnection(myConnectionString))
    {
      conn.Open();
      doSomething(conn);
    }


    El using en este contexto libera todos recursos declarados, por medio de Dispose.

  • WarNov Developer Evangelist

    Error en WebService: &quot;The thread have been aborted&quot;

    • 0 Comments
    El webservice protagonista de este post es uno basado en WSDL; así que no aplica para WCF. Fue creado y usado para lo que no debería ser. Una funcionalidad de una aplicación web administradora de contenidos. Como esa era muy compleja para modificarla, entonces la dejaron intacta, solo que le adicionaron el web service, para que la aplicación propia pudiese usar el dichoso administrador de contenidos.

    En teoría funcionaba bien. Pero ante cargas significativas: "The thread have been aborted". Y nadie sabía qué era. Entonces me llamaron a ver que era. Y lo primero que observé, es que el pobre webservice exponía unas operaciones que operaban sobre la base de datos. Y en general eran operaciones costosas. Pero lo peor, es que siempre el webservice tenía que quedarse esperando la respuesta del servidor de DB.

    "Eso es el timeout del webservice" dije.
    "Si, pero ya le pusimos hasta 5000 horas y nada!!"
    Ouch!!!

    Entonces tratemos de optimizar las operaciones de la DB.
    Le pasé el profiler, el DBEngine Tunning Advisor, implementé y borré índices y en efecto. La vaina mejoró.
    Operaciones de 9 minutos pasaron a 3 y en otros casos operaciones de 3 min pasaron a 1 seg (y eso porque el reporte no mostraba menos de 1 seg)

    Pero llegamos al punto en que por más optimización que hicimos, el error seguía pasando y el thread seguía siendo abortado.

    El httpruntime es un parámetro de configuración en el webconfig y jugar con sus valores puede ser catastrófico o genial. (En este punto cuando he nombreado web.config obvio que sabrán que estoy hablando de asp.net. especficamente del 2.0).

    Señores, se los presento aquí.

    Allí encontramos como atributo a executionTimeOut y fue el que le pusieron como en 5000 y nada. Por qué?
    Uno diría que aquí es donde le puede decir al webservice que espere más antes de "morirse". En efecto así es. Lo que pasa es que con el framework 2.0 vino nuevo otro atributo: shutdownTimeout. El primer atributo aplica sobre la aplicación como tal. Pero el segundo aplica sobre el worker process. Así que si está muy bajo para lo que uno quiere, el worker process es "bajado" por ASP.net cuando el tiempo expira y adivinen que pasa "The thread has been aborted".

    Lo pusieron en 1000 y por fin pudieron hacer su prueba completa!!!

    Concluyendo: Para evitarse problemas, no ponga a los webservices a esperar respuestas a trabajos completos. Esto margina el rendimiento de la red, y en general de todos los recursos del sistema. Use mecanismos asincrónicos.

    Si ya la embarró y no hay tiempo para cambios o definitivamente la terquedad o condiciones del negocio no permiten más, acuda al httpruntime y sus dos timeouts; esto puede apagar el incendio.
  • WarNov Developer Evangelist

    Don JSon

    • 0 Comments
    Algunas aplicaciones web requieren AJAX y requieren que su tamaño de página ha de mantenerse bajo límites estrictos. Entonces no es posible usar las librerías de AJAX .NET dado el considerable peso que le agregan a la página, sino usar directamente el objeto XmlHTTPRequest. Adicionalmente es necesario considerar el peso impuesto por los datos que se transfieren desde el server al cliente luego de usar AJAX. En primera instancia uno podría pensar en XML. Pero como se sabe, los archivos se hacen muy grandes con información que finalmente no es la relevante, así que se genera más peso para las páginas. Por este motivo, actualmente se está difundiendo rápidamente el uso de JSON.

    JSON es un sobconjunto del lenguaje JavaScript, que permite representar objetos a través del paradigma llave-valor. En síntesis es como un "fatless" XML, que es mucho más liviano. Y que además tiene la gran ventaja que puede ser interpretado directamente por JavaScript, de manera que tanto el peso de la página como la ejecución se mejorar sustancialmente, ya que no hay que usar librerías para manejo de XML en JavaScript ni hacer tediosos recorridos a través del texto.

    Para JSON hay librerías disponibles en casi todos los lenguajes, incluido C#. De esta manera, cualquier objeto puede ser traducido a de C# a texto JSON en el server, luego transferido al cliente usando Request.Write después de un llamado AJAX, e interpretado inmediatamente por el browser, sin mayor overhead.

    Desde C# 3.0 muchas de estas características están siendo implementadas de forma nativa y ofrecen beneficios incalculables a la hora de desarrollar, por lo que es recomendable desde ya comenzar a usar estos elementos que han existido desde hace mucho tiempo, pero que solo ahora con el auge de “la interpretación – AJAX, Silverlight, etc- han entrado de lleno en el mundo Microsoft.


    El sitio oficial es
    http://www.json.org
    Pero para no devanarse los sesos y entender rapidito el asunto está: http://www.secretgeek.net/json_3mins.asp; en tres minutos sabrán qué es.
  • WarNov Developer Evangelist

    Trasmitiendo las variables de aplicación entre capas en una solución .NET

    • 0 Comments
    (Y haciéndolas dinámicas)

    Sea el escenario de una típica aplicación 3-tier para un sistema de información. Hay una capa de presentación, una de negocios y la de datos. En la capa de datos según lineamientos plenamente aceptados, tenemos las cadenas de conexión a las bases de datos que se usarán. Si la aplicación se desarrolla con el Framework 2.0, es normal que las capas de datos y negocio, queden representadas por DLLs que luego son consumidas por una aplicación Windows o web, por ejemplo. Entonces cada cliente se comunica con sus capas servidoras que tienen la conexión a base de datos y saben en dónde están los datos para operar.

    Hasta ahí no hay ningún problema. Cuando la aplicación ya está lista para producción, generalmente se usará una base de datos distinta a la usada en desarrollo y quizá en pruebas.
    Este cambio, gracias a la arquitectura del framework 2.0 en adelante, solo implicaría cambiar el archivo de configuración (App.config) de la DLL de capa de datos. Se abre con un editor de texto, y se edita el XML con la nueva cadena de conexión, y ya está. Todos los clientes quedan conectados a la nueva fuente. Pero qué sucede si se crea una aplicación de capas, que no necesariamente tiene la misma conexión de base de datos para todos los clientes? Cómo lograr que cada cliente genere una cadena de conexión dinámica que se pueda cambiar a discreción permitiendo que la aplicación funcione correctamente?

    En el framework 2.0 las cadenas de conexión son tratadas como variables de alcance de aplicación. El otro tipo de alcance es de usuario. Cuando la variable es de alcance de usuario, esa misma, puede ser modificada en tiempo de ejecución. Entonces sería fácil crear métodos para que los clientes de presentación de alguna manera transmitieran los nuevos valores de las cadenas de conexión a las otras capas. No obstante, como mencioné anteriormente, las cadenas de conexión son de alcance "aplicación" y estas variables no se pueden modificar en tiempo de ejecución. Así que para un cliente es imposible modificarlas transmitiendo nuevos valores mientras está corriendo. Así que el método de crear código que transmita los cambios requeridos, no es factible. La solución, aunque es trivial, no es intuitiva y Visual Studio no provee una manera directa para lograrla. Para encontrarla y entender de qué se trata, suponga que llamamos a la cadena de conexión strCon1. Entonces, queda guardada dentro de los settings de la DLL de datos como strCon1 y tiene determinados valores de conexión.

    Además permitiría cambiar la cadena de conexión dinámicamente, antes de iniciar la ejecución de la aplicación (recordemos que ésta es una variable de aplicación). Al distribuir la aplicación, se puede hacer con o sin el archivo de configuración de la aplicación. Si se distribuye sin este, cuál será entonces la cadena de conexión a usarse? Se usaría la última presente al compilar la librería (Esto gracias a la compilación del archivo de propiedades en la clase Settings.settings).

    Como es conocido, cada capa en el framework, vendría representada por un assembly (DLL) por separado. Es decir, cada capa es un proyecto dentro de la solución y cada proyecto de estos, tiene sus propias propiedades y variables de usuario y aplicación. Como ya se mencionó estas variables van en archivos App.config. Al compilar la solución, dentro de cada carpeta de salida de los proyectos queda un archivo App.config para las dallas, y un archivo miaplicacion.exe.config para los ejecutables en el caso de aplicaciones Windows o web.config en el caso de web services o aplicaciones web ( en estos últimos dos casos, el archivo queda en el root del sitio web).

    Lo que uno como desarrollador distribuiría, sería únicamente los compilados y salidas de los proyectos componentes de la solución. Entonces irían en nuestro ejemplo dos DLL (una de datos, la otra de negocio) y el ejecutable. Además irían los archivos de configuración, que en el caso de las DLL se llamarían igual.

    Pero si se llaman igual, cómo se soluciona este problema? Fácil; basta con combinar los archivos de configuración en uno solo con el mismo nombre y listo. Pero es fundamental que los nombres de las variables (por ejemplo de cadenas de conexión) permanezcan invariables.

    En mi búsqueda de esta solución, una de las cosas que intenté fue agregar una variable de aplicación a la capa de presentación, que tuviera el mismo nombre de conexión y los mismos parámetros que la definida en la capa de datos usando la interfaz de Visual Studio. De esta manera se produciría un miaplicacion.exe.config, con la cadena de conexión que usa la capa de datos y así cada vez que yo cambiase este archivo y reiniciase la aplicación, el sistema tomaría los cambios y funcionaría de acuerdo a ellos.
    Al ver con más detalle el resultado, descubrí que el nombre de la variable no había quedado exactamente igual que el usado por la capa de datos. Y en la práctica, este hecho no es muy fácil de identificar.

    Así que dado que uno puede estar tentado a agregar el setting usando la interfaz de Visual Studio, puede incurrir en este error si no se fija lo suficientemente bien. Lo mejor, es no agregar el setting de esta manera. Sino agregar a mano (o editar a mano si ya existe), un archivo App.config y escribir el setting exactamente como se usó en la capa de datos.Cuando así lo hice, con felicidad observé como finalmente los cambios en el archivo XML se veían reflejados en la aplicación, cuando esta empezaba a correr. Esto me dio la flexibilidad requerida para configurar cada cliente con una fuente de datos distinta a la usada en el desarrollo de la aplicación.

    Conclusión: Para propagar las variables de configuración desde las capas más exteriores a las más interiores dentro de un sistema n-tier usando framework 2.0 en adelante, basta con escribirlas todas en el archivo de configuración de la capa más externa, de manera que sean absolutamente idénticas a las usadas en las capas internas. Y no es posible hacer esto, solo con la ayuda de la interfaz gráfica de Visual Studio, pues se requiere editar el archivo manualmente y luego incluirlo en el deployment de la aplicación.


  • WarNov Developer Evangelist

    Enfrentándose al StackOverflowException

    • 0 Comments
    Más de una semana sin solución. Buscaron en internet a ver... nada.
    Los StackOverFlow Exception no se pueden capturar con un try catch. Ni lo intenten. Cuando sucede la aplicación está más muerta que al cerrarla.
    Finalmente, me preguntaron....
    "Eso es que tienen una función recursiva con el punto de parada mal diseñado" les dije.
    Pero no había tal.
    Entonces me puse a mirar...
    En la primera ocasión no vi nada anormal en realidad. Solo un par de cosas para optimizar el código. Pero nada como para decir que el misterioso snack dejara de aparecer.
    Una y otra vez se repetía. Y lo peor, es que era un proceso bastante largo, que siempre fallaba luego de la primera horta. Así que hacer debug era un infierno total.
    En la segunda ocasión que me senté a mirarle el código, tampoco vi nada raro; se me ocurrió que depronto había mucha memoria desperdiciada... pero nótenlo: eso nunca tiene que ver con el stack. Snack es una cosa y Stack es otra y Memoria no tiene que ver con ellos. El Stack almacena el listado de funciones que se han ejecutado. Y tiene un tamaño entre 500 y 1000. Así que si llamamos más de ese número, el stack secillamente se llena y la aplicación colapsa.

    Teniendo esto muy presente, decidí volver a chequear el código una tercera vez...
    y oh sorpresa cuando al fin encontré lo que estaba pasando!!!!

    Había un método que al final del mismo, tenía un disparador de evento. Otra clase capturaba ese evento y en respuesta lanzaba la ejecución de otro proceso distinto que antes de terminar volvía a lanzar ese evento y así sucesivamente. Todo esto siempre se ejecutaba con el mismo thread. Así que cada vez, el método se quedaba esperando a que se ejecutara el siguiente. Por esto el stack comenzaba a llenarse hasta colapsar, porque las funciones no terminaban, pero si se llamaba a otras.

    Es algo para nada obvio. Pero al fin por pura intuición se descubrió. Lo ridículo del asunto, era el mensaje que representaba el evento disparado: "Terminé" Entonces otra clase leía que había terminado y ponía a correr otro proceso. Que sentido tiene eso? Era muy difícil programar a la clase externa que corriera un proceso y luego otro y otro y ya? No lo creo. Sencillamente a algunos diseños les falta ingeniería de verdad.
  • WarNov Developer Evangelist

    .NET Avanzado: Closures

    • 0 Comments

    Voy a ponerlo lo más simple que pueda:

    Un Closure  es una entidad de código que encapsula un comportamiento dado teniendo acceso al contexto en que fue definido; en cristiano, es como una clase, pero no con tanta flexibilidad (solo admite una acción dada) y su estado no puede ser cambiado luego de ser inicializado. En síntesis, una seudoclase más especializada, que consume menos recursos. Y que es más felxible que una estructura, dado que se constuye con delegados, que pueden apuntar a distintos métodos.

    Cómo se construye?

    Tomar el framework 2.0 en adelante, usar sus delegados y métodos anónimos, generar un productor de delegados con un parámetro de configuración y se obtendrá un closure.

    Ha tenido por ejemplo que calcular un impuesto como el IVA que puede variar según el artículo?
    Por ejemplo para una crema dental es de 16% pero para un auto es 25%.

    Entonces el programador bien juicioso se hace el siguiente método:

    double IvaCalc(double tax, double amount);

    Así pues siempre que se vaya a llamar al método se han de pasar ambos parámetros:

    double imp1 = IvaCalc(25, 25800);
    double imp2 = IvaCalc(16, 4);
    dpuble imp3 = IvaCalc(16, 5800);

    etcétera

    Entonces se puede optar por hacer dos métodos; uno por cada tipo de IVA.
    Pero si son 10 tipos de IVA habrán 10 métodos?

    Así que se opta por hacer una clase calculadora de IVA:

    Código clase calculadora de impuestos en C#

    De esta manera basta con instanciar un objeto por cada tipo de IVA y ponerlo a trabajar; esto minimiza la cantidad de código escrita, y es bastante claro:

    IvaCalculator autoCalc=new IvaCalculator(25);
    IvaCalculator prodCalc=new IvaCalculator(16);
    double imp1 = autoCalc(25800d);
    double imp2 = prodCalc(4d);
    double imp3 = prodCalc(5800d);


    Pero de nuevo... si son diez tipos distintos de IVA, creará diez instancias de objeto? Es justo tanto empleo de memoria al tener un objeto completo solo para hacer una operación?
    No lo creo... precísamente para solventar esta situación son útiles los closures.(Entre otras)

    Un closure permite reflejar la simple funcionalidad de la pequeña clase que diseñamos anteriormente, sin incurrir en el overhead del objeto como tal. Para lograrlo, se requiere una forma de mantener un estado (en este caso, la tasa del impuesto) para no tener que estar pasando el parámetro de configuración en cada llamado. Además se requiere una operación sobre ese estado. Cómo lograrlo sin tener que hacer un objeto?

    La operación como tal, se logra con un simple método. Pero este método debe ser configurable en su creación de manera que tenga un estado.

    Para que se pueda configurar es necesario que exista una variable en un ambiente léxico (scope) superior al del método, de manera que esta variable pueda ser inicializada sin necesidad de llamar al método. Esta, será pues la variable que indica el "estado" del método. Pero igual, eso está dentro de una clase. De hecho en C# todo lo que ejecute, ha de estar dentro de una clase. La ventaja ahora, es que vamos a trabajar dentro de la misma clase de ejecución de nuestro flujo. No tendremos que crear más instancias.

    Tanto el parámetro como la operación deben quedar encapsulados dentro de un mismo ambiente léxico dentro de la clase, para que tengamos la unidad requerida para poder generar instancias (pero no de una clase que es lo que queremos instanciar, sino de algo más liviano que llamaremos "enclosure"). Para esto es necesario poder hacer referencia al método dado.

    En .NET qué nos permite hacer referencia a métodos? Si... correcto: los delegados. Entonces generamos un ambiente léxico que tenga al delegado referenciando al método y al parámetro de configuración. Obviamente si estamos dentro de una clase y no queremos generar otra, ese ambiente léxico es un nuevo método. Este método deberá retornar el delegado apuntando a la operación ya configurada como es debido, pero además el método al que apunte el delegado deberá estar declarado inmediatamente, de manera que el parámetro de configuración del mismo sea accesible a éste, desde el método que lo contiene.

    En teoría suena bien. Pero cómo lograr que un delegado apunte a un método que se declara "en línea" junto con éste?

    Ahí es donde entran los métodos anónimos. Son precisamente eso: Métodos declarados en línea donde son requeridos por los delegados. Generalmente, los delegados se han inicializado con el nombre de un método que cumpla el contrato de su firma. Ahora (Framework 2.0 en adelante), no es necesario declarar el método aparte para poderlo referenciar luego por un delegado (lo que impediría acceder al dichoso parámetro de configuración) sino en línea junto con la declaración del delegado:

    delegate int MyDelegate(int a, int b);
    MyDelegate myDel = delegate (int a, int b)
    {
       .....
       return ....
    };

    No olvide el ";".

    Ya con este conocimiento, podemos generar el método que queremos:

    //Este delegado que permitira
    delegate double IvaCalculator_(double tax);

    IvaCalculator_ ivaCalcProducer(double tax)
    {
       return delegate(double amount)

       {
          return amount*tax;
       };
    }


    Exótico no?

    Pero a pesar de ello, logramos lo deseado: El método toma una variable de configuración. Así tenemos estado y manipulación de estado. Lo que haría una clase. Entonces ahora cómo se operaría es muy parecido al uso de clases anterior; solo que ahora no hay overhead por creación de nuevos objetos. Lo que se crean son nuevos delegados. Uno por cada tipo de tasa en este caso. Ellos "cuestan" mucho menos que un objeto.

    IvaCalc_ ivaCalc16=ivaCalcProducer(16);
    IvaCalc_ ivaCalc25=ivaCalcProducer(20);
    double imp1 = ivaCalc25(25800); 
    double imp2 = ivaCalc16(4); 
    double imp3 = ivaCalc16(5800);

    Descargar Ejemplo Completo (Aplicación de consola en C# mostrando el uso de Closures)

    Y listo. Así se construyen y usan los closures. Ahora ya puede ir y alardear un poco con su equipo de desarrollo acerca del misterioso "Closure"!!

     Open mind 4 a different Coding!!!

  • WarNov Developer Evangelist

    Introducción a Generic Handlers en ASP.NET

    • 2 Comments

    Un Generic Handler (GH) es una clase de objeto .NET que puede procesar http requests, sin necesidad de estar dentro del scope de una página aspx (que está dirigida a presentar salidas de tipo HTML clásico). Un ejemplo de GH es el HTTP Handler. Como es bien sabido un http Handler se puede asociar a cualquier extensión de archivo (de acuerdo a lo permitido por el IIS). Los GH sin embargo, solo se pueden asociar a la extensión ASHX que está directamente soportada por los proyectos web en visual Studio 2005 y posteriores. Así que los GH en .NET se asocian a archivos con extensión ASHX.

    Todos los Handlers implementan System.Web.IHttpHandler. Además, en IIS 7 se puede alojar cualquier Handler directamente.


    El hecho que el GH pueda correr fuera del entorno de una página y aparte procesar HTTPRequests, lo hace una herramienta perfecta para ofrecer servicios similares a los que ofrecería un Web Service. De esta manera, es un muy buen candidato para reemplazarlos, cuando no se pueden implementar ya sea por requerimientos del negocio o requerimientos no funcionales.

    Por qué puede no ser deseado un WebService?

    Según la arquitectura y requerimientos de algunos clientes, es mejor recibir resultados a través de HTTPRequest "simple", debido a que por ejemplo el llamado se hace desde una plataforma distinta a .NET desde la cual se hace bastante complejo crear un llamado a un WebService, tal vez porque la herramienta no puede manejar todos los tipos estándar en los WebServices (como sucede por ejemplo con PHP antiguo).

    Entonces por qué no hacer una página Web Normal que responda a los llamados?

    Si se crea una página aspx que responde a las peticiones se incurre en adicionales encabezados y todo el overhead adicional que genera la creación de una página completa (ciclo de vida, viewstate, etc), cuando en realidad sólo se desea obtener una simple respuesta (una imágen un xml, etc).

    Entonces para ganar performance y facilidad de administración en este tipo de funciones, es posible crear un Generic Handler sin dejar de atender al requerimiento de que la comunicación permanezca sencilla.

    Entre los métodos obligatorios al estarse implementando IHttpHandler está ProcessRequest que es el que ejecuta el proceso requerido y por ende al fnal de su alcance habrá de tener un llamado a context.Response.Write o similar, que devuelva una respuesta http. Esta respuesta puede ser html, txt plano, imágenes, xml, etc.

    Uso Avanzado 

    Suponga le siguiente escenario: Existe un objeto en memoria que se desea presentar al usuario como una página html.

    Opciones:

    1. Serializar el objeto a XML, leer el XML y pasarlo a un XSLT que crea el HTML, y grabarlo en un archivo que luego es presentado en un IFrame. Como es obvio, el overhead de crear y borrar estos archivos físicos generados es absolutamente inaceptable.
    2. Otro enfoque es incluir en la página un control XML que muestre el objeto serializado y en el cual luego de hacer la transformación se vea el HTML como tal. Es una alternativa muy aceptable que a primera vista no tiene ninguna desventaja, excepto el mismo overhead y tamaño que implica una página ASP.NET.
    3. Generic Handler: Se obtiene un control más directo sin el overhead que implica agregar un control XML a una página que además tendrá otros elementos que sumaran innecesariamente peso al resultado.

    Cómo se Logra?

    Al crear un GH, éste puede ser llamado como cualquier otra página aspx. (Por ejemplo desde un browser) Además también pueden aceptar parámetros: http://warnov.com/miGH.ashx?param=valor;otroparam=otrovalor a través de su URL. Para incluir un GH en su aplicación Web, solo agreguelo como un nuevo item en el proyecto en Visual Studio.

    En el caso especial de querer mostrar un objeto serializado en XML y transformado a través de XSLT es bastante sencillo: Solo se tiene que incluir en el XML la directiva de transformación XSLT y el archivo XSLT se ha de encontrar en la ruta que allí se especifica.

    Conclusión:
    Como se observa, son muchas la aplicaciones que tienen estos objetos y es considerable la ganancia que se obtiene con su uso, aunque en general pasan muy desapercibidos.

  • WarNov Developer Evangelist

    Carga Dinámica de CSS en ASP.NET

    • 2 Comments

    Los descubrimientos descritos a continuación, surgieron de mi necesidad de cargar CSS dinámicamente sin estar creando numerosos temas dentro de una aplicación WEB ASP.NET. Esto es, separar la administración de CSS de los temas. Así un mismo tema podrá tener varios CSS a petición.

    En primera instancia: Toda página que referencie un tema, SIEMPRE cargará todos los CSS incluidos en el mismo, independientemente de que en realidad los necesite, y del nivel de anidamiento en el que se encuentren ubicados. Poco eficiente no es así?

    Como se sabe, los CSS finalmente son Links referenciados en el HEAD de la página que está referenciándolos. Entonces es cuestión de escribir dinámicamente allí la ruta del CSS que se desea cargar y listo.

    Lo anterior se logra agregando un ASP.NET literal control dentro del HEAD, y en el load de la página ajustarlo con el valor que se desea.

    Y listo!!!

    A pesar de que existan varios CSS en la misma ruta de aquel que está siendo referenciado, solo el referenciado se descarga.

    Ventajas?

    • Tener organizados varios CSS y no solo uno gigantesco con todo.
    • En cuanto a ancho de banda, si los CSS se dejan dentro de temas, por más separados que estén si son cargados por medio de referencia al tema desde la página, siempre bajan todos la primera vez que se llamen (luego quedan en el caché y no vuelven a descargarse si no se borra el caché o si no cambian en el server).

    Conclusión:
    Si se desea optimizar el tiempo de descarga, entonces es mejor no usar Themes para cargar los estilos, sino que estos se carguen independientemente usando el modelo de HEAD descrito anteriormente.

    Ejemplo:

    Dado que me han pedido mucho un ejemplo en código aquí va:

    Aspx

    <html xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
        <asp:Literal ID="Literal1" runat="server"></asp:Literal>
        <title></title>
    </head>
    <body>
        <form id="form1" runat="server">
        <div>
            <asp:Label ID="Label1" runat="server" Text="Este es un ejemplo de texto"></asp:Label>
            <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
        </div>
        </form>
    </body>
    </html>
    

     

    Codebehind

    using System;
    
    namespace WebApplication1
    {
        public partial class WebForm1 : System.Web.UI.Page
        {
            protected void Page_Load(object sender, EventArgs e)
            {
                Literal1.Text = "<link href='Styles/Site.css' rel='stylesheet' type='text/css' />";
            }
        }
    }
    

     



  • WarNov Developer Evangelist

    Alternativas para evitar abuso de los portales

    • 0 Comments
    Uno de los principales riesgos en la operación de nuestros portales es su posible abuso por parte de terceros que con el fin de hacerse a la base de datos que los alimentan, están en capacidad de ejecutar todas las consultas que a bien tengan, tanto manual como automáticamente. En este artículo me estaré enfocando en ambientes sin manejo de sesión y autorización que son los más vulnerables a este tipo de anomalías.

    Los portales son muy vulnerables a estos abusos (que no se pueden catalogar realmente como “ataques”) dado que la naturaleza del negocio implica que todas las consultas estén abiertas a todos los públicos y no con menos importancia, a los motores de búsqueda; de manera que no existen mecanismos de autenticación que impidan por ejemplo el acceso al sitio por medio de robots o programas que extraen automáticamente el contenido de nuestros sitios; además existen efectos colaterales como disminución del ancho de banda y de velocidad de proceso en los sitios.
    Existen básicamente dos tipos de acciones que podrían ayudar a mitigar este riesgo. El primer tipo comprende las acciones ejecutadas a nivel de la infraestructura de la aplicación. El segundo tipo consiste en las acciones ejecutadas a nivel de desarrollos adicionales en la aplicación como tal.

    Infraestructura
    Existen servidores de seguridad que reciben todas las peticiones de los clientes antes de que estas lleguen a la aplicación como tal. Esta herramientas se instalan al frente de los servidores web. Y ayudan a través de los siguientes mecanismos:

    Cookies
    Las cookies estarían almacenando la cantidad de requests que está haciendo cada cliente en una unidad de tiempo dada. Esto requiere sin embargo que se exija a todos los clientes el uso de cookies; hay que tener en cuenta sin embargo, que existen muchos usuarios que desactivan estas cookies en sus browsers.

    Javascript
    El uso de javascript permite generar rutinas que los robots no podrían seguir, de manera que el acceso quedaría restringido a estos entes automatizados. La gran contra que tiene este enfoque, es que puede requerir procesos de considerable costo en el servidor. Además que se le estaría restringiendo el uso también a motores de búsqueda como google que usan robots para obtener información de los sitios.


    Aplicación
    A nivel de aplicación el conjunto de acciones posibles es más diverso. Se trata de rutinas destinadas a detectar accesos irregulares a la aplicación. Estas pueden ser provistas como productos terminados ya hechas por terceros, o como desarrollos nuevos dentro de la aplicación.

    Delay
    Existen herramientas como ISTools de Peter Blum, que basadas en un patrón de IP (esto puede ser contraproducente en el caso de que las ips reales estén siendo reemplazadas por las ips de los ISP) detectan los accesos irregulares y generan retardos en las respuestas, advertencias y finalmente denegación del servicio a los supuestos atacantes. Un caso favorable es que en algunas ocasiones los ISP mantienen la ip de sus clientes y la reenvían como una variable HTTP que puede ser consultada. Pero esto no ocurre siempre.

    Javascript y Cookies
    Ambos mecanismos funcionan con desarrollos de productos de igual forma a la que fue descrita en el apartado de infraestructura.

    Listado de Robots
    Herramientas de terceros permiten consultar un IP dada y verificar si ha sido tildada como un robot para en ese caso tomar acciones al respecto.

    Cómo obtener la solución al problema
    Para generar una solución se han de tener en cuenta los siguientes puntos:
    1. Hoy en día no hay una solución ad-hoc que abarque todo el problema sobretodo sin efectos colaterales.
    2. Para generar una solución es muy necesario comenzar por definir unas políticas de detección de abuso que permitan establecer los parámetros para las herramientas que se usaran/construirán
    3. Los mayores problemas se presentan cuando no es posible obligar la autenticación en los portales luego no hay manejo de sesión
    4. Existen ISPs que direccionan los requerimientos con una IP única
    5. Existen usuarios que no permiten el uso de cookies en sus máquinas
    Teniendo en cuenta lo anterior, se puede sugerir implementar una solución compuesta tal como se describe a continuación:

    1. Definir la política de uso abusivo (Esto implica declarar cuándo se considera que se está extrayendo información del sitio de manera inescrupulosa; por ejemplo, que un mismo usuario visite más de 50 páginas de resultados de una misma búsqueda, o que realice más de 20 búsquedas distintas en un determinado lapso de tiempo)
    2. Definir las acciones a tomar luego de la violación de la política. (Redireccionar a un captcha, denegar el servicio, retardar el servicio, etc.)
    3. Proveer un mecanismo que permita avisar acerca de la violación de la política de acceso. Dependiendo de lo elaborado de la política, esto puede ser ejecutado desde la infraestructura o de la aplicación. Una política sencilla como solo contar el número de requests de una ip dada se puede implementar en la infraestructura. Una política algo más completa como la descrita como ejemplo en el numeral 1, requiere de un a implementación en el lado de la aplicación.
    4. Implementar e integrar los puntos anteriores de manera que cuando el mecanismo de advertencia avise acerca de un posible abuso de acuerdo a las políticas definidas, se tomen las acciones pertinentes.

    Recomendaciones acerca de la política de abuso


    Un acceso abusivo siempre puede ser detectado cuando desde una misma IP son hechos muchos requests. Pero esto mismo puede suceder con el caso de los ISP que tienen una sola ip de salida. Para evitar tachar incorrectamente a los ISP es necesario verificar el tipo de requests que se están haciendo desde una ip sospechosa. En general las consultas sobre los sitios no abarcan más de 10 páginas de resultados de un mismo tema. También de acuerdo a las estadísticas se puede establecer un límite para distintas búsquedas en un tiempo dado por una ip dada; por ejemplo más de 100 búsquedas distintas en 10 minutos indicarían un comportamiento malicioso.

    Entonces ante una violación a la política establecida anteriormente se garantizaría que no se cae en el falso positivo del ISP así que ante este comportamiento sospechoso se podría iniciar con buscar la IP en una base de datos provista por un tercero en la que están registrados los robots en la actualidad. Si este filtro pasa, se continúa con la verificación de si se trata de un robot autorizado como el de google o yahoo; esto se logra a través de un DNS lookup reverso. Aquí entonces si no pasa la validación, se procederá con la acción correctiva.

    Como inconveniente a esta solución, se cita la complejidad de su desarrollo, ya que requiere hacerse del lado de la aplicación que al no tener manejo de sesión, requeriría una implementación con almacenamiento en base de datos por ejemplo.
Page 13 of 14 (326 items) «1011121314