2.3 ARCHITECTURES VERSUS MIDDLEWARE

The role of Middleware in distributed systems

Architectural Styles and Middleware (Middleware)

Chapter 2.3 "Architectures vs Middleware"

The Middleware Role

Middleware is an intermediate layer between applications and distributed platforms. Its key task is to ensure transparency of distribution, hiding from applications the complexities associated with data distribution, processing and management.

The connection of Middleware with architectural styles

In practice, middleware often implements a specific architectural style:

• Object-oriented style: for example, CORBA (Common Object Request Broker Architecture), where interaction is built through remote objects.
• Event-oriented style: as in TIB/Rendezvous, where components exchange asynchronous event messages.

Advantages of this approach:

• Simplify application design through standardized templates.

Disadvantages:

• Limited flexibility. For example, CORBA initially supported only remote method calls (RPC), which later required the addition of other patterns (such as messaging), complicating the system.
• The risk of "bloating" middleware due to the addition of new features.

Adapting Middleware to the needs of applications

To solve the problem of flexibility, two approaches are proposed.:

1. Specialized versions of middleware for different classes of applications.
2. Configurable systems, where mechanisms (basic functionality) and policies (configurable rules of behavior) are separated. This allows you to adapt middleware without rewriting the code.

Interceptors Technology

One of the ways to configure middleware is to use interceptors — software modules that "wedge" into the standard execution flow to add specific logic.

An example from object-oriented systems:

1. Object A calls the method B.do_something(value), where B is located on a remote machine.
2. The call is converted into a universal query invoke(B, &do_something, value).
3. The request is sent via the OS network interface.

How interceptors help:

• At the query level: If object B is replicated, the interceptor can automatically forward the call to all replicas without requiring changes to either the A code or the underlying middleware.
• At the message level: if the value parameter is a large amount of data, the interceptor can split it into parts to improve transmission reliability, unnoticed by the main system.

Advantages:

• Transparency for the application.
• Minimal changes to middleware.

Problems:

• The complexity of implementing universal interceptors (as shown in Schmidt et al., 2000).
• The balance between flexibility and ease of management.

Conclusion

Middleware, based on architectural styles, simplifies development, but requires adaptation mechanisms (for example, interceptors). Modern systems tend to separate policies and mechanisms in order to maintain flexibility without complicating the code.

---

Graphical representation

(You can add a scheme for interceptors in remote method invocation.)

Example of interceptor operation:

[Object A] → [Calling B.do_something()] → [Request Interceptor] →  
[Invoke for replicas B] → [Message Interceptor] → [Network]  

Key terms:

• Interceptor — interceptor.
• Distribution Transparency — transparency of distribution.
• Policy-Mechanism Separation — separation of policies and mechanisms.

2.3.2 General approaches to adaptive software

Adapting middleware through interceptors

Interceptors allow middleware to be adapted to the changing operating conditions of distributed systems, such as:

• Mobility (changing the location of nodes).
• Instability of QoS (network connection quality).
• Equipment failures.
• Low battery (in mobile devices).

Instead of making applications responsible for responding to changes, middleware takes over this task.

Three approaches to creating adaptive software

McKinley et al. (2004) identify three main methods:

1. Separation of concerns

2. The traditional approach: separating the main functionality from the "additional" aspects (security, reliability, performance).

   • Problem: Many aspects (such as security) cannot be isolated into a separate module.
   • Aspect-oriented programming (AOP) It is trying to solve this problem, but it is not yet scaling to large distributed systems (Filman et al., 2005).

3. Computational reflection

4. The ability of the program to analyze and change its behavior during execution (Kon et al., 2002).

   • It is supported in languages (for example, Java) and some middleware systems.
   • However, reflexive middleware has not yet proven effective in large distributed systems (Blair et al., 2004).

5. Component-based design

6. Adaptation through the composition of components (static or dynamic).

   • Dynamic component replacement requires complex dependency management (Yellin, 2003).
   • Problem: Components often turn out to be more connected than they seem.

---

2.3.3 Discussion

Middleware Issues

• Complexity and cumbersomeness due to attempts to ensure transparency of distribution.
• The conflict between universality (transparency) and specialization (for specific applications).
• Example: the code size of some middleware solutions increases by 50% in 4 years, and the number of files increases by 3 times (Zhang & Jacobsen, 2004).

Do I need adaptability?

• Arguments for:
• Distributed systems cannot be stopped for updates.
  • Dynamic replacement of components is required.
• Arguments against:
• Many changes (attacks, equipment failures) can be predicted in advance.
  • The complexity of adaptive solutions may outweigh their advantages.

Alternative approach

Instead of rebuilding on the fly, you can:

• Provide adaptation policies in advance (for example, reallocation of resources).
• Automate the response to changes without human intervention.

---

Conclusion

Middleware adaptability is an important but challenging task. Modern approaches (AOP, reflection, components) are not perfect yet. Perhaps the best way is predictable adaptation policies instead of "realignment on the move."