No description available.

The microservice architecture is a new architectural style that structures an application into a set of small, independently deployable microservices, as opposed to the traditional monolith approach with a single executable. The microservice architecture is a distributed system that results in new challenges and increased complexity. This study expands the previous related research and investigates the implications of using the one-database-per-service pattern and a solution to the introduced need of queries spanning multiple microservices. In this thesis, two applications are presented, one with the microservice architecture and one monolithic counterpart, which are compared in terms of response time and throughput. As a solution for the distributed queries, the API Composition pattern was chosen. The results of the experiments conclude in a greater understanding of the difficulty in distributed queries as well as the benefits and limitations of the API composition pattern. It shows that the API composition pattern is a valid solution for distributed queries. However, it does perform worse in terms of response time and throughput than the monolith prototype. This results in the insights that one must carefully choose, with respect to the requirements of the system, when to apply it.

Dans un contexte où nous produisons de plus en plus de données personnelles et où nous contrôlons de moins en moins comment et par qui elles sont utilisées, une nouvelle manière de les gérer voit le jour: le « nuage personnel ». En partenariat avec la jeune pousse française Cozy Cloud (https://cozy.io) qui développe une telle technologie, nous définissons à travers ces travaux une manière collaborative d'interroger ces nuages personnels qui respecte la vie privée des utilisateurs.Pour y parvenir nous détaillons dans cette thèse trois contributions : (1) un ensemble de quatre prérequis que tout protocole doit respecter dans ce contexte particulier : l'aléa imposé qui empêche un attaquant d'influencer le déroulement de l'exécution, la dispersion des connaissances qui assure qu'aucun participant ne possède trop d'informations, l'atomicité des tâches qui diminue au maximum le rôle joué par chaque participant directement impliqué dans l'exécution et les communications cachées pour protéger l'identité des participants et les informations échangées ; (2) SEP2P un protocole se basant sur une table de hashage distribuée et CSAR, un protocole permettant de générer un nombre aléatoire, afin de générer une liste aléatoire et vérifiable d'acteurs en accord avec le premier prérequis ; et (3) DISPERS un protocole qui applique les trois derniers prérequis et découpe l'exécution d'une requête de sorte à minimiser les informations accédées par chaque acteur pour minimiser l'impact d'une fuite au cas où un attaquant aurait été sélectionné parmi ces mêmes acteurs. / In a context where we produce more and more personal data and where we control less and less how and by whom they are used, a new way of managing them is on the rise: the "personal cloud". In partnership with the french start-up Cozy Cloud (https://cozy.io) that is developing such technology, we propose through this work a way of collaboratively querying the personal clouds while preserving the privacy of the users.We detail in this thesis three contributions to achieve this objective: (1) a set of four requirements any protocol has to respect in this particular context: imposed randomness to prevent an attacker from influencing the execution of a query, knowledge dispersion to prevent any node from concentrating information, task atomicity to split the execution in as many independent tasks as necessary and hidden communications to protect the identity of the participants as well as the content of their communications; (2) SEP2P a protocol leveraging a distributed hash table and CSAR, another protocol that generates a verifiable random number, in order to generate a random and verifiable list of actors in accordance with the first requirement; and (3) DISPERS a protocol that applies the last three requirements and splits the execution of a query so as to minimize the impact of a leakage (in case an attacker was selected as actor) by providing to each actor the minimum amount of information it needs in order to execute its task.

Com a grande quantidade de informações existentes nas aplicações computacionais hoje em dia, cada vez mais tornam-se necessários mecanismos que facilitem e aumentem o desempenho da recuperação dessas informações. Nesse contexto vem surgindo os bancos de dados chamados de NOSQL, que são bancos de dados tipicamente não relacionais que, em prol da disponibilidade e do desempenho em ambientes com enormes quantidades de dados, abrem mão de requisitos antes vistos como fundamentais. Neste trabalho iremos lidar com esse cenário ao implementar o módulo de consultas distribuídas do JBoss Infinispan, um sistema de cache distribuído que funciona também como um banco de dados NOSQL em memória. Além de apresentar a implementação desse módulo, iremos falar do surgimento do movimento NOSQL, de como se caracterizam esses bancos e de onde o Infinispan se insere nesse movimento. / With the big amount of data available to computer applications nowadays, there is an increasing need for mechanisms that facilitate the retrieval of such data and improve data access performance. In this context we see the emergence of so-called NOSQL databases, which are databases that are typically non-relational and that give up fulfilling some requirements previously seen as fundamental in order to achieve better availability and performance in big data environments. In this work we deal with the scenario above and implement a module that supports distributed queries in JBoss Infinispan, a distributed cache system that works also as an in-memory NOSQL database. Besides presenting the implementation of that module, we discuss the emergence of the NOSQL movement, the characterization of NOSQL databases, and where Infinispan fits in this context.

Com a grande quantidade de informações existentes nas aplicações computacionais hoje em dia, cada vez mais tornam-se necessários mecanismos que facilitem e aumentem o desempenho da recuperação dessas informações. Nesse contexto vem surgindo os bancos de dados chamados de NOSQL, que são bancos de dados tipicamente não relacionais que, em prol da disponibilidade e do desempenho em ambientes com enormes quantidades de dados, abrem mão de requisitos antes vistos como fundamentais. Neste trabalho iremos lidar com esse cenário ao implementar o módulo de consultas distribuídas do JBoss Infinispan, um sistema de cache distribuído que funciona também como um banco de dados NOSQL em memória. Além de apresentar a implementação desse módulo, iremos falar do surgimento do movimento NOSQL, de como se caracterizam esses bancos e de onde o Infinispan se insere nesse movimento. / With the big amount of data available to computer applications nowadays, there is an increasing need for mechanisms that facilitate the retrieval of such data and improve data access performance. In this context we see the emergence of so-called NOSQL databases, which are databases that are typically non-relational and that give up fulfilling some requirements previously seen as fundamental in order to achieve better availability and performance in big data environments. In this work we deal with the scenario above and implement a module that supports distributed queries in JBoss Infinispan, a distributed cache system that works also as an in-memory NOSQL database. Besides presenting the implementation of that module, we discuss the emergence of the NOSQL movement, the characterization of NOSQL databases, and where Infinispan fits in this context.