Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

JORAM

JORAM

Présentation

 

JORAM est sortie en 1999 et est distribué sous licence LGPL depuis Mai 2000.

Caractéristiques principales du produit

Nous allons parcourir les caractéristiques de JORAM selon les classes de fonctionnalités présentées plus haut.

Implémentation

JORAM a une architecture interne élégante,basée sur le modèle d'agent.

Architecture de JORAM

Un agent est un composant logiciel répondant à certains événements. Dans le cas de JORAM, les événements sont sous forme de messages. Les queues et les topics sont ainsi représentés par des agents. Un utilisateur connecté à la plateforme est également représenté par un agent dit proxy. Cette approche offre une grande flexibilité, car elle permet la création et la suppression d'agents à la volée et sur n'importe quel broker. Un broker est donc uniquement un serveur d'agent (ou un container d'agent). À l’instar des EJB, ces agents ne peuvent pas encore être déplacés de broker en broker.

Le code source récupéré du SVN JORAM est assez bien documenté. Il est fait de « beans » séparés en Interfaces et Implémentations. Dans l’ensemble, le code respecte les bonnes pratiques de développement Java.

Langages pris en charge

Les langages par lesquels ont peut accéder à JORAM sont :

  • Java via l'interface JMS
  • C et C++ :à l'aide de JNI, permettant ainsi de simuler un environnement JMS.

Protocoles pris en charge

Le protocole interne de JORAM est propriétaire, et n'est pas documenté. Nous estimons que c’est un handicap dans la mesure où cela tend à limiter le nombre d’environnements dans lesquels des APIs sont offertes, et à rendre plus difficiles les interconnexions. Joram le désigne simplement par « TCP », mais il est évident qu’il y a un protocole, non spécifié, au dessus de TCP/IP.

Ainsi, JORAM ne s’appuie pas sur des protocoles standards comme
AMQP ou STOMP.

JORAM met à disposition des passerelles permettant d'étendre le nombre de protocoles gérés tout en se basant sur le protocole dit « TCP ».

  • Passerelle SOAP (grâce à un serveur d'application) : Permet la communication en SOAP avec le broker, donc en principe depuis des environnements autres que Java.
  • Passerelle Mail : Cette passerelle permet d'envoyer et de recevoir des messages JMS en s'appuyant sur du SMTP (Protocole de mail). Pour cela JORAM utilise des queues et topics spécifiques. Cette passerelle est réalisée en Java.
  • Passerelle FTP : JORAM réserve des queues spécifiques pour les canaux FTP. Cette passerelle fonctionne sur le même principe que la passerelle Mail . Elle est destinée à l'échange de messages volumineux. Cette passerelle est réalisée en Java .

Interfaces prises en charge

Selon les classes d'interface :

  • Gestion des messages

JORAM prend en charge le JMS 1.1 et est compatible avec JMS 1.0.2b. JORAM a aussi implémenté une interface JMS 1.1 destinée, au Framework J2ME, la version de l’environnement Java destinée aux mobiles, téléphones et PDAs. JORAM peut donc être mis en œuvre à partir de terminaux mobiles compatibles Java.

JORAM prend aussi en charge JCA 1.5, lui permettant de se connecter aux différents PGI du marché (Open ERP, …) qui le gèrent.

  • Interfaces d’Administration, Monitoring, Configuration

JORAM supporte l’interface d’administration JMX . Il est intégrable et configurable en Java . Il supporte aussi le JAAS pour l’authentification et les habilitations.

Gestion des messages

Outre les fonctionnalités standards, JORAM gère :

  • La notion de hiérarchie des topics : Chaque topic peut être lié à un autre (et un seul) et recevoir tous ses messages. À son tour, le parent topic reçoit tous les messages de ces parents et les envoie à tous ses topics fils. Prenons un exemple : Imaginons trois topics :Manager, Operateurs_France, Operateurs_Espagne. On souhaite que tous les messages envoyés aux topics Opérateurs_* soient aussi envoyés au topic Manager. En plaçant Manager comme topic père aux topic Operateurs_*, tous les consommateurs recevront de façon transparente les messages envoyés aux topics Opérateurs_*. Il n'est pas possible de faire de traitement avec JORAM.
Persistance des messages

La persistance peut être gérée sur le système de fichier, dans une base java embarquée (Derby, voir plus loin pour plus de détail), ou sur une base de données relationnelle externe via JDBC.

Derby est un système de gestion de base de données relationnelle embarquée. « Embarquée » veut simplement dire qu'il n'est pas nécessaire d'avoir un serveur de base de données, au sens d’un processus distinct. La base de données est dans le même processus que l'application. Le support de stockage de la base Derby est le fichier. Derby est une méthode avancée de lecture et d'écriture sur des fichiers.

Nous n’avons pas trouvé, dans les documentations fournies par JORAM, d’information sur les optimisations possibles de la gestion de la persistance.

Répartition de charge et haute disponibilité avec plusieurs sites

Comme on l’a évoqué, JORAM est construit selon une architecture à base d'agent s. Cette architecture est l’objet d'un livre blanc disponible sur le site du produit.

Grâce à son architecture, JORAM assure :

  • La disponibilité : pour rappel, la défaillance d’un serveur n’affecte que les clients JMS connectés à ce serveur. Les autres continuent à fonctionner en accédant à d’autres copies du domaine. La synchronisation des domaines se fait d'une manière transparente, selon un principe maître-esclave.
  • Répartition de charge : les applications clientes sont réparties sur plusieurs serveurs de telle sorte que la charge engendrée par la gestion des domaines soit répartie entre les serveurs. Cette répartition peut soit être réalisée manuellement (configuration et utilisation du « Store and Forward »), soit être confiée à un load-balancer.

    JORAM fournit un squelette de passerelle avec d'autres MOM gérant le JMS 1.1.

    JORAM peut être configuré pour utiliser des connexions SSL / TLS.

    Il gère l'authentification et l'autorisation.

    Des fichiers de configuration au format XML sont utilisés pour définir la configuration de sécurité. Il est possible également de personnaliser la gestion de la sécurité au travers JAAS.

    Mais ces aspects ne sont pas suffisamment documentés.

Administration

JORAM met à disposition une interface graphique d'administration. Elle se base sur l'utilisation de JMX.

Voici quelques captures d'écran de l'interface d'administration.

IA1
IA2

Lors d'une utilisation standard, l'interface d'administration graphique présente quelques problèmes. Si l’on génère beaucoup d'actions, l'application s’affole et devient erratique.

Il nous semble que cette interface devrait être surtout utilisée à des fins de démonstration.

Configuration et déploiement

Après téléchargement, et modulo l'installation d'un runtime Java (JRE), il suffit de quelques déclarations d'environnement pour faire fonctionner la solution.

Une vingtaine d'exemples est fournie. Un système basé sur ANT rend l'utilisation de ces exemples particulièrement simple. On regrette l’absence d’une documentation digne de ce nom concernant le C / C++ et la persistance.

La configuration du MOM se fait à l'aide de fichiers XML. Les balises XML sont assez claires. La définition d'un broker se fait par exemple à l'aide d'une balise « server » contenant la définition de celui-ci ainsi que la définition de services.

 

JORAM fonctionne sur tout système d'exploitation supportant au minimum Java 1.4.

Détail sur le projet

Détail

 

Nous avons testé la version 5.2.1. Des mises à jour sont disponibles environ tous les 3 mois aussi bien pour les versions en cours que pour les versions antérieures.

Il n'y a pas de version commerciale de JORAM, ni de modules distribués sous une autre licence.

Qualité

JORAM utilise ANT pour gérer la construction du projet, le code source est disponible sur un SVN public. JORAM est également disponible dans le référentiel MAVEN Central qui ne contient que les binaires.
Concernant la documentation, un WIKI est hébergé sur la forge d'OW2, mais celui-ci n'est pas très riche, et surtout trop peu actualisé. La dernière mise à jour semble dater du 06/04/2006.

Un guide complet PDF en anglais abordant l'installation, l'utilisation et l'administration de JORAM est disponible sur le site. ÀA cela, s'ajoute un forum sous forme d’une mailing liste, avec accès aux archives. En moyenne, on trouve quelques dizaines de messages par mois.

Un gestionnaire de bug est présent sur la forge OW2, mais ne semble pas être utilisé par le projet, on trouve uniquement 10 anomalies entre 2003 et 2009. Le nombre de contributeurs au projet JORAM est de 24.

Le site officiel de JORAM est http://joram.ow2.org. Il a un page rank Google de 4, ce qui est plutôt faible pour ce genre de sites. Le site est composé d'une centaine de pages tandis que le Wiki comporte une trentaine de pages. Les archives de mails comptent, quant à elle, près 400 pages.

Le site internet de JORAM n'est pas présent sur Google Trend.

Référence

Aucune référence n'est renseignée.