With the rise of multiple cloud platforms and various Software-as-a-Service (SaaS) products, there has been a paradigm shift in the integration of architecture patterns. Concepts and patterns that might have been relevant a few years back do not make much impact now because of changes in the infrastructure and software market. This has been seen in the digital transformation paths of many enterprises. Organizations are taking advantage of machine learning, big data platforms, and serverless features (such as Azure Functions and Azure Logic Apps), and are moving to more granular microservice-based models of application design. Such application designs allow organizations to have real-time customer interactions and offer a better service model where further innovation is concerned.
As organizations move closer to the cloud with next-generation solutions in mind, integration is becoming more critical than ever. With current market trends, organizations are not dealing with serving a single customer base or working with a single set of software. Rather, most organizations have a global footprint and own a multitude of software and services to serve customers worldwide. As organizations' business dimensions grow& in different areas, such as marketing, service catalogs, and customer bases, we have seen a fast-paced shift toward better integrated solutions. These integrated solutions generally connect multiple applications over various protocols, such as HTTP, SFTP, AMQP, file-based transfers, and more.
Organizations are trying to take advantage of the data available to them and learn from existing systems by implementing hybrid communication models. In hybrid solutions, the structure of software and resources is scattered between on-premises environments and the cloud. With heavy investment on internal infrastructure already having been made in the past, most organizations are searching for ways to take advantage of the cloud while still keeping their own services on-premises, sitting behind a firewall.
In this section, we will discuss events and event utilization, along some definitions of basic concepts that we will deal with throughout this chapter. To get started, let's first define events and eventing in terms of software development.
We can define an event as a lightweight state change notification that is broadcast from the event source to participating event listeners through a subscription in an asynchronous pattern. On the other hand, eventing is defined as the process of notifying appropriate listeners about any specific events that have taken place within the event source system.
On Wikipedia, an event is defined as follows:
Let's get an understanding of the concept of event-based patterns with an e-commerce example. In e-commerce, when a customer places a new order through an e-commerce website, the website will send an order creation event to the warehouse and finance department for the basic inventory status and payment status checks. If both the inventory and payment status checks are successful, then a clearance event is fired to the shipment department, which will then send the order to the respective customer.
In cases where an ordered product does not exist in the warehouse or the payment status check has failed, the appropriate events will be sent from the warehouse and financial department to the respective system handling the order failure request. As you can see, all of this communication follows asynchronous patterns with real-time communications and connecting systems. With event-driven processes, an enterprise can limit the manual intervention required to process orders.
The following diagram describes a basic order-processing flow in an event-based architecture pattern. This diagram can be extended with other systems that might be interested in consuming or publishing events from one or more parties involved in overall communication:
An event-based architecture has great benefits that can make it a next-generation solution utilizing the full power of cloud-hosted services. Another example of an eventing process could be found on a social media platform, when someone follows us on Twitter or when we get a friend request over Facebook or LinkedIn, for instance. All these interactions happen asynchronously, in real time, and through events raised by a specific entity involved.
As we have covered events and eventing, let's now discuss the basics of messages and messaging patterns.
Like events, messages are also micro components of a messaging platform. Usually, messages are pieces of conceptual data sent through the specified channel to a recipient in an asynchronous fashion. An example of this could be a postal order sent through the post office, or an email sent from an account to someone. Messaging can be defined as the overall process of sending data from the source to the desired recipient in an asynchronous way, while maintaining the contextual information of the communication.
So, what differentiates events from messages? The differentiating point here is the state. In event-based programming, events are tightly coupled to the object or entity state change without maintaining any other contextual information. When events are emitted, they only contain information about the state of an entity or object, such as when a blob is modified or when a message is published to a Service Bus.
On the other hand, messaging maintains contextual information while communicating with the end system or user. A great example of this would be an email thread between you and your friend, in which communication information and context are stored in the mail server and your inboxes.
If you have worked with integration before, you can easily correlate this with a pattern called the correlation properties pattern, in which context properties are used for message aggregation and routing. With message-based communication, pattern applications can transmit data along with its contextual information in an asynchronous manner without any human interaction.
To explain this definition with a visual representation, think of a use case in which an enterprise application creates jobs in the Microsoft Dynamics 365 customer relationship management (CRM) system, and part of the data needs to be replicated in Dynamics AX for financial invoicing. Here, there are multiple stages that need to be covered before the job can be invoiced to the customer.
Maintaining all these state changes—including creating an initial sales order number with job details, prepping the sales order line, assigning appropriate staff, performing servicing activities, and more—can be cumbersome with an event-based architecture. These are often long-running processes that can run over days. Communication channels, though, should be able to correlate all these actions and activities in a single transaction, like so:
As we have completed our discussion of event and messaging patterns, we will move on to look at the various characteristics of events and event-based design patterns.