UDA – Utilidades de desarrollo de aplicacionesSelección de tecnologíasFecha: 06/06/2011 Referencia:EJIE S.A.Mediterráneo, ...
Selección de tecnologías ii/21Control de documentaciónTítulo de documento: Selección de tecnologíasHistórico de versionesC...
Selección de tecnologías iii/21ContenidoCapítulo/sección Página1 Introducción. 12 Identificación de los interesados y los ...
Selección de tecnologías 1/211 Introducción.Una vez definida la arquitectura conceptual el siguiente paso es poner nombre ...
Selección de tecnologías 2/212 Identificación de los interesados y los objetivos de la arquitecturaEn los siguientes punto...
Selección de tecnologías 3/213 Referencias y vistas utilizadasEl contenido y formato del documento presente es una evoluci...
Selección de tecnologías 4/214 Selección de tecnologías4.1 BasesSi atendemos a una de las premisas en las que queremos fun...
Selección de tecnologías 5/21Para ello, se proporcionará una versión actualizada de los componentes RIA de los que actualm...
Selección de tecnologías 6/21Aunque el uso de estos patrones (ServiceLocator o factorías) podría ser una solución valida, ...
Selección de tecnologías 7/214.4 Capa de acceso a datosAl igual que la capa de servicios de negocio la tecnología seleccio...
Selección de tecnologías 8/21- Mapeo Java- Relacional: actualmente la asignación de los datos obtenidos desde el ResultSet...
Selección de tecnologías 9/21Con el objeto de mejorar estos aspectos además de cumplir con uno de los requerimientos defin...
Selección de tecnologías 10/21Lo mismo ocurre en el caso en el que es necesario añadir parámetros de entrada en el caso de...
Selección de tecnologías 11/21Comparativa de líneas de código JDBC Plano /SpringJDBCDentro de las pruebas de tiempo de res...
Selección de tecnologías 12/214.4.2. JPACon el fracaso de la especificación EJB (1 y 2) y más concretamente EJB entity, un...
Selección de tecnologías 13/21private String movil;@Columnprivate String fechaAlta;@Columnprivate String fechaBaja;@ManyTo...
Selección de tecnologías 14/21em.remove(usuario);}@Overridepublic Usuario update(Usuario usuario) {em.merge(usuario);retur...
Selección de tecnologías 15/21La tecnología como se indicó anteriormente es más potente en este caso permitiendo de forma ...
Selección de tecnologías 16/215 Definición del modelo de programaciónPara este apartado consultar la guía de desarrollo do...
Selección de tecnologías 17/216 Definición de la arquitectura de aplicaciónPara este apartado consultar la guía de desarro...
Selección de tecnologías 18/217 Resumen de la selección tecnológicaTecnología Versión Función CapaTiles 2.2.2 Plantillado ...
Upcoming SlideShare
Loading in …5
×

UDA-Selección de tecnologías

517 views
440 views

Published on

UDA-Utilidades de desarrollo de aplicaciones
• Selección de tecnologías

http://uda-ejie.github.io/

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
517
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

UDA-Selección de tecnologías

  1. 1. UDA – Utilidades de desarrollo de aplicacionesSelección de tecnologíasFecha: 06/06/2011 Referencia:EJIE S.A.Mediterráneo, 14Tel. 945 01 73 00*Fax. 945 01 73 0101010 Vitoria-GasteizPosta-kutxatila / Apartado: 80901080 Vitoria-Gasteizwww.ejie.esUDA – Utilidades de desarrollo de aplicaciones by EJIE is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported License.
  2. 2. Selección de tecnologías ii/21Control de documentaciónTítulo de documento: Selección de tecnologíasHistórico de versionesCó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 logging2.0.0 22/06/2012 Actualización de la tabla de tecnologíasCambios producidos desde la última versiónModificación de las versiones en la tabla de tecnologíasControl de difusiónResponsable: Ander MartínezAprobado por:Firma: Fecha:Distribución:Referencias de archivoAutor:Nombre archivo:Localización:
  3. 3. Selección de tecnologías iii/21ContenidoCapítulo/sección Página1 Introducción. 12 Identificación de los interesados y los objetivos de la arquitectura 22.1 Interesados 22.2 Objetivos 23 Referencias y vistas utilizadas 34 Selección de tecnologías 44.1 Bases 44.2 Capa de presentación 44.3 Servicios de Negocio 54.4 Capa de acceso a datos 74.4.1. Spring JDBC 74.4.2. JPA 124.5 Remoting (Wrappers de despliegue) 145 Definición del modelo de programación 166 Definición de la arquitectura de aplicación 177 Resumen de la selección tecnológica 18
  4. 4. Selección de tecnologías 1/211 Introducción.Una vez definida la arquitectura conceptual el siguiente paso es poner nombre y apellidos a los conceptos queaparecen en ésta. Así pues, este documento se dedica a la presentación de las tecnologías que consideramosadecuadas para dar solución a los artefactos definidos en la arquitectura conceptual. Aunque el espíritu deeste proyecto no es en ningún caso limitar, si no todo lo contrario, sí que se establecen las tecnologías que seconsideran más adecuadas en este momento y para las cuales se dará soporte. Además los generadores ycomponentes que se construyen durante este proyecto con el fin de aumentar la productividad estaránbasados en estas tecnologías.
  5. 5. Selección de tecnologías 2/212 Identificación de los interesados y los objetivos de la arquitecturaEn los siguientes puntos se establecen los roles o perfiles a los que va dirigido el presente documento ademásde los objetivos perseguidos por el mismo.2.1 InteresadosEl presente documento esta dirigido a los responsables técnicos de cada proyecto de desarrollo ejecutado enel marco de EJIE, concretamente a los jefes de proyecto o responsables de la arquitectura técnica de losproyectos. Es decir, se trata de un documento dirigido a describir la arquitectura técnica de los proyectos Javaen el entorno EJIE justificando punto por punto las decisiones tomadas en su proceso de elaboración. Por lotanto se trata de un documento fundamentalmente teórico que se centra especialmente en la descripción yjustificació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 ObjetivosEl objetivo del presente documento es ofrecer una visión clara de la arquitectura que han de seguir lasaplicaciones java EE dentro del marco de EJIE haciendo especial hincapié en las tecnologías a utilizar.
  6. 6. Selección de tecnologías 3/213 Referencias y vistas utilizadasEl contenido y formato del documento presente es una evolución del estudio de modelos de arquitecturallamado “20090216_Modelos_Arquitectura.doc”. En función de las conclusiones extraídas de dicho estudio seestablecieron 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 dearquitectura- El uso de varias vistas para documentar la arquitectura incluyendo como mínimo las siguientes vistasobtenidas de la agregación de vistas de las diferentes metodologías de documentación dearquitecturas analizadas: vista del entorno de desarrollo (propuesta por RUP [2] y SEI [3]), vista delentorno 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 (propuestapor RUP).Una vez realizado el trabajo más teórico de recopilación de referencias y haber consensuado las vistas autilizar, se detecto una carencia desde el punto de vista metodológico a la hora de afrontar el proyecto dearquitectura. Es decir, los diferentes estándares establecían un estándar de creación de vistas pero no aportanlos 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ógicointentando 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 vistafuncional o del dominio sobre el que se esta trabajando. Por ejemplo la división del código en variosmódulos o proyectos.En los siguientes puntos se describe la arquitectura de EJIE haciendo uso de los planos o vistas acordados ysiguiendo los pasos establecidos por la metodología de Volter.
  7. 7. Selección de tecnologías 4/214 Selección de tecnologías4.1 BasesSi atendemos a una de las premisas en las que queremos fundar esta arquitectura, la estandarización y lareutilización, se nos presentan dos opciones interesantes que pueden servir como pilares tecnológicos denuestra arquitectura. Spring y el modelo Java EE 5. Si bien estos no son excluyentes entendemos que Springes un modelo estándar de facto muy superior, sobre todo en productividad, al anterior modelo j2ee seguidopor EJIE en sus aplicaciones anteriores.Spring se ha convertido en un estándar de facto de la comunidad java en respuesta a la innecesariacomplejidad de j2ee. Su modelo basado en POJOs, su soporte a la inyección de dependencias, a laprogramación orientada a aspectos, sus wrappers para integrar diferentes soluciones, sus módulosfacilitadotes para trabajar con las complejas APIS de las especificaciones del modelo J2EE lo han hechoextremadamente popular.Es por ello que es nuestra opción de partida. Un modelo simple que además de lo anteriormente citado tienedos grandes bondades: no necesita un servidor de aplicaciones j2ee y facilita la realización de test unitariostan demandada hoy día. Sin embargo hay que resaltar que con las especificaciones de java EE en su versión5 (y aún más con el nuevo estándar java EE 6) los modelos de desarrollo de Spring y Java EE estánconvergiendo. Ambos soportan Inyección de dependencias y AOP. Ambos se basan en un modelo de POJOscon lo que la simplificación del desarrollo ya no es un gran factor diferencial. Si bien es cierto que el modelo deSpring de DI y AOP es más potente, no es menos cierto que es difícil que el modelo java EE se quede cortopara el desarrollo de una aplicación Web. Más allá de pequeñas diferencias a la hora de programar hay unadiferencia 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 deservidor. Podemos correr Spring 2.5 y ahora también Spring 3.0 en nuestro servidor y este puede ser unTomcat o un servidor de aplicaciones completo como Weblogic. Este es un aspecto deseable para nuestrasaplicaciones. Sin embargo hay dos temas que hacen que en EJIE sea menos relevante que en otrasentidades. El primero es que EJIE dispone de Servidores Weblogic 10.3 que soportan el estándar java EE 5 ypor tanto la inversión monetaria está realizada. En segundo lugar es de hacer notar que las aplicaciones querequieren de clusterización y de transaccionalidad con alta disponibilidad como son algunas de las que serealizan en EJIE requieren de algunos servicios como JTA, JMS, clusterización etc. que los servidores JavaEE proporcionan porque se han creado con este objetivo en mente. Un punto importante para algunasaplicaciones y que Java EE aborda pero Spring inicialmente no es el uso de transacciones distribuidas en lared.Es por todo esto que se concluye que no vamos a limitar el modelo a Spring máxime cuando los modelos sontan parecidos hoy en día. De forma que a modo de recomendación diríamos que las aplicaciones con unmodelo local las vemos dentro del marco de Spring y en aquellas en las que se trabaje con transaccionesdistribuidas XA integrando servicios de distintas aplicaciones se ve a Java EE como una posible solución.4.2 Capa de presentaciónEl punto de partida para definir la capa de presentación es el estudio de Patrones de interacción RIA en la quese marcan los requisitos a cumplir en términos de usabilidad y accesibilidad de las interfaces gráficas de lasaplicaciones. 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 cumplencon los criterios de cada uno de los patrones.
  8. 8. Selección de tecnologías 5/21Para ello, se proporcionará una versión actualizada de los componentes RIA de los que actualmente Ejiedispone. Estos están desarrollados en el lenguaje JavaScript y utilizan masivamente la librería jQuery.4.3 Servicios de NegocioSiguiendo las normas de la arquitectura conceptual, la lógica de negocio de las aplicaciones debe ser lo másindependiente posible de la posible evolución tecnológica. Al mismo tiempo no debe de implementar losaspectos enumerados con anterioridad (seguridad, transacciones,..), postergando en consecuencia la fechade caducidad del código de lógica de negocio. En otras palabras maximizando la inversión realizada en eldesarrollo 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 lassiguientes 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 delcódigo de la lógica de negocio- Implementar mediante aspectos las reglas transaccionales, seguridad, logging y otros elementosaplicables 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 claseJava. En la siguiente imagen podemos ver gráficamente la aplicación de dos aspectos (seguridad ytransacciones) sobre un POJO:AOP de SpringLos beneficios ofrecidos por la factoría de Spring no posibilitan únicamente el uso de AOP sino queproporcionan más ventajas, concretamente:- Es necesario minimizar las dependencias directas entre las diferentes capas mediante el uso deinterfaces y beans de transferencia. Dichos interfaces no deben de estar ligados a ninguna tecnologíaen concreto en lo posible.- El código debe ser independiente del entorno de ejecución, debiendo ser configurable para adaptarseal entorno de ejecución. Por ejemplo poder utilizar un DataSource de acceso directo o vía JNDI enfunción del entorno de ejecución.Tradicionalmente estos requerimientos han sido implementados mediante el uso del patrón ServiceLocator deJ2EE o mediante clases de utilidad o factorías que independizan la obtención de las dependencias.
  9. 9. Selección de tecnologías 6/21Aunque el uso de estos patrones (ServiceLocator o factorías) podría ser una solución valida, se ha acordadoutilizar 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 usode clases de utilidades o factorías del código fuente, simplificando el código resultante. Además evitael 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 pordefecto del patrón Singleton dentro de los beans definidos en la factoría, reduciendo el consumo dememoria 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 deluso de inyección de dependencia, se ha establecido la norma de uso de la factoría de Spring para laimplementación de las capas de negocio y acceso a datos.Uso de java EEComo se ha comentado anteriormente la línea básica propuesta es la de elegir Spring en la mayoría dedesarrollos. Sin embargo esta arquitectura no cierra las puertas al uso de java EE y en concreto a EJBs. Enlos casos en los que la lógica de negocio vaya a ser expuesta a otras aplicaciones el modelo java EE es unaopción tenida en cuenta. En este caso los beneficios proporcionados por la sencillez de desarrollo deaplicaciones que soporten transacciones distribuidas son claramente superiores al hecho de que nos ligamosa un servidor de aplicaciones java EE (en caso de EJIE Weblogic 10). La implementación servicios en JavaEE se realiza mediante POJOs igualmente y también soporta DI tanto con anotaciones como con XML. Añadircarácter remoto a los POJOs se realiza mediante el uso de simples anotaciones (@remote, @stateless).Migración Spring / java EEEl coste de migrar una aplicación desarrollada en Spring a Java EE para añadirle la capacidad de exponer sucódigo en un entorno de transacciones distribuidas entre varias aplicaciones es mínimo. En estos casos sepuede añadir una capa de servicios a través de un EJB stateless que delegue la lógica en los serviciosimplementados en Spring (ver guía desarrollo).ConvivenciaSpring proporciona las herramientas necesarias para beneficiarse de java EE. En concreto en la capa deservicios ofrece un interceptor (SpringBeanAutowiringInterceptor) que permite inyectar beans de Spring losejbs.En cuanto a la integración con ejb2 (para el caso de Geremua 2) spring permite definir ejbs como beans despring de forma muy sencilla en sus xml utilizando el tag <jee:remote-slsb> o bien <jee:local-slsb>.
  10. 10. Selección de tecnologías 7/214.4 Capa de acceso a datosAl igual que la capa de servicios de negocio la tecnología seleccionada para la implementación de la capade acceso a datos ha sido el uso de POJOs, es decir, basada en simples componentes ofrecidos por laJDK.De esta forma obtenemos los siguientes beneficios:- Mejoramos la capacidad de testear los componentes de la capa de acceso a datos, haciendo uso dela JDK y de conexiones directas contra la base de datos- Aumenta la dependencia sobre la plataforma tecnológica al basarse únicamente en la JDKUna vez establecida la norma del uso de clases planas o POJOs el siguiente objetivo, siguiendo la norma dedelegar en lo posible el las clases comunes de infraestructura ha sido automatizar en lo posible las tareas deacceso a datos. En otras palabras, eliminar en lo posible todo el trabajo repetitivo que se pueda dar en elacceso a datos, eliminando el margen de error y mejorando la productividad.Dos alternativasActualmente los modelos existentes de desarrollo java contra base de datos están basados en JDBC. Estatecnología se apoya básicamente en el conocimiento de los desarrolladores del uso del lenguaje SQL y esconocida por una gran base de programadores java. No en vano se incluye en java SE. No ofrece dudas encuanto 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 unmayor control.En este sentido Spring nos ofrece un interesante modulo: Spring JDBC que mitiga en gran parte la escriturade código repetitivo como por ejemplo el control de errores, aperturas y cierres etc. Por otro lado no podemosdejar de lado el éxito que las tecnologías de ORM (hibernate, Toplink, Ibatis, kodo, jdo …) han alcanzado enlos últimos años. La comunidad java ha hecho un esfuerzo por unificar el uso de ORMs en la especificaciónJPA y éste forma parte ya de la plataforma Java EE. Hay que añadir además que también es una apuesta deSpring. Por todo ello esta arquitectura permite su uso.4.4.1. Spring JDBCAnalizando las funcionalidades ofrecidas en la arquitectura actual de EJIE en esta área se han detectado unaserí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 JDBCson manejados de forma manual por parte de los programadores. Es decir, cada vez que realiza unaconsulta la responsabilidad de crear y cerrar los recursos JDBC recae en los programadores. Delegaresta responsabilidad a los programadores puede generar problemas de recursos mal gestionadosademás de tener que programar dichas tareas en cada consulta sql aumentando el costo dedesarrollo.- Tratamiento de excepciones: las excepciones son tratadas de forma manual, delegando laresponsabilidad de la gestión de las excepciones a los programadores. Siguiendo con la normaestablecida en el punto anterior esta práctica de programación puede provocar la gestión inadecuadade excepciones (por ejemplo excepciones no propagadas) además de aumentar el costo de desarrolloal tener que incluir el tratamiento de excepciones en cada consulta realizada contra la base de datos(bloques try/catch).
  11. 11. Selección de tecnologías 8/21- Mapeo Java- Relacional: actualmente la asignación de los datos obtenidos desde el ResultSet aobjetos Java o la asignación de los parámetros de entrada de una consulta se realiza de formamanual. Es decir, por cada columna obtenida de base de datos o por cada propiedad que se quieraincluir 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 reflejalas tres carencias presentadas:Acceso de datos a través del uso directo de JDBCComo se puede apreciar en el ejemplo gran parte del código del método es dedicado a tareas que se repitenen cada método de acceso a base de datos, como por ejemplo crear/cerrar conexiones, tratamiento deexcepciones y mapeo de objetos-relacional, superando en muchos casos al código de negocio propio delmé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) {}}
  12. 12. Selección de tecnologías 9/21Con el objeto de mejorar estos aspectos además de cumplir con uno de los requerimientos definidos dentro dela arquitectura, automatizar y evitar tareas repetitivas en lo posible, se ha realizado una tarea de búsqueda desoluciones 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 existentesentre las que se ha seleccionado a SpringJDBC como la más adecuada. Los motivos de haber seleccionado aSpringJDBC son los siguientes:- Gestiona de forma automática todos los recursos JDBC, liberando de esta responsabilidad a losprogramadores 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 laarquitectura: 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 ybase de datos. Estas funcionalidades son utilizables únicamente cuando se mantiene unaequivalencia entre la nomenclatura de las columnas de la base de datos y de las propiedades de losBeans.- Reduce considerablemente las líneas de código necesarias para el acceso a datos, especialmente porla 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 semantiene 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 SpringJDBCComo se puede apreciar en el ejemplo, las funcionalidades ofrecidas por SpringJDBC cubren losrequerimientos definidos dentro del área de acceso a datos:- La gestión de recursos de JDBC es realizada por el objeto jdbcTemplate, eliminando de estaresponsabilidad a los programadores- El objeto jdbcTemplate genera excepciones de tipo unchecked evitando la necesidad de bloquestry/catch en el código- El mapeo del resultado es automatizado por el RowMapper automático de Spring. En el uso directo deJDBC 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 entrecolumnas 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);}
  13. 13. Selección de tecnologías 10/21Lo mismo ocurre en el caso en el que es necesario añadir parámetros de entrada en el caso de las insert oupdates como podemos ver en el siguiente cuadro:Insert de una tabla implementado mediante SpringJDBCPara comprobar la validez de la solución se han realizado diferentes pruebas de concepto para comparar laprogramació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 respuestaEn las siguientes gráficas se presentan los resultados de la comparativa realizada respecto al número delí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 = newMultipleBeanPropertySqlParameterSource(paramMap);this.getNamedParameterJdbcTemplate().update(sql.toString(), namedParameters);…
  14. 14. Selección de tecnologías 11/21Comparativa de líneas de código JDBC Plano /SpringJDBCDentro de las pruebas de tiempo de respuesta se ha implementado un método que solicita datos a un SistemaGestor de Bases de Datos Oracle 11g. En concreto, esta tabla consta de dieciséis columnas y trescientosveinte mil registros. El método, recupera secuencialmente cien, quinientos, mil, diez mil, cien mil y trescientosmil registros. Una vez obtenidos los datos de la base de datos, el método mapea los registros a clases Javautilizando 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 descartacualquier 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 seha considerado a Spring JDBC como la opción más adecuada para ser la solución de acceso a datos dentrode esta primera fase de la definición de arquitectura.
  15. 15. Selección de tecnologías 12/214.4.2. JPACon el fracaso de la especificación EJB (1 y 2) y más concretamente EJB entity, una serie de herramientaspara sustituirla ganaron cuota de mercado. Su propósito era el mismo: orientar a objetos las interacciones conbase de datos. Estas herramientas denominadas ORM (object relational mapping) hace desaparecer granparte de los problemas que se plantean en el punto anterior. El principal beneficio de esta tecnología es lareducció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 utilizadaen el mercado es Hibernate en el campo del Open Source y TopLink en el caso de las herramientascomerciales. La versión del Servidor de aplicaciones de la que disponemos trae una implementación basadaen KODO. Este producto va a ser discontinuado por parte de oracle en beneficio de TopLink. Una versiónOpen Source de este servidor EclipseLink (anteriormente Toplink essentials) está disponible también en laversió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 deJPA 1.0. Sin embargo la versión 2.0 está disponible ya e incluye algunas mejoras interesantes. Existe tambiénla 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 demostradoque 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 contrajdbc directamente el enfoque de JPA es orientado a objetos puro consiguiendo un mayor nivel de abstraccióna 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 rowMappersy en muchos casos de utilización de SQL. Es decir se trabaja con el modelo directamente.@Entitypublic class Usuario implements Serializable {@SequenceGenerator(name="usuario_seq", sequenceName="usuario_seq",initialValue=1,allocationSize=10 )@Id@GeneratedValue(strategy=GenerationType.SEQUENCE, generator="usuario_seq" )@Columnprivate int id;@Columnprivate int dni;@Columnprivate String nombre;@Columnprivate String apellido1;@Columnprivate String apellido2;@Columnprivate String email;@Column
  16. 16. Selección de tecnologías 13/21private String movil;@Columnprivate String fechaAlta;@Columnprivate 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 lapersistencia 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 lasqueries esta tecnología proporciona un leguaje orientado a objetos de búsqueda denominado JPQL como sepuede ver en la implementación del DAO en el recuadro siguiente. En todos los casos las funciones devuelvendirectamente los beans que representan el modelo sin necesidad de parseos y desparseos.@Repositorypublic class UsuarioDAOImpl implements UsuarioDAO{@PersistenceContextprivate EntityManager em;@Overridepublic Usuario add(Usuario usuario) {em.persist(usuario);return usuario;}@Overridepublic Usuario find(int idUsuario) {return em.find(Usuario.class, idUsuario);}@SuppressWarnings("unchecked")@Overridepublic List<Usuario> findAll() {Query query = em.createQuery("select u from Usuario u");return query.getResultList();}@Overridepublic void remove(int idUsuario) {Usuario usuario = em.find(Usuario.class, idUsuario);if(usuario!= null)
  17. 17. Selección de tecnologías 14/21em.remove(usuario);}@Overridepublic 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 losservicios de JDBC. En estos casos JPA proporciona la posibilidad de utilizar SQL nativo a través de susmétodos createNativeQuery de forma que evitamos el riesgo de quedarnos sin posibilidad de avanzar a medioproyecto.En cuanto a la reducción de líneas de código algunas mediciones de terceros revelan estos resultados en losque 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 denegocio implementada en la capa de servicios de negocio. Además se ha delegado a esta capa laresponsabilidad de aplicar los aspectos relacionados con los servicios remotos y manejo transaccional.
  18. 18. Selección de tecnologías 15/21La tecnología como se indicó anteriormente es más potente en este caso permitiendo de forma transparente lacreación de componentes que soporten transacciones distribuidas XA entre los distintos servicios expuestospor las aplicaciones. Además está pensado específicamente para trabajar en entornos clusterizados quenecesiten 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 quepermiten dotar de estas cualidades también al framework Spring. Aunque como se ha apuntado no sonsoluciones 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 limitadoabstrae mejor la tecnología que utilizan los servicios pudiendo intercambiar entre RMI, Hessian, jaxrpc, httpInvokker, burlap, JMS con facilidad.
  19. 19. Selección de tecnologías 16/215 Definición del modelo de programaciónPara este apartado consultar la guía de desarrollo donde se definen todas las funcionalidades y normasnecesarias para el desarrollo de aplicaciones.
  20. 20. Selección de tecnologías 17/216 Definición de la arquitectura de aplicaciónPara este apartado consultar la guía de desarrollo donde se define los módulos involucrados en el desarrollode aplicaciones.
  21. 21. Selección de tecnologías 18/217 Resumen de la selección tecnológicaTecnología Versión Función CapaTiles 2.2.2 Plantillado PresentaciónjQuery 1.8.0 Vista y Ajax PresentaciónjQueryUI 1.8.23 Vista PresentaciónjQGrid 4.4.1 Vista PresentaciónSpring MVC 3.1.2 Control PresentaciónJSTL 1.2 Vista PresentaciónSpring Framework 3.1.2 Servicio ServicioSpring JDBC 3.1.2 Persistencia JDBC PersistenciaEclipseLink 2.3.0 Persistencia JPA 2.0 PersistenciaSpring Framework 3.1.2 Contenedor IoC CoreSpring AOP 3.1.2 Aspectos CoreWebLogic 10.3.5 Servidor de Aplicaciones CoreJava Development Kit 6 Maquina Virtual Java CoreEnterprise Java Beans 3.0 Remoting RemotingJTA 1.1 Transaccionalidad ComponentesSpring Security 3.1.2 Seguridad ComponentesLogBack 1.0.6 Trazas ComponentesHibernate Validator 4.2.0 Validación ComponentesEclipse OEPE 11.1.1.7 IDE PlataformaSubVersion 1.6.13 Gestión de versiones PlataformaMaven 3.0.3 Gestión de dependencias PlataformaAnt 1.7.1 Tareas PlataformaFreemaker 2.3.16 Plantillas AsistentesHibernate Tools 3.4.0 Plugin Asistentes

×