A l'occasion de la sortie de Biztalk Server 2006 R2, Microsoft organisera une conférence sur le thème des SOA  (Service Oriented Architecture ou architectures orientées Services en français) le jeudi 25 Octobre 2007 de 9h à 16h, au Pavillon Kléber à Paris.

Le programme de la journée

Les sessions plénières du matin :

- Vision et perspectives des architectures orientées services selon le Gartner.
Massimo Pezzini, analyste et vice-président du Gartner Research, présentera les derniers enjeux et les perspectives d’évolution des architectures orientées services.
- L’approche « Software + Services » Microsoft : une nouvelle manière de concevoir le système d’information.
- Biztalk 2006 R2 pour accélérer la mise en œuvre d’architectures de services.

L'après midi, un ensemble d'ateliers animés par des experts Microsoft :

- RFID, SOA : convergence ?
- SOA et BPM : comment exploiter l’approche service pour la refonte des processus ?
- Comment démarrer sereinement un projet SOA ? Recueil des meilleures pratiques.
- Gouvernance SOA ou simplement gouvernance IT ?

Cette nouvelle version de Biztalk Server 2006 inclut une plate-forme permettant de travailler avec la technologie d'identification d'objets RFID, des supports d'échanges de données informatisés (EDI) et d'autres fonctionnalités dont la liste est consultable ICI.

Pour les non experts en systèmes d'information et pour les nouveaux lecteurs (eh oui, je sais qu'il y en a ;-), je vais tenter d'introduire le plus clairement possible ce concept d'architectures orientées services.
En fait, pour bien comprendre le pourquoi des SOA, il serait nécessaire de parcourir l'histoire de l'informatique d'entreprise depuis les années 1960-70. Ici, je vais me contenter de quelques schémas qui résument assez bien la situation passée / actuelle et celle que les grandes enterprises cherchent à atteindre depuis le début des années 2000.

Actuellement, le système d'informaiton de la quasi-totalité des entreprises peut être vue de la façon suivante :
 

Chaque silo (on parle de silo applicatif dans le jargon des SI) représente un Département de l'entreprise, qui possède des logiciels et applications diverses qui lui sont propres. Cette configuration est liée à la façon dont les entreprises ont construit leurs systèmes d'information tout au long de leur histoire. Auparavant, lorsqu'il s'agissait de gérer son parc logiciel, l'entreprise ne résonnait pas sur elle-même en tant qu'entité unique, sur le tout qu'elle formait, mais seulement à l'échelle d'un Département particulier. Ainsi, lorsque le Marketing avait besoin d'une nouvelle base de données, une nouvelle base était développée et on ne cherchait pas à savoir ce qu'avait déjà en main le voisin des Ressources Humaines. A moyen et long terme, ces pratiques coûtaient bien évidemment très cher à l'entreprise. De plus, les données étaient largement dupliquées, les informations étaient incohérentes et  l'entreprise devenait d'autant plus rigide qu'elle investissait dans ces silos.

On a donc ensuite cherché à faire communiquer les applications des différents silos entre elles. Une grosse barrière technologique se posait alors : par construction, les silos disposaient d'un vaste ensemble de plate-formes (ERP, Applications Web, CRM, Mainframe, SGBD, etc.) conçues par différents éditeurs (Microsoft, IBM, Oracle, etc). Les applications ne savaient bien évidemment pas communiquer entre elles puisque chaque éditeur avait ses propres standards.
Des solutions ad hoc en mode point-à-point (connexion directe entre deux applications) jusqu'aux outils permettant de mettre en oeuvre une approche intégrée (les EAI, Enterprise Application Integration), plusieurs solutions technologiques sont apparues au cours de ces 15 dernières années, afin de tenter de répondre à cette problématique d'échange de données en environnement hétérogène.

A la fin des années 1990, les outils d'EAI constituaient une solution intéressante mais présentaient plusieurs inconvénients des points de vue économique et flexibilité : des coûts de développement et de déploiement élevés, une implantation coûteuse en temps et ressources.

En 2000, Microsoft sort la première version de son serveur de gestion des processus métiers Biztalk Server, une solution du géant qui, au-delà de résoudre les problèmes d'interconnexion applicative, permet de répondre au dynamisme du marché, à ses évolutions constantes et aux nouveaux besoins des utilisateurs.

Pour le SI, le phénomène de globalisation ainsi que l'exigence des consommateurs imposent aujourd'hui une grande agilité (sortie rapide de nouveaux produits, intégration de SI lors d'une fusion / acquisition) et l'intégration des acteurs externes (une communication plus fluide pour livrer plus rapidement, une personnalisation de plus en plus fine des produits). C'est à ce niveau que le concept d'architecture orientée services intervient. Il faut bien avoir à l'esprit que les SOA ne représentent ni une nouvelle technologie ni la marque d'un éditeur. Il s'agit d'une façon d'organiser l'architecture du SI dans l'objectif de répondre à l'ensemble des problématiques évoquées plus haut : redondance des donnés, communication inter-applications, coûts de mise en oeuvre et de maintenance, intégration des acteurs externes, besoin d'agilité, environnement hétérogène.

On a donc bien compris l'objectif des SOA mais il reste encore à expliquer ce que dissimule la notion de Service dans une telle architecture. Bien qu'on puisse l'utiliser dans le cadre de projets extrêmement complexes, le concept est assez simple à comprendre.
Prenons l'exemple d'une application Web de commerce en ligne (Amazon, par exemple) dont le rôle est de gérer la commande d'un internaute. Avant de lancer la commande, l'application doit effectuer de nombreuses tâches : proposer un catalogue de produits, vérifier si les produits commandés sont disponibles et éventuellement retrouver les informations personnelles de l'internaute.
Dans le cadre d'une architecture SOA, on récupère chaque tâche (on parle de fonction métier) pour en faire un composant autonome que l'on nomme Service :

• Le premier service est chargé de récupérer les informations des clients. Ce service ne fait que ça et est capable de fonctionner en totale autonomie.
• De la même façon, le second service se charge d'exposer le catalogue des produits.
• Le troisième service vérifie si les produits sont disponibles en stock.

L'intérêt d'un tel découpage est de pouvoir réutiliser ces services dans différents contextes et de faire de la composition de service. Par exemple, étant donné que les trois services  
précédents s'exécutent systématiquement pour chaque nouvelle commande, nous pouvons créer un quatrième service qui aura la charge de lancer une commande (donc d'appeler les trois services en plus des traitements qui lui seront propres). Ainsi, l'intérêt des services est également de favoriser la ré-utilisation.
Du point de vue technique, cette possibilité de pouvoir créer des composants génériques passe la plupart du temps par l'intermédiaire du langage XML (voir la notion de Service Web). D'autres technologies (cf. Microsoft .NET) permettent également de mener une démarche SOA.

Voilà, il resterait encore une quantité de choses à dire autour des architectures orientées services, à la fois des points de vue technique, métier et managérial. Sachez qu'il existe d'excellentes publications si vous souhaitez approfondir ce thème. Du côté des publications françaises, l'ouvrage SOA, le guide de l'architecte constitue une excellente référence avec des pistes d'élargissement très intéressantes.

Quelques mots-clés supplémentaires relatifs (plus ou moins directement) aux SOA : Enterprise Service Bus (ESB), Business Process Management (BPM), Business Process Execution Language (BPEL), Business Activity Monitoring (BAM) , Message Oriented Middleware (MOM), Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL), Representational State Transfer (REST),  Urbanisation des SI, Gouvernance des SI.