Rerum Varium

lunes, diciembre 12, 2005

OLE, COM, ActiveX sin remplazo en el campo de juego  

COM Para la época de Windows 3.0, una de las características que mejor vendieron el sistema operativo era la de poder incorporar "partes" de una aplicación en otra (digamos, por ejemplo, una planilla de Excel dentro de un informe creado con Word). Eso era OLE y era un desórden basado en conversaciones sobre mensajes Windows (DDE). Había que cambiar OLE desde su fundamento y Microsoft contrató a un grupo de arquitectos de software, mayormente ingleses. En Windows World 1994 (no me canso de contarlo), en Costa Salguero, tuve el gran honor de asistir a la conferencia del mismísimo Kraig Brockschmidt sobre COM. El autor de "Inside OLE 2" y gran arquitecto de COM estuvo clarísimo, chistoso y lo que mostró revolucionó mi forma de pensar el software de ahí en adelante. También dio una cachetada a los porteños presentándose no sólo sin corbata, sino calzado con sandalias (¡!). COM tenía la enorme ventaja de ser un concepto extremadamente simple. Si bien algunas de las interfaces, se puede decir, terminaron con demasiados miembros o nombres no muy buenos, la idea era redonda. Hasta que hubo que incorporar a Visual Basic. Para acomodar el entonces magro intérprete de VB, inventaron un modo para encontrar y llamar métodos por nombre en una interfaz única por objeto llamada IDispatch. El nombre que dieron al bicho fue "OLE Automation" y encima le hicieron propaganda sobre la supuesta ventaja de no tener que distribuir una biblioteca de tipos. Unos años después nos mandaron a los instructores de cursos oficiales a hacer entender que (una vez que VB pudo leer bibliotecas de tipo) hay que mantenerse lo más lejos posible del "late binding" (que es lo mismo que OLE Automation, pero el nombre nos indica que hay que odiarlo en vez de amarlo, viene a ser como "Anakin Skywalker" transformado a "Darth Vader"). En 1996 Microsoft decidió pagar su antigua deuda de manejo de transacciones y escalabilidad y lo hizo con la técnica de "intercepción", poniendo un programa en medio entre un cliente y un servidor COM. Pronto encontraron más usos, a parte de las transacciones, y completaron la idea de COM+ (COM con servicios basados en intercepción de llamadas). Para ese momento ya existía DCOM (prometido desde el inicio con COM), tristemente basado en un viejo RPC con criterios caprichosos de seguridad, tales como elegir un puerto al azar dentro de un rango (¿seguridad?). Un poco después, MS comenzó a trabajar sobre la plataforma .NET y a hacer público que dejaría de lado COM. Para ese momento Kraig había dejado la programación para dedicarse a la enseñanza de un antiguo instrumento de música ritual (más información en su libro al respecto). La plataforma .NET ofrece gran cantidad de información entre objetos y un conjunto de interfaces conocidos (ComponentModel) para utilizar partes entre sí. Sin embargo ¿en sus años de existencia, ha cumplido siquiera con la premisa de vincular e incrustar objetos entre aplicaciones? Todavía no he visto ningún paquete de aplicaciones de oficina que soporte esa operación desde .NET. COM Kraig Brockschmidt