Service Work Area Partition

Le service Work Area Partition est une extension du service WorkArea qui active la création de plusieurs zones de travail personnalisées. Il est disponible en option. Les utilisateurs actuels du service WorkArea et de la partition UserWorkArea peuvent continuer à travailler de la même manière. La partition UserWorkArea est créée automatiquement (à condition qu'elle n'ait pas été désactivée) par le service Work Area Partition. Les utilisateurs autorisés à créer leur propre partition Work Area par le biais du service Work Area Partition peuvent contrôler plus efficacement la configuration de leur partition et les accès à celle-ci.

Le service de partition de zone de travail est essentiellement une fabrique de créations d'instances de l'interface UserWorkArea. Les applications interagissent avec les zones de travail à l'aide de l'interface UserWorkArea et de son implémentation. Cette interface définit toutes les méthodes permettant la création, la manipulation et l'achèvement de zones de travail. Le service de partition de zone de travail permet aux utilisateurs de créer leur instance nommée de l'interface UserWorkArea. Chaque instance nommée est appelée partition de zone de travail de l'utilisateur ou partition, pour faire court. Chaque instance de l'interface UserWorkArea (partition) est distincte des autres partitions définies par l'utilisateur. De plus, vous pouvez configurer une partition à l'aide de diverses options pour fournir des qualités de service propres à un scénario d'utilisation pour un utilisateur individuel. Toutes les options de configuration utilisées dans le panneau du service de partition de zone de travail n'ont aucun impact sur le service de zone de travail.

Contrairement à la partition UserWorkArea, qui est publique, l'accès aux zones de travail créées par le service Work Area Partition est réservé à leur créateur. Cependant, le service Work Area Partition n'applique pas strictement la règle selon laquelle une partition ne doit être consultée/utilisée que par son créateur. Il n'existe aucune limitation si le créateur souhaite publier sa partition Work Area et la rendre publique en liant sa référence à JNDI ou en utilisant une autre méthode. Cependant, le service Work Area Partition masque dans la mesure du possible une partition lorsqu'un utilisateur souhaite que son existence ne soit pas connue. Le service Work Area Partition n'autorise pas une personne à déterminer ou à demander le nom de toutes les partitions créées mais il n'interdit pas l'accès des partitions à d'autres utilisateurs que la personne qui les a créées. Le contexte d'une partition, telle que la partition UserWorkArea ou une partition définie par l'utilisateur, a sa portée limitée à une unité d'exécution unique et n'est pas accessible par plusieurs unités d'exécution.

La référence d'une partition de zone de travail renvoyée à un utilisateur permet d'implémenter javax.naming.Referenceable ainsi que com.ibm.websphere.UserWorkArea, ce qui permet à l'utilisateur de lier sa partition à un nom s'il souhaite rendre sa partition publique. Au lieu d'utiliser JNDI (Java™ naming) pour lier la partition et y accéder, faites appel à l'interface de gestion du service Work Area Partition. Tout le monde peut avoir accès à l'interface de gestion des partitions Work Area ; ainsi si un utilisateur souhaite rendre sa partition publique, il doit simplement en publier le nom. D'autres utilisateurs peuvent appeler la méthode getWorkAreaPartition dans l'interface de gestion de la partition Work Area à l'aide du nom publié.

La méthode WorkAreaPartitionManager.createWorkAreaPartition ne peut être utilisée qu'à partir d'un client Java EE (Java Platform, Enterprise Edition). Pour créer une partition Work Area côté serveur, il convient d'utiliser la console d'administration. Côté serveur, une partition Work Area doit être créée au cours du démarrage du serveur car chaque partition doit être enregistrée auprès des collaborateurs Web et EJB (Enterprise JavaBeans) appropriés avant le démarrage du serveur. Les partitions Work Area personnalisées sont créées par le service Work Area Partition et définies par l'interface UserWorkArea.

Le service Work Area Partition autorise également un utilisateur à configurer des partitions en y ajoutant des propriétés non disponibles dans la partition UserWorkArea, telles que la propagation bidirectionnelle du contexte de la partition Work Area et la sérialisation d'attribut reportée. Ces propriétés sont disponibles en tant que propriétés de configuration lors de la création d'une partition. Pour obtenir la liste complète des propriétés de configuration disponibles lors de création d'une partition, consultez la section "Propriétés configurables de Work Area Partition" dans l'article Interface du gestionnaire de partitions Work Area. Elles sont définies comme indiqué ci-après.

Propagation bidirectionnelle du contexte de zone de travail

