Buenas practicas con J2EE€¦ · Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005 Arquitectura Consejo 2: No trabajar mucho => Automatización Ant No debemos

Buenas prácticascon J2EE

Pequeños consejos para saliradelante en desarrollos conJ2EE

Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005

¿Quién es Martín Pérez? Ingeniero de sistemas por la Universidad de A Coruña

Ingeniero de Software en la empresa DINSA Soluciones, GrupoBanesto

Sun Certified Java Programmer, Sun Certified Java Developer, SunCertified Business Component Developer

Responsable del desarrollo del sistema de gestión de costes delComplejo Hospitalario Universitario Juan Canalejo de A Coruña

Miembro activo y colaborador de javaHispano:http://www.javahispano.org

Creador de jLibrary, un CMS de escritorio Open Source:http://jlibrary.sourceforge.net


Índice

Arquitectura Presentación Lógica de negocio Persistencia Referencias


Índice



Arquitectura

Consejo 1: No utilizar J2EE – si no hacefalta Analizar el escenario de la aplicación

¿Estamos ante una plataforma demasiado‘Microsoft’?

Tenemos el suficiente presupuesto ¿Tenemos herramientas que cubran las

necesidades?El mundo empresarial no es sólo J2EE:

.NET, LAMP, Ruby, Python, …


Arquitectura Consejo 2: No trabajar mucho =>

Automatización

Ant No debemos trabajar nosotros, debe ser la máquina No debemos depender de un IDE

Escoger un buen sistema de repositorio (CVS, Subversion)

Utilizar un buen framework de pruebas (Junit, TestNG, etc.)

¿Cuándo se hace todo esto? Al principio, que es cuando sepuede hacer, por tiempo y por complejidad.

Utilizar sistemas de integración continua (CruiseControl)


ArquitecturaCheckout CVS

Compilación

Generación de Código de web, EJBs, WS, …

Tests de pruebas

Construcción depaquetes .jar,

.ear, etc.

Despliegue en servidor de aplicaciones

Tests de pruebas

Automatización eintegración continua


Arquitectura

Consejo 3: Utilizar herramientas degeneración de códigoYa dije que no debíamos trabajar Valorar soluciones como Xdoclet o similaresEvita dependencias con IDEsCon EJB 3.0 proliferará aún más la

generación de códigoSe integran con mecanismos de

automatización


ArquitecturaXDoclet EJB 3.0


Arquitectura Consejo 4: No caer en las diez falacias

(Ted Neward, James Gosling y Peter Deutsch)

La red es fiable La latencia es cero El ancho de banda es infinito La red es segura La topología no cambiará Siempre hay un administrador El coste del transporte es cero La red es homogénea El sistema es monolítico El sistema está finalizado


Arquitectura

Consejo 5: Valorar la neutralidad de lasolución¿Tendré siempre la misma base de datos?¿Tendré siempre el mismo sistema

operativo?¿Tendré siempre el mismo servidor de

aplicaciones?¿Tendré siempre el mismo sistema de

directorio?


Arquitectura

Consejo 6: Conocer bien tu servidor deaplicaciones¿Soporta balanceo de carga? ¿Para clientes

web? ¿Para clientes de escritorio?¿Tiene elementos de valor añadido (Ejs:

caché dinámica, Enterprise Service Bus, …)¿Y la documentación…?¿Tiene herramientas de monitorización y

administración?


Arquitectura

Consejo 7: Utilizar herramientas demonitorización Permiten detectar y resolver problemas Herramientas de análisis de logs

Consultar errores, consola forense, análisis de accesos, …

Herramientas de análisis de rendimiento Algunas permiten configuración de acceso hasta a nivel de

método de EJB Consumo de memoria, número de llamadas, tiempo de

respuesta, tamaño de la sesión, número de sesionesabiertas, …


Arquitectura


Índice



Presentación Consejo 8: Contratar a al menos un

diseñador¿Estas seguro de que sabes hacer un

interfaz serio? Haz la prueba Las administraciones y grandes empresas

exigen concentración en pequeños detalles:colores, plantillas, usabilidad, navegabilidad,…

Muchas veces además de programar, ¡haytambién que vender para poder comer!


Presentación

Consejo 9: Considerar las aplicacionesde escritorio Las aplicaciones de escritorio están resurgiendo Ventajas:

Trabajo más ágil Mayor cantidad de widgets (puede ser decisivo) Trabajo offline Mayores recursos para la presentación: memoria, disco, etc. Integración con el sistema operativo

Plataformas de clientes ricos: Eclipse Rich ClientPlatform, Spring RCP, NetBeans Platform, …


Presentación

Consejo 10: No desdeñar JavaScript El soporte de JavaScript ha mejorado mucho en los últimos

años Permite crear interfaces complejas en la web sin recurrir a

terceras partes (Macromedia, laszlo, etc.) Buzzword: AJAX (Asynchronous JavaScript and XML)

Recarga del árbol DOM asíncronamente con JavaScript Ejemplos: Gmail, Flickr, Google Maps, …

Recientemente se ha añadido a los Blueprints J2EE Validación de formularios en tiempo real Controles sofisticados de UI Refresco de datos Encuestas (polling) a servidores


Presentación


Presentación

Consejo 11: Patrón – Business Delegate Interfaz común en el cliente para acceso al

servidor.Podemos tener múltiples servidores: 2

niveles, tres niveles, servidor trivial ‘paracasa’, entorno de pruebas.

No debe haber accesos al servidor a travésde otra interfaz diferente

Facilita la migración entre tecnologías


Presentación


Presentación Consejo 12: Caché, caché, caché

En aplicaciones de escritorio, aprovechar la memoria disponible parahacer caché

La caché en cliente es muy sencilla, y tiene menos problemas desincronización

Evita accesos redundantes al servidor de aplicaciones

Oportunidades de carga: Al iniciar la aplicación Mientras el usuario no hace nada Siempre que se recuperen datos de servidor

Ideal para aplicaciones que requieran rendimiento crítico


Presentación

Consejo 13: Valorar frameworks webLas soluciones con Servlets/JSP sólo son

aptas para sistemas simplesValorar frameworks web. Incrementan

notablemente la productividad Struts, Tapestry, WebWork, Spring, Echo, ….

Valorar también Java Server Faces ycontenedores de portlets MyFaces, Liferay, …


Presentación

Consejo 14: Con JSP utilizar Tags yminimizar el scriptingCustom tags

Agrupan funcionalidad Pueden ser manejadas por no-programadores Forman páginas más limpias

Utilizar scripting en páginas JSP es mezclarla lógica de negocio y la lógica depresentación


Presentación

Consejo 15: Pregenerar contenido La pregeneración de contenido minimiza el

procesado Muchas aplicaciones web no necesitan ser

totalmente dinámicas Ejemplo: Marca.com ¿Van a cambiar los resultados

del último fin de semana? ¿Va cambiar el resultadode la última carrera de Fórmula 1? …

Los portales suelen utilizar esta aproximación Muchos utilizan repositorios de información:

Documentum, Vignette, jLibrary


Índice



Lógica de negocio Consejo 16: Tener claro cuando usar

EJBs J2EE no es sólo EJB

No se debe usar “porque es guay” o “porque así además lo podemos poner enlos curriculums”, o “porque los de marketing venden mejor la aplicación”

EJB añade complejidad a las soluciones

EJB requiere tener un servidor de aplicaciones

Hacer pruebas en entornos con EJB es una tarea difícil (EJB 3.0 prometesolucionarlo)

EJB es fantástico al trabajar con múltiples fuentes de recursos y en contextosde alta transaccionalidad (acceso simultáneo a múltiples bases de datos,sistemas de mensajería, adaptadores de recursos JCA, etc.)


Lógica de negocio Consejo 17: Preferir beans de sesión

sin estado a beans de sesión conestado Los beans de sesión con estado tienen muy mal rendimiento Problemas con clusters

Almacenar el estado en base de datos o implementar mecanismosde sincronización

Complica las soluciones de balanceo de carga (¿dónde está miestado?)

La mayoría de vendedores de aplicaciones no recomiendan suuso

Alternativa: Bean de sesión sin estado, y pasar el estado comoparámetro


Lógica de negocio

Consejo 18: Patrón – Session FaÇadeSe implementa con un bean de sesión sin

estadoProtege a la interfaz cliente de cambios en el

servidorAumenta el rendimiento al acceder a los

beans de entidad Ideal para una arquitectura orientada a

servicios


Lógica de negocio


Lógica de negocio

Consejo 19: Patrón – Data TransferObject La red es MUY lenta. Recordad las falacias: la

latencia es cero, el coste de transporte es cero Hay que minimizar los accesos remotos Crear objetos de negocio coherentes. Mejora el rendimiento en la comunicación entre EJBs Ojo con el tamaño de los objetos Deberían ser inmutables


Lógica de negocio

*http://msdn.microsoft.com/l ibrary/en-us/dnpatterns/html/Des_DTO_Fig02.gif


Lógica de negocio Consejo 20: Utilizar serialVersionUID

Numero de serie utilizado por RMI para validar que las clasesde cliente y servidor son iguales

La generación de estos UIDs en tiempo de ejecución es cara La generación es muy sensible a cambios. Puede haber

excepciones (UnmarshallExceptions) aunque no hallamoshecho cambios notables

Utilidad: JAVA_HOME/bin/serialver.exe

public class MiDTO implements Serializablepublic static final long serialVersionUID=1L….

}


Lógica de negocio

Consejo 21: Utilizar las interfaceslocalesSiempre utilizar interfaces locales al llamar a

EJBs desde otros EJBsOjo cuando estamos en Servlets. ¿Cómo

sabes que estás en la misma máquina?Perfecta combinación con Session FaÇade y

Data Transfer Object¿Qué sucede cuando tenemos un cluster?


Lógica de negocio

Consejo 22: Cuidado conSingleton/Static¿Se puede implementar un Singleton con

EJBs? Sí, … bueno, … depende.¿Quiero pactar con el diablo?

Ojo al utilizar variables estáticas y Singletons ensistemas de Clustering: Sincronización, memoriaocupada, etc.

Solución apta sólo para variables de sólo lectura EJB3 podría solucionar esto


Lógica de negocio Consejo 23: Mimar los niveles de

transaccionalidad La afinidad transaccional entre los EJBs puede determinar en

gran medida el rendimiento

Ej: RequiresNew en bean de entidad => Cada llamada crea unatransacción, sincronización con base de datos, etc. = uuupss

Ej: Cambiamos a Requires. Ahora ya no hay el problemaanterior. Pero… ¿y si el que llama está en Never, NotSupportedo Supports?

No sólo hay que fijarse en la transaccionalidad un EJB sinotambién en la de los que llama y en la de los que lo llaman


Lógica de negocio Consejo 24: Mimar el nivel de

aislamiento Niveles de aislamiento

SERIALIZABLE: Te protege de lecturas fantasmas, lecturas no repetibles y lecturassucias

REPEATABLE_READ: Te protege de lecturas no repetibles y lecturas sucias READ_COMMITED: Te protege de lecturas sucias READ_UNCOMMITED: No te protege de nada

Cuanto menor sea el nivel, más rápido será el acceso

Configuración a través de JDBC (Connection)

Sólo se puede usar con BMT, es decir, con beans de sesión

Ojo con los servidores de aplicaciones, la especificación se lava las manos. (Ej:¿Qué pasa si llamo desde un bean de sesión en READ_UNCOMMITED a unbean de entidad?


Índice



Persistencia Consejo 25: Tener claro cuando usar

EJBs de entidad Ideal para accesos con fuerte transaccionalidad, requisitos de

seguridad, acceso a múltiples recursos heterogéneos,conectores de datos, etc.

¿Cuánto cuesta leer dos filas de base de datos? JDBC: solución trivial EJB-CMP: carga de transaccionalidad, callbacks a base de datos

innecesarios, EJB-BMP: atrapar llamadas load, store, para evitar callbacks,

escribir el SQL a mano, duplicación en caso de hacer caché de losdatos, etc.

Con EJB 3.0 el modelo de persistencia gana en simplicidad


Persistencia Consejo 26: JDBC también es J2EE

Siempre optimizar primero las consultas SQL: Reordenarcolumnas, crear bien las claves, traerse sólo las columnas necesarias,etc. etc. etc.

Conocer las potencialidades de nuestro driver JDBC Evitar drivers de tipo 1 o 3 (bridges): peor rendimiento Usar drivers tipo 2 (acceso con librerías nativas), o tipo 4 (acceso

mediante protocolos de red) ¿Especificación? 1.0, 2.0, 3.0, 4.0 ¿Opciones de arranque? Encoding, autocommit, tamaño de los

pools, espera por transacciones, etc. Optimizar, optimizar, optimizar

PreparedStatements: precompilación, pooling, … Operaciones batch Preferir los ResultSets forward only


Persistencia Consejo 27: Manejar bien las

conexiones JDBC

Ceder la gestión al servidor de aplicaciones siempreque se pueda: DataSources

Utilizar pools de conexiones en otro caso. Ej: DBCP

JDBC 2.0 soporta pooling (opcional). JDBC 3.0soporta pooling (obligatorio)

Cerrar las conexiones y los PreparedStatementdespués de haberlos utilizado


Persistencia Consejo 28: Patrón – Data Access

Object

Abstrae y encapsula el acceso a datos

Desacopla las capas de lógica de negocio y de persistencia

Permite la migración sencilla de mecanismos de persistencia:JDBC, ORM, EJBs, sistemas legacy, …

Permite la migración sencilla entre bases de datos:InformixDAO, DB2DAO, MySQLDAO,…

Puede hacerse con varios niveles de granularidad


Persistencia


Persistencia

Consejo 29: Patrón – Fast Lane Reader A veces los EJB de entidad ralentizan las

aplicaciones Datos de solo lectura Datos con formatos tabulares Sin requerimientos de transaccionalidad

Otras veces simplemente no valen: herencia, EJB-QL limitado, consultas muy complejas

Solución: Acceso directo a JDBC mediante un beande sesión


Persistencia


Persistencia Consejo 30: Valorar el uso de

herramientas ORM

A veces EJB no hace falta

Evaluar herramientas ORM: Hibernate, OJB, etc. Suelen ser herramientas más sencillas Suelen ser herramientas menos pesadas Son más flexibles y con más opciones que los EJBs Manejas directamente tu modelo de negocio, tus objetos y no

EJBs, o filas de base de datos: session.create(coche),session.delete(coche), session.findAll(coche), …

El SQL se genera automáticamente, sólo hay objetos.

Con EJB 3.0 los dos mundos estarán más cerca:EntityManager, detached objects, herencia, callbacks, etc.


Persistencia Consejo 31: Carga perezosa

Si no se va a utilizar, ¿para que cargarlo? Cargar los datos informativos necesarios, lo que se va a usar en un

primer momento, etc. Cargar el resto de información bajo demanda

Se puede utilizar también cuando se tratan listas enormes deresultados. Ej: mostrar sólo los 50 primeros de los 10.000resultados

Los sistemas ORM incluyen carga perezosa

EJB soporta esto en muchos algunos servidores deaplicaciones, pero como extensión propietaria

El problema es saber qué datos son los que no se necesitan


Persistencia

Consejo 32: Carga agresiva

Si se va a utilizar, ¿por qué no cargarlo? Los sistemas ORM incluyen carga agresiva EJB soporta esto en muchos algunos servidores de

aplicaciones, pero como extensión propietaria Ojo con:

Lo que se precarga (Ej: BLOBs) Falacias: El ancho de banda es infinito, el coste de

transporte es cero Concurrencia: ¿Puede modificarse lo que hemos

precargado?


Índice



Referencias

Consejo 33: Leer mucho javaHispanoPatrones TheServersideBlueprintsCore J2EE patterns 2nd editionJava enterprise best practicesEffective enterprise javaJava performance tuning

¡Gracias y Suerte!

Documents

Buenas practicas con J2EE€¦ · Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005 Arquitectura Consejo 2: No trabajar mucho => Automatización Ant No debemos