Bindung des Netscape Application Servers an CORBA 

Zurück Weiter

Die Architektur des Netscape Application Servers

NAS Applikationen basieren auf einer Client/Server Architektur. Wie Grafik 1 zeigt, gibt es in dieser Architektur drei oder vier Schichten, je nach Art der verwendeten Clients:

1. Die Benutzerschnittstelle, das ist entweder eine HTML-Seite in einem Browser (HTML-Client), oder ein sogenannter "Thin-Client", der per IIOP (Internet Inter-ORB Protokoll) direkt mit dem Application Server kommuniziert.
2. Applikations-Publishing, hierbei handelt es sich um den Web-Server, der die Anfragen eines HTML-Clients an den Application Server weiterleitet (wird für Thin-Clients nicht benötigt).
3. Application Server, der ggf. mit der IV. Schicht kommuniziert und ein errechnetes Ergebnis entweder als HTML-Code an den Web-Server oder mit IIOP an den Thin-Client weitergibt.
4. Datenbanken und bereits existierende Systeme, die mit dem Netscape Application Server verbunden sind.

Grafik 1: Die Architektur des Netscape Applikation Servers (Quelle: Netscape Präsentationen)

Ich betrachte in meinem Bericht ausschließlich die Möglichkeit, den Netscape Application Server (NAS) mit HTML-Clients anzusprechen, das ist die Vier-Schicht-Methode.

Es ist darauf zu achten, daß hierbei die Präsentationsschicht von der Geschäftslogik getrennt ist. Web-basierte Clients benutzen einen Web-Browser, der HTML-Seiten anzeigt; während der Anteil der Applikation, der auf dem Server ist, aus Java oder C++ Objekten besteht. Diese Objekte haben jeweils eine Standardmethode, die "execute" Methode, die aufgerufen wird, wenn ein Client eine Anfrage stellt. Die Java und C++ Objekte heißen "AppLogics", und eine Applikation besteht aus einer Menge von AppLogics und HTML-Seiten.

Der Kontrollfluß einer Applikation ist ein Fluß durch eine Reihe von HTML-Seiten und AppLogics, die Daten untereinander austauschen können. Da ein AppLogic seine referierten Objekte verliert, wenn die execute-Methode endet, wird ein sog. "Session and state management" zur Verfügung gestellt, das Daten speichert. Die Daten, die in Session- und State-Objekten gespeichert werden, können dadurch zwischen AppLogics und HTML-Seiten ausgetauscht werden.

Grafik 2 zeigt zwei AppLogics, die zu einem Session-Objekt verweisen, das auf die gemeinsamen Daten verweist.

Grafik 2: Kontroll- und Datenfluß zwischen zwei AppLogics (Quelle: Netscape Präsentationen)