UDA-Selección de tecnologías

UDA – Utilidades de desarrollo de aplicaciones
Selección de tecnologías
Fecha: 06/06/2011 Referencia:
EJIE S.A.
Mediterráneo, 14
Tel. 945 01 73 00*
Fax. 945 01 73 01
01010 Vitoria-Gasteiz
Posta-kutxatila / Apartado: 809
01080 Vitoria-Gasteiz
www.ejie.es
UDA – Utilidades de desarrollo de aplicaciones by EJIE is licensed under a Creative Commons Reconocimiento-
NoComercial-CompartirIgual 3.0 Unported License.

Selección de tecnologías ii/21
Control de documentación
Título de documento: Selección de tecnologías
Histórico de versiones
Código: Versión: Fecha: Resumen de cambios:
1.0.0 06/06/2011 Primera versión.
1.1.0 17/10/2011 Tecnología en el sistema de logging
2.0.0 22/06/2012 Actualización de la tabla de tecnologías
Cambios producidos desde la última versión
Modificación de las versiones en la tabla de tecnologías
Control de difusión
Responsable: Ander Martínez
Aprobado por:
Firma: Fecha:
Distribución:
Referencias de archivo
Autor:
Nombre archivo:
Localización:

Selección de tecnologías iii/21
Contenido
Capítulo/sección Página
1 Introducción. 1
2 Identificación de los interesados y los objetivos de la arquitectura 2
2.1 Interesados 2
2.2 Objetivos 2
3 Referencias y vistas utilizadas 3
4 Selección de tecnologías 4
4.1 Bases 4
4.2 Capa de presentación 4
4.3 Servicios de Negocio 5
4.4 Capa de acceso a datos 7
4.4.1. Spring JDBC 7
4.4.2. JPA 12
4.5 Remoting (Wrappers de despliegue) 14
5 Definición del modelo de programación 16
6 Definición de la arquitectura de aplicación 17
7 Resumen de la selección tecnológica 18

Selección de tecnologías 1/21
1 Introducción.
Una vez definida la arquitectura conceptual el siguiente paso es poner nombre y apellidos a los conceptos que
aparecen en ésta. Así pues, este documento se dedica a la presentación de las tecnologías que consideramos
adecuadas para dar solución a los artefactos definidos en la arquitectura conceptual. Aunque el espíritu de
este proyecto no es en ningún caso limitar, si no todo lo contrario, sí que se establecen las tecnologías que se
consideran más adecuadas en este momento y para las cuales se dará soporte. Además los generadores y
componentes que se construyen durante este proyecto con el fin de aumentar la productividad estarán
basados en estas tecnologías.

2 Identificación de los interesados y los objetivos de la arquitectura
En los siguientes puntos se establecen los roles o perfiles a los que va dirigido el presente documento además
de los objetivos perseguidos por el mismo.
2.1 Interesados
El presente documento esta dirigido a los responsables técnicos de cada proyecto de desarrollo ejecutado en
el marco de EJIE, concretamente a los jefes de proyecto o responsables de la arquitectura técnica de los
proyectos. Es decir, se trata de un documento dirigido a describir la arquitectura técnica de los proyectos Java
en el entorno EJIE justificando punto por punto las decisiones tomadas en su proceso de elaboración. Por lo
tanto se trata de un documento fundamentalmente teórico que se centra especialmente en la descripción y
justificación de la arquitectura y no en la forma de programar las aplicaciones.
Para más información sobre la forma de programar las aplicaciones consultar la Guía de Desarrollo.
2.2 Objetivos
El objetivo del presente documento es ofrecer una visión clara de la arquitectura que han de seguir las
aplicaciones java EE dentro del marco de EJIE haciendo especial hincapié en las tecnologías a utilizar.

