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 vínculo 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).