MoisesDaniel's Bloc

SigWeb 2.0: AJAX + OpenToro

Artículo que escribimos el equipo de desarrollo Portales-SIGs de Dap para un congreso sobre SIG y herramientas abiertas:

RESUMEN

En esta comunicación se describe el desarrollo de un nuevo visor SIG para la web, integrándole AJAX y el componente libre de publicación web OpenToro.

Palabras clave: SIG, visores web, AJAX , OpenToro, publicación web.

Aquí está la comunicación: SigWeb 2.0: AJAX + OpenToro

Reflections Opentoro: Objects, Databases, and the OpenToro's Philosophy'.

(Previously published in http://opentoro.sourceforge.net/reflections.html )

In these days, there has been a notable discussion about ORM, RDBMS and ODBMS, with interesting contributions like Ted Neward’s ‘The Vietnam of Computer Science’ and ‘Avoiding the Quagmire’, Gabin’s reply  ‘In defense of the RDBMS’, and the interesting discussions in the TheServerSide.net (and this) and InfoQ forums.

The next OpenToro version (the 5.0) has an interesting new feature: java objects, like previously database tables, can be easily published in the web. So we have wanted to make a reflection about these questions too.

 

Introduction.

OpenToro is a Web Database Publisher, a tool that allows us developing database-driven web applications (with advanced AJAX technology) in an agile and automatic way. Using OpenToro simply means to forget coding countless SQLs and JSPs every time we want to implement a web application with database access.

When we say ‘publishing’ a database in the web, we want to say generating a web interface that let people listing database tables, visualizing records, and generating forms for inserting, modifying and deleting records.

 

An OpenToro application is just a way to perform manipulations on the data in a relational database in a direct way (through the web).

 

You can see OpenToro too like a framework for rapid development of web applications.

 

OpenToro is not a panacea, and is not suitable for all application scenarios.

Usually you are going to use OpenToro in the Views of an application, using its easy tag lib and its XML files.

OpenToro and java Objects.

Like we have said, OpenToro next release (5.0 version, planned for November 2007) has an interesting new feature: java objects, like previously database tables, can be easily published in the web.

Until now OpenToro have not supported a very object oriented programming style for web applications, supporting more a declarative programming style (OpenToro is a complex metadata-reflective architecture piece of software). The reason is very simple: if you want to publish in the web some database tables, and made some CRUD operations (Create, Read, Update and Delete), why do you need to build a complex application?

It has nonsense using an ORM, a lot of classes for the data model, and a big architecture for doing so simple things. An excerpt from Martin Fowler:  

Costs of a domain model: The primary cost is the awkwardness of mapping to a database, which typically results in a whole layer of O/R mapping. This is worthwhile if you use the powerful OO techniques to organize complex logic.

 

But there are a lot of problems that are naturally developed using a full object oriented data model. LikeMartin Fowler says:

 

At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behaviour, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual.

 

OpenToro wants to do the next step, supporting other data container, like java objects, for web publication.

 

Our Philosophy.

In these days, there has been a notable discussion about ORM, RDBMS, and ODBMS.

Our philosophy is the next: keep the things simple.

 

We have identified al least 3 development scenarios:

• You don’t have complex logic; rather, you almost don’t have any business logic. Solution: Don’t use any ORM, don’t build a domain model, perform manipulations on the data (in a relational database, of course) in a direct way. This is very simple using XML files for declarative specification of database tables. OpenToro will do the rest for you. Application example: a web site that contains news, events, and some documentation.
• You have some business logic. The recommendation is simple, you must to develop a small domain model, only with the entities that have logic, the rest can be in the database. OpenToro 5.0 implements mechanisms that let your classes to reference database records (as if they were objects too). Still you don’t need an ORM, OpenToro has a set of utilities that let you ‘move’ data between classes and records.
• You have complex logic. Ok, let’s open way to the heavy artillery. Anyhow we recommend using OpenToro 5.0 for publishing objects’ data in the web.

Plataformas Software

En estas últimas semanas he estado reflexionando e investigando un poco sobre las plataformas software.

Aquí va un apunte interesante: una definición y sus ventajas.

Definición de Plataforma:

Una plataforma software es un conjunto de artefactos (componentes o subsistemas) que forman una estructura común a partir de la cual podemos derivar (desarrollar, construir) sistemas de una forma eficiente.

Los sistemas derivados de una plataforma no sólo comparten código, sino requisitos y arquitectura. Se da por tanto un proceso de reutilización natural de los artefactos de la plataforma en los diferentes sistemas.

Ventajas de una plataforma software:

• Reducción del coste de operación. Uno de los parámetros fundamentales en la ingeniería y en la estrategia empresarial es la justificación económica. Una plataforma software nos permitirá reducir el coste de operar en el campo del desarrollo del software, ya que nos permitirá reducir costes tanto a nivel de desarrollo, como de mantenimiento. El elemento esencial aquí es el de reutilización de los artefactos que componen la plataforma.
• Mejora de la calidad. Al ser usados los artefactos de la plataforma en muchos sistemas, éstos son revisados y testeados de forma intensiva, por lo que es más fácil hacer que dichos artefactos tengan un número muy reducido de errores, buen rendimiento, etc.
• Reducción del tiempo de desarrollo. Tener la capacidad de poder desarrollar proyectos en menos tiempo no tiene sólo un impacto económico directo en el coste individual de los proyectos, sino que tiene varios indirectos: al hacernos más competitivos podemos optar a realizar más proyectos y a ser por tanto más productivos. Para esto es fundamental una plataforma estable y adaptada a la problemática a la que se quiere aplicar.
• Gestión centralizada de la evolución. La introducción de un nuevo artefacto en la plataforma da la posibilidad de que todos los sistemas derivados de la plataforma usen ese nuevo artefacto. Esta gestión centralizada permite a los sistemas evolucionar de forma ordenada.
• Reducción de la complejidad global. El hecho de usar una plataforma bien definida con una serie de artefactos reconocibles y conocidos reduce la complejidad significativamente tanto a nivel de desarrollo, como de gestión del desarrollo, mantenimiento, etc.
• Mejoras en las estimaciones de costes. Calcular costes para sistemas derivados de la plataforma es más sencillo y tiene menos riesgo porque se tienen ya resultados de otros sistemas derivados de la plataforma y que por tanto pueden ser comparables.
• Interfaz común. Todos los sistemas derivados de la plataforma tendrán en común bastantes elementos en cuanto a su funcionamiento e interfaz, lo que hace que los usuarios aprendan rápido y se sientan cómodos ante nuevos sistemas derivados de la misma plataforma.
• Estandarización del conocimiento técnico. El conocimiento de los técnicos de la organización se estandariza al estar todos los sistemas (o casi todos) basados en la plataforma y sus artefactos. Esto hace fácil que los técnicos puedan comprender y por lo tanto desarrollar y mantener el conjunto de sistemas generados por la organización, facilitando a su vez la movilidad del personal entre los diferentes proyectos atendiendo a las necesidades corporativas.

También tienen una clara desventaja (entre otras): Inversión en el desarrollo y mantenimiento de la plataforma. Se supone que una vez construida una plataforma la inversión realizada se recupera al utilizarla en 3-5 proyectos.