miércoles, 19 de agosto de 2009

IBatis Vs Técnica Tradicional en la Capa de Persistencia

Este blog intenta analizar, sin muchas pretensiones, la actualidad de la Ingeniería de software en Colombia con sencillez e intuición. Expondré algunos ejemplos de arquitectura en varios campos de la Ingeniería de Sistemas Informáticos, conceptos arquitectónicos básicos, al igual que publicare artículos de interés procurando que los lectores hagan sus propios juicios de valor sobre el devenir de la Ingeniería de sistemas en Colombia. Esta es mi primera entrada, en la que aprovecho para exponer un estudio propio acerca de uno de los Frameworks de persistencia mas populares IBatis y Criterios para su utilizacion.

Resumen
Se analizan los problemas surgidos de la implementación de un sistema con una arquitectura de software tipo Enterprise. Entiéndase por Enterprise, sistemas cliente/servidor de tres o más capas. Basándose en este análisis se derivan criterios de diseño para la opción de usar iBatis en la capa de persistencia1 ó conservar el diseño tradicional en el desarrollo de aplicaciones empresariales bajo un entorno JEE. Las dos primeras secciones de este documento están dedicadas a ilustrar brevemente que es iBatis y en que consiste la Técnica Tradicional respectivamente, luego se presenta información acerca de la situación actual, también la arquitectura y metodología diseñadas para poder comparar las características de iBatis versus las características de la Técnica Tradicional para la capa de persistencia y finalmente se presentan los resultados y conclusiones del estudio.

Palabras Claves: iBatis, Persistencia y Distribuidas.

Abstract
It discusses the problems arising from the implementation of a system with a software architecture type Enterprise, systems client / server of three or more layers. Based on this analysis are derived design criteria for the possibility of using iBatis in the persistence layer or retain the traditional design in the development of business applications under a JEE environment. The first two sections of this document are devoted to illustrate briefly that is iBatis and that is the Technical Traditional respectively, then presents information about the current situation, architecture and methodology designed to be able to compare the characteristics of iBatis vs features the Traditional Technique for the persistence layer and finally presents the results and conclusions of the study.
Keywords: iBatis, Persistence and Distributed.

Introducción
En estos días el vertiginoso avance de la informática y las comunicaciones, con sus mayores exponentes Internet e Intranet, y la cada vez más creciente demanda de aplicaciones de calidad que den solución a diferentes necesidades, han hecho que las técnicas tradicionales de diseño e implementación de aplicaciones comiencen a ser insuficientes, por lo que un nuevo enfoque de desarrollo se hace necesario, así varios proyectos se oponen a la tendencia de una mayor complejidad, optando por construir frameworks específicos más ligeros que ayuden a simplificar las aplicaciones pero, ¿hasta que punto es conveniente que un framework como iBatis encamine el diseño de un sistema tipo Enterprise?. Con el desarrollo en paralelo de una aplicación con una sola lógica de negocio pero con dos plataformas de desarrollo distintas una tradicional y el framework iBatis; el presente documento tiene como objetivo principal fijar criterios de diseño que permitan seleccionar la tecnología a utilizar en cada caso, según el modelo del sistema a desarrollar, el tipo de plataforma sobre el cual debe funcionar y la complejidad del negocio que el sistema resuelve.

1. IBatis
El framework  iBatis DataMapper (también conocido como SQL Maps) permite reducir significativamente la codificación en java para una aplicación que maneja base de datos relacional. Quizás la primera impresión que se tenga es que es igual a Hibérnate (que es un mapeador de objetos con tablas relacionales –ORM-). IBatis es diferente, mapea las consultas SQL y permite interactuarlas con JavaBeans tanto como parámetros de entrada, como salidas.

Apache iBatis está constituido por dos frameworks independientes que generalmente se usan juntos: DAO y sqlMaps. El primero simplifica la implementación el patrón de diseño Direct Access Objects (DAO) y el segundo simplifica la persistencia de objetos en bases de datos relacionales.

IBatis no es un ORM (Object Relational Mapper), por lo que se pueden utilizar modelos de datos existentes o poco normalizados y, finalmente, no es completamente transparente (el programador programa el SQL). Ambos frameworks de iBatis son OpenSource3 han sido portados a .NET y Java con notable éxito y popularidad. Ambas versiones ya son estables y maduras.

2. Técnica Tradicional
El modelado Tradicional se basa en la plataforma J2EE, utiliza un modelo de aplicación distribuida multicapa en la que “manualmente” se conecta la base de datos, se crean statements, se construyen selects/updates/insert, se recorren resultsets y se setean atributos de objetos para guardar, buscar y recuperar los valores de los atributos de un objeto. Las partes de una aplicación modelada tradicionalmente se muestran en la figura 1 y son presentadas en los siguientes componentes que brinda J2EE4.

• Componentes de la Capa Cliente (Client-Tier) que corren en la máquina cliente.
• Componentes de la Capa Web (Web-Tier) que corren en el servidor J2EE.
• Componentes de la Capa de Negocio (Business-tier) que corren en el servidor J2EE.
• Software de la Capa de Enterprise information system (EIS-tier) que corren en el servidor EIS.

Aunque pueda constar de 3 o 4 capas lógicas, las aplicaciones J2EE modeladas de forma tradicional son denominadas aplicaciones de 3 capas, ya que hace referencia a capas físicas, puesto que son distribuidas en 3 lugares físicos diferentes, máquina Cliente, máquina Servidor J2EE y la máquina Servidor Base de Datos.

Las aplicaciones Enterprise tradicionales están basadas en componentes, cada componente tiene su propia funcionalidad y permite ser ensamblado en una aplicación J2EE, Estos componentes corren y son manejados por un servidor J2EE.

Estas aplicaciones definen los siguientes componentes:
  • Application Clients y applets son componentes que corren en el cliente.
  • Java Servlet y Java Server Pages (JSP) con componentes Web que corren en el servidor.
  • Enterprise Beans (EJB) son componentes de negocio que corren en el servidor.
3. Situación Actual
El modelo de programación Enterprise inicial o tradicional conllevaba una serie de inconvenientes que limitaron el uso y aceptación de este modelado y motivó la aparición de muchas soluciones Open Source que suplían las carencias y dificultades especialmente para la capa de persistencia, la capa de mayor criticidad y por consiguiente en la cual más trabajo se ha desarrollado en los últimos años. Debido al choque de impedancia que se produce entre los objetos del modelo de negocio y los datos persistidos en una base de datos relacional, es que esta capa requiere un tratamiento particular, gran parte de lospro ductos que se han generado atacan el problema del mapeo y acceso a los datos persistentes, algunos de los más conocidos son: EJB Entity Beans, JDBC, SQLJ, TopLink, CocoBase, Hibernate / nHibernate, JPOX (JDO), Versant (JDO), OBJ, Object Spaces y Apache iBatis. Aunque no se encuentran estudios formales comparativos sobre ellos, si se pueden mencionar algunas características.
Debido a algunas limitaciones de EJB Entity Beans han surgido las otras alternativas, básicamente los Entity Beans presentan la característica de ser usables cuando los modelos de dominio son simples, deben ser distribuidos y conectarse a otros sistemas, su utilización es buena cuando existe un mapeo uno a uno con las tablas de la base de datos, es decir cuando la granularidad es baja, no admiten herencia entre clases componentes, por esta razón y debido a esta limitación han surgido otros productos, debido a esto también es que se no se recomienda su utilización.

