Annexe E
Joram : un intergiciel de communication asynchrone

E.1  Introduction

E.1.1  Les intergiciels à messages (MOM)

• Intégration de données et intégration d'applications (EAI, B2B, ESB, etc.)
  
  
• Systèmes ubiquitaires et usages de la mobilité.
  
  
• Surveillance et contrôle d'équipements en réseau.
  
  

• Les entités communicantes sont découplées. L'émission (on dit aussi la production) d'un message est une opération non bloquante. D'autre part émetteur (producteur) et récepteur (consommateur) ne communiquent pas directement entre eux mais utilisent un objet de communication intermédiaire (boîte aux lettres).
  
  
• Deux modèles de communication sont fournis : un modèle point à point dans lequel un message produit est consommé par un destinataire unique ; un modèle multi-points dans lequel un message peut être adressé à une communauté de destinataires (communication de groupe).
  
  
• Le mode multipoints est généralement doublé d'un système de désignation associative dans lequel les destinataires du message sont identifiés par une propriété du message. Ce mode de communication est à l'origine du modèle Publication/Abonnement (Publish/Subscribe) largement répandu aujourd'hui.
  
  

E.1.2  JMS (Java Messaging Service)

Figure E.1: Application JMS

• Le système de messagerie JMS (JMS provider). Dans la mise en oeuvre du système de messagerie on distingue le service de base qui met en œuvre les abstractions du modèle de programmation JMS et une bibliothèque de fonctions liée aux programmes utilisateurs qui met en œuvre l'interface de programmation JMS.
  
  
• Les clients JMS (JMS client) sont les programmes (applications), écrits en langage Java, qui produisent (émettent) et consomment (reçoivent) des messages selon des protocoles spécifiés par l'API JMS.
  
  
• Les messages JMS sont des objets qui permettent de véhiculer des informations entre des clients JMS. Différents types de messages sont utilisables : texte structuré (par exemple un fichier XML), format binaire, objets Java (sérialisés), etc.
  
  

Figure E.2: Modèle de communication Point à Point

Figure E.3: Modèle de communication Publish/Subscribe

E.1.3  Ce que JMS ne dit pas et ne fait pas

E.1.4   JORAM : une mise en œuvre d'un service de messagerie JMS

• Comme un système de messagerie Java autonome entre des applications JMS développées pour des environnements variés (de J2EE à J2ME).
  
  
• Comme un composant de messagerie intégré dans un serveur d'application J2EE. A ce titre, JORAM est une brique essentielle du serveur J2EE JOnAS, également disponible sur ObjectWeb - http://jonas.objectweb.org
  
  

Figure E.4: La plate-forme JORAM

E.2  Le modèle de programmation JMS

E.2.1  Les abstractions de JMS

• ConnectionFactory : un objet d'administration utilisé par le client JMS pour créer une connexion avec le système de messagerie.
  
  
• Connection : une connexion active avec le système de messagerie.
  
  
• Destination : l'objet de communication entre deux clients JMS. Cet objet désigne la destination des messages pour un producteur et la source des messages attendus pour un consommateur. La destination désigne une Queue de messages dans le modèle de communication point à point et un Topic dans le modèle de communication Publish/Subscribe.
  
  
• Session : un contexte (mono-thread) pour émettre et recevoir des messages.
  
  
• MessageProducer : un objet créé par une session et utilisé pour émettre des messages à un objet Destination.
  
  
• MessageConsumer : un objet créé par une session et utilisé pour recevoir les messages déposés dans un objet Destination.
  
  

Figure E.5: Correspondance des interfaces Point à Point et Publish/Subscribe

E.2.2  Principe de fonctionnement

• Il recherche un objet ConnectionFactory dans un répertoire en utilisant l'API JNDI (Java Naming and Directory Interface)
  
  
• Il utilise l'objet ConnectionFactory pour créer une connexion JMS, il obtient alors un objet Connection.
  
  
• Il utilise l'objet Connection pour créer une ou plusieurs sessions JMS, il obtient alors des objets Session.
  
  
• Il utilise le répertoire pour trouver un ou plusieurs objets Destination.
  
  
• Il peut alors, à partir d'un objet Session et des objets Destination, créer les objets MessageProducer et MessageConsumer pour émettre et recevoir des messages.
  
  

Figure E.6: Architecture d'une application JMS

E.2.3  Messages

• Il fournit une interface de message unique.
  
  
• Il supporte les messages contenant du texte, des objets Java ou des données XML.
  
  

Structure des messages

• Un en-tête : qui contient l'ensemble des données utilisées à la fois par le client et le système pour l'identification et l'acheminement du message.
  
  
• Des propriétés : en plus des champs standard de l'en-tête, les messages permettent d'ajouter des champs optionnels sous forme de propriétés normalisées, ou de propriétés spécifiques à l'application ou au système de messagerie.
  
  
• Un corps : JMS définit différents types de corps de message afin de répondre à l'hétérogénéité des systèmes de messagerie.
  
  

En-tête des messages

• JMSDestination : ce champs contient la destination du message, il est fixé par la méthode d'envoi de message en fonction de l'objet Destination spécifié.
  
  
• JMSDeliveryMode : ce champ définit le mode de délivrance du message (persistant ou non²) ; il est fixé par la méthode d'envoi de message en fonction des paramètres spécifiés.
  
  
• JMSMessageId : ce champs contient un identificateur qui identifie de manière unique chaque message envoyé par un système de messagerie. Il est fixé par la méthode d'envoi de message et peut-être consulté après envoi par l'émetteur.
  
  
• JMSTimeStamp : ce champs contient l'heure de prise en compte du message par le système de messagerie, il est fixé par la méthode d'envoi de message.
  
  
• JMSReplyTo : ce champs contient la Destination à laquelle le client peut éventuellement émettre une réponse. Il est fixé par le client dans le message.
  
  
• JMSExpiration : ce champs est calculé comme la somme de l'heure courante (GMT) et de la durée de vie d'un message (time-to-live). Lorsqu'un message n'est pas délivrée avant sa date d'expiration il est détruit ; aucune notification n'est définie pour prévenir de l'expiration d'un message.
  
  
• JMSCorrelationId, JMSPriority, JMSRedelivered, JMSType, etc.
  
  

Propriétés

Corps du message

• StreamMessage : un message dont le corps contient un flot de valeurs de types primitifs Java ; il est rempli et lu séquentiellement.
  
  
• MapMessage : un message dont le corps est composé d'un ensemble de couples noms-valeurs.
  
  
• TextMessage : un message dont le corps est une chaîne de caractère (String).
  
  
• ObjectMessage : un message dont le corps contient un objet Java sérialisable.
  
  
• BytesMessage : un message dont le corps est composé d'un flot d'octets ; ce type de message permet de coder un message conformément à une application existante.
  
  

E.2.4  Objets JMS

Objets d'administration

Objet Connection

Objet Session

• Il construit les objets MessageProducer et MessageConsumer.
  
  
• Il crée les objets Destination et Message.
  
  
• Il supporte les transactions et permet de grouper plusieurs opérations de réception et d'émission dans une unité atomique qui peut être validée (resp. invalidée) par la méthode Commit (resp. Rollback).
  
  
• Il réalise l'ordonnancement des messages reçus et envoyés.
  
  
• Il gère l'acquittement des messages.
  
  

Objet MessageConsumer

Objet MessageProducer

E.2.5  Communication en mode Point à point

E.2.6  Communication en mode Publish/Subscribe

E.2.7  JMS par l'exemple

Initialisation d'une session "Point-to-Point"

// We need a pre-configured ConnectionFactory.
// Get it by looking it up using JNDI.
Context messaging = new InitialContext();
QueueConnectionFactory connectionFactory =
                                        (QueueConnectionFactory) messaging.lookup(" &");

// Gets Destination objects using JNDI.
Queue queue1 = (Queue) messaging.lookup(" &");
Queue queue2 = (Queue) messaging.lookup(" &");

