RabbitMQ

Il y a deux ans nous avions parlé de JMS [1], et des principes et enjeux liés aux échanges de messages entre systèmes logiciels. Aujourd’hui je profite d'être sur un sujet très proche de JMS  pour écrire un petit article ce coup ci sur RabbitMQ [2].

Un message Broker

Qu’est ce que RabbitMQ? Il s’agit d’un message broker [4] qui à l'instar de JMS permet la réception et le dispatch de message au sein d’un système d’information.

De façon logique, on va donc retrouver comme dans JMS une logique de files auxquelles les applications vont devoir s’abonner. La différence dans RabbitMQ est que la gestion des messages n’est pas limitée autour de l’utilisation de files ou de topic mais autour de files configurable [5] selon différentes configurations auxquelles vont être associées des clefs de routages permettant la gestion de la diffusion des messages.

La haute disponibilité, les Webservices et JMS dans weblogic

Un article court aujourd'hui pour parler d'architecture JEE et de haute disponibilité dans le cadre JMS.

Nous avons déjà parlé du fonctionnement de JMS mais nous n'avons pas forcement traité la question de la haute disponibilité. Mais qu'est ce que la haute disponibilité?

La haute disponibilité [HD] est la capacité d'un système a fournir un service selon un taux de disponibilité pre-déterminer.

Cela semble un peu de la paraphrase mais cela se traduit par quelles solutions doivent ou peuvent être mises en oeuvre afin de garantir le rendu d'un service par un système?

Pour répondre a cette problématique, il existe une approche simple, la duplication. il suffit de fournir le service de manière répliquée de façon à palier à des éventuelles erreurs et crash.

Dans le cadre des systèmes a base de web-services, souvent la haute disponibilité est couplé a des systèmes de répartition de charge [weblogic-WS-LB]. Le flux http/https est adressé sur un load-balancer qui a pour charge de rediriger ces flux successivement sur les différents serveurs/containeurs d'un cluster construis pour rentre le service attendu.

Robotframework

Nous avons vu dans un article précédent [18] les differents types de tests que l’on pouvait rencontrer dans le cadre du développement de système logiciel. Nous avions alors évoqué l’utilisation qui pouvait être fait de l’outil RobotFramework [1] sans être pour autant rentrer dans le détail de son utilisation.

Dans cet article je vous propose donc de nous y attarder afin de regarder son intérêt, ses cas d’utilisations classiques, son principe de fonctionnement, et ce que l’on peut en faire (et vous verrez on peut en faire beaucoup de choses)

Robot Framework est un orchestrateur de tests automatiques [1]. Son principe de base est assez classique car il comporte, comme beaucoup d’outils de test, de SuiteCases composés de TestCases. La différence majeur se trouve par contre dans une approche orientée données proposant la possibilité de définir des DSL (Domain Specific Language) pouvant être à la fois technique comme fonctionnel (on verra qu’il est préférable justement de séparer ces deux aspects)

JEE : JMS

Nous voici aujourd'hui sur un sujet JEE très classique qu'est JMS.

JMS pour Java Messaging System est un MOM (Message Oriented Middleware), c'est à dire un support intermédiaire (Middleware) pour l'échange de messages entre différents systèmes d'informations et/ou entres différentes couches applicatives. JMS se positionne donc comme solution technique pour des architectures spécifiques telles que celles que nous avons déjà vu dans l'article précédent sur les architectures types [1] en fournissant des solution de couplage faible entre les composants, des échanges de messages asynchrones (positionnable en synchrone mais cela enlève beaucoup d'intérêt a JMS), d'être scalable (c'est à dire qu'on l'on peut facilement ajouter des composants à l'ensemble des composant déjà présent dans le système sans perturbation notable) et sécurisé.

Pour permettre la mise en relation de ces composants de façon homogènes, JMS repose sur différents modes de communications orientées autour des concepts de queue (Queue) ou de sujet (Topic) [10]. Ces deux approches apportent leur propres paradigmes afin de répondre à des besoins soit d'échanges point à point, soit d'échange sous la forme de liste de diffusion.

L'intérêt de JMS est de définir un contexte où l'information est au centre des préoccupations et non les émetteurs ou les receveurs qui n'auront pas à s'acquitter de leur présence ou non sur le réseau et n'auront pas non plus en charge d'acquitter les messages (a moins que cela ne soit prévu via un autre flux).