Si un appel à distance est émis à partir d'une unité d'exécution associée à une zone de travail, une copie de cette dernière est automatiquement propagée à l'objet cible qui peut, selon le cas, utiliser ou ignorer les informations dans la zone de travail. Si l'application appelante est associée à une zone de travail imbriquée, une copie de cette dernière et tous ses ancêtres sont propagés à l'application cible. L'application cible peut modifier en local les informations, comme admis par les modes de propriété, en créant d'autres zones de travail imbriquées. Ces informations sont propagées à tous les objets éloignés qu'elle appelle.

Le fait que les modifications de contexte soient propagées de nouveau à une application appelante à partir d'une application éloignée dépend de la configuration de la partition Work Area. Si un utilisateur crée une partition devant être bidirectionnelle en sélectionnant la propriété Bidirectionnel lors de sa création, les modifications effectuées par une application éloignée sont propagées de nouveau à l'application appelante, ce qui signifie que les modifications apportées au contexte de la zone de travail par un processus en aval sont propagées de nouveau en amont. La partition UserWorkArea n'est pas configurée pour être bidirectionnelle (et ne peut pas l'être) ; ainsi, les modifications de contexte sont uniquement transmises aux processus en aval et ne sont pas propagées de nouveau en amont.

Exemple : Propagation bidirectionnelle du contexte de zone travail

Le fait que les modifications de contexte soient propagées de nouveau à une application appelante à partir d'une application éloignée dépend de la configuration de la partition Work Area. Si un utilisateur crée une partition bidirectionnelle, les modifications effectuées par une application éloignée sont propagées de nouveau à l'application appelante. Les modifications apportées à un contexte de zone de travail par un processus en aval est propagé de nouveau en amont. La figure Distribution du contexte de zone de travail lorsqu'il est configuré pour la propagation bidirectionnelle illustre cette relation pendant un appel distant émis au serveur. Pour cette illustration, le client et le serveur doivent avoir créé une partition ayant le même nom.

Figure 1. Distribution du contexte de zone de travail lorsqu'il est configuré pour la propagation bidirectionnelle. Cette figure illustre la distribution du contexte de zone de travail lorsque le service est configuré pour la propagation bidirectionnelle. Exemple de propagation bidirectionnelle du contexte de zone de travail

Lorsque le client envoie un appel distant au serveur, ce dernier reçoit le contexte défini par le processus client. Le serveur peut alors modifier ce contexte ou y ajouter des éléments. Dans cette illustration, le serveur remplace la valeur de clé1, supprime la propriété de clé2 et ajoute deux propriétés à clé5 et clé6. Lorsque le serveur d'applications renvoie les données au client, le contexte de zone de travail est propagé de nouveau au client et il est désérialisé. La zone de travail en cours est ensuite mise à jour avec le nouveau contexte. Si la partition n'est pas configurée comme étant bidirectionnelle et que le serveur tente de modifier ou de supprimer le contexte dans la zone de travail 1, il reçoit une exception com.ibm.websphere.workarea.NotOriginator car le client est l'émetteur de la zone de travail. Le serveur peut extraire le contexte dans la zone de travail 1. Ceci constitue la principale différence entre la propagation bidirectionnelle et la propagation non bidirectionnelle du contexte.

Exemple : Propagation bidirectionnelle du contexte de zone travail imbriquée

Si une application éloignée doit ajouter un contexte à une zone de travail qu'elle seule ou tout autre objet distant peut utiliser, elle doit créer une autre zone de travail. Lorsqu'une zone de travail est créée, le contexte supplémentaire voit sa portée limitée à cette application et n'est pas transmis de nouveau à l'application appelante. L'imbrication des zones de travail a pour avantage principal de permettre à une application de limiter la portée du contexte d'une zone de travail à une application donnée. Si, comme indiqué dans l'illustration présentée à l'étape précédente, le serveur a créé une zone de travail avant de remplacer la valeur de clé1, de supprimer la propriété de clé2 ou d'ajouter des propriétés à clé5 et clé6, ces modifications ne sont pas propagées de nouveau au client. Ce processus est décrit dans la figure Distribution du contexte de zone de travail imbriquée lorsqu'il est configuré pour la propagation bidirectionnelle. Cette dernière démontre également que le client ne reçoit pas le contexte provenant de la zone de travail imbriquée lancée par le serveur.

Figure 2. Distribution du contexte de zone de travail imbriquée lorsqu'il est configuré pour la propagation bidirectionnelle. Cette figure illustre la distribution du contexte de zone de travail imbriquée lorsque le service est configuré pour la propagation bidirectionnelle. Exemple de propagation bidirectionnelle du contexte de zone de travail imbriquée

Sérialisation d'attribut reportée du contexte de zone de travail

