Middleware-Konzepte Entfernte Aufrufe

Middleware-Konzepte 

Entfernte Aufrufe 

Dr. Gero Mühl 

Kommunikations- und Betriebssysteme 

Fakultät für Elektrotechnik und Informatik 

Technische Universität Berlin

Übersicht 

> Remote Procedure Call (RPC) 

> Remote Method Invocation (RMI) 

> Common Request Broker Architecture (CORBA) 

Middleware-Konzepte © Gero Mühl 2

Remote Procedure Call (RPC)

Remote Procedure Call (RPC) 

> Aufruf einer nicht-lokalen Prozedur entfernter Aufruf 

> Transparent für aufrufende und aufgerufene Prozedur 

> Wirkt für Aufrufenden wie ein lokaler Aufruf Blockierung 

> Bekanntes, bewährtes und bequemes 

Programmierparadigma 

> Verbirgt Verteilung und Netzkomplexität 

> Kein händisches Festlegen von Nachrichtentypen und -inhalt 

> Kein händisches Verpacken/Auspacken der Parameter 

> Kein händischen Senden/Empfangen von Nachrichten 

> … 


Lokaler Prozeduraufruf 

Aufrufende Prozedur 

Aufgerufene Prozedur 

P(x,y,z) 

1 

2 

P(a,b,c) 

4 

3 


Lokaler Prozeduraufruf 

> Prozedur 

> ist eine Menge von Instruktionen mit eindeutigem Namen 

> besteht aus Prozedurkopf und Prozedurrumpf 

> definiert lokale Variablen 

> ist gedächtnislos 

> kennt den Aufrufenden nicht 

> Prozeduraufruf 

> ist Sprunganweisung mit Prozedurnamen und Prozedurparametern (In/Out) 

> alternativ zu Ausgabeparametern Rückgabe eines Wertes durch 

return-Anweisung 

> aufrufende Prozedur wird blockiert, bis aufgerufene Prozedur returniert 

> Aufrufende und aufgerufene Prozedur laufen in einem Adressraum 

⇒ Datenaustausch über globale Variablen ist möglich und kann 

(unerwünschte) Seiteneffekte verursachen (möglichst) vermeiden 


Prozedurparameter 

> Verschiedene Übergabearten möglich 

> call-by value, call-by reference, call-by copy/restore 

> Prozedurdefinition enthält die formalen Parameter 

> Namen, Typen, Übergabeart 

> Beim Aufruf werden die tatsächlichen Parameter übergeben 

> Compiler prüft Typkonformität 

PROCEDURE quadrat ( x REAL, VAR ergebnis REAL ); 

VAR i: INT; 

BEGIN 

i := x * x; 

ergebnis := i; 

END quadrat; 

by value by reference 


Remote Procedure Call (RPC) 

> Verstecken der Kommunikation hinter lokalen Prozeduren 

> Stubs (Stummel) sind lokale Proxies (Stellvertreter) des 

Aufrufers/Aufgerufenen, die meist (weitgehend) automatisch 

generiert werden 

.... 

proc( a, 29 ) 

.... 

Stub 

Netz 

Stub 

proc( x, y ) 

.... 

.... 

end-proc; 

Client 

Server 


Client Stub 

> Lokaler Proxy für die aufzurufende Prozedur 

> Gleiche Prozedursignatur (Prozedurname, Parameter, 

Übergabearten) wie die aufzurufende Prozedur 

> Ruft ggf. Verzeichnis, Dienstvermittler auf, um Adresse des 

Servers zu ermitteln (Binding) 

> Packt Namen der aufzurufenden Prozedur und die Parameter in 

Anfragepaket (= Marshalling) und sendet es an den Server 

> Wartet auf und empfängt Antwortpaket vom Server Stub 

> Entpackt Ergebnisse aus dem Antwortpaket 

> Gibt Ergebnisse und Kontrolle an aufrufende Prozedur zurück 


Client Stub – Exemplarisches Beispiel 

> Signatur der aufzurufenden Prozedur 

