Middleware Architectures

Middleware

Middleware acts as the "plumbing or wiring" of software applications.

Purpose:
 Facilitates communication between software components.
 Provides infrastructure for data exchange.
Functions:
 Connects software components.
 Facilitates data exchange.
 Supports multiple connection types: one-to-one, one-to-many, many-to-many.
Key Traits:
 Invisible to end-users unless it fails.
 General and configurable for diverse applications.
Technology Classification
 Application Domains

Different application domains tend to regard different technologies as middleware.

1. Transport Layer: Simple data exchange mechanisms, pipes for sending requests

and data.

2. Application Servers: Multi-threaded server-based programming models, add

transaction, security, and directory services.

3. Message Brokers: Specialized for message transformation and routing.

4. Business Process Orchestrators:

 Manage workflows and intermediate states of applications

 Execute long-term processes involving human tasks.

 Why Middleware is Critical

Key Benefits:
 Ready-to-use infrastructure for connecting components.
 Scalable and configurable for various domains.

User Perception: Middleware is seamless and only noticed during

failures.

The excerpt outlines two key middleware technologies

1. Distributed Objects (exemplified by CORBA)

2. Message-Oriented Middleware (MOM):

Used in building robust, scalable, and flexible distributed systems.

Distributed Objects
 Distributed Objects

Distributed Objects are based on the Common Object Request Broker

Architecture (CORBA), distributed objects enable object-oriented systems to

communicate across networks

Architecture:

1. Object Request Broker (ORB): Facilitates communication between

clients and server objects, allowing remote procedure calls.

2. Interface Description Language (IDL): Defines the interfaces of

servant objects, specifying methods, parameters, and return types.

 Key Components of CORBA
1. ORB (Object Request Broker):
 Acts as the middleware to handle communication between client and
server objects.
 Abstracts network details, enabling location transparency.
2. Client:
 The application making requests to the server object.
 Interacts with the ORB using stubs.
3. Server (Servant):
 The object that provides services to clients.
 Implements the actual business logic.
4. IDL (Interface Definition Language):
 Defines the interface for objects in a platform- and language-independent
manner.
 Used to generate client stubs and server skeletons.
 Client-Servant Interaction:

1. The client initiates a request on a stub that appears to be a synchronous call

to a local object.

2. Behind the scenes, the Object Request Broker (ORB) handles marshaling

(serializing) the request and its parameters for transmission across a network

to the remote servant.

3. The ORB marshals the request and sends it over the network.

4. The server-side ORB demarshals the request and forwards it to the servant.

5. After the servant processes the request, the response is marshaled back to

the waiting client.

Message-Oriented Middleware
(MOM)
 Message-Oriented Middleware (MOM)

MOM provides asynchronous communication through message queues, enabling

loose coupling of distributed systems.
Advantages:
 Decouples senders and receivers.
 Inherently asynchronous, allowing independent operation of components.
Architecture
1. Message Queues:
i. Store messages sent by one or more senders.
ii. Deliver messages to receivers in a First-In-First-Out (FIFO) manner.
2. MOM Server:
i. Manages message queues.
ii. Handles message persistence, acknowledgments, and delivery.
1. Send Message:
A sender places a message in the queue.

2. Queue Storage:
The MOM server ensures message persistence, even if the receiver is unavailable.
3. Receive Message:
 Receivers receives messages, that are delivered in FIFO order, and once
acknowledged, they are removed from the queue.
 Send-and-Forget Messaging: No immediate reply needed; sender continues
without waiting for acknowledgment.
 Delayed Processing: Receiver processes the message at its own pace.
 Fault Tolerance: MOM stores messages for later delivery, ensuring reliability
during downtime .
 Features of MOM

Integrated Reliable
Decoupled Scalable
platform/languages communication
 Advanced Features

 Message-Oriented Middleware (MOM) enhances enterprise application

communication by offering advanced features that ensure reliability,
usability, and scalability.
 While basic MOM functionalities suffice for many systems, mission-critical
applications require stronger guarantees. Here’s an overview of the
advanced features MOM offers:

1. Message Delivery

2. Transactions

3. Clustering

4. Two-Way Messaging
 1. Message Delivery

MOM ensures messages are delivered reliably, even in failure scenarios. Delivery

quality-of-service (QoS) options balance reliability and performance are:

Best Effort Transactional

Persistent

i. Best Effort

 Messages are stored in memory only.

 Delivery may fail due to system crashes or network issues.

 Suitable for non-critical messages.

ii. Persistent

 Messages are logged to disk and memory.

 Guarantees delivery despite failures.

 Performance decreases by 30%-80% due to disk logging.

iii. Transactional

 Bundles messages into atomic units of delivery.

 Ensures "all-or-nothing" message delivery.

 Can be synchronized with external resources like

databases.

 Performance is slightly slower than persistent delivery,

dependent on transaction
 2. Transactions

Transactional messaging integrates tightly with application logic, ensuring

consistency between messages and other operations like database updates. Key
features:
i. Atomic Operations
 Batch messages into a single transaction.
 Receivers process messages in the same order as sent.
 Failed transactions roll back changes and re-queue messages.
ii. Integration with Databases
 Transactions coordinate message delivery and database updates.
 Example: Begin a transaction, update a record, send a message,
then commit.
 3. Clustering
MOM servers cluster for:
 High Availability
If one server fails, others continue processing messages.
 Load Balancing
Traffic is distributed across servers for scalability.
Transparent to clients, who interact as if using a single server.
 4. Two-Way Messaging

While MOM is inherently asynchronous, it supports synchronous

communication through request-reply messaging:

Request-Reply Workflow

 Sender places a request in the queue and waits for a reply.

 Receiver processes the request and sends a response.

Advantages

1. Integrates legacy systems with minimal changes.

2. Cost-effective compared to synchronous technologies like CORBA.

3. Widely compatible with various platforms.

 Benefits of MOM Advanced Features

 Enhanced Reliability
Ensures no loss of critical data, even during failures.
 Scalability
Efficiently handles increased loads via clustering.
 System Integration
Seamlessly integrates legacy and modern systems.
 Flexibility
Supports both asynchronous and synchronous communication.

These advanced features make MOM a robust choice for enterprise applications
requiring high performance, reliability, and adaptability.
 Message-Oriented
Feature Distributed Objects Middleware (MOM)

Synchronous (remote Asynchronous (message

Communication
method calls) queues)

Coupling Tightly coupled Loosely coupled

Slower due to network Optimized for intermittent

Performance
dependencies connections

Dependent on continuous Decouples failures with

Reliability
availability message persistence

Requires custom recovery Built-in queue-based

State Management
mechanisms persistence

Asynchronous, scalable
Primary Use Real-time interactions
systems
 Architectural Considerations

When deciding between distributed objects and MOM:

1. System Requirements:
 Use Distributed Objects for systems requiring real-time interaction and object-
oriented design.
 Use MOM for large-scale, loosely coupled systems with asynchronous workflows.
2. Failure Tolerance:
MOM offers better fault tolerance with message persistence, making it ideal for
systems with intermittent network reliability.
3. Scalability:
MOM scales better for multi-application integration and diverse platforms.

These technologies form the backbone of many modern enterprise systems, bridging
diverse applications and enabling robust distributed architectures.
Publish-Subscribe Architecture
 Publish-Subscribe Architecture

 Publish-Subscribe (Pub-Sub) messaging extends traditional

message-oriented middleware (MOM) systems, enabling one-to-
many, many-to-many, and many-to-one communication models.

 This architecture supports loose coupling by decoupling the

sender (publisher) and receivers (subscribers), offering dynamic
flexibility in enterprise systems.
 Key Components
 Publisher:
Sends messages to a named topic.
 Topic:
 Logical equivalent of a queue in traditional MOM, can be persistent or non-
persistent , with the same effects on reliable message delivery.
 Subscriber:
Registers to a topic and receives messages published to it.
 Messaging Layer:
Manages topics, tracks subscribers, and ensures message delivery.

Messages can also be published with an optional “time-to-live” setting to attempt

to deliver a message to all active subscribers for the time-to-live period, and after
that delete the message from the queue.
 Core Features
 Dynamic Subscription: Subscribers can register or unregister at any time without
affecting the system.
 Multi-Publisher Support: Multiple publishers can publish to the same topic.
 Time-to-Live: Messages can have a delivery timeframe, ensuring timely
dissemination.
 Persistence: Topics can store messages for later delivery or handle transient
messaging.

Benefits

 Scalability: Supports large numbers of subscribers.

 Flexibility: New topics and subscriptions can be added dynamically.
 Loose Coupling: Publishers and subscribers remain unaware of each other,
promoting modular system design.
 Topic Hierarchies and Wildcards
Topics are represented hierarchically using strings with "/" separators. For example:

 Sydney/DevGroup/Information/work

 Sydney/SupportGroup/Information/gossip

 Wildcards enhance flexibility:

 *: Matches one level (e.g., Sydney/*/Information).

 **: Matches multiple levels (e.g., Sydney/DevGroup/**).

Wildcards allow dynamic subscription to evolving topics without requiring updates to

subscription logic.
 Performance: Multicast vs. Point-to-Point

Publish-subscribe systems often use either point-to-point TCP/IP or

multicast protocols:

 Point-to-Point: Creates individual connections for each subscriber,

increasing latency as the number of subscribers grows.
 Multicast: Sends a single message over the network, which is then
delivered to multiple subscribers via daemons (e.g., TIBCO’s rvd).

Example: Benchmark results highlight that multicast performs better

with increasing subscribers, as shown in the comparative study of
technologies.
 Limitations

 Reliance on Middleware:
Requires a robust messaging layer to manage topics and ensure reliable
delivery.
 Network Dependencies:
Scalability depends on the underlying protocol; multicast isn't universally
supported across networks.
 Message Loss:
Without persistence, non-delivered messages may be lost if subscribers are
inactive.
 Real-World Applications

 Event-Driven Systems: Event notification platforms.

 Market Data Feeds: Financial market data distribution.

 Collaborative Tools: Chat or collaboration platforms for distributed teams.

Publish-Subscribe architectures empower systems requiring dynamic and

flexible communication models, fostering a balance between scalability and

modularity in enterprise applications.

Essential Software Architecture, Ian
Gorton, Springer – Verlag, 2011.

Ch # 4