Mashup et SOA, alliés ou ennemis ?
Par Olivier Picciotto, directeur général de Twinsoft

mardi 25 mars 2008

20080325_11 Avec l'augmentation de la complexité des architectures des systèmes d'informations, l'industrie du logiciel pour les entreprises a cherché à codifier, structurer et définir des concepts qui certains se sont appliqués avec succès et d'autres avec moins de réussite.

En théorie, les Architectures orientées services (SOA) sont indépendantes des technologies employées pour la mettre en œuvre. 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 des SOA n'est pas révolutionnaire. En effet, bien avant les 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 les 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 les SOA permet 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'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.

Les mashups d'entreprises apparaissent

Au début 2005, un nouveau concept apparaissait, 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 l'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.

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 éléments stratégiques.

Les mashups sont l'un des concepts du Weh 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.

Mashups et SOA, même combat

A ce niveau, si les API ne sont pas prévues, deux possibilités existent :

- Redévelopper ou racheter de nouvelles applications « mashuppables »;
- Utiliser des outils qui permettent de capitaliser sur les applications existantes pour les rendre intégrables dans les mashups.

D'évidence, la deuxième solution 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 .... Où se trouve donc la différence ? La

différence est que les SOA s'intéressent à 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 »