miércoles, 16 de noviembre de 2016

PARADIGMAS DE DESARROLLO DE SISTEMAS DISTRIBUIDOS

PARADIGMAS DE DESARROLLO DE SISTEMAS DISTRIBUIDOS
Paso de mensajes
El paso de mensajes es el paradigma fundamental para aplicaciones distribuidas. Un proceso envía un mensaje que representa una petición. El mensaje se entrega a un receptor, que procesa la petición y envía un mensaje como respuesta. En secuencia, la réplica puede disparar posteriores peticiones, que lleven a sucesivas respuestas, y así en adelante. Las operaciones básicas necesarias para dar soporte al paradigma de paso de mensajes son enviar y recibir. Para comunicaciones orientadas a conexión, también se necesitan las operaciones conectar y desconectar.
Paradigma cliente-servidor
El paradigma cliente-servidor asigna roles diferentes a los dos procesos que colaboran. Un proceso, el servidor interpreta el papel de proveedor de servicio, esperando de forma pasiva la llegada de peticiones. El otro, el cliente, invoca determinadas peticiones al servidor y aguarda sus respuestas. De una concepción simple, el modelo cliente-servidor proporciona una abstracción eficiente para facilitar servicios de red.
Paradigma de igual a igual peer-to-peer
En el paradigma peer-to-peer, los procesos participantes interpretan los mismos papeles, con idénticas capacidades y responsabilidades (de ahí el término peer, en inglés par). Cada participante puede solicitar una petición a cualquier otro participante y recibir una respuesta. Un ejemplo bien conocido de un servicio de transferencia de ficheros peer-to-peer es Napster.com; servicios similares permiten la compartición de ficheros (primordialmente ficheros multimedia) entre ordenadores a través de Internet.
Paradigma de sistema de mensajes
El paradigma de Sistema de Mensajes o Middleware Orientado a Mensajes (Message-Oriented Middleware-MOM), es una elaboración del paradigma básico de paso de mensajes. En este paradigma, un sistema de mensajes sirve de intermediario entre procesos separados e independientes. El sistema de mensajes actúa como un conmutador para mensajes, a través del cual los procesos intercambian mensajes asíncronamente, de una forma desacoplada. (Asíncronamente, como recordará del Capítulo 2, indica una comunicación sin bloqueo.) Un emisor deposita un mensaje en el sistema de mensajes, el cual redirige el mismo a la cola de mensajes asociada a dicho receptor. Una vez que se ha enviado, el emisor queda liberado para que realice cualquier otra tarea.
Paradigma basado a objetos
En el paradigma basado en Object Request Broker1, un proceso solicita una petición a un ORB (Object Request Broker), el cual redirige la petición al objeto apropiado que proporciona dicho servicio. El paradigma se parece bastante al modelo de Invocación de Métodos Remotos en su soporte para acceso remoto a objetos. La diferencia es que el ORB en este paradigma funciona como middleware, permitiendo a una aplicación, como solicitante de un objeto, acceder potencialmente a varios objetos remotos (o locales). El ORB puede funcionar también como mediador para objetos heterogéneos, permitiendo la interacción entre objetos implementados usando diferentes API y/o ejecutando sobre diferentes plataformas.
Fuentes Consultadas

miércoles, 28 de septiembre de 2016

Modelos de Consistencia Centrada al Cliente

Descripción de:
-       Modelos de Consistencia Centrada al Cliente
  • ·         Monotónico
  • ·         Lea sus escrituras
  • ·         Escrituras siguen a lecturas

Modelos de Consistencia Centrada al Cliente
Este tipo de modelos trata de una clase de almacenamiento de datos distribuidos en los cuales la mayoría de las operaciones son de lectura, estos modelos permiten esconder  efectos contrarios a la consistencia de una manera muy fácil. Los almacenamientos de datos referidos se  caracterizan por la falta de actualizaciones simultáneas o cuando ocurren dichas actualizaciones, pueden ser resueltas de una manera fácil.

Monotónico

Lecturas Monotónicas:
Un dato ofrece consistencia de lecturas monotónicas si y solo si se cumple la  siguiente condición:
Si un proceso le el valor de un documento  x, cualquier operación de lectura sucesiva sobre x por el mismo proceso siempre retornará el mismo valor o un valor más reciente. La consistencia de lecturas monotónicas garantiza  que si un proceso ha visto un valor de X al tiempo T, no se verá una versión más vieja de X en un tiempo posterior.
Escrituras Monotónicas:
Las escrituras monotónicas deben de ser correctamente propagadas en el orden correcto a todas las copias del almacenamiento se debe cumplir:
Una operación de escritura por un proceso sobre un elemento de datos x debe de ser completada antes que cualquier otra operación siguiente de escritura sobre x por el mismo proceso, esto quiere decir que si una operación de escritura sobre una copia de un elemento X  se realiza solo si la copia se ha actualizado mediante cualquier operación de escritura previa.de ser necesario la nueva escritura debe esperar a que terminen las escrituras anteriores.
Lea sus escrituras

