La pregunta mas reciente que me han hecho en los meses cercanos, es: ¿Cómo migraría una aplicación que corre en Microsoft Internet Explorer a Microsoft EDGE?, si se preguntan porque resulta interesante esta pregunta, es porque en el pasado Internet Explorer permitía implementar una API con un tipo de objeto llamado ActiveXObject, el cual le daba facultades a la aplicación para interactuar con los recursos del Sistema Operativo, por supuesto estoy hablando de Microsoft Windows, por otro lado permitía el uso de otros scripts como JScript o VBScript, que agregaban otras caracteristicas para ejecutar codigos que aunque podían resultar interesantes, iban amarrando cada vez mas la aplicación a solo funcionar con Internet Explorer, haciendo mas y mas dificil su compatibilidad con otros navegadores que si se apegan a los estándares internacionales.
Tabla de Contenido
¿Qué se podía hacer con ActiveXObject?
Antes de profundizar en alguna solución es importante analizar y entender ¿Qué tipo de funciones se podían hacer con ActiveXObject?, y entonces, seremos capaces de imaginar posibles soluciones.
Bien, partiendo de este punto, listemos algunas de las funciones mas caracteristicas que se solían implementar en esta tecnología.
- Consultar, escribir y/o manipular registros del RegEdit en Windows.
- Obtener datos de la PC como la IP o Versión del SO o Versión del Navegador.
- Buscar e incluso abrir un programa que estuviera instalado en la PC.
- Interactuar con las librerias del sistema operativo o de algún otro programa instalado en el PC
- Manipular/interactuar con dispositivos periféricos conectados al PC
- Manipular/interactuar los folders y archivos contenidos dentro de la PC
- Otros
Todo esto desde una aplicación web, lo cual puede resultar util y hasta interesante, pero sumamente riesgoso, si se analiza desde el punto de seguridad, imaginen que alguien construyera una aplicación con estas capacidades y que por error permitieramos la ejecución de dichas caracteristicas, estaríamos exponiendo nuestras computadoras a la posibilidad de compartir cualquier tipo de recurso a través de una aplicación web.
Cierto que de vista al usuario esto no era tan sencillo, ya que se requería otorgar los permisos correspondientes, ya fuera a través de una acción manual propia del usuario o desde una politica, aún así el riesgo era inminente, y por ello, la comunidad de desarrollo web ha evitado la propagación del uso de este tipo de caracteristicas hasta el punto en que hoy día la versión de navegador mas reciente de Microsoft se ha sumado a estas buenas practicas y ha retirado dicha API del core del navegador, haciendo imposible la ejecución de este tipo de códigos.
Pero entonces ¿Deberán desaparecer por completo este tipo de aplicaciones de manera definitiva?, y la respuesta es: no necesariamente, existen alternativas para brindar una solución a este problema.
Tipos de implementaciones en Microsoft Edge
Cuando estaba revisando información sobre posibles soluciones para este tema, la fuente mas natural que se me ocurrió verificar fue directamente en el sitio oficial de Microsoft, así que resultado de esa consulta encontré 3 posibilidades a considerar, las cuales son:
Yo los invito a revisar los enlaces arriba descritos, según sus necesidades particulares, alguno de ellos puede ser de utilidad, yo personalmente decidí enfocar mis esfuerzos en otro tipo de solución ya que no deseaba hacer demasiados cambios a la aplicación que ya existía, ni buscaba transferir funcionalidad hacia otro tipo de implementación, es posible que no haya comprendido del todo el potencial de dichas alternativas, pero llegue a la conclusión de que estas opciones son mas viables para la creación de una aplicación de cero y no para una migración como es el objetivo de lo que estamos revisando.
Pero que no sea solo mi opinión la que determine el mejor camino para dirigir su solución de acuerdo con sus necesidades particulares. Como quiera que sea la lectura resulta buena y en el futuro creo que me será más útil.
Migración de IE a Edge usando WebSockets
Con la premisa de conservación intacta de la mayor parte del código de la aplicación existente, seguí investigando hasta dar con una tecnología que no es del todo nueva, pero que esta adquiriendo una popularidad recientemente debido a los Chat Bots, si así como lo leen, esta tecnología que esta siendo muy utilizada para otro tipo de solución permite solventar las principales necesidades de funcionalidad y seguridad para reemplazar lo que se hacia en Internet Explorer y que ahora se requiere siga funcionando en Microsoft Edge.
Primero un poco de conocimiento general, los sockets son escuchas que se pueden levantar en una maquina a través desde prácticamente cualquier lenguaje de programación.
En lo que se refiere a los WebSockets, estos de igual forma se pueden implementar sin una dependencia real de la maquina y en prácticamente cualquier PC sea o no un servidor, por ejemplo los WebSocket, se pueden programar con JAVA, .NET, NODEJS y PYTHON, por mencionar algunos lenguajes. Como dije pueden ser colocados en un servidor o en una PC de escritorio, pero ojo, si hay códigos diferentes para cada una de las formas.
En este caso, lo que queremos resolver es la funcionalidad de interactuar con los recursos de la PC, por lo que las recomendaciones irán en ese sentido.
El WebSocket, se puede abrir en prácticamente cualquier puerto disponible de la computadora, y se usa el protocolo WS o WSS, en su modo seguro para interactuar con este tipo de implementaciones, haciendo uso de unas pocas lineas de codigo en JavaScript para su consumo.
Es importante mencionar que esta solución es una aplicación que tiene que ser instalada y ejecutada, en la PC donde se requiere la ejecución del código, por lo que no es tan simple para algún sitio web solo mandar a invocarla, ademas de que tiene su protocolo seguro para hacer que la transacción sea todavía mas confiable encriptando la información desde el navegador y hacia el socket.
Por otro lado al tener un lenguaje de programación como los antes mencionados (JAVA, .NET, PYTHON) y acceso a todas sus APIs, para interactuar con la PC donde se esta ejecutando, las posibilidades se amplían, permitiendo solventar prácticamente todas las necesidades antes mencionadas.
Si bien no es lo mas recomendable, ante la necesidad y dentro de un ambiente controlado, puede ser una solución sumamente adecuada y con muy pocos cambios al aplicativo original.
Dado que yo no tengo un código propio que yo pueda compartir, debido al tipo de implementación que hice, les voy a ahorrar un poco de tiempo y les compartiré los enlaces que utilice resultado de mi investigación, para el diseño de una pequeña POC, con la que se demostró el funcionamiento.
Arquitectura de solución usando WebSocket
Es posible que aún después de haber llegado a este punto alguien siga teniendo dudas con respecto a lo que te he venido comentando, ante esa posible situación, nada mejor que un poco de representación grafica que permita dar un vistazo al papel que juegan las capas dentro de esta propuesta de solución.
La imagen anterior se puede explicar de una forma sencilla, primero la Computadora Personal que corre un sistema operativo Windows, que tiene instalado un navegador Edge, este proceso los objetos DOM a través de HTML, CSS, y JavaScript, a través del cual se puede establecer transacciones de peticiónes y respuestas con JSON, hacia el WebSocket, el cual como ya les había contado responde a través de un puerto WS o WSS, este a su vez procesa el JSON y lo usa para saber cual de las operaciones dentro del WebSocket se desea ejecutar, una vez que esta ha sido completada, el camino es a la inversa, haciendo con ello que la aplicación Web tenga conocimiento del resultado de la operación y con ello continuar sus operaciones.
