Recherche rapide | Aide | Plan | Actualités | Navigation principale | Aller au contenu | Pied de page Recherche rapide | Aide | Plan | Actualités | Navigation principale | Aller au contenu | Pied de page 
Les architectures SOA représentent une nouvelle manière de construire un SI. Celles-ci sont structurées autour d’unités élémentaires composables et réutilisables : les services. La composition de ces services permet l’exposition de processus métier transversaux dans de véritables portails de services. Le principe SOA est une solution complète et standardisée d'urbanisme technique.
Cosmosbay~Vectis met en œuvre cette nouvelle génération d’architectures qui, réalisée progressivement, ne déstabilise pas les SI opérationnels.
Le terme SOA est apparu très rapidement après l’émergence des technologies de services Web, au début des années 2000, dans le sillage de la standardisation du langage XML par le W3C. Ce terme désigne des architectures dont la conception repose sur un nouveau modèle (design pattern) qui privilégie l’usage et la réutilisation de services indépendants, interopérables et faiblement couplés. Ce nouveau style s’impose comme une évolution des architectures orientées objets, puis orientées ressources du Web.
L’artefact service constitue l’unité élémentaire de traitement dans une architecture SOA. Les fonctionnalités d’un service, ainsi que les informations échangées durant l’interaction avec le service sont décrites par une interface standardisée (contrat). La nature du traitement exposé par le service est variable : objet (Java, C# …), composant (EJB…), document XML (news, séries de données temporelles…). L’interaction entre un service et ses clients est réalisée via un échange de messages (couplage faible).
La construction d’applications est réalisée par assemblage et réutilisation de composants unitaires (services) en composants de plus forte valeur ajoutée (processus). Les processus résultent de la combinaison de l’algorithmique de leurs activités (orchestration) et de la dynamique des échanges de messages entre les services participant au processus (chorégraphie). L’exécution de ces applications composées est prise en charge par de nouvelles solutions BPM (Business Process Management) standardisées.
La mise en œuvre d’une architecture SOA suppose une évolution de l’infrastructure de support. Celle-ci doit être en mesure de gérer la médiation entre les différentes pièces de l’architecture : échanges de messages fiables et sécurisés, éventuellement transactionnés, via différents protocoles de transport. Cette capacité de médiation repose sur la mise en œuvre des dernières générations de solutions EAI ou de nouveaux produits ESB (Enterprise Services Bus).
Les modèles de programmation des grands frameworks d’exécution et de développement d’applications (notamment J2EE et .NET) sont en cours d’adaptation afin d’unifier la programmation fonctionnelle des applications, quels que soient les artefacts utilisés : objets, ressources ou services. Cette transformation se traduit par l’apparition de l’architecture SCA (Service Component Architecture) dans le monde Java ou du composant WCF (Windows Communication Foundation) de l’API WinFX chez Microsoft.
Les architectures SOA autorisent un pilotage fin des services en exécution par la mise en œuvre de stratégies prédéfinies. Ces stratégies (policies) sont définies à l’aide d’assertions relatives à différents aspects des contrats des services utilisés : sécurité, qualité de service… De nouveaux produits de gestion de la sécurité et des infrastructures de services sont capables de gérer ces métadonnées et de permettre ainsi une véritable gouvernance des architectures SOA.
Toutes les composantes d’une architecture technique sont concernées par l’adoption d’une architecture cible SOA.
Nous vous conseillons pour construire progressivement votre architecture SOA via la mise à niveau des pièces architecturales existantes d’une part (EAI, ERP, serveurs d’applications, sécurité…) et l’adjonction de nouveaux éléments techniques (annuaires de services, serveurs BPM, bus de services ESB, solutions SaaS – Software-as-a-Service…) d’autre part.
Le pragmatisme guide notre démarche pour l’adoption d’une cible architecturale SOA.
