Web Services Architecture - Services multiples et plusieurs connexions de base de données?

Question

Est-ce que quelqu'un pourrait me diriger vers une bonne documentation ou une rétroaction ici sur ce que sont les meilleures pratiques pour la mise en œuvre de services Web dans une application qui traite de différentes préoccupations? Par exemple, devrais-je créer différents services, un qui gère la sécurité, (AuthService), un qui gère l'entrée de données pour les représentants du service client, (CRUDService), BillingService et ainsi de suite ou devrais-je simplement encapsuler tous ces "services" en un? par exemple ApplicationService? Fondamentalement, je demande si c'est une mauvaise conception pour créer plusieurs services (fichiers) dans une application. Certains d'entre vous peuvent-ils noter vos expériences ou ce que vous avez vécu? En outre, disons que trois des services énumérés ci-dessus se connectent à la même base de données, mais sont en réalité en train de répondre à des préoccupations totalement différentes, par ex. l'un est pour toutes les transactions comme CRUD, et l'autre est à des fins purement de reporting. Dois-je créer deux services ici, l'un CRUDService et l'autre pour ReportingService? Est-il mauvais de créer deux connexions de bases de données différentes via ces 2 services? Ou comment puis-je partager la même connexion de base de données avec différents services?

Answer 1

Je pense que les services accessibles au public ont tendance à simplement tout vider dans un seul service. Ce qui n'est peut-être pas une mauvaise idée pour une API disponible publiquement. Cela facilite les choses pour les développeurs. Cependant, pour tout projet sur lequel je travaille, j'essaie de décomposer les choses en groupes logiques. De cette façon, votre client n'a pas besoin d'hériter des fonctionnalités dont il n'a pas besoin. La mise à jour des services serait également une tâche un peu plus simple car vous n'affectez qu'un certain sous-ensemble de votre infrastructure de services Web et pas tout. Ainsi, si votre contrat de service est interrompu et que vos clients ne le supportent plus, ils peuvent toujours utiliser d'autres parties de votre système, mais pas celle-ci. Où, comme si vous rompez un contrat sur votre service agrégé, tout échoue. Enfin, si vous devez implémenter quelque chose comme un support de basculement, vous avez plus de flexibilité pour choisir quel service requiert plus de nœuds de basculement, ce qui vous permet de mieux gérer l'allocation de vos ressources.

Answer 2

Si vous voulez des bonnes pratiques, jetez un oeil à la SOA Design Pattern Catalog