Page 46 - Ingeniantes 421 interactivo
P. 46
Revista Ingeniantes 2017 Año 4 No. 2 Vol. 1
procedimientos almacenados de la base de datos a la Se programó la clase “Proceso.php” con la finalidad
cual hayan sido asociados en donde el resultado sea un de que sea extendida para crear clases que definan
valor, un registro o un conjunto de registros y son capa- el comportamiento de objetos cuyas funciones serán
ces de contener el dataset resultante de una consulta trabajar como un listener de las peticiones POST que
SQL en un array dinámico de objetos de tipo Registro. llegan al servidor y árbitro de acceso a las bases de
BD.php: Esta clase es una extensión de la librería PDO datos. Las extensiones de esta clase, verifican que la
[6] de PHP 7.0 que consigue conectar de forma trans- solicitud sea una operación reconocida, que la naturale-
parente a diversos gestores de bases de datos. Es ca- za de los datos de solicitud sea la esperada y si todo es
paz de contener un array de objetos Tablas o resulta- correcto, es él, y no el cliente, quien accede al cluster
dos de consultas que pueden ser cargadas de inicio para entregar los resultados de la consulta solicitada.
para poderlas enviar al cliente como un paquete de Si la solicitud no es reconocida, el listener asumirá una
datos de tipo JSON. Puede ejecutar las operaciones amenaza de ataque y devolverá un mensaje de error
SELECT, INSERT, UPDATE Y DELETE de un registro ó que quizás terminaría ocasionando un mal funciona-
una o más tablas. miento en el cliente. Cada cliente que se comunique
Gestión de la concurrencia. con el server debe hacerlo mediante una petición asín-
En un gran sistema, como es el caso del SITM, la ges- crona de tipo AJAX [7] y enviar/recibir datos en forma-
tión de la concurrencia a las bases de datos es un fac- to JSON. La interacción del listener con el cluster de
tor determinante para su correcto funcionamiento. En bases de datos y los clientes queda representada en
el SITM la gestión de la concurrencia se lleva a cabo la Figura 1.
mediante la técnica o patrón conocida como single-
ton, la cual nos permite gestionar las conexiones para Figura. 1. Interacción del BackEnd y el FronEnd.
hacer posible que exista una y solo una conexión por
cliente, independientemente del número de solicitudes Diseño del FrontEnd
que éste realice. Las clases descendientes de la clase Se tomó como punto de partida el patrón de arquitec-
BD del proyecto quedan habilitadas para implementar tura: Modelo Vista Controlador y se adaptó un motor
un Singleton y así evitar la sobrecarga de conexiones de comunicaciones asíncronas propio basado en Ajax.
que podría ocasionar una solicitud masiva de peticiones (Véase Anexo 1) muestra el esquema aplicado.
de un cliente. Por defecto, el constructor de la clase Vista: Los clientes fueron creados bajo los principios
conecta con un gestor MySQL y a petición se puede de la web adaptativa establecidos por Ethan Marcotte
realizar la conexión a otros gestores como son MSSQL, en 2009 [8]. Marcotte indica que existen tres elemen-
Oracle, PostgreSQL, SQLite, etc., de forma transparen- tos fundamentales para lograr un diseño web adaptati-
te. Las siguientes líneas muestran el singleton creado vo, que son: cuadrícula fluida, imágenes flexibles y me-
para conectar con un gestor de base de datos MSSQL dia queries. Gran parte de la solución la proporciona un
ubicado en un segundo servidor. Todos los singleton buen manejo de CSS3 Flexbox y una parte la progra-
pertenecen a clases derivadas de la clase BD.php mación en Javascript para adaptar la interfaz de usuario
// Singleton para el manejo de la conexión a a las resoluciones de pantalla que tienen los diferentes
MSSQL dispositivos.
private static $BD; Representación de la información orientada a ob-
public static function BD(){ jetos.
if (!isset(self::$BD)) Dado el número de veces que se ocupa la terna cam-
self::$BD = new BD(“E00758\SMISANTLA”, “gas”, po, registro, tabla, se programaron las tres clases si-
“user”, “clave”, “MSSQL”);
return self::$BD;
}
Gestión del cluster de base de datos heterogéneas y
comunicación con los clientes.
Se tomó la decisión de crear un cluster de base de
datos y no una mega base de datos para simplificar
su gestión, mantenimiento y primordialmente mantener
la capacidad de interactuar con otros sistemas sin la
necesidad de llevar a cabo una migración de datos o
adecuar las consultas a cada gestor, simplemente so-
licitando la ejecución de procedimientos almacenados
alojados en cada instancia, favoreciendo colateralmen-
te un acceso seguro a los datos.
42