Par défaut, lors de chaque opération de définition (set), l'attribut défini dans une zone de travail est automatiquement sérialisé par le service WorkArea. Ensuite, lors de chaque opération d'extraction (get), cet attribut est désérialisé et renvoyé au demandeur. Le contrôle qu'exerce le service WorkArea sur l'attribut est si complet que toutes les modifications apportées à un objet modifiable ne sont reflétées dans la copie de la zone de travail de l'attribut que si un utilisateur redéfinit spécifiquement l'attribut dans la zone de travail. Cela peut toutefois entraîner un nombre trop élevé d'opérations de sérialisation et de désérialisation.

Une telle situation peut provoquer une baisse sensible des performances lorsque la charge de travail est élevée. La propriété de configuration de sérialisation d'attribut reportée est une fonction de mise en cache qui réduit le nombre des opérations de sérialisation et de désérialisation. Lorsque la sérialisation d'attribut reportée est activée (en sélectionnant Sérialisation d'attribut reportée lors de la création de la zone de travail) dans un processus serveur, les attributs définis dans le service WorkArea ne sont pas automatiquement sérialisés lors de l'opération de définition (set). En revanche, une référence à l'attribut est enregistrée dans la zone de travail. Si l'attribut est modifiable, les modifications apportées à l'objet sont reflétées dans la référence de la zone de travail à cet attribut. Lorsqu'une opération d'extraction (get) est effectuée sur cet attribut, la référence à cet objet est renvoyée et aucune désérialisation n'est effectuée.

Les attributs ne sont sérialisés qu'au moment où l'unité d'exécution à laquelle l'attribut est associé émet un appel IIOP à distance. L'attribut est alors sérialisé et c'est sous cette forme qu'il est mis en cache. Si l'attribut n'est pas redéfini dans la zone de travail, les modifications apportées à l'attribut d'origine sont tout de même reflétées dans l'attribut contenu dans la zone de travail car cette dernière contient encore une référence en cache à l'objet d'origine. Cependant, si l'attribut n'est pas redéfini dans la zone de travail (ce qui indique à cette dernière que l'attribut a été modifié), la version sérialisée mise en cache de l'attribut continue d'être utilisée dans les requêtes à distance ultérieures et les modifications directes apportées à l'attribut modifiable ne sont pas propagées. Cela indique combien les choses sont différentes lorsque la propriété de configuration d'attribut reportée est activée ou non. Il convient donc de prendre soigneusement en compte ces facteurs et de bien comprendre la manière dont les objets modifiables sont gérés lorsque cette propriété est activée. Le service WorkArea génère des références d'attribut en cache et des versions sérialisées en cache des attributs dans les cas de figure ci-après.

  • Un attribut est redéfini ou supprimé.
  • La zone de travail est explicitement terminée par l'application.
  • Le composant serveur arrête l'exécution de la requête au cours de laquelle la zone de travail a été créée.
  • Le processus client ayant créé la zone de travail s'arrête.

Propagation du contexte de partition d'un processus à l'autre

Le contexte de la zone de travail est propagé automatiquement du client au serveur lorsqu'un client émet un appel à distance au serveur. Par exemple, si un client est configuré avec trois partitions Work Area différentes lorsqu'il envoie un appel à distance au serveur serveur1, le contexte associé à chaque partition dans l'unité d'exécution du client est propagé au serveur1. Si ces trois partitions ont été créées sur le serveur1, le contexte est désérialisé dans la partition appropriée. Cependant, si aucune des trois partitions n'a été créée sur le serveur1 ou si un petit nombre d'entre elles seulement l'ont été, seul le contexte associé à une partition qui réside à la fois sur le client et sur le serveur est désérialisé. Le contexte associé à une partition, qui ne réside pas sur le serveur1, réside encore sur le serveur1 mais n'est pas accessible. Le contexte associé à des partitions qui ne résident pas sur le serveur1 doit résider encore sur le serveur1 au cas où un autre appel à distance serait émis vers un serveur différent. En allant plus loin, si le serveur1 émet un appel à un autre serveur, serveur2, qui dispose des mêmes partitions que celles du client, le serveur2 reçoit le contexte pour les partitions qui ne résidaient pas sur le serveur1. Les partitions qui résident sur le serveur1 et non sur le client voient maintenant leur contexte propagé au serveur2.

Pour plus d'informations sur les zones de travail, voir le module com.ibm.websphere.workarea dans la documentation sur les API (Application Programming Interface). La documentation sur les API générées est disponible dans la table des matières du centre de documentation, sous Référence > APIs - Application Programming Interfaces.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwa_partition
Nom du fichier : cwa_partition.html