Beneficios del uso de JAVA en las aplicaciones modernas de Bibliotecas

Maryvonne Enjolras
Innovative Interfaces Inc. ( www.iii.com y www.sls.se)
maryvonne@medusa.es

 

Resumen.- En este artículo se comienza describiendo Java, a la vez un lenguaje de programación y un entorno para la ejecución de programas, así como su historia y sus perspectivas de futuro. Se explican a continuación las cualidades principales de Java que le confieren toda su potencia: universalidad y transportabilidad, sencillez, orientación a objetos, seguridad extrema y diseño específico para computación en red. Se describen asimismo los beneficios que estas propiedades implican cuando se emplea Java en el desarrollo de aplicaciones para Bibliotecas: las aplicaciones pueden funcionar directamente en cualquier máquina y bajo cualquier sistema operativo, así como a través de Internet y de intranets; se pueden desarrollar, adaptar y mejorar rápidamente; son seguras, robustas y fiables; son fáciles de distribuir y de personalizar; y posibilitan una nueva arquitectura cliente/servidor basada en thin clients, que consisten esencialmente en un navegador web, lo que supone para las Bibliotecas menores costes de mantenimiento y apoyo. Se pone como ejemplo de este tipo de aplicaciones el sistema INNOPAC Millennium de gestión de Bibliotecas.

Palabras claves: applet, arquitectura cliente/servidor, Internet, Java, lenguaje de programación, máquina virtual, navegador, orientación a objetos, sistema de gestión de Bibliotecas, thin client.

 

 

Plan del artículo

I.- Introducción

I.1.- Definición de Java

I.2.- Orígenes y evolución de Java

I.3.- Perspectivas de futuro

II.- Java: Descripción y cualidades

II.1.- La máquina virtual —ó VM— de Java

II.2.- Cualidades principales de Java

III.- Beneficios del uso de Java en las aplicaciones de Bibliotecas

III.1.- Beneficios directos derivados de las cualidades de Java

III.2.- Nuevas posibilidades específicas de diseño de aplicaciones. La arquitectura cliente/servidor de tipo thin client

III.3.- Un caso particular: INNOPAC Millennium

Referencias

 

 

I.- INTRODUCCION

El objetivo de este artículo es, en primer lugar, el de exponer los fundamentos de Java, para comprender la revolución que este nuevo lenguaje ha supuesto tanto en Internet como en el mundo de la programación; y en segundo lugar, el de entender los beneficios que esta revolución puede reportar a las Bibliotecas. La exposición, que va dirigida principalmente a bibliotecarios no expertos en programación, pretende establecer los fundamentos teóricos sobre los cuales se asientan los beneficios de Java para las aplicaciones de Bibliotecas.

 

I.1.- Definición de Java

En un primer nivel, Java es un lenguaje de programación de propósito general, orientado a objetos, que fue introducido por Sun Microsystems en 1995, y diseñado en principio para el ambiente distribuido de Internet. Pero lo que hace de Java un concepto diferente es que, en un segundo nivel, es también un entorno para la ejecución de programas, englobado en la llamada máquina virtual de Java. Este entorno es un software que permite que las aplicaciones escritas en Java se ejecuten en cualquier ordenador, independientemente del sistema operativo y de la configuración de hardware utilizados.

Antes de explicar conceptos tales como máquina virtual u orientación a objetos en Java, un repaso a la historia de Java será muy esclarecedor para comprender su filosofía.

 

I.2.- Orígenes y evolución de Java (ver [1], [2] y [4] para más detalles)

Los orígenes de Java se remontan al año 1990, en que un equipo de Sun Microsystems dirigido por James Gosling estaba desarrollando software para dispositivos electrónicos de consumo, es decir, para los chips de objetos tales como lavadoras o equipos de música: estos microprocesadores deben programarse para determinadas funciones, pero los fabricantes cambian cada poco los chips a modelos más potentes y baratos, lo que obliga a reprogramarlos cada vez con nuevo software adaptado a ellos, que debe recompilarse. Se hizo necesario desarrollar un nuevo lenguaje de programación que permitiera escribir programas que funcionaran en cualquier tipo de plataforma, sin necesidad de efectuar modificaciones cada vez que se cambiara el modelo de chip (como había que hacer con C ó C++). Al mismo tiempo, el nuevo lenguaje debía ser capaz de crear programas pequeños y rápidos (pues este tipo de chips no tienen gran capacidad de proceso), a la par que robustos y fiables (un fallo en el software puede implicar la sustitución de un elemento importante del electrodoméstico). Así nació el lenguaje de programación Oak ("roble"), lanzado en enero de 1991.

En 1993 se produce en Internet (hasta entonces limitada al ámbito académico) la creación de la denominada World Wide Web (www) y del primer navegador (Mosaic), que permite acercar dicha red a multitud de empresas y de usuarios particulares. Pronto se advierte la necesidad de instrumentos que permitan la interactividad de los usuarios con las páginas web, lo que propicia la aparición del estándar CGI (Common Gateway Interface): éste define los procedimientos utilizables para acceder desde una página web a un programa que reside y se ejecuta en el servidor web (en general, a través de un formulario). El estándar CGI tiene una utilidad limitada, pues implica un gran número de conexiones que ralentizan las operaciones, además de sobrecargar el servidor. Así, en 1994, el equipo de Gosling, tras haber implementado Oak para un fallido proyecto de televisión interactiva, se percata de la potencialidad de su lenguaje para mejorar la interactividad de las páginas web en Internet, y decide implementarlo en esa dirección. De este modo, Oak se convierte en un nuevo lenguaje de programación, al que se llamará Java ("café hecho a la europea", en inglés de California), y el cual se lanza en mayo de 1995, junto con una versión preliminar de un navegador llamado HotJava ("café caliente"): con el nuevo lenguaje y el nuevo navegador, Sun aborda el problema de la interactividad desde un nuevo enfoque.

