Spelling suggestions: "subject:"händelsedriven arkitektur"" "subject:"händelsedriven ganarkitektur""
1 |
Implementering av händelsedrivenarkitektur och händelsekällor för hälsodata / Implementation of event driven architecture and event sourcing for health dataKarlström, Kasper, Dewitsegid, Samsom January 2024 (has links)
Dagens hälso- och sjukvårdssystem är byggda som en traditionell monolit men det finns fler sätt att utveckla dessa system på. Händelsedriven arkitektur med händel-sekällor för lagring av data är ett modernt sätt att utveckla system. Syftet med det här arbetet är att undersöka om den modernare arkitekturen skulle kunna vara lämpligt och säkert alternativ för hälso- och sjukvårdssystem. För att undersöka detta gjordes en litteraturstudie inom relevanta områden som händelsedriven arki-tektur, händelsekällor, mikrotjänster och monolitiska system. Resultatet ifrån litteraturstudien gav att det finns andra beprövade koncept från andra problemområden, så som säker kommunikation och säker lagring med spår-barhet, som om de användes med händelsedriven arkitektur skulle uppnå kraven för hälsosektorn. Forskningsfrågan kan besvaras positivt baserat på den genomförda lit-teraturstudien. Därtill utvecklades en enkel prototyp, som utan att innehålla säker-hetsaspekter, gör det lätt att observera för och nackdelar med händelsedrivna lös-ningar jämfört med exempelvis traditionella monolitiska lösningar. / Today's healthcare systems are built as a traditional monolith, but there are more ways to develop these systems. Event driven architecture with event sourcing for sto-ring data is a modern way of developing systems. The purpose of this work is to in-vestigate whether the more modern architecture could be a suitable and safe alter-native for healthcare systems. To investigate this, a literature study was conducted in relevant areas such as event driven architecture, event sources, microservices and monolithic systems. The result of the literature study showed that there are other proven concepts from other problem areas, such as secure communication and secure storage with tracea-bility, which if used with event driven architecture would meet the requirements of the health sector. The research question can be answered positively based on the completed literature study. In addition, a simple prototype was developed, which, without containing security aspects, makes it easy to observe the pros and cons of event driven solutions compared to, for example, traditional monolithic solutions.
|
2 |
Comparison between CRUD and CQRS in an event driven system / Jämförelse mellan CRUD och CQRS i ett event drivet systemJansson, Rasmus January 2024 (has links)
In todays digitalised society, effective solutions to manage huge amount of data is needed. An established design pattern that are used in many systems are CRUD. To handle data in events have become more popular over the years, but CRUD is not optimised for it. A possible replacement is CQRS, it is designed with events in mind. The purpose of the report is to see if CQRS can replace CRUD. The report shows that when it comes to an event driven system using event sourcing, CQRS is recommended. Reason being CQRS is more compatible with events then CRUD. CRUD is more designed around data driven design and therefor is a better fit for other systems. / I dagens digitaliserade samhälle krävs effektiva lösningar för att behandla stora mängder data. Ett etablerat designmönster som används i många system är CRUD. Att hantera data i händelser är något som har blivit alltmer populärt, men CRUD är inte optimerad kring just det. En möjlig ersättare är CQRS, som är designad med event i åtanke. Målet med denna rapport är att se om CQRS kan ersätta CRUD i ett händelsebaserat system. Rapporten visar att när det kommer till ett händelsedrivet system som använder händelsekällor, så är rekommendationen att använda CQRS. Detta för att CQRS är mer kompatibel med händelser än CRUD. CRUD är mer designat runt data driven design och funkar därför bättre med andra typer av system.
|
3 |
Performance of message brokers in event-driven architecture: Amazon SNS/SQS vs Apache Kafka / Prestanda av meddelandeköer i händelsedriven arkitektur: Amazon SNS/SQS vs Apache KafkaEdeland, Johan, Zivkovic, Ivan January 2023 (has links)
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.
|
Page generated in 0.0569 seconds