INSTITUTO TECNOLOGICO DE APIZACODESARROLLO DE APLICACIONES DE AMBIENTES DISTRIBUIDAS. CATEDRATICO: HIGINIO NAVA BAUTISTA

28/11/2012UNIDAD 2- 6ALUMNO: MARIBEL GUZMAN FLORES.

Contenido

UNIDAD 2..................................................................................................................................4

ARQUITECTURA DE APLICACIONES DISTRIBUIDAS....................................................4

2.1 Capa de interfaz de usuario..........................................................................................4

2.2 ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS. . .10

2.3 ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD..................................12

2.4 Integración de sistemas heredados...........................................................................14

2.5 Distribución de elementos de una aplicación...........................................................15

2.6 Integración de tecnologías homogéneas y heterogéneas......................................17

Existen diferentes motivos para la heterogeneidad y homogeneidad...................................17

3.1 Diseño e implementación de manejo de datos........................................................18

3.2 Diseño de procesamiento de datos...........................................................................19

3.3 Diseño de interfaz de usuario.....................................................................................20

4.1 Construcción de componentes...................................................................................23

5.1 Lenguajes de Mercado................................................................................................27

5.2 Tecnologías para implementación de interfaces de usuario..................................29

Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y

servicios: Apéndices............................................................................................................29

5.3 Programación................................................................................................................30

5.3.1 Del Lado del Cliente..................................................................................................31

5.3.1 Del Lado del Servidor...............................................................................................31

6.1 Asignación de las Partes de la Aplicación................................................................32

6.2 Distribución de la Aplicación.......................................................................................33

6.3 Instalación de los Componentes................................................................................34

6.4 Configuración de los Componentes...........................................................................35

6.5 Configuración de la Aplicación...................................................................................36

6.6 Evaluar Desempeño.....................................................................................................37

6.7 Optimización del Desempeño.....................................................................................38

UNIDAD 2.

ARQUITECTURA DE APLICACIONES DISTRIBUIDAS.

2.1 Capa de interfaz de usuario.

Interfaces de usuario y su arquitectura

ARQUITECTURA DE INTERFACES GRÁFICAS EN AMBIENTE DISTRIBUIDOS.

El modo en que el usuario se comunica con una aplicación para solicitar los recursos del sistema operativo constituye la interfaz del mismo. La interfaz es particularmente importante para establecer una vinculación amigable entre el usuario de la computadora y la aplicación.

Históricamente 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 carácter. Un ejemplo clásico de una interfaz orientada a carácter es el COMMAND de MS-DOS.

Modelo de dos capas.

Modelo de tres capas.

Modelo de N capas.

Interfaz de modo carácter

En esta clase de interfaz entre la aplicación 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 carácter 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 difusión 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 presentación. Al software que simula la presentación de un sistema se le conoce como emulador de terminal, el cuál debe ser interactivo como cuando uno redacta un informe en una máquina de escribir, lo que el usuario teclea se ve reflejado en el documento, una terminal la cual solo realiza tareas de presentación debería funcionar de la

misma manera.

Principio general de emulación de terminal

La terminal tradicional de minicomputadoras o mainframe tiene que ejecutar dos tipos básicos 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 carácter 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 estándar ANSI X3.64 los comandos son identificados por una secuencia de dos caracteres ascii, ESC (ascii=27h) y [ (ascii=5bh) ].

Características de las interfaces gráficas de usuarios

En general, las GUI´s presentan información 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 tamaño y la posición. Las ventanas pueden contener objetos los cuales pueden ser seleccionados haciendo clic con el botón del ratón una vez que el indicador del ratón se encuentra sobre el dibujo del objeto al cual se le llama icono. El tamaño total de una ventana puede ser reducido a un icono, y el usuario puede restablecer la ventana a su tamaño normal.

GUI´s avanzados eliminan completamente la necesidad de teclear comandos, permitiéndole al usuario seleccionar comandos desde menús usando el ratón o teclas de función. Las ventanas también pueden contener barras de desplazamiento y botones. En la programación con GUI´s se debe estar atento para aceptar y procesar eventos asíncronos 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 GUI´s son los siguientes:

Evento de ratón. Ocurre cuando el usuario mueve el apuntador del ratón dentro o fuera de una ventana, hace clic en el botón dentro o fuera de la ventana o libera el botón del ratón.

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 actualización de ventana. Ocurre cuando una porción de la imagen de la presentación de una aplicación ha sido alterado (posiblemente por que se sobrepuso otra ventana) y se tenga que restablecer.

Evento de ajuste. Ocurre cuando el usuario ha modificado el tamaño de una ventana.

Evento de Activación/Desactivación. 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.

Distribución de eventos

Los eventos deben ser procesados por la lógica de presentación en cooperación con la lógica de procesamiento. El procesamiento puede ser distribuido entre el

mismo GUI, la lógica de la aplicación y el API (Aplication Programming Interface) del GUI. Un API es un conjunto de rutinas de un GUI específico que hacen funciones como crear ventanas y desplegar varios gráficos. El procesamiento de los eventos se puede distribuir de la siguiente manera:

Modelo de ciclo de evento. Específica que una aplicación debe contener un ciclo de evento. El ciclo de evento llama a una rutina de librería en particular para ver si hay eventos pendientes. Cada evento pendiente causa que la aplicación atienda (despache) el evento antes de regresar el control al ciclo de evento.

