Este artículo lo publiqué en un medio universitario hace 10 años ahora (de ahí el tono tan formal del texto). .NET estaba apareciendo y al releerlo, me ha sorprendido que, a pesar del tiempo transcurrido (un mundo, 10 años) creo que sigue siendo válido en lo fundamental.
<ARTICULO>
Desde los tiempos de los mainframes, la evolución en las
estructuras y soluciones de software, parece haberse basado en dos conceptos
básicos:
- Disgregación o Intercalación (o cómo sacar factor
común)
- La
comunicación entre los elementos
disgregados, que ahora
denominamos mecanismos de integración de sistemas, orquestación de
soluciones, etc.
Dicha comunicación plantea básicamente un
problema de lenguaje y además, afecta la forma en que se escribe el software,
tanto estructural como específicamente.
Una breve memoria histórica, nos lleva a
tiempos del DOS, cuando se hicieron populares las aplicaciones TSR (Terminate & Stay Resident), que,
como su nombre indica, permanecían en memoria pudiendo ser recuperadas más
adelante con una combinación de teclas. Los problemas de colisión que surgieron
entonces, podían resolverse mediante la aportación de un intermediario, el
conocido como Extensor del DOS, un programa que se cargaba al lanzarse el
sistema operativo, y permitía administrar la memoria de forma que cuando una
aplicación necesitaba una ubicación en memoria extendida, no la tomaba
directamente, sino que la solicitaba a través del extensor, quien la
administraba, evitando colisiones entre zonas ocupadas por distintos programas.
Ciertos enlazadores (linkers) de la
época tenían bien en cuenta esta circunstancia (por ejemplo, Blinker).
Pero la idea puede extenderse: pongámonos de
acuerdo en el paquete funcional que da acceso a cada origen de información, de
forma que el cambio de dicho origen no suponga la modificación de la aplicación
que lo utiliza. Se populariza a partir de ahí la estructura fragmentada, que
incluso hoy ha llegado a su máxima expresión en lo que conocemos como arquitectura multicapa.
Con el advenimiento de Windows, el concepto
de DLL se convierte en el principal ejemplo del intermediario, esta vez en su
versión sacar factor común. Las DLL
de Windows, almacenan un conjunto funcional común que pasará a denominarse API
de Windows, y que permiten a cualquier programa instalado en el sistema,
utilizar los mismos recursos. Los programas no tienen que incorporar ya en sus
ejecutables lo que el sistema les proporciona por defecto.
Sin embargo, el paradigma del intermediario
como solución, no llegaría a su madurez hasta el advenimiento de ciertos
estándares de intermediación llamados modelos de objetos: COM y CORBA son sólo
dos ejemplos, a los que seguirían los modelos de acceso a datos, tales como ODBC y OLE-DB, o el propio modelo
de objetos de documento (DOM), que convierte lo que es texto plano (HTML) en un
sistema de objetos en el cliente capaz de ser programado mediante un lenguaje
de script.
Desde el punto de vista del programador, incluso
el concepto de interfaz descansa en varios sentidos en el concepto de
intercalación. Pero, los principales lenguajes de programación lo han estado
usando desde el principio: las MFC y posteriores WFC y .NET Framework, no son
otra cosa que inmensas jerarquías de clases comunes a las que un lenguaje puede
hacer referencia. Por eso, la importancia del lenguaje se minimiza,
reduciéndose a una mera cuestión de afinidad sintáctica. Las capacidades del
actual Visual Basic .NET son prácticamente idénticas a las que posee el
novísimo lenguaje C#. Al final, todo es
MS-IL (código intermedio: el gran intermediario en .NET) y lo que realmente
facilita la programación es el conocimiento de la jerarquía (o mejor aún, de
los mecanismos de búsqueda y manipulación, dentro de ella), más que la adhesión
a un lenguaje concreto.
Y MS-IL tiene una contrapartida externa: el recién aparecido estándar XML, una sintaxis (que no lenguaje) común -autodefinido, mediante Schemas– para permitir el transporte y la comunicación de datos entre sistemas y plataformas distintos. Y en eso, comparte algo en común con MSIL que resulta fundamental: ambos disponen de metadatos: de un sistema de autodescripción.
Tenemos pues, un modelo de arquitectura que
se repite por doquier. De hecho, una de las más relevantes novedades de .NET, es
el sistema de comunicación entre objetos, basado en el concepto de delegado (delegate).
Un delegado es el intermediario por excelencia al estilo de los viejos
extensores del DOS: se sitúa en una zona intermedia y vela por la correcta
comunicación entre métodos de objetos distintos, garantizando la presencia del
receptor, y la compatibilidad de los tipos de datos recibidos por éste.
Es la solución aportada por Hejlsberg al problema de los punteros
nulos (si queremos tener garantía que un mecanismo de comunicación es eficaz,
garanticemos, primero, la presencia de los sujetos de la comunicación (tipos
emisor y receptor) y después, al de la coherencia de la información transmitida: los
tipos de datos pasados entre uno y otro. Eso posibilita gran parte de la
seguridad asociada .a NET, y la garantía de la ejecución administrada de
programas: de nuevo el paradigma del intermediario, ha sido la solución a un
problema de software.
</ARTICULO>
Saludos