SOA, Cloud Integration & APIs: How Services Talk in the Cloud

TAKEAWAYS:

• SOA breaks applications into loosely coupled services that communicate via standardized protocols (SOAP/REST), enabling reuse and scalability in the cloud.
• Cloud integration uses APIs, ESBs (Enterprise Service Buses), and message brokers to connect disparate services (e.g., Daraz’s inventory → payment → shipping workflows).
• REST APIs dominate cloud integration due to statelessness, HTTP methods (GET/POST/PUT/DELETE), and JSON/XML payloads, while SOAP adds WS-* standards for transactions.
• Service orchestration (BPEL) and choreography (event-driven) handle complex workflows like NTC’s traffic fine processing or Khalti’s multi-bank transfers.
• Security in SOA/cloud integration relies on OAuth 2.0, JWT tokens, API gateways (Kong, Apigee), and TLS 1.3 for end-to-end encryption.
• Real-world examples show how eSewa’s payment API uses OAuth 2.0 for bank authentication, while Pathao’s driver dispatch relies on REST APIs for real-time location updates.

1. What is Service-Oriented Architecture (SOA)?

SOA is a design paradigm where applications are built as independent, reusable services that communicate over a network using standardized protocols. Unlike monolithic apps, SOA services:

• Are loosely coupled (changes in one service don’t break others).
• Have well-defined interfaces (contracts via WSDL or OpenAPI specs).
• Are discoverable (registered in a service registry like Eureka or Consul).
• Are stateless (or use sessions sparingly).

Why SOA for Cloud?

Cloud computing thrives on scalability, elasticity, and multi-tenancy. SOA enables:

• Microservices architecture: Each service (e.g., user auth, payment, inventory) can scale independently.
• Vendor-agnostic integration: Services from AWS (S3), Google Cloud (Firestore), and Azure (Cosmos DB) can interoperate.
• Cost efficiency: Pay-per-use for services (e.g., AWS Lambda for event-driven workflows).

2. Core SOA Concepts

A. Service Contracts

Services expose interfaces defined via:

• WSDL (Web Services Description Language): XML-based for SOAP services.
• OpenAPI/Swagger: JSON/YAML for REST APIs (e.g., Daraz’s order API).

Example Contract (REST API for Ncell Recharge):

{
  "paths": {
    "/recharge": {
      "post": {
        "summary": "Initiate mobile recharge",
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "type": "object",
                "properties": {
                  "phone": {"type": "string"},
                  "amount": {"type": "number"},
                  "operator": {"type": "string", "enum": ["Ncell", "NTC", "Smart"]}
                }
              }
            }
          }
        },
        "responses": {
          "200": {"description": "Recharge successful", "content": {"application/json": {"schema": {"type": "object", "properties": {"transactionId": {"type": "string"}}}}}}
        }
      }
    }
  }
}

B. Service Discovery

Services must find each other dynamically. Tools:

• Service Registries: Eureka (Netflix), Consul (HashiCorp).
• DNS-based discovery: AWS Route 53, Google Cloud DNS.
• API Gateways: Kong, Apigee (route requests to the right service).

Example: When you use Khalti to pay on Daraz, the API gateway routes your request to:

1. User Auth Service (verifies your Khalti account).
2. Payment Service (deducts funds).
3. Order Service (updates Daraz’s inventory).
4. Notification Service (sends SMS/email).

sequenceDiagram
    participant User
    participant API_Gateway
    participant Auth_Service
    participant Payment_Service
    participant Order_Service
    participant Notification_Service

    User->>API_Gateway: POST /pay (Khalti token, order ID)
    API_Gateway->>Auth_Service: Validate Khalti token
    Auth_Service-->>API_Gateway: 200 (User verified)
    API_Gateway->>Payment_Service: Deduct Rs. 500
    Payment_Service-->>API_Gateway: 200 (Success)
    API_Gateway->>Order_Service: Update inventory
    Order_Service-->>API_Gateway: 200 (Order confirmed)
    API_Gateway->>Notification_Service: Send SMS
    Notification_Service-->>API_Gateway: 200 (Delivered)
    API_Gateway-->>User: 200 (Payment successful)

C. Service Orchestration vs. Choreography

Worked Example: NTC Traffic Fine Workflow (Orchestration)

1. Camera Service detects violation → sends event to Kafka.
2. Orchestration Engine (BPEL):
   • Calls License Service to fetch vehicle owner.
   • Calls Payment Service to generate fine.
   • Calls Notification Service to send SMS.
3. Database updates fine records.

stateDiagram-v2
    [*] --> Fine_Detected: Camera captures violation
    Fine_Detected --> License_Lookup: Query license DB
    License_Lookup --> Payment_Generated: Create fine record
    Payment_Generated --> Notification_Sent: SMS to owner
    Notification_Sent --> [*]

3. Cloud Integration Mechanisms

A. APIs: The Glue of Cloud Services

REST API Design Rules (for Exams):

1. Resources: Nouns (/users, /orders).
2. HTTP Methods:
   • GET /users/123 → Fetch user.
   • POST /orders → Create order.
   • PUT /users/123 → Update user.
   • DELETE /users/123 → Delete user.
3. Status Codes:
   • 200 OK, 201 Created, 404 Not Found, 500 Server Error.
4. Headers:
   • Authorization: Bearer <JWT>.
   • Content-Type: application/json.

B. Enterprise Service Bus (ESB)

An ESB is a middleware that routes messages between services. Features:

• Protocol translation: Converts SOAP → REST.
• Message transformation: XML ↔ JSON.
• Routing: Directs messages based on rules (e.g., "If payment fails, retry 3 times").
• Security: Enforces OAuth, JWT validation.

Example: Nepal Rastra Bank’s ESB connects:

• Banking APIs (NMB, Global IME).
• Khalti/eSewa gateways.
• Government databases (for KYC checks).

graph LR
    A["Banking API"] -->|"SOAP"| B["ESB"]
    B -->|"Translate to REST"| C["Khalti Gateway"]
    B -->|"Validate OAuth"| D["Government KYC DB"]
    C -->|"JSON"| E["Merchant App"]

C. Message Brokers (Event-Driven Integration)

Tools: RabbitMQ, Kafka, AWS SQS/SNS. Use cases:

• Asynchronous processing: Pathao’s driver dispatch (no need to wait for GPS updates).
• Decoupling: NEPSE’s stock price updates (publishers don’t need to know subscribers).

Example: Pathao’s Order Flow

1. User places order → POST /orders (REST API).
2. Order Service publishes OrderCreated event to Kafka.
3. Driver Service subscribes → picks nearest driver.
4. Notification Service subscribes → sends SMS to user/driver.

sequenceDiagram
    participant User
    participant Order_API
    participant Kafka
    participant Driver_Service
    participant Notification_Service

    User->>Order_API: POST /orders (Pickup: Thapathali)
    Order_API->>Kafka: Publish OrderCreated (OrderID: 123)
    Kafka->>Driver_Service: Consume OrderCreated
    Driver_Service->>Kafka: Publish DriverAssigned (DriverID: 456)
    Kafka->>Notification_Service: Consume DriverAssigned
    Notification_Service->>User: SMS "Driver assigned"

4. Security in SOA/Cloud Integration

A. API Security

B. OAuth 2.0 Flow (for Exams)

1. User requests access to a resource (e.g., Khalti balance).
2. Authorization Server (Khalti) redirects to login.
3. User logs in → gets authorization code.
4. Client (your app) exchanges code for access token.
5. Client uses token to call /balance API.

sequenceDiagram
    participant User
    participant Client_App
    participant Authorization_Server
    participant Resource_Server

    User->>Client_App: Request balance
    Client_App->>Authorization_Server: Redirect to /login
    User->>Authorization_Server: Login + Grant access
    Authorization_Server-->>Client_App: Authorization code
    Client_App->>Authorization_Server: Exchange code for token
    Authorization_Server-->>Client_App: Access token (JWT)
    Client_App->>Resource_Server: GET /balance (Authorization: Bearer <token>)
    Resource_Server-->>Client_App: 200 (Balance: Rs. 5000)

C. API Gateways

Tools: Kong, Apigee, AWS API Gateway. Functions:

• Authentication: Validate API keys/JWT.
• Rate limiting: Prevent abuse (e.g., 100 requests/min for Daraz).
• Routing: A/B testing, canary deployments.
• Logging: Track API usage (e.g., NTC monitors traffic fine APIs).

Example: eSewa’s API Gateway

• Validates OAuth tokens from banks.
• Routes requests to payment service or refund service.
• Logs all transactions for audit compliance.

Example: Kong’s request flow (auth → rate limiting → routing → logging) (Image: APaskulin (WMF), CC BY-SA 4.0, via Wikimedia Commons)

5. Cloud-Native Integration Patterns

A. Serverless Integration (AWS Step Functions, Azure Logic Apps)

• Use case: Event-driven workflows (e.g., "When a new order arrives, check inventory → update warehouse → send notification").
• Example: Daraz’s order fulfillment:
  1. Event: OrderCreated (trigger).
  2. Step 1: Check inventory (Lambda).
  3. Step 2: If stock > 0 → update warehouse (SQS).
  4. Step 3: Send SMS (SNS).

B. Hybrid Integration (On-Prem + Cloud)

• Scenario: NTC’s legacy traffic cameras (on-prem) + AWS cloud analytics.
• Solution:
  • MQTT for real-time camera feeds.
  • AWS IoT Core to process data.
  • DynamoDB to store violation records.

graph TD
    A["Traffic Camera<br/>(On-Prem)"] -->|"MQTT"| B["AWS IoT Core"]
    B --> C["Lambda: Detect Violation"]
    C --> D["DynamoDB: Store Fine"]
    C --> E["SNS: Alert Police"]

6. Real-World Examples

Example 1: eSewa’s Payment Flow (SOA + OAuth 2.0)

1. User selects "Pay bill" → eSewa app calls /payments/initiate.
2. API Gateway validates JWT (from eSewa login).
3. Payment Service calls Bank API (via OAuth 2.0).
4. Bank returns transactionId → eSewa updates DB.
5. Notification Service sends SMS.

Why SOA?

• Bank Service can be updated independently.
• Notification Service can switch from SMS to WhatsApp without breaking payments.

Example 2: Pathao’s Driver Dispatch (Event-Driven)

1. User requests ride → POST /rides (REST API).
2. Ride Service publishes RideRequested to Kafka.
3. Driver Service subscribes → filters drivers within 500m.
4. Driver accepts → RideAssigned event published.
5. User and Driver get real-time updates via WebSockets.

Why Cloud Integration?

• Scalability: Handles 1000s of rides/hour.
• Resilience: If one service fails (e.g., GPS), others continue.

Example 3: NTC’s Traffic Fine System (Orchestration)

1. Camera detects violation → sends image to S3.
2. Fine Orchestrator (BPEL):
   • Calls License Service (DynamoDB) → fetches owner.
   • Calls Payment Service → generates fine.
   • Calls Notification Service → sends SMS.
3. Database logs fine in Aurora PostgreSQL.

Challenges:

• Latency: License lookup must be fast (use ElastiCache Redis).
• Fraud: Validate license plate via OCR (AWS Textract).

7. Challenges of SOA/Cloud Integration

8. Exam Tip: How to Score Full Marks

1. Define SOA clearly:

   "SOA is an architectural style where applications are composed of independent, reusable services that communicate via standardized protocols (SOAP/REST) and are discoverable via registries."

2. Compare REST vs. SOAP: Use a table (like above) and mention real-world use (e.g., REST for eSewa, SOAP for Ncell legacy).

3. Draw sequence diagrams: Examiners love message flows. Always label:

   • Participants (User, API Gateway, Service A).
   • Messages (e.g., POST /pay).
   • Responses (HTTP status codes).

4. Relate to Nepal:

   • eSewa: OAuth 2.0 + API Gateway.
   • Pathao: Event-driven (Kafka) + REST APIs.
   • NTC: Orchestration (BPEL) + DynamoDB.

5. Security is key: Always mention:

   • Authentication: OAuth 2.0/JWT.
   • Encryption: TLS 1.3.
   • API Gateways: Rate limiting, logging.

6. Worked examples:

   • Calculate: If a REST API returns 429 Too Many Requests, how would you fix it? → "Use API gateway rate limiting or implement exponential backoff."
   • Trace: Draw a sequence diagram for Khalti’s payment flow (as above).