For people who are in the IT industry for years, the comparison of SOA to EDA and vice versa is not news. For the new generation, their fundamental difference may be not that obvious, especially, when the architecture implementation relates to Microservices.
The basis of SOA is a client-server/service model. Yes, it is the old one that appeared 25 years ago. Nothing has changed at the conceptual level as nothing has changed in Business, which still makes its money by servicing consumers. That is, SOA is a technological model of proactive Business conducted by people.
An EDA basis concept is more about reactive Business, which operates as in prehistoric time with natural food production – you grow the harvest. Yes, you have to react to the changes in the weather to know how to manage your work, i.e. you are watching certain events around your field, but nothing more than that, especially regrating activities of your neighbours (I know, many will disagree with me in this, I am talking about basics here). Let’s agree on a concept of “working entity”, e.g. an SW that performs certain processing and generates a value for anyone, not only for itself. We can say that EAD is a collection of self-sufficient, independent working entities that announce their own work events and several logical rules that enforce certain working entities to “listen” to the notification about the events produces by some other working entities.
The operational mechanism in SOA is a request from a consumer to the service. No requests, no service execution. This is how Microservices have been defined and designed initially. However, there is nothing that prevents a Microservice to subscribe and listen to an event. Oops! Service Orientation stops here because there is nobody to serve. We have a clear question: If a Microservice listens to an event and does not provide an interface, which a consumer may use to communicate, is it still a Microservice or it is an Eventholder?
For example, we can define an Eventholder as a working entity that realises certain business functionality (primitive or even more complex) upon catching certain event notifications. Execution of the Eventholder changes the overall state of the ecosystem (comprised collections of working entities and related rule-sets). The real-world example is a set of sensor devices used in IoT; if nobody’s listening to event notifications produced by them, nobody knows about their existence, i.e. they work (or do not work) for nothing.
Finally, we approach a question that many enthusiastic people prefer to avoid – where we better use Microservices (designed to follow SOA) and where we better use Eventholder (designed to follow events) for solving business tasks? Certainly, some people prefer to use Microservices everywhere as well as some other people promote Eventholders in the same way, but this is not the answer to our question. The answer depends on the business needs.
If you want to orchestrate certain activities for reaching a certain outcome, I’d recommend using Microservices via an asynchronous communication bus. In this case, the orchestrator can always be aware of the responsiveness of the actors and replace some of them on the fly if they do not respond. If you need to collect information from independent autonomous information sources or actors, Eventholder will be sufficient. If an Eventholder is down, this should not impact your solution. Otherwise, you are risking the fatal failure as it happened with the emergency programme in New Orleans, USA, during hurricane Katrina when several “listeners” did not get notifications because businesses were destroyed by the hurricane and could not fire their evacuation events to trigger the chain of “listeners”. Even if EDA looks easier in development, it can appear more costly and difficult in the run-time management.
August 28, 2021
HOW to ARCHITECT for DEVELOPERS 