SISTEMAS DE INFORMACIÓN

Arquitectura Cliente
Servidor

http://www.renacersantaclara.org/academico
ARQUITECTURA MAINFRAME

 Procesos centralizados
 Dependencia total del MainFrame
 Terminales brutas
 Todo el proceso se realiza de lado del MainFrame
 No soporta GUI
 No es cliente servidor
ARQUITECTURA MAINFRAME

MAINFRAME
100% Procesamiento

Terminales brutas,
no poseen CPU
ARQUITECTURA DESKTOP

 Una máquina, un proceso, un usuario

 Arquitectura monolítica
 No existe posibilidad de concurrencia
 Requiere de dispositivos externos para
compartir información.
 Dbase II
ARQUITECTURA DESKTOP

Estructura Monolítica
ARQUITECTURA FILE-SHARING
 Una máquina comparte recursos (Archivos)
 Otra máquina peticiona los recursos y trabaja sobre ellos
 Terminales inteligentes
 Los procesos se realizan de lado de la máquina que peticiona
el archivo
 Soporta GUI
 No es cliente servidor
 Funciona medianamente con bajo nivel de tráfico, archivos
pequeños, pocas actualizaciones, poca concurrencia. (Máximo
12 usuarios simultáneos)
ARQUITECTURA FILE-SHARING

REPOSITORIO DE
ARCHIVOS

Terminales inteligentes,
poseen CPU
100% Procesamiento
ARQUITECTURA FILE-SHARING

Algunos gestores de bases de datos que

utilizan arquitectura File Sharing. Muchos de
ellos híbridos entre desktop y FS

Xbase, FoxBase, Dbase, FoxPro

Visual FoxPro
Access
Paradox
ARQUITECTURA CLIENTE
SERVIDOR
 Es una arquitectura basada en el principio clásico de
divide y vencerás, donde el procesamiento se
fracciona entre dos entidades fundamentales
denominadas cliente y servidor.

CLIENTE SERVIDOR
X% Proceso Y% Proceso

X + Y = 100%
Generalmente Y>X
ARQUITECTURA CLIENTE
SERVIDOR

Servidor(es)
Y% Procesamiento

Clientes inteligentes
X% Procesamiento
X + Y = 100%
ARQUITECTURA CLIENTE
SERVIDOR

 Surge en la década de los 80 como respuesta

a la evolución del hardware en términos de
redes, planteando un modelo versátil, modular
basado en mensajes que permite incrementar
la flexibilidad, la escalabilidad y la ínter-
operación de los sistemas.
ARQUITECTURA CLIENTE
SERVIDOR

 El cliente se define como el PROCESO que requiere

un servicio en particular
 El servidor se define como el PROCESO que provee
dicho servicio
 Debido a que clientes y servidores son conceptos a
nivel software y no hardware, una misma máquina
puede actuar como cliente y servidor al mismo
tiempo.
ARQUITECTURA CLIENTE
SERVIDOR

VENTAJAS
 Aprovecha mejor el ancho de banda
 Aprovecha en mayor medida el hardware
 Mayor seguridad y autonomía
 Mejor manejo de la concurrencia
 Permite que los clientes trabajen GUI mientras el
servidor se centra en los procesos centrales
ARQUITECTURA CLIENTE
SERVIDOR
 Algunos ejemplos:
 Servidor Web (Apache, IIS) Cliente Web (IExplorer, Netscape Navigator,
Mozilla)

Cliente WEB
Servidor WEB
Protocolo
ARQUITECTURA CLIENTE
SERVIDOR
 Servidor FTP (SFTP) Cliente FTP (Cute FTP, WS FTP)

Cliente FTP
Servidor FTP

Protocolo
ARQUITECTURA CLIENTE
SERVIDOR
 Servidor IRC (IRC Server) Cliente IRC (Mirc, Pirch)

Cliente IRC
Servidor IRC

Protocolo
ARQUITECTURA CLIENTE
SERVIDOR
 Servidor de Bases de datos (Interbase, Oracle, SyBase, MySql, SQL Server, Postgress)
Cliente de Base de Datos (IBManager,IBConsole, Su propio aplicativo !!!)

Cliente Interbase
Servidor InterBase

Protocolo
ARQUITECTURA CLIENTE
SERVIDOR
Interacción de clientes y servidores

Servidor de DB
(MySQL)

Servidor WEB (Apache)

BE Wset neil C

Servidor de Aplicaciones
Cliente Win32 (SkyCell) (PHP)

Servidor DB
Cliente Interbase (IBmanager) (InterBase)
ARQUITECTURA CLIENTE
SERVIDOR
CLIENTE SERVIDOR MULTICAPA (Glosario)
 CAPA: Conjunto de componentes de un aplicativo que se dedican a
una labor en particular
 CAPA DE PRESENTACIÓN (FrontEnd) : Todo aquello que se enfoca en la
interacción con el usuario final.
 REGLAS DEL NEGOCIO (Bussines rules) : Validaciones, restricciones,
reglamentos, protocolos y normativas relativas a un dominio en
particular.
 CAPA LÓGICA (Middle Tier, Middleware) : Todo aquello que gestiona y hace
valer las reglas del negocio
 CAPA DE ALMACENAMIENTO (BackEnd): Todos los elementos
dedicados a la persistencia del sistema
ARQUITECTURA CLIENTE
SERVIDOR

Ingeniería del Software

 MVC: (Modelo vista controlador) Patrón de diseño que insta a
desacoplar los elementos de presentación de los de lógica.
Planteado inicialmente en SmallTalk.
 PATRON OBSERVER: Patrón de diseño que plantea el
desacoplamiento de presentación y lógica permitiendo
múltiples vistas para una lógica en particular junto a la
implementación de un método de notificación y
actualización de vistas múltiples.
ARQUITECTURA CLIENTE
SERVIDOR
CLIENTE SERVIDOR DE 2 CAPAS
 La primera capa encapsula la presentación y la lógica
 La segunda gestiona el almacenamiento y puede almacenar
parte de la lógica (Procedimientos almacenados, triggers)

Presentación
Almacenamiento

Lógica Lógica
ARQUITECTURA CLIENTE
SERVIDOR
CLIENTE SERVIDOR DE 2 CAPAS
 Buen manejo de concurrencia hasta con 100 usuarios simultáneos aprox.
 Protocolos propietarios pueden causar problemas de flexibilidad, portabilidad y
escalabilidad.

Presentación
Almacenamiento

Lógica Lógica
ARQUITECTURA CLIENTE
SERVIDOR
CLIENTE SERVIDOR DE 3 CAPAS (Multicapa)
 Agrega una capa intermedia (middle tier) que permite priorización y gestión de
peticiones, gestión de balance, entre otros.
 Buen manejo de concurrencia con miles de usuarios simultáneos
 Protocolos estandarizados permiten gran flexibilidad, portabilidad y escalabilidad.

Almacenamiento
Presentación Lógica
Lógica
ARQUITECTURA CLIENTE
SERVIDOR
ARQUITECTURA CLIENTE
SERVIDOR
CLIENTE SERVIDOR DE 3 CAPAS (Multicapa)
 Ejemplo: Google

Servidor de indexación
Millones de clientes
(5’000.000 por día,
57 por segundo aprox.) Servidor de documentos

Servidor de balance
Bibliografía
 Meyer Bertran, Construcción de software orientado a objetos
 Booch Grady, Análisis y diseño orientado a objetos
 Aguilar Luis J, Programación Orientada a Objetos
 Gates Bill Camino al futuro
 Cantú Marco, Mastering Delphi 7
 Cantú Marco,Essential Delphi
 Cantú Marco,Essential Pascal
 Ray Lischner, Delphi In A Nutshell
 Delphi Magazine
 Ayres, Bowden, Diehl, Dorcas, The Tomes of Delphi
 Reisdorph Kent, Teach Yourself Borland Delphi 4 in 21 Days
Bibliografía
 http://www.nationmaster.com
 http://www.ddj.com/
 http://www.sdmagazine.com/
 http://www.byte.com/
 http://www.borland.com
 http://www.acm.com
 http://www.wikipedia.org
 http://www.byte.com/
 http://www.marcocantu.com
 http://www.mers.com
 http://liinwww.ira.uka.de/bibliography/
 http://www.webopedia.com
 http://www-db.stanford.edu/~backrub/google.html
 http://www.malditainternet.com/node/60
 http://www.akamarketing.com/google-dance-guide.html
 FIN Módulo
Arquitectura

jcampo@renacersantaclara.org