Habilitación en Microsoft .NET: análisis y precauciones

Análisis

Como se ha venido explicando en esta serie, es necesario contar con ciertos elementos para desarrollar e implementar una arquitectura de tecnología de la información (TI) que esté conectada con servicios Web. Dichos elementos son smart clients, servidores para alojar los servicios Web, herramientas para crearlos y aplicaciones para usarlos. Además de estos elementos, Microsoft .NET Framework cuenta con una red mundial de más de 35,000 empresas certificadas como Microsoft Certified Partner que pueden proporcionar a los usuarios la ayuda necesaria. Si desea consultar una definición de cómo el ambiente Microsoft .NET trata la situación, refiérase a Los sutiles (o no tan sutiles) matices de la habilitación de Microsoft .NET.

Tercera parte de la serie Los sutiles (y no tan sutiles) matices de la habilitación de Microsoft .NET.

El artículo Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios contiene información sobre la evolución de la arquitectura de sistemas.

Sólo algunos vendedores innovadores o valientes (o ambos) que se centran en Microsoft han decidido aventurarse en el angustiante (pero potencialmente gratificante) esfuerzo para ofrecer un software completamente nuevo, escrito en código administrado basado en .NET Framework, en donde gran parte de las tareas básicas del sistema se retiran del código para ser “administradas” por .NET Framework. Se puede usar y acceder a esta funcionalidad, que ha sido totalmente reescrita o que se ha creado usando sólo .NET Framework, mediante servicios Web, como lo demuestran los ejemplos del software habilitado en .NET (“envuelto”) de la contraparte que se mencionan en Ejemplos de habilitación en Microsoft .NET.

Precauciones

Sin embargo, si la historia sirve para predecir el futuro, es realmente difícil llevar a cabo con eficacia esta estrategia de transformación de las estructuras del software, y sólo los vendedores más ingeniosos o firmes podrán resultar ganadores a largo plazo. Así, hay que poner atención a la forma en que la tecnología puede desarrollarse en el futuro y alinear las funciones del negocio y de TI. En todo el ciclo de vida de las aplicaciones, los altos costos de desarrollo, soporte y mejoras -en cuanto a dinero, tiempo y calidad- limitan la capacidad que tiene el software legado para satisfacer muchas de las demandas del negocio. Existen otros obstáculos, como el hecho de que puede resultar imposible modificar las funciones legadas, y que para desarrollar y mantener dichos ambientes para la aplicación wrapper puede ser necesario contar con una capa adicional de código (obligando al programador a seguir manejando las tareas del sistema). Asimismo, este salto tecnológico puede no ser recomendable para los avances tecnológicos futuros de Microsoft, como Windows Vista.

Una vez que se agregan las tecnologías registradas en la ecuación de investigación y desarrollo, los vendedores deben tratar los asuntos de traducción, interfaz y desempeño, además de tener que soportar el calvario de migrar o mantener actualizados a los clientes existentes o de mantener varias versiones de los productos. De hecho, algunos vendedores rezagados ven este paquete de arquitectura orientada al servicio (SOA) y servicios Web como una oportunidad para presentar los sistemas legados como el “tesoro oculto” de los activos del software. Si bien esto puede ser cierto para algunas aplicaciones en las que no se justifica la “reinvención de la rueda” (en otras palabras, duplicar lo que ya existe, por ejemplo, desarrollar un sistema nuevo para nómina o contabilidad general), los usuarios y los vendedores deben esforzarse para descifrar este tesoro oculto y diferenciar los “diamantes” de las “imitaciones”. Para ello deben iniciar un minucioso proceso que los lleve a descubrir con qué activos funcionales cuentan y decidir cuáles mantener, cuáles modernizar y cuáles desechar, ya que el código que se mantenga será la fundación de un depósito funcional de servicios que se usará durante muchos años.

Existen muchos vendedores, especialmente aquéllos que son veteranos (y que iniciaron con unidades de cómputo), que disfrutan haciendo creer a la gente que con SOA cualquier código antiguo es útil. Sin embargo, la realidad puede ser muy diferente. Algunos sistemas legados han existido desde hace más de cuarenta años, y aunque siguen funcionando y siendo útiles, no todos son dignos de mantenerse como están. Si bien en muchas circunstancias las empresas pueden usar las aplicaciones wrapper como medida temporal, eventualmente, y al contrario de lo que afirman muchos vendedores, tanto los vendedores como las empresas usuarias deberán modernizar y transformar gran parte de su código legado. Si desea obtener más información consulte Rewrite or Wrap-Around Old Software?.

