Contexte d'internationalisation : propagation et portée
La portée du contexte d'internationalisation est implicite. Chaque application client EJB (Enterprise JavaBeans), méthode de service de servlet et appel de méthode métier EJB comporte deux contextes d'internationalisation dans lesquels il s'exécute.
Pour chaque appel de composant d'application, le conteneur saisit le contexte d'appelant et le contexte d'appel dans la portée, comme indiqué par les règles d'internationalisation appropriées, avant que le conteneur le délègue à l'implémentation réelle. Lors du retour de l'implémentation, le service supprime ces contextes de la portée. Le service d'internationalisation ne fournit aucune méthode programmée permettant aux programmes de gérer explicitement la portée du contexte d'internationalisation.
Le contexte d'internationalisation respecte la sémantique par valeur sur les demandes de méthodes éloignées. Les modifications apportées aux éléments de contexte d'internationalisation étendus à un appel n'ont pas d'incidence sur les éléments correspondants du contexte d'internationalisation étendu au processus appelant éloigné. De même, les modifications apportées aux éléments de contexte obtenus à l'aide de l'API du contexte d'internationalisation n'ont pas d'incidence sur les éléments correspondants étendus à l'appel.
Programmes client EJB (contenus)
Avant d'appeler la méthode main d'un programme client, le conteneur client Java™ EE insère dans la portée des contextes d'internationalisation d'appel et d'appelant qui contiennent des éléments indéfinis. Ces contextes restent dans la portée tout au long de la durée de vie du programme. Les programmes client EJB sont la base d'une chaîne d'appels de méthode métier éloignés et, techniquement, ne comportent pas de contexte d'appelant logique. L'accès à un élément de contexte d'appelant renvoie l'élément par défaut correspondant de la JVM client. Dans le cas des demandes de méthode métier EJB sortantes, le service d'internationalisation propage le contexte d'appel au processus cible. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par les éléments par défaut de la JVM lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes.
Pour propager des valeurs autres que les valeurs JVM par défaut à des méthodes métier éloignées, les programmes client EJB et les servlets AMI ou les beans enterprise doivent définir (remplacer) des éléments du contexte d'appel. Pour savoir comment définir des éléments de contexte d'appel, consultez Accès aux paramètres régionaux et aux fuseaux horaires d'appel.
Servlets
Lors de chaque appel de méthode de service de servlet (doGet ou doPost), le conteneur Web Java EE insère des contextes d'internationalisation d'appelant et d'appel dans la portée avant de déléguer à l'implémentation de la méthode de service. Le contexte de l'appelant contient les langages d'acceptation propagés dans la demande de servlet HTTP, généralement à partir d'un navigateur Web. Le contexte d'appel contient le contexte qui est indiqué par l'attribut d'internationalisation de conteneur de la règle d'internationalisation associée au servlet. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par les éléments par défaut de la JVM du serveur lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes. Les contextes d'appelant et d'appel restent en vigueur jusqu'après le retour de l'implémentation, lorsque le conteneur les retire de la portée.
Beans enterprise
Lors de chaque appel de méthode métier EJB, le conteneur EJB Java EE insère des contextes d'internationalisation d'appelant et d'appel dans la portée avant de déléguer à l'implémentation de méthode métier. Le contexte d'appelant contient les éléments de contexte d'internationalisation importés de la demande IIOP entrante ; si la demande entrante ne contient pas un élément de contexte d'internationalisation particulier, le conteneur étend un élément indéfini. Le contexte d'appel contient le contexte qui est indiqué par l'attribut d'internationalisation de conteneur de la règle d'internationalisation associée à la méthode métier.
Dans le cas des demandes de méthode métier EJB sortantes, le service propage le contexte d'appel au processus cible. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par les éléments par défaut de la JVM du serveur lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes. Les contextes d'appelant et d'appel restent en vigueur jusqu'après le retour de l'implémentation, lorsque le conteneur les retire de la portée.
Prenons le cas d'une simple application EJB et d'un client Java qui appelle la méthode de bean myBeanMethod distante. Côté client, l'application peut utiliser l'API du service d'internationalisation pour définir des éléments de contexte d'appel. Lorsque le client appelle myBeanMethod(), le service exporte le contexte d'appel du client vers la demande sortante. Côté serveur, le service détache le contexte importé de la demande entrante et l'étend à la méthode comme son contexte d'appelant ; le service étend également le contexte d'appel à la méthode, comme indiqué par la règle de gestion de contexte d'internationalisation associée. Le conteneur d'EJB appelle myBeanMethod, qui peut utiliser l'API du contexte d'internationalisation pour accéder aux éléments du contexte d'appel ou du contexte de l'appelant. Lors du retour de la méthode myBeanMethod, le conteneur d'EJB retire ces contextes de la portée.
Programmes client de service Web (contenus)
Avant d'appeler la méthode main d'un programme client de service Web, le conteneur client insère dans la portée les contextes d'internationalisation d'appel et d'appelant qui contiennent des éléments indéfinis. Ces contextes restent dans la portée tout au long de la durée du programme. Les programmes client de service Web sont la base d'une chaîne d'appels de méthode métier éloignés et, techniquement, ne comportent pas de contexte d'appelant logique. L'accès à un élément de contexte d'appelant renvoie l'élément par défaut correspondant de la machine virtuelle client.
Dans les demandes sortantes des services Web, le service d'internationalisation crée automatiquement un bloc d'en-tête SOAP (Simple Object Access Protocol) contenant le contexte d'appel associé à l'unité d'exécution en cours ; la représentation SOAP du contexte d'appel est propagée via la demande au processus cible. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par l'élément par défaut de la JVM lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes. En outre, l'en-tête ne contenant qu'un ID fuseau horaire, l'état supplémentaire de l'objet fuseau horaire (java.lang.SimpleTimeZone) du contexte d'appel risque d'être perdu, car il n'est pas propagé via la demande.
Pour propager des valeurs autres que les valeurs JVM par défaut à des méthodes métier éloignées, les programmes client de service Web et les servlets AMI ou les beans enterprise doivent définir (remplacer) des éléments du contexte d'appel. Pour plus d'informations, voir Accès aux paramètres régionaux et aux fuseaux horaires d'appel.
Beans session sans état compatibles avec les services Web
Lors de chaque appel de méthode de bean compatible avec les services Web, le conteneur EJB insère des contextes d'internationalisation d'appelant et d'appel dans la portée avant de déléguer le contrôle à l'implémentation de méthode métier. Le contexte de l'appelant contient les éléments de contexte d'internationalisation importés du bloc d'en-tête SOAP de la demande entrante. Si la demande entrante ne contient pas d'élément de contexte d'internationalisation particulier, le conteneur insère un élément nul dans la portée. Le contexte d'appel contient le contexte qui est indiqué par l'attribut d'internationalisation de conteneur de la règle d'internationalisation associée à la méthode métier.
Dans le cas des demandes de méthode métier EJB sortantes, le service propage le contexte d'appel au processus cible. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par l'élément par défaut de la machine JVM du serveur lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes. Les contextes d'appelant et d'appel restent en vigueur tant que le contrôle n'est pas retourné à l'implémentation de la méthode ; à ce moment, le conteneur les supprime de la portée.
Dans les demandes sortantes des services Web, le service d'internationalisation crée automatiquement un bloc d'en-tête SOAP contenant le contexte d'appel associé à l'unité d'exécution en cours. La représentation SOAP du contexte d'appel est propagée via la demande au processus cible. Tous les éléments de contexte d'appel non définis (nuls) sont remplacés par l'élément par défaut de la JVM lorsqu'ils sont exportés par l'API du contexte d'internationalisation ou par des demandes sortantes.
Remarques sur l'association des unités d'exécution
Les conteneurs Web et EJB étendent les contextes d'internationalisation à une méthode en l'associant à l'unité qui exécute l'implémentation de la méthode. De même, les méthodes de l'API du contexte d'internationalisation associent le contexte ou obtiennent un contexte associé à l'unité sur laquelle ces méthodes sont exécutées.
Au cas où de nouvelles unités d'exécution sont générées dans un composant d'application (par exemple, une unité d'exécution générée par un utilisateur dans la méthode service d'un servlet, ou une unité de gestion d'événements générée par le système dans un client AWT), les contextes d'internationalisation associés à l'unité d'exécution parent ne sont pas automatiquement transférés vers l'unité d'exécution nouvellement générée. Dans ces cas, le service exporte les paramètres régionaux et le fuseau horaire par défaut de la JVM lors de toutes les demandes de méthode métier éloignées et de tous les appels d'API exécutés sur la nouvelle unité d'exécution.
Si le contexte par défaut est inapproprié, les éléments de contexte d'appel souhaités doivent explicitement être associés à la nouvelle unité d'exécution à l'aide des méthodes setXxx de l'interface InvocationInternationalization. A l'heure actuelle, les règles de gestion de contexte d'internationalisation permettent la définition du contexte d'appel dans les programmes client EJB, ainsi que dans les servlets, les beans session et les beans gérés par message utilisant l'internationalisation gérée par application.