2 tier (cont.)

Transcripción

2 tier (cont.)
Arquitectura de los sistemas
distribuidos
●
A nivel lógico, los sistemas de información se diseñan
asumiendo tres niveles
presentation
layer
application logic
layer
resource management
layer
2/03/06
Prog Distr. Internet
information system
client
1
Nivel de Presentación
●
●
Todo sistema interactúa con entidades externas =
clientes
–
Pueden ser personas u otros sistemas informáticos
–
Utilizan los servicios del sistema
La interacción (interfaz con el cliente) requiere:
–
Presentar la informacion a los clientes
●
–
Ej.- interfaz gráfico, o cierto lenguaje de interacción
Permitir que los clientes lancen operaciones y obtengan
respuestas
2/03/06
Prog Distr. Internet
2
Posible confusión
cliente/presentación
●
●
Navegador web que accede a un fichero HTML
–
Actua como cliente (solo visualiza la información preparada
por el servidor web)
–
El nivel de presentación es el servidor web y los modulos
que crean el documento html (ej.- servlet java)
En los sistemas cliente/servidor
–
Un mismo programa actúa como cliente y nivel de
presentación
●
2/03/06
(ej.- applet java ejecutándose en un navegador)
Prog Distr. Internet
3
Lógica de la aplicación
●
Los sistemas de información no se limitan a devolver
datos previamente almacenados
–
●
Realizan algún tipo de procesamiento sobre los datos (un
programa implementa la operación solicitada por el cliente)
Lógica de la aplicación = programas y servicios
ofrecidos por el sistema de información
–
Ej.interacción con el sist de información de un banco (ej
reintegro)
–
Representa la lógica de la operación desde el punto de vista
del proveedor del servicio (el banco)
2/03/06
Prog Distr. Internet
4
Lógica de la aplicación (cont.)
●
●
Verifica las condiciones de cada operación
–
Comprobar si se exceden los niveles de reintegro
–
Autorizar (o no) la entrega de dinero
Y realiza los pasos necesarios
–
Crea una entrada log para la operación
–
Realiza la operación frente al balance actual
●
Todo esto es opaco para el cliente
●
Este nivel también puede denominarse
–
Procesos de negocio, lógica de negocio, reglas de negocio,
o simplemente servidor
2/03/06
Prog Distr. Internet
5
Gestión de recursos
●
Los sistemas de información trabajan con datos
–
–
Los datos residen en un medio de almacenamiento estable
●
Sistemas de ficheros
●
Bases de datos
●
Depósitos de información (repositories)
Las fuentes de datos pueden incluso ser externas
●
●
Gestión de recursos = gestión de las fuentes de datos
–
●
Hay que interactuar con ellos
Ej en el caso del banco, el estado de las cuentas
También se denomina nivel de datos
2/03/06
Prog Distr. Internet
6
Alternativas de diseño
●
●
Si partimos desde cero, diseño Top-Down
–
Procedemos por niveles (presentación, lógica de aplicación,
gestión de recursos)
–
Viable siempre que tengamos total libertad de acción
–
Ventaja.- Enfatiza los objetivos de funcionalidad (solución a
la medida)
Si nos basamos en sistemas pre-existentes, diseño
Bottom-Up
2/03/06
Prog Distr. Internet
7
Diseño Top-Down
1)Elige plataformas cliente y canales de acceso
2)Define la funcionalidad del sistema
•
Interacción cliente/sistema -protocolos, tipos ops, etc-
3)Define la lógica de aplicación necesaria
4)Define los recursos necesarios para la lógica
•
●
Organización de los datos y acceso a los mismos
En paralelo con los pasos anteriores
–
Especifica distribución del sist. entre los nodos
●
2/03/06
Puede distribuirse funcionalidad de cualquier nivel
Prog Distr. Internet
8
Diseño Bottom-Up
●
Responde a una necesidad, no a una elección
–
Los sistemas de información se construyen en base a
integrar sistemas ya existentes
●
●
Se denominan legacy applications o legacy systems
Utilizamos dichos sistemas en un contexto o con un propósito
diferente al original
–
●
Todo sistema de información inevitablemente se convertirá en
legacy en algún momento de su vida útil
Problema.- integrar la funcionalidad de sistemas
'legacy'
–
No podemos seleccionar la funcionalidad (prefijada)
●
2/03/06
El diseño top-down no es viable
Prog Distr. Internet
9
Diseño Bottom-Up (cont.)
●
El diseño está condicionado por las caracteristicas de
los niveles inferiores.
–
Definir la funcionalidad deseada
–
Analizar el nivel de gestión de recursos (donde están los
sistemas legacy)
●
Analizar la viabilidad (y coste) para obtener la funcionalidad
necesaria a partir de dichos componentes
–
Construir interfaces adecuados para esos elementos
(wrapped)
–
Construir la lógica de aplicación usando dichos interfaces.
–
Desarrollar la presentación
2/03/06
Prog Distr. Internet
10
Bottom-Up (cont.)
●
●
Los pasos son:
–
Investigar las aplicaciones y procesos existentes
–
Analizar y reestructurar el dominio del problema
El resultado es un sistema debilmente acoplado
–
Muchos elementos son sistemas independientes
●
●
Pueden reutilizarse en otros contextos
En ocasiones se busca ambivalencia
–
El sistema legacy debe mantener su funcionalidad como
sistema independiente
–
y simultaneamente es un componente de nuestro sist
2/03/06
Prog Distr. Internet
11
Inciso.- Servicios web
●
La ventaja de los servicios web radica en que:
–
Permiten diseños bottom-up más eficientes
–
Facilitan su desarrollo y mantenimiento.
2/03/06
Prog Distr. Internet
12
Arquitectura
●
●
Los niveles lógicos pueden combinarse y distribuirse
de distintas formas.
En ese caso hablamos de niveles de la arquitectura
(tiers)
–
●
Aparecen arquitecturas 1 tier, 2 tier, 3 tier, N tier
La arquitectura de los sistemas distribuidos
evolucionan en respuesta a:
–
Mejoras a nivel del hardware y redes de interconexión
–
Nuevos tipos de aplicación
–
Nuevos patrones en el uso de los sistemas
2/03/06
Prog Distr. Internet
13
Evolución histórica
●
1 tier (mainframes + terminales)
–
●
2 tier
–
●
Middleware
N tier
–
●
Modelo Cliente/Servidor
3 tier
–
●
Sistema monolítico
Integración entre servidores
...Servicios web
2/03/06
Prog Distr. Internet
14
1 tier
client
presentation
layer
application logic
layer
resource management
layer
2/03/06
Prog Distr. Internet
information system
1-tier architecture
15
1 tier (cont.)
●
Mainframe al que se conectan terminales
–
Terminal = pantalla+teclado
●
●
●
Se limita a mostrar la información remitida por el mainframe
Todos los niveles mezclados (entidad monolítica)
–
Eficiente, mantenimiento caro, modificación imposible
–
No existe un API para que las aplicaciones u otros sistemas
interactuen con ese sistema
–
Screen scrapping (a medida, elevado coste)
Algunos sistemas de ese tipo continuan en uso
–
Ejemplo de legacy system
2/03/06
Prog Distr. Internet
16
2 tier
2-tier architecture
client
resource management
layer
2/03/06
Prog Distr. Internet
information system
application logic
layer
server
presentation
layer
17
2 tier (cont.)
●
●
●
Aparecen los Pcs
–
División entre grandes ordenadores (mainframes y servidores,
pero con terminales inteligentes-ej Pcs-)
–
y pequeños ordenadores (PC y estaciones de trabajo)
Los terminales inteligentes permiten desplazar el nivel
de presentación al cliente
–
Libera potencia en el servidor
–
Permite personalizar el nivel de presentación
Modelo cliente/servidor
–
El cliente procesa información remitida por el servidor
2/03/06
Prog Distr. Internet
18
2 tier.- Cliente/Servidor
●
Se populariza el modelo cliente/servidor
–
Clientes ligeros (funcionalidad mínima)
●
–
Clientes pesados (amplia funcionalidad).
●
●
Fáciles de portar, instalar y mantener
Requieren muchos recursos en la máquina cliente.
Aparece el 'interfaz de aplicación' (API). Indica:
●
●
●
–
Como invocar el servicio
Las respuestas que pueden esperarse
Qué efectos tendrá sobre el estado interno del servidor.
Un API estable permite:
2/03/06
●
Desarrollar todo tipo de clientes
●
Evolucionar el servidor sin afectar a los clientes
Prog Distr. Internet
19
2 tier.- Cliente/Servidor (cont.)
●
●
●
Servicio = programa que implementan la lógica de
aplicación
–
Se ejecuta sobre un servidor.
–
El interfaz del servicio define como interactuar con el mismo,
y oculta los detalles de implementación
API del servidor = cto de interfaces de los servicios
que se ejecutan sobre el servidor
Enfasis en interfaces -> necesidad de estandarización
–
Los servicios web representan el último paso en la vía de la
estandarización.
2/03/06
Prog Distr. Internet
20
2 tier (cont.)
●
Eficiencia
–
●
●
Los niveles lógico y de recursos comparten contexto
●
Mantenemos la eficiencia de las operaciones clave
●
Permite las mismas optimizaciones que en sistemas 1tier.
Portabilidad
–
El nivel de presentación es independiente
–
Puede reescribirse para distintos tipos de clientes
Problema de escalabilidad
–
Un servidor soporta un número limitado de clientes
2/03/06
Prog Distr. Internet
21
2 tier (cont.)
●
El cliente no debe integrar servicios
–
Cliente complejo
–
Invalidado si cambia el API de cualquier servidor
client
application logic
2/03/06
presentation
layer 2
application logic
layer
application logic
layer
resource management
layer
resource management
layer
Prog Distr. Internet
server 2
server 1
presentation
layer 1
22
3 tier
3-tier architecture
client
application logic
layer
middleware
resource management
layer
2/03/06
Prog Distr. Internet
information system
presentation
layer
23
3 tier (cont.)
●
●
Necesitamos integrar servicios (ej.- servidores de una
empresa)
–
Los servidores no se conocen entre sí
–
El cliente no puede integrarlos
–
Las mejoras a nivel de interconexión (LANs) permiten
plantear la integración de distintos servidores.
Introducimos un nivel adicional entre clientes y
servidores (middleware)
–
Dicho nivel incluye la lógica de aplicación
–
Y además soporta integración de los sist subyacentes.
2/03/06
Prog Distr. Internet
24
3 tier (cont.)
●
Arquitecturas más complejas y variables las 2 tier
–
●
Caracterización dificil
A nivel abstracto
–
La presentación reside en el cliente
–
La lógica en el nivel intemedio (middleware)
–
El nivel de recursos está compuesto por todos los
servidores que deseamos integrar
●
2/03/06
a su vez poseen sus propios niveles de lógica y recursos
Prog Distr. Internet
25
3 tier.- integración de sistemas
client
presentation
layer
application
logic
client
layer
client
wrapper
wrapper
2/03/06
2-tier
1-tier
wrapper
Prog Distr. Internet
middleware
resource
management
layer
3-tier
integration logic
26
3 tier (cont.)
Mejor escalabilidad
●
Lógica de aplicación y gestión de recursos pueden ejecutarse
en servidores distintos
●
●
Mejor portabilidad
●
Mejor reutilización
●
Podemos adaptar/reutilizar cada nivel
●
Middleware =
●
Base para desarrollar lógica de aplicación
●
Permite añadir otras propiedades (transacciones, logging, replicación,..)
Facilidad para integrar recursos diferentes
●
●
Soporte para automatización
2/03/06
Prog Distr. Internet
27
N tier
client
Web server
presentation
layer
HTML filter
application logic
layer
middleware
information system
N-tier architecture
Web browser
resource management
layer
2/03/06
Prog Distr. Internet
28
N tier
Dos variantes:
●
Enlazar distintos sistemas
●
El nivel de recursos puede contener no solo recursos simples, sino
sistemas 2-tier y 3-tier completos
●
Añadir conectividad mediante internet
●
●
●
●
2/03/06
Incorporamos servidores web como parte del nivel de presentación
El cliente es el navegador web, y el nivel de presentación se distribuye
entre el navegador web, el servidor web, y el código que prepara las
págs HTML
Podemos añadir otros niveles: ej filtro HTML que transforma los datos
generados por la lógica de aplicación en páginas HTML
Prog Distr. Internet
29
N tier (cont.)
●
Arquitectura muy compleja
●
●
●
●
●
●
Colección de redes, ordenadores simples, clusters, y enlaces entre
distintos sistemas
Los clientes remotos acceden al sistema via internet
Clientes dispersos por toda la empresa pueden acceder tambien a la
lógica de aplicación
Puede coexistir varias plataformas middleware para distintas aplicaciones
y funcionalidad
El nivel de recursos puede agrupar varios sistemas, e incluir enlaces a
sistemas 2tier, 3tier y Ntier adicionales
Elevado coste de desarrollo y mantenimiento
●
Mucho middleware involucrado, muchas veces funcionalidad redundante
●
Los costes crecen con el número de niveles
2/03/06
Prog Distr. Internet
30

Documentos relacionados