J2EE et les Enterprise Java Beans (EJB)
1
7.8/10
J2EE : les Enterprise Java Beans (EJB)
ARCHITECTURE LOGICIELLE / 22 août 2017

Les Enterprise java Beans (EJB) ont émergé en 1998 afin de proposer aux programmeurs un outil qui leur simplifie la conception et le déploiement d’une couche métier. Avec leur version 2.0, les EJB ont introduit a possibilité de travailler directement sur les données stockées dans une base de données relationnelle. Mais cette évolution et d’autres avec elle, s’est faite au prix d’une certaine lourdeur de mise en œuvre. En effet, les composants 2.0 doivent implémenter de nombreuses interfaces. En conséquence, leur déploiement nécessite d’envoyer au serveur d’applications des fichiers de description relativement lourds rédigés en langage XML. Les 4 grands principes de base Voila pourquoi la version 3.0 publiée en 2006 a tenté de simplifier l’utilisation et le déploiement des Enterprise Java Beans en définissant une approche basée sur quatre principes : Les fichiers XML servant au déploiement ont été remplacés par des annotations placées directement dans le code des EJB. Ce principe s’inspire directement des apports apparus dans la version 1.5 de Java SE. Et plus précisément de la définition et de l’exploitation des annotations ; Afin d’assurer les interactions entre les EJB et le serveur d’applications, il n’est plus nécessaire d’implémenter de nombreuses interfaces (au sens java). Dans…

Middlewares on messages
1
6.4/10
Middlewares On Messages (MOM)
ARCHITECTURE LOGICIELLE / 2 juin 2017

Le terme « middlewares on messages » (MOM) désigne une architecture logicielle basée sur des composants (les middlewares). Ces middlewares permettent l’échange de messages entre applications réparties sur un réseau. Globalement, un middleware n’est autre qu’une couche informatique intermédiaire au sein d’un système client serveur multi-tiers. Le middleware assure donc la standardisation des échanges de services entre les fournisseurs et les consommateurs. Ainsi, d’un point de vue purement théorique, il est possible de représenter la couche middleware comme un bus d’échanges inter-applications. Plus précisément, il existe deux principes de fonctionnement : le middleware objet et le middleware à messages. Et concrètement pour les “middlewares on messages” ? Avec les « middlewares on messages » (MOM), la relation est asynchrone et organisée autour de 2 types de composants : Le « provider » ou « broker » : il s’agit du composant central du middleware, dont le rôle est de router les messages entre les applications. Les clients : les applications qui échangent les messages (une application cliente peut jouer successivement le rôle d’émetteur et celui de récepteur des messages). Le client envoie un message pour solliciter un service. Ensuite, un service de messagerie achemine ce message vers le serveur. Une fois la requête demandée exécutée, le serveur poste…

Unified Modeling Language (UML) et design patterns
1
7.6/10
UML & Design patterns
ARCHITECTURE LOGICIELLE / 26 mai 2017

UML pour Unified Modeling Language, est né en octobre 1994 au sein de la société Rational Software Corporation sur une idée de Grady Booch et de James Rumbaugh. La version 1.1 d’UML a été standardisée par l’OMG (Object Management Group) le 17 novembre 1997 suite à une demande de collaboration de plusieurs grande entreprises américaines. Parmi celles-ci, nous pouvons notamment citer Hewlett-Packard, IBM,vMicrosoft et Oracle. L’ Unified Modeling Language a été conçu pour modéliser différents types de systèmes, de taille quelconque et ceci pour tous les domaines d’application (gestion, science, temps réel, système embarqué). Ainsi, UML permet de diviser le système d’information (d’une organisation) entre un système métier et le système informatique. Le système métier doit modéliser les aspects statiques et dynamiques de l’activité selon une vision externe et une vision interne. De cette manière, le système métier ignore l’implémentation technique. De son côté, le système informatique recouvre la partie automatisée du système métier concrétisant les choix effectués parmi les différentes technologies disponibles. Les concepts manipulés sont les mêmes, pour chacun de ces deux niveaux d’abstraction. UML est fortement inspiré de l’approche 4+1 vues indépendantes (logique, composants, processus, déploiement et cas d’utilisation) définie par P. Kruchten. Il s’agissait alors d’exprimer les…

Architectures n-tiers
1
7.7/10
Architectures N-tiers
ARCHITECTURE LOGICIELLE / 25 mai 2017

Les architectures n-tiers doivent permettre de pallier les limites des architectures trois tiers et de concevoir des applications puissantes et simples à maintenir. Ce type d’architecture permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge entre tous les niveaux. Cette évolution des architectures trois tiers met en œuvre une approche objet pour offrir une plus grande souplesse d’implémentation et faciliter la réutilisation des développements. Théoriquement, ce type d’architecture supprime tous les inconvénients des architectures précédentes. Elle permet l’utilisation d’interfaces utilisateurs riches et sépare nettement tous les niveaux de l’application. Elle offre de grandes capacités d’extension et facilite la gestion des sessions. L’appellation “n-tiers” peut laisser penser que cette architecture met en œuvre un nombre indéterminé de niveaux de services. Mais ces niveaux restent à un nombre maximum de trois (les trois niveaux d’une application informatique). En fait, l’architecture n-tiers qualifie la distribution d’applications entre de multiples services et non la multiplication des niveaux de service. Ainsi, l’architecture prend toujours en compte les trois niveaux d’abstraction d’une application. Rôle de la POO dans les architectures n-tiers Cette distribution est facilitée par l’utilisation de composants métier, spécialisés et indépendants, introduits par les concepts orientés objets…

Méthode MVC
1
9.9/10
La méthode Modèle – Vue – Contrôleur 

La recherche en interactions homme-machine a permis le développement de modèles génériques et abstraits de systèmes interactifs. Ces recherches ont pour objectifs de mieux comprendre les systèmes interactifs existants, et à mettre en place une base commune de communication. Elles guident également vers des choix d’architecture logicielle lors du développement de nouveaux systèmes interactifs. L’architecture Modèle – Vue – Contrôleur également nommée méthode MVC s’inscrit dans la lignée de ces recherches. Lors de sa conception, le modèle MVC devait servir de solution générale permettant aux utilisateurs de manipuler des données volumineuses et complexes. A l’origine, ce sont les applications logicielles qui devaient faire usage de l’architecture MVC. Pourtant, aujourd’hui, ce se ont principalement les applications Web qui en font usage. Dans ce contexte, il est étonnant de constater que le modèle MVC fût conceptualisé quelques années avant l’utilisation du terme « Internet » en 1982. Et force est de constater qu’après 40 ans, la mécanique MVC reste toujours autant d’actualité. Mais le traitement de ce sujet n’en reste pas moins difficile malgré une base théorique de l’époque relativement condensée. L’évolution du concept au fil des années, ses différentes versions, ses nombreux domaines d’application, l’usage diversifié qu’en font les développeurs rendent…