Vill man bygga en API tjänst idag existerar det en mängd olika ramverk att välja mellan, varav några av dessa använder reaktiva system. Denna teknik tillåter värden att använda sina resurser på ett mycket mer effektivt sätt än med de icke reaktiva ramverken. Två ramverk som kan användas för att utnyttja denna teknik är Spring Boot och Quarkus. Spring Boot är ett väl etablerat API ramverk med mycket inbyggd funktionalitet som hjälper utvecklare att bygga robusta API tjänster. Quarkus å andra sidan är ett nyare ramverk med fokus på att vara en liten och lätt API som är främst för containers. Även fast dom fokuserar på olika saker borde dom i slutet presentera på samma nivå och ge snarlika resultat. Målet med denna studie är att jämföra reaktiva API tjänster med icke-reaktiva API tjänster med hjälp av Spring Boot och Quarkus. Samt svara på frågor om vilket ramverk och teknik som är den bästa för olika scenarion. För att få kunskap om ämnet om reaktiva system gjordes det först en teoretisk studie för att veta vad som definierar ett reaktivt system samt vad som krävs av operativsystemet för att exekvera en sådan tjänst. För att kunna utföra jämförelsen byggdes det en reaktiv samt icke-reaktiv variant av de två olika ramverken som ger totalt fyra applikationer att jämföra. Flera olika tester var byggda och exekverade på de fyra olika applikationerna. Resultaten visade att reaktivt Quarkus var överlägsen jämfört med de andra applikationer när storleken på transaktionerna var små. I de fall att transaktionerna var stora eller behövdes behandlas var istället Spring Boot bättre. Jämförelsen av CPU- och minnesanvändning resulterade i att reaktivt Quarkus använder både mindre minne och använder mindre CPU. / As technology evolves, more and more companies strive to automate as much work as possible. The use of chatbots in messaging apps is becoming more and more common as replacements in the operation of customer service because of the efficiency and reliability it poses. Replacing customer service with chatbots also saves companies money. In this paper an IT company have asked for the implementation and proof of concept of integration between their server-side application, to Microsoft Teams. They want it to be possible to use a chatbot in Teams to send tickets containing data to their system in order to be handled by users of their application. In this paper a solution to this problem is described as well as discussions about the chosen implementation. The discussion is focused on the final solution, user tests, related work, ethical issues as well as future work. User tests of the implemented solution are included in the results. The conclusion of the work is that this implementation is useful and saves time and effort both for the customer and the employees. There is much potential for future work to be expanded upon, including specialized Ticket Forms and implemented AI.

GlobalEye is an aircraft by Saab that provides surveillance of air, sea, and land. In order to train on the system present in this aircraft a Mission Training System, MTS, is used. The MTS consists of the Command and Control, C2, system that is present in the aircraft as well as a scenario simulator. This master thesis is focused on evaluating the performance of the distributed real-time system that is the MTS in terms CPU and memory usage of its Java processes. These Java processes are divided across four servers and two types of workstations.  Two sorts of tests were conducted; workload model testing and user scenario testing. Both tests were conducted multiple times with different amount of workload. The workload was defined as a number of air and sea targets added to the scenario simulator. The data was collected by running bash scripts on each machine that saved the CPU and memory output from the Linux top command. Java VisualVM was used to examine a selection of processes further. In Java VisualVM the heap size, garbage collector pauses, and CPU time of the methods were the main focus of interest. The result from the workload model testing showed that a large majority of the processes handled an increased workload in terms of memory usage well. When it comes to the CPU usage four processes with significantly increasing CPU values were examined further in Java VisualVM. These processes were MMI processes and processes involved in data transfer. No problems were noted regarding the garbage collection and heap sizes. The longest pause, across all processes, caused by garbage collection was 29.7ms. The methods with highest amount of CPU self time were also identified for the processes. One observation was that a method related to map rendering, for the MMI processes, showed decreases in CPU time as the workload increased. The result from the user scenario testing showed that the MMI of the scenario simulator suffers delays dependant on the number of targets present in the scenario. The Java process of the MMI did increase its CPU usage significantly as the targets increased. In Java VisualVM it was observed that the garbage collector for the scenario simulator MMI process was more extensive during these tests, with the longest pause being 104ms. Lastly when it comes to the CPU self time of the methods within the MMI process, one error related method was identified.