avanttic blog

A veces nos encontramos con la necesidad de mostrar en la misma fila de una tabla campos procedentes de diferentes fuentes de datos (‘data sources’).  Puede darse el caso,  por ejemplo,  de que necesitemos cruzar mediante una operación ‘JOIN’ dos tablas que se encuentran en distintas Bases de Datos. También es posible que algunos atributos se encuentren en la B.D.  y el resto deban obtenerse mediante un Web Service. Este post  muestra los pasos a seguir para implementar una solución para este segundo escenario.

Vamos a describir de forma concisa el problema:

1. Disponemos de una tabla en la B.D. donde se registran a modo de log todas las conexiones a nuestro sistema. Se guardan dos atributos, la fecha de conexión y la dirección IP de la máquina que se conectó.
2. Tenemos que diseñar una pantalla que presente de forma tabular el log de conexiones con las siguientes columnas: fecha, IP y una tercera columna con el nombre del país al que pertenece la dirección IP.

Los dos primeros campos, los tenemos, pero la información correspondiente al tercero, ¿de dónde la obtenemos?  Muy sencillo: existen varios  Servicios Web  que nos proporcionan este dato,  uno de los más conocidos es GeoIP.  Trabajar con él será fácil: nosotros le damos una dirección IP  y el WS nos responde con el nombre del país.

¿Y cómo pegamos lo uno con lo otro, y en que lugar? El punto de encuentro está claro: en la capa del modelo, exactamente en el mismo ViewObject donde se realiza la consulta sobre la tabla de Log; añadimos un nuevo atributo llamado Country  y guardamos los cambios. Una vez hecho esto, editamos la clase que implementa el registro del ViewObject y sobrescribimos  el método getCountry() para que se comunique con el  Web Service, consiga el país y lo devuelva. No lo hará directamente, usaremos un JavaBean para ocultar y envolver las llamadas al servicio.

Hay que hacer notar, que estamos planteando un caso muy sencillo,  basta con utilizar un ViewObject de sólo lectura y no basado en entidad. Si los campos de la B.D. tuvieran que ser modificables, entonces diseñaríamos una vista basada en entidad y todo lo dicho para la columna externa (Country)  seguiría siendo válido. Otro caso de uso un poco mas complicado contemplaría la posibilidad de trabajar con WS que proporcionan operaciones  CRUD (create, read, update, delete). Entonces crearíamos entidades basadas en Web Services (y tendríamos que trabajar a nivel de entidad ocultando el origen de datos a los ViewObjects), pero eso lo dejamos para un futuro post.

Pongámonos manos a la obra:

1. Creamos un proyecto nuevo en nuestra aplicación y a partir del WSDL del servicio construimos un proxyService (de tipo JAX-WS,  con el ‘endpoint‘ de la versión 1.2)

2. Creamos un JavaBean, para envolver la llamada al servicio. A partir de este Bean tendremos la posibilidad de crear un DataControl que nos permita trabajar de forma declarativa con los datos las estructuras del WS.  El método getGeoIP() se encarga de hacer la llamada a la operación del WS que nos interesa.

3. Diseñamos el  ViewObject  (LogView1) a partir de la tabla Log y le añadimos un atributo nuevo, Country.

4. Sobrescribimos  el método getCountry() en la implementación del registro de LogView1, para que obtenga a través d nuestro JavaBean el país correspondiente a la dirección IP.

5. Diseñamos la página con  la tabla de log, arrastrando y soltando el DataControl correspondiente a la vista LogView1 sobre la página, ejecutamos y vemos el resultado final.

Presentación homogénea de columnas que provienen de diferentes fuentes de datos

De esta forma en cinco sencillos pasos hemos conseguido resolver el problema. Seguramente no es muy eficiente llamar al servicio para cada fila, para mejorar esta situación usaremos nuestro JavaBean. Teniendo en cuenta que este tipo de servicios web ofrece operaciones que permiten pasar como parámetro listas de elementos en vez de elementos individuales y de igual manera devuelven listas de resultados, podremos invocar la operación del WS  una vez y mantener en un HashMap la lista de paises, evitando así una invocación  por cada registro.