Arquitecturas aplicativas

Transcripción

1 Arquitecturas aplicativas 100 Arquitectura Arquitectura::= Arte de proyectar y construir Dada la funcionalidad que deberá tener el aplicativo, establecer una división modular para su implementación Enumerar sus elementos (módulos) y las funciones de cada uno Identificar las interrelaciones entre elementos y sus características Identificar los flujos de control 101

2 Arquitectura Monolítica basada en file sharing Aplicación completa (monolítica) FILE server soporte de com. (red) 102 Arquitectura Monolítica basada en file sharing La aplicación se concibe como un único elemento funcionalmente completo, que ejecuta íntegramente en un solo entorno de ejecución (un solo programa corriendo en una máquina) Copias idénticas del programa pueden correr en varias máquinas. La base de datos está implementada como uno o varios archivos y albergada en un única máquina, que permite acceso remoto a estos archivos y provee un mecanismo de locking elemental. El modelo es análogo a dos personas que utilizan un procesador de texto, cada uno en su propia máquina, pero el archivo abierto es el mismo, ubicado en un file server. 103

3 Arq. monolítica con file-sharing Limitaciones Dificultades con el locking (no es fácil hacer corresponder una estructura en disco con un elemento de la base de datos) Gran volumen de tráfico en la red (se deben transferir los archivos para hacer las búsquedas). Esta solución no escala bien, ni se adapta a canales de comunicación de baja capacidad

4 Tráfico modo file sharing 88 seg SELECTS archivo.mdb de 862 Kbytes ubicado en el fileserver. Netbios SMB 74 KB / 794 paq. (6%) (42%) 1.25 MB / 1080 paq. (94%) (58%) Aplicación File server 106 Tráfico hacia el cliente Tamaño paquete [bytes] Tiempo [s] 107

5 Arquitectura Client-server (Fat client) Aplicación, parte 1 (parte cliente) Aplicación, parte 2 Database server soporte de com. (red) 108 Arquitectura Client-server (Fat client) La aplicación se separa en dos: En el server se coloca la lógica de búsqueda de datos, en el cliente todo lo demás. Aparece el concepto de protocolo aplicativo (reglas que determinan la interacción entre C y S) y la posibilidad de que esa interacción se ejecute a distancia, a través de algún mecanismo de transporte adecuado (ej. TCP/IP) 109

6 Arq. Client-Server (fat client) Limitaciones Las implementaciones suelen efectuar varias consultas secuenciales para formar una transacción. Cada consulta involucra al menos un RTD. Esto impacta fuertemente la performance en la WAN La lógica del programa se suele colocar en el cliente, en su mayor parte (salvo los stored procedures). Esto requiere redistribuir el programa cliente (que es grande) cada vez que éste se actualiza. Un programa grande para cada aplicación Existen problemas de seguridad 110 Problemas a resolver Distribución del Cliente Conectividad Configuración de la PC del Cliente Entrenamiento del Usuario Help Desk Seguridad Transaccionado Flexibilidad Escalabilidad 111

7 Arquitectura 3-tier Se divide la aplicación en tres partes: Interfaz con el usuario Lógica de la aplicación Administración de los datos persistentes 112 Arquitectura 3-tier Aplicación, parte 1 (parte cliente) Aplicación, parte 2 Lógica de la aplicación Aplicación, parte 3 Database server soporte de com. (red) 113

8 Tier I: Interfaz con el usuario La máquina cliente tiene un programa genérico (el browser) que sirve como plataforma para las distintas aplicaciones. El browser contiene un cierto run-time support para facilitar la implementación de aplicaciones; éste es extensible mediante clases y plug-ins. La lógica (programa) que debe correr en el cliente se obtiene del server en cada sesión (también existe caching) El programa en el cliente es independiente de la plataforma cliente (java) El programa cliente se comunica con el server de variadas maneras (socket TCP, URL http, RPC, etc.) y en la comunicación puede utilizarse SSL. 114 Tier II: Servidor de lógica de aplicación Recibe, preprocesada, la información y requisitos del usuario Implementa el núcleo de la aplicación relacionada con el negocio del usuario Puede implementarse en forma redundante, en varios servidores de hardware Obtiene los datos que necesita del 3er. tier 115

9 Tier III: Servidor de datos Gateways más DBMS del más diverso tipo Permite, por ejemplo, seguir utilizando sistemas legacy Distintos servidores para distintos datos, previamente en distintas áreas de negocio, ahora pueden integrarse en la aplicación Independencia del proveedor de B.D. 116 Motivaciones Internet permite la concepción de sistemas con acceso remoto, y la incorporación de nuevas modalidades de operación en las empresas El costo es muy bajo, e inclusive puede delegarse Antes de internet, estos sistemas eran sólo posibles para quienes pudieran afrontar el enorme costo de una red privada 117

10 Ejemplos Compra a distancia Home banking Servicios por subscripción (publicaciones, software) Notificación automática Publicación personal Virtual libraries Implementación del soporte informático de las organizaciones 118 Network IPC 101 Berkeley Sockets RPC 119

11 Sockets: Secuencia en cliente y servidor - UDP client server sock=socket(family, type, proto) socket() bind() sendto() select() recvfrom() request reply bind(sock, myaddr,...) select() recvfrom(sock, backlog) sendto(sock, buff,...) Sockets: Secuencia en cliente y servidor - TCP client server sock=socket(family, type, proto) bind(sock, myaddr,...) socket() connect() 3-way handshake listen(sock, backlog) select() write() read() request reply accept(sock, peeraddr,...) read(sock, buff,...) write(sock, buff,...)

12 Servicio de múltiples conexiones en servers server master socket (1) server slave socket(3) server slave socket (2) client socket socket bind listen select socket connect accept read accept write read request reply write read write request reply close RPCgen

13 124 RPCGEN : date.x Program DATE_PROG { version DATE_VERS { long BIN_DATE(void) = 1 ; string STR_DATE = 2 ; } = 1 } = 0x

14 Cliente : rdate.c #include <rpc/rpc.h> #include date.h... server= argv[1] ; cl=clnt_create(server, DATE_PROG, DATE_VERS, udp );... /* llamada a bin_date */ lresult = bin_date_1(null, cl); printf( La hora en %s es %ld, server, *lresult); /* llamada a str_date para convertir lresult*/ sresult = str_date_1(lresult, cl); printf( La hora en %s es %s, server, *sresult); Server : dateproc.c... long * bin_date_1() { static long timeval ; long time() ; /* Unix library */ timeval = time((long*) 0) ; return (&timeval) ; } char **str_date_1(bintime) long * bintime ; { static char *ptr ; char ctime() ; /* Unix library */ ptr = ctime(bintime) ; return (&ptr) ; }