Академический Документы
Профессиональный Документы
Культура Документы
Contenido
n n
Middlewares
Sistema
n
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 Los bloques constructores del mismo (ladrillos) Sus propiedades externas Sus relaciones entre si y con el ambiente
Compuesta por?
q q q
Arquitectura
n
Para que?
q
Diseada para que la estructura del sistema permita las funcionalidades deseadas para el sistema
n n n n
Funcionalidades del negocio Funcionalidades del sistema Cross-cutting concerns Propiedades verticales
q q
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 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
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)
Ecosistemas 2000s +
Objetos Distribuidos
Cliente / Servidor
Componentes
Estructuradas
Monolticas
3 Capas
N Capas
Servicios
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
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
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
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
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
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
Arquitectura en 2 capas
n
Ahora la lgica de negocio puede colocarse tambin dentro de la base de datos (nuevas herramientas)
q q q
n n
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)
Arquitectura en 2 capas
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
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.
Arquitectura en 3 capas
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
Arquitectura en 3 capas
n
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!
Arquitectura en 3 capas
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
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
El procesamiento es realizado fuera del DBMS, por terceras partes Suelen soportar miles de clientes El procesamiento es realizado dentro del DBMS La experiencia prueba que por encima de los cientos de clientes, comienza la degradacion de performance
TP Lite
q q
3 capas + TM
n
q q
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
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)
Evitar problemas de seguridad Disminucin de los costos de instalacin Facilidad de mantenimiento y escalabilidad
Una variacin del enfoque cliente/servidor En cliente servidor se tienen dos roles claramente marcados
q q
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
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
Arquitectura de Integracin
Servicios
Componentes Empresariales
Sistemas Operacionales
CRM
Mainframes Sistemas OO
Datamining
Artefactos
q q
Servicio Descripcin del servicio Publicar Localizar Enlazar e invocar Consumidor de servicios Proveedor de servicios Registro de servicios Find, bind and invoke
Operaciones
q q q
Roles
q q q
Registro de Servicios
Bsqueda
Publicacin
Servicio
Consumidor de Servicio
Enlazado e Invocacin
Proveedor de Servicios
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
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.
Middleware
Con middlewares
Sistema Red
Sistema Red
Middleware
n
Sin embargo, hoy da existen soluciones armadas, que ofrecen middlewares empaquetados para diversas situaciones Algunos ejemplos:
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
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