2.1. Módulos de la aplicación

El usuario es guiado a través de la interfaz gráfica de la aplicación por los diferentes módulos que entran en juego para desarrollar el proyecto estructural. Estos son enumerados a continuación.

1. Modelador 3D.
2. Aplicación para análisis estructural.
3. Aplicación de diseño estructural.
4. Módulo de CAD. Generador de la documentación gráfica.

El cliente, a través del menú de la aplicación, tiene la posibilidad bien de crear un nuevo proyecto, en donde será guiado por los diferentes módulos, o bien modificar uno en curso. La interacción del usuario con las diversas partes de la aplicación hasta del desarrollo DXF final se ofrece de una manera lineal, pero pudiendo también intervenir diferentes agentes en el mismo proyecto; mediante la asignación de privilegios por parte del administrador o compartiendo el proyecto a otros socios; gracias al alojamiento de todo el proyecto en la nube.

El primer módulo, el modelador 3D, está centrado en definir gráficamente la estructura conforme a la definición del proyecto. Aquí el usuario, a través de la correspondiente aplicación web cliente, dispone de un entorno gráfico 3D donde modelar gráficamente, mediante las herramientas proporcionadas, el esqueleto del sistema estructural. La poca exigencia gráfica de este proceso y el soporte de WebGL de los navegadores actuales, permitiendo el acceso al procesador gráfico por parte de la aplicación web; nos permite la ejecución de esta aplicación sobre el navegador del usuario, soportando este una pequeña carga de trabajo gráfico exclusivamente, tal y como muestran Gracia y Bayo (2). De esta forma, eliminamos costes adicionales del servicio así como la pequeña latencia visual que podría generarse.

Una vez realizado el trabajo en este primer módulo, los datos de la definición de la estructura quedan almacenados en el fichero del proyecto, definiendo ya un esqueleto de la tipología del mismo.

El módulo para el análisis estructural es el encargado de realizar un análisis conforme a la elección del cliente, obteniendo un dimensionado y análisis de la estructura, y realizándose todo el trabajo computacional en el entorno cloud computing. Es en el módulo de diseño estructural donde, con los datos del cálculo de la estructura, se definen las uniones y otros elementos restantes conforme a la normativa vigente.

El usuario tiene la posibilidad de modificar cualquier parámetro del proyecto en cualquier momento, aunque esto conllevará el recalculado de todas las demás partes, teniendo que revisar los usuarios oportunos esta actualización.

Por último, después de la intervención de las fases anteriores, el proyecto es procesado por el módulo CAD; este genera la documentación gráfica detallada del sistema estructural completo. Esta información es generada como fichero DXF que el usuario podrá descargar y utilizar con programas CAD de escritorio, y utilizarlo para la puesta en obra del proyecto.

2.2. Arquitectura REST y la API

El desarrollo del servicio web que nos ocupa, se implementa mediante una arquitectura tipo REST, creando una API que es consumida por JavaScript y por aplicaciones web programadas bajo PHP. Se usa por lo tanto el protocolo HTTP (Hypertext Transfer Protocol) como método de comunicación y JSON (JavaScript Object Notation) o XML (Extensible Markup Language) para el intercambio de datos.

REST es una técnica o familia de arquitecturas software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP, como explican Richardson y Ruby (3).

REST implica que una URL es la representación de un objeto o recurso, cuyos contenidos son accesibles mediante HTTP (Figura 2) (3), (4). Los clientes trabajan con estos recursos a través de las operaciones estándar («verbos») de HTTP, como GET, POST, PUT y DELETE para descargar o modificar una copia de la representación del recurso. La alternativa más conocida, SOAP (Simple Object Access Protocol), es un protocolo estándar que utiliza una capa adicional por debajo de HTTP para la transmisión de información. Las arquitecturas que siguen los principios de REST son denominadas ‘RESTful’.

Figura 2.  Conversación REST.

El uso de REST frente a SOAP nos proporciona una mayor escalabilidad del servicio (5). Al tratarse de un protocolo cliente - servidor sin estado cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes.

Además, REST proporciona una arquitectura mucho más fácil, así como peticiones más simplificadas, permitiendo todo ello un mayor rendimiento y velocidad; y permite interpretar las URIs (Uniform Resource Identifier) de manera visual. Por contra, la información es transferida de forma no optimizada según la aplicación y hacen falta múltiples llamadas para conseguir información compleja.

Un tipo de arquitectura SOAP es aconsejable cuando se describen en la comunicación todas las funciones de la interfaz o cuando es necesario abordar requerimientos complejos no funcionales. Por el contrario, la arquitectura basada en REST es útil cuando el servicio web no necesita tener estado, cuando se busca rendimiento o cuando tanto el cliente como el servidor conocen el contenido a intercambiar.

