As we went through how problems are addressed with Messaging and Message Brokers, we are now ready to dive into the software architectures that are parallel with these solutions. Message Brokers create an abstraction between modules, applications, and processes. The abstraction, which is created with Message Brokers, is simply defined as Message Oriented Middleware. As we know, Message Brokers has a functionality to apply asynchronous patterns on the affected modules, applications, and processes. Then, it comes to Event Driven Architecture that is strictly related with the asynchronous system. After defining these related software architectures, let's dive into this amazing stuff.
Message Oriented Middleware is simply defined as a component that allows software components, which have been placed on the same or different network, to communicate with one another. In a Producer/Consumer pattern, producers send their message to different consumers with the help of Message Oriented Middleware, guaranteeing the message received as shown in the next screenshot. If we look at the definition deeply, Message Oriented Middleware tries to solve some software engineering problems such as interoperability, monitoring, enterprise integration of software systems, abstraction, reliability, security, and so on.
Interoperability is defined as systems and devices that can exchange data without knowing each other's functionality. In an interoperable system, we have heterogeneous software components rather than homogeneous components. Message Oriented Middleware integrates all of the heterogeneous components and interacts with them in a scalable way. As we talked before, we are now using different technologies in our technology stack. With the help of Message Oriented Middleware, we are able to interact with these different types of technologies.
Application performance management is widely described as monitoring and management of performance and availability of software applications. Nowadays, we need to monitor performance metrics closely in most software systems. Message Oriented Middleware can ease up monitoring and tuning performance. So, both consumers and producers are partly relieved from problems like monitoring, logging, and tuning.
Today, we are using different software systems from different companies. Especially in financial area, we have to use customer relationship management software, enterprise resource planning software, human resource management software, and so on. Also, every director needs to combine these software systems in a single software architecture. This is done by enterprise integration of software systems. This integration has many software architectures, and Message Oriented Middleware is one of the architectures that satisfy the enterprise integration of software systems.
As a consequence, Message Oriented Middleware that is provided with the Message Brokers is responsible to solve some software engineering problems such as interoperability, enterprise integration of software systems, and so on. We are able to use Message Oriented Middleware in our software system whenever using the Message Brokers. You can see an overview of message oriented architecture in the following screenshot:
Message Oriented Middleware architecture
In an asynchronous system, operations take place independent of other operations; therefore, operations can take place without waiting for others. Since Message Broker's support asynchronous operations, they can be easily used in an Event Driven Architecture. Before defining Event Driven Architecture (EDA), let's talk about the problems before EDA.
As we discussed in the messaging concept, producers send message to the consumers. Before EDA, consumers always await their incoming messages from producers. Then, one of the processes had to control the waiting process. With EDA, we have listeners, whose duty is to trigger the listener event whenever a message is received. Now we are ready to define the EDA. EDA is a push-based communication between producer and consumer, which gives reaction to the events.
The structure of EDA consists of four elements: event creator or producer, event consumer, event manager, and event. The following is an explanation of these elements:
- Event creator is just the source of event
- Event consumer is a listener of event that needs to know the event has occurred
- Event manager is a middleware between creator and consumer, which is the controller of the events and triggers the related event consumers
- Event is an action that is detected by a Event listener or consumer.
These structures could be seen in an example in the preceding screenshot. Note that arrows between components are events.
EDA solves lots of software engineering problems, for example, scalability, high availability, and so on. So, it is good to list the benefits of the EDA:
- EDA has a capacity to support large numbers of creators and consumers
- It responses to information in near real time
- It prevents the blocking or waiting in the consumer phase
- It shapes the architecture as an extremely loosely-coupled architecture
Consequently, Message Brokers support asynchronous software system. Then, we are able to use Event Driven Architecture in our software system to gather great solutions to well-known problems such as scalability. You can see an overview of event driven architecture in the following screenshot:
Image 7: Event Driven Architecture