Resumen de la segunda emisión de OpenTalks de JavaMéxico

El sábado 4 de diciembre pasado se presentó la segunda edición de OpenTalks. Una vez más, el ITESM campus Ciudad de México abrió sus puertas para recibir a los usuarios y entusiastas colaboradores de JavaMéxico. Como lo dicta el propio lenguaje, inició Javier Benek mediante una introducción muy ceremoniosa con la agenda para aquél soleado día otoñal. Las charlas fueron: "Proyecto Rel – Las bases de datos como deberían ser", a cargo de Francisco Jose Peredo Noguez (Luxspes en JavaMéxico), así como "Integración de Java y Flex con Spring BlazeDS", ofrecida por Miguel Daniel Ramos Martínez (dannygeek en twitter). Mientras las comunidades de proyectos alrededor de Java se dividían, JavaMéxico se unía todavía más.

El objetivo de la primera plática fue el traer la atención del modelo relacional, pues la mayoría de las bases de datos, según el Ing. Peredo, quisieran ser relacionales. Rel es un verdadero RDBMS (no como Oracle, SQLServer o DB2, que son pseudorelacionales). Rel está programado en Java.

«¿Será que haya algo más allá de SQL?» Un "mapeador" objeto-relacional se usa para obtener las características adicionales. Aunque "a escondidas", Java usa una perspectiva de apuntadores. El objetivo de esta exposición es mostrar las ventajas del modelo relacional, pues SQL es una mala implementación del modelo relacional. Es posible construir una base relacional.

«Las bases de datos son aburridas», ha escuchado en muchos lados, ¡pero no es cierto! El campo de las bases de datos está lleno de problemas importantes que quieren resolverse y muchas cosas a examinarse. Habló de una experiencia propia respecto a Telcel: SQL es tan laxo que permite hacer muchas cosas así, sin validaciones adicionales: habló de los mentados "planes a la medida" y sus vicisitudes porque el paquete que "le armaron" resulta no podía darse de alta en la base de datos, y como resultado, cobros exorbitantes llegaron a su cuenta, pues la aplicación no pudo concebir el "combo" que había contratado, aunque la base de datos lo admitió, estaba "fuera de la norma".

Una relación representa un predicado, un predicado describe propiedades que un conjunto de elementos tienen en común. Cada tupla en la relación representa una preposición que se considera verdadera, la preposición es un enunciado que afirma o niega un predicado de un sujeto. En la base de datos se planeó guardar hechos electrónicamente, para de allí mediante operaciones, derivar hechos.

El modelo relacional. En 1970, Edgar Frank Codd se basó en la lógica de predicados y en la teoría de conjuntos para proponer el modelo más utilizado hoy en día para bases de datos, pero en implementaciones incompletas: SELECT all from usuarios con nombre 'Juan'. En Java se le dice cómo lidiar con el problema, tal como lo hacía COBOL hace 40 años.

Las bases de datos se componen por una colección de relaciones. De manera simple, una relación es una tabla de tuplas o registros y atributos o campos. El Ing. Peredo hizo una comparación entre el modelo entidad-relación de Chen con el modelo relacional. El modelo es un mapa abstracto. Ese modelo nos conduce a creer que ese eso es una relación. En el modelo entidad-relación los vínculos se establecen mediante un diagrama: [artist] – [performs] – [song]. Si no se puede modelar en un mapa, no se peude hacer; es decir, no se pueden hacer "cerros" si no se supiera cómo representarlos en el mapa. En cambio, el modelo relacional no requiere más de una tabla ara representar una relación. Para darle consistencia existen las restricciones, pero los sistemas de bases de datos lo hacen muy pobremente.

El mundo es complejo: jerárquico contra relacional, sustancia contra paquete, clase contra relación. Para poner en perspectiva estas dicotomías, se utilizó un ejemplo a manera de parábola: «Un señor vive en su cabaña. Llega un demonio cargando un cadáver humano y lo deja. Llega un segundo demonio y reclama el cadáver para sí, cuando llega el primer demonio, empiezan a discutir sobre la propiedad del cadáver, pero en su discusión le fueron intercambiando partes a dicho cadáver: uno le quitaban una pierna y el segundo le colocaba una pierna ajena, el segundo le quitaba un brazo y el primero le colocaba uno ajeno. Al final los restos tienen todas sus partes cambiadas. Deciden preguntar al señor, quien responde "El primer demonio es el dueño del cadáver" para evitar que el otro demonio le hiciera daño por favorecer a alguno. La pregunta es: ¿sigue siendo el mismo cadáver humano?».

En el modelo relacional no tiene sentido almacenar lo mismo dos veces, ni un objeto vacío, o que siga siendo el mismo objeto tras cambiar todos sus atributos. En el mundo real, una sola característica no nos controla, pero el enfoque jerárquico sólo puede representarse el objeto en una sola entrada. En un marcador (bookmark en inglés) relacional de marcadores de stack clouds un elemento se puede organizar en varias secuencias. Un enfoque "en carpetas" no resuelve esta particularidad.

Las bases de datos relacionales, de acuerdo con Codd, utilizan seis operaciones básicas para su operación. Ellas son: selección (σ), proyección (π), unión [natural (⋈), equivalente o equijoin (θ), semiunión (⋉), antiunión (⊳), etcétera), unión de n elementos (⋃), diferencia (∂), renombrar (ρ) [introducida por ISBL].

La importancia de creer algo más allá de la teoría. En las bases de datos modernas, por ejemplo, el soporte para renombrar es muy pobre. ISBL es el primer lenguaje relacional, surgido en 1975, para PRTV, y el primero en traer un optimizador relacional. Después llegó Business System 12, la primera (¿y última?) base de datos verdaderamente relacional. Los ingenieros de IBM pensaron a SQL como mal diseñado y difícil de usar. BS12 fue un éxito tecnológico pero un fracaso comercial. Larry supo venderlo.

En BS12 podían pasarse tablas, actualizar en las tablas de catálogos, había una API para integrarse con terceros, y todo esto en 1982. Se podían insertar bases de datos dentro de bases de datos, y todo ello venía de paquete. Se supone que todo eso debería venir en todas las bases de datos. En contraste, JPA no tiene manera de agregar campos en tiempo de ejecución.

Como moraleja de esta historia, la mejor solución no siempre será la que sobreviva. La mercadotecnia es importantísima. Mientras en SQL es dificilísimo descomponer en partes más pequeñas, las consultas complejas en muchos casos no funcionan. Los WebServices son populares porque permiten evitar hablar con el encargado de redes. Aplicamos la tecnología para tapar problemas "de abajo".

SQL se creó en IBM. La empresa Relational Software (hoy Oracle) vio potencial y lo sacó incompleto, con muy poco qué ofrecer, pero estuvo listo y funcionando, con una relativa facilidad de implementación. El resultado: la mercadotecnia venció a la tecnología. ¿Cuántas veces ha sido así?

Pero debe quedar claro que SQL no es relacional. SQL permite duplicados, cosa sin sentido en una base relacional. Una columna en SQL puede no tener nombre, o el mismo nombre que otra. En bases relacionales todas las columnas deben tener nombre. En SQL las vistas son limitadas: no actualizan, no restringen, etcétera. Las vistas no son más que relvars al contrario que en relacional, donde cumplen las mismas características que las tablas. En SQL el orden de las columnas es significativo, en relacional, no. La ventaja: cuando las vistas son complejas, simplemente se les dice a dónde deben repartirse los atributos. En SQL al menos debe haber una columna por tabla, en relacional puede no haber columnas. En SQL, null significa una pesadilla, mientras en relacional un valor boolean se puede representar trivalentemente: verdadero, falso y desconocido. En relacional hay presunción de mundo cerrado: se representa sólo lo que se conoce.

Rel es una implementación del sucesor de BS12 llamado D. D es en lo que Hugh Darwin y Chrostopher J. Date piensan se debería utilizar hoy en día, en lugar de SQL. D se presenta al mundo a través del libro "The Third Manifest". Ellos fueron los teóricos.

Dave Voorhis es el programador creador de Rel. Todavía no está terminado. Quiere implementar su lenguaje visual Tomato para ofrecer algo como M$ Acce$$, pero relacional. Está en beta y próxima la versión 1.

Por último comparó statements entre SQL y Rel, mediante ejemplos. El sitio del proyecto es http://dbappbuilder.sourceforge.net/, entre ellos, cómo cerrar la llave en el modelo muchos a muchos para impedir, por ejemplo, que haya u solo autor. Se puede modificar en Rel incluso el modelo completamente en tiempo de ejecución.

Para mayor información, el sitio http://c2.com/cgi/wiki, por cierto, el primer Wiki en Internet, así como el por muchos conocido, por otros imitado y jamás igualdado http://luxspes.blogspot.com/.


La segunda charla inició minutos después. Versó sobre RIAs (Aplicaciones ricas en Internet, por sus siglas en inglés), aplicaciones en escritorio más aplicaciones Web. El Ing. Ramos ubicó en primer instancia las posibilidades de la plataforma Flash y el conjunto de tecnologías como Flash Catalyst, Flash Builder y Flex como framework, los clientes, Adobe AIR y Flash Player, los servicios y servidores disponibles, resaltando el esfuerzo de Adobe para unificar las experiencias de usuario en dispositivos móviles y en escritorio.

La herramienta Adobe Flash Builder "Burrito", la última versión beta al momento de esta exposición, tiene posibilidades de desarrollo para iPhone y Android, entre otros muchos. Basado en Eclipse, es ideal para mejorar interfaces de usuario, es decir, para cuando se requiera de un diseñador. Se usa Java para datos o para middleware. Flex está pensado para vistas. Flex se puede integrar con múltiples lenguajes.

El framework Spring puede entrar para eliminar la complejidad de Java empresarial, con programación indolora y dormir bien como consecuencia. El IoC o Principio de Hollywood "No nos llames, nosotros te llamamos", pasamos el control al framework. Que algo externo les diga cómo conectarse. IoC permite ensamblar un sistema a partir de sus partes. La idea es que un elemento externo sea capaz de ser "alambrado", que cada parte se pueda sustituir fácilmente, sea el core, definir los contextos o poder intercambiarlos en automático, creándose o cambiándose sin que se enteren los componentes.

En el Application Context se pueden partir las configuraciones. El IoC se encarga de crear objetos, inyectar dependencias, y unirlos en el orden correcto, basados en sus dependencias. Ello salva problemas en tiempo de ejecución. Mostró cómo hacer una inyección con Spring vía constructores mediante setters.

Flex es el framework. El lenguaje es ActionScript. En la demo que mostró,utilizó Flex Framework 4, Java 1.6, Apache Tomcat y sobre él montó BlazeDS (blazeds.war) y luego con LCDS (lcds.war y sus jars).

Como IDE está SpringSource Tool Suite y Flex Builder, además de Spring BlazeDS Integration, Test Drive y Spring Roo junta todo, modelos y vistas directamente en Flex e integra con Apache Maven. Eclipse JEE, para la gente de Java, tiene un agregado para Flash Builder.

Describió la estructura de directorios y cómo ir creando una aplicación desde cero. Para integrarlo necesitó archivos de configuración. Se pueden obtener del instalador, del WAR incluido. Habrá un XML para la configuración de servicios, de remoto, de proxy, mensajería, etcétera. Lo único a hacer es bajar el ZIP, descomprimir, pegar los WARs y ya están disponibles.

La regla básica: contexto – WEB-INF-Flex-Context. Si no está allí, el contexto no sirve.

Hizo después una vista desde la pestaña de diseño y la mostró desplegada en el navegador, mientras seguía describiendo la estructura del proyecto. Para vincularlo, nada más se declara en la sección y en WEB-INF/app-config.xml, en el mismo contexto, se le agrega el destino remoto. Así nos ahorramos hacer dos instancias. Sólo debe decírsele "usa el que existe". Flex lo mandará llamar como si hubiera sido hecho en Flex, aunque realmente lo haga Spring. Esa llamada será asíncrona. Todo el código mostrado en la charla viene del Test Drive.

Lo único que se requiere para sacar provecho de todas estas ventajas es bajar las herramientas. La integración consiste en decirle nada más dónde está la clase y función. En BlazeDS Integration se encuentra cómo se puede utilizar a Spring Roo.

Terminada la ponencia, se le preguntó al Ing. Ramos dónde daba cursos, respondiendo que en http://www.tidyslice.com/ se puede encontrar mayor información.

Y como broche de oro, se realizó una dinámica para otorgar 2 liencias de IntelliJ Idea, se regalaron plumas, CDs y se recomendaron sitios como Java Programming (with Passion!). Cierro estas (no tan) breves líneas con una invitación a las próximas OpenTalks, es una muy buena experiencia y en distintos niveles. La mejor manera de saberlo es experimentarlo.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Shadonwk

no estarian mal las fotos que

no estarian mal las fotos que benek tomo... como dice @Oscar_Ryz las paredes de texto son algo cansadas de leer.

Imagen de benek

Imágenes

Ya agregué las imágenes en un showcase al inicio del post. ;-)

¡¡Que buena reseña Mike!!

Salute.

Quihubo quihubo no me citen

Quihubo quihubo no me citen fuera de contexto :P

En este caso no está tan paredsosa y se puede leer más fácilmente. :)

Pero si, +1 por lo de las fotos.

un video

ojala agregaran un video de OpenTalks para los que no pudimos asistir, gracias.