Course Name :

Middleware
Technologies
CSIW
BITS Pilani
Pilani Campus ZG524
Textbooks

T1: Letha Hughes Etzkorn - Introduction to middleware _

web services, object components, and cloud computing-
Chapman and Hall_CRC (2017).

T2: William Grosso - Java RMI (Designing & Building

Distributed Applications)

R1: Gregor Hohpe, Bobby Woolf - Enterprise Integration Patterns_ Designing,

Building, and Deploying Messaging Solutions -Addison-Wesley Professional
(2003)

R2: MongoDB in Action

Note: In order to broaden understanding of concepts as applied to Indian IT industry, students are advised to refer books of their choice and case-studies in their own organizations
BITS Pilani, Pilani Campus
Modular Structure

No Title of the Module

M1 Introduction and Evolution

M2 Enterprise Middleware

M3 Middleware Design and Patterns

M4 Middleware for Web-based Application and Cloud-based Applications

M5 Specialized Middleware

BITS Pilani, Pilani Campus

 BITS Pilani
Pilani Campus

CS1: Introduction and Evolution

Agenda

 View of Middleware
 Forms of Middleware

BITS Pilani, Pilani Campus

What is Middleware?
 Layer between OS and distributed applications
 Hides complexity and heterogeneity of distributed system
 Bridges gap between low-level OS communications and programming language
abstractions
 Provides common programming abstraction and infrastructure for distributed
applications
 Overview at: http://www.middleware.org

BITS Pilani, Pilani Campus

What is Middleware?
 “Middleware is the software that connects software components or enterprise applications
in a distributed system”.

 Examples: Enterprise Application Integration software, telecommunications

software, transaction monitors, and messaging-and-queueing software.

BITS Pilani, Pilani Campus

Cont.
 Middleware provides support for (some of):
 Naming, Location, Service discovery, Replication
 Protocol handling, Communication faults, QoS
 Synchronization, Concurrency, Transactions, Storage
 Access control, Authentication

 Middleware dimensions:
– Request/Reply vs. Asynchronous Messaging
– Language-specific vs. Language-independent
– Proprietary vs. Standards-based
– Small-scale vs. Large-scale
– Tightly-coupled vs. Loosely-coupled components

BITS Pilani, Pilani Campus

Common Forms of MW
 Sockets
 Remote Procedure Calls
 Distributed Object-Oriented Components (Ex: ORB)
 Message Oriented Middleware (Message Queues/Enterprise Message Bus
etc.)
 Service Oriented Architectures
 Web services (Arbitrary / RESTful)
 SQL-oriented data access
 Embedded middleware
 Cloud Computing

BITS Pilani, Pilani Campus

Sockets
 Socket is an internal endpoint for sending/receiving data within a
node on network
 Berkeley/POSIX sockets defined API for Inter Process Communication
(IPC) within same host (BSD 4.2 – circa 1983)
 Early form of Middleware (limited to same host systems)
 Windows variant (WinSock) based on BSD Sockets.
 Treated similar to files in BSD/POSIX
 Maintained in File Descriptor table
 Supported protocols
 TCP/IP – IPv4, IPv6
 UDP

BITS Pilani, Pilani Campus

Sockets API
 socket —creates a descriptor for use in network  recvmsg —receive the next incoming
communications datagram (variation of recv)
 recvfrom —receive the next incoming
 connect —connect to a remote peer (client)
datagram and record its source endpoint
 write —send outgoing data across a connection address
 read —acquire incoming data from a connection  send —send an outgoing datagram
 close —terminate communication and deallocate a  sendmsg —send an outgoing datagram
descriptor (variation of send)
 bind —bind a local IP address and protocol port to  sendto —send an outgoing datagram, usually
a socket to a prerecorded endpoint address
 shutdown —terminate a TCP connection in
 listen —set the socket listening on the given
one or both directions
address and port for connections from the client
 getpeername —after a connection arrives,
and set the number of incoming connections from a
obtain the remote machine’s endpoint
client (backlog) that will be allowed in the listen
address from a socket
queue at any one time
 getsockopt —obtain the current options for a
 accept —accept the next incoming connection socket
(server)  setsockopt —change the options for a socket
 recv —receive the next incoming datagram
BITS Pilani, Pilani Campus
Sockets - Life Cycle
TCP Client – Server example

#Server

server.c

#Client

client.c

BITS Pilani, Pilani Campus

Remote Procedure Call (RPC)
 Mask's remote function calls as being local Client/server model
 Request/reply paradigm usually implemented with message passing in
RPC service
 Marshalling of function parameters and return value

BITS Pilani, Pilani Campus

Remote Procedure Call (RPC)
Properties of RPC Failure Modes of RPC
Language-level pattern of function call Invocation semantics supported by RPC in
 easy to understand for programmer the light of : network and/or server
Synchronous request/reply interaction congestion, client, network and/or server
 natural from a programming language failure. Note DS independent failure modes
point-of-view matches replies to requests RPC systems differ, many examples, local
 built in synchronization of requests and was Mayflower
replies
May be or at most once( RPC system tries
Distribution transparency (in the no-failure
once) Error return – programmer may retry
case) Exactly once (RPC system retries a few
 hides the complexity of a distributed system
times)
Various reliability guarantees

Hard error return – some failure most likely
 deals with some distributed systems
note that “exactly once” cannot be
aspects of failure guaranteed
BITS Pilani, Pilani Campus
Remote Procedure Call (RPC)
Disadvantages of RPC
Synchronous request/reply interaction
 tight coupling between client and server
 client may block for a long time if server loaded leads
to multi-threaded programming at client
 slow/failed clients may delay servers when replying
multi-threading essential at servers
Distribution Transparency
 Not possible to mask all problems
RPC paradigm is not object-oriented
 invoke functions on servers as opposed to methods on
objects

BITS Pilani, Pilani Campus

Object-Oriented Middleware (OOM)
 Objects can be local or remote Properties of OOM
 Object references can be local or Support for object-oriented programming
remote model
 Remote objects have visible remote  objects, methods, interfaces, encapsulation…
interfaces  exceptions (were also in some RPC systems e.g.
 Masks remote objects as being local Mayflower)
using proxy objects Remote method Synchronous request/reply interaction
invocation  same as RPC
Location Transparency
 system (ORB) maps object references to locations
Services comprising multiple servers are
easier to build with OOM
 RPC programming is in terms of server-interface
(operation)
 RPC system looks up server address in a location
service BITS Pilani, Pilani Campus
Java Remote Method Invocation (RMI)
public interface PrintService extends Remote
{
int print(Vector printJob) throws RemoteException;
}

 Distributed objects in Java

 RMI compiler creates proxies and skeletons
 RMI registry used for interface lookup

 Entire system written in Java (single-language system)

BITS Pilani, Pilani Campus

CORBA
 Common Object Request Broker Architecture
 Open standard by the OMG (Version 3.0)
 Language- and platform independent
 Object Request Broker (ORB)
 General Inter-ORB Protocol (GIOP) for communication
 Interoperable Object References (IOR) contain object location
 CORBA Interface Definition Language (IDL)
 Stubs (proxies) and skeletons created by IDL compiler
 Dynamic remote method invocation
 Interface Repository
 Querying existing remote interfaces
 Implementation Repository
 Activating remote objects on demand

BITS Pilani, Pilani Campus

CORBA IDL
 Definition of language-independent remote CORBA Services
interfaces Naming Service
 Language mappings to C++, Java, Smalltalk, …  Names  remote object references
 Translation by IDL compiler Trading Service
 Type system  Attributes (properties)  remote object
 basic types: long (32 bit), references
 long long (64 bit), short, float, char, boolean, Persistent Object Service
octet, any, …  Implementation of persistent CORBA objects
 constructed types: struct, union, sequence, Transaction Service
array, enum  Making object invocation part of transactions
 objects (common super type Object) Event Service and Notification Service
 Parameter passing  In response to applications‘ need for
 in, out, inout asynchronous communication
 basic & constructed types passed by value  built above synchronous communication with
 objects passed by reference push or pull options
 not an integrated programming model with
general IDL messages
typedef sequence<string> Files; interface
PrintService : Server {
void print(in Files printJob); }; BITS Pilani, Pilani Campus
CORBA - Disadvantages
 Synchronous request/reply interaction only
 So CORBA oneway semantics added and -
 Asynchronous Method Invocation (AMI)
 But implementations may not be loosely coupled
 Distributed garbage collection
 Releasing memory for unused remote objects
 OOM rather static and heavy-weight
 Bad for ubiquitous systems and embedded devices

BITS Pilani, Pilani Campus

Message-Oriented Middleware (MOM)
Properties of MOM
 Communication using messages Asynchronous interaction
 Messages stored in message queues  Client and server are only loosely
