Sunday, April 13, 2014

¿Cuándo no usar Java?



Yo sé que Java prometía ser un lenguaje casi universal, pues parecía cumplir con la expectativa: escríbase una vez y córrase en cuanta plataforma halle. Todo esto es factible porque Java trabaja sobre una máquina virtual y entonces no hay que escribir un compilador para cada plataforma. Se cambia esta ingrata tarea por la de escribir una máquina virtual lo cual, parece ser, es mucho más fácil de hacer. De hecho los emuladores son una solución económica a muchísimos problemas de compatibilidad y el software actualmente tiene el suficiente nivel de abstracción para lograr este cometido.

Java, supuestamente, funciona en algo que se llama un "sandbox", un arenero, una analogía para indicar que lo que corre en el arenero no puede salir de ahí y por ende, los virus son imposibles. Sin embargo, hay reportes de posibles virus como el "Java.Trojan.Exploit.Bytverify.Q", el cual, se dice, aprovecha la vulnerabilidad de Java Runtime Environment para ejecutar código malicioso. El peligro, afirman, acecha en los 'applets' de Java que se integran en las páginas web. A mí no me queda estrictamente claro cómo es esto posible de acuerdo a la definición de seguridad de Java, pero evidentemente no faltará quien haya encontrado una manera de brincarse las trabas que originalmente pone el sistema.

Y la verdad es que Java suena como una muy buena idea y tiene montones de virtudes que no hay que despreciar, amén de que hoy en día hay muchísimas bibliotecas de funciones para todos los gustos y necesidades. Es increíble la cantidad de gente que ha escrito código y rutinas para Java. No es un asunto que deberíamos despreciar.

Sin embargo, el problema es el tipo de aplicaciones y programas que se pueden hacer con Java. En muchos casos, queda claro que Java es una buena opción, pero hay un caso interesante en donde me pone a dudar el usar Java. Se trata cuando las aplicaciones por escribir tienen que ver con sistemas que inherentemente buscan ser seguros. Hablamos de los bancos o bien del SAT, en donde los usuarios (con eso de la factura electrónica), están mucho más involucrados para hacer todo el asunto de sus impuestos vía una página web.

Y si vamos a la experiencia práctica, ocurren una serie de factores que me ha tocado ver de primera mano en el uso de Java y particularmente en el SAT (Servicio de Administración Tributaria). Por ejemplo, si como yo, no se recuerda la clave (contraseña) con la que se definió la FIEL (Firma Electrónica Avanzada), está perdido, porque no podrá facturar electrónicamente. La solución es relativamente simple pero implica ir a la oficina local del SAT para pedir una nueva firma electrónica avanzada. No hay que llevar más que una identificación y un USB o disco compacto para que le graben la información. Curiosamente para ello se puede bajar un programa del sitio del SAT para generar un archivo con extensión ".req" y con él, al ir a la oficina del SAT, le generarán los archivos ".key" y ".cer". Pero oh, uno descarga el archivo y cuando lo quiere ejecutar en el navegador, Java se niega a hacerlo.

Y esto es un solo de los detalles. Otro es el acceso a la información de cada usuario que factura electrónicamente. Por una parte, el manejo de bases de datos parece ser una cuestión crítica y resulta que al hacer una factura nueva, a veces el registro tarda hasta 72 horas en generarse. ¿Tantas horas? ¿Por qué? ¿No debería ser inmediato? ¿Dónde está el cuello de botella? ¿En el manejador de bases de datos usado? Misterio.

Y no quiero exagerar, pero el sistema simplificado de facturación electrónica es malísimo, mal explicado, lento, en donde muchas veces no funciona si uno usa Chrome, Firefox o el inútil pero favorito del SAT, el Internet Explorer. En ocasiones no se sabe qué está pasando porque aparece un símbolo como que el sistema está cargando algo pero no pasa nada en la pantalla en un buen rato. Sigo sin entender muy bien qué software es el responsable de todas estas dificultades.

Si a mí me hubiesen preguntado cómo hacer un sistema de esta naturaleza, hubiese elegido otra opción. Mi enfoque hubiese sido hacer programas clientes para las diferentes plataformas, los cuales pudiesen acceder a las bases de datos de los usuarios en particular. Por una parte, los sistemas tenderían a ser más ágiles, porque solamente se mandarían y se recibirían los datos, sin necesidad de mandar toda la parafernalia que significa por ejemplo, crear la factura electrónica en línea. De hecho, éste es el enfoque de algunos sitios web donde interactúan con el usuario. El sistema en donde se ven sus ventajas es por ejemplo el Internet Chess Club - ICC, un sitio web donde se puede jugar ajedrez en línea. A diferencia de Yahoo, por ejemplo, que su "club de ajedrez" funciona usando un programa que corre en Java en el navegador, el ICC corre un cliente en la plataforma de cada usuario y solamente manda la información relevante de las partidas. La diferencia en el desempeño de Yahoo contra el del ICC es evidente: el segundo supera en agilidad y precisión al sistema escrito en Java.

Mi opinión sobre todo este asunto de usar Java para estos sitios de -digamos- misión crítica [1] no es la mejor. Quizás lo que ocurre es que todo esto de la factura electrónica va evolucionando y por ende, hallamos las dificultades normales porque aún estamos aprendiendo a hacer estas cosas.  No obstante esta argumentación, me queda claro que en este país hay suficiente masa crítica de neuronas que pudo haber llevado a una solución mucho, pero mucho más eficiente en el SAT, y sin necesidad de Java.


___
[1] Podemos entender por sistemas de misión crítica a aquellos servidores que ejecutan aplicaciones esenciales que, si fallan, tienen un impacto significativo en el funcionamiento de cualquier empresa, organización o institución que dependa de su información. (http://www.datacenterdynamics.es/focus/archive/2011/12/%C2%BFqu%C3%A9-es-el-c%C3%B3mputo-de-misi%C3%B3n-cr%C3%ADtica)


6 comments:

markuz said...

Evítelo Java cuanto sea posible

Manuel Garcia Sanchez said...

El titulo debería ser "Cuando no usar Applets" (nunca diría yo, si acaso para bajar rolas del youtube).
El problema del SAT no es Java. Yo he trabajado con cientos de aplicaciones de misión critica que usan Java y son invisibles precisamente porque nadie se queja de ellos. El SAT fundamentalmente adolece de dos catastrofes: El primero y causa de la lentitud de sus tramites es un carisimo pedazo de basura llamado PeopleSoft. El segundo es pretender blindar sus formularios por medio de Applets.

Jesús said...

Yo me topé con otro problema. En Mac el sistema de facturación no sirve porque requiere una versión de Java que aún no existe paraesta plataforma. Entonces la famosa portabilidad ni siquiera existe.

Ivan Chavero said...

Lo más apropiado para el ejemplo del SAT sería hacer un API web basada en servicios REST que permitiera crear diferentes aplicaciones alrededor de esta.

Carlos Alvarado said...

Hasta donde me quedé, Indra Company (empresa española) tenía el contrato más grande con el SAT, aunque no es la única firma de consultoría metida en esos rollos.

Java para un sistema tan pesado de nivel nacional se me hace una barbaridad, si van a cobrar las perlas de la Virgen por los desarrollos que hacen, por lo menos háganlos bien.

El problema podría estar en la configuración del middleware, del cual solamente conozco IBM WebSphere que justamente corre sobre Java, Java scripts, XML y HTML con bases DB2, Oracle, SQL etc.

También habría que ver si las bases están bien normalizadas, si el enfoque es el correcto, en pocas palabras si el IT Architect hizo bien su trabajo (créeme Morsa, he trabajado por años en la consultoría y ves a cada tipo que no sabe nada, independientemente de ser titulado o no).

Creo que el principal problema del caso es que los ingenieros en computación se meten a hacer trabajo de programación y de informática, cuando ellos deberían andar desarrollando micro controladores en Intel, por ejemplo; las carreras de computación en México están mal enfocadas en general.

Chochos said...

En resumen, lo que ya todos sabemos:

1. No hagas applets.
2. No hagas aplicaciones de escritorio en Java.