Building Event Driven Systems
6 likes1,776 views
The document discusses building event-driven systems and the evolution from synchronous request-response architecture to event-driven architecture (EDA), emphasizing the significance of events in enterprise systems. It outlines key components, principles, and patterns of EDA, including the event mediator and broker patterns, which are essential for orchestrating processes and distributing message flow. Additionally, the document links EDA to trends like the Internet of Things and microservices architecture, highlighting the need for reactive design to enhance system scalability and adaptability.
Building Event Driven Systems
- 1. Building Event Driven Systems Shiroshica Kulatilake Solutions Architect
- 2. Setting Expectations o Today’s Enterprise Systems and how events fit in o What is Event Driven Architecture o Patterns for building Event Driven Systems o Summarize
- 3. Enterprise Systems & Events
- 4. Enterprises Today o Distributed - Functionality is broken down into several sub systems - Located in multiple places o Ubiquitous - Based on parties interacting through different means o Connected - Built based on synergies - Own as well as partner systems need to interact with each other efficiently
- 5. Events in Enterprise Systems o Occurrence within the context of interest o A series of events depicting one event in the real world - e.g. A customer placing an order in a retail system o Not all events are of interest o Most everyday events can be dealt in an asynchronous manner o Occurrence of an situation (relevant event) requires something to react to it - to move from one state to another o For this events should be detected, situations filtered and processes notified o Leads to Event Driven Architecture
- 7. Evolution o SOA - Synchronous request response systems with asynchronous message delivery - Technically loosely coupled - Functionally tightly coupled - Mostly centralized o Evolving into EDA - Based on message driven model for information propagation - Spatial and temporal decoupling - Analogous to the operational model of an organisation where a series of events take place o Suited where - Distributed environments - Higher level of autonomy is needed at unit level
- 8. Main Components o Event - significant happening which results in change of state from a business perspective o Event generator- publishes events o Event processor- consumes events and decide what to do o Event channel - medium where event lies before consumption
- 9. Principles o Immediate information dissemination and reactive business process execution o Fire and forget - push based mechanism o Single responsibility at practice o Autonomous messages for the receiver to process o Higher decoupling - no need to bind to contracts o Logical decoupling of functional units - not dependent and less impact from change o Receiver driven flow control - more responsibility lies with receivers o Near real time information consistency
- 10. Advantages o Effective data integration o Low latency of information o High reactiveness o More accurate responses o High flexibility o Higher business agility
- 13. Event Mediator Pattern o Need to orchestrate multiple steps o Orchestration happens through a central mediator o Multiple steps need to happen in a certain order o Processing will be done by separate entities which need to be invoked in many ways o Fits scenarios which are complex, have some sort of orchestration logic and approval tasks etc as well
- 15. Broker Pattern o Message flow is distributed across several processors with no orchestration o Fits for use cases where the flow is entirely dependent on event receiving with no timing o Once a processor is done with processing another event will be fired to the broker which will be consumed by another processor
- 16. Components in an Event Driven System o Process Engine o Mediation Engine o Message Broker o Business Activity Monitor o Complex Event Processor o Business Rules Manager
- 17. Patterns in building Event Driven Systems
- 18. Centralized Message Driven System
- 19. Sample Solution
- 21. Autonomous Message Driven System
- 22. Sample Solution
- 25. Guaranteed Delivery - Directly via Broker
- 26. Guaranteed Delivery - via Mediation Engine
- 27. Guaranteed Delivery - Fault Handling
- 29. Keeping up with the trends
- 30. Internet of Things (IoT)
- 31. Internet of Things (IoT) o There exists a plethora of devices which provide data in several contexts o This data needs to be captured in order to analyze and derive intelligence and then take actions o Point to point integration with each device is not a possibility o Leads to the use of Event Driven Architecture through the use of protocols which work on publish-subscribe mechanisms - e.g. MQTT and also through handling large scale event analyzing
- 32. Internet of Things (IoT)
- 34. Microservices Architecture o Microservices promote distributed data management o Data in microservices - Are private to a specific microservice - Use polygot persistence - Might not expose generic APIs for all possible modes of use o However, business transactions span multiple microservices which would need accessing private data of other microservices o Leads to the use of Event Driven Architecture where distributed data management is handled through the use of events o Variants are event tables, transaction log mining and event sourcing which try to reduce errors relating to atomicity
- 37. Reactive Architecture o To achieve being reactive, systems should be designed with containment of functionality in mind so that scaling, isolation of failures and adaptable fault tolerance happens o Microservices Architecture can achieve this o Also, for a system to be reactive it should be able to - React to Load through scalability - React to failure through recoverability - React to user experience effectively o The ability to react to events and act accordingly becomes the main ingredient o Leads to designing and building systems in an Event Driven manner
- 38. Key take aways ...
- 39. Building Event Driven Systems o What does your enterprise system look like ? - Determine how complex or simple your system flows are - Determine how autonomous your processing units are - Determine how isolated your processing units should be o What do you need to do with event processing ? - Identify both functional as well as operational needs o Which pattern would suit you best ? - Select based on enterprise system characteristics and needs o Which components do you need ? - Identity which middleware components you need to achieve the above
- 40. References o Event Processing in Action - Opher Etzion and Peter Niblett - Manning o https://msdn.microsoft.com/en-us/library/dd129913.aspx o Software Architecture Patterns - Mark Richards - Orielly o http://radar.oreilly.com/2015/02/variations-in-event-driven- architecture.html o http://wso2.com/whitepapers/a-reference-architecture-for-the- internet-of-things/ o https://www.nginx.com/blog/event-driven-data-management- microservices/
- 41. CONTACT US !