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 offre des services à l'ensemble des autre 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 ouvre. Par contre il est d'usage d'associer à la SOA des technologies normalisée qui garantissent l'interopérabilité des composants.
Citons par exemple : SOAP, WSDL.

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, elle s'est elle imposée dans les entreprise depuis 2001 ? Tout simplement car elle a reçu le support de tous les acteurs du marché, car elle est basée sur de normes stables, car elle permet 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 ouvre dans tous les systèmes d'informations dans les entreprises ? Le principal problème vient du fait qu'un système d'information d'une entreprise n'est jamais crée « 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 de type « SOA enabler » qui permettra aux entreprises d'intégrer leurs applications sans les réécrire.

Au début 2005, un nouveau "Buzz word" comme disent nos amis anglo-saxons appariait sur la toile, le WEB 2.0. Comme toujours, il semble que l'on ne puisse pas se satisfaire des services offerts par le WEB (Dit 1.0) et donc on invente le WEB 2.0 ! On se demande immédiatement si 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éuni 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, 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 la 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 prévue à 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 mashup 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é au terme de notre voyage dans le monde de l'intégration. Faut-il choisir entre les deux technologies ? Bien sur les deux concepts présentent des similitudes. Architecture basée sur des composants, souplesse, facilité de configuration .. Ou 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, l'assemblage des composants mashup 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 sur, : « Il n'y a pas à choisir, car les deux technologies sont complémentaires »

Olivier PICCIOTTO, Directeur Général de Twinsoft
www.twinsoft.fr