3 Referencias y vistas utilizadas
El contenido y formato del documento presente es una evolución del estudio de modelos de arquitectura
llamado “20090216_Modelos_Arquitectura.doc”. En función de las conclusiones extraídas de dicho estudio se
establecieron las siguientes normas o reglas de cara a documentar la arquitectura:
- Respetar en lo posible el modelo presentado por IEEE [4] para organizar la documentación de
arquitectura
- El uso de varias vistas para documentar la arquitectura incluyendo como mínimo las siguientes vistas
obtenidas de la agregación de vistas de las diferentes metodologías de documentación de
arquitecturas analizadas: vista del entorno de desarrollo (propuesta por RUP [2] y SEI [3]), vista del
entorno de despliegue (propuesta por todas las referencias analizadas), vista estática o estructural
(SEI, IEEE [4] y RUP), vista dinámica (propuesta por SEI, IEEE y RUP) y vista de procesos (propuesta
por RUP).
Una vez realizado el trabajo más teórico de recopilación de referencias y haber consensuado las vistas a
utilizar, se detecto una carencia desde el punto de vista metodológico a la hora de afrontar el proyecto de
arquitectura. Es decir, los diferentes estándares establecían un estándar de creación de vistas pero no aportan
los pasos a seguir para llegar a dichos planos.
Para intentar mejorar este último aspecto se ha tomado como referencia la propuesta realizada por Volter [5]
donde se propone la definición de la arquitectura en varios pasos, concretamente:
- Definición de la arquitectura conceptual: definición de la arquitectura desde un punto de vista lógico
intentando en lo posible aislar de las tecnologías a utilizar
- Justificación de la arquitectura conceptual
- Definición de las tecnologías a utilizar para implementar el modelo conceptual
- Definición del modelo de programación
- Arquitectura de aplicación: se trata de la organización de la arquitectura desde un punto de vista
funcional o del dominio sobre el que se esta trabajando. Por ejemplo la división del código en varios
módulos o proyectos.
En los siguientes puntos se describe la arquitectura de EJIE haciendo uso de los planos o vistas acordados y
siguiendo los pasos establecidos por la metodología de Volter.

4 Selección de tecnologías
4.1 Bases
Si atendemos a una de las premisas en las que queremos fundar esta arquitectura, la estandarización y la
reutilización, se nos presentan dos opciones interesantes que pueden servir como pilares tecnológicos de
nuestra arquitectura. Spring y el modelo Java EE 5. Si bien estos no son excluyentes entendemos que Spring
es un modelo estándar de facto muy superior, sobre todo en productividad, al anterior modelo j2ee seguido
por EJIE en sus aplicaciones anteriores.
Spring se ha convertido en un estándar de facto de la comunidad java en respuesta a la innecesaria
complejidad de j2ee. Su modelo basado en POJOs, su soporte a la inyección de dependencias, a la
programación orientada a aspectos, sus wrappers para integrar diferentes soluciones, sus módulos
facilitadotes para trabajar con las complejas APIS de las especificaciones del modelo J2EE lo han hecho
extremadamente popular.
Es por ello que es nuestra opción de partida. Un modelo simple que además de lo anteriormente citado tiene
dos grandes bondades: no necesita un servidor de aplicaciones j2ee y facilita la realización de test unitarios
tan demandada hoy día. Sin embargo hay que resaltar que con las especificaciones de java EE en su versión
5 (y aún más con el nuevo estándar java EE 6) los modelos de desarrollo de Spring y Java EE están
convergiendo. Ambos soportan Inyección de dependencias y AOP. Ambos se basan en un modelo de POJOs
con lo que la simplificación del desarrollo ya no es un gran factor diferencial. Si bien es cierto que el modelo de
Spring de DI y AOP es más potente, no es menos cierto que es difícil que el modelo java EE se quede corto
para el desarrollo de una aplicación Web. Más allá de pequeñas diferencias a la hora de programar hay una
diferencia clara cuando se trata de Spring vs. java EE.
Spring no necesita un servidor compatible y por tanto puede evolucionar sin la necesidad de cambiar de
servidor. Podemos correr Spring 2.5 y ahora también Spring 3.0 en nuestro servidor y este puede ser un
Tomcat o un servidor de aplicaciones completo como Weblogic. Este es un aspecto deseable para nuestras
aplicaciones. Sin embargo hay dos temas que hacen que en EJIE sea menos relevante que en otras
entidades. El primero es que EJIE dispone de Servidores Weblogic 10.3 que soportan el estándar java EE 5 y
por tanto la inversión monetaria está realizada. En segundo lugar es de hacer notar que las aplicaciones que
requieren de clusterización y de transaccionalidad con alta disponibilidad como son algunas de las que se
realizan en EJIE requieren de algunos servicios como JTA, JMS, clusterización etc. que los servidores Java
EE proporcionan porque se han creado con este objetivo en mente. Un punto importante para algunas
aplicaciones y que Java EE aborda pero Spring inicialmente no es el uso de transacciones distribuidas en la
red.
Es por todo esto que se concluye que no vamos a limitar el modelo a Spring máxime cuando los modelos son
tan parecidos hoy en día. De forma que a modo de recomendación diríamos que las aplicaciones con un
modelo local las vemos dentro del marco de Spring y en aquellas en las que se trabaje con transacciones
distribuidas XA integrando servicios de distintas aplicaciones se ve a Java EE como una posible solución.
4.2 Capa de presentación
El punto de partida para definir la capa de presentación es el estudio de Patrones de interacción RIA en la que
se marcan los requisitos a cumplir en términos de usabilidad y accesibilidad de las interfaces gráficas de las
aplicaciones. La solución propuesta por la arquitectura, siempre con el objetivo de la productividad en mente,
es ofrecer a los desarrolladores una paleta de componentes gráficos altamente reutilizables que ya cumplen
con los criterios de cada uno de los patrones.

