0
La SOA signifie 'Service Oriented Architecture'. L'idée de base est de considérer qu'un système d'information est composé de différentes briques fonctionnelles qui, chacune, offrent des services à l'ensemble des autres briques. Chaque composant de la SOA gère non seulement les données de son système fonctionnel, mais aussi les règles métiers qui régissent ces données. En théorie, la SOA est indépendante des technologies employées pour la mettre en œuvre. Par contre, il est d'usage d'associer à la SOA des technologies normalisées qui garantissent l'interopérabilité des composants. Citons par exemple SOAP (Simple Object Access Protocol) et WSDL (Web Service Description Language).
Le concept de la SOA n'est pas révolutionnaire. En effet, bien avant la SOA d'autres architectures basées sur des composants fonctionnels ont vu le jour. Citons par exemple CORBA ou COM/DCOM. Pourtant, ces technologies ne se sont pas imposées. Pourquoi la SOA s'est-elle imposée dans les entreprises depuis 2001 ? Tout simplement parce que : elle a reçu le support de tous les acteurs du marché, elle est basée sur des normes stables, elle permet d'assembler des composants fonctionnels qui ont été crées par différents développeurs ou éditeurs de logiciels. S'appuyer sur SOA permet donc aux entreprises de dégager de nombreux avantages : l'architecture de composants permet une meilleure modularité, le système d'information est évolutif (de nouveaux composants peuvent être rajoutés au système pour faire évoluer son fonctionnel).
Avec de tels avantages, pourquoi la SOA n'est-elle pas mise en œuvre dans tous les systèmes d'information des entreprises ? Le principal problème vient du fait qu'un système d'information d'une entreprise n'est jamais créé « ex nihilo », il y a toujours un existant. Et évidemment dans 80% des cas, cet existant n'est pas architecturé en SOA. A ce stade deux solutions sont possibles : la réécriture intégrale (mission impossible) ou l'utilisation de produit type « SOA Enabler » qui permettra aux entreprises d'intégrer leurs applications sans les réécrire.
Les mashups d'entreprises
Au début 2005, un nouveau 'buzz word' comme disent nos amis anglo-saxons est apparu sur la toile, le Web 2.0. Il semble que l'on ne puisse pas se satisfaire des services offerts par le Web (dit 1.0) et donc on invente le 2.0. On se demande immédiatement s'il ne s'agit pas là d'un effet de mode de plus, mais en y regardant de plus près le Web 2.0 réunit bien sous une bannière unique de nouveaux concepts qui, il est vrai, n'existaient pas ou peu dans le Web standard. Voici quelques-uns des concepts les plus souvent associés au Web 2.0 : Ajax, partage, blogs et flux rss. La grande nouveauté vient majoritairement de l'engouement des entreprises pour cette approche guidée par l'ergonomie et la fluidité d'accès à des interfaces utilisateur plus conviviales, ou le partage d'informations, le travail collaboratif et les possibilités de personnalisation se positionnent comme des données stratégiques.
Les mashups sont l'un des concepts du Web 2.0 issu de l'idée de la personnalisation. En effet, quitte à personnaliser son application pourquoi ne pas pousser le concept plus loin en permettant à l'utilisateur de composer lui-même sa propre application à partir des applications qui sont à sa disposition ? C'est bien là l'idée derrière les mashups (littéralement « compilation » en anglais). Un mashup est la combinaison de plusieurs applications Web en une seule en assemblant leurs interfaces utilisateurs et en les liants les unes aux autres. Le premier défi des mashups est d'arriver, à terme, à ce que les utilisateurs avertis puissent eux même composer leurs propres « mashups » sans programmation. Le deuxième défi consiste à intégrer une application dans un mashup même si cette application ne dispose pas d'API (interfaces de programmation) prévues à cet effet.
A ce niveau, si les API ne sont pas prévues, deux possibilités existent : redévelopper ou racheter de nouvelles applications « mashuppables » ou, utiliser des outils qui permettent de capitaliser sur les applications existantes pour les rendre intégrables dans les mashups. D'évidence, la solution n°2 semble plus réaliste et économique. Il est donc fondamental de pouvoir transformer n'importe quelle application Web existante en composant intégrable dans un mashup. On parlera donc alors de mashups d'entreprise ou de « business mashups » en anglais. Une fois que nous avons nos composants, nativement intégrables ou rendus intégrables par un outil approprié, il reste à créer le mashup proprement dit.
Nous voici arrivés au terme de notre voyage dans le monde de l'intégration : faut-il choisir entre les deux technologies ? Bien sûr les deux concepts présentent des similitudes. Architecture basée sur des composants, souplesse, facilité de configuration. Où se trouve donc la différence ? La différence est que la SOA s'intéresse à l'assemblage de composants métiers fonctionnels ne présentant pas d'interface utilisateur et que les mashups eux, s'intéressent à l'assemblage composant métiers fonctionnels qui présentent des interfaces utilisateur. L'assemblage des services en SOA est réalisé par la couche BPM (gestion des processus métiers), l'assemblage des composants mashups est réalisé par l'outil de composition de mashups. On peut donc considérer que les mashups en entreprise sont une extension de la SOA jusqu'au niveau de l'interface utilisateur. Dans ce cas, les deux concepts ne sont pas opposés, mais bien complémentaires, et la réponse à la question posée plus haut est bien sûr : « il n'y a pas à choisir, car les deux technologies sont complémentaires ».
Olivier Picciotto, directeur général, Twinsoft.
