Middlewares

Taller de Sistemas de
Informacin 2
Clase 1
Arquitecturas y Middlewares
PDF created with pdfFactory Pro trial version www.pdffactory.com
Contenido
n
n
Arquitectura de un sistema
Evolucin de las arquitecturas
q
q
q
q
q
Monolticas
File sharing
Cliente/Servidor
En capas
SOA
Middlewares
Sistema
n
El concepto de arquitectura esta 100%

relacionado con el de sistema
Que es un sistema?
q
q
Un conjunto o coleccin de elementos

Relacionados o conectados para llevar a cabo
una funcin o tarea, que no es realizable por
estos elementos en forma aislada
Arquitectura
n
Que es?
q
La estructura organizativa de un sistema de

software
Una descripcin top-down de la estructura de un
sistema
Compuesta por?
q
q
q
Los bloques constructores del mismo (ladrillos)

Sus propiedades externas
Sus relaciones entre si y con el ambiente
Arquitectura
n
Para que?
q
Diseada para que la estructura del sistema

permita las funcionalidades deseadas para el
sistema
n
n
n
n
q
q
Funcionalidades del negocio

Funcionalidades del sistema
Cross-cutting concerns
Propiedades verticales
Diseada para que el sistema tenga integridad

Diseada para facilitar la evolucin y
mantenimiento del sistema
Arquitectura
n
Para que?
q
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:

q
q
q
Resolver los cross-cutting concerns

Resolver las propiedades globales del sistema
Balancear las capacidades del sistema de forma de
cumplir con los requerimientos del mismo
Resolver lo requerimientos del negocio
Arquitectura
n
n
La arquitectura por lo general se organiza en vistas,

tal y como se hace con los planos de una casa
Algunas vistas:
q
q
q
q
q
Funcionalidades o Lgica
Implementacin
Desarrollo o Estructural
Concurrencia o Procesos
Despliegue o Fsica
Existen mltiples lenguajes para expresar las

anteriores
q
Unified Modelling Language
Evolucin
n
La arquitectura de los sistemas ha evolucionado

con el tiempo
Acompaa los cambios tecnolgicos y de
paradigmas
Algunos tipos de arquitectura:
q
q
q
q
Centralizadas (Monolticas)
Cliente/Servidor (2 niveles)
En mltiples capas (3 o mas niveles)
Orientadas a servicios (Altamente desacopladas)
Verticales
1980s y antes
Ecosistemas
2000s +
Horizontales
1980s 1990s
Evolucin de las arquitecturas

Servicios
Componentes
Objetos Distribuidos
N Capas
3 Capas
Cliente / Servidor
Estructuradas
Monolticas
Evolucin de los sistemas de informacin
Modelo centralizado
n
n
Tambin conocidas como Mainframe architectures

Toda la inteligencia, procesamiento de negocio,
interfaces y persistencia, se realiza en un host
central
Los usuarios interactan a travs de terminales
tontas
q
Capturan el teclado, envan la informacin al host, este

procesa y se retorna la pantalla a la terminal
La interaccin puede realizarse tanto en terminales unix,
dos/windows u otras
Un emulador de terminales remotas

IBM Client Access
Modelo centralizado
n
Fueron (y lo son todava) muy exitosas en

mbitos donde se realizan procesamientos
intensos de datos
Por ejemplo, entidades bancarias,
procesamiento de tarjetas de crdito, etc.
Es comn encontrar hoy da mainframes en
perfecto funcionamiento
Sus programadores se cotizan en el mercado
(escasean)
Modelo centralizado
n
Posee limitantes
q
No soporta fcilmente el uso de interfaces

graficas
Se dificulta el acceso a repositorios de datos
(DBMS) distribuidos
Hoy da existe un resurgimiento de las

arquitecturas tipo mainframe
q
Como soporte para servidores en arquitecturas

cliente servidor distribuidas
Modelo centralizado
n
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
Modelo de intercambio de archivos

n
Conocidas tambin como file sharing

architectures
Tiene su punto de partida con la
popularizacin de las redes de rea local
En esta, el servidor (o el PC) descarga en su
espacio local archivos que se encuentran en
el servidor
El procesamiento solicitado por el cliente, es
realizado en el espacio de procesamiento del
mismo
Modelo de intercambio de archivos

n
Funcionan cuando el volumen compartido es bajo, la

contencin por actualizaciones es baja y el volumen
transferido es tambin bajo
Un ejemplo de esto, es un sistema desarrollado en
Visual Basic con Access
Los clientes acceden a travs de los programas
(almacenado en el servidor en un disco compartido) a
una base de datos/archivos indexados compartida
A medida que el uso concurrente aumenta, disminuye
la escalabilidad de este tipo de soluciones
q El limite son las decenas de usuarios
Modelo Cliente/Servidor
n
Como una evolucin 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.
Modelo Cliente/Servidor
n
El procesamiento es dividido entre el cliente y el

servidor, balanceando la carga entre ambos
Existen modelos basados en cliente servidor que
extienden la idea
q
q
q
Arquitecturas en 2 capas
Arquitecturas en 3 capas
Arquitecturas en 3 capas con
n
n
n
Monitores transaccionales
Servidores de mensajes
Servidores de aplicacin
Arquitectura en 2 capas
n
La presentacin y la lgica de negocio se

encuentran en la maquina cliente
Los datos y el acceso a los mismos, se
resuelve en el servidor
El servidor suele ser mucho mas poderoso
que las maquinas cliente
Este tipo de arquitecturas es buena cuando
el volumen de los usuarios es alto
q
En el orden de los cientos
n
Ahora la lgica de negocio puede colocarse tambin

dentro de la base de datos (nuevas herramientas)
q
q
q
n
n
Lenguajes de programacin en el DBMS (Java, C)

Procedimientos almacenados
Triggers
Todos estos enfoques limitan la portabilidad del

sistema construido
Sin embargo aumentan la eficiencia de los mismos,
ya que el procesamiento:
q
q
Se hace mas cerca de los datos

Se hace en un entorno mas poderoso (servidor)
n
Un problema de este tipo de arquitecturas, es

que el procesamiento de la lgica de negocio
se hace en el contexto del cliente
q
q
Esto dificulta el mantenimiento y deployment

Implica repeticin de elementos de software
n
n
Debo colocar el binario en cada cliente

O en un servidor de archivos, lo que conceptualmente
es lo mismo
Enfrento problemticas del estilo DLL hell.
Para evitar esto, se debe factorizar la capa

cliente
n
Tambin conocidas como arquitecturas multicapa (no estn limitadas a 3)

Una capa intermedia se aade entre el
ambiente del cliente y el servidor de base de
datos
Esta capa puede implementarse de multiples
formas
q
q
q
Servidores de aplicacin
Monitores transaccionales
Sistemas de mensajeria
Ejemplos de arquitecturas en mltiples capas
n
Esta capa intermedia puede:

q
q
q
q
Facilitar encolado de peticiones

Ejecutar aplicaciones y lgica de negocio (en forma de
programas)
Cachear informacin desde la base de datos
Definir planificacin y prorizacin del trabajo realizado
Este tipo de arquitecturas aumentan la performance

en sistemas con grandes volmenes de uso
q
Miles y mas!
n
Una limitacin importante de este tipo de

arquitecturas, es su complejidad intrnseca
El proceso de diseo, desarrollo y
especialmente testeo de este tipo de
soluciones es muy complejo
Hoy da existe mucho soporte por parte de
las herramientas de desarrollo para este tipo
de sistemas
q
Eclipse, Visual Studio .NET
3 capas + TM
n
El tipo mas bsico, tiene un monitor transaccional

como capa intermedia
El monitor transaccional es un sistema que:
q
q
Recibe pedidos del cliente

Los encola, prioriza y vuelca contra un manejador
relacional
Una vez que una transaccin es aceptada, el TP

acepta la responsabilidad de llevarla a termino
Esto libera al cliente para que contine con el
procesamiento
3 capas + TM
n
n
Existen dos tipos de monitores transaccionales

TP Heavy
q
El procesamiento es realizado fuera del DBMS, por

terceras partes
Suelen soportar miles de clientes
TP Lite
q
q
El procesamiento es realizado dentro del DBMS

La experiencia prueba que por encima de los cientos de
clientes, comienza la degradacion de performance
3 capas + TM
n
Los monitores transaccionales tambin

proveen
q
La capacidad de actualizar mltiples DBMS en

una sola transaccin
n
Conectividad a mltiples fuentes de datos

n
q
q
Pool de conexiones
Archivos planos, XML, datos no relacionales,
Mainframes
Priorizar las transacciones

Seguridad y robustez
3 capas + Mensajera
n
Muy similares a los monitores

transaccionales
En los anteriores, el foco estaba en la
transaccin, tratando esta como una unidad
de procesamiento, pero manteniendo la
inteligencia en el monitor
En el caso de la mensajeria, se asume que el
mensaje es inteligente
3 capas + Servidores de Aplicacin

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 que se focaliza en:
q
q
q
q
Resolver la lgica de negocio

Encargarse del acceso a los datos
Caching
Manipular transacciones (suelen usar un TM o
sistema de mensajera)
3 capas + Servidores de Aplicacin

n
Al no colocar el grueso de la aplicacin en el

cliente, se obtienen mltiples ventajas:
q
q
q
Evitar problemas de seguridad

Disminucin de los costos de instalacin
Facilidad de mantenimiento y escalabilidad
Peer to Peer Architectures

n
n
Una variacin del enfoque cliente/servidor

En cliente servidor se tienen dos roles
claramente marcados
q
q
Cliente hace pedidos

Servidor responde pedidos
En Peer to Peer (P2P) tanto cliente como

servidor pueden tomar ambos roles
q
Se obtiene una arquitectura mas flexible ante las

necesidades del sistema
Ejemplos: Napster, Kazaa, Emule
Service Oriented Architectures

n
Una arquitectura de software

