Bindung des Netscape Application Servers an CORBA 

Zurück Weiter

Der CORBA Server

Als Anwendungsfall wählten wir eine Bank, die auf einem CORBA-System vom Typ OrbixWeb2.0 implementiert wurde. Diese Bank hat zwei Klassen von Objekten: Die Klassen bank und account. Die Klasse bank verwaltet accounts mit den Methoden newAccount(.), findAccount(.) und deleteAccount(.). Ein account hat die Attribute name und balance und die Methoden makeLodgement(.) (macheEinzahlung) und makeWithdrawal(.) (macheAuszahlung). Listing 1 zeigt die CORBA-IDL.

//
// a simple description of a bank account
//
 interface account {
    readonly attribute string name;
    readonly attribute float balance;
 
    void makeLodgement (in float amount);
    void makeWithdrawal (in float amount);
 
 };
 
//
// a bank simply manufactures accounts
//
//  bank::reject is raised if a duplicate account name
//  is seen
//
 interface bank {
 
    exception reject {string reason;};
 
    account newAccount (in string name) raises (reject);
    account findAccount (in string name);
    void deleteAccount (in account anAccount);
 };

 
Grafik 3: NAS in Verbindung mit einem CORBA Server (Quelle: Präsentation von Prof. Dr. Schmauch)

Wenn wir nun CORBA zu einer Applikation hinzufügen, fügen wir eine zweite Client/Server Architektur neben der des NAS ein. Wir setzen den CORBA-Server in eine Reihe zusammen mit Datenbanken und bereits existierenden Systemen, wie in Grafik 3 ersichtlich.

Eine NAS-Applikation, die sich an einen CORBA Server bindet, tut dies durch AppLogics. Diese rufen Methoden an den entfernten CORBA Objekten auf, empfangen Ergebnisse, und bereiten die Antwortseiten vor, die diese Ergebnisse anzeigen. Im Fall unseres Bank-Servers könnte ein AppLogic die Methode makeLodgement(.) an einem vorher erhaltenen account aufrufen, um Geld einzuzahlen - und anschließend eine Seite zurückgeben, die den aktuellen Kontostand angibt. Das Erhalten des account Objektes wird gewöhnlich im Voraus von einem anderen AppLogic erledigt. Deshalb müssen NAS-Applikationen, die ja aus einer Menge von HTML-Seiten und AppLogics bestehen, die Referenzen auf CORBA Objekte über verschiedene Adreßräume hinweg verwalten: Im Browser des Clients, in den verschiedenen AppLogics, die zu einer Applikation gehören und sogar über mehrere NAS hinweg muß der aktuelle Zustand der Applikation bekannt sein.

Dies lösten wir, indem wir die CORBA Objektreferenz als Zeichenkette zusammen mit einem eindeutigen Identifizierer (UID) im Session-Objekt speicherten, das vom Session- und State-Management des NAS zur Verfügung gestellt wird. Anschließend leiteten wir die UID an die HTML-Seite weiter. Diese Verfahrensweise erlaubt dem Programmierer, die Applikation voll zu kontrollieren; sogar das viel gefürchtete Drücken des "zurück"-Knopfes im Browser, welches den Status einer Applikation durcheinanderbringen kann, ist somit kontrollierbar.