Significant developments in microprocessor and sensor technology make wirelessly connected small computing devices widely available / hence they are being used frequently to collect data from the environment. In this study, we construct a framework in order to extract high level information in an environment containing such pervasive computing devices. In the framework, raw data originating from wireless sensors are collected using an event driven system and converted to simple events for transmission over a network to a central processing unit. We also utilize complex event processing approach incorporating temporal constraints, aggregation and sequencing of events in order to define complex events for extracting high level information from the collected simple events. We develop a prototype using easily accessible hardware and set it up in a classroom within our university. The results demonstrate the feasibility of our approach, ease of deployment and successful application of the complex event processing framework.

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.

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.

The way the structure of systems and programs are designed is very important. When working with smaller groups of systems, the chosen architecture does not affect the performance and efficiency greatly, but as these systems increase in size and complexity, the choice of architecture becomes a very important one. Problems that can arise when the complexity of software scales up are waiting for data accesses, long sequential executions and potential loss of data. There is no single, optimal software architecture, as there are countless different ways to design programs, but it is interesting to look at which architectures perform the best in terms of execution time when handling multiple bigger systems and large amounts of data. In this thesis, a case called "The Income Deduction" will be implemented in a monolithic and an event-driven architectural style and then be put through three different scenarios. The monolithic architecture was chosen due to its simplicity and popularity when constructing simpler programs and systems, while the event-driven architecture was chosen due to its theoretical benefits of removing sequential communicating between systems and thus reduce the time systems spend waiting for each other to respond. The main research question to answer is what the main benefits and drawbacks are when building larger systems with an event-driven architectural style. Additional research questions include how the architecture affects the organisation’s efficiency and cooperation between different teams, as well as how the security of data is handled. The two implementations where put through three different scenarios within the case, measuring execution time, number of HTTP requests sent, database accesses and events emitted. The results show that the event-driven architecture performed 9.4% slower in the first scenario and 0.5% slower in the second scenario. In the third scenario the event-driven architecture performed 49.0% faster than the monolithic implementation, finishing the scenario in less than half the amount of time. The monolithic implementation generally performed well in the simpler scenarios 1 and 2, where the systems had fewer integrations to each other. In these cases it is the preferred solution since it is easier to design and implement. The event-driven solution did perform much better in the more complex scenario 3, where a lot of systems and integrations were involved, since it could remove certain connections between systems. Lastly, this thesis also discusses the sustainability and ethics of the study, as well as the limitations of the research and potential future work. / Strukturen som system och program designas efter är väldigt viktigt. När en arbetar med mindre grupper av system så kommer den valda arkitekturen inte att påverka prestandan mycket. Men när dessa system växter i storlek och komplexitet så kommer valet av arkitektur vara väldigt viktigt. Problem som kan uppstå när mjukvarukomplexiteten ökar är väntandet på dataaccesser, långa sekventiella exekveringar och potentiell förlust av data. Det finns ingen optimal mjukvaruarkitektur, det finns oräkneligt många sätt att designa program. Det är intressant att kolla på vilka arkitekturer som preseterar bäst sätt till exekveringstid när en hanterar ett flertal större system och stora mängder data. I den här avhandlingen kommer ett fall, kallat "Ingångsavdraget", att implementeras i en monolitisk och en event-driven arkitekturell stil och sedan köras igenom tre olika scenarion. Den monolitiska arkitekturen var vald på grund av dess enkelhet och populäritet vid utveckling av enklar program och system. Den event-drivna arkitekturen valdes på grund av vissa teoretiska fördelar, så som att kunna undvika sekventiell kommunikation mellan systemen och därmed reducera tiden som systemen väntar på svar från varandra. Den huvudsakliga forskningsfrågan som ska besvaras är vad de största fördelarna och nackdelarna är när man bygger större system med en event-driven arkitekturell stil. Andra forskningsfrågor inkludera hur arkitekturen påverkar effektiviteten hos en organisation och samarbetet mellan olika team, samt hur datasäkerheten hanteras. De två implementationerna sattes igång tre olika scenarion inom fallet, där exekveringstid, antal HTTP-anrop skickade, databasaccesser och event skickad mättes. Resultaten visar att den event-drivna arkitekturen presterade 9.4% långsamare i det första scenariot och 0.5% långsamare i det andra scenariot. I det tredje scenariot presterade den event-drivna lösningen 49.0% snabbare än den monolitiska lösningen och avslutade därmed scenariot under hälften av tiden. Den monolitiska implementationen presterade generellt väl under de simplare scenarion 1 och 2, där systemen hade färre integrationer till varandra. I dessa fallen så är den den föredragna lösningen eftersom det är lättare att designa och implementera. Den event-drivna lösningen presterade mycket bättre i det mer komplexa scenario 3, där många system och integrationer var inblandade, eftersom den kunde ta bort vissa kopplingar mellan system. Slutligen så diskuteras även hållbarhet och etik i studien, samt begränsningarna av forskningen och potentiellt framtida arbete.

Microservices is one of the most commonly used buzzword of the systems architecture industry and is being adopted by several of the world’s largest technology companies such as Netflix, Uber and Amazon. The architecture which embraces splitting up your system in smaller independent units is an extension of the service-oriented architecture and an opponent of the monolithic architecture. Being a top buzzword and promises of extreme scalability has spiked the interest for microservices, but unlike the relatively simple monolithic architecture the complexity of microservices creates a new set of obstacles. This work sheds a light on these issues and implements solutions for some of the most frequent problems using a case study. The study shows that while microservices can help reduce the inner complexity of a system, it greatly increases the outer complexity and creates the need for a variety of tools aimed at distributed systems. It also concludes that communication and data storage are two of the most frequently occurring issues when developing microservices with the most difficult one being how you reason with and structure your data, especially for efficient queries across microservices. / Microservices eller så kallade mikrotjänster är ett ofta förekommande buzzword inom systemarkitektur och nyttjas av flera teknikjättar som exempelvis Netflix, Uber och Amazon. Arkitekturen som bygger på att dela upp sina system i mindre oberoende delar är en utbyggnad av den tjänstorienterade arkitekturen och numera motståndare till den klassiska monolitiska arkitekturen. En plats högt upp på trendlistan och lovord om extrem skalbarhet har gjort att intresset för mikrotjänster är enormt, men till skillnad från den relativt simpla monolitiska arkitekturen skapar komplexiteten hos mikrostjänster en rad nya hinder. Det här arbetet belyser dessa hinder och implementerar även lösningar för de vanligaste förekommande problemen med hjälp av en fallstudie. Resultatet visar att även fast en mikrotjänstarkitektur kan minska systemets interna komplexitet så leder det till en markant ökning av systemets yttre komplexitet och det skapas ytterligare behov av en mängd olika verktyg och tjänster designade för distribuerade system. Studien visar också att de två mest förekommande problemen vid utveckling av en mikrotjänstarkitektur är kommunikation och datalagring där hantering och struktur av data är den mest komplicerade och kräver mycket kunskap, speciellt för att skapa effektiva datasökningar som sträcker sig över flera mikrotjänster.

服務導向架構(Service-Oriented-Architecture, SOA)與事件導向架構(Event-driven Architecture, EDA)的結合應用將成為未來Real-Time Enterprise軟體應用系統架構的主流趨勢，雖然兩架構的結合可以整體提升應用系統之反應、整合與溝通的能力，但若無良好的事件管理機制及搭配提供服務的配套設計，則難以充分發揮兩架構結合的互補綜效。本研究所提出之調適式SOA有效事件模型，以事件價值觀點(Value-driven)分析事件所提供的價值對使用者的重要性與效益。由於使用者所重視的事件價值不同，因此也為各別使用者設計一調適性事件語意資訊模型(Customized Event Ontology Model)，作為篩選事件的依據，另外，事件管理機制也可運用智慧型代理人(Agent)觀察使用者採用事件的行為，透過學習更新事件過濾的規則，並可建議使用者取消訂閱(subscribe)不重視的事件。本研究同時搭配設計一事件與服務對應的機制，並透過此機制連結外部環境所提供的服務。本研究所提出之調適式SOA有效事件模型，預期可提供更為健全的服務導向架構(SOA)與事件導向架構(EDA)的結合應用設計，讓使用者可以真正受惠於此種應用軟體架構結合的好處與效用。 / The combination of Service-Oriented-Architecture (SOA) and Event-driven Architecture (EDA) will become the main trend of application architecture of Real-Time Enterprise in the future. Although the combination of these two architectures can enhance an application system’s capabilities in response, integration and communication as a whole, it’s hardly to extend these two architectures’ complemented advantages unless there is a sound mechanism for advanced event and service management. This paper presents a novel methodology which can analyze the importance and impacts of events’ values to users. Based on different emphases on events’ values among users, this research can also develop a Customized Event Ontology Model used as the basis for filtering events for an individual user. The event management mechanism designs an intelligent agent in order to observe the records of a user’s history events and to learn new filtering rules of events. The mechanism can also suggest the user to cancelling events which are insignificant to him. Furthermore, this study devises a mechanism to bridge the connections between events and services. The contribution of my methodology aims to provide an advanced solution of combining the architectures of SOA and EDA in order for a user to exert up-to-date information for personalized competitive advantage.

Les travaux présentés dans ce manuscrit s’appliquent au domaine de la gestion de crise française, et notamment à la phase de réponse qui suit un évènement majeur, comme une crue ou un accident industriel. Suite à l’évènement, des cellules de crise sont activées pour prévenir et traiter les conséquences de la crise. Elles font face, dans l’urgence, à de nombreuses difficultés. Les parties-prenantes sont nombreuses, autonomes et hétérogènes, la coexistence de plans d’urgence engendre des contradictions et des effets en cascade se nourrissent des interconnexions entre réseaux. Ces constats arrivent alors que les données disponibles sur les réseaux informatiques ne cessent de se multiplier. Elles sont, par exemple, émises par des capteurs de mesures, sur des réseaux sociaux, ou par des bénévoles. Ces données sont l’occasion de concevoir un système d’information capable de les collecter pour les interpréter en un ensemble d’information formalisé, utilisable en cellule de crise. Pour réussir, les défis liés aux 4Vs du Big data doivent être relevés en limitant le Volume, unifiant (la Variété) et améliorant la Véracité des données et des informations manipulées, tout en suivant la dynamique (Vélocité) de la crise en cours. Nos états de l’art sur les différentes parties de l’architecture recherchée nous ont permis de définir un tel système d’information. Ce dernier est aujourd’hui capable de (i) recevoir plusieurs types d’évènements émis de sources de données connues ou inconnues, (ii) d’utiliser des règles d’interprétations directement déduites de règles métiers réelles et (iii) de formaliser l’ensemble des informations utiles aux parties-prenantes. Son architecture fait partie des architectures orientées évènements, et coexiste avec l’architecture orientée services du logiciel développé par le laboratoire Centre de Génie Industriel (CGI). Le système d’information ainsi implémenté a pu être éprouvé sur un scénario de crue majeure en Loire Moyenne, élaboré par deux Services de Prévision des Crues (SPC) français. Le modèle décrivant la situation de crise courante, obtenu par le système d’information proposé, peut être utilisé pour (i) déduire un processus de réponse à la crise, (ii) détecter des imprévus ou (iii) mettre à jour une représentation de la situation en cellule de crise. / The present work is applied to the field of French crisis management, and specifically to the crisis response phase which follows a major event, like a flood or an industrial accident. In the aftermath of the event, crisis cells are activated to prevent and deal with the consequences of the crisis. They face, in a hurry, many difficulties. The stakeholders are numerous, autonomous and heterogeneous, the coexistence of contingency plans favours contradictions and the interconnections of networks promotes cascading effects. These observations arise as the volume of data available continues to grow. They come, for example, from sensors, social media or volunteers on the crisis theatre. It is an occasion to design an information system able to collect the available data to interpret them and obtain information suited to the crisis cells. To succeed, it will have to manage the 4Vs of Big Data: the Volume, the Variety and Veracity of data and information, while following the dynamic (velocity) of the current crisis. Our literature review on the different parts of this architecture enables us to define such an information system able to (i) receive different types of events emitted from data sources both known and unknown, (ii) to use interpretation rules directly deduced from official business rules and (iii) to structure the information that will be used by the stake-holders. Its architecture is event-driven and coexists with the service oriented architecture of the software developed by the CGI laboratory. The implemented system has been tested on the scenario of a 1/100 per year flood elaborated by two French forecasting centres. The model describing the current crisis situation, deduced by the proposed information system, can be used to (i) deduce a crisis response process, (ii) to detect unexpected situations, and (iii) to update a COP suited to the decision-makers.

No description available.