INSTITUTO TECNOLOGICO DE CONKAL.

PANORAMA GENERAL DE LAS APLICACONES DISTRIBUIDAS.

Desarrollo de aplicaciones para ambientes distribuidas.
Que presenta:

JUAN FRANCISCO CANCHE DAVID.

Conkal, Yucatn, Mxico 2013.

Unidad 2.-Arquitectura de aplicaciones distribuidas. Introduccin: Las aplicaciones distribuidas son la razn de ser de las redes de computadores. La razn de ser de las aplicaciones distribuidas son las personas organizadas socialmente, que incluye estructuras organizadas en forma de universidades, empresas, asociaciones, comunidades, etc. que se comunican, cooperan, coordinan mediante intercambios de informacin. Esa informacin se representa en forma estructurada como pequeas estructuras de datos, como mensajes o documentos estructurados, como medios continuos (audio/video); Los intercambios los inician y/o reciben: personas (correo, web) o procesos (comercio electrnico) siguiendo ciertos protocolos. Estas actividades ocurren en Internet, por lo que hay que atender y soportar la diversidad entre las partes que interaccionan, tener en cuenta el tamao de la red (escala), considerar la evolucin en forma de extensiones o cambios futuros), el coste y por tanto la eficiencia para poder funcionar en redes de baja capacidad o alto coste como por ejemplo las redes mviles.

2.1 Capa de interfaz de usuario.

Interfaces de usuario y su arquitectura. Arquitectura de interfaces grficas en ambiente distribuidos. El modo en que el usuario se comunica con una aplicacin para solicitar los recursos del sistema operativo constituye la interfaz del mismo. La interfaz es particularmente importante para establecer una vinculacin amigable entre el usuario de la computadora y la aplicacin. Histricamente las interfaces estuvieron basadas en comandos formateados por palabras clave que se combinaban con otras cadenas de caracteres (sintaxis) para ser interpretados por el sistema operativo. Estas interfaces se denominan; interfaces orientadas a carcter . Un ejemplo clsico de una interfaz orientada a carcter es el COMMAND de MS-DOS. Interfaz de modo carcter. En esta clase de interfaz entre la aplicacin y el usuario en la que las rdenes se pasan en ASCII existen algunas ventajas y desventajas: Las ventajas que tienen las interfaces orientadas a carcter son su simplicidad, confiabilidad y poco costo en el desarrollo del sistema operativo que las soporta. Las desventajas son que requieren un usuario calificado que estudie y conozca los comandos, lo cual resulta muy restrictivo para la difusin del uso de las computadoras. Uno de los beneficios de los sistemas cooperativos visto anteriormente es que: para el usuario lo que importa es lo que ste ve en la pantalla, la presentacin. Al software que simula la presentacin de un sistema se le conoce como emulador de terminal, el cul debe ser interactivo como cuando uno redacta un informe en una mquina de escribir, lo que el usuario teclea se ve reflejado en

el documento, una terminal la cul solo realiza tareas de presentacin debera funcionar de la misma manera. Principio general de emulacin de terminal. La terminal tradicional de minicomputadoras o mainframe tiene que ejecutar dos tipos bsicos de comandos. Primero, debe desplegar los caracteres enviados por el servidor remoto. Segundo, debe enviar al servidor los caracteres introducidos por el usuario o solicitados por el servidor. Algunas terminales realizan tareas adicionales. Ejemplos de emuladores de terminal basados en carcter son: ANSI.SYS, y VT-100. Cuando los caracteres llegan desde el servidor, la terminal no puede simplemente escribirlos en la pantalla y avanzar el cursor, la terminal debe analizar la cadena de caracteres para detectar posibles comandos. De acuerdo al estndar ANSI X3.64 los comandos son identificados por una secuencia de dos caracteres ascii, ESC (ascii=27h) y [ (ascii=5bh) ]. Ejemplo: ESC [2]: Cuando la terminal recibe este comando, limpia la pantalla. Una interfaz basada en caracteres, por lo general ofrece los siguientes servicios: Comandos de posicionamiento del cursor. Comandos para limpiar la pantalla. Comandos para indicar los atributos de los caracteres.

