[ASPL Fact devel] Seguridad en comunicaciones.

Jesús Martínez jamarcer at inicia.es
Tue Jan 28 19:23:40 CET 2003


Hola:

Resumo un poco el correo ;).

De acuerdo con la "filosofía" de que cada servidor controle sus datos.

De acuerdo con que sea la aplicación la que gestione la integridad de
los datos, a través de los servidores. 

> El problema que le veo es que realizar algo que supiera manejar
> TODA la base de datos la haría realmente difícil de mantener. Quizá
> fuese una buena idea que las labores que indicas fuesen
> realizadas, dentro de cada servidor, por módulos diferenciados, de modo que al
> cambiar las tablas de la base de datos, sólo fuese necesario la
> modificación de unos ficheros .h o .c concretos.

Manejar TODA la base de datos es excesivo. Pero lo que a mí me preocupa
no son los servicios (querys) de consulta, son los servicios que
implican actuar en la BBDD (altas, modificaciones, bajas). Y no tanto
las que involucran un sólo servidor.

Por lo que he entendido, desde el cliente se van a realizar llamadas
asíncronas a los servidores. Supongamos un proceso que implica el alta
en tres servidores: el primer servidor realiza su alta y ok. Entonces el
segundo servidor intenta la suya y también ok. Pero el tercero, por el
motivo que sea falla (desde un error en la BBDD a un error en la
conexión tras el alta correcta). Si no tenemos un tratamiento
transaccional, implica que para cada servicio (alta, modificación, baja)
debemos tener uno que restaure los datos. ¿no es un poco complejo de
mantener? 
Creo que el ejemplo del error en la transmisión es más claro. Si en el
último alta la aplicación no recibe el ok (y todo a ido bien), se tiene
una inconsistencia que no existe. Y si se deshace ¿hasta dónde?. Si
establecemos una transacción (con un sistema que si en un tiempo dado no
recibe la orden de commit realize un rollback) ese tipo de problemas es
más manejable.

Pero esto es el típico diálogo que ocurre cuando se habla de BBDDs, ;).

> En resumen: 
> 
> * Poner una librería común de acceso a datos parece ser una buena idea,
>   ya que posibilitaría la realización de transacciones. Pero aún no  
>   deberíamos preocuparnos por ello: soluciones hay muchas, y los cambios
>   que habría que realizar no serían preocupantes.

Mi problema es que no se exactamente dónde ayudaros, y puede que levante
perdices dónde no es necesario.
 
> * Aparte de la realización de transacciones, suponiendo que todas las  
>   abstracciones se realizaran a nivel de cada uno de los servidores, no
>   le veo mayor sentido a esa librería auxiliar libafdal-gda, ya que
>   parece que libgda ya está suficientemente "masticado". De todos
>   modos, si crees que no es así, haznos una propuesta de posible API para
>   concretar un poco más.

No sé si la idea de la librería es la más correcta. En el fondo, tengo
malas experiencias con las querys incrustadas en el código. Son
endiabladas de mantener. Si las sentencias SQL están en esa librería y
somos capaces de abstraerlas para el resto de la aplicación, el
mantenimiento SQL se centraliza.
Si af_tax_list() llama a libafdal-gda_consultar(parametros), y en
libafdal-gda_consultar(parametros) está la resolución de "SELECT * FROM
aspl_tax_list WHERE parametros", si se cambia algo de la BBDD sólo se
toca en un punto.
Y e acuerdo con que este mantenimiento puede estar distribuido en cada
servidor. Es la misma solución implementada de otra forma ;).
 
> * La idea de la organización de la base de datos es que, si se modifica
>   alguna tabla de la misma, sólo haya que cambiar el servidor asociado
>   y la librería libafdal asociada a ese módulo (a ser posible,
>   manteniendo la interfaz y simplemente recompilando). El acceso de
>   otros servidores a información controlada por ese servidor se haría,
>   en principio (mientras no se vea, a través de llamadas al servidor
>   (comportándose como clientes del servidor dueño de los datos) y no a
>   través de querys SQL. De este modo se busca una amplia mantenibilidad
>   (quizá a costa de rendimiento).

Esa es la idea que pretendía explicar, pero en vez de hablar entre
servidores, yo me refiero a servidor gda. No tengo muy claro si GDA es
independiente de los SGBD a nivel de query (las sentencias SQL son muy
parecidas, pero ciertos gestores tienen sus particularidades). Me estoy
leyendo la documentación de gda, pero no me queda claro [Pregunta para
Rodrigo Moya ;)] 

Espero haber presentado con más claridad mis inquietudes en este tema.
Son difíciles de explicar :(.

Y si de un diálogo como este aparece una posible buena idea, yo me doy
por satisfecho ;)).

Un saludo
Jesús Martínez





More information about the ASPL-Fact-devel mailing list