- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
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:
Advantages of this approach:
Disadvantages:
To solve the problem of flexibility, two approaches are proposed.:
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:
How interceptors help:
Advantages:
Problems:
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:
Adapting middleware through interceptors
Interceptors allow middleware to be adapted to the changing operating conditions of distributed systems, such as:
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:
Middleware Issues
Instead of rebuilding on the fly, you can:
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."
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.
To solve the problem of flexibility, two approaches are proposed.:
- Specialized versions of middleware for different classes of applications.
- Configurable systems, where mechanisms (basic functionality) and policies (configurable rules of behavior) are separated. This allows you to adapt middleware without rewriting the code.
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:
- Object A calls the method B.do_something(value), where B is located on a remote machine.
- The call is converted into a universal query invoke(B, &do_something, value).
- 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.
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.
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:
- Separation of concerns
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).
Computational reflection
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).
Component-based design
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.
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).
- 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.
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.
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."