Este enfoque consiste en introducir como elementos de las páginas web los llamados applets, o "programitas" escritos en Java. El navegador carga los applets junto con el resto de la página, y una vez cargados se ejecutan en el ordenador del usuario, visualizándose el resultado en la pantalla del navegador. La filosofía en la programación de los applets debe ser la misma que la que presidía la programación de los chips de los electrodomésticos: los programas deben ser pequeños (para que se carguen en poco tiempo) y rápidos (para que se visualicen en la página web sin demoras), a la par que robustos y fiables (son inadmisibles errores o fallos del applet que pudieran modificar los ficheros del usuario o bloquear su sistema operativo); y sobre todo: han de funcionar en cualquier tipo de plataforma, con cualquier sistema operativo bajo el que funcione el navegador. El lenguaje y la plataforma Java permiten todo ello.

El hecho crucial para el éxito fulminante de Java fue la inclusión de la máquina virtual de Java en la versión 2.0 de Netscape Navigator (el navegador de Netscape Communications) bajo licencia de Sun, en septiembre de 1995. Poco después, deciden licenciar Java otras grandes compañías como IBM, Symantec o Microsoft (que integraría la máquina virtual en su navegador Internet Explorer).

Sun distribuye el primer entorno de programación en Java (Java Development Kit ) en 1996, y entre 1996 y 1997 mejora drásticamente Java como lenguaje de programación, al incluir facilidades de impresión, el estándar JDBC de acceso a bases de datos, así como el estándar JavaBeans ("granos de café"): éste potencia el carácter de lenguaje orientado a objetos de Java, al tiempo que proporciona un entorno visual de programación que facilita y simplifica el desarrollo del software escrito en Java. De este modo, Java se convierte en un poderoso entorno de programación y de ejecución de programas para producir no sólo applets aislados para páginas web, sino también verdaderas aplicaciones de interés comercial, comparables a las programadas hasta ahora en otros lenguajes, pero con las ventajas mencionadas de independencia de plataforma (transportabilidad), robustez y fiabilidad de que gozaba el primitivo lenguaje Oak, así como de adaptación a la computación en red que ya tenía Java cuando irrumpió en Internet.

 

I.3.- Perspectivas de futuro

A principios de 1998 se calculaba en 500.000 el número de programadores que usaban software registrado para el desarrollo de programas en Java de manera regular, aproximadamente el doble que en 1996. La cuarta parte de dichos programadores (unos 125.000) se consideran a sí mismos como "del núcleo duro" (fuente: IDC Research, citado por [1]). Esto da una idea de la rapídisima expansión de Java. Además, la mayoría de las empresas de software ha adoptado Java como plataforma de desarrollo estratégico, y muchas están ya programando aplicaciones en Java.

Por otro lado, JavaSoft, la división de software de Sun dedicada a Java (ver su página web [9]), publicará en breve la nueva versión del Java Development Kit, la 1.2, la cual permitirá a los programadores diseñar interfaces de usuario más ricas que las posibles hasta ahora, con mayores capacidades gráficas y de manipulación de objetos multimedia; y que incluirá una nueva máquina virtual para incrementar la rapidez de ejecución de los programas escritos en Java, así como nuevas herramientas que faciliten el trabajo de los programadores. De esta manera, se prevé que las aplicaciones en Java sean cada vez más rápidas, fiables y sencillas de escribir.

Por todo esto, no parece arriesgado aventurar que Java será pronto, si no el estándar, sí al menos una de las grandes referencias en programación. La propia Sun está empeñada en ello, y de hecho tomó la iniciativa de solicitar a la ISO —International Standards Organization— que sus especificaciones sobre Java se reconozcan como una norma oficial disponible públicamente.

 

 

II.- JAVA: DESCRIPCION Y CUALIDADES

 

II.1.- La máquina virtual —ó VM— de Java

II.1.1.- Lenguajes compilados e interpretados. Un lenguaje de programación es un conjunto de instrucciones, y una serie de esas instrucciones se dice que forma el código fuente de un programa. Para que un ordenador entienda un programa hay que traducir el código fuente a código máquina; según el lenguaje de programación empleado, esto se puede hacer de dos maneras:

El código fuente se traduce a código máquina completamente antes de la ejecución del programa, mediante un proceso llamado compilación, realizado por un programa llamado compilador. Se dice que el lenguaje de programación es un lenguaje compilado.

La traducción se realiza en el mismo momento de la ejecución, mediante un proceso llamado interpretación, en el que un programa llamado intérprete lee las líneas del código fuente y las va traduciendo y ejecutando una a una. El lenguaje se dice entonces que es interpretado.

Lógicamente, un programa compilado se ejecuta más deprisa que uno interpretado, pues el compilador ha producido previamente todo el código máquina necesario, y normalmente ha llevado a cabo un proceso de optimización. Como contrapartida, es muchísimo más fácil escribir un intérprete que un compilador, lo que permite disponer de intérpretes en una amplia variedad de entornos, incluidas máquinas de reducidas prestaciones. Esto hace que los lenguajes interpretados estén presentes en más plataformas.

En el caso de Java, se trataba de conseguir tanto la eficiencia de los lenguajes compilados como la universalidad de los lenguajes interpretados. Desde el punto de vista de las prestaciones, los requisitos exigidos al lenguaje hacían pensar en la utilización de un compilador: pero esto implicaba la pérdida de universalidad de las aplicaciones, pues la generación de código máquina para un ordenador particular hace necesario adaptar y recompilar las aplicaciones para cada plataforma existente, y para todas las futuras. De modo que se integraron las dos filosofías:

 

II.1.2.- Java: entre compilación e interpretación. Se decidió que los programas escritos en Java debían sufrir una compilación como paso previo a su ejecución. Sin embargo, el resultado de la compilación no es un conjunto de instrucciones comprensibles por un cierto microprocesador, sino una representación binaria genérica, llamada byte codes. Se diseñó una máquina ficticia, con un juego de instrucciones asociado, que entendiera los byte codes, como lo haría un microprocesador real, y se la llamó la máquina virtual de Java (abreviadamente: VM, por virtual machine), pues no existe ningún microprocesador que utilice el juego de instrucciones mencionado, sino que se trata de una pieza de software.

La función del compilador de Java es por tanto producir byte codes, o código para la VM. Así se consigue: generar un código binario compacto y eficiente; aislarlo de cualquier máquina particular; y definir perfectamente el comportamiento del lenguaje. En efecto, la VM está diseñada para ajustarse exactamente a la sintaxis y a la semántica de Java: p.ej, algunas de las características de la VM están relacionadas directamente con la estructura de datos en Java, lo que permite fijar ciertos parámetros para la representación de los mismos. (Esos parámetros, sin embargo, varían entre los distintos microprocesadores reales, lo que hace que con lenguajes de programación tradicionales haya que cambiar el código fuente cada vez que se quiere ejecutar un programa en diferentes máquinas.)

Para ejecutar Java en ordenadores reales, la VM se implementa en cada plataforma como software, para que funcione en tanto que intérprete de los byte codes: en vez de ir leyendo cada línea del código fuente, como haría un intérprete tradicional, la VM va examinando cada uno de los byte codes compilados previamente, y los ejecuta en el ordenador donde reside el intérprete. Así, el código Java compilado (los byte codes) puede ejecutarse en cualquier plataforma que disponga de un intérprete de Java, pues las características de la máquina virtual son siempre las mismas.

 

II.1.3.- Compilador just-in-time en la VM de Java. La interpretación de los byte codes en un ordenador no puede resultar tan rápida como la ejecución de un programa escrito en un lenguaje compilado para ese ordenador. Para paliar en buena medida la mayor lentitud de Java con respecto a los lenguajes compilados, se han ideado dos soluciones. La primera es la adopción de la técnica de compilación just-in-time por la VM: cuando ésta va interpretando los byte codes, va almacenando el código máquina resultante, de modo que cuando el flujo de ejecución del programa obliga a volver sobre una parte que ya ha sido procesada, no es necesario volver a interpretar los byte codes, sino que basta con reutilizar la secuencia de código memorizada. Esto da resultados espectaculares en trozos de código que utilicen a fondo la capacidad computacional del microprocesador, como es el caso de los cálculos de todo tipo.

[La segunda solución es la fabricación de chips específicos para Java, esto es, microprocesadores cuyas características y juegos de instrucciones coinciden con los de la VM de Java. Esto ha dado lugar a un tipo especial de "ordenadores de red" ó NCs (network computers) de los que se hablará más adelante: véase §III.2.2.]

 

II.2.- Cualidades principales de Java

II.2.1.- Universalidad. Aunque hemos dicho que un programa interpretado no es en principio tan rápido como un programa equivalente compilado, las prestaciones de Java son sin embargo muchísimo mejores que las de cualquier lenguaje interpretado. Este hecho, junto con la sencillez de programación en Java (a la que nos referiremos luego) ha propiciado que se hayan escrito intérpretes de pequeño tamaño adaptados a prácticamente cualquier plataforma, desde mainframes y ordenadores personales (con cualquier sistema operativo: Windows, Macintosh OS, Unix,...) hasta dispositivos electrónicos de bajo coste. Además, la universalidad de los byte codes hacen de Java el lenguaje idóneo para desarrollar aplicaciones para Internet. De hecho, la mayor parte de los navegadores (Netscape Navigator, Internet Explorer, HotJava) integran máquinas virtuales, y por tanto intérpretes de Java, lo que hace posible acceder automáticamente a los applets presentes en las páginas web. De nuevo la sencillez de Java hace que esta integración no reduzca en absoluto las prestaciones de los navegadores, permitiendo además la ejecución rápida y simultánea de gran cantidad de applets.

También se suele hacer referencia a la universalidad de Java con términos equivalentes como transportabilidad, o independencia de plataforma, pues para ejecutar un programa basta compilarlo una sola vez: a partir de entonces, se puede hacer correr en cualquier máquina que tenga implementado un intérprete de Java.

Además, las bibliotecas estándar de funciones y métodos de Java (definidas en su API, Application Programming Interface) facilitan la programación de multitud de acciones complejas (desarrollo de interfaces gráficas, multimedia, multitarea, interacción con bases de datos,...). Ningún otro lenguaje (ni compilado ni interpretado) dispone como Java de una cantidad tan grande de funciones accesibles en cualquier plataforma sin necesidad de cambiar el código fuente.

 

II.2.2.- Sencillez. Java es un lenguaje de gran facilidad de aprendizaje, pues en su concepción se eliminaron todos aquellos elementos que no se consideraron absolutamente necesarios. Por ejemplo, en comparación con otros lenguajes como C ó C++, es notable la ausencia de punteros, o lo que es lo mismo: es imposible hacer referencia de forma explícita a una posición de memoria; ello ahorra gran cantidad de tiempo a los programadores, dado que el comportamiento imprevisto de los punteros es una de las principales fuentes de errores en la ejecución de un programa. Por otra parte, el código escrito en Java es por lo general mucho más legible que el escrito en C ó C++.

Por otro lado, Java dispone de un mecanismo conocido como de "recogida de basura", el cual —usando la capacidad multitarea de Java— hace que, durante la ejecución de un programa, los objetos que ya no se utilizan se eliminen automáticamente de la memoria. Dicho mecanismo facilita enormemente el diseño de un programa y optimiza los recursos de la máquina que se esté usando para la ejecución del mismo (con los lenguajes tradicionales, la eliminación de objetos y la consiguiente optimización de recursos debe planificarse cuidadosamente al idear el programa).

 

II.2.3.- Orientación a objetos. Aunque C++ es también, como Java, un lenguaje orientado a objetos, la diferencia fundamental es que Java lo es desde su concepción, mientras que C++ se diseñó como un lenguaje compatible con C (que no es orientado a objetos): de este modo, un programa escrito en C++ puede ignorar la mayoría de las características de orientación a objetos de C++ y compilarse sin problemas en un compilador de C++. Sin embargo, un programador no puede obviar la orientación a objetos cuando escribe un programa en Java, y esto hace que las aplicaciones escritas en Java tengan interesantes ventajas, como veremos en §III.

Para entender qué es la orientación a objetos, recordemos que los lenguajes tradicionales no orientados a objetos, como Pascal ó C, estaban pensados para trabajar de forma secuencial y basaban su funcionamiento en el concepto de procedimiento o función. La tarea principal del programa se dividía en funciones o tareas más pequeñas, a menudo muy interrelacionadas, por lo que era difícil modificar una función sin tener que revisar el resto del programa: por tanto, también era difícil reutilizar o actualizar los programas ya escritos.

En el caso de los lenguajes orientados a objetos, el concepto clave no es el de función, sino el de objeto. Un objeto es un elemento de programación, autocontenido y reutilizable, y que podríamos definir como la representación en un programa de un concepto, representación que está formada por un conjunto de variables (los datos) y un conjunto de métodos (o instrucciones para manejar los datos). Por ejemplo, en una aplicación de Bibliotecas un objeto puede ser un código de barras, que contiene datos (p. ej. el número mismo del código de barras) e instrucciones para manejarlos (p. ej. el método para calcular el dígito de control). Los objetos, además, poseen la capacidad de enviarse mensajes entre sí durante la ejecución de un programa.

La "encapsulación" de variables y métodos en un objeto tiene claras ventajas:

Cada objeto puede ser modificado y mantenido por separado.

Se pueden mantener en un objeto métodos y variables que no son accesibles desde fuera de él, lo que evita multitud de posibilidades de error en el momento de confeccionar un programa. Esta característica se llama "ocultamiento de la información".

Es posible reutilizar porciones de programa ya escritas: en el ejemplo anterior, un programador puede reutilizar el objeto "código de barras" para escribir software para diversos tipos de transacciones, como préstamo, devolución, reserva, etc. sin necesidad de reescribir cada vez los comandos para calcular el dígito de control, dado que el programa se encargará de hacerlo cada vez que se use el objeto.

Como hemos dicho en §I.2, el estándar JavaBeans de Java proporciona un entorno visual de programación que facilita y simplifica la programación de objetos. De hecho, es posible escribir applets sencillos en Java sin necesidad de escribir una sola línea de código.

 

II.2.4.- Seguridad. En general, se considera que un lenguaje es tanto más seguro cuanto menor es la posibilidad de que errores en la programación, o diseños malintencionados de programas (virus), causen daños en el sistema. La extrema seguridad de Java se establece a tres niveles:

Nivel de seguridad dado por las características del lenguaje, tales como la ausencia de punteros (que evita cualquier error de asignación de memoria) o el "ocultamiento de la información" propio de la programación orientada a objetos, por recordar dos ejemplos ya mencionados.

Nivel de seguridad dado por el diseño de la VM:

La VM de Java posee un verificador de los byte codes, que antes de ejecutarlos analiza su formato comprobando que no existen punteros en ellos, que se accede a los recursos del sistema a través de objetos de Java, etc.

Otro elemento constitutivo de la VM es el cargador de clases. Una clase es una categoría de objetos utilizados en un programa; cuando se ejecuta un programa en Java, éste llama a determinadas clases a través del cargador de clases. Estas clases pueden provenir de tres lugares distintos, en donde residen en forma de ficheros: del ordenador local, de la red de área local a la que pueda estar conectado el ordenador cliente, o de Internet. En función de la procedencia de las clases, se efectúan una serie de comprobaciones diferentes y el gestor de seguridad de la VM prohíbe los accesos peligrosos.

Nivel de seguridad dado por la API de Java. El conjunto de métodos y clases que estamos obligados a utilizar cuando programamos en Java para acceder a los recursos del sistema, está definido por la API, y constituye la última barrera defensiva. El diseño de dichos métodos y clases hace que éstos realicen múltiples verificaciones cuando son invocados, de modo que se dificultan los errores (voluntarios o involuntarios).

 

