Arquitectura de 4D Server

Con su arquitectura cliente/servidor, 4D Server no sólo guarda y administra la base, también ofrece servicios a los clientes. Estos servicios funcionan a través de una red por intermedio de un sistema de peticiones y de respuestas.

Para buscar un conjunto de registros, por ejemplo, un equipo cliente envía una petición al servidor. Una vez recibida la petición, el servidor ejecuta la búsqueda en local, es decir en el equipo servidor, y cuando termina devuelve el resultado (registros encontrados).

La arquitectura de 4D Server está basada en el modelo cliente/servidor. Por muchos años, la arquitectura cliente/servidor se ha impuesto, convirtiéndose en el modelo más eficiente en bases de datos multiusuarios.

El tipo de arquitectura cliente/servidor de 4D Server es similar al utilizado en el mundo de los minicomputadores. Sin embargo, 4D Server ofrece dos innovaciones importantes:

• Una interfaz intuitiva y gráfica, presente en todos los niveles de la base
• Una arquitectura integrada que ofrece más eficiencia y velocidad

Antes de la aparición de la arquitectura cliente/servidor, los sistemas multiusuario utilizaban el compartimiento de archivos como modelo de arquitectura de red. En este modelo, todos los usuarios comparten los mismos datos, pero la gestión de datos no es controlada por un motor de base de datos central. Cada equipo cliente debe guardar una copia de la estructura y del motor de la base, mientras el servidor se encarga de la gestión del software de compartimiento de archivos en la red.

En el modelo de compartimiento de archivos, cada estación de trabajo efectúa en local todas las acciones de modificación en los datos. Esto crea un tráfico de red importante, ya que cada petición consiste en múltiples comunicaciones a través de la red. El esquema siguiente es un ejemplo de tráfico de red generado cuando un usuario busca personas de apellido “Gómez.”

Otra desventaja del modelo de compartimiento de archivos es la imposibilidad de utilizar una memoria caché para conservar los registros en memoria. Si los registros se conservan en memoria, puede haber diferentes versiones del mismo registro almacenado en la memoria caché, produciendo inconsistencia en los datos. Por lo tanto, cada vez que un usuario accede a un registro, debe ser descargado del servidor de archivos. Esto produce tráfico de red y aumenta el tiempo necesario para acceder a los datos.

La arquitectura cliente/servidor es utilizada ampliamente en el mundo de los minicomputadores, para la gestión de bases de datos muy grandes, gracias a su eficiencia y velocidad. En esta arquitectura, el trabajo se divide entre los clientes y el servidor de manera que aumente el rendimiento.

El servidor contiene el motor central de la base, que guarda y administra los datos. El motor de la base es el único software que accede a los datos almacenados en el disco. Cuando un cliente envía una petición al servidor, el servidor envía el resultado. El resultado puede ser de todo tipo desde un simple registro a modificar hasta una lista ordenada de registros. 

En general, la mayoría de las arquitecturas cliente/servidor se llaman arquitecturas heterogéneas, porque las aplicaciones frontales ejecutadas en los equipos cliente y el motor de la base de datos ejecutado en el equipo servidor son dos productos diferentes. En esta situación, un driver de base de datos es necesario para servir de traductor entre los clientes y el servidor. 

Para buscar un registro, por ejemplo, un cliente envía una petición al servidor. Como la base está almacenada en el servidor, el servidor ejecuta el comando localmente en el equipo servidor y envía el resultado al cliente. La siguiente imagen muestra un ejemplo de tráfico de red generado cuando un usuario busca cada persona de apellido “Smith” y muestra el primer registro encontrado.

Este ejemplo muestra dos diferencias mayores entre el compartimiento de archivos y la arquitectura cliente/servidor:

• La arquitectura cliente/servidor autoriza el uso de una memoria caché: como el motor es el único software que accede físicamente a los datos, el servidor puede utilizar un caché que conserva en memoria los registros modificados hasta que se escriban en el disco. Como los datos se envían desde un sitio central, los equipos clientes se aseguran de recibir siempre la última versión de un registro. Adicional al control de integridad de los datos asegura, el uso de un mecanismo de caché central acelera las operaciones de base de datos reemplazando los accesos al disco por acceso a la memoria. Bajo el modelo de compartimiento de archivos, todos los accesos son de acceso disco.
• Las operaciones de base de datos de bajo nivel se efectúan en el servidor: la arquitectura cliente/servidor ofrece un aumento significativo en la velocidad de ejecución, como la navegación de tablas de índice y direcciones, se ejecutan localmente en el servidor, a la velocidad de la máquina. Con el compartimiento de archivos, las mismas operaciones se vuelven lentas por las transferencias de red y las limitaciones del equipo cliente.

En la mayoría de las arquitecturas cliente/servidor, la aplicación cliente y la aplicación servidor son dos productos separados, que necesitan una capa de comunicación para poder entenderse entre ellos. Con 4D Server, la arquitectura cliente/servidor es totalmente integrada. 4D Server y 4D son dos aplicaciones que comparten la misma estructura y se comunican directamente. 

Como 4D Server y 4D hablan el mismo idioma, no es necesario traducir las peticiones. La división del trabajo entre el cliente y el servidor es transparente y es manejada automáticamente por 4D Server.

La división del trabajo está organizada de tal manera que una petición está asociada a una respuesta. Como lo puede ver en el diagrama anterior, el cliente es responsable de:

• Peticiones: el cliente 4D envía las peticiones a 4D Server. Estas peticiones pueden construirse con la ayuda de los editores integrados, tales como el editor de búsquedas y el editor de ordenaciones, utilizando el lenguaje integrado de 4D o vía el SQL. 4D ofrece editores en los cuales los métodos pueden crearse y modificarse. También maneja los elementos de los métodos tales como las variables y arrays.
• Recepción de respuestas: el cliente 4D recibe las respuestas de 4D Server y actualiza al usuario por medio de la interfaz de usuario (los registros diferentes se muestran en un formulario, etc.). Por ejemplo, si el cliente busca todos los registros con el apellido “Gómez,” 4D recibe los registros de 4D Server y los muestra en un formulario.

El servidor es responsable de las siguientes tareas:

• Gestión de acceso: 4D Server utiliza todas las conexiones simultáneas y los procesos creados por los clientes. Esta gestión aprovecha la arquitectura multitareas de 4D Server.

• Objeto de estructura y de datos: 4D Server guarda y administra todos los objetos de estructura y de datos, incluyendo campos, registros, formularios, métodos, barras de menús y listas.
• Caché: 4D Server mantiene una caché con los registros así como también con los objetos de datos creados por los equipos clientes, tales como selecciones y conjuntos.

• Operaciones de base de datos de bajo nivel: 4D Server realiza operaciones de base de datos de bajo nivel, tales como búsquedas y ordenaciones, que implican el uso de tablas de índices y direcciones.

Esta división del trabajo es extremadamente eficaz gracias a la integración de 4D Server y 4D. La integración de la arquitectura de 4D Server está presente en cada nivel:

• A nivel de la petición: cuando 4D envía a 4D Server una petición, tal como una búsqueda o una ordenación, 4D envía una descripción de la operación de búsqueda u ordenación utilizando la misma estructura interna que 4D Server.
• A nivel de la estructura y de los datos: cuando 4D y 4D Server intercambian un objeto de estructura o de datos, ambas aplicaciones utilizan el mismo formato interno. Por ejemplo, cuando 4D necesita un registro, 4D Server envía directamente los datos en el formato en el que se encuentran en el disco o en la memoria caché. De la misma forma, cuando 4D quiere actualizar un registro y envía los datos a 4D Server, el cual almacena los datos directamente en la caché tal como los recibe.
• A nivel de la interfaz de usuario: cuando 4D muestra una lista de registros, el formulario utilizado muestra los registros que juegan un papel en la arquitectura cliente/servidor. Por ejemplo, la siguiente imagen muestra el resultado de una petición en la tabla [Clientes].

Como el tamaño de la ventana sólo permite mostrar doce registros y cinco campos a la vez. 4D Server envía exactamente doce registros. En lugar de enviar la totalidad de los registros, 4D Server envía sólo el número de registros y campos que pueden mostrarse en la ventana. Si el usuario se desplaza por el formulario, 4D Server envía los registros adicionales o campos necesarios. Esta optimización reduce el tráfico de red asegurando que los registros y campos se envíen sólo cuando sea necesario.