Modelo de aviso (callback) de evento. Requiere que la aplicación registre una función manejadora de eventos por cada entidad GUI que crea, de esta manera se libera a la aplicación 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 aplicación. La aplicación tiene el control sólo cuando se inicia una entidad GUI o cuando se llama a una de sus rutinas de atención a eventos.

Modelo híbrido. Combina el modelo ciclo de evento y el modelo aviso de evento. Microsoft Windows emplea un modelo (donde una aplicación debe contener un ciclo de evento) el cuál llama a una rutina para obtener el siguiente evento. En ese momento, una aplicación puede llamar a otra rutina del API, el cual puede, en su momento, llamar al manejador de eventos de la aplicación.

TIPOS DE INTERFACES (Front-end, back-end).

Básicamente existen dos tipos de interfaces, las interfaces estáticas y las interfaces dinámicas. Las interfaces estáticas son aquellas que no tienen cambio y son difíciles de modificar y por su ubicación pueden ser:

De propósito especial (stand-alone).

Centralizado (novell).

Distribuido (internet).

Las interfaces dinámicas 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 aplicación donde los usuarios interactúan directamente con las funciones del sistema, cubre todas las interfaces con las cuales un usuario interactúa con los sistemas, ya sean locales o remotos, sus funciones principales son:

Diseño de formatos.

Presentación.

Lógica de la aplicación.

Manipulación de datos.

Herramientas de consulta.

Utilerías/menús

Interfaz Back-End. Es un conjunto de elementos (programas) que sirven como complemento de una interfaz Front-End. Ayuda en la administración, control y configuración 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:

Administración de la memoria.

Seguridad.

Manejo de base de datos.

Procesamiento remoto.

2.2 ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS

La mayoría de los sistemas de manejo de bases de datos disponibles actualmente están basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo, como se puede apreciar en la Figura 2.4.

La vista conceptual, conocida también como vista lógica global, representa la visión de la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones individuales observan los datos o como éstos son almacenados. La vista conceptual está basada en el esquema conceptual y su construcción se hace en la primera fase del diseño de una base de datos.

Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a través de un esquema externo definido a nivel externo. La vista externa proporciona una ventana a la vista conceptual lo cual permite a los usuarios observar únicamente los datos de interés y los aísla de otros datos en la base de datos. Puede existir cualquier número de vistas externas y ellos pueden ser completamente independientes o traslaparse entre sí.

El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel de descripción más bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de archivos del sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver con la especificación de qué elementos serán indexados, qué técnica de organización de archivos utilizar y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso.

En las Figuras 2.5, 2.6 y 2.7 se presenta la definición de los esquemas conceptual, interno y externo para las relaciones de la Figura 2.1.

Figura 2.4. Arquitectura ANSI/SPARC de una base de datos.

Figura 2.5. Vista conceptual de las relaciones E, S, J y G.

2.3 ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD

En la Figura 2.8 se presentan las diferentes dimensiones (factores) que se deben considerar para la implementación de un sistema manejador de base de datos. Las dimensiones son tres:

1. Distribución. Determina si las componentes del sistema están localizadas en la misma computadora o no.

2. Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.

3. Autonomía. La autonomía se puede presentar a diferentes niveles:

Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.

Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.

Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera.

Figura 2.9. Arquitectura de un SMBDD homogéneo.

Desde el punto de vista funcional y de organización de datos, los sistemas de datos distribuidos están divididos en dos clases separadas, basados en dos filosofías totalmente diferentes y diseñadas para satisfacer necesidades diferentes:

1. Sistemas de manejo de bases de datos distribuidos homogéneos 2. Sistemas de manejo de bases de datos distribuidos heterogéneos

Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples recursos de datos como se muestra en la Figura 2.9. Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un solo lugar, los datos se distribuyen en varios sitios comunicados por la red. No existen usuarios locales y todos ellos accesan la base de datos a través de una

interfaz global. El esquema global es la unión de toda las descripciones de datos locales y las vistas de los usuarios se definen sobre el esquema global.

Para manejar los aspectos de la distribución, se deben agregar dos niveles a la arquitectura estándar ANSI-SPARC, como se muestra en la Figura 2.10. El esquema de fragmentación describe la forma en que las relaciones globales se dividen entre las bases de datos locales. La Figura 2.11 presenta el ejemplo de una relación, R, la cual se divide en cinco fragmentos. El esquema de asigna miento especifica el lugar en el cual cada fragmento es almacenado. De aquí, los fragmentos pueden migrar de un sitio a otro en respuesta a cambios en los patrones de acceso.

Figura 2.10. Arquitectura de los esquemas de un SMBDD homogéneo

2.4 Integración de sistemas heredados.

Análisis de proyectos con sistemas heredados Opciones, no insistencia

Cuando los clientes vienen a nosotros con una estructura de producción 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 rediseño y de ingeniería de proceso. Nunca abordamos a nuestros clientes con nuestra solución preferida, y diciendo esencialmente así es como se debe re configurar esta estructura. Comprendemos que la producción multilingüe es uno de los elementos de lo que puede ser una serie completa de factores de éxito del proyecto.

Adaptación de fuentes heredadas

Nosotros respetamos el valor de los activos de producción de información existentes. Invertimos más que cualquier otra agencia en herramientas y capacitación que permitan a nuestro departamento de producción adaptar fuentes heredadas, en lugar de desecharlas o reconstruirlas. Más aún, nuestro departamento técnico 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 implementación multilingüe.

Monitoreo automatizado

Una herramienta clave en el esfuerzo para adaptar fuentes heredadas en línea sin una reingeniería demasiado invasiva, es nuestro servicio de monitoreo automatizado. Esto permite a sus diseñadores y administradores actualizar diseño e información cuando sea necesario, y con una única notificación al sistema de monitoreo automático, el material que se ha modificado es señalado y el registro es dirigido al proceso de traducción y localización automáticamente. Para fuentes en línea existentes con un flujo de información bajo a moderado, esta puede ser una manera económicamente eficiente de manejar fuentes en línea multilingües con una pequeña inversión adicional.

2.5 Distribución de elementos de una aplicación.

Cada aplicación 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 ubicación de los recursos (pensando que son locales). En cambio, las distribuidas pueden solicitar la asignación de recursos en las ubicaciones que deseen y controlar la revocación de tal modo que se mantengan en el nodo local (en la cache) los recursos convenientes (revocando primero aquellos recursos que sea más barato traer al nodo local, y no aquellos que sea costoso volver a obtener debido a su ubicación 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 escogería él mismo las unidades a revocar y ello sin tener una idea exacta de para qué se emplea cada una de ellas.

Por un lado, una aplicación centralizada se puede distribuir ``automáticamente'' interponiendo entre ella y el sistema un algoritmo distribuido de asignación y revocación de recursos. De este modo la distribución será como sigue:

· Ante una petición de recursos, el algoritmo de asignación puede solicitar recursos remotos (o locales) al kernel.

· La aplicación realizará peticiones al sistema empleando dichos recursos de manera transparente. Sean éstos locales o remotos, el kernel atenderá las peticiones.

· Ante una eventual revocación, el algoritmo de revocación empleado puede optar por eliminar primero los recursos que sean mas ``baratos'' en términos de posición y uso.

A modo de ejemplo, la figura 2.5 muestra (a) cómo las aplicaciones utilizan la distribución 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) cómo pueden emplear su propia distribución en un DAMN.

Figure: Distribución del sistema en kernels (a) y DAMNs (b).

2.6 Integración de tecnologías homogéneas y heterogéneas

Existen diferentes motivos para la heterogeneidad y homogeneidad.

Una razón son los cambios tecnológicos que siempre se dan en un periodo de tiempo corto. En este contexto, dichos cambios se refieren a mejor calidad, mejor desempeño, costos más económicos, seguridad, entre otras características que se toman en cuenta.Otra razón es que la diversidad en una red de computadoras puede hacerla más resistente que cualquier problema dado en algún tipo de máquina, sistema operativo o aplicación son poco probables que afecten a otros sistemas corriendo en diferentes sistemas operativos y aplicaciones.

HOMOGÉNEO.

En los sistemas homogéneos, todos los sitios emplean idéntico software de gestión de base de datos, son conscientes de la existencia de los demás sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios

HETEROGENEO.Las tecnologías Heterogéneas son aquellas donde Sitios diferentes utilizan diferentes DBMS, siendo cada uno esencialmente autónomo.

Es posible que algunos sitios no sean conscientes de la existencia de los demás y quizás proporcionen facilidades limitadas para la cooperación en el procesamiento de transacciones.

La heterogeneidad se debe a que los datos de cada BD son de diferentes tipos o formatos. El enfoque heterogéneo es más complejo que el enfoque homogéneo.

UNIDAD 3.Diseño de aplicaciones distribuidas.

3.1 Diseño e implementación de manejo de datos. 

Que es un sistema de manejo de datos 

n Todos los procedimientos utilizados para la entrada, procesamiento y salida de datos junto con la infraestructura de computadoras en las cuales se realiza este manejo de datos.

Se decide la arquitectura de la aplicación y se determina qué componentes son objetos locales y cuáles deberían ser accesibles remotamente. Este paso incluye.Definir las interfaces remotas. Implementar los objetos remotos. Implementar los clientes.

El diseño del sistema de información describe el plan general o el modelo que se propone para ese sistema. Contiene todas las especificaciones que le dan forma y estructura al sistema. Durante la etapa de diseño, el desarrollado debe trasformar los requisitos del sistema en una estructura de alto nivel, identificando sus componentes principales y sus relaciones, tal como las verá el usuario, este diseño se denomina diseño global. El diseño global muestra lo que la solución

hará, describe sus entradas y salidas, las funciones de procesamiento, los modelos de datos y controles.

Implementación. Programación: lo que sigue en el proceso de desarrollo es traducir las especificaciones de la solución en un sistema informático operativo, para ello se traducen las especificaciones del sistema en código de programas.

3.2 Diseño de procesamiento de datos.

Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas:

1. El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 3.1 se presenta un diagrama con la estructura general del enfoque top-down.

2. El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la

integración del esquema local en un esquema global común.

Figura 3.1. El enfoque top-down para el diseño de bases de datos distribuidas.

3.3 Diseño de interfaz de usuario

El diseño de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al éxito o al fracaso. Los principios que se presentan son de utilidad para creación de interfaces funcionales y de fácil operación. A pesar de no ser capaces de resolver todos los aspectos propios del contexto con el que se esté trabajando, pueden ser combinados con la prototipación y la aplicación de heurísticas de evaluación para facilitar elProceso de diseño. El presente artículo se centra en los componentes de software de las interfaces de usuario, quedando fuera del alcance de mismo otros aspectos, como hardware y documentación.

Principios para el Diseño de Interfaces de UsuarioAnticipaciónLas aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla oinvocar las herramientas que va a utilizar.

Autonomía La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender

Objetos de Interfaz HumanaLos objetos de interfaz humana no son necesariamente los objetos que se encuentran en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o percibidos de alguna forma. Además, estos objetos deberían ser entendibles, consistentes y estables.

Curva de Aprendizaje

El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal es que la curva de aprendizaje sea nula, y que el usuario principiante

Pueda alcanzar el dominio total de la aplicación sin esfuerzo.

Auditoría del Sistema

La mayoría de los navegadores de Internet(browsers), no mantienen información acerca de la situación del usuario en el entorno, pero para cualquier aplicación es conveniente conocer un conjunto de características tales como: hora de acceso al sistema, ubicación del usuario en el sistema ylugares a los que ha accedido, entre otros. Además, el usuario debería poder salir del sistema y al volver a ingresar continuar trabajando en lugar dóndehabía dejado.

Interfaces Visibles

El uso de Internet, ha favorecido la implementación de interfaces invisibles.Esto significa que el usuario siempre ve una página específica, pero nunca puede conocer la totalidad del espacio de páginas de Internet.

UNIDAD 4.Implementación de Procesamiento de Datos.

Es una forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que contienen información adicional acerca de la estructura del texto o su presentación. El lenguaje de marcas más extendido es el HTML, fundamento del World Wide Web. Los lenguajes de marcado suelen confundirse con lenguajes de programación.

-Marcado de presentación

El marcado de presentación es aquel que indica el formato del texto. Este tipo de marcado es útil para maquetar la presentación de un documento para su lectura, pero resulta insuficiente para el procesamiento automático de la información.

Marcado de procedimientos

El marcado de procedimientos está enfocado hacia la presentación del texto, sin embargo, también es visible para el usuario que edita el texto. El programa que representa el documento debe interpretar el código en el mismo orden en que aparece.

Marcado descriptivo

El marcado descriptivo o semántico utiliza etiquetas para describir los fragmentos de texto, pero sin especificar cómo deben ser representados, o en que orden. Los lenguajes expresamente diseñados para generar marcado descriptivo son el SGML y el XML.

¿Importancia de las interfaces gráficas y de texto?

Es de suma importancia porque permiten que las personas puedan acceder a un ordenador sin tener que pasar por el tortuoso proceso de tener que aprender a manejar un entorno bajo línea de órdenes.¿Qué es la programación relacionada con las interfaces virtuales, gráficas y de texto?

Representación en modo texto

Se trabaja en un entorno de texto (no gráfico), el programa en ejecución controla la información representada en la totalidad de la pantalla (no hay "ventanas"); el control de esta se realiza en término de filas y columnas y un surtido muy limitado de 256 caracteres. Los únicos atributos que pueden tener los caracteres suelen ser: Color de tinta y de papel (trazo y fondo); subrayado y parpadeo.

“Programación Moderna"

Se trata de conceptos generales e independientes. Por ejemplo, un programa "moderno" puede ser multiprogramación pero en modo texto, o no orientado a objetos; sin embargo, la mayoría de las característica se dan juntas. En especial si se trata de programas que utilizan la interfaz gráfica de los SOS más conocidos.

4.1 Construcción de componentes.

Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (cliente-middleware-servidor) y multinivel.

Una aplicación distribuida que sigue el modelo cliente-servidor tiene los siguientes componentes:

Lado servidor: Programa que se ejecuta en un computador que esta conectado a una red. Esta a la escucha en un puerto, esperando las peticiones de los clientes; por ejemplo, un servidor Web escucha en el puerto 80. Un computador que ejecuta un servidor de aplicación necesita estar conectado a la red para responder a las peticiones de los clientes.

Lado cliente: Programa que ejecuta el usuario de la aplicación. El cliente hace sus peticiones al servidor a través de la red. Por ejemplo, un navegador Web.

Protocolo de aplicación para la comunicación entre el cliente y el servidor. El protocolo define el tipo de mensajes intercambiados; por ejemplo, el protocolo de la capa de aplicación de la Web, HTTP, define el formato y la secuencia de los mensajes transmitidos entre el navegador y el servidor Web.

Formato de los mensajes que se intercambian, algunas veces forma parte del servicio; por ejemplo, en el correo electronico se define el formato de los mensajes electronicos.

Estos componentes son independientes de la arquitectura de red que se utiliza.

Componentes Software

¿Alguna vez ha pensado que un programa pudiera ser como... una bicicleta?. Si es necesario cambiar la cadena de la bicicleta, usted solo se centra en la cadena, no tiene que lidiar con otros componentes ajenos, como por ejemplo, las gomas o tan sencillo como el timbre, sino solo la cadena. Sabe con exactitud donde está el componente y puede modificarlo (engrasar) o actualizarlo (una nueva). Si ahora le dijera que pudiera hacer lo mismo con los software que usted desarrolla, ¿qué diría al respecto?.

El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos (componentes) que han sido previamente diseñados por otras personas a fin de ser rehusados en múltiples aplicaciones. La ingeniería de programación que sigue esta estrategiade diseño se le conoce por el acrónimo CBSE1 y es actualmente una de las más prometedoras para incrementar la calidad del software, abreviar los tiempos de acceso al mercado y gestionar el continuo incremento de su complejidad.

La arquitectura software de una aplicación basada en componentes consiste en uno o un número pequeño de componentes específicos de la aplicación (que se diseñan específicamente para ella), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre sí para proporcionar losservicios que se necesitan en la aplicación.

En la tecnología de componentes la interfaz constituye el elemento básico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz.

Características muy relevantes de la tecnología de programación basada en componentes son la modularidad, la rehusabilidad y componibilidad y en todos ellos coincide con la tecnología orientada a objetos de la que se puede considerar una evolución. Sin embargo, en la tecnología basada en componentes también se requiere robustez ya que los componentes han de operar en entornos mucho más heterogéneos y diversos.

El desarrollo de software basado componentes es la evolución natural de la ingeniería software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.

Entornos normalizados de desarrollo de componentes software.

Para que una arquitectura de componentes pueda operar es necesario disponer de un entorno normalizado que proporcione soporte a los mecanismos con que se comunican las interfaces.

COM (Component Object Model).

Los lenguajes de programación clásicos fueron diseñados para desarrollar aplicaciones secuenciales compuestas de módulos, todos ellos codificados con un solo lenguaje. Sin embargo, hay situaciones en las que no es práctico restringirse al uso de un único lenguaje. La tecnología COM aborda la solución a este problema proporcionando un sencillo, pero a la vez potente modelo para construir sistemas software a partir de la interacción de objetos (componentes).

COM define un estándar binario (esto implica que es independiente del lenguaje de programación) para objetos y la intercomunicación entre ellos. Todacomunicación se realiza a través de operaciones que son proporcionadas dentro de interfaces. El diseñador invoca las operaciones que necesita directamente, incluso si el objeto destinatario está localizado en otro proceso o en otra máquina.

El modelo de programación COM esta basado en la distribución de código de clases en componentes binarios. Esto significa que el software (componentes) que se adhiere a COM, puede ser rehusado sin ninguna dependencia de código fuente. Los desarrolladores pueden exponer sus trabajos como ficheros binarios sin dar a conocer sus algoritmos.

El desarrollo basado en componentes resuelve muchos de los problemas asociados con las aplicaciones monolíticas. Permite al grupo de desarrollo exponer ficheros binarios en vez de código fuente. Los componentes binarios pueden ser actualizados independientemente y reemplazados, lo que se hace mucho más fácil mantener y extender una aplicación después de que esta ha sido puesta en explotación.

4.2 Comunicación con manejo de datos.

Comunicación de Datos. Es el proceso de comunicar información en forma binaria entre dos o más puntos. Requiere cuatro elementos básicos que son:

Emisor: Dispositivo que transmite los datos. Mensaje: lo forman los datos a ser transmitidos. Medio: consiste en el recorrido de los datos desde el origen hasta su destino. Receptor: dispositivo de destino de los datos. BIT: es la unidad más pequeña de información y la unidad base en

comunicaciones. BYTE: conjunto de bits continuos mínimos que hacen posible, un direccionamiento

de información en un sistema computarizado. Está formado por 8 bits.

Paquete: fracciones de un mensaje de tamaño predefinido, donde cada fracción o paquete contiene información de procedencia y de destino, así como información requerida para el reensamblado del mensaje.

Interfaces: conexión que permite la comunicación entre dos o más dispositivos.

Códigos: acuerdo previo sobre un conjunto de significados que definen una serie de símbolos y caracteres. Toda combinación de bits representa un carácter dentro

de la tabla de códigos.-----Paridad: técnica que consiste en la adición de un bit a un carácter o a un bloque de caracteres para forzar al conjunto de unos (1) a ser par o impar. Se utiliza para el chequeo de errores en la validación de los datos. El bit de paridad será cero (0=SPACE) o uno (1=MARK).

Modulación: proceso de manipular de manera controlada las propiedades de una señal portadora para que contenga la información que se va a transmitir

Unidad 5:Implementación de interfaz de usuario.

5.1 Lenguajes de Mercado

Un “Lenguaje de marcado” o “lenguaje de marcas” se puede definir como una forma de codificar un documento donde, junto con el texto, se incorporan etiquetas, marcas o anotaciones con información adicional relativa a la estructura del texto, su presentación.Los lenguajes de marcado se pueden clasificar en:• Procedimental:

– Describen operaciones tipográficas• Estructural:– Describen la estructura lógica de un documento, pero no su tipografía• Híbrido:– Combinación de ambos– Las hojas de estilo o lenguajes de transformación permiten la “traducción” de anotaciones de tipo estructural a anotaciones de carácter tipográfico.Otra posible clasificación sería:• De presentación:– Indica el formato del texto (información para el maquetado).• De procedimientos:– Orientado también a la presentación pero, en este caso, se indican los procedimientos que deberá realizar el SW de representación.• Descriptivo o semántico:– Describen las diferentes partes en las que se estructura el documento pero sin especificar cómo deben representarse.Algunos lenguajes de marcado específicos:– Documentación electrónica

RTF TeX Wikitexto DocBook

– Tecnologías de internet

HTML, XHTML RDF (recurso-propiedad(relación)-valor) RSS

– Otros lenguajes especializados

MathML VoiceXML SVG MusicXML

5.2 Tecnologías para implementación de interfaces de usuario.

En el contexto del proceso de interacción persona-ordenador, la interfaz gráfica de usuario, es el artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del lenguaje visual, una interacción amigable con un sistema informático.La interfaz gráfica de usuario (en inglés GraphicalUser Interface, GUI) es un tipo de interfaz de usuario que utiliza un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulación directa para facilitar la interacción del usuario con la computadora.Surge como evolución de la línea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno gráfico.Como ejemplo de interfaz gráfica de usuario podemos citar el escritorio o desktop del sistema operativo Windows y el entorno X-Windows de Linux.Algunas Interfaces gráficas (GUIs) son:

GPA Intenta ser la interfaz de usuario gráfica estándar de Gnu PG. GPA se hospeda en este sitio.

K Gpg

Es una interfaz de usuario de KDE para Gnu PG.* SeahorseEs una interfaz de usuario de GNOME para Gnu PG.* XAPArquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios: Apéndices

5.3 Programación

La creación de las interfaces de usuario ha sido un área del desarrollo de software que ha evolucionado dramáticamente a partir de la década de los setentas. La interfaz de usuario es el vínculo entre el usuario y el programa de computadora. Una interfaz es un conjunto de comandos o menús a través de los cuales el usuario se comunica con el programa. Esta es una de las partes más importantes de cualquier programa ya que determina que tan fácilmente es posible que el programa haga lo que el usuario quiere hacer. Un programa muy poderoso con una interfaz pobremente elaborada tiene poco valor para un usuario no experto.La elaboración de una interfaz de usuario, bien diseñada, exige una gran dedicación pues generalmente las interfaces son grandes, complejas y difíciles de implementar, depurar y modificar. Hoy en día las interfaces de manipulación directa (también llamadas interfaces gráficas de usuario, GUI por sus siglas en inglés) son prácticamente universales. Las interfaces que utilizan ventanas, íconos y menús se han convertido en estándar en los materiales computacionalesLa interfaz representa el punto de encuentro entre el usuario y la computadora. En esta interacción, el usuario juzga la utilidad de la interfaz; el hardware y el software se convierten en simples herramientas sobre los cuales fue construida la interfaz. La definición de interfaz en si misma es un tanto arbitraria, aunque esto depende de la naturaleza de la tarea que se tiene enfrente.Existen muchos tipos de software para la creación de interfaces de usuario.El sistema de ventanas permite la división de la pantalla en diferentes regiones rectangulares, llamadas ``ventanas''. El sistema de ventanas XWindows para Unix divide la funcionalidad de la ventana en dos capas: el sistema de ventanas, el cual

es la interfaz funcional, y el administrador de ventanas. El sistema de ventanas provee de procedimientos que permiten a la aplicación el dibujar figuras en la pantalla y sirve como medio de entrada de las acciones del usuario. El administrador de ventanas le permite al usuario final el mover las ventanas por la pantalla, y es el responsable de desplegar las líneas de título, bordes e íconos alrededor de las ventanas.La parte central de un sistema de ventanas es el conjunto de herramientas (toolkit), el cual contiene los objetos gráficos (widgets más empleados tales como menús, botones, barras de scroll, y campos para entrada de texto.Eltoolkit generalmente se conecta a los programas de aplicación a través de una serie de procedimientos definidos por el programador. La función de estos procedimientos es el decidir la forma en que se comportarán los objetos gráficos.

5.3.1 Del Lado del Cliente.

Con la programación del lado del cliente se pueden validar algunos de los datos en la máquina cliente antes de enviarlos al servidor. Esto proporciona a los usuarios informes de error inmediatos, mientras siguen en esa página de formulario y sin necesidad de volver atrás tras recibir un mensaje de error. Puede resultar necesario acceder a una base de datos para validar determinados valores, mientras que no suele disponer de un acceso directo a la base de datos en la máquina del cliente, aunque ese acceso a la base de datos es factible.Los clientes también se pueden mejorar con otras técnicas. Por ejemplo, podemos usar controles ActiveX y Applets de Java. Aunque estas tecnologías son bastantes diferentes, el resultado final es similar: la interfaz del cliente puede hacer cosas que no puede hacer normalmente con HTML. De momento, la diferencia principal entre ambas es que los controles ActiveX sólo funcionan en IE. Las Applets de Java funcionan tanto en IE como en Navigator, aunque no todos los Applets funcionan igual de bien en ambos exploradores.

5.3.1 Del Lado del Servidor

La programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante la interpretación de un script en el servidor web para generar páginas HTML dinámicamente como respuestaLos primeros servidores web permitían visualizar exclusivamente información estática. Esto presentó pronto una limitación; sobre todo desde el momento en el

que la actividad publicitaria y comercial comenzó a concentrarse también en Internet. La primera solución técnica realizada fue la posibilidad de que el servidor web ejecutase programas residentes en la máquina de servicio. Esta tecnología, conocida como Common Gateway Interface (CGI) permitía lanzar programas escritos principalmente en C o Perl.Si bien la tecnología CGI resolvía el problema de la presentación exclusiva de información estática, al mismo tiempo presentaba dos limitaciones importantes: el problema de seguridad que podía representar el hecho de que mediante una petición se pudiesen ejecutar programas indeseados en el servidor y la carga del servidor (si una página que lanzaba un programa era llamada desde 100 clientes simultáneamente, el servidor ejecutaba 100 procesos, uno por cada cliente que solicitaba dicha página).Para resolver estos problemas, se buscó desarrollar una tecnología que permitiera ejecutar, en un único proceso del servidor, todos los pedidos de ejecución de código sin importar la cantidad de clientes que se conectaban concurrentemente. Así surgieron los denominados servlets, basados en la tecnología Java de Sun Microsystems, y los filtros ISAPI de Microsoft. Éstos permitían ejecutar código en un único proceso externo que gestionaba todas las llamadas realizadas por el servidor web, impidiendo al mismo tiempo que el servidor web pueda ejecutar programas del sistema operativo.No obstante, de este modo se limitaron los problemas de prestación y seguridad de la tecnología CGI, y no se resolvió el problema representado por un desarrollo demasiado costoso en términos de tiempo. Asimismo, se hizo necesario que dos figuras profesionales distintas trabajen en un único proyecto: el programador (que conoce el lenguaje de programación utilizado del lado del servidor) y el diseñador web (que conoce la parte gráfica y el lenguaje HTML). Para resolver estas limitaciones, fueron desarrollados lenguajes que pueden ser incluidos al interno de archivos HTML. Estos comandos pueden ser interpretados (como por ejemplo las páginas ASP o PHP) o precompilados (como en las páginas JSP o ASP.NET).Con la utilización de esta tecnología se buscaba, también, desarrollar aptitudes de diseñador web en los programadores y de programador en los diseñadores (se esperaba con ello el hacer más fácil y veloz el desarrollo de scripts del lado del servidor).

UNIDAD 6INTEGRACIÓN DE APLICACIONES DISTRIBUIDAS.

6.1 Asignación de las Partes de la Aplicación

Una vez realizada la identificación de las partes, la valoración de la sensibilidad nos lleva a darle un valor y a evaluar que tan críticos son: la información y los demás elementos de la organización como el software, hardware, y el valor de los servicios que provee la aplicación. Cuando hablamos de valor debemos tener claro que a la información y a los servicios de red se les debe asociar un monto simbólico, mientras el software y el hardware se evalúan en dinero, de acuerdo a los criterios que se describen a continuación.* ConfidencialidadLa cual se refiere al servicio prestado para proteger la información principalmente de accesos no autorizados. Por ejemplo si hay un circuito virtual entre dos sistemas, este servicio debería ser capaz de proteger la "revelación" de la información que viaja por dicho circuito de un tercer atacante que intenta capturar dichos datos. Información del personal, investigaciones y reportes de desarrollo son algunos de los ejemplos de información que necesita confidencialidad.* IntegridadEl servicio de integridad es el que permite que la información sea adecuada, completa y auténtica en el momento de ser procesada, presentada, guardada o transmitida. Por ejemplo si uno transmite datos de control de cualquier tipo por una red, mínimo desea que estos no lleguen dañados o defectuosos porque las consecuencias finales podrían ser desastrosas (e.g. datos que controlen un mecanismo de armas). En algunos casos mantener y garantizar esta característica es más importante que la confidencialidad.* DisponibilidadComo su nombre lo indica la disponibilidad incluye todos los servicios de red que se pueden tener y prestar en determinado momento. Un esquema típico con el cual se maneja la disponibilidad es el de dos dominios donde el primero coloca un valor a la información que se puede destruir completamente y nunca más podrá ser consultada, el segundo dominio coloca valores en tiempo de disponibilidad por ejemplo: el servicio de impresora no está disponible por 1 hora, 2 horas o lo contrario está disponible solo por 3 horas, etc; este último dominio conocido como "o ver time" sirve para encontrar umbrales de disponibilidad; por ejemplo, "si después de 2 horas no está disponible el servidor de la base de datos de empleados hay que programar un procedimiento manual".

6.2 Distribución de la Aplicación

Cada aplicación 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 ubicación de los recursos (pensando que son locales). En cambio, las distribuidas pueden solicitar la asignación de recursos en las ubicaciones que deseen y controlar la revocación de tal modo que se mantengan en el nodo local (en la cache) los recursos convenientes (revocando primero aquellos recursos que sea más barato traer al

nodo local, y no aquellos que sea costoso volver a obtener debido a su ubicación 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 escogería él mismo las unidades a revocar y ello sin tener una idea exacta de para qué se emplea cada una de ellas.El kernel permite que peticiones locales al sistema puedan operar con recursos remotos, eso es todo lo que hace.Por un lado, una aplicación centralizada se puede distribuir ``automáticamente'' interponiendo entre ella y el sistema un algoritmo distribuido de asignación y revocación de recursos. De este modo la distribución será como sigue:

Ante una petición de recursos, el algoritmo de asignación puede solicitar recursos remotos (o locales) al kernel.

La aplicación realizará peticiones al sistema empleando dichos recursos de manera transparente. Sean éstos locales o remotos, el kernel atenderá las peticiones.

Ante una eventual revocación, el algoritmo de revocación empleado puede optar por eliminar primero los recursos que sean mas ``baratos'' en términos de posición y uso.

Por otro lado, una aplicación distribuida puede emplear algoritmos específicos de asignación y revocación sin necesidad de conformarse con un algoritmo general que funcione bien en el caso medio. Cuando el sistema ve que el recurso es remoto es la propia implementación del servicio la que contacta con el nodo remoto usando protocolos específicos de cada aplicación (esto es, realizando una up-call). Esto no es lo mismo que emplear una IPC distribuida que alcanza un núcleo remoto sin que el local se entere de ello. Si se distribuyen sólo las IPCs podemos tener problemas en el uso de referencias a memoria de usuario en las llamadas al sistema (una referencia local no es válida en el nodo remoto). Estas pueden ocasionar mensajes extra en la red o el envió de datos innecesarios.

6.3 Instalación de los Componentes

Se ha convertido en un principio ampliamente aceptado en el diseño de aplicaciones distribuidas la división de la aplicación en componentes que ofrezcan servicios de presentación, institucionales y de datos. Los componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos están organizados en forma de apilamiento para que los componentes que se encuentran por "encima" de una capa determinada utilicen los servicios proporcionados por ésta, y un componente especifico utilizará la funcionalidad proporcionada por otros componentes de su propia capa, y otras capas "inferiores", para realizar su trabajo.Esta visión dividida de una aplicación también se puede aplicar a los servicios. Desde un punto de vista de alto nivel, se puede considerar que la solución basada en servicios está formada por varios servicios, los cuales se comunican entre sí pasando mensajes. Desde el punto de vista conceptual, los servicios se pueden considerar como componentes de la solución global. Sin embargo, internamente el servicio está formado por componentes de software, al igual que cualquier otra aplicación, los cuales se pueden agrupar de forma lógica en servicios de presentación, institucionales y de datos.

EJEMPLO:

6.4 Configuración de los Componentes

Las aplicaciones requieren datos de configuración para funcionar técnicamente. Los valores que modifican el comportamiento de las directivas (seguridad, administración operativa y comunicaciones) se consideran datos de configuración.Los datos de configuración se conservan en los archivos de configuración de .NET a nivel de usuario, equipo y aplicación. La configuración personalizada almacenada aquí se puede definir con cualquier esquema y se puede tener fácil acceso mediante el uso de la clase ConfigurationSettings en su aplicación.Es muy importante tener en cuenta la confidencialidad de seguridad de la conexión; por ejemplo, no debe almacenar cadenas de conexión SQL en texto no cifrado en los archivos de configuración XML, especialmente si contienen credenciales SQL. Debería limitar el acceso a la información de seguridad a los operadores adecuados y a fin de disponer de una mayor seguridad, debería considerar la firma digital de la información para asegurarse de que los datos de configuración no se han modificado.Los datos de configuración se pueden almacenar en varios lugares, cada uno de ellos con sus ventajas e inconvenientes:

Archivos de configuración XML: el almacenamiento de los datos de configuración aquí permite a los clientes de su aplicación trabajar sin conexión y este modelo resulta fácil de implementar. Con aplicaciones de cliente enriquecido, este enfoque puede suponer un aumento en los costos de administración de los cambios, ya que requiere que todos los clientes dispongan de la misma información de configuración.

SQL Server o el almacén de datos de la aplicación: se trata de la ubicación de almacenamiento normal para los datos de configuración administrados por la aplicación, pero aún más para los metadatos de las aplicaciones. Si almacena aquí la configuración, se recomienda que guarde los metadatos en una base de datos de SQL Server distinta de la de los datos empresariales. El acceso a la base de datos supone a menudo una mejora en el rendimiento, por lo que debería considerar el almacenamiento en caché.

Active Directory: dentro de una organización, puede decidir almacenar los metadatos de la aplicación en Active Directory. De este modo, los clientes del dominio pueden disponer de los metadatos. También puede asegurar la información en Active Directory con ACL de Windows, asegurando que sólo los usuarios y las cuentas de servicio autorizadas podrán tener acceso al mismo.

Cadenas del constructor: si utiliza componentes basados en Enterprise Services, puede agregar datos de configuración a la cadena del constructor para los componentes.

Otras ubicaciones para casos especiales: éstas incluyen el Registro de Windows, el almacén de Windows Local Security Authority (LSA) y las implementaciones personalizadas. Se utilizan en casos muy especiales y agregan requisitos para los privilegios de aplicaciones en el equipo y los mecanismos de implementación.

Soluciones de administración de configuración de terceros que pueden proporcionar también características de control de versiones e implementación.

6.5 Configuración de la Aplicación

Los componentes de proceso de usuario generalmente requieren los siguientes valores de configuración:

Información de la ubicación para llegar a los componentes de procesos empresariales y los componentes de acceso a datos.

Datos de conexión (como una cadena de conexión o una ruta de archivo) para el recurso que controla los datos de procesos de usuario persistentes para procesos de larga ejecución.

Configuración en agentes de serviciosLos agentes de servicios necesitan disponer de información de configuración para conectarse al servicio externo a través de los servicios Web, colas de mensajes u otros medios. El esquema y los datos de configuración dependen del servicio específico al que se está teniendo acceso.Configuración en los componentes de acceso a datosLos componentes de acceso a datos normalmente necesitan lo siguiente:

Necesitan tener la capacidad de asignar nombres de orígenes de datos lógicos a parámetros de la conexión física (por ejemplo, para asignar la base de datos "Ventas" a una cadena de conexión real).

Si los componentes de acceso a datos realizan un enrutamiento dinámico de datos, necesitará contar con datos de configuración que expresen los parámetros (por ejemplo, región del cliente), algoritmos (por ejemplo, hash) y destinos del enrutamiento (por ejemplo, cadenas de conexión para las bases de datos). Es común incluir la lógica del enrutamiento dinámico de datos en un componente de utilidad distinto.

6.6 Evaluar Desempeño

Los sistemas informáticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la computación que estaban realizando. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre sí: Redundancia hardware (uso de componentes redundantes) y recuperación del software (diseño de programas que sean capaces de recuperarse de los fallos).En los sistemas distribuidos la redundancia puede plantearse en un grano mas fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas.La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo.Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina.El término 'recurso' es bastante abstracto, pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos.La idea de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo mono usuario o computadoras personales dentro de un sistema distribuido no obtienen automáticamente los beneficios de la compartición de recursos.Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente. Surge el término genérico de gestor de recursos.

6.7 Optimización del Desempeño

Un gestor de recursos es un modulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localización; la traslación de nombre de recurso a direcciones de comunicación y la coordinación de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia.Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos.