Post on 27-Jul-2020
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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, …
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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)
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
ArquitecturaXDoclet EJB 3.0
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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?
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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?
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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, …
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Arquitectura
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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!
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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, …
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Presentación
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Presentación
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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, …
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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.)
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Lógica de negocio
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Lógica de negocio
*http://msdn.microsoft.com/l ibrary/en-us/dnpatterns/html/Des_DTO_Fig02.gif
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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….
}
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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?
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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?
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Persistencia
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Persistencia
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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.
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
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?
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Índice
Arquitectura Presentación Lógica de negocio Persistencia Referencias
Buenas prácticas con J2EE, Martín Pérez Mariñán, Alicante, 2005
Referencias
Consejo 33: Leer mucho javaHispanoPatrones TheServersideBlueprintsCore J2EE patterns 2nd editionJava enterprise best practicesEffective enterprise javaJava performance tuning
¡Gracias y Suerte!