double square (double x1) 

> Stub (gleiche Signatur) 

double square (double x1) { 

request = new_request("square"); 

add_double(request, x1); 

send_request(request, server); 

reply = receive_reply(request); 

return extract_double(reply); 

} 


Server Stub 

> Lokaler Proxy für die aufrufende Prozedur 

> Wird vom Laufzeitsystem des Servers aufgerufen 

> Empfängt Anfragepaket und entpackt aus ihm Namen und 

Parameter der aufzurufenden Prozedur (= Unmarshalling) 

> Ruft die jeweilige Prozedur mit den Parametern auf 

> Packt Ergebnisse der Prozedur in Antwortpaket und 

sendet es an den Client Stub 

> Führt evtl. Verwaltungsarbeiten aus 


Server Stub – Exemplarisches Beispiel 

> Wird von der Middleware aufgerufen, wenn eine 

entsprechende Nachricht empfangen wird 

message square_sstub (message request) { 

double x1 = extract_double(request); 

double x2 = square(x1); 

reply = new_reply(request); 

add_double(reply, x2); 

return reply; 

} 


Interface Definition Language (IDL) 

> Ermöglicht deklarative, Programmiersprachen-unabhängige 

Schnittstellendefinitionen 

> Eine Schnittstelle (Interface) wird beschrieben durch 

> Namen der aufrufbaren Operationen 

> Namen und Typen der Parameter der einzelnen Operationen 

> Zusatzinformationen, z.B. eindeutige Kennzeichnung der Definition, 

Art einer Operation, Verhalten bei Fehlern, ... 

> [in], [out], [in, out] (* für Parameter *) 

> [maybe] (* Attribut für Operation *) 

> Server-Programmierer spezifiziert Schnittstelle mit IDL 

> Ein programmiersprachen-abhängiger Stub Compiler erzeugt 

daraus Stubs für Client und Server 


RPC Eigenschaften 

> Getrennte Adressräume machen Adressen bedeutungslos 

> Nachbildung von call-by-reference durch call-by-copy/restore 

> Aufwendig für komplexe verkettete Strukturen 

> Synchroner (d.h. blockierender) Aufruf 

⇒ Parallele Anfragen an mehrere Server nur durch 

Multithreading 

> Die aufgerufene Prozedur kann weitere RPCs aufrufen 

⇒ Server werden (meist) multithreaded implementiert, um 

zeitweise Blockierung des Servers zu vermeiden 


Threads 

> Leichtgewichtige Prozesse 

> Selbstständiger Kontrollfluss mit eigenem Stack 

> Mehrere Threads teilen sich einen Speicherbereich 

> Schnellere Kontextwechsel 

> Einfache Kommunikation durch gemeinsamen Speicher 

> Kein Schutz bei Zugriff auf gemeinsamen Speicher oder 

gleichzeitigem Aufruf einer Prozedur durch mehrere Threads 

⇒ Gefahr von Inkonsistenzen 

⇒ Synchronisation notwendig ⇒ Deadlock-Gefahr 

> Multithreading ermöglicht quasi-gleichzeitige Aufrufe und 

Bearbeitung von RPCs 


Threads: Usage 

> Client several concurrent invocations 

> Server serving several clients concurrently 

Parallel 

Execution 

Server 1 Server 2 

Server 3 

A call is 

waiting 

One idle 

thread 

Client 1 Client 2 Client 3 Client 4 


RPC Fehlersemantik 

> RPC hat andere Fehlersemantik 

als lokaler Prozeduraufruf! 

> Was kann alles schief gehen 

Client 

1. Client findet den Server nicht 

2. Client stürzt ab, nachdem er den Auftrag abgeschickt hat 

3. Auftrag geht verloren 

4. Server stürzt ab, nachdem er den Auftrag empfangen hat, 

aber bevor er die Antwort abgeschickt hat 

5. Antwort geht verloren 

6. Client stürzt ab, bevor er die Antwort erhalten 

(und bearbeitet) hat 

Server 


RPC Fehlersemantik 

> Ist ein Fehler aufgetreten 

> Unterscheidung zwischen langsamen und verlorenen 

Nachrichten bzw. zwischen langsamen und abgestürztem 

Client bzw. Server in verteilten Systemen nicht möglich! 

> Client wartet auf Antwort zu seinem Auftrag 

> Wann soll er den Auftrag erneut schicken 

> Server wartet auf Bestätigung der Antwort/neuen Auftrag 

> Wann soll er die Antwort erneut schicken 

> Wie lange soll er die Antwort aufheben 

> Setzen von sinnvollen Timeouts äußerst schwierig! 


RPC Fehlersemantik – Client Crash 

> Abgestürzte Clients blockieren Ressourcen beim Server 

(z.B. extra für den Client erzeugte Prozesse Waisen) 

> Mögliche Gegenmaßnahmen 

> Client schickt regelmäßig Heartbeat (Wie oft) 

> Server fragt nach, ob Client noch existiert (Wie oft) 

> Verbindungslose Aufrufe 

> Neustart des Clients: alte Antworten dürfen nicht stören 

> Epochen-Zähler beim Neustart inkrementieren und im 

persistenten Speicher ablegen 

> Antworten aus vergangenen Epochen werden ignoriert 


Steigende 

Komplexität 

RPC Fehlersemantik – Server Crash 

> Beim Client tritt Timeout beim Warten auf Antwort auf 

> Wie oft wurde der Auftrag ausgeführt 

> maybe evtl. gar nicht, einmal, mehrfach 

(einfach implementierbar) 

> at least once min. einmal (Wiederholungen) 

> at most once max. einmal (Seriennummern) 

> exactly once genau einmal 

Server 

Receive 

Execute 

Reply 

Server 

Receive 

Execute 

Crash 

Server 

Receive 

Crash 


Kann „exactly once“-Semantik erreicht werden 

> Szenario: Client schickt Druckauftrag an Server 

> Server schickt eine Bestätigung, wenn der Auftrag eintrifft 

> Nach einem Crash schickt der Server „Wieder da“ an alle 

Clients 

> Erfährt der Client vom Crash des Servers, kann er den 

Auftrag wiederholen 

1. niemals 

2. immer 

3. nur, wenn Bestätigung eingetroffen ist 

4. nur, wenn Bestätigung nicht eingetroffen ist 



> Aktionen des Servers 

> M schicke Bestätigung 

> P drucke Text 

> C Crash 

> Server kann Bestätigung schicken, 

> M P bevor der Druckauftrag angestoßen wird 

> P M nachdem der Druckauftrag angestoßen wurde 

> Betrachte den Fall eines Server-Crashs 

> Eine mögliche Reihenfolge ist: M P C 

> Sechs Reihenfolgen insgesamt 

(jeweils 3 für M P bzw. P M) 



> Betrachte Kombinationen der Client- und Server- 

Strategien – wie oft wird der Druckauftrag ausgeführt 

⇒ Keine Strategie-Kombination, ist stets erfolgreich 

Client 

Server 

Strategie M P 

Strategie P M 

Wiederholung 

MPC 

MC(P) 

C(MP) 

PMC 

PC(M) 

C(PM) 

immer 

DUP 

OK 

OK 

DUP 

DUP 

OK 

niemals 

OK 

ZERO 

ZERO 

OK 

OK 

ZERO 

nur wenn bestätigt 

DUP 

OK 

ZERO 

DUP 

OK 

ZERO 

nur wenn nicht bestätigt 

OK 

ZERO 

OK 

OK 

DUP 

OK 


Asynchronous RPC 

> Synchronous RPC most common 

> Sun RPC, DCE, J2EE, CORBA, .NET etc. 

> Asynchronous RPC 

⇒ Client is not blocked while waiting for reply 

> Two common approaches 

> Callback is executed when reply arrives 

(⇒ results are processed in a different context!) 

> Client polls local proxy for reply either non-blocking or 

blocking (with or without timeout) 


Asynchronous RPC – Examples 

Request 

Request 

Request 

local 

polling 

processing 

of request 

Ack. 

blocking 

wait 

Reply 

Reply 

Reply 

callback 

invoked 

Client 

Server 

Client 

Server 

Client 

Server 


Multicast RPC 

> Mehrere Instanzen der gleichen Prozedur 

(z.B. auf verschiedenen Rechnern) werden mit einem 

einzigen Aufruf aufgerufen 

> Für die Verarbeitung der Resultate gibt es mehrere 

Möglichkeiten 

> Die zuerst eintreffenden Resultate werden zurückgeliefert 

> Die eintreffenden Resultate werden zusammengefasst 

(z.B. per Mehrheitsentscheidung) und ein Resultat wird 

zurückgegeben 

> … 


Remote Method Invocation (RMI)

Remote Method Invocation (RMI) 

> Übertragung des Konzeptes des entfernten 

Prozeduraufrufes auf objektorientierte 

Programmiersprachen Entfernter Methodenaufruf 

> Objekt = Zustand + Verhalten (Methoden) 

> Zustand alleine nützt (meist) nichts 

⇒ Übertragung von Objekten by value oder by copy/restore 

ist in heterogenen Systemen problematisch 

> Der Aufgerufene muss Zugriff auf die Implementierung der 

Methoden haben und diese auch ausführen können 

⇒ Häufig können Objekte daher nur per reference 

übergeben werden Entfernte Objektreferenz 


Entfernte Objektreferenz 

> Identifiziert ein Objekt eindeutig in einem verteilten 

System 

> Exemplarischer Aufbau 

> IP-Adresse des Servers + TCP-Portnummer 

> Objektkennung 

192.168.0.1:4444:123456 


Distributed Object Middleware 

> Middleware-Plattformen basierend auf dem Konzepts des 

entfernten Methodenaufrufes 

> Beispiele 

> Common Object Request Broker Architecture (CORBA) 

> Java 2 Enterprise Edition (J2EE) 

> .NET 

> … 


Common Object Request Broker Architecture 

(CORBA)

Object Request Broker (ORB) 

> "Software Bus" für verteilte Objektsysteme 

> Wie ein Hardware-Bus verschiedene Hardware- 

Komponenten verbindet, so verbindet der ORB 

verschiedene Software-Komponenten 

Object 

Request 

Broker 


Objektmodell 

Client 

> Instanz einer Klasse 

> Hat einen Zustand 

> Besitzt "Namen" und Lebenszeit 

> Objekt 

> Klasse 

> Schablone für Objekte 

> Verfeinerung durch Vererbung 

> Polymorphe Substitution 

> Schnittstelle (Interface) eines Objektes 

> Methoden und Attribute 

> Kapselung der Implementierung 

Schnittstelle 

Server 


Object Request Broker (ORB) 

> Einbettung von Objekt-Implementierungen 

("Server-Objekte") 

> Vergabe von Objektreferenzen 

> Entgegennehmen von Aufrufen des Clients 

> Transport der Aufrufe zum Server 

> Ggf. Aktivierung eines Server-Objektes 

> Übergabe des Aufrufs an das Server-Objekt 

> Entgegennehmen von Ergebnissen und Transport / 

Rückgabe an den Client 

> Unterstützung von Sicherheits- und 

Abrechnungsfunktionen 


CORBA-Schnittstellen 

Client 

Objekt-Implementierung 

Dynam. 

Aufruf 

IDL 

Stub 

ORB 

Interface 

Dynam. 

Skeleton 

IDL 

Skeleton 

Objekt- 

Adapter 

Interface Repository 

ORB-Kern 

Implementation Rep. 

standardisiert 

intern 

Anwendung 


CORBA IDL 

Schnittstelle 

Client 

C 

C++ 

Smalltalk 

Cobol 

Ada 

Java 

..... 

IDL 

Server 

interface Quoter { 

double get_quote (in string stock_name); 

}; 

 


Entwicklung einer Anwendung 


..... 

}; 

IDL 

IDL Compiler 

Client Stub 

Server Skeleton 

Client 

Server 


Ablauf 

1. Definition der Schnittstellen in IDL 

2. Mittels IDL-Compiler Stubs und Skeletons generieren 

3. Implementierung des Klienten 

4. Implementierung des Servants 

(d.h., der Objektimplementierung) 

5. Implementierung des Servers 

6. Registrierung des Servants beim ORB 

7. Methodenaufrufe des Klienten auf dem Objekt 


Statische Aufrufe 

> Verwenden das Static Invocation Interface (SII) 

> Schnittstellen stehen zur Compile-Zeit fest 

> IDL-Compiler erzeugt aus den Schnittstellen die Stubs 

> Typüberprüfung schon zur Compile-Zeit möglich 

> Stub vertritt die lokal nicht vorhandenen Prozedur 

> Kaum Unterschiede zum lokalen Aufruf 


Dynamische Aufrufe 

> Verwenden das Dynamic Invocation Interface (DII) 

> DII ist unabhängig von der konkreten Schnittstelle des 

aufgerufenen Objekts 

> Vorteil: Schnittstelle muss nicht zur Compile-Zeit 

vorliegen, da Aufruf zur Laufzeit zusammengestellt wird 

> Allerdings deutlich mehr Code notwendig 

> Normalerweise deutlich ineffizienter, als statische Aufrufe 

> Typüberprüfung erst zur Laufzeit möglich 

> Folgende Angaben sind für einen Aufruf notwendig 

> Objekt, Operation, Argumente (Anzahl, Typ, Modus, Wert), 

Rückgabetyp 


Ablauf eines dynamischen Aufrufs 

1. Objektreferenz beschaffen (z.B. über Name Service) 

2. Schnittstelle bestimmen (z.B. im Interface Repository) 

3. Request Pseudo Object erzeugen und füllen 

( = Behälter für die zum Aufruf gehörenden Informationen) 

4. Request Pseudo Object an ORB übergeben 

( = Starten des Aufrufs) 

5. Auf Ergebnis warten (optional) 

6. Request Pseudo Object löschen oder wieder verwenden 


Mögliche Aufrufarten mit dem SII und dem DII 

> Synchroner Aufruf 

> Client blockiert bis Antwort zurück (oder Fehler) 

> Aufruf- und Rückgabeparameter möglich 

> Möglich für statische und dynamische Aufrufe 

> Oneway Aufruf ( = "fire and forget“ ) 

oneway void sayGoodBye(...); 

> Kein Rückgabewert oder Rückgabeparameter 

> Keine Exceptions bei Fehlern 

> Semantik hängt vom ORB ab 

(können z.B. auch blockierend sein!) 

> Möglich für statische und dynamische Aufrufe 


Mögliche Aufrufarten mit dem SII und dem DII 

> Asynchroner Aufruf (Deferred Synchronous) 

> Client blockiert nicht 

> Aufruf- und Rückgabeparameter möglich 

> Zustand des Request-Objekts kann abgefragt werden 

> Nur möglich für dynamische Aufrufe 

> Bedarf für asynchrone Aufrufe mittels des SIIs AMI 


Mögliche Aufrufarten mit dem AMI 

> CORBA Messaging (ab CORBA 2.3) ermöglicht asynchrone 

Aufrufe mit dem SII Asynchronous Method Invocation (AMI) 

> AMI unterstützt zwei Modelle 

> Callback Model 

> Client gibt dem Aufruf eine Objektreferenz für Antwort mit 

> ORB benutzt diese Objektreferenz, um Antwort abzuliefern 

> Client muss als Server agieren 

> Ergebnis wird nicht im Kontext des Aufrufenden verarbeitet 

> Polling Model 

> Aufruf gibt sofort ein Pseudo-Objekt zurück 

> Client kann an diesem Objekt pollen bzw. warten 

> Ergebnis wird im Kontext des Aufrufenden verarbeitet 


Zusammenfassung der möglichen Aufrufarten 

Static Invocation 

Interface (SII) 

Dynamic Invocation 

Interface (DII) 

Asynchronous 

Invocation 

Interface (AMI) 

Two-Way 

Synchronous Call 

Oneway 

Call 

Deferred 

Synchronous Call 

Asynchronous 

Call (Callback) 

Asynchronous 

Call (Polling) 


CORBA Beispiel: Stock Quote Server 

> Szenario: Aktienkurse sollen von einem Server an eine Menge 

von Clients zugestellt werden 

> Mehrere Implementierungen sind möglich 

> Pull: Der Server bietet über eine Schnittstelle die aktuellen Kurse 

diverser Aktien an; Clients fragen diese (periodisch) ab 

> Synchrone Aufrufe (SII oder DII möglich) 

> Asynchrone Aufrufe mit dem DII 

> Asynchrone Aufrufe mit AMI (Callback oder Polling Model) 

> Push: Clients registrieren Callbacks beim Server; dieser ruft beim 

Vorliegen eines neuen Kurses den Callback beim Client auf 

> Synchrone Aufruf (SII oder DII möglich) 

> Oneway-Aufrufe 


1. Implementierungsmöglichkeit: Pull

CORBA Example: Stock Quote Server 

module Stock 

// CORBA IDL implemented by server developer 

{ 

// Requested stock does not exist. 

exception Invalid_Stock {}; 


// Two-way operation to retrieve current stock value. 

double get_quote (in string stock_name) 

raises (Invalid_Stock); 

}; 

} 

// ... 


Used Classes 

Quoter 

double get_quote ( 

in string stock_name) 

… 

IDL written by server developer 

Stubs generated by IDL compiler 

Servant implemented by server developer 

Stock::QuoterBOAImpl 


const char *stock_name) 

Quoter_var 



… 

Client-Side 

RMI 

MyQuoter 



Server-Side 


Example: Stock Quote Server 

(Servant) 

// C++ implementation class for IDL interface. 

class My_Quoter 

// Inherits from a generated CORBA skeleton class. 

: virtual public Stock::QuoterBOAImpl 

{ 

public: 

My_Quoter (Quote_Database *db): db_ (db) {} 

// Invoked by the CORBA skeleton. 

virtual double get_quote (const char *stock_name) 

throw (Stock::Invalid_Stock) { 

double value = 

db_->lookup_stock_price (stock_name); 

if (value == -1) throw Stock::Invalid_Stock(); 

return value; 

} 

private: 

Quote_Database *db_; 

}; 



(Server Side) 

// Pointer to online stock quote database. 

extern Quote_Database *quote_db; 

int main (int argc, char *argv[]) 

{ 

// Initialize the ORB and the BOA. 

CORBA::ORB_var orb = CORBA::ORB_init (argc, argv, 0); 

CORBA::BOA_var boa = orb->boa_init (argc, argv, 0); 

// Create an object implementation. 

My_Quoter quoter (quote_db); 

} 

// Single-threaded event loop that handles CORBA 

// requests by making callbacks to the user-supplied 

// object implementation of My_Quoter. 

boa->impl_is_ready (); 

/* NOTREACHED */ 

return 0; 



(Client Side) 

int main (int argc, char *argv[]) 

{ 

CORBA::Object_var obj = 

orb -> string_to_object(argv[1]); 

Quoter_var q = Quoter::_narrow (obj); 

} 

const char *stock_name = "ACME ORB Inc."; 

try { 

double value = q -> get_quote (stock_name); 

return 0; 

} catch (Invalid_Stock &) { 

return 1; 

} 


Deferred Synchronous Invocations mit dem DII 

void get_stock_quotes(Stock::Quoter_ptr quoter_ref) 

{ 

CORBA::Request_var *requests[NUM_STOCKS]; 

for (i = 0; i < NUM_STOCKS; i++) { 

requests[i] = quoter_ref -> _request ("get_quote"); 

requests[i] -> add_in_arg () send_deferred (); 

} 

} 

for (i = 0; i < NUM_STOCKS; i++) { 

requests[i] -> get_response(); 

quotes[i] = request->return_value (); 

} 

> Concurrent calls can be issued since calls are non-blocking 

> Here, the overall execution time is dominated by the longest call 


Asynchronous Method Invocation 

> IDL compiler generates additional stubs for asynchronous 

calls implied IDL 

> One version for the polling and one for the callback model 

> Clients must be rewritten to use asynchronous calls 

> Servers does not need to be changed 


Used Classes (AMI Polling Model) 

Quoter 



AMIQuoterPoller 

void get_quote ( 

long timeout, 

double ami_return_val) 

Quoter_var 



AMI_QuoterPoller* sendp_get_quote ( 

const char *stockname) 

… 


Stub generated by IDL compiler 

Poller object generated by IDL compiler 


CORBA: AMI Polling Model (Client) 

void get_stock_quotes(Stock::Quoter_ptr quoter_ref) { 

// C++ implemented by client developer 

Stock::AMI_QuoterPoller *pollers[NUM_STOCKS]; 

// issue calls to get stock quotes from exchange 

for (i = 0; i < NUM_STOCKS; i++) 

pollers[i] = 

quoter_ref -> sendp_get_quote(stock_symbols[i]); 

// collect replies 


pollers[i] -> get_quote(MAX_TIMEOUT, quotes[i]); 

} 

> Relies on the tedious Objects-by-Value (OBV) specification 

> The execution time is dominated by largest request duration 

> Reply handled in the context of the caller 


CORBA: AMI Polling Model (Poller Objects) 

> AMI_QuoterPoller is a valuetype generated by the IDL 

compiler object instances are always collocated and, 

therefore, calls to them are local 

namespace Stock { 

// C++ generated by IDL compiler 

class AMI_QuoterPoller : public Messaging::Poller { 

public: 

virtual void get_quote ( 

long timeout, 

double ami_return_val); 

}; 

}; 


CORBA: AMI Polling Model (sendp_ methods) 

> sendp_ methods are also generated by the IDL compiler 

namespace Stock { 

// C++ generated by IDL Compiler 

class Quoter : public virtual CORBA::Object 

{ 

public: 

Stock::AMI_QuoterPoller* 

sendp_get_quote (const char *stockname); 

// ... 

}; 

}; 


Used Classes (AMI Callback Model) 

Quoter 



AMI_QuoterHandler 


double d) 

StockHandler 


double d) 

Quoter_var 



void sendc_get_quote( 

AMI_QuoterHandler_ptr, 

const char *stockname); 

… 


Stubs generated by IDL compiler 

Callback to be implemented by client developer 


CORBA: AMI Callback Model (Client) 

void get_stock_quotes(Stock::Quoter_ptr quoter_ref) { 

// C++ implemented by client developer 

// Initialize handler servants 


handlers[i] = new Stock_Handler(i); 

// Initialize handler object references 


handler_ref[i] = handlers[i]->_this (); 

} 

// Issue asynchronous calls using the callback model 


quoter_ref -> sendc_get_quote 

(handler_ref[i], stock_symbols[i]); 


CORBA: AMI Callback Model (send_c methods) 

namespace Stock 

{ 


class Quoter : public virtual CORBA::Object 

{ 

public: 

void sendc_get_quote(Stock::AMI_QuoterHandler_ptr, 

const char *stockname); 

// ... 

}; 

}; 


CORBA: AMI Callback Model (Handler Objects) 

namespace POA_Stock 

{ 


class AMI_QuoterHandler 

: public POA_Messaging::ReplyHandler 

{ 

public: 

virtual void get_quote (CORBA::Double d) = 0; 

virtual void get_quote_excep 

(Stock::AMI_QuoterExceptionHolder *excep)= 0; 

}; 

}; 


CORBA: AMI Callback Model (Client Servant) 

class Stock_Handler 

: public POA_Stock::AMI_QuoteHandler 

{ // C++ implemented by client developer 

public: 

Stock_Handler(const int i){ i_=i; } 

virtual void get_quote(CORBA::Double value) 

throw (CORBA::SystemException) 

{ quotes[i_] = value; } 

virtual void get_quote_excep 

(Stock::AMI_QuoterExceptionHolder *excep) 

throw (CORBA::SystemException, Stock::Invalid_Stock) 

{ ... } 

} 

private int i_; 


2. Implementierungsmöglichkeit: Push

Callbacks using oneway Methods 

> Clients call the register_callback method to register a callback at 

the server 

> Server calls callback to deliver new quote 

> Requires clients to behave as a “server” 

> Using synchronous calls for callbacks would raise the problem 

that the server could be blocked by a “slow” client 

> oneway IDL keyword in interface 

> Indicates that no reply should be passed back to the caller 

> Best effort and (not guaranteed to be) non-blocking 

> Application must handle end-to-end reliability 

> Semantic depends on ORB implementation 


Callbacks using One-Way Methods 

module Stock { // CORBA IDL 

... 

module Callback 

{ 

struct Info 

{ 

string stock_name; double value; 

}; 

interface Handler 

{ 

// Oneway method called by quote server to 

// deliver new quote 

oneway void push(in Info data); 

}; 

}; 


Callbacks using One-Way Methods 

}; 

}; 

interface Notifying_Quoter 

{ 

// Called by clients to register a callback 

void register_callback(in string stock_name, 

in Callback::Handler handler) 


// Called by clients to unregister a callback 

void unregister_callback(in string stock_name, 

in Callback::Handler handler) 



Client‘s Callback Implementation 

class My_CallBack 

: public POA_Stock::Callback::Handler 

{ 

public: 

// Handle callback from quoter supplier. 

void push (const Stock::Callback::Info& info) 

{ 

double price = info.value; 

string stock_name = info.stock_name; 

... 

} 

}; 


Client Implementation 

int main (int argc, char** argv) 

{ 

// Initialize the ORB and the BOA. 

CORBA::ORB_var orb = CORBA::ORB_init (argc, argv, 0); 

CORBA::BOA_var boa = orb->boa_init (argc, argv, 0); 

// Create a new implementation object. 

My_Callback* cb = new My_Callback; 

// Get the callback object reference. 

Callback::Handler_var handler = cb->_this (); 


Client Implementation 

// Obtain a Notifying_Quoter object reference, 

// e.g., from the Naming or Trader service 

Notifying_Quoter_var quoter = // ... 

// Register callback with the supplier. 

quoter -> register_callback 

("ACME ORB Inc.", handler); 

} 

// Now instruct the object adapter to 

// wait for callbacks from the supplier. 

boa->impl_is_ready (); 

/* NOTREACHED */ 


Bibliography 

1. Object Management Group (OMG). CORBA Messaging Specification. OMG Document 

orbos/98-0505, May 1998. 

2. D. C. Schmidt and S. Vinoski. Comparing Alternative Client Distributed Programming 

Techniques. C++ Report, 7(4), May 1995. 

http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col3.pdf 

3. D. C. Schmidt and S. Vinoski. Distributed Callbacks and Decoupled Communication in CORBA. 

C++ Report, 8(9), Oct. 1996. 


4. D. Schmidt and S. Vinoski. An Introduction to CORBA Messaging. C++ Report, 10(10), Nov. 

1998. 


5. D. C. Schmidt and S. Vinoski. Programming Asynchronous Method Invocations with CORBA 

Messaging. C++ Report, 11(2), Feb. 1999. 


6. D. Schmidt and S. Vinoski. Time-Independent Invocation and Interoperable Routing. C++ 

Report, 11(4), Apr. 1999. 


7. Microsoft Corp. .NET Framework Developer's Guide: Asynchronous Programming Overview. 

http://msdn.microsoft.com/library/default.aspurl=/library/enus/cpguide/html/cpovrasynchronousprogrammingoverview.asp

Middleware-Konzepte Entfernte Aufrufe

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?