Un almacén de datos provee consistencia lea sus escrituras si se cumple que:
Es cuando se sigue el mismo proceso un ejemplo de ello es cuando yo escribo un documento X, con el mismo proceso leeré el mismo documento. El efecto de una operación de escritura por procesos sobre un elemento de datos X será siempre visto por las operaciones sucesivas de lectura sobre X por el mismo proceso.
Siempre se sigue un mismo proceso siempre se escriben primero los documentos y luego se pueden leer, no importa el lugar en donde se realice dicho proceso.
Las escrituras siguen a lecturas

El objetivo de este modelo es que si se va a modificar el valor de un dato, es que aya sido leído antes de la última actualización.
Un almacén de datos provee consistencia de escrituras siguen lecturas solo si se cumple que:

Una operación de escritura de un proceso sobre un elemento de datos x realizada luego de leer ese dato x, se realizó sobre el valor más reciente de x.

Fuentes de información:

miércoles, 21 de septiembre de 2016

¿Qué es un modelo de consistencia?

¿Qué es un modelo de consistencia?
Es esencialmente un conjunto de reglas que deben de seguir tanto el software como la memoria, en donde el software acuerda obedecer ciertas reglas, por otra parte la memoria  debe trabajar correctamente siguiendo las reglas acordadas entre estos, pero si el software no cumple con  las reglas todo termina ya que no se garantiza que la memoria haya hecho una operación correcta.
A continuación se describen algunos modelos de consistencia:
Estricta
Este modelo se define mediante la siguiente condición:
Cualquier lectura de una localidad de memoria X regresa el valor guardado por la operación de escritura más reciente en X.

Secuencial
Es una forma ligeramente más débil de la consistencia estricta. Satisface la siguiente condición:
El resultado de una ejecución es el mismo si las operaciones (lectura y escritura) de todos los procesos sobre el dato fueron ejecutadas en algún orden secuencial y las operaciones de cada proceso individual aparecen en esta operaciones de cada proceso individual aparecen en esta secuencia en el orden especificado por su programa
a) Un dato almacenado secuencialmente consistente.
b) Un dato almacenado que no es secuencialmente consistente.
Causal
Es un debilitamiento de la consistencia secuencial. Se hace una diferenciación entre eventos que están potencialmente relacionados en forma causal y aquellos que no. Las operaciones que no están causalmente relacionadas se dicen concurrentes.
La condición a cumplir para que unos datos sean causalmente consistentes es:
Escrituras que están potencialmente relacionadas en forma causal deben ser vistas por todos los procesos en el mismo orden. Escrituras concurrentes pueden ser vistas en un orden diferente sobre diferentes máquinas.
Esta secuencia es permitida con un almacenamiento causalmente consistente, pero no con un almacenamiento secuencialmente consistente o con un almacenamiento consistente en forma estricta.




miércoles, 24 de agosto de 2016

Como Surgen los Sistemas Distribuidos

El concepto de Sistema Distribuido surge a partir de la necesidad de tener redes dinámicas.
La motivación para construir sistemas distribuidos tienen su origen en un deseo de compartir recursos.
En el inicio de la era de la informática las computadoras eran grandes y caras. Debido a su escasez y coste, éstas funcionaban de forma independiente entre ellas.
A partir de los años 70, surgen los primeros miniordenadores, que competirían con los grandes ordenadores tanto por las presentaciones como por su precio, con lo que se extendió su uso. Los grandes sistemas centralizados fueron dejando paso lentamente a sistemas mucho más descentralizados, y formados por varios ordenadores o a sistemas multiprocesador. Pronto surgieron nuevas necesidades de interconexión de los equipos, y se desarrollaron las redes de área local (LAN), como Ethernet o Token Ring. En la actualidad, Internet es la red de mayor tamaño y la más usada, y mantiene un impresionante ritmo de crecimiento. Además, Internet es la base de muchos nuevos proyectos de sistemas distribuidos.
Aunque los actuales sistemas de red solucionan parte de las necesidades actuales de comunicación entre computadoras, tienen importantes limitaciones, y no son aplicables a una gran cantidad de problemas. Por ello surge la necesidad de crear sistemas distribuidos que sustituyan a los actuales sistemas de red o a los sistemas multiprocesadores.
Es fundamental tener presente un sistema distribuido ya que las tareas de distribuyen entre los componentes que componen la red.