Métodos de distribución de aplicaciones JAVA

Introducción

A la hora de desarrollar una aplicación casi nunca solemos reparar en la forma en la que el software desarrollado será distribuido e instalado en los sistemas de usuario final. A priori esto parece un aspecto poco relevante, pero que puede llegar a ser crítico cuando se pretende que la distribución de la aplicación se efectúe de manera transparente sobre conjuntos de PC’s que pueden llegar a contener varios cientos o miles de unidades. Si además, estos PC’s presentan un espectro de configuraciones de hardware y S.O muy diversa, este proceso puede tornarse excesivamente complejo. En este tipo de escenarios haber planificado un método eficiente y sencillo para la distribución puede ser determinante para evitar la inmensa pérdida de tiempo que conlleva la escasa automatización de este proceso por la consiguiente necesidad de intervención humana para la resolución de conflictos.

Pero si hablamos específicamente de aplicaciones JAVA, a todo lo mencionado, debemos añadir ciertas particularidades propias de esta plataforma. Los programas de JAVA necesitan de la presencia de un entorno de ejecución (Java Runtime Environment JRE) para poder ejecutarse. Este lenguaje nació para ser multiplataforma y ha presumido siempre de este lema; “Write once run anywhere” (Escribir una vez ejecutar en cualquier sitio). Cuando escribimos una aplicación JAVA no la compilamos de manera nativa para una arquitectura hardware/software específica; windows, linux, sparc . La “compilación” de programas JAVA consiste en la traducción del código fuente escrito por el programador a un código intermedio independiente de plataforma denominado “bytecodes” (.class de java). Una vez obtenidos estos bytecodes la máquina virtual Java contenida en el JRE es capaz de interpretarlos y ejecutarlos de manera eficiente sobre la plataforma objetivo como una aplicación más. Por lo tanto, los únicos componentes JAVA que son específicos de la plataforma son las máquinas virtuales de ejecución. Actualmente existe un gran número de implementaciones de estos JRE para la mayoría de las plataformas, incluso para las más exóticas. Además, no sólo la empresa creadora de JAVA, SUN microsystems , es la que ofrece estos entornos de ejecución sino que podemos encontrar abundantes implementaciones de numerosas partes, algunas de ellas libres: sablevm, blackdown, kaffe etc.

Problema

El principal problema de la distribución de aplicaciones JAVA es que para ser ejecutadas necesitan disponer de un JRE instalado en el sistema operativo. En plataformas como Windows esto es problemático porque no viene ningún JRE acompañando la instalación del Sistema Operativo . Por tanto, cuando queremos instalar una aplicación JAVA en este sistema, primero debemos instalar una versión del JRE compatible con los requerimientos de la aplicación (actualmente la última versión de java de SUN es la 5). Llegados a este punto, es dónde pueden empezar los problemas para un usuario medio de Windows. Si la propia aplicación que se pretende instalar no está provista de métodos para efectuar la descarga e instalación de la versión apropiada de la JRE, junto a la propia aplicación, de una manera simple, se pueden producir ciertas situaciones de incomprensión y frustración por parte de un usuario acostumbrado a instalar software de una manera sencilla. Por el contrario en otros sistemas donde la presencia de una JRE viene por defecto y además hay un soporte explícito para mejorar el rendimiento y simplificación de la gestión de programas JAVA , como es el caso de Mac OSX o Solaris, el proceso de distribución y despliegue puede ser mucho más fácil y manejable.

Cuando se compila una aplicación JAVA es conveniente empaquetar el conjunto de clases generadas en un único archivo .jar. A este archivo comprimido contenedor de las clases de nuestro programa debemos acompañar el conjunto de librerías que usamos. Usualmente estas librerías también vienen empaquetadas cada una de ellas en archivos .jar. Con todo el conjunto de librerías y el archivo .jar de nuestro programa y presuponiendo la preexistencia de un JRE apropiado para la aplicación, ésta se ejecutaría de la siguiente forma.

java [options] -cp lib1.jar;lib2.jar … ;libn.jar; miaplicacion.jar MyApp

Dónde la opción -cp indica el classpath(conjunto de librerias usadas) apropiado para nuestra aplicación. Es decir, especifica la ruta dónde poder encontrar cualquier clase usada o definida en nuestra aplicación. Notar que debe incluirse en este CLASSPATH el archivo .jar que contiene las clases propias de nuestra aplicación. MyApp indica la clase principal o punto de entrada a la aplicación, o sea, la que contiene el método main. Esta clase puede estar definida dentro de un paquete, en este caso se debe especificar el nombre completo indicando la ruta de todos los paquetes a los que pertenece. Es usual que cada organización y empresa defina su propio espacio de nombres para especificar un sistema de nombrado de clases coherente y unificado para todas las aplicaciones que desarrolle con el fin de evitar colisiones de nombres de clases. Por ejemplo en nuestro grupo, en el caso de la aplicación MyApp, su nombre completo probablemente podría ser org.upv.gim.app.MyApp, y por tanto en el comando de ejecución java anterior el nombre de la clase de entrada de la aplicación debería aparecer completo; org.upv.gim.app.MyApp.

Si aún quisiéramos simplificar un poco más el comando de ejecución anterior, ya que se podría dar el caso de utilizar decenas de librerías para un proyecto -con lo que la opción de classpath (-cp) sería demasiado extensa- se podría reducir el número de archivos .jar a un sólo archivo desempaquetando todas las librerías usadas con el propósito de reempaquetarlas después de manera conjunta y junto a nuestras clases en un único archivo JAR. Incluso en este mismo .jar podríamos definir en su archivo de Manifiesto (Manifest) cual es la clase de entrada de la aplicación de modo que el comando de lanzamiento se simplificaría a la siguiente instrucción:

java -jar myapp.jar

NOTAS:

jar xvf lib1.jar (comando para desempaquetar .jar no comprimidos)
jar xvfz lib1.jar (comando para desempaquetar .jar comprimidos)
jar cvfz Myapp.jar classes/ (empaqueta de manera recursiva todos los .class contenidos en el directorio classes/ en el archivo Myapp.jar)

Como se desprende de estos ejemplos, a un usuario final inexperto no vamos a poder distribuirle una aplicación JAVA de esta manera. Dándole un conjunto de archivos .jar y una instrucción que debe ejecutar en una línea de comandos para poder ejecutar el aplicativo y además con el agravio de dejarle pendiente como tarea personal la comprobación del entorno de JRE adecuado y en su defecto su descarga e instalación. Por lo tanto, como mínimo, y dependiendo del S.O debemos hacer algún esfuerzo más para simplificar el proceso. En el caso de Windows o cualquier sistema Unix podríamos acompañar al conjunto de archivos de la aplicación un script que contuviese el comando de lanzamiento de la aplicación. De esta forma en un entorno Windows esta instrucción podría estar contenida en un archivo de ejecución por lotes .bat y con un simple doble click sobre el archivo éste lanzaría la aplicación, incluso si hace un uso regular de la aplicación y necesita un acceso rápido podría crearse un acceso directo en el escritorio. En el caso de un sistema tipo Unix se podría solucionar esto mismo con un Script bash, sh o cualquier otro derivado.

Sin embargo aún con este paso no tendríamos solucionado el chequeo del entorno JRE adecuado y su instalación en caso de que éste no estuviera presente. Está claro que en ciertos entornos tendríamos la opción de ampliar la funcionalidad de los Scripts que contienen el comando de lanzamiento para efectuar estas comprobaciones. Sin embargo esta posibilidad está sujeta a la potencia del lenguaje de Script y en cualquier caso difícilmente podríamos informar al usuario de las comprobaciones y posibles opciones a tomar en consideración en forma de ventanas gráficas. Además mantener una versión de Script específica para cada posible plataforma de distribución es una tarea tediosa.

Seria deseable contar con un lanzador multiplataforma de aplicaciones Java no dependiente de la preexistencia de una máquina JRE capaz de efectuar las siguientes comprobaciones y con la siguiente funcionalidad:

  • Comprobar si existe una JRE con una versión adecuada para la ejecución de la aplicación que se desea instalar.

    En el caso de satisfacer este requerimiento, lanzar la aplicación con el comando java acompañado de las opciones y configuración pertinente del CLASSPATH.

  • En caso contrario ofrecer al usuario la posibilidad preferente de instalar una JRE que nosotros mismos hayamos adjuntado en la distribución de nuestra aplicación. Tras su instalación, se ejecutará la aplicación Java sin ningún problema.

  • Como segunda opción. En caso de que el usuario sea consciente de que tiene instalada una JRE pero no se ha detectado correctamente, dar la posibilidad de escogerla navegando por el sistema de archivos para dar con la ubicación correcta de esta JRE.

  • Como tercera opción. Dar la posibilidad de bajarse de Internet una última versión del JRE para instalarlo en el ordenador.

Esto puede ser un método razonable para la distribución de software que no va a estar sujeto a numerosas modificaciones periódicas. No obstante si el software se actualiza constantemente y necesita ser redistribuido este método no está dotado de un mecanismo adecuado para llevar a cabo automáticamente dichas actualizaciones. Por lo tanto, cada aplicación es responsable de este soporte con lo cual debemos implementarlo en la propia aplicación con el objetivo de poder comprobar en algún repositorio accesible vía red de la existencia de algún cambio para poder aplicarlo sobre nuestra instalación, automáticamente o por demanda del usuario.

Es sorprendente que hasta la aparición de la versión 1.4. El propio entorno de programación de java SDK (standard development kit), ofrecido por la empresa SUN, no contemplaba ningún mecanismo de distribución y despliegue de aplicaciones JAVA -con una funcionalidad mínima similar a lo descrito hasta el momento-. No obstante a partir de esta versión incorporaron un mecanismo de despliegue de aplicaciones conocido como Java Web Start cuyo protocolo subyacente se denomina JNLP (Java Network Launch Protocol). Este mecanismo permite la distribución de aplicaciones JAVA a partir de un servidor web. El usuario final puede iniciar la instalación pulsando sobre una URL que apunte a un descriptor JNLP de la aplicación. No obstante, si no contamos con una JRE instalada volvemos a estar en la misma situación anterior, es decir, no podemos lanzar la aplicación. Para resolver este problema la propia empresa SUN ofrece y recomienda algunos scripts para la web que permiten hacer esta comprobación y informar al usuario de la descarga e instalación de la JRE adecuada. Desgraciadamente muchas veces estos scripts no funcionan de manera adecuada en todos los navegadores web y hay que hacer alguna adaptación para su adecuación y además requiere la instalación por separado del entorno de JRE y vuelta de nuevo a ejecutar la aplicación deseada.

Finalmente, en el caso de contar con un JRE o haber efectuado una instalación correcta con el simple acceso a la URL JNLP de la aplicación ésta se arrancará sin problemas dentro del entorno de ejecución controlado de Java Web Start. Este mecanismo nos facilita la instalación de accesos directos en el escritorio y además cuenta con un mecanismo automático de comprobación y instalación de actualizaciones cada vez que ejecutamos una aplicación JWS y estamos conectados a la red. El despliegue de aplicaciones JWS debe especificarse en archivos JNLP donde se definen los requerimientos de JRE necesarios de la aplicación así como el conjunto de librerías y recursos asociados a la misma.

JNLP es una excelente método de distribución para un entorno controlado, como una intranet corporativa, pero no está realmente pensado para destinarlo a un mercado de consumo dónde la forma de instalación/desinstalación y uso de los programas deba ser exactamente igual a la forma en la que se efectúan las instalaciones de programas nativos para dicha plataforma. En el caso de una intranet, con equipos lo bastante potentes para ejecutar de manera fluida un entorno JRE superior o igual a la versión 1.4 – y en la que se puedan contar con los suficientes recursos humanos encargados del soporte informático – se pueden paliar los posibles incidentes de la distribución de aplicaciones vía JNLP de un modo aceptable.

No es hasta la versión 1.5 de java JWS dónde realmente se presenta una integración con el escritorio apropiada (especialmente para entornos Windows). Sin embargo los requerimientos de un PC para ejecutar de manera fluida aplicaciones gráficas java basadas en SWING/AWT sobre un entorno JRE pueden ser insuficientes si contamos en la intranet con un conjunto numeroso de PC’s con hardware con pocos recursos.

En este tipo de situaciones es cuando es necesario replantearse seriamente desde el principio la posibilidad de un cambio radical del diseño de nuestra aplicación. En nuestro caso tuvimos una experiencia que puede ejemplificar un caso de uso similar dónde este cambio de diseño facilitó el despliegue y mantenimiento de la aplicación de manera considerable.

El caso es el siguiente:

Hospital CHGUV

Se necesitaba implantar en un entorno hospitalario un visor para la historia clínica de los pacientes que debía ser instalado en cada uno de los PC’s usados por el personal sanitario de la institución. Las cifras no eran nada desdeñables, ya que en la intranet se contaba con un millar de máquinas. En un principio se diseñó una aplicación basada en una arquitectura cliente-servidor. El cliente era la única parte del software que debía ser distribuida. Este cliente consistía en una aplicación GUI basada en Java/SWING que permitía buscar pacientes y mostrar su historia clínica de manera homogénea y unificada, recabando toda la información clínica dispersa por las diferentes fuentes de datos del hospital. La tarea de recolección de toda la información se efectuaba en la parte servidora y el cliente tenia acceso a esta información a partir de los Web Services expuestos por el servidor.

Todos los usuarios de la intranet contaban con equipos donde estaba instalado el S.O Windows en cualquiera de sus muchas variantes. De modo que había desde equipos con Windows Nt.4 hasta equipos con Windows XP y algunos menos con otras versiones. Todos ellos estaban bajo un mismo dominio controlado por el servicio LDAP de Windows -denominado Active Directory (AD)-. Con el AD los usuarios pueden autentificarse con sus cuentas desde cualquier equipo perteneciente al dominio.

El AD y los sistemas LDAP en general además de servir como mecanismo distribuido de autenticación cuentan con numerosas funcionalidades adicionales. Algunas de ellas son; La aplicación de políticas de seguridad global, nombrado de máquinas , políticas de actualización y distribución de software etc. Aprovechando las funcionalidades de distribución, se especificó una política para instalar de manera automática -sin ninguna intervención del usuario- una JRE y un enlace JNLP en el escritorio que apuntaba a nuestra aplicación Swing ubicada en un servidor web. Previamente se tuvo que convertir el archivo instalable de la JRE en un archivo .msi para poder instalarlo sin necesidad de ninguna interacción de usuario. Una vez establecida y aplicada la política en el AD, a los usuarios que cerraban su sesión y volvían a entrar para autenticarse de nuevo, se les instalaba de manera automática el JRE sin necesidad de ningún tipo de interacción y además les aparecía en el escritorio un enlace con el icono del visor apuntando al archivo .JNLP descriptor de la aplicación visor de historia clínica del paciente.

En apariencia este tipo de distribución parece bastante automático y cómodo, sobre todo en lo concerniente a la fácil distribución de las modificaciones gracias a las capacidades del protocolo JNLP. Sin embargo, en la práctica, esto no fue tan sencillo y eficaz como se anticipaba. Hubo un importante número de ordenadores que por problemas de carga del driver de la tarjeta de red no eran capaces de ejecutar las políticas de instalación establecidas en el AD. Otros tantos, por problema de sistema operativo, tampoco realizaban bien o la instalación de la JRE o del enlace a la aplicación en el escritorio. Además, existían muchos ordenadores con unos recursos de hardware insuficientes para correr con comodidad la versión 1.5 de java y nuestro visor Swing.

Ciertamente no eran problemas críticos, ya que posiblemente sólo afectaban al 10% del total de los ordenadores, sin embargo se requería de una intervención técnica personal para atender las incidencias que los usuarios presentaban.

Finalmente se decidió migrar la aplicación cliente SWING a una versión web. Esto se pudo llevar a cabo de una manera rápida debido a que la interfaz gráfica no era excesivamente compleja. Utilizando Struts, algo de ajax para ciertas sincronizaciones, JSP y html, se pudo emular una interfaz con una apariencia y comportamiento exactamente igual a la que estaban acostumbrados los usuarios pero esta vez a través de una interfaz web.

Con este nuevo diseño, dónde el peso de ciertas operaciones recaían sobre el cliente, ahora trasladábamos toda la carga al servidor web -junto con el Tomcat (contenedor de servlets)- que eran los encargados finales de servir la aplicación. Con esta nueva configuración la distribución de las modificaciones es igual de sencilla ya que con sólo modificar y desplegar en el servidor web la nueva versión esto se refleja de manera automática en los usuarios que acceden al cliente a través de un navegador web. Además, ahora incluso los ordenadores con pocos recursos pueden hacer uso de este cliente de una manera mucho más fluida.

Está claro que el paso de una aplicación a su versión web no siempre es posible, sencilla o aconsejable. Por ejemplo cuando utilizamos interfaces muy ricas, excesivamente complejas etc. Hay que notar que la productividad es un factor importante a tener en cuenta en el desarrollo y que actualmente hacer aplicaciones web supone un esfuerzo de tiempo y dedicación mucho mayor que su homónimo para escritorio. Por lo tanto se deben sopesar y analizar los posibles riesgos y ventajas antes de tomar decisiones precipitadas de diseño, ya que nos pueden facilitar ciertos procesos como la distribución pero entorpecer otros como la implementación.

Es verdad que este tipo de escenarios no suelen ser los más comunes. Muchas veces desarrollamos aplicaciones a medida que van destinadas a un grupúsculo reducido de usuarios. En estos casos distribuirles un CD o darles un enlace de descarga de la aplicación puede ser suficiente. En esta situación el CD o el archivo del programa debe contener un programa de instalación que autogestione todos los problemas técnicos de instalación que a un usuario medio no tienen por qué importarle. Este programa de instalación debe ser capaz de informar al usuario de los componentes del proyecto que se van a instalar y además posibilitar que la aplicación se integre en el sistema de manera nativa al igual que la mayoría de aplicaciones.

Actualmente podemos encontrar en el ciberespacio una gran cantidad de aplicaciones que nos ayudan a empaquetar el software y generan proyectos de instalación personalizables para nuestros proyectos. Izpack es un ejemplo de este tipo de programas. Está realizado en java y permite aglutinar de manera sencilla en un único archivo .jar todos los archivos a instalar. De esta manera conseguimos que el programa de instalación sea exactamente el mismo para cualquier plataforma. No obstante volvemos a caer en el mismo problema anteriormente citado; “Necesitamos de un JRE para lanzar el programa de instalación porque está hecho en Java”. De modo que si queremos un software de chequeo e instalación automático o guiado de un JRE necesitamos que este sea nativo a los binarios o lenguajes de scripts soportados de serie por el S.O.

En el caso de Izpack podemos encontrar un lanzador de instaladores izpack-java hecho en C++ y que hace uso de las librerías gráficas Qt (son multiplataforma) que nos permiten sortear esta necesidad. Cuando ejecutamos aplicaciones Java éstas no aparecen como procesos diferenciados en el S.O. De modo que si estamos ejecutando varias aplicaciones java estas no aparecen diferenciadas en la lista de procesos del S.O, todas aparecen como procesos java. Gracias a los lanzadores nativos conseguimos que las aplicaciones Java se pueden lanzar como procesos identificables de manera que podemos asociarles iconos propios y tenemos capacidad de gestionarlos (matarlos, controlar su ciclo de vida desde una aplicación …) sin interferir con otros procesos java.

El objetivo es encontrar un programa nativo para cada plataforma que se encargue del lanzamiento del programa de instalación y de la comprobación y posible instalación de una JRE adecuada para su funcionamiento. Esta tarea puede ser demasiado ardua si para cada plataforma se tiene que implementar un lanzador distinto. Es deseable encontrar una única forma para implementar un lanzador multiplataforma. Los lenguajes de programación C y C++ son los más potables , pero sólo si se usan las librerías ANSI propuestas como estándar para estos lenguajes. Entre estas librerías estándar no existe ninguna encargada de representar ventanas y widgets gráficos en un sistema operativo basado en ventanas. Esto puede ser un impedimento para el lanzador, ya que queremos que informe por pantalla al usuario del hecho de la inexistencia de una JRE adecuada y que además le de opción a escoger como solucionar el problema:

Para la parte gráfica y la comprobación de la existencia de la JRE adecuada en el sistema podemos hacer uso de las potentes librerías Qt de TrollTech (El escritorio para linux KDE está basada en ellas). Estas librerías están bajo licencia dual y son totalmente libres si se utilizan para un proyecto libre – en caso de ser comercial hay que pagar unas “royalties” por su uso-. Estas librerías son multiplataforma, lo que nos permite escribir un único programa en C++ para actuar como lanzador de aplicaciones Java y compilarlo luego natívamente en cada una de las plataformas en las que queramos que se distribuya la aplicación.

Para distribuir el lanzador Qt en su versión Windows es necesario adjuntar en el mismo directorio de la aplicación de instalación las siguientes librerías; mingwm10.dll, Qtcore4.dll y QtGui4.dll.

Otra opción para evitar la necesidad de una JRE que es menos utilizada, pero que en algunos casos incluso podría ser beneficiosa en muchos aspectos, consiste en la compilación nativa de nuestras clases Java a las distintas plataformas para las que queremos desplegar el sistema.

Es lo que se conoce como compiladores “Ahead-Of-Time” o compiladores estáticos o nativos. Existen algunos compiladores de este estilo que permiten que nuestras clases java sean convertidas a un ejecutable específico de plataforma, por ejemplo un EXE para windows o un binario ELF para Linux o un APP para MacOSX. Este tipo de solución suele generar código que se ejecuta de manera más eficiente que la interpretación de bytecode por parte de una máquina virtual. Además nos facilita la instalación e integración perfecta sobre la plataforma objetivo. Sin embargo, actualmente no existen muchas opciones libres para realizar esta compilación. Los chicos de GNU están extendiendo su potente compilador gcc con una variante denominada gcj que parece prometer bastante. Actualmente permite la compilación de numerosos programas Java en diferentes modos:

  • Código fuente java directamente a código máquina nativo

  • Código fuente Java a bytecode (archivos class)

  • Java bytecode a código máquina nativo

Desgraciadamente existen aún numerosas clases de la librería de Java 2ª edición que no puede compilar . Especialmente las relacionadas con la creación de interfaces gráficas con componentes AWT o Swing. Se pretende que la convergencia del compilador GCJ con el proyecto Gnu Classpath – que dispone de una implementación libre bastante avanzada de todos los paquetes java de la 2ª edición – permitirá la compilación nativa, teóricamente, de cualquier aplicación Java (por lo menos en Linux o en cualquier sistema unix).

Conclusión.

A la hora de distribuir software para instalación basado en Java se deben contemplar numerosos aspectos. Hay que distinguir si la aplicación desarrollada es de instalación pública o privada, va destinada a un número limitado de PC’s o a varias decenas o cientos, frecuencia de actualizaciones, nivel de conocimientos informáticos esperados de los usuarios finales, recursos disponibles en los ordenadores para los que se instalará la aplicación, necesidades de integración con el escritorio y/o sistema etc…

Según nuestro criterio y para facilitar la distribución y instalación de aplicaciones JAVA podríamos resumir los escenarios más importantes y las posibles recomendaciones para cada uno de ellos a modo del siguiente cuadro resumen:

Intranet                                                                Internet                                                                Grupo Reducido de usuarios             

i la aplicación debe correr en muchos ordenadores y algunos de ellos cuentan con pocos recursos es aconsejable replantear su diseño para realizar la aplicación en versión web.

En otro caso JNLP es una buena opción de distribución.

Usar el sistema LDAP o AD(en windows) para ayudar en la distribución. Por lo menos en el despliegue de un enlace con el icono apropiado en el escritorio para que los usuarios noten y puedan acceder a la nueva aplicación a través de él.

Si la aplicación está a disposición pública para su descarga, JNLP es un buen método de distribución general. No obstante si la necesidad de actualizaciones constantes no es un requisito importante y queremos que el usuario se sienta cómodo con la integración de la aplicación en su sistema darle la posibilidad de descarga de un lanzador/cargador y/o programa de instalación para su sistema específico simplificará su instalación y la percepción positiva sobre la misma.

Si es importante el rendimiento y queremos que la aplicación sea completamente nativa y no dependa de un JRE utilizar un compilador “Ahead-of-time” puede ser una opción interesante.

Lanzador/cargador y/o programa de instalación específico para su plataforma que se integre de manera nativa con el resto de las aplicaciones para que el usuario no perciba siquiera que está haciendo uso de una aplicación JAVA.

Al usuario acostumbrado a java darle la posibilidad de ejecutar la aplicación al menos del siguiente modo:

java -jar myapp.jar

Si es importante el rendimiento y queremos que la aplicación sea completamente nativa y no dependa de un JRE utilizar un compilador “Ahead-of-time”

Tabla de diferentes herramientas de apoyo a la creación, empaquetado, carga, lanzamiento etc. de aplicaciones java.

1.Compiladores Ahead-of-time para java   2.Wrappers y lanzadores nativos para aplicaciones Java (jre check) 3.Creación de instaladores para aplicaciones Java

Libres

GNU GCJ classpath

izpack-launcher

IzPack

launch4j

Roxes Ant tasks

Comerciales

Excelsior JET

exe4j

InstallAnywhere

NewMonics PERC

JExeCreator

InstallShield

install4j

(c) 2006 Pere Crespo Molina
This work is licensed under a Creative Commons
Attribution-ShareAlike License.
http://creativecommons.org/licenses/by-sa/2.0/

5 thoughts on “Métodos de distribución de aplicaciones JAVA”

  1. SOLICITO ANALISIS DE :CARACTER�STICAS TÉCNICAS

    El sistema Univex esta desarrollado en un esquema multi-capas en
    ambiente gráfico con procesos que pueden ejecutar tanto en el cliente
    como en el servidor, tiene un esquema distribuido de varias capas que
    permiten independizar el cliente, la base de datos y la lógica del negocio
    en servidores diferentes o si es necesario integrar todo en una sola
    máquina. Cuenta con una interfaz dinámica en forma de árbol que
    permite ser escalada con facilidad a otros esquemas.

    Servidor de Datos:

    1. Univex no requiere una base de datos especial para su ejecución, sin
    embargo exige que sea relacional con SQL y que proporcione como
    mínimo el manejo de Vistas que permitan modificación, adición y
    borrado, y disparadores en la base de datos (triggers). Por lo tanto
    puede acoplarse a DBMS como SqlServer 2000, etc.,
    2. El sistema operativo debe ser Windows 2K Server.
    3. Para la versión completa del sistema se requieren 150 MB de disco
    en la base de datos y 1GB adicional para datos históricos por cada
    1000 Estudiantes que se deseen manejar en el sistema.
    4. Se requiere como mínimo un procesador Intel Pentium
    IV o
    equivalente CISC con velocidad de 3.0 Ghz (reales) o superior.
    5. Un mínimo 2GB de memoria principal
    6. Al menos una tarjeta de red de como mínimo de 100Mbps.
    La configuración anterior permite manejar de forma optima un promedio
    de diez (10) conexiones simultaneas a la base de datos y cada conexión
    extrayendo o guardando información de un promedio de 500Kb, con un
    tiempo de respuesta de aproximadamente dos segundos. El numero de
    conexiones simultaneas inactivas o en espera lo establece la
    configuración de la base de datos, y/o el número de licencias del
    mismo, y también la cantidad disponible de memoria. A mas
    conexiones, menos memoria disponible u otras conexiones de otro tipo;
    menor será el desempeño del sistema.

    Si la configuración es inferior a la solicitada el tiempo de respuesta
    decae y el número de las conexiones simultaneas es inferior.

    Forjamiento de Herramientas Exactas Página
    29 de 37

    Servidor Web

    El sistema Univex utiliza paginas JSP con Java, lo cual representa una
    amplia gama de sistemas operativos que pueden ser utilizados para este
    fin:

    1. El Software del Servidor Web debe ser Apache Tomcat Versión 4.1.x
    2. Debe tener instalado como soporte al Tomcat un versión de JAVA
    JRE 1.3.1_02 o superior
    3. Los procesos y formularios Web ocupan menos de 50 MB de espacio
    en disco.
    4. El procesador recomendado debe ser Intel Pentium IV o equivalente
    CISC, con una velocidad mínima 2.0 Ghz (reales) y 1GB de memoria
    principal.
    7. Al menos una tarjeta de red de como mínimo de 100Mbps.
    Esta configuración se establece con base en un promedio de diez (10)
    conexiones simultaneas extrayendo páginas del servidor con un tiempo
    de respuesta promedio de dos (2) segundos para cada solicitud, y
    asumiendo que exista la disponibilidad de conexiones del servidor de
    datos, las restantes solicitudes quedan en espera hasta que se libere
    una de las que están siendo atendidas. El numero de conexiones
    simultaneas inactivas o en espera lo establece la configuración del
    servidor y la capacidad de memoria disponible del mismo.
    El máximo tamaño de una solicitud es de 50Kbytes para una pagina JSP
    convertida en html y cargada con datos más el tamaño de los gráficos
    que se incluyan en las páginas.

    Solicitudes 25K de XML 58K de XML
    1 40 ms 90 ms
    2 75 ms 220 ms
    3 125 ms 390 ms
    4 160 ms 550 ms
    5 200 ms 740 ms

    Pruebas tomadas de la pagina de Apache.org con un equipo
    configurado así:

    Red Hat 8.0 server, AMD XP 2ghz, 1Gb DDR Ram, Tomcat
    4.1.19, Sun Jdk1.4.1_01, IBM Jdk1.4, JMeter 1.7

    Forjamiento de Herramientas Exactas
    Página
    30 de 37

    La progresión sugiere que a 58K tardara alrededor de dos segundos las
    diez (10) solicitudes simultaneas.

    Servidor de Aplicaciones

    1. Los procesos del sistema Univex están desarrollados en Java y deben
    ser instalados en un computador con Windows 2K, 2K Server XP, NT,
    2K3 Server, sobre una máquina cliente dedicada o un equipo
    servidor.
    2. Este debe tener como mínimo 1GB de memoria principal.
    3. El procesador debe ser un Intel Pentium IV o equivalente en CISC
    con una velocidad de al menos 2GHz (Reales)
    4. Al menos una tarjeta de red de como mínimo 100Mbps.
    Si se desea instalar el servidor de aplicaciones y el servidor web en una
    misma máquina debe tener la siguiente configuración:

    5. El servidor debe tener como mínimo 2GB de memoria principal.
    6. El procesador mínimo debe ser un Intel Pentium IV o equivalente en
    CISC, con una velocidad de al menos 2,8GHz (Reales)
    Equipos Cliente:

    1. Las estaciones cliente requieren el sistema operativo Windows XP,
    2000 o NT WS.
    2. Se requiere una configuración de hardware con valores mínimos de:
    Procesador Pentium IV de 2Ghz (reales), 512 MB en RAM,
    3. Espacio disponible de 10MB en disco duro para la instalación básica
    y 6MB para cada módulo a ser instalado.
    4. Además se requiere monitores
    con resolución de 840×600 como
    mínimo para tener una visión completa de los formularios,
    5. tarjeta de red de 100Mhz,
    6. Tener instalado el Java JRE 1.3.1_02 y BDE de Borland con
    los
    drivers nativos del SQLServer y el ODBC de SqlServer.

    Forjamiento de Herramientas Exactas Página
    31 de 37

    ESQUEMA Y ARQUITECTURA DEL
    SISTEMA UNIVEX

    El sistema Univex se plantea de forma que se independicen las plataformas de
    hardware, sistema operativo y manejador de base de datos, para esto se
    incorporan tres capas dentro del sistema y dos interfaces de usuario
    adicionales, cada capa tiene un objetivo especifico dentro del esquema y
    permite utilizar el esquema Cliente/ Servidor o el esquema distribuido de
    acuerdo a las necesidades y capacidades físicas de la universidad en donde se
    instale.

    Capa de datos: Tiene la responsabilidad de almacenar los datos del sistema
    al igual que el comportamiento de las interfaces del sistema, permitiendo
    establecer un flujo hacia y desde las otras dos capas utilizando el DBMS como
    validador de la integridad referencial y de los rangos básicos de datos, de esta
    forma es posible independizar la base de datos del sistema pudiendo así
    utilizar cualquiera.

    Capa de lógica: Esta capa se encarga de realizar los procesos que definen la
    lógica del negocio, lo que en una base de datos serían los procedimientos
    almacenados, aquí se separa de la base de datos para no casarla con esta y
    permitir escalar el esquema a una estructura distribuida.

    Capa de interfaz: Esta capa es dinámica y puede permitirle a los usuarios
    ver y modificar la información de muchas más formas que los esquemas
    multiusuario y Cliente/ Servidor tradicional, si se requiere puede ser creada
    una nueva capa que utilice nuevas tecnologías sin necesitar rehacer todo el
    sistema. Se plantean dos interfaces con el usuario: la primera con programas
    ejecutables que correrían en las máquinas locales y accederían directamente a
    las otras capas, y una interfase web que ayudara a presentar y recibir los
    datos desde Internet o una Intranet.

  2. Pingback: Buy matcha
  3. Pingback: buy backlinks

Leave a Reply

Your email address will not be published. Required fields are marked *