Vorbereitende Schritte
Vergewissern Sie sich, dass Ihr Client eine Referenz auf die Schnittstelle "UserWorkArea"
(siehe die Beschreibung im Artikel "Auf die UserWorkArea-Partition zugreifen") oder eine Referenz auf eine benutzerdefinierte
Partition enthält (siehe die Definition im Artikel "Auf eine benutzerdefinierte Arbeitsbereichspartition zugreifen").
In den
folgenden Schritten wird die Verwendung der UserWorkArea-Partition veranschaulicht. Eine
benutzerdefinierte Partition kann jedoch auf exakt dieselbe Weise verwendet werden.
Informationen zu diesem Vorgang
In einer Geschäftsanwendung, die Arbeitsbereiche verwendet,
rufen die Serverobjekte normalerweise die Eigenschaften des Arbeitsbereichs ab und verwenden
sie für die Ausführung der lokalen Arbeit.
Vorgehensweise
- Rufen Sie den Namen des aktiven Arbeitsbereichs ab, um festzustellen, ob der aufrufende Thread
einem Arbeitsbereich zugeordnet ist.
Anwendungen verwenden die Methode
"getName" der Schnittstelle "UserWorkArea", um den Namen des aktuellen Arbeitsbereichs
abzurufen. Falls der Thread keinem Arbeitsbereich zugeordnet ist, gibt die Methode
"getName" null zurück. Im folgenden Codebeispiel entspricht der Name des Arbeitsbereichs dem Namen der Klasse,
in der der Arbeitsbereich begonnen wurde.
public class SimpleSampleBeanImpl implements SessionBean {
...
public String [] test() {
// Die Referenz zum Arbeitsbereich aus JNDI abrufen.
...
// Den Namen des Arbeitsbereichs abrufen. In diesem Beispiel
// gibt der Name die Klasse an, in der der Arbeitsbereich
// begonnen wurde.
String invoker = userWorkArea.getName();
...
}
}
- Eigenschaften des Arbeitsbereichs überschreiben. Serverobjekte können die Eigenschaften des Clientarbeitsbereichs überschreiben, indem sie
einen eigenen, verschachtelten Arbeitsbereich erstellen. Weitere Informationen finden Sie im Artikel
"Eigenschaften des Arbeitsbereichs überschreiben".
- Rufen Sie mit der get-Methode Eigenschaften von einem Arbeitsbereich ab.
Die get-Methode ist absichtlich schlank. Es sind keine Ausnahmen deklariert, die behandelt werden müssen. Ist kein aktiver Arbeitsbereich vorhanden oder ist die abgefragte Eigenschaft
im aktuellen Arbeitsbereich nicht vorhanden, gibt die Methode
"get" null zurück.
Wichtig: In dem relativ seltenen Fall, dass CORBA-Clients
komplexe Datentypen festlegen und Enterprise-Bean-Schnittstellen aufrufen,
kann die Methode "get" die Ausnahme
"NotSerializableError" auslösen.
Das folgende Beispiel zeigt das Abrufen der Eigenschaften
für die Site Site-ID und die Priorität durch die
SimpleSampleBean. Beachten Sie, dass das eine Eigenschaft im
äußeren (übergeordneten) Arbeitsbereich durch den Client festgelegt wurde und die
andere Eigenschaft im verschachtelten Arbeitsbereich von der Bean auf Serverseite definiert wurde.
Die Verschachtelung ist beim Abrufen der Eigenschaften transparent.
public class SimpleSampleBeanImpl implements SessionBean {
public String [] test() {
...
// Einen verschachtelten Arbeitsbereich beginnen.
userWorkArea.begin("SimpleSampleBean");
try {
userWorkArea.set("company",
SimpleSampleCompany.London_Development);
}
catch (NotOriginator e) {
}
SimpleSampleCompany company =
(SimpleSampleCompany) userWorkArea.get("company");
SimpleSamplePriority priority =
(SimpleSamplePriority) userWorkArea.get("priority");
...
}
}
- Optional: Rufen Sie eine Liste aller Schlüssel ab, die über einen Arbeitsbereich sichtbar sind.
Die Schnittstelle "UserWorkArea" stellt die Methode
"retrieveAllKeys" bereit, mit
der eine Liste aller Schlüssel abgerufen werden kann, die in einem Arbeitsbereich sichtbar sind. Diese
Methode verwendet keine Argumente und gibt einen Array mit Zeichenfolgen zurück. Falls dem Thread kein Arbeitsbereich zugeordnet ist, gibt
die Methode "retrieveAllKeys" null zurück. Ist dem Thread ein Arbeitsbereich zugeordnet, der keine Eigenschaften enthält,
gibt die Methode einen Array mit der Größe 0 zurück.
- Fragen Sie den Modus einer Arbeitsbereichseigenschaft mit der Methode "getMode" ab.
Die Schnittstelle "UserWorkArea" stellt die
Methode "getMode" bereit, mit der der Modus einer bestimmten Eigenschaft abgefragt
werden kann. Diese Methode verwendet
den Schlüssel der Eigenschaft als Argument und gibt den Modus
als PropertyModeType-Objekt zurück. Falls der angegebene Schlüssel im Arbeitsbereich nicht
existiert, gibt die Methode "PropertyModeType.normal" zurück. Damit zeigt sie an,
dass die Eigenschaft festgelegt und entfernt werden kann, ohne dass ein Fehler zurückgegeben wird.
- Optional: Löschen Sie eine Arbeitsbereichseigenschaft.
Die Schnittstelle "UserWorkArea" stellt die Methode
"remove" bereit, mit der eine Eigenschaft aus dem aktuellen Geltungsbereich eines Arbeitsbereichs
gelöscht werden kann. Falls die Eigenschaft ursprünglich im aktuellen Geltungsbereich
definiert wurde, wird die Eigenschaft durch das Entfernen gelöscht. Falls die Eigenschaft
ursprünglich in einem übergeordneten Arbeitsbereich
definiert wurde, bleibt die Eigenschaft nach dem Entfernen so lange gelöscht, bis
der aktuelle Geltungsbereich (Arbeitsbereich) beendet wird. Wenn der aktuelle Arbeitsbereich beendet wird, wird
die gelöschte Eigenschaft wiederhergestellt.
Die Methode "remove" verwendet den Schlüssel der
Eigenschaft als Argument. Nur Eigenschaften mit den Modi "Normal" und "Read-only" können entfernt werden. Beim Versuch, eine
Eigenschaft mit dem Modus "Fixed" zu entfernen,
wird die Ausnahme "PropertyFixed" ausgelöst. Falls versucht wird, Eigenschaften in Arbeitsbereichen zu löschen,
die in anderen Prozessen erstellt wurden, wird
die Ausnahme "NotOriginator" ausgelöst.
Beispiel
Im Anwendungsbeispiel "SimpleSample", das im Artikel "Anwendungen entwickeln, die Arbeitsbereiche verwenden"
beschrieben ist, akzeptiert die Serverseite ferne Aufrufe von Clients.
Mit jedem fernen Aufruf ruft der Server auch einen Arbeitsbereich vom Client ab,
falls der Client einen erstellt hat. Der Arbeitsbereich wird transparent weitergeben.
Keine der fernen Methoden enthält den Arbeitsbereich in ihrer Argumentenliste.
In der Beispielanwendung verwendet das Serverobjekt die Schnittstelle des Arbeitsbereichs
lediglich zur Demonstration. Beispielsweise versucht die
SimpleSampleBean absichtlich, direkt in einen importierten Arbeitsbereich zu schreiben, wodurch
die Ausnahme "NotOriginator" ausgelöst wird. In ähnlicher Weise versucht die Bean absichtlich,
die schreibgeschützte (Read-only)
SimpleSampleCompany zu ändern, wodurch die Ausnahme
PropertyReadOnly ausgelöst wird. Außerdem verschachtelt die SimpleSampleBean
einen Arbeitsbereich und überschreibt das Prioritätseigenschaft erfolgreich, bevor sie
die SimpleSampleBackEndBean aufruft. Eine echte Geschäftsanwendung würde die Eigenschaften
des Arbeitsbereichs extrahieren und diese Eigenschaften als Richtlinien für die
lokale Arbeit verwenden. Die SimpleSampleBean ahmt dieses Verhalten nach, indem sie in einer Nachricht schreibt,
dass die Funktion verweigert wird, wenn eine Anforderung aus einer Verkaufsumgebung
stammt.