Nella nostra architettura il servizio di validazione (che ha anche un endpoint per le statistiche circa i biglietti validati) ha bisogno della chiave usata dal TravelerService per firmare i biglietti emessi.
Abbiamo scelto di non includere in maniera hardcoded tale chiave anche nel servizio di validazione, ma che debba essere tale servizio a chiederla al TravelerService, che così può avere la completa gestione delle chiavi utili alla generazione dei biglietti.
Per farlo è necessario contattare il Traveler a un endpoint destinato solo agli embedded system.
Per cui il validator service deve prima autenticarsi tamite il LoginService.
Questo è quello che avevamo in parte descritto nella issue #25
Abbiamo scelto di utilizzare un approccio sincrono, tramite REST API: in questa maniera il servizio prova ad ottenere ciò che gli serve (token di autenticazione + chiave per la validazione) allo startup e in caso di fallimento, proverà ad ottenere ciò che gli manca, contattando il servizio corrispondente la prima volta che qualcuno proverà ad utilizzare l'endpoint di validazione.
Un'alternativa poteva essere un approccio asincrono, pull-based, con un messsage broker ed eventuali meccanismi di protezione (un topic kafka protetto per lo scambio della chiave di validazione). In questa maniera il servizio di validazione sarebbe rimasto inattivo, fin quando un produttore non avrebbe pushato il segreto necessario nella coda.
Un approccio sincrono espone ad eventuali delay nella gestione di una richiesta di validazione e alla generazione di richieste http verso un endpoint di un servizio che magari non sta rispondendo perché congestionato, con aumento della congestione e del traffico di rete. Questo problema può essere risolto con l'impiego di un circuit breaker (vedi resilience4J)
Nella nostra architettura il servizio di validazione (che ha anche un endpoint per le statistiche circa i biglietti validati) ha bisogno della chiave usata dal TravelerService per firmare i biglietti emessi. Abbiamo scelto di non includere in maniera hardcoded tale chiave anche nel servizio di validazione, ma che debba essere tale servizio a chiederla al TravelerService, che così può avere la completa gestione delle chiavi utili alla generazione dei biglietti. Per farlo è necessario contattare il Traveler a un endpoint destinato solo agli embedded system. Per cui il validator service deve prima autenticarsi tamite il LoginService. Questo è quello che avevamo in parte descritto nella issue #25 Abbiamo scelto di utilizzare un approccio sincrono, tramite REST API: in questa maniera il servizio prova ad ottenere ciò che gli serve (token di autenticazione + chiave per la validazione) allo startup e in caso di fallimento, proverà ad ottenere ciò che gli manca, contattando il servizio corrispondente la prima volta che qualcuno proverà ad utilizzare l'endpoint di validazione. Un'alternativa poteva essere un approccio asincrono, pull-based, con un messsage broker ed eventuali meccanismi di protezione (un topic kafka protetto per lo scambio della chiave di validazione). In questa maniera il servizio di validazione sarebbe rimasto inattivo, fin quando un produttore non avrebbe pushato il segreto necessario nella coda.
Un approccio sincrono espone ad eventuali delay nella gestione di una richiesta di validazione e alla generazione di richieste http verso un endpoint di un servizio che magari non sta rispondendo perché congestionato, con aumento della congestione e del traffico di rete. Questo problema può essere risolto con l'impiego di un circuit breaker (vedi resilience4J)