Taller de Sistemas de Información 2

Transcripción

1 Taller de Sistemas de Información 2 Clase 1 Aruitecturas y Middlewares

2 Contenido Aruitectura de un sistema Evolución de las aruitecturas Monolíticas File sharing Cliente/Servidor En capas SOA Middlewares

3 Sistema El concepto de aruitectura esta 100% relacionado con el de sistema Que es un sistema? Un conjunto o colección de elementos Relacionados o conectados para llevar a cabo una función o tarea, ue no es realizable por estos elementos en forma aislada

4 Aruitectura Que es? La estructura organizativa de un sistema de software Una descripción top-down de la estructura de un sistema Compuesta por? Los bloues constructores del mismo (ladrillos) Sus propiedades externas Sus relaciones entre si y con el ambiente

5 Aruitectura Para ue? Diseñada para ue la estructura del sistema permita las funcionalidades deseadas para el sistema Funcionalidades del negocio Funcionalidades del sistema Cross-cutting concerns Propiedades verticales Diseñada para ue el sistema tenga integridad Diseñada para facilitar la evolución y mantenimiento del sistema

6 Aruitectura Para ue? La integridad de un sistema no puede lograrse en forma bottom-up Si se concentra en las partes, se compromete el todo Perspectiva global, para: Resolver los cross-cutting concerns Resolver las propiedades globales del sistema Balancear las capacidades del sistema de forma de cumplir con los reuerimientos del mismo Resolver lo reuerimientos del negocio

7 Aruitectura La aruitectura por lo general se organiza en vistas, tal y como se hace con los planos de una casa Algunas vistas: Funcionalidades o Lógica Implementación Desarrollo o Estructural Concurrencia o Procesos Despliegue o Física Existen múltiples lenguajes para expresar las anteriores Unified Modelling Language

8

9

10 Evolución La aruitectura de los sistemas ha evolucionado con el tiempo Acompaña los cambios tecnológicos y de paradigmas Algunos tipos de aruitectura: Centralizadas (Monolíticas) Cliente/Servidor (2 niveles) En múltiples capas (3 o mas niveles) Orientadas a servicios (Altamente desacopladas)

11 Verticales 1980 s y antes Horizontales 1980 s 1990 s Ecosistemas 2000 s + Evolución de los sistemas de información Monolíticas Estructuradas Cliente / Servidor 3 Capas N Capas Objetos Distribuidos Componentes Servicios Evolución de las aruitecturas

12 Modelo centralizado También conocidas como Mainframe architectures Toda la inteligencia, procesamiento de negocio, interfaces y persistencia, se realiza en un host central Los usuarios interactúan a través de terminales tontas Capturan el teclado, envían la información al host, este procesa y se retorna la pantalla a la terminal La interacción puede realizarse tanto en terminales unix, dos/windows u otras

13 Un emulador de terminales remotas IBM Client Access

14 Modelo centralizado Fueron (y lo son todavía) muy exitosas en ámbitos donde se realizan procesamientos intensos de datos Por ejemplo, entidades bancarias, procesamiento de tarjetas de crédito, etc. Es común encontrar hoy día mainframes en perfecto funcionamiento Sus programadores se cotizan en el mercado (escasean)

15 Modelo centralizado Posee limitantes No soporta fácilmente el uso de interfaces graficas Se dificulta el acceso a repositorios de datos (DBMS) distribuidos Hoy día existe un resurgimiento de las aruitecturas tipo mainframe Como soporte para servidores en aruitecturas cliente servidor distribuidas

16 Modelo centralizado Empresas como IBM utilizan sus productos tipo mainframe para soportar servidores J2EE El caso de la linea iseries es un ejemplo de ello El mainframe ejecuta un sistema operativo particular el cual ejecuta Websphere (Application Server) Las aplicaciones acceden a este como si entraran a un servidor tradicional

17 Modelo de intercambio de archivos Conocidas también como file sharing architectures Tiene su punto de partida con la popularización de las redes de área local En esta, el servidor (o el PC) descarga en su espacio local archivos ue se encuentran en el servidor El procesamiento solicitado por el cliente, es realizado en el espacio de procesamiento del mismo

18 Modelo de intercambio de archivos Funcionan cuando el volumen compartido es bajo, la contención por actualizaciones es baja y el volumen transferido es también bajo Un ejemplo de esto, es un sistema desarrollado en Visual Basic con Access Los clientes acceden a través de los programas (almacenado en el servidor en un disco compartido) a una base de datos/archivos indexados compartida A medida ue el uso concurrente aumenta, disminuye la escalabilidad de este tipo de soluciones El limite son las decenas de usuarios

19 Modelo Cliente/Servidor Como una evolución de las anteriores, surge este modelo El servidor de archivos es reemplazado por una base de datos (relacional) Se tienen dos partes claramente diferenciadas, el cliente y el servidor El cliente emite consultas, las cuales son respondidas por un servidor En este caso, se recibe solo la respuesta, en vez de un archivo compartido.

20 Modelo Cliente/Servidor El procesamiento es dividido entre el cliente y el servidor, balanceando la carga entre ambos Existen modelos basados en cliente servidor ue extienden la idea Aruitecturas en 2 capas Aruitecturas en 3 capas Aruitecturas en 3 capas con Monitores transaccionales Servidores de mensajes Servidores de aplicación

21 Aruitectura en 2 capas La presentación y la lógica de negocio se encuentran en la mauina cliente Los datos y el acceso a los mismos, se resuelve en el servidor El servidor suele ser mucho mas poderoso ue las mauinas cliente Este tipo de aruitecturas es buena cuando el volumen de los usuarios es alto En el orden de los cientos

22 Aruitectura en 2 capas Ahora la lógica de negocio puede colocarse también dentro de la base de datos (nuevas herramientas) Lenguajes de programación en el DBMS (Java, C) Procedimientos almacenados Triggers Todos estos enfoues limitan la portabilidad del sistema construido Sin embargo aumentan la eficiencia de los mismos, ya ue el procesamiento: Se hace mas cerca de los datos Se hace en un entorno mas poderoso (servidor)

23 Aruitectura en 2 capas Un problema de este tipo de aruitecturas, es ue el procesamiento de la lógica de negocio se hace en el contexto del cliente Esto dificulta el mantenimiento y deployment Implica repetición de elementos de software Debo colocar el binario en cada cliente O en un servidor de archivos, lo ue conceptualmente es lo mismo Enfrento problemáticas del estilo DLL hell. Para evitar esto, se debe factorizar la capa cliente

24 Aruitectura en 3 capas También conocidas como aruitecturas multicapa (no están limitadas a 3) Una capa intermedia se añade entre el ambiente del cliente y el servidor de base de datos Esta capa puede implementarse de multiples formas Servidores de aplicación Monitores transaccionales Sistemas de mensajeria

25 Ejemplos de aruitecturas en múltiples capas

26 Aruitectura en 3 capas Esta capa intermedia puede: Facilitar encolado de peticiones Ejecutar aplicaciones y lógica de negocio (en forma de programas) Cachear información desde la base de datos Definir planificación y prorización del trabajo realizado Este tipo de aruitecturas aumentan la performance en sistemas con grandes volúmenes de uso Miles y mas!

27 Aruitectura en 3 capas Una limitación importante de este tipo de aruitecturas, es su complejidad intrínseca El proceso de diseño, desarrollo y especialmente testeo de este tipo de soluciones es muy complejo Hoy día existe mucho soporte por parte de las herramientas de desarrollo para este tipo de sistemas Eclipse, Visual Studio.NET

28

29 3 capas + TM El tipo mas básico, tiene un monitor transaccional como capa intermedia El monitor transaccional es un sistema ue: Recibe pedidos del cliente Los encola, prioriza y vuelca contra un manejador relacional Una vez ue una transacción es aceptada, el TP acepta la responsabilidad de llevarla a termino Esto libera al cliente para ue continúe con el procesamiento

30 3 capas + TM Existen dos tipos de monitores transaccionales TP Heavy El procesamiento es realizado fuera del DBMS, por terceras partes Suelen soportar miles de clientes TP Lite El procesamiento es realizado dentro del DBMS La experiencia prueba ue por encima de los cientos de clientes, comienza la degradacion de performance

31 3 capas + TM Los monitores transaccionales también proveen La capacidad de actualizar múltiples DBMS en una sola transacción Pool de conexiones Conectividad a múltiples fuentes de datos Archivos planos, XML, datos no relacionales, Mainframes Priorizar las transacciones Seguridad y robustez

32 3 capas + Mensajería Muy similares a los monitores transaccionales En los anteriores, el foco estaba en la transacción, tratando esta como una unidad de procesamiento, pero manteniendo la inteligencia en el monitor En el caso de la mensajeria, se asume ue el mensaje es inteligente

33 3 capas + Servidores de Aplicación Este tipo de soluciones coloca el cuerpo principal de un sistema a funcionar en un host compartido En general, el App Srv no provee la interfaz de usuario, sino ue se focaliza en: Resolver la lógica de negocio Encargarse del acceso a los datos Caching Manipular transacciones (suelen usar un TM o sistema de mensajería)

34 3 capas + Servidores de Aplicación Al no colocar el grueso de la aplicación en el cliente, se obtienen múltiples ventajas: Evitar problemas de seguridad Disminución de los costos de instalación Facilidad de mantenimiento y escalabilidad

35 Peer to Peer Architectures Una variación del enfoue cliente/servidor En cliente servidor se tienen dos roles claramente marcados Cliente hace pedidos Servidor responde pedidos En Peer to Peer (P2P) tanto cliente como servidor pueden tomar ambos roles Se obtiene una aruitectura mas flexible ante las necesidades del sistema Ejemplos: Napster, Kazaa, Emule

36 Service Oriented Architectures Una aruitectura de software Todas las funciones se definen como servicios independientes Estos tienen interfaces invocables bien definidas Pueden ser llamadas en secuencia para formar procesos de negocio. SOA puede ser una aruitectura, un modelo de programación y una manera de pensar el software

37 Capas de una SOA Presentación Portlets WSRP Otros Composición de Procesos de Negocio Servicios Componentes Empresariales Aruitectura de Integración Calidad de Servicio, Seguridad, Monitoreo, Administración Sistemas Operacionales CRM Mainframes Datamining Sistemas OO

38 Componentes de una SOA Artefactos Servicio Descripción del servicio Operaciones Publicar Localizar Enlazar e invocar Roles Consumidor de servicios Proveedor de servicios Registro de servicios Las SOAs se basan en el paradigma Find, bindand invoke

39 Registro de Servicios Descripción del Servicio Búsueda Publicación Servicio Consumidor de Servicio Enlazado e Invocación Proveedor de Servicios Descripción del Servicio Participantes en un solución tipo SOA

40 Algunas Conclusiones Si un proyecto alcanza un tamaño importante, se hace esencial definir la aruitectura del mismo Si bien tenemos una clasificación clara de las aruitecturas existentes, no todo es blanco y negro Las aruitecturas pueden (y suelen ser) ser heterogéneas Ojo!, esto no implica mezclar a lo loco

41 Middleware Es un termino general usado para denotar a cualuier elemento o agente computacional ue oficia de mediador o pegamento entre múltiples sistemas existentes Puede definirse como una capa de traslación y/o conversión entre dos o mas partes Puede actuar también como integrador y consolidador A pesar de su nombre, es muy común desarrollar un middleware para relacionar dos programas ue necesitan intercambiar información

42 Para ue Middlewares? Si dos aplicaciones se uieren comunicar, hay ue resolver la comunicación entre los procesos. Si las aplicaciones se conectan directamente a soft de red, entonces no se necesita Middleware. Este enfoue dificulta el desarrollo de las aplicaciones: Se deben 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 A manera de ejemplo la invocación remota de un procedimiento, puede realizarse como si fuera local.

43 Programa Programa Sistema Operativo Sistema Red Sin middlewares Sistema Red Sistema Operativo Programa Programa Sistema Operativo Middleware Sistema Red Con middlewares Middleware Sistema Red Sistema Operativo

44 Middleware Sin embargo, hoy día existen soluciones armadas, ue ofrecen middlewares empauetados para diversas situaciones Algunos ejemplos:

45

46

47

48

49 Para ue Middlewares? Una frase ue define el concepto vago de middleware es: El middleware es la interseccion de las tareas ue un ingeniero de redes (networking) no uiere hacer, y las tareas ue un ingeniero de sistemas (applications) no uiere hacer

50 Entonces Por ue son importantes? El middleware surge como un segundo nivel de infraestructura en una empresa Localizado entre el nivel de red y el de aplicación La necesidad de los middlewares surge de: El aumento de aplicaciones El aumento de la distribución El aumento en las necesidades de comunicación