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.

Pourquoi le SOA ?

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 et les métiers

Le SOA est une couche de rencontre et d’échange entre le métier et l’informatique, il met en œuvre 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'approche financière

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.

Quels sont les composants nécessaires ?

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.

Faire du neuf avec du vieux ?

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.

Les standards SOA

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.