Arquitecturas y Middlewares

8/16/2019 Arquitecturas y Middlewares

1/50

Taller de Sistemas deInformación 2

Clase 1

Arquitecturas y Middlewares

PDF created with pdfFactory Pro trial version www.pdffactory.com

http://www.pdffactory.com/http://www.pdffactory.com/


2/50

Contenido

n Arquitectura de un sistema

n Evolución de las arquitecturas

q Monolíticasq File sharing

q Cliente/Servidor

q En capas

q SOA

n Middlewares




3/50

Sistema

n El concepto de arquitectura esta 100%

relacionado con el de “sistema”

n

¿Que es un sistema?q Un conjunto o colección de elementos

q Relacionados o conectados para llevar a cabo

una función o tarea, que no es realizable por

estos elementos en forma aislada




4/50

Arquitectura

n ¿Que es?

q La estructura organizativa de un sistema de

software

q Una descripción top-down de la estructura de un

sistema

n ¿Compuesta por?

q

Los bloques constructores del mismo (ladrillos)q Sus propiedades externas

q Sus relaciones entre si y con el ambiente




5/50

Arquitectura

n ¿Para que?q Diseñada para que la estructura del sistema

permita las funcionalidades deseadas para el

sisteman Funcionalidades del negocio

n Funcionalidades del sistema

n “Cross-cutting concerns”

n Propiedades verticales

q Diseñada para que el sistema tenga integridad

q Diseñada para facilitar la evolución ymantenimiento del sistema




6/50

Arquitectura

n ¿Para que?

q La integridad de un sistema no puede lograrse en forma

bottom-up

q Si se concentra en las partes, se compromete el todon Perspectiva global, para:

q Resolver los “cross-cutting concerns”

q Resolver las propiedades globales del sistema

q

Balancear las capacidades del sistema de forma decumplir con los requerimientos del mismo

q Resolver lo requerimientos del negocio




7/50

Arquitectura

n La arquitectura por lo general se organiza en vistas,tal y como se hace con los planos de una casa

n Algunas vistas:q Funcionalidades o Lógica

q Implementación

q Desarrollo o Estructural

q Concurrencia o Procesos

q Despliegue o Física

n Existen múltiples lenguajes para expresar las

anterioresq Unified Modelling Language




8/50PDF created with pdfFactory Pro trial version www.pdffactory.com



9/50PDF created with pdfFactory Pro trial version www.pdffactory.com



10/50

Evolución

n La arquitectura de los sistemas ha evolucionado

con el tiempo

n Acompaña los cambios tecnológicos y de

paradigmasn Algunos tipos de arquitectura:

q Centralizadas (Monolíticas)

q Cliente/Servidor (2 niveles)

q En múltiples capas (3 o mas niveles)q Orientadas a servicios (Altamente desacopladas)




11/50

Verticales

1980’s y antesHorizontales

1980’s – 1990’s

Ecosistemas

2000’s +

Evolución de los sistemas de información

M o n o l í t i c a s

E s t r u c t u r a d a s

C l i e n t e / S e r v i d o r

3 C a p

a s

N C a p

a s

O b j e t o s D i s

t r i b u i d o s

C o m p o n e

n t e s

S e r v i c i o s

Evolución de las arquitecturas




12/50

Modelo centralizado

n También conocidas como “Mainframe architectures”

n Toda la “inteligencia”, procesamiento de negocio,interfaces y persistencia, se realiza en un host

centraln Los usuarios interactúan a través de terminales

tontasq Capturan el teclado, envían la información al host, este

procesa y se retorna la pantalla a la terminal

q La interacción puede realizarse tanto en terminales unix,dos/windows u otras




13/50

Un emulador de terminales remotas

IBM Client Access




14/50

Modelo centralizado

n Fueron (y lo son todavía) muy exitosas enámbitos donde se realizan procesamientosintensos de datos

n Por ejemplo, entidades bancarias,procesamiento de tarjetas de crédito, etc.

n Es común encontrar hoy día mainframes enperfecto funcionamiento

n Sus programadores se cotizan en el mercado(escasean)




15/50

Modelo centralizado

n Posee limitantes

q No soporta fácilmente el uso de interfaces

graficas

q Se dificulta el acceso a repositorios de datos

(DBMS) distribuidos

n Hoy día existe un resurgimiento de las

arquitecturas tipo mainframe

q Como soporte para servidores en arquitecturas

cliente servidor distribuidas




16/50

Modelo centralizado

n Empresas como IBM utilizan sus productostipo mainframe para soportar servidoresJ2EE

n El caso de la linea iSeries es un ejemplo deello

n El mainframe ejecuta un sistema operativoparticular el cual ejecuta Websphere

(Application Server)n Las aplicaciones acceden a este como si

entraran a un servidor tradicional




17/50

Modelo de intercambio de archivos

n Conocidas también como “file sharingarchitectures”

n Tiene su punto de partida con la

popularización de las redes de área localn En esta, el servidor (o el PC) descarga en su

espacio local archivos que se encuentran enel servidor

n El procesamiento solicitado por el cliente, esrealizado en el espacio de procesamiento delmismo




18/50

Modelo de intercambio de archivos

n Funcionan cuando el volumen compartido es bajo, lacontención por actualizaciones es baja y el volumentransferido es también bajo

n Un ejemplo de esto, es un sistema desarrollado enVisual Basic con Access

n Los clientes acceden a través de los programas(almacenado en el servidor en un disco compartido) auna base de datos/archivos indexados compartida

n A medida que el uso concurrente aumenta, disminuyela escalabilidad de este tipo de soluciones

q El limite son las decenas de usuarios




19/50

Modelo Cliente/ Servidor

n Como una evolución de las anteriores, surge estemodelo

n El servidor de archivos es reemplazado por una

base de datos (relacional)n Se tienen dos partes claramente diferenciadas, el

cliente y el servidor

n El cliente emite consultas, las cuales sonrespondidas por un servidor

n En este caso, se recibe solo la respuesta, en vez deun archivo compartido.




20/50

Modelo Cliente/ Servidor

n El procesamiento es dividido entre el cliente y el

servidor, balanceando la carga entre ambos

n Existen modelos basados en cliente servidor que

extienden la ideaq Arquitecturas en 2 capas

q Arquitecturas en 3 capas

q Arquitecturas en 3 capas con

n Monitores transaccionales

n Servidores de mensajes

n Servidores de aplicación




21/50

Arquitectura en 2 capas

n La presentación y la lógica de negocio seencuentran en la maquina cliente

n Los datos y el acceso a los mismos, se

resuelve en el servidor n El servidor suele ser mucho mas poderoso

que las maquinas cliente

n Este tipo de arquitecturas es buena cuandoel volumen de los usuarios es altoq En el orden de los cientos




22/50


n Ahora la lógica de negocio puede colocarse tambiéndentro de la base de datos (nuevas herramientas)q Lenguajes de programación en el DBMS (Java, C)

q Procedimientos almacenados

q Triggersn Todos estos enfoques limitan la portabilidad del

sistema construido

n Sin embargo aumentan la eficiencia de los mismos,ya que el procesamiento:q Se hace mas cerca de los datosq Se hace en un entorno mas poderoso (servidor)




23/50


n Un problema de este tipo de arquitecturas, esque el procesamiento de la lógica de negociose hace en el contexto del clienteq Esto dificulta el mantenimiento y deploymentq Implica repetición de elementos de software

n Debo colocar el binario en cada cliente

n O en un servidor de archivos, lo que conceptualmentees lo mismo

n Enfrento problemáticas del estilo DLL hell.

n Para evitar esto, se debe factorizar la capacliente




24/50


n También conocidas como arquitecturas multi-capa (no están limitadas a 3)

n Una capa intermedia se añade entre el

ambiente del cliente y el servidor de base dedatos

n Esta capa puede implementarse de multiplesformasq Servidores de aplicaciónq Monitores transaccionales

q Sistemas de mensajeria




25/50

Ejemplos de arquitecturas en múltiples capas




26/50


n Esta capa intermedia puede:

q Facilitar encolado de peticiones

q Ejecutar aplicaciones y lógica de negocio (en forma de

programas)q Cachear información desde la base de datos

q Definir planificación y prorización del trabajo realizado

n Este tipo de arquitecturas aumentan la performance

en sistemas con grandes volúmenes de uso

q Miles y mas!




27/50


n Una limitación importante de este tipo dearquitecturas, es su complejidad intrínseca

n El proceso de diseño, desarrollo y

especialmente testeo de este tipo desoluciones es muy complejo

n Hoy día existe mucho soporte por parte delas herramientas de desarrollo para este tipo

de sistemasq Eclipse, Visual Studio .NET




28/50




29/50

3 capas + TM

n El tipo mas básico, tiene un monitor transaccionalcomo capa intermedia

n El monitor transaccional es un sistema que:

q Recibe pedidos del clienteq Los encola, prioriza y vuelca contra un manejador

relacional

n Una vez que una transacción es aceptada, el TPacepta la responsabilidad de llevarla a termino

n Esto libera al cliente para que continúe con elprocesamiento




30/50

3 capas + TM

n Existen dos tipos de monitores transaccionales

n “TP Heavy”

q El procesamiento es realizado fuera del DBMS, por

terceras partesq Suelen soportar miles de clientes

n “TP Lite”

q El procesamiento es realizado dentro del DBMS

q La experiencia prueba que por encima de los cientos declientes, comienza la degradacion de performance




31/50

3 capas + TM

n Los monitores transaccionales también

proveen

q La capacidad de actualizar múltiples DBMS en

una sola transacción

n Pool de conexiones

q Conectividad a múltiples fuentes de datos

n Archivos planos, XML, datos no relacionales,

Mainframes

q Priorizar las transacciones

q Seguridad y robustez




32/50

3 capas + Mensajería

n Muy similares a los monitores

transaccionales

n En los anteriores, el foco estaba en la

transacción, tratando esta como una unidad

de procesamiento, pero manteniendo la

“inteligencia” en el monitor

n En el caso de la mensajeria, se asume que elmensaje es “inteligente”




33/50

3 capas + Servidores de Aplicación

n Este tipo de soluciones coloca el cuerpoprincipal de un sistema a funcionar en unhost compartido

n En general, el App Srv no provee la interfazde usuario, sino que se focaliza en:q Resolver la lógica de negocio

q Encargarse del acceso a los datos

q Cachingq Manipular transacciones (suelen usar un TM o

sistema de mensajería)




34/50

3 capas + Servidores de Aplicación

n Al no colocar el grueso de la aplicación en el

cliente, se obtienen múltiples ventajas:

q Evitar problemas de seguridad

q Disminución de los costos de instalación

q Facilidad de mantenimiento y escalabilidad




35/50

Peer to Peer Architectures

n Una variación del enfoque cliente/servidor

n En cliente servidor se tienen dos rolesclaramente marcadosq Cliente hace pedidos

q Servidor responde pedidos

n En Peer to Peer (P2P) tanto cliente comoservidor pueden tomar ambos roles

q Se obtiene una arquitectura mas flexible ante lasnecesidades del sistema

q Ejemplos: Napster, Kazaa, Emule




36/50

Service Oriented Architectures

n Una arquitectura de softwareq Todas las funciones se definen como servicios

independientes

q Estos tienen interfaces invocables bien definidasq Pueden ser llamadas en secuencia para formar

procesos de negocio.

n SOA puede ser una arquitectura, un modelo

de programación y una manera de pensar elsoftware




37/50

Sistemas

Operacionales

Componentes

Empresariales

Servicios

Composición de

Procesos de

Negocio

Presentación

A r q u

i t e c t ur a d eI n t e gr a c i ó n

C al i d a d

d e S er v i c i o , S e g ur i d a

d ,

M on

i t or e o ,A d mi ni s t r a c i ó n

Portlets WSRP Otros

Datamining

Sistemas OO

MainframesCRM

Capas de una SOA




38/50

Componentes de una SOA

n Artefactosq Servicio

q Descripción del servicio

n Operacionesq Publicar

q Localizar

q Enlazar e invocar

n Rolesq Consumidor de servicios

q Proveedor de servicios

q Registro de serviciosn Las SOAs se basan en el paradigma

q Find, bind and invoke




39/50

Consumidor de

Servicio

Registro de

Servicios

Proveedor de

Servicios

Servicio

Descripción del

Servicio

Descripción del

Servicio

Publicación

Enlazado e

Invocación

Búsqueda

Participantes en un solución tipo SOA




40/50

Algunas Conclusiones

n Si un proyecto alcanza un tamaño

importante, se hace esencial definir la

arquitectura del mismo

n Si bien tenemos una clasificación clara de las

arquitecturas existentes, no todo es blanco y

negro

q Las arquitecturas pueden (y suelen ser) serheterogéneas

q Ojo!, esto no implica mezclar a lo loco




41/50

Middleware

n Es un termino general usado para denotar acualquier elemento o agente computacional queoficia de mediador o “pegamento” entre múltiplessistemas existentes

n Puede definirse como una capa de traslación y/oconversión entre dos o mas partes

n Puede actuar también como integrador yconsolidador

n A pesar de su nombre, es muy común desarrollar un

middleware para relacionar dos programas quenecesitan intercambiar información




42/50

¿Para que Middlewares?

n Si dos aplicaciones se quieren comunicar, hay que resolver lacomunicación entre los procesos.

q Si las aplicaciones se conectan directamente a soft de red,entonces no se necesita Middleware.

q Este enfoque dificulta el desarrollo de las aplicaciones:

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

conectar.n El soft de Middleware permite realizar esta conexión a través de

interfases de alto nivel

n

A manera de ejemplo la invocación remota de un procedimiento,puede realizarse como si fuera local.




43/50

SistemaOperativo

Programa

SistemaRed

Programa

SistemaOperativo

SistemaRed

Middleware

Middleware

SistemaOperativo

Programa

SistemaRed

Programa

SistemaOperativo

SistemaRed

Sin middlewares

Con middlewares




44/50

Middleware

n Sin embargo, hoy día existen soluciones armadas, que ofrecen

middlewares empaquetados para diversas situaciones

n Algunos ejemplos:




45/50




46/50




47/50




48/50




49/50

¿Para que Middlewares?

n Una frase que define el concepto vago de

middleware es:

“El middleware es la interseccion de las

tareas que un ingeniero de redes

(networking) no quiere hacer, y las tareas

que un ingeniero de sistemas (applications)no quiere hacer”




50/50

Entonces…¿Por que son importantes?

n El middleware surge como un segundo nivel

de infraestructura en una empresa

n Localizado entre el nivel de red y el de

aplicación

n La necesidad de los middlewares surge de:

q El aumento de aplicaciones

q El aumento de la distribuciónq El aumento en las necesidades de comunicación

Arquitecturas y Middlewares

Documents

Transcript of Arquitecturas y Middlewares