Book Image

Architectural Patterns

By : Anupama Murali, Harihara Subramanian J, Pethuru Raj Chelliah
Book Image

Architectural Patterns

By: Anupama Murali, Harihara Subramanian J, Pethuru Raj Chelliah

Overview of this book

Enterprise Architecture (EA) is typically an aggregate of the business, application, data, and infrastructure architectures of any forward-looking enterprise. Due to constant changes and rising complexities in the business and technology landscapes, producing sophisticated architectures is on the rise. Architectural patterns are gaining a lot of attention these days. The book is divided in three modules. You'll learn about the patterns associated with object-oriented, component-based, client-server, and cloud architectures. The second module covers Enterprise Application Integration (EAI) patterns and how they are architected using various tools and patterns. You will come across patterns for Service-Oriented Architecture (SOA), Event-Driven Architecture (EDA), Resource-Oriented Architecture (ROA), big data analytics architecture, and Microservices Architecture (MSA). The final module talks about advanced topics such as Docker containers, high performance, and reliable application architectures. The key takeaways include understanding what architectures are, why they're used, and how and where architecture, design, and integration patterns are being leveraged to build better and bigger systems.
Table of Contents (13 chapters)

The EDA fundamental principles

In an asynchronous push-based messaging pattern, the EDA model builds on the pub/sub model to push a variety of real-time notifications and alerts out to the subscribed listeners in a fire-and-forget fashion. This neither blocks nor waits for a synchronous response. Also, this is a unidirectional and asynchronous pattern.

  • Autonomous messages: Events are communicated in the form of autonomous/self-defined messages. That is, each message contains just enough details to represent a unit of work and this provides the decision-enablement capability for notification receivers. Event messages should not require any additional context. Also, they should not require any kind of dependencies on the in-memory session state of the connected applications. The event message is simply intended to communicate the business state transitions of each application, domain, or workgroup within an enterprise.
  • Decoupled and distributed systems: As mentioned, the EDA pattern logically decouples connected systems. SOA guarantees loose and light coupling. That is, participating applications need not be available online all the time to accomplish the business tasks. The middleware (ESB) does take care in unobtrusively delivering the messages to the target application. The issue here is that the sender system has to know the relevant details of the target application towards service invocation to process completion.
    In the synchronous SOA case, connected and dependent systems are often required to meet the various non-functional requirements/quality of service (QoS) attributes, such as scalability, availability, performance, and so on. But in the case of asynchronous EDA, the transaction load of one system does not need to influence or depend on the service levels of downstream systems. This decoupling-enabled autonomy allows application architects to be a bit carefree in designing their respective physical architectures and capacity planning. Decoupled systems can be deployed independently and are horizontally scalable, as there are no dependencies among the participating modules.
  • Receiver-driven flow control: The EDA pattern shifts much of the responsibility of control-flow away from the event source (or sender system) and distributes/delegates it to event receivers. The EDA-centric connected systems have more autonomy in deciding whether to propagate the events further or not. The knowledge used to support these decisions is distributed into discrete steps or stages throughout the architecture and is encapsulated where the ownerships reside. The following diagram is the grandiose mix of both the SOA and EDA patterns: