Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
Taller 4 - Teleinformatica
1. TALLER EN CLASE 4
TELEINFORMATICA
PRESENTADO POR:
CRISTIAN VILLAMIZAR
PRESENTADO A :
ING. YANETH CARDENAS GALVIS
CORPORACIÓN UNIVERSITARIA
REMINGTON
CUCUTA
2013
2. TALLER Nro. 4
INTRODUCCION
Para aclarar la idea y consolidar un concepto básico sobre la arquitectura
cliente servidor se presenta a continuación la información sobre este
tema, manejando el concepto sobre en que se basa la idea de cliente
servidor su forma de distribuirse, los diferentes estilos, aplicaciones
ventajas y desventajas de estas aplicaciones, en si visto desde una manera
muy coloquial y nada complicada con términos técnicos sencillos de
entender. Manejando además el termino y concepto sobre Middleware,
software distribuido necesario para el soporte de interacciones entre
Clientes y Servidores
La arquitectura cliente servidor termina siendo una herramienta muy útil
al momento de aprovechar al máximo el compartir de los recursos lógicos
y físicos que componen el montaje de una red, ya sea para el objetivo que
sea montada la idea es aprovechar y distribuir la información dejándola al
alcance de todos los usuarios autorizados.
3. OBEJTIVOS
GENERAL
Conceptualizar términos y definiciones con relación a la
Arquitectura Cliente Servidor.
ESPECIFICOS
Manejar concepto básico sobre Arquitectura Cliente Servidor
Definir estilos de modelos Cliente Servidor
Definir que es Middleware y los tipos en los que se distribuye
4. Defina el concepto de arquitectura cliente- servidor.
La arquitectura cliente-servidor es un modelo de aplicación distribuida en el
que las tareas se reparten entre los proveedores de recursos o servicios,
llamados servidores, y los demandantes, llamados clientes. Un cliente
realiza peticiones a otro programa, el servidor, quien le da respuesta.
Esta idea también se puede aplicar a programas que se ejecutan sobre una
sola computadora, aunque es más ventajosa en un sistema operativo
multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los
clientes y los servidores, aunque son más importantes las ventajas de tipo
organizativo debidas a la centralización de la gestión de la información y la
separación de responsabilidades, lo que facilita y clarifica el diseño del
sistema.
5. Estilos del modelo cliente servidor (con sus respectivas ventajas y
desventajas).
Aplicaciones mono-capa
Entendemos por aplicaciones mono-capa, aquellas que tanto la
propia aplicación como los datos que maneja se encuentran en la
misma máquina y son administradas por la misma herramienta:
podríamos decir que son una sola entidad
Figura 1. Arquitectura Típica de una aplicación
de una sola capa.
6. Modelo En Dos Capas (Two-Tier Model)
En una arquitectura cliente/servidor clásica tenemos dos "capas" (two-tier):
Una donde está el cliente que implementa la interface. Otra donde se encuentra
el gestor de bases de datos que trata las peticiones recibidas desde el cliente.
La lógica de la aplicación se encuentra por tanto repartida entre el cliente y
servidor. Un ejemplo de esta configuración podría ser un applet Java que se
carga en el navegador del cliente y trabaja directamente con la base de datos
mediante JDBC.
Figura A: Esquema de arquitectura Cliente/Servidor clásica.
7. Ventajas de este modelo:
Se mantiene una conexión persistente con la base de datos.
Se minimizan las peticiones en el servidor trasladándose la mayor parte del trabajo al
cliente.
Se gana en rendimiento gracias a la conexión directa y permanente con la base de
datos. A través de una única conexión se realiza el envío y recepción de varios datos.
Inconvenientes:
La más importante desventaja, es que esta solución es muy dependiente del tipo
controlador JDBC que se utilice para acceder a la base de datos. El acceso se realiza
desde el cliente y esto significa que es él el que tiene que tener instalado en su
sistema los controladores necesarios para que se produzca la comunicación con la
base de datos.
8. Además hay que tener en cuenta que el modelo de seguridad de Java impide que
desde un applet sin validar (lo que se conoce como untrusted applet), como lo son la
mayoría de los que se ejecutan en un navegador, se puedan realizar las siguientes
operaciones:
El acceso general, y por supesto mediante JDBC, a bases de datos situadas en
direcciones URL distintas a las que procede el mismo applet.
La configuración de recursos locales como, por ejemplo, la información de la fuente
de datos ODBC para usar el puente JDBC-ODBC.
La descarga de clases nativas, es decir, aquellas cuyo nombre empieza por Java. Esta
restricción afecta directamente a los navegadores que utilizan JDK 1.0.2 o anterior,
pues JDBC es posterior a esta versión, de forma que las clases apropiadas no
estarán instaladas localmente ni podrán ser descargadas de Internet por el applet.
Finalmente debemos tener en cuenta que es bien conocido que los programas Java
pueden ser descompilados muy fácilmente con lo que introducir el acceso a
nuestras bases de datos mediante un applet Java conlleva un riesgo considerable
en cuanto a la seguridad.
9. Modelo en Tres Capas (Three-Tier Model)
Con la arquitectura cliente/servidor en tres capas (three-tier) añadimos una nueva
capa entre el cliente y el servidor donde se implementa la lógica de la aplicación. De
esta forma el cliente es básicamente una interface, que no tiene por qué cambiar si
cambian las especificaciones de la base de datos o de la aplicación; queda aislado
completamente del acceso a los datos. Así un applet de Java se carga en el navegador
del cliente y se comunica con un servlet que corre en la máquina servidor; o bien
accedemos a la base de datos a través de un formulario HTML. El servlet establece una
conexión a la base de datos mediante JDBC.
En este caso se tiene total libertad para escoger dónde se coloca la lógica de la
aplicación: en el cliente, en el servidor de base de datos, o en otro(s) servidor(es).
También se tiene total libertad para la elección del lenguaje a utilizar.
Se utiliza un lenguaje de tipo general (probablemente C) por lo que no existen
restricciones de funcionalidad.
Los programas serán óptimos desde el punto de vista de la performance. También
deberá implementarse especialmente el Call remoto, lo que seguramente se hará de
una forma más libre que los Remote Procedure Call actualmente disponibles.
10. No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las
aplicaciones serán totalmente portables sin cambio alguno.
Puede determinarse en qué servidor(es) se quiere hacer funcionar estos
procedimientos. En aplicaciones críticas se pueden agregar tantos servidores de
aplicación como sean necesarios, de forma simple, y sin comprometer en absoluto la
integridad de la base de datos, obteniéndose una escalabilidad muy grande sin
necesidad de tocar el servidor de dicha base de datos.
El problema de esta arquitectura es ¿cómo se implementa? Parece ilusorio tratar de
programar manualmente estos procedimientos, mientras que, si se dispone de una
herramienta que lo hace automáticamente, presenta ventajas claras sobre la
alternativa anterior:
Figura B: Arquitectura Cliente/Servidor en tres capas (three-tier)
11. Como se podría esperar cada uno de los componentes de la aplicación en una
arquitectura three-tier se separa en una sola entidad. Esto te permite
implementar componentes de una manera más flexible. Algo que no creo que
sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.
Figura 4. Arquitectura Three-Tier.
12. En esta Arquitectura todas las peticiones de los clientes se controlan en la capa
correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una
petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es
bastante importante pues eso quiere decir que:
1.- El cliente no tiene que tener drivers ODBCni la problemática consiguiente de
instalación de los drivers por tanto se reduce el costo de mantener las
aplicaciones cliente
2.- El Cliente y el Gestor de Reglas de negocio tienen que hablar el mismo
lenguaje (en nuestro caso COM)
3.- El Gestor de Reglas de Negocio y el Servidor de Datos tienen que hablar el
mismo lenguaje (en nuestro caso ODBC)
13. Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros
estándares como DBLib, OLI, DRDA, SQL/API y X/Open
No existe ningún problema con respecto al tipo de controlador JDBC utilizado para
acceder a la base de datos. Todos los recursos necesarios para establecer la conexión
con la base de datos se encuentran en el servidor y por tanto, el cliente no necesita
instalar nada adicional en su máquina para poder acceder a la base de datos.
Esta arquitectura proporciona considerables mejoras desde el punto de vista de la
portabilidad de la aplicación, escalabilidad, robustez y reutilización del código.
Asimismo facilita las tareas de migración o cambios en el sistema gestor de la base
de datos.
Desaparecen las restricciones debidas a las limitaciones de los applets impuestas por
el modelo de seguridad de Java.
Inconvenientes:
Esta solución es algo menos eficiente que la del modelo de dos capas, ya que hemos
añadido una capa intermedia más de software.
14. Arquitectura de N Tier
Windows DNA distribuye una aplicación entre varias capas llamadas niveles.
Aunque los niveles algunas veces residen físicamente en máquinas diferentes,
Windows® DNA enfatiza la distribución lógica. Mientras que los nombres de estos
niveles difieren de acuerdo a la fuente, la Guía del Desarrollador de BackOffice®
(BackOffice® Developer's Guide, BDG) se refiere a ellos como sigue:
Servicios de usuario.
Servicios de negocios.
Servicios de datos.
15. Este diagrama muestra como varias aplicaciones y tecnologías de Microsoft son
implementadas en la arquitectura N niveles. Al leer la BDG, Usted verá como estos
niveles trabajan juntos para proporcionar la funcionalidad, estabilidad y
escalabilidad que las aplicaciones empresariales requieren. Como lo indica el
diagrama, Windows DNA sintetiza en las aplicaciones un conjunto común de
servicios, incluyendo HTML y HTML dinámico (DHTML), controles ActiveX®,
componentes del Modelo de Objeto Componente (COM), scripts en el lado cliente y
en el lado servidor, transacciones, seguridad y servicios de directorio, acceso a datos
y a bases de datos, administración de sistemas y ambientes de creación de
componentes. Estos servicios son expuestos de manera unificada a través del COM,
el cual permite que las aplicaciones inter-operen y compartan componentes.
Las principales ventajas del desarrollo en N niveles son respecto a la escalabilidad.
Las aplicaciones que procesan su lógica de negocios, ya sea en las máquinas cliente o
en las bases de datos, se vuelven lentas cuando están siendo muy utilizadas. Esto se
ha convertido en algo muy importante en esta era donde las aplicaciones de Web
pueden ser utilizadas millones de veces por día. La transición para el desarrollo N
niveles no es gratis, el tiempo de desarrollo se incrementó debido a la complejidad
de añadir otro nivel. Afortunadamente, el middleware, tal como el MTS, fue
desarrollado para manejar automáticamente los detalles de la infraestructura de
aplicación, tal como el manejo de procesos alternos y los detalles de COM.
16. Defina que es Middleware y los tipos en los que se distribuye.
Es un término que abarca a todo el software distribuido necesario para el soporte
de interacciones entre Clientes y Servidores". Es el enlace que permite que un
cliente obtenga un servicio de un servidor.
Este se inicia en el módulo de API de la parte del cliente que se emplea para
invocar un servicio real; esto pertenece a los dominios del servidor. Tampoco a la
interfaz del usuario ni la a la lógica de la aplicación en los dominios del cliente.
TIPOS:
La clasificación por aplicación incluye los middleware que son ajustados para
aplicaciones específicas.
17. Middleware para acceso a información (DAM, Data Access middleware)
Los middleware para acceso a información tienen la característica de poder
interactuar con diversas fuentes de datos. En este tipo de middleware se encuentran
los que procesan transacciones, gateways de bases de datos y sistemas distribuidos
de transacción/procedimiento. Sus ventajas residen en la comunicación que tienen
entre múltiples fuentes de datos, la conversión del lenguaje de programación de la
aplicación a un lenguaje aceptado por la fuente de datos de destino y la capacidad
de respuesta en un formato y lenguaje aceptable para el solicitante.
Middleware de escritorio
Los middleware de escritorio pueden hacer variaciones en la presentación de la
información pedida por el usuario por aplicaciones de rastreo y asistencia, controlar
cualquier servicio de transporte y proveer una copia de seguridad y otras
operaciones de fondo. Otras pueden ser manutención y gráficas, ordenamientos,
directorios de servicios, manejo de información de la base de datos, manejo de
procesos, calendarización de trabajos, notificación de eventos de servicios, manejo
de instalación de software, servicios de cifrado y control de accesos.
18. Middleware basados en la web
Este tipo de middleware asiste al usuario con la navegación web, el uso de interfaces
que le permiten encontrar páginas de su interés y detectar cambios de interés del
usuario basado en su historial de búsquedas. Provee de un servicio de identificación
para un gran número de aplicaciones y comunicación entre procesos independiente
del sistema operativo, protocolo de red y plataforma de hardware. Los middleware
que se encuentran fuertemente unidos a la red se llaman servidores de aplicaciones,
ya que mejorar el rendimiento, disponibilidad, escalabilidad, seguridad, recuperación
de información, y soportan la administración colaborativa y su uso. Los middleware
pueden contactar directamente a la aplicación ganando mejor comunicación entre el
servidor y el cliente. Otros servicios importantes dados por este tipo de middleware
son servicios de directorios, emails, cadenas de suministros de gran tamaño, accesos
remotos a información, descarga de archivos, accesos a programas y acceso a
aplicaciones remotas.
Middleware especialistas
En muchos casos los middleware proveen una tarea muy específica que no se puede
ajustar a las categorías anteriores. Un ejemplo serían middlewares médicos.
19. Middleware a tiempo real
La información en tiempo real es caracterizada por que la información correcta en un
instante puede no serlo en otro. Los middleware en tiempo real soportan las
peticiones sensibles al tiempo y políticas de planificación. Esto se realiza con servicios
que mejoran la eficiencia de las aplicaciones de usuario. Los middleware en tiempo
real se pueden dividir en diferentes aplicaciones:
Aplicación de base de datos en tiempo real.
Sensor de procesamiento.
Transmisión de información.
La información que pasa a través de un middleware en tiempo real se ha
incrementado dramáticamente con la introducción de Internet, redes inalámbricas, y
las nuevas aplicaciones basadas en la difusión. Las ventajas de este tipo de
middleware son que proveen un proceso de decisión que determinar el mejor criterio
para resolver procesos sensibles al tiempo, y la posibilidad de ayudar a los sistemas
operantes en la localización de recursos cuando tienen tiempos límites de operación.
Los middleware multimedia son una rama mayor en los middleware en tiempo real.
Éstos pueden manejar una gran variedad de información. Estos tipos pueden ser
textos, imágenes de todo tipo (GPS, imágenes, etc.), procesadores de lenguajes
naturales, música y video. La información debe ser recopilada, integrada y entonces
enviada al usuario sensible del tiempo. Los dispositivos multimedia pueden incluir una
mezcla de dispositivos tanto físicos (parlantes, cámaras, micrófono) como lógicos.
20. CONCLUSION
De manera muy sencilla y básica podemos concluir que la arquitectura
cliente servidor es una herramienta muy útil empleada en diseños de
administración y distribución de recursos lógicos y físicos en una red o en
cualquier estructura de red brinda una seguridad robusta al momentos de
compartir dichos recursos con los usuarios que tiene acceso a ella y
protegiéndola de los que no lo tienen, permitiendo elegir de manera clara
cual aplicación de este modelo es más útil al momento de diseñar la red.
21. GLOSARIO
Applet: es un componente de una aplicación que se ejecuta en el contexto de otro
programa, por ejemplo en un navegador web
BackOffice: es la parte de las empresas donde se realizan las tareas destinadas a
gestionar la propia empresa y con las cuales el cliente no necesita contacto directo.
Por ejemplo: el departamento de informática y comunicaciones que hace que
funcionen los ordenadores, redes y teléfonos, el departamento de recursos
humanos, el de contabilidad, etc
Gateways: gateway es una puerta de enlace, acceso, pasarela. Es un nodo en una
red informática que sirve de punto de acceso a otra red