CLASES DE 11 JUNIO

Arquitectura del sistema central

Las primeras redes informticas se desarrollaron alrededor de un equipo central llamado
"sistema central".
Por este motivo el sistema central es un ordenador central de alto rendimiento que
controla las sesiones del usuario en los diferentes terminales que estn conectados a l.
Gracias a esta arquitectura puede consolidarse, es decir, administrar de manera
centralizada todas las aplicaciones comerciales de una empresa.
Sin embargo, en el modelo de sistema central, el rendimiento del sistema depende
ntegramente de la capacidad de procesamiento del ordenador central, por eso a veces se
le denomina "informtica pesada". Adems, en un entorno de sistema central, los
terminales de red slo pueden ver al servidor central.

Arquitectura en 2 niveles.
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en
donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con
sus propios recursos. Esto significa que el servidor no requiere otra aplicacin para
proporcionar parte del servicio.

Introduccin a la arquitectura en 3 niveles

En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la
arquitectura generalmente est compartida por:
1.

Un cliente, es decir, el equipo que solicita los recursos, equipado con una
interfaz de usuario (generalmente un navegador Web) para la presentacin
2.
El servidor de aplicaciones (tambin denominado software intermedio), cuya
tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para
hacerlo
3.
El servidor de datos, que proporciona al servidor de aplicaciones los datos que
requiere

Comparacin entre ambos tipos de arquitecturas

La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la que
el servidor es polivalente, es decir, puede responder directamente a todas las solicitudes
de recursos del cliente.
Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor son
descentralizadas de uno a otro, es decir, cada servidor se especializa en una determinada
tarea, (por ejemplo: servidor web/servidor de bases de datos). La arquitectura en 3
niveles permite:

Un mayor grado de flexibilidad

Mayor seguridad, ya que la seguridad se puede definir independientemente para
cada servicio y en cada nivel
Mejor rendimiento, ya que las tareas se comparten entre servidores

Arquitectura de niveles mltiples

En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea
especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros
servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3
niveles es potencialmente una arquitectura en N-niveles

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

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

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