SEDA and its use for EAI
Google changed their main search page from Static to Dynamic with Instant. One of the challenges as pointed out in their official blog was increase in 5-7X hit to their servers due to this enhancement. Naturally the Infrastructure team had a huge challenge to deal with this without affecting the existing performance. But they solved the problem with changes as pointed out in the blog. Performance as we know is an obvious expectation from any solution from a Non functional requirement (NFR) perspective but still in most of the solution implementations it is not given the same impetus that the functional side usually gets. Most of the projects in initiation stage wouldn’t have planned for addressing the non functional requirements as compared to addressing the functional requirements. Down the lane during the software development it is often experienced that performance is not as expected and then time and effort is spent on tuning the solution to meet the NFR through cycles of load testing-fixing-testing. Though Performance Engineering is a vast topic, the interest in this post is towards an architecture pattern called SEDA (Staged Event Driven Architecture).
Briefly about SEDA, it was envisioned way back in 2000-01 as a pattern to address the performance problem associated with high concurrent processing such as web servers overloaded with requests (note the connection to Google or any search service provider problem). The creators of SEDA based their hypothesis with the knowledge that most of the software applications as well as the Operating system execute the incoming requests concurrently as concurrent threads but not as concurrent events. SEDA’s principle is to add a layer for processing by considering Events as separate Stages. Basically, distribute applications (or modules) as separate stages and process them under separate queues. This way if we take the example of web server, it can combine aspects of threads and event-driven programming which in theory should provide better performance benefit. The original theory and explanation is explained in the white papers in the above referred site. Carrying forward the theory to middleware, consider the following example of a standard interface implementation in an EAI implementation. An EAI implementation will have multiple such interfaces using a VETRO (Validation, Enrichment, Transformation, Routing and Operate) pattern.
In Figure 1, the implementation showcases traditional EAI concepts about when an event is generated, it will be traverse through multiple steps in an interface as the message gets enriched and transformed from original system to destination system. But the same event when generated in realtime through multiple sources will be handled by the underlying engine concurrently. If there are 50 threads, then 50 concurrent messages are processed concurrently.
In Figure 2, the implementation showcases how each stage in the interface is configured to listen to a queue independently. This way each of the stages would be configured to have its own set of threads at runtime. With this pattern, one of the advantages is reusability.
Any stage can be independently configured and can serve multiple event types and not necessarily one type. Second development itself can be broken up. Third this can easily be adapted to SOA etc, etc. Performance should increase as possibly different stages could run in parallel depending on whether it needs to wait for data from previous stage. On the flip side, disadvantage is in maintaining additional components. Second, number of failure points increases. Third, transaction management becomes complicated etc, etc.
It can be observed thus that not only thread concurrency but event concurrency can also be employed with this pattern. Not all EAI vendors in their suite or their SDK packages have support for this pattern. Some examples which support SEDA are open source ESBs such as Mule ESB and Apache ServiceMix ESB.
