Lecture 03: Middleware

Copyright Notice

Some material in this lecture is adapted from the teaching materials of the book “Web Services: Concepts, Architectures and Applications” and is thus Copyright © 2003 Gustavo Alonso, ETH Zürich and/or Copyright © 2004 Springer-Verlag Berlin Heidelberg.

Middleware

Middleware facilitates and manages the interaction between applications across heterogeneous computing platforms. It is the architectural solution to the problem of integrating a collection of servers and applications under a common service interface.
— Introduction to Chapter 2 of our Textbook

Understanding Middleware
- Middleware as a Programming Abstraction
- Middleware as Infrastructure
- Types of Middleware
RPC
TP Monitors
Object Brokers & Object Monitors
Message-Oriented Middleware

Programming Abstractions

Abstraction is a key concept in making software development easier for software developers
- programming abstractions can
  - hide hardware/platform details
  - provide powerful building blocks
  - reduce programming errors
  - offload difficult tasks to other services
  - reduce development and maintenance costs
Middleware can be seen as a set of programming abstractions that make it easier to develop complex distributed systems
To understand a particular class of middleware, you need to understand its model and its API

Genealogy of Middleware

Today's application servers evolved from the classical types of middleware
TP Monitors, Object brokers, and Message brokers all evolved from specializations of RPC
RPC hides cross-platform communication details behind a procedure call
Sockets are an operating system interface to underlying communication protocols
Transmission Control Protocol (TCP) verifies correct delivery of data streams; User Datagram Protocol (UDP) delivers data packets without guarantees
Internet Protocol moves a packet of data from one node in a network to another node

Middleware as Infrastructure

As programming abstractions move to higher levels, the underlying infrastructure must become more powerful
- additional functionality is almost always implemented through additional software layers
- these layers increase the size and complexity of the infrastructure necessary to implement the new abstractions
- of course, as this happens, the learning curve for developers goes up!
More powerful infrastructure can, in turn, reduce the cost of development, maintenance, and monitoring of distributed systems
- RPC → transactional RPC → logging, recovery, advanced transaction models, transactional file system, etc.
Infrastructure is also used to address non-functional concerns (typically ignored by programming models) such as performance, availability, security, recovery, etc.

Middleware as Infrastructure: DCE

Types of Middleware

RPC-Based Systems	RPC is the most basic form of middleware. It is used as a foundation for all other types of middleware.
TP Monitors	TP Monitors are the oldest and best-known form of middleware. They are also the most reliable, best tested, and most stable technology in the EAI arena. TP Monitors can be seen as RPC with transactional capabilities and are classified into TP-lite and TP-heavy systems.
Object Brokers	A middleware platform that supports the use of RPC in object-oriented languages; aka RMI
Object Monitors	TP Monitors extended with APIs in object-oriented languages
Message-Oriented Middleware	A middleware system built around the model of asynchronous RPC and persistent message queues. Tools are provided to create a number of transactional, persistent queues and allow programs to manipulate both local and remote queues.
Message Brokers	A specialization of MOM systems that can transform and/or filter messages as they move through message queues. They can also dynamically select message recipients based on the content of a message.

RPC in Three Slides: IDL and Client/Server Stubs

RPC in Three Slides: RPC using static bindings

RPC in Three Slides: RPC with dynamic bindings

RPC: What Can Go Wrong?

Lots!
- server may not be available
- bug may occur when sending the call, when processing it, and/or when receiving it
- RPC calls are independent from one another: this fact makes it hard to recover from failures when more than two entities are involved (such as a client with two servers, or a client, a server, and a database)
Recovering from partial system failures is very complex! Imagine a purchasing system in which an order was placed but a bug causes payment details to be lost or inventory not to be updated
Avoiding these types of problems with plain RPC is very difficult

Transactional RPC to the Rescue!

