Abstract— This paper describes some metrics to consider for

web application development with frameworks like Google Web Toolkit and Google App Engine, technologies with a particular mode of operation and with some restrictions that affect the design and the functionality of these applications, but also offer great benefits such as improved user interface, better usability, improved performance, greater scalability and as the ability to use certain services, which allow application interoperability with different systems.

Keywords— Web application, Java, GWT, App Engine, JDO, design patterns, Model View Presenter.

I. INTRODUCCIÓN A WEB 2.0 ha sido gran influyente en el surgimiento de tecnologías que buscan facilitar el desarrollo de

aplicaciones Web y a la vez ofrecer funcionalidades que, hasta hace poco, solo se encontraban en aplicaciones de escritorio. Una de estas tecnologías es Google Web Toolkit, un framework orientado a la construcción de RIAs (Rich Internet Applications) [20], que propone un nuevo paradigma en lo referente al desarrollo de este tipo de aplicaciones.

Por otro lado, cuando se requiere gran capacidad de procesamiento y alojamiento Web a bajo costo, aparecen empresas como Google o Amazon que permiten el uso de su infraestructura para el alojamiento y ejecución de aplicaciones Web por medio del empleo de frameworks como, por ejemplo, App Engine para el caso de Google [16]. Este tipo de servicios si bien ofrecen grandes beneficios, también implican algunas restricciones que limitan o condicionan el diseño de la aplicación.

En el presente artículo se dan a conocer aspectos generales del uso de las tecnologías Google Web Toolkit y Google App Engine para el desarrollo de aplicaciones Web. En primer lugar se contextualiza al lector acerca de que son y cómo funcionan estas tecnologías, luego se define la arquitectura sugerida para este tipo de aplicaciones mediante el uso de patrones de diseño que mejoran y facilitan controlar el comportamiento de esta. También se mencionan algunos detalles técnicos a tener en cuenta durante el diseño e implementación de la aplicación y finalmente se presenta una síntesis de las ventajas y desventajas en que se incurre al hacer

1J. D. Yanquén, Universidad Pedagógica y Tecnológica de Colombia,

jesus.yanquen@uptc.edu.co J. A. B. Ricaurte, Universidad Pedagógica y Tecnológica de Colombia,

javier.ballesteros@uptc.edu.co

uso de estas tecnologías.

II. CONCEPTUALIZACIÓN A continuación se describen los conceptos necesarios para

lograr una contextualización sobre qué son y cómo funcionan las tecnologías objeto de estudio.

A. Google Web Toolkit (GWT) Es un framework para el desarrollo de aplicaciones Web

con interfaz gráfica de usuario enriquecida (RIA) basadas en Ajax (Asynchronous JavaScript and XML, JavaScript asíncrono y XML), por medio del lenguaje de programación Java [20]. Dado que Ajax basa su funcionamiento en lenguajes tipo script, GWT compila el código Java de la aplicación a su equivalente JavaScript para poder hacer uso de esta técnica. Es importante aclarar que para realizar el proceso de compilación, se requiere un conjunto de librerías JavaScript que emulan las clases incluidas en la máquina virtual de Java conocido como JRE (Java Runtime Environment, Entorno de ejecución de Java) emulator [7], sin embargo, dado que JavaScript no soporta características ofrecidas por la tecnología Java como el manejo de hilos, sockets, archivos, entre otros, no todo el código Java puede compilarse a JavaScript [7].

En [11] se evalua como GWT proporciona APIs que facilitan la creación de interfaces gráficas de usuario de forma similar a las librerías AWT o Swing de Java, este ofrece diversidad de componentes gráficos que van desde manejadores de espacio (layouts), hasta listas y tablas para la muestra de datos [19]. Respecto a la apariencia de cada componente gráfico, se puede emplear hojas de estilo en cascada (CSS) con el fin de separar el comportamiento de un objeto y la forma en que se presenta [8], además de facilitar las modificaciones de la apariencia de la aplicación sin tener que volver a compilarla.

Una característica de GWT es que, al estar basada en Ajax, su ejecución se realiza en el cliente por medio del navegador Web, lo cual permite que el control de la interfaz gráfica de la aplicación sea manejado allí y no en el servidor como lo hacen las aplicaciones Web tradicionales; esto trae la ventaja del hecho de tener que transportar con la interfaz de usuario a mostrar solo la información necesaria para su funcionamiento, lo cual a su vez libera la carga en el servidor y ofrece una mayor interactividad y usabilidad en este tipo de aplicaciones. Un acercamiento a tal comportamiento se puede observar en la Fig. 1:

Web Application Deveploment Technologies Using Google Web Toolkit And Google App

Engine-Java J. D. Y. Correa and J. A. B. Ricaurte1

L

372 IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 2, MARCH 2014

Figura 1. Aplicación web tradicional (a) vs aplicación web basada en Ajax (b) (Adaptada de [10])

Respecto a la comunicación entre el cliente y el servidor, este framework ofrece mecanismos para el intercambio de datos, independientemente de la tecnología usada en el servidor, por medio de XML, JSON (JavaScript Object Notation) o HTTP; sin embargo, si se usan tecnologías Java como Servlets o JSP, se puede emplear, además de los anteriores, GWT-RPC (Remote Procedure Call) [1, 21], un mecanismo basado en Java Servlets para el transporte directo de objetos a través de la red [21].

B. Google App Engine Es una plataforma y un SDK (Software Development Kit )

para el desarrollo y alojamiento Web usando la infraestructura de Google, diseñado con el propósito de tener gran escalabilidad y rendimiento, siendo capaz de distribuir la carga en tantos servidores como sea necesario con el fin de proveer una rápida respuesta. Su componente principal, el AppEngine Datastore, está basado sobre la tecnología de la BigTable de Google, una base de datos NoSQL (Not only SQL) cuyos datos son almacenados de forma similar a una estructura tipo tabla Hash, es decir, por el par clave-valor aunque mucho más avanzada [18].

AppEngine tiene soporte para los lenguajes de programación Python y Java, para este último permite el acceso al almacén de datos por medio de las interfaces para acceso a datos JPA (Java Persistent API) y JDO (Java Data Objects) con Datanucleus como implementación en ambos casos [6]. Sin embargo, no soporta todas las cualidades definidas en estos estándares puesto que tiene restricciones en lo referente a joins entre entidades, consultas polimórficas, búsqueda avanzada de texto, entre otras [5].

C. Java Data Objects (JDO)

Es un estándar para el acceso a datos persistentes en bases de datos desde aplicaciones Java, por medio del uso de objetos planos Java (POJOs) [14]. A diferencia de frameworks similares, JDO se caracteriza por estar orientado a diferentes fuentes de datos [14] como pueden ser archivos XML, bases de datos relacionales, bases de datos NoSQL, entre otros. Adicionalmente, al ser un estándar, para hacer uso de este se requiere de alguna de sus implementaciones como puede ser

TJDO (TriActive Java Data Objects) o Datanucleus puesto que por sí solo no es funcional.

III. ARQUITECTURA SUGERIDA El desarrollo de aplicaciones con GWT implica una

separación de la funcionalidad de estas entre el cliente y el servidor, por lo cual es necesario saber que parte funcional de la aplicación será ejecutada en el cliente y que parte en el servidor.

A partir de lo anterior, es conveniente estructurar la aplicación GWT de tal manera que todo el manejo de la interfaz gráfica (creación y control de componentes gráficos y manejo de eventos), sea realizada en el cliente, mientras que la manipulación y almacenamiento de la información sea una tarea realizada en el servidor. Esta estructura mejora la operación de la aplicación puesto que, al no transportar el código de la interfaz gráfica en cada petición, se optimizan los tiempos de respuesta y mejora la interacción del usuario.

Respecto al manejo de la interfaz gráfica, existen diversos patrones de diseño que solucionan problemas como la interacción entre vistas y la independencia entre la forma en que se muestran los datos de las acciones generadas como respuesta a un evento. Entre estos patrones de diseño se destacan Model View Controller (MVC) y Model View Presenter (MVP) [3], patrones que en el transcurso de los años han demostrado su efectividad en el control del comportamiento de la interfaz gráfica, motivo por el cual vale la pena resaltar la forma en que operan y su estructura interna.

El patrón de diseño MVC está formado por la interacción de los patrones de diseño Observer, Composite y Strategy. El primero de ellos es implementado entre la vista y el modelo con el fin de lograr una sincronización entre ellos, de tal manera que cualquier cambio en el modelo sea notificado a la vista y esta realice la acción correspondiente. Por otro lado, el patrón Composite es implementado en la vista para la creación de interfaces gráficas complejas a partir de elementos gráficos simples. Finalmente, el patrón Strategy es implementado en el controlador como mecanismo regulador entre las acciones generadas en la vista y enviadas al modelo, esto con el fin de separar la forma en que se muestran los datos de su comportamiento [4].

En cuanto al patrón de diseño MVP, se sabe que es una variación del patrón MVC en donde se elimina la implementación del patrón de diseño Observer entre la vista y el modelo, lo cual implica que todo el control de la interacción entre estos sea manejado por el presentador (el equivalente al controlador en MVC pero con más funciones). Respecto a los demás patrones que hacen parte de MVC (Composite y Strategy) mantienen su finalidad y funcionamiento en MVP [9], [15].

En cualquiera de los casos, los patrones mencionados permiten una adecuada interacción entre la interfaz gráfica, el modelo de datos y el control del comportamiento de estos. Sin embargo, para la realización de pruebas unitarias a la interfaz gráfica en aplicaciones GWT es conveniente el uso del patrón

DAVID YANQUÉN CORREA AND ANTONIO BALLESTEROS RICAURTE : WEB APPLICATION 373

MVP en lugar del patrón MVC debido a que, gracias a su estructura, es posible simular el comportamiento de objetos de la interfaz gráfica por medio del uso de Mocks2, técnica que no funciona muy bien si se emplea el patrón MVC.

Retomando la arquitectura, por el lado del servidor, se manipula y almacena la información necesaria para el funcionamiento de la aplicación. Allí, por medio de App Engine, es posible hacer uso de la infraestructura de Google para realizar dichas tareas. Dado que App Engine puede usarse únicamente por los lenguajes de programación Java y Python (aunque también soporta lenguajes interpretados como JavaScript y Ruby), en este trabajo se hace referencia a su versión para Java.

De acuerdo con lo explicado, la arquitectura sugerida para el desarrollo de aplicaciones GWT y AppEngine-Java se muestra en la Fig. 2:

Figura 2. Arquitectura sugerida para aplicaciones GWT y AppEngine

Como se muestra en la fig. 2, en el cliente se controla todo lo relacionado con la capa de presentación, esto es el bus de eventos, los presentadores, las vistas o interfaces gráficas y las definiciones de los servicios para la comunicación con el servidor. Por el lado del servidor se encuentran las reglas de negocio, el control de acceso a datos, la seguridad y la implementación de los servicios para el intercambio de información con el cliente; nótese también que se sugiere emplear GWT-RPC para la comunicación entre el cliente y el servidor, por lo que este permite el transporte directo de objetos, lo que a su vez facilita su manipulación.

IV. IMPLEMENTACIÓN

Con base en la arquitectura planteada en la sección III, a continuación se presentan algunos detalles técnicos para el desarrollo de aplicaciones Web que hagan uso de las tecnologías GWT y App Engine.

A. El Modelo Como se sabe, el modelo de dominio es una abstracción en

donde se plasman las entidades y relaciones entre sí, involucradas en la ejecución de un proceso. Para aplicaciones

GWT generalmente se dispone de un modelo para el servidor, en donde se encuentran las reglas de negocio y las entidades a persistir, y un modelo para el cliente usado para el transporte y visualización de datos. Si se emplean POJOs, puede darse el caso de usar el mismo modelo tanto en el cliente como en el servidor, siempre y cuando todas las clases que componen el modelo puedan compilarse a JavaScript.

Sin embargo, el hecho de usar App Engine-Java implica tener en cuenta las restricciones en la forma en que guardan los datos a la hora de diseñar el modelo de dominio, debido a que el almacén de datos de Google no soporta algunas características del diseño orientado a objetos.

Como solución a lo anterior, surgen las siguientes recomendaciones a tener en cuenta en el diseño del modelo de dominio para una aplicación que haga uso de estas tecnologías:

• Utilizar composición de clases en lugar de herencia. • Preferir el uso de relaciones sin propiedad a

relaciones con propiedad. • Aplicar el patrón de diseño DTO (Data Transfer

Object) [22] para el envío de datos al cliente. • En el caso de relaciones muchos a muchos

únicamente pueden usarse por medio de relaciones sin propiedad, pero es responsabilidad de la aplicación mantener ambos lados de la relación.

