Fédérant plusieurs technologies avancées, l'architecture SOA promet une évolution majeure dans la conception du système d'information de l'entreprise. Depuis longtemps, on pense développements structurés, conception modulaire, intégration de l'existant, mais aussi processus métier, monitoring. Et si SOA conciliait tout cela ?
Description et commentaires.

SOA (Service Oriented Architecture) ou Architecture Orientée Services est une architecture qui rassemble les grandes applications de l'entreprise (dites applications composites) en services interopérables et réutilisables.
Ces applications communiquent :

• grâce au bus applicatif: entre elles et avec le système,
• grâce au bus de services : avec les utilisateurs en leur fournissant des "services". 

Les services ainsi définis sont :

• soit de nouveaux services ou des services entièrement refondus,
• soit des services existants intégrés dans l'architecture à l'aide de connecteurs (contrairement à l'EAI, la connexion s'effectue plutôt à un niveau métier qu'à un niveau application).

Pour que ces services puissent communiquer entre eux, avec le système et avec les utilisateurs, on dispose de bus assurant le transport des informations; Des modules additionnels assurent la supervision technique, la sécurité et l'enchaînement optimal des processus. Mais SOA n'est donc pas seulement une solution technologique mais bien le système d'information de l'entreprise.

Aujourd'hui, la faiblesse des progiciels réside principalement dans la dynamique des entreprises. Si certaines applications restent pérennes, d'autres doivent être rapidement améliorées ou remplacées. Certaines sont stratégiquement en "première ligne" alors que les performances limitées de certaines autres ne constituent pas un frein à la bonne marche de l'ensemble. Il fallait donc imaginer une architecture modulaire qui saurait incorporer l'existant tout en permettant le développement de nouveaux services performants et mutualisables. 

A noter que le SOA ne remet pas forcément en cause l'architecture centralisée de type ERP et ce, pour 2 raisons :

• l'ERP peut devenir un des services ou plusieurs services exposés dans une architecture SOA,
• l'ERP renonce peu à peu à sa tyrannie centralisatrice et adopte lui aussi une organisation interne modulaire et communicante.

Le SOA est une couche de rencontre et d'échange entre le métier et l'informatique, il met en oeuvre une démarche : la stratégie d'entreprise. 

Le passage au SOA comprend 3 chantiers :

• organiser le changement au point de vue métier (quels sont les besoins de services unitaires, décrire le pilotage des process, identifier les étapes).
• recensement par la DSI des services existants mis aux services de la nouvelle application.
• mettre en place l'infrastructure du système d'information capable d'exploiter ce nouveau système (performance , fiabilité, évolution à long terme).

L'évolution vers le SOA ne se traduit pas forcément par l'augmentation du budget grâce à la mutualisation et la réutilisation. Bien sûr, l'encapsulation du premier service, l'installation de l'infrastructure d'échange et de contrôle constituent des surcoûts par comparaison avec le simple ajout d'un module directement connecté au SI. Le retour sur investissement du SOA s'effectue grâce :

• à une mutualisation effective des services (on n'intègre plus 2 fois des services semblables),
• à la facilité apportée lors de la modernisation ou l'ajout de nouveaux services dans le SI

Les composants organiques du SOA sont :

• de quoi présenter et exposer les services en WSDL :
  - soit disponibles dans l'application pour les plus récentes
  - soit générés à la demande (par exemple comment créer un nouvel employé dans le SIRH)
• de quoi faire une plate forme d'intégration des web services :
  - gérer le référentiel de services
  - routage, filtrage
  - monitoring, SLA, contrat de service
  - accès aux données

A noter 2 modules indispensables :

• le registry : référentiel de services
• l'ESB : qui permet l'orchestration des services.

Normalement, un changement d'architecture est un séisme interne. On a peut-être assisté à ce genre d'événement lorsque l'entreprise a basculé sur un ERP. Tout devait disparaître et chaque application était remplacée par un module tout neuf connecté à l'entité suprême. Révolution des technologies, révolution des pratiques, pourvu que les services ne soient pas trop dégradés avant l'embellie promise.
Avec SOA, pas de table rase. Certes, le passage à SOA correspond à une nouvelle génération de technologie, mais elle embarque au passage l'existant. Pour la plupart des experts, le SOA est avant tout une technologie de refonte progressive des systèmes existants.

Puisque le SI doit être constitué de services réutilisables et interopérables, ajoutés ou améliorés au fil du temps, il est préférable que tout cela soit bien standardisé pour permettre l'insertion d'un nouveau service sans problème.
Malheureusement, si les spécifications issues des web services sont maintenant bien connues (SOAP, WSDL...), la couche supérieure qui entraîne tout cela est encore propriétaire.
A noter toutefois l'existence de l'Open SOA qui réunit BEA, IBM, Iona, Oracle, Progress, Red Hat, SAP, Software AG, Sun, Sybase, Tibco, Xcalia, Zend...
L'Open SOA a publié 2 spécifications pour SOA :

• SCA (Service Component Architecture)pour aider à la création et la composition de services ;
• SDO (Service Data Objects), pour l'accès aux données.

 
Merci à Yves Lhérault, directeur technique BEA, pour son aide dans la rédaction de cette fiche.