Java actualmente está en boca de todos, Java e Intranet son las palabras de moda. Pero, surge la pregunta de si esta es una buena tecnología para desarrollar aplicaciones corporativas. Y la respuesta es afirmativa y voy a proponer argumentos para esa afirmación. En donde la red sea algo crítico, Java facilita tremendamente la vida de la programación corporativa.
Durante años, las grandes empresas se han convencido de que la "red" corporativa es la arteria por donde fluye la sangre que mantiene vivo su negocio. Desde el gran servidor de sus oficinas centrales, hasta los servidores de las delegaciones, las estaciones de trabajo de los programadores y la marabunta de PCs, la información va fluyendo de unos a otros. Para muchas compañías, la Red es la Empresa.
Si esta red no se mantiene sana, los pedidos no llegan, el inventario no se actualiza, el software no se desarrolla adecuadamente, los clientes no están satisfechos y, fundamentalmente, el dinero no entra. La necesidad de diagnosticar y reducir la arterioesclerosis de la red, hace que se estén inyectando continuamente nuevas metodologías que subsanen este grave problema.
¿Es Java la medicina? Está claro que cuando vemos
un cepillo animado limpiando los dientes, cubos moviéndose
en 3-D, o una banda de gatos locos en applets de Java, nos convencemos
de que es el lenguaje idóneo para Internet. Pero, qué
pasa con las aplicaciones corporativas, ¿sería una
buena tecnología allí donde la red es el punto crítico?
Vamos a intentar responder comparando las capacidades de Java
contra la lista de necesidades de la red corporativa.
Hace años, se decía que los programadores pronto desaparecerían. Los generadores automáticos de programas, eliminarían a los generadores humanos y el mundo sería un lugar mejor para vivir. Desafortunadamente, quienes decían esto no tuvieron en cuenta una acelerada demanda de software de calidad para muy diferentes aplicaciones. Sin embargo, la tecnología de objetos pronto vino a intentar facilitar la tarea, adoptando el modelo de "generar parte de un programa", así, generando la parte básica de un programa (los objetos), se podría conectar con otras partes para proporcionar diferentes utilidades al usuario.
El lenguaje C++ es una buena herramienta, pero no cumple totalmente
la premisa. Visual Basic y NextStep, se acercan cada vez más
al poder de los objetos. Java facilita la creación de entornos
de desarrollo-aplicaciones de modo similar, pero además
es flexible, poderoso y efectivo. Los programadores ahora disponen
de herramientas de programación de calidad beta, que apuntan
hacia esa meta, como son el Java WorkShop
de SunSoft, el entorno Java de Borland,
el Café de Symantec, y pronto, herramientas más sofisticadas
como Netcode o FutureTense.
Esto proporciona una gran progresión a los entornos de
desarrollo Java.
Las aplicaciones que se crean en grandes empresas deben ser más efectivas que eficientes; es decir, conseguir que el programa funcione y el trabajo salga adelante es más importante que el que lo haga eficientemente. Esto no es una crítica, es una realidad de la programación corporativa. Al ser un lenguaje más simple que cualquiera de los que ahora están en el cajón de los programadores, Java permite a éstos concentrarse en la mecánica de la aplicación, en vez de pasarse horas y horas incorporando APIs para el control de las ventanas, controlando minuciosamente la memoria, sincronizando los ficheros de cabecera y corrigiendo los agónicos mensajes del linker. Java tiene su propio toolkit para interfaces, maneja por sí mismo la memoria que utilice la aplicación, no permite ficheros de cabecera separados (en aplicaciones puramente Java) y solamente usa enlace dinámico.
Muchas de las implementaciones de Java actuales son puros intérpretes. Los byte-codes son interpretados por el sistema run-time de Java, la Máquina Virtual Java (JVM), sobre el ordenador del usuario. Aunque ya hay ciertos proveedores que ofrecen compiladores nativos Just-In-Time (JIT). Si la Máquina Virtual Java dispone de un compilador instalado, las secciones (clases) del byte-code de la aplicación se compilarán hacia la arquitectura nativa del ordenador del usuario. Los programas Java en ese momento rivalizarán con el rendimiento de programas en C++. Los compiladores JIT no se utilizan en la forma tradicional de un compilador; los programadores no compilan y distribuyen binarios Java a los usuarios. La compilación JIT tiene lugar a partir del byte-code Java, en el sistema del usuario, como una parte (opcional) del entorno run-time local de Java.
Muchas veces, los programadores corporativos, ansiosos por exprimir al máximo la eficiencia de su aplicación, empiezan a hacerlo demasiado pronto en el ciclo de vida de la aplicación. Java permite algunas técnicas innovadoras de optimización. Por ejemplo, Java es inherentemente multithreaded, a la vez que ofrece posibilidades de multithread como la clase Thread y mecanismos muy sencillos de usar de sincronización; Java en sí utiliza threads. Los desarrolladores de compiladores inteligentes pueden utilizar esta característica de Java para lanzar un thread que compruebe la forma en que se está utilizando la aplicación. Más específicamente, este thread podría detectar qué métodos de una clase se están usando con más frecuencia e invocar a sucesivos niveles de optimización en tiempo de ejecución de la aplicación. Cuanto más tiempo esté corriendo la aplicación o el applet, los métodos estarán cada vez más optimizados (Guava de Softway es de este tipo).
Si un compilador JIT está embebido en el entorno run-time
de Java, el programador no se preocupa de hacer que la aplicación
se ejecute óptimamente. Siempre he pensado que en los Sistemas
Operativos tendría que aplicarse esta filosofía;
un optimizador progresivo es un paso más hacia esta idea.
En una empresa de relativo tamaño hay una pléyade diferente de ordenadores. Probablemente nos encontremos con estaciones de trabajo Sun para el desarrollo de software, hordas de PCs para cada empleado, algún Mac en el departamento de documentación, una estación de trabajo HP en administración y una estación SGI en la sala de demos. Desarrollar aplicaciones corporativas para un grupo tan diferente de plataformas en excesivamente complejo y caro. Hasta ahora era complicado convencer a los programadores de cada arquitectura que utilizasen un API común para reducir el coste de las aplicaciones.
Con un entorno run-time de Java portado a cada una de las arquitecturas de las plataformas presentes en la empresa y una buena librería de clases ("packages" en Java), los programadores pueden entenderse y encontrar muy interesante trabajar con Java. Esta posibilidad hará tender a los programadores hacia Java, justo donde otros intentos anteriores con entornos universales (como Galaxy o XVT) han fracasado. Estos APIs eran simplemente inadecuados, no orientados a redes y, verdaderamente, pesados.
Una vez que los programas estén escritos en Java, otro
lado interesante del asunto es que los programadores también
son portables. El grupo de programadores de la empresa puede ahora
enfrentarse a un desarrollo para cualquiera de las plataformas.
La parte del cliente y del servidor de una aplicación estarán
ahora escritas en el mismo lenguaje. Ya no será necesario
tener un grupo que desarrolle en Solaris en del departamento de
I+D, programadores trabajando sobre Visual Basic en el departamento
de documentación y programadores sobre GNU en proyectos
especiales; ahora todos ellos podrán estar juntos y formar
el grupo de software de la empresa.
En contraste con el alto coste de los desarrollos realizados sobre estaciones de trabajo, el coste de creación de una aplicación Java es similar al de desarrollar sobre un PC.
Desarrollar utilizando un software caro para una estación de trabajo (ahora barata) es un problema en muchas empresas. La eficiencia del hardware y el poco coste de mantenimiento de una estación de trabajo Sun, por ejemplo, resulta muy atractivo para las empresas; pero el coste adicional del entorno de desarrollo con C++ es prohibitivo para la gran mayoría de ellas. La llegada de Java e Intranet reducen considerablemente estos costes. Las herramientas Java ya no están en el entorno de precios de millones de pesetas, sino a los niveles confortables de precio de las herramientas de PCs. Y con el crecimiento cada día mayor de la comunidad de desarrolladores de software freeware y shareware que incluso proporcionan el código fuente, los programadores corporativos tienen un amplio campo donde moverse y muchas oportunidades de aprender y muchos recursos a su disposición.
El éxito que Internet ha proporcionado a los equipos de
software corporativos es un regalo. El precio del software es
ahora el mismo para un poderoso equipo corriendo Unix que para
un PC. Incluso Netscape tiene al mismo precio la versión
Unix de su servidor Web SuiteSpot que la versión PC/NT.
Esta es la filosofía de precios que parece ser será
la que se siga con las herramientas basadas en Java.
Un problema bien conocido que ocurre con el software corporativo es la demanda de cuidados y realimentación. Java no es, ciertamente, la cura para la enfermedad del mantenimiento, pero tiene varias características que harán la vida del enfermero más fácil.
Uno de los componentes del JDK es javadoc. Si se usan ciertas convenciones en el código fuente Java (como comenzar un comentario con /** y terminarlo con */), javadoc se puede fácilmente generar páginas HTML con el contenido de esos comentarios, que pueden visualizarse en cualquier navegador. La documentación del API de Java ha sido creada de este modo. Esto hace que el trabajo de documentar el código de nuevas clases Java sea trivial.
Otro gran problema del desarrollador corporativo es la creación y control de makefiles. Leerse un makefile es como estar leyendo la historia de empresa. Normalmente se pasan de programador a programador, quitando la información que no es esencial, siempre que se puede. Esto hace que muchos de los makefiles de las aplicaciones contengan docenas de librerías, una miríada de ficheros de cabecera y ultra-confusos macros. Es como mirar en el estómago de la ballena de Jonás.
Java reduce las dependencia de complejos makefiles drásticamente. Primero, no hay ficheros de cabecera. Java necesita que todo el código fuente de una clase se encuentre en un solo fichero. Java tiene la inteligencia de make en el propio lenguaje para simplificar la compilación de byte-codes. Por ejemplo:
public class pepe { // Fichero: pepe.java
Guitarra flamenca ;
}
public class guitarra { // Fichero: guitarra.java
}
% javac -verbose pepe.java
[parsed pepe.java in 720ms]
[loaded C:\JAVA\BIN\..\classes\java\lang\Object.class in 220ms]
[checking class pepe]
[parsed .\\Guitarra.java in 50ms]
[wrote pepe.class]
[checking class Guitarra]
[wrote .\\Guitarra.class]
[done in 2300ms]
El compilador Java se da cuenta de que necesita compilar el fichero guitarra.java. Ahora vamos a forzarlo a que recompile pepe.java sin cambiar guitarra.java, podremos comprobar que el compilador de byte-code Java no recompila innecesariamente el fichero guitarra.java.
% javac -verbose pepe.java [parsed pepe.java in 440ms] [loaded C:\JAVA\BIN\..\classes\java\lang\Object.class in 160ms] [checking class pepe] [loaded .\\Guitarra.java in 0ms] [wrote pepe.class] [done in 1860ms]
Ahora, si modificamos guitarra.java (añadiendo, por ejemplo, otro miembro a la clase) y compilamos pepe.java, el compilador Java se dará cuenta de que debe recompilar tanto pepe.java como guitarra.java
% javac -verbose pepe.java [parsed pepe.java in 710ms] [loaded C:\JAVA\BIN\..\classes\java\lang\Object.class in 220ms] [checking class pepe] [parsed .\\Guitarra.java in 0ms] [wrote pepe.class] [checking class Guitarra] [wrote .\\Guitarra.class] [done in 2640ms]
En el libro Just Java de Peter van der Linden hay un capítulo
excelente acerca del compilador de Java, si tienes oportunidad,
no dejes de leerlo.
Si la empresa está llena de programadores de C++ con alguna experiencia en el manejo de librería gráficas, aprenderán rápidamente lo esencial de Java. Si el equipo de ingenieros no conoce C++, pero maneja cualquier otro lenguaje de programación orientada a objetos, les llevará pocas semanas dominar la base de Java. Lo que sí que no es cierto es que haya que aprender C++ antes de aprender Java.
Si los ingenieros de la empresa no conocen ningún lenguaje
orientado a objetos, sí que tienen que aprender los fundamentos
de esta tecnología antes de nada, y luego aplicarlos a
la programación con Java. El análisis y diseño
orientado a objetos debe ser comprendido antes de intentar nada
con Java. Los programadores de Java sin un fondo de conocimientos
de OOA/D producirán código pobre. Además,
los libros sobre Java crecen como la espuma, ya hay más
de 25 publicados, y si buscas "Progamming in Java" en
la Red, encontrarás 312 Web sites, y 30 más dedicados
a "Learning Java". Y si esto, evidentemente, no es el
sustituto de un instructor humano, hay ya varias empresas que
ofrecen enseñanza de Java, entre ellas, Sun.
En base a los argumentos que acabamos de exponer, ¿podría
una empresa utilizar Java para sus aplicaciones críticas?
En este instante, sería suficiente un acercamiento a Java.
Porque más importante que la elección de Java o
cualquier otro lenguaje de programación es un buen diseño
de la arquitectura de la aplicación. Diseñar la
aplicación para que esté distribuida entre servidores
y clientes, y la línea de partida debe ser el diseño
modular.
Algunas sugerencias para adoptar Java como tecnología corporativa, serían:
Intranet está creciendo actualmente más rápido
que Internet. Las organizaciones corporativas están adoptando
la metodología Internet para proporcionar soluciones a
sus usuarios y clientes. Java tiene todas las cartas para ser
una herramienta de inestimable valor en el desarrollo de aplicaciones
corporativas.