// Creates QueueConnection, then use it to create a session.
QueueConnection connection = connectionFactory.createQueueConnection();
QueueSession session = connection.createQueueSession(
                                        false,  // not transacted
                                        Session.AUTO_ACKNOWLEDGE);      // acknowledge on receipt

// Getting a QueueSender and a QueueReceiver.
QueueSender sender = session.createSender(queue1);
QueueReceiver receiver = session.creatReceiver(queue2);

// Getting a QueueReceiver with a selector message.
Queue queue3 = (Queue) messaging.lookup(" &");
String selector = new String("(name = 'Bull') or (name = 'IBM'))");
QueueReceiver receiver2 = session.creatReceiver(queue3, selector);

Initialisation d'une session "Publish/Subscribe"

// We need a pre-configured ConnectionFactory.
// Get it by looking it up using JNDI.
Context messaging = new InitialContext();
TopicConnectionFactory connectionFactory =
                                        (TopicConnectionFactory) messaging.lookup(" &");
// Gets Destination object using JNDI.
Topic Topic = (Topic) messaging.lookup(" &");

// Creates TopicConnection, then use it to create a session.
TopicConnection connection = connectionFactory.createTopicConnection();
TopicSession session =
                                        connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE);

// Getting a TopicPublisher  &
TopicPublisher publisher = session.createPublisher(Topic);
//  & then a TopicSubscriber.
TopicSubscriber subscriber = session.createSubscriber(Topic);
Subscriber.setMessageListener(listener);

Construction de messages

byte[] data
BytesMessage message = session.createByteMessage();
message.writeBytes(data);
Utilisation d'un TextMessage
StringBuffer data
TextMessage message = session.createTextMessage();
message.setText(data);

MapMessage message = session.createMapMessage();
message.setString("Name", " &");
message.setDouble("Value", doubleValue);
message.setLong("Time", longValue);

StreamMessage message = session.createStreamMessage();

message.writeString(" &");
message.writeDouble(doubleValue);
message.writeLong(longValue);

ObjectMessage message = session.createObjectMessage ();
message.setObject(obj);

Envoi et reception de messages

// Sending of all of these message types is done in the same way:
sender.send(message);
// Receiving of all of these message types is done in the same way. Here is how to
// receive the next message in the queue.
// Note that this call will block indefinitely until a message arrives on the queue.
StreamMessage message;
message = (StreamMessage)receiver.receive();

// Sending (publishing) of all of these message types is done in the same way:
publisher.publish(message);
// Receiving of all of these message types is done in the same way. When the
// client subscribed to the Topic, it registered a message listener. This listener
// will be asynchronously notified whenever a message has been published to
// the Topic. This is done via the onMessage() method in that listener class.
// It is up to the client to process the message there.
void
onMessage(Message message) throws JMSException {
        // unpack and handle the messages we receive.
        ...
}

Lecture d'un message

byte[] data;
int length;
length = message.readBytes(data);
TextMessage
StringBuffer data;
data = message.getText();
MapMessage              // Note : l'ordre de lecture des champs est quelconque. 
String name = message.getString("Name");
double value = message.getDouble("Value");
long time = message.getLong("Time");
StreamMessage   // Note : l'ordre de lecture des champs
                                // doit etre identique a l'ordre d'ecriture.
String name = message.readString();
double value = message.readDouble();
long time = message.readLong();
ObjectMessage
obj = message.getObject();

E.3  Architecture de JORAM

E.3.1  Principes directeurs et choix de conception

La caractéristique essentielle de la plate-forme JORAM est son architecture distribuée et configurable. L'architecture de base de JORAM est de type snowflake, c'est-à-dire qu'une plate-forme JORAM est constituée d'un ensemble de serveurs JORAM distribués, interconnectés par un bus à message. Chaque serveur gère un nombre variable de clients JMS. La répartition des serveurs et la distribution des clients sur les serveurs sont de la responsabilité de l'administrateur de la plate-forme JORAM en fonction des besoins de l'application. Ce choix constitue donc un premier niveau de configuration. Un deuxième niveau réside dans la capacité de localiser les destinations (Queues et Topics ) en fonction des besoins (nous verrons plus loin que ce choix d'implantation a des conséquences importantes sur les propriétés de l'application : performance, évolutivité, etc.). Un dernier niveau de configuration concerne les paramètres de qualité de service associés au bus à messages(protocole de communication, sécurité, persistance, etc.). Le choix de mécanismes appropriés est ici le résultat d'un compromis entre le niveau de qualité de service souhaité et le coût de la solution correspondante. Figure E.7: Architecture de la plate-forme JORAM

L'architecture générale d'une plate-forme JORAM est illustrée dans la figure 7.

E.3.2  Architecture logique

• La gestion des communications entre le client et le serveur.
  
  
• L'acheminement des messages vers / depuis la destination (ici une queue de messages).
  
  

Modèle de communication point à point

1. L'interprétation d'une primitive Send d'un client JMS producteur se traduit par l'envoi d'un message sur la connexion entre le client JORAM et l'objet Proxy (noté ici Proxy-P) associé au client dans le serveur JORAM. Cette interaction est représentée par la flèche pleine 1.
   
   
2. L'objet Proxy-P encapsule le message JMS dans un message destiné à être véhiculé par le bus (noté ici Message MOM). Ce message est sauvegardé dans un support persistant local. Un accusé de réception est envoyé au client JORAM qui le remonte ensuite au client JMS (flèche pointillée 2). Du point de vue du client JMS, l'opération Send est terminée.
   
   
3. Le message construit par l'objet Proxy est véhiculé par le MOM vers le site de résidence de la queue de messages. Cette interaction est représentée par la flèche pleine 3. Sur le site où se trouve la queue de messages, le message est enregistré sur un support persistant local.
   
   
4. L'interprétation d'une primitive Receive par le client consommateur génère un message de contrôle vers l'objet Proxy associé (noté ici Proxy-C) qui le fait suivre au site où se trouve la file de message (objet Queue ). Le message applicatif correspondant est extrait de la queue de messages et est envoyé vers l'objet Proxy-C. Celui-ci extrait le message JMS de son enveloppe véhiculée par le MOM et l'envoie au client JMS. Cette suite d'échanges est représentée par les flèches pleines 4. La requête Receive du client consommateur est terminée.
   
   
5. Un accusé de réception est envoyé vers le site de la localisation de l'objet Queue afin de retirer le message de la queue et de libérer les ressources correspondantes (flèches pointillées). L'accusé de réception peut être généré par le client JMS ou par le système.
   
   

Figure E.8: Communication Point à Point

Modèle de communication Publish/Subscribe

1. Les étapes 1 et 2 sont similaires à celles du modèle de communication point à point.
   
   
2. Dans l'étape 3, le message construit par le Proxy du producteur est acheminé directement vers l'ensemble des objets Proxy des consommateurs où ils sont enregistrés. Notons ici une différence essentielle avec le schéma précédent dans la mesure ou l'objet Topic est utilisé, non pas comme une destination finale, mais plutôt comme un aiguillage vers un ensemble de destinations finales représentées par les objets Proxy des consommateurs.
   
   
3. L'opération de consommation du message se traduit par un échange entre le client et l'objet Proxy-C (flèches pleines 4). L'accusé de réception est ensuite envoyé vers l'objet Proxy-C (flèche pointillée 5). Par rapport au schéma précédent on notera que le protocole de consommation se limite à un dialogue entre le client et l'objet Proxy. Il n'y a pas de dialogue entre les objets Proxy et le Topic .
   
   

Figure E.9: Modèle de communication Publish/Subscribe

E.3.3  Architecture centralisée

Figure E.10: Architecture centralisée

E.3.4  Architecture distribuée

Dans une architecture distribuée, plusieurs serveurs JORAM coopèrent pour assurer la communication des messages entre des clients connectés à ces divers serveurs. La Figure 11décrit la structure des échanges pour une architecture répartie sur trois sites géographiques composés chacun d'un serveur et d'un client. Le schéma représenté utilise l'exemple d'une communication point à point dans lequel chaque serveur est responsable de la queue de messages destinés aux clients JMS connectés à ce serveur⁵.

Le message JMS, émis par le client JMS Client à destination de la queue de messages Q3 est envoyé vers le proxy Px1 sur le serveur S1. Le message MOM qui encapsule le message JMS est généré. La fonction Store and Forward sauve le message localement avant de l'envoyer vers le serveur S3, où se trouve localisée la queue Q3. Le message stocké dans la queue Q3 peut être consommé par la suite par un client JMS connecté au serveur S3. De façon identique un message produit par le client JMS Client-2 à destination de la queue de messages Q1 est transmis via l'objet Px2 du serveur S2, puis est ensuite consommé par le client JMS Client à partir du serveur local S1.

Figure E.11: Architecture distribuée

La communication entre les serveurs est mise en œuvre par le bus à messages sous-jacent qui garantit l'acheminement des messages quelles que soit les pannes de sites et de réseau.

E.3.5   JORAM : une plate-forme JMS configurable

La construction d'une plate-forme JMS adaptée à un contexte applicatif donné est un exercice difficile dans la mesure où l'architecture de la plate-forme est le résultat de compromis délicats entre de nombreux critères souvent antinomiques, tels que performance, disponibilité, scalabilité, flexibilité et capacité d'évolution, sécurité, coûts de développement et d'exploitation, etc. Le rôle de l'architecte dans la définition d'une plate-forme est essentiel. À partir d'un cahier des charges il doit prendre en compte l'ensemble des critères d'évaluation et leur fixer un poids dans la perspective de définir l'architecture «« la mieux adaptée »». Ce travail n'est possible que si le service de messagerie fournit des capacités de configuration suffisantes pour traduire les options d'architecture retenues. C'est le cas de la plate-forme JORAM qui permet, à plusieurs niveaux, de définir les choix de conception appropriés :

• Organisation des serveurs et clients JMS, et placement des objets JMS. Comme cela est illustré dans la figure 7, La structure de la plate-forme JORAM est de type snowflake, ce qui donne à l'architecte du système une grande liberté pour décider de l'emplacement des serveurs et de la répartition des clients sur les serveurs pour répondre aux besoins de l'application (par exemple pour servir un ensemble de clients géographiquement proches dans une approche de type serveur de proximité, ou bien pour respecter certaines contraintes de sécurité). Multiplier le nombre de serveurs pour une meilleure couverture géographique des clients distribués a un coût d'exploitation (en terme de machines) qui doit être mis en balance avec la performance et la fiabilité des communications pour des clients très éloignés d'un serveur. Le dimensionnement des serveurs (calcul, mémoire, stockage) est également un point clé pour la performance et la disponibilité de l'ensemble du système.
  
  
• Placement des objets de communications (Queues et Topics ). Sauf dans des cas très particuliers, on peut noter qu'il est souhaitable de rapprocher les objets Destination des clients consommateurs. Cette stratégie a un impact positif sur les performances et la disponibilité des clients.
  
  
• Evolution du système et passage à l'échelle. Cette propriété fait référence à la capacité de faire évoluer le système pour répondre aux évolutions de l'application. JORAM fournit ainsi des fonctions d'administration qui permettent d'ajouter et/ou de retirer un serveur depuis un point central d'administration.
  
  
• Protocoles de communication. Plusieurs protocoles de transport sont disponibles pour la connexion client - serveur et pour les connexions entre serveurs : TCP/IP, HTTP, SOAP, SSL, etc.
  
  
• Paramètres de qualité de service (persistance, sécurité). La fiabilité et la mise en sécurité des communications a un coût. C'est pourquoi JORAM donne la possibilité de retenir ou non ces options selon les besoins.
  
  
• Niveau de disponibilité grâce à la clustérisation et à la réplication (voir plus loin en section 4).
  
  

E.4   JORAM : fonctions avancées

E.4.1  Répartition de charge

Topic répliqué

Figure E.12: Topic "clustérisé"

Queue répliquée

Le principe des «« queues clustérisées »» est un peu différent (voir figure 13). Plusieurs exemplaires du même objet Queue sont localisés sur des serveurs indépendants. Chacune de ces copies est accessible uniquement aux clients connectés au serveur correspondant. Si la charge sur une copie dépasse un certain seuil, les messages reçus ensuite sur cette copie sont redirigés vers un autre exemplaire de la même queue géré par un autre serveur. Le seuil est un paramètre configurable qui peut prendre en compte divers critères tels que : nombre de messages en attente, nombre de requêtes de lecture en attente, délai d'attente dépassé pour une requête en lecture, etc. Il est important de noter que la sémantique des queues de message n'est pas modifiée, à savoir qu'un message donné n'est consommé que par un seul client JMS).

Figure E.13: Clustered Queue

Comme dans le cas des Topic , le concept de queue clustérisée permet d'améliorer les performances et le niveau de disponibilité sans impact sur la programmation de l'application.

E.4.2  Fiabilité et haute disponibilité

• Un accusé de réception entre un client JMS et son représentant dans le serveur (objet proxy) permet de fiabiliser la communication entre client et serveur (sémantique «« au moins une fois »»).
  
  
• La fonction Store and Forward réalisée par le proxy permet de fiabiliser les échanges entre le proxy et la destination (sémantique «« exactement une fois »»).
  
  
• Enfin le bus à messages assure des échanges fiabilisés entre serveurs (voir 5.2).
  
  

Figure E.14: Serveur JORAM HA

E.4.3  Connectivité élargie

• Passerelle JMS pour l'interopérabilité avec d'autres plates-formes JMS,
  
  
• Utilisation du protocole SOAP
  
  
• Support de l'architecture de connectivité JCA 1.5
  
  
• Passerelles vers les protocoles SMTP et FTP
  
  

Passerelle JMS

Figure E.15: Passerelle JMS

• En tant que destination gérée par JORAM, il reçoit les messages produits par les clients producteurs et les requêtes des clients consommateurs gérés par la plate-forme JORAM.
  
  
• En tant que représentant d'un objet destination externe, il se comporte comme un client JMS géré par la plate-forme xMQ pour propager les messages et requêtes vers la destination finale.

  Utilisation du protocole SOAP

  L'utilisation du protocole HTTP-SOAP fournit un moyen normalisé pour accéder à des services distants en échangeant des messages XML sur des connexions HTTP. Dans certains cas il peut être utile d'utiliser ce protocole pour accéder depuis un client aux services d'un serveur JORAM, en particulier pour répondre aux besoins suivants :
  
  
• Contraintes de sécurité imposées par la gestion de pare-feux,
  
  
• Prise en compte de clients s'exécutant dans un environnement J2ME pour lequel l'API JMS complète ne peut pas être fournie (par exemple J2ME ne fournit pas de fonction de sérialisation des objets).
  
  

Figure E.16: Utilisation de SOAP et KJORAM

JCA 1.5

• Gestion du cycle de vie de la ressource : création, démarrage, arrêt.
  
  
• Gestion des connexions avec les composants EJB
  
  
• Gestion transactionnelle conforme à l'interface XA.
  
  

Connecteurs JORAM

• Passerelle mail : cette fonction permet d'émettre et recevoir des messages JMS en utilisant le protocole SMTP. La fonction est mise en oeuvre par le biais d'objets Queues et Topics spécialisés pour réaliser cette interopérabilité. Ces objets sont configurés et installés comme les destinations normales.
  
  
• Passerelle FTP : cette fonction est identique à la précédente pour le protocole FTP. C'est un dispositif utile lorsque les messages JMS à transporter sont de très grande taille.
  
  

E.4.4  Sécurité

E.5   JORAM : bases technologiques

E.5.1  Les agents distribués

• Modèle de programmation à base d'agents communicants. Les agents sont des objets Java distribués communiquant par messages. Le contenu d'un agent est défini par une classe Java héritant d'une classe pré-définie «« agent »» qui définit le comportement générique d'un objet agent. Les agents se conforment à un modèle de programmation de type «« événement-réaction »». Un événement correspond à la notification d'un message typé qui va se traduire par l'exécution d'une méthode de l'objet. Cette exécution peut, à son tour, provoquer la production d'événements auxquels un ou plusieurs agents vont réagir. Par défaut l'exécution d'une réaction est atomique (i.e. propriété du "tout ou rien") et l'état d'un agent est persistant.
  
  
• Environnement d'exécution : serveurs d'agents. Les agents s'exécutent au sein d'une structure d'accueil nommée «« serveur d'agents »», dont l'organisation est représentée sur la figure 17.
  
  

Figure E.17: Structure d'un serveur d'agents

• Le canal est chargé de distribuer les messages en provenance du moteur d'exécution vers les composants réseau et vice-versa.
  
  
• Les composants réseau sont responsables de l'émission de messages provenant du canal à destination des serveurs distants. Il existe différents composants réseau correspondant à différents protocoles de communication (par exemple TCP/IP, HTTP, SOAP, etc.). Par ailleurs, il est possible d'ajouter à un composant réseau des modules logiciels pour la mise en œuvre de propriétés complémentaires (par exemple sécurité, ordonnancement causal, etc.).
  
  

E.5.2   JORAM : une plate-forme JMS à base d'agents

• Queues et Topics sont représentés par des agents persistants.
  
  
• Sur chaque serveur un agent ConnectionManager gère les connexions avec les clients JMS gérés par ce serveur.
  
  
• Un agent Proxy persistant est créé pour chaque utilisateur reconnu par le système. Par la suite, cet agent a la charge de gérer la communication pour le compte des clients JMS (producteur ou consommateur) associés à cet utilisateur. Rappelons qu'une de ses fonctions essentielles est de mettre en oeuvre la fonction Store and Forward.
  
  

• Le choix des protocoles de communication (TCP/IP, HTTP, SOAP, etc.) et des paramètres de QoS (persistance et garantie de délivrance, sécurité, etc.).
  
  
• Un choix d'implantation des serveurs JORAM pour définir une configuration distribuée de type «« snowflake »» qui réponde aux besoins de l'application cible.
  
  
• Un choix d'implantation des objets (agents) Destination et des objets (agents) Proxy.
  
  

E.6  Conclusion

• Il est conforme à la spécification JMS1.1. Cette conformité a été démontrée dans le cadre de la campagne de certification J2EE 1.4 réalisée en liaison avec le serveur d'application JOnAS⁶. Il est donc possible d'utiliser JORAM comme environnement d'exécution de toute application distribuée qui suit l'interface de programmation définie par JMS.
  
  
• L'architecture de JORAM est distribuée et hautement configurable. Cette propriété permet de concevoir une plate-forme d'exécution adaptée aux besoins d'une application donnée.
  
  

Figure E.18: Les usages de JORAM

• Système de communication asynchrone fiable entre applications JMS s'exécutant dans des environnements Java variés (J2EE, J2SE, J2ME), y compris la possibilité d'établir une passerelle vers des applications s'exécutant sur des plates-formes JMS externes.
  
  
• Composant de messagerie asynchrone intégré dans un serveur d'application J2EE. L'intégration dans le serveur JOnAS (http://jonas.objectweb.org ) est la plus accomplie (administration globale unique). JORAM est également utilisé en liaison avec d'autres serveurs J2EE, en particulier JBoss.
  
  
• La combinaison des deux usages précédents permet d'élargir le champ d'action des serveurs d'application à des clients s'exécutant sur des dispositifs à faibles ressources (téléphones mobiles, équipements industriels, etc.).
  
  
• Interopérabilité avec des applications patrimoniales (legacy applications). JMS est aujourd'hui le canal de communication privilégié pour l'intégration d'application dans les plates-formes EAI (Enterprise Application Integration) et ESB (Enterprise Service Bus). En conséquence JORAM peut être utilisé comme base de mise en œuvre d'une telle plate-forme d'intégration.
  
  
• Coopération entre serveurs d'application J2EE. L'utilisation de JORAM permet ainsi de réaliser des versions distribuées du serveur d'application JOnAS.
  
  

• Etendre son champ d'application, en particulier dans le domaine des systèmes embarqués. Cet objectif requiert de pouvoir réaliser une version «« légère »» du serveur JORAM pour répondre aux contraintes de ressources de nombreuses classes d'équipements tels que carte à puce, lecteur RFID, contrôleur industriel, etc (en particulier pour ce qui concerne la mémoire RAM et la mémoire persistante de type mémoire flash) . Une approche, parmi d'autres, consiste à déporter une fonction store and forward dans la librairie client. Cette nouvelle structure permettrait également de mettre en œuvre, sous certaines conditions, des liaisons pair à pair (peer to peer) entre clients JORAM sans avoir recours à un serveur tiers.
  
  
• Améliorer les performances et les fonctions d'administration de la plate-forme JORAM. Ces deux aspects sont présentés globalement dans la mesure où ils présentent des dépendances fortes. La performance est un paramètre difficile à maîtriser car il dépend de critères multiples, tels que volume et taille des messages, nombre de clients, nombre de connexions, etc. L'optimisation d'une plate-forme JORAM relève à la fois de l'évolution de certains mécanismes internes (gestion de la concurrence, de la mémoire et de la persistance pour ne citer que ceux là), et du bon dimensionnement de la plate-forme pour un usage déterminé (par exemple les ressources des serveurs, le placement des objets de communication, etc.). Parmi les pistes explorées, l'usage d'un système de gestion de base de données pour gérer la persistance des messages est envisagé. Une piste à plus long terme concerne l'usage de mécanismes auto-adaptatifs pour permettre à une plate-forme JORAM de recueillir des informations sur son comportement afin de s'adapter «« spontanément »» à des défaillances (auto-réparation), à des baisses de performance (auto-optimisation), ou plus simplement à des changements de configuration (connexion / déconnexion d'un serveur).
  
  

Figure E.19: Joram et la médiation

• un ensemble de composants de médiation pour la collecte, le traitement et la remontée d'informations d'usage produites par des équipements, services ou applications délocalisés. Ces composants peuvent être personnalisés et assemblés pour décrire des flots de données entre des équipements et des applications métiers. A l'exécution, les composants sont mis en œuvre par des agents exécutés sous le contrôle d'un ensemble de serveurs d'agents.
  
  
• Un ensemble d'outils graphiques pour construire, déployer et administrer des solutions d'intégration par personnalisation et assemblage de ces composants. Ces outils s'appuient sur une représentation de type ADL.
  
  
• un service de déploiement pour automatiser le processus de déploiement d'une solution d'intégration sur un ensemble de sites.
  
  

E.7  Références

• Page d'accueil : http://joram.objectweb.org
  
  
• Manuel de l'utilisateur : http://joram.objectweb.org/doc/index.html
  
  
• Wiki JORAM : https://wiki.objectweb.org/joram/
  
  

• Page d'accueil JMS : http://java.sun.com/products/jms/
  
  
• Tutorial JMS : http://java.sun.com/products/jms/tutorial/index.html
  
  
• Forum JMS : http://forum.java.sun.com/forum.jsp?forum=29
  
  
• Introduction à JMS (dans IBM developerwork) : Ënterprise messaging with JMS"
  
  
• Nommage et administration (dans IBM developerwork) : Ïmplementing vendor-independent JMS solutions"
  
  
• JMS 1.1 (dans IBM developerwork) : "JMS 1.1 simplifies messaging with unified domains"
  
  
• Les architectures applicatives JMS (dans TheServerSide) : "JMS Application Architectures"
  
  

Footnotes: