What is message-oriented middleware?

Message-oriented middleware (MOM) provides rules-based messaging routing capabilities. In addition, MOM includes message broker technology. Messaging brokers enable request and reply constructs to be handled asynchronously, which supports the guaranteed delivery and integrity of messages between applications and components.

• First generation MOM: IBM MQSeries had emerged as the de facto standard in the messaging middleware market, owning over half of the market in first generation MOM. However, MQSeries is based on a first generation, asynchronous, broker-centric design.

We have now seen the next generation of message-oriented middleware, which extensively uses the publish and subscribe model for message and application brokering. The publish and subscribe paradigm's primary strength lies in allowing applications and components to communicate and exchange information without too many established connection dependencies.

• Transparency in publish and subscribe:
  The communicating component's physical location and identity (barring security implications) are transparent to one another. This is similar to a person "subscribing" to the New York Times. When the paper is "published" it appears at the subscriber's doorstep. The publisher of the New York Times does not need to know the identity of the subscriber. Likewise, the subscriber does not need to know where the New York Times publisher resides. Both parties have their service fulfilled without knowing the routing involved: The New York Times distributes and gets paid, and the subscriber receives and reads.
• Advantages of publish and subscribe:
  The publish and subscribe model offers flexibility not found in earlier generation message-oriented middleware which typically used a single static broker. In the publish and subscribe model, publishers (message stores) and subscribers (message users) may be deployed dynamically and in various numbers.
• Advantages include:
  1. Message Broker Technology: Acts as a message server being multiple systems/solutions requiring integration.
  2. De facto standards: Have NOT been approved by a standards organization. Instead these are widely used and recognized by an industry as being standard.

While message-oriented middleware (MOM) from the dotcom era hasn't been entirely replaced by microservices, the way applications are architected and communicate has significantly evolved, and microservices have become a prominent architecture. Let's explore the relationship between MOM and microservices to clarify this evolution:

1. Message-Oriented Middleware (MOM):
   • MOM refers to software that facilitates the communication between distributed applications by sending messages back and forth asynchronously.
   • Examples from the dotcom era include IBM MQSeries, TIBCO, ActiveMQ, and RabbitMQ.
   • MOM was often used in monolithic architectures or early distributed systems to enable loose coupling and asynchronous communication between different parts of the system, using message queues or brokers.
2. Microservices:
   • Microservices architecture breaks down an application into smaller, independently deployable services that focus on specific business functionalities.
   • Communication between microservices can be synchronous (HTTP/REST) or asynchronous (messaging/queues).
   • Asynchronous messaging between microservices often uses modern message brokers like Apache Kafka, AWS SQS, RabbitMQ, etc., which serve as evolved versions of message-oriented middleware but with features tailored to the needs of modern distributed systems.
3. Coexistence:
   • Microservices can still use message-oriented middleware for communication. MOM has evolved, and newer platforms like Kafka or modern implementations of RabbitMQ and others are widely used to support microservices architecture.
   • What has changed is the architectural paradigm. While MOM in the dotcom era supported communication within large monoliths or early distributed systems, today's microservices architecture relies on modern messaging systems for inter-service communication, event streaming^[1], event-driven architectures, and scalability.
4. Key Differences in Evolution:
   • Granularity: MOM was often used within large, monolithic applications, while microservices focus on fine-grained, independently scalable services.
   • Deployment and Flexibility: Microservices can be deployed independently, often in containers using orchestration tools like Kubernetes. MOM-based architectures from the dotcom era didn’t have such flexibility.
   • Communication Patterns: Modern microservices still use asynchronous messaging systems, but now they also include RESTful APIs, gRPC, and more advanced messaging protocols.

Conclusion Message-oriented middleware hasn’t been fully replaced; rather, it has evolved. In microservices architectures, modern messaging systems still play a key role, but with enhanced capabilities designed to support more distributed, scalable, and cloud-native applications.

Message-Oriented Middleware (MOM) can play a pivotal role in a Service-Oriented Architecture (SOA) by enabling effective communication between distributed services. Here's how MOM can be utilized within an SOA:

1. Facilitating Asynchronous Communication
   
   • Loose Coupling: MOM allows services to communicate without needing immediate responses. Services send messages to a queue, and receiving services process them when ready. This decouples the sender and receiver, enhancing flexibility.
   • Improved Scalability: Asynchronous messaging helps in handling varying loads by decoupling processing times, allowing services to scale independently.
2. Enhancing Reliability and Fault Tolerance
   • Guaranteed Delivery: MOM systems often support features like persistent messaging and acknowledgments, ensuring messages aren't lost even if a service is down.
   • Retry Mechanisms: They can automatically retry sending messages in case of failures, increasing the robustness of the system.
3. Integrating Heterogeneous Systems
   • Platform Agnostic Communication: MOM enables different services built on various technologies and platforms to communicate seamlessly through standardized messaging protocols.
   • Protocol Bridging: It can act as a mediator between services using different communication protocols, facilitating interoperability.
4. Implementing Enterprise Service Bus (ESB) Patterns
   • Centralized Messaging Backbone: MOM can serve as the backbone of an ESB within an SOA, handling message routing, transformation, and orchestration between services.
   • Service Mediation and Orchestration: It can manage complex interactions, coordinating multiple services to fulfill a business process.
5. Supporting Event-Driven Architectures
   • Publish/Subscribe Model: MOM allows services to publish events that other interested services can subscribe to, enabling real-time data distribution and reactive programming models.
   • Decoupled Event Handling: Publishers and subscribers do not need to know about each other, further enhancing modularity.
6. Enhancing Security and Transaction Management
   • Secure Messaging: MOM can enforce security policies, encrypt messages, and authenticate services to protect sensitive data during transmission.
   • Distributed Transactions: It can manage transactions that span multiple services, ensuring data consistency across the system.
7. Simplifying Service Integration
   • Message Transformation: MOM can transform message formats between services, allowing for easier integration without modifying existing services.
   • Routing and Filtering: It can direct messages to appropriate services based on content or predefined rules, streamlining communication flows.

Practical Implementation Steps

1. Select an Appropriate MOM Platform: Choose a middleware that fits your needs (e.g., Apache Kafka, RabbitMQ, IBM MQ).
2. Design Message Schemas: Define clear and consistent message structures using formats like JSON or XML.
3. Configure Queues and Topics: Set up queues for point-to-point communication and topics for publish/subscribe models.
4. Develop Service Interfaces: Implement services to send and receive messages through the MOM using its APIs or protocols.
5. Implement Error Handling: Design strategies for message retries, dead-letter queues, and exception management.
6. Monitor and Optimize: Use monitoring tools to track message throughput, latency, and system performance, making adjustments as needed.

Benefits of Using MOM in SOA

• Increased Reliability: Reduces the risk of message loss and handles service outages gracefully.
• Better Performance: Manages high volumes of messages efficiently, improving overall system throughput.
• Enhanced Flexibility: Allows services to evolve independently without affecting the entire system.
• Simplified Maintenance: Centralizes communication logic, making it easier to update and manage.

Considerations

• Complexity: Introducing MOM adds an additional layer that requires management and understanding.
• Latency: Asynchronous communication might introduce delays not suitable for real-time requirements.
• Cost: There may be licensing costs and resource overhead associated with running a MOM system.

Conclusion Integrating Message-Oriented Middleware within a Service-Oriented Architecture enables robust, scalable, and flexible communication between services. MOM acts as the glue that binds disparate services, supporting the core SOA principles of loose coupling, interoperability, and reusability. By leveraging MOM, organizations can build complex, distributed systems that are resilient and adaptable to changing business needs.

A new generation of message-oriented middleware products are pushing MQ Series, by offering more sophisticated publish and subscribe models, and integrating other types of Middleware. These products are discussed in the section on enterprise application integration (EAI).
MQSeries has responded to some degree, for now it also supports:

1. Workflow services
2. Messaging formatting services (e.g. converting file structures into messages)
3. Message repositories

Several other vendors offer MOM products including:

Figure 4-5 shows a time line of WebSphere MQ versions and some highlights of the features and products that have been made available.

WebSphere MQ V7.0, in 2008, was a major release with significantly enhanced application programming interfaces (APIs) and a fully integrated publish/subscribe component. These enhancements made that messaging pattern a first-class way of working. WebSphere MQ V7.0.1, in 2009, was primarily an update to improve availability and performance.
Even though there was nearly a 2 ½ year gap before V7.1 in 2011, there were still incremental improvements. The improvements were to both the core WebSphere MQ product and new products.
WebSphere MQ File Transfer Edition is a solution for the integration of applications that are file-based, making it possible to reliably transfer files between systems. WebSphere MQ File Transfer Edition provides management, monitoring, and security of those transfers. WebSphere MQ File Transfer Edition uses existing skills and infrastructure as it uses WebSphere MQ as its backbone transfer medium.
Advanced Message Security (AMS) is a solution to the problem of securing message contents, even when those messages are at rest in queues or logs. Several regulatory frameworks require data to be protected from viewing, changing, or being stored on disks in the clear even during processing. One example of these regulations is the Payment Card Industry (PCI) for dealing with credit card data. There are other regulatory bodies for other types of data, for example, healthcare, that have similar requirements.
Both WebSphere MQ File Transfer Edition and WebSphere MQ Advanced Message Security have been integrated into the WebSphere MQ V7.5 package. WebSphere MQ File Transfer Edition has been renamed to Managed File Transfer. There are two variations of V7.5 that are functionally identical but that have different licensing terms. The WebSphere MQ Advanced offering can be ordered under a single part number and price and it includes licenses to use the Managed File Transfer and AMS features. The original V7.5 offering has these features as separately orderable and priced components.

Publish and subscribe also allows for highly flexible, yet reliable, security schemas.
For more information on vendors and tools associated with message-oriented middleware, click on the Search button located at the top of the page. Verify your understanding of the concepts we have covered with a self-check quiz. This quiz will provide you with valuable practice prior to taking the end of course test.
Data Integration - Quiz

[1] Event streaming:Event streaming is a real-time data processing paradigm where a continuous stream of events, or discrete pieces of information, is captured, processed, and analyzed as they occur. This enables organizations to gain immediate insights from their data, make faster decisions, and respond to events in real-time.