Les trois parties de ce modèle sont :

• L’attribution (leasing). Elle permet de gérer la durée de vie des objets distribués en étendant la notion de ramasse-miettes (garbage collector) aux environnements distribués.
• Les transactions. Il s’agit d’une manière de regrouper un ensemble d’opérations impliquant plusieurs entités (clients, services) afin d’assurer un certain degré d’atomicité dans l’exécution de ces opérations.
• Les événements distribués (distributed events), qui étendent la notion d’événements Java aux environnements distribués.

Les services initiaux discovery, join et lookup sont construits selon ce modèle ; les autres services présents sur la fédération peuvent également l’être, à la convenance de leur développeur.

Le leasing permet à des objets présents sur des machines virtuelles Java (JVM) distinctes de négocier et obtenir la réservation de ressources de toutes sortes. Le processus de leasing prévoit les conditions du maintien et de la suppression de la réservation de ressource, y compris en cas de blocage du système distribué (panne d’un élément...).

Sur un système Java non distribué, un objet instancié est conservé en mémoire tant que subsiste une référence pointant vers lui. À la suppression de la dernière référence, le garbage collector se charge de libérer l’espace-mémoire qu’occupait l’objet devenu inutile.

Dans le cadre d’un système distribué, un tel procédé n’est pas applicable. Imaginons par exemple qu’une entité réserve une ressource rare sur un système distant, puis subisse une panne qui rende hors service. Le système distant conserve la réservation indéfiniment, croyant la ressource employée. La ressource est bloquée, sans espoir d’être libérée pour un usage plus productif.

Le leasing réside sur le principe suivant : au lieu d’allouer une ressource jusqu’à ce que le requérant déclare explicitement ne plus en avoir besoin, on alloue la ressource pour une période donnée (qui peut être négociée entre les deux parties, ou imposée par le gestionnaire de la ressource). Bien entendu, le bail peut être renouvelé ad libitum, si les circonstances le permettent. En cas de problème, la ressource n’est bloquée que le temps du bail et redevient disponible à l’expiration de celui-ci.

De plus, le modèle de leasing permet d’éviter l’accumulation sur un serveur de ressources réservées mais non utilisées. En effet, dans un système traditionnel, certaines ressources peuvent être réservées puis " oubliées " par des clients ; avec le système de leasing, la nécessité de renouveler régulièrement le bail impose au client de sélectionner avec plus de discernement les ressources qu’il juge nécessaires.

• Un bail est une période durant laquelle le fournisseur du bail garantit au demandeur l’accès à une certaine ressource. La durée peut en être définie par le fournisseur ou négociée par les deux parties.
• Pendant la durée du bail, celui-ci peut être annulé par le demandeur. Les ressources en jeu sont alors libérées.
• Un demandeur peut demander la reconduction du bail, pour une durée qui peut différer de la durée précédente.
• Un bail peut expirer. S’il n’est pas renouvelé, les ressources impliquées sont libérées.

Une transaction est un ensemble d’opérations groupées de manière à étendre le principe d’atomicité, selon les critères suivants :

• Elles réussissent ou échouent ensemble.
• Pour un observateur extérieur, elles constituent une unique opération.

Les transactions jouent un rôle crucial dans la fiabilité des environnements distribués en assurant la cohérence des opérations d’un ensemble d’entités distinctes. En cas de problème chez un des participants d’une transaction, l’ensemble de l’opération échoue, ce qui évite de laisser des entités dans des états intermédiaires.

Le protocole de transaction distribuée est conçu pour satisfaire aux conditions dites ACID :

• Atomicité (Atomicity) : Toutes les opérations groupées dans une transaction ont lieu ou bien aucune d’entre elles n’a lieu. Le protocole permet aux participants d’une transaction de découvrir quelle partie de cette alternative est attendue par les autres participants. Cependant, chaque objet est libre de déterminer s’il souhaite opérer de concert avec les autres participants.
• Cohérence (Consistency) : Le fait de compléter une transaction doit laisser le système dans un état cohérent. La cohérence peut faire intervenir des notions connues seulement des humains ; les techniques de maintien de la cohérence d’un système ne sont pas spécifiées par Jini.
• Isolation : Des transactions en cours ne peuvent pas s’affecter mutuellement. Les participants d’une transaction ne doivent voir que les états intermédiaires de leur propre transaction, et ne pas avoir accès aux états intermédiaires d’autres transactions. Le protocole permet donc aux objets participants de savoir quelles opérations ont lieu dans le cadre d’une transaction. C’est à chaque objet de choisir individuellement si une opération peut être vue uniquement par les objets participant à une transaction ou par tous.
• Durabilité (Durability) : Les résultats d’une transaction doivent subsister aussi longtemps que les entités en jeu. La durabilité n’est pas garantie par Jini, mais est spécifique de l’implémentation de chaque objet.