Para ello, se proporcionará una versión actualizada de los componentes RIA de los que actualmente Ejie
dispone. Estos están desarrollados en el lenguaje JavaScript y utilizan masivamente la librería jQuery.
4.3 Servicios de Negocio
Siguiendo las normas de la arquitectura conceptual, la lógica de negocio de las aplicaciones debe ser lo más
independiente posible de la posible evolución tecnológica. Al mismo tiempo no debe de implementar los
aspectos enumerados con anterioridad (seguridad, transacciones,..), postergando en consecuencia la fecha
de caducidad del código de lógica de negocio. En otras palabras maximizando la inversión realizada en el
desarrollo de aplicaciones mejorando el retorno de la inversión realizada (ROI).
Para poder obtener estas dos premisas establecidas en la arquitectura conceptual, se han acordado las
siguientes reglas a la hora de seleccionar las tecnologías de la capa de servicios de negocio.
- Uso de simples clases Java (POJOS) que implementan interfaces Java para la implementación del
código de la lógica de negocio
- Implementar mediante aspectos las reglas transaccionales, seguridad, logging y otros elementos
aplicables a los servicios pero que no resuelven funcionalidades específicas del negocio.
Spring posibilita la aplicación de cualquier tipo de aspecto (que a su vez son POJOs) sobre una simple clase
Java. En la siguiente imagen podemos ver gráficamente la aplicación de dos aspectos (seguridad y
transacciones) sobre un POJO:
AOP de Spring
Los beneficios ofrecidos por la factoría de Spring no posibilitan únicamente el uso de AOP sino que
proporcionan más ventajas, concretamente:
- Es necesario minimizar las dependencias directas entre las diferentes capas mediante el uso de
interfaces y beans de transferencia. Dichos interfaces no deben de estar ligados a ninguna tecnología
en concreto en lo posible.
- El código debe ser independiente del entorno de ejecución, debiendo ser configurable para adaptarse
al entorno de ejecución. Por ejemplo poder utilizar un DataSource de acceso directo o vía JNDI en
función del entorno de ejecución.
Tradicionalmente estos requerimientos han sido implementados mediante el uso del patrón ServiceLocator de
J2EE o mediante clases de utilidad o factorías que independizan la obtención de las dependencias.

