La composition des services SOA fonctionne-t-elle réellement dans la pratique?

L'un des principaux principes de conception des services SOA est le principe de composabilité des services ( https://en.wikipedia.org/wiki/Service_composability_principle ).

L'idée est qu'en composant de nouveaux services en utilisant ceux existants comme blocs de construction, on peut rapidement développer de nouveaux services. De façon analogue à la façon dont vous appelez les méthodes existantes des objets lorsque vous implémentez de nouvelles méthodes. C'est de là que devrait provenir une grande partie de la productivité de SOA.

Quelqu'un fait-il vraiment cela dans la pratique? J'ai vu cela se répéter à l'infini dans un texte écrit, mais je n'ai pas moi-même expérimenté des implémentations réelles. La plupart du texte omet également toute mention de la gestion des transactions , ce qui me semble être le plus grand obstacle à la réalisation de services composables.

Tout d'abord, vous devez vraiment résoudre le problème des transactions avant de pouvoir composer des services non triviaux. Bien sûr, si l'exemple a les services "findCurrentTime ()" et "writeLogMessage ()", il est facile de ne pas s'inquiéter des transactions, mais pas lorsque vous avez des exemples du monde réel tels que "depositMoney ()" et "removeMoney ()".

Je connais deux options:

1. Implémentez des transactions réelles avec WS-Atomic Transaction ou autre
2. Mettre en œuvre une solution basée sur la compensation qui compense l'appel à A avec "cancelA ()" ou quelque chose comme si l'appel à B échoue

Ces deux éléments me semblent très problématiques / presque inutilisables:

• Transaction WS-Atomic
  • un grand nombre de complexité, la plupart des conseils que je trouve juste met en garde contre « la douleur dans le cul, ne le faites pas »
  • le support est limité, par exemple si vous prenez des ESB open source, les principales alternatives ServiceMix, Mule ou WSO2 ne le prennent pas en charge
