De l’utilisation abusive de buzzword à leur intérêt voir l’utilisation qui en est faite, il y a en général un fossé indiscutable. Je prendrai pour exemple SOA et MDA.
Il est vrai que MDA est moins connu mais il n’en est pas moins pas utilisé à des fins de markéting sans vrai intérêt derrière. Pour SOA, il est clair que l’on est dans le domaine du concept que tout le monde met à sa sauce…voire même les clients eux-mêmes. SOA veut dire “Service Oriented Architecture”, qui n’est ni plus ni moins un concept pour définir une séparation claire entre implémentation et application. Les mauvaises langues diront que c’est ni plus ni moins que le concept de design pattern : Façade…je dois avouer que je ne leur donne pas tord!
Je parle dans cette article de SOA et MDA car le concept MDA (”Model Driven Architecture”) est en partie en recouvrement avec le SOA car le MDA est basé sur une description claire du modèle des applications afin de pouvoir les porter sur des implémentation différentes.
Revenons au SOA. Comme je l’ai dit, il requière une séparation entre application (objets métiers, workflow, …etc) et l’implémentation, le but étant de pouvoir faire ce comprendre des applications d’architecture différentes et qu’elles puissent interagir. Le fait qu’une application soit exposée en Web Service n’en fait pas de facto une application SOA, mais il est vrai que 90% du chemin a été parcouru car une architecture WebService se repose (dans 99% des cas) sur du SOAP (over HTTP) qui est —lui— un standard…donc le canal de communication est déjà en place et il ne reste plus qu’a exposer des objets qui sont indépendants de l’implémentation. Si par exemple l’application retourne des images dans un format propriétaire…perdu! Ou encore s’il faut faire un appel pour ouvrir une transaction, puis la fermer après l’appel…on est encore trop proche de l’implémentation.
Autre problème souvent sous-estimé: le versioning! Si les objets manipulés, ou les méthodes changes d’une version à une autre, l’interaction avec les autres applications devient un cauchemar alors que SOA intrinsèquement cherche a gommer ces problématiques. Bref n’est pas SOA qui veut, même si tout le monde prétend l’être afin de pouvoir placer ce buzzword dans leur plaquettes.
Le concept MDA est quand a lui moins un buzzword, mais a-t-il sa place dans une plaquette marketing (ce qui est souvent le cas). A mon avis c’est un terme qui ne doit pas sortir d’une R&D car il n’offre que peut d’avantages en tant que Client excepté le fait d’avoir une documentation claire et précise d’une ou plusieurs applications de son système d’information. Le principe est simple: la ou les applications sont défini dans un modèle qui va décrire les objets métiers, les worklows — bref, tout ce qui compose une application — indépendamment de l’implémentation (2 ou 3 tiers, J2EE ou .Net, …etc.). Ce concept est beaucoup plus pragmatique que SOA car il permet entre autre de simplifier les des migrations d’implémentation en assurant minimisant le risque de voir apparaître des bugs. Pour les applications particulièrement sensibles comme les applications financières c’est un atout majeur. Il permet aussi d’assurer des modifications substantielles dans les mêmes conditions. Là ou je trouve qu’il y a de l’abus, c’est que documentations technique exhaustive est tout à fait valable, or je n’ai jamais vu une documentation technique markétée MDA !!