2016/05/29
 
29 May, 2016 | 3 min read

How You Can Increase Agility and Expandability with Event Driven Architecture (EDA)

  • Samudra Weerasinghe
  • Senior Lead Marketing Officer - WSO2

From ordering your favorite kind of pizza or a taxi to manufacturing and financial processes, everything is event driven today. People expect to do everything immediately, get instant feedback on the status of their request, and interact in real-time with anybody involved in the process.

John Mathon, the former vice president of enterprise evangelism at WSO2, wrote a white paper which explores how you can keep pace with these demands by implementing event driven architecture (EDA) in your enterprise.

EDA is essentially a messaging system that notifies interested parties of events that occur in order for them to benefit from it. The publish/subscribe model was implemented in the earliest real-time event-driven systems. Anonymity, discoverability and guaranteed delivery were a few of the characteristics that made it popular.

But this simple model deemed insufficient for the demanding and varied needs of subscribers, notes Mathon. Here came the rise of the enterprise service bus (ESB), which standardized enterprise integration patterns, the business process server (BPS) which allowed messages to trigger business processes that dealt with events and business activity monitor, now named data analytics server (DAS), to monitor the health of enterprises through statistics.

These tools became standard components in an EDA and are useful even today, which is why IoT is reusing pub/subs all over again.

The easiest, fastest and most efficient way of implementing EDA in your enterprise is to incorporate already existing event-driven technologies. You may think writing dedicated software would be more cost efficient and cater more to your specific needs, but in the long run the cost of maintenance would be over a dozen times more than the initial cost of development.

Existing tools are designed to increase performance and reliability of your system. It’s also easy for non-programmers to use because of features such as drag-and-drop components. They can handle large loads and are robust, secure and resilient to failure.

You can choose a specific tool for a specific problem. For example, long-running processes use BPS and short-running ones use message broker (MB). Also, when the tools are combined together it can provide additional power by working together to achieve one goal.

The problem with combining tools is that they can each be large monolithic entities that require significant communication bandwidth and can cause increased load on servers. WSO2 solves this problem because all the tools you require are built as light-weight components with the same base framework making it possible to combine them in the same Java runtime.

When implementing an EDA you need to keep in mind the message flow rates and the characteristic of the message flows. Make sure not to create extremely large messages or do a lot of computation during processing. You also need to consider whether you will be designing for microservices; your architecture design depends on this. API management is another key factor that you need to keep in mind. And lastly, you need to know which tool to use for which job.

WSO2 offers a full suite of open source components for EDA to implement highly scalable and reliable enterprise grade solutions. This includes a complete middleware stack, which includes the WSO2 integration, analytics, security and API management platforms.

For more details download John’s whitepaper here.

Undefined