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