Paxos
¿Qué es Paxos?
Replicación =>Alta Disponibilidad
•Consenso
Es un algoritmo que tiene los siguientes
objetivos
Paxos:Replicación
Varias máquinas han de alcanzar el mismo
estado en algún instante de tiempo.
Si tenemos n máquinas, toda...
Paxos:Replicación
Esto en un principio parece sencillo,pero...
Si hay varios usuarios conectados al mismo
tiempo... ¿Quién...
Paxos:Replicación
Paxos:Replicación
No se puede asegurar que las dos máquinas
reciben las peticiones en el mismo orden.
La máquina 1 puede r...
Paxos:Replicación
Para que todos los ordenadores reciban las
peticiones en el mismo orden se necesita algo
que elija dicho...
Paxos
Consenso!!!
Paxos:Consenso
Todos los procesos han de llegar a un
acuerdo, para decidir que operación se
realiza.
Para esto se realiza ...
Paxos:Votación
Un proceso propone una operación para una
posición a unos procesos del sistema.
Estos procesos deciden si e...
Paxos
Una vez explicados los objetivos...
Expliquemos como funciona
Paxos!!!
Paxos:Estructura
En Paxos existen 3 tipos de procesos:
Réplicas.
Líderes.
Aceptores.
Paxos:Réplicas
Endpoint de entrada para los clientes.
Sobre la misma se implementa la aplicación
que deseamos replicar.
In...
Paxos:Réplicas
op1
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas 0 1 2
op1
op2
op2
Paxos:Réplicas
Al recibir las peticiones, observa la posición
más pequeña entre aceptadas y propuestas
que no tienen valor...
Paxos:Réplica
op1 op3
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op1
0 1 2
op2
op1
op3
op2
Paxos:Réplica
op1 op3 op2
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op1 op3
0 1 2
op2
op3
op2
Paxos:Réplica
Cuando una operación es aceptada, se
proponen las operaciones pendientes en el
siguiente slot libre.
Se proc...
Paxos:Réplica
Otro caso!!!
Paxos:Réplica
Una réplica recibe una operación aceptada
para una posición que no ha propuesto, y
posterior a las que propo...
Paxos:Réplica
Se asegura que todas las operaciones se
ejecutan en el mismo orden.
¡¡Incluso si se reciben en orden desorde...
op0
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op4
0 1 2
op4
R1
R2
Paxos:Réplica
op0
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op0 op4
0 1 2
op4
R1
R2
Ejecuta
Paxos:Réplica
op0
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op0 op4
0 1 2
op4
R1
R2
Ejecuta
Paxos:Réplica
Paxos:Líderes
Son los encargados de inicializar las
votaciones de las peticiones.
Reciben mensajes de las réplicas. Si el
...
Paxos:Líderes
¡Problema!
Petición(x),pos:1
Petición(x1),pos:1
¿Cuál de las dos
se decide?
¡Existe una colisión!
Paxos:Líderes
Para estos casos se introduce el concepto de
Ballot.
Paxos:Líderes
Cada votación se realiza dentro de un espacio
llamado ballot.
Varias peticiones pueden pertenecer a un
mismo...
Paxos:Líderes
Cada líder posee un ballot.
El ballot se identifica por un número
secuencial y el nombre del líder.
Ante una...
Paxos:Líderes
Ballot:<0,Jose>
Ballot:<0,Mariano>
Petición(x),pos:1
Petición(x1),pos:1
Mariano posee un ballot mayor.
Su pe...
Paxos:Líderes
Con esta solución se impide la colisión, pero...
¿El otro líder nunca conseguirá decidir alguna
petición?
Paxos:Líderes
Un líder con un ballot inferior recibe de sus
votantes un PREEMPT.
Es decir, se le ofrece la posibilidad de
...
Paxos:Líderes
Ballot:<0,Jose>
Ballot:<0,Mariano>
Petición(x),pos:1
Petición(x1),pos:1
PREEMPTED
ACEPTED
Paxos:Líderes
Ballot:<1,Jose>
Ballot:<0,Mariano>
Petición(X1),pos:1 ACEPTED
Paxos:Líderes
Al recibir el PREEMTED, el líder aumenta su
ballot y realiza de nuevo la votación.
¡¡Pero ha de votar con el...
Paxos:Líderes
Esto conlleva otro problema.
Cada vez que hay una colisión, un líder
aumenta su ballot y realiza de nuevo la...
Paxos:Líderes
La duplicidad de los líderes se permite para
aumentar la disponibilidad del sistema.
Si hay un líder y este ...
Paxos: Líderes
El mejor rendimiento se obtiene con un único
líder.
Para acercarse a este rendimiento sin perder
la disponi...
Paxos:Líderes
De esta forma los líderes se van
intercambiando el control, y el número de
colisiones se ve disminuida.
Paxos:Líderes
Espera un momento... antes has dicho una
cosa...
Después de recibir un PREEMPTED el líder
aumenta su ballot ...
Paxos:Líderes
¿Como sabe el líder que valor fue votado en
dicha posición?
Paxos:Líderes
Es más... Si aparece un líder nuevo, este no
sabe que se ha votado y puede dar todo el
rato “palos de ciego”...
Paxos
¡Aceptores!
Paxos:Aceptores
Los aceptores tienen dos propósitos en
Paxos:
1.Votar las peticiones de los líderes.
2.Actuar como la memo...
Paxos:Aceptores
Al almacenartodaslasoperaciones, esposible
re-establecer el sistema a partir de ellos.
Un
nuevolíderpuedec...
Paxos:Aceptores
Por lo tanto...
Paxos:Aceptores
Son una parte crítica del sistema
Si los aceptores fallan no se pueden aceptar
peticiones.
Y se pierden to...
Paxos:Aceptores
Si los aceptorespierdensuestado,
seríacomosihubiésemostrabajadodurantedías
y el día de la
entregatodohubie...
Paxos:Aceptores
Para evitar esta situación es necesario
realizar una replicación de los aceptores, para
asegurar que siemp...
Paxos:Aceptores
Esto significa que...
Una petición es aceptada si la mayoría de los
aceptores del sistema aceptan la petic...
Paxos:Aceptores
Paxos:Aceptores
El líder envía su petición y el ballot a todos los
aceptores del sistema.
Los aceptores comparan los ballo...
Paxos:Aceptores
Aceptada!
Paxos:Aceptores
El líder ha
de cambiar el ballot!
Preempted
Paxos:Aceptores
Obligando a que la mayoría de los aceptores
respondan la petición se consiguen dos
objetivos:
Un consenso....
Paxos:Aceptores
Los mensajes
pueden perderse!
Paxos
Arquitectura
Paxos:Arquitectura
El sistema se ejecuta dentro de un clúster de
ordenadores.
En el clúster, al menos los aceptores deben
...
Paxos:Arquitectura
Esta arquitectura ofrece el
servicio
¡¡Pero si falla la red se pierde la
disponibilidad!!
Paxos:Arquitectura
Se duplica la red y los puntos
de entrada.
Se soportan las caídas de red.
Se consiguen distintos domini...
Paxos:Arquitectura
Es necesario que exista un
balanceo de aceptores en cada
dominio.
Se deben de crear nuevos
procesos din...
Paxos:Arquitectura
Si un dominio cae, el otro
dominio desplegará n
aceptores, hasta que estos
constituyan una mayoría.
Paxos:Arquitectura
Los nuevos aceptores realizan
una actualización de su estado.
!De esta forma el sistema
puede seguir fu...
Paxos
¿Y todo esto al final para que sirve?
Paxos
Conseguir alta disponibilidad.
Si un programa (réplica) cae, seguirá otro
funcionando con el mismo estado.
El sistem...
Paxos
Permite realizar un “balanceo” de las
peticiones.
Un número N de réplicas pueden conectarse a
un Líder L1.
Un número...
Paxos
Réplicas Líderes Aceptores
A
L
L
L
L
L
L
R
R
R
R
R
R
Paxos
Todas las réplicas tienen un punto de entrada
al sistema.
Pero todos los puntos de entrada comparten
la misma memori...
Paxos
DEMO
Paxos:Demo
Se ha realizado una implementación del
algoritmo sobre CoffeeScript.
Se ha realizado una aplicación web que uti...
Paxos:Demo
La aplicación tiene dos partes:
Servidor: Desarrollada sobre Node.JS
Cliente: Desarrollada sobre PHP.
Paxos:Demo-Servidor
El servidor realiza dos acciones.
Contiene un servidor HTTPs, ofrece al
exterior un servicio REST con ...
Paxos:Demo-Cliente
Aplicación diseñada sobre PHP utilizando
Symfony2.
“Simplemente” consume el servicio REST y
muestra los...
Paxos:Demo
Symfony+REST+Réplica
Symfony+REST+Réplica
Líder+Aceptor
Paxos:Demo
¿Y en que consiste?
Permite al usuario subir ficheros a la “nube”.
El usuario puede listar , subir y borrar los
ficheros.
Todos los ficheros s...
El servicio REST que ofrece tiene las
siguientes acciones:
LIST => Obtiene una lista de todos los
ficheros. Realiza una pe...
DOWNLOAD => Descarga un fichero al
sistema. Realiza una petición GET.
DELETE => Elimina un fichero del
sistema.Realiza una...
El servidor utiliza HTTPs con el fin de
encriptar la comunicación.
Para asegurar que una petición se refiere a un
fichero ...
express = require 'express’
http = require 'https’
fs = require 'fs’
key = fs.readFileSync('key.pem').toString()
cert = fs...
app.put '/file' , ( req , res ) =>
resultado = (msg)=>
res.set('Content-Type', 'application/json')
msg = JSON.parse msg
ms...
app.get '/list', ( req , res ) =>
result = ( msg ) ->
res.set('Content-Type','application/json')
msg = JSON.parse msg
msg ...
app.get '/file', (req , res ) =>
result = ( msg ) ->
msg = JSON.parse msg
result = msg.body.result
res.set('Content-Type',...
app.delete '/file' , ( req , res ) =>
result = ( msg ) ->
msg = JSON.parse msg
result = msg.body.result
res.set('Content-T...
En el cliente se utiliza Guzzle.
Un API sobre PHP que facilita la creación y
consumo de servicios web utilizando REST.
MyBox: Guzzle
$client = new Client("https://127.0.0.1:3000");
//crea el tipo de cliente y forma la query
$request = $clien...
La autorización se realiza con Google+
• Puedesver un video en:
• http://www.youtube.com/watch?v=qtxz7Mvj0l4
Presentacion
Presentacion
Presentacion
Presentacion
Próxima SlideShare
Cargando en…5
×

Presentacion

390 visualizaciones

Publicado el

Presentación para la asignatura de modelado, diseño e implementación de servicios Web, de un proyecto para la replicación y alta disponibilidad de aplicaciones utilizando como base el algoritmo Paxos.

0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
390
En SlideShare
0
De insertados
0
Número de insertados
5
Acciones
Compartido
0
Descargas
7
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Presentacion

  1. 1. Paxos
  2. 2. ¿Qué es Paxos? Replicación =>Alta Disponibilidad •Consenso Es un algoritmo que tiene los siguientes objetivos
  3. 3. Paxos:Replicación Varias máquinas han de alcanzar el mismo estado en algún instante de tiempo. Si tenemos n máquinas, todas ellas deberán alcanzar un estado común.
  4. 4. Paxos:Replicación Esto en un principio parece sencillo,pero... Si hay varios usuarios conectados al mismo tiempo... ¿Quién va primero?
  5. 5. Paxos:Replicación
  6. 6. Paxos:Replicación No se puede asegurar que las dos máquinas reciben las peticiones en el mismo orden. La máquina 1 puede recibir la petición Naranja y Azul. La máquina 2 puede recibir la petición Azul y Naranja. ¡Existe inconsistencia!
  7. 7. Paxos:Replicación Para que todos los ordenadores reciban las peticiones en el mismo orden se necesita algo que elija dicho orden.
  8. 8. Paxos Consenso!!!
  9. 9. Paxos:Consenso Todos los procesos han de llegar a un acuerdo, para decidir que operación se realiza. Para esto se realiza una votación.
  10. 10. Paxos:Votación Un proceso propone una operación para una posición a unos procesos del sistema. Estos procesos deciden si están a favor o no. Si la mayoría está a favor se acepta la operación.
  11. 11. Paxos Una vez explicados los objetivos... Expliquemos como funciona Paxos!!!
  12. 12. Paxos:Estructura En Paxos existen 3 tipos de procesos: Réplicas. Líderes. Aceptores.
  13. 13. Paxos:Réplicas Endpoint de entrada para los clientes. Sobre la misma se implementa la aplicación que deseamos replicar. Internamente recibe las peticiones, las ordena en diferentes posiciones y las envía a votación. Una vez votada la operación , el programa la procesa y se retorna al cliente.
  14. 14. Paxos:Réplicas op1 Peticiones Propuestas 0 1 2 Peticiones Aceptadas 0 1 2 op1 op2 op2
  15. 15. Paxos:Réplicas Al recibir las peticiones, observa la posición más pequeña entre aceptadas y propuestas que no tienen valor. Introduce las operaciones para proponer en dicha posición. Se asegura que al menos una de las propuestas en X será aceptada en X.
  16. 16. Paxos:Réplica op1 op3 Peticiones Propuestas 0 1 2 Peticiones Aceptadas op1 0 1 2 op2 op1 op3 op2
  17. 17. Paxos:Réplica op1 op3 op2 Peticiones Propuestas 0 1 2 Peticiones Aceptadas op1 op3 0 1 2 op2 op3 op2
  18. 18. Paxos:Réplica Cuando una operación es aceptada, se proponen las operaciones pendientes en el siguiente slot libre. Se procesa la operación aceptada y se retorna al cliente. ¡No tienen porque coincidir con el orden de envío del cliente!
  19. 19. Paxos:Réplica Otro caso!!!
  20. 20. Paxos:Réplica Una réplica recibe una operación aceptada para una posición que no ha propuesto, y posterior a las que propone. La réplica ha de almacenar pero no ejecutar dicha operación. Cuando decida una operación, ejecutará todas las operaciones en orden secuencial.
  21. 21. Paxos:Réplica Se asegura que todas las operaciones se ejecutan en el mismo orden. ¡¡Incluso si se reciben en orden desordenado!!
  22. 22. op0 Peticiones Propuestas 0 1 2 Peticiones Aceptadas op4 0 1 2 op4 R1 R2 Paxos:Réplica
  23. 23. op0 Peticiones Propuestas 0 1 2 Peticiones Aceptadas op0 op4 0 1 2 op4 R1 R2 Ejecuta Paxos:Réplica
  24. 24. op0 Peticiones Propuestas 0 1 2 Peticiones Aceptadas op0 op4 0 1 2 op4 R1 R2 Ejecuta Paxos:Réplica
  25. 25. Paxos:Líderes Son los encargados de inicializar las votaciones de las peticiones. Reciben mensajes de las réplicas. Si el mensaje no ha sido decidido entonces inician la votación.
  26. 26. Paxos:Líderes ¡Problema! Petición(x),pos:1 Petición(x1),pos:1 ¿Cuál de las dos se decide? ¡Existe una colisión!
  27. 27. Paxos:Líderes Para estos casos se introduce el concepto de Ballot.
  28. 28. Paxos:Líderes Cada votación se realiza dentro de un espacio llamado ballot. Varias peticiones pueden pertenecer a un mismo ballot. Pero un ballot solamente pertenece a un líder. ¡Así se evitan colisiones!.
  29. 29. Paxos:Líderes Cada líder posee un ballot. El ballot se identifica por un número secuencial y el nombre del líder. Ante una votación se comparan los valores del ballot. Gana aquel que tiene un ballot mayor.
  30. 30. Paxos:Líderes Ballot:<0,Jose> Ballot:<0,Mariano> Petición(x),pos:1 Petición(x1),pos:1 Mariano posee un ballot mayor. Su petición seguramente sea la aceptada.
  31. 31. Paxos:Líderes Con esta solución se impide la colisión, pero... ¿El otro líder nunca conseguirá decidir alguna petición?
  32. 32. Paxos:Líderes Un líder con un ballot inferior recibe de sus votantes un PREEMPT. Es decir, se le ofrece la posibilidad de aumentar su ballot y tomar el control. Simplemente ha de aumentar su ballot una unidad por encima del ballot actual.
  33. 33. Paxos:Líderes Ballot:<0,Jose> Ballot:<0,Mariano> Petición(x),pos:1 Petición(x1),pos:1 PREEMPTED ACEPTED
  34. 34. Paxos:Líderes Ballot:<1,Jose> Ballot:<0,Mariano> Petición(X1),pos:1 ACEPTED
  35. 35. Paxos:Líderes Al recibir el PREEMTED, el líder aumenta su ballot y realiza de nuevo la votación. ¡¡Pero ha de votar con el mismo valor ya adoptado!! Así se asegura que todos los líderes votan el mismo valor para la misma posición incluso en diferentes ballots.
  36. 36. Paxos:Líderes Esto conlleva otro problema. Cada vez que hay una colisión, un líder aumenta su ballot y realiza de nuevo la petición. ¡El número de mensajes aumenta en función del número de Líderes! Más Líderes => Más mensajes => Menor rendimiento.
  37. 37. Paxos:Líderes La duplicidad de los líderes se permite para aumentar la disponibilidad del sistema. Si hay un líder y este cae el sistema no avanzaría. Con varios líderes se resuelve. Vale...muy bien, ¿pero el rendimiento?
  38. 38. Paxos: Líderes El mejor rendimiento se obtiene con un único líder. Para acercarse a este rendimiento sin perder la disponibilidad... Si un líder recibe PREEMPTED, se mantiene dormido durante un intervalo T. Al finalizar dicho intervalo toma el control.
  39. 39. Paxos:Líderes De esta forma los líderes se van intercambiando el control, y el número de colisiones se ve disminuida.
  40. 40. Paxos:Líderes Espera un momento... antes has dicho una cosa... Después de recibir un PREEMPTED el líder aumenta su ballot y propone el valor ya aceptado en la posición...
  41. 41. Paxos:Líderes ¿Como sabe el líder que valor fue votado en dicha posición?
  42. 42. Paxos:Líderes Es más... Si aparece un líder nuevo, este no sabe que se ha votado y puede dar todo el rato “palos de ciego”. ¿Como consigue conocer todo el estado del sistema y así “estar al día”?
  43. 43. Paxos ¡Aceptores!
  44. 44. Paxos:Aceptores Los aceptores tienen dos propósitos en Paxos: 1.Votar las peticiones de los líderes. 2.Actuar como la memoria principal del sistema, almacenando todas las peticiones aceptadas.
  45. 45. Paxos:Aceptores Al almacenartodaslasoperaciones, esposible re-establecer el sistema a partir de ellos. Un nuevolíderpuedeconocertodaslasvotaciones. Unanuevaréplicapuedeejecutartodaslasoperac ionesparaponerse al día.
  46. 46. Paxos:Aceptores Por lo tanto...
  47. 47. Paxos:Aceptores Son una parte crítica del sistema Si los aceptores fallan no se pueden aceptar peticiones. Y se pierden todas las peticiones.
  48. 48. Paxos:Aceptores Si los aceptorespierdensuestado, seríacomosihubiésemostrabajadodurantedías y el día de la entregatodohubiesedesaparecido. ¡Nosabríamosquedado sin nada!
  49. 49. Paxos:Aceptores Para evitar esta situación es necesario realizar una replicación de los aceptores, para asegurar que siempre estén disponibles. Es necesario que existan siempre al menos (f/2)+1 aceptores funcionando, donde f es el número de fallos soportados.
  50. 50. Paxos:Aceptores Esto significa que... Una petición es aceptada si la mayoría de los aceptores del sistema aceptan la petición. ¡Existe un consenso!
  51. 51. Paxos:Aceptores
  52. 52. Paxos:Aceptores El líder envía su petición y el ballot a todos los aceptores del sistema. Los aceptores comparan los ballots: Si el ballot es mayor acepta la petición y la almacena. Si es inferior manda un PREEMTED al líder.
  53. 53. Paxos:Aceptores Aceptada!
  54. 54. Paxos:Aceptores El líder ha de cambiar el ballot! Preempted
  55. 55. Paxos:Aceptores Obligando a que la mayoría de los aceptores respondan la petición se consiguen dos objetivos: Un consenso. Asegurar que siempre hay un conjunto de aceptores que conocen todas las peticiones.
  56. 56. Paxos:Aceptores Los mensajes pueden perderse!
  57. 57. Paxos Arquitectura
  58. 58. Paxos:Arquitectura El sistema se ejecuta dentro de un clúster de ordenadores. En el clúster, al menos los aceptores deben estar desplegados. Los líderes y réplicas podrían encontrarse en una red externa.
  59. 59. Paxos:Arquitectura Esta arquitectura ofrece el servicio ¡¡Pero si falla la red se pierde la disponibilidad!!
  60. 60. Paxos:Arquitectura Se duplica la red y los puntos de entrada. Se soportan las caídas de red. Se consiguen distintos dominios de fallo: Ante el fallo de un sistema el resto sigue disponible.
  61. 61. Paxos:Arquitectura Es necesario que exista un balanceo de aceptores en cada dominio. Se deben de crear nuevos procesos dinámicamente , según las necesidades.
  62. 62. Paxos:Arquitectura Si un dominio cae, el otro dominio desplegará n aceptores, hasta que estos constituyan una mayoría.
  63. 63. Paxos:Arquitectura Los nuevos aceptores realizan una actualización de su estado. !De esta forma el sistema puede seguir funcionando!
  64. 64. Paxos ¿Y todo esto al final para que sirve?
  65. 65. Paxos Conseguir alta disponibilidad. Si un programa (réplica) cae, seguirá otro funcionando con el mismo estado. El sistema podría crear tantas réplicas como sean necesarias en cada momento.
  66. 66. Paxos Permite realizar un “balanceo” de las peticiones. Un número N de réplicas pueden conectarse a un Líder L1. Un número N’ de réplicas pueden conectarse a un Líder L2. Si ambos líderes tienen en común los aceptores, ambos tendrán la misma información.
  67. 67. Paxos Réplicas Líderes Aceptores
  68. 68. A L L L L L L R R R R R R
  69. 69. Paxos Todas las réplicas tienen un punto de entrada al sistema. Pero todos los puntos de entrada comparten la misma memoria, por lo que tienen el mismo estado.
  70. 70. Paxos DEMO
  71. 71. Paxos:Demo Se ha realizado una implementación del algoritmo sobre CoffeeScript. Se ha realizado una aplicación web que utiliza dicha implementación para replicar su estado.
  72. 72. Paxos:Demo La aplicación tiene dos partes: Servidor: Desarrollada sobre Node.JS Cliente: Desarrollada sobre PHP.
  73. 73. Paxos:Demo-Servidor El servidor realiza dos acciones. Contiene un servidor HTTPs, ofrece al exterior un servicio REST con un conjunto de aplicaciones. Procesa las operaciones y guarda los datos en una BBDD MongoDB.
  74. 74. Paxos:Demo-Cliente Aplicación diseñada sobre PHP utilizando Symfony2. “Simplemente” consume el servicio REST y muestra los resultados al cliente.
  75. 75. Paxos:Demo Symfony+REST+Réplica Symfony+REST+Réplica Líder+Aceptor
  76. 76. Paxos:Demo ¿Y en que consiste?
  77. 77. Permite al usuario subir ficheros a la “nube”. El usuario puede listar , subir y borrar los ficheros. Todos los ficheros son replicados en diferentes servidores Vale..es una copia descarada de DropBox.
  78. 78. El servicio REST que ofrece tiene las siguientes acciones: LIST => Obtiene una lista de todos los ficheros. Realiza una petición GET. UPLOAD => Sube un fichero al sistema.Realiza una petición PUT.
  79. 79. DOWNLOAD => Descarga un fichero al sistema. Realiza una petición GET. DELETE => Elimina un fichero del sistema.Realiza una petición DELETE.
  80. 80. El servidor utiliza HTTPs con el fin de encriptar la comunicación. Para asegurar que una petición se refiere a un fichero de un usuario en concreto... Se puede enviar el mensaje con un token vinculado a la sesión del usuario. Si no coincide no tiene derechos sobre el mismo.
  81. 81. express = require 'express’ http = require 'https’ fs = require 'fs’ key = fs.readFileSync('key.pem').toString() cert = fs.readFileSync('cert.pem').toString() app = express() https = http.createServer({key:key,cert:cert},app) app.use(require('connect').bodyParser()) https.listen 3000 Creación servidor Https
  82. 82. app.put '/file' , ( req , res ) => resultado = (msg)=> res.set('Content-Type', 'application/json') msg = JSON.parse msg msg = {operation:'UPLOAD',result:msg.body.result} res.send(msg) Stub.sendOperation('WRITE’,type:'UPLOAD', name:req.body.name, file:req.body.file, mimetype:req.body.mimetype}).then resultado Servicio REST: Upload File
  83. 83. app.get '/list', ( req , res ) => result = ( msg ) -> res.set('Content-Type','application/json') msg = JSON.parse msg msg = {operation:'LIST',result:msg.body.result} res.send(msg) Stub.sendOperation('READ',{type:'LIST'}).then result Servicio REST: Listar Ficheros
  84. 84. app.get '/file', (req , res ) => result = ( msg ) -> msg = JSON.parse msg result = msg.body.result res.set('Content-Type','application/json') msg = {operation:'DOWNLOAD',result:result} res.send(msg) Stub.sendOperation('READ',{type:'DOWNLOAD',id:req.query.id}).then result Servicio REST: Descargar Fichero
  85. 85. app.delete '/file' , ( req , res ) => result = ( msg ) -> msg = JSON.parse msg result = msg.body.result res.set('Content-Type','application/json') msg = {operation:'DELETE',result:result} res.send(msg) Stub.sendOperation('WRITE',{type:'DELETE',id:req.query.id}).then result Servicio REST: Eliminar Fichero
  86. 86. En el cliente se utiliza Guzzle. Un API sobre PHP que facilita la creación y consumo de servicios web utilizando REST.
  87. 87. MyBox: Guzzle $client = new Client("https://127.0.0.1:3000"); //crea el tipo de cliente y forma la query $request = $client->delete("file"); $request->getQuery()->add("id", $id); //utilizado para no comprobar el certificado SSL $request->getCurlOptions()->set(CURLOPT_SSL_VERIFYHOST, false); $request->getCurlOptions()->set(CURLOPT_SSL_VERIFYPEER, false); //Se envía la petición y se procesa el resultado en JSON $response = $request->send(); $data = $response->json(); $data = $data['result']; $data = json_decode($data,true);
  88. 88. La autorización se realiza con Google+
  89. 89. • Puedesver un video en: • http://www.youtube.com/watch?v=qtxz7Mvj0l4

×