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-capa
Entendemos 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.

o 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.

o Se minimizan las peticiones en el servidor trasladndose la mayor parte del

trabajo al cliente.
o 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.

o 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/Open

Ventajas 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.

o 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.
o 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 Tier

Windows 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.