Java Threads Rx Java Spring WebFlux WebSockets

@arafkarsh arafkarsh
8 Years
Network &
Security
6+ Years
Microservices
Blockchain
8 Years
Cloud
Computing
8 Years
Distributed
Computing
Architecting
& Building Apps
a tech presentorial
Combination of
presentation & tutorial
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
1
Microservice
Architecture Series
Building Cloud
Native Apps
Concurrency & Parallelism
Immutability, Atomic Operations
Semaphore, Monitor, Mutex (ReentrantLock),
Count Down Latch, Cyclic Barrier, Exchanger, Phaser
Threads, Thread Pool, Thread Groups
Future / Completable Future
Reactive Programming
Rx Java / WebFlux /
Server-Side Events, Web Sockets
Part 4 of 15

View Slide

@arafkarsh arafkarsh 2
Slides are color coded based on the topic colors.
Concurrency / Parallelism
Immutability / Atomic
Synchronization
Semaphore / Mutex
1
Thread Pools
Thread Groups
Future
Completable Future
2
Rx Java
Design Patterns
Observables
Operators
3
Spring Reactive
WebFlux
Mono / Flux
SSE / Web Sockets
4

View Slide

0
Code Setup
o SpringBoot 2.7.2 (MVC) / SpringBoot 3.1.0 (WebFlux)
o Java 8 for Compile and Java 17 to run
o H2 DB or PostgreSQL database
3

View Slide

Package Structure
4
Source: https://github.com/arafkarsh
Threads / Rx Java 2: https://github.com/arafkarsh/fusion-sky-threads-rx-java
Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc
Spring MVC & Security: https://github.com/arafkarsh/ms-springboot-272-vanilla

View Slide

Codebase
5
Source: https://github.com/arafkarsh/ms-quickstart

View Slide

Agile
Scrum (4-6 Weeks)
Developer Journey
Monolithic
Domain Driven Design
Event Sourcing and CQRS
Waterfall
Optional
Design
Patterns
Continuous Integration (CI)
6/12 Months
Enterprise Service Bus
Relational Database [SQL] / NoSQL
Development QA / QC Ops
6
Microservices
Scrum / Kanban (1-5 Days)
Mandatory
Design
Patterns
Infrastructure Design Patterns
CI
DevOps
Event Streaming / Replicated Logs
SQL NoSQL
CD
Container Orchestrator Service Mesh

View Slide

Application Modernization – 3 Transformations
7
Monolithic SOA Microservice
Physical
Server
Virtual
Machine
Cloud
Waterfall Agile DevOps
Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY
Architecture
Infrastructure
Delivery
Modernization
1
2
3

View Slide

Problem
8
Is Concurrency == Parallelism?

View Slide

1
Concurrency & Parallelism
o Understanding Concurrency
o Understanding Parallelism
o Immutability / Atomic Operations
o Handling Shared Resources
9

View Slide

Concurrency
10
Concurrency is the concept of managing multiple tasks by
allowing them to overlap, giving the appearance that the tasks
run simultaneously. It does not necessarily imply that the
tasks are executed at the same time. Instead, it focuses on
dealing with many things simultaneously, even if only one task
is being processed at any moment.
In a single-core system, accurate parallel execution is not
possible. However, concurrency can still be achieved through
time-slicing or multitasking, where the CPU switches between
different tasks rapidly, giving the illusion of simultaneous
execution.

View Slide

Parallelism
11
Parallelism, on the other hand, is the execution of multiple
tasks or computations at the exact same time. This requires a
multi-core processor, where tasks are assigned to different
cores and processed simultaneously.
Parallelism is a specific form of concurrency where the
overlapping tasks genuinely run simultaneously, not just
appearing to do so. It is beneficial in computations or
operations that can be divided into independent sub-tasks
that can be processed simultaneously.

View Slide

Comparison
12
Feature Concurrency Parallelism
Definition
Managing multiple tasks, allowing them
to overlap or run out of order.
Executing multiple tasks at the exact same
time.
Simultaneous
Execution
Not required; tasks may appear to run
simultaneously but don't have to.
Requires true simultaneous execution.
Use Case
Efficiently handling multiple tasks, e.g.,
I/O-bound tasks.
Speeding up computation-intensive tasks
by dividing into independent parts.
Hardware
Requirement
Can be achieved on single-core or multi-
core processors.
Generally requires multi-core processors.
Synchronization
Often requires complex synchronization
to manage shared resources.
Easier when tasks are independent and
don't need to share resources.
Performance Goal
Maximizing responsiveness, managing
many tasks at once.
Maximizing computational throughput,
completing tasks faster.
Example
Web server handling multiple client
requests.
Image processing uses multiple cores to
process different parts of an image
simultaneously.

View Slide

Summary
13
• Concurrency focuses on managing multiple tasks, giving the appearance of
simultaneous execution. It is more about structure, dealing with multiple
things at once, and can be applied even on a single-core system.
• Parallelism is a specific form of concurrency that deals with executing
several tasks or computations at the exact same time, typically on a multi-
core system.
Understanding these distinctions is vital in software architecture, especially
in cloud-native environments where efficient resource utilization and
scalability are critical. It helps choose the right strategy for different
workloads, from I/O-bound tasks that may benefit from concurrency to CPU-
bound tasks that can be accelerated with parallelism.

View Slide

Immutability
o Object Immutability
o Atomic Operations
14

View Slide

Immutable Objects
15
Immutable objects are objects
whose state cannot be changed
after creation. They provide
several benefits, especially in a
multithreaded environment:
• Thread Safety: Since their state
cannot change, they can be
safely shared across threads
without synchronization.
• Predictability: An immutable
object’s behavior is easier to
reason, leading to more
maintainable and less error-
prone code.

View Slide

Atomic Operations on Primitives
16
Atomic operations ensure that operations are completed without being interrupted
by other threads, thereby avoiding inconsistencies.
• Atomic Classes in Java: Java provides classes like AtomicInteger, AtomicLong,
etc., in the java.util.concurrent.atomic package that offers methods for
performing atomic operations on primitive variables.
• Visibility: Atomic classes also ensure that changes to a variable are visible across
threads.
• Efficiency: They typically offer better performance compared to synchronized
blocks.

View Slide

Compare and Swap (CAS)
17
CAS is a fundamental building block for many atomic operations and
concurrent algorithms. It's a hardware-level instruction supported by
many processors.
• Operation: CAS takes three parameters – a memory location (V), the
expected current value (A), and the new value (B). If the current
value at location V equals A, CAS updates V to B. Otherwise, it does
nothing.
• Atomicity: The comparison and the update happen as a single atomic
operation. If another thread changes the value at location V after the
comparison but before the update, the operation will fail.
• Usage in Java: Classes like AtomicInteger use CAS internally to
provide atomic operations.

View Slide

Example 1: Non-Thread Safe Integer Arithmetic
18
Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

View Slide

Why is the Example 1 Not Thread safe?
19
The operation x++ seems like a single operation, but it's comprised of three separate steps:
1. Read: Read the current value of x.
2. Increment: Increment the read value by 1.
3. Write: Write the new value back to x.
These three operations are not atomic, meaning multiple threads can interleave in undesirable
ways. Here's an example with two threads:
• Thread 1 reads x (value is 0).
• Thread 2 reads x (still 0 because Thread 1 still needs to update it).
• Thread 1 increments and writes the value (now 1).
• Thread 2 increments the old value it read (0 + 1 = 1) and writes it back.
Both threads intended to increment the counter, but it only got incremented once because of the
race condition.

View Slide

Example 2: Thread Safe Integer Arithmetic
20

View Slide

Why Example 2 thread safe?
21
AtomicInteger uses low-level synchronization mechanisms, often employing
Compare And Swap (CAS), to ensure that the read-modify-write operations
are done atomically. When you call incrementAndGet() on an AtomicInteger,
it ensures that the underlying value is incremented so that no two threads
can interfere with each other’s updates. This way, you avoid the race
condition illustrated above.
So, in a multithreaded environment, using AtomicInteger would ensure that
each thread correctly increments the value without corrupting it, thereby
making the operation thread-safe.
Understanding these subtleties is particularly important in concurrent and
distributed systems, as you might encounter in your work with Cloud Native
Architecture and Security. Using thread-safe constructs like AtomicInteger
helps to build more robust and scalable systems.

View Slide

Handling Shared Resources
o Synchronization
o Semaphores / Monitor / Mutex / Count Down Latch
o Cyclic Barrier / Exchanger / Phaser
22

View Slide

Synchronization
23
Synchronization is a general concept that refers to
coordinating the execution of multiple threads to
ensure that they can safely access shared resources
or perform actions in a specific sequence.
Without proper synchronization, there can be race
conditions, where the program’s behavior depends
on the threads’ relative timing, leading to
unpredictable or erroneous behavior.

View Slide

Compare
24
Feature Synchronization Semaphore Monitor Mutex
Primary
Purpose
Coordinate
multiple threads'
execution.
Control access to a
common resource
by threads.
Mutual exclusion +
ability to wait for
conditions.
Enforce mutual
exclusion.
Mechanism
General concept;
various
techniques.
Counting
mechanism; Wait
and Signal
operations.
Mutual exclusion +
Condition
Variables.
Lock/Unlock
operations.
Complexity
Depends on the
specific
technique used.
Relatively simple;
versatile.
More complex;
high-level
synchronization.
Simple;
specifically for
mutual exclusion.
Use Cases
Various; depends
on the situation.
Resource
management, flow
control.
Complex
synchronization,
producer-consumer
problems.
Protecting critical
sections from
race conditions.
Java Semaphore
Java Thread Wait &
Notify
ReentrantLock