De hecho, Epicor Vantage es un ejemplo de una aplicación que esencialmente se posiciona entre el enfoque de habilitación en .NET y la reescritura en código administrado .NET puro (que sería el siguiente paso en la evolución, como se explicará más adelante). Es decir, cerca del 60 por ciento de Vantage está en código administrado .NET (en otras palabras, un smart client basado en C#, herramientas para la capacidad de extensión, personalización, etc.), y toda la lógica del negocio se expone como servicios Web (no con aplicaciones wrapper, sino como servicios Web generados con Progress OpenEdge). Durante la reescritura, Epicor recreó gran parte de la lógica del negocio en una forma más detallada, con el propósito de soportar las llamadas de servicios Web. Por ejemplo, la llamada de revisión de la capacidad para promesa (CTP) que requieren los usuarios de Vantage no puede operar correctamente sin .NET Framework.

Por supuesto, la presencia de Progress demuestra que Vantage no se está por completo en código administrado .NET. Pero Epicor no planeó que Vantage estuviera en .NET 100 por ciento, sino en SOA. El vendedor sólo usó .NET para la mayor parte de la solución en donde tenía sentido hacerlo, como la gestión de biblioteca de enlace dinámico (DLL) del lado del cliente, y proporcionó la plataforma normalizada Epicor Portal basada en las tecnologías Microsoft SharePoint “más recientes y avanzadas” (consulte Epicor le da a sus aplicaciones más que un retoque). El vendedor no usó .NET cuando quiso garantizar que los clientes tendrían opciones y flexibilidad en el lado del sistema operativo (SO) y la base de datos. A saber, .NET puro en todo el sistema implicaría soportar únicamente una pila Microsoft, y que Epicor puede soportar SO Microsoft y Linux/Unix, y bases de datos Microsoft SQL Server, Progress y Oracle (actualmente no soporta esta última, pero pretende hacerlo en el futuro). Esta fue una decisión importante que tenía como fin dar soporte a los clientes más grandes que creen, con o sin razón, que las plataformas de Microsoft no se pueden graduar.

El diseño de SYSPRO ha seguido la misma ruta, y las aplicaciones web, SYSPRO Reporting Services (SRS) y Analytics que se mencionaron en Los sutiles (o no tan sutiles) matices de la habilitación de Microsoft .NET se escribieron usando código administrado .NET, mientras que la capacidad de habilitación en .NET que tiene SYSPRO Cyberstore también se puede apreciar en los sistemas SYSPRO BarCode y SYSPRO Warehousing Management System (WMS), que están integrados por completo con el sistema de planificación de los recursos de la empresa (ERP) mediante .NET Framework.

¿La administración con .NET es lo correcto?

No obstante, los productos de software administrado con .NET están creados con componentes homogéneos de “código administrado” .NET, es decir, sin aplicaciones wrapper. En otras palabras, el código administrado .NET es aquél cuya ejecución es administrada por una máquina virtual .NET, como .NET Framework Common Language Runtime (CLR). Administrado se refiere a un método para intercambiar información entre el programa y el ambiente de operación, o a un “acuerdo de cooperación” entre el código que se ejecuta de forma nativa y la operación. Este acuerdo especifica que en cualquier momento de la ejecución, la operación puede detener una unidad de procesamiento central (CPU) que esté en funcionamiento y buscar información específica a la dirección actual de la instrucción de la CPU. Esta información que debe poder consultarse pertenece generalmente al estado operativo, como contenido de registro o memoria en pilas.

Por lo tanto, la información necesaria se codifica en Microsoft Common Intermediate Language (MCIL o MSDIL) y los metadatos relacionados, o en información simbólica que describa todos los puntos de entrada y las construcciones que se exponen en el MCIL (como métodos y propiedades) y sus características. La norma de la infraestructura de lenguaje común (CLI) (en la que CLR es la implementación comercial principal de Microsoft) describe cómo se codificará la información, y los lenguajes de programación que se orientan a la operación emiten la codificación adecuada. Los desarrolladores sólo deben saber que cualquier lenguaje que se oriente a la operación produce código administrado emitido como archivos ejecutables portátiles que contienen MCIL y metadatos.

Como se subrayó antes, existen más de treinta lenguajes de este tipo ofrecidos por terceras personas: desde COBOL hasta Camel, además de Visual C#, J#, VB.NET, Jscript y C++ de Microsoft. La CLR incluye sistema de lenguaje común (CLS), que establece las reglas y normas de sintaxis y semántica del lenguaje, así como el sistema de tipos comunes (CTS), que define los tipos de datos que pueden usarse. Todos los programas usan los servicios comunes del CLS, por lo tanto, no importa en qué lenguaje se escriban las aplicaciones, se dice que usan “código administrado”. En un ambiente Microsoft Windows, todo el código restante se conoce como “código no administrado”, mientras que en otros ambientes, el código administrado se usa de forma más general para referirse a cualquier lenguaje de programación interpretado.

Antes de operar el código administrado, se compila el MCIL en un código nativo ejecutable (máquina). Además, debido a que la compilación se realiza en todo el ambiente administrado de ejecución (mejor dicho, por un compilador just-in-time [JIT] que sabe cómo orientarse al ambiente administrado de ejecución), este puede garantizar lo que hará el código. Puede insertar trampas y ganchos de recolección de basura, manejo de excepciones, seguridad de tipos, revisión de los índices y los límites de las matrices, etc. Por ejemplo, este compilador se asegura de organizar bien las estructuras de las pilas y todo lo demás para que el recolector de basura pueda funcionar en segundo plano en una hebra distinta, caminando la pila de llamadas activas constantemente, encontrando todas las raíces y persiguiendo todos los objetos en vivo. Además, MCIL tiene una idea de seguridad de tipos, por lo que el motor de ejecución mantendrá la garantía de dicha seguridad, eliminando toda una clase de errores de programación que con frecuencia producen orificios en la seguridad.

Normalmente, esto se conoce como compilación JIT, aunque a diferencia de la mayoría de los compiladores JIT tradicionales, el archivo que mantiene el seudo código de máquina que la máquina virtual compila en un código nativo de máquina también puede contener binarios compilados previamente para diferentes máquinas nativas (como x86 y PowerPC). Este es un concepto similar al formato binario Apple Universal, que mucha gente percibe como el sistema que “nunca falla”. En cambio, los archivos ejecutables no administrados son básicamente una imagen binaria, código x86, cargada en la memoria, que hace que el contador del programa se coloque ahí, y que es lo último que verá el SO. Existen protecciones alrededor de la gestión de memoria y el puerto de entrada y salida, entre otros, pero el sistema no sabe en realidad lo que está haciendo la aplicación. Por lo tanto, no puede garantizar lo que sucederá durante su funcionamiento.

Esto quiere decir que el software administrado con .NET debe aprovechar las ventajas de desempeño y seguridad del código administrado por .NET, ya que CLR maneja gran parte de las tareas básicas que antes manejaba un programador en el código de la aplicación, como las revisiones de seguridad y la gestión de la memoria. Asimismo, los productos administrados con .NET podrán funcionar mejor como “código nativo” en Microsoft Vista y los futuros avances tecnológicos y SO de Microsoft, proporcionando otra ventaja importante. Finalmente, aquellos desarrolladores de .NET que tengan experiencia con código administrado confirmarán que este nuevo paradigma de programación les permite desarrollar y expandir las aplicaciones en tiempo récord y con grandes mejoras a la calidad. Esto se debe a la capacidad para crear software más “esbelto” con muchas menos líneas de código, que funciona de forma nativa en .NET Framework.

El uso de tecnologías que son compatibles de forma intrínseca debe resultar en un desarrollo más rápido y menos costoso. Así, cualquier serie de aplicaciones que haya sido reescrita con la estructura de código administrado Microsoft .NET, no deberá enfrentarse a los conflictos tecnológicos, los sacrificios o las ineficacias que produce la mezcla o la “envoltura” de tecnologías. En cambio, cualquier vendedor que cubra varias plataformas gasta más de la mitad de su presupuesto de investigación y desarrollo en resolver problemas de transferencia. Por ello, una solución de plataformas múltiples sigue siendo la prerrogativa (y la carga consecuente) de los vendedores más grandes.