Introduction to Middleware I

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
P id common programming i abstraction
b i andd infrastructure
i f for
f
distributed applications
Overview at: http://www.middleware.org

DistributedApplications
Distributed Applications
Distributed Applications

Middleware (remote calls, object invocation,

messages,
g , ))
OperatingSystem
Operating SystemComms
Comms
Operating System Comms (sockets, IP, TCP, UDP, )
N
Network
Network k
Network (packets, bits) 1
Middleware
 Introduction to Middleware II
Middleware provides support for (some of):
Naming, Location,
Naming Location Service discovery,
discovery Replication
Protocol handling, Communication faults, QoS
Synchronisation, Concurrency, Transactions, Storage
Access control, Authentication

Middleware dimensions:
Request/Reply vs. Asynchronous Messaging
L
Language-specific
ifi vs. L
Language-independent
i d d t
Proprietary vs. Standards-based
Small-scale
Small scale vs. Large-scale
Large scale
Tightly-coupled vs. Loosely-coupled components

2
Middleware
 Outline
Part I: Remote Procedure Call (RPC)
Historic interest
Part II: Object-Oriented Middleware (OOM)
Java RMI
CORBA
Reflective Middleware
Part III: Message-Oriented Middleware (MOM)
Java Message Service
IBM MQSeries
Web Services
Part IV: Event-Based
E ent Based Middle
Middleware
are
Cambridge Event Architecture
Hermes
3
Middleware
 Part I: Remote Procedure Call (RPC)
Masks 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

Caller RPC Service RPC Service Remote

1) Marshal args Function
2) Generate ID message
3) Start timer 4) Unmarshal
call() 5) Record ID fun()

8) Unmarshal 6) Marshal
9) Acknowledge 7) Set timer

4
Middleware
 Properties of RPC
Language-level pattern of function call
easy to understand for programmer

Synchronous request/reply interaction

natural from a programming language point-of-view
matches replies to requests
built in synchronisation of requests and replies

Distribution transparency (in the no-failure case)

hides the complexity of a distributed system

Various reliability guarantees

d l with
deals i h some distributed
di ib d systems aspects off failure
f il
5
Middleware
 Failure Modes of RPC
Invocation semantics supported by RPC in the light of:
network and/or server congestion,
client, network and/or server failure
note DS independent failure modes
RPC systems differ, many examples, local was Mayflower

Maybe or at most once (RPC system tries once)

Error return programmer may retry

Exactly once (RPC system retries a few times)

Hard error return some failure most likely
note that exactly once cannot be guaranteed

6
Middleware
 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
fork()
slow/failed clients may delay servers when replying
multi-threading essential at servers
remote call

Distribution Transparency join()

Not possible to mask all problems

RPC paradigm is not object-oriented

invoke functions on servers as opposed to methods on objects

7
Middleware
 Part II: Object-Oriented Middleware (OOM)
Objects can be local or remote
Object
j references can be local or remote
Remote objects have visible remote interfaces
Masks remote objects as being local using proxy objects
Remote method invocation

local OOM OOM remote

object
bj t object
bj t
object A request
request skeleton
broker broker object B
/ /
object object
manager manager
proxy
object B object B 8
Middleware
 Properties of OOM
Support for object-oriented programming model
objects,
objects methods
methods, interfaces
interfaces, encapsulation
encapsulation,
exceptions (were also in some RPC systems e.g. Mayflower)

Synchronous request/reply interaction

same as RPC

Location Transparency
system (ORB) maps object references to locations

Ser ices comprising multiple

Services m ltiple servers
ser ers are easier to build
b ild with
ith OOM
RPC programming is in terms of server-interface (operation)
RPC system looks up server address in a location service
9
Middleware
 Java Remote Method Invocation (RMI)
Covered in 1B Advanced Java programming
Distributed objects in Java

public interface PrintService extends Remote {

int print(Vector printJob) throws RemoteException;
}

RMI compiler creates proxies and skeletons

RMI registry
eg s y used for
o interface
e ace lookup
oo up
Entire system written in Java (single-language system)

10
Middleware
 CORBA
Common Object Request Broker Architecture
Open standard by the OMG (Version 33.0)
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
11
Middleware
 CORBA IDL
Definition of language-independent remote interfaces
Language mappings to C++
C++, Java
Java, Smalltalk
Smalltalk,
Translation by IDL compiler
Type system
basic types: long (32 bit), typedef sequence<string> Files;
interface PrintService : Server {
long long (64 bit), short,
void p
print(in( Files p
printJob);
);
fl t char,
float, h boolean,
b l };
octet, any,
constructed types:
yp struct, union, sequence,
q array,
y enum
objects (common super type Object)
Parameter passing
in, out, inout
basic & constructed types passed by value
objects
bj t passedd by
b reference
f
12
Middleware
 CORBA Services (selection)
Naming Service
Names remote object references
Trading Service
Attributes (properties) remote object references
Persistent Object Service
Implementation
p of ppersistent CORBA objects
j
Transaction Service
Making object invocation part of transactions
Event Service and Notification Service
In response to applications need for asynchronous communication
built above synchronous communication with push or pull options
not an integrated programming model with general IDL messages

13
Middleware
 Disadvantages of OOM
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
h static
i and
d hheavy-weight
i h
Bad for ubiquitous systems and embedded devices

14
Middleware
 OOM experience
Keynote address at Middleware 2009
Steve Vinoski
From Middleware Implementor to Middleware User
(Th andd back
(There b k again)
i )

Available from the course materials page and the MW09

program on the
th website
b it
15
Middleware
 Reflective Middleware
Flexible middleware (OOM) for mobile and context-aware
applications adaptation to context through monitoring
and substitution of components

Interfaces for reflection

Objects
j can inspect
p middleware behaviour

Interfaces for customisabilityy

Dynamic reconfiguration depending on environment
Different protocols, QoS, ...
e.g. use different marshalling strategy over unreliable wireless link

16
Middleware
 Part III: Message-Oriented Middleware (MOM)
Communication using messages
Messages stored in message queues
message servers decouple client and server
Various assumptions about message content

Client App. Server App.

Message Servers

local message message local message

queues queues queues

Network Network Network

17
Middleware
 Properties of MOM
Asynchronous interaction
Client and server are only loosely coupled
Messages are queued
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

18
Middleware
 IBM MQSeries
One-to-one reliable message passing using queues
Persistent and non-persistent
non persistent messages
Message priorities, message notification
Queue Managers
Responsible for queues
Transfer messages from input to output queues
Keep routing tables
Message Channels
Reliable connections between queue managers
Messaging API: MQopen Open a queue
MQclose Close a queue
MQput Put message into opened queue
MQget Get message ffrom
om local q
queue
e e
19
Middleware
 Java Message Service (JMS)
API specification to access MOM implementations
Two modes of operation *specified*:
Point-to-point
one
one-to-one
to one communication using queues
Publish/Subscribe
cf. Event-Based Middleware

JMS Server implements JMS API

JMS Clients connect to JMS servers
Java objects can be serialised to JMS messages
A JMS interface has been provided for MQ
pub/sub (one-to-many) - just a specification?
20
Middleware
 Disadvantages of MOM
Poor programming abstraction (but has evolved)
Rather low-level
low level (cf
(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?)

21
Middleware
 Web Services
Use well-known web standards for distributed computing
Communication
Message content expressed in XML
Simple Object Access Protocol (SOAP)
Lightweight protocol for sync/async communication

Service Description
Web Services Description Language (WSDL)
Interface description for web services

Service Discovery
Universal Description Discovery and Integration (UDDI)
Directory with web service description in WSDL
22
Middleware
 Properties of Web Services
Language-independent and open standard

SOAP offers OOM and MOM-style communication:

Synchronous request/reply like OOM
Asynchronous messaging like MOM
Supports internet transports (http, smtp, ...)
Uses XML Schema for marshalling types to/from programming
language types

WSDL says how to use a web service

http://api.google.com/GoogleSearch.wsdl

UDDI helps
h l tot find
fi d the
th right
i ht webb service
i
Exports SOAP API for access

23
Middleware
 Disadvantages of Web Services
Low-level abstraction
leaves a lot to be implemented

Interaction patterns have to be built

one-to-one and request-reply provided
one-to-many?
still synchronous service invocation, rather than notification
No nested/grouped invocations, transactions, ...

No location transparency

24
Middleware
 What we lack, so far
General interaction patterns
we have one-to-one
one to one and request-reply
request reply
one-to-many? many to many?
notification?
dynamic joining and leaving?

Location transparency
anonymity of communicating entities

Support for pervasive computing

data values from sensors
lightweight software

25
Middleware
 Part IV: Event-Based Middleware a.k.a. Publish/Subscribe

Publishers (advertise and) publish events (messages)

S b ib
Subscribers express interest
i t t in
i events
t with
ith subscriptions
b i ti
Event Service notifies interested subscribers of published events
Events can have arbitrary content (typed) or name/value pairs

subscribe
publish
Publisher notify Subscriber
Event Service
(event-broker
(event broker subscribe
Publisher publish Subscriber
notify
network)
subscribe
Publisher publish Subscriber
notify

26
Middleware
 Topic-Based and Content-Based Pub/Sub
Event Service matches events against subscriptions
What do subscriptions look like?
Topic-Based Publish/Subscribe
Publishers publish events belonging to a topic or subject
Subscribers subscribe to a topic
subscribe(PrintJobFinishedTopic )
subscribe(PrintJobFinishedTopic, )

(Topic and) Content-Based Publish/Subscribe

Publishers publish events belonging to topics and
Subscribers provide a filter based on content of events
subscribe(type=printjobfinished, printer=aspen, )

27
Middleware
 Properties of Publish/Subscribe
Asynchronous communication
Publishers and subscribers are loosely coupled

Many-to-many interaction between pubs. and subs.

Scalable scheme for large-scale systems
Publishers do not need to know subscribers, and vice-versa
Dynamic join and leave of pubs,
pubs subs,
subs (brokers - see lecture DS-8)
DS 8)

(Topic and) Content-based pub/sub very expressive

Filtered information delivered only to interested parties
Efficient content-based routing through a broker network

28
Middleware
 Composite Event Detection (CED)
Content-based pub/sub may not be expressive enough
Potentially
y thousands of event types
yp (primitive
(p events))
Subscribers interest: event patterns (define high-level events, ref DS-2)
Event Patterns
PrinterOutOfPaperEvent or PrinterOutOfTonerEvent
Composite Event Detectors (CED)
Subscribe to primitive events and publish composite events

Publisher
CED Subscriber
Publisher

Publisher CED
CED Subscriber
Publisher
29
Middleware
 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.
vs asynchronous communication
Scalability, many-to-many communication
Lang age integration
Language
Ubiquitous systems, mobile systems

30
Middleware