Une transaction est créée et surveillée par un manager. Un manager est un objet qui implémente une interface (au sens de Java) particulière, l’interface TransactionManager. La sémantique de la transaction est représentée par des objets particuliers que s’échangent les clients et les participants de la transaction, construits par exemple à partir d’un objet TransactionFactory.

Un client crée une transaction en formulant une requête au manager (le client peut obtenir la référence au manager par un service de lookup, par exemple), qui a pour objet de créer un objet sémantique. L’objet ainsi créé est passé comme paramètre lorsqu’ont lieu des opérations sur un service. Si ce service accepte l’opération, il doit rejoindre la transaction en tant que participant. Un client qui a formulé une transaction ne participe pas nécessairement à la transaction.

Une transaction se termine (to complete en anglais) lorsqu’une entité quelconque de la transaction valide (to commit) ou annule (to abort) celle-ci. Si une transaction est validée, toutes les opérations impliquées dans la transaction sont effectuées. Si une transaction et annulée, le système doit apparaître comme si aucune de ces opérations n’avait eu lieu.

La validation d’une transaction implique le vote de chaque participant. Les trois votes possibles sont :

• Prêt (prepared), si le participant estime que la transaction, de son point de vue, peut être validée.
• Inchangé (not changed), si les opérations qui le concernaient étaient en lecture seule.
• Annuler (aborted), si le participant estime que la transaction ne doit pas être validée.

Si tous les participants votent prêt ou inchangé, la transaction est validé et le manager indique aux objets ayant voté prêt qu’ils peuvent basculer (roll forward) dans l’état résultant des opérations constitutives de la transaction. Les participants ayant voté inchangé n’ont rien à faire.

Si la transaction est annulée, tous les participants doivent revenir (roll back) à l’état qui était le leur antérieurement à la transaction.

Dans un modèle à unique espace d’adressage, certains objets peuvent réagir à un changement d’état au sein d’un autre objet. Par exemple, une action de l’utilisateur (un clic de souris) peut influer sur le comportement de plusieurs objets. En langage Java, on fait appel à la notion d’événement pour modéliser l’interaction entre objets et actions extérieures. Les événements locaux présentent certaines caractéristiques essentielles, parmi lesquelles le fait que leur transmission peut être considérée comme fiable, ordonnée, prévisible et quasiment instantanée.

Dans un environnement distribué, on peut chercher à étendre la notion d’événements, en tenant compte des caractéristiques suivantes :

• Les notifications d’événements n’arrivent pas forcément à destination.
• L’ordre chronologique des événements n’est pas forcément conservé.
• L’objet ayant manifesté son intérêt pour un événement n’est pas nécessairement celui à qui la notification doit être envoyée.

Les écouteurs d’événement distants (remote event listeners) sont des objets qui présentent un intérêt pour la survenue d’un événement dans un objet distinct. La principale fonction d’un écouteur d’événement est de recevoir des notifications de la part de générateurs d’événements.

Un événement distant (remote event) est un objet qui est transmis entre un générateur et un écouteur pour indiquer qu’un événement particulier a eu lieu, ainsi que ses principales caractéristiques.

L’intérêt de ce modèle est de permettre l’introduction d’entités intermédiaires, ou agents, capables d’accroître les fonctionnalités d’un environnement distribué sans en changer les interfaces de base. Les principaux types d’agents sont les suivants :

• L’agent de relais (store-and-forward agent). Le but de cet objet est d’agir au nom du générateur d’événement et de prendre en charge l’envoi des notifications aux écouteurs enregistrés selon des modalités prédéfinies (envoi régulier de notifications jusqu’à acquittement, par exemple).
• Le filtre de notification (notification filter). Cet objet peut être local soit au générateur, doit à l’écouteur d’événement, et génère un fil (thread) chargé de s’occuper d’une notification lors de sa réception.
• La boîte à notification (notification mailbox). Cet objet stocke les notifications pour le compte d’un autre objet, jusqu’à ce que cet objet lui demande la distribution de son " courrier ". Ce dispositif permet à un objet de ne recevoir de notifications d’événements que lorsqu’il le souhaite, sans que celles-ci se perdent.