TICB1 - Arquitecturas Cliente Servidor

www.haztefuncionario.com

Material registrado. Prohibida su reproducción.

Copia exclusiva de José Ignacio Méndez Yanes. Av de los Poblados 133, 7º - 3ª - 28025 - Madrid - Tel. 917464968

B1G1T06 - ARQUITECTURAS CLIENTE SERVIDOR.

1.

INTRODUCCIÓN A LA ARQUITECTURA CLIENTE/SERVIDOR ........................................................................ 2 1.1. 1.2.

2.

DEFINICIÓN DE SISTEMA CLIENTE/SERVIDOR ................................................................................................. 2 FUNCIONAMIENTO USUAL DE UN SISTEMA CLIENTE/SERVIDOR ............................................................... 3

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. COMUNICACIÓN 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 APLICACIÓN ........................................................................................................................ 9

3.

TIPOLOGÍA..................................................................................................................................................................... 10 3.1. POR TAMAÑO 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. 5.2.

VENTAJAS................................................................................................................................................................ 19 INCONVENIENTES ................................................................................................................................................. 20

6.

CONCLUSIÓN ................................................................................................................................................................. 20

7.

BIBLIOGRAFÍA .............................................................................................................................................................. 21

8.

ESQUEMA – RESUMEN ................................................................................................................................................ 22

TEMARIO-TICB-feb04 Actualizado en febrero de 2004

B1G1T06 Página 1 de 23




1.

INTRODUCCIÓN 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 combinación implica que debemos tener en cuenta también una gran cantidad de elementos a considerar y evaluar en el momento de enfrentarnos a una solución informática basada en la arquitectura Cliente/Servidor. La problemática Cliente/Servidor se puede agrupar básicamente en dos aspectos: □

¿Qué plataforma elegir?

□

¿Qué herramientas de desarrollo elegir?

La primera pregunta tiene relación con la respuesta a cuestiones aún más específicas 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 computación distribuida se tendrá que montar la solución? El segundo aspecto tiene relación 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 tecnología es la flexibilidad en cuanto a que podemos elegir entre muchas opciones, esto mismo nos obliga a tener conocimientos importantes para la integración de las mismas, dado que el desarrollo de aplicaciones Cliente/Servidor requiere del manejo de elementos en el área de diseños de bases de datos, comunicación entre procesos, procesamiento de transacciones,… y para que hablar de Internet, con clientes y servidores distribuidos a lo largo de la Web.

1.1.

DEFINICIÓN DE SISTEMA CLIENTE/SERVIDOR

La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales. Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos. Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes características: □

Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.

□

Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos.

□

Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente.

□

Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar.

□

Independencia de la plataforma HW y SW que se emplee.

□

Sistemas débilmente acoplados. Interacción basada en envío de mensajes.

□

Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente.






□

Escalabilidad horizontal (añadir 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 múltiples comparten los servicios de un programa servidor común. Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores.

Esquema de funcionamiento de un Sistema Cliente/Servidor

1) 2) 3) 4) 5)

2.

El cliente solicita una información al servidor. El servidor recibe la petición del cliente. El servidor procesa dicha solicitud. El servidor envía el resultado obtenido al cliente. El cliente recibe el resultado y lo procesa.

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. Además esta relación está establecida en función del intercambio de mensajes que es el único elemento de acoplamiento entre ambos. De estas líneas 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 diálogo, 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 más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma: □

Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.

□

Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.

□

Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación 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 descomposición en niveles, como se verá más adelante, permite introducir más claramente la discusión 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 definición un poco más elaborada podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor. Se lo conoce con el término front-end. Éste normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además 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 lógica de la aplicación 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 aplicación (flujo de información o lógica de negocio). De este modo el cliente se puede clasificar en:

Cliente basado en aplicación de usuario.

Cliente basado en lógica de negocio.






□

Cliente basado en aplicación de usuario. Si los datos son de baja interacción y están fuertemente relacionados con la actividad de los usuarios de esos clientes.

□

Cliente basado en lógica de negocio. Toma datos suministrados por el usuario y/o la base de datos y efectúa los cálculos necesarios según 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 múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las principales funciones que lleva a cabo el proceso servidor se enumeran a continuación: □

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 lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Puede darse el caso que un servidor actúe 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 clasificación se hablará en el apartado 3 (Tipología) del tema. Ambigüedad: 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 módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con varias fuentes de información 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 utilización del middleware permite desarrollar aplicaciones en arquitectura Cliente/Servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo. Los primeros monitores de teleproceso de los grandes sistemas basados en tecnología Cliente/Servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos cuando el concepto de middleware toma su máxima importancia. El middleware se estructura en tres niveles: □

Protocolo de transporte.

□

Network Operating System (NOS).

□

Protocolo específico del servicio.






Específico Servicio

ODBC

NOS Transporte

TxRPC

Directorio RPC NetBios

Correo

Seguridad Mensajes TCP/IP

ORB

HTTP

Tiempo Peer-to-Peer

IPX/SPX

SNA

Las principales características de un middleware son: □

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

□

Permite la interconectividad de los Sistemas de Información del Organismo.

□

Proporciona mayor control del negocio al poder contar con información procedente de distintas plataformas sobre el mismo soporte.

□

Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.

Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria para que puedan funcionar.

2.2.

COMUNICACIÓN 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 específico 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 comunicación 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 extensión 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 contestación.






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

Localización: Los recursos sólo 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.

□

Conexión: Un único usuario y contraseña para todo el sistema.

□

Replicación: 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 detección de fallos, redundancia y reconexión tras un fallo.

□

Administración: Un único sistema de gestión de todos los recursos.

□

Protocolos: Idéntica interfaz de programación 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 conversación.

à

Protocolo simétrico.

à

Inicialmente específicos 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 asíncrono. à

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: envío de mensajes en cadena de aplicaciones. 1) 2) 3) 4)

La aplicación genera un mensaje. Lo pone en una cola, y sigue procesando. La aplicación destino lo extrae de la cola cuando pueda procesarlo. La respuesta sigue el mismo procedimiento.






□

Remote Procedure Calls (RPC) à

La ejecución del servicio en el cliente se realiza del mismo modo que una llamada a una función local.

à

Existen varios tipos de problemas de transparencia:

Paso de parámetros: No es posible pasar parámetros por referencia.

Semántica 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 número de veces; y las no idempotentes son las que el resultado varía con el número de veces que se ejecutan.

Representación de los distintos tipos de datos: Se hace necesario un método de representación de datos independiente del sistema.

Rendimiento de las llamadas.

Seguridad.

CLIENTE

SERVIDOR 1

Aplicación Cliente

Client Stub

10

Server Stub

Mensaje

9

4

2 Entidad de Transporte

5 6

Aplicación Servidor

7

Entidad de Transporte

3

Mensaje

RED 8

a) El cliente llama a una función con una serie de parámetros (Client Stub) (1). b) El CLient Stub compone un mensaje para el servidor (parameter marshalling) (2). c) El mensaje se envía a través 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 información que necesita (parameter unmarshalling) (5). f) El Server Stub pasa la petición a la rutina de servicio (5). g) La contestación del servidor sigue un proceso análogo:

Respuesta del servidor (6).






Generación del mensaje de respuesta (parameter marshalling) (7).

Envío del mensaje a través del protocolo de transporte (8).

Descomposición del mensaje en el Client Stub (parameter unmurshalling) (9).

Entrega de la respuesta de la función al cliente (10).

El cliente permanece a la espera de la respuesta bloqueado en la llamada a la rutina.

Características

Peer to Peer

Message Oriented Middleware

Remote Procedure Calls

Modelo

Conversación normal

Llamada telefónica.

Temporización

Síncrona.

Correo. Asíncrona. Clientes y servidores pueden trabajar a distintas velocidades.

Secuencia de Arranque sistema Estilo Extremos listos Simultáneamente Filtrado de mensajes Rendimiento Proceso asíncrono

Las dos partes de la “conversación” deben estar disponibles. Llamada / respuesta.

Síncrona. Trabajo concurrente.

Mensajes encolados.

Los servidores deben estar disponibles antes que comiencen los clientes. Llamada / respuesta.

Sí.

No.

Sí.

No posible. Alto. Comunicación directa sin intermediarios. Limitado. Mediante el uso de procesos e hilos.

Posible. Bajo. Requiere intermedio.

No fija.

almacenamiento

Sí.

No posible. Alto. Comunicación directa sin intermediarios. Limitado. Requiere creación de tareas y sincronización entre procesos.

Comparación de los modelos P2P - MOM - RPC

2.2.1.2. SERVICIOS DE APLICACIÓN Cabe destacar, entre los servicios de aplicación del soporte de comunicaciones de un sistema Cliente/Servidor, los siguientes: □

□

□

Servicios de directorio global: à

Refleja la composición del sistema Cliente/Servidor en todo momento.

à

Encargado de resolver la transparencia de ubicación.

à

Se puede implementar como estructura plana o jerárquica.

à

Cada entrada contiene todos los datos asociados al elemento: dirección, 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 información de tiempo (timestamp) de todos los componentes de un sistema Cliente/Servidor.

à

Sincronizan periódicamente 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 desviación es mayor que un umbral determinado.

à

Uno o más servidores deben estar conectados a un proveedor externo de información 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 transmisión de datos en la red.






à

3.

Se utilizan varios métodos de cifrado: cifradores de bloques, intercambio de claves, algoritmos de clave pública, autentificación de usuarios, firma digital, certificados…

TIPOLOGÍA

Uno de los aspectos claves para entender la tecnología 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. Más allá de entender los componentes cliente/middleware/servidor, es preciso analizar ciertas relaciones entre éstos, que pueden definir el tipo de solución que se ajusta de mejor forma a las estadísticas y restricciones acerca de los eventos y requerimientos de información que se obtuvieron en la etapa de análisis 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 configuración, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la información, tiempo de respuesta, tamaños de registros, tamaño de bases de datos, estimaciones del tráfico de red, distribución geográfica tanto de los procesos como de los datos, etc. En tal sentido se presenta, en primer lugar, un esquema de clasificación basado en los conceptos de Fat Client/Thin Client, Fat Server/Thin Server, es decir, basado en el tamaño de los componentes. En segundo lugar tenemos una clasificación según la naturaleza del servicio que nos ofrecen.

3.1.

POR TAMAÑO DE COMPONENTES

Este tipo de clasificación se basa en los grados de libertad que brinda el modelo Cliente/Servidor para balancear la carga de proceso entre los niveles de presentación, aplicación 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 número de restricciones impuestas por una problemática a resolver.

3.1.1.

FAT CLIENT (THIN SERVER)

En este esquema de arquitectura el peso de la aplicación es ejecutada en el cliente, es decir, el nivel de presentación y el nivel de aplicación 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 aplicación en sistemas de apoyo de decisiones (DSS: Decision Support System) y sistemas de información ejecutiva (EIS: Executive Information System), y como se concluirá más adelante, tiene pocas posibilidades de aplicarse en sistemas de misión crítica.

3.1.2. FAT SERVER (THIN CLIENT) Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la interfaz de usuario, mientras que el peso de la aplicación corre por el lado del servidor de aplicación. En general este tipo de arquitectura presenta una flexibilidad mayor para desarrollar una gran variedad de aplicaciones, incluyendo los sistemas de misión crítica a través 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, imágenes y archivos grandes sobre la red.

3.2.2. SERVIDORES DE BASES DE DATOS Este análisis 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 creación de aplicaciones Cliente/Servidor está asociada a la utilización 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. Según las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso compartido a los datos con los mecanismos de protección necesarios, así como proveer mecanismos para seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro en procesos de comunicación. El servidor debe también proveer mecanismos de concurrencia, seguridad y consistencia de datos, basado principalmente en el concepto de transacción en el que todo se realiza, y por lo tanto se hace permanente, o todo falla, anulándose la transacción en tal caso. Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones propias de cada proveedor. Por ejemplo casi todas las bases de datos están 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 través de procedimientos almacenados, que son funciones que agrupan un conjunto de instrucciones y lógica 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 lógica de una aplicación Cliente/Servidor, es decir vendría a reemplazar al servidor de aplicaciones en una arquitectura tres planos (three-tier).

□

Desencadenantes (triggers): Son mecanismos que permiten realizar acciones automáticamente sobre los datos, las cuales están asociadas a algún evento definido. Normalmente son implementados a través de procedimientos almacenados. Los eventos a los cuales se hace referencia están asociados a las actualizaciones de tablas mediante sentencias delete, insert o update, y son llamados implícitamente al suceder cualquiera de estos eventos, a diferencia de los procedimientos almacenados que son llamados explícitamente por un proceso cliente.

□

Restricciones (constraints): Al igual que los desencadenantes, son acciones que se realizan asociadas a algún evento determinado y están orientadas a llevar a cabo validaciones más 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 transacción.






Con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos 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 través de la red se realiza mediante un único mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad lógica llamada transacción; evitando así el intercambio a través 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 través de SQL remoto. Estas aplicaciones denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los procedimientos y reglas de los sistemas de misión crítica. En la actualidad muchas aplicaciones tienen la necesidad de ser desarrolladas con la ayuda de transacciones, véase el ejemplo de los cajeros automáticos: imaginemos que queremos sacar dinero. Introducimos la cantidad adecuada y pulsamos el botón 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 volvería a realizar la petición, por lo que el banco volvería a descontar dicha cantidad de la cuenta bancaria asociada. Este problema tan común 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 comunicación más 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 envía prepare to commit a todos los nodos subordinados.

Devuelven al nodo gestor ready to commit.

Fase 2:

El nodo gestor envía commit a todos los nodos subordinados.






□

Los nodos subordinados finalizan la transacción y devuelven al nodo gestor complete.

Caso 2: Algún sistema no puede finalizar la transacción. à

Fase 1:

à

El nodo que no puede realizar correctamente la transacción contesta refuse al prepare_to_commit del nodo gestor.

Fase 2:

El nodo gestor envía rollback a todos los nodos subordinados.

Los nodos subordinados deshacen la transacción y devuelven al nodo gestor complete.

La parte central de cualquier servidor de transacciones es el TP Manager. El núcleo del TP consta de diferentes partes: □

□

□

□

Gestor de transacciones (Transaction Manager): à

Arranque de la transacción.

à

Registro de Gestores de Recursos que participan.

à

Gestión Commit/Rollback.

RPCs transaccionales: à

Permiten garantizar la integridad de la transacción cuando no se ejecuta en un solo ordenador.

à

RPCs con un identificador de transacción asociado, asignado por el TM.

Gestor de registro de modificaciones (Log Manager). à

Graba los cambios realizados por los Gestores de Recursos.

à

Permite reconstruir una versión consistente de todos los recursos.

Gestor de bloqueos (Lock Manager) à

Proporciona mecanismos para regular el acceso concurrente a lso recursos.

Esquema de comunicación mediante transacciones






3.2.4. SERVIDORES DE TRABAJO EN GRUPO Este tipo de sistema Cliente/Servidor es difícil de definir. Se trata de un conjunto de tecnologías encaminadas a representar procesos complejos relacionados con actividades que requieren colaboración. Groupware direcciona la administración de información semi-estructurada como texto, imágenes, 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 gráficas. Típicamente el middleware de comunicaciones entre clientes y servidores es específico de cada vendedor, aunque muchos productos groupware usan el e-mail como su estándar para el paso de mensajes. Internet se está volviendo la plataforma middleware para estas aplicaciones. Existen en torno a cinco tecnologías básicas: □

□

□

Heredados de los sistemas de gestión de imágenes: à

MDM: Multimedia Document Management.

à

Control de flujo de trabajo, Workflow.

Heredados de los sistemas de automatización de oficinas: à

Correo electrónico.

à

Planificación.

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 método de un objeto remoto. El ORB localiza el método 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 comunicación en los servidores de objetos es el ORB: □

Elemento central y principal de esta arquitectura.

□

Bus de objetos. Permite la comuniación entre ellos.

□

Middleware avanzado:






à

Permite llamadas estáticas y dinámicas a objetos.

à

Lenguaje de descripción de interfaces independiente del lenguaje de programación.

à

Sistema autodescrito. Genera meta-información sobre todo el sistema.

à

Transparencia de localización.

à

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. Localización de componentes por nombre.

□

Eventos. Permite a los componentes registrar su interés en eventos específicos.

□

Control de concurrencia. Gestos de bloqueos para garantizar la exclusividad de acceso a los recursos.

□

Relaciones. Permite crear dinámicamente asociaciones o enlaces entre componentes.

□

Tiempo. Permite sincronización entre componentes y disparo de alarmas temporales.

□

Seguridad…

3.2.6. SERVIDORES DE WEB La primera aplicación 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 parámetros son pasados como cadenas y no provee tipos de datos. La Web y los objetos distribuidos están comenzando a crear un conjunto muy interactivo de computación 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 petición http y la envía al servidor Web solicitado (2).

□

El servidor recibe la petición y envía la página solicitada (3)

□

4.

à

Una sesión TCP por cada solicitud.

à

La página se codifica utilizando HTML.

El cliente (navegador) visualiza la página recibida (4, 4a) à

Puede tener asociados nuevos elementos en su interior (4b).

à

Nueva solicitud a los servidores que los contienen para su recuperación (se realiza una nueva sesión TCP) (4b).

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 variación sobre la división o clasificación por tamaño de componentes. Esto se debe a que se trata de definir el modo en que las prestaciones funcionales de la aplicación serán asignadas, y en qué proporción, tanto al cliente como al servidor. Dichas prestaciones se deben agrupar entre los tres componentes clásicos para Cliente/Servidor: interfaz de usuario, lógica de negocios y los datos compartidos, cada uno de los cuales corresponde a un plano. Ni que decir tiene que la mala elección de uno u otro modelo puede llegar a tener consecuencias fatales. Dentro de esta categoría tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier) y multi-planos (multi-tier). Dado que este término ha sido sobrecargado de significados por cuanto se lo utiliza indistintamente para referirse tanto a aspectos lógicos (Software) como físicos (Hardware), aquí se esquematizan ambas acepciones.

4.1.

A NIVEL DE SOFTWARE

Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques modernos, dado que se fundamenta en los componentes lógicos de la estructura Cliente/Servidor y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física sobre la cual pueden operar uno o más servidores de aplicaciones.

4.1.1. MODELO CLIENTE/SERVIDOR 2 CAPAS Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:

4.1.1.1. IMPLEMENTADO CON SQL REMOTO En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el resultado de cada instrucción 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, según 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 gestión, pero resultan inadecuados para los sistemas críticos 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 más simple respecto al Cliente/Servidor en tres planos, puesto que reduce una capa de programación, como se verá más adelante).

Inconvenientes: □

La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.

□

Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a la construcción de sistemas no críticos.

4.1.1.2. IMPLEMENTADO CON PROCEDIMIENTOS ALMACENADOS En este esquema el cliente envía 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 función. Ventajas: □

Presenta las mismas ventajas de una arquitectura dos planos con procedimientos almacenados, pero mejora considerablemente el rendimiento sobre ésta, dado que reduce el tráfico por la red al procesar los datos en la misma base de datos, haciendo viajar sólo 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 aplicación 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 estándar de SQL

4.1.2. MODELO CLIENTE/SERVIDOR 3 CAPAS Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de software, más la capa correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y según las decisiones de






diseño que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de aplicación. En este esquema el cliente envía mensajes directamente al servidor de aplicación 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 tráfico de información 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 elección de plataformas sobre la cual montar las aplicaciones.

□

Provee escalabilidad horizontal y vertical.

□

Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones.

□

Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace más exportables las aplicaciones entre plataformas.

□

Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos 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 número de usuarios (licencias) conectados a la base de datos.

Inconvenientes:

4.2.

□

Dependiendo de la elección de los lenguajes de desarrollo, puede presentar mayor complejidad en comparación con Cliente/Servidor dos planos.

□

Existen pocos proveedores de herramientas integradas de desarrollo con relación al modelo Cliente/Servidor dos planos, y normalmente son de alto costo.

A NIVEL DE HARDWARE

Esta clasificación del modelo Cliente/Servidor se basa igualmente en la distribución de los procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el que la administración de la interfaz gráfica 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 vía LAN a un servidor de aplicaciones local, el cual, dependiendo de la aplicación 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 vía 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 actúa como cliente o servidor en función de la dirección de la comunicación.

5.

VENTAJAS E INCONVENIENTES

5.1.

VENTAJAS □

Costes. El enfoque Cliente/Servidor es económico, sobre todo cuando está unido al concepto de racionalización. Los costes de compra, arrendamiento y mantenimiento de macrocomputadoras centrales son tal elevados que los correspondientes a la compra de servidores, PCs y demás componentes para crear una red de área local parecen ridículos. Con frecuencia sucede que el coste de un sistema Cliente/Servidor completo es inferior al de la instalación de una computadora central para que pueda procesar una nueva aplicación.






□

Acceso a la información. 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 información. El usuario no sólo puede tener un acceso transparente a toda la información que necesita, sino además puede procesarla como prefiera.

□

Ergonomía. Un buen sistema Cliente/Servidor no se concibe sin una interfaz gráfica de usuario y sin una transparencia total. De esta manera, el cliente puede trabajar en el ambiente que más le convenga sin preocuparse de la conversión de interfaces y protocolos. Se concentra en el trabajo que debe realizar más que en la tecnología.

□

Interoperabilidad de plataformas. En teoría, un ambiente Cliente/Servidor puede estar formado de varias plataformas, sistemas operativos, SGBD, etc. De ahí que haya muchas opciones para cada aplicación; 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 más o menos fácil de volverse a configurar.

5.2.

6.

INCONVENIENTES □

Incompatibilidad. El ambiente Cliente/Servidor supone que la época en que IBM tenía 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 algún problema, el proveedor inicial lo remite a otro proveedor.

□

Si las especificaciones se ponen por escrito, no hay problema; pero en la práctica cotidiana, las incompatibilidades entre computadoras, sistemas operativos, lenguajes, protocolos, interfaces y programas de aplicación superan las expectativas.

□

Formación. En casi todos los casos de implantación del modelo Cliente/Servidor, la principal dificultad es la formación de los usuarios. No se trata de sólo impartir cursos a los usuarios y a los ingenieros en computación, sino de cambiar toda una cultura, lo cual es más complicado y costoso. Es necesario redefinir todas las funciones computacionales; la polivalencia debe ubicarse en el primer plano. El coste de una formación a fondo puede ser superior a la del conjunto del sistema. Sin embargo, debemos considerar que la formación es una inversión 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: formación, solución de montones de pequeños problemas imprevistos, el tiempo perdido en reconciliarse con lo proveedores, la reorganización y el desarrollo de aplicaciones que aún no se encuentran en el mercado...

□

La implantación del modelo Cliente/Servidor comprende varios elementos. En primer lugar, se debe contar con una arquitectura completa de telecomunicación, es decir, no basta tener un protocolo de comunicación común entre todos los sistemas llamados a cooperar, sino también se necesita toda una serie de funciones o aplicaciones de telecomunicación para retomar la terminología del modelo OSI de interconexión de sistemas abiertos. A sin prevista puede no parecer un inconveniente, pero desarrollar un sistema que debe cumplir tantas características no es una tarea fácil.

CONCLUSIÓN

En este tema hemos repasado los principales aspectos de la arquitectura Cliente/Servidor, que es la plataforma abierta por excelencia. Hemos visto cuáles son sus 3 componentes principales: cliente, middleware y servidor así como la forma en que se lleva a cabo la comunicación entre ellos. También se han descrito los modelos a 2 y 3 capas y se han enumerado las ventajas e inconvenientes más importantes de esta tecnología.






7.

BIBLIOGRAFÍA □

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 característica de la arquitectura Cliente/Servidor es su gran adaptabilidad a cualquier tipo de entorno, así como sus múltiples posibilidades de implantación. Pero desafortunadamente estamos hablando de una característica 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 aquél que requiere los servicios de otro (servidor).

□

Middleware. Es el conducto central de información entre cliente y servidor.

□

Servidor. Es aquél que lleva a cabo los servicios solicitados.

Para hacer posible la comunicación 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: à

Localización y espacio.

à

Conexión.

à

Tiempo.

à

Fallos.

à

Protocolos…

Así mismo, el NOS ofrece dos servicios básicos para la comunicación: □

□

Servicios de transporte: à

Peer-to-Peer: Su principal característica es que cualquier ordenador puede iniciar la conversación.

à

Colas de mensajes, en la que el cliente no puede esperar la respuesta para continuar el proceso.

à

RPC. Tal vez uno de los más extendidos en Internet. Es la esencia de cualquier servidor Web.

Servicios de Aplicación: à

De directorio global. Encargado de resolver la transparencia de ubicación.

à

De tiempo. Sincroniza periódicamente cada ordenador de la red.

à

De seguridad. Se encarga de resolver la vulnerabilidad de los sistemas Cliente/Servidor.

Los sistemas basados en la tecnología Cliente/Servidor se suelen clasificar en función de: □

□

Tamaño de los componentes: à

Fat Client: Todo el peso de la aplicación 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, imágenes… 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: búsquedas, actualizaciones…

à

Servidores de Transacciones. Usados para la ejecución remota de acciones críticas, tales como transferencias bancarias, reserva de butacas en el cine…

à

Servidores de Trabajo en Grupo. Se trata de agrupar los procesos que requieren colaboración 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:

à

Comunicación entre objetos.

Persistencia.

Localización de componentes por su nombre, independientemente de dónde se encuentren ubicados.

Sincronización entre componente.

Servidores Web. Los clientes hacen peticiones al servidor Web para que éste le devuelva la página 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 función del número de capas en el que esté dividido. Normalmente hablamos de modelos a dos capas y a tres capas. □

□

Modelo 2 capas. Existe una conexión 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 información devuelta por el servidor.

à

Procedimientos almacenados. El cliente solicita la ejecución de un método en el servidor, y es éste el que se encarga de procesarlo y devolver únicamente la información requerida.

Modelo 3 capas. Su característica más relevante es que la comunicación 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 aplicación 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 también existe otra clasificación por capas fijándonos en su arquitectura “hardware”: □

Modelo 2 capas. Todos los clientes están 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

Recommend Documents