Yours

7.9: Assessments

Introduction to Cloud Computing · LibreTexts

0%

Contents

    Text

    Size
    100%
    Theme
    Typeface
    Line length
    Spacing

    From LibreTexts, under CC BY 4.0, as the source states it; its equations are written in TeX, which the PDF shows typeset. This page at LibreTexts.

    Learning Objectives

    After completing this chapter, students will be able to:

    1. Explain the evolution from distributed objects (CORBA, RMI) to modern web services.
    2. Compare SOAP and REST web service architectures, including their strengths and trade-offs.
    3. Describe RESTful API design principles based on Roy Fielding's architectural constraints.
    4. Define ACID transaction properties and their challenges in distributed systems.
    5. Analyze how modern web service patterns support cloud-native application development.
    6. Evaluate real-world implementations of distributed object and web service technologies.
    7. Apply web service design principles to create well-structured API interfaces.

    Key Terms and Definitions

    Match each term (1–15) with the correct definition (A–O).

    Key Terms
    # Term
    1 CORBA
    2 Remote Procedure Call (RPC)
    3 SOAP
    4 REST
    5 API
    6 WSDL
    7 JSON
    8 HTTP Methods
    9 Statelessness
    10 ACID
    11 Idempotency
    12 gRPC
    13 Endpoint
    14 Service Registry
    15 Middleware
    Letter Definition
    A An architectural style using standard HTTP methods and URIs to interact with resources in a stateless manner.
    B A protocol for exchanging structured information using XML messages, typically over HTTP.
    C A standard for distributed object computing that enables communication between programs written in different languages.
    D A mechanism enabling a program to execute a procedure on a remote server as if it were a local call.
    E A set of definitions and protocols that allows software components to communicate with each other.
    F An XML-based language describing the interface and operations of a web service.
    G A lightweight data interchange format using key-value pairs, widely used in REST APIs.
    H Standard operations (GET, POST, PUT, DELETE) used to perform actions on web resources.
    I A constraint requiring each request to contain all information needed to process it, with no stored session state.
    J Properties ensuring database transactions are Atomic, Consistent, Isolated, and Durable.
    K The property where performing an operation multiple times produces the same result as performing it once.
    L A high-performance, open-source RPC framework developed by Google using Protocol Buffers.
    M A specific URL where a web service or API can be accessed by a client application.
    N A directory that maintains a list of available services and their network locations for discovery.
    O Software that sits between applications and the operating system, providing communication and data management services.

    Answer Key: 1-C, 2-D, 3-B, 4-A, 5-E, 6-F, 7-G, 8-H, 9-I, 10-J, 11-K, 12-L, 13-M, 14-N, 15-O

    Review Questions

    Multiple Choice

    1. Which technology preceded modern web services as a standard for distributed object communication across different programming languages?
      • a) REST
      • b) CORBA
      • c) JSON
      • d) Docker
    2. In REST architecture, which HTTP method is used to retrieve a resource without modifying it?
      • a) POST
      • b) PUT
      • c) GET
      • d) DELETE
    3. Which of the following is a property of ACID transactions?
      • a) Asynchronous — transactions execute in the background
      • b) Atomic — a transaction either fully completes or fully rolls back
      • c) Available — transactions are always accepted regardless of system state
      • d) Adaptive — transactions adjust to network conditions

    Short Answer

    1. Compare SOAP and REST web services across at least four dimensions (e.g., message format, protocol, statefulness, complexity, use cases). When would you choose SOAP over REST?
    2. Explain Roy Fielding's key architectural constraints for REST. Why does the statelessness constraint improve scalability in cloud environments?
    3. What are the four ACID properties? Explain why maintaining ACID guarantees is particularly challenging in distributed systems. How does this relate to the CAP theorem from Chapter 2?
    4. Describe how CORBA attempted to solve the problem of distributed computing. What were its limitations, and why did web services (SOAP and REST) eventually replace it as the dominant approach?

    True/False

    1. True or False: REST APIs must always use JSON as their data format.
    2. True or False: SOAP provides built-in standards for security (WS-Security) and reliable messaging that REST does not have natively.
    3. True or False: An idempotent API operation produces different results each time it is called with the same parameters.

    Answer Key:

    1. b
    2. c
    3. b
    4. SOAP: XML only, protocol-agnostic (HTTP/SMTP/JMS), stateful possible, built-in WS-* standards, complex. REST: JSON/XML/others, HTTP only, stateless, simpler, lightweight. SOAP preferred for: enterprise integration requiring formal contracts, transactions, security standards (e.g., banking, healthcare).
    5. Fielding's constraints: client-server, stateless, cacheable, uniform interface, layered system, (optional) code on demand. Statelessness means each request is self-contained — any server can handle any request, enabling horizontal scaling via load balancers.
    6. Atomic (all-or-nothing), Consistent (valid state transitions), Isolated (concurrent transactions don't interfere), Durable (committed changes persist). In distributed systems, network partitions make coordinating these guarantees across nodes difficult — relates to CAP theorem's consistency vs. availability trade-off.
    7. CORBA used Interface Definition Language (IDL) to enable cross-language remote object invocation. Limitations: complexity, vendor incompatibility, firewall issues (non-HTTP ports), heavyweight infrastructure. Web services over HTTP were simpler, firewall-friendly, and internet-native.
    8. False
    9. True
    10. False

    Critical Thinking Questions

    1. API Design Philosophy: REST has become the dominant API style for cloud services, but gRPC is gaining adoption for service-to-service communication within microservices. Compare the two approaches. In what scenarios would gRPC be preferable to REST, and vice versa? Consider factors like performance, developer experience, browser compatibility, and tooling.
    2. Distributed Transactions: An e-commerce platform processes orders across three microservices: Inventory (reserves stock), Payment (charges credit card), and Shipping (schedules delivery). If the payment fails after inventory is reserved, how should the system handle this? Compare the traditional ACID approach with the Saga pattern used in modern distributed systems.
    3. Legacy Integration: A large insurance company has critical business logic embedded in CORBA-based systems built in the 1990s. They want to modernize and expose these capabilities via cloud APIs. What migration strategies would you recommend? Should they rewrite, wrap, or gradually replace the CORBA services?
    4. API Versioning: A cloud service provider needs to update their REST API in a way that changes the response format, which could break existing client applications. Discuss strategies for API versioning (URL path versioning, header versioning, query parameter versioning). What are the trade-offs, and which approach would you recommend?

    Hands-On Lab Exercise

    Lab: Designing RESTful APIs for a Cloud Application

    Objective: Design a complete RESTful API specification for a cloud-based application.

    Scenario: TaskFlow is a cloud-based project management SaaS application. You need to design the REST API that will serve both the web/mobile frontends and third-party integrations.

    Core entities:

    • Users (name, email, role)
    • Projects (name, description, owner, members, status)
    • Tasks (title, description, assignee, project, priority, status, due date)
    • Comments (text, author, task, timestamp)

    Instructions:

    1. API Resource Design (20 min): Define the REST API endpoints for all CRUD operations on each entity. Use proper HTTP methods and URL patterns. Create a table:
      Method Endpoint Description Request Body Response
      GET /api/v1/projects List all projects — Array of projects
      ... ... ... ... ...

      Include at least 15 endpoints covering basic CRUD plus relationships (e.g., tasks within a project, comments on a task).

    2. Request/Response Design (15 min): Design JSON request and response bodies for:
      • Creating a new project
      • Retrieving a task with its comments
      • Updating a task's status Include appropriate fields, data types, and nested objects.
    3. Error Handling (10 min): Design a consistent error response format for the API. Define error responses for:
      • 400 Bad Request (validation error)
      • 401 Unauthorized
      • 403 Forbidden
      • 404 Not Found
      • 500 Internal Server Error
    4. Authentication & Authorization (15 min): Design the authentication flow for the API:
      • How do users obtain access tokens?
      • How are tokens included in API requests?
      • How do you handle different permission levels (admin, project owner, team member, read-only)?
    5. API Documentation (15 min): Write documentation for three of your endpoints that a third-party developer could use to integrate with TaskFlow. Include: description, URL, method, headers, request parameters, example request, example response, and possible errors.
    6. SOAP vs REST Comparison (15 min): Rewrite ONE of your REST endpoints as a SOAP service definition. Compare the complexity, verbosity, and tooling requirements of both approaches.

    Deliverables:

    • Complete API endpoint table (15+ endpoints)
    • JSON request/response examples (3 operations)
    • Error response specification
    • Authentication design document
    • API documentation for 3 endpoints
    • SOAP vs REST comparison for 1 endpoint

    Case Study Analysis

    The Evolution of Amazon's Service Architecture

    Amazon's journey from a monolithic e-commerce application to a service-oriented architecture is one of the most influential stories in distributed computing. In the early 2000s, Amazon's engineering teams struggled with a massive, tightly coupled codebase where changes to one component could break others. Development velocity was slowing as the company grew.

    In 2002, Jeff Bezos issued his famous "API Mandate" requiring that:

    1. All teams must expose their data and functionality through service interfaces.
    2. Teams must communicate with each other through these interfaces.
    3. There will be no other form of inter-process communication allowed.
    4. All service interfaces must be designed from the ground up to be externalizable.

    This mandate forced Amazon to decompose its monolith into hundreds of independent services communicating via APIs. Initially, many services used SOAP, but over time, REST became the dominant internal and external protocol. This service-oriented transformation had profound consequences:

    • It enabled each team to develop, deploy, and scale their service independently (the "two-pizza team" model).
    • It created the foundation for Amazon Web Services (AWS) — the internal services were so well-designed that Amazon realized they could offer them externally.
    • Services like S3, SQS, and EC2 started as internal Amazon tools before becoming the world's largest cloud platform.

    Today, a single customer request on Amazon.com triggers calls to hundreds of microservices, all communicating through well-defined APIs with strict contracts.

    Discussion Questions:

    1. How did Amazon's "API Mandate" change the company's software architecture? What problems did it solve, and what new challenges did it create (e.g., distributed system complexity, network overhead, debugging)?
    2. The mandate required all interfaces to be "externalizable" — designed as if they could be exposed to the outside world. Why was this requirement important, even for internal services? How did this decision eventually lead to the creation of AWS?
    3. Amazon transitioned from SOAP to REST for most of its services over time. Based on what you've learned in this chapter, what factors likely drove this transition? Are there Amazon services where SOAP-style contracts might still be more appropriate?
    4. Compare Amazon's API-driven architecture from 2002 with modern microservices architectures. What has evolved in terms of communication patterns (REST, gRPC, event-driven), service discovery, and API management? What core principles from the Bezos mandate remain relevant today?

    Assessment Rubric

    Lab Exercise Rubric (100 points)

    Criteria Excellent (90–100%) Proficient (70–89%) Developing (50–69%) Beginning (0–49%)
    API Endpoint Design (25 pts) 15+ well-designed endpoints using correct HTTP methods, RESTful URL patterns, and proper resource modeling 12+ endpoints with mostly correct REST conventions Basic endpoint design with some REST violations Fewer than 10 endpoints or significant REST violations
    Request/Response Design (20 pts) Well-structured JSON with appropriate data types, nesting, and consistent naming conventions Reasonable JSON structures with minor inconsistencies Basic JSON but with structural issues or inconsistencies Missing or poorly designed JSON structures
    Error Handling (10 pts) Consistent error format with meaningful codes, messages, and details for all specified status codes Covers most error codes with adequate format Basic error handling with gaps Missing or inconsistent error handling
    Auth Design (20 pts) Complete authentication/authorization design with token flow, permission model, and security considerations Reasonable auth design covering basic scenarios Basic auth concepts but gaps in permission handling Missing or insecure auth design
    Documentation & Comparison (25 pts) Professional-quality API docs that a developer could use; insightful SOAP/REST comparison Good documentation with adequate SOAP comparison Basic documentation with superficial comparison Missing or unusable documentation

    Case Study Rubric (50 points)

    Criteria Excellent (90–100%) Proficient (70–89%) Developing (50–69%) Beginning (0–49%)
    Historical Understanding (15 pts) Demonstrates clear understanding of the evolution from monolithic to service-oriented architecture Shows good understanding of the architectural transition Basic understanding with limited context Superficial or incorrect understanding
    Technical Analysis (20 pts) Insightful analysis connecting the case to SOAP, REST, and modern patterns with specific technical details Reasonable technical analysis with supporting details Some technical discussion but mostly descriptive No meaningful technical analysis
    Critical Thinking (15 pts) Evaluates trade-offs, draws connections to modern practices, and offers original insights Shows analytical thinking with some depth Limited analysis beyond surface description No critical analysis

    This page titled 7.9: Assessments was last modified on Wed, 23 Sep 2026 03:04:27 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.