• compensations
  • la mise en œuvre du traitement des compensations me semble très complexe. Que faisons-nous si le service A réussit et que nous n'obtenons jamais de réponse du service B et que nous ne savons pas s'il a échoué ou réussi? Manipuler une telle logique manuellement (en tant qu'implémentateur de services de compositing) me donne envie de me couper les poignets - c'est le genre de travail qu'un outil devrait faire pour moi!.
  • Je ne vois pas non plus comment vous pouvez avoir des méthodes de compensation dans des services non triviaux. Supposons que votre service A soit "depositMoney ()" et que cela réussisse, une autre action transfère rapidement l'argent ailleurs, puis nous recevons "compensateDepositMoney ()", que faisons-nous maintenant? On dirait une grosse boîte de vers.

Il me semble que la composition des services est un principe SOA si fondamental que vous n'obtenez vraiment pas les avantages de la SOA si vous ne pouvez pas (commodément) composer des services . Quelle est la réalité? 90% des utilisateurs SOA utilisent "SOA paralysé" sans véritable compression de service? Ou la plupart des utilisateurs utilisent en fait la composition des services et j'exagère la difficulté?

La reponse courte est oui!

J'ai vu cela dans plusieurs grandes organisations financières et cela a bien fonctionné.

Les problèmes de transaction sont complexes mais sont généralement traités par des middleware (coûteux) tels que Oracles WebLogic EAI ou IBMs Websphere ESB.

Oui, il peut fonctionner en pratique. Cependant, ce n'est peut-être pas la meilleure approche et est peut-être utilisée comme option par défaut plus qu'elle ne devrait. À mon avis, la SOA est devenue un moyen populaire d'intégrer des systèmes hérités au fur et à mesure que les organisations faisaient évoluer leur informatique pour automatiser des tâches de plus en plus importantes. Cela peut être très compliqué, mais cela en vaut la peine si les anciens systèmes peuvent être réutilisés. Si vous avez la chance de démarrer un projet de champ vert, d'autres approches doivent être envisagées avant de supposer que c'est la meilleure façon de procéder.

Pour répondre à certaines de vos préoccupations plus spécifiques ...

Vous pouvez utiliser des transactions:

1. WS-TX est un PITA et je l'éviterais.
2. Tous vos services peuvent s'exécuter sur un seul serveur d'applications, auquel cas vous pouvez tous les étendre avec une transaction XA. C'est pourquoi des choses telles que les serveurs d'applications ont été inventées.

Considérant l'approche basée sur la rémunération:

Les actions compensatoires ne doivent être envisagées qu'en cas de défaillance. L'outil de composition de service a-t-il un indicateur qu'il peut contrôler qui est effacé lors de la première exécution d'une étape de workflow, mais défini lors d'appels ultérieurs? Comme le drapeau de renvoi possible dans JMS. Ensuite, vous pouvez utiliser ce que l'on appelle un commit de 1,5 phase, ce qui signifie essentiellement aller de l'avant si l'indicateur est clair, mais si l'indicateur est défini, faites d'abord un appel pour vérifier si l'état est déjà mis à jour et doit être effectué une deuxième fois . Cela nécessite toujours une gestion manuelle des erreurs et peut être complexe, voire impossible, comme vous le faites remarquer.

Dans certaines situations, peu importe:

C'est l'approche finalement cohérente. Supposons qu'un service envoie un e-mail. Si la composition du service échoue et est redémarrée, l'e-mail est envoyé à nouveau. C'est légèrement ennuyeux pour le destinataire, mais ils réalisent probablement que c'est un doublon et que tout peut continuer sans trop de problème.

Vous pouvez également conserver un journal des e-mails envoyés, et l'utiliser pour déduper lorsque l'indicateur est défini, et de cette façon envoyer uniquement l'e-mail une fois.

Vous pouvez utiliser la messagerie asynchrone pour diviser les transactions en plusieurs parties:

Considérez une file d'attente JMS qui est transactionnelle. Votre coordinateur de service peut mettre à jour son état et publier un message dans la file d'attente en un seul Tx. Les services en aval peuvent retirer des messages et mettre à jour leur état en un seul Tx. Vous coordonnez maintenant les services dans plusieurs unités de travail, mais chacune est atomique. Si quelque chose échoue et doit être redémarré, aucun problème.

Cela signifie toujours que vous effectuez des transactions XA sur la base de données et une file d'attente JMS, mais cela peut toujours être efficace en utilisant le dernier gambit de ressource pour éviter la surcharge totale de XA.

Vous pouvez également utiliser ce modèle, mais avec une validation de phase 1,5 dans la base de données et JMS. OU vous pouvez exécuter JMS sans transactions mais le rendre plus fiable en cluster.

La messagerie asynchrone peut également aider à découpler les systèmes, car les producteurs et les consommateurs peuvent devenir plus indépendants l'un de l'autre, réduisant la quantité de couplage dans le système global et le rendant plus flexible. Ce type de découplage est à peu près essentiel quand il s'agit de grandes organisations avec beaucoup de services divers.

Non, c'est un mythe. C'est une mauvaise intention d'avoir lors de la conception d'une architecture de service. Il y a tout un tas de problèmes:

1. Accouplement très serré. Si un service a été modifié, vous devez tester l'ensemble du système.
2. Ces services sont très fins donc il y a beaucoup de communication interne.
3. En raison de sa granularité, il existe de nombreux services. Le système devient difficile à comprendre, les requêtes deviennent plus difficiles à suivre.
4. Les services d'entité sont mal encapsulés: aucune des règles métier n'y est vérifiée, cette logique est dans les services d'exploitation. Ainsi, n'importe quel service peut appeler n'importe quel service d'entité et mettre à jour ses données avec une requête de mise à jour commune présente dans son interface. Ce type de services d'entité est souvent appelé services centrés sur les données - par opposition aux services centrés sur les processus et les comportements.
5. La nature innée de la communication entre ces services est synchrone. Les chances sont donc que le transport choisi soit http. D'où tous ses inconvénients dont je parlerai un peu plus tard.

Il existe encore plus de fausses façons d'aborder l'architecture des services . Soyez donc prudent.