Comportement lors de l'exécution

Le sous-système de courtier d'événements du portail offre un support pour la communication entre portlets, avec des notifications actives via des événements de portlets ou le modèle de programmation coopératif.

Le courtier d'événements se base sur un modèle de communication de publication/abonnement associé : les portlets participants déclarent les messages ou les types de données qu'ils peuvent publier ou consommer, sans besoin de connaître la structure de communication réelle.

En fonction du modèle de programmation utilisé, les sources et les cibles sont définies et implémentées de façon différente (voir la documentation sur l'interopérabilité entre des événements et des portlets coopératifs) ; au niveau des concepts décrits ici, elles sont toutefois traitées de la même façon.
Remarque : Les explications suivantes s'appliquent à des portlets standard.

La distribution des messages entre des portlets est déterminée par les connexions de portlets définies dans le cadre de l'édition de la page. Les connexions de portlets relient la sortie définie d'un portlet dans une page à la sortie définie d'un autre portlet dans la même page ou dans une autre.

L'étape de connexion est séparée du développement et du déploiement. Ceci permet un développement indépendant des portlets source et cible, tant que ces portlets utilisent des types de données et des sémantiques en commun pour l'échange d'informations. Les portlets peuvent fonctionner de façon autonome, et quand des portlets partenaires pour la communication sont ajoutés en modifiant des pages, ils peuvent échanger des informations et réagir de façon coordonnée, ce qui améliore l'expérience de l'utilisateur. A l'inverse, lorsque des portlets sont supprimés, ceux qui restent continuent à fonctionner correctement.

Phases d'action/événement et de rendu

Le cycle de traitement d'une demande de portail comporte une phase d'action/événement qui traite l'entrée utilisateur, et une phase de rendu qui génère la sortie du marquage. L'activité du sous-système de courtier d'événements se produit lors de la phase d'action/événement. Le traitement des événements commence généralement par une action du portlet codée dans l'URL de demande en cours. Par exemple, il peut s'agir d'une URL d'action de portlet ou d'une URL générée par une menu click-to-action. Pour des demandes qui n'ont pas besoin de l'activité du portlet et ne font que produire la sortie, la phase d'action/événement peut être totalement ignorée.

Si la demande indique une action de portlet, celle-ci sera exécutée et pourra publier elle-même une sortie, soit en tant qu'événement JSR 286, soit comme propriété de portlet coopératif. Si cette sortie est liée à celle d'un ou plusieurs autres portlets, un appel des méthodes de traitement de ces portlets est placé dans la file d'attente d'événements. Lorsque la première action de portlet s'achève, l'événement suivant est pris de la file d'attente et le portlet cible est appelé. Au cours du traitement des événements, le portlet cible peut déclencher d'autres appels de communication qui sont alors également mis file en attente. Ce processus se répète tant que la file d'attente n'est pas vide.

Ceci permet la synchronisation de plusieurs portlets dans un cycle demande-réponse. Par exemple, dans le contexte d'une commande de marchandises par un client, ce qui suit se produit :
  1. Transfert de l'ID de commande au portlet Détails de la commande.
  2. Cette première étape lance aussi le transfert de l'ID de suivi pour la commande au portlet Détails du suivi.
  3. Le portlet Détails du suivi déclenche à son tour le transfert au portlet Détails du client du nom du client associé à la commande.
  4. Par conséquent, les trois portlets affichent des informations appartenant à une même commande.
Pour éviter des boucles infinies, la distribution d'événements s'arrête lorsque la limite maximum d'appels de portlets est atteinte ; il s'agit d'un cas d'erreur qui doit être évité.
Remarque : Le traitement d'événements est complètement séquentiel et jamais imbriqué dans une demande client : chaque événement ou action cible subit un traitement complet avant l'appel du suivant. Le portail garantit que l'ordre dans lequel les événements sont distribués à une même cible respecte celui dans lequel ils ont été publiés. Toutefois, pour des questions de performances, les événements pour diverses cibles peuvent être réordonnés afin de réduire les changements de contexte.

Communication entre pages

Les connexions peuvent relier une sortie source d'un portlet dans une page à des événements cible d'autres portlets dans d'autres pages. Toutes les cibles, qu'elles soient dans la même page ou dans plusieurs, sont traitées lors de la phase d'action/événement d'un cycle de demande. Un réacheminement à la page cible peut uniquement être effectué au terme de la phase d'action/événement. Pour des détails sur la connexion et la connexion entre pages, voir la documentation sur les connexions de portlets.
Remarque : Ce comportement implique que le portlet cible qui reçoit des appels d'événements ou d'actions d'une connexion entre pages puisse être dans une page autre que celle en cours. En d'autres termes, la "page en cours" au moment de l'exécution peut être une autre que celle contenant le portlet cible. Le code du portlet qui se base sur la récupération d'informations de programmation sur le contexte de la page en cours lors de la phase d'action/événement doit être préparé pour gérer ce cas.