Appel de services à partir de la couche Orchestrating dans SOA?

Question

Les principes de l'architecture orientée services site indiquent que la composition de service est importante dans SOA. Mais le Service Loose Coupling est également important. Cela signifie-t-il que le "Couche orchestrante" doit être le seul à pouvoir effectuer des appels aux services du système? Comme je comprends la SOA, la «couche d'orchestration» «colle» tous les services en une seule application logicielle. J'ai essayé de décrire cela sur Fig.A et Fig.B. La différence entre les deux est que sur la Fig.A l'application est composée de services et toute la logique est faite dans la "couche d'orchestration" (tous les appels aux services sont effectués à partir de la "couche d'orchestration" uniquement). Sur la Fig.B, l'application est composée de services, mais un service appelle un autre service. Est-ce que l'architecture de la Fig.B viole le principe du "Service Loose Coupling" de SOA? Un service peut-il appeler un autre service dans SOA? Et plus généralement, l'architecture de la figure A peut-elle être considérée comme supérieure à celle de la figure B en termes de couplage, d'abstraction, de réutilisation, d'autonomie, etc. Je suppose que l'architecture A est beaucoup plus universelle, mais elle peut ajouter des transferts de données inutiles entre la "couche d'orchestration" et tous les services appelés.

Answer 1

Si tout les services ci-dessous 1 et 2 sont encapsulées derrière leurs contrats alors ils sont faiblement couplés. Cependant, B ne tire pas parti de la capacité de la couche d'orchestration à libérer Service 1. Il n'y a pas de vrai ou faux de A ou B, mais il y a des compromis. La figure A nécessite un effort de développement supplémentaire car les détails de ce que B renvoie à A doivent être extraits jusqu'à la couche d'orchestration - et s'il existe des listes de données impliquées, B doit autoriser la transmission d'une collection de paramètres en tant que critères. Cela permet cependant à svc 1 de ne rien savoir de svc 2. Donc si les services sont détenus et gérés par deux équipes différentes, alors A va permettre à ces équipes de fonctionner de façon autonome. Par exemple, si svc 1 est un service d'information client (CIS) et svc 2 est un service de paiement, la couche d'orchestration peut assembler les données CIS avec Svc 2 pour renvoyer une liste de noms de clients et leurs données de paiement les plus récentes. Avec la figure A, une jointure en mémoire est utilisée dans la couche d'orchestration pour effectuer l'assemblage. Ensuite, les clients appellent la couche d'orchestration. Avec B, le client peut appeler directement le service 1, mais si vous commencez à autoriser les services à s'appeler les uns les autres, vous pouvez vous retrouver avec un graphe de dépendance désagréable incluant la possibilité d'appels entrants. Si votre équipe est petite et possède les deux svc 1 & 2 alors ils peuvent suivre ces dépendances. Toutefois, lorsque vous avez des équipes différentes, vous pouvez constater que les dépendances ne sont pas facilement connues ou bien gérées dans B.