B. La persistencia con JDO En lo referente a la persistencia, App Engine-Java permite

que por medio de las interfaces para el acceso a datos JPA o JDO se controle la creación, edición, eliminación y obtención de objetos sobre el almacén de datos de Google [6]. Para el caso de JDO, el primer paso es realizar los mapeos de las entidades que componen el dominio de la aplicación, tarea que puede realizarse por medio de la inclusión de anotaciones Java sobre la entidad o de forma independiente en archivos basados en XML. En cuanto la manipulación de objetos con JDO [6] es necesario saber:

• Para guardar por primera vez un objeto, basta con utilizar la función makePersistent de la interfaz PersistenceManager y enviar como parámetro el objeto a guardar.

• Para actualizar un objeto es necesario obtener la transacción actual utilizando la función currentTransaction de la interfaz PersistenceManager, abrirla mediante la función begin, obtener el objeto a actualizar del almacén de datos, editar los atributos o propiedades del objeto y finalmente confirmar los cambios mediante la función commit de la transacción.

• Para eliminar un objeto puede emplearse la función deletePersistent de la interfaz PersistenceManager y enviando como parámetro el objeto a eliminar.

• Para obtener uno o varios objetos de una entidad es necesario el uso de la interfaz Query, enviando por parámetro la consulta jdoql (JDO Query Language. - Lenguaje para consulta de objetos de JDO) en donde se

374 IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 2, MARCH 2014

especifica la entidad y la condición de los objetos a obtener.

Como se puede observar, el uso de JDO facilita el control y manipulación de objetos que residan en el almacén de datos de Google, sin embargo, la complejidad en su uso depende del tipo de relaciones empleadas en el modelo de dominio y la forma en que se realice el mapeo.

C. Construcción de la capa de presentación con GWT El objetivo principal de GWT es brindar las librerías

necesarias para facilitar la creación de interfaces gráficas enriquecidas en aplicaciones Web por medio del lenguaje de programación Java. El hecho de crear la interfaz de usuario mediante programación orientada a objetos en lugar del uso de lenguajes de marcado, facilita la implementación de patrones de diseño que mejoran la estructura de la aplicación.

Figura 3. Diagrama de clases MVP + EventBus + AppController

Con base en la arquitectura presentada en la sección II para este tipo de aplicaciones y la estructura propuesta por Chris Ramsdale [15], se muestra a continuación un esquema que refleja algunos detalles de la implementación del patrón de diseño Model-View-Presenter para el control del comportamiento de la interfaz gráfica de una aplicación GWT.

De la Fig. 3 vale la pena destacar:

• Model: hace referencia a cualquier entidad concreta que haga parte del modelo de dominio de la aplicación

• Presenter: clase encargada de controlar el comportamiento de la interfaz gráfica y su interacción con las entidades del modelo de dominio.

• Display: interfaz en donde se definen los tipos de datos a intercambiar entre el presentador y la vista

• View: es la clase en donde se crean los componentes gráficos para mostrar la información del modelo,

implementa la interfaz Display para interactuar con el respectivo presentador.

• EditEvent/ListEvent: clases en donde se define el tipo de evento por medio de la implementación del patrón de diseño Command, en este caso editar y listar respectivamente.

• EventBus: manejador de eventos de la aplicación • AppController: controlador principal de la

aplicación. Allí son creados e invocados todos los presentadores, así como la implementación del comportamiento de los eventos mencionados.

• RpcService: servicio RPC mediante el cual se logra el intercambio de datos con el servidor.

V. VENTAJAS Y DESVENTAJAS

Como se ha podido apreciar a lo largo del artículo, los frameworks GWT y AppEngine presentan algunos inconvenientes a la hora de desarrollar aplicaciones Web que contrarrestan los beneficios que ofrecen. Con el fin de ofrecer al lector la posibilidad de emitir su propio juicio acerca del uso de cada tecnología, se muestra en la tabla I y tabla II algunas ventajas y desventajas encontradas en estas.

TABLA I. VENTAJAS Y DESVENTAJAS FRAMEWORK GWT

GWT Ventajas Desventajas

Facilita la creación de interfaces gráficas complejas para aplicaciones Web, con soporte de características como drag & drop.

Genera demasiado código HTML para mostrar cosas simples, esto aumenta el tiempo de procesamiento para su visualización.

El soporte de JSON y XML permite la interoperabilidad con diferentes tecnologías para el lado servidor.

La construcción de interfaces graficas simples implican mayor esfuerzo a si se usaran lenguajes de marcado.

El uso de GWT-RPC facilita el intercambio de datos con el servidor siempre y cuando se use alguna tecnología Java en este.

El uso de llamadas asíncronas para la comunicación con el servidor afecta la forma en que se manipulan algunos datos.

Existen herramientas gráficas que facilitan el diseño de interfaces de usuario con esta tecnología

El hecho de que el resultado de compilar una aplicación GWT sea código JavaScript, aumenta el riesgo de ataques XSS [2] y dificulta la indexación y el rastreo de la aplicación por los motores de búsqueda [20].

Al compilar una aplicación GWT se obtiene como resultado archivos JavaScript que son ejecutados por cualquier navegador web con soporte JavaScript sin necesidad de plugins.

TABLA II. VENTAJAS Y DESVENTAJAS FRAMEWORK APP-ENGINE

AppEngine-Java Ventajas Desventajas

Permite que la aplicación haga uso de la infraestructura de

Restricciones en el tipo de relaciones del modelo de

DAVID YANQUÉN CORREA AND ANTONIO BALLESTEROS RICAURTE : WEB APPLICATION 375

Google. dominio.

Facilita la creación del modelo de datos a partir de POJOs por medio de las especificaciones JPA y JDO.

A pesar de usar JPA y JDO, no implementa todas las funcionalidades definidas en estos.

Ofrece gran rendimiento para la ejecución de la aplicación.

Restringe el uso de algunas clases incluidas en la JVM

Ofrece mecanismos que facilitan el uso de los servicios como Memcache, mail, XMPP, autentificación mediante cuentas de Google, entre otras [17].

No permite la búsqueda avanzada de texto directamente. Para ello es necesario realizar algunas adaptaciones al modelo aplicando técnicas para FTS (Full Text Search) por medio del uso de librerías como Lucene [12].

Brinda herramientas que facilitan la subida de la aplicación a la infraestructura de Google.

VI. CONCLUSIONES El uso de patrones de diseño, en este caso en la

construcción de la interfaz gráfica, ayudan en la obtención de un software de calidad, extensible y reutilizable, a la vez de solucionar los problemas para los que fueron diseñados. Sin embargo, aumenta la complejidad durante el desarrollo de software y, en ocasiones, requiere un gran número de procesos para realizar tareas simples, algo que influye en el rendimiento de la aplicación.

Respecto al uso de App Engine-Java en el desarrollo de aplicaciones Web, es necesario tener en cuenta que el hecho que sea una tecnología con bastantes restricciones, implica un mayor esfuerzo a la hora de introducir funcionalidades no ofrecidas por el framework y a la vez, condiciona el diseño modelo de dominio de una aplicación para su persistencia.

Debido a la naturaleza en la forma en que funcionan las tecnologías GWT y App Engine y a las restricciones que tienen, su integración con otros frameworks para Java, como por ejemplo Spring, es algo complejo y no se pueden aprovechar todos las beneficios ofrecidos por estos.

REFERENCIAS [1] DEWSBURY, Ryan. Server Integration Techniques. En: Google

Web Toolkit Applications. Massachusetts: Pearson Education, 2008. p. 117 - 124.

[2] DWYER, Jeff. Security and Authorization. En: Pro Web 2.0 Application Development with GWT: Apress, 2008. p. 313 - 316.

[3] FOWLER, Martin. GUI Architectures. [Sitio web]. Accedido desde: <http://martinfowler.com/eaaDev/uiArchs.html>. [con acceso el 20 de Noviembre de 2010].

[4] FREEMAN, Eric, FREEMAN, Elisabeth, BATES, Bert, et al. Patterns of Patterns. En: Head First Design Patterns: O'Reilly, 2004. p. 532.

[5] Google. Google App Engine - Relationships. [Sitio Web]. Accedido desde: <http://code.google.com/intl/es/appengine/docs/java/datastore/relationships.html>. [con acceso el 11 de Febrero de 2011].

[6] GUERMEUR, Daniel y UNRUH, Amy. Persisting Data: The App Engine Datastore. En: Google App Engine Java and GWT Application Development. Birmingham: Packt Publishing, 2010. p. 91 - 101.

