Thesis discusses about different ways of a communication between components of a distributed system. It describes a communication using a message exchange and at the same time talks about other alternatives. It adds details about various models of a message exchange, various message types and about various specifications as well. Commercial tools ActiveMQ, RabbitMQ and Kafka are presented. Special emphasis is placed on describing the way these tools exchange messages, scalability options and others. The web service is designed according to the described features. Its main purpose is management and monitoring of the tool by user choice and easy replacement of this tool with another one. Designed application is implemented using the Kotlin language for selected tool RabbitMQ. The implemented solution allows a simple exchange of messages through the REST api.

The thesis focuses on developing prototype of e-commerce platform. This platform will be used as a base for a full-fledged e-commerce solution of specific trader in the future. The thesis deals with the analysis of the current state, analysis of available solutions, description of selected technologies, including a description of how these technologies were specifically implemented in the project. The result of this thesis is a functional prototype of e-commerce platform.

The purpose of this thesis was to find approaches solving major performance and scalability issues for Topic Maps-related data access and the merging process. Especially regarding the management of multiple, heterogeneous topic maps with different sizes and structures. Hence the scope of the research was mainly focused on the Maiana web application with its underlying MaJorToM and TMQL4J back-end.

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.

Att flera datorer används för att gemensamt lösa problem är inte någonting nytt. Det finns många distribuerade system i bruk och många olika lösningar för hur dessa ska kommunicera med varandra. Vissa använder sig av meddelande-orienterade lager för kommunikation vilket det finns väldigt många implementationer av. RabbitMQ är ett exempel där att kommunikation går genom en (eller ett kluster av) central nod och kommunicerar med hjälp av protokollet Advanced Message Queue Protocol, AMQP. I en helt annan kategori finns ZeroMQ som inte definierar någon central nod för all kommunikation att passera utan peer to peer är istället möjlig vilket innebär snabbare responstider men försvårar hur olika klienter hittar till varandra. Det bloggindexerande företaget Twingly kör idag med ett distribuerat system som använder flera olika kösystem för att koordinera ut arbete till de olika datorerna. De vill kolla närmare på hur de kan bygga sitt system med hjälp av meddelande-orienterade lager. Resultatet av arbetet är att RabbitMQ innebär mindre komponenter att hålla reda på vilket innebär att koden blir mindre komplex. Det som kommer gratis med att använda RabbitMQ är just att klienterna inte behöver känna till varandra utan endast behöver känna till RabbitMQ-servern. Nackdelen är att RabbitMQ-servern kommer bli en flaskhals för systemet. ZeroMQ är däremot friare att implementera den funktionalitet man själv behöver vilket är till fördel i de fall tid och pengar finns för att skapa ett eget system byggt ovanpå ZeroMQ. För Twingly som vill ha ett system inom en snar framtid är RabbitMQ ett bättre val av dessa två alternativ.

Genetic algorithms are modern algorithms intended to solve optimization problems. Inspiration originates in evolutionary principles in nature. Parallelization of genetic algorithms provides not only faster processing but also new and better solutions. Parallel genetic algorithms are also closer to real nature than their sequential counterparts. This paper describes the most used models of parallelization of genetic algorithms. Moreover, it provides the design and implementation in programming language Python. Finally, the implementation is verified in several test cases.

Människors levnadsstandarder förbättras ständigt tack vare nya innovativa system som möjliggörs genom att sensorer kopplas upp mot internet för att i realtid producera och analysera stora mängder viktiga data om den verkliga världens tillstånd. Luftkvalitet förvärras i världen och genom datainsamling och dataanalys kan realtidsvarningar erbjudas. Meddelandemäklare introduceras i systemarkitekturer för att samla in, lagra och strukturera datamängder på ett felsäkert sätt. Problemet är att meddelandemäklare måste kunna hantera många distribuerade luftkvalitetssensorer för att tillgodose behovet av exakt representation av luftkvalitet. Kafka och RabbitMQ sattes upp med hjälp av Docker för att under experiment undersöka vilken meddelandemäklare som tillhandahöll bäst prestanda när antalet sensorer ökade. En containeriserad webbapplikation utvecklades för att i ett gränssnitt kunna definiera exekverbara experiment. Containeriserade tjänster startades under exekvering upp. Genomsnittliga data aggregerades varje sekund till en mätpunkt för realtidspresentation i webbgränssnittet. Kafka tillhandahöll lägst latens och högst genomströmningshastighet när antalet sensorer ökade. / <p>Det finns övrigt digitalt material (t.ex. film-, bild- eller ljudfiler) eller modeller/artefakter tillhörande examensarbetet som ska skickas till arkivet.</p>

With the substantial growth of cloud computing over the past decade, microservices has gained significant popularity in the industry as a new architectural pattern. It promises a cloud-native architecture that breaks large applications into a collection of small, independent, and distributed packages. Since microservices-based applications are distributed, one of the key challenges when designing an application is the choice of mechanism by which services communicate with each other. There are several approaches for implementing Interprocess communication (IPC) in microservices, and each comes with different advantages and trade-offs. While theoretical and informal comparison exists between them, this thesis has taken an experimental approach to compare and contrast common forms of IPC communications. In this the- sis, IPC methods have been categorized into Synchronous and Asynchronous categories. The Synchronous type consists of REST API and Google gRPC, while the Asynchronous type is using a message broker known as RabbitMQ. Further, a collection of microservices for an e-commerce scenario has been designed and developed using all the three IPC methods. A load test has been executed against each model to obtain quantitative data related to Performance Efficiency, and Availability of every method. Developing the same set of functionalities using different IPC methods has offered a qualitative data related to Scalability, and Complexity of each IPC model. The evaluation of the experiment indicates that, although there is no universal IPC solution that can be applied in all cases, Asynchronous IPC patterns shall be the preferred option when designing the system. Nevertheless, the findings of this work also suggest there exist scenarios where Synchronous patterns can be more suitable. / Med den kraftiga tillväxten av molntjänster under det senaste decenniet har mikrotjänster fått en betydande popularitet i branschen som ett nytt arkitektoniskt mönster. Det erbjuder en moln-baserad arkitektur som delar stora applikationer i en samling små, oberoende och distribuerade paket. Eftersom microservicebaserade applikationer distribueras och körs på olika maskiner, är en av de viktigaste utmaningarna när man utformar en applikation valet av mekanism med vilken tjänster kommunicerar med varandra. Det finns flera metoder för att implementera Interprocess-kommunikation (IPC) i mikrotjänster och var och en har olika fördelar och nackdelar. Medan det finns teoretisk och in- formell jämförelse mellan dem, har denna avhandling tagit ett experimentellt synsätt för att jämföra och kontrastera vanliga former av IPC-kommunikation. I denna avhandling har IPC-metoder kategoriserats i synkrona och asynkrona kategorier. Den synkrona typen består av REST API och Google gRPC, medan asynkron typ använder en meddelandemäklare känd som RabbitMQ. Dessutom har en samling mikroservice för ett e-handelsscenario utformats och utvecklats med alla de tre olika IPC-metoderna. Ett lasttest har utförts mot var- je modell för att erhålla kvantitativa data relaterade till prestandaeffektivitet, och tillgänglighet för varje metod. Att utveckla samma uppsättning funktionaliteter med olika IPC-metoder har erbjudit en kvalitativ data relaterad till skalbarhet och komplexitet för varje IPC-modell. Utvärderingen av experimentet indikerar att även om det inte finns någon universell IPC-lösning som kan tillämpas i alla fall, ska asynkrona IPC-mönster vara det föredragna alternativet vid utformningen av systemet. Ändå tyder resultaten från detta arbete också på att det finns scenarier där synkrona mönster är mer lämpliga.