Depuis quelque temps, je vois les trois lettres SOA un peu partout. Sur papier, l’idée est attirante : les fonctions d’entreprise deviennent des services avec des contrats connus, puis les applications les composent au lieu de recopier la même logique.

Le contrat est la pièce centrale. Avec les services Web de l’écosystème actuel, WSDL décrit les opérations, les messages et l’adresse. XML Schema décrit les champs et leurs types. SOAP enveloppe une demande XML qui voyage souvent sur HTTP. Le consommateur peut générer un proxy local, mais l’appel finit toujours par sérialiser des objets, traverser le réseau, être désérialisé puis exécuté ailleurs.

écran de commande
   → proxy .NET → SOAP/XML → HTTP → service Prix
   ← proxy .NET ← SOAP/XML ← HTTP ← résultat ou faute

Une demande simplifiée pourrait ressembler à ceci :

<CalculerPrix>
  <clientId>4182</clientId>
  <article code="VELO-01" quantite="2" />
  <devise>CAD</devise>
</CalculerPrix>

La bonne granularité compte. Appeler ObtenirNom, puis ObtenirAdresse, puis ObtenirRabais transforme un écran en série d’allers-retours. Une opération CalculerPrix qui reçoit tout son contexte métier est plus autonome. À l’autre extrême, un gigantesque service FaireTout recrée l’application monolithique derrière XML. La frontière devrait suivre une capacité et ses données responsables, pas chaque table.

Un appel distant n’est pas une fonction locale avec une flèche plus longue. Il peut réussir sur le serveur et expirer côté client avant que la réponse revienne. Pour une lecture, répéter est souvent acceptable. Pour CréerCommande, je fournis un identifiant de demande stable :

requestId = COMMANDE-2005-000184

Le service garde cet identifiant avec le résultat sous une contrainte unique. Un retry retourne la première commande au lieu d’en créer une deuxième. Les timeouts doivent être finis; attendre sans limite occupe les threads et propage la panne aux cinq applications consommatrices.

Une opération qui touche plusieurs services ne possède pas automatiquement une transaction unique. Réserver l’inventaire réussit, puis facturer échoue. Une transaction distribuée serait parfois possible dans un environnement contrôlé, mais elle garde des ressources et couple fortement les services. Un workflow peut plutôt enregistrer ses étapes et exécuter une compensation : annuler la réservation si la facturation ne peut pas reprendre. « Annuler » doit être une vraie opération métier, pas un DELETE direct dans la base d’un autre service.

Les contrats évoluent. Ajouter un élément facultatif que les anciens consommateurs ignorent peut être compatible. Renommer montant ou changer son sens avant taxes vers après taxes ne l’est pas, même si le XML reste valide. Je versionnerais le schéma, publierais des exemples et garderais l’ancienne opération pendant une période annoncée. Les tests de contrat utilisent les messages réels de chaque consommateur.

Le XML ne sécurise rien tout seul. HTTPS protège le transport entre deux points. Le service doit authentifier l’appelant, autoriser l’opération et valider la taille, les types et les valeurs du message. Une identité technique commune pour dix applications rend l’audit vague; des comptes distincts et des droits par opération montrent qui appelle quoi. Les détails d’une exception interne ne devraient pas revenir dans une faute SOAP lisible par tous.

Avec cinq consommateurs, l’exploitation devient une feature. Je veux un correlationId propagé, le temps de réponse, le taux de fautes, la version de contrat et la profondeur des files si l’échange est asynchrone. Un message durable dans une file convient mieux qu’un appel synchrone pour une action qui peut attendre et doit survivre à une panne; le consommateur doit encore dédupliquer les livraisons.

Pour mon premier service, je choisirais une capacité étroite, dessinerais le message avant le code et testerais quatre cas : timeout après commit, même requestId deux fois, ancien consommateur avec nouveau service et dépendance indisponible. SOA peut rendre les frontières explicites. Les flèches, elles, ne deviennent jamais gratuites.