TICB1 - Arquitecturas Cliente Servidor

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.
Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968
B1G1T06 - ARQUITECTURAS CLIENTE SERVIDOR.
1. INTRODUCCIN A LA ARQUITECTURA CLIENTE/SERVIDOR ........................................................................ 2

1.1. DEFINICIN DE SISTEMA CLIENTE/SERVIDOR ................................................................................................. 2
1.2. FUNCIONAMIENTO USUAL DE UN SISTEMA CLIENTE/SERVIDOR ............................................................... 3
2. COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR ....................................................................... 3
2.1. ELEMENTOS PRINCIPALES .................................................................................................................................... 4
2.1.1. CLIENTE .............................................................................................................................................................. 4
2.1.2. SERVIDOR ........................................................................................................................................................... 5
2.1.3. MIDDLEWARE .................................................................................................................................................... 5
2.2. COMUNICACIN ENTRE LOS ELEMENTOS (NOS)............................................................................................. 6
2.2.1. ELEMENTOS DEL NOS ...................................................................................................................................... 7
2.2.1.1. SERVICIOS DE TRANSPORTE ....................................................................................................................... 7
2.2.1.2. SERVICIOS DE APLICACIN ........................................................................................................................ 9
3. TIPOLOGA..................................................................................................................................................................... 10
3.1. POR TAMAO DE COMPONENTES...................................................................................................................... 10
3.1.1. FAT CLIENT (THIN SERVER).......................................................................................................................... 10
3.1.2. FAT SERVER (THIN CLIENT)........................................................................................................................... 10
3.2. POR NATURALEZA DE SERVICIO ....................................................................................................................... 11
3.2.1. SERVIDORES DE FICHEROS........................................................................................................................... 11
3.2.2. SERVIDORES DE BASES DE DATOS............................................................................................................... 11
3.2.3. SERVIDORES DE TRANSACCIONES............................................................................................................... 11
3.2.4. SERVIDORES DE TRABAJO EN GRUPO ........................................................................................................ 14
3.2.5. SERVIDORES DE OBJETOS ............................................................................................................................. 14
3.2.6. SERVIDORES DE WEB ..................................................................................................................................... 15
4. MODELOS CLIENTE/SERVIDOR............................................................................................................................... 16
4.1. A NIVEL DE SOFTWARE ........................................................................................................................................ 16
4.1.1. MODELO CLIENTE/SERVIDOR 2 CAPAS....................................................................................................... 16
4.1.1.1. IMPLEMENTADO CON SQL REMOTO ....................................................................................................... 16
4.1.1.2. IMPLEMENTADO CON PROCEDIMIENTOS ALMACENADOS ................................................................ 17
4.1.2. MODELO CLIENTE/SERVIDOR 3 CAPAS....................................................................................................... 17
4.2. A NIVEL DE HARDWARE....................................................................................................................................... 18
4.2.1. MODELO CLIENTE / SERVIDOR 2 CAPAS..................................................................................................... 19
4.2.2. MODELO CLIENTE / SERVIDOR 3 CAPAS..................................................................................................... 19
5. VENTAJAS E INCONVENIENTES .............................................................................................................................. 19
5.1. VENTAJAS................................................................................................................................................................ 19
5.2. INCONVENIENTES ................................................................................................................................................. 20
6. CONCLUSIN ................................................................................................................................................................. 20
7. BIBLIOGRAFA .............................................................................................................................................................. 21
8. ESQUEMA RESUMEN ................................................................................................................................................ 22
TEMARIO-TICB-feb04 B1G1T06
Actualizado en febrero de 2004 Pgina 1 de 23
1. INTRODUCCIN A LA ARQUITECTURA CLIENTE/SERVIDOR

Entre las primeras cosas que hay que decir de la arquitectura Cliente/Servidor, es que estamos frente a la
plataforma abierta por excelencia. Ciertamente las posibilidades de igualar o nivelar distintos productos,
aplicaciones o componentes de distintos proveedores nos brinda la oportunidad de hacer una gran variedad de
combinaciones entre clientes y servidores.
Pero esta gran variedad de posibilidades de combinacin implica que debemos tener en cuenta tambin una gran
cantidad de elementos a considerar y evaluar en el momento de enfrentarnos a una solucin informtica basada
en la arquitectura Cliente/Servidor.
La problemtica Cliente/Servidor se puede agrupar bsicamente en dos aspectos:
Qu plataforma elegir?
Qu herramientas de desarrollo elegir?
La primera pregunta tiene relacin con la respuesta a cuestiones an ms especficas como pueden ser: qu
plataforma cliente elegir? qu plataforma servidor? qu clase de middleware? qu administrador o servidor de
base de datos? sobre qu arquitectura de computacin distribuida se tendr que montar la solucin?
El segundo aspecto tiene relacin con la toma de decisiones sobre el rea de desarrollo y herramientas de
Cliente/Servidor.
Si bien es cierto que la mayor ventaja de esta tecnologa es la flexibilidad en cuanto a que podemos elegir entre
muchas opciones, esto mismo nos obliga a tener conocimientos importantes para la integracin de las mismas,
dado que el desarrollo de aplicaciones Cliente/Servidor requiere del manejo de elementos en el rea de diseos
de bases de datos, comunicacin entre procesos, procesamiento de transacciones, y para que hablar de
Internet, con clientes y servidores distribuidos a lo largo de la Web.
1.1. DEFINICIN DE SISTEMA CLIENTE/SERVIDOR
La tecnologa Cliente/Servidor es el procesamiento cooperativo de la informacin por medio de un conjunto de

procesadores, en el cual mltiples clientes, distribuidos geogrficamente, solicitan requerimientos a uno o ms
servidores centrales.
Desde el punto de vista funcional, se puede definir la computacin Cliente/Servidor como una arquitectura
distribuida que permite a los usuarios finales obtener acceso a la informacin de forma transparente an en
entornos multiplataforma. Se trata pues, de la arquitectura ms extendida en la realizacin de Sistemas
Distribuidos.
Un sistema Cliente/Servidor es un Sistema de Informacin distribuido basado en las siguientes caractersticas:
Servicio: unidad bsica de diseo. El servidor los proporciona y el cliente los utiliza.
Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a travs de ellos, comparten
tanto recursos lgicos como fsicos.
Protocolos asimtricos: Los clientes inician conversaciones. Los servidores esperan su establecimiento
pasivamente.
Transparencia de localizacin fsica de los servidores y clientes: El cliente no tiene por qu saber dnde
se encuentra situado el recurso que desea utilizar.
Independencia de la plataforma HW y SW que se emplee.
Sistemas dbilmente acoplados. Interaccin basada en envo de mensajes.
Encapsulamiento de servicios. Los detalles de la implementacin de un servicio son transparentes al
cliente.
Escalabilidad horizontal (aadir clientes) y vertical (ampliar potencia de los servidores).

Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento.
1.2. FUNCIONAMIENTO USUAL DE UN SISTEMA CLIENTE/SERVIDOR
En el modelo usual Cliente/Servidor, un servidor, a veces llamado daemon, se activa y espera las solicitudes de
los clientes. Habitualmente, programas cliente mltiples comparten los servicios de un programa servidor comn.
Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicacin mayores.
Esquema de funcionamiento de un Sistema Cliente/Servidor
1) El cliente solicita una informacin al servidor.

2) El servidor recibe la peticin del cliente.
3) El servidor procesa dicha solicitud.
4) El servidor enva el resultado obtenido al cliente.
5) El cliente recibe el resultado y lo procesa.
2. COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

Como se ha venido diciendo, Cliente/Servidor es un modelo basado en la idea del servicio, en el que el cliente es
un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Adems esta relacin
est establecida en funcin del intercambio de mensajes que es el nico elemento de acoplamiento entre ambos.
De estas lneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e implantan los
sistemas Cliente/Servidor: el proceso cliente que es quien inicia el dilogo, el proceso servidor que pasivamente
espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la
conectividad entre el cliente y el servidor para poder intercambiar mensajes.
Para entender en forma ms ordenada y clara los conceptos y elementos involucrados en esta tecnologa se
puede aplicar una descomposicin o arquitectura de niveles. Esta descomposicin principalmente consiste en
separar los elementos estructurales de esta tecnologa en funcin de aspectos ms funcionales de la misma:
Nivel de Presentacin: Agrupa a todos los elementos asociados al componente Cliente.

Nivel de Aplicacin: Agrupa a todos los elementos asociados al componente Servidor.
Nivel de comunicacin: Agrupa a todos los elementos que hacen posible la comunicacin entre los
componentes Cliente y servidor.
Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.
Este modelo de descomposicin en niveles, como se ver ms adelante, permite introducir ms claramente la
discusin del desarrollo de aplicaciones en arquitecturas de hardware y software en planos.
2.1. ELEMENTOS PRINCIPALES
2.1.1. CLIENTE
Un cliente es todo proceso que reclama servicios de otro. Una definicin un poco ms elaborada podra ser la
siguiente: cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor. Se lo
conoce con el trmino front-end.
ste normalmente maneja todas las funciones relacionadas con la manipulacin y despliegue de datos, por lo que
estn desarrollados sobre plataformas que permiten construir interfaces grficas de usuario (GUI), adems de
acceder a los servicios distribuidos en cualquier parte de la red.
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
Administrar la interfaz de usuario.

Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.
La funcionalidad del proceso cliente marca la operativa de la aplicacin (flujo de informacin o lgica de negocio).
De este modo el cliente se puede clasificar en:
Cliente basado en aplicacin de usuario.
Cliente basado en lgica de negocio.
Cliente basado en aplicacin de usuario. Si los datos son de baja interaccin y estn fuertemente
relacionados con la actividad de los usuarios de esos clientes.
Cliente basado en lgica de negocio. Toma datos suministrados por el usuario y/o la base de datos y
efecta los clculos necesarios segn los requerimientos del usuario.
2.1.2. SERVIDOR
Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de atender a mltiples
clientes que hacen peticiones de algn recurso administrado por l. Al proceso servidor se lo conoce con el
trmino back-end.
El servidor normalmente maneja todas las funciones relacionadas con la mayora de las reglas del negocio y los
recursos de datos.
Las principales funciones que lleva a cabo el proceso servidor se enumeran a continuacin:
Aceptar los requerimientos de bases de datos que hacen los clientes.

Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los clientes.
Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de datos.
Puede darse el caso que un servidor acte a su vez como cliente de otro servidor.
Existen numerosos tipos de servidores, cada uno de los cuales da lugar a un tipo de arquitectura Cliente/Servidor
diferente; pero de esta clasificacin se hablar en el apartado 3 (Tipologa) del tema.
Ambigedad: Normalmente se llama servidores tanto a las aplicaciones o procesos que realizan un servicio como
a los ordenadores que les sirven de soporte. En este tema normalmente nos referiremos a los procesos de
servicio.
2.1.3. MIDDLEWARE
El middleware es un mdulo intermedio que acta como conductor entre sistemas permitiendo a cualquier usuario
de sistemas de informacin comunicarse con varias fuentes de informacin que se encuentran conectadas por
una red. En el caso que nos concierne, es el intermediario entre el cliente y el servidor y se ejecuta en ambas
partes.
La utilizacin del middleware permite desarrollar aplicaciones en arquitectura Cliente/Servidor independizando los
servidores y clientes, facilitando la interrelacin entre ellos y evitando dependencias de tecnologas propietarias.
El concepto de middleware no es un concepto nuevo. Los primeros monitores de teleproceso de los grandes
sistemas basados en tecnologa Cliente/Servidor ya se basaban en l, pero es con el nacimiento de la tecnologa
basada en sistemas abiertos cuando el concepto de middleware toma su mxima importancia.
El middleware se estructura en tres niveles:
Protocolo de transporte.
Network Operating System (NOS).
Protocolo especfico del servicio.
Especfico Servicio ODBC TxRPC Correo ORB HTTP

Directorio Seguridad Tiempo
NOS
RPC Mensajes Peer-to-Peer
Transporte NetBios TCP/IP IPX/SPX SNA
Las principales caractersticas de un middleware son:
Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios.

Permite la interconectividad de los Sistemas de Informacin del Organismo.
Proporciona mayor control del negocio al poder contar con informacin procedente de distintas
plataformas sobre el mismo soporte.
Facilita el desarrollo de sistemas complejos con diferentes tecnologas y arquitecturas.
Dentro de los inconvenientes ms importantes destacan la mayor carga de mquina necesaria para que puedan
funcionar.
2.2. COMUNICACIN ENTRE LOS ELEMENTOS (NOS)
Como se ha comentado en el apartado anterior, el middleware es un conjunto de aplicaciones encargadas de

enlazar al cliente con el servidor.
Para ello se estructura en tres capas diferentes:
Protocolo de transporte: comunes a otras aplicaciones.

Network Operating System (NOS).
Protocolo especfico del servicio: especiales para distintos tipos de sistemas Cliente/Servidor.
Este apartado se centra en el Network Operating System por ser la parte central de toda la comunicacin entre el
cliente y el servidor.
El NOS es el encargado de proporcionar una apariencia de sistema nico a un sistema Cliente/Servidor. Se trata
pues, de una extensin del Sistema Operativo:
El cliente realiza una llamada a un servicio como si fuera local.

