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:
- Implémentez des transactions réelles avec WS-Atomic Transaction ou autre
- 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é?