coupled
 message servers decouple client and server  Messages are queued
 Various assumptions about message content  Good for application integration
Support for reliable delivery service
 Keep queues in persistent storage
Processing of messages by intermediate
message server(s)
 May do filtering, transforming,
logging, …
 Networks of message servers
Natural for database integration

BITS Pilani, Pilani Campus

Message-Oriented Middleware (MOM)
IBM MQ-Series Java Messaging Service (JMS)
One-to-one reliable message passing API specification to access MOM
using queues implementations
 Persistent and non-persistent Two modes of operation *specified*:
messages Point-to-point: one-to-one communication
 Message priorities, message using queues
notification Publish/Subscribe: Event-Based
Queue Managers Middleware
 Responsible for queues JMS Server implements JMS API
 Transfer messages from input to JMS Clients connect to JMS servers
output queues Java objects can be serialised to JMS
 Keep routing tables messages
Message Channels A JMS interface has been provided for MQ
 Reliable connections between queue pub/sub (one-to-many) - just a
managers specification?

BITS Pilani, Pilani Campus

MOM - Disadvantages
 Poor programming abstraction (but has evolved)
 Rather low-level (cf. Packets)
 Request/reply more difficult to achieve, but can be done
 Message formats originally unknown to middleware
 No type checking (JMS addresses this – implementation?)
 Queue abstraction only gives one-to-one communication
 Limits scalability (JMS pub/sub – implementation?)

BITS Pilani, Pilani Campus

Web Services
 Use well-known web standards for Properties of Web Services
distributed computing Language-independent and open standard
SOAP offers OOM and MOM-style
 Communication communication:
• Message content expressed in XML  Synchronous request/reply like OOM
• Simple Object Access Protocol (SOAP)  Asynchronous messaging like MOM
– Lightweight protocol for sync/async  Supports internet transports (http,
smtp, ...)
communication
 Uses XML Schema for marshalling types
 Service Description
to/from programming language types
• Web Services Description Language WSDL says how to use a web service
(WSDL)  http://api.google.com/Google
– Interface description for web services Search.wsdl
 Service Discovery UDDI helps to find the right web service
• Universal Description Discovery and  Exports SOAP API for access
Integration (UDDI)
– Directory with web service description
in WSDL BITS Pilani, Pilani Campus
Web Services
Disadvantages of WS What we lack so far ?
Low-level abstraction General interaction patterns
 leaves a lot to be implemented  we have one-to-one and request-reply
Interaction patterns have to be built  one-to-many? many to many?
 one-to-one and request-reply provided  notification?
 one-to-many?  dynamic joining and leaving?
 still synchronous service invocation,
Location transparency
rather than notification  anonymity of communicating entities
 No nested/grouped invocations,
Support for pervasive computing
transactions, ...
 data values from sensors
 No location transparency
 lightweight software
BITS Pilani, Pilani Campus
Event-Based Middleware a.k.a.
Publish/Subscribe
 Publishers (advertise and) publish events (messages)

 Subscribers express interest in events with subscriptions

 Event Service notifies interested subscribers of published events
 Events can have arbitrary content (typed) or name/value pairs

BITS Pilani, Pilani Campus

Topic-Based and Content-Based
Pub/Sub
 Event Service matches events against Properties of Pub/Sub
subscriptions Asynchronous communication
 What do subscriptions look like?  Publishers and subscribers are loosely
 Topic-Based Publish/Subscribe coupled
 Publishers publish events belonging to a Many-to-many interaction between pubs.
topic or subject and subs.
 Subscribers subscribe to a topic  Scalable scheme for large-scale systems
subscribe(PrintJobFinishedTopic, …)  Publishers do not need to know
 (Topic and) Content-Based subscribers, and vice-versa
Publish/Subscribe  Dynamic join and leave of pubs, subs,
 Publishers publish events belonging to (Topic and) Content-based pub/sub very
topics and expressive
 Subscribers provide a filter based on  Filtered information delivered only to
content of events interested parties
subscribe(type=printjobfinished,  Efficient content-based routing through
printer=‘aspen’, …) a broker network
BITS Pilani, Pilani Campus
Summary
 Middleware is an important abstraction for building distributed systems

1. Remote Procedure Call

2. Object-Oriented Middleware

3. Message-Oriented Middleware

4. Event-Based Middleware
 Synchronous vs. asynchronous communication
 Scalability, many-to-many communication
 Language integration

 Ubiquitous systems, mobile systems

BITS Pilani, Pilani Campus