El NOS
Intercepta la llamada.
Redirige la llamada al servidor apropiado.
Devuelve la contestacin.
El NOS debe proporcionar transparencia a los procesos Cliente/Servidor con respecto a:
Localizacin: Los recursos slo se conocen por su nombre. El sistema en el que se ejecutan es
irrelevante.
Espacio de nombres: Las convenciones de los nombres de los recursos deben ser iguales,
independientemente del sistema que los soporte.
Conexin: Un nico usuario y contrasea para todo el sistema.
Replicacin: No se debe diferenciar entre copias de un mismo recurso.
Acceso local / remoto: El acceso a un recurso se debe realizar como si estuviera localizado en el mismo
sistema que el programa cliente.
Tiempo: Los relojes de todos los elementos del sistema deben estar sincronizados.
Fallos: El sistema debe proporcionar servicios de deteccin de fallos, redundancia y reconexin tras un
fallo.
Administracin: Un nico sistema de gestin de todos los recursos.
Protocolos: Idntica interfaz de programacin para todos los protocolos de transporte.
2.2.1. ELEMENTOS DEL NOS
2.2.1.1. SERVICIOS DE TRANSPORTE
Entre los servicios de transporte que utiliza el NOS cabe destacar estos tres:
Comunicaciones Peer to Peer (P2P)

Cualquier ordenador puede originar una conversacin.
Protocolo simtrico.
Inicialmente especficos del protocolo sobre el que se utilizan.
Sus principales APIs son: Sockets, NetBios, Named Pipes, IPX/SPX, APPC.
Colas de mensajes: Se trata de un proceso asncrono.
Conectividad Cliente/Servidor no permanente y costosa.
El cliente no puede esperar a la respuesta para continuar el proceso.
Proceso de mensajes con prioridades (no FIFO).
Workflow: envo de mensajes en cadena de aplicaciones.
1) La aplicacin genera un mensaje.

2) Lo pone en una cola, y sigue procesando.
3) La aplicacin destino lo extrae de la cola cuando pueda procesarlo.
4) La respuesta sigue el mismo procedimiento.
Remote Procedure Calls (RPC)

La ejecucin del servicio en el cliente se realiza del mismo modo que una llamada a una funcin
local.
Existen varios tipos de problemas de transparencia:
Paso de parmetros: No es posible pasar parmetros por referencia.
Semntica de la llamada (problemas con el comportamiento de la llamada):
- Tras un TimeOut no se sabe si la llamada se ha ejecutado.
- Distintos tipos de operaciones: las idempotentes se pueden ejecutar cualquier nmero de
veces; y las no idempotentes son las que el resultado vara con el nmero de veces que se
ejecutan.
Representacin de los distintos tipos de datos: Se hace necesario un mtodo de representacin
de datos independiente del sistema.
Rendimiento de las llamadas.
Seguridad.
CLIENTE SERVIDOR
1 5
Aplicacin Client Server Aplicacin
Cliente Stub Stub Servidor
10 6
Mensaje
9 4 7
2
Entidad de Entidad de
Transporte Transporte
3
Mensaje
RED
8
a) El cliente llama a una funcin con una serie de parmetros (Client Stub) (1).
b) El CLient Stub compone un mensaje para el servidor (parameter marshalling) (2).
c) El mensaje se enva a travs de un protocolo de transporte (2, 3).
d) La entidad de transporte del servidor lo recibe y lo pasa al Server Stub (4).
e) El Server Stub recibe el mensaje y extrae de l la informacin que necesita (parameter

unmarshalling) (5).
f) El Server Stub pasa la peticin a la rutina de servicio (5).
g) La contestacin del servidor sigue un proceso anlogo:
Respuesta del servidor (6).
Generacin del mensaje de respuesta (parameter marshalling) (7).

Envo del mensaje a travs del protocolo de transporte (8).
Descomposicin del mensaje en el Client Stub (parameter unmurshalling) (9).
Entrega de la respuesta de la funcin al cliente (10).
El cliente permanece a la espera de la respuesta bloqueado en la llamada a la rutina.
Caractersticas Peer to Peer Message Oriented Middleware Remote Procedure Calls
Modelo Conversacin normal Correo. Llamada telefnica.
Asncrona. Clientes y servidores pueden
Temporizacin Sncrona. Sncrona. Trabajo concurrente.
trabajar a distintas velocidades.
Las dos partes de la Los servidores deben estar
Secuencia de
conversacin deben estar No fija. disponibles antes que comiencen
Arranque sistema disponibles. los clientes.
Estilo Llamada / respuesta. Mensajes encolados. Llamada / respuesta.
Extremos listos
S. No. S.
Simultneamente
Filtrado de mensajes No posible. Posible. No posible.
Alto. Comunicacin directa sin Bajo. Requiere almacenamiento Alto. Comunicacin directa sin
Rendimiento intermediarios. intermedio. intermediarios.
Limitado. Mediante el uso de Limitado. Requiere creacin de
Proceso asncrono procesos e hilos. S. tareas y sincronizacin entre
procesos.
Comparacin de los modelos P2P - MOM - RPC
2.2.1.2. SERVICIOS DE APLICACIN
Cabe destacar, entre los servicios de aplicacin del soporte de comunicaciones de un sistema Cliente/Servidor,
los siguientes:
Servicios de directorio global:

Refleja la composicin del sistema Cliente/Servidor en todo momento.
Encargado de resolver la transparencia de ubicacin.
Se puede implementar como estructura plana o jerrquica.
Cada entrada contiene todos los datos asociados al elemento: direccin, estado, otras variables
Un claro ejemplo de los servicios de directorio global son los espacios de nombres (namespaces).
Servicios de tiempo (fecha y hora):
Mantienen consistente la informacin de tiempo (timestamp) de todos los componentes de un sistema
Cliente/Servidor.
Sincronizan peridicamente cada ordenador de la red.
Mantienen un componente de inexactitud en cada ordenador, en el que cada agente conoce las
desviaciones esperadas del sistema en el que residen y lo resincronizan cuando la desviacin es
mayor que un umbral determinado.
Uno o ms servidores deben estar conectados a un proveedor externo de informacin de tiempo
(time ticks) y el resto de servidores realizan consultas para sincronizar sus relojes.
Servicios de seguridad:
Los sistemas Cliente/Servidor plantean nuevos problemas de seguridad sobre los sistemas centrales
tradicionales.
Deben reconocer a los ordenadores de la red y permitir el acceso a los usuarios adecuados, as
como garantizar que el ordenador es quien dice que es.
Confidencialidad en la transmisin de datos en la red.
Se utilizan varios mtodos de cifrado: cifradores de bloques, intercambio de claves, algoritmos de

clave pblica, autentificacin de usuarios, firma digital, certificados
3. TIPOLOGA
Uno de los aspectos claves para entender la tecnologa Cliente/Servidor, y por tanto contar con la capacidad de
proponer y llevar a cabo soluciones de este tipo, es llegar a conocer la arquitectura de este modelo y los
conceptos o ideas asociados al mismo. Ms all de entender los componentes cliente/middleware/servidor, es
preciso analizar ciertas relaciones entre stos, que pueden definir el tipo de solucin que se ajusta de mejor forma
a las estadsticas y restricciones acerca de los eventos y requerimientos de informacin que se obtuvieron en la
etapa de anlisis de un determinado proyecto. De hecho el analista deber conocer estos eventos o restricciones
del proyecto para que a partir de ah, se puedan hacer las consideraciones y estimaciones de la futura
configuracin, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la informacin, tiempo de
respuesta, tamaos de registros, tamao de bases de datos, estimaciones del trfico de red, distribucin
geogrfica tanto de los procesos como de los datos, etc.
En tal sentido se presenta, en primer lugar, un esquema de clasificacin basado en los conceptos de Fat
Client/Thin Client, Fat Server/Thin Server, es decir, basado en el tamao de los componentes. En segundo lugar
tenemos una clasificacin segn la naturaleza del servicio que nos ofrecen.
3.1. POR TAMAO DE COMPONENTES
Este tipo de clasificacin se basa en los grados de libertad que brinda el modelo Cliente/Servidor para balancear
la carga de proceso entre los niveles de presentacin, aplicacin y base de datos. Dependiendo de qu segmento
de las capas de software tenga que soportar la mayor o menor carga de procesamiento, se habla de Fat Client
(Thin Server) o Fat server (Thin Client). Consideraciones de este tipo son importantes en el momento de decidir
una plataforma de desarrollo, al mismo tiempo que pueden definir la viabilidad o no de las mismas para enfrentar
un cierto nmero de restricciones impuestas por una problemtica a resolver.
3.1.1. FAT CLIENT (THIN SERVER)
En este esquema de arquitectura el peso de la aplicacin es

ejecutada en el cliente, es decir, el nivel de presentacin y el nivel de
aplicacin corren en un nico proceso cliente, y el servidor es
relegado a realizar las funciones que provee un administrador de
base de datos.
En general este tipo de arquitectura tiene mejor aplicacin en

sistemas de apoyo de decisiones (DSS: Decision Support System) y
sistemas de informacin ejecutiva (EIS: Executive Information
System), y como se concluir ms adelante, tiene pocas
posibilidades de aplicarse en sistemas de misin crtica.
3.1.2. FAT SERVER (THIN CLIENT)
Este es el caso opuesto al anterior, el proceso cliente es restringido

a la presentacin de la interfaz de usuario, mientras que el peso de
la aplicacin corre por el lado del servidor de aplicacin.
En general este tipo de arquitectura presenta una flexibilidad mayor

para desarrollar una gran variedad de aplicaciones, incluyendo los
sistemas de misin crtica a travs de servidores de transacciones.
3.2. POR NATURALEZA DE SERVICIO
3.2.1. SERVIDORES DE FICHEROS
Con un servidor de archivos, un cliente lo que hace es requerimientos de los mismos sobre una red. Esta es una
forma muy primitiva de servicios de datos, la cual necesita intercambio de muchos mensajes sobre una red para
hallar el dato requerido. Los servidores de archivos usan recursos compartidos sobre la red y son necesarios para
crear repositorios de documentos, imgenes y archivos grandes sobre la red.
3.2.2. SERVIDORES DE BASES DE DATOS
Este anlisis est elaborado desde el punto de vista del modelo Cliente/Servidor, y est directamente relacionado
con la arquitectura en dos planos, que se describir en el apartado siguiente.
Obviamente la creacin de aplicaciones Cliente/Servidor est asociada a la utilizacin de servidores de bases de

datos relacionales SQL, y dependiendo de los requerimientos y restricciones se debe elegir entre una arquitectura
dos o tres planos. Pero para una arquitectura centrada en un servidor de bases de datos, cualquiera de las
modalidades dos planos, permite que un proceso cliente solicite datos y servicios directamente a un servidor de
bases de datos. Segn las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso
compartido a los datos con los mecanismos de proteccin necesarios, as como proveer mecanismos para
seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro en procesos de comunicacin. El
servidor debe tambin proveer mecanismos de concurrencia, seguridad y consistencia de datos, basado
principalmente en el concepto de transaccin en el que todo se realiza, y por lo tanto se hace permanente, o todo
falla, anulndose la transaccin en tal caso.
Los servidores de bases de datos actuales son una mezcla de SQL estndar ms otras extensiones propias de
cada proveedor. Por ejemplo casi todas las bases de datos estn provistas con:
Procedimientos almacenados (stored procedures): Una de las posibilidades de implementar de mejor

forma un sistema Cliente/Servidor en dos planos (two-tier), sin olvidar todas sus restricciones y
limitaciones, es a travs de procedimientos almacenados, que son funciones que agrupan un conjunto de
instrucciones y lgica de procedimientos SQL, los cuales son compilados y almacenados en la misma
base. El rol principal de los procedimientos almacenados es proveer la parte servidora de la lgica de una
aplicacin Cliente/Servidor, es decir vendra a reemplazar al servidor de aplicaciones en una arquitectura
tres planos (three-tier).
Desencadenantes (triggers): Son mecanismos que permiten realizar acciones automticamente sobre los
datos, las cuales estn asociadas a algn evento definido. Normalmente son implementados a travs de
procedimientos almacenados. Los eventos a los cuales se hace referencia estn asociados a las
actualizaciones de tablas mediante sentencias delete, insert o update, y son llamados implcitamente al
suceder cualquiera de estos eventos, a diferencia de los procedimientos almacenados que son llamados
explcitamente por un proceso cliente.
Restricciones (constraints): Al igual que los desencadenantes, son acciones que se realizan asociadas a
algn evento determinado y estn orientadas a llevar a cabo validaciones ms simples de datos. Los tipos
de eventos son los mismos que para los desencadenantes.
3.2.3. SERVIDORES DE TRANSACCIONES
Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades Cliente/Servidor en dos o tres
planos, pero incorporan un elemento principal sobre el cual se elabora y basa toda la fortaleza de este modelo, el
concepto de transaccin.
Con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o mtodos que residen en
el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de aplicaciones. Lo importante es
que el intercambio a travs de la red se realiza mediante un nico mensaje de solicitud/respuesta, es decir,
independientemente de que se necesite ejecutar una o ms funciones, una o ms instrucciones o sentencias
SQL, stas son agrupadas en una unidad lgica llamada transaccin; evitando as el intercambio a travs de la
red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas Cliente/Servidor
dos planos, implementados a travs de SQL remoto. Estas aplicaciones denominadas OLTP (On Line Transaction
Proccesing) estn orientadas a dar soporte a los procedimientos y reglas de los sistemas de misin crtica.
En la actualidad muchas aplicaciones tienen la necesidad de ser desarrolladas con la ayuda de transacciones,
vase el ejemplo de los cajeros automticos: imaginemos que queremos sacar dinero. Introducimos la cantidad
adecuada y pulsamos el botn de enviar. El cajero manda una solicitud al banco para que descuente dicha
cantidad de la cuenta del cliente, y recibe la respuesta. Si diera la casualidad que la respuesta del banco se
perdiera en medio de la red, el cajero volvera a realizar la peticin, por lo que el banco volvera a descontar dicha
cantidad de la cuenta bancaria asociada. Este problema tan comn se soluciona con la ayuda de las
transacciones.
Prepare_to_Commit
Ready_to_Commit Ready_to_Commit Ready_to_Commit

Prepare_to_Commit
Ready_to_Commit
Commit
Complete Complete Complete Commit
Complete
Two-Phase Commit (I)
Prepare_to_Commit
Ready_to_Commit Refuse Ready_to_Commit

Prepare_to_Commit
Ready_to_Commit
Rollback
Complete Complete Complete

Rollback
Complete
Two-Phase Commit (II)
El modelo de comunicacin ms usado entre el cliente y el servidor a la hora de realizar transacciones planas
distribuidas es el Two-Phase-Commit, el cual funciona de la siguiente manera:
Caso 1: Todas las operaciones en los distintos sistemas han sido correctas.
Fase 1:
El nodo gestor enva prepare to commit a todos los nodos subordinados.
Devuelven al nodo gestor ready to commit.
Fase 2:
El nodo gestor enva commit a todos los nodos subordinados.
Los nodos subordinados finalizan la transaccin y devuelven al nodo gestor complete.

Caso 2: Algn sistema no puede finalizar la transaccin.
Fase 1:
El nodo que no puede realizar correctamente la transaccin contesta refuse al prepare_to_commit
del nodo gestor.
Fase 2:
El nodo gestor enva rollback a todos los nodos subordinados.
Los nodos subordinados deshacen la transaccin y devuelven al nodo gestor complete.
La parte central de cualquier servidor de transacciones es el TP Manager. El ncleo del TP consta de diferentes
partes:
Gestor de transacciones (Transaction Manager):

Arranque de la transaccin.
Registro de Gestores de Recursos que participan.
Gestin Commit/Rollback.
RPCs transaccionales:
Permiten garantizar la integridad de la transaccin cuando no se ejecuta en un solo ordenador.
RPCs con un identificador de transaccin asociado, asignado por el TM.
Gestor de registro de modificaciones (Log Manager).
Graba los cambios realizados por los Gestores de Recursos.
Permite reconstruir una versin consistente de todos los recursos.
Gestor de bloqueos (Lock Manager)
Proporciona mecanismos para regular el acceso concurrente a lso recursos.
Esquema de comunicacin mediante transacciones
3.2.4. SERVIDORES DE TRABAJO EN GRUPO
Este tipo de sistema Cliente/Servidor es difcil de definir. Se trata de un conjunto de tecnologas encaminadas a
representar procesos complejos relacionados con actividades que requieren colaboracin.
Groupware direcciona la administracin de informacin semi-estructurada como texto, imgenes, correo, bulletin
boards y flujo de trabajo. Estos sistemas Cliente/Servidor ponen en contacto directo a personas con otras
personas. Lotus Notes y Microsoft Exchange son ejemplos de este tipo de sistemas. En muchos casos las
aplicaciones son creadas usando un lenguaje de script, con interfaces grficas. Tpicamente el middleware de
comunicaciones entre clientes y servidores es especfico de cada vendedor, aunque muchos productos
groupware usan el e-mail como su estndar para el paso de mensajes. Internet se est volviendo la plataforma
middleware para estas aplicaciones.
Existen en torno a cinco tecnologas bsicas:
Heredados de los sistemas de gestin de imgenes:

MDM: Multimedia Document Management.
Control de flujo de trabajo, Workflow.
Heredados de los sistemas de automatizacin de oficinas:
Correo electrnico.
Planificacin.
Heredado de los sistemas BBS e Internet.
Multiconferencia.
3.2.5. SERVIDORES DE OBJETOS
Con un servidor de objetos, las aplicaciones Cliente/Servidor son escritas como un conjunto de objetos que se
comunican. Los objetos cliente se comunican con los objetos servidores usando un Object Request Broker (ORB).
El cliente invoca un mtodo de un objeto remoto. El ORB localiza el mtodo del objeto en el servidor, y lo ejecuta
para devolver el resultado al objeto cliente. Los servidores de objetos deben soportar concurrencia.
ORB
La parte central de la comunicacin en los servidores de objetos es el ORB:
Elemento central y principal de esta arquitectura.

Bus de objetos. Permite la comuniacin entre ellos.
Middleware avanzado:
Permite llamadas estticas y dinmicas a objetos.

Lenguaje de descripcin de interfaces independiente del lenguaje de programacin.
Sistema autodescrito. Genera meta-informacin sobre todo el sistema.
Transparencia de localizacin.
Soporte de seguridad.
Soporte de transacciones.
Algunos de los servicios que ofrece actualmente el ORB son:
Persistencia. Almacenamiento de los componentes de modo duradero.

Nombres. Localizacin de componentes por nombre.
Eventos. Permite a los componentes registrar su inters en eventos especficos.
Control de concurrencia. Gestos de bloqueos para garantizar la exclusividad de acceso a los recursos.
Relaciones. Permite crear dinmicamente asociaciones o enlaces entre componentes.
Tiempo. Permite sincronizacin entre componentes y disparo de alarmas temporales.
Seguridad
3.2.6. SERVIDORES DE WEB
La primera aplicacin cliente servidor que cubre todo el planeta es el World Wide Web. Este nuevo modelo
consiste en clientes simples que hablan con servidores Web. Un servidor Web devuelve documentos cuando el
cliente pregunta por el nombre de los mismos. Los clientes y los servidores se comunican usando un protocolo
basado en RPC, llamado HTTP. Este protocolo define un conjunto simple de comandos, los parmetros son
pasados como cadenas y no provee tipos de datos. La Web y los objetos distribuidos estn comenzando a crear
un conjunto muy interactivo de computacin Cliente/Servidor.
Modo de funcionamiento de un servidor WEB:
El usuario selecciona una URL que desea visualizar desde su navegador (1).
El navegador genera una peticin http y la enva al servidor Web solicitado (2).
El servidor recibe la peticin y enva la pgina solicitada (3)
Una sesin TCP por cada solicitud.
La pgina se codifica utilizando HTML.
El cliente (navegador) visualiza la pgina recibida (4, 4a)
Puede tener asociados nuevos elementos en su interior (4b).
Nueva solicitud a los servidores que los contienen para su recuperacin (se realiza una nueva sesin
TCP) (4b).
4. MODELOS CLIENTE/SERVIDOR
Una de las clasificaciones mejor conocidas de las arquitecturas Cliente/Servidor se basa en la idea de planos
(tier), la cual es una variacin sobre la divisin o clasificacin por tamao de componentes. Esto se debe a que se
trata de definir el modo en que las prestaciones funcionales de la aplicacin sern asignadas, y en qu
proporcin, tanto al cliente como al servidor. Dichas prestaciones se deben agrupar entre los tres componentes
clsicos para Cliente/Servidor: interfaz de usuario, lgica de negocios y los datos compartidos, cada uno de los
cuales corresponde a un plano. Ni que decir tiene que la mala eleccin de uno u otro modelo puede llegar a tener
consecuencias fatales.
Dentro de esta categora tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier) y multi-planos
(multi-tier). Dado que este trmino ha sido sobrecargado de significados por cuanto se lo utiliza indistintamente
para referirse tanto a aspectos lgicos (Software) como fsicos (Hardware), aqu se esquematizan ambas
acepciones.
4.1. A NIVEL DE SOFTWARE
Este enfoque o clasificacin es el ms generalizado y el que ms se ajusta a los enfoques modernos, dado que
se fundamenta en los componentes lgicos de la estructura Cliente/Servidor y en la madurez y popularidad de la
computacin distribuida. Por ejemplo, esto permite hablar de servidores de aplicacin distribuidos a lo largo de
una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no ms bien entenderlo
como una plataforma fsica sobre la cual pueden operar uno o ms servidores de aplicaciones.
4.1.1. MODELO CLIENTE/SERVIDOR 2 CAPAS
Esta estructura se caracteriza por la conexin directa entre el proceso cliente y un administrador de bases de
datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lgica de negocios se pueden
tener a su vez dos tipos distintos dentro de esta misma categora:
4.1.1.1. IMPLEMENTADO CON SQL REMOTO
En este esquema el cliente enva mensajes con solicitudes SQL al servidor de bases de datos y el resultado de
cada instruccin SQL es devuelto por la red, no importando si son uno, diez, cien o mil registros. Es el mismo
cliente quien debe procesar todos los registros que le fueron devueltos por el servidor de base de datos, segn el
requerimiento que l mismo hizo. Esto hace que este tipo de estructura se adecue a los requerimientos de
aplicaciones orientadas a los sistemas de apoyo y gestin, pero resultan inadecuados para los sistemas crticos
en que se requieran bajos tiempos de respuesta.
Ventajas:
Presenta una estructura de desarrollo

bastante simple ya que el programador
maneja un nico ambiente de desarrollo
(es ms simple respecto al
Cliente/Servidor en tres planos, puesto
que reduce una capa de programacin,
como se ver ms adelante).
Inconvenientes:
La gran cantidad de informacin que viaja

al cliente congestiona demasiado el trfico
de red, lo que se traduce en bajo
rendimiento.
Por su bajo rendimiento esta estructura
tiene un bajo espectro de aplicacin,
limitndose a la construccin de sistemas
no crticos.
4.1.1.2. IMPLEMENTADO CON PROCEDIMIENTOS ALMACENADOS
En este esquema el cliente enva llamadas a funciones

que residen en la base de datos, y es sta quien resuelve
y procesa la totalidad de las instrucciones SQL agrupadas
en la mencionada funcin.
Ventajas:
Presenta las mismas ventajas de una arquitectura

dos planos con procedimientos almacenados, pero
mejora considerablemente el rendimiento sobre
sta, dado que reduce el trfico por la red al
procesar los datos en la misma base de datos,
haciendo viajar slo el resultado final de un
conjunto de instrucciones SQL.
Inconvenientes:
Si bien la complejidad de desarrollo se ve

disminuida, se pierde flexibilidad y escalabilidad en
las soluciones implantadas.
Obliga a basar el peso de la aplicacin en SQL
extendido, propios del proveedor de la base de datos que se elija. Debiera considerarse que s bien los
procedimientos almacenados (stored procedures), los desencadenantes (triggers) y las reglas (constraint)
son tiles, en rigor son ajenos al estndar de SQL
4.1.2. MODELO CLIENTE/SERVIDOR 3 CAPAS
Esta estructura se caracteriza por elaborar la aplicacin en base a dos capas principales de software, ms la capa
correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y segn las decisiones de
diseo que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso
correspondiente al servidor de aplicacin.
En este esquema el cliente enva mensajes directamente al servidor de aplicacin el cual debe administrar y
responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud, quien accede y se conecta con
la base de datos.
Ventajas:
Reduce el trfico de informacin en la red por lo

que mejora el rendimiento de los sistemas
(especialmente respecto a la estructura en dos
planos).
Brinda una mayor flexibilidad de desarrollo y de
eleccin de plataformas sobre la cual montar las
aplicaciones.
Provee escalabilidad horizontal y vertical.
Se mantiene la independencia entre el cdigo
de la aplicacin (reglas y conocimiento del
negocio) y los datos, mejorando la portabilidad
de las aplicaciones.
Los lenguajes sobre los cuales se desarrollan
las aplicaciones son estndares lo que hace
ms exportables las aplicaciones entre
plataformas.
Dado que mejora el rendimiento al optimizar el flujo de informacin entre componentes, permite construir
sistemas crticos de alta fiabilidad.
El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de distribuirlos en la
capa de interfaz de usuario, permite reducir el impacto de hacer mantenimiento, cambios urgentes de
ltima hora o mejoras al sistema.
Disminuye el nmero de usuarios (licencias) conectados a la base de datos.
Inconvenientes:
Dependiendo de la eleccin de los lenguajes de desarrollo, puede presentar mayor complejidad en

comparacin con Cliente/Servidor dos planos.
Existen pocos proveedores de herramientas integradas de desarrollo con relacin al modelo
Cliente/Servidor dos planos, y normalmente son de alto costo.
4.2. A NIVEL DE HARDWARE
Esta clasificacin del modelo Cliente/Servidor se basa igualmente en la distribucin de los procesos y elementos
entre sus componentes, pero centrndose en la parte fsica del mismo, en el que la administracin de la interfaz
grfica se asocia a los clientes PC y la seguridad e integridad de los datos quedan asociados a ambientes
mainframe o por lo menos a servidores locales y/o centrales.
4.2.1. MODELO CLIENTE / SERVIDOR 2 CAPAS
Como se ve en la figura, los clientes son conectados va LAN a un servidor de aplicaciones local, el cual,
dependiendo de la aplicacin puede dar acceso a los datos administrados por l.
4.2.2. MODELO CLIENTE / SERVIDOR 3 CAPAS
Como se ve en la figura, los clientes son conectados va LAN a un servidor de aplicaciones local, el cual a su vez
se comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento dual, dado que
acta como cliente o servidor en funcin de la direccin de la comunicacin.
5. VENTAJAS E INCONVENIENTES
5.1. VENTAJAS
Costes. El enfoque Cliente/Servidor es econmico, sobre todo cuando est unido al concepto de
racionalizacin. Los costes de compra, arrendamiento y mantenimiento de macrocomputadoras centrales
son tal elevados que los correspondientes a la compra de servidores, PCs y dems componentes para
crear una red de rea local parecen ridculos. Con frecuencia sucede que el coste de un sistema
Cliente/Servidor completo es inferior al de la instalacin de una computadora central para que pueda
procesar una nueva aplicacin.
Acceso a la informacin. Si bien el acceso a los datos es posible por otros medios, la arquitectura
Cliente/Servidor constituye el ambiente ideal para facilitar el acceso a la informacin. El usuario no slo
puede tener un acceso transparente a toda la informacin que necesita, sino adems puede procesarla
como prefiera.
Ergonoma. Un buen sistema Cliente/Servidor no se concibe sin una interfaz grfica de usuario y sin una
transparencia total. De esta manera, el cliente puede trabajar en el ambiente que ms le convenga sin
preocuparse de la conversin de interfaces y protocolos. Se concentra en el trabajo que debe realizar
ms que en la tecnologa.
Interoperabilidad de plataformas. En teora, un ambiente Cliente/Servidor puede estar formado de varias
plataformas, sistemas operativos, SGBD, etc. De ah que haya muchas opciones para cada aplicacin;
por ejemplo HP con UNIX y con estaciones de trabajo Macintosh para un servicio y un servidor Netware y
estaciones de trabajo Windows para otro.
Modularidad. En un ambiente Cliente/Servidor, es factible agregar o eliminar estaciones de trabajo y
servidores, puesto que el sistema puede ser ms o menos fcil de volverse a configurar.
5.2. INCONVENIENTES
Incompatibilidad. El ambiente Cliente/Servidor supone que la poca en que IBM tena todo el mercado
dominado ha concluido. Con el fin de esta etapa, se debe recurrir a varios proveedores. Todos sabemos
lo que sucede en estos casos: cuando hay algn problema, el proveedor inicial lo remite a otro proveedor.
Si las especificaciones se ponen por escrito, no hay problema; pero en la prctica cotidiana, las
incompatibilidades entre computadoras, sistemas operativos, lenguajes, protocolos, interfaces y
programas de aplicacin superan las expectativas.
Formacin. En casi todos los casos de implantacin del modelo Cliente/Servidor, la principal dificultad es
la formacin de los usuarios. No se trata de slo impartir cursos a los usuarios y a los ingenieros en
computacin, sino de cambiar toda una cultura, lo cual es ms complicado y costoso. Es necesario
redefinir todas las funciones computacionales; la polivalencia debe ubicarse en el primer plano. El coste
de una formacin a fondo puede ser superior a la del conjunto del sistema. Sin embargo, debemos
considerar que la formacin es una inversin a largo plazo.
Costes. Si bien el coste es uno de los principales factores que inclinan la balanza en favor de la
arquitectura Cliente/Servidor, los inconvenientes antes mencionados conducen a reflexionar sobre la
variedad de costes ocultos que conlleva: formacin, solucin de montones de pequeos problemas
imprevistos, el tiempo perdido en reconciliarse con lo proveedores, la reorganizacin y el desarrollo de
aplicaciones que an no se encuentran en el mercado...
La implantacin del modelo Cliente/Servidor comprende varios elementos. En primer lugar, se debe
contar con una arquitectura completa de telecomunicacin, es decir, no basta tener un protocolo de
comunicacin comn entre todos los sistemas llamados a cooperar, sino tambin se necesita toda una
serie de funciones o aplicaciones de telecomunicacin para retomar la terminologa del modelo OSI de
interconexin de sistemas abiertos. A sin prevista puede no parecer un inconveniente, pero desarrollar un
sistema que debe cumplir tantas caractersticas no es una tarea fcil.
6. CONCLUSIN
En este tema hemos repasado los principales aspectos de la arquitectura Cliente/Servidor, que es la plataforma
abierta por excelencia. Hemos visto cules son sus 3 componentes principales: cliente, middleware y servidor as
como la forma en que se lleva a cabo la comunicacin entre ellos.
Tambin se han descrito los modelos a 2 y 3 capas y se han enumerado las ventajas e inconvenientes ms
importantes de esta tecnologa.
7. BIBLIOGRAFA
John Wiley: Introduction to Client / Server Systems: A Practical Guide for Systems Professionals.
Tanenbaum, A.: Sistemas Distribuidos.
Morgan Kaufmann: Transaction Processing Concepts and Techniques.
Orfali, R., Harkey, D. y Edwards, J.: The Essential Client/Server Survival Guide.
OMG, The Common Object Request Broker Architecture and Specification, Object Management Group.
8. ESQUEMA RESUMEN
Como se ha comentado a lo largo de todo el tema, la principal caracterstica de la arquitectura Cliente/Servidor es
su gran adaptabilidad a cualquier tipo de entorno, as como sus mltiples posibilidades de implantacin.
Pero desafortunadamente estamos hablando de una caracterstica de doble filo, ya que hace falta un gran
dominio sobre el tema para saber el modelo y las pautas a seguir a la hora de implantar un sistema
Cliente/Servidor.
Todo sistema Cliente/Servidor est estructurado en tres bloques:
Cliente. Es todo aqul que requiere los servicios de otro (servidor).

Middleware. Es el conducto central de informacin entre cliente y servidor.
Servidor. Es aqul que lleva a cabo los servicios solicitados.
Para hacer posible la comunicacin entre cliente y servidor se utiliza un mecanismo intermedio llamado NOS:
Es el encargado de proporcionar una apariencia de sistema nico a un sistema Cliente/Servidor.

Se aloja tanto en el cliente como en el servidor.
Proporciona una transparencia total en lo referente a:
Localizacin y espacio.
Conexin.
Tiempo.
Fallos.
Protocolos
As mismo, el NOS ofrece dos servicios bsicos para la comunicacin:
Servicios de transporte:
Peer-to-Peer: Su principal caracterstica es que cualquier ordenador puede iniciar la conversacin.
Colas de mensajes, en la que el cliente no puede esperar la respuesta para continuar el proceso.
RPC. Tal vez uno de los ms extendidos en Internet. Es la esencia de cualquier servidor Web.
Servicios de Aplicacin:
De directorio global. Encargado de resolver la transparencia de ubicacin.
De tiempo. Sincroniza peridicamente cada ordenador de la red.
De seguridad. Se encarga de resolver la vulnerabilidad de los sistemas Cliente/Servidor.
Los sistemas basados en la tecnologa Cliente/Servidor se suelen clasificar en funcin de:
Tamao de los componentes:

Fat Client: Todo el peso de la aplicacin recae sobre el cliente. El servidor se limita a ejecutar el
servicio pedido.
Fat Server: Al contrario que el anterior, el peso lo lleva el proceso servidor. Utilizado especialmente
para desarrollar aplicaciones con transacciones.
Naturaleza del servicio.
Servidores de Ficheros. Encargado de ofrecer archivos, documentos, imgenes a los clientes que
lo soliciten
Servidores de Bases de Datos. Se ocupan de mantener la integridad de las bases de datos; y de
ofrecer a los clientes servicios como: bsquedas, actualizaciones
Servidores de Transacciones. Usados para la ejecucin remota de acciones crticas, tales como
transferencias bancarias, reserva de butacas en el cine
Servidores de Trabajo en Grupo. Se trata de agrupar los procesos que requieren colaboracin en
grupo en un nico proceso central.
Servidores de Objetos. Gracias a este tipo de servidores, las aplicaciones Cliente/Servidor son
escritas como objetos que se comunican entre s gracias a un intermediario denominado ORB. El
ORB ofrece los siguientes servicios:
Comunicacin entre objetos.
Persistencia.
Localizacin de componentes por su nombre, independientemente de dnde se encuentren
ubicados.
Sincronizacin entre componente.
Servidores Web. Los clientes hacen peticiones al servidor Web para que ste le devuelva la pgina
solicitada, y de este modo poder visualizarla en el ordenador cliente. Se utiliza el protocolo TCP.
La arquitectura Cliente/Servidor est basada en una serie de modelos, en funcin del nmero de capas en el que
est dividido. Normalmente hablamos de modelos a dos capas y a tres capas.
Modelo 2 capas. Existe una conexin directa entre el proceso cliente y el administrador de la base de
datos. A su vez se clasifica en:
SQL Remoto. Es el cliente el encargado de procesar toda la informacin devuelta por el servidor.
Procedimientos almacenados. El cliente solicita la ejecucin de un mtodo en el servidor, y es ste el
que se encarga de procesarlo y devolver nicamente la informacin requerida.
Modelo 3 capas. Su caracterstica ms relevante es que la comunicacin entre el cliente y el servidor de
Base de Datos, no se hace de forma directa; sino que existe un proceso intermedio llamado servidor de
aplicacin que es el que se ocupa de administrar y responder a todas las solicitudes de los clientes.
Los modelos de los que acabamos de hablar son modelos software, pero tambin existe otra clasificacin por
capas fijndonos en su arquitectura hardware:
Modelo 2 capas. Todos los clientes estn conectados a un servidor central, encargado de ofrecer los
servicios pedidos.
Modelo 3 capas. Los cliente se conectan a un servidor local y es ste el que est conectado directamente
con el servidor central.

TICB1 - Arquitecturas Cliente Servidor

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TICB1 - Arquitecturas Cliente Servidor

Transféré par

Droits d'auteur :

Formats disponibles

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

B1G1T06 - ARQUITECTURAS CLIENTE SERVIDOR.

1. INTRODUCCIN A LA ARQUITECTURA CLIENTE/SERVIDOR ........................................................................ 2

1. INTRODUCCIN A LA ARQUITECTURA CLIENTE/SERVIDOR

La problemtica Cliente/Servidor se puede agrupar bsicamente en dos aspectos:

1.1. DEFINICIN DE SISTEMA CLIENTE/SERVIDOR

La tecnologa Cliente/Servidor es el procesamiento cooperativo de la informacin por medio de un conjunto de

Un sistema Cliente/Servidor es un Sistema de Informacin distribuido basado en las siguientes caractersticas:

Escalabilidad horizontal (aadir clientes) y vertical (ampliar potencia de los servidores).

1.2. FUNCIONAMIENTO USUAL DE UN SISTEMA CLIENTE/SERVIDOR

Esquema de funcionamiento de un Sistema Cliente/Servidor

1) El cliente solicita una informacin al servidor.

2. COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

Nivel de Presentacin: Agrupa a todos los elementos asociados al componente Cliente.

2.1. ELEMENTOS PRINCIPALES

Administrar la interfaz de usuario.

Cliente basado en aplicacin de usuario.

Cliente basado en lgica de negocio.

Aceptar los requerimientos de bases de datos que hacen los clientes.

El middleware se estructura en tres niveles:

Especfico Servicio ODBC TxRPC Correo ORB HTTP

Las principales caractersticas de un middleware son:

Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios.

2.2. COMUNICACIN ENTRE LOS ELEMENTOS (NOS)

Como se ha comentado en el apartado anterior, el middleware es un conjunto de aplicaciones encargadas de

Para ello se estructura en tres capas diferentes:

Protocolo de transporte: comunes a otras aplicaciones.

El cliente realiza una llamada a un servicio como si fuera local.

El NOS debe proporcionar transparencia a los procesos Cliente/Servidor con respecto a:

2.2.1. ELEMENTOS DEL NOS

2.2.1.1. SERVICIOS DE TRANSPORTE

Comunicaciones Peer to Peer (P2P)

Workflow: envo de mensajes en cadena de aplicaciones.

1) La aplicacin genera un mensaje.

Remote Procedure Calls (RPC)

b) El CLient Stub compone un mensaje para el servidor (parameter marshalling) (2).

c) El mensaje se enva a travs de un protocolo de transporte (2, 3).

d) La entidad de transporte del servidor lo recibe y lo pasa al Server Stub (4).

e) El Server Stub recibe el mensaje y extrae de l la informacin que necesita (parameter

f) El Server Stub pasa la peticin a la rutina de servicio (5).

g) La contestacin del servidor sigue un proceso anlogo:

Respuesta del servidor (6).

Generacin del mensaje de respuesta (parameter marshalling) (7).

Comparacin de los modelos P2P - MOM - RPC

2.2.1.2. SERVICIOS DE APLICACIN

Servicios de directorio global:

Se utilizan varios mtodos de cifrado: cifradores de bloques, intercambio de claves, algoritmos de

3.1. POR TAMAO DE COMPONENTES

3.1.1. FAT CLIENT (THIN SERVER)

En este esquema de arquitectura el peso de la aplicacin es

En general este tipo de arquitectura tiene mejor aplicacin en

3.1.2. FAT SERVER (THIN CLIENT)

Este es el caso opuesto al anterior, el proceso cliente es restringido

En general este tipo de arquitectura presenta una flexibilidad mayor

3.2. POR NATURALEZA DE SERVICIO

3.2.1. SERVIDORES DE FICHEROS

3.2.2. SERVIDORES DE BASES DE DATOS

Obviamente la creacin de aplicaciones Cliente/Servidor est asociada a la utilizacin de servidores de bases de

Procedimientos almacenados (stored procedures): Una de las posibilidades de implementar de mejor

3.2.3. SERVIDORES DE TRANSACCIONES

Ready_to_Commit Ready_to_Commit Ready_to_Commit

Complete Complete Complete Commit

Two-Phase Commit (I)

Ready_to_Commit Refuse Ready_to_Commit