ICA II Lectures 9-11

What are webservice APIs and what are their goals

• API (Application Programming Interface): A set of rules that lets apps or devices connect and communicate (IBM).

• Core Mechanism: Lets one app/service (client) access a resource in another (server).

• Modern Architecture Goal (late 2000s):

  • Highly flexible (unlike SOAP, no strict message format).

  • Supports any programming language and data/message format.

REST & RESTful Web Services

• REST = Representational State Transfer

• RESTful Services: Follow REST architecture by applying specific constraints.

• Key Concepts:

  • Share resource representations (data/state objects like user, product, etc.).

  • Use standard HTTP methods (GET, POST, etc.).

  • Expose actions as URLs.

  • Stateless: No session/history is stored between requests.

REST API Architectural Guidelines

Uniform Interface

Client-Server Decoupling

Statelessness

Cacheability

Von Neumann Architecture: CPU, RAM, and Storage

• CPU (Central Processing Unit): Executes instructions.

• RAM (Main Memory): Volatile, stores temporary processing data from active apps. Faster than secondary storage but data is lost on shutdown.

• Secondary Storage (e.g., HDD): Non-volatile, permanent storage. Slower than RAM but retains data when powered off.

REST API CRUD Operations

REST APIs expose an interface of actions for CRUD database operations over resources:

Create = HTTP Post method

Read = HTTP Get method

Update = HTTP Put method

Delete = HTTP Delete method

REST API: Resource State

• A resource's state at a specific time is called its representation (e.g., current EGX30 ORA stock price).

• This state can be sent to the client in formats like JSON, XML, HTML, plain text, etc.

• JSON is widely used for being human-readable, machine-friendly, and language-agnostic.

Rest APIs and JSON

JSON (JavaScript Object Notation) is a lightweight, semi-structured data format used in REST APIs (alongside XML) for data exchange. It is also machine and human readable.

JSON basic data types:

Number (integer, real, or floating point)

String (double-quoted Unicode with backslash escaping)

Boolean (true and false)

Array (an ordered sequence of values, comma-separated and enclosed in square brackets)

Object (collection of key:value pairs, comma-separated and enclosed in curly braces)

null

JSON all elements example:

Service interface vs service implementation:

• Service Interface:

  • Defines visible functionality for external access.

  • Specifies operations, parameters, data types, and protocols.

  • Enables other software to know what the service does and how to use it.

• Service Implementation:

  • Actual code realizing the interface.

  • Implementation details are hidden from users.

• Key Point:

  • Multiple providers can implement the same interface in different languages.

  • Enables loose coupling between components.

REST Web API Uses

REST implemented with Web standard protocols use:

 HTTP methods for communication

 URLs are used to identify a resource

 JSON / XML for messages

Used in web services and inter-web app communication

Cloud-based web services expose functionalities as REST APIs

RESTful Web Services

In REST, the communication is usually based on HTTP/ HTTPS Protocols.

• HTTPS ensures secure, encrypted communication.

• Supports multiple resource representation formats: JSON, XML, plain text, PDF, JPEG, HTML, etc.

• JSON and XML are the most common formats.

REST API Headers

• Request and response headers carry key info like metadata, authorization, URIs, caching, and cookies.

• Headers can specify the expected response format (e.g., JSON, XML).

• Used alongside HTTP status codes in well-designed REST APIs.

HTTP Status Codes:

REST API URL Resource Naming Conventions

Conventional: /api/{resource}/{ID} (eg. /api/user/johnsmith)

Parameter Based: /api/{resource}?{parameter}={ID}

(eg. /api/user?id=johnsmith)

REST API Resource Naming Conventions

Singleton and Collection Resources

 Singleton: E.g., GET /api/user/johnsmith

Retrieve specific single user

 Collection: E.g., GET /api/users

Retrieve all users

Major REST principles

• Information is organized as resources identified by URIs.

• Clients and servers communicate via standard HTTP methods.

• They exchange resource representations (data formats).

• Intermediaries (caches, proxies) handle requests without affecting the client.

• Apps need only the resource ID and action to interact.

• No need to know about intermediaries or history.

• Must understand the representation format.

• REST is platform-independent.

SOA Architecture based on REST Web API (Communication)

• All functions exposed via API using HTTP methods and HTTP body.

• Payload can be any HTTP-supported format (JSON, XML, HTML, etc.).

• Client and service agree on resources and operations.

• Only the data format is fixed; payload is parsed at runtime.

• Middleware can automatically process calls and extract data.

REST VS SOAP

When to use SOAP and not REST API?

• Need a rigid, unchanging contract—no runtime parsing.

• Require standardized, specific file formats (e.g., stock exchange, SWIFT).

• Want to register services in a UDDI directory.

• For non-dynamic APIs that don’t change often.

• Ideal for legacy apps lacking modern web protocol support or needing faster native connectivity.

Web services and what makes a good one

• A service abstracts any business task (e.g., get stock price).

• Has stable inputs/outputs, even if implementations change (e.g., COBOL → C#).

• Good services are loosely coupled, enabling multiple implementations.

• Applications use the service interface without knowing implementation details.

• Middleware manages communication and data exchange.

• Services support many requesters sharing a common interface.

• Avoids 1-to-1 app connections.

• Encapsulation: self-contained, with well-defined interfaces.

• Web services are loosely coupled, business-driven, and promote rapid development.

• Service-oriented architectures apply at various levels; web services often serve external needs.

START OF LECTURE 10

SOA Recap:

• Uses loosely coupled services to support business needs.

• Services are accessible without knowing internal platform or logic.

• APIs expose fixed message formats, not tied to function names.

• Internal logic is hidden (blackbox); only inputs/outputs matter.

• Data/functions are exposed via standard formats like XML or web services.

Loose Coupling & Granularity

Loose Coupling

• Refers to low dependency between systems.

• Web services are loosely coupled — they work independently and don’t need to know internal details of each other.

Service Granularity

• Fine-grained: Simple, atomic services (e.g., getCustomerByID).

• Coarse-grained: Complex, multi-step services (e.g., SubmitPurchaseOrder), often involve multiple interactions and richer data.

• Fine-grained = more flexible, but needs more calls

• Coarse-grained = fewer calls, but can be slower or less reusable

Microservices

• Everything is a service: Each function is a small, self-contained unit.

• Loose coupling: Services work independently and communicate via APIs.

• Benefits: Easy to update, scale, and maintain; failure in one doesn’t affect others.

Monolithic vs Microservice Applications

Monolithic applications are built as a single unit where all components—UI, business logic, and data access—are tightly coupled. This makes them easier to develop initially but harder to scale or update, as any change requires rebuilding and redeploying the whole application. A single failure can crash the entire system. In contrast, microservice applications break functionality into small, independent services that communicate via APIs. Each service can be developed, deployed, and scaled separately, allowing for greater flexibility, easier updates, and better fault isolation. Microservices support loose coupling and are better suited for modern, cloud-based, and scalable systems.

Common Architecture (Microservices)

Uses Containers which are similar to virtualization but operate on the same OS in a separate process. (An example would be docker)

Use Container Orchestration for: (e.g. Kubernetes) Load balancing and deployment of containers across server clusters

Why should we use micro services?

Containers are more lightweight compared to

VMs

 Faster development per each service

 Easier to scale

 Flexible technology choices

 Can be easily deployed on the Cloud

START OF LECTURE 11

Middleware Types:

 Program-to-program

 Program-to-message

 Program-to-database

RPC: Distributed Objects

Code “sees” server object as if it existed on the client (on the same local machine!). A client can invoke methods on a remote object as if it's local, and the system takes care of the communication and execution details behind the scenes.

Remote Procedure Call (RPC) — Program-to-Program Middleware

• Allows a program to call a procedure/function on another machine as if it were local.

• Client and server syntax remain the same — no need to change code structure for remote calls.

• Uses an Interface Description Language (IDL) to define the functions/interfaces.

• IDL generates:

  • Stub on the client side: acts as a local placeholder for the remote function.

  • Skeleton on the server side: receives requests and calls the actual server function.

• Middleware handles parameter conversion (marshalling) and message transmission between client and server.

Marshelling (Serialization) & unMarshalling (deserialization)

Marshalling (Serialization)

• Converts structured data into a byte stream for network transmission.

Unmarshalling (Deserialization)

• Reconstructs the original structured data from the received byte stream.

Essential in Remote Procedure Calls (RPC), where function arguments and return values need to be transmitted between programs running on different machines.

Communication Architecture of Distributed Systems

Distributed systems built in different programming languages can interoperate through standard messaging protocols, with the web server acting as a central point for communication.

Remote Database Access (program to database)

Remote database access allows applications to connect to and operate on remote databases using standard tools like SQL, ODBC, and JDBC — regardless of the underlying database system.

Most popular DB middleware

ODBC (most programming language, by OMG standard) 

JDBC (Java only; native)

Middleware should provide:

Ease of use: better than programming from scratch

Message delivery integrity: messages should not be lost or duplicated

Message format integrity: messages should not be corrupted

Language transparency: programs of different development languages communicate

Distributed Transactions in Middleware

• Transaction monitors manage transactions across multiple distributed databases.

• They need direct communication with each database.

• But for security, direct access is often not allowed.

Transactional component middleware (TCM)

• Helps build scalable, easier-to-manage transaction systems.

• Uses containers that offer:

  • Transaction support

  • Resource pooling

  • Extra useful interfaces for developers.

What are transactions"?

• Represents a complete business action, like:

  • Withdrawing money from an ATM

  • Buying stock

  • Cancelling a sale

• Must fully complete or fully cancel — no half-done steps.

Follows ACID Properties:

• Atomic – All or nothing happens.

• Consistent – Keeps database rules valid.

• Isolated – Changes stay hidden until done.

• Durable – Once done, changes are permanent.

One Phase Commit

One Phase Commit simply makes changes and commits

Problem with One Phase Commit

Multiple databases may result in an error after a commit

Two Phase Commit

Phase One = preparation to commit (just say data entered successfully but not final!)

Phase Two = commit (make data entry final!)

When should we use two phase commits

1. Necessary if using multiple database brands or distributed databases

2. Requires high-end transaction monitor in middleware

3. Requires every database support two phase commits (standards compliant)

Long transactions

Contains the security session and the task session. The Security Session is long-lived (for login/logout), while Task Sessions are short-lived and handle individual transactions during that time.

Shared Data vs controlled data duplication

Shared Data

• One shared database

• Only needed data is stored centrally

• All applications access the same data

• Easier to manage, but may cause performance bottlenecks

---

Controlled Data Duplication

• Same data is copied to each application's database

• Requires synchronization to keep data consistent

• Improves performance but adds complexity in managing updates

Pass Through Transactional Process (independant data)

each database is independent, no shared data among applications, just commit to middleware when done and share confirmation message!

Copy Out / Copy In process (Hub-and-Spoke)

• Hub = Central data store

• Spokes = Connected applications (e.g., reservation, payment, etc.)

Advantages

• Centralized control and data visibility

• Simplified integration vs. point-to-point

Disadvantage

• If the hub fails, all connected apps may stop (single point of failure)

Message queuing (program to message)

Sends data between applications as messages. makes queues for messages which are like an ordered list of timestamped messages, it also holds messages even when the network is down which supports recovery and integrity and it can cooperate with transaction manager.

Middleware Messaging

Client makes requests in the form of a message  Messages sit in queue until handled

SOA Message oriented middleware (MOM)

any application functionality can be translated to exchange of messages between applications: Input/request message (parameters) and output/response message (feedback).

MOM can use here an Enterprise Service Bus, which manages all messages from all webservices integrating different applications. It makes a queue of messages and guarantees their delivery in case they fail initially.

Middleware bus architecture implementations

in the enterprise bus the middleware servers are connected to each other, but each application is connected to specific servers in the middleware bus enterprise network.

First application A connects to the middleware, the middleware server then forwards the and routes the message to the server which contains application B, that server thens ends the message to application B. When application B commits changes. the middleware queue removes the message. if commit fails, the system either retries (e.g., 10 times over 1 minute / timeout period) or aborts and notifies the sender.

Transaction with reversal

In distributed systems or banking software, money transfers often span multiple systems. To avoid data inconsistency (like debiting without crediting), you must:

• Use atomic transactions.

• Protect data from being modified/deleted mid-transaction.

• Roll back safely if anything fails.

When should we use messaging?

Best when process may not always be available (remote client, non-24x7 server) & When business process does not require real time processing. Meaning it is deferrable.

Features of MOM middleware

Guarantees of service

Publish / subscribe (pull messages based on requests by receiver)

OR store and forward (push messages to receiver),

OR request/reply (pull based on ad-hoc requests by receiver)

Supports transactions