middleware n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
MIDDLEWARE PowerPoint Presentation
Download Presentation
MIDDLEWARE

Loading in 2 Seconds...

play fullscreen
1 / 37

MIDDLEWARE

2 Views Download Presentation
Download Presentation

MIDDLEWARE

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MIDDLEWARE Seminar „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. language specific call interface client stub RPC - IDL Compilation - result development environment client process server process IDL IDL sources client code server code language specific call interface IDL compiler server stub interface headers

  8. RPC – How it works II client process server process client 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

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

  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 ControlSystem 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 transactionalbrackets • „beginning of transaction“ – BOT • „end of transaction“ – EOT • handled by transaction management tool • responsible for interaction between client andserver

  20. TPM – transactional RPC client process server process client BOT procedure call EOT server procedure 1 4 9 10 server stub extract context & txn id register server for tx participate 2PC client stub register txn & create context add txn id & context to call request commit confirm termination 2 6 7 5 11 13 14 12 lookup txn id run 2PCnotify client of outcome 3 8 lookup txn idregister server for txn create txn id register txn register client for txn return txn id 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 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

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

  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 : 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

  33. MOM Core Message Queues client application server application queuedmessages inbound queue

  34. MOM Core Shared Message Queues server application n client application server application 2 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

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