Tips de JAVA - J2EE

¿Sabes qué es un pool de conexiones?   (javaHispano) Las conexiones a cualquier medio ( base de datos relacional, sistemas legacy, etc. ) son un recurso caro. Normalmente existe un número limitado de conexiones que puede mantener abiertas un determinado servidor, dependiendo de su memoria, su potencia, del sistema al que estamos accediendo, etc.

Muchos sistemas que actúan como servidores necesitan mantener una gran escalabilidad y por lo tanto no pueden arriesgarse a que se agoten las conexiones. ¿Qué se puede hacer?

Un pool de conexiones soluciona esta técnica. Se trata de un conjunto limitado de conexiones que se reutilizan constantemente para dar servicio a los diferentes clientes. De este modo se aumenta la escalabilidad y también el rendimiento ya que no será necesario abrir las conexiones constantemente.

Normalmente un pool de conexiones se inicializa con un número de conexiones determinado. Casi todos los servidores modernos traen normalmente pools de conexiones integrados, aunque crearse uno propio no es demasiado difícil.

En un pool de conexiones cada una de éstas es utilizada por múltiples clientes diferentes. Los clientes abren la conexión, acceden al servicio a través de ella y por último cierran dicha conexión. Es importante que el cliente abra y cierre la conexión en cada acceso al servicio ya que si no la cerrase no la estaría devolviendo al pool y por lo tanto correríamos el riesgo de agotar los recursos del servidor.

Un driver de base de datos puede ofrecer soporte de pools de conexiones si implementa la interfaz javax.sql.DataSource. Este soporte es optativo en JDBC 2.0 y obligatorio en JDBC 3.0

¿Sabías que utilizar el PrintWriter que ofrece el objeto HttpServletResponse para generar contenido no siempre es la mejor opción?   (javaHispano) En un Servlet normalmente la manera más típica de generar contenido es la siguiente: public void doGet(HttpServletRequest request, HttpServletResponse response) { PrintWriter out = response.getWriter();out.println(...);out.write(...);}

Esto tiene un inconveniente. Cada uno de los caracteres se codifican internamente de char a byte. Cuando el contenido que queremos mostrar ya se encuentra codificado ( por ejemplo ficheros, urls, datos de base de datos que hayamos cogido con métodos como resultSet.getAsciiStream() ) nos encontramos con que estamos realizando miles y miles de transformaciones redundantes que no aportan nada.

Normalmente, en estos casos, es preferible utilizar streams para generar la salida. De este modo se realiza un transferencia directa de bytes a bytes sin realizar ninguna transformación.

Jason Hunter, en el libreo Java Enterprise Best Practices de O'Reilly expone el ejemplo siguiente: import java.io.*;import java.util.prefs.*;import javax.servlet.*;import javax.servlet.http.*; public class NoConversions extends HttpServlet { String name = "content.txt"; // Fichero a enviar public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String file = getServletContext( ).getRealPath(name); res.setContentType("text/plain"); OutputStream out = res.getOutputStream( );

returnFile(file, out); } public static void returnFile(String filename, OutputStream out) throws FileNotFoundException, IOException { InputStream in = null; try { in = new BufferedInputStream(new FileInputStream(filename)); byte[ ] buf = new byte[4 * 1024]; // 4K buffer int bytesRead; while ((bytesRead = in.read(buf)) != -1) { out.write(buf, 0, bytesRead); } } finally { if (in != null) in.close( ); } }}

Como resultado, utilizando un fichero de prueba de 2Mb se ha obtenido un aumento del rendimiento del 20% en Tomcat 3.x y del 50% en Tomcat 4.x.

¿Sabías que no conviene utilizar el modelo SingleThreadModel del API de Servlets y JSP?   (javaHispano) Los desarrolladores cuando crean JSPs y Servlets se enfrentan a un reto importante: como sincronizar el acceso de múltiples clientes.

Tradicionalmente se han considerado dos opciones: realizar la sincronización manualmente o implementar el modelo SingleThreadModel.

Cuando un Servlet o un JSP implementan el modelo SingleThreadModel el contenedor web garantiza que nunca habrá más de una petición accediendo a la misma instancia de Servlet o JSP.

Internamente esto se consigue de dos modos: creando una cola de peticiones para entrar a cada Servlet y JSP que implementen el modelo SingleThreadModel o creando un pool de instancias del Servlet de modo que se garantice que a cada instancia accede únicamente una petición.

La primera de las opciones supone una degradación importante de rendimiento por lo que normalmente se implementa la segunda. El problema surge en que con este segundo modelo múltiples peticiones accederan al mismo Servlet simultáneamente ( ojo, no a la misma instancia del Servlet ).

Esto es un problema muy grave ya que los desarrolladores pueden creer que no necesitan sincronizar los elementos compartidos a los que acceden ( por ejemplo bases de datos, variables críticas, etc. ) y sin embargo la realidad es que se está accediendo simultánemanete a dichos elementos desde diferentes instancias del Servlet.

Por lo tanto, la diferencia entre utilizar el modelo SingleThreadModel y no utilizarlo es mínima ya que sigue siendo necesario implementar el código de sincronización. Más importante aún, como hemos visto utilizar dicho modelo puede llevar a engaños y producir problemas de difícil depuración.

¿Sabes qué es un motor de persistencia?   (javaHispano) Nos referimos con el término de persistencia a la capacidad de un elmemento para hacerse persistente, es decir, a la capacidad de poder almacenar el estado de un elemento de modo que sea posible recuperarlo posteriormente.

Atendiendo a esta definición, un motor de persistencia es un sistema de desarrollo, también conocido como framework o librería, que nos permite hacer persistentes los elementos de nuestras aplicaciones o modelos. Estos elementos pueden ser objetos, tipos primitivos de datos, arrays, etc., mientras que la persistencia se puede realizar sobre múltiples destinos: bases de datos relacionales, bases de datos orientadas a objetos, sistemas legacy, etc.

Actualmente, esta definición resulta bastante limitada. Los motores de persistencia no sólo nos permiten hacer persistentes nuestros objetos, sino que también nos permiten realizar consultas complejas que nos ofrezcan jerarquías completas de objetos, realizan optimizaciones automáticamente, resuelven asociaciones y dependencias, etc.

La ventaja de utilizar un motor de persistencia es la sencillez del modelo de programación que promueven. Un programador ya no se tiene que preocupar de realizar consultas manuales con JDBC y simplemente utilizará las funciones que le ofrece el motor. Estas funciones además de realizar múltiples optimizaciones de rendimiento le garantizan que la aplicación será compatbible con todas las bases de datos que soporte el motor de persistencia que utilice el programador.

Por ejemplo. Con el motor de persistencia Hibernate guardar en base de datos una instancia de una clase Gato con sus n crías se reduciría a : Gato gato = new GatoDomestico();Gato cria = new GatoDomestico();...Set crias = new HashSet();crias.add(cria);gato.setCrias(crias);session.save(gato);

Casi todos los motores de persistencia utilizan ficheros de configuración (normalmente en XML) para definir la asociación entre las diferentes clases y almacenamiento secundario. Por otra parte, normalmente estas clases son generadas automáticamente a partir de estos ficheros de configuración por loq ue el desarrollador tampoco tiene que perder el tiempo creándolas.

Ejemplos de motores de persistencia son Hibernate, Castor o OJB

¿Sabes por qué en los EJB cuando accedemos a una referencia remota desde un EJB o desde un cliente tenemos que utilizar PortableRemoteReference. narrow(..)?   (javaHispano) EJB utiliza como protocolo de comunicación remoto RMI-IIOP. Este protocolo permite unir los mundos de Java (RMI) y CORBA (IIOP) de modo que un cliente en cualquier lenguaje pueda comunicarse con un Enterprise Java Bean escrito en Java.

Como CORBA es una plataforma que soporta múltiples lenguajes se nos presenta un problema. No todos los lenguajes de programación soportan el concepto de cast por lo que es imposible realizar automáticamente casts de objetos que provengan de RMI-IIOP a objetos Java. Con el método PortableObjectReference.narrow(objeto, clase) explicitamos que queremos transformar ese objeto a una instancia de la clase que le pasamos como parámetro.

Esto no deja de ser bastante molesto cuando estamos trabajando únicamente en entornos basados en Java pero es el precio de la interoperabilidad.

¿Sabes lo que es una DMZ?   (javaHispano) Una DMZ, también conocida como Demilitarized Zone o zona desmilitarizada, es un ordenador o una pequeña subred que se sitúa entre el exterior y una intranet empresarial. Está situada pues entre dos firewalls y su función es evitar accesos peligrosos desde el exterior. Además, sirve de puente entre la red interna e Internet recibiendo las peticiones de los empleados y redireccionandolas al lugar apropiado. La DMZ normalmente aloja las páginas web de la empresa. Estas páginas web no deberían acceder a datos sensibles de la compañía. Las bases de datos con datos realmente importantes deberían ser accesibles únicamente desde el interior de la red o a través de una red privada virtual.

¿Sabes qué es un EIS?   (javaHispano) El término EIS proviene de Enterprise Information System y se utiliza para referirse a cualquier sistema que proporciona una infraestructura para el soporte de la información de una empresa.

Un EIS ha de ofrecer una serie de servicios a sus clientes, exponiendose éstos a través de una serie de interfaces locales o remotas, es decir, el cliente normalmente puede trabajar

localmente al EIS o desde un puesto de su intranet o incluso desde fuera de ésta.

Ejemplos típicos de sistemas EIS son:

Sistemas ERP Sistemas de procesamiento de transacciones en mainframes Bases de datos heredadas

Normalmente los EIS ofrecen una API para el acceso externo desde otras aplicaciones. Esta API suele exponer los servicios más importantes de un EIS. Cada sistema y cada fabricante tiene sus propias APIs y estas son muy diferentes entre si por lo que la integración con múltiples sistemas EIS suele ser compleja. Java tiene un magnifico soporte de este tipo de sistemas gracias a la especificación JCA ( Java Connector Architecture ) que especifica un conjunto de interfaces estándar para acceder a cualquier tipo de sistemas EIS.