7.6.1: Chapter 7

Overview

• Chapter: 7 — Distributed Objects and Web Services
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Comparison Table, Conceptual Illustration, Network Diagram

Figure 7.1.1

Title: RPC Communication Model

Detailed Caption: Two large process frames sit side by side on a pale gray backdrop — a navy-bordered "Client Process" on the left and an identical "Server Process" on the right. Inside each frame, three stacked tiles trace the call path: navy "Client Application" / "Server Implementation" at the top, teal "Client Stub" / "Server Skeleton" in the middle, and gray "Network Interface" at the bottom. A horizontal "Network" channel runs across the bottom of the figure, with two dashed arrows showing the request crossing left-to-right and the response returning right-to-left. Five warm-gold pill labels number the steps in order: 1. Call Stub, 2. Marshal Params, 3. Transmit Message, 4. Unmarshal & Invoke, and 5. Result Returned (reverse). By making the marshalling, transmission, and unmarshalling steps explicit, the figure reveals what the "transparent" RPC abstraction is actually doing — students can see exactly where serialization, network latency, and security boundaries live, instead of assuming a remote call behaves like a local one.

Figure 7.1.2

Title: Java RMI Layered Architecture

Detailed Caption: Two parallel three-layer towers face each other across a center channel under headers "Client Side" and "Server Side." Each tower stacks, top to bottom: a light-gray application tile (Client Application / Remote Object Implementation), a teal Layer 1 tile (Stub (Proxy) on the left, Skeleton (Dispatcher) on the right), a gray Layer 2 "Remote Reference Layer," and a navy Layer 3 "Transport Layer," all connected by downward arrows. A bidirectional double-headed arrow at the bottom labeled "TCP/IP Network (JRMP)" links the two transport boxes. Floating between the two towers near the top, a gold-bordered "RMI Registry" tile is wired by dashed lines to the Stub via lookup() and to the Skeleton via bind(), capturing the publish/lookup pattern. The figure makes vivid why RMI feels so different from a plain method call: the layered descent through stub, reference, and transport on each side is exactly the cost of remoting, and the registry off to the side is the rendezvous point that lets clients discover servers without hard-coded addresses.

Figure 7.1.3

Title: CORBA Architecture Overview

Detailed Caption: A wide navy bar labeled "ORB (Object Request Broker)" runs horizontally across the middle of the figure with a gray "IIOP (Internet Inter-ORB Protocol)" bar beneath it. Above the ORB, four columns of components feed into it via downward arrows: on the left a navy "Client" connects through a teal "IDL Stub"; in the center a light-gray "ORB Interface" sits standalone; on the right a navy "Servant (Object Implementation)" feeds a teal "IDL Skeleton" with a gray "Portable Object Adapter (POA)" attached to its right; the POA also bridges into the ORB. Off to the lower-left, a gold-bordered "Naming Service" tile is wired to both the Client (dashed "resolve()" line) and the ORB ("register" line), capturing the lookup workflow. By placing the ORB as a single backbone running underneath every CORBA component, the figure communicates the architecture's defining trade-off: every request flows through the broker, which is what makes language- and platform-independent calls possible but also what made CORBA notoriously heavy compared to lighter web protocols.

Figure 7.2.1

Title: SOAP Web Services Publish-Find-Bind Model

Detailed Caption: Three large rounded actor tiles form a triangular layout — a warm-gold "Service Registry (UDDI)" at the apex, a navy "Service Provider" at the bottom-left, and a teal "Service Consumer" at the bottom-right — with three labeled arrows tracing the publish-find-bind workflow. Arrow 1 ("Publish — WSDL") rises from the Provider to the Registry next to a small document glyph; arrow 2 ("Find — Query UDDI") rises from the Consumer to the Registry next to a magnifier glyph; and arrow 3 ("Bind — SOAP Messages") runs horizontally from the Consumer back across to the Provider with an envelope glyph. Below the triangle, a small framed code block shows the SOAP envelope structure as <Envelope> containing <Header> and <Body> tags. The figure makes vivid that SOAP web services are not just a wire format but a three-role choreography: the registry's job is matchmaking, and once that's done the consumer talks directly to the provider, which is why understanding the triangle is essential to reasoning about discovery, versioning, and outages in legacy enterprise stacks.

Figure 7.2.2

