Archive for the ‘Arquitectura de software’ Category

Ejecutar Java en plataformas .NET y MONO

Jueves, septiembre 30th, 2010

Sí, como lo oyen: Java en .NET.

No sé si todos lo sepan pero .NET tiene un Common Language Runtime o CLR (Lenguaje común en tiempo de ejecución) que es el componente de máquina virtual de la plataforma .NET de Microsoft.

Mono es un proyecto Open Source iniciado por Ximian y actualmente impulsado por Novell (tras la adquisición de Ximian) para crear un grupo de herramientas libres, compatibles con .NET, según lo especificado por el ECMA (y proporciona un CLR, además de soporte a algunos lenguajes como C#, MonoBasic, GTK# etc).

Alguna vez escuché a los evangelizadores de .NET decir que su máquina virtual es una evolución natural de la Java Virtual Machine (JVM). ¿Por qué? Porque Java produce bytecodes que se interpretan en la JVM. Si los bytecodes son portables porque la implementación de la JVM es un estándar (independiente del Sistema Operativo o hardware) es lógico hacer lo mismo con cualquier lenguaje y esto haría que cualquier lenguaje pueda funcionar como Java, es decir independiente del Sistema Operativo y del hardware. Así nace CLR, una máquina virtual para múltiples lenguajes. Creado CLR lo único que faltaría es el compilador que genere código intermedio (llamado Common Intermediate Language – CIL) para el lenguaje que se desee ejecutar en el CLR.

[ Breve paréntesis: ¿Por qué no hacemos un compilador que nos permita programar con Logo o Basic y ejecutar lo programado en la JVM? No he visto ningún proyecto similar. Y la idea no deja de ser interesante y teóricamente posible.]

Bueno, buscando, era obvio que era cuestión de tiempo para que crearan eso que permitiese ejecutar Java dentro del CLR.
El proyecto es IKVM.NET:

IKVM.NET es una implementación de Java para Mono y Microsoft.NET Framework. Incluye los siguientes componentes:

  • Una máquina virtual de Java implementada en. NET
  • Implementación de las clases básicas de Java en .NET
  • Herramientas que permiten la interoperabilidad entre Java y .NET

Lo bueno, es que funciona bien con aplicaciones de consola (habrá que ver el rendimiento, en MONO y en CLR .NET). Lo malo, es que no funcionan bien las interfaces gráficas (olvídate de usar Swing). Como alternativa creo que podrías crear un programa híbrido con clases Java, usando interfaces gráficas .NET.

Los links de interes:

Mono & Java
Interfaces gráficas Java en Mono… que decepción

Java Server Faces 2: Un vistazo

Miércoles, septiembre 29th, 2010

JSF (Java Server Faces) siempre será una muy buena opción al momento de buscar frameworks que nos den soporte a la parte de presentación de una aplicación WEB en Java. Lamentablemente no he encontrado el editor ideal para mis necesidades (motivo por el que mis últimos desarrollos los orientaré a GWT).

JavaServer Faces (JSF) es una tecnología y framework para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías como XUL.

JSF incluye:

  • Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.
  • Un conjunto por defecto de componentes para la interfaz de usuario.
  • Dos bibliotecas de etiquetas personalizadas para JavaServer Pages que permiten expresar una interfaz JavaServer Faces dentro de una página JSP.
  • Un modelo de eventos en el lado del servidor.
  • Administración de estados.
  • Beans administrados.

La especificación de JSF fue desarrollada por la Java Community Process como JSR 127, que definía JSF 1.0 y 1.1, JSR 252 que define JSF 1.2 y JSR 314 para JSF 2.0

A continuación agrego unos tutoriales de IBM que pueden aclarar un poco como desarrollar con JSF:

La imagen siguiente corresponde al editor visual de JSF de MyEclipse. Pero es importante que sepan que se incluye un editor similar en Eclipse, así que ya ustedes decidan cual usar:

JSF Page Designer

Este editor también puede ser usado para editar JSP’s. Para convertir el Web Page Editor en el editor por defecto de JSP’s, se debe hacer lo siguiente:

  1. Vaya a “Window” -> “Preferences…” -> “General” -> “Editors” -> “File Associations”
  2. En el “File Associations” seleccione “*. jsp”
  3. En “Associated editors”, seleccione “Web Page Editor”
  4. Seleccione el botón “Default”

Y listo.

Espero este breve vistazo a JSF les sirva de ayuda.

 
 
 

Un framework WEB que nos permita editar interfaces gráficas visualmente

Miércoles, septiembre 29th, 2010

Sí, un framework WEB que nos permita editar interfaces gráficas visualmente es el Santo Grial de todos los desarrolladores Java: Se trata de lograr editar interfaces gráficas web como si se tratase de una vieja aplicación desktop.

He escogido tres tecnologías interesantes que pueden ayudarnos en esta tarea, que permiten ejecutarse en múltiples sistemas operativos (y múltiples browsers):

  • Yahoo! UI Library
  • Microsoft Silverlight
  • Google Web Toolkit

Yahoo! UI Library
Yahoo User Interface(YUI), una serie de bibliotecas escritas en JavaScript, para la construcción de aplicaciones interactivas (RIA). Liberadas bajo licencia BSD por parte de la compañía Yahoo. Dichas bibliotecas son utilizadas para el desarrollo web específicamente para ser usadas como la programación de aplicaciones de escritorio, con componentes vistosos y personalizables y con una amplia implementación con AJAX.

Para integrarlo con Java he visto dos páginas interesantes:

  • Yahoo’s Rich Web UIs for Java Developers: Java developers who develop web applications with server-side frameworks often don’t have the JavaScript expertise to create rich user interfaces. Learn how Yahoo User Interface (YUI) can help bridge that gap.
  • Putting a YUI Face on a Java Web Application: Learn how to use Yahoo User Interface (YUI) Web components to develop a real world application with just the right mix of JavaScript/AJAX.

Sin embargo en este punto no he encontrado una herramienta que me ayude a hacer un diseño fácil de estas interfaces gráficas.

Tres referencias importantes que nos acercan a un “editor” WYSIWYG para YUI:

Microsoft Silverlight
No se asusten, se puede integrar con Java y además es independiente del browser. Microsoft Silverlight es una estructura para aplicaciones web que agrega nuevas funciones multimedia como la reproducción de vídeos, gráficos vectoriales, animaciones e interactividad, en forma similar a lo que hace Adobe Flash. Silverlight compite con Adobe Flex, Nexaweb, OpenLaszlo y algunas presentaciones de componentes AJAX. Actualmente se distribuye de forma gratuita.

Para Silverlight hay herramientas comerciales y libres, incluso un plugin de Eclipse. Sin embargo las herramientas que permiten hacer más sencillo el diseño de las interfaces son de pago.

Como integrarlo con Java:

Google Web Toolkit
Framework creado por Google que permite ocultar la complejidad de varios aspectos de la tecnología AJAX. Es compatible con varios navegadores, lo cual es notorio ya que cada navegador suele necesitar código específico para lograr un front-end correcto en una aplicación web. El concepto de Google Web Toolkit es bastante sencillo, básicamente lo que se debe hacer es crear el código en Java usando cualquier entorno de desarrollo (IDE) de Java y el compilador lo traducirá a HTML y JavaScript. Se distribuye bajo la Apache License, v2.0.

La verdad es el framework del que encontré más información y lo que más me gustó fue facilidad de usar el GWT Designer que ofrece (que es robusto y libre). Justo lo que buscaba.

Página oficial: http://code.google.com/intl/es-ES/webtoolkit/

Y para integrarlo con aplicaciones Java:

Algo importante es que Google nos facilitó un designer, una herramienta para diseñar interfaces con GWT de forma visual, WYSIWYG. Vea la noticia aquí: Google publica plugins de Instantiations gratuitamente..

GWT Designer: Permite crear aplicaciones Ajax de forma gráfica usando Google Web Toolkit. Para muchos la verdadera razón de que Google compró a Instantiations. Sin duda se extrañaba una herramienta gratuita y soportada por el mismo Google para generar interfaces con GWT. Si bien GWT ha ganado bastantes usuarios en los últimos años, GWT Designer va a bajar la barrera para que aquellos que no lo usan se acerquen al framework y va a facilitar mucho la vida a los usuarios existentes.

He preparado una entrada dedicada al primer demo que desarrollé con GWT y Eclipse, aquí. Y si no conocen como configurar esos plugins en Eclipse pueden dirigirse a esta otra entrada.
 
 
 

Usar PHP y JEE juntos

Miércoles, septiembre 29th, 2010

Desde hace unos días me ha saltado la duda de qué usar en un nuevo desarrollo: Si es mejor PHP o JEE, o mejor usar PHP para la presentación y JEE para programar el core.

Cómo recordarán, tengo una entrada respecto a ‘Delphi for PHP’ (D4PHP) un producto que ofrece una forma rápida de desarrollar interfaces gráficas en PHP.

Tengo que decirles que una de mis motivaciones principales es lograr un entorno de desarrollo donde de manera visual pueda editar las interfaces gráficas, como lo que ofrece D4PHP. Claro, me gustaría más si se puede desarrollar en un producto Open Source y en el lenguaje Java, pero quiero evaluar de forma objetiva las opciones disponibles en el mercado.

Es indudable que las ventajas de menor consumo de memoria hacen deseable a PHP. PHP ya tiene muchos sistemas para administración de contenidos (páginas) que pueden ser modificados o ampliados. Sin embargo, creo que JEE (y la pléyade de frameworks alrededor) permiten mucha flexibilidad y orden en el desarrollo de las cosas.

Sí, hay ventajas y desventajas que habrá que evaluar individualmente en cada caso. Y en el tema de recursos, rentar un hosting sencillo o rentar un servidor virtual tiene una diferencia de precio. Y si es un hosting Java o PHP también varía el precio. Qué buscamos con el servidor:

  • Tener un tiempo de respuesta aceptable.
  • Soportar la operación de los múltiples usuarios concurrentes.
  • Un uptime alto.

Algunas variables a tomar en cuenta para decidirse por el hosting son:

  • Cantidad de memoria disponible.
  • Procesador disponible en el servidor.
  • Espacio en disco.
  • Experiencia de los desarrolladores.
  • Conocimiento del lenguaje con el que se desarrollará, etc.

Navegando por la web buscando mas pistas sobre como evaluar correctamente el uso de PHP o JEE encontré un artículo algo viejito de IBM con una forma de integrar PHP y J2EE en Websphere Application Server (artículo del año 2005).

Las ligas útiles son:

Espero les sea de ayuda.
 
 
 
PD: Encontré un framework que me permite diseñar interfaces gráficas web en Java como si se tratasé de Swing. ¿Han oído de GWT? Vean el artículo al respecto, aquí.
 
 
 

Creando hilos en Java

Sábado, septiembre 11th, 2010

En el inicio de los tiempos (para Java) habían dos formas de crear hilos:

  • La primera forma de crear un thread es simplemente extender la clase “Thread”.

    public class ThreadExample extends Thread {
        public ThreadB() {
            super("ThreadB");
        }
        public void run() {
            //Code
        }
    }
    //crea un objeto "threadExample".
    //usa "threadExample.start()" para iniciar el hilo.
    
  • La segunda forma es implementar la interfaz “Runnable”.

    public class RunnableExample implements Runnable {
        public void run() {
            //Code
        }
    }
    //crea un objeto "runnableExample".
    //usa "new Thread(runnableExample).start()" para iniciar el hilo.
    

¿Cúal de las dos formas es preferible?

La segunda forma es preferible, ya que el hecho de implementar una interface no impide extender de otra clase (o implementar otras interfaces). La composición (“composition”) es el camino “purista” a seguir. esto permite un bajo acoplamiento y da libertad de a futuro poder cambiar la forma de iniciar los hilos.

Pero… eso era el Java de antes.

Actualmente es más recomendable usar las nuevas funcionalidades proporcionada para el manejo de hilos. Es más recomendable el uso de Callables y FutureTasks. El soporte para los tiempos de espera (timeouts), para la cancelación y el manejo del conjunto de hilos (thread pooling), y las nuevas funciones de concurrencia son mucho más útiles que manejar montones de hilos en crudo y ser uno mismo el que implemente ese manejo.

La interfaz Callable es muy parecida a Runnable, con la diferencia que Callable permite devolver un objeto de la ejecución del método call (que funciona similar al run de Runnable).

Notar que Callable es una interfaz tipada, en este caso pongo un ejemplo con el tipo Object, pero bien se pudo definir el tipo de dato a regresar por call como String, Integer, o lo que desees.

	//El tipado debe ser definido por el tipo de resultado de call: Callable
	private class CallableExample implements Callable {

		/*
		 * Método sobreescrito (sin Javadoc propio)
		 * @see java.util.concurrent.Callable#call()
		 */
		@Override
		public Object call() throws Exception {
			Object obj = null;
			//implementar negocio y dar valor a "obj"
			return obj;
		}

	}

Para usos prácticos esto significa que yo estoy esperando una respuesta de Callable y que seguramente eso se traducirá en tareas síncronas:

//Colección para mantener una liga a todas las tareas
Collection tasks = new ArrayList();

//creando cada tarea
CallableExample yt1 = new CallableExample();
//Creando más tareas...

//Agregando tareas a la colección
tasks.add(yt1);
//Agregando más tareas...

//Usar el ejecutor:
ExecutorService exec = Executors.newFixedThreadPool(5);

//La lista de respuesta debe ser del tipo: List>
List> results = exec.invokeAll(tasks);

En el caso de tareas de las cuales no esperamos una respuesta, usamos la interfaz Runnable. Seguramente eso está ligado a tareas asíncronas.


/* Get an executor service that will run a maximum of 5 threads at a time: */
ExecutorService exec = Executors.newFixedThreadPool(5);

/* For all the 100 tasks to be done altogether... */
for (int i = 0; i < 100; i++) {
    /* ...execute the task to run concurrently as a runnable: */
    exec.execute(new Runnable() {
        public void run() {
            /* do the work to be done in its own thread */
            System.out.println("Running in: " + Thread.currentThread());
        }
    });
}

/* Tell the executor that after these 100 steps above, we will be done: */
exec.shutdown();

try {
    /* The tasks are now running concurrently. We wait until all work is done,
     * with a timeout of 50 seconds: */
    boolean b = exec.awaitTermination(50, TimeUnit.SECONDS);
    /* If the execution timed out, false is returned: */
    System.out.println("All done: " + b);
} catch (InterruptedException e) { e.printStackTrace(); }

Espero esto te sea de ayuda.
 
 
 
Algunas de las páginas que visité para hacer esta entrada fueron: