Seminar „Web Services“ MIDDLEWARE Wolfgang Gassler, Eva Zangerle

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

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

RPC History How RPC works RPC binding RPC heterogeneity RPC extensions RPC transparency

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

RPC – How it works I interface for procedures Compilation of IDL IDL (Interface Definition Language) Compilation of IDL Result of compilation client and server stub for every defined procedure interface headers

RPC - IDL Compilation - result development environment client process server process IDL client code IDL sources server code language specific call interface language specific call interface IDL compiler client stub server stub interface headers

RPC – How it works II client process server process client server procedure call server procedure dispatcher selects stub server stub (un)marshal (de)serialize receive (send) client stub locate (un)marshal (de)serialize send (receive) communication module communication module

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

RPC - binding dynamic binding name and directory server load balancing IDL used for binding flexible redundant servers possible

name and directory server RPC - dynamic binding client process server process client procedure call server procedure 3 13 11 10 client stub bind (un)marshal (de)serialize find send receive server stub register (un)marshal (de)serialize receive send 8 1 communication module communication module dispatcher selects stub 12 4 9 7 12 12 5 6 2 name and directory server

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

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

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

TP Monitors History Transactional RPC How TP monitors work

TP Monitors TPM = transaction processing monitors oldest form of middleware most efficient and best tested middleware basis for many new middleware platforms

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

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

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 and server

TPM – transactional RPC client process server process client BOT procedure call EOT server procedure 1 4 9 10 client stub register txn & create context add txn id & context to call request commit confirm termination server stub extract context & txn id register server for tx participate 2PC 2 6 5 7 11 13 14 12 lookup txn id run 2PC notify client of outcome 3 create txn id register txn register client for txn return txn id 8 lookup txn id register server for txn transaction manager

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

OVERVIEW III Object Brokers (CORBA) History CORBA System Architecture How CORBA works Dynamic Service Selection Encapsulation Object Monitors

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)

CORBA – System Architecture Vertical facilitites CORBA facilities Financials Health care ... user-definied objects Horizontal facilities Distributed documents Systems management Information management Task management Object Request Broker (ORB) CORBA services naming transactions events lifecycle properties relationships time licensing trader concurrency query security collection startup persistence

CORBA – How it works IDL of service provider application object (client) IDL compiler (client) IDL compiler (server side) application object (client) application object (service provider) stub skeleton Dynmic Invocation Interface Object Request Broker (ORB) Interface repository

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?

Encapsulation Hides internal details Change implementation Change programming language Change platform/operating system Change location (General Inter-ORB Protocol )

Object Monitors Extremely inefficient Lacked key functionality Too long time for implementation Object Monitors = TP Monitors + Object Brokers

Summary Object Brokers/CORBA Object oriented Provides many services Difficult to handle/manage Not used

OVERVIEW IV Message Oriented Middleware How it works Message Channels Message Routers Message Queues

Message Oriented Middleware Asynchronous forms of interaction Communication by exchanging messages More dynamic

Message Oriented Middleware Message : quoteRequest { QuoteRefernceNumber: 325 Customer: University of Innsbruck Item: #120 (IBM Laptop) Quantity: 10 DeliveryAdress: Innsbruck } client application Message-Oriented Middleware (MOM) Message : quote { QuoteRefernceNumber: 325 DeliveryDate: Nov 10, 2004 Price: 20 000 EUR } quotation tool

Message Queues client application server application MOM Core queued messages MOM Core inbound queue

Shared Message Queues server application n client application MOM Core inbound queue

Summary Message oriented MW Asynchronous More dynamic Flexibility Modular Often used in new projects

SUMMARY RPC based systems TP monitors object brokers object monitors message oriented middleware

Seminar „Web Services“ ? Seminar „Web Services“ MIDDLEWARE Wolfgang Gassler, Eva Zangerle