Controles ActiveX - Applets Java.

...

Velocidad

En general, las aplicaciones interpretadas (como applets de Java) corren aproximadamente 10 veces más lento que las aplicaciones compiladas (como controles ActiveX). A medida que la velocidad de los procesadores aumenta, esta diferencia podría ser cada vez menos significativa.

Disponibilidad

Para poder desarrollar applets de Java es necesario tener el JDK (Java Developers Kit). Existen también algunos paquetes como el Cafe de Symantec, ó la última versión de C++ de Borland, que incluyó una herramienta de desarrollo para Java.

En términos de disponibilidad, ActiveX ha tomado la delantera, ya que es soportado por Visual Basic 5.0 de Microsoft, Visual C++ 4.2., y Visual J++ 1.1 y versiones superiores. Están disponibles actualmente en el mercado miles de controles ActiveX, incluyendo reproductores "RealAudio" y reproductores de películas. Y los principales vendedores de herramientas Java, incluyendo Borland y Metrowerks han anunciado soporte Java para ActiveX. Además, una aplicación puede crearse en minutos a partir de componentes ActiveX escritos en diferentes lenguajes, y el "Developer Studio" de Microsoft automáticamente cambiará el modo de "debugging" entre los lenguajes componentes a medida que la aplicación se ejecuta.

Seguridad

Java y ActiveX tienen modelos de seguridad radicalmente diferentes.

El modelo de seguridad de Java incluye seguridad intrínseca que protege al usuario de errores que pueden resultar de algún acceso ilegal a memoria. Además, un Manager de Seguridad provee seguridad a nivel de los recursos que restringe, como el acceso a disco y a la red del programa Java. Esto es importante porque el usuario está protegido contra códigos erróneos. El ambiente runtime de Java define el nivel de acceso a los recursos permitido a un programa Java. Actualmente, el acceso a los recursos es ilimitado para las aplicaciones Java y extremadamente limitado para los applets de Java. Ya JDK 1.1 introduce applets firmados digitalmente, por lo que el usuario decide los permisos para el acceso a los recursos extendidos por parte de los applets provenientes de una fuente confiable. La firma digital verifica que el applet viene inalterado desde la fuente, así que si uno confía en JavaSoft y un applet es firmado por JavaSoft, entonces uno puede darle al applet acceso extendido a los recursos. Recordando que la seguridad intrínseca de Java siempre está ahí protegiendo al usuario de muchos errores de programación que podrían llevar al applet a causar daño. Los navegadores futuros permitirán a los applets no confiables cierto acceso extendido a los recursos, por ejemplo, acceso de escritura en un determinado directorio. Este modelo de seguridad significa que los programas Java pueden ser ejecutados y serles permitido acceder a los recursos con seguridad, dependiendo de la confianza en la fuente.

Los controles ActiveX no están sujetos a chequeo intrínseco de seguridad ni chequeos de acceso a los recursos. En cambio, los controles corren con completo acceso a la máquina y sus recursos. El único mecanismo de seguridad es la firma digital, que permite verificar que un control llega inalterado desde la fuente. Para firmar el control, hay que presentarlo a una Autoridad de Certificación (CA) como Verisign, junto con una descripción y el nombre del desarrollador. La Autoridad de Certificación utiliza técnicas de encriptación para generar una firma que verifica el control, el nombre y la descripción. Cuando un navegador recibe un control firmado, éste usa su propia copia de las claves públicas CA para verificar que el control corresponde con la firma. Si es así, entonces se puede asegurar que el control está inalterado.

La falta de control de recursos hace de ActiveX una tecnología muy poderosa para aplicaciones intranet basadas en Windows, pero si un control no realiza un chequeo completo de parámetros puede realizar operaciones arbitrarias en la máquina del usuario, lo que no ocurre con un applet debido a su seguridad intrínseca. Las firmas digitales son una valiosa tecnología si se usan para soportar un ambiente seguro como Java, porque permiten el despliegue seguro de aplicaciones en Internet, con acceso de recursos apropiado en las máquinas clientes.

Capacidad

Si se ejecuta un applet confiable, este tendrá todo el poder y capacidades de cualquier aplicación Java, pero si se ejecuta un applet no firmado digitalmente por una fuente confiable, sus capacidades están restringidas. Java sufre una severa deficiencia en capacidades de multimedia. Los ambientes Java futuros ofrecerán un mayor número de opciones de seguridad para códigos que expandirán las capacidades de los applets hacia las de las aplicaciones nativas. Sin embargo, las API limitadas de Java continuarán siendo un problema. Sin embargo ActiveX tiene todo el poder de una aplicación nativa, que le permite tomar ventaja de poderosas APIs nativas, como DirectX, OpenGL, y QuickDraw3D. Java no ofrece esta capacidad. Las API futuras mejorarán esta situación, pero si se requiere acceso a recursos de bajo nivel del sistema, sólo ActiveX lo provee, aunque es a costa de limitar la aplicación a una sola plataforma.

CONCLUSIONES

Tanto applets de Java como controles ActiveX seguirán desarrollándose en el futuro. Los navegadores líderes Netscape Navigator e Internet Explorer de Microsoft soportarán ambos estándares. Las organizaciones que construyen componentes usando navegadores como contenedores tienen que decidir cual de los dos tecnologías utilizar.

Si un componente debe correr en diferentes tipos de sistemas clientes, y las limitaciones impuestas por sandboxing (el software no toca ningún fichero fuera del contenedor donde se ejecuta) son aceptables o deseables, entonces lo más lógico es construir ese componente como un applet Java. Si, por el contrario, el componente va destinado a sistemas Microsoft, no requiere sandboxing, debe correr tan eficientemente como sea posible y es útil en un rango de contenedores mayor que sólo navegadores Web, entonces, la tecnología a escoger son los controles ActiveX.