Interfaz grfica de usuario. En la actualidad millones de nuevos usuarios de las computadoras se han beneficiado con la aparicin de las Interfaces Grficas de Usuario/Graphical User Interface, (GUI), las computadoras pueden dar la apariencia de un

escritorio comn y corriente de una oficina, mostrando iconos, imgenes y otros objetos visuales los cuales permiten que el usuario se acerque ms a las computadoras. Caractersticas de las interfaces grficas de usuarios. En general, las GUIs presentan informacin en reas rectangulares en la pantalla llamadas ventanas. Las ventanas se pueden sobreponer. Al usuario se le permite manipular la ventana y su contenido, puede cambiar el tamao y la posicin. Las ventanas pueden contener objetos los cuales pueden ser seleccionados haciendo clic con el botn del ratn una vez que el indicador del ratn se encuentra sobre el dibujo del objeto al cual se le llama icono. El tamao total de una ventana puede ser reducido a un icono, y el usuario puede restablecer la ventana a su tamao normal. GUIs avanzados eliminan completamente la necesidad de teclear comandos, permitindole al usuario seleccionar comandos desde mens usando el ratn o teclas de funcin. Las ventanas tambin pueden contener barras de desplazamiento y botones. En la programacin con GUIs se debe estar atento para aceptar y procesar eventos asncronos iniciados por el usuario o por el sistema. Tipos de eventos El conjunto de eventos generados tanto por el usuario o por el sistema los cuales deben ser soportados por las implementaciones de GUIs son los siguientes: Evento de ratn. Ocurre cuando el usuario mueve el apuntador del ratn dentro o fuera de una ventana, hace clic en el botn dentro o fuera de la ventana o libera el botn del ratn. Evento de teclado. Ocurre cuando el usuario oprime o libera una tecla del teclado.

Evento de men. Ocurre cuando el usuario selecciona un comando desde un men. Evento de actualizacin de ventana. Ocurre cuando una porcin de la imagen de la presentacin de una aplicacin ha sido alterada (posiblemente por que se sobrepuso otra ventana) y se tenga que restablecer. Evento de ajuste. Ocurre cuando el usuario ha modificado el tamao de una ventana. Evento de Activacin/Desactivacin. Se generan por la GUI para permitirle al usuario activar y desactivar ventanas. Evento de Inicializar/Terminar. Ocurre cuando una entidad GUI se ha creado o destruido. Distribucin de eventos. Los eventos deben ser procesados por la lgica de presentacin en cooperacin con la lgica de procesamiento. El procesamiento puede ser distribuido entre el mismo GUI, la lgica de la aplicacin y el API (Aplication Programming Interface) del GUI. Un API es un conjunto de rutinas de un GUI especfico que hacen funciones como crear ventanas y desplegar varios grficos. El procesamiento de los eventos se puede distribuir de la siguiente manera: Modelo de ciclo de evento. Especfica que una aplicacin debe contener un ciclo de evento. El ciclo de evento llama a una rutina de librera en particular para ver si hay eventos pendientes. Cada evento pendiente causa que la aplicacin atienda (despache) el evento antes de regresar el control al ciclo de evento.

Modelo de aviso (callback) de evento. Requiere que la aplicacin registre una funcin manejadora de eventos por cada entidad GUI que crea, de esta manera se libera a la aplicacin de una sobre carga con el ciclo de evento. Cuando el GUI detecta un evento (de teclado, men, etc.) para una ventana, llama a la rutina apropiada de la aplicacin. La aplicacin tiene el control slo cuando se inicia una entidad GUI o cuando se llama a una de sus rutinas de atencin a eventos. Modelo hbrido. Combina el modelo ciclo de evento y el modelo aviso de evento. Microsoft Windows emplea un modelo (donde una aplicacin debe contener un ciclo de evento) el cul llama a una rutina para obtener el siguiente evento. En ese momento, una aplicacin puede llamar a otra rutina del API, el cual puede, en su momento, llamar al manejador de eventos de la aplicacin. TIPOS DE INTERFACES (Front-end, back-end). Bsicamente existen dos tipos de interfaces, las interfaces estticas y las interfaces dinmicas. Las interfaces estticas son aquellas que no tienen cambio y son difciles de modificar y por su ubicacin pueden ser: De propsito especial (stand-alone). Centralizado (novell). Distribuido (internet).

Las interfaces dinmicas son aquellas que cambian de acuerdo a los requerimientos del usuario y por su uso pueden ser: Front-End. Back-End.

Interfaz Front-End. Es una aplicacin donde los usuarios interactan directamente con las funciones del sistema, cubre todas las interfaces con las cuales un usuario interacta con los sistemas, ya sean locales o remotos, sus funciones principales son: Diseo de formatos. Presentacin. Lgica de la aplicacin. Manipulacin de datos. Herramientas de consulta. Utileras/mens

Interfaz Back-End. Es un conjunto de elementos (programas) que sirven como complemento de una interfaz Front-End. Ayuda en la administracin, control y configuracin de los sistemas teniendo un acceso directo a los recursos (base de datos, comunicaciones, servidores, etc.), que el sistema requiere, entre sus funciones principales se tienen: Administracin de la memoria. Seguridad. Manejo de base de datos. Procesamiento remoto.

2.4 Integracin de sistemas heredados. Anlisis de proyectos con sistemas heredados Opciones, no insistencia Cuando los clientes vienen a nosotros con una estructura de produccin existente ya sea un sitio Web actual o un flujo de trabajo de empaque y etiquetado comprendemos que sus factores internos de xito de un proyecto completo pueden dictar diversos niveles de rediseo y de ingeniera de proceso. Nunca abordamos a nuestros clientes con nuestra solucin preferida, y diciendo esencialmente as es como se debe reconfigurar esta estructura. Comprendemos que la produccin multilinge es uno de los elementos de lo que puede ser una serie completa de factores de xito del proyecto.

Nuestro anlisis de proyectos con sistemas heredados se orienta a brindar a nuestros clientes un espectro completo de las opciones de calidad disponibles para crear una funcin multilinge con mayor o menor impacto sobre la estructura existente. Nuestros ingenieros analizarn minuciosamente el proyecto existente y crearn una jerarqua de enfoques posibles que podemos tomar en asociacin para construir un flujo multilinge sin sobresaltos. Esto deja la decisin final sobre el correcto equilibrio entre la eficiencia total y la invasividad, a quienes corresponde: nuestros clientes. Adaptacin de fuentes heredadas Nosotros respetamos el valor de los activos de produccin de informacin existentes. Invertimos ms que cualquier otra agencia en herramientas y capacitacin que permitan a nuestro departamento de produccin adaptar fuentes heredadas, en lugar de desecharlas o reconstruirlas. Ms an, nuestro departamento tcnico est siempre disponible para consultas sobre los pasos que nuestros clientes pueden realizar internamente para ayudar a migrar los materiales existentes a fin de trabajar sin sobresaltos en una implementacin multilinge. Monitoreo automatizado Una herramienta clave en el esfuerzo para adaptar fuentes heredadas en lnea sin una reingeniera demasiado invasiva, es nuestro servicio de monitoreo automatizado. Esto permite a sus diseadores y administradores actualizar diseo e informacin cuando sea necesario, y con una nica notificacin al sistema de monitoreo automtico, el material que se ha modificado es sealado y el registro es dirigido al proceso de traduccin y localizacin automticamente. Para fuentes en lnea existentes con un flujo de informacin bajo a moderado, esta puede ser una manera econmicamente eficiente de manejar fuentes en lnea multilinges con una pequea inversin adicional. 2.5 Distribucin de elementos de una aplicacin. Cada aplicacin considera el nodo local como una cache de los recursos disponibles en todo el sistema distribuido. En el caso de aplicaciones centralizadas, stas se limitan a utilizar dicha cache ignorando la ubicacin de los recursos (pensando que son locales). En cambio, las distribuidas pueden solicitar la asignacin de recursos en las ubicaciones que deseen y controlar la revocacin de tal modo que se mantengan en el nodo local (en la cache) los recursos convenientes (revocando primero aquellos recursos que sea ms barato traer al nodo local, y no aquellos que sea costoso volver a obtener debido a su ubicacin u otros factores). En este sentido es crucial que el kernel permita a las aplicaciones escoger las unidades de recurso que han de revocarse, de otro modo el sistema escogera l mismo las unidades a revocar y ello sin tener una idea exacta de para qu se emplea cada una de ellas. Sorprendentemente, en un DAMN, no hay un nico modelo de distribucin de recursos. El kernel permite que peticiones locales al sistema puedan operar con recursos remotos, eso es todo lo que hace.

Por un lado, una aplicacin centralizada se puede distribuir ``automticamente'' interponiendo entre ella y el sistema un algoritmo distribuido de asignacin y revocacin de recursos. De este modo la distribucin ser como sigue:

Ante una peticin de recursos, el algoritmo de asignacin puede solicitar recursos remotos (o locales) al kernel. La aplicacin realizar peticiones al sistema empleando dichos recursos de manera transparente. Sean stos locales o remotos, el kernel atender las peticiones. Ante una eventual revocacin, el algoritmo de revocacin empleado puede optar por eliminar primero los recursos que sean mas ``baratos'' en trminos de posicin y uso.

Por otro lado, una aplicacin distribuida puede emplear algoritmos especficos de asignacin y revocacin sin necesidad de conformarse con un algoritmo general que funcione bien en el caso medio. Un posible modelo para implementar estos algoritmos de asignacin y revocacin podra ser el campo computacional [163], donde las relaciones entre distintos objetos se tienen en cuenta para crear, destruir y migrar objetos. Por ltimo, conviene dejar claro que en un DAMN no slo se distribuyen las IPCs, esto es, no slo se permiten interacciones entre elementos en distintos nodos. Para cualquier servicio del sistema, la operacin se procesa en el nodo local tanto como sea posible. Cuando el sistema ve que el recurso es remoto es la propia implementacin del servicio la que contacta con el nodo remoto usando protocolos especficos de cada aplicacin (esto es, realizando una upcall). Esto no es lo mismo que emplear una IPC distribuida que alcanza un ncleo remoto sin que el local se entere de ello. Si se distribuyen slo las IPCs podemos tener problemas en el uso de referencias a memoria de usuario en las llamadas al sistema (una referencia local no es vlida en el nodo remoto). Estas pueden ocasionar mensajes extra en la red o el envi de datos innecesarios. A modo de ejemplo, la figura 2.5 muestra (a) cmo las aplicaciones utilizan la distribucin del sistema en kernels centralizados convencionales con IPC distribuida (como en el caso de Mach con un netmsgserver que extiende la IPC de Mach a la red) y (b) cmo pueden emplear su propia distribucin en un DAMN.

Figure: Distribucin del sistema en kernels (a) y DAMNs (b). En la figura se aprecian varios procesos de usuario (crculos) que efectan llamadas a servicios del sistema (lnea continua) y a servicios de un proceso remoto (lnea discontinua). En el caso de un kernel tradicional todos los procesos de usuario se ven obligados a utilizar un mismo protocolo de transporte. En un DAMN cada aplicacin puede utilizar su propio transporte (un servicio de datagramas, uno orientado a conexin, con o sin cifrado, etc.). Lo que es ms, en el caso de la llamada al sistema, un kernel tradicional no permite llamadas al sistema desde otros nodos. Es el propio kernel el que, imponiendo su modelo de distribucin, utiliza el sistema de transporte para permitir que sus abstracciones utilicen recursos remotos (como denota la separacin en varios tramos del camino de la llamada al sistema en la figura). En un DAMN el sistema se limita a encaminar aquellas peticiones dirigidas a recursos remotos al servidor especificado por la aplicacin involucrada. Esto afecta tanto a las llamadas a servicios del sistema como a los mensajes de aplicacin dirigidos a otros procesos de usuario.