clase5 MODELO CLIENTE SERVIDOR

  • Published on
    18-Feb-2016

  • View
    217

  • Download
    2

Embed Size (px)

DESCRIPTION

REDES

Transcript

Evolucin del modelo Cliente Servidor Mono-capa Data Base Server Computacin centralizada Two-Tier Proceso de transacciones Multi-tier Client/Server Three-tier Multi-tier N-tier Aplicaciones mono-capaEntendemos por aplicaciones mono-capa, aquellas que tanto la propia aplicacin como los datos que maneja se encuentran en la misma mquina y son administradas por la misma herramienta: podramos decir que son una sola entidad

Figura 1. Arquitectura Tpica de una aplicacin de una sola capa.

Modelo En Dos Capas (Two-Tier Model) En una arquitectura cliente/servidor clsica tenemos dos "capas" (two-tier):o 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 lgica de la aplicacin se encuentra por tanto repartida entre el cliente y servidor.Un ejemplo de esta configuracin podra 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 clsica.

Ventajas de este modelo:o Se mantiene una conexin persistente con la base de datos. Se minimizan las peticiones en el servidor trasladndose la mayor parte del trabajo al cliente. Se gana en rendimiento gracias a la conexin directa y permanente con la base de datos. A travs de una nica conexin se realiza el envo y recepcin de varios datos. Inconvenientes:o La ms importante desventaja, es que esta solucin 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 comunicacin con la base de datos. Adems 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 mayora de los que se ejecutan en un navegador, se puedan realizar las siguientes operaciones: 1. El acceso general, y por supesto mediante JDBC, a bases de datos situadas en direcciones URL distintas a las que procede el mismo applet. 2. La configuracin de recursos locales como, por ejemplo, la informacin de la fuente de datos ODBC para usar el puente JDBC-ODBC. 3. La descarga de clases nativas, es decir, aquellas cuyo nombre empieza por Java. Esta restriccin afecta directamente a los navegadores que utilizan JDK 1.0.2 o anterior, pues JDBC es posterior a esta versin, de forma que las clases apropiadas no estarn instaladas localmente ni podrn ser descargadas de Internet por el applet. o Finalmente debemos tener en cuenta que es bien conocido que los programas Java pueden ser descompilados muy fcilmente con lo que introducir el acceso a nuestras bases de datos mediante un applet Java conlleva un riesgo considerable en cuanto a la seguridad.

Modelo en Tres Capas (Three-Tier Model) Con la arquitectura cliente/servidor en tres capas (three-tier) aadimos una nueva capa entre el cliente y el servidor donde se implementa la lgica de la aplicacin. De esta forma el cliente es bsicamente una interface, que no tiene por qu cambiar si cambian las especificaciones de la base de datos o de la aplicacin; 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 mquina servidor; o bien accedemos a la base de datos a travs de un formulario HTML. El servlet establece una conexin a la base de datos mediante JDBC.En este caso se tiene total libertad para escoger dnde se coloca la lgica de la aplicacin: en el cliente, en el servidor de base de datos, o en otro(s) servidor(es). Tambin se tiene total libertad para la eleccin del lenguaje a utilizar. Se utiliza un lenguaje de tipo general (probablemente C) por lo que no existen restricciones de funcionalidad. Los programas sern ptimos desde el punto de vista de la performance. Tambin deber implementarse especialmente el Call remoto, lo que seguramente se har de una forma ms libre que los Remote Procedure Call actualmente disponibles. No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las aplicaciones sern totalmente portables sin cambio alguno. Puede determinarse en qu servidor(es) se quiere hacer funcionar estos procedimientos. En aplicaciones crticas se pueden agregar tantos servidores de aplicacin como sean necesarios, de forma simple, y sin comprometer en absoluto la integridad de la base de datos, obtenindose una escalabilidad muy grande sin necesidad de tocar el servidor de dicha base de datos. El problema de esta arquitectura es cmo se implementa?. Parece ilusorio tratar de programar manualmente estos procedimientos, mientras que, si se dispone de una herramienta que lo hace automticamente, presenta ventajas claras sobre la alternativa anterior: Figura B: Arquitectura Cliente/Servidor en tres capas (three-tier)

Como se podra esperar cada uno de los componentes de la aplicacin en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera ms flexible. Algo que no creo que sorprenda es la afirmacin de que este tipo de arquitectura es la ms compleja.

Figura 4. Arquitectura Three-Tier. En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lgica del negocio. Cuando el cliente necesita hacer una peticin se la hace a la capa en la que se encuentra la lgica del negocio. Esto es bastante importante pues eso quiere decir que: 1.- El cliente no tiene que tener drivers ODBCni la problemtica consiguiente de instalacin 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) Lo ideal sera que el Gestor de Reglas de Negocio no slo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/OpenVentajas de este modelo:o No existe ningn problema con respecto al tipo de controlador JDBC utilizado para acceder a la base de datos.Todos los recursos necesarios para establecer la conexin con la base de datos se encuentran en el servidor y por tanto, el cliente no necesita instalar nada adicional en su mquina para poder acceder a la base de datos. Esta arquitectura proporciona considerables mejoras desde el punto de vista de la portabilidad de la aplicacin, escalabilidad, robustez y reutilizacin del cdigo. Asimismo facilita las tareas de migracin 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:o Esta solucin es algo menos eficiente que la del modelo de dos capas, ya que hemos aadido una capa intermedia ms de software.

Arquitectura de N TierWindows DNA distribuye una aplicacin entre varias capas llamadas niveles. Aunque los niveles algunas veces residen fsicamente en mquinas diferentes, Windows DNA enfatiza la distribucin lgica. Mientras que los nombres de estos niveles difieren de acuerdo a la fuente, la Gua del Desarrollador de BackOffice (BackOffice Developer's Guide, BDG) se refiere a ellos como sigue: Servicios de usuario. Servicios de negocios. Servicios de datos.

Este diagrama muestra como varias aplicaciones y tecnologas 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 comn de servicios, incluyendo HTML y HTML dinmico (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, administracin de sistemas y ambientes de creacin de componentes. Estos servicios son expuestos de manera unificada a travs del COM, el cual permite que las aplicaciones interoperen y compartan componentes.Las principales ventajas del desarrollo en N niveles son respecto a la escalabilidad. Las aplicaciones que procesan su lgica de negocios, ya sea en las mquinas cliente o en las bases de datos, se vuelven lentas cuando estn 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 da. La transicin para el desarrollo N niveles no es gratis, el tiempo de desarrollo se increment debido a la complejidad de aadir otro nivel. Afortunadamente, el middleware, tal como el MTS, fue desarrollado para manejar automticamente los detalles de la infraestructura de aplicacin, tal como el manejo de procesos alternos y los detalles de COM.