Aunque el uso de estos patrones (ServiceLocator o factorías) podría ser una solución valida, se ha acordado
utilizar el patrón de diseño denominado como inyección de dependencia o InversiónOfControl (IoC).
Este patrón de diseño, utilizado en la actualidad por la mayoría de las nuevas tecnologías en el mundo Java
(Spring, JEE, JSF,..) y que viene a sustituir a los patrones tradicionales como ServiceLocator o Factoría,
ofrece las siguientes ventajas frente a las soluciones tradicionales:
- Externaliza la resolución de las dependencias del código fuente. En otras palabras, se eliminan el uso
de clases de utilidades o factorías del código fuente, simplificando el código resultante. Además evita
el tener que crear o implementar dichas funcionalidades de forma propietaria.
- Cacheo de recursos: otra de las ventajas ofrecidas por la factoría de Spring es la implementación por
defecto del patrón Singleton dentro de los beans definidos en la factoría, reduciendo el consumo de
memoria y mejorando el tiempo de respuesta al disponer de componentes previamente inicializados.
Una vez descartado el uso de los patrones de diseño tradicionales como Service Locator o Factoría a favor del
uso de inyección de dependencia, se ha establecido la norma de uso de la factoría de Spring para la
implementación de las capas de negocio y acceso a datos.
Uso de java EE
Como se ha comentado anteriormente la línea básica propuesta es la de elegir Spring en la mayoría de
desarrollos. Sin embargo esta arquitectura no cierra las puertas al uso de java EE y en concreto a EJBs. En
los casos en los que la lógica de negocio vaya a ser expuesta a otras aplicaciones el modelo java EE es una
opción tenida en cuenta. En este caso los beneficios proporcionados por la sencillez de desarrollo de
aplicaciones que soporten transacciones distribuidas son claramente superiores al hecho de que nos ligamos
a un servidor de aplicaciones java EE (en caso de EJIE Weblogic 10). La implementación servicios en Java
EE se realiza mediante POJOs igualmente y también soporta DI tanto con anotaciones como con XML. Añadir
carácter remoto a los POJOs se realiza mediante el uso de simples anotaciones (@remote, @stateless).
Migración Spring / java EE
El coste de migrar una aplicación desarrollada en Spring a Java EE para añadirle la capacidad de exponer su
código en un entorno de transacciones distribuidas entre varias aplicaciones es mínimo. En estos casos se
puede añadir una capa de servicios a través de un EJB stateless que delegue la lógica en los servicios
implementados en Spring (ver guía desarrollo).
Convivencia
Spring proporciona las herramientas necesarias para beneficiarse de java EE. En concreto en la capa de
servicios ofrece un interceptor (SpringBeanAutowiringInterceptor) que permite inyectar beans de Spring los
ejbs.
En cuanto a la integración con ejb2 (para el caso de Geremua 2) spring permite definir ejbs como beans de
spring de forma muy sencilla en sus xml utilizando el tag <jee:remote-slsb> o bien <jee:local-
slsb>.

4.4 Capa de acceso a datos
Al igual que la capa de servicios de negocio la tecnología seleccionada para la implementación de la capa
de acceso a datos ha sido el uso de POJOs, es decir, basada en simples componentes ofrecidos por la
JDK.
De esta forma obtenemos los siguientes beneficios:
- Mejoramos la capacidad de testear los componentes de la capa de acceso a datos, haciendo uso de
la JDK y de conexiones directas contra la base de datos
- Aumenta la dependencia sobre la plataforma tecnológica al basarse únicamente en la JDK
Una vez establecida la norma del uso de clases planas o POJOs el siguiente objetivo, siguiendo la norma de
delegar en lo posible el las clases comunes de infraestructura ha sido automatizar en lo posible las tareas de
acceso a datos. En otras palabras, eliminar en lo posible todo el trabajo repetitivo que se pueda dar en el
acceso a datos, eliminando el margen de error y mejorando la productividad.
Dos alternativas
Actualmente los modelos existentes de desarrollo java contra base de datos están basados en JDBC. Esta
tecnología se apoya básicamente en el conocimiento de los desarrolladores del uso del lenguaje SQL y es
conocida por una gran base de programadores java. No en vano se incluye en java SE. No ofrece dudas en
cuanto a su fiabilidad, estabilidad, rendimiento, futuro, etc. lo que la convierten en una apuesta segura. La
única pega que podemos poner a esta tecnología es que requiere escribir excesivo código a cambio de un
mayor control.
En este sentido Spring nos ofrece un interesante modulo: Spring JDBC que mitiga en gran parte la escritura
de código repetitivo como por ejemplo el control de errores, aperturas y cierres etc. Por otro lado no podemos
dejar de lado el éxito que las tecnologías de ORM (hibernate, Toplink, Ibatis, kodo, jdo …) han alcanzado en
los últimos años. La comunidad java ha hecho un esfuerzo por unificar el uso de ORMs en la especificación
JPA y éste forma parte ya de la plataforma Java EE. Hay que añadir además que también es una apuesta de
Spring. Por todo ello esta arquitectura permite su uso.
4.4.1. Spring JDBC
Analizando las funcionalidades ofrecidas en la arquitectura actual de EJIE en esta área se han detectado una
sería de aspectos que se han considerado que se podían mejorar, son los siguientes:
- Gestión de los recursos JDBC (conexiones, PreparedStament, ResultSet,…): los recursos JDBC
son manejados de forma manual por parte de los programadores. Es decir, cada vez que realiza una
consulta la responsabilidad de crear y cerrar los recursos JDBC recae en los programadores. Delegar
esta responsabilidad a los programadores puede generar problemas de recursos mal gestionados
además de tener que programar dichas tareas en cada consulta sql aumentando el costo de
desarrollo.
- Tratamiento de excepciones: las excepciones son tratadas de forma manual, delegando la
responsabilidad de la gestión de las excepciones a los programadores. Siguiendo con la norma
establecida en el punto anterior esta práctica de programación puede provocar la gestión inadecuada
de excepciones (por ejemplo excepciones no propagadas) además de aumentar el costo de desarrollo
al tener que incluir el tratamiento de excepciones en cada consulta realizada contra la base de datos
(bloques try/catch).