View Slide

Semaphore
25
A Semaphore is a synchronization primitive that controls multiple
threads’ access to a shared resource. It maintains a count representing
the number of available resources:
• Wait (P operation): If the count is greater than zero, it is
decremented, and the thread continues. If the count is zero, the
thread blocks until it becomes greater than zero.
• Signal (V operation): This operation increments the count, potentially
unblocking a waiting thread.
Semaphores can implement various synchronization patterns, including
mutual exclusion (MutEx using a binary semaphore) or limiting
concurrency to a fixed number of threads.

View Slide

Semaphore Java Example
26
Only one thread can acquire the
lock at any given time because
only one permit is available.
Subsequent calls to acquire() from
other threads will be blocked until
the thread that holds the lock calls
release().
Initializing the semaphore with
10 permits means up to 10
threads can concurrently acquire
the lock.
Use cases
1. Thread Pools
2. Database Connection Pools

View Slide

Monitor
27
A Monitor is a synchronization construct that allows threads to have
both mutual exclusion and the ability to wait for a certain condition to
become true. Monitors provide:
• Mutual Exclusion: Only one thread at a time can execute inside the
monitor, ensuring controlled access to shared resources.
• Condition Variables: These allow threads to wait inside the monitor
for specific conditions to be met and to signal other threads when
conditions have changed.
In many programming languages, Monitors are implemented using
objects and associated lock mechanisms, and they provide a high-level
way to manage concurrent access to shared resources.

View Slide

Monitor Java Example
28

View Slide

Java notify()
29
In Java, both notify() and notifyAll() methods are used to wake up threads waiting for a
condition to be met, typically within a synchronized block or method. They are part of Java's
built-in synchronization support, often termed "intrinsic locks" or "monitors.”
notify()
When notify() is called, it wakes up a single waiting thread from the waiting pool
associated with the object's monitor. If multiple threads are waiting, it chooses one thread
to wake up, but it's not specified which one will be chosen; the choice is arbitrary and
implementation-dependent.
Behavior with Multiple Waiting Threads:
• Wake Up: Only one among multiple waiting threads is woken up.
• Choice: Which thread will be woken up is not deterministic; it depends on the
scheduling policy.

View Slide

Java notifyAll()
30
When notifyAll() is called, it wakes
up all the threads currently waiting
on that object's monitor.
Behavior with Multiple Waiting
Threads:
• Wake Up: All waiting threads are
woken up.
• Competition: After waking up,
they will compete for the lock.
Only one will get it, and the
others will return to waiting.

View Slide

MutEx
31
A Mutex is a synchronization primitive specifically designed to enforce
mutual exclusion. When a thread acquires a Mutex (also known as
locking the Mutex), no other thread can access the critical section
protected by that Mutex until the original thread releases it:
• Lock: A thread locks the Mutex to gain exclusive access to the
critical section.
• Unlock: The thread unlocks the Mutex when it is done, allowing
other threads to enter the critical section.
A Mutex ensures that only one thread at a time can execute the code
that accesses shared resources, preventing race conditions.

View Slide

Mutex: ReentrantLock – Java Example
32

View Slide

Conditions with Mutex - ReentrantLock
33
The ReentrantLock class in Java's java.util.concurrent.locks package allows
for more flexible and fine-grained control over synchronization than
synchronized blocks. One of its powerful features is the use of Condition
objects, which allow threads to wait for specific conditions to be met
before proceeding.
A Condition object is often used as a replacement for the Object monitor
methods wait(), notify(), and notifyAll() when using ReentrantLock.
Example: Producer-Consumer with ReentrantLock and Condition
The example that simulates a producer-consumer relationship. The
producer adds items to a shared LinkedList, and the consumer removes
them. The producer and consumer operate concurrently and coordinate
using ReentrantLock and Condition.

View Slide

ReentrantLock with Condition Example
34

View Slide

Understanding the Producer Code
35
• int value = 0;: This initializes the value to be inserted into the list to 0.
• while (value < totalItems ) { ... }: The producer will produce until it reaches the max no. of items defined.
• lock.lock();: This acquires the lock. After this point, only one thread can execute the code inside the try
block until lock.unlock(); is called.
• while (list.size() == capacity) { ... }: If the list is full (the size is equal to the capacity), the producer will enter
this while loop. Inside this loop, notFull.await(); is called, which makes the producer thread wait until the
notFull condition is met (i.e., the list is not full). In simpler terms, the producer will pause and release the
lock, allowing other threads to acquire it. When the consumer consumes an item and calls notFull.signal();,
the waiting producer is awakened, and the loop condition (list.size() == capacity) is re-evaluated.
• list.add(value++);: Adds a value to the list and then increments it for the next round of production.
• notEmpty.signal();: This signals any waiting consumer threads that the list is no longer empty, and they can
proceed to consume items.
• finally { lock.unlock(); }: Whether or not an exception is thrown inside the try block, the lock will be
released, allowing other threads to acquire it.

View Slide

ReentrantLock with Condition Example
36

View Slide

ReadWriteLock
37
The ReadWriteLock interface in Java provides a pair of locks for read and write
operations. A ReadWriteLock allows multiple threads to read a shared resource
concurrently, but only one can write to it at any given time. This can result in better
performance than using a single, mutual exclusion lock.
1. Read Locks: Multiple threads can acquire read locks as long as no thread holds a
write lock.
2. Write Locks: Only one thread can acquire a write lock, and no other thread can
hold either a read or write lock during this time.
3. Fairness Policy: ReadWriteLock implementations, like ReentrantReadWriteLock,
can be constructed to follow a fairness policy, where they favor granting access
to the longest-waiting thread, whether it is a reader or writer.
4. Reentrant Capabilities: The ReentrantReadWriteLock allows threads to re-enter
any lock (read or write) they already hold.

View Slide

ReadWriteLock
38
5. Lock Downgrading: A writer can downgrade to a reader lock
without releasing the write lock, allowing a more graceful transition
from write to read operations.
6. Separate Conditions: The write lock provides the same Condition
support as ReentrantLock, allowing you to manage conditional
synchronization.
7. Non-Blocking tryLock(): Both read and write locks offer a non-
blocking tryLock() method to attempt lock acquisition without
blocking.
8. Timed Lock Waits: The ReadWriteLock supports timed lock waits. A
thread can attempt to acquire a lock for a specified maximum time.

View Slide

ReadWriteLock – Example
39

View Slide

ReadWriteLock – Example
40
The readResource method acquires a read lock, reads the
sharedResource variable, and then releases the read lock.
The writeResource method acquires a write lock, updates the
sharedResource variable, and then releases the write lock.

View Slide

Count Down Latch
41
The CountDownLatch class in Java's java.util.concurrent
package serves as a synchronization mechanism that allows
one thread to wait for one or more threads before it starts
processing.
• The latch is initialized with a count, which is decremented
using the countDown() method.
• The thread that needs to wait for other threads to finish
uses the await() method, which blocks until the count
reaches zero.

View Slide

Count Down Latch Example
42

View Slide

Count Down Latch Example
43

View Slide

Feature Comparison
44
Feature CountDownLatch Semaphore Monitor Mutex
Purpose
Coordination
Allows one or more threads to wait
until a set of operations in other
threads completes.
Resource Access
Manages a set of permits
for controlling access to a
resource.
Mutual Exclusion
Encapsulates mutual
exclusion and condition
synchronization within an
object.
Mutual Exclusion
Provides exclusive access
to a section of code to
only one thread at a time.
Behavior
One-way
One-way countdown; once the
count reaches zero, it cannot be
reset.
Two-way
Permits can be acquired
and released, making it a
two-way mechanism.
Conditional
Uses wait(), notify(), and
notifyAll() methods for
coordination.
Exclusive
Acquire before entry and
release after exit.
Flexibility
Low
Less flexible in terms of reusability;
once the latch reaches zero, it can't
be used again.
High
More flexible as permits
can be dynamically
acquired and released.
High
Allows complex conditions
for entering the
synchronized block.
Medium
Generally, less flexible;
and designed for mutual
exclusion, not for
signalling between
threads.
Reusability No Yes Yes Yes
Common
Use-Cases
Initialization, Aggregation
Waiting for initialization tasks to
complete before application Startup,
computation tasks to finish before
aggregating results, etc.
Resource Pooling,
Rate Limiting
Resource pooling, limiting
concurrent access to a
section of code, etc.
Complex Conditions
Producer-consumer
problems, reader-writer
problems, etc.
Critical Sections
Critical sections, singleton
initialization, etc.

View Slide

Cyclic Barrier
45
1. Functionality: A synchronization aid that allows a set of
threads to wait for each other to reach a common
execution point.
2. Resettable: Can be reset and reused.
3. Actions at Barrier: You can specify a runnable action that is
executed when the last thread reaches the barrier.
4. Use Cases: Useful in parallel algorithms where threads
perform work in phases and each phase depends on the
completion of the previous phase.

View Slide

Cyclic Barrier Example
46

View Slide

Cyclic Barrier Example
47

View Slide

Exchanger
48
1. Functionality: A synchronization point where threads can
swap objects.
2. Pairing: Pairs up threads and allows them to exchange
data.
3. Blocking: Threads will block until the paired thread arrives.
4. Use Cases: Useful in genetic algorithms, or any kind of
algorithm where two threads need to swap data at a
certain point

View Slide

Exchanger Example
49

View Slide

Phaser
50
1. Functionality: A more flexible and reusable synchronization
barrier.
2. Phases: Supports multiple phases, and threads can de-
register themselves dynamically.
3. Flexible Registration: Allows dynamic addition and removal
of threads.
4. Actions at Phases: Allows actions to be performed at the
commencement of each phase.
5. Use Cases: Useful in complex algorithms where the
number of threads and phases can change during runtime.

View Slide

Phaser – Objectives
51
The Java Phaser class is a thread synchronization mechanism that is more flexible than both
CyclicBarrier and CountDownLatch. The Phaser ensures that multiple threads can perform a series
of actions in sync. Unlike CyclicBarrier, Phaser allows the number of registered parties (threads) to
change over time.
Objective of Phaser
The objective of the Phaser class is to provide a synchronization barrier that allows threads to wait
for each other, but with the added flexibility of:
1. Dynamic Registration: You can register or de-register threads dynamically.
2. Phases: You can divide the tasks into multiple phases and synchronize threads at each phase.
Use Case
Consider a scenario where you have a multiplayer online game with various stages or "phases".
Players may join or leave at any stage, and you need to ensure that the stage begins when all players
in that stage are ready.
Each player can be considered a separate thread, and the game stages as phases.

View Slide

Phaser – Example
52
• Initialization: A Phaser is initialized with a count of 3, indicating that 3 threads are
participating.
• All threads must complete each phase before any thread can move on to the next
phase, ensuring synchronization between phases.
• In microservices, a Phaser could be applicable when you need to orchestrate
multiple services or tasks that are part of a workflow. Primarily, when you deal
with services that can be dynamically scaled, Phaser provides the ability to
handle such complexity with its dynamic registration features.

View Slide

Phaser – Example
53
Phase Completion: Threads call arriveAndAwaitAdvance() to signal they have
completed the current phase. This call is blocked until all registered threads arrive.
Deregistration: Once a thread completes all Stages, it deregisters
itself.

View Slide

Comparison
54
Feature CyclicBarrier Exchanger Phaser CountDownLatch
Functionality
Wait for
each other
Data
exchange
Multiple
phases
Wait for events
Resettable Yes N/A Yes No
Dynamic
Registration
No No Yes No
Actions at
Sync Point
Yes No Yes No
Use Cases
Parallel
algorithms
Data
swapping
Complex
dynamic tasks
One-time
event wait
Complexity Moderate Moderate High Simple

View Slide

Summary
55
• Cyclic Barrier: Best for scenarios where you have a fixed number of threads that
must wait for each other to reach a common point before proceeding. It is
beneficial in parallel algorithms like matrix multiplication.
• Exchanger: Useful when you need two threads to exchange data at a certain
point. This is common in genetic algorithms or task-result reconciliation
scenarios.
• Phaser: Highly flexible and designed for complex synchronization requirements.
It can handle various threads and phases, making it ideal for problems requiring
more complex coordination.
• CountDownLatch: Suited for scenarios where one or more threads must wait for
events to occur. Once all events have occurred, the latch is released. It's simpler
but non-resettable.

View Slide

2
Thread Pools
o Thread Pools and Thread Groups
o Future
o Completable Future
56

View Slide

Thread Pools and Thread Groups
o Thread Pools
o Thread Groups
o Thread Pools using Semaphores
57

View Slide

Thread Pools
58
1. Purpose: Manages a fixed number of threads and reuses them for executing tasks (typically
implements Runnable or Callable).
2. Control over Execution: Provides more control over when tasks are executed.
3. Task Queue: Usually has a task queue where tasks wait until a thread becomes available.
4. Resource Management: Better resource management, as the number of threads is fixed and
reused, reducing the overhead of thread creation and destruction.
5. Error Handling: It is easier to handle errors and exceptions through features like Future.
6. Shutdown: Provides graceful shutdown capabilities, allowing running tasks to be completed
before terminating.
7. Built-in Features: Various built-in policies for task scheduling, thread creation, and termination
(e.g., ScheduledThreadPoolExecutor for scheduled tasks).
8. Concurrency Control: Can be used in combination with other concurrency control mechanisms
like Semaphore, CountDownLatch, etc.

View Slide

Thread Pool with Executor Service
59
Advantages
1. Ease of Use: ExecutorService abstracts away many low-level details of thread
management.
2. Thread Pooling: Built-in thread pool management.
3. Graceful Shutdown: Provides methods to shut down the pool safely.
4. Task Scheduling: Supports delayed or periodic task execution.
5. Future Support: Can return Future objects to fetch computation results
asynchronously.
Disadvantages
1. Overhead: Higher-level abstractions may introduce some overhead.
2. Limited Control: More flexible for tasks requiring low-level thread control.

View Slide

Thread Pool with Executor Service
60

View Slide

Thread Groups
61
1. Purpose: Serves as a convenient way to group multiple threads for easier management and
control. It doesn't reuse threads.
2. Control over Execution: Limited control over when and how threads within the group are
executed.
3. Task Queue: No task queue. Threads are executed as soon as they are started.
4. Resource Management: No inherent resource optimization. Threads are neither pooled nor
reused.
5. Error Handling: Provides very minimal support for error handling.
6. Shutdown: It doesn't provide an inherent way to shut down threads gracefully. You have to
manage this manually.
7. Built-in Features: Lacks advanced features like scheduling or task prioritization.
8. Concurrency Control: Provides basic synchronization mechanisms but less flexibility than thread
pools.

View Slide

Thread Pool with Thread Groups
62
Advantages
1. Group Operations: Easy to manage a group of threads, like pausing, stopping, or
interrupting them at once.
2. Less Overhead: Lower-level than ExecutorService, which can sometimes mean less
overhead.
3. Direct Control: More control over the individual threads.
Disadvantages
1. Thread Safety: Managing thread life cycles and task submissions can be error-prone.
2. Manual Management: Requires more manual effort for thread pooling and resource
management.
3. Deprecation: Some methods of ThreadGroup are deprecated, and it is considered
legacy.

View Slide

Thread Pool with Thread Group
63
ExecutorService is generally
recommended for production
use due to its robust features,
ease of use, and built-in thread
pooling capabilities. It provides a
cleaner, more maintainable way
of handling concurrent tasks.

View Slide

Summary
64
Feature Thread Pool Thread Group
Purpose Task execution Thread grouping
Control High Low
Task Queue Yes No
Resource Management Optimized Manual
Error Handling Advanced Basic
Shutdown Graceful Manual
Built-in Features Many Few
Concurrency Control High Flexibility Basic

View Slide

Thread Pool / Executor Service / Semaphore
65

View Slide

Thread Pool / Executor Service / Semaphore
66

View Slide

Asynchronous API
o Future
o Completable Future
67

View Slide

Future
68
The Future and CompletableFuture classes in Java provide
mechanisms for representing the result of an asynchronous
computation. These classes make writing asynchronous, non-
blocking, and multi-threaded code easier.
Future
A Future represents the pending result of an asynchronous
computation. It provides methods to check if the computation
is complete, to wait for its completion, and to retrieve the
result.

View Slide

Future Example
69
Key Features:
1. Blocking: The get() method is blocking.
It waits until the computation is
complete, and the result is available.
2. Cancellation: You can cancel a
computation using cancel().
3. Check for Completion: You can check if
the computation is complete using
isDone().

View Slide

Completable Future
70
CompletableFuture extends the Future to provide a more feature-rich
and flexible API for working with asynchronous computations. It
enables you to write non-blocking, asynchronous code in a more
readable and maintainable manner.
Key Features:
1. Non-blocking Operations: Methods like thenApply, thenCompose,
and thenCombine allow for non-blocking operations.
2. Combining Multiple Async Computations: You can combine multiple
asynchronous computations easily.
3. Exception Handling: It provides methods like exceptionally and
handle to deal with exceptions.

View Slide

Completable Future
71

View Slide

Comparison
72
1.Blocking Nature
1. Future: The Future.get() method blocks, meaning it will hold up the thread until the result is
available or an exception is thrown.
2. CompletableFuture: Provides a non-blocking, event-driven model for completing the future. You
can chain methods like thenApply, thenCompose, etc., to handle results without blocking.
2.Exception Handling
1. Future: Exception handling could be more complex. You'll only know of an exception when you
call get().
2. CompletableFuture: Provides better mechanisms like exceptionally and handle to recover from
exceptions.
3.Method Chaining and Composition
1. Future: Does not support method chaining directly.
2. CompletableFuture: Supports method chaining and allows combining multiple asynchronous
computations.

View Slide

Comparison
73
4. Combining Multiple Futures
1. Future: There is no direct way to combine multiple Futures.
2. CompletableFuture: Methods like thenCombine and allOf allow you to combine multiple
futures easily.
5. Applicability
1. Future: Suitable for simpler, fire-and-forget asynchronous operations.
2. CompletableFuture: Better suited for complex asynchronous workflow, reactive programming,
and combining multiple asynchronous results.
6. Readability
1. Future: As you use external mechanisms for better control flow, the code might become less
readable.
2. CompletableFuture: Provides a more readable and maintainable code due to its rich API for
composing and combining asynchronous computations.

View Slide

Completable Future Example
74

View Slide

Completable Future Example
75

View Slide

Comparison – Future / Completable Future
76
Feature Future CompletableFuture
Blocking Nature Yes No
Exception Handling Basic Advanced
Method Chaining No Yes
Combine Multiple
Futures
No Yes
Applicability Simple tasks Complex workflows
Readability Lower Higher
API Complexity Simple Rich and Flexible

View Slide

Completable Future and Rx Java
77
Completable Future
1. Design Philosophy: Built into the Java standard library, aimed at simplifying asynchronous
programming in a future-promise style.
2. Thread Model: Usually utilizes a fixed pool of worker threads, but you can specify custom thread
pools.
3. Exception Handling: Provides explicit exception handling using exceptionally() or handle()
methods.
4. Chaining Operations: Enables straightforward chaining of asynchronous tasks using methods like
thenApply, thenAccept, etc.
5. API: Limited API focused mainly on representing a single future result. It provides methods to
combine multiple futures but is less rich and comprehensive than RxJava.
6. Back Pressure: This doesn’t natively support back pressure.
7. Operators: Limited number of operators compared to RxJava.
8. Use-Case: More suitable for simpler use-cases or when dealing with a single asynchronous
computation and its resultant data.

View Slide

Completable Future and Rx Java
78
RxJava Observable
1. Design Philosophy: Implements the Reactive Extensions (Rx) library standards and aims at providing
a comprehensive platform for reactive and asynchronous programming.
2. Thread Model: Flexible and allows you to specify schedulers (observeOn, subscribeOn) to control
threading behavior more granularly.
3. Exception Handling: This can be done using operators like onErrorResumeNext, onErrorReturn, etc.
4. Chaining Operations: Rich operators like map, filter, zip, concat, etc., for composing asynchronous
operations.
5. API: Rich and comprehensive API designed for various use cases, including complex data
transformation, filtering, and combination.
6. Back Pressure: Supports back pressure through the Flowable class.
7. Operators: Extensive set of operators for various data manipulations and transformations.
8. Use-Case: Better suited for complex and advanced use cases, especially when dealing with data
streams.

View Slide

Comparison
79
Design Philosophy Future-Promise Reactive Programming
Thread Model Fixed or Custom Pool Flexible Schedulers
Exception Handling exceptionally() onErrorXXX operators
Chaining
Limited (thenApply,
thenCompose)
Extensive
(map, filter, etc.)
API Richness Limited Rich and Comprehensive
Back Pressure No Yes (Flowable)
Operators Limited Extensive
Best Use-Case Simple Async Tasks Complex Data Streams

View Slide

3
Functional Reactive Programming
o Architecture & Design Patterns
o Building Blocks of Rx Java
o Observable and Observer Design Pattern
o Examples
80

View Slide

Functional Reactive Programming
81
Resilient
Elastic
Message – Driven
1. A responsive, maintainable &
Extensible application is the
goal.
2. A responsive application is both
scalable (Elastic) and resilient.
3. Responsiveness is impossible to
achieve without both scalability
and resilience.
4. A Message-Driven architecture
is the foundation of scalable,
resilient, and ultimately
responsive systems.
Value
Means
Form
Principles What it means?
Responsive thus React to users demand
Resilient thus React to errors and failures
Elastic thus React to load
Message-Driven thus React to events and messages
Source: http://reactivex.io/
Responsive Maintainable Extensible

View Slide

Functional Reactive Programming : Result = Decoupling
82
1. Containment of
1. Failures
2. Implementation Details
3. Responsibility
2. Shared Nothing Architecture, Clear Boundaries
3. Single Responsibility Principle

View Slide

Functional Reactive Programming : Design Patterns
83
83
Single
Component Pattern
A Component shall do ONLY one thing,
But do it in FULL.
Single Responsibility Principle By DeMarco : Structured
Analysis & System Specification (Yourdon, New York, 1979)
Let-It-Crash
Pattern
Prefer a FULL component restart to
complex internal failure handling.
Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003)
Popularized by Netflix Chaos Monkey. Erlang Philosophy
Saga
Pattern
Divide long-lived distributed
transactions into quick local ones with
compensating actions for recovery.
Pet Helland: Life Beyond Distributed Transactions CIDR 2007

View Slide

4 Building Blocks of RxJava
84
84
Observer Listens for emitted values [ Receiver ]
Observable Source of Data Stream [ Sender ]
Client Server
Request
Response
Traditional Synchronous Pull
Communications
1. The Observer subscribes (listens) to the Observable
2. Observer react to what ever item or sequence of items the Observable emits.
3. Many Observers can subscribe to the same Observable
Observer Observable
on Next
on Completed
on Error
Time
Subscribes
Non Blocking
Time
1
2

View Slide

4 Building Blocks of RxJava
85
Schedulers
Operators
Content Filtering
Time Filtering
Transformation
Schedulers are used to manage and control
concurrency.
1. observeOn: Thread Observable is executed
2. subscribeOn: Thread subscribe is executed
Operators that let you
Transform, Combine,
Manipulate, and work
with the sequence of
items emitted by
Observables
3
4

View Slide

Observable Design Pattern (Marble Diagram) 1
Building
Block
86
• An Observer subscribes to an Observable.
• Then that observer reacts to whatever item or sequence of items the
Observable emits.
Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html | http://rxmarbles.com

View Slide

Observable / Observer Design Pattern
87
• Allows for Concurrent Operations: the
observer does not need to block while
waiting for the observable to emit values
• Observer waits to receive values when
the observable is ready to emit them
• Based on push rather than pull
1 & 2
Building
Block

View Slide

What’s missing from GOF Observer Pattern
88
1
Building
Block
Source:http://reactivex.io/intro.html
1.The ability for the producer to signal to the consumer that there
is no more data available (a foreach loop on an Iterable
completes and returns normally in such a case; an Observable
calls its observer’s onCompleted method)
2.The ability for the producer to signal to the consumer that an
error has occurred (an Iterable throws an exception if an error
takes place during iteration; an Observable calls its
observer’s onError method)
3.Multiple Thread Implementations and hiding those details.
4.Dozens of Operators to handle data.

View Slide

Compare Iterable Vs. Observable
31 August 2023 89
Observable is the asynchronous / push
dual to the synchronous pull Iterable
• Composable: Easily chained together or
combined
• Flexible: Can be used to emit:
• A scalar value (network result)
• Sequence (items in a list)
• Infinite streams (weather sensor)
• Free from callback hell: Easy to transform
one asynchronous stream into another
Observables are:
Event
Iterable
(Pull)
Observable
(Push)
Retrieve Data T next() onNext(T)
Discover Error
throws
Exception
onError
(Exception)
Complete !hasNext() onComplete()
1
Building
Block
Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html

View Slide

Comparison : Iterable / Streams / Observable
31 August 2023 90
1
Building
Block
First Class Visitor (Consumer)
Serial Operations
Parallel Streams (10x Speed)
Still On Next, On Complete and
On Error are Serial Operations
Completely Asynchronous
Operations
Java 8 – Blocking Call
Java 6 – Blocking Call Rx Java - Freedom

View Slide

Observer Contract
91
Methods:
• onNext(T)
• onError(Throwable T)
• onCompleted()
onError / onCompleted called precisely once
2
Building
Block
Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html
X
|
Time Line

View Slide

RxJava Scheduler Details
92
Source: http://reactivex.io/documentation/scheduler.html
• If you want to introduce multithreading into your cascade of
Observable operators, you can do so by instructing those operators
(or particular Observables) to operate on particular Schedulers.
• By default, an Observable and the chain of operators that you apply
to it will do its work, and will notify its observers, on the same thread
on which its Subscribe method is called.
• The SubscribeOn operator changes this behavior by specifying a
different Scheduler on which the Observable should operate.
TheObserveOn operator specifies a different Scheduler that the
Observable will use to send notifications to its observers.
3
Building
Block

View Slide

RxJava Scheduler Threading Details
31 August 2023 93
Source: http://reactivex.io/documentation/scheduler.html
Scheduler Purpose
1 Schedulers.computation ( ) Meant for computational work such as event-loops and callback
processing; do not use this scheduler for I/O.
(useSchedulers.io( ) instead)
The number of threads, by default, is equal to the number of processors
2 Schedulers.from(executor) Uses the specified Executor as a Scheduler
3 Schedulers.immediate ( ) Schedules work to begin immediately in the current thread
4 Schedulers.io ( ) Meant for I/O-bound work such as asynchronous performance of
blocking I/O, this scheduler is backed by a thread-pool that will grow as
needed; for ordinary computational work, switch to
Schedulers.computation( );
Schedulers.io( ) by default is a CachedThreadScheduler, which is
something like a new thread scheduler with thread caching
5 Schedulers.newThread ( ) Creates a new thread for each unit of work
6 Schedulers.trampoline ( ) Queues work to begin on the current thread after any already-queued
work
3
Building
Block

View Slide

RxJava Operator : Frequently used
Content Filtering
1 Observable filter (Func1 Predicate)
2 Observable skip (int num)
3 Observable take (int num)
4 Observable takeLast (int num)
5 Observable elementAt (int index)
6 Observable distinct ()
7 Observable distinctUntilChanged ()
94
Time Filtering
1 Observable throttleFirst (long duration, TimeUnit unit)
2 Observable throttleLast (long duration, TimeUnit unit)
3 Observable timeout (long duration, TimeUnit unit)
Transformation Use
1 Observable map (Func1 func) Transforms Objects
2 Observable flatMap (Func1> func) Transforms an Observable to another Observable
3 Observable cast (Class klass)
4 Observable> groupBy (Func1 keySelector)
4
Building
Block

View Slide

The Problem? How Rx Helps!
95
2
Building
Block
Apple Basket
Fruit Processor
Scenario
1. A Basket Full of Apples
2. Fruit Processor capacity (limit) is 3 Apples at a time.
The Problem
1. I don’t have time to wait till the Fruit Processor finishes it’s job.
2. I don’t mind having multiple Fruit Processors too. But that still
doesn’t solve the problem
What I need
1. I want to start the Process and leave.
2. Once the processing is done, then the system should inform me.
3. If something goes wrong, then the system should inform me.
Me = the calling program

View Slide

RxJava : Examples – Handling Fruit Processor
31 August 2023 96
1
Building
Block
Completely Asynchronous
Operations
Rx Java - Freedom
1. Abstract Fruit
2. Fruit (Interface)
3. Apple
4. Orange
5. Grapes
6. Mixed Fruit
(Aggregate Root)
Entities
1. Fruit Processor (Domain
Service) - Observer
2. Fruit Basket Repository
3. Fruit Basket Observable
Factory
Business Layer
Next Section focuses more on Operators and how to handle
business logic in Asynchronous world!
1. Rx Java Example : Observable / Observer / Scheduler
Implementation
2. Rx Java Example 2 : Merge / Filters (on Weight) / Sort (on Price)

View Slide

RxJava : Entities & Repositories
31 August 2023
97
1
Building
Block
Fruit Interface Abstract Fruit Fruit Repository

View Slide

RxJava : Entities
98
1
Building
Block
Apple Orange Grapes

View Slide

Rx 2 Java : Apple Fruit Basket : Observable
99
1
Building
Block
1. This function calls the Apple Basket Repository
function to load the data.
2. Observable is created using the collection from
the data returned by the Repository
3. Subscribe method checks if the Observer is NOT
Disposed.
4. If Yes for Each Apple it calls the Observer to do
the action = observer.onNext (fruit)
5. Once the process is completed
6. Observable will call the on Complete method in
Observer.
7. If an error occurs then Observable will call the
on Error method in Observer
Fruit Basket Observable

View Slide

Rx 2 Java : Fruit Processor : Observer
100
1
Building
Block
1. Fruit Processor implements Subscriber
(Observer) interface
2. On Next Method Implementation. Main
Business logic is done over here. Observable
will call on Next and pass the Fruit Object for
processing.
3. On Complete Method. Observable will call this
method once the processing is done.
4. If Any error occurred then Observable will call
on Error method and pass on the Exception.
5. test() implements the Predicate for filtering.
Weight is passed as a parameter in Fruit
Processor Constructor.
Fruit Processor Observer
Fruit Processor Handles the Business Logic

View Slide

10
1
Bringing all the
pieces together
Apple Basket
Fruit Processor
Observable / Observer / Schedulers / Operators

View Slide

Rx 2 Java Operator : Merge 3 Streams
102
4
Building
Block
Objective:
Merge Three Data Streams (Apple Fruit Basket, Orange Fruit Basket & Grapes Fruit Basket) into a Single Stream and
do the Processing on that new Stream Asynchronously
A1 is the Apple Series, O1 is the Orange Series & G1 is the Grapes Series
Rx Example 2

View Slide

Rx 2 Java Operator : Merge / Filter Streams
103
4
Building
Block
Objective:
From the previous three Merged streams Filter Fruits which weighs more than 50 grams.
Rx Example 2

View Slide

RxJava Operator : Merge / Filter Streams
104
4
Building
Block
Objective:
From the previous three Merged streams Filter Fruits which weighs more than 50 grams.
Rx Example 2

View Slide

Rx 2 Java Operator : Merge / Filter / Sort
105
4
Building
Block
Objective:
From the previous three Merged streams Filter Fruits which weighs more than 50 grams and sort on Price (Asc).
Rx Example 2
Don’t Use
blockgingGet()
in Production
Code

View Slide

Rx 2 Java Operator: Filter / Sort / FlatMap
106
4
Building
Block
Objective:
toSortedList() returns an Observable with a single List containing Fruits.
Using FlatMap to Transform Observable to Observable
Rx Example 2

View Slide

The Problem? How Rx Helps!
107
2
Building
Block
Scenario – Three Different Data streams
1. Movie database, Movie Reviews, Movie Trivia
2. Based on the Recommendation Engine combine all the three above and
send the final result to end-user / customer.
The Problem / Rule
1. No Synchronous Calls allowed
What I need
1. Movie Suggestion based on recommendation Engine
2. Filter the suggested movies based on the User filter (Movie Ratings)
3. Once the movies are identified, combine all the other related info and
Zip (Movies, Reviews & Trivia) it into a Single Entity (Movie Titles) and
send the collection back to the caller.

View Slide

Movie Example
RxJava Operator : Filter / Sort / FlatMap
108
4
Building
Block
Objective:
toSortedList() returns an Observable with a single List containing Movies. Using
FlatMap to Transform Observable to Observable

View Slide

RxJava Operator Details
109
4
Building
Block
Creating Observables
Operators that originate new Observables.
• Create — create an Observable from scratch by calling observer methods programmatically
• Defer — do not create the Observable until the observer subscribes, and create a fresh
Observable for each observer
• Empty/Never/Throw — create Observables that have very precise and limited behavior
• From — convert some other object or data structure into an Observable
• Interval — create an Observable that emits a sequence of integers spaced by a particular
time interval
• Just — convert an object or a set of objects into an Observable that emits that or those
objects
• Range — create an Observable that emits a range of sequential integers
• Repeat — create an Observable that emits a particular item or sequence of items repeatedly
• Start — create an Observable that emits the return value of a function
• Timer — create an Observable that emits a single item after a given delay

View Slide

Rx 2 Java Operator Details
110
Creating Observables
Operators that originate new Observables.
• Create — create an Observable from scratch by calling observer methods programmatically
• Defer — do not create the Observable until the observer subscribes, and create a fresh
Observable for each observer
• Empty/Never/Throw — create Observables that have very precise and limited behavior
• From — convert some other object or data structure into an Observable
• Interval — create an Observable that emits a sequence of integers spaced by a particular
time interval
• Just — convert an object or a set of objects into an Observable that emits that or those
objects
• Range — create an Observable that emits a range of sequential integers
• Repeat — create an Observable that emits a particular item or sequence of items repeatedly
• Start — create an Observable that emits the return value of a function
• Timer — create an Observable that emits a single item after a given delay
4
Building
Block

View Slide

111
Transforming Observables
Operators that transform items that are emitted by an Observable.
• Buffer — periodically gather items from an Observable into bundles and emit these
bundles rather than emitting the items one at a time
• FlatMap — transform the items emitted by an Observable into Observables, then flatten
the emissions from those into a single Observable
• GroupBy — divide an Observable into a set of Observables that each emit a different group
of items from the original Observable, organized by key
• Map — transform the items emitted by an Observable by applying a function to each item
• Scan — apply a function to each item emitted by an Observable, sequentially, and emit
each successive value
• Window — periodically subdivide items from an Observable into Observable windows and
emit these windows rather than emitting the items one at a time
4
Building
Block

View Slide

112
Filtering Observables
Operators that selectively emit items from a source Observable.
• Debounce — only emit an item from an Observable if a particular timespan has passed without it
emitting another item
• Distinct — suppress duplicate items emitted by an Observable
• ElementAt — emit only item n emitted by an Observable
• Filter — emit only those items from an Observable that pass a predicate test
• First — emit only the first item, or the first item that meets a condition, from an Observable
• IgnoreElements — do not emit any items from an Observable but mirror its termination notification
• Last — emit only the last item emitted by an Observable
• Sample — emit the most recent item emitted by an Observable within periodic time intervals
• Skip — suppress the first n items emitted by an Observable
• SkipLast — suppress the last n items emitted by an Observable
• Take — emit only the first n items emitted by an Observable
• TakeLast — emit only the last n items emitted by an Observable
4
Building
Block

View Slide

113
Combining Observables
Operators that work with multiple source Observables to create a single Observable
• And/Then/When — combine sets of items emitted by two or more Observables by means of Pattern
and Plan intermediaries
• CombineLatest — when an item is emitted by either of two Observables, combine the latest item
emitted by each Observable via a specified function and emit items based on the results of this
function
• Join — combine items emitted by two Observables whenever an item from one Observable is
emitted during a time window defined according to an item emitted by the other Observable
• Merge — combine multiple Observables into one by merging their emissions
• StartWith — emit a specified sequence of items before beginning to emit the items from the source
Observable
• Switch — convert an Observable that emits Observables into a single Observable that emits the
items emitted by the most-recently-emitted of those Observables
• Zip — combine the emissions of multiple Observables together via a specified function and emit
single items for each combination based on the results of this function
4
Building
Block

View Slide

114
Observable Utility Operators
A toolbox of useful Operators for working with Observables
• Delay — shift the emissions from an Observable forward in time by a particular amount
• Do — register an action to take upon a variety of Observable lifecycle events
• Materialize/Dematerialize — represent both the items emitted and the notifications sent as
emitted items, or reverse this process
• ObserveOn — specify the scheduler on which an observer will observe this Observable
• Serialize — force an Observable to make serialized calls and to be well-behaved
• Subscribe — operate upon the emissions and notifications from an Observable
• SubscribeOn — specify the scheduler an Observable should use when it is subscribed to
• TimeInterval — convert an Observable that emits items into one that emits indications of the
amount of time elapsed between those emissions
• Timeout — mirror the source Observable, but issue an error notification if a particular period of
time elapses without any emitted items
• Timestamp — attach a timestamp to each item emitted by an Observable
• Using — create a disposable resource that has the same lifespan as the Observable
4
Building
Block

View Slide

115
Conditional and Boolean Operators
Operators that evaluate one or more Observables or items emitted by Observables
• All — determine whether all items emitted by an Observable meet some criteria
• Amb — given two or more source Observables, emit all of the items from only the first of these
Observables to emit an item
• Contains — determine whether an Observable emits a particular item or not
• DefaultIfEmpty — emit items from the source Observable, or a default item if the source
Observable emits nothing
• SequenceEqual — determine whether two Observables emit the same sequence of items
• SkipUntil — discard items emitted by an Observable until a second Observable emits an item
• SkipWhile — discard items emitted by an Observable until a specified condition becomes false
• TakeUntil — discard items emitted by an Observable after a second Observable emits an item or
terminates
• TakeWhile — discard items emitted by an Observable after a specified condition becomes false
4
Building
Block

View Slide

116
Mathematical and Aggregate Operators
Operators that operate on the entire sequence of items emitted by an Observable
• Average — calculates the average of numbers emitted by an Observable and emits this average
• Concat — emit the emissions from two or more Observables without interleaving them
• Count — count the number of items emitted by the source Observable and emit only this value
• Max — determine, and emit, the maximum-valued item emitted by an Observable
• Min — determine, and emit, the minimum-valued item emitted by an Observable
• Reduce — apply a function to each item emitted by an Observable, sequentially, and emit the
final value
• Sum — calculate the sum of numbers emitted by an Observable and emit this sum
Backpressure Operators
• backpressure operators — strategies for coping with Observables that produce items more
rapidly than their observers consume them
4
Building
Block

View Slide

117
Connectable Observable Operators
Specialty Observables that have more precisely-controlled subscription dynamics
• Connect — instruct a connectable Observable to begin emitting items to its subscribers
• Publish — convert an ordinary Observable into a connectable Observable
• RefCount — make a Connectable Observable behave like an ordinary Observable
• Replay — ensure that all observers see the same sequence of emitted items, even if they subscribe after the
Observable has begun emitting items
Operators to Convert Observables
• To — convert an Observable into another object or data structure
Error Handling Operators
Operators that help to recover from error notifications from an Observable
• Catch — recover from an onError notification by continuing the sequence without error
• Retry — if a source Observable sends an onError notification, re-subscribe to it in the hopes that it will
complete without error
4
Building
Block

View Slide

8/31/23
118
• onCompleted became onComplete— without the trailing d
• Func1 became Function
• Func2 became BiFunction
• CompositeSubscription became CompositeDisposable
• limit operator has been removed. Use take in RxJava 2
Rx Java 1 to Rx Java 2 Migration

View Slide

8/31/23
119
Object Method Call
import rx.Observable;
Observable.operator
Observer call(Observer)
import rx.*;
Observer
void onCompleted
Subscriber implements
Observer
Import rx.Observable;
Observerable.onSubscribe
void
call(Observer)
Observer > Subscriber
onNext()
onCompleted()
onError()
-
isUnSubscribed()
Object Method Call
import io.reactivex.*;
ObservableOperator
Subscriber apply(Subscriber)
Observer
void onComplete
No Subscriber Class in v2.0
Import io.reactivex.*
ObservableOnSubscriber
Void
subscribe(ObservableEmitter)
throws Exception
Emitter > ObservableEmitter
onNext()
onComplete()
onError()
-
IsDisposed()
Rx Java 1.0 Package = rx.* Rx Java 2.0 Package = io.reactivex.*
http://reactivex.io/RxJava/1.x/javadoc/ http://reactivex.io/RxJava/2.x/javadoc/
This is not a comprehensive list, but a most used list.

View Slide

8/31/23
120
Object Method Call
import rx.functions.*;
Func1
T call(T)
import rx.Observable; Observable filter(Func1)
Observable Observable first()
Observable flatMap(Func1)
void forEach(Action1)
Observable from(Future)
Observable from(Iterable)
Observable from(Array)
Observable(GroupedObservable)
groubBy(Func1)
Observable
groupJoin(Observable)
Object Method Call
io.reactivex.functions.*;
Function1
T apply(T)
import io.reactivex.*; Observable filter(Predicate)
Observable Single first()
Observable flatMap(Function)
Disposable forEach(Consumer)
Observable fromFuture(Future)
Observable fromIterable(Iterable)
Observable fromArray(Array)
Observable(GroupedObservable)
groubBy(Function)
Observable
groupJoin(ObservableSource)

View Slide

8/31/23
121
Object Method Call
import rx.Observable;
Observable
Observable
Join(Observable, Func1)
Observable
all(Func1)
Observable
amb(Observable….)
asObservable()
Observable
collect(Func0, Action2)
Observable
contact(Observable)
Observable
concatMap(Func1)
Observable contains()
Object Method Call
Observable
Observable
Join(ObservableSource, Function)
Single
all(Predicate)
Observable
amb(Iterable)
Single
collect(java.util.concurrent.Callable)
Observable
concat(ObservableSource)
Observable
concatMap(Function)
Single contains()

View Slide

8/31/23
122
Object Method Call
import rx.Observable; Observable countLong()
Observable static Observable
create(Action1,
Emitter.backpressure)
static Observable create(-----)
Observable debounce(Func1)
Observable distinct(Func1)
Observable exists(Func1)
Observable first()
Object Method Call
Observable
static Observable
create(ObservableOnSubscriber)
Observable debounce(Function)
Observable distinct(Function)
Single first(T)

View Slide

4
Spring WebFlux
o SpringBoot MVC
o Spring MVC and WebFlux
o Servlet and Reactive Life Cycle
o Comparison
123

View Slide

SpringBoot WebFlux
124

View Slide

Springboot MVC
125
Spring Boot MVC is an extension of the Spring framework that simplifies
the development of web applications by using the Model-View-Controller
(MVC) design pattern. It provides features like dependency injection, data
binding, and application-layer frameworks integrated through the Spring
framework.
Key Features
• Annotation-based Configuration: Simplifies the setup of the application.
• Built-in Tomcat, Jetty, or Undertow Servers: No need to deploy WAR
files.
• Data Binding: Maps client-side values to server-side models.
• Thymeleaf, JSP, and More: Allows multiple view technologies.

View Slide

Springboot MVC: How it works?
126
1. Controller: Handles incoming
requests. Annotated with
@Controller.
2. View: The user interface is
usually written in Thymeleaf,
JSP, or Angular / React-based
frontends.
3. Model: Represents
application data. Populated
by the controller and
accessed by the view.
Use Cases
• Ideal for form-based applications and template-
based HTML views.
• Suitable for applications that require a tightly
integrated backend, where there is direct data
manipulation.

View Slide

SpringBoot MVC
127
Controller
@RestController
Service
@Service
Repository
@Repository
Model
@Entity
Data
Store
Firewall
Users
DTO
@Autowired
Service …
@Autowired
Repository …
Dependency
Injection
Form of IoC

View Slide

SpringBoot MVC
128
Controller
@RestController
Service
@Service
Repository
@Repository
Model
@Entity
Data
Store
Firewall
Users
DTO
@Autowired
Service …
@Autowired
Repository …
Dependency
Injection
Form of IoC
Dispatcher
Servlet
Handler
Mapping

View Slide

Springboot WebFlux
129
Spring Boot WebFlux is a reactive-stack web framework, part of the
Spring 5+ ecosystem, fully non-blocking, and supports Reactive
stream back pressure. It's designed to handle many simultaneous,
high-latency I/O operations with minimal threads.
Key Features
• Reactive Programming: Utilizes Project Reactor for reactive
programming.
• Back-Pressure: Manages resource consumption rates.
• Non-blocking: Doesn't block threads, leading to better resource
utilization.

View Slide

Springboot WebFlux: How it works?
130
1. Handler: Similar to controllers
but designed for reactive
programming. Annotated with
@RestController.
2. Router: Maps requests to
handlers. Can be Java or Kotlin.
3. Reactive Streams: Utilizes
publishers (Flux, Mono) for
data emission.
Use Cases
• Suited for applications that require a high degree of scalability.
• Suitable for real-time event processing, like chat applications or real-time notifications.

View Slide

Springboot WebFlux: How it works?
131
Instead of @RestController
• .route(RequestPredicates.GET("/hello"): Specifies that
the route is for GET requests with the path /hello.
• .and(RequestPredicates.accept(MediaType.TEXT_PLAIN
)): Adds another condition that the accepted media
type should be text/plain.
• myHandler::sayHello: Specifies that the sayHello
method from MyHandler will handle the request.
• RouterFunction: Responsible for providing
routing information. It tells the application
which handler function needs to be executed
for a particular URL pattern.
• ServerResponse and ServerRequest: These are
abstractions over HTTP request and response
models. They offer a more functional way to
deal with HTTP requests and responses.
• RequestPredicates: These are used to match
HTTP requests based on various conditions like
HTTP method, URL, headers, etc.
• Mono and Flux: These are Reactor types used
for asynchronous programming. In the above
example, Mono is used, which means zero or
one element could be returned.

View Slide

WebFlux Internals
132
The responsibility of handling and routing requests in Spring WebFlux is mainly
undertaken by several different components working together:
1. HttpHandler: This is the basic interface that any reactive server must implement to
handle HTTP requests. It's similar to the Servlet API's Servlet interface.
2. WebHandler: This is a specialization of HttpHandler used by Spring's
WebHttpHandlerBuilder and provides a convenient way to build a composite
HttpHandler with several customizations and configurations.
3. RouterFunction: This function takes a request and returns a HandlerFunction wrapped
in a Mono. It's used for functional-style routing, an alternative to the annotation-
based controller model.
4. HandlerFunction: This function handles a request and produces a response. It's similar
to a controller method in Spring MVC.
5. WebFilter: This is similar to a Filter in the Servlet API. It's a function that can intercept
and modify incoming requests and outgoing responses.

View Slide

Spring MVC Vs WebFlux
133
SpringBoot MVC SpringBoot WebFlux

View Slide

Spring MVC vs. WebFlux
134
Aspect Spring Boot MVC Spring Boot WebFlux
Programming
Model
Synchronous Asynchronous
Throughput Lower Higher
Complexity Lower Higher
Learning Curve Easier Steeper
Ecosystem Mature Emerging

View Slide

Servlet and Reactive – Life Cycle
135
1 A request is made by the client. A request is made by the client.
2
The Servlet container creates
HttpServletRequest and
HttpServletResponse objects.
The Reactor Netty (default server used by WebFlux)
creates ServerRequest and
ServerResponse objects.
3
A separate thread is assigned to this request-
response pair and the control is passed to the
appropriate Servlet
The control is passed to the appropriate handler function
without assigning a separate thread to this request-
response pair.
4
The Servlet processes the request (which
may involve calling various services,
accessing a database, etc.), populates the
HttpServletResponse object and returns
control back to the Servlet container.
The handler function processes the request in a non-
blocking manner. This may involve calling various
services, accessing a database, etc. While the process is
waiting for the results (for instance, from a database), the
thread is not blocked and can be used to handle other
requests.
5
The Servlet container sends the response
back to the client and the thread is released.
Once the results are available, they are populated in the
ServerResponse object and returned back.
6 The Reactor Netty sends the response back to the client.

View Slide

Comparison
136
1
Concurrency
Model:
The Servlet API uses a blocking I/O model,
meaning each request is handled by a
dedicated thread until it's completed.
Reactive Streams, on the other hand, employ
a non-blocking I/O model where threads can
handle other requests when idle.
2
Resource
Utilization
With Servlet API, under heavy load, you
might end up exhausting all system
resources since each request demands a
separate thread.
Reactive Streams are more efficient in
resource utilization as they allow more
requests to be handled concurrently using
fewer threads.
3 Backpressure
The Servlet API does not have a built-in
mechanism for back pressure.
Reactive Streams allow for backpressure,
meaning the consumer can control how much
data it can handle, preventing it from being
overwhelmed.
4 API Design:
The Servlet API is based on a synchronous
and imperative style of programming,
which is easy to understand but can lead
to callback hell in complex applications.
Reactive Streams (like Spring WebFlux)
support a declarative style of programming
using Functional Programming principles,
leading to cleaner and more maintainable
code.

View Slide

Demo and Code Review
o SpringBoot WebFlux
o Controllers, Routers, Services, Repositories
o Exception Handling
o Web Filters
137
Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

View Slide

RestController – Exception from Service
138
Success Message Failure Message
http://localhost:9092/ms-webflux/api/v1/country/id/356
Reactive Controller
Returning a Mono with
Standard Response.
Exception from the
Service is propagated to
the Global Exception
Handler.
Standard Response
1. Time
2. Success Status
3. Error Code
4. Message
5. Payload
Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

View Slide

RestController – Exception from Controller
139
http://localhost:9092/ms-webflux/api/v1/country/code/ARG
Reactive Controller
Returning a Mono with
Standard Response.
Rest Controller is
throwing the Business
Service Exception if the
Result is Empty.
Standard Response
1. Time
2. Success Status
3. Error Code
4. Message
5. Payload

View Slide

Router (instead of Rest Controller)
140
http://localhost:9092/ms-webflux/api/v1/cart/customer/123
Cart Handler
Router
In Spring WebFlux, a router
function is generally expected
to return a
Mono.
This is not because of any
limitation in returning a Flux but
because the router function is
supposed to produce a single
ServerResponse object to
handle the HTTP request.
The Mono
encapsulates the HTTP
response, including the status
code, headers, and body. If you
want the body of the HTTP
response to contain a stream of
values (e.g., a JSON array), then
that stream should be a Flux
and wrapped inside the
ServerResponse object.

View Slide

Router / Handlers – Exceptions
141
In Spring WebFlux, the distinction between routers and handlers is designed to separate concerns. Handlers are responsible
for business logic, and it is there that exceptions would naturally occur. They handle the request and generate the response,
so they handle all the intricacies that may include errors or exceptions. On the other hand, Routers are concerned solely with
routing: they determine which handler should handle a given request based on URL patterns, HTTP methods, and other
request criteria.

View Slide

Service Layer
142

View Slide

Repository Layer
143

View Slide

Streaming Data
o Server-Side Events in WebFlux
o Web Sockets
144

View Slide

Server-Side Streaming Events
o Uni-Directional
145

View Slide

Server-Side Events – Streaming Data
146
3 Seconds
Delayed &
Random
Errors

View Slide

Server-Side Events: Result
147

View Slide

How Server-Side Events (SSE) Work?
148
1. Initiation: The client (a web application or a mobile app) requests an HTTP GET to a
specific URL on the server. The request asks for a particular MIME type, usually
text/event-stream.
2. Server Response: The server accepts the request and opens a stream, keeping the
connection open. The server can then push data to the client whenever it has new
information to share.
3. Data Format: The data is sent as plain text in a specific format that the client can
interpret. Typically, each message is separated by a pair of newline characters.
4. Client Handling: On the client side, the EventSource JavaScript API or corresponding
mobile libraries handle incoming data. Event listeners can be attached to process the
data.
5. Unidirectional: SSE is unidirectional; the server sends data to the client, but the client
cannot send data back through the same connection. If the client needs to send data to
the server, it would use regular AJAX requests or other mechanisms.

View Slide

Server-Side Events – Streaming Data
149
o When streaming data using protocols like Server-Sent Events (as
you are doing with MediaType.TEXT_EVENT_STREAM_VALUE), the
HTTP status code is sent only once at the beginning of the
connection. The individual items in the stream do not contain HTTP
status codes.
o The client initially makes a request and receives an HTTP status
code that indicates the success or failure of that initial request. If
the initial request is successful (typically returning a 200 OK status),
the server will keep the connection open and stream data as a
series of "events."
o Each Event will NOT have its own HTTP status code.

View Slide

WebSocket
o Multi-Directional
o Plain Text and Binary Data
150

View Slide

Web Socket Configuration
151

View Slide

Web Socket – Streaming Data
152

View Slide

Web Socket Result
153

View Slide

How Web Sockets work?
154
1. Initiation: A standard HTTP request is upgraded using the Upgrade
header to a WebSocket connection.
2. Bidirectional: Unlike SSE, WebSockets provide a full-duplex
communication channel. Both client and server can send data to
each other at any time.
3. Data Format: The data can be sent as plain text or binary.
4. Client Handling: The WebSocket API in JavaScript or equivalent
libraries in mobile apps are used to handle data.
5. More Features: WebSockets support more features like framing,
ping/pong control messages, etc.

View Slide

Web Sockets
155
WebSocket protocol provides full-duplex communication channels over a single, long-lived TCP
connection. It is designed to be implemented in client-side web browsers and server-side
applications to enable real-time applications like chat, notifications, and collaborative editing. Here
are some key features:
Framing:
WebSocket data is transmitted in frames, each consisting of a header and payload. The header
contains metadata about the frame, like opcode (defines the frame type), a payload length
indicator, and optional masking information. This structure allows more efficient data transfer and
better control over the transmission.
• Continuation Frame: To send payloads that exceed the frame size, continuation frames can be
used. A message is fragmented into multiple frames, and continuation frames carry the payload
in ordered parts.
• Text and Binary Frame: WebSocket supports text and binary data frames. The opcode in the
frame header differentiates between the two.
• Control Frames: These are frames with opcodes that dictate control messages for connection
management, such as close, ping, and pong frames.

View Slide

Web Sockets
156
Ping/Pong Control Messages:
Ping/Pong frames are control frames that serve as "heartbeats" for the connection.
• Ping: When a server or client sends a ping frame, it asks for a quick response to
confirm that the other end is still available. The ping frame can contain optional
application data.
• Pong: A pong frame is sent in response to a ping frame, ideally containing the
same data as the ping frame. This mechanism allows either end to check the
"liveness" of the connection.
Connection Close:
WebSocket has a closing handshake that allows the client and server to close the
connection gracefully. The client or server initiates a “Close” control frame, and the
receiving end is expected to reply with another "Close" frame. Once the closing
handshake is completed, the connection is terminated.

View Slide

Web Sockets
157
Masking:
In client-to-server communication, WebSocket protocol mandates the data to be
masked for security reasons. This is intended to prevent specific security
vulnerabilities related to "cache poisoning" in network infrastructure.
Multiplexing:
Although not part of the initial WebSocket standard, there's an extension that
allows for multiplexing—multiple logical channels over a single WebSocket
connection. This is useful for more complex applications that require separate
channels for different types of data.
Compression:
WebSocket allows for payload compression through the per-message compression
extension. This helps reduce the amount of data transferred over the network.

View Slide

Filters and Exception Handling
o Web Filters
o Exception Handling
o Standard Response
158

View Slide

Web Filter
159

View Slide

Exception Handling
160

View Slide

Exception Handling
161

View Slide

Debugging Reactive Programming
o Log Messages
o Checkpoints
o doOn…
Hooks
162

View Slide

Debugging Options
163
1. Reactor Debug Agent: This helps to track the original stack trace elements and gives
more meaningful information about errors. This is initialized at the start of the
application with ReactorDebugAgent.init().
2. BlockHound: This Java agent detects blocking calls from non-blocking threads and
throws an exception. While not exclusively a debugging tool for reactive pipelines, it's
beneficial for maintaining the integrity of your reactive system. It helps you spot where
you inadvertently introduce blocking behavior in your code.
3. Custom doOn Operators: Reactor provides a host of doOn methods like doOnNext,
doOnError, doOnTerminate, etc., where you can insert custom logic, such as logging or
incrementing metrics counters.
4. Using Hooks: Reactor provides an API to register custom logic that will be executed on
certain events like onNext, onError, onSubscribe, etc., using the Hooks class.
5. Testing: Frameworks like StepVerifier allow you to write unit tests for your reactive
pipelines. This can be very helpful for debugging and isolating issues in a controlled
environment.

View Slide

Debugging Options
164
6. Profiler Tools: Profiling can be helpful in identifying resource leaks or
performance bottlenecks in your reactive pipelines.
7. R2DBC Debug Logging: If you use R2DBC for reactive database access, enabling
debug logging can provide insights into SQL queries and database transactions.
8. Metrics: Libraries like Micrometer can provide runtime metrics which can be
helpful in debugging performance and behaviour issues.
9. Distributed Tracing: Tools like Zipkin or Jaeger can be used to trace the request
flow across various microservices, which can be helpful in debugging issues in a
more extensive, distributed system.
10. Visual Debugging: Some IDEs offer visual tools to debug reactive streams,
which can be more intuitive for some developers.

View Slide

Checkpoints
o Logs and Checkpoints
o Conditional Checkpoints
165

View Slide

Checkpoint – Stack Traces & Logging
166
The concept of "Checkpoints" in Project Reactor is a debugging feature that helps you to identify
issues in a reactive stream. A checkpoint acts like a marker or a tag in the reactive chain, capturing
the state and context of the stream at that specific point. When an error occurs downstream, these
checkpoints are included in the stack trace, making it easier to debug issues.

View Slide

167

View Slide

168

View Slide

Reactive Request and Error
169
http://localhost:9092/ms-webflux/api/v1/country/code/FRA1

View Slide

Checkpoint - Stack Traces
170

View Slide

Conditional Checkpoints
171
Checkpoints can be enabled conditionally based on a property flag. Using ”transform,” the conditional flag can
be checked and enable checkpoints.

View Slide

Conditional Checkpoints
172
Stack Trace with
Checkpoints disabled
and logs removed.
Stack Trace with
Checkpoints enabled
and logs removed.

View Slide

doOn….
o doOnNext
o doOnError
o doOnComplete
o doOnTerminate
o doOnEach
173

View Slide

doOnNext – More Logs
174

View Slide

doOnError – More Logs
175

View Slide

doOnComplete – More Logs
176

View Slide

doOnTerminate – More Logs
177

View Slide

doOnEach – More Logs
178

View Slide

Hooks
179

View Slide

Hooks
180

View Slide

Design Patterns are
solutions to general
problems that
software developers
faced during software
development.
Design Patterns

View Slide

DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid :
India: +91.999.545.8627
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
https://www.youtube.com/user/arafkarsh/playlists
http://www.arafkarsh.com/
@arafkarsh
arafkarsh

View Slide

Source Code: https://github.com/arafkarsh Web Site: https://arafkarsh.com/ https://pyxida.cloud/

View Slide

http://www.slideshare.net/arafkarsh

View Slide

References
185
1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas
2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google
3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head
4. Feb 17, 2019 - Lean vs Agile vs Design Thinking
5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban
6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained.
Agile Methodologies

View Slide

References
186
1. Vmware: What is Cloud Architecture?
2. Redhat: What is Cloud Architecture?
3. Cloud Computing Architecture
4. Cloud Adoption Essentials:
5. Google: Hybrid and Multi Cloud
6. IBM: Hybrid Cloud Architecture Intro
7. IBM: Hybrid Cloud Architecture: Part 1
8. IBM: Hybrid Cloud Architecture: Part 2
9. Cloud Computing Basics: IaaS, PaaS, SaaS
1. IBM: IaaS Explained
2. IBM: PaaS Explained
3. IBM: SaaS Explained
4. IBM: FaaS Explained
5. IBM: What is Hypervisor?
Cloud Architecture

View Slide

References
187
Microservices
1. Microservices Definition by Martin Fowler
2. When to use Microservices By Martin Fowler
3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler
4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern
5. Thought Works: Microservices in a Nutshell
6. Microservices Prerequisites
7. What do you mean by Event Driven?
8. Understanding Event Driven Design Patterns for Microservices

View Slide

References – Microservices – Videos
188
1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s
2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg
3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans
4. GOTO 2015 – Challenges Implementing Micro Services By Fred George
5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer
6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith
7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k
8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans
9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney
10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016
11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles
12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan
13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup.
14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant
15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula
16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford.
17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

View Slide

References
189
1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans
2. Mar 19, 2013 Domain Driven Design By Eric Evans
3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World
4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard
5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke
6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson
7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune
8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans
9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans
10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

View Slide

References
190
1. IBM: Event Driven Architecture – Mar 21, 2021
2. Martin Fowler: Event Driven Architecture – GOTO 2017
3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016
4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young
5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS
6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler
7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

View Slide

References
191
Kafka
1. Understanding Kafka
2. Understanding RabbitMQ
3. IBM: Apache Kafka – Sept 18, 2020
4. Confluent: Apache Kafka Fundamentals – April 25, 2020
5. Confluent: How Kafka Works – Aug 25, 2020
6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020
7. Kafka Streams – Sept 4, 2021
8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018
9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

View Slide

References
192
Databases: Big Data / Cloud Databases
1. Google: How to Choose the right database?
2. AWS: Choosing the right Database
3. IBM: NoSQL Vs. SQL
4. A Guide to NoSQL Databases
5. How does NoSQL Databases Work?
6. What is Better? SQL or NoSQL?
7. What is DBaaS?
8. NoSQL Concepts
9. Key Value Databases
10. Document Databases
11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends
12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012
13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB
14. Oct 30, 2020 - Column vs Row Oriented Databases Explained
15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained!
1. Graph Databases
2. Column Databases
3. Row Vs. Column Oriented Databases
4. Database Indexing Explained
5. MongoDB Indexing
6. AWS: DynamoDB Global Indexing
7. AWS: DynamoDB Local Indexing
8. Google Cloud Spanner
9. AWS: DynamoDB Design Patterns
10. Cloud Provider Database Comparisons
11. CockroachDB: When to use a Cloud DB?

View Slide

References
193
Docker / Kubernetes / Istio
1. IBM: Virtual Machines and Containers
2. IBM: What is a Hypervisor?
3. IBM: Docker Vs. Kubernetes
4. IBM: Containerization Explained
5. IBM: Kubernetes Explained
6. IBM: Kubernetes Ingress in 5 Minutes
7. Microsoft: How Service Mesh works in Kubernetes
8. IBM: Istio Service Mesh Explained
9. IBM: Kubernetes and OpenShift
10. IBM: Kubernetes Operators
11. 10 Consideration for Kubernetes Deployments
Istio – Metrics
1. Istio – Metrics
2. Monitoring Istio Mesh with Grafana
3. Visualize your Istio Service Mesh
4. Security and Monitoring with Istio
5. Observing Services using Prometheus, Grafana, Kiali
6. Istio Cookbook: Kiali Recipe
7. Kubernetes: Open Telemetry
8. Open Telemetry
9. How Prometheus works
10. IBM: Observability vs. Monitoring

View Slide

References
194
1. Feb 6, 2020 – An introduction to TDD
2. Aug 14, 2019 – Component Software Testing
3. May 30, 2020 – What is Component Testing?
4. Apr 23, 2013 – Component Test By Martin Fowler
5. Jan 12, 2011 – Contract Testing By Martin Fowler
6. Jan 16, 2018 – Integration Testing By Martin Fowler
7. Testing Strategies in Microservices Architecture
8. Practical Test Pyramid By Ham Vocke
Testing – TDD / BDD

View Slide

1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and
most of the important components are plug- gable.
2. Pumba : A chaos testing and network emulation tool for Docker.
3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH-
managed environment, as an aid to resilience testing of high-availability systems.
4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours.
5. Blockade : Docker-based utility for testing network failures and partitions in distributed
applications.
6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server.
7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an
OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift
components like Pods or Deployment Configs and randomly terminates them.
8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS
deployed to an Azure Resource Manager-based resource group.
9. Tugbot : Testing in Production (TiP) framework for Docker.
Testing tools

View Slide

References
196
CI / CD
1. What is Continuous Integration?
2. What is Continuous Delivery?
3. CI / CD Pipeline
4. What is CI / CD Pipeline?
5. CI / CD Explained
6. CI / CD Pipeline using Java Example Part 1
7. CI / CD Pipeline using Ansible Part 2
8. Declarative Pipeline vs Scripted Pipeline
9. Complete Jenkins Pipeline Tutorial
10. Common Pipeline Mistakes
11. CI / CD for a Docker Application

View Slide

References
197
DevOps
1. IBM: What is DevOps?
2. IBM: Cloud Native DevOps Explained
3. IBM: Application Transformation
4. IBM: Virtualization Explained
5. What is DevOps? Easy Way
6. DevOps?! How to become a DevOps Engineer???
7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg
8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM
9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE
11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU
12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

View Slide

References
198
1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014.
2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015.
3. Newman, Sam. Building Microservices. O’Reilly Media, 2015.
4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015.
5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014.
6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014.
7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015.
8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012.
9. Zuul Edge Server, Ketan Gote, May 22, 2017
10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017
11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017
12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017
13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016
14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016
15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

View Slide

References
199
16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx
17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/
19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs
20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer
21. CQS : http://en.wikipedia.org/wiki/Command–query_separation
22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem
23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
24. CAP 12 years how the rules have changed
25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices
26. Pat Helland (Amazon) : Life beyond distributed transactions
27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw
28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem
29. Rx Observable : https://dzone.com/articles/using-rx-java-observable

View Slide

Java Threads Rx Java Spring WebFlux WebSockets

Java Threads Rx Java Spring WebFlux WebSockets

Araf Karsh Hamid

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript