Permíteme explicar a DCOM, aunque para esto tengo que hacer algo de
historia.

Todo empezó por las quejas de los usuarios del DOS de no poder combinar el
potencial de varios programas. Cada programa se apropia de la máquina y no
hay oportunidad de ejecutar ninguna otra tarea a la vez. Esto es lo que se
conoce como modo Real.

Ante ello, se implantó un emulador para poder (por principio de cuentas)
implantar tareas múltiples a DOS (aunque previo a ello se estaba creando un
poderoso Sistema Operativo que sería *EL* sistema operativo. Su nombre lo
desenmascara: Operating System/2 [OS/2]). Este emulador es una interfaz
gráfica que se ejecuta sobre DOS y que emula la multitarea mediante la
cooperación de las aplicaciones: Windows.

Una vez que se consiguió la multitarea, se requería el dar la posibilidad de
compartir la funcionalidad entre aplicaciones. Ello empezó a dar forma a
diferentes metodologías y técnicas como DDE y OLE. DDE permite comunicarse
con otra aplicación de manera muy básica. Es difícil de controlar y no se
puede aprovechar a cabalidad la funcionalidad de la aplicación origen.

El segundo esfuerzo, OLE, permite aprovechar en mayor medida la
funcionalidad propia de la aplicación, no obstante toda su serie de
apuntadores y referencias debían estar incrustadas en la aplicación de
destino. Con esto se complicaban las llamadas a la funcionalidad y las
aplicaciones que utilizaban OLE crecían de manera desmedida.

OLE2 redujo en gran medida esta situación. Ya no era necesario incrustar
todas las referencias a la aplicación requerida, sino que sólo era necesario
invocarla. Ello trajo severos problemas de programación a sus diseñadores
dado que no existía una tabla que pudiera indicar de inmediato si la
aplicación requerida existía en el sistema y su ubicación. Esta situación
obligaba a que las referencias a tales aplicaciones se agregaran en el
archivo WIN.INI o SYSTEM.INI, lo que traía consigo la generación de
enoooooooormes archivos de este tipo que, con el paso del tiempo, hacía
prohibitiva su depuración.

Con Windows 95 la circunstancia se allanó. Gracias a las técnicas aplicadas
a OS/2 (Sistema Operativo que se estaba creando entre Microsoft e IBM a
mediados/finales de los años ochenta), y que luego del divorcio de IBM y
Microsoft, este último aprovechara para cambiarle la interfaz y lo
presentara como Windows NT (cuyo kernel o núcleo es básicamente OS/2), se
agregó el concepto de Base de datos de Registro o Registry.

Así, el nuevo OLE2 pudo funcionar de manera más fluida, y mejoró el panorama
de la comunicación entre aplicaciones y objetos de Windows. Al mejorarse el
lenguaje de intercomunicación entre objetos y sacar de contexto el
significado de las siglas OLE (vinculación e incrustación de objetos), se
creó una nueva sigla que fue el COM (Modelo de objetos basado en
componentes), lo que da una idea de su funcionamiento: Todo en Windows es un
componente. Curiosamente la línea que separa a un objeto de un componente no
está bien definida, de tal suerte que podríamos concluir a primera vista que
un componente es un objeto, y viceversa.

COM, por lo tanto, se convirtió en el modelo de programación para Windows, y
ello facilitó el desarrollo de nuevas tecnologías como los controles OLE,
luego conocidos como ActiveX, entre otras cosas. Cualquier cosa que
instalases en Windows y que cuente con un GUID (Identificador único) puedes
utilizarla como componente.

No obstante, los requerimientos han ido subiendo conforme pasa el tiempo.
Aunque la ventaja de COM es que puedas aprovechar la funcionalidad de
cualquier aplicación u objeto que se encuentre en tu sistema, la desventaja,
a su vez, es precisamente esa: el objeto debe estar en *TU* sistema. ¿Qué
sucedía si tu aplicación requiriese los servicios de Word en una máquina que
no tenga a Word instalado? Simple, tu aplicación falla.

Bajo la base de que las redes cada vez más se han convertido en el estándar
en una multitudinaria presencia de computadoras, Microsoft implantó un nuevo
concepto: el poder utilizar un componente sin que esté físicamente en tu
máquina. A esto se le llamó COM Distribuido o Modelo de objetos basado en
componentes distribuidos. ¿Cómo lograrlo? Básicamente es sencillo: La
aplicación que ejecutes debe contar con un GUID, hasta aquí no hay problema.
Debes indicar dónde se encuentra la aplicación (aquí estableces el nombre de
la máquina que la contiene) y, luego de ello, ejecutar tus instrucciones
como lo harías con cualquier componente COM y contar con alguna licencia
para su uso de este modo.

Así, ya no necesitas que el objeto de marras se encuentre en tu máquina
instalado. Conque se encuentre en un servidor de objetos COM con ello lo
podrás ejecutar. Incluso, esto puede traer grandes ventajas: Si necesitas
hacer cambios a cierta funcionalidad que hayas creado en algún DLL, por
ejemplo, el cambio lo harás en uno sólo (el que está en el servidor) y te
evitarás la pena de hacer instalaciones del objeto en cada máquina. ¿Y los
clientes? Ni siquiera se enteraron del cambio.

Básicamente, esto es lo que define el concepto de DCOM. Espero que sea útil
para tus (sus) próximas aplicaciones.

¡SALUDOS!
Tron.BAS