- Mapeo Java- Relacional: actualmente la asignación de los datos obtenidos desde el ResultSet a
objetos Java o la asignación de los parámetros de entrada de una consulta se realiza de forma
manual. Es decir, por cada columna obtenida de base de datos o por cada propiedad que se quiera
incluir en una consulta es necesario programar una línea de código.
En el siguiente cuadro podemos ver un ejemplo de acceso a base de datos de uso directo de JDBC que refleja
las tres carencias presentadas:
Acceso de datos a través del uso directo de JDBC
Como se puede apreciar en el ejemplo gran parte del código del método es dedicado a tareas que se repiten
en cada método de acceso a base de datos, como por ejemplo crear/cerrar conexiones, tratamiento de
excepciones y mapeo de objetos-relacional, superando en muchos casos al código de negocio propio del
método.
try {
conexionBD = Q70ConectorJDBC.getSingleton().getConnection(V55SpringDao.
V55_JNDI_DATASOURCE);
preparedStatement =conexionBD.prepareStatement(queryStr);
rs = preparedStatement.executeQuery();
V5501T00 row;
while (rs.next()) {
row = new V5501T00(); row.setIdent_001(rs.getString("IDENT_001"));
row.setDesc_com_001(rs.getString("DESC_COM_001"));
row.setDese_com_001(rs.getString("DESE_COM_001"));
row.setBaja_001(rs.getString("BAJA_001"));
lista.add(row);
}
} catch (Exception e) {
}
finally {
try {
if (rs != null) rs.close();
if (preparedStatement != null) preparedStatement.close();
}
catch (Exception e) {
}
try{
if (conexionBD != null) conexionBD.close();
}
catch (Exception e) {
}
}

Con el objeto de mejorar estos aspectos además de cumplir con uno de los requerimientos definidos dentro de
la arquitectura, automatizar y evitar tareas repetitivas en lo posible, se ha realizado una tarea de búsqueda de
soluciones para mejorar el acceso a base de datos basado en JDBC.
Dado que el desarrollo de las aplicaciones ya ha comenzado, se ha priorizado el uso de soluciones existentes
entre las que se ha seleccionado a SpringJDBC como la más adecuada. Los motivos de haber seleccionado a
SpringJDBC son los siguientes:
- Gestiona de forma automática todos los recursos JDBC, liberando de esta responsabilidad a los
programadores y eliminando la existencia de errores de programación en esta área.
- Implementa la política de tratamiento de excepciones requerida por los requerimientos de la
arquitectura: cierre de recursos JDBC y transformación a excepciones de tipo unchecked
- Ofrece funcionalidades de mapeo automático dirigidas a automatizar la tarea de mapeo entre Java y
base de datos. Estas funcionalidades son utilizables únicamente cuando se mantiene una
equivalencia entre la nomenclatura de las columnas de la base de datos y de las propiedades de los
Beans.
- Reduce considerablemente las líneas de código necesarias para el acceso a datos, especialmente por
la automatización de los mapeos a objetos y la gestión de recursos.
- Dispone de una jerarquía propia de excepciones para acceso a base de datos. Esta jerarquía se
mantiene incluso en el caso de cambiar en un futuro de tecnología de acceso a base de datos
(Hibernate, JPA,..).
En el siguiente cuadro podemos ver un ejemplo de acceso a datos basado en SpringJDBC.
Select implementado mediante SpringJDBC
Como se puede apreciar en el ejemplo, las funcionalidades ofrecidas por SpringJDBC cubren los
requerimientos definidos dentro del área de acceso a datos:
- La gestión de recursos de JDBC es realizada por el objeto jdbcTemplate, eliminando de esta
responsabilidad a los programadores
- El objeto jdbcTemplate genera excepciones de tipo unchecked evitando la necesidad de bloques
try/catch en el código
- El mapeo del resultado es automatizado por el RowMapper automático de Spring. En el uso directo de
JDBC tendríamos que programar una línea de código por cada columna obtenida de base de datos.
Es importante recordar que esta funcionalidad es posible en caso de mantener la equivalencia entre
columnas y propiedades Java.
public Alumno getAlumno(String dni) {
StringBuffer sql = new StringBuffer();
sql.append(" SELECT * FROM ").append(Tablas.ALUMNO).append(" WHERE DNI = ?”);
Object[] params = new Object[] { dni };
BeanPropertyRowMapper rowMapper = new BeanPropertyRowMapperExtension(Alumno.class,4);
return (Alumno) getJdbcTemplate().queryForObject(sql.toString(), params, rowMapper);
}

Lo mismo ocurre en el caso en el que es necesario añadir parámetros de entrada en el caso de las insert o
updates como podemos ver en el siguiente cuadro:
Insert de una tabla implementado mediante SpringJDBC
Para comprobar la validez de la solución se han realizado diferentes pruebas de concepto para comparar la
programación directa de JDBC con SpringJDBC, con los siguientes objetivos:
- Analizar el número de líneas de código para evaluar el costo de desarrollo
- Analizar el tiempo de respuesta
En las siguientes gráficas se presentan los resultados de la comparativa realizada respecto al número de
líneas de código:
public void insertAccount(Account account) {
StringBuffer sql = new StringBuffer();
sql.append("INSERT INTO ").append(Tablas.ACCOUNT)
.append(" (email, firstname, lastname, status, addr1, addr2, city, state, zip,
country, phone, userid)").append("VALUES(:a.email,:a.firstname,:a.lastname,
:a.status,:a.addr1,:a.addr2,:a.city,:a.state,:a.zip,:a.country,:a.phone,
:a.userid)");
Map paramMap = Collections.singletonMap("a", account);
SqlParameterSource namedParameters = new
MultipleBeanPropertySqlParameterSource(paramMap);
this.getNamedParameterJdbcTemplate().update(sql.toString(), namedParameters);
…

Comparativa de líneas de código JDBC Plano /SpringJDBC
Dentro de las pruebas de tiempo de respuesta se ha implementado un método que solicita datos a un Sistema
Gestor de Bases de Datos Oracle 11g. En concreto, esta tabla consta de dieciséis columnas y trescientos
veinte mil registros. El método, recupera secuencialmente cien, quinientos, mil, diez mil, cien mil y trescientos
mil registros. Una vez obtenidos los datos de la base de datos, el método mapea los registros a clases Java
utilizando la utilidad RowMapper que proporciona Spring 3.0.
El resultado del tiempo que emplea el RowMapper en realizar los mapeos es el siguiente:
Se estima que los tiempos de mapeo ofrecidos por Spring 3.0 son muy satisfactorios, por lo que se descarta
cualquier otra utilidad aplicable a este respecto.
Uniendo esta propiedad a las ventajas ofrecidas desde el punto de vista de reducción de líneas de código se
ha considerado a Spring JDBC como la opción más adecuada para ser la solución de acceso a datos dentro
de esta primera fase de la definición de arquitectura.

4.4.2. JPA
Con el fracaso de la especificación EJB (1 y 2) y más concretamente EJB entity, una serie de herramientas
para sustituirla ganaron cuota de mercado. Su propósito era el mismo: orientar a objetos las interacciones con
base de datos. Estas herramientas denominadas ORM (object relational mapping) hace desaparecer gran
parte de los problemas que se plantean en el punto anterior. El principal beneficio de esta tecnología es la
reducción del número de líneas de código a escribir que nos permite ganar en productividad lo cual está
estrechamente alineado con el objeto de la presente arquitectura.
JPA es una especificación y como tal necesita una implementación concreta. La implementación más utilizada
en el mercado es Hibernate en el campo del Open Source y TopLink en el caso de las herramientas
comerciales. La versión del Servidor de aplicaciones de la que disponemos trae una implementación basada
en KODO. Este producto va a ser discontinuado por parte de oracle en beneficio de TopLink. Una versión
Open Source de este servidor EclipseLink (anteriormente Toplink essentials) está disponible también en la
versión de oracle weblogic 10.3.
De la misma forma hay que destacar que la versión java EE 5 obliga a proporcionar una implementación de
JPA 1.0. Sin embargo la versión 2.0 está disponible ya e incluye algunas mejoras interesantes. Existe también
la posibilidad de instalar una versión de eclipse link que soporta JPA 2.0 como se puede ver en el artículo:
Running JPA 2.0 API on WebLogic 10.3.
El producto final escogido para hacerse cargo de la persistencia es EclipseLink 2.1, ya que se ha demostrado
que es compatible con WebLogic 10.3.1.
Reducción de líneas de código.
Si bien Spring JDBC nos ayuda a reducir el número de líneas de código que son necesarias trabando contra
jdbc directamente el enfoque de JPA es orientado a objetos puro consiguiendo un mayor nivel de abstracción
a la par que reduce el número de líneas y aumenta la sencillez. El mapeo se establece con propiedades
(anotaciones como se ve en el siguiente recuadro) de forma que ya no es necesario el uso de los rowMappers
y en muchos casos de utilización de SQL. Es decir se trabaja con el modelo directamente.
@Entity
public class Usuario implements Serializable {
@SequenceGenerator(name="usuario_seq", sequenceName="usuario_seq",
initialValue=1,allocationSize=10 )
@Id
@GeneratedValue(strategy=GenerationType.SEQUENCE, generator="usuario_seq" )
@Column
private int id;
@Column
private int dni;
@Column
private String nombre;
@Column
private String apellido1;
@Column
private String apellido2;
@Column
private String email;
@Column

private String movil;
@Column
private String fechaAlta;
@Column
private String fechaBaja;
@ManyToMany
@JoinTable(name="usuario_deporte",
joinColumns=@JoinColumn(name="ID_USUARIO"),
inverseJoinColumns=@JoinColumn(name="ID_RESERVA"))
private Set<Deporte> deportes;
//Relación entre usuarios y el conjunto de horas disponibles que tienen
@OneToMany(mappedBy="usuario",cascade=CascadeType.PERSIST )
private Set<Disponibilidad> horasDisponibilidad;
//getters y setters
…
}
La legibilidad y la reducción de código se hace manifiesta viendo el código del DAO que gestiona la
persistencia a través del entity manager. Las funciones persist, merge, remove y find operan con una línea
única y son capaces de hacer un mantenimiento sin tener que utilizar un lenguaje como el SQL. Para las
queries esta tecnología proporciona un leguaje orientado a objetos de búsqueda denominado JPQL como se
puede ver en la implementación del DAO en el recuadro siguiente. En todos los casos las funciones devuelven
directamente los beans que representan el modelo sin necesidad de parseos y desparseos.
@Repository
public class UsuarioDAOImpl implements UsuarioDAO
{
@PersistenceContext
private EntityManager em;
@Override
public Usuario add(Usuario usuario) {
em.persist(usuario);
return usuario;
}
@Override
public Usuario find(int idUsuario) {
return em.find(Usuario.class, idUsuario);
}
@SuppressWarnings("unchecked")
@Override
public List<Usuario> findAll() {
Query query = em.createQuery("select u from Usuario u");
return query.getResultList();
}
@Override
public void remove(int idUsuario) {
Usuario usuario = em.find(Usuario.class, idUsuario);
if(usuario!= null)

em.remove(usuario);
}
@Override
public Usuario update(Usuario usuario) {
em.merge(usuario);
return usuario;
}
}
No obstante es importante preguntarse qué pasa cuando la solución JPA no alcanza a proporcionar los
servicios de JDBC. En estos casos JPA proporciona la posibilidad de utilizar SQL nativo a través de sus
métodos createNativeQuery de forma que evitamos el riesgo de quedarnos sin posibilidad de avanzar a medio
proyecto.
En cuanto a la reducción de líneas de código algunas mediciones de terceros revelan estos resultados en los
que se puede observar como en la mayoría de casos el ahorro ronda un factor x 5 o x 6.
4.5 Remoting (Wrappers de despliegue)
Se trata de la capa responsable de cumplir con los requisitos de posibilitar el consumo remoto de la lógica de
negocio implementada en la capa de servicios de negocio. Además se ha delegado a esta capa la
responsabilidad de aplicar los aspectos relacionados con los servicios remotos y manejo transaccional.

La tecnología como se indicó anteriormente es más potente en este caso permitiendo de forma transparente la
creación de componentes que soporten transacciones distribuidas XA entre los distintos servicios expuestos
por las aplicaciones. Además está pensado específicamente para trabajar en entornos clusterizados que
necesiten de escalabilidad, seguridad y monitorización.
En el caso de Weblogic y de forma no estándar, éste provee de unas clases propietarias para Spring que
permiten dotar de estas cualidades también al framework Spring. Aunque como se ha apuntado no son
soluciones que vayan a funcionar en otros servidores de aplicaciones ya que no son nativas de Spring.
En todo caso los desarrolladores pueden optar por el uso de Spring remoting. Éste aunque más limitado
abstrae mejor la tecnología que utilizan los servicios pudiendo intercambiar entre RMI, Hessian, jaxrpc, http
Invokker, burlap, JMS con facilidad.

5 Definición del modelo de programación
Para este apartado consultar la guía de desarrollo donde se definen todas las funcionalidades y normas
necesarias para el desarrollo de aplicaciones.

6 Definición de la arquitectura de aplicación
Para este apartado consultar la guía de desarrollo donde se define los módulos involucrados en el desarrollo
de aplicaciones.

7 Resumen de la selección tecnológica
Tecnología Versión Función Capa
Tiles 2.2.2 Plantillado Presentación
jQuery 1.8.0 Vista y Ajax Presentación
jQueryUI 1.8.23 Vista Presentación
jQGrid 4.4.1 Vista Presentación
Spring MVC 3.1.2 Control Presentación
JSTL 1.2 Vista Presentación
Spring Framework 3.1.2 Servicio Servicio
Spring JDBC 3.1.2 Persistencia JDBC Persistencia
EclipseLink 2.3.0 Persistencia JPA 2.0 Persistencia
Spring Framework 3.1.2 Contenedor IoC Core
Spring AOP 3.1.2 Aspectos Core
WebLogic 10.3.5 Servidor de Aplicaciones Core
Java Development Kit 6 Maquina Virtual Java Core
Enterprise Java Beans 3.0 Remoting Remoting
JTA 1.1 Transaccionalidad Componentes
Spring Security 3.1.2 Seguridad Componentes
LogBack 1.0.6 Trazas Componentes
Hibernate Validator 4.2.0 Validación Componentes
Eclipse OEPE 11.1.1.7 IDE Plataforma
SubVersion 1.6.13 Gestión de versiones Plataforma
Maven 3.0.3 Gestión de dependencias Plataforma
Ant 1.7.1 Tareas Plataforma
Freemaker 2.3.16 Plantillas Asistentes
Hibernate Tools 3.4.0 Plugin Asistentes

UDA-Selección de tecnologías

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a UDA-Selección de tecnologías

Semelhante a UDA-Selección de tecnologías (20)

Mais de Ander Martinez

Mais de Ander Martinez (20)

Último

Último (10)

UDA-Selección de tecnologías