Toplink es un producto muy utilizado en el mercado, ahora integrado al servidor de aplicaciones Oracle 9i AS, permite entre otras cosas:

  • Integración de EJB CMP
  • Mapeo de objetos a múltiples tablas
  • Uso de herencia
  • Soporta bloqueo optimista de tablas
  • Transacciones anidadas
  • Permite adaptar el mapeo de datos entre objetos y tablas
  • Permite realizar el diseño en ambas direcciones, objetos/tablas y tablas/objetos.
  • Permite adaptar código SQL generado
  • Permite el uso de Store Procedures
  • Administra pool de objetos

 Tiene una desventaja, es dependiente de APIs propietarias.


 Hibernate también es muy utilizado tanto en el ambiente java como .net. JDO es una especificación java que se espera se convierta en el estándar de administración de bases de datos orientadas a objetos, no exige la implementación de interfaces, presenta menor sobrecarga en la creación de objetos y su configuración se realiza en un archivo XML, siendo más simple que la de los EJB CMP, presenta ventajas que heredó de EJB tales como el encapsulamiento de datos de la aplicación, el mapeo a tablas, trabaja en transacciones delimitadas por los Session Beans y administra pool de objetos, también posee ventajas propias como trabajar con clases java genéricas y las hace persistentes, requiere menor infraestructura.


 Apache iBatis, como ya se mencionó, está constituido por dos frameworks independientes que generalmente se usan juntos: DAO y sqlMaps. El primero simplifica la implementación el patrón de diseño Direct Access Objects (DAO) y el segundo simplifica la persistencia de objetos en bases de datos relacionales.
Para hacer este estudio comparativo entre frameworks y técnica tradicional, se escogió IBatis ya que no es propiamente un ORM (Object Relational Mapper), por lo que se pueden utilizar modelos de datos existentes o poco normalizados y no es completamente transparente (el programador programa el SQL), lo que hace que este sea uno de los frameworks más conocidos y robustos.


 4. Metodología y Arquitectura

 Los sistemas Enterprise buscan la solución a dos tipos de problemas del desarrollo:

  •   Problemas de forma y unidad, y problemas de integración.
  • Problemas de forma y unidad debido a que poseen un modelo de negocio subyacente que abarca distintos aspectos de un área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de usuarios, lo cual genera:
    •  Persistencia y gran volumen de datos.
    • Acceso concurrente, que implica gran cantidad de usuarios. Diversidad en la funcionalidad brindada.
    • Variedad de interfaces de usuario.
  • Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos.
  • Disonancia conceptual (modelo de datos con distintas visiones).
  • Lógica de negocio, lo que implica procesamiento de datos.
  • Problemas de integración
De la misma forma suelen presentarse problemas que se derivan de la impedancia entre objetos del dominio y la base de datos. Debido a que la mayoría de las aplicaciones de tipo Enterprise son implementadas a partir de un modelo de objetos del dominio y la base de datos que persiste los datos es relacional, se produce un choque de impedancias entre ambos modelos. Algunas de los problemas derivados de este choque son:

  • ¿Cómo se convierten las columnas del resultado de un query SQL en objetos?
  • ¿Cómo se refleja en forma eficiente en un query SQL el cambio de estado de un objeto en memoria?
  • ¿Cómo se modelan las relaciones?
  • ¿Cómo se mapean las relaciones de herencia de un modelo de objetos en un modelo relacional de una base de datos?
  • ¿Cómo se mapean los objetos cuyos atributos se persisten en varias tablas de la base de datos?

 Para minimizar estos riesgos de performance se valora el comportamiento de IBatis, el cual optimiza el código para la capa de persistencia a partir del modelo de objetos y se compara con el camino clásico o tradicional.

El mejor método de trabajo para el estudio de estos problemas de forma, unidad e integración surgidos en el desarrollo de arquitecturas Enterprise, es la implementación de una arquitectura basada en capas lógicas (Layer Pattern)5, donde una de estas capas es la capa de modelo del dominio (Domain Model Layer), ésta es la capa que se busca que tenga el menor acoplamiento posible, con el fin de marcar diferencias claras entre ambos diseños. De esta forma lograremos la riqueza del modelo de objetos teniendo modelos relacionales sin pérdida de performance y explotar mecanismos propios de un modelo relacional.


Dado el tipo de aplicaciones seleccionado, es decir del tipo Enterprise, donde las aplicaciones poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo, y van modificando a las actuales, y nutriéndose con otras nuevas, la idea central es modelar el dominio utilizando programación orientada a objetos, obteniendo así, un modelo del dominio, formado por objetos muy similares a la realidad, que se rigen según las reglas de negocio.

Para poder acompañar los cambios del negocio, actualizando así el modelo del dominio, se buscó la manera de mantener este dominio lo mas aislado posible del resto de la aplicación, es decir desacoplar al máximo al modelo de dominio del resto de la aplicación. Entonces partiendo de una arquitectura cliente servidor, se logró una máxima distribución de capas, al introducir la capa de persistencia. El objetivo de la capa de persistencia es que el modelo, no conozca la manera en que sus datos son persistidos o almacenados, en la capa de datos, ya que éste es un problema tecnológico que no tiene nada que ver con los problemas del dominio a resolver; además permite encontrar diferencias claras entre el comportamiento de la capa de persistencia bajo el diseño tradicional y el diseño mediante iBatis, objetivo principal de este estudio. La arquitectura final en capas puede verse en la figura 2.



En la figura 3a se distribuyen las diferentes partes de la aplicación sobre la arquitectura tradicional, se puede notar la diferencia entre esta y la arquitectura con iBatis de la figura 3b que respetará la distribución añadiendo tres subcapas mas, lo que hace un sistema mas escalable y más seguro ante ataques. 

La capa de Abstracción será el interfaz con la capa de la lógica de negocio, haciendo las veces de “facade”. Se implementa mediante el patrón Data Access Object (DAO).

La capa de Framework de Persistencia será el interfaz con el gestor de Base de Datos ocupándose de la gestión de los datos mediante un API, que en Java es JDBC. La capa de Driver se ocupa de la comunicación con la propia Base de Datos utilizando un Driver específico para la misma.



Para el modelo iBatis (figura 3b), es obligatorio encapsular las operaciones persistentes y aislar su uso de la implementación, es decir, usar patrón DAO. De este modo, se tiene toda la potencia de SQL sin una línea de código JDBC y se respeta la arquitectura distribuida propuesta separando la capa de negocio y la de acceso a datos.
5. Resultados
Se determinó que el análisis y diseño de un sistema Enterprise debe implicar el uso de patrones ya examinados y probados, evitando a los participantes del desarrollo el redundar en problemas comunes resueltos por herramientas o alternativas confiables; sin embargo lo importante es saber y distinguir claramente si estas herramientas son acordes a la problemática a resolver. Básicamente todo sistema Enterprise tiene una estructura cliente/servidor, distribuido en capas, generalmente se obtiene el modelo de clases y también se diseña el modelo de datos donde se almacena la información no obstante se encontró que la etapa más critica es la persistencia de datos: conectar la fuente de datos, crear statements, construir selects/updates, recorrer resultsets y setear atributos de objetos para guardar, buscar y recuperar; se obtuvo que iBatis sqlMap simplificó esta tarea resumiéndola a la configuración de ficheros XML, con SQL, Pero su uso no es óptimo en todos los casos.

Criterios de uso
IBatis sqlMap es válido cuando:
  • Se sabe que el RDBMS (motor de base de datos) puede cambiar en el futuro. 
  • La implementación del acceso a datos puede requerir cambios sustanciales en el futuro. Portabilidad: entre Java y .NET; entre diferentes proveedores de bases de datos.
  • La implementación del acceso a datos puede variar entre un entorno de producción y otro (software comercial en distintos clientes).
  • Se requiere una curva de aprendizaje rápida y pocos conocimientos previos, y no requiere aprender un lenguaje de consultas como en Hibernate o EJB CMP.
  • Se necesita manipular el SQL (para utilizar SQL propietario y optimizarlo) o se necesita llamar a procedimientos almacenados.
  • El modelo de datos existe previamente y no está muy normalizado (aunque lógicamente se puede utilizar con modelos nuevos y normalizados).
  • Se desea alto rendimiento y optimización. Se trata de código abierto, es decir Open Source.
  • Se prefiere separación entre SQL y el lenguaje de programación de la aplicación (Java/.NET).

Se debe usar diseño tradicional cuando
  • Se requiere una automatización total y transparente de la persistencia.
  • Se requiere soporte multi-RDBMS (motor de base de datos) transparente y automática.
  • Las bases de datos que se gestionan no son exclusivamente relacionales. Se deben construir sentencias SQL dinámicamente.
Consideraciones y recomendaciones
  • La capa de persistencia no debe contener lógica alguna.
  • Se recomienda, en la medida de lo posible, ser independiente del motor de base de datos que subyace.
  • ¿Se pueden utilizar procedimientos almacenados? Se recomienda que no, si implementan lógica de negocio. Aunque se proporcionan mecanismos para el acceso a procedimientos almacenados pre-existentes, no se propugna su uso, sobre todo por romper la responsabilidad de las distintas capas del sistema, y vincular en exceso un sistema a un modelo específico de base de datos. Existen ciertas consideraciones especiales, como casos específicos de rendimiento, o implementación de ciertos aspectos específicos de acceso a datos, en los que se podrían usar, pero deben tener un análisis previo importante.
  • Es obligatorio encapsular las operaciones persistentes y aislar su uso de la implementación, es decir, usar patrón DAO.
  • No se usan las clases de iBatis propuestas para construir el patrón DAO, tal como las factorías de iBatis. Esta funcionalidad está delegada a Spring.
  • Se recomienda usar una notación de métodos DAO consistente y uniforme: delete, insert, update, findAll, findByPrimaryKey, findAllByFecha, findByPrimaryKeyWithUsuario.
  • Es obligatorio usar iBatis con Spring, heredando, directa o indirectamente, de la clase SqlMapClientDaoSupport.
  • Se recomienda posibilitar el desacoplo iBatis de Spring, por medio de unos pequeños cambios; por ejemplo, cambiando una clase padre de la que hereden todos los DAO.
  • Se recomienda no realizar captura de excepciones, sino delegar esta operatividad a un aspecto (AOP). 
6. Conclusiones
El desarrollo de sistemas Enterprise puede involucrar el uso de patrones previamente desarrollados que resuelven problemas comunes. Lo esencial es diferenciar y saber que herramientas son coherentes a la problemática que el sistema presenta.

El uso de frameworks acordes a la problemática a resolver, facilitan el desarrollo de sistemas ya que señalan un precepto y una estructura ya madurada para un tipo de arquitectura dada. Por lo que problemas frecuentes y genéricos ya están resueltos y optimizados por el framework y se permite hacer uso de ellos y especializarlos extendiendo al mismo, esto garantiza un rápido start up de la aplicación.

Con la utilización de un framework como iBatis incorporando metodologías y procesos de desarrollo correctos, se agiliza el desarrollo de una aplicación, y es más factible obtener un resultado exitoso.

  
Con iBatis se puede mapear fácilmente las consultas que se necesitan para proyectos tipo Enterprise. La sintaxis utilizada está fuertemente aislada en la lógica de negocio. Esto permite fácil disposición a modificaciones futuras.

La separación de una aplicación en capas permite retirar las problemáticas y abordar los problemas de cada una en forma más independiente del resto de las capas, permitiendo así ocuparse del desarrollo en forma paralela una vez que se describieron las interfaces entre capas, permitiendo tener roles especializados en los temas a abordar en cada capa.

