DISTRIBUTED SYSTEM

DISTRIBUTED SYSTEM NOTES, BCA, TU

Distributed System Architecture

Distributed system architecture refers to a system design where components located on different networked computers communicate and coordinate their actions by passing messages. The goal is to achieve a common objective and ensure that the system appears to its users as a single coherent system. Distributed systems can provide high availability, fault tolerance, scalability, and improved performance by leveraging multiple computing resources.

 

 

Component: A modular unit with well-defined interfaces ,is replaceable and reusable 

Connector: A communication link between modules which mediates coordination or cooperation among components.

So the idea behind distributed architectures is to: have these components presented on different platforms, where components can communicate with each other over a communication network in order to achieve specific objectives.
 

Architectural Styles 

 

Distributed system architectural styles define the structure and behavior of systems distributed across multiple networked computers. These styles provide different ways to design and organize the components of a distributed system, each with its own advantages and use cases. 

 

1. Layered Architecture

The layered architecture separates layers of components from each other, giving it a much more modular approach. A well known example for this is the OSI model that incorporates a layered architecture when interacting with each of the components. Each interaction is sequential where a layer will contact the adjacent layer and this process continues.

The layers on the bottom provide a service to the layers on the top. The request flows from top to bottom, whereas the response is sent from bottom to top. The advantage of using this approach is that, each layer can be easily replaced or modified without affecting the entire architecture.

 

 

Components are structured in a layered manner, with a component at layer LLL permitted to invoke components in the layer directly beneath it, Li−1L_{i-1}Li−1​. Control typically moves sequentially through the layers: requests travel downward through the hierarchy, while results are passed upward.This model has been widely adopted by the networking community.

2. Object Based Architecture

Object-based architecture in distributed systems is an approach that structures the system as a collection of interacting objects. Each object encapsulates both data and behavior, and objects interact through well-defined interfaces, typically using method calls. This architecture is heavily influenced by object-oriented programming principles and provides several advantages, including modularity, reusability, and encapsulation.

Components of Object-Based Architecture

• Client Objects: Initiate requests for services from other objects. They typically interact with user interfaces or higher-level application logic.
• Server Objects: Provide services and respond to requests from client objects. Server objects implement the business logic and manage data.
• Middleware: Facilitates communication between distributed objects. Middleware handles remote method invocation, object location, and data exchange.
  • Examples: CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), DCOM (Distributed Component Object Model).

Interaction in Object-Based Systems

• Remote Method Invocation (RMI): Allows an object to invoke methods on an object located on a different machine.
• Object Request Brokers (ORBs): Middleware that manages communication between objects in different locations, typically used in CORBA-based systems.
• Message Passing: Objects communicate by sending and receiving messages. This can be synchronous or asynchronous.

Examples

• CORBA: Provides a standard for distributed objects to communicate regardless of the programming language or platform.
• Java RMI: A Java API that allows objects to invoke methods on remote objects as if they were local.
• DCOM: A Microsoft technology for distributed objects, allowing COM objects to communicate across network boundaries.

3. Data Centric Architecture 

Data-centric architecture in distributed systems focuses on the organization and management of data as the central component around which the system's functionality revolves. This architecture prioritizes the accessibility, consistency, distribution, and manipulation of data across different nodes in the system. It is particularly suitable for applications where data plays a critical role, such as big data analytics, distributed databases, and real-time data processing systems.

 

 

Components of Data-Centric Architecture

• Data Storage Nodes: These nodes are responsible for storing and managing data. They can be part of distributed databases or file systems.
  • Examples: HDFS (Hadoop Distributed File System), Cassandra, Amazon S3.
• Data Access Layer: This layer provides APIs and interfaces for accessing and manipulating data. It abstracts the underlying data storage complexities.
  • Examples: SQL queries for relational databases, RESTful APIs for NoSQL databases.
• Data Processing Nodes: Nodes that perform computations and transformations on data. They often work in parallel to handle large-scale data processing tasks.
  • Examples: Apache Spark, Apache Flink.
• Data Distribution Middleware: Middleware that manages data distribution, replication, and consistency across different nodes.
  • Examples: Apache Kafka for data streaming, Zookeeper for coordination.
• Clients: End-users or applications that request and consume data. They interact with the data access layer to perform read/write operations.

Examples

• Distributed Databases: Systems like Google Bigtable, Amazon DynamoDB, and Apache Cassandra that store and manage large volumes of data across multiple nodes.
• Big Data Platforms: Hadoop and Spark, which provide frameworks for processing and analyzing large datasets distributed across many nodes.
• Data Warehouses: Systems like Amazon Redshift and Google BigQuery that support large-scale data storage and complex querying.

4. Event Based Architecture 

Event-based architectures in distributed systems are designed around the production, detection, consumption, and reaction to events. This type of architecture promotes loose coupling between components, enabling systems to be highly scalable, responsive, and adaptable to changes. It is particularly effective in scenarios requiring real-time processing and asynchronous communication.

 

 

Components of Event-Based Architectures

• Event Producers: These generate events based on certain conditions or changes in state.
  • Examples: User actions in a web application, IoT sensor readings, log entries.
• Event Consumers: These listen for specific events and act upon them.
  • Examples: Notification services, data processors, alert systems.
• Event Channels: These are used to transmit events from producers to consumers.
  • Examples: Message queues (RabbitMQ), event buses (NATS), streaming platforms (Apache Kafka).
• Event Brokers: Middleware responsible for managing the event flow, ensuring that events are delivered to the appropriate consumers.
  • Examples: Kafka brokers, RabbitMQ exchanges, AWS EventBridge.
• Event Storage: Systems to store events for auditing, replaying, or analyzing.
  • Examples: Event sourcing databases, log-based storage systems like Apache Kafka.

Examples

• Apache Kafka: A distributed streaming platform that allows for high-throughput, low-latency event handling.
• RabbitMQ: A message broker that supports various messaging protocols and patterns, including publish/subscribe.
• AWS Lambda: Serverless computing service that can be triggered by events from various AWS services.
• Google Cloud Pub/Sub: A messaging service that allows for scalable event delivery and processing.