DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CLOUD COMPUTING
UNIT – II

1. Cloud Enabling Technologies

2. Ubiquitous Internet
3. Parallel and Distributed Computing
4. Elements of Parallel Computing
a) What is parallel processing?
b) Hardware architectures for parallel processing
c) Approaches to parallel programming
d) Levels of parallelism
e) Laws of caution
5. Elements of Distributed Computing
a) General concepts and definitions
b) Components of a distributed system
c) Architectural styles for distributed computing
d) Models for Interprocess Communication
6. Technologies for Distributed Computing
a) Remote procedure call
b) Distributed object frameworks
c) Service-oriented computing

DEPT OF CSE Page 1

 Cloud Enabling Technologies

Amazon Web Services (AWS): This is a comprehensive, broadly adopted, and leading cloud
platform offered by Amazon. It provides a vast array of services, including computing power (e.g.,
EC2 for virtual machines), storage (e.g., S3 for object storage), databases, analytics, machine
learning, networking, mobile, developer tools, and more. AWS is a prime example of a public cloud
offering Infrastructure as a Service (IaaS) and many other service models.

Google App Engine: This is a Platform as a Service (PaaS) offered by Google Cloud. It allows
developers to build and host web applications on Google's scalable infrastructure without managing
the underlying servers. It supports various programming languages and automatically scales
applications based on demand.

Microsoft Azure: This is Microsoft's cloud computing platform, similar to AWS and Google Cloud.
Azure offers a wide range of services, including IaaS (virtual machines, networking), PaaS (app
services, databases), and Software as a Service (SaaS) offerings. It caters to a broad spectrum of
computing needs, from simple web hosting to complex enterprise solutions.

Hadoop: This is an open-source framework for distributed storage and processing of large datasets
across clusters of computers. It's not a cloud service provider itself, but rather a foundational
technology for big data analytics. Key components include HDFS (Hadoop Distributed File
System) for storage and MapReduce for processing. Many cloud providers offer managed Hadoop
services.

[Link] and [Link]: These are closely related.

• [Link]: Is primarily known as a leading provider of Software as a Service (SaaS),
especially for Customer Relationship Management (CRM). It offers various cloud-based
applications for sales, service, marketing, and more.
• [Link]: Is the underlying Platform as a Service (PaaS) that [Link] applications
are built upon. It allows developers to build custom applications that integrate with
Salesforce CRM and leverage its robust infrastructure, database, and user interface
components. Essentially, [Link] is the product, and [Link] is the platform on
which products can be built.

Manjrasoft Aneka: This is a PaaS (Platform as a Service) software framework that allows
developers to build and deploy distributed applications on private or hybrid clouds. It focuses on
providing a flexible environment for parallel and distributed programming, supporting various
programming models (like Bag of Tasks, MapReduce). Aneka aims to simplify the development and
deployment of applications that can leverage the power of cloud computing environments.

Ubiquitous Internet
 “Ubiquitous Internet” means that internet connectivity is available anytime, anywhere, and
on any device.
• Ubiquitous = present everywhere
• So, users, devices, and applications can seamlessly connect to services without
location constraints.
• Ubiquitous Internet = The backbone that connects users and devices to the cloud
anytime, anywhere.
 Without ubiquitous Internet, cloud computing loses its core value proposition of on-demand,
location-independent, device-agnostic services.
Page 2
Example Use Case
A company uses a SaaS CRM (like Salesforce).
 Sales teams in different countries can log in anytime.
 Managers can get real-time dashboards on their phones.
 Data syncs seamlessly because of ubiquitous connectivity.
 The Ubiquitous Internet is a fundamental enabler of cloud computing because it:
Connects users to cloud services:
 Users can access data, apps, and infrastructure hosted in the cloud from anywhere.
 Example: Accessing Google Drive, Office 365, or AWS from a laptop, tablet, or
phone.
Facilitates on-demand resources:
 Cloud computing relies on delivering resources (compute, storage, applications) over
the Internet.
 The always-available Internet makes this possible for globally distributed users.
Supports multi-device access:
 One user can switch between devices (laptop → tablet → smartphone) and still
access the same cloud services.
Enables edge and IoT integration:
 Smart devices and IoT sensors use ubiquitous connectivity to send data to the cloud
for processing and analytics.
Benefits of Ubiquitous Internet in Cloud Computing:
 Accessibility: 24/7 availability of services and data.
 Scalability: Cloud providers can serve millions of users globally.
 Flexibility: Work and collaborate from any location.
 Cost-effectiveness: Organizations don’t need on-premises infrastructure for remote
workers.
 Innovation: Enables new apps like smart cities, connected vehicles, and real-time
collaboration tools.

Parallel vs. distributed computing

Page 3
Two Fundamental Computing Eras
• Sequential Era (1940s onwards)
• Dominated by single-processor (sequential) computing.
• Executing instructions one at a time in a specific order.
• A single processor handles one task at a time
• Drawbacks: performance limitations and lack of scalability
o lower processing speeds for complex tasks, a bottleneck when dealing
with parallelizable operations, and vulnerability to system failure due
to a single point of failure.
• Parallel Era (1950s onwards)
• Emerged to overcome limitations of sequential processing.
o Enhancing speed, efficiency, and scalability for complex tasks
o By dividing workloads across multiple processors, parallel computing
can significantly reduce processing time, handle larger datasets, and
improve overall system performance.
• Includes parallel and distributed computing.
• Using multiple processors/cores/nodes to solve larger, more complex
problems.

Four elements evolved across both eras:

• Architectures — Hardware evolution (CPUs, multi-core, distributed nodes).
• Compilers — Software to translate high-level code into machine instructions
efficiently for target architectures.
• Applications — Real-world programs that solve problems using the underlying
architectures and compilers.
• Problem-Solving Environments (PSEs) — High-level frameworks/tools that make it
easier for engineers/scientists to use computing power (e.g., MATLAB, simulation
platforms, cloud-based environments).

Parallel Computing:
Computation is divided into tasks that execute simultaneously on multiple processors sharing the
same memory.
Key features:
Tightly coupled: Processors communicate via shared memory.
Homogeneous processors: Same type and capability.
Single address space: All processors access the same memory.
Classic example:
A multi-core CPU running a parallel algorithm, or a supercomputer with shared memory nodes.
Modern example:
Clusters with distributed shared memory via high-speed interconnects (e.g., InfiniBand).
Goal: Achieve high performance through concurrency within a single, often physically unified
system.

Distributed Computing:
Computation is divided into tasks executed concurrently on different computing elements — which
may or may not share memory, and are often in different physical locations.

Page 4
Key features:
Loosely or tightly coupled: Can range from clusters to globally distributed systems.
Heterogeneous: Nodes can differ in hardware/software.
Communication: Nodes communicate via messages over a network.
Classic examples:
o Computing grids (e.g., SETI@home)
o Internet-based distributed systems
o Cloud computing (public cloud data centers are large distributed systems).
Goal: Aggregate distributed resources to solve large problems collaboratively.

Aspect Parallel Computing Distributed Computing

Coupling Tightly coupled Often loosely coupled
Memory Shared memory May have no shared memory

Homogeneity Homogeneous processors Often heterogeneous nodes

Location Usually one physical system Often geographically dispersed

Communication Via shared memory Via network messages
Multi-core processors, Cloud services, grids, Internet
Examples
supercomputers computing

Elements of parallel computing

 What is parallel processing?
 Hardware architectures for parallel processing
 Single-instruction, single-data (SISD) systems
 Single-instruction, multiple-data (SIMD) systems
 Multiple-instruction, single-data (MISD) systems
 Multiple-instruction, multiple-data (MIMD) systems
 Approaches to parallel programming
 Data parallelism
 Process parallelism
 Farmer-and-worker model
 Levels of parallelism
 Large grain (or task level)
 Medium grain (or control level)
 Fine grain (data level)
 Very fine grain (multiple-instruction issue)
 Laws of caution

 Parallel computing helps overcome the speed limits of single processors by horizontally
scaling — using many processors in parallel to achieve higher performance for complex
problems.

