Le couplage faible est un principe de conception bien connu de la programmation orientée objets. Réduire les dépendances entre les composants d’une application (objets, classes, paquetages) permet de faire évoluer le code plus facilement, encourage la réutilisation et facilite la maintenance.
Plus le couplage entre deux composants est fort, plus les modifications sur l’un ont un impact sur l’autre.
La réduction du couplage est également important à une autre échelle: celle du système informatique de l’entreprise. Dans ce cas, ce sont les dépendances entre les applications que l’on cherche à réduire. Il s’agit d’une problématique d’intégration plus que de développement, même si la frontière entre ces deux disciplines est floue.
C’est un aspect important de la notion d’architecture orientée services (SOA). Face à un ensemble de systèmes hétérogènes, on veut éviter de réaliser une multitude d’intégrations point à point (qui augmentent le couplage). Pour cela, on expose la logique métier des systèmes sous la forme de services. Chaque service remplit une fonction, chaque service peut être invoqué à distance, grâce à une infrastructure d’échange de messages.
Différents services peuvent ensuite être combinés et de coordonnés, ce qui permet d’implémenter de la logique applicative à un niveau supérieur, de manière transversales aux applications. Par exemple, un processus de “traitement d’une commande client” est implémenté en orchestrant un service de “gestion des clients”, un service de “gestion du stock”, un service de “calculation de rabais” et un service de “facturation”.
Un point important à relever, c’est que les principes d’une architecture orientée services sont génériques, et donc indépendants d’une technologie particulière. Beaucoup d’éditeurs logiciels insistent sur l’utilisation de standards “web services”, mais il existe des alternatives.
On peut par exemple penser à Jini, une technologie particulièrement élégante qui fournit des mécanismes pour publier, découvrir et invoquer des services au sein d’une infrastructure distribuée. On peut également penser aux middlewares orientés messages (MOM), qui fournissent une infrastructure de communication inter-applicative fiable et performante. Les MOMs sont utilisés depuis de nombreuses années dans des environnements critiques (notamment dans les applications financières) et ont démontré leur valeur. Beaucoup de MOMs implémentent l’API standardisée Java Message Service (JMS).
Il existe pourtant beaucoup d’organisations qui n’utilisent pas de MOM, souvent parce que l’intégration a été faite de manière ad-hoc (connections point à point). Conscientes du besoin d’urbaniser leur système informatique, elles considèrent les solutions logicielles estampillées “SOA” comme la solution à leurs besoins. L’introduction d’un MOM est une alternative qu’elles devraient considérer, car elle présente plusieurs avantages: elle est éprouvée, “légère”, simple à appréhender par les développeurs, introduit peu de complexité dans l’infrastructure, etc.
Convaincus des avantages des MOMs, nous pensons qu’il existe un besoin pour des outils de conception, de développement et de gestion spécialement conçus à leur effet. C’est une thématique que nous nous proposons d’investiguer dans le projet MURMURES à l’IICT.
Si vous êtes intéressés par cette problématique - parce que vous utilisez déjà un MOM ou parce que vous envisagez d’en utiliser à l’avenir, n’hésitez pas à nous contacter. Nous sommes intéressés par différentes formes de collaboration.
Pour les étudiants, un travail de diplôme est proposé dans le cadre du projet MURMURES. N’hésitez pas à nous contacter pour en discuter. Plus d’informations sont disponibles sur le site b2s.
