Middleware is the software layer between applications and the operating system or network that lets distributed programs talk to each other, regardless of language, machine or vendor. Names such as CORBA, RMI and EJB belong to an earlier era, but the problems they solved, remote calls, messaging, transactions, service discovery and integration, are exactly what gRPC, Kafka, API gateways and service meshes solve today. This article revisits the five units of the JNTUK course with that mapping.
Unit 1: Client-server computing and distributed systems
Why middleware
When an application is split across machines, programmers would otherwise handle sockets, data formats, failures and security by hand. Middleware hides heterogeneity (different operating systems, languages and hardware) and gives location transparency, a common API and services such as naming, security and transactions.
| Transparency | Meaning |
|---|---|
| Access | Local and remote calls look the same |
| Location | The caller does not need to know where the service is |
| Concurrency | Many users do not interfere |
| Replication, failure | Hidden from the user |
The fallacies of distributed computing are worth remembering: the network is not reliable, latency is not zero, bandwidth is not infinite, the network is not secure, topology changes, there is more than one administrator, transport has a cost and the network is not homogeneous.
Client-server architectures
| Model | Description |
|---|---|
| Two-tier | Client (UI and logic) talks directly to a database server |
| Three-tier | Client, application server (business logic), database; the standard |
| N-tier | More layers: web, application, services, data |
| Fat vs thin client | Logic on the client, or on the server (browser) |
| Peer-to-peer | Equal nodes |
Servers can be stateful or stateless; stateless servers scale and fail over more easily. Concurrency models include process-per-request, thread-per-request and event-driven.
Types of middleware
| Type | Examples (old and new) |
|---|---|
| Remote procedure and object middleware | RPC, RMI, CORBA, gRPC |
| Message-oriented middleware | IBM MQ, JMS, RabbitMQ, Kafka |
| Transaction processing monitors | CICS, Tuxedo |
| Database middleware | ODBC, JDBC |
| Application servers and component containers | EJB, Tomcat, WebLogic, Spring Boot |
| Integration middleware (ESB) | Mule, WSO2 |
Today: a modern three-tier web app is Angular or React (client), Node.js or Spring services (application tier) and MySQL or MongoDB (data tier). The fallacies list is the reason timeouts, retries and circuit breakers exist.
Unit 2: Remote procedure calls and distributed objects
RPC
A Remote Procedure Call lets a program call a function on another machine as if it were local.
- The caller invokes a client stub, which marshals (serialises) the arguments into a message.
- The message is sent over the network.
- The server stub unmarshals it and calls the real procedure.
- The result returns the same way.
An Interface Definition Language (IDL) describes the interface and generates the stubs. Issues: parameter passing (by value; pointers do not work across machines), binding (finding the server via a registry or name service), failure semantics (at-most-once, at-least-once, exactly-once is hard) and timeouts.
Java RMI
Remote Method Invocation is Java’s object-oriented RPC. A remote object implements an interface that extends Remote, methods throw RemoteException, and a client looks up a stub in the RMI registry and calls it. Arguments are serialised (Serializable), and the stub and skeleton hide the networking.
CORBA
The Common Object Request Broker Architecture (from the OMG) lets objects written in different languages call each other. Its parts:
| Part | Role |
|---|---|
| IDL | Language-neutral interface definition |
| ORB (Object Request Broker) | Delivers requests to objects wherever they are |
| Stubs and skeletons | Client-side and server-side proxies |
| IIOP | The standard protocol between ORBs |
| Services | Naming, events, transactions, security |
CORBA was powerful but complex, and it faded as the web and web services arrived.
COM, DCOM and .NET Remoting
Microsoft’s equivalents: COM (binary components) and DCOM (its distributed form), later .NET Remoting and WCF.
Today: gRPC is the modern RPC: an IDL (Protocol Buffers), generated stubs in many languages, HTTP/2 transport and streaming. It is used between microservices at Google, in Kubernetes components (etcd, the container runtime interface) and in many service-to-service calls. The same concepts of stubs, IDL, binding and failure semantics apply. Service discovery (DNS, Kubernetes Services, Consul) replaces the RMI registry.
Unit 3: Message-oriented middleware
Instead of calling and waiting, a sender puts a message on a queue or topic and carries on. The middleware (a message broker) stores and forwards it.
| Property | Synchronous (RPC) | Asynchronous (messaging) |
|---|---|---|
| Coupling | Tight: both sides must be up | Loose: sender and receiver independent in time |
| Failure | Caller fails if the service is down | Messages wait in the queue |
| Latency | Immediate reply | Reply later, or none |
| Scaling | Scale the service | Add more consumers |
Messaging models
| Model | Description |
|---|---|
| Point-to-point (queue) | Each message goes to one consumer; used for work distribution |
| Publish-subscribe (topic) | Each message goes to all subscribers; used for events |
| Request-reply | A reply queue carries the answer |
JMS and brokers
The Java Message Service (JMS) is the standard Java API: ConnectionFactory, Session, Queue/Topic, MessageProducer, MessageConsumer. Brokers include ActiveMQ, RabbitMQ (AMQP), IBM MQ, and cloud services Amazon SQS/SNS and Google Pub/Sub.
Delivery guarantees: at-most-once, at-least-once (the usual choice; consumers must be idempotent) and exactly-once (costly, and often achieved by idempotent processing). Features: persistence, acknowledgements, dead-letter queues, ordering, transactions and message priority.
Event streaming
Apache Kafka treats messages as a distributed, append-only log split into partitions; consumers track their own offset and can replay history. It scales to very high throughput and underlies event-driven architectures and streaming analytics.
Today: Kafka, RabbitMQ and SQS are in nearly every production architecture: decoupling services, absorbing traffic spikes, feeding data pipelines. Consumer lag, a growing dead-letter queue and rebalances are the usual operational signals to watch.
Unit 4: Application servers and component models
An application server hosts business components and supplies shared services so developers write only the business logic.
| Service | What the container provides |
|---|---|
| Lifecycle | Creating, pooling and destroying components |
| Transactions | Declarative, with commit and rollback |
| Security | Authentication and authorisation |
| Persistence | Connection pooling, object-relational mapping |
| Naming | JNDI lookup of resources |
| Messaging, concurrency, scaling | Managed threads, clustering |
Java EE and EJB
Enterprise JavaBeans (EJB) are server-side components in an EJB container.
| Bean | Purpose |
|---|---|
| Session bean | Business logic (stateless, stateful or singleton) |
| Entity bean (now JPA entities) | Persistent data |
| Message-driven bean | Reacts to JMS messages |
Servers include WebLogic, WebSphere, JBoss/WildFly and GlassFish; Tomcat is a lighter servlet container. Java EE became Jakarta EE. Alongside it, the Spring framework provides dependency injection, transactions and web support in a lighter form, and Spring Boot embeds the server inside the application’s own JAR.
.NET
Microsoft’s platform: the CLR runtime, ASP.NET for web applications, WCF for services, and ADO.NET for data. Today’s .NET runs on Linux and in containers.
Transactions
A distributed transaction needs all parties to commit or abort together. The two-phase commit (2PC) protocol has a prepare phase and a commit phase driven by a coordinator; it is correct but blocks if the coordinator fails. Modern systems often prefer the saga pattern: a sequence of local transactions with compensating actions to undo earlier steps.
Today: an embedded server in a Spring Boot or Node.js app, packaged in a Docker image, has replaced the shared application server. Container orchestration now provides what the app server did: lifecycle (restarts and scaling), configuration and secrets, health checks, and service discovery. Sagas and the outbox pattern are how microservices keep data consistent.
Unit 5: Web services, SOA and modern integration
Web services
A web service exposes functions over standard web protocols.
| Style | Technology | Features |
|---|---|---|
| SOAP | XML messages over HTTP; WSDL describes the service; UDDI registry; WS-Security and WS-* standards | Formal contracts, heavy, enterprise |
| REST | HTTP verbs on URL-addressed resources, usually JSON | Simple, cacheable, the web’s own model |
| GraphQL | One endpoint, clients ask for exactly the fields they need | Flexible queries |
| gRPC | Binary Protocol Buffers over HTTP/2 | Fast, strongly typed, streaming |
Service-oriented architecture (SOA)
SOA builds applications from loosely coupled services with published contracts, found through a registry and combined by orchestration or choreography. An Enterprise Service Bus (ESB) routes, transforms and mediates messages between them. Principles: loose coupling, reusability, abstraction, statelessness and discoverability.
Microservices and modern middleware
Microservices are SOA in a lighter form: small, independently deployable services, each owning its data, communicating over HTTP or messages.
| Need | Modern tool |
|---|---|
| Entry point, routing, authentication, rate limits | API gateway (Kong, NGINX, AWS API Gateway, Gateway API in Kubernetes) |
| Service-to-service traffic, retries, mTLS, observability | Service mesh (Istio, Linkerd) with sidecar proxies |
| Service discovery and configuration | DNS, Kubernetes Services, Consul, etcd |
| Resilience | Timeouts, retries with back-off, circuit breakers, bulkheads |
| Asynchronous integration | Kafka, RabbitMQ, SQS |
| Observability | Distributed tracing (OpenTelemetry, Jaeger), metrics, logs |
Today: the middleware of the older syllabus has been absorbed into the platform. Ingress and gateways (the Gateway API) route traffic, service meshes add security and retries without code changes, Kafka carries events, and OpenTelemetry traces a request across services. Understanding stubs, brokers, transactions and the fallacies of distributed computing explains why each of these exists.
One-minute recap
| Unit | Key idea | You meet it in |
|---|---|---|
| 1. Client-server and middleware | Transparency, N-tier architecture, fallacies of distributed computing | Timeouts, retries, circuit breakers |
| 2. RPC, RMI, CORBA | Stubs, marshalling, IDL, binding | gRPC, Protocol Buffers, service discovery |
| 3. Message-oriented middleware | Queues, topics, at-least-once delivery, JMS | Kafka, RabbitMQ, SQS, dead-letter queues |
| 4. App servers and components | Container services, EJB, 2PC and sagas | Spring Boot, Tomcat, Kubernetes as the container |
| 5. Web services and SOA | SOAP, REST, GraphQL, SOA, microservices | API gateways, service meshes, OpenTelemetry |
Next in Engineering Revisited: Software Testing Methodologies.
Written by Claude, Anthropic’s AI assistant, as part of Engineering Revisited, a quick refresher of the B.Tech subjects one at a time.