Hola,
Cita:
Giniromero comentó:
En cualquier caso, hay algo que no tengo muy claro, puede parecer un tema elemental, pero, ¿como hay que tener configurada la aplicación para que sea cliente servidor?, [...]
|
no es tanto una cuestión de configuración (que también) como de diseño. Un sistema (aplicación, entorno, arquitectura, ... al nivel que estamos hablando los términos son intercambiables) cliente/servidor se basa en la existencia de al menos tres entidades: un proceso servidor (o varios), un proceso cliente (o varios) y un mecanismo de comunicación entre los dos primeros. Un ejemplo típico es el sistema en el que dejamos mensajes en este foro: procesos servidores (al menos dos: un servidor http [web] y un servidor de base de datos [para almacenar los mensajes]), procesos clientes (nuestros navegadores) y un mecanismo de comunicaciones (la pila de protocolos tcp/ip sobre diferentes sistemas operativos y las líneas de comunicaciones).
En tu caso concreto: es evidente que una aplicación diseñada para trabajar en una red local (seguramente entre 10 y 100 Mbps, tal vez 1000 Mbps) no puede trabajar con la misma "agilidad" cuando los clientes están en puestos remotos comunicados con líneas que oscilan entre 32 Kbps y los 512 Kbps. Es cierto que ciertas técnologías permiten mayores velocidades (ADSL puede contratarse hasta con 2 Mbps, incluso hasta 8 Mbps; contratación de paquetes de varios canales RDSI; uso de líneas de gran ancho de banda, ...), pero a un coste elevado. La solución pasa por economizar en el recurso que supone el cuello de botella: el tráfico de datos. ¿Cómo hacerlo?:
Uso de terminales "tontos". Los procesos servidores y clientes se ejecutan en un sistema central y sus resultados (digamos "pantallazos") se envían a los puestos remotos (terminales "tontos") por la línea de comunicaciones. Muchas aplicaciones corporativas (bancos y similares) todavía lo utilizan.
Acumulando transacciones (entendido como operaciones, sean del tipo que sean) en los puestos remotos (allí donde se ejecuten las aplicaciones clientes) para enviar posteriormente al servidor(es).
El enfoque distribuido (en varias capas). La aplicación cliente(s) no se comunica directamente con el servidor, sino con un servidor(es) intermedio, cercano geográficamente al cliente y por tanto con un tiempo de respuesta menor.
Todo lo anterior es una descripción muy somera. Existen alternativas en forma de combinaciones de las anteriores.
Saludos.