II.2.5.- Adaptación a redes (y en particular a Internet). Ya hemos dicho que Java irrumpió en el mercado para potenciar la interactividad en Internet, y también hemos hablado de los applets, pequeños programas en Java que se cargan junto con una página web desde un servidor, y que son ejecutados (por la VM del navegador del cliente) como una parte de la página web. Además de las ventajas que supone su ejecución local, los applets disponen de una significativa riqueza de recursos y son capaces de realizar tareas muy complejas a pesar de su reducido tamaño. Una de las explicaciones de esta sorprendente capacidad es el hecho de que los applets se sirven del propio código del navegador en cuya VM se ejecutan, utilizándolo para tareas tales como presentación gráfica o comunicaciones. Sin embargo, el acceso a las funciones del navegador es totalmente automático y transparente para el programador, que debe limitarse a invocar ciertas funciones de la API de Java; estas invocaciones, interpretadas por el navegador, dan origen a acciones muy complejas. Esta observación es muy importante cuando se discute del rendimiento de Java, pues todas estas acciones se realizan en la máquina que está ejecutando el applet, y la rapidez de ejecución de las mismas no depende de que Java sea un lenguaje semiinterpretado (o semicompilado).

Entre las tareas básicas más comunes que suelen realizar los applets, se encuentran: visualizar animaciones en la ventana del navegador; reproducir sonidos; establecer comunicaciones con el servidor del que procede el applet (p. ej. para cargar desde él ficheros de cualquier naturaleza); crear interfaces gráficas con los elementos habituales de los entornos de ventanas (como Macintosh o Windows): menús desplegables, botones, áreas de texto, barras de desplazamiento, etc.; pedir datos al usuario para procesarlos (gestionando eventos como pulsaciones de teclas o acciones con el ratón); etc. No obstante, y como acabamos de decir, es posible programar applets para realizar tareas de enorme complejidad. (Ver [11].)

 

 

III.- BENEFICIOS DEL USO DE JAVA EN LAS APLICACIONES DE BIBLIOTECAS

Los beneficios del uso de Java para las aplicaciones de Bibliotecas derivan de las propias cualidades del entorno Java que se han expuesto en §II.2. Los que son consecuencia directa de dichas cualidades se exponen en §III.1. Otros beneficios menos evidentes, pero más espectaculares si cabe, se derivan de que Java también permite la adopción de una filosofía totalmente nueva e impensable hasta ahora en el diseño de aplicaciones de Bibliotecas, y que se expone en §III.2.

 

III.1.- Beneficios directos derivados de las cualidades de Java

III.1.1.- Rapidez de desarrollo y mejora del software. El hecho de que Java sea un lenguaje orientado a objetos desde su concepción tiene, entre otras muchas consecuencias, la de que es fácil reutilizar el código de programación, como hemos dicho en §II.2.3; y por tanto los desarrollos de una aplicación serán más rápidos, pues es más rápido reutilizar objetos y sus componentes que reescribir el código desde el principio. Además, una vez que el código de un objeto es estable, la reutilización de ese objeto replica ese código fiable en cualquier parte en toda la aplicación, lo que reduce el proceso de depuración (debugging)..

Además, como hay menor posibilidad de errores en la programación, como también hemos visto al describir los niveles de seguridad de Java en §II.2.4, resulta que, como se ha dicho en alguna ocasión: "al programador en Java no le queda más remedio que escribir código robusto y fiable" [7], o lo que es lo mismo: en el desarrollo de una aplicación se necesitará emplear menos tiempo (y dinero) en los procesos de depuración y de perfeccionamiento o reescritura del programa.

Otra consecuencia de la orientación a objetos de Java es que hace que el software escrito en Java sea modular: como el objeto es la entidad clave en la programación, cada uno puede ser modificado y mantenido por separado. Además, en Java no existe el concepto de fichero ejecutable: un programa no es más que un conjunto de ficheros compilados para la VM (llamados "módulos"), que no es necesario "enlazar" en un único ejecutable como ocurría en el caso de los lenguajes compilados. Esto significa que pueden realizarse modificaciones sobre cada uno de los "módulos" sin necesidad de tener que recompilar y enlazar todos ellos: basta compilar sólo los "módulos" afectados.

En el caso de un sistema de gestión de Bibliotecas, esta modularidad implica que sus distintos módulos [en el sentido tradicional de este término: módulo de adquisiciones, módulo de control de publicaciones periódicas, etc.] pueden compartir una serie de applets que realicen las mismas funciones (como pueden ser los que proporcionan la interfaz gráfica, p. ej.), lo que incrementa la facilidad de desarrollo y mantenimiento del software.

Insistimos de nuevo en que la universalidad de Java (§II.2.1) equivale a que las aplicaciones escritas en Java son transportables de una plataforma a otra: pueden funcionar en cualquier máquina y bajo cualquier sistema operativo sin que sea precisa ninguna modificación, siempre que en dicha plataforma se haya instalado un intérprete o VM (máquina virtual) de Java: recuérdese que se han implementado VMs para casi todas las plataformas, incluyendo las más populares como Unix, Macintosh OS, IBM OS/2, Microsoft Windows 95/Windows NT, ó Solaris. Pues bien, esta independencia total de la máquina elimina la necesidad de desarrollar y mantener múltiples versiones del código fuente. En particular, cuando se deseaba implementar una nueva funcionalidad de una aplicación escrita en un lenguaje compilado, podía ser necesario reescribirla en múltiples ocasiones para adecuarla a cada plataforma en que se utilizaba la aplicación. En el caso de Java, basta añadir el código una sola vez, en un solo lugar. Esto equivale a que la Biblioteca soporta sólo una versión del software. Este enfoque es más eficiente, económico y directo que soportar diferentes paquetes de cliente para cada tipo de plataforma.

Como es evidente, todas las consideraciones que hemos realizado en esta sección tienen las siguientes ventajas añadidas para las Bibliotecas:

Se intensifica y acelera la entrega de mejoras de la aplicación, garantizando por consiguiente una mayor versatilidad y adaptabilidad a las tecnologías emergentes y a las necesidades crecientes, en materia de servicios, de la comunidad de usuarios de las Bibliotecas.

No sólo las mejoras llegan antes a las Bibliotecas, incrementando su rendimiento, sino que también llegan con un menor coste financiero del mantenimiento del software.

 

III.1.2.- Seguridad, fiabilidad y eficiencia. Como se ha visto en §II.2.4, las características de Java como lenguaje redundan en una ejecución segura del código, de manera que es posible construir módulos de software capaces de detectar intentos de acceso a recursos privilegiados del sistema. Esa capacidad es importante, sobre todo a la hora de emplear Java en redes de ordenadores inseguras como Internet (cuando se cargan applets). La supremacía de Java sobre los lenguajes interpretados tradicionales (muy populares en Internet debido a su flexibilidad para evaluar cadenas dinámicas de caracteres, lo que permite manejar formularios, p. ej.) es rotunda, pues éstos presentan graves deficiencias en ese sentido.

En cuanto a la capacidad y prestaciones de las aplicaciones obtenidas al programar con Java, ya hemos discutido bastante este tema en §II. Para resumir, recordemos que la semicompilación de Java proporciona resultados aceptables, y más si la VM incorpora un compilador just-in-time. Pero para lo que es relevante ahora, esto es, para las aplicaciones destinadas a Bibliotecas, y sólo desde el punto de vista del lenguaje Java propiamente dicho, digamos que la sencillez de las construcciones de que consta Java permiten obtener un código de tamaño reducido, por lo que la penalización en que se incurre (con respecto a la utilización de un lenguaje compilado) por la necesidad de interpretarlo se reduce considerablemente, y las diferencias en la rapidez de ejecución serán inapreciables por el usuario. (Para otras consideraciones sobre eficiencia y rendimiento, véase también §II.2.5.)

 

III.2.- Nuevas posibilidades específicas de diseño de aplicaciones. La arquitectura cliente/servidor de tipo thin client

III.2.1.- Aplicaciones modulares, distribuidas y personalizadas. El concepto dominante en Internet es el de "servidores de información"; Java permite la extensión de este concepto al mucho más potente de "servidores de aplicaciones". Para explicarlo, recordemos que un programa en Java es un conjunto de ficheros compilados para la VM, cada uno de los cuales representa una clase (categoría de objetos). Cuando se accede a un applet que reside en otro ordenador, el navegador carga la clase principal, y va cargando dinámicamente el resto de clases a medida que son necesarias para la ejecución. Es decir, se pueden gestionar las clases del programa independientemente del applet que las usa: esto implica que cuando un usuario requiere un nuevo applet para realizar cierta función, el navegador puede comprobar si algunas de sus clases existen ya en la memoria local, por lo que no es necesario cargarlas de nuevo, lo que incrementa el rendimiento.

La aplicación de este nuevo concepto en un entorno de red se realiza del siguiente modo. Debido (de nuevo) a su rigurosa concepción de orientación a objetos, es muy fácil programar aplicaciones verdaderamente modulares (como ya hemos dicho en §III.1.1); aquellas funcionalidades de la aplicación que deban ser accedidas por un usuario (un bibliotecario, p. ej., para prestar un libro, registrar un fascículo de revista, etc.) pueden programarse como applets.

En todo caso, basta instalar los distintos "módulos" de la aplicación, incluidos los applets, en un único servidor, de manera que:

Los usuarios acceden a las aplicaciones con un navegador. Los usuarios pueden seleccionar sus navegadores preferidos con interfaces familiares y personalizadas. Asimismo, los bibliotecarios acceden a interfaces web basadas en Java y dinámicamente configurables. No sólo el acceso público sino también el acceso bibliotecario se benefician de una interfaz fácil de usar y de personalizar como es la interfaz web. La generalización del uso del web en los últimos años permite reducir en forma considerable el proceso de aprendizaje y formación en la aplicación.

Las Bibliotecas se liberan de la preocupacion de instalar las aplicaciones localmente y de actualizar sucesivas versiones. Los applets de Java se distribuyen fácilmente por la www. Además, las dificultades de tráfico en una red (incluso en una de banda tan estrecha como Internet) no afectan a la funcionalidad de los applets, pues éstos ocupan un tamaño muy reducido (no más de 10 ó 20KB, según el tipo de aplicación); recuérdese además que no se tienen por qué cargar los applets enteros, sino sólo las clases necesarias. Esta facilidad de distribución tiene como ventajas la de obviar el coste asociado a la actualización de la aplicación en los clientes, así como la de garantizar que todos los usuarios utilizan la misma versión de software.

La independencia de Java con respecto de toda plataforma permite que las aplicaciones, al estar en Java, funcionen igual en todos los ordenadores, independientemente de su modelo o sistema operativo.

El usuario sólo cargará la utilidad específica de la aplicación que necesite y cuando la necesite. Y se crean, para cada usuario, entornos de trabajo personalizados que sólo utilicen las funcionalidades del software requeridas.

 

III.2.2.- Consecuencias del enfoque anterior: una nueva arquitectura cliente/servidor para los sistemas de Bibliotecas. En el enfoque que acabamos de describir, en que una aplicación se instala modularmente en un único servidor y los usuarios interactúan con ella a través de applets, resulta evidente que todo lo necesario para que un ordenador cliente saque todo el partido a las distintas funcionalidades de la aplicación es que tenga instalado un navegador (que incorpore la VM de Java, como Netscape o Internet Explorer), sin que haya que usar ningún sistema operativo o configuración de hardware preferentes. En suma, no se necesitan ordenadores especialmente potentes.

Esto es lo que se conoce como thin clients ("clientes delgados"): por contraposición a los fat clients ("clientes gruesos") que utilizan actualmente la mayor parte de los sistemas de gestión de Bibliotecas. Estos fat clients necesitan funcionar con un sistema operativo determinado, como Windows, y deben tener cargados programas específicos para efectuar ciertas funcionalidades (de catalogación, circulación, etc.), lo cual implica requisitos determinados en lo que se refiere a potencia del microprocesador, cantidad de RAM, capacidad del disco duro, etc., sin contar con que hay que preocuparse de cargar cada vez la última actualización del software. Además, para mejorar un fat client típico es preciso actualizar el hardware (lo que implica en particular visitar cada estación de trabajo); mientras que para mejorar un thin client basta mejorar su VM (lo que se puede hacer a través de red local).

En esta nueva arquitectura cliente/servidor, es más fácil optimizar las prestaciones, porque los thin clients requieren estaciones de trabajo menos potentes. Estos requisitos reducidos implican una mayor flexibilidad en la selección de estaciones, incluyendo los menos costosos terminales y ordenadores de red (NCs ó network computers). Un ordenador de red puede ser de dos tipos: o bien un PC de bajas prestaciones con la configuración mínima para trabajar con un navegador web, o bien un ordenador específico (como los que fabrica Sun) que incorpora el chip de Java, esto es, un microprocesador diseñado para ejecutar directamente los byte codes de Java, evitando el uso de un intérprete (lo que aumenta espectacularmente la velocidad de ejecución de los byte codes). Ambos tipos de NC tienen un coste parecido, inferior al de un PC de los utilizados por la arquitectura fat client.

Pero sobre todo, el verdadero ahorro que supone la tecnología de thin client se debe a una reducción considerable de los costes de mantenimiento y soporte de estos clientes:

De acuerdo con el Gartner Group, el Coste Total de Propiedad (Total Cost of Ownership), ó CTP, de una estación de trabajo de tipo microordenador es de 6 veces el precio de su adquisición en un plazo de cuatro años. Por ejemplo, según este modelo, un microordenador con un precio de 350.000 Pts elevaría su CTP al cabo de cuatro años a 2.100.000 Pts, lo que supone unas 500.000 Pts por año. Este coste se reparte como sigue:

un 16% corresponde al coste de la estación de trabajo (hardware y software);

un 16%, al coste de apoyo técnico (es decir, de personal que actualiza y mantiene la estación de trabajo): este coste equivale al coste de adquisición de la estación de trabajo en su ciclo de vida;

un 12%, al coste de administración y mantenimiento de las comunicaciones;

y un 56%, al coste para el usuario final (tiempo perdido debido a fallos del sistema, actividades no productivas resultantes de la extensibilidad del ambiente PC actual, cambios inadvertidos de configuración, instalación de nuevas aplicaciones que entran en conflicto con el software existente, etc.).

En cambio, un sistema cliente/servidor de tipo thin client reduce su CTP de forma dramática. Sobre una base real, y dejando de lado los modelos financieros, existen experiencias comprobadas. El Medical Center de la University of Washington tiene aproximadamente 1200 NCs (network computers). El coste de mantenimiento y apoyo técnico se eleva a 15.000 Pts por año y por usuario. El coste de propiedad ó CTP se reduce a alrededor de 160.000 Pts en un plazo de cuatro años, es decir, a 40.000 Pts al año.

(Fuente: [5].)

 

III.3.- Un caso particular: INNOPAC Millennium

III.3.1.- Generalidades. Mientras que Java se integra en los ambientes de desarrollo, en los navegadores y en los sistemas operativos, y se consolida a través de una adhesión creciente y sin precedentes —se evalúa que el 71% de las mayores empresas americanas incluye Java como plataforma estratégica de desarrollo—, es todavía limitada la adopción de la programación Java entre las empresas proveedoras de aplicaciones para Bibliotecas. Innovative ha adoptado de forma precoz la tecnología ofrecida por Java, y con el sistema INNOPAC Millennium ofrece ya productos que se encuentran funcionando en el mercado.

INNOPAC Millennium es un sistema de gestión de Bibliotecas de nueva generación, escrito en Java y que combina una nueva y potente arquitectura cliente/servidor de tipo thin client y una eficaz interfaz gráfica, con una riqueza funcional consolidada por veinte años de experiencia en desarrollos para Bibliotecas. Se anunció este programa en 1996 con una completa finalización para el nuevo milenio.

INNOPAC Millennium, además del extenso catálogo de productos del sistema INNOPAC, incluye ya productos diseñados según esta filosofia, disponibles para su instalación como son:

el OPAC,

el módulo de control de circulación,

el módulo de información de gestión y estadísticas,

el módulo de gestión de imagen,

el módulo de material en reserva,

el módulo de gestión de acceso por Web (a bases de datos),

el sistema de búsqueda por texto completo (full-text searching).

Dichas partes ya en funcionamiento, así como las que se prevén a corto plazo (tales como las nuevas interfaces de usuario para los módulos de control de publicaciones periódicas y de adquisiciones) están basadas en la tecnología ofrecida por Java, con la filosofía de la nueva arquitectura cliente/servidor de tipo thin client que se ha descrito en §III.2.2: es decir, pueden funcionar en una intranet o en Internet de forma potente y segura, permitiendo la integración de datos de una Biblioteca con otros recursos remotos, y minimizando los costes gracias al uso de hardware (PCs basados en Windows, Macintosh o simples NCs) y software (navegadores web) de cliente no propietarios. Como sistema de gestión en sí, INNOPAC Millennium no sólo aprovecha toda la funcionalidad que existe en INNOPAC, sino que además tiene un diseño de acceso abierto, un aspecto gráfico mejorado (la interfaz permite incluir diagramas y gráficos de todo tipo, funcionalidad del ratón, ayuda en línea, múltiples ventanas abiertas simultáneamente, capacidad multimedia), una funcionalidad expandida para el acceso público y del personal de la Biblioteca, y una arquitectura de base de datos abierta y conforme a los estándares de la industria.

(Véase [6] para conocer la política de Innovative acerca de Java, y otros detalles acerca de INNOPAC Millennium.)

 

III.3.2.- Un ejemplo. El módulo de control de circulación. Este módulo está basado en Java, y posee toda la funcionalidad del módulo de circulación del sistema INNOPAC. Por ejemplo, los bibliotecarios pueden crear inmediatamente registros de usuarios o de ejemplares inmediatamente (on the fly) o actualizar otros registros dentro del módulo de circulación. También están plenamente operativos los applets que permiten controlar las reservas, cursos, reclamaciones y atrasos, gestión de multas (cobros, aplazamientos, etc.), materiales en reserva,...

El módulo también permite visualizar en pantalla o actualizar todas las transacciones relacionadas con un usuario durante el proceso de préstamo de un libro (desde que el sistema lee el código de barras del usuario o se introduce manualmente su número), incluyendo el estatus de sus peticiones de préstamo interbibliotecario, su posición en la lista de espera, las reservas de ejemplares específicos que ha realizado, el material previamente sacado en préstamo, las reservas de recursos (salas, material, equipos), etc. Estas son funcionalidades que ya posee el módulo de INNOPAC, a las que el INNOPAC Millennium añade otras como la posibilidad de incluir fotos de los usuarios para que aparezcan durante la transacción, o de añadir otras imágenes y sonidos totalmente personalizables sustituyendo la tradicional alerta sonora durante una operación especial; además, la interfaz es totalmente gráfica (todas las funciones se pueden solicitar tanto con el ratón como con equivalentes de teclado, y muchos campos están dotados de menús desplegables). Y, sí, se puede hacer todo esto desde cualquier tipo de ordenador que albergue un navegador compatible con Java y que esté conectado a la red.

Con todo, una de las mayores ventajas que se consiguen con el nuevo módulo respecto a INNOPAC es, sorprendentemente, el incremento de la velocidad en la realización de las operaciones propias del control de circulación: esto es debido a la mejora en el diseño propiciada por las posibilidades gráficas de Java: de 150 pantallas en la versión de INNOPAC se ha pasado a sólo 25 en la versión de INNOPAC Millennium. Todo ello se traduce en un considerable ahorro de tiempo para la Biblioteca.

 

 

REFERENCIAS

Artículos y libros

[1] G. Alwang, J. Clyman, R.V. Dragan, L. Seltzer: Java Guide. PC Magazine, vol.17 no. 7 (April 1998), p. 101-209.

[2] P.M. Cuenca Jiménez: Programación en JAVA para Internet. Anaya Multimedia (col. Vía@Internet), Madrid, 1996. xxiv+528p.

[3] R.V. Dragan, L. Seltzer: Java: A Field Guide for Users. PC Magazine, vol.16 no. 10 (May 1997), p. 100-115.

[4] J.M. Framiñan Torres: Java. Anaya Multimedia (col. Al Día en una Hora), Madrid, 1997. 128p.

[5] R. Gilbertson: NC’s the Fourth Wave — The Network computer is switching the client-server standard to server-client. Tech Web News (June 16, 1997).

[6] INN Touch (boletín informativo periódico de Innovative Interfaces Inc.). Números de 1997 y 1998 (muchos de ellos dedicados a Java o al sistema de gestión de Bibliotecas INNOPAC Millennium). Pueden consultarse sus versiones electrónicas en la dirección http://www.iii.com

[7] J. Manger: Java: More than just a programming language. Internet Business Magazine (April 1997), p. 66-70.

[8] P. Jones: Java and Libraries. Digital and Otherwise. D-Lib Magazine (March 1997). [Se trata de un artículo de una revista electrónica, que puede consultarse p. ej. en http://mirrored.ukoln.ac.uk; su versión impresa ocupa unas 5p.]

 

Direcciones en Internet

[9] http://www.javasoft.com, http://www.sun.com —Sitios oficiales de Sun Microsystems.

[10] http://www.javaworld.com/JavaWorld —Revista electrónica sobre Java.

[11] "Gamelan: The Java Directory" en http://java.developer.com (también puede invocarse con http://www.gamelan.com) —Gamelan es uno de los más conocidos recursos en Internet sobre Java; contiene listas anotadas, bien organizadas y actualizadas de miles de applets.

[12] http://www.iii.com —Innovative Interfaces y http://www.sls.se —SLS (Information Systems), División Europea de Innovative Interfaces.