Internationalisierungskontext: Weitergabe und Geltungsbereich
Der Geltungsbereich eines Internationalisierungskontextes ist implizit. Jeder Aufruf einer EJB-Clientanwendung (Enterprise JavaBeans), Servlet-Service-Methode oder EJB-Geschäftsmethode hat zwei Internationalisierungskontexte, in denen er ausgeführt wird.
Für jeden Aufruf einer Anwendungskomponente richtet der Container den Callerkontext und den Aufrufkontext ein, der in der zugehörigen Internationalisierungsrichtlinie festgelegt ist, bevor er den Aufruf an die Implementierung überträgt. Wenn die Implementierung zurückkehrt, entfernt der Service diese Kontexte aus dem Geltungsbereich. Der Service zur Internationalisierung bietet keinen programminternen Mechanismus, mit dem Komponenten den Geltungsbereich des Internationalisierungskontextes explizit verwalten können.
Der Internationalisierungskontext hält bei Anforderungen ferner Methoden die wertabhängige Semantik (oder "Call-by-Value"-Semantik) ein, d. h. Änderungen a den Elementen des Internationalisierungskontextes eines Aufrufs haben keine Auswirkung auf die entsprechenden Elemente des Internationalisierungskontextes des fernen aufrufenden Prozesses. Ebenso haben Änderungen an den Kontextelementen, die mit der API für Internationalisierungskontext angefordert werden, keine Auswirkung auf die entsprechenden Elemente des Aufrufs.
EJB-Clientprogramme (im Container)
Vor dem Aufruf der Methode main eines Clientprogramms führt der Java™ EE-Client-Container den Aufruf- und den Caller-Internationalisierungskontexten mit nicht zugewiesenen Elementen in den Geltungsbereich ein. Diese Kontexte bleiben so lange gültig, wie das Programm ausgeführt wird. EJB-Clientprogramme bilden in einer Kette von Aufrufen ferner Geschäftsmethoden die Basis und haben vom technischen Standpunkt aus gesehen keinen logischen Caller-Kontext. Beim Zugriff auf ein Element eines Caller-Kontextes wird das entsprechende Standardelement der Client-JVM verwendet. Bei abgehenden Anforderungen für EJB-Geschäftsmethoden gibt der Service zur Internationalisierung den Aufrufkontext an den Zielprozess weiter. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch die Standardwerte der JVM ersetzt.
Wenn andere Werte als die JVM-Standardwerte an ferne Geschäftsmethoden weitergegeben werden sollen, müssen EJB-Clientprogramme sowie AMI-Servlets oder Enterprise-Beans die Elemente des Aufrufkontextes definieren (überschreiben). Informationen zum Definieren von Elementen für Aufrufkontexte finden Sie im Artikel Auf Ländereinstellung und Zeitzonen des Aufrufes zugreifen.
Servlets
Bei jedem Aufruf einer Servlet-Servicemethode (doGet, doPost) weist der Java EE-Web-Container die Caller- und Aufruf-Internationalisierungskontexte zu, bevor er den Aufruf an die Implementierung der Servicemethode überträgt. Der Caller-Kontext enthält die in der HTTP-Servletanforderung weitergegebenen, akzeptierten Sprachen (accept-languages), die in der Regel von einem Web-Browser stammen. Der Aufrufkontext enthält den Kontext, der im Containerattribut für die Internationalisierung der Internationalisierungsrichtlinie definiert ist, die dem Servlet zugeordnet ist. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch die Standardwerte der Server-JVM ersetzt. Die Caller- und Aufrufkontexte bleiben so lange gültig, bis die Implementierung zurückkehrt und der Container sie aus dem Geltungsbereich entfernt.
Enterprise-Beans
Bei jedem Aufruf einer EJB-Geschäftsmethode weist der Java EE-EJB-Container die Caller- und Aufruf-Internationalisierungskontexte zu, bevor er den Aufruf an die Implementierung der Geschäftsmethode überträgt. Der Caller-Kontext enthält die Elemente des Internationalisierungskontextes, die aus der eingehenden IIOP-Anforderung importiert wurden. Falls in der eingehenden Anforderung ein bestimmtes Element des Internationalisierungskontextes fehlt, weist der Container ein Nullelement zu. Der Aufrufkontext enthält den Kontext, der im Containerattribut für die Internationalisierung der Internationalisierungsrichtlinie definiert ist, die der Geschäftsmethode zugeordnet ist.
Bei abgehenden Anforderungen für EJB-Geschäftsmethoden gibt der Service den Aufrufkontext an den Zielprozess weiter. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch die Standardwerte der Server-JVM ersetzt. Die Caller- und Aufrufkontexte bleiben so lange gültig, bis die Implementierung zurückkehrt und der Container sie aus dem Geltungsbereich entfernt.
Stellen Sie sich eine einfache EJB-Anwendung mit einem Java-Client vor, der die ferne Bean-Methode "myBeanMethod" aufruft. Auf der Clientseite kann die Anwendung die API des Service zur Internationalisierung verwenden, um die Elemente des Aufrufkontextes festzulegen. Wenn der Client die Methode "myBeanMethod()" aufruft, exportiert der Service den Aufrufkontext des Clients in die abgehende Anforderung. Auf der Serverseite hängt der Service den importierten Kontext von der eingehenden Anforderung ab und weist ihn der Methode als Caller-Kontext zu. Außerdem weist er der Methode den Aufrufkontext zu, der in der zugehörigen Verwaltungsrichtlinie für Internationalisierungskontext definiert ist. Der EJB-Container ruft anschließend die Methode myBeanMethod auf, die mit der API für Internationalisierungskontexte auf Elemente der Kontexte von Aufrufendem und Aufruf zugreifen kann. Wenn die Methode "myBeanMethod" zurückkehrt, entfernt der EJB-Container diese Kontexte aus dem Geltungsbereich.
Web-Service-Clientprogramme (im Container)
Vor dem Aufruf der Methode main eines Web-Service-Clientprogramms führt der Java EE-Client-Container den Aufruf- und den Caller-Internationalisierungskontext mit nicht zugewiesenen Elementen in den Geltungsbereich ein. Diese Kontexte bleiben so lange gültig, wie das Programm ausgeführt wird. Web-Service-Clientprogramme bilden in einer Kette von Aufrufen ferner Geschäftsmethoden die Basis und haben vom technischen Standpunkt aus gesehen keinen logischen Caller-Kontext. Beim Zugriff auf ein Element eines Caller-Kontextes wird das entsprechende Standardelement der Client-JVM verwendet.
Bei abgehenden Web-Service-Anforderungen erstellt der Service zur Internationalisierung einen SOAP-Headerblock (Simple Object Access Protocol), der den Aufrufkontext für den aktuellen Thread enthält. Die SOAP-Darstellung des Aufrufkontextes wird über die Anforderung an den Zielprozess weitergegeben. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch das Standardelement der JVM ersetzt. Da der Header nur eine Zeitzonen-ID enthält, können zusätzliche Statusinformationen zum Zeitzonenobjekt des Aufrufkontextes (java.lang.SimpleTimeZone) verloren gehen, weil diese nicht mit der Anforderung weitergegeben werden.
Wenn andere Werte als die JVM-Standardwerte an ferne Geschäftsmethoden weitergegeben werden sollen, müssen Web-Service-Clientprogramme sowie AMI-Servlets oder Enterprise-Beans die Elemente des Aufrufkontextes definieren (überschreiben). Weitere Informationen hierzu finden Sie im Artikel Auf Ländereinstellung und Zeitzonen des Aufrufes zugreifen.
Stateless-Session-Beans, die Web-Services unterstützen
Bei jedem Methodenaufruf einer Bean mit Unterstützung für Web-Services führt der EJB-Container den Aufruf- und den Caller-Internationalisierungskontext in den Geltungsbereich ein, bevor er die Steuerung an die Implementierung der Geschäftsmethode übergibt. Der Caller-Kontext enthält die Internationalisierungskontextelemente, die aus dem SOAP-Headerblock der eingehenden Anforderung importiert wurden. Wenn in der eingehenden Anforderung ein bestimmtes Internationalisierungskontextelement fehlt, führt der Container ein nicht zugewiesenes Element in den Geltungsbereich ein. Der Aufrufkontext enthält den Kontext, der im Containerattribut für die Internationalisierung der Internationalisierungsrichtlinie definiert ist, die der Geschäftsmethode zugeordnet ist.
Bei abgehenden Anforderungen für EJB-Geschäftsmethoden gibt der Service den Aufrufkontext an den Zielprozess weiter. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch das Standardelement der Server-JVM ersetzt. Caller- und Aufrufkontexte bleiben so lange aktiv, bis die Implementierung der Geschäftsmethode die Steuerung zurückgibt und der Container die Kontexte daraufhin aus dem Geltungsbereich entfernt.
Bei abgehenden Web-Service-Anforderung erstellt der Service zur Internationalisierung einen SOAP-Headerblock, der den Aufrufkontext für den aktuellen Thread enthält. Die SOAP-Darstellung des Aufrufkontextes wird über die Anforderung an den Zielprozess übergeben. Alle nicht zugewiesenen (null) Elemente des Aufrufkontextes werden beim Export durch die API für Internationalisierungskontext oder abgehende Anforderungen durch das Standardelement der JVM ersetzt.
Hinweise zur Thread-Zuweisung
Die Web- und EJB-Container weisen einer Methode Internationalisierungskontexte zu, indem Sie ihr den Thread zuweisen, der die Implementierung der Methode ausführt. Ebenso ordnen die Methoden der API für Internationalisierungskontext einen Kontext dem Thread zu, in dem diese Methoden ausgeführt werden, oder rufen den Kontext ab, der diesem Thread zugeordnet ist.
In solchen Fällen, in denen neue Thread in einer Anwendungskomponente erzeugt werden (z. B. ein benutzergenerierter Thread in der Methode service eines Servlets oder ein systemgenerierter Thread für die Behandlung von Ereignissen in einem AWT-Client), werden die Internationalisierungskontexte, die dem übergeordneten Thread zugeordnet sind, nicht automatisch an den neu erzeugten Thread übertragen. Hier exportiert der Service die Standard-Locale und Standardzeitzone der JVM in allen Anforderungen ferner Geschäftsmethoden und allen API-Aufrufen, die in dem neuen Thread ausgeführt werden.
Falls der Standardkontext nicht geeignet ist, müssen die gewünschten Elemente des Aufrufkontextes dem neuen Thread mit den Methoden "setXxx" der Schnittstelle "InvocationInternationalization" explizit zugeordnet werden. Derzeit lassen die Verwaltungsrichtlinien für Internationalisierungskontexte zu, dass der Aufrufkontext in EJB-Clientprogrammen sowie Servlets, Session-Beans und Message-Driven-Beans definiert wird, die mit AMI (Application-Managed Internationalization) arbeiten.