Projektstudium SS98 - distributed computingProjektstudium SS98 - distributed computing
Dieser Abschnitt beschreibt wie Objekte implementiert und Client Anwendungen zur Verfügung gestellt werden. Zusätzlich wird gezeigt wie Server und Objekte aktiviert werden sowie der Baisc Object Adapter verwendet wird.
VisiBrokers Basic Object Adapter (BOA) bietet verschiedene Funktionen für Client Anwendungen und Objekt Implementationen an. Zu diesen angebotenen Funktionen gehören:
Es wichtig zu erkennen, daß eine Objekt Implementation entweder im selben Prozeß wie der Client oder als separater Prozeß residieren kann. Im Falle der zweiten Variante wird dieser separate Prozeß als Server bezeichnet. Server können ein oder mehrere Objekte anbieten. Weiterhin können Server durch den BOA bei Bedarf aktiviert werden oder durch eine externe Entität gestartet werden.
VisiBroker besitzt mehrere Adapter Typen, die durch
BOA_init() mit Eingabe des Adaptertyps initialisiert werden:
TPool TSession SSLTPool SSLTSession
Mit
BOA_init() wird der Adaptertyp und dessen Eigenschaften gesetzt. Von BOA_init() existieren die folgenden Versionen:
BOA_init() BOA_init() null anstelle der Eigenschaften BOA_init() übergeben.
Jeder
BOA_init() Aufruf gibt eine Instanz des spezifizierten Objekt Adapters zurück, wobei beachtet werden muß, daß immer nur die gleiche Instanz des Objekt Adapters zurückgegeben wird. Wenn BOA_init() ohne Argumente aufgerufen wird, wird eine Instanz von TPool zurückgegeben. Wenn BOA_init() mit einem TPool Argument und irgendwelchen Eigenschaften aufgerufen wird, wird das bereits existierende TPool modifiziert. Wird immer wieder BOA_init() mit dem gleichen Typ aufgerufen, so wird geprüft ob Unterschiede zum vorherigen Aufruf von BOA_init() bestehen und wenn dies der Fall ist, werden die Eigenschaften aktualisiert.
VisiBroker implementiert drei verschiedene Aktivierungsstrategien, die jeweils einen anderen Ansatz bezüglich des Startens und Zugriffes auf einen Server bilden, wobei angemerkt werden muß, daß diese Aktivierungsstrategien nur für globale Objekte gelten:
Wenn die Shared Server Strategie spezifiziert wird, kann auf den Server von mehr als einem Client zugreifen, was dazu führt, daß mehrere Clients sich die gleiche Implementation teilen.
Bei dieser Strategie greift immer nur ein Client auf den Server zu, was bedeutet, daß immer nur ein Client mit einem solchen Server verbunden sein wird. Wenn mehrere Clients mit der gleichen Objekt Implementation verbunden sein wollen, wird wird für jeden Client ein separater Server aktiviert.
Bei dieser Aktivierungsstrategie wird für jeden Methodenaufruf ein Serverprozeß gestartet. Nachdem die Methode ausgeführt wurden ist, hört der Server auf zu existieren.
Eine Objekt Implementation bietet ORB Objekten Status- und Prozeß Aktivitäten. Ein ORB Objekt wird erzeugt, wenn eine Instanz von dessen Implementationsklasse in Java gebildet wird.. Eine Objekt Implementation verwendet die BOA zur Aktivierung des eigenen ORB Objektes, so daß es von Client Anwendungen verwendet werden kann.
Objektreferenzen, die nur während der Laufzeit des Prozesses, der sie erzeugt hat, verfügbar sind, werden als transient object references bezeichnet und nicht beim Smart Agent oder Object Activation Daemon (OAD) registriert und sind somit für sie nicht sichtbar. Nur die Entitäten, die eine explizite Objektreferenz zu einer transienten Objektreferenz besitzen, können die Methoden der Objektreferenz aufrufen. Eine transiente Objektreferenz kann dadurch erzeugt werden, daß beim Bilden einer Instanz des Objektes kein Name angegeben wird.
class CountServer {
static public void main(String[] args) {
try {
//Initialisierung des ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
//Initialisierung des BOA
org.omg.CORBA.BOA boa = orb.BOA_init();
//Erzeugen eines Count Objektes
CountImpl count = new CountImpl();
//Exportieren des neu erzeugten Objektes an den ORB
boa.obj_is_ready(count);
//Exportieren des neu erzeugten Objektes
boa.impl_is_ready(count);
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
Persistente Objektreferenzen werden erzeugt, wenn bei der Erzeugung einer Instanz Objektes ein Name angegeben wird. Persistente Objektreferenzen bleiben über die Lebenszeit des Prozesses, der sie erzeugt hat, hinaus gültig. Diese Objektrefrenzen besitzen eine globale Sichtweise und sind beim osagent registriert. Die Registrierung beim osagent erfolgt durch den
BOA.obj_is_ready Aufruf.
class CountServer {
static public void main(String[] args) {
try {
//Initialisierung des ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
//Initialisierung des BOA
org.omg.CORBA.BOA boa = orb.BOA_init();
//Erzeugen eines Count Objektes
CountImpl count = new CountImpl("My Count");
//Exportieren des neu erzeugten Objektes an den ORB
boa.obj_is_ready(count);
//Exportieren des neu erzeugten Objektes
boa.impl_is_ready(count);
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
Die
Object._is_persistent Methode erlaubt den Client Anwendungen zu bestimmen, ob eine Objektrefernz persistent oder transient ist. Es ist wichtig zu wissen, ob eine Objektreferenz persistent oder transient ist, da einige Methoden für die Manipulation von Objektreferenzen bei transienten Objektreferenzen fehlschlagen. Die _is_persistent Methode liefert true zurück, wenn die Referenz persteistent ist und ansonsten false.
Nachdem ein Server von den von ihm angebotenen ORB Objekten eine Instanz hat, muß der BOA bestätigen, wenn ein Objekt initialisiert wurde. Zuletzt muß der BOA bestätigen, wenn der Server zum Erhalten von Anfragen von Client Anwendungen bereit ist.
Die obj_is_ready Methode bestätigt, daß ein bestimmtes ORB Objekt bereit für den Empfang von Anfragen von Client Anwendungen ist. Wenn der Server mehr als ein Objekt den Client Anwendungen anbietet, muß die obj_is_ready Methode für jedes Objekt mit der Objektreferenz als Argument aufgerufen werden.
Wenn ein persistentes Objekt der obj_is_ready Methode übergeben wurde, wird der BOA das Objekt in VisiBrokers osagent registrieren, was hingegen bei einer transienten Referenz nicht geschieht.
Im in
Eine erste JavaCORBA Anwendung eingeführtem Beispiel wurde das Objekt direkt durch den Server aktiviert. Es muß für jede Objekt Implementation durch den Server eine Instanz gebildet werden. Dazu wird dieboa.obj_is_ready Methode für jedes Objekt und danach boa.impl_is_ready aufgerufen. Das unten stehende Listing verdeutlicht dieses Vorgehen.
class CountServer {
static public void main(String[] args) {
try {
//Initialisierung des ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
//Initialisierung des BOA
org.omg.CORBA.BOA boa = orb.BOA_init();
//Erzeugen der Count Objekte
CountImpl count1 = new CountImpl("My Count1");
CountImpl count2 = new CountImpl("My Count2");
//Exportieren des neu erzeugten Objektes an den ORB
boa.obj_is_ready(count);
//Exportieren der neu erzeugten Objekte
boa.impl_is_ready(count1);
boa.impl_is_ready(count2);
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
Eine Objektimplementation, die manuell gestartet wurde, kann als deaktiviert bezeichnet werden, wenn der Server, der das Objekt implementiert, nicht mehr existiert. Dann werden die Objekte automatisch aus der Registrierung entfernt.
Implementationen, die mit dem Aufruf
boa.obj_is_ready aktiviert wurden sind, werden mit boa.deactive_obj explizit deaktiviert. Nachdem diese Methode aufgerufen wurden ist, ist die Implementation für Client Anfragen nicht mehr verfügbar.
Es sollte beachtet werden, daß
boa.deactive_obj nur eine Deaktivierung des entsprechenden Objektes bewirkt. Soll der Server heruntergefahren werden, so muß die Methode ORB.shutdown() verwendet werden.
© Copyright 1998 André Möller, Oliver Mentz & Magnus Wiencke