lunes, 24 de agosto de 2009

Sencillo ejemplo de implementación del Framework IBatis en Capa de Persistencia

Como complemento al Post anterior aquí va un ejemplo de Base de datos, Java, Mysql, Open Source, Programación e IBatis para poder dar una idea de las diferentes opciones que hay en cuanto al manejo de Data Base.

Es un sistema de almacenamiento de formulas en una droguería. A continuacion creamos los DTO:

package com.serunix.model;
import java.util.List;


/**
* author hgroj@s
*
*/
public class Recipe {


private int recipeId;
private String patientName;
private List medicaments;
}

_______________________________________



package com.serunix.model;


/**
* @author hgroj@s
*
*/
public class Medicament {


private int medicamentId;
private String name;
private String description;
private Recipe recipe;
}


Luego creamos los Servicios:


package com.serunix.model.services;
import java.util.List;
import com.serunix.model.Recipe;


/**
* @author hgroj@s
*
*/
public interface RecipeDaoImpl {


List getAllRecipes();
Recipe getRecipeById(Integer id);
}

_______________________________________


package com.serunix.model.services;
import java.util.List;
import com.serunix.model.Medicament;


/**
* @author hgroj@s
*
*/
public interface MedicamentDaoImpl {


List getAllMedicaments();
Medicament getMedicamentById(Integer id);
int update(Medicament medicament);
Boolean insert(Medicament medicament);
int delete(Integer id);
}


Creamos los Los Daos:


package com.serunix.model.daos;
import java.util.List;
import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
import com.serunix.model.Recipe;
import com.serunix.model.services.RecipeDaoImpl;
/**
* @author hgroj@s
*
*/
public class RecipeDao extends SqlMapClientDaoSupport implements RecipeDaoImpl {

public List getAllRecipes() {
return (List)getSqlMapClientTemplate().queryForList("Recipe.getAllRecipes", null);
}


public Recipe getRecipeById(Integer id) {
return (Recipe)getSqlMapClientTemplate().queryForObject("Recipe.getRecipeById", id);
}
}

_______________________________________


package com.serunix.model.daos;
import java.util.List;
import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
import com.serunix.model.Medicament;
import com.serunix.model.services.MedicamentDaoImpl;
/**
* @author hgroj@s
*
*/
public class MedicamentDao extends SqlMapClientDaoSupport implements MedicamentDaoImpl {


public List getAllMedicaments() {
return (List) getSqlMapClientTemplate().queryForList("getAllMedicaments", null);
}
public Medicament getMedicamentById(Integer id) {
return ((Medicament)getSqlMapClientTemplate().queryForObject("getMedicamentById", id));
}
public int update(Medicament medicament) {
return getSqlMapClientTemplate().update("update", medicament);
}
public Boolean insert(Medicament medicament) {
return (Boolean)getSqlMapClientTemplate().insert("insert", medicament);
}
public int delete(Integer id) {
return (int)getSqlMapClientTemplate().delete("delete", id);
}
}



En seguida el mapeo XML



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN" "http://www.ibatis.com/dtd/sql-map-2.dtd">
<sqlMap namespace="Medicament">

<cacheModel id="recipeCache" type="MEMORY" readOnly="false" >
<flushInterval hours="24"/>
</cacheModel>

<resultMap class="com.serunix.model.Medicament" id="medicamentsMap">
<result property="medicamentId"
column="medicamentId"/>


<result property="name"
column="name"/>


<result property="description"
column="description"/>

</resultMap>


<select id="findMedicaments" parameterClass="java.lang.Integer" resultMap="medicamentsMap" cacheModel="recipeCache">


    SELECT * FROM tcmedicaments WHERE recipeId = #id#;


</select>

</sqlMap>

_______________________________________


 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN" "http://www.ibatis.com/dtd/sql-map-2.dtd">

<sqlMap namespace="Recipe">
<cacheModel id="recipeCache" type="MEMORY" readOnly="false" >
<flushInterval hours="24"/>


</cacheModel>
<resultMap class="com.serunix.model.Recipe" id="recipeMap">


<result property="recipeId"
column="recipeId"/>


<result property="patientName"
column="patientName"/>


<result property="medicaments"
column="recipeId" select="Medicament.findMedicaments" />


</resultMap>


<select id="getRecipeById" parameterClass="java.lang.Integer" resultMap="recipeMap" cacheModel="recipeCache">
SELECT * FROM trrecipes WHERE recipeId = #id#;

</select>

</sqlMap>
 

Y no olvidemos  el spring-context.xml

 
 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>


<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
<property name="url"><value>jdbc:mysql://127.0.0.1/SU BASE</value></property>
<property name="username"><value>SU USUARIO</value></property>
<property name="password"><value>SU PASSWORD</value></property>


</bean>

<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">


<property name="dataSource"><ref bean="dataSource"/></property>
<property name="configLocation">
<value>classpath:SqlMapConfig.xml</value>
</property>
<property name="useTransactionAwareDataSource">
<value>true</value>
</property>


</bean>

<bean id="recipeDao" class="com.serunix.model.daos.RecipeDao">


<property name="sqlMapClient">
<ref bean="sqlMapClient"/>
</property>


</bean>


</beans>



Por ultimo un Main de testeo, espero les sirva….


package test;
import java.util.Iterator;
import org.apache.log4j.Logger;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import com.serunix.model.Medicament;
import com.serunix.model.Recipe;
import com.serunix.model.daos.RecipeDao;


/**
* @author hgroj@s
*
*/
public class TestDaos {
protected static Logger logger = Logger.getLogger(TestDaos.class);


/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
ClassPathXmlApplicationContext ctxt = new ClassPathXmlApplicationContext("spring-context.xml");
RecipeDao repl = (RecipeDao) ctxt.getBean("recipeDao");
Recipe recipe = (Recipe)repl.getRecipeById(1);
Iterator iteRecipe = recipe.getMedicaments().iterator();
logger.info(" Recipe No. " + recipe.getRecipeId() + " \n");
logger.info(" Patient Name: " + recipe.getPatientName() + " \n");
while (iteRecipe.hasNext())
{
Medicament medicament = (Medicament)iteRecipe.next();
logger.info(" ----- Medicaments ------------- \n");
logger.info(medicament.getMedicamentId() + ".- Name: "+ medicament.getName() +" \n");
logger.info( "\t Description: "+ medicament.getDescription() +" \n");

}
}
}

Dejo el fuente del proyecto… FarmaciaIbatis. Este es el archivo sql de la DB el proyecto se creo en eclipse, pero si importan las librerias correspondientes y crean los todos los objetos seguro no tendran problemas con Netbeans,

viernes, 21 de agosto de 2009

No hay ingenieros de sistemas

Y como este blog intenta analizar, la actualidad de la Ingeniería de software en Colombia con sencillez e intuición, publico en mi segunda entrada el siguiente articulo tomado de la revista dinero procurando que los lectores hagan sus propios juicios de valor sobre el devenir de la Ingeniería de sistemas en Colombia:

Colombia está importando ingenieros de la India. Los disponibles son pocos, no saben inglés, no tienen la formación suficiente. Se trata de un enorme problema.

Las nuevas generaciones de colombianos estudian mercadeo, criminalística, gastronomía, decoración de interiores, diseño de modas o hasta producción de cine y televisión. Es una buena tendencia que muestra una diversificación en la oferta académica que no existía hace quince años.

Pero a la vez que aparecen nuevos campos que les interesan a los estudiantes, en el país perdió fuerza un área crucial para el crecimiento y para la competitividad nacionales. Hoy Colombia enfrenta un gran déficit de ingenieros de sistemas. No solo hay problemas de cantidad de profesionales, sino que muchos de ellos trabajan para compañías en el exterior y que otro gran grupo no tiene las calificaciones que se requieren.

El Presidente de InterGrupo, Darío Solórzano, la compañía nacional pionera en la prestación de servicios de consultoría, desarrollo de software e integración de productos y servicios en tecnología, dice que este tema es realmente preocupante para el país, porque usan la tecnología, saben de ella, pero no quieren aprenderla a desarrollar. La manipulan, pero no se interesan por ser parte de ella. “No sé qué es lo que pasa en el país. No sé si es que los muchachos no se están presentando en las universidades para estudiar esta carrera o será que se les hace muy difícil el tema. Esto lo que hace es que exista menos gente preparada, cuando la demanda es muy alta, pues sin duda, ésta es una carrera que siempre necesitará personas que creen, que inventen y que desarrollen cosas nuevas”.

Sin duda el interés por los sistemas, junto con la pasión por las ciencias, las matemáticas y la tecnología han bajado drásticamente.

El gerente general de Microsoft Colombia, Jorge Silva, dice que “posiblemente el problema, sumado a las amplias ofertas de profesionalización, también puede estar generado desde los mismos colegios, ya que no existen incentivos, desde esa etapa, para que los jóvenes se interesen por las matemáticas y para que esa materia deje de ser vista como el ‘coco’ del bachillerato”.

El problema de la escasez de estos profesionales no es solo de Colombia. Por la falta de ingenieros que trabajen en IT, Estados Unidos y el resto del mundo también están respirando preocupación frente al tema.

