Introducción

Antes de entrar en definición de ActiveX, habría que entender lo que es un objeto OLE.

 

Objetos OLE

 

Un objeto OLE (Object Linking and Embedding) significa el estándar de vinculación e incrustación de objetos. OLE es un entorno unificado de servicios basados en objetos con la capacidad de personalizar esos servicios y de ampliar arbitrariamente la arquitectura a través de servicios personalizados, con la finalidad global de permitir una integración rica entre los componentes.

 

OLE proporciona un estándar consistente que permite a los objetos, aplicaciones y componentes ActiveX, comunicarse entre sí con la finalidad de usar el código de los demás. Los objetos no necesitan conocer por anticipado en qué objetos se van a comunicar, ni su código necesita estar escrito en el mismo lenguaje.

 

Las aplicaciones ActiveX están conceptualmente divididas en servidores, objetos que hacen que sus métodos y propiedades estén disponibles para los demás, y clientes, aplicaciones que usan objetos de servidor expuestos, métodos y propiedades. Algunos tipos de servidores, por ejemplo controles ActiveX, pueden disparar eventos que pueden ser después respondidos por el código de un cliente.

 

Comunicación asíncrona y síncrona.

 

No solamente es OLE comunicación entre objetos, la comunicación es también síncrona. La comunicación síncrona implica una comunicación en dos direcciones. La aplicación que llama (el cliente) hace una llamada y espera una respuesta. La aplicación que recibe (el servidor) espera la llamada. Al recibir la llamada, la aplicación que recibe produce una respuesta mientras que la aplicación que llama se encuentra aún en la línea.

Los antiguos estándares de comunicación entre objetos, tales como OLE 1 o DDE, se comunicaban de forma asíncrona. En una comunicación asíncrona, aplicación que llama realiza una llamada sin esperar una respuesta.

 

La comunicación asíncrona entre aplicaciones puede ser problemática. Desde la aplicación servidor, si no hay notificación expresa, no se sabe sí se ha ejecutado la solicitud del cliente. La comunicación puede rebasar el tiempo. La comunicación asíncrona es menos fiable y más difícil de programar que una comunicación síncrona.

 

La interfaz OLE

 

Dado que una parte importante del modelo OLE es que los objetos servidor no tienen por qué estar escritos en el mismo lenguaje que los clientes ni tienen que tener ningún conocimiento anticipado de qué clase de objeto cliente puede llamarlos, los objetos OLE deben aplicar una interfaz estándar.

 

Los objetos OLE pueden tener tantas interfaces como desee su diseñador, agrupadas generalmente por su funcionalidad. Una interfaz determinada mostrará una "tabla de contenido", o índice alfabético, de las funciones que contiene y proporcionará un medio de ejecutar esas funciones.

 

El examinador de objetos utiliza la interfaz expuesta de los objetos ActiveX para mostrar los miembros, propiedades, métodos y eventos, de los componentes o de la aplicación. Los programas de los clientes sólo necesitan utilizar la sintaxis familiar Object.Method y Object.Property para acceder a los miembros de servidor ActiveX. Los eventos que pueden ser disparados por un objeto, como un control ActiveX, se muestran en el marco del controlador del evento en la ventana de código del cliente. El posible agregar código para responder a los eventos disparados por el componente ActiveX según sea apropiado.

 

ActiveX, se puede ver como la evolución de OLE, de la siguiente forma:

OLE + Internet = ActiveX

Controles OLE + Internet = Controles ActiveX

Documentos OLE + Internet = Documentos ActiveX

Modelo de objeto OLE + Internet = Modelo de objetos ActiveX 

 

Definición del objeto ActiveX

 

Un objeto ActiveX se define como el que se adhiere al Modelo de Objetos Componentes (Component Object Model COM) definido por Microsoft.

 

Un objeto que cumpla con este modelo tiene las siguientes características:

 

Un objeto ActiveX está aplicado como código binario, por consiguiente, puede estar escrito en cualquier lenguaje fuente.

 

El objeto está encapsulado en un archivo ejecutable o en una biblioteca de vinculo dinámico. 

 

El objeto contiene datos de dos tipos: datos de presentación, que se requieren para presentar la pantalla o para imprimir, y datos internos. Puede considerar los dos tipos de datos como propiedades que son privadas para el objeto.

 

El objeto contiene también funciones para manipular sus datos.

 

El objeto proporciona una interfaz estándar para que otros objetos se comuniquen con él.

 

El objeto participa en la disposición en formación, proceso de pasar argumentos de funciones y valores de retorno entre procesos y máquinas.

 

Que hace un objeto ActiveX

 

Un objeto ActiveX, esta esperando, sin hacer nada, hasta que es llamado. Hay objetos que esperan a ser llamados como servidores, pero mientras tanto están muy ocupados, quizás como clientes llamando a otros objetos servidor. Pro ejemplo, Word puede ser llamado como servidor por un objeto cliente externo. En general, se espera que los objetos OLE acepten varios protocolos y proporcionen varios servicios:

 

• Se supone que los objetos proporcionan una interfaz para los comandos internos, "automatizan", de forma que los demás objetos puedan hacer que el objeto servidor realice las operaciones especificadas sobre sus datos. De aquí la frase "servidor de automatización OLE". Por ejemplo, un objeto Excel tiene un método que permite que un cliente externo provoque la carga de una hoja de cálculo.

 

 

• Se supone que los objetos OLE aceptan arrastrar y soltar. Si el objeto maneja ventanas, debe responder adecuadamente a los datos u objetos soltados sobre él usando el ratón.

 

 

• Los objetos OLE aceptan la Transferencia uniforme de datos (Uniform Data Transfer, UDT), que es un mecanismo para el manejo del intercambio de estructuras de datos con formato entre aplicaciones. Las transferencias UDT se realizan llevando información del puntero en lugar de los datos mismos, de forma que no es necesario leer en la memoria grandes cantidades de datos.

 

 

• Se supone que los objetos OLE participan en una arquitectura definida OLE llamada almacenamiento estructurado, usando un servicio OLE, los archivos compuestos. Los archivos compuestos definen una forma de compartir el contenido de un archivo entre componentes, usando un mecanismo que podría considerarse como "un sistema de archivos dentro de un sistema de archivos"

 

En el contexto de los documentos compuestos, se supone que los objetos OLE:

 

• Se incrustan ellos mismos de forma adecuada dentro de un documento manejador y presentan sus datos en forma apropiada en la pantalla o en la impresora. Por ejemplo, un documento Word podría contener incrustado un objeto de hoja de cálculo Excel.

 

 

• Mantienen vínculos entre objetos incrustados, comparables al vínculo automático DDE, de forma que pueden ser actualizados automáticamente los datos.

 

 

• Aceptan la activación y la edición "en contexto" en respuesta a las acciones del usuario. Esto significa proporcionar una interfaz de edición visual apropiada en el contexto del manejador. Por ejemplo, un objeto de CorelDRAW incrustado en un documento Word puede ser editado usando las herramientas de Corel.

 

Los objetos OLE proporcionan un objeto interno conocido como apodo, que encapsula un puntero a un objeto y el mecanismo para volver a crear el puntero si es necesario. En términos de DDE, el puntero es una ruta para el objeto vinculado junto con un método para localizar el objeto vinculado, en el caso en que la ruta absoluta llegue a ser imprecisa.

 

 

Reutilización de código

 

 

La idea de reutilizar código es común a casi todos los lenguajes de programación, mediante esta técnica se consiguen importantes ahorros de tiempo en programación, pero a costa de un problema, para usar una clase, por ejemplo en C++, hace falta acceder completamente al código fuente.

 

Con ActiveX no se necesita ningún código fuente. Como el código original se ha convertido en un control ActiveX, es posible utilizarlo sin el apoyo de un programa compatible con ActiveX. Los controles ActiveX ofrecen un marco de reutilización de código, ya que son independientes del lenguaje. Los controles permiten conectar código C++ con Java, el código Java con Visual Basic, Visual Basic con C++ y así sucesivamente.

 

Reutilización en binario

 

Los controles ActiveX pueden conseguir esta independencia del lenguaje, ya que su código se encripta en forma binaria, no como código fuente. Sea cual sea la herramienta de desarrollo utilizada, el resultado será un control ActiveX comprensible como binario por cualquier programa compatible con ActiveX.

 

La independencia del lenguaje no es la única ventaja que se extrae del empleo de código reutilizable en forma binaria. Por ejemplo, después de convertir un algoritmo en un control ActiveX, podrá suministrarse a otros programadores sin necesidad de desvelar el resto del código fuente. Además los algoritmos dejarán de estar limitados a las herramientas de desarrollo. Toda aplicación que se que contemple en sus controles al estándar ActiveX, podrá hacer uso de este código.

 

Contenedores ActiveX

 

Los programas que usan controles ActiveX se llaman contenedores. El contenedor de un control es una aplicación capacitada para el manejo de ActiveX que actúa como soporte de interfaz de usuario para dicho control. Se puede por ejemplo, presentar un botón que, una vez pulsado, envíe un mensaje al control. O también responder a diversos sucesos, o mensajes especiales que se envían desde el control al contenedor. Estos sucesos pueden reclamar un "clic" de ratón, la terminación de una tarea o cualquier otra cosa.

 

El principal contenedor ActiveX existente, es el navegador Web. Un navegador puede mostrar controles ActiveX en una página Web incluso aunque el control provenga de un ordenador remoto.

 

Para obtener un máximo aprovechamiento de la arquitectura ActiveX son necesarios tanto los controles como los contenedores. Los primeros permiten empaquetar código fuente en un objeto único y reutilizable.

 

El problema de la transportabilidad

 

Los controles ActiveX no han sido concebidos para un funcionamiento interplataformas. La arquitectura ActiveX está fuertemente ligada al sistema operativo Microsoft Windows, los controles ActiveX no funcionan bien en otras plataformas. Este problema se agrava más, por el hecho de que los controles ActiveX no dependen solo de la plataforma, sino también del navegador. Con la excepción de Internet Explorer, los navegadores han de trucarse para admitir el manejo de ActiveX.

 

Acceso a archivos

 

Los controles ActiveX pueden acceder a archivos del ordenador cliente. Un control ActiveX podría guardar los resultados de una consulta a una base de datos en el disco duro, como fuente de futuras referencias.

 

El acceso a archivos es una alternativa cómoda, pero también peligrosa. Para paliar este problema, existe una solución. Antes de cargar ningún control ActiveX, el navegador Web lo explora en busca de una secuencia encriptada de octetos. Esta secuencia, o firma digital, es creada en un proceso conocido como firma de código. Si encuentra esta secuencia el navegador podrá determinar quién escribió el código y quién lo distribuyó y, por lo tanto, conocerá la identidad del responsable. Cuando no detecta la secuencia, advierte al usuario que el control puede ser peligroso y le da la opción de no cargarlo.

 

 

Código heredado

 

Los controles ActiveX, ofrecen un soporte muy completo para el código heredado. El proceso de conversión de programas existentes a controles ActiveX es bastante sencillo, y como los controles ActiveX son independientes del lenguaje, no importa que lenguaje se elija para componer la base de codificación.

 

Aparte del código heredado, se pueden recuperar controles heredados. Los controles OLE son totalmente compatibles con ActiveX. En consecuencia, será posible seguir perfeccionando el código de los programas con los últimos controles ActiveX.

 

 

Compilación

 

Cuando se crea un control ActiveX en Visual C++, debe compilarse dicho control en el lenguaje maquina nativo antes de iniciar las fases de pruebas y depuración. Visual C++ consume bastante potencia para traducir el código fuente C++ a lenguaje maquina nativo, por lo que se perderá un tiempo importante esperando a que el código termine de compilarse. Dicho código debe, pues, preprocesarse, analizarse, traducirse, optimizarse, ensamblarse y, finalmente, escribirse en disco.

 

Ejecución

 

Los controles ActiveX se ejecutan directamente en el sistema para el que han sido compilados. La mayoría de los compiladores optimizarán el código ActiveX por la eliminación de código innecesario o redundante.

 

Cargar el control

 

Los controles ActiveX, son perdurables, es decir, cuando se bajan de Internet, el navegador Web guardará en disco una copia del control. Antes de salvar en disco un control ActiveX, el navegador Web lleve a cabo tres comprobaciones (licencia, versión y firma) con el fin de garantizar la seguridad y proteger los derechos de propiedad del mismo.

 

Comprobación de licencia

 

Para evitar el uso sin licencia de los controles ActiveX en las páginas Web se ha incluido un mecanismo especial de protección, según el cual la distribución de los controles se acompaña de una licencia al desarrollador. Con esta licencia, los usuarios reciben permiso para insertar el control en herramientas como Visual Basic, Visual J++ y Visual C++. Si no se dispone de esa licencia, el usuario tan solo podrá visualizar el control dentro de una página Web o en una aplicación existente, nunca modificar su modo de actuar.

 

Interfaces ActiveX

 

Las interfaces ActiveX son colecciones de funciones interrelacionadas. Las interfaces ActiveX no ha sido diseñadas en el ámbito de la POO, y no tienen relación alguna con las clases o la herencia.

 

Funciones binarias

 

Las interfaces activeX, se pueden considerar como funciones ActiveX, pero como funciones a nivel binario.

Las funciones normales, al ser miembros de una clase, sólo existen en código fuente y, por tanto, dejan de ser accesibles una vez que se compilan. En cambio, las interfaces ActiveX se encuentran en el extremo opuesto: sólo pueden llamarse después de haber sido compiladas en forma binaria.

Una vez hecho esto, las funciones ActiveX pasan a estar disponibles para todo el sistema. Cualquier programa compatible con ActiveX, con independencia de cómo haya sido creado (con C++, Java, Visual Basic u otro lenguaje), puede invocar funciones binarias sin necesidad del código fuente. Esta peculiar caracteristica conforma un tipo de programa particular, llamado software de componentes, que ofrece ciertas ventajas con respecto al diseño tradicional orientado a objetos.

 

Uno de los peligros inherentes a las funciones binarias y extendidas a todo el sistema es la posibilidad de que generen conflictos de nombres. Para solucionar este problema, la arquitectura ActiveX marca cada interfaz con un identificador único a escala global. El algoritmo utilizado garantiza su unicidad. Por consiguiente, un programa ActiveX que solicite un identificador correcto siempre accederá a la interfaz adecuada.

 

Otra de la ventaja de usar funciones en interfaces ActiveX, se deriva del protocolo Distributed COM de Microsoft, o DCOM. Con este protocolo los programas ActiveX pueden invocar funciones ubicadas no sólo dentro del sistema sino en cualquier punto de la red. El soporte a las interfaces distribuidas procede de un proceso denominado marshaling (enganche).