[7] GUPTA, Vipul. GWT Architecture and Internal Features. En: Accelerated GWT Building Enterprise Google Web Toolkit Applications: Apress, 2008. p. 27 - 31.

[8] GUPTA, Vipul. UI Programming: Handling events and using advanced widgets. En: Accelerated GWT Building Enterprise Google Web Toolkit Applications: Apress, 2008. p. 110 - 114.

[9] KEREKI, Federico. Programming the User Interface. En: Essential GWT Building for the Web with Google Web Toolkit 2. Crawfordsville: Pearson Education, 2010. p. 57 - 61.

[10] KEREKI, Federico. Working with Servers. En: Essential GWT Building for the Web with Google Web Toolkit 2. Crawfordsville: Pearson Education, 2010. p. 184.

[11] LOPEZ, Fabián y BALLESTEROS, Javier. Comparación de herramientas para el desarrollo de librerías enfocadas a aplicaciones web. En: Revista Virtual Universidad Católica del Norte, No. 34, 2011. p. 342-359.

[12] MAZUKNA, Tomas. Google App Engine – Full Text Search with JDO. [Sitio web]. Accedido desde: <http://www.wetfeetblog.com/google-app-engine-full-text-search-with-jdo-revisited/368>. [con acceso el 9 de Marzo de 2011].

[13] MSDN Library. Patterns for Web Client Applications Model-View-Presenter. [Sitio web]. Accedido desde: <http://msdn.microsoft.com/en-us/library/ff649820.aspx>. [con acceso el 20 de Noviembre de 2010].

[14] Oracle. Java Data Objects (JDO) - Overview. [Sitio web]. Accedido desde: <http://www.oracle.com/technetwork/java/index-jsp-135919.html>. [con acceso el 11 de Febrero de 2011].

[15] RAMSDALE, Chris. Large scale application development and MVP. [Sitio web]. Accedido desde: <http://code.google.com/intl/es-ES/webtoolkit/articles/mvp-architecture.html>. [con acceso el 20 de Noviembre de 2010].

[16] ROCHE, Kyle y DOUGLAS, Jeff. Cloud Computing and App Engine. En: Beginning Google App Engine for Java: Apress, 2009. p. 1 - 3.

[17] ROCHE, Kyle y DOUGLAS, Jeff. Introduction to App Engine. En: Beginning Google App Engine for Java: Apress, 2009. p. 7 - 8.

[18] RODRIGUEZ, Nelson, VILLAFAÑE, Daniela, MURAZZO, María et al. GAE, una estrategía para completar SaaS y PaaS a través de la web. Accedido desde: |<http://sites.setrem.com.br/stin/2012/anais/Nelson.pdf>. [con acceso el 20 de abril de 2013]

[19] SMEETS, Bram, BONESS, Uri y BANKRAS, Roald. Building an Advanced UI. En: Beginning Google Web Toolkit: From Novice to Professional: Apress, 2008. p. 89 -101.

[20] SMEETS, Bram, BONESS, Uri y BANKRAS, Roald. Introducing Google Web Toolkit. En: Beginning Google Web Toolkit: From Novice to Professional: Apress, 2008. p. 21 - 25.

[21] SMEETS, Bram, BONESS, Uri y BANKRAS, Roald. Server Integration. En: Beginning Google Web Toolkit: From Novice to Professional: Apress, 2008. p. 141-149.

376 IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 2, MARCH 2014

[22] http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

Jesús David Yanquén Correa recibió el título de Ingeniero de Sistemas y Computación de la Universidad Pedagógica y Tecnológica de Colombia, Estudiante de Maestría en Ingeniería de Sistemas, Universidad Nacional de Colombia.

Javier Antonio Ballesteros Ricaurte Ingeniero de Sistemas de la Universidad de Boyacá, Magíster en Ciencias Computacionales de la Universidad Autónoma de Bucaramanga y el Instituto Tecnológico de Estudios Superiores de Monterrey, Docente Asistente Escuela de Ingeniería de Sistemas y Computación, Investigador Grupo GIS de la Universidad Pedagógica y Tecnológica

de Colombia Tunja, Colombia.

DAVID YANQUÉN CORREA AND ANTONIO BALLESTEROS RICAURTE : WEB APPLICATION 377