GeoStratum es un sistema de información basado en un visor cartográfico sobre el que podemos desarrollar diferentes aplicaciones basadas en visualización georeferenciada.

La usabilidad de una aplicación de estas características alcanza niveles excelentes gracias a la sencillez de navegación, basada principalmente en clicks y movimientos del ratón, en contraposición a los típicos formularios de las aplicaciones de gestión tradicionales y la exposición de la información de forma espacial sobre localizaciones geográficas en vez de las tablas de datos normales en estos casos.

Este es sin duda un buen ejemplo de aplicación RIA, desarrollada sobre Flex y JEE, por uno de los equipos de producción de Codeoscopic. El concepto principal detrás del producto es el poder extender la base GIS para añadir información propia de un negocio concreto. En ese aspecto, GeoStratrum 2.0 es la herramienta apropiada para gestionar infraestructuras de suministro (agua, electricidad, etc), planes urbanísticos, líneas de transporte (metro, autobus,…), servicios de logística, polígonos industriales, parques naturales, etc…

Históricamente, este problema se ha resuelto con una técnica denominada Lazy Loading, de forma que nosotros podemos definir para nuestras entidades que propiedades deben de ser “Lazy” y no deben de ser iniciadas al ejecutar una query. Es decir, se trata de reducir el conjunto de datos que viajaran por la red, accediendo solo a lo necesario.

El problema con BlazeDS y LCDS es la forma de serializar la información para enviar los DTOs hacia el cliente que se lleva a cabo inicializando TODAS las propiedades del objeto, lo que obliga en caso de relaciones complejas a que se empiece a tirar del hilo y terminemos trayendo más datos de los requeridos.

En el caso de GraniteDS, existe una solución basada en externalizers, pero esta es torna demasiado compleja y tediosa de implementar ya que obliga al desarrollador a escribir un par de métodos por entidad definiendo la forma de serializar-deserializar los objetos que viajarán por el cable y especificando que propiedades se añadirán o no. En BlazeDS/LCDS, no existe por el momento una solución oficial para solventar este problema, y en principio no tiene porque haberla ya que esto no es del dominio de este software.

RIAlity, por el contrario, si es una arquitectura que debe solventar este tipo de problemas. Por eso hemos buscado una solución elgante, flexible y transparente al usuario. Esta basada en un Interceptor que se aplica a nivel de DAO. Básicamente lo que se hace es aplicar un aspecto (AOP) a todos los DAOs de forma que se intercepte la llamada a la recogida de resultados. En ese momento se aplica la funcionalidad que elimina el proxy que genera Hibernate de forma que tratemos con las entidades originales y evitemos la lógica interna del proxy que provoca que traigamos esos datos de forma innoportuna.

Esta solución permite que el usuario no se preocupe de las interioridades y decida como quiere tratar con sus entidades. Solo tenemos que indicar en las propiedades habituales si queremos un comportamiento EAGER o LAZY .

Continuando con la serie de videos, vamos a ver una demo de como generar un proyecto de modulo para RIAlity. Este proyecto ya estará configurado para usar las librerias de RIAlity, compilar en la carpeta de despliegue de la aplicación web, compilar usando los reportes del login y el shell para reducir los tamaños del modulo y otras muchas cosas.

De nuevo con unos pocos clicks de raton y en pocos segundos nos ahorraremos la tediosa configuración de todos estos parametros y estaremos listos para desarrollar la funcionalidad que queramos.

En el siguiente video, mostraremos como generar el código de una entidad sobre los próyectos generados en los pasos anteriores.

En el siguiente video se muestra la creación de los proyectos Java y Flex implicados en una arquitectura RIAlity:

El video muestra como automatizar el proceso de los 4 proyectos RIAlity através de un wizard. Este wizard genera el proyecto Java con todas las librerí­as y configuraciones preestablecidas y listo para desplegar en el servidor java. También se generan los proyectos Flex de la arquitectura: Login, Shell y CommonLibrary.

De esta forma y en apenas 1 minuto, tenemos un proyecto Flex/Java extremadamente versatil, con acceso seguro y listo para servir como esqueleto del sistema o negocio que queramos implementar.

En los siguientes ví­deos veremos como generar los proyectos de módulos y la generación de código para una entidad.

En las próximas entradas, colgaré unos videos que muestran la creación de un proyecto RIAlity en pocos minutos gracias a los wizards y plugins creados para resolver estas tareas repetitivas.

¡Permaneced atentos!

[fuente Matt Chotin]

Es decir, Flex SDK son dos compiladores:mxmlc y compc (mediante los cuales podemos compilar ActionScript 3 y MXML) y el código fuente del framework de clases y componentes para crear aplicaciones Flex. Por otra parte, el SDK de Java tiene entre otras cosas, el compilador javac y el framework de componentes Swing. Faltarí­a un lenguaje de marcado tipo XML para Swing, como contrapartida a MXML. Buscando por la web he encontrado JFCML(aunque parece ser que existen más).
Evidentemente, ambos lenguajes son muy diferentes, asi como sus objetivos, pero querí­a resaltar el caracter de software gratis, que no libre, que hace que Flex y Java sean, hoy dí­a…bastante parecidos, ¿no os parece?.

¿Por qué EasyBeans es una tecnologí­a a tener en cuenta?. Muy sencillo, EasyBeans es una implementación open source de un contendedor que soporta la nueva especificación de EJB3. En la actualidad esta especificación está en estado de borrador final. Gracias al uso de EJBs el desarrollador puede abstraerse de una serie de problemas inherentes al desarrollo de aplicaciones como son los problemas de la persistencia, transacionalidad, concurrencia, etc…y delegar todo el trabajo “sucio” al contenedor.
Lo bueno de está nueva especificación es que se ha creado teniendo en mente la “facilidad de desarrollo” o EoD (Ease of Development). Si habeis usado alguna vez EJB 2.x sabreis que aunque el concepto es muy acertado, requiere de demasiados ficheros que dificultan el trabajo diario con ellos a no ser que se utilice alguna herramienta de generación de código tipo XDoclet que automatize la creación de la mayorí­a de los ficheros haciendo que el desarrollador solo se preocupe de tan solo uno de ellos. Además es necesario un Servidor de Aplicaciones que soporte la especificación J2EE.

Con EasyBeans conseguimos las mismas ventajas que nos daban los antiguos EJBs pero haciendonos la vida mucho más fácil a los desarrolladores gracias a que ahora podemos crear sencillos POJOs que son desplegados en el contenedor EJB3 el cual es capaz de correr tanto en un servidor de aplicaciones J2EE como JOnAS o en un simple contenedor de aplicaciones web como Tomcat. Hay que tener en cuenta que es necesario usar Java 1.5 debido a que gran parte de la simplificación en el desarrollo de EJBs se debe al uso de las nuevas annotations presentes en dicha distribución de Java.

Según el equipo de EasyBeans se espera que la release final de este producto open source sea para dentro de un par de meses aproximadamente (teniendo en cuenta que la especificación final de EJB3 está al caer).

Algunos links a tener en cuenta:

• EasyBeans release notes
• EasyBeans download
• Flope: Flex2/OpenAMF/EasyBeans integration
  

• JOPE WTP Adapter

Según los autores del plugin en un correo a la lista de JOnAS:

“The goal of this plug-in is to ensure that the various WTP project types can all be correctly built and published to a JOnAS server, as well as providing some additional tools aimed at customizing WTP support for the JOnAS server. These
tools include the ability to create and populate a JOnAS configuration directory (supported in this version). The current plug-in was built to work with Eclipse 3.1.2 and WTP 1.0.1 with JOnAS 4.6.6 or later.“