Page 5
  Connect multiple processors that work in coordination to solve “Grand Challenge” problems
(complex problems needing massive computing power).
 Instead of doing everything sequentially, tasks are broken into parts that run simultaneously
(parallelism).
 Parallel computing is the field that covers:
 Techniques — How to split and manage tasks in parallel.
 Architectures — The hardware setups (multi-core processors, multiprocessor
systems) that make it possible.
 Systems — The tools and environments that support parallel execution and
coordination.

What is Parallel Processing?

 Parallel processing means performing multiple tasks simultaneously on multiple processors.

• It works by dividing a big problem into smaller subtasks (divide-and-conquer).
• Each subtask is processed on a different CPU at the same time.
• Programming a multiprocessor system this way is called parallel programming.
 Why use Parallel Processing?
• Many modern applications (scientific, business, big data, AI) need more computing
power than a single CPU can deliver.
 Parallel processing provides a cost-effective solution by:
• Adding more CPUs instead of relying on one faster CPU.
• Using an efficient communication system to share the workload.
• Achieving higher computing power and better performance than sequential systems.
 Parallel processing is the simultaneous execution of multiple tasks on multiple processors,
which boosts computing power, overcomes the speed limits of single CPUs, and meets the
demands of modern, compute-intensive applications.

Key Factors Driving Parallel Processing:

Increasing computational demand:
 Used in life sciences, aerospace, GIS, mechanical design & analysis, etc.
Limits of sequential architectures:
 CPUs can’t keep getting faster because of physical laws (speed of light, heat limits).
 So, instead of vertical growth (faster CPU), use horizontal growth (more CPUs).
Limits of other hardware improvements:
 Techniques like pipelining, superscalar design, or vector processing help only for certain
tasks and can’t scale infinitely.
 Vector processing works well for math-heavy tasks but not for general computing.
Maturity and commercial readiness:
 Parallel processing technology is well-developed with robust tools and environments.
Networking advances:
 High-speed networking enables combining different systems for heterogeneous computing,
further boosting performance.

Page 6
Hardware architectures for parallel processing:
The core elements of parallel processing are CPUs. Based on the number of instruction and data
streams that can be processed simultaneously, computing systems are classified into the following
four categories:
• Single-instruction, single-data (SISD) systems
• Single-instruction, multiple-data (SIMD) systems
• Multiple-instruction, single-data (MISD) systems
• Multiple-instruction, multiple-data (MIMD) systems
Note:
 The instruction stream is the sequence of instructions fetched from memory and executed.
 The data stream is the flow of data (operands, results) between the CPU and memory.
 The CPU fetches instructions from the instruction stream, and those instructions operate on
the data within the data stream.

1. SISD systems:

Instruction Stream:
 One set of instructions flows to the processor.
Data Input:
 One stream of input data feeds the processor.
Processor:
 The single processor executes one instruction at a time on the data.
Data Output:
 Results are output sequentially.

 The SISD model is the simplest computer architecture — a single processor working on one
task at a time, processing a single data stream sequentially.
This is why classic computers are often called sequential computers.
 SISD stands for Single-Instruction, Single-Data:
 A single processor executes one instruction at a time on one data stream.
 This is the classical sequential computing model.

Page 7
Key features:
Sequential execution: Instructions are processed one after another, no parallelism.
Memory: All instructions and data must be stored in primary memory.
Performance limit: Speed depends on how fast the system can transfer information internally
(CPU speed, memory bandwidth, bus speed).
Common examples: Traditional PCs (e.g., IBM PC), Macintoshes, and standard workstations.

2. SIMD Systems:

 SIMD systems use multiple processors to execute the same instruction on different data
elements at the same time, making them perfect for data-parallel tasks like vector/matrix
operations.
 SIMD stands for Single-Instruction, Multiple-Data:
 It’s a multiprocessor system where the same instruction is executed simultaneously
on multiple data streams.
 The same control unit broadcasts one instruction to all processing elements, but each
works on its own piece of data.
 Examples of SIMD systems
 Cray vector processors — famous for high-speed scientific computing.
 Thinking Machines’ CM (Connection Machine) — early massively parallel
supercomputer.
 Modern example:
 GPUs (Graphics Processing Units) also follow the SIMD idea — thousands of cores
execute the same instructions on different pixels or data.

Page 8
How does it work?
 A single instruction is broadcast to all processors (Processing Elements(PEs)).
 The input data is divided into multiple chunks — each processor handles a different chunk
in parallel.
 Example: Cᵢ = Aᵢ × Bᵢ
Vectors A and B are split across processors; each PE computes its own Cᵢ.

Where is SIMD useful?

Scientific computing:
 Ideal for tasks involving vector and matrix operations.
 Common in physics simulations, image processing, and AI (e.g., GPUs).
Why?
 Same operation needs to be applied repeatedly to large sets of data.
 SIMD does this efficiently by parallelizing at the data level.

3. MISD Systems:

 MISD means different instructions operating on the same data in parallel — but it’s not
practical for most real-world applications, so it’s mostly studied as a theoretical model.
 MISD stands for Multiple-Instruction, Single-Data:
 It’s a multiprocessor system where multiple processors each execute different
instructions on the same data stream.
 So:
 Multiple instruction streams
 Single shared data input

Page 9
  One single data input stream feeds all processors.
 Each processor has its own unique instruction stream, performing different operations on the
same data.
 The results are combined into a single data output stream.
 Example:
Input data x
Processor 1: sin(x)
Processor 2: cos(x)
Processor 3: tan(x)
Final output: y = sin(x) + cos(x) + tan(x)
 MISD architectures are more of an intellectual concept than a practical one.
 They have very limited practical use.
 A few experimental systems have been built, but none are commercially available.

4. MIMD Systems:

 MIMD systems execute multiple instructions on multiple data sets, with independent
processors working asynchronously — making them the most powerful and flexible
architecture for modern parallel and distributed computing.
 MIMD stands for Multiple-Instruction, Multiple-Data:
 It’s a multiprocessor system where each processor executes its own instruction
stream on its own data set.
 All processors operate independently and asynchronously.
How does it work?
 Multiple Instruction Streams:
 Each processor fetches and executes its own unique instructions.
 Multiple Data Streams:

Page 10
  Each processor works on its own separate chunk of data.
 Independent Processing Elements (PEs):
 No global lock-step coordination; each PE works at its own pace.

Why is MIMD so flexible?

General-purpose:
 Well suited for all kinds of applications, from scientific to business, because each processor
can do a different task on different data.
Asynchronous:
 Processing Elements do not need to wait for each other; they can run different programs
simultaneously.
Most modern systems:
 Most modern multiprocessor systems, clusters, cloud computing nodes, and networked
computers are MIMD systems.

Types of MIMD Architectures:

1. Shared Memory MIMD
 All Processing Elements share a single global memory.
 Communication happens by reading/writing shared memory.
 Also called tightly coupled multiprocessor systems.
 Example: SMP (Symmetric Multi-Processing) systems like Silicon Graphics,
Sun/IBM servers.
2. Distributed Memory MIMD
 Each Processing Element has its own local memory.
 Processors communicate via high-speed networks and message passing.
 Used in clusters, supercomputers, and cloud data centers.

Aspect Shared Memory MIMD Distributed Memory MIMD

Memory One global memory shared by Each PE has its own local memory
all PEs
Coupling Tightly coupled Loosely coupled
Communication Through shared memory Through message passing (IPC)
Failure Tolerance Less fault tolerant; one failure More fault tolerant; failures can be
can impact the whole system isolated
Scalability Limited by memory contention Highly scalable; no shared-
memory bottlenecks
Programming Easier to program More complex to program (need
to handle message passing)

Approaches to parallel programming:

Parallel Program:
• A sequential program runs on a single processor with a single flow of control.
• A parallel program divides the work into smaller, independent chunks that can run
simultaneously on multiple processors.

Page 11
Why Parallel Programming?
• To make efficient use of multiple processing elements (PEs).
• To reduce execution time and handle large computational tasks.
Major Approaches to Parallel Programming
1. Data Parallelism
• Same operation is performed simultaneously on different chunks of data.
• Uses divide-and-conquer; splits data into sets that run on different PEs.
• Suitable for: SIMD (Single Instruction, Multiple Data) architectures.
• Example: Image processing, where each pixel or block is processed in parallel.
2. Process Parallelism
• Different operations (or tasks) run at the same time on different processors.
• Multiple distinct activities are executed in parallel.
• Suitable for MIMD (Multiple Instruction, Multiple Data) architectures.
• Example: A web server handling multiple client requests simultaneously.
3. Farmer-and-Worker Model (Master-Slave)
• A central master processor (farmer) distributes tasks to multiple worker processors
(slaves).
• Master assigns jobs → Workers process them → Workers return results to master.
• Suitable for Task distribution when work units are independent.
• Example: Rendering frames in animation or solving independent parts of a
simulation.

Levels of parallelism:

Page 12
Laws of caution:
 When designing parallel systems, it’s easy to assume that adding more processors will
always linearly increase speed or performance — but real-world results show otherwise due
to factors like communication overhead, synchronization delays, and non-parallelizable
parts of the task.

 The speed of computation is roughly proportional to the square root of the system cost —
not linear!
 Doubling the cost does not double the speed.
 Faster systems become increasingly expensive for smaller performance gains.
 speed (GHz) increases gradually as you spend more money, but the rate of improvement
slows down.

 The speedup gained from parallelism increases roughly logarithmically with the number of
processors.
 Formula: Speed=k⋅log(N)
 Where N = number of processors
 Adding processors yields diminishing returns.
 Beyond a point, more processors give very small speed increases due to communication and
coordination overhead.
 Speed curve flattens out as the number of processors grows.

Page 13
 Elements of Distributed Computing

a) General concepts and definitions

b) Components of a distributed system
c) Architectural styles for distributed computing
d) Models for Interprocess Communication

a) General concepts and definitions

Distributed computing extends parallel computing by coordinating activities across multiple

heterogeneous systems rather than just within a single machine. It enables systems to work
collaboratively, enhancing scalability and fault tolerance.

 Definition by Tanenbaum et al.:

"A distributed system is a collection of independent computers that appears to its

users as a single coherent system."

This emphasizes resource aggregation and unified behavior across independent systems.

 Definition by Coulouris et al.:

"A distributed system is one in which components located at networked computers

communicate and coordinate their actions only by passing messages."
This highlights the importance of message passing over a network as the
foundation of distributed coordination.

b) Components of a Distributed System:

This figure shows a layered architecture of a traditional distributed system, composed of the
following layers:

Page 14
 1. Hardware Layer
o Networking and parallel hardware (servers, network cards, etc.)
o Physical infrastructure across multiple computers.
2. Operating System Layer
o Provides core services: process management, file systems, IPC (Interprocess
Communication).
o Relies on standardized protocols (TCP/IP, UDP).
3. Middleware Layer
o Offers abstraction over the OS and hardware.
o Handles:
 Communication protocols
 Data formats
 Distributed frameworks (e.g., CORBA, RMI, gRPC)
4. Application Layer
o End-user applications (data sharing, streaming, databases).
o Uses middleware for distributed capabilities.

Key Features

o Heterogeneity handling
o Message-passing for communication
o Appears as a single system to users

The above figure refines the distributed system into the cloud service model stack (IaaS, PaaS,
SaaS):

1. Infrastructure-as-a-Service (IaaS)
o Base layer: virtual hardware, networking, storage.
o Examples: Amazon EC2, Google Compute Engine.
o Managed by cloud providers; users have control over OS and deployed apps.

Page 15
 2. Platform-as-a-Service (PaaS)
o Middleware layer abstracted as a development platform.
o Provides: frameworks, libraries, databases, app hosting.
o Examples: Google App Engine, Heroku.
3. Software-as-a-Service (SaaS)
o Top layer with end-user applications.
o Delivered via browser or apps.
o Examples: Gmail, Office 365, Dropbox.

End Users and Developers

o Consumers use SaaS.

o Developers build on PaaS.
o System administrators manage IaaS.

Cloud Computing Distributed

Feature / Layer Traditional Distributed System
System
Virtualized hardware managed by
Hardware Physical networked machines
providers (IaaS)
Local control over OS and OS abstracted in IaaS; controlled by
OS
resources user/tenant
PaaS layer provides runtime, APIs,
Middleware Handles communication, protocols
dev tools
Delivered as SaaS (via
Applications Built directly over middleware
browsers/APIs)
Managed services with web-based
Management Fully manual/system admin driven
orchestration
Users consume SaaS; devs use PaaS;
End User Role Users interact with apps directly
admins use IaaS
Simplified via virtualization and
Deployment More complex; lower-level control
automation

c) Architectural Styles for Distributed Computing:

Distributed systems are complex, involving interactions across multiple layers — from hardware to
software. However, it is the middleware layer that plays the most critical role in enabling
distributed computing. It provides a coherent and uniform runtime environment for
applications spread across different machines.

Architectural styles help in:

 Classifying and understanding distributed software systems.

 Defining vocabulary: What components and connectors are used.
 Constraining composition: How these components/connectors can be combined.
 Creating a standardized approach for software engineers, similar to how design patterns
guide application-level structure.

Page 16
Two Major Classes of Architectural Styles

1. Software Architectural Styles

o Describe the logical structure of a distributed system.
o Focus on how software components interact, regardless of physical placement.
o Examples: Data-centered, data-flow, object-oriented, layered, event-driven.
2. System Architectural Styles
o Describe the physical organization of distributed systems.
o Focus on deployment of components across machines, networks, and infrastructure.

The first class relates to the logical organization of the software; the second class includes all those
styles that describe the physical organization of distributed software systems in terms of their major
components.

Components and Connectors

Before understanding architectural styles, it's essential to define their core building blocks:

Component

 A unit of software that encapsulates a specific function or feature.

 Examples:
o Programs
o Objects
o Processes
o Pipes
o Filters
 Self-contained and can operate independently or in collaboration with other components.

Connector

 A communication mechanism used to coordinate and enable interaction between

components.
 Not confined to a single entity — distributed across multiple system elements.
 Examples include:
o Message passing
o Remote procedure calls (RPC)
o Data streams
o Shared memory interfaces

1. Software Architectural Styles

Software architectural styles define the logical organization of distributed systems (irrespective of
how they're physically deployed).

Purpose

 Provide an intuitive understanding of system structure.

 Identify key abstractions and interaction patterns between components.

Page 17
Benefits of Using Architectural Styles

 Promote reusability, scalability, and maintainability.

 Help software engineers develop standardized patterns for component arrangement and
communication.

i. Data-Centered Architectures

 In data-centered architectures, data is the core element.

 All system components interact through shared data.
 Common in distributed and parallel systems, where data integrity is a top priority.
 Contains two essential parts:
1. Central Data Structure – holds the system’s state.
2. Independent Components – perform operations on the central data.

Interaction Styles

 The way components interact with the central data can vary:
o Passive Data Access: Components read/write as needed.
o Active Data Access: Data changes trigger specific actions.

Two Major Repository Subtypes

1. Database Systems

 Components control the system by querying/updating the data.

 Trigger specific processes based on their operations.

2. Blackboard Systems

 Data (blackboard) controls the flow:

o When data changes, triggers determine which processes to run.
 Best for problem-solving in dynamic environments.

Page 18
 Blackboard Architectural Style

Components:

1. Knowledge Sources
o Agents that add/update information in the blackboard.
2. Blackboard
o The shared memory/data space; acts like a central whiteboard.
3. Control
o Manages when and how agents act, based on blackboard changes.

Use Cases

 Widely used in AI systems, especially when domain knowledge is dynamic or distributed:

o Speech recognition
o Signal processing
o Knowledge-based expert systems

ii. Data-Flow Architectures in Distributed Systems:

In data-flow architectures, data availability drives the execution:

 Unlike data-centered models that focus on shared access, data-flow models focus on how
data moves between components.
 Components are linked in a flow, and data is passed along to trigger computation.
 Data flow acts as the communication medium.
 The system’s logic is structured as data transformations across components.
 Vary based on:
o How control is managed
o Concurrency level
o Flow topology

Main Styles of Data-Flow Architecture

Batch Sequential Style

 Components (programs) execute one after another in sequence.

 Output of one stage is saved (e.g., in a file) and used as input for the next.
 Control flows strictly step-by-step.

Examples

 Mainframe computing
 Scientific workflows: e.g., pre-filter → analyze → post-process
 Data processing jobs in cloud environments

Page 19
 Pipe-and-Filter Style

 Each component is a filter that processes data as it arrives.

 Filters are connected by pipes (streams) carrying data.
 Data is processed incrementally — enabling concurrent execution.
 Filters are generally:
o Stateless
o Independent
o Connected via FIFO buffers or streams

Key Feature: Pipelining

 Allows multiple filters to operate in parallel, increasing performance and responsiveness.

Examples

 Microprocessor pipeline: Instruction phases like fetch, decode, execute act as filters.
 Compiler pipelines: Lex → Yacc → Semantic Analyzer → Code Generator
 Streaming systems: Image/video/audio processing (e.g., live encoding, real-time filters)

When to Use Data-Flow Architectures

 Ideal for multistage processing pipelines.

 Suited for systems where each stage has a distinct transformation role.
 Examples:
o ETL (Extract → Transform → Load)
o Real-time analytics
o Signal processing chains

Batch Sequential vs Pipe-and-Filter

iii. Virtual Machine Architectural Styles

Virtual machine (VM) architectures introduce an abstract execution environment—a software

layer that simulates hardware/software features. This abstraction:

 Makes applications portable across systems.

 Enables uniform execution despite platform differences.
 Supports design flexibility, particularly for AI and high-level programming.

Characteristics

 Applications are written in a platform-independent format.

Page 20
  A virtual machine engine interprets and runs the application.
 May involve:
o Maintaining internal state representations
o Simulating unavailable features
 Decouples application logic from hardware constraints.

Major Styles in Virtual Machine Architectures

Rule-Based Style

 Uses an inference engine that executes rules or logic based on a knowledge base.
 Programs are expressed using rules/predicates that describe conditions or behaviors.

How It Works

 Input → Set of assertions or facts

 Engine → Applies rules to deduce new facts or trigger actions
 Output → Results of rule activation or final assertions

Use Cases

 Artificial Intelligence: Expert systems, reasoning engines

 Process control systems:
o Rule engines monitor sensors
o PLCs feed sensory data
o Alarms are triggered on rule violations
 Network Intrusion Detection Systems (NIDS):
o Rule-based pattern matching to detect attacks

Interpreter Style

 Execution is driven by interpreting pseudo-code or scripts using a dedicated engine.

 Interpretation = real-time execution

Main Components

1. Interpretation Engine – core executor

2. Internal Memory – stores pseudo-code
3. Engine State – reflects current interpreter status
4. Program State – tracks execution progress

Use Cases

 Programming language interpreters:

o Java Virtual Machine (JVM)
o .NET CLR for C#
 Scripting environments:
o Awk, Perl, Python, etc.
 Suitable for systems needing flexible, runtime-defined behavior

Page 21
 Benefits of Virtual Machine Styles:
Portability: Applications run on any system with a compatible VM
Abstraction: Developers focus on logic, not hardware.
Modularity: Easy to design reusable, high-level software components.

Limitations:
Performance overhead: Interpreting abstract instructions is slower than native execution.
Limited access to hardware: May block use of advanced system-specific features.
Complexity: Requires design of the VM itself, plus mapping to system resources

iv. Call & Return Architectures

Call & Return architectures organize systems as components that communicate via method (or
procedure) calls. The system’s activity forms a chain of calls, resembling a program control flow.

This style is foundational in software engineering and forms the basis of many programming
paradigms—especially in structured, object-oriented, and layered designs.

Key Characteristics

 Components: Functions, procedures, objects, or layers

 Connectors: Method calls, possibly including RPCs
 Emphasis: Clear caller-callee relationship and structured control flow
 Control structure often resembles a tree, where each function calls other functions.

Three Major Substyles

1️. Top-Down Style (Procedure-Oriented)

 Follows the imperative programming model.

 A main procedure controls the flow by invoking subprograms (procedures/functions).

Execution Flow:

 The program executes as a call tree starting from the main function.
 Calls can be local or remote (using RPCs and derivatives).

Use Cases

 Legacy procedural codebases (e.g., COBOL, Fortran)

 Small or well-structured systems where modularity is straightforward

Pros vs Cons
Pros Cons
Easy to understand Hard to maintain as size increases
Straightforward design Poor separation of data and behavior
Compatible with RPC systems Difficult reuse and testing in large apps

Page 22
2️. Object-Oriented Style (OOP)

 Systems are modeled using classes and objects.

 Encapsulation of data + methods within each object.

Execution Flow:

 Method invocation represents object-to-object communication.

 Objects hide their internal state and expose only controlled interfaces.
 Interactions occur through message passing or method calls.

Use Cases

 Modern enterprise systems (Java, C++, Python, etc.)

 UI frameworks, game engines, large-scale web apps

Pros vs Cons:
Pros Cons
High modularity and encapsulation Objects must know each other’s identity
Supports reuse and maintainability Shared objects may create consistency issues
Easier to model real-world entities Complexity in managing object relationships

3️. Layered Style (Stacked Abstractions)

 System is organized as a stack of layers, each offering a level of abstraction.

 Each layer interacts only with adjacent layers via well-defined interfaces.

Execution Flow

 Top-down: User calls the highest layer → each layer calls the next lower one
 Bottom-up: Lower layer events trigger actions in upper layers (callbacks)

Components and Connectors

 Components: Layers (modules with cohesive responsibility)

 Connectors: Interfaces + protocols

Use Cases

 Operating systems (e.g., kernel/user/driver layers)

 TCP/IP or OSI network stacks
 Middleware, database architectures

Pros vs Cons:
Pros Cons
Modular and organized by abstraction Hard to extend without breaking layer interfaces
Easy to swap layers (if interfaces match) Adding new features across layers is complex
Supports clean separation of concerns Performance overhead due to layer traversal

Page 23
v. Architectural Styles Based on Independent Components

These architectural styles organize systems as independent components that:

 Have their own life cycles

 Interact to achieve system behavior
 Are ideal for distributed, concurrent, and reactive systems

There are two main types:

1️. Communicating Processes

 Components are independent processes that run concurrently.

 Interaction is done via Inter-Process Communication (IPC) mechanisms like:
o Message passing
o Shared memory
o Sockets
o Remote Procedure Calls (RPCs)

Types:

 Client-Server Model: One component (client) requests services from another (server).
 Peer-to-Peer Model: All components can act both as clients and servers.

Suitable For:

 Distributed systems
 Systems spread across networked nodes
 Services needing loose coupling with service discovery

Examples:

 Microservices using gRPC or HTTP

 UNIX process pipelines
 Network applications using TCP/IP

Pros vs Cons:
Advantages Disadvantages
Clear separation of components Overhead of process communication
High scalability in distributed systems Complex synchronization
Supports concurrency and modular design Harder to debug and manage race conditions

2️. Event Systems

 Components are loosely coupled and communicate via events.

 One component emits (or publishes) an event.
 Other components subscribe (or register) to handle the event with callbacks.

Page 24
Key Concepts:

 Publish–Subscribe Model
 Events carry contextual information
 Invocation is implicit, not direct

Suitable For:

 GUI systems, IoT platforms, reactive systems, and middleware

 Applications where asynchronous behavior and extensibility are essential

Examples:

 JavaScript event listeners in browsers

 Message queues (e.g., RabbitMQ, Kafka)
 Observer design pattern

Pros vs Cons:
Advantages Disadvantages
Loose coupling and extensibility Loss of control over execution flow
Cannot guarantee event handling order or
Easy integration of new modules
even presence
Dynamic runtime behaviour; handlers Hard to analyze system correctness
don’t need known identities statically

2. System Architectural Styles:

System architectural styles define how components and processes are physically organized over
a distributed infrastructure. They:

 Provide standard reference models

 Help engineers assess system deployment, scalability, and suitability
 Enable a common vocabulary for system design

Two primary architectural styles:

a) Client/Server
b) Peer-to-Peer

