La evolución del software de componentes hasta .Net. COM permite el desarrollo de servicios de aplicación

La capacidad del software de componentes para desarrollar aplicaciones se basa en la utilización de módulos binarios y no de blibliotecas de código fuente. Uno de los software de componentes con más solera es COM (Component Object Model (COM), una arquitectura independiente de lenguaje desarrollada por Microsoft en los noventa, que permite a los desarrolladores crear aplicaciones a partir de componentes de software binario reutilizables.

En un mundo de redes interconectadas y de servicios web, las cargas de proceso son divididas cada vez más entre clientes y servidores separados los unos de los otros, tanto en distancia como en funcionalidad. Esto significa que es esencial que los ordenadores sean capaces de comunicarse entre sí, utilizando como información datos de entrada generados por otros ordenadores. No se trata de una situación nueva. En realidad, no es más que la consecuencia de cómo se vienen desarrollando las aplicaciones durante años.

En un intento por conseguir una mayor interoperabilidad y eficiencia, los desarrolladores de aplicaciones han establecido reglas de procedimiento, programación orientada a objetos y bibliotecas de software reutilizable. Normalmente y si pueden evitarlo, los desarrolladores rara vez crean aplicaciones a partir de cero, sino que intentan aprovechar la infraestructura de hardware, software y herramientas ya existentes, así como componentes de software previamente creados, todo ello para controlar el tiempo y el coste del desarrollo y del despliegue de las aplicaciones. Aunque estos métodos adoptan nombres muy diferentes, se designan normalmente como “software de componentes”, por lo que podemos considerar a los servicios web como una forma más distribuida del software de componentes.

Teniendo en cuenta que Windows se ha convertido en el sistema operativo principal de muchos ordenadores de sobremesa y que Microsoft ha decidido extender ese monopolio al mundo de los servidores, no es sorprendente que haya ofrecido durante años su propio repertorio de productos y estándares para software de componentes. Entre los más antiguos, y por lo tanto más conocidos y ampliamente utilizados, está el Component Object Model (COM) y su sucesor con capacidad para redes conocido como Distributed COM o DCOM.

La esencia binaria de COM
El verdadero valor del software de componentes para el desarrollo de aplicaciones es que permite utilizar módulos binarios, es decir, codificación en lenguaje de máquina y no bibliotecas de código fuente como sucedía con la mayoría de los entornos de desarrollo.
COM define un interfaz de programación de aplicación (API) que permite a diversos componentes interactuar entre sí. Mientras utilizasen una infraestructura binaria especificada por Microsoft, podían ser escritos en diferentes lenguajes y aún así interoperar unos con otros una vez que hubieran sido compilados. COM permite el desarrollo de servicios de aplicación utilizando documentos combinados, controles a medida, scripting interaplicaciones, transferencia de datos y otros tipos de interacciones de software.

Un recorrido por la evolución
La historia del software de componentes es compleja. Y esto se debe a que, en ocasiones, Microsoft ha tendido a cambiar su enfoque y su estructura cada pocos años, dando nuevos nombres y nuevas marcas a las tecnologías.

Inicialmente se desarrolló una tecnología para documentos combinados llamada OLE (Object Linking and Embedding), que fue construida encima de controles Dynamic Data Exchange y Visual Basic Extension (VBX) de Visual Basic 1.0. En 1992, Microsoft introdujo Windows 3.1 y con él OLE llegó a los ordenadores de sobremesa. Sin embargo, el fabricante otorgó a algunas partes de OLE relativas a Internet el nuevo nombre de ActiveX, un símbolo que abarcaba gradualmente a todas las tecnologías de componentes. OLE ocupó entonces, de nuevo, su papel como tecnología de documentos combinados, utilizada principalmente en Microsoft Office. Y llegó el tiempo de COM, que se implementó por primera vez en Windows 95. En 1996, al aumentar la importancia de las redes y de las aplicaciones conectables en red, Microsoft anunció DCOM como su alternativa a la arquitectura CORBA (Common Object Request Broker Architecture). DCOM apareció por primera vez en Windows NT 4.0, con herramientas de ayuda para crear aplicaciones cliente/servidor que abarcaban tanto la red corporativa como Internet. En septiembre de 1992, Microsoft cambió de nuevo a COM el nombre de todo su framework.

Años después cuando introdujo Windows 2000, Microsoft modifico de nuevo el COM consiguiendo que la organización TI de una empresa pudiera ejecutarlo en grupos o conjuntos de componentes gestionados por el Microsoft Transaction Server. Un componente creado adecuadamente podía ser reutilizado realizando llamadas a su rutina de reinicialización sin necesidad de descargarlo de la memoria. Los componentes podían también ser “llamados” desde otro ordenador, lo cual antes sólo era posible con DCOM, por lo que Microsoft prescindió en gran medida de DCOM como concepto independiente.

Sin embargo, todavía quedaba un nuevo paso: Microsoft lanzaba su iniciativa .Net, un framework que casi sustituyó por completo a la tecnología COM, aunque la compatibilidad retroactiva es limitada. De hecho, la tecnología .Net puede utilizar un objeto COM implementando lo que se conoce como un wrapper. .Net incluye software y sistemas operativos de aplicación para clientes “inteligentes”, dispositivos inteligentes, servicios web que pueden ser combinados con otros e incluso ser utilizados directamente con aplicaciones de clientes inteligentes, una infraestructura de servidor y un entorno (Visual Studio .Net) que soporta directamente cierto número de lenguajes de desarrollo a través del Common Language Runtime de .Net.

Cambios Recientes
A pesar de haber sido sustituidas por .Net, las tecnologías COM y DCOM siguen vivas y con buena salud. De hecho, en el Service Pack 2 para Windows XP Microsoft implementó dos cambios importantes a DCOM. Así, introduce restricciones a nivel de todo el ordenador que ofrecen una comprobación de acceso adicional, a través de una lista de control de accesos cada vez que es activado, “llamado” o puesto en marcha un servidor COM. A ello hay que sumarle que SP2 introduce también permisos COM más detallados, lo que repercute en incrementos en la flexibilidad de la que disfrutan administradores y desarrolladores a la hora de activar políticas de control de permisos de acceso a un ordenador.