Service für Arbeitsbereichspartitionen

Der Service für Arbeitsbereichspartitionen ist eine Erweiterung des Arbeitsbereichsservice und unterstützt das Erstellen mehrerer angepasster Arbeitsbereiche (Work Areas). Der Service für Arbeitsbereichspartitionen ist ein optionaler Service. Jeder Benutzer, der derzeit den Arbeitsbereichsservice und die UserWorkArea-Partition verwendet, kann diese Komponenten unverändert weiterverwenden. Die UserWorkArea-Partition wird automatisch vom Service für Arbeitsbereichspartitionen erstellt (falls sie nicht inaktiviert wurde). Durch die Option, mit dem Service für Arbeitsbereichspartitionen eine eigene WorkArea-Partition erstellen zu können, hat der Benutzer mehr Kontrolle über die Konfiguration und den Zugriff auf seine Partition.

Der Service für Arbeitsbereichspartitionen ist im Wesentlichen eine "Factory" für das Erstellen von Instanzen der Schnittstelle "UserWorkArea". Anwendungen interagieren über das Interface "UserWorkArea" und seiner Implementierung mit Arbeitsbereichen. Dieses Interface definiert alle Methoden, die zum Erstellen, Bearbeiten und Vervollständigen von Arbeitsbereichen verwendet werden. Der Service für Arbeitsbereichspartitionen ermöglicht Benutzern, eigene benannte Instanzen der Schnittstelle "UserWorkArea" zu erstellen. Jede benannte Instanz ist eine so genannte benutzerdefinierte Arbeitsbereichspartition oder kurz Partition. Jede Instanz der Schnittstelle (Partition) "UserWorkArea" ist von anderen benutzerdefinierten Partitionen getrennt. Darüber hinaus können Sie eine Partition mit verschiedenen Optionen konfigurieren, um Servicequalitäten bereitzustellen, die in einem bestimmten Anwendungsfall für einen einzelnen Benutzer eindeutig sind. Keine der Konfigurationsoptionen, die in der Anzeige "Service für Arbeitsbereichspartitionen" ausgewählt werden, wirken sich auf den Arbeitsbereichsservice aus.

Im Gegensatz zur UserWorkArea-Partition, die allgemein bekannt ist, sind Arbeitsbereiche, die vom Service für Arbeitsbereichspartitionen erstellt werden, nur dem Ersteller zugänglich und bekannt. Der Service für Arbeitsbereichspartitionen legt nicht strikt fest, dass nur der Ersteller der Partition auf eine Partition zugreift und/oder diese bearbeitet. Wenn der Ersteller die Arbeitsbereichspartition veröffentlichen und öffentlich verfügbar machen möchte, indem er die Partitionsreferenz an Java Naming oder auf andere Weise bindet, bestehen diesbezüglich keine Einschränkungen. Wenn ein Benutzer allerdings vermeiden möchte, dass andere Benutzer eine bestimmte Partition erkennen, versucht der Service für Arbeitsbereichspartitionen, die Partition bestmöglich zu verdecken. Der Service für Arbeitsbereichspartitionen erlaubt einer Person nicht, die Namen aller erstellten Partitionen zu bestimmen oder abzufragen. Allerdings können andere Benutzer als der Ersteller der Partition ohne Einschränkungen auf die Partitionen zugreifen. Der Kontext einer Partition, z. B. der UserWorkArea-Partition oder einer benutzerdefinierten Partition, wird auf einen Einzelthread begrenzt, Mehrfachthreads können nicht zugreifen.

Die Referenz auf die Arbeitsbereichspartition, die an einen Benutzer zurückgegeben wird, implementiert javax.naming.Referenceable ebenso wie com.ibm.websphere.UserWorkArea. Daher kann ein Benutzer seine Partition an einen Namen binden, wenn er seine Partition öffentlich verfügbar machen möchte. Wenn Sie Java™ Naming nicht verwenden möchten, um die Partition zu binden und auf sie zuzugreifen, können Sie alternativ dazu die Schnittstelle des Managers für Arbeitsbereichspartitionen verwenden. Jeder kann auf dieses Interface zugreifen, d. h., wenn ein Benutzer seine Partition öffentlich verfügbar machen möchte, muss er lediglich den Namen seiner Partition veröffentlichen. Andere Benutzer können dann die Methode "getWorkAreaPartition" in der Schnittstelle des Managers für Arbeitsbereichspartitionen mit dem veröffentlichten Namen aufrufen.

Die Methode "WorkAreaPartitionManager.createWorkAreaPartition" kann nur auf einem Java EE-Client (Java Platform, Enterprise Edition) verwendet werden. Wenn Sie serverseitig eine Arbeitsbereichspartition erstellen möchten, müssen Sie die Administrationskonsole verwenden. Serverseitig muss eine Arbeitsbereichspartition beim Starten des Servers erstellt werden, da jede Partition für die entsprechenden Web- und EJB-Collaborator (Enterprise JavaBeans) registriert werden muss, bevor der Server gestartet wird. Angepasste Arbeitsbereichspartitionen werden vom Service für Arbeitsbereichspartitionen erstellt und von der Schnittstelle "UserWorkArea" definiert.

Der Service Arbeitsbereichspartitionen ermöglicht einem Benutzer auch, Partitionen mit zusätzlichen Eigenschaften, die nicht in der UserWorkArea-Partition verfügbar sind, zu konfigurieren, z. B. die bidirektionale Weitergabe von Kontext der Arbeitsbereichspartition und verzögerte Serialisierung von Attributen. Diese Eigenschaften sind bei der Erstellung einer Partition als Konfigurationseigenschaften verfügbar. Eine vollständige Liste der Konfigurationseigenschaften, die bei die Erstellung einer Partition verfügbar sind, finden Sie im Abschnitt "Konfigurierbare Eigenschaften für die Arbeitsbereichspartition" im Artikel "Schnittstelle des Managers für Arbeitsbereichspartitionen". Die Eigenschaften sind wie folgt definiert:

Bidirektionale Weitergabe von Arbeitsbereichskontext

Falls ein Thread, der einem Arbeitsbereich zugeordnet ist, einen fernen Aufruf startet, dann wird automatisch eine Kopie des Arbeitsbereichs an das Zielobjekt weitergegeben, das die Informationen im Arbeitsbereich nach Bedarf verwenden oder ignorieren kann. Ist der aufrufenden Anwendung ein verschachtelter Arbeitsbereich zugeordnet, wird eine Kopie des verschachtelten Arbeitsbereichs und aller übergeordneten Bereiche an das Zielobjekt weitergegeben. Die Zielanwendung kann die Informationen entsprechend den definierten Eigenschaftsmodi lokal ändern, indem sie zusätzliche verschachtelte Arbeitsbereiche erstellt. Diese Informationen werden an alle fernen Objekte zurückgegeben, die von dieser Anwendung aufgerufen werden.

Von der Konfiguration der Arbeitsbereichspartition hängt ab, ob Kontextänderungen von einer fernen Anwendung an die aufrufende Anwendung weitergegeben werden. Wenn ein Benutzer eine bidirektionale Partition erstellt (indem er die Eigenschaft "Bidirektional" bei der Erstellung auswählt), werden die von der fernen Anwendung durchgeführten Änderungen an die aufrufende Anwendung zurückgegeben, d. h., dass Änderungen, die von einem Downstreamprozess am Arbeitsbereichskontext vorgenommen werden, zurück an einen Upstreamprozess weitergegeben werden. Die UserWorkArea-Partition ist nicht als bidirektional konfiguriert (und kann keinesfalls so konfiguriert werden), daher können Kontextänderungen nur an Downstreamprozesse, nicht jedoch zurück an Upstreamprozesse weitergegeben werden.

Beispiel: Bidirektionale Weitergabe von Arbeitsbereichskontext

Von der Konfiguration der Arbeitsbereichspartition hängt ab, ob Kontextänderungen von einer fernen Anwendung an die aufrufende Anwendung weitergegeben werden. Wenn ein Benutzer eine bidirektionale Partition erstellt, werden Änderungen, die von einer fernen Anwendung durchgeführt werden, zurück an die aufrufende Anwendung übergeben. Änderungen, die von einem Downstreamprozess am Arbeitsbereichskontext vorgenommen wurden, werden zurück an Upstreamprozesse übergeben. Die Abbildung Verteilung von Arbeitsbereichskontext bei Konfiguration für bidirektionale Weitergabe veranschaulicht diese Beziehung während eines an den Server abgesetzten Fernaufrufs. Im Falle dieser Abbildung müssen Client und Server eine Partition mit demselben Namen erstellt haben.

Abbildung 1. Verteilung von Arbeitsbereichskontext bei Konfiguration für bidirektionale Weitergabe. Diese Abbildung veranschaulicht die Verteilung von Arbeitsbereichskontext, wenn der Service für bidirektionale Weitergabe konfiguriert ist. Beispiel für die bidirektionale Weitergabe von Arbeitsbereichskontext

Der Server empfängt den vom Clientprozess definierten Kontext, wenn der Client einen fernen Aufruf an den Server absetzt. Der Server kann dann Änderungen an diesem Kontext vornehmen oder Inhalt hinzufügen. In dieser Abbildung überschreibt der Server den Wert bei key1, entfernt die Eigenschaft bei key2 und fügt zwei neue Eigenschaften unter key5 und key6 hinzu. Wenn die Serveranwendung zum Client zurückkehrt, wird der Arbeitsbereichskontext zurück an den Client übergeben, und für den Kontext wird eine Demarshaling-Operation ausgeführt. Der aktuelle Arbeitsbereich wird mit dem neuen Kontext aktualisiert. Anmerkung: Wenn die Partition nicht als bidirektional konfiguriert ist und der Server versucht, Kontext im Arbeitsbereich, "Work Area 1", zu ändern oder zu entfernen, empfängt sie die Ausnahme com.ibm.websphere.workarea.NotOriginator, da der Client der Ersteller des Arbeitsbereichs war. Der Server kann den Kontext aus "Work Area 1" abrufen. ist der Hauptunterschied zwischen bidirektionaler und nicht bidirektionaler Weitergabe von Kontext.

Beispiel: Bidirektionale Weitergabe eines verschachtelten Arbeitsbereichskontextes

Wenn eine ferne Anwendung Kontext zu einem Arbeitsbereich hinzufügen muss, der nur für sie oder andere ferne Objekte verwendet wird, muss die ferne Anwendung einen neuen Arbeitsbereich beginnen. Dadurch, dass ein neuer Arbeitsbereich begonnen wird, wird der hinzugefügte Kontext der Anwendung zugeordnet und fließt nicht an die aufrufende Anwendung zurück. Der wichtigste Nutzen der Verschachtelung von Arbeitsbereichen besteht darin, dass eine Anwendung Arbeitsbereichskontext für eine bestimmte Anwendung erstellen kann. Ausgehend von der obigen Abbildung gestaltet der nächste Schritt sich wie folgt: Wenn der Server einen Arbeitsbereich begonnen hat, bevor er den Wert bei key1 überschrieben, die Eigenschaft bei key2 entfernt oder neue Eigenschaften bei key5 und key6 hinzugefügt hat, werden diese Änderungen nicht zurück an den Client übergeben. Dies wird in der Abbildung Verteilung von verschachteltem Arbeitsbereichskontext bei Konfiguration für bidirektionale Weitergabe veranschaulicht. Sie können anhand dieser Abbildung auch erkennen, dass der Client den Kontext nicht vom verschachtelten Arbeitsbereich, der vom Server gestartet wurde, empfängt.

Abbildung 2. Verteilung von verschachteltem Arbeitsbereichskontext bei Konfiguration für bidirektionale Weitergabe. Diese Abbildung veranschaulicht die Verteilung von verschachteltem Arbeitsbereichskontext, wenn der Service für bidirektionale Weitergabe konfiguriert ist. Beispiel für die bidirektionale Weitergabe von verschachteltem Arbeitsbereichskontext

Verzögerte Serialisierung der Attribute des Arbeitsbereichskontextes

Standardmäßig wird für jede set-Operation das in einem Arbeitsbereich festgelegte Attribut automatisch vom Arbeitsbereichsservice serialisiert. Bei allen nachfolgenden Abrufoperationen, die für dasselbe Attribut ausgeführt werden, wird dieses entserialisiert und an den Anforderer zurückgegeben. Dies führt dazu, dass der Arbeitsbereichsservice das Attribut vollständig steuert, sodass alle Änderungen, die an einem mutablen Objekt vorgenommen werden, nicht in der Kopie des Arbeitsbereichs des Attributs sichtbar werden, es sei denn, ein Benutzer setzt das Attribut in den Arbeitsbereich zurück. Dies kann jedoch eine übermäßige Serialisierung und Entserialisierung zur Folge haben.

Dies wiederum kann zu einem merklichen Leistungsabfall bei Lastspitzen führen. Die Konfigurationseigenschaft für die verzögerte Attributserialisierung ist eine Caching-Funktion, die Serialisierungs- und Entserialisierungsoperationen verringert. Wenn die verzögerte Attributserialisierung in einem Client- oder Serverprozess aktiviert wird (durch Auswahl des Felds "Verzögerte Serialisierung der Attribute" bei der Erstellung des Arbeitsbereichs), werden die im Arbeitsbereichsservice konfigurierten Attribute bei der set-Operation nicht automatisch serialisiert. Stattdessen wird eine Referenz auf das Attribut im Arbeitsbereich gespeichert. Ist das Attribut mutabel, werden Änderungen am Objekt in der Referenz des Arbeitsbereichs auf dieses Attribut sichtbar. Wenn eine Abrufoperation für dieses Attribut ausgeführt wird, wird die Referenz auf dieses Objekt zurückgegeben und es wird keine Entserialisierung durchgeführt.

Attribute werden erst serialisiert, wenn der Thread, dem das Attribut zugeordnet ist, einen fernen IIOP-Aufruf durchführt. An diesem Punkt wird das Attribut serialisiert, und die serialisierte Form des Attributs wird in den Cache gestellt. Wenn das Attribut nicht in den Arbeitsbereich zurückgesetzt wird, werden Änderungen am Originalattribut dennoch in dem im Arbeitsbereich enthaltenen Attribut sichtbar, da der Arbeitsbereich noch eine zwischengespeicherte Referenz auf das Originalobjekt enthält. Wenn der Arbeitsbereich jedoch nicht über eine Änderung des Attributs informiert wurde (durch Zurücksetzen des Attributs in den Arbeitsbereich), können nachfolgende ferne Anforderungen die zwischengespeicherte serialisierte Version des Attributs verwenden, und direkte Änderungen am mutablen Attribut werden nicht weitergegeben. Dies ist eine wichtige Unterscheidung zwischen Aktivierung und Nichtaktivierung der Konfigurationseigenschaft für die verzögerte Attributserialisierung. Ein Benutzer muss auf diesen Unterschied genau achten und berücksichtigen, wie mutable Objekte bei der Aktivierung der verzögerten Attributserialisierung behandelt werden. Der Arbeitsbereichsservice gibt zwischengespeicherte Referenzen und zwischengespeicherte serialisierte Versionen von Attributen frei, wenn eine der folgenden Situationen eintritt:

  • Ein Attribut wird zurückgesetzt oder entfernt.
  • Der Arbeitsbereich wird von der Anwendung explizit abgeschlossen.
  • Die Serverkomponente beendet die Ausführung der Anforderung, während der der Arbeitsbereich begonnen wurde.
  • Der Clientprozess, der den Arbeitsbereich begonnen hat, wird beendet.

Prozessübergreifende Weitergabe des Partitionskontextes

Der Arbeitsbereichskontext wird automatisch vom Client an den Server weitergegeben, wenn ein Client einen fernen Aufruf an einen Server absetzt. Wird ein Client bei der Durchführung eines fernen Aufrufs an einen Server, server1, z. B. mit drei verschiedenen Arbeitsbereichspartitionen konfiguriert, wird der Kontext, der den einzelnen Partitionen auf dem Clientthread zugeordnet ist, an server1 weitergegeben. Wenn dieselben drei Partitionen sich auf server1 befinden (erstellt wurden), wird für den Kontext eine Demarshaling-Operation in der geeigneten Partition ausgeführt. Wenn keine oder nicht alle der drei Partitionen auf server1 erstellt wurden, wird nur für den Kontext, der einer auf dem Client und dem Server befindlichen Partition zugeordnet ist, eine Demarshaling-Operation ausgeführt. Der Kontext, der einer nicht auf server1 befindlichen Partition zugeordnet ist, befindet sich immer noch auf server1, ist jedoch nicht verfügbar. Der Kontext, der nicht auf server1 befindlichen Partitionen zugeordnet ist, muss auf server1 verbleiben, falls ein weiterer ferner Aufruf an einen anderen Server abgesetzt wird. Gehen Sie einen Schritt weiter, und nehmen Sie an, dass server1 einen Aufruf an noch einen anderen Server, server2, absetzt. Nehmen Sie weiter an, dass server2 dieselben Partitionen erstellt wie der Client. Server2 empfängt den Kontext für die Partitionen, die sich nicht auf server1 befunden haben. Die Kontexte aller auf server1 befindlichen Partitionen, die sich nicht auf dem Client befunden haben, werden an server2 weitergegeben.

Weitere Informationen zum Arbeitsbereich finden Sie im Paket "com.ibm.websphere.workarea" in der API-Dokumentation. Sie finden die generierte API-Dokumentation im Inhaltsverzeichnis des Information Center unter Referenz > APIs - Application Programming Interfaces.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwa_partition
Dateiname:cwa_partition.html