Page 25
a) Client/Server Architecture

 Client: Actively sends requests

 Server: Passively listens and responds
 Communication: Unidirectional (Client → Server → Client)

Characteristics:

 Centralized service model (Many clients → One server)

 Communication over network via a standard protocol
 The server must be designed to handle multiple client requests concurrently

Client Types

1. Thin Client:

 Client handles only presentation

 Server performs data processing and logic execution
 Suitable for lightweight devices and centralized control
 Heavy load on the server

2. Fat Client:

 Client handles presentation + application logic

 Server mainly stores and manages data
 Reduced server load, faster local processing
 More complex client, harder to maintain updates

Two major classes exist:

1. Two-Tier Architecture:

 Client = Presentation layer

 Server = Application logic + Data storage
 Simple to implement
 Poor scalability (server becomes bottleneck as users grow)

Page 26
2. Three-Tier (or N-Tier) Architecture:

 Separates:
o Client (UI/presentation)
o Application server (business logic)
o Database server (data storage)
 Scalable: Tiers can run on separate machines
 Flexible and maintainable
 Complex to deploy and manage

Example of 3-tier:
Tier Component
Presentation Web browser (client)
Application Logic Web server or app server
Data Storage Database server (e.g., MySQL)

Advantages of Client/Server:

 Centralized control and management

 Easier updates in thin-client model
 Broadly applicable (web, databases, email)

Limitations:

 Single point of failure (server-centric)

 Scalability issues as user load increases
 Not suitable for large, decentralized systems

b) Peer-to-Peer (P2P) Architecture

 Symmetric architecture: All nodes (called peers) have equal responsibilities.

 Each peer can act as both a client and a server.
 No central authority or dedicated server.

Page 27
  Each peer:
o Sends requests (like a client)
o Processes incoming requests (like a server)

Characteristics of P2P Architecture:

Feature Description
Decentralized No single point of control or failure
Scalable Easily handles increasing number of peers
Self-organizing Peers can join/leave freely
Resource Sharing Peers contribute their own resources (files, bandwidth, storage)
Complex Coordination Managing routing, search, and availability is more difficult

Examples of P2P Systems:

Application Description
File-sharing system where files are split into chunks and
BitTorrent
downloaded from multiple peers simultaneously
Gnutella Early decentralized search-based file-sharing protocol
Kazaa P2P network with partial hierarchy (supernodes for indexing)
Used P2P for voice communication with some central elements for
Skype (early versions)
login and NAT traversal

Client/Server vs Peer-to-Peer:
Feature Client/Server Peer-to-Peer
Architecture Centralized Decentralized
Roles Distinct client and server Each peer acts as both client and server
Scalability Limited by server capacity High scalability with more peers
Fault Tolerance Single point of failure (server) More resilient (no central failure point)
Management Easier (central control) Harder (distributed algorithms required)
Examples Web apps, email, databases BitTorrent, Gnutella, Skype

d) Models for Interprocess Communication (IPC)

 Interprocess Communication (IPC) allows concurrent processes in distributed systems to

exchange data or coordinate actions.
 It’s crucial for making different processes act as parts of a single cohesive system.

Importance in Distributed Systems

 In distributed environments, processes do not share memory directly.

 Communication occurs over networks, using IPC mechanisms to:
o Share data
o Synchronize actions
o Request services

Page 28
Common IPC Models:

1. Shared Memory

 Processes communicate by accessing a common memory space

 Fastest form of communication (used mostly in single-machine systems)
 Requires synchronization mechanisms (e.g., semaphores, locks) to avoid conflicts

Example Use:

 Multi-threaded server where threads share a buffer

 Memory-mapped files

2. Remote Procedure Call (RPC)

 Abstraction of a local function call extended to remote services

 A process (client) invokes a procedure hosted on another process (server)
 The system hides network communication and presents it like a local call

Characteristics:

 Request/response model
 Provides language-level abstraction (stub functions)
 Common in service-oriented architectures (SOA)

Examples:

 gRPC, Java RMI, XML-RPC, SOAP

3. Message Passing

 Processes exchange explicit messages (e.g., request, reply, acknowledgment)

 Communication is synchronous (blocking) or asynchronous (non-blocking)

Characteristics:

 Messages sent over the network

 Simple, explicit, and flexible
 Common in microservices, actor models, or event-driven systems

Examples:

 MPI (Message Passing Interface), RabbitMQ, Kafka

4. Sockets

 Low-level IPC primitive used to establish communication over a network

 Support bidirectional byte-stream communication
 Provide the foundation for higher-level IPC models (RPC, message queues, etc.)

Page 29
Socket Types:

 TCP sockets – reliable, connection-oriented

 UDP sockets – faster, connectionless, but less reliable

Typical Pattern:

 Mimics client/server interaction

 Supports request-response model

Message-Based Communication:

A message refers to any discrete unit of information exchanged between distributed components.
It includes:

 Remote procedure calls

 Serialized objects
 HTTP requests
 Structured text (JSON, XML, etc.)

In essence, any IPC model that doesn’t rely on streaming data and instead transmits data in
bounded chunks can be called message-based.

Why Messages?

“A distributed system is one in which components located at networked computers communicate

and coordinate their actions only by passing messages.”

— Couloris et al.

 Messages form the foundation of interaction in distributed systems.

 They abstract underlying network details and allow for modular, decoupled, and
asynchronous communication.

Message-Based Communication

1. Message Passing

 Core Idea: Directly send and receive messages.

 Explicit message handling by developers.
 Examples:
o MPI (Message Passing Interface)
o OpenMP (used with shared memory, but can abstract message-like behavior)
 Use Case: High-performance computing (HPC), parallel computation

2. Remote Procedure Call (RPC)

 Core Idea: Call a function located on another machine as if it were local.

 RPC systems automatically wrap parameters into messages and marshal them to the
remote server.

Page 30
  Implies a client/server model.
 Examples:
o gRPC, Java RMI, XML-RPC, Apache Thrift

3. Distributed Objects

 Object-oriented extension of RPC.

 Clients access remote object references, invoke methods, and receive results via messages.
 Requires:
o Object state management
o Lifecycle control (persistent, transient, request-scoped)
 Examples:
o CORBA
o COM/DCOM
o Java RMI
o .NET Remoting

4. Distributed Agents & Active Objects

 Each object or agent has its own thread of control (active entity).
 Messages may represent commands, events, or triggers for behavior.
 Semantics of messages is richer than in RPC (may trigger asynchronous workflows).
 Examples:
o JADE (Java Agent DEvelopment Framework)
o Akka actors (in Scala/Java)
o Erlang processes

5. Web Services

 Implements message-based interaction over HTTP.

 Encodes method calls as:
o SOAP (XML-based, strict structure)
o REST (HTTP verbs like GET, POST; typically JSON)
 Enables technology-agnostic interoperability across languages/platforms.
 Examples:
o Amazon Web Services (AWS)
o Google Cloud APIs
o Any RESTful API

Role of Messages in IPC

Paradigm Message Role Communication Style Complexity
Direct exchange of
Message Passing Explicit, point-to-point Moderate
messages
Messages used for
RPC Abstracted from developer Low
call/return values
Distributed Messages tied to
Managed by runtime Medium
Objects method/state
Agents & Active
Trigger behavior/actions Asynchronous, decoupled High
Objects
Encapsulate method calls Interoperable, HTTP-
Web Services Low-Med
via HTTP based
Page 31
Message-Based Communication Models:

Distributed systems require well-structured communication among components. These interactions

are primarily built around message passing, and how those messages are exchanged determines the
system architecture and behavior.

1. Point-to-Point Message Model

 Direct one-to-one or many-to-one communication.

 The sender knows exactly who the receiver is.

Subtypes:

1. Direct Communication
o Message sent synchronously or asynchronously.
o Receiver immediately processes the message.
2. Queue-Based Communication
o Message is placed in a queue.
o Receiver processes messages later (decoupled).
o Enables asynchronous and reliable delivery.

Best for:

 Traditional client-server systems

 Load-balanced task dispatching
 Transaction processing (e.g., banking systems)

Example Technologies:

 Sockets
 JMS (Java Message Service) in P2P mode
 RabbitMQ queues

2. Publish-and-Subscribe Message Model

 One-to-many or many-to-many communication.

 Senders (publishers) don’t know the receivers (subscribers).
 Communication is event-driven.

Workflow:

 Subscribers register interest in events/topics.

 Publisher generates messages when an event occurs.
 Message gets delivered to all interested subscribers.

Dispatch Strategies:

 Push Strategy: Publisher actively notifies subscribers.

 Pull Strategy: Subscribers poll/check for new messages.

Page 32
Best for:

 Event-driven architectures
 Notifications systems
 Real-time analytics and monitoring

Example Technologies:

 MQTT
 Apache Kafka
 Amazon SNS
 Redis Pub/Sub

3. Request-Reply Message Model

 For every request message, there is a response.

 Focuses on interaction flow, not component count.

Characteristics:

 Often used in RPC-like systems.

 Enables synchronous or asynchronous replies.
 Works well in both direct and queued messaging systems.

Best for:

 Service invocation (e.g., function calls over a network)

 Microservices communication
 Distributed databases or search engines

Example Technologies:

 gRPC
 HTTP REST APIs
 ZeroMQ request-reply pattern
 AMQP RPC

Comparison Table
Interaction Addressing
Model Suitable Use Case Decoupling Examples
Pattern Style
Explicit JMS,
Point-to- One-to-one, Direct messaging,
(known Low RabbitMQ,
Point Many-to-one task delegation
address) TCP sockets
Kafka,
Publish- Event
One-to- Implicit (by MQTT,
and- notifications, real- High
many topic) Redis
Subscribe time updates
Pub/Sub
Service queries, HTTP,
Request- One-to-one Explicit or
APIs, Medium gRPC,
Reply (2-way) topic-based
command/response ZeroMQ

Page 33
 Technologies for distributed computing

1. Remote procedure Call (RPC).

2. Distributed object frameworks.
3. Service-oriented computing.

1. Remote procedure Call (RPC):

Remote Procedure Call (RPC) is a foundational abstraction that extends the concept of a local
procedure call across process and memory boundaries, enabling a client to execute a procedure on a
remote system as if it were local. Developed in the early 1980s, RPC remains a critical component
for Inter-Process Communication (IPC) in modern complex systems due to its robust and well-
established nature.

Key Characteristics and Components

 Client-Server Model: RPC operates on a client-server paradigm. A server process exposes

procedures for remote invocation and maintains a registry of these available procedures,
listening for client requests.
 Synchronous Communication: RPC inherently maintains a synchronous communication
pattern. The calling client thread blocks its execution until the remote procedure on the
server completes and returns a result.
 Marshaling and Unmarshaling: A crucial aspect of RPC is "marshaling," the process of
converting parameters and return values into a byte sequence suitable for network
transmission. "Unmarshaling" is the reverse process. These tasks are handled transparently
by the RPC runtime infrastructure, abstracting away network serialization details from the
client and server application code.
 Transparent Request-Reply Handling: Beyond data serialization, the RPC runtime
manages the entire request-reply interaction between the client and server processes, making
the distributed nature of the call transparent to the developer.
Page 34
Steps for Developing an RPC-Leveraged System:

1. Server Procedure Design: Develop and implement the procedures that will be made
available for remote invocation on the server side.
2. Procedure Registration: Register these remote procedures with the RPC server on the node
where they will be hosted and made accessible.
3. Client Code Implementation: Design and implement the client-side code responsible for
invoking these remote procedures.

RPC implementations typically offer client and server Application Programming Interfaces (APIs)
to simplify the use of this powerful abstraction. A critical consideration for parameter and return
value passing in RPC is the distributed nature of the client and server processes:

 No Pass-by-Reference/Pointers: Due to separate address spaces, passing parameters or

return values by reference or pointer is unsuitable. Unmarshaled pointers would refer to
inaccessible memory locations in the remote process.
 Marshalling User-Defined Types: For user-defined parameter and return value types, it's
crucial that the RPC runtime can marshal them. This is generally feasible, especially when
these types are composed of simpler, naturally marshalable data types.

RPC has long been a dominant IPC technology, with widespread support across various
programming languages and environments through libraries and packages (e.g., RPyC for Python).
Furthermore, platform-independent solutions like XML-RPC and JSON-RPC facilitate RPC over
XML and JSON, respectively. Frameworks like Thrift (developed by Facebook) aim to provide
transparent cross-language RPC.

It's important to note that the term "RPC implementations" now broadly encompasses a range of
solutions that have evolved from the original RPC concept. These include distributed object
programming frameworks (such as CORBA, DCOM, Java RMI, and .NET Remoting) and Web
services, each with their own unique characteristics that will be discussed in subsequent sections.

2. Distributed Object Frameworks:

Distributed Object Frameworks extend object-oriented programming to allow objects to be

distributed across a heterogeneous network while maintaining the illusion of co-located interaction
within the same address space. Building upon the foundational RPC mechanism, these frameworks
enable remote invocation of object methods and manage references to network-available objects.

Key Differences and Interaction Pattern from RPC:

Instead of procedures, distributed object frameworks manage instances exposed via well-defined
interfaces. The typical interaction flow is:

1. Server Registry: The server process maintains a registry of active objects, making them
available to other processes, often published through interface or class definitions.
2. Client Reference Acquisition: The client obtains a reference to a remote object using a
specific addressing scheme. This reference is a pointer to a local instance conforming to the
shared interface/class definition.
3. Remote Method Invocation: The client invokes methods on this "local" reference, and
parameters/return values are marshaled, similar to RPC.

Page 35
Proxy-Skeleton Mechanism for Transparency

The illusion of local interaction is achieved through a proxy-skeleton mechanism:

 Proxy (Client-side): The client environment interacts with an "Object Proxy." This proxy,
generated as a subclass of the server-published type, translates local method calls into RPC
calls for the remote object.
 Skeleton (Server-side): The server maintains an "Object Skeleton" component. When an
RPC request is received, the skeleton unpacks it, dispatches the method call to the actual
remote object instance, and after execution, packs and sends return values back to the client.
 Inheritance for Transparency: The transparency of remote method invocation is enabled
by object-oriented inheritance/subclassing, where both the proxy and the remote object
expose the same interface.

Distributed object frameworks treat objects as first-class entities for IPC, allowing them not only to
be invoked remotely but also to be passed as parameters and return values. This introduces a
significant design consideration:

 Marshaling by Value (Duplication): The standard approach, "marshaling by value,"

involves duplicating the object instance in the other execution context. This creates two
independent objects whose states evolve separately, which can lead to inconsistencies if not
carefully managed.
 Marshaling by Reference (Proxy Creation): An alternative, "marshaling by reference,"
avoids duplication. Instead, a proxy of the object is created on the remote side (e.g., on the
server for parameters, or client for return values). While more complex and resource-
intensive due to the need for tracking remote references, this technique is beneficial when
object duplication would cause unexpected or inconsistent system behavior. It should be
reserved for scenarios where duplication is problematic.

Page 36
Object activation and lifetime

Managing distributed objects presents challenges beyond simple remote procedure calls, primarily
due to object instances maintaining internal states that can be altered by method execution. A
critical aspect of distributed object-oriented systems is the lifetime of an object instance, which
differs significantly from a single memory address space. In a local context, object creation,
reference management, and memory reclamation (manual or automatic) are straightforward.
However, a distributed environment introduces complexities requiring distinct lifetime management
strategies for remotely exposed objects.

Key Elements of Distributed Object Lifetime Management:

1. Object Activation (Remote Object Creation):

o Server-Based Activation: The object is explicitly created and registered within the
server process, becoming a long-lived, independent instance that responds to remote
method invocations. Its lifetime is generally user-controlled.
o Client-Based Activation: The object does not initially exist on the server. Instead, it
is implicitly created only when a client requests a method invocation. This strategy is
more suitable for stateless objects or those acting as simple gateways, as it is more
efficient for short-lived, request-driven interactions.
2. Lifetime of Remote Objects:
o Server-Based Activation: The object's lifetime is typically under direct user control,
given its explicit creation.
o Client-Based Activation: The object's creation is implicit, so its lifetime is
governed by the runtime infrastructure's policies. Common policies include:
 New Instance per Invocation: A new object instance is created for every
method call, which can be resource-intensive. This is often combined with
lease management strategies to allow instances to be reused for subsequent
invocations within a defined time window.
 Single Instance Policy: Maintaining only one instance at a time, with its
lifetime controlled by the frequency and number of method calls.

Importance in Distributed System Design:

Object activation and lifetime management features are now standard in most distributed object
programming frameworks. They are fundamental for:

 Understanding System Behavior: Providing insights into how a distributed system

functions.
 Designing Stateful Components: Crucial for components that are accessible from other
processes and need to maintain state.
 Tracking Inconsistencies: Essential for identifying issues caused by incorrect updates to an
instance's internal data, by understanding how many objects representing a component exist
and for how long they persist.

Examples of distributed object frameworks:

a) Common object request broker architecture (CORBA)
b) Distributed component object model (DCOM/COM1)
c) Java remote method invocation (RMI)
d) .NETremoting

Page 37
Common Object Request Broker Architecture (CORBA)

CORBA, specified by the OMG, aimed to be a cross-platform, cross-language interoperability

standard for distributed components at an industrial level. Although less popular today due to
complexity and limited transparency across languages, its core architecture is significant:

 Object Request Broker (ORB): Acts as a central "object bus." CORBA objects register
their interfaces with the ORB, allowing clients to obtain references and invoke methods. The
ORB manages low-level remote invocation operations.
 Interface Definition Language (IDL): Provides platform-independent interface
specifications. IDL compilers generate language-specific client (stub) and server (skeleton)
code, which developers then implement.
 Internet Inter-ORB Protocol (IIOP): Standardizes communication between different ORB
implementations, ensuring low-level interoperability.
 Portable Object Adapter (POA): Separates the ORB's networking concerns from the
runtime environment that hosts and manages skeletons, offering architectural flexibility.

Distributed Component Object Model (DCOM/COM+)

DCOM, a Microsoft solution predating .NET, extended COM components beyond process
boundaries into distributed environments. While architecturally similar to CORBA, it's simpler and
primarily focused on Microsoft ecosystems, lacking CORBA's broad interoperability goals.

 COM Objects: Encapsulate coherent operations and standardize a binary format for
language interoperability.
 Distributed Capabilities: DCOM adds IPC support to enable distributed use of COM
objects.
 Interface Pointers: Clients obtain pointers to exposed interfaces and interact as if with a
local object, with the DCOM runtime managing the illusion.
 Microsoft-Centric: Its implementation is largely monopolized by Microsoft, offering
reasonable interoperability within Microsoft-based environments. Though still present, it's
largely superseded by newer technologies like .NET Remoting.

Java Remote Method Invocation (RMI)

Java RMI is Java's native technology for RPC among distributed Java objects, enabling method
invocation on objects residing in different Java Virtual Machines (JVMs).

 Stub-Skeleton Concept: Similar to CORBA, RMI relies on a stub (client-side) and a

skeleton (server-side) pair.
 Remote Interface: Developers define an interface extending [Link] to specify the
contract for IPC; only interfaces can be published.
 rmic Tool: The skeleton class definition is used by the rmic command-line tool to generate
the client-side stub.
 RMI Registry: A separate component that maps URIs (e.g., rmi://host:port/serviceName) to
remote object instances, allowing clients to look up and obtain references.
 Transparent Interaction: Once a remote object reference is obtained, client code interacts
with it transparently as a local instance.
 Security Customization: Leverages Java's standard security infrastructure to define access
policies for remote objects.

Page 38
.NET Remoting

.NET Remoting is the IPC technology for .NET applications, offering a unified platform for
accessing remote objects across any .NET-supported language. It distinguishes itself with its high
customizability.

 Customizable Architecture: Developers have control over transport protocols (e.g., TCP,
HTTP), serialization formats, object lifetime management, and server-side object
management.
 Application Domains: Represents isolated execution environments within a process.
Remoting enables transparent interaction between objects in different application domains,
whether on the same process, machine, or different nodes.
 MarshalByRefObject: Classes intended for remote access must inherit from
MarshalByRefObject. Objects not inheriting from this are copied (marshaled by value)
across application domain boundaries.
 Automatic Proxy Generation: No manual stub generation is required; the Remoting
infrastructure automatically provides information to generate client proxies.
 Registration: Components are made accessible by registering them with the Remoting
runtime and mapping them to URIs (e.g., scheme://host:port/ServiceName).
 Activation Strategies: Supports providing an instance or just type information (leading to
automatic, client-based activation). Developers can override default lifetime behaviors.
 Transparent Interaction & Security: Offers transparent interaction with remote objects
and allows customization of security measures, similar to Java RMI.

3. Service-Oriented Computing (SOC):

Service-Oriented Computing (SOC) is an architectural paradigm for organizing distributed systems

around services as the primary building blocks. It envisions applications as coordinated
aggregations of these services within a Service-Oriented Architecture (SOA). While not tied to a
single technology, Web services have become the de facto implementation for SOA, particularly in
enabling cloud computing by leveraging the Internet for interaction.

What is a Service?

A service is a self-contained software component offering a coherent set of reusable functionalities,

designed for integration into larger applications. The concept is highly abstract, encompassing
diverse implementations.

Don Box identifies four key characteristics of a service:

 Explicit Boundaries: Service-oriented applications consist of services potentially spread

across different domains, trust authorities, and execution environments. Interactions with
services are explicitly designed and often use message passing, as crossing these boundaries
is typically costly. Unlike the transparent remote method invocation in distributed object
programming, service interaction is explicit, with minimal interfaces to promote reuse and
simplify communication.
 Autonomy: Services are independent components designed to offer functionality, not to be
intrinsically part of a specific system. They can be integrated into multiple software systems,
even concurrently. While object-oriented systems often assume atomic application
deployment, service orientation treats this as an exception, emphasizing the service's
autonomous nature. This autonomy also dictates how services handle failures, as they

Page 39
 operate in unpredictable environments with third-party interactions. SOC addresses potential
issues like unnoticed failures, malformed messages, or unauthorized clients through
mechanisms like transactions, durable queues, redundant deployment, failover, and managed
trust relationships.
 Shared Schema and Contracts (not Class/Interface Definitions): Services define
themselves through schemas and contracts, rather than classes or interfaces common in
object-oriented systems. A service advertises a contract detailing the structure and ordering
of messages it can send or receive. This approach enhances consumability in diverse and
heterogeneous environments. To manage evolution, contracts and schemas are designed for
stability, allowing services to change without breaking existing client code. Technologies
like XML and SOAP are instrumental in supporting this feature.
 Policy-Based Compatibility: Service orientation distinguishes between structural and
semantic compatibility.
o Structural Compatibility: Based on contracts and schemas, it can be validated and
enforced by automated means.
o Semantic Compatibility: Expressed through "policies" that define a service's
capabilities and requirements. These policies are essentially expressions that must
hold true for the service to operate normally, ensuring alignment beyond just
message structure.

Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an architectural style that organizes a software system into
a collection of interacting services. It provides a set of design principles for building coherent,
decentralized systems by packaging functionalities into interoperable services that can be integrated
across different business domains.

Core Roles in SOA:

 Service Provider: Maintains and offers one or more services for consumption. Providers
can publish their services in a registry along with a service contract, which details the
service's nature, usage instructions, requirements, and any associated fees.
 Service Consumer: Locates service metadata in the registry and develops client
components to bind to and utilize the service.

It's common for components in SOA systems to act as both providers and consumers, orchestrating
or choreographing services to fulfill requests.

 Service Orchestration: Describes the automated arrangement, coordination, and

management of services, often involving a central controller to aggregate information or
create workflows.
 Service Choreography: Involves the coordinated interaction of services without a single
point of control.

Guiding Principles of SOA Platforms:

SOA emphasizes interoperability, standards, and service contracts, characterized by the following
principles:

 Standardized Service Contract: Services adhere to agreed-upon communication terms

defined in service description documents.

Page 40
  Loose Coupling: Services are self-contained, minimizing dependencies on other services.
They only need to be aware of each other's contracts, enabling flexible aggregation and agile
design.
 Abstraction: Service contracts and description documents fully define a service, hiding its
internal logic and implementation details. This simplifies system definition from a business
perspective.
 Reusability: Services are designed as reusable components, reducing development time and
costs, promoting agile design, and allowing for leveraging third-party services.
 Autonomy: Services control their encapsulated logic, and consumers do not need
implementation knowledge.
 Lack of State: Services are ideally stateless (at least in principle), increasing their
reusability and aggregatability, especially when consumed by multiple clients across
different domains.
 Discoverability: Services are defined by metadata-rich description documents, facilitating
their effective discovery and utilization of third-party resources.
 Composability: Services act as building blocks, enabling the implementation of complex
operations through orchestration and choreography to achieve business goals.

While early SOA implementations leveraged distributed object technologies like CORBA (due to
its interoperability focus), Web services are currently the predominant technology for realizing
SOA due to their interoperable platform for system and application connectivity. Beyond principles,
frameworks like the Service-Oriented Modeling Framework (SOMF) and reference architectures
from OASIS guide effective SOA implementation.

Web Services
Web services are the leading technology for implementing Service-Oriented Architecture (SOA)
systems and applications, leveraging Internet technologies and standards to build distributed
systems. Their popularity in SOA stems from several key advantages:
Interoperability: They support cross-platform and cross-language communication.
Standardization: Based on widely adopted, vendor-independent standards like HTTP, SOAP,
XML, and WSDL.
Ease of Integration: Provide a simple and intuitive way to connect disparate software systems,
facilitating rapid service composition.
Enterprise Features: Offer essential functionalities for industrial use, including service discovery
and metering (for contract compliance).
Core Concept and Interaction
At its core, a Web service exposes a set of operations that can be invoked using Internet-based
protocols, primarily HTTP. These operations support complex and simple parameters and return
values, whose semantics are defined using XML and WSDL in a platform-independent manner.
Web services are hosted on Web servers, making HTTP the most common transport protocol.

Page 41
 1. Deployment & Description: System architects develop a Web service and deploy it on a
compatible Web/application server. A Web Service Definition Language (WSDL)
document, which describes the service's interface and operations, is either uploaded to a
UDDI Registry (a global catalog) or directly attached as metadata to the service.
2. Discovery: Service consumers can discover services by querying a UDDI registry or, more
commonly, by directly requesting the WSDL metadata from the Web service itself.
3. Client Generation: The WSDL document enables service consumers to automatically
generate client-side proxies for the service, which are then integrated into their existing
applications.
4. Invocation: The "WS Client" (Web Service Client) application then uses this generated
client to send an "Invocation" request over the network to the Web service, and receives a
"Response" back.

Advantages and Evolution:

Web services are seamlessly integrated into mainstream programming languages through extensive
library and tool support, requiring less integration effort compared to older technologies like
CORBA. Their inherent interoperability makes them a superior solution for SOA compared to
platform-specific distributed object frameworks such as .NET Remoting, Java RMI, and
DCOM/COM+, which limit applicability to single environments.

Web Service Technologies Stack (XML as the Backbone):

Beyond simple remote method invocation, Web services encompass a stack of technologies that
facilitate the integration of heterogeneous applications and enable service-oriented computing (as
shown in Figure 2.17, which is not provided but described). The backbone of all these
technologies is XML, which significantly contributes to their popularity and ease of use. XML-
based languages are used for:

 Low-level Interaction: Handled by Simple Object Access Protocol (SOAP).

 Service Metadata: Provided by Web Service Definition Language (WSDL).
 Service Discovery: Facilitated by Universal Description Discovery and Integration
(UDDI).

In practice, SOAP and WSDL are the core enabling components of Web services.

Page 42
Simple Object Access Protocol (SOAP):

SOAP is an XML-based protocol for exchanging structured information platform-independently.

Within a distributed, Internet-leveraged context, SOAP acts as an application layer protocol that
typically uses transport protocols like HTTP for inter-process communication. SOAP messages are
structured as XML documents, resembling a letter with:

 Envelope: Defines the message boundaries.

 Header (Optional): Contains processing instructions, routing/delivery settings,
authentication/authorization details, and transaction contexts.
 Body: Contains the actual message content to be processed.

The primary functions of SOAP (Simple Object Access Protocol) messages are method
invocation and result retrieval for Web services. As illustrated in Figure 2.18, SOAP messages
are XML documents structured with an Envelope, an optional Header (for metadata like routing or
security), and a Body (containing the method call or execution result). For example, Figure 2.18
shows a SOAP message invoking a GetStockPrice method and its corresponding response message.
While XML's platform independence makes SOAP versatile, its verbose markup can lead to
inefficiency.

Page 43
Addressing SOAP's Inefficiency: Representational State Transfer (REST)

To overcome SOAP/XML's verbosity, Representational State Transfer (REST) emerged as a

lightweight alternative for designing network-based software systems. REST leverages standard
HTTP capabilities for inter-process communication, avoiding the overhead of additional layers.

 HTTP-Based Communication: In a RESTful system, clients send requests using standard

HTTP methods (GET, PUT, POST, DELETE) to interact with resources identified by
URIs. The server responds with a representation of the resource.
 Minimal Operations: The HTTP methods directly correspond to atomic operations for
retrieving (GET), adding (POST), modifying (PUT), and deleting (DELETE) data. This
minimal set, combined with appropriate URI organization, implements all necessary Web
service functionalities.
 Reduced Markup: While data content can still be XML (or other formats), REST
eliminates the extensive additional markup imposed by SOAP, making it more efficient.
 Context: REST is effective when advanced features beyond HTTP's native capabilities
(e.g., complex security mechanisms not built into HTTP) are not strictly required. Despite
this, RESTful Web services are highly popular and used extensively by major companies
like Twitter, Yahoo!, Flickr, and [Link] for enterprise-scale functionality.

Web Service Description Language (WSDL): Defining Service Contracts

Web Service Description Language (WSDL) is an XML-based language crucial for describing
Web services. It defines the service's interface, specifying the methods that can be called, along
with the types and structures of their required parameters and return values.

 Type and Structure Information: As Figure 2.18 highlights, SOAP messages themselves
don't contain type information for parameters or return values; this crucial metadata is stored
within the associated WSDL document.
 Automatic Client Generation: WSDL's XML-based nature allows for the automatic
generation of Web service clients in any programming language capable of interpreting
XML. This feature is fundamental to Web service interoperability and makes them a
preferred choice for SOA over less natively interoperable distributed object frameworks like
.NET Remoting, Java RMI, and DCOM/COM+.

Broader Web Technologies and Web 2.0 Influence:

Beyond core Web service technologies, Web 2.0 advancements further enhance Web and SOA-
based applications:

 Asynchronous JavaScript and XML (AJAX): A conceptual framework leveraging

JavaScript and XML to enable asynchronous behavior in web browsers, transforming simple
web pages into richer, more interactive applications. AJAX typically uses XML for data
exchange with Web services.
 JavaScript Standard Object Notation (JSON): An alternative to XML for data
transmission in AJAX contexts. JSON is often preferred due to its lighter syntax, allowing
for more concise representation of objects and collections, and thus more efficient data
transfer.

Page 44