MIDDLEWARESeminar „Web Services“

Wolfgang Gassler, Eva Zangerle

2

OVERVIEW

• introduction

• types of middleware• RPC based systems• TP monitors• object brokers• object monitors• message oriented middleware

3

INTRODUCTION• provide interface to integrate

heterogeneous systems

• manage interaction application <-> server

• roles of middleware• as a programming abstraction

• hide complexity to the programmer

• as an infrastructure• basis of programming abstraction• extensions

4

RPC• History

• How RPC works

• RPC binding

• RPC heterogeneity

• RPC extensions

• RPC transparency

5

RPC - History• RPC = Remote Procedure Call

• Birell and Nelson (1980s)

• calling procedures on remote machines

• basis for two tier systems

• start of the developement of distributed systems

• basis for middleware, EAI and web services

6

RPC – How it works I• interface for procedures

• IDL (Interface Definition Language)

• Compilation of IDL

• Result of compilation• client and server stub for every

defined procedure• interface headers

7

RPC - IDL Compilation - result

client code

language specific call interface

client stub

client process server process

server code

server stub

language specific call interface

development environment

IDL

IDL sources

IDL compiler

interfaceheaders

8

RPC – How it works II

client

procedure call

client stub

locate(un)marshal(de)serialize

send (receive)

com

mun

icat

ion

mod

ule

com

mun

icat

ion

mod

ule

server

procedure

server stub

(un)marshal(de)serialize

receive (send)

dispatcher

selects stub

client process server process

9

RPC - binding• static binding

• hard coded stub• simple• efficient• not flexible• stub recompilation necessary if the location

of the server changes• use of redundant servers not possible

10

RPC - binding• dynamic binding

• name and directory server• load balancing

• IDL used for binding• flexible• redundant servers possible

11

RPC - dynamic binding

client

procedure call

client stubbind

(un)marshal(de)serialize

findsend

receive

com

mun

icat

ion

mod

ule

com

mun

icat

ion

mod

ule

server

procedure

server stubregister

(un)marshal(de)serialize

receivesend

dispatcher

selects stub

client process server process

name and directory server

2

4

5 6

7

8

9

1

12

11 10

12

13

12

3

12

RPC - Heterogeneity• RPC hides heterogeneity of a system

• x servers, y clients

• 2*x*y stubs, for each combination• too much, not efficient

• solution: common form of representation• mapped in IDL (platform independent)• x+y stubs need to be implemented

13

RPC - Extensions• conventional RPC: sequential

execution of routines

• client blocked until response of server

• asynchronous RPC – non blocking• client has two entry points(request and response)• server stores result in shared memory• client picks it up from there

14

RPC - Transparency+ programmer aware of distribution,

performance and reliability issues

+ error detection is easier

- no need to worry about details

- simplicity

- less opportunities to cause errors

15

TP Monitors• History

• Transactional RPC

• How TP monitors work

16

TP Monitors• TPM = transaction processing monitors

• oldest form of middleware

• most efficient and best tested middleware

• basis for many new middleware platforms

17

TPM - History• Customer Information and Control

System by IBM (late 1960s)

• alternative operating system

• complete development tool

• later split up in modules• logging, recovery, persistence, security....

• TP lite monitors• provide core functionality of TPM• embedded in database management system• result = two tier system

18

TPM – transactional RPC I• conventional RPC

• not taking care of dependencies within various calls

• difficult error detection

• TRPC• derived from database transactions• transaction criteria: atomicity, consistency,

isolation and durability• if not all criteria are fullfilled: rollback• criteria also applicable to RPC calls

19

TPM – transactional RPC II• define procedures within transactional

brackets• „beginning of transaction“ – BOT• „end of transaction“ – EOT• handled by transaction management tool

• responsible for interaction between client andserver

20

TPM – transactional RPC

clientBOTprocedure callEOT

client stubregister txn & create contextadd txn id & context to callrequest commitconfirm termination

server

procedure

server stubextract context & txn id

register server for txparticipate 2PC

client process server process

2

4

65

10

7

1

8

13

9

11

create txn id register txn register client for txn return txn id

3 lookup txn idregister server for txn

14

12 lookup txn id run 2PCnotify client of outcome

transaction manager

21

TPM – 2 phase commit protocol• „prepare to commit“ message to server

• server responds „ready to commit“• guarantees successful commit of procedure

• check whether all servers are ready• ready: commit results of requests• not ready: cancelation, rollback• log states of transactions

22

OVERVIEW III• Object Brokers (CORBA)

• History• CORBA System Architecture• How CORBA works• Dynamic Service Selection• Encapsulation• Object Monitors

23

Object Brokers - History• 1990s – object oriented programming

• similar to RPC

• Problem: object oriented features

• CORBA by OMG

• Common Object Request Broker Architect.

• DCOM / COM+ (Microsoft)

24

CORBA – System Architecture

Object Request Broker (ORB)

user-definied

objects

CORBA facilities

CORBA services

Vertical facilitites

Financials Health care ...Horizontal facilities

DistributeddocumentsInformation

management

Systemsmanagement

Taskmanagement

naming transactions events lifecycle properties

relationships time licensing trader concurrency

query security collection startup persistence

25

CORBA – How it works

IDL of service provider

applicationobject

(client)

Object Request Broker (ORB)

Interface repository

Dynmic Invocation Interface

IDL compiler(client)

IDL compiler(server side)

application object(client)

application object(service provider)

stub skeleton

26

Dynamic Service Selection• Dynamically discover new objects

• Interface repository (stores IDL definitions)

• Dynamic invocation interface

• Naming and Trader services

• In practice NOT used!

• meaning of the properties, parameters?

27

Encapsulation

• Hides internal details

• Change implementation

• Change programming language

• Change platform/operating system

• Change location (General Inter-ORB Protocol )

28

Object Monitors

• Extremely inefficient

• Lacked key functionality

• Too long time for implementation

• Object Monitors = TP Monitors + Object Brokers

29

Summary Object Brokers/CORBA

• Object oriented

• Provides many services

• Difficult to handle/manage

• Not used

30

OVERVIEW IV• Message Oriented Middleware

• How it works• Message Channels• Message Routers• Message Queues

31

Message Oriented Middleware

• Asynchronous forms of interaction

• Communication by exchanging messages

• More dynamic

32

Message Oriented Middleware

Message : quote { QuoteRefernceNumber: 325 DeliveryDate: Nov 10, 2004 Price: 20 000 EUR}

Message-Oriented Middleware (MOM)

client application

quotation tool

Message : quoteRequest { QuoteRefernceNumber: 325 Customer: University of Innsbruck Item: #120 (IBM Laptop) Quantity: 10 DeliveryAdress: Innsbruck}

33

Message Queues

MOM Core

client application server application

inbound queue

queuedmessages

34

Shared Message Queuesserver application n

server application 2

MOM Core

client application

server application 1

inbound queue

35

Summary Message oriented MW

• Asynchronous

• More dynamic

• Flexibility

• Modular

• Often used in new projects

36

SUMMARY

• RPC based systems

• TP monitors

• object brokers

• object monitors

• message oriented middleware

MIDDLEWARESeminar „Web Services“

Wolfgang Gassler, Eva Zangerle

?