Project for the Concurrent Software Architectures Implementation class.
Web Application for auctioning products.
===============================
mix deps.getmix ecto.create && mix ecto.migrate (es necesario tener PostgreSQL)Levantar el server principal:
> iex --sname main -S mix phoenix.serverLevantar el server de backup:
> failover='main@<hostname>' iex --sname backup -S mix phoenix.serverEl server de backup pinguea al server principal, cuando detecta que está caido el se inicia el server http en el server de backup.
POST /api/subastas
body:
{
"subasta": {
"titulo": "subasta 2",
"precio_base": 100,
"duracion": 5000,
"vendedor": "pablo"
}
}POST /api/subastas/:id_subasta/cancelarPOST /api/subastas/:id_subasta/ofertas
body:
{
"oferta": {
"precio": 20000,
"comprador": "pablo"
}
}Es un GenServer que se encarga de notificar a la app http que se termina una subasta.
Cuando inicia carga las subastas activas de la db y cada vez que se agrega una hay que mandarle un cast con {:nueva_subasta, subasta_id}.
Cuando un vendedor cancela la subasta se le envía {:cancela_subasta, subasta_id}.
TP final de Arquitecturas Concurrentes
Queremos implementar un API HTTP para un servicio de subastas de elementos on-line. Momentáneamente queremos concentrarnos sólo en:
No vamos preocuparnos por ahora por:
En esta primera etapa vamos a construir una prueba de concepto de la arquitectura; los únicos requerimientos no funcionales son:
Se podrá utilizar cualquier tecnología que aplique alguno de los siguientes conceptos vistos en la cursada:
Obviamente, lo más simple es basarse en Elixir/OTP, Haskell, o Node.js, que son las tecnologías principales que vimos en la materia. Otras opciones son tecnologías basadas en Scala/Akka, Go, Clojure, etc, pero ahi te podremos dar menos soporte
Se deberá construir el sistema descrito, tanto el servidor como clientes de prueba. No es obligatoria la construcción de casos de prueba automatizados, pero constituye un gran plus. Se evaluará que:
En lugar de describir el dominio, vamos a presentarlo a través de algunos escenarios.
Similar al escenario anterior, pero antes de terminar la subasta, B oferta un precio mayor, y al cumplirse el plazo, se le adjudica a éste. Obviamente, este proceso de superar la oferta anterior puede repetirse indefinidamente mientras la subasta esté abierta.
Similar a los escenarios anteriores, pero el vendedor cancela la subasta antes de la expiración de la subasta y adjudicación del ganador. En este caso, obviamente, nadie gana la subasta, y todos los compradores son notificados.
Similar a los escenarios anteriores, pero un tercer participante, C, se registra después de que la subasta inició y antes de que termine. C podrá hacer ofertas y ganar la subasta como cualquier otro participante (A y B, en este caso)
Mientras una subasta está en progreso, un vendedor (que puede ser el mismo de la anterior u otro) crea una nueva subasta, y las dos subastas estarán en progreso en simultáneo, funcionando cada una de ellas como siempre.
Con la subasta ya en progreso, el servidor abruptamente falla por un error de hardware. En no más de 5 segundos un segundo servidor debe levantarse y continuar con la subasta. Esto significa que de alguna forma los clientes tienen que dejar de hablar con el servidor caído, para empezar a hablar con el nuevo servidor.
Vamos a considerar en el error kernel (es decir, los datos que no podemos perder) a:
Cuando se produce una caída, se debería extender el plazo de la subasta en 5 segundos.