10 comentarios:

  1. Hola!

    Encontré muy bueno tu articulo.

    Saludos

    ResponderEliminar
  2. Buen día, realmente no me queda muy claro la diferencia entre un framework como iBatis (actualmente MyIbatis) y un Object Relational Mapper (ORM). Según entiendo es una capa intermedia entre la base de datos pura y la definición de la misma (acceso a datos) pero a mi parecer no simplifica tanto la declaración de los objetos como lo puede hacer un ORM (llamese Doctrine, Hibernate, etc). ¿Cuales serían realmente las ventajas de hacer uso de un framework intermedio si de igual forma tengo que estar escribiendo sentencias sql en el desarrollo de mi software?

    ResponderEliminar
  3. El articulo es interesante, pero considero que se debe ampliar el glosario, debido a que no todos los ingenieros de sistemas esta directamente relacionados con el uso de bases de datos y programación orientada a objetos. Pero en general se trata de describir las caractetiticas de cada Framework.

    ResponderEliminar
  4. En una base de datos como ORACLE, en donde el motor realiza el procesamiento de las sentencias y entrega un resultado, y basados en la lectura me surge una pregunta ¿cómo es el rendimiento obtenido en la red, entendiendo que el Framework es quien realiza las consultas?

    ResponderEliminar
  5. @Luis: el framework es una capa de abstracción más, la mayoría contienen entre sus características la opción de convertir todo tipo de consultas (normalmente sql) en un lenguaje común que se entienda en los diferentes motores de BD. Con esto, la aplicación web se independiza casi totalmente del motor, ya que este pasa a un segundo plano. Además, existen mapeadores que se encargan de transformar las tablas en objetos y los campos de dichas tablas en propiedades de los objetos, normalmente se conocen como ORM... pero si comprendo bien el texto, MyIbatis se centra en rendimiento para una sola base de datos y a su vez al momento de desarrollar, lo que sacrificaría esa capacidad de utilizar múltiples bases de datos...

    ResponderEliminar
  6. Resulta interesante la presentación de El framework iBatis DataMapper el cual permite reducir significativamente la codificación en java para una aplicación que maneja base de datos relacional.
    De igual forma, resaltar su interacción con arquitecturas basadas en capas lógicas.
    Vale la pena ahondar un poco más en el tema y en lo posible de manera práctica para aclarar mejor el concepto.

    ResponderEliminar
  7. El artículo es interesante ya que nos deja ver las diferencias, sus ventajas y desventajas en el desarrollo de aplicaciones a través de capas y la importancia que hay en separar cada una de ellas para un mejor seguimiento, escalabilidad y actualización de las mismas. No sé hasta qué punto es bueno el uso de framework ya que estos podrían desmejorar el rendimiento entre la aplicación y la base de datos pero al mismo tiempo puede mejorar la portabilidad, mantenimiento de las aplicaciones y facilidad en la codificación. Yo creo que el uso de estos dependería del objetivo que se quiere obtener con el software que se desea realizar o las necesidades del desarrollo del proyecto.

    ResponderEliminar
  8. El artículo es entretenido, porque nos muestra una descripción muy detallada de las diferentes funciones de la programación en Ibatis, explicándonos de forma que podamos entender muy bien el artículo, sin tantas vueltas ni enredos como en otros artículos relacionados, que al final no llegan a solucionar la inquietud que a uno en ocasiones le surge. Pienso que la programación en Ibatis al tener los SQL visibles en un fichero, da siempre la sensación de tener más control sobre lo que se está haciendo, a mi modo de percibir el articulo. Pero mi duda es si Ibatis se podrá llevar bien en Eclipse . Gracias

    ResponderEliminar
  9. Saludos a todos. Según entiendo, Ibatis es un framework que a través de mapeo reduce de manera considerable la codificación de una aplicación, sin embargo, esto resulta altamente útil para proyectos grandes y con un nivel de complejidad alto, aunque en mi opinión para desarrollos pequeños (y si se quiere medianos) resulta más eficiente hacer uso de las técnicas tradicionales aplicadas a las capas de persistencias, tanto por recursos de máquina como por velocidad de procesamiento tanto en plataformas de desarrollo (ambiente de pruebas)como en plataforma de producción (producto de usuario final).

    ResponderEliminar