“La necesidad ha aumentado vertiginosamente porque cada decisión, cada paso, cada momento está impactado por la tecnología y todo lo que hay a nuestro alrededor. Un ejemplo claro puede ser el hecho de enviar un mensaje de texto o un e-mail. ¿Cuántas personas están soportando esta operación, cuánta gente participa en algo tan simple como esto? Si no hay gente capacitada vamos a tener serios problemas, cuando se presenten cosas complejas. El propio Bill Gates siempre decía que trajeran gente buena de cualquier parte del mundo porque no había suficiente gente preparada y eso es lo mismo que pasa en Colombia, no hay con quien”, argumenta Silva.

Pero aunque el problema sea global, para Colombia este diagnóstico es aterrador. Esto no solo porque la formación de ingenieros es una de las condiciones para conseguir el avance que necesita el país para su crecimiento normal, sino porque además el desarrollo de software fue escogido por el ministerio de Comercio como uno de los ocho sectores que impulsará para convertirlos en áreas de trabajo de clase mundial. Porque lo escogió como una de las apuestas para impulsar el desarrollo competitivo del país.

La preocupación la comparten las universidades y Proexport, que se han reunido para estudiar el asunto.

Encuentran, por ejemplo, que el número de graduados en sistemas en los últimos 3 años cayó 5%. Algo similar ocurre con las matrículas. Este es un fenómeno que se observa más en las universidades privadas que en las públicas.

También identificaron que hay un problema de calificación de las personas. No solo hay menos ingenieros, sino que muchos no cumplen con el perfil que requiere la industria. “En muchas ocasiones la formación está dirigida a entrenar personas de soporte de sistemas de las organizaciones. Eso no le aporta nada a la industria”, le dijo un experto en el tema a Dinero.com.

Así mismo, hay dificultades con la actualización de los profesionales y del enfoque de los programas académicos. Con la velocidad que se mueve la tecnología, un profesional que deje de actualizarse dos años pierde vigencia.

Al extranjero

El otro punto del problema, que también resulta definitivo, es que los pocos jóvenes mejor preparados están encontrando formas fáciles de engancharse con empresas extranjeras que les ofrecen una mejor remuneración que las nacionales.

Pero ahora los trabajadores no tienen que emigrar. Los empleadores que necesitan ingenieros de sistemas contratan colombianos pero no se los llevan del país. Los ingenieros trabajan desde sus casas con esquemas de oficina virtual. Ese fenómeno que es también cada vez más frecuente, reduce la oferta de profesionales disponibles para las firmas locales y encarece su remuneración

Para el gerente del Centro de Desarrollo de Software de Open Systems, Benito Pardini, la crisis por falta de gente preparada en Colombia es tan notorio, que ya han tenido que importar algunas veces personas de países como India, con el fin de suplir sus necesidades.

El directivo sostiene que el problema de falta de ingenieros calificados tiende a crecer con el paso del tiempo, además, porque el bilingüismo en el sector es muy bajo y en el mundo de hoy es prácticamente obligatorio el conocimiento de otro idioma.

Concuerda con los analistas en el sentido de que no se trata de estudiar para manejar los departamentos de sistemas de las empresas, sino de ir más allá para poder crear e innovar en el mundo de la tecnología.

En qué vamos

Por ahora Microsoft está trabajando desde una de las bases del problema, que es cerrar la brecha digital existente en el país y trabajar en conjunto con el Sena, para poner este tipo de educación en línea, totalmente gratis y lograr que cada vez más personas se interesen por aprender tecnología. Decenas de empresas en Colombia, también tienen programas específicos de formación, educación y profesionalización para cultivar y atraer a más jóvenes, sin dejar de lado indudablemente a las grandes universidades, a las que también les preocupa el futuro del país.

Algunos en el país, como la Asociación Colombiana de Ingenieros de Sistemas, no han visto el problema. En diálogo con Dinero.com, uno de sus directivos manifestó que encuentran que la situación en el mercado es normal.

Sin embargo, para los empresarios del sector, esta será una de las mayores talanqueras para el desarrollo de la actividad del desarrollo de software desde Colombia.

Para otras entidades como Proexport, una parte – quizás grande – de la solución, está en volver a entusiasmar a los colegiales con los sistemas como ocurrió en los setenta. Tal vez, hay que mostrar más en los últimos años de educación secundaria el potencial de la industria. Para ello servirían, los casos de las empresas nacionales que trabajan en temas divertidos e importantes en el mundo, como la que desarrolla programas de entretenimiento para ser usados en celulares que comercializa una compañía suiza, o la que elabora videojuegos para Xbox.

El tema crucial está planteado y la discusión abierta.

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.