Event-Driven Architecture and SOA in collaboration - A study of how Event-Driven Architecture (EDA) interacts and functions within Service-Oriented Architecture (SOA)

Abstract

Over the years many different architecture styles and concepts have evolved. Two are Service Oriented architecture (SOA) and Event Driven Architecture (EDA). Both styles are revolutionary and have great benefits for the business if they are used in the right context for the right purpose. EDA is not a new paradigm nor is it new as an architecture style. It has been around for many years but has revived during the last years due to SOA and new technology available. Now days EDA is often mentioned when discussing SOA. The confusion these days is about how the two architecture styles interact. People have different views on this issue. Now, even as there is widespread concurrence that SOA brings in the possibility of EDA being used, there is a lot of debate on exactly how EDA will blend in with SOA. Ranging from EDA being the “new SOA”, to EDA “succeeding” SOA, to EDA “extending” SOA, to pure skepticism of any relationship at all! The purpose of this thesis is to study SOA and EDA and discuss how they interact and integrate in the same environment. The discussions and analysis presented will be at a conceptual level and I will not cover technical infrastructure issues if not necessary. This research is founded on theoretical study, personal experience, and interviews to find out the main characteristics, similarities and differences of both architecture concepts and how they are relating. During the study it became evident that there are several areas where EDA and SOA are interacting. People have different opinion on how EDA and SOA relate to each other but I’m of the clear opinion that EDA is extending SOA in several areas. The relation between the two concepts is obvious almost in all architecture layers and aspects, from business and information, to information system integration and technical infrastructure. It is however important to also point out that despite the identified relations between EDA and SOA they may be implemented separately. Based on our findings there are three main reasons for this collaboration. The first one is common and aligned business objectives, the second one is that both architecture concepts build upon decoupled and flexible components and common data model, and the third reason is use of common infrastructure and technology. Though the relation between EDA and SOA is clear the challenges when implementing EDA and SOA should not be underestimated. Involving business when implementing EDA and SOA is the key to success and perhaps the main challenge. Another major challenge is the governance of services and events. This is also a new field where the level of maturity may not be high enough and where real-life experience is rare.