Arquitecturas y Middleware

Arquitecturas y Middleware

Taller de Sistemas de Información 1InCo – Facultad de Ingeniería

Abril 2004

Taller de Sistemas de Información 1

2

Temario

Evolución de las arquitecturas Centralizada Cliente/Servidor (2 y n-Capas) Bases de Datos Distribuidas Internet/Intranet.

Ejemplos Middleware y clasificación del mismo. Configuración del Panorama Actual.


3

Evolución según décadas


4

Evolución de las Arquitecturas Al comienzo: Mainframes y Centralización Gerente de IT priorizaba la integridad de los datos a

través de la centralización. No se le daba importancia a la integración de

sistemas heterogéneos. Los primeros conceptos de distribución fueron

recluidos a las áreas donde eran estrictamente necesarios, caso de EDI, que usualmente eran unidades completamente separadas de la organización.


5

Evolución de las Arquitecturas Tipos de Procesamiento DBMSs. Lógica asociada a datos en la BD. Lógica (reglas) del negocio. Validaciones sobre atributos (campos).

Relacionadas con la lógica del negocio. Según el tipo o formato de los datos.

Armado y presentación de interfase. Despliegue de interfase.


6

Evolución de las Arquitecturas Arquitectura Centralizada Mayoría del procesamiento en el servidor. En el cliente:

Solo el Despliegue de la Interfase. Ventajas:

Simplicidad. Uso de hardware del cliente muy simple.

Desventajas: Recarga del servidor y escalabilidad. Problemas en acceso remoto.


7

Evolución de las Arquitecturas Arquitectura Centralizada (2)


8

Evolución de las Arquitecturas Minicomputadores y comienzos de Distribución

Los principales conceptos de distribución, como la comunicación sincrónica o asincrónica o las facilidades de bajo nivel para integrarse con aplicaciones remotas, aparecieron con los minicomputadores (léase DEC VMS, Tandem, HP, etc). Ej. MQSeries, de IBM.

Oculta por el boom del surgimiento de los PCs, la distribución no tuvo auge hasta que Internet se volvió un “commodity”.

Definición: Un ambiente computacional se dice distribuido cuando sus programas o BDs están ubicados en dos o más computadores.


9

Evolución de las Arquitecturas Arquitectura Cliente – Servidor Una forma de definirlo:

C/S es una relación entre procesos corriendo en máquinas separadas: El servidor (S) es un proveedor de servicios. El cliente (C) es un consumidor de servicios.

C y S Interactúan por un mecanismo de pasaje de mensajes: Pedido de servicio. Respuesta.


10

Evolución de las Arquitecturas Arquitectura C/S - Ventajas La gran ventaja es usar lo mejor de ambos

sistemas: Puestos de trabajo autónomos (Cliente):

Ambiente mono-usuario. Excelente relación potencia/costo. Aplicaciones potentes. Interfaces simples y amigables.

Grandes sistemas (Servidor): Ambiente multiusuario. Gestión centralizada de la BD. Gran seguridad. Compartir información y dispositivos.


11

Evolución de las Arquitecturas Arquitectura C/S – Separación y Contras Separación del procesamiento entre Cliente y

Servidor. Cliente: Despliegue, Interfase, Validaciones,

Reglas Negocio. Servidor: Reglas Negocio, Lógica BD, DBMS.

Desventajas: Más compleja que Centralizado. Escalabilidad: procesamiento en C o S.


12

Evolución de las Arquitecturas Arquitectura C/S - Propiedades esperadas1. Acceso a recursos:

Un S puede atender a varios C y controlar el acceso a los recursos.

2. Transparencia: El diálogo entre C y S debe ser transparente a la ubicación, hardware y plataforma.

3. Encapsulamiento: Un pedido indica qué servicio se desea. El S se encarga de cómo resolverlo. Se

puede modificar los S sin afectar los C.

4. Escalabilidad:Se puede escalar sin afectar a otros componentes: Horizontal: se agregan otros C y S. Vertical: se cambia un S por otro más potente o se distribuye su trabajo entre

varios.

5. Integridad: Las funciones y datos del S son manejadas en forma centralizada. Eso

beneficia el mantenimiento e integridad de los datos.


13

Evolución de las Arquitecturas Arquitectura C/S – Tipos de Clientes Modelo “cliente flaco”:

Servidor rápidamente saturado. Gran circulación de datos de interfase en la

red. Modelo “cliente gordo”:

Casi todo el trabajo en el cliente. No hay centralización de la gestión de la

BD. Gran circulación de datos inútiles en la red.


14

Evolución de las Arquitecturas Arquitectura C/S – Lógica de Aplicación


15

Evolución de las Arquitecturas Arquitectura C/S – Lógica de Aplicación Lógica de la aplicación en el cliente:

La semántica está dividida entre los programas. C/prog sólo maneja una parte del problema. Los controles están “embebidos” en el código. Problemas de mantenimiento, dupl. esfuerzo e integridad.

Lógica de la aplicación en el servidor: Lógica centralizada y consistente. Aumenta seguridad e integridad. Algunos controles los puedo expresar en SQL (triggers),

otros deben ser complicados. Aumenta trabajo y complejidad del servidor.


16

Evolución de las Arquitecturas Arq. en 3 Capas - Distribución de Procesos Se tienen Servidores de Procesos o

Aplicaciones. Cliente: Despliegue, Interfase, Validaciones. Servidor Aplicación: Validaciones, Reglas

Negocio. Servidor BD: Lógica BD, DBMS.

Ventajas: Mas escalable.

Desventajas: Mayor complejidad de sistema.


17

Evolución de las Arquitecturas Arquitectura de BD Distribuidas Un opción además de distribuir procesos, es

distribuir datos. Se tiene varios Servidores de BD:

Las consultas/operaciones se distribuyen en los diferentes sitios.

Pueden haber datos replicados. Ventajas:

Mayor disponibilidad de datos. Distribución del procesamiento de la BD.

Desventajas: Arquitectura más compleja.


18

Evolución de las Arquitecturas Arquitectura Internet/Intranet Internet/Intranet: clientes = browsers html

Se tiene una arq. C/S en 4 capas: Serv BD, Serv Aplic, Serv Web, Cliente.

En el Servidor Web se: Procesa la conexión con el cliente. Prepara la interfaz a desplegar en el cliente.

Ventajas: Cliente universal: browser html.

Desventajas: Procesamiento de cliente limitado. Baja conexión cliente/servidor.


19

Evolución de las Arquitecturas Arquitecturas en N Capas


20

Evolución de las ArquitecturasEjemplos File Servers:

C pide bloques de archivos al S. Es la primera forma de C/S. Cliente muy gordo.

Database Servers: C hace pedidos SQL, S construye el result. y lo envía. Hace un uso más eficiente de recursos. Lógica en C.

Transaction Servers: C invoca proced. remotos que residen del lado del S, junto

al DBMS. Cada proced. consiste de pedidos SQL para el DBMS.

Lógica en S.


21

Evolución de las ArquitecturasEjemplos (2) Groupware Servers:

Involucra el intercambio de datos semi-estructurados (texto, imágenes, mail, workflow…).

C envía mensajes al S (Originalmente en formato propietario, nuevos productos usan email). Lógica en S.

Object Application Servers: Una aplicación se escribe como un conjunto de objetos

que se comunican usando un ORB. Un objeto C invoca métodos en objetos remotos S. El ORB encuentra al objeto S e invoca al método.

Está orientado a implementar servidores de aplicaciones en arquitecturas de +3 niveles.


22

Evolución de las ArquitecturasEjemplos (3) Web Servers:

En la primera versión: Un C (browser) solicita un documento por su nombre. El

S retorna el documento. C muy flaco.

El modelo ha evolucionado: Comenzó con la ejecución de programas en el servidor. Enriquecimiento de la web con objetos distribuídos

(object web). Arquitectura de N niveles.


23

MiddlewareDefinición Es el “pegamento” (glue) que ayuda a la conexión

entre programas (o bases de datos). Más formalmente:

Es el soft-sistema que permite las interacciones a nivel de aplicación entre programas en un ambiente distribuido.

Por soft-sistema (system software) se entiende el software posicionado entre una aplicación y un sistema de menor nivel (s. Op, DBMS, Servicio Red).


24

MiddlewarePara qué usar Middleware ? Dadas dos aplicaciones que se quieren conectar, hay que

resolver la comunicación entre los procesos. Si las aplicaciones se conectan directamente a soft de red,

entonces no se necesita Middleware. Este encare complica el desarrollo de las aplicaciones:

Se debe programar módulos de bajo nivel. Este desarrollo se repite para cada aplicación a conectar.

El soft de Middleware permite realizar esta conexión a través de interfases de alto nivel, por ejemplo que permiten ver un procedimiento remoto como si fuera local.


25

MiddlewareEsquema de conexión sin Middleware Los programas deben resolver la conexión

usando medios de bajo nivel, cercanos al Sistema de Red.

Sistema Operativo

Programa

Sistema Red

Programa

Sistema Operativo

Sistema Red


26

MiddlewareEsquema de conexión con Middleware La capa de Middleware permite programar la

comunicación mediante herramientas de alto nivel. Por ejemplo: procedimientos, mensajes, acceso a

objetos.

Middleware

Middleware

Sistema Operativo

Programa

Sistema Red

Programa

Sistema Operativo

Sistema Red


27

MiddlewareEjemplos Ejemplos de Middleware:

Drivers a DBMSs. Acceso a DBMS desde un programa u otro DBMS.

Remote Procedure Call (RPC). Invocación a procedimientos remotos como si fueran

locales al programa. Message Oriented Middleware (MOM).

Envío de mensajes entre aplicaciones. Object Request Brokers (ORB).

Invocación a procedimientos y propiedades de objetos distribuidos en distintos equipos.


28

MiddlewareAplicación en Arquitecturas de más de 3 niveles

Servidor WEB

Cliente Cliente Cliente Cliente Cliente

Servidor Aplicaciones

ServidorDBMS

Servidor DBMS




Conexión a DBMS

ORB

TPMTPM

TPMMOM

Conexión a DBMS

RPC


29

Middleware Clasificación (1) De base (Basic Middleware).

Data Middleware. Remote File Access, Remote DB Access. Permite el acceso a datos desde programas u otros BDs.

Communication Middleware. Permiten la comunicación entre programas. Ej. RPC, MOMs.

Platform Middleware. Permiten resolver invocaciones o acceso a datos entre

programas. Proveen un runtime environment, que incluye tecnologías de Middleware de datos y comunicaciones.

Ej. Application servers, ORBs, OTMs & TPMs.


30

Middleware Clasificación (2) Integrador (Integration Middleware).

Características: Permiten conexión de alto nivel entre aplicaciones

desarrolladas independientemente, o entre sistemas con diferente Middleware.

Embeben tecnologías de Middleware básicas. Subtipos:

Gateways, Superservices, Integration Brokers, Business Process Managers.


31

Basic MiddlewareData Middleware / SQL Middleware Características:

Conectan programas con DBMS o DBMSs entre si a través de un API, con uso opcional de lenguaje de consulta.

Fuertemente asociados a tecnologías de DBMS. Incluyen un componente cliente y otro servidor.

Ejemplos: ODBC, OLEDB, JDBC


32

Basic Middleware Data Middleware / SQL MiddlewareLa idea es que diferentes DBMS den la ilusión de ser un único

sistema, es decir un sistema federado. Entonces tengo diferentes clientes accediendo al sistema federado.

Problemas que lo impiden: SQL no es tan estándar: SQL (‘ 86), SQL2 (‘ 92), SQL3 (‘ 99).

Cada vendedor tiene sus propias extensiones (dialectos). Diferencias en:

APIs (Application Programming Interface). Driver: Runtime que acepta llamadas, formatea mensajes (FAP: Format

and Protocols) y maneja el intercambio. Stacks. Sólo algunos usan transporte estándar: sockets, named pipes


33

Basic Middleware Data Middleware / SQL Middleware API común: facilita el desarrollo, pero sigue habiendo múltiples FAPs, además qué API usar ?

FAP o driver común: el uso de una FAP simplifica al cliente. Pero implica más trabajo para el servidor. Ejemplos de FAPs: IBM-DRDA, EDA/SQL.

Estandarizar API y FAP: debe soportar un súper conjunto de dialectos y facilita el desarrollo de aplicaciones y el mantenimiento. El problema es que los vendedores deben aceptar cambiar su FAPs. Es un ideal !


34

Basic Middleware SQL Middleware - Call Level Interface Objetivo: Cualquier cliente hable con cualquier servidor.

Semántica común de SQL. Dialectos se ejecutan directamente (pass through).

Permite crear y ejecutar comandos SQL en runtime (dinámico) Soporta sólo SQL dinámico: No requiere pre-compilar.

Requiere el uso de drivers especializados. Traducen llamadas CLI a código nativo. Un driver por DBMS. Incluye un manejador de drivers.


35

Basic Middleware SQL Middleware - Propuestas CLI X/Open SAG CLI (SQL Access Group’ 88)

Standard ISO SQL/CLI ‘ 96. Interfase procedural para SQL. Codificación de tipos de datos, manejo de errores.

ODBC (Microsoft ‘ 92) Versión extendida de SAG CLI

OLE DB (Microsoft ‘ 97) Extensión de ODBC para ActiveX Interfase OO.

JDBC (Javasoft ‘ 97) Java CLI.


36

Basic Middleware Communication Middleware

RPC Esconde la red. Cliente invoca a una

función del servidor remoto y se bloquea hasta tener el resultado.

Se pasan parámetros de la forma normal.

Message Oriented Middleware (MOM) Aplicaciones sólo ponen y

sacan mensajes de colas. No se conectan. C y S

pueden correr en diferentes tiempos.

No necesariamente se requiere respuesta.


37

Basic Middleware RPC vs. MOM RPC:

Sincrónico: Se requiere una conexión. Cliente se bloquea. Respuesta inmediata. Ideal para aplicaciones que sincronizar acciones. Ejemplo: Aplicaciones interactivas, transacciones.

MOM: Asíncrono: Cliente y servidor operan en diferentes tiempos. Respuesta lenta, cuando el servidor pueda contestar. Ideal para informar, para aplicaciones poco conectadas. Ejemplos: Email, workflow.


38

Platform Middleware

Permiten la comunicación entre programas a través de mecanismos de mayor nivel que los otros Basic Middleware.

Combinan técnicas de los Communication Middleware.

En general implementan un framework que provee funciones tales como: Gestión de memoria y procesos del sistema operativo. Carga de programas, inicio y fin, pasaje de mensajes. A veces balance de carga y gestión de transacciones.

Ejemplos: Servidores de Aplicación y ORBs.

CORBA, EJB, COM+. TPM:

Tuxedo, CICS, Encina.


39

Platform MiddlewareObjetos Distribuidos Programar ensamblando componentes (building blocks).

Empaquetados como piezas de código indep. y auto contenidas. No está asociado a un programa, lenguaje o implementación. Accedidos por invocaciones a métodos. Interfase bien definida (IDL: Interface Definition Language).

Portabilidad e Interoperabilidad: Transparentes al lenguaje, compilador, ubicación, s. operativo. Se importan dentro de paletas o toolbars. Puede ser invocado a través de espacios de direcciones, redes, lenguajes,

sist operativos y herramientas. Utilizar y reutilizar.

Se diseña para ofrecer un número limitado de operaciones. Nivel de abstracción alto para que sea más útil. Tiene un estado, que es modificado seteando propiedades: permite la

reutilización y customización. Metadata: Provee información sobre sí mismo: descripción, interfase,

propiedades, eventos, calidad de servicio servicio, … Mantenerse sólos, mantener recursos. Coexistir con otros objetos.


40

Platform MiddlewareComponentes en el Servidor Seguridad: protegerse y proteger recursos (Autenticación de los

2 lados,.control de acceso, trazas) Licenciamiento. Versionado de componentes. Manejo del ciclo de vida: Creación, destrucción, clones,

externalizar contenido, movimiento. Control de transacciones y bloqueo: integridad “todo o nada” y

locks para serializar acceso a recursos. Persistencia. Relaciones dinámicas o permanentes con otros componentes. Auto-testeo: correr programas de diagnóstico para determinar

problemas. Auto-instalación: Instalarse, des-instalarse. y registrarse con

SO.


41

Platform MiddlewareORB Es un bus de comunicación entre objetos:

Permite hacer/recibir requerimientos en forma transparente: Objetos locales o remotos.

Funcionamiento: Objeto cliente invoca un método en un objeto remoto. ORB:

Localiza una instancia del objeto servidor. Invoca el método. Retorna el resultado al cliente.


42

Platform MiddlewareORB - Características 2 tipos de invocación:

Estática: interfase conocida en tiempo de compilación. Se compila el cliente con la interfase del objeto servidor.

Dinámica: la interfase se descubre en tiempo de ejecución. Se consultan directorios de servicios.

El cliente no se preocupa de: Mecanismos para activar objetos. Almacenamiento de objetos en el servidor. Mecanismos para comunicarse (bajo nivel) con los

objetos. Tipo RPC: pedido - respuesta. Tipo MOM: mensajes asíncronos. Publicar y suscribir: por eventos.


43

Platform MiddlewareORB Publicar y suscribir:

Publishers: productores de eventos. Suscribers: consumidores de eventos. Event broker: canal de comunicación para los eventos:

filtros, logs, colas, reglas, prioridades, ruteo basado en sujetos, multicasting, balance de carga, ...


44

Platform MiddlewareORB Infraestructura distribuida:

Define como los objetos conviven con los contenedores: Insertar un objeto en un contenedor de una herramienta,

por ej. un formulario. Dialogar con un DBMS, un monitor transaccional. Ser accedido desde un servidor web.

Propuestas: Cliente: ActiveX, JavaBeans. Servidor: COM+, EJB, Corba Beans.


45

Platform MiddlewareTransacción Es una secuencia de intercambios de

información y el trabajo asociado (ej. actualizar una BD) que son tratados como una unidad con el propósito de satisfacer una solicitud y asegurar la integridad de los datos.


46

Atomicidad: Se ejecuta completamente o no se ejecuta.

Consistencia: Debe dejar la base de datos en un estado consistente.

Aislamiento (isolation): No se ve afectada por otras transacciones que ejecutan

concurrentemente. Los efectos no son visibles al exterior hasta su fin.

Durabilidad: Los efectos de una transacción que valida son

permanentes.

Platform MiddlewarePropiedades ACID


47

Platform MiddlewareMonitores Transaccionales

Objetivo: Es un sistema especializado en la creación, ejecución y

manejo de aplicaciones de procesamiento de transacciones.

Características: Sistemas transaccionales tienen:

Muchas transacciones pequeñas. Muchos usuarios concurrentes.

Coordinan las transacciones con: Subsistemas ACID locales. Manejadores de recursos.

DBMS, manejadores de colas, objetos persistentes, transporte de mensajes.

Ejemplo: Sistema de reservas de agencias de viaje.


48

Platform MiddlewareMonitores Transaccionales - Funciones Control de procesos:

Iniciar y monitorear servidores. Uso optimizado de recursos. Control de flujo. Control de disponibilidad y fallos. Manejo eficiente de conexiones (muchos clientes).

Manejo de transacciones: Integridad transaccional (ACID). División y coordinación de transacciones.

Comunicación C/S. Aplicaciones clientes se comunican por diversos mecanismos. Conectividad para recursos heterogéneos. Firewalls para recursos.


49

Platform MiddlewareMonitores Transaccionales OTM: Object Transaction Monitors

Combinan ORBs con monitores de transacciones. Maneja contenedores que corren los componentes que

brindan los servicios. Maneja objetos logrando: transaccionalidad,

robustez, persistencia, seguridad, performance. Levanta un conjunto de objetos (pool), distribuye

la carga, provee tolerancia a fallos, y coordina transacciones multi-componentes.


50

Platform MiddlewareMonitores Transaccionales OTM:

¿Qué hace? Intercepta los pedidos de servicios. Invoca al objeto apropiado y le pasa el pedido.


51

TPM OTM

Platform MiddlewareMonitores Transaccionales


52

Platform Middleware Servidores de Aplicaciones

Contexto: Arquitecturas en múltiples capas: Cliente: interface usuario. Servidor Web:

Acceso http, interface usuario. Servidor de Aplicaciones:

Lógica del negocio. Lógica de los datos. Gestión de Transacciones. Acceso a la BD. Balance de carga en configuraciones paralelas.

Servidor de Base de Datos: almacenamiento.


53

Cubren: Nivel Servidor de Aplicaciones. Casi seguro: Gestión de Transacciones. Muy probablemente: Programación del Web

Server. 3 Grandes familias:

Corba Component Model (CCM): basado en estándar de la OMG.

J2EE: Propuesta de Java. COM/DCOM/COM+ .NET: Propuestas de MS

Platform Middleware Servidores de Aplicaciones


54

Integration MiddlewareGateways Características:

Realizan la traducción entre 2 o más protocolos. Existen gateways para:

DBMS, MOM. Platform Midd: Corba COM, COM EJB.


55

Integration MiddlewareSuper Services Características:

Proveen APIs de muy alto nivel para otros middleware: Directorios, gestión de transacciones, seguridad en diferentes

sistemas operativos.


56

Integration MiddlewareIntegration Brokers Características:

Son intermediarios que facilitan la interacción entre programas.

Proveen dos funciones de interés: Transformation:

Transforma mensajes o contenidos de archivos. Transforma modelos de datos de diferentes aplicaciones a

un modelo común. Flow automation (or flow control):

Son tratamientos inteligentes de flujos, por ejemplo: ruteo inteligente y/o basado en contenidos.


57

Integration MiddlewareIntegration Brokers Características:

También pueden ofrecer: Business process management (p.ej, workflow) Interpretan reglas de negocio y responden a eventos de

negocio y excepciones. Ayudan a automatizar tareas. Administrative monitoring.

Algunos requieren un MOM en especial (ej. IBM MQSeries),otros tienen interfases a una gran variedad de productos.


58

Integration MiddlewareBusiness Process Managers Características:

Objetivo de los BPM: Implementar la automatización de procesos. Llevar registro de las instancias de los procesos, a

través de su ciclo de vida. Se ofrecen de diferentes formas:

Sistemas de workflow, businessware, enterprise work management systems.


59

Algunos productos (1)

Application Server: BEA WebLogic (EJB y Corba). IBM WebSphere (EJB). Imprise Visibroker (Corba) (www.imprise.com). IONA Orbix (Corba) (www.iona.com). Microsoft COM/DCOM/MTS/COM+.

TPMs: BEA Tuxedo y WebLogic (www.beasys.com). IBM CICS.


60

Algunos productos (2)

MOM: BEA MessageQ. IBM MQSeries. Microsoft Message Queue Services (MSMQ).

Integration Middleware: BEA E-Link. MS Biztalk Server IBM MQSeries Integrator. Software AG EntireX (www.softwareag.com).


61

Ultimas tecnologías que hacen a la Integración de SI y su aparición en el tiempo

Arquitecturas y Middleware

Documents

Transcript of Arquitecturas y Middleware