Las llamadas a recursos se hacen por medio de URIs, debiendo introducir en cada llamada la petición completa sin poder tener un estado previo como en SOAP, pero haciendo el sistema más flexible y eficaz, así como poder orientar el servicio mediante el uso de APIs a todo tipo de dispositivos fácilmente.

Como se ha indicado antes, el servicio consta de una API desarrollada mediante REST. Esta API permite el acceso, mediante las funciones implementadas en ella, a aplicaciones de escritorio y móviles; o la utilización de características del servicio a aplicaciones de terceros.

Una API es un grupo de funciones que permiten que desarrolladores puedan acceder al servicio mediante sus propias aplicaciones, de forma que pueden comunicarse con la base de datos sin necesidad de disponer del código fuente de nuestro sitio. El ejemplo más claro es Twitter que con su API se han creado multitud de sitios en Internet que, disponiendo de los datos de los usuarios de Twitter, pueden crear multitud de aplicaciones para ayudar o añadir valor al servicio.

Una API puede disponer o no de dos grandes funcionalidades:

1. Recoger y disponer de los datos del sitio para mostrarlos de forma conveniente.
2. Alterar esos datos, cómo modificarlos, añadir nuevos datos o eliminarlos.

Para la comunicación interna de la aplicación, como para el formato de almacenaje de los datos del proyecto del usuario (archivo de proyecto) se usa JSON. Esto nos permite una buena eficiencia en entornos donde se utilice AJAX (Asynchronous JavaScript And XML), como demuestra Wang (6). JSON es un formato ligero para el intercambio de datos, generalizado como alternativa a XML en AJAX gracias a su simplicidad. JSON es una parte de la definición del estándar ECMA-262 en que se basa JavaScript. Se utiliza generalmente en entornos donde el tamaño del flujo de datos entre cliente - servidor es de vital importancia y cuando la fuente de los datos es de fiar.

La fácil escritura de un parser JSON y la posibilidad de análisis mediante la función eval() en JavaScript ha contribuido a su expansión actual. Conviene mencionar la falta de seguridad que plantea el uso de la función eval(), aunque no requerida para el intercambio de datos o funciones al usando la definición correcta de Literal JavaScript (LSJ).

Así, destacamos algunas ventajas de JSON sobre XML, como su facilidad de interpretación y creación en entornos como PHP, donde existen funciones nativas para crear objetos JSON; el menor consumo de ancho de banda en la comunicación de datos al evitar partes de estructura propias del lenguaje como tabulaciones y etiquetas del XML; y su soporte nativo por parte de JavaScript pudiendo acceder a los datos fácilmente mediante el operador “.” (objeto.propiedad), facilitando la extracción de contenido frente a XML.

3.1. Distribución del SaaS en AWS

Para la integración del servicio web comentado a lo largo de este artículo en Amazon Web Services, se necesita el uso de varias instancias reservadas EC2, así como varios de los servicios mencionados. Estas instancias, para una mayor facilidad de gestión, llevarán Ubuntu como sistema operativo. Las instancias serán generadas teniendo en cuenta el servicio que van a correr, con una mejor capacidad gráfica para el módulo CAD, o mejor capacidad de computación en el caso del módulo de análisis. Para el servicio de bases de datos no usaremos Amazon SimpleDB, en vez de este utilizaremos una instancia EC2 ejecutando MySQL como servidor de bases de datos.

Se detalla a continuación un esquema de distribución del servicio en caso de alta demanda por gran cantidad de clientes simultáneos (Figura 3).

Figura 3. Esquema de distribución en AWS.

Para la distribución del módulo de CAD del servicio web, dedicaremos varias instancias EC2 ejecutando el código desarrollado. Estas instancias estarán controladas por otra de rendimiento reducido (instancia de control), encargadas de modificar dinámicamente las anteriores en función de la demanda, tanto aumentando sus características, como creando nuevas instancias.

Al disponer de distintas instancias ejecutando el módulo de CAD, debemos situar MySQL en otra independiente para el acceso a la base de datos a través del dominio interno ofrecido por Amazon para esta. En caso de tener una sola instancia EC2 podríamos instalar MySQL, si nos conviniese, en esta para acceder localmente a través de la IP 127.0.0.1, dejando la base de datos cerrada a conexiones exteriores para mayor seguridad.

La aplicación principal correrá en otra EC2 independiente, usando Amazon S3 como almacenamiento de los ficheros de proyecto de cada usuario. Cuando sea necesario generar la solución final de un proyecto, se creará un mensaje en una cola de Amazon SQS con una referencia al fichero de proyecto en Amazon S3. El software de la instancia EC2 disponible leerá la solicitud de la cola y recuperará el proyecto de Amazon S3 para su procesado. Después de esto lo colocará de nuevo en S3 creando otro mensaje en la cola de Amazon SQS indicando la finalización.

La instancia de control supervisará constantemente la cola de trabajo, y en función del número de mensajes de la misma, ajustará de forma dinámica el número de instancias de Amazon EC2 dedicadas al módulo CAD necesarias para cumplir con los requisitos de tiempo de respuesta de los clientes.

4.1. Implementación del módulo de CAD

Para un mejor seguimiento con la aplicación desarrollada, se procede a explicar la misma distinguiendo los 4 pasos que muestra visualmente durante el proceso, hasta la generación de la documentación final en DXF.

Recordemos que la programación de esta aplicación se basa fundamentalmente en PHP, por lo que el documento generado por estas rutinas contiene elementos HTML así como links en la cabecera del documento a dos ficheros externos: una hoja de estilo CSS y un documento con JavaScript.

Para las peticiones cliente/servidor, se usa el método POST haciendo uso de un submit y enlazando el action del form con un documento PHP. Para no crear diferentes páginas PHP, una por cada paso descrito, se enlaza con el mismo documento recursivamente. Para que este muestre la sección correcta, PHP lee un campo oculto en el formulario que indica el paso actual.

1. $Paso=$_REQUEST[“Form0_1”];

En cualquier momento de la ejecución podemos volver al inicio de la aplicación presionando el botón superior ‘Reiniciar’.

Envío del fichero paramétrico:

En la primera sección de la aplicación, se pide al usuario mediante un input de tipo file, que seleccione el fichero con los parámetros del dibujo a crear.

Lectura del fichero:

En esta fase, la rutina de PHP lee e interpreta el archivo enviado. Para ello creamos un manejador que referenciará al archivo para trabajar con él:

1. $hadle=fopen($_FILES[‘Form1_1’][‘tmp_name’], “r”);

A medida que el fichero es interpretado por el servidor, los datos se van guardando en diversas variables que podrán ser modificadas posteriormente por el usuario mediante un formulario (Figura 5).

Figura 5. Prototipo de la aplicación de CAD.

Cuando se haga clic en el botón ‘Continuar’, se enviarán también todos los valores de los formularios, tanto si han sido modificados como si no.

Generación archivo DXF:

Una vez recuperados todos los valores finales, generamos una cadena de texto $command que contiene todos los parámetros que pasaremos al ejecutable externo de la forma siguiente:

1. exec($command, $output, $return_var);

Mediante las variables $output y $return_var obtenemos la información que ofrece el ejecutable C++, que mostraremos al cliente en un campo ‘textarea’.

Descarga documento:

Por último se permite al usuario la opción de descargar el fichero DXF generado. Para ello, se ha optado por relacionar el submit de un formulario directamente con el fichero. De esta forma no es necesario crear un enlace y la aplicación conserva la misma estética de los apartados anteriores:

1. <form method=”post”
   action=”portico.dxf”
   enctype=”multipart/form-data”>

Otra forma de realizar el proceso, más correcta en cuanto a la gestión de tráfico de datos en la red, hubiese sido crear un enlace como el siguiente:

1. <a href=”CaVaAC_4.php”>Descargar</a>

Y posteriormente controlar la descarga mediante PHP, generando una cabecera al siguiente documento HTML.

1. $filename=’portico.dxf’;
2. $fp=fopen($filename, ‘r’);
3. $output=fread($fp, filesize($filename));
4. fclose($fp);
5. header(“Content-type: application/autocad-dxf”);
6. header(“Content-Disposition; attachment; filename=Filename.dxf”);
7. echo $output;
8. exit();

4.2. Implementación del prototipo de la aplicación principal

Por último, se expone brevemente la implementación de la aplicación principal que permite el acceso a todos los módulos de la aplicación. Esta aplicación se presenta al usuario por medio de un entorno de trabajo con diversos iconos. El cliente accede por medio de un registro con su cuenta personal y el servidor le proporciona el acceso a los módulos para los que esté registrado. Este entorno, permite el registro simultáneo de diferentes usuarios, cada uno con sus permisos, sin interferir en los demás.

Este programa también está desarrollado en PHP introduciendo el uso de sesiones. Las sesiones nos permiten guardar el registro de un mismo usuario durante la duración de su visita a la aplicación, independientemente de que abra otra página en su navegador y posteriormente regrese. Esto proporciona una mejor experiencia de usuario al cliente y nos permite mantener su sesión abierta mientras no cierre su navegador o finalice la sesión en el programa.

Si observamos la aplicación relacionada con el módulo de CAD (Figura 6), veremos que sobre un div se muestra totalmente funcional dicha aplicación, sin necesidad de recargar la página ‘padre’ para interactuar con ella. Esto se ha conseguido mediante la incrustación de un ‘marco’ posicionado en otro div. Mediante la etiqueta <iframe> insertamos el contenido de otro documento HTML sin necesidad de usar frameset. Esta porción de la página web toma el control y se ejecuta como si fuese suya la página.

Figura 6. Prototipo de la aplicación de CAD sobre el menú del servicio.