What is Transactional RPC? It is RPC plus
- additional language constructs and run-time support to bundle several RPC calls into an atomic unit
- extensions to databases and possibly other resource managers to allow them to participate in a 2-phase commit process
In a transaction, either all operations succeed and an information system's state is updated or all operations fail and the information system's state is unchanged.
This means that if a transaction has, for example, four operations and the third operation fails, the effect of operations one and two must be rolled back.
Once the client ends a transaction, the transaction manager begins the two phase commit process.
- First, the manager sends a prepare to commit message to each server participating in the transaction
- Second, each server responds with either a ready to commit message or an abort message (if failures occurred while processing its operation)
- Third, if all servers are ready to commit, the manager sends a commit message and the client is notified that the transaction was successful.
- Otherwise, the manager sends an abort message to each server (which may then have to perform a rollback) and the client is notified that the transaction failed.

Transactional RPC

TP Monitors

TP Monitors are middleware systems that provide transactional RPC
They, of course, provide basic RPC functionality (IDLs, name servers, stub compilers, etc.)
They add programming language abstractions for TRPC
They add a transaction manager for implementing TRPC
They add a monitor in charge of scheduling threads, assigning priorities, load balancing, etc.
They provide a run-time environment offering services that can support TRPC
and more... (tools for installing, managing, and monitoring the TP Monitor)

TP Monitors, continued

For many decades, TP monitors were the absolutely dominant form of middleware and have been used to enable many of the operations we perform in daily life (banking transactions, purchasing plane tickets, etc.)
A typical TP monitor can handle hundreds to thousands of concurrent clients due to its use of threads (as opposed to processes) that are distributed across many machines
A TP-heavy monitor provides
- a full development environment
- additional services (queues, priority scheduling, etc.)
- support for authentication
- its own solutions for replication, load balancing, storage management, etc.
A TP-lite system is an extension to a database that
- is implemented via threads, not processes
- is based on stored procedures
- does not provide a full development environment

Object Brokers

Object Brokers extend the RPC paradigm to the object-oriented world; they are middleware that support interoperability among objects
The most famous object broker architecture is CORBA. CORBA follows the same model as RPC but also proposes a complete architecture and identifies parts of the system in much more detail. Indeed, you can think of RPC as an interprocess communication mechanism and CORBA as a reference architecture that includes an interprocess communication mechanism
The key parts of CORBA are an object request broker, a set of services (such as persistence, life cycle management, security, etc.) known as CORBA services, and a set of facilities (such as document management, internationalization, and support for mobile agents) known as CORBA facilities.

Development is similar to RPC:

Object Monitors: Best of Two Worlds

Middleware technology should be interpreted as different stages of the evolution of an “ideal” system. Current systems do not necessarily compete with each other as much as they complement each other. Competition arises as the underlying infrastructures converge towards a single platform:
- OBJECT REQUEST BROKERS (ORBs): enables reuse and distribution of components via a standard, object-oriented interface and a number of additional services
- TRANSACTION PROCESSING MONITORS: an environment to develop components capable of interacting transactionally and the tools necessary to maintain transactional consistency
Object Transaction Monitors? → Object Monitor → ORB + TP-Monitor

Message-Oriented Middleware (MOM)

MOMs are direct descendants of queuing systems found in TP monitors
Provide interoperability via messages: a structured data set typically characterized by a type and a set of attribute-value pairs
Components in a MOM will then publish certain messages while subscribing to other messages; components will often be both clients AND servers depending on the messages they understand

Message Queues

	MOMs provide message queues Messages sent by clients are assigned to queues (typically by name) When the recipient is ready, it retrieves its next message and processes it; this gives servers a lot of control
	queues can also be shared among components here, three components share the responsibility of processing messages in a single queue; a message in this queue is delivered to at most one of these components

Coming up Next

In lecture 4, Dennis will be going more into detail about CORBA. CORBA is important both to what it did for middleware at the time and what lessons it holds for the Web services work that is going on today.
In lecture 5 next week, we will move on to chapter 3 of the textbook and discuss Enterprise Application Integration.