Today applications are often designed with a modular approach, dividing functionality into micro services rather than relying on a monolithic structure. This requires solutions for decoupled message exchange throughout the distributed system and can be achieved by implementing a message broker. In some cases, it is interesting to make the message broker itself a distributed system, which has been a development path for systems such as RabbitMQ, Apache Kafka, and others. This thesis seeks to understand the alternative approaches to implementing  a distributed solution for the message broker LavinMQ. To find out which algorithm would be the most suitable for this purpose, a comparative analysis of the most common alternatives was performed based on LavinMQ's requirements and a literature review of related comparisons. The results showed that Raft would be the best choice due to its simple but effective nature. To further investigate the consensus approach in LavinMQ, a Raft prototype was developed in the programming language Crystal. The prototype was then evaluated based on correctness and performance in terms of mean replication time and mean election time. The prototype successfully passed the correctness tests, showing that the prototype successfully achieves correctness according to LavinMQ standard. The mean election time results show that the prototype recovers from a leader failure in 216 ms and that the most effective range for the heartbeat timeout is 150 to 300 ms. The replication time test results show that the mean replication time is 84.45 ms and the most efficient interval for message replication is 0.13 ms. The performance results are consistent with the results of related work, however result in overall slower performance and indicate that some additional features and optimizations need to be implemented in order to consider the prototype for practical use.

O modelo de atores tem sido visto como uma abordagem alternativa à programação concorrente convencional, baseada em travas e variáveis de condição. Atores são agentes computacionais que se comunicam por troca de mensagens e que possuem uma caixa de correio e um comportamento. As mensagens destinadas a um ator são armazenadas na caixa de correio do ator e processadas de maneira assíncrona. Sistemas de middleware orientados a mensagens trabalham com troca assíncrona de mensagens e formam uma base que simplifica o desenvolvimento de aplicações distribuídas. Tais sistemas permitem interoperabilidade com baixo acoplamento e provêm suporte para tratamento robusto de erros em caso de falhas. Message brokers são frequentemente apresentados como uma tecnologia que pode mudar a maneira com que sistemas distribuídos são construídos. A especificação AMQP é uma proposta recente de padronização de um protocolo para message brokers. Neste trabalho exploramos a potencial sinergia entre um message broker e uma implementação do modelo de atores. Criamos uma versão modificada da implementação do modelo de atores do projeto Akka que utiliza um message broker AMQP como mecanismo de transporte de mensagens para atores remotos. / The actor model has been seen as an alternative for conventional concurrent programming based on locks and condition variables. Actors are computational agents that communicate by sending messages and have a mailbox and a behavior. The messages sent to an actor are stored in its mailbox and are asynchronously processed. Message oriented middleware systems work with asynchronous message exchange and create a base that simplifies the development of distributed applications. These systems have interoperability with low coupling and provide support for robust error handling in case of failures. Message brokers are often presented as a technology that can change the way distributed systems are built. The AMQP specification is a recent proposal of a standard protocol for message brokers. In this document we explore the potential synergy between a message broker and an implementation of the actor model. We created a modified version of the actor model implementation provided by the Akka project. Our modified implementation uses an AMQP message broker as the transport engine for messages to remote actors.

O modelo de atores tem sido visto como uma abordagem alternativa à programação concorrente convencional, baseada em travas e variáveis de condição. Atores são agentes computacionais que se comunicam por troca de mensagens e que possuem uma caixa de correio e um comportamento. As mensagens destinadas a um ator são armazenadas na caixa de correio do ator e processadas de maneira assíncrona. Sistemas de middleware orientados a mensagens trabalham com troca assíncrona de mensagens e formam uma base que simplifica o desenvolvimento de aplicações distribuídas. Tais sistemas permitem interoperabilidade com baixo acoplamento e provêm suporte para tratamento robusto de erros em caso de falhas. Message brokers são frequentemente apresentados como uma tecnologia que pode mudar a maneira com que sistemas distribuídos são construídos. A especificação AMQP é uma proposta recente de padronização de um protocolo para message brokers. Neste trabalho exploramos a potencial sinergia entre um message broker e uma implementação do modelo de atores. Criamos uma versão modificada da implementação do modelo de atores do projeto Akka que utiliza um message broker AMQP como mecanismo de transporte de mensagens para atores remotos. / The actor model has been seen as an alternative for conventional concurrent programming based on locks and condition variables. Actors are computational agents that communicate by sending messages and have a mailbox and a behavior. The messages sent to an actor are stored in its mailbox and are asynchronously processed. Message oriented middleware systems work with asynchronous message exchange and create a base that simplifies the development of distributed applications. These systems have interoperability with low coupling and provide support for robust error handling in case of failures. Message brokers are often presented as a technology that can change the way distributed systems are built. The AMQP specification is a recent proposal of a standard protocol for message brokers. In this document we explore the potential synergy between a message broker and an implementation of the actor model. We created a modified version of the actor model implementation provided by the Akka project. Our modified implementation uses an AMQP message broker as the transport engine for messages to remote actors.

No description available.

In this thesis, a scalable, highly available and reactive RabbitMQ cluster is implemented on Amazon Web Services (AWS) and Microsoft Azure. An alternative solution was created on AWS using the CloudFormation service. These solutions are performance tested using the RabbitMQ PerfTest tool by simulating high loads with varied parameters. The test results are used to analyze the throughput and price-performance ratio for a chosen set of instances on the respective cloud platforms. How performance changes between instance family types and cloud platforms is tested and discussed. Additional conclusions are presented regarding the general performance differences in infrastructure between AWS and Microsoft Azure.

<p>Validerat; 20101217 (root)</p>

The microservice architectural pattern refers to a system consisting of independently deployable services that communicate across networks. RabbitMQ is a popular message broker that can be used to make this communication possible. An alternative to this is Amazon Simple Queuing Service (SQS), which is a fully managed queuing service. By performing a literature- and case study, two systems with a microservice architecture are developed. One using RabbitMQ to communicate between the services, and the other using Amazon SQS. The systems are compared, with regards to message latency, ease of use and maintainability. The results show that RabbitMQ provides much lower message latency than Amazon SQS. Amazon SQS is however both easier to maintain and to use than RabbitMQ. / En mikrotjänstarkitektur syftar till ett system bestående av tjänster som kan driftsättas oberoende av varandra och som kommunicerar över nätverk. RabbitMQ är en populär meddelandemäklare som nyttjas för att möjliggöra ovan nämnd kommunikation. Ett alternativ till detta är Amazon Simple Queueing Service (SQS), vilket är en meddelandetjänst som helt och hållet förvaltas av Amazon. Genom att utföra en litteratur- och fallstudie utvecklas två system med en mikrotjänstarkitektur. Det ena nyttjar RabbitMQ för kommunikation mellan tjänster, medan det andra använder Amazon SQS. Båda systemen jämförs därefter med hänsyn till meddelandens fördröjning, användarvänlighet samt enkelhet att underhålla. Resultaten visar att meddelanden skickade genom RabbitMQ har mycket lägre fördröjning än de skickade genom Amazon SQS. Ur perspektiven användarvänlighet och enkelhet att underhålla är Amazon SQS ett mer fördelaktigt akternativ än RabbitMQ.

Systems for selective dissemination of information (SDI) are used to efficiently filter, transform, and route incoming XML documents according to pre-registered XPath profiles to subscribers. Recent work focuses on the efficient implementation of the SDI core/filtering engine. Surprisingly, all systems are based on the best effort principle: The resulting XML document is delivered to the consumer as soon as the filtering engine has successfully finished. In this paper, we argue that a more specific Quality-of-Service consideration has to be applied to this scenario. We give a comprehensive motivation of quality of service in SDI-systems, discuss the two most critical factors of XML document size and shape and XPath structure and length, and finally outline our current prototype of a Quality-of-Service-based SDI-system implementation based on a real-time operating system and an extention of the XML toolkit.

В работе рассматриваются подходы к созданию интеграционной платформы, для цепочки взаимодействия сервисов расположенных в разной доступности сети. Основное внимание сфокусировано на проектировании и разработке сервисной шины предприятия, реализующей событийную интеграцию с помощью брокера сообщений. Как результат представлено готовое решение модуля корпоративной платформы, которое адаптивно под схожие системы. Магистерская диссертация состоит из введения, трех глав и заключения, изложенных на 79 страницах, а также библиографического списка. В работе имеется 18 рисунок. Библиографический список состоит из 36 наименований. / The paper considers approaches to creating an integration platform for the chain of interaction of services located in different network accessibility. The main attention is focused on the design and development of an enterprise service bus that implements event-based integration using a message broker. As a result, a ready-made solution for the corporate platform module is presented, which is adaptive for similar systems. The master's thesis consists of an introduction, three chapters and a conclusion set out on 79 pages, as well as a bibliographic list. There are 18 drawings in the work. The bibliographic list consists of 36 titles.

Microservice architecture, which involves breaking down applications into smaller and loosely coupled components, is becoming increasingly common in the development of modern systems. Connections between these components can be established in various ways. One of these approaches is event-driven architecture, where components in the system communicate asynchronously with each other through message queues.  AWS, Amazon Web Services, the largest provider of cloud-based services, offers such a messaging queue: SQS, Amazon Simple Queue Service, which can be integrated with SNS, Amazon Simple Notification Service, to enable "one-to-many" asynchronous communication.  An alternative tool is Apache Kafka, created by LinkedIn and later open-sourced under the Apache Software Foundation. Apache Kafka is an event logging and streaming platform that can also function as a message queue in an event-driven architecture.  The authors of this thesis have been commissioned by Scania to compare and evaluate the performance of these two tools and investigate whether there are use cases where one might be more suitable than the other. To achieve this, two prototypes were developed, each prototype consisting of a producer microservice and a consumer microservice. These prototypes were then used to conduct latency and load tests by producing messages and measuring the time interval until they were consumed.  The results of the tests show that Apache Kafka has a lower average latency than SNS/SQS and scales more efficiently with increasing data volumes, making it more suitable for use cases involving real-time data streaming. Its potential as a message bus for loosely coupled components in the system is also evident. In this context, SNS/SQS is equally valuable, as it operates as a dedicated message bus with good latency and offers a user-friendly and straightforward setup process. / Mikrotjänstarkitektur, som innebär att applikationer bryts ned till mindre och löst kopplade komponenter, är något som blir allt vanligare vid utvecklingen av moderna system. Kopplingar mellan dessa komponenter kan etableras på olika sätt. Ett av dessa tillvägagångssätt är händelsedriven arkitektur, där komponenterna i systemet kommunicerar asynkront med varandra genom meddelandeköer.  AWS, Amazon Web Services, som är den största leverantören av molnbaserade tjänster, tillhandahåller en sådan meddelandekö: SQS, Amazon Simple Queue Service, som kan integreras med SNS, Amazon Simple Notification Service för att möjliggöra ”en-till-många” asynkron kommunikation.  Ett alternativt verktyg är Apache Kafka, skapat av Linkedin och senare öppen källkodspublicerad under Apache Software Foundation. Apache Kafka är en händelselogg och strömningsplattform som även kan fungera som en meddelandekö i en händelsedriven arkitektur.  Författarna av detta arbete har på uppdrag av Scania blivit ombedda att jämföra och utvärdera prestandan hos de två verktygen samt undersöka om det finns användningsfall där det ena kan vara mer lämpligt än det andra. För att uppnå detta utvecklades två prototyper, där varje prototyp består av en producent- och en konsumentmikrotjänst. Dessa prototyper användes sedan för att genomföra latens- och lasttester genom att producera meddelanden och mäta tidsintervallet till dess att de konsumerades.  Resultatet från testerna visar att Apache Kafka har lägre genomsnittlig latens än SNS/SQS och skalar mer effektivt vid ökande datamängder, vilket gör det mer lämpat för användningsfall med realtidsströmning av data. Dess potential som meddelandebuss för löst kopplade komponenter i systemet är också tydlig. I detta sammanhang är SNS/SQS lika användbart, då det fungerar som en dedikerad meddelandebuss med god latens och en användarvänlig och enkel startprocess.