Title: SOAP vs. REST Comparison

Detailed Caption: A three-column table sits beneath color-coded headers — gold "Dimension" labels on the left, navy "SOAP" in the center, and teal "REST" on the right — with eight alternating-shaded rows: Protocol (XML-based protocol vs. Architectural style using HTTP), Data Format (XML only vs. JSON, XML, others), Interface Definition (WSDL vs. OpenAPI / Swagger, or none), Statefulness (Can be stateful or stateless vs. Stateless by design), Caching (Not natively cacheable vs. HTTP caching supported), Message Size (Larger, verbose XML envelope vs. Smaller, lightweight JSON), Security (WS-Security built-in vs. HTTPS/TLS, OAuth), and Typical Use Cases (Enterprise, banking, legacy vs. Public APIs, mobile, cloud-native). Each cell carries a single concise phrase so the entire table is scannable in one read. The matrix collapses paragraphs of contrast into a one-page reference and makes the practical implication clear: SOAP wins where contracts and compliance dominate, REST wins where speed-to-integration and HTTP infrastructure (caches, CDNs, browsers) carry the architecture.

Figure 7.4.1

Title: Client-Side vs. Server-Side Service Discovery

Detailed Caption: A vertical dashed divider splits the figure into two side-by-side patterns. On the left, "Client-Side Discovery" shows a navy Service Consumer issuing arrow "1. Query" to a gold Service Registry, receiving "2. Instance list" back, then drawing "3. Direct call" arrows downward to a column of three teal Service Instance tiles below it. On the right, "Server-Side Discovery" inserts a gray Load Balancer between the navy Service Consumer and the three teal Service Instances; the consumer sends "1. Request" to the load balancer, which fires "2. Query" up to a gold Service Registry on the right, then "3. Forward" arrows down to a single chosen Service Instance. By keeping the registry and instance topology visually identical and varying only where the discovery logic lives, the figure isolates the architectural choice cleanly: in client-side discovery the consumer carries lookup logic and gains protocol flexibility; in server-side discovery a network appliance owns lookup and consumers stay simple at the cost of an extra network hop.

Figure 7.4.2

Title: Circuit Breaker Pattern State Diagram

Detailed Caption: Three large rounded state tiles form a triangle: a teal CLOSED state at the upper-left ("Normal Operation — Requests pass through," with an inset "Monitors failure count" pill), a navy OPEN state at the upper-right ("Failing Fast — Requests blocked immediately"), and a warm-gold HALF-OPEN state at the bottom-center ("Testing Recovery — Limited requests allowed"). Four curved transition arrows wire them together with labeled triggers: CLOSED → OPEN on "Failure threshold exceeded," OPEN → HALF-OPEN on "Timeout period expires," HALF-OPEN → CLOSED on "Test requests succeed," and HALF-OPEN → OPEN on "Test requests fail." The state-machine layout makes the temporal contract explicit — the breaker isn't a switch but a policy with hysteresis, and rendering the four labeled transitions side by side helps students see why a circuit breaker prevents cascading failures: it stops calling a downstream service the moment errors spike and only resumes traffic gradually after evidence of recovery.

Figure 7.5.1

Title: Evolution from Distributed Objects to Modern Cloud APIs

Detailed Caption: A horizontal arrow runs left to right across the figure, punctuated by seven labeled milestone tiles whose colors trace the technological generation: gray "RPC (1980s)," gray "CORBA (early 1990s)" (offset below), gray "Java RMI / DCOM (mid-1990s)," teal "SOAP / WSDL / UDDI (late 1990s–2000s)" (below), teal "REST / JSON (2000s–2010s)," navy "gRPC / OpenAPI (2015+)" (below), and warm-gold "API-First Platforms (AWS, Google, Twilio)." Two horizontal brackets beneath the timeline group the milestones into two named eras — "Distributed Objects Era" spanning RPC through Java RMI/DCOM, and "Web Services Era" spanning SOAP through API-First Platforms. The deliberate color rotation (gray → teal → navy → gold) gives the visual a generational cadence and supports the chapter's synthesis: today's cloud API platforms didn't appear from nowhere; they are the latest and most ergonomic expression of a forty-year continuum that began with stub-based RPC and accumulated lessons through CORBA's heaviness, SOAP's contracts, and REST's web-native simplicity.