q
q
q
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 arquitectura, un modelo

de programacin y una manera de pensar el
software
Capas de una SOA

Presentacin
Portlets
WSRP
Otros
Servicios
Componentes
Empresariales
Sistemas
Operacionales
CRM
Mainframes
Datamining
Sistemas OO
Calidad de Servicio, Seguridad,

Monitoreo, Administracin
Arquitectura de Integracin
Composicin de
Procesos de
Negocio
Componentes de una SOA

n
Artefactos
q
q
Operaciones
q
q
q
Publicar
Localizar
Enlazar e invocar
Roles
q
q
q
Servicio
Descripcin del servicio
Consumidor de servicios
Proveedor de servicios
Registro de servicios
Las SOAs se basan en el paradigma

q
Find, bind and invoke
Descripcin del
Servicio
Registro de
Servicios
Publicacin
Bsqueda
Servicio
Consumidor de
Servicio
Enlazado e
Invocacin
Proveedor de
Servicios
Participantes en un solucin tipo SOA
Descripcin del
Servicio
Algunas Conclusiones
n
Si un proyecto alcanza un tamao

importante, se hace esencial definir la
arquitectura del mismo
Si bien tenemos una clasificacin clara de las
arquitecturas existentes, no todo es blanco y
negro
q
Las arquitecturas pueden (y suelen ser) ser

heterogneas
Ojo!, esto no implica mezclar a lo loco
Middleware
n
n
n
n
Es un termino general usado para denotar a

cualquier elemento o agente computacional que
oficia de mediador o pegamento entre mltiples
sistemas existentes
Puede definirse como una capa de traslacin y/o
conversin entre dos o mas partes
Puede actuar tambin como integrador y
consolidador
A pesar de su nombre, es muy comn desarrollar un
middleware para relacionar dos programas que
necesitan intercambiar informacin
Para que Middlewares?

n
n
n
Si dos aplicaciones se quieren comunicar, hay que resolver la

comunicacin 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 mdulos de bajo nivel.
n Este desarrollo se repite para cada aplicacin a
conectar.
El soft de Middleware permite realizar esta conexin a travs de
interfases de alto nivel
A manera de ejemplo la invocacin remota de un procedimiento,
puede realizarse como si fuera local.
Programa
Programa
Sistema
Operativo
Sistema
Operativo
Sin middlewares
Sistema
Red
Sistema
Red
Programa
Sistema
Operativo
Middleware
Programa
Con middlewares
Sistema
Red
Sistema
Middleware Operativo
Sistema
Red
Middleware
n
Sin embargo, hoy da existen soluciones armadas, que ofrecen

middlewares empaquetados para diversas situaciones
Algunos ejemplos:
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
EntoncesPor que son importantes?

n
El middleware surge como un segundo nivel

de infraestructura en una empresa
Localizado entre el nivel de red y el de
aplicacin
La necesidad de los middlewares surge de:
q
q
q
El aumento de aplicaciones
El aumento de la distribucin
El aumento en las necesidades de comunicacin

Middlewares

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Middlewares

Cargado por

Copyright:

Formatos disponibles

Taller de Sistemas de

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

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

El concepto de arquitectura esta 100%

Un conjunto o coleccin de elementos

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

La estructura organizativa de un sistema de

Los bloques constructores del mismo (ladrillos)

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

Diseada para que la estructura del sistema

Funcionalidades del negocio

Diseada para que el sistema tenga integridad

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

La integridad de un sistema no puede lograrse en forma

Perspectiva global, para:

Resolver los cross-cutting concerns

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

La arquitectura por lo general se organiza en vistas,

Existen mltiples lenguajes para expresar las

Unified Modelling Language

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

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

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

La arquitectura de los sistemas ha evolucionado

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

Evolucin de las arquitecturas

Evolucin de los sistemas de informacin

Tambin conocidas como Mainframe architectures

Capturan el teclado, envan la informacin al host, este

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

Un emulador de terminales remotas

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

Fueron (y lo son todava) muy exitosas en

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

No soporta fcilmente el uso de interfaces

Hoy da existe un resurgimiento de las

Como soporte para servidores en arquitecturas

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

Empresas como IBM utilizan sus productos

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

Modelo de intercambio de archivos

Conocidas tambin como file sharing

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

Modelo de intercambio de archivos

Funcionan cuando el volumen compartido es bajo, la

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

Como una evolucin de las anteriores, surge este

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

El procesamiento es dividido entre el cliente y el

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

La presentacin y la lgica de negocio se

En el orden de los cientos

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

Ahora la lgica de negocio puede colocarse tambin

Lenguajes de programacin en el DBMS (Java, C)

Todos estos enfoques limitan la portabilidad del

Se hace mas cerca de los datos

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

Un problema de este tipo de arquitecturas, es

Esto dificulta el mantenimiento y deployment

Debo colocar el binario en cada cliente

Para evitar esto, se debe factorizar la capa

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

Tambin conocidas como arquitecturas multicapa (no estn limitadas a 3)