SOA apporte une réelle souplesse d’architecture et une adaptabilité aux demandes et objectifs de l’entreprise que l’on n’avait pas toujours, notamment dans les environnements d’intégration. Aujourd’hui, on voit fleurir des solutions SOA chez tous les éditeurs ou presque. Mais si l’offre logicielle devient pléthorique, ne croyez pas que tout se résout grâce aux services. Car SOA représente un risque potentiel
sur la conception, le développement, le déploiement, la gestion. C’est un réel défi de gestion et de gestion du changement. Il faut pouvoir définir les services à produire, cartographier ses applications, définir l’écosystème du SOA, définir les processus métiers, mettre en place l’architecture, etc. Passer au SOA nécessite une bonne analyse des besoins et de savoir ce que l’on veut mettre en service. Il faut une démarche progressive de mise en place, permettant de valider la démarche, les choix techniques et les services. Et les problèmes techniques ne manqueront pas. Il faut vérifier la bonne interopérabilité
des services, connaître les standards et les spécifications utilisées, construire un référentiel des services, être le plus indépendant possible. Un outil de gouvernance n’est pas superflu surtout lorsqu’une
SOA utilise des milliers de services. Le choix technologique constitue un défi à part entière. Car chaque éditeur ou presque propose sa vision SOA avec ou non de l’application composite, des différences
dans les standards. Il existe aussi des spécifications très liées à SOA comme l’Open SOA qui doit fournir des spécifications et recommandations pour simplifier et " unifier " SOA. Il faut regarder aussi le travail autour de JCA, SDO ou encore SCA et JBA ! Dans cette seconde partie, nous continuerons à aborder le problème de l’interopérabilité et les clés de sa réussite, nous nous interrogerons sur la sécurité (un point toujours sensible) et pour terminer sur un panorama des outils.