Je prends un projet pour remplacer un ancien système hérité de la terre. Avant de venir, la société a embauché un consultant qui a rassemblé un croquis de base du système et poussé SOA fortement. Cela a abouti à une longue liste de «services d'entité», l'intention d'entre eux étant composée de combinaisons de services plus complexes. Par exemple, une information du comité souhaité par l'utilisateur frapperait le service "Comité", qui appelle ensuite le service "Personne" pour obtenir ses membres et le service "Réunion" pour obtenir ses réunions, etc.
Je comprends les gains de flexibilité dans cela, mais mes préoccupations concernent la performance. Il me semble qu'un système construit avec un niveau de granularité aussi fine à ses services dépense trop de ressources sur la traduction de messages de service, et la performance sera inacceptable. Il me semble également que les gains de flexibilité peuvent toujours être fabriqués à l'aide d'objets de base réutilisables, bien que dans ce cas, l'avantage d'une interface technologique-agnostique soit perdue pour obtenir des performances.
Pour plus d'arrière-plan: l'organisation demandant ce logiciel ne dispose pas d'une stable de suites de logiciels tiers qui doivent être intégrant. Ce logiciel remplacera toutes les suites. Il n'existe également actuellement aucun consommateur externe qui doit accéder aux données en dehors de l'interface de site Web fournie - tous les appels de service provenant d'autres pièces à l'intérieur de notre système. Le choix de la SOA dans ce cas semble entièrement basé sur le concept de "préparation".
Donc, ma question - quel niveau de granularité est acceptable dans une écurie de services sans sacrifier la performance? Suis-je trop sceptique des hits de performance que nous allons mettre en œuvre toutes nos entités en tant que services? Si la fonctionnalité doit être disponible en tant que services Web uniquement lorsqu'ils sont nécessaires, avec la mise au point "Préparation", en concevant la couche d'entreprise pour la probabilité de services en cours de chute ultérieure?
3 Réponses :
Quand je dis "service", je veux dire le composant vertical complet pouvant effectuer une opération totale indépendante. Et je ne préfère pas y aller plus de granularité à moins d'exiger une exigence exceptionnelle. À mon avis de SOA, un service devrait effectuer la fonction d'entreprise significative pouvant être effectuée de manière indépendante. Un service ne doit pas nécessiter un autre service pour compléter sa fonction.
Qu'en est-il de l'exemple ci-dessus, où "personne" est un service théorique? Il effectue une fonction d'entreprise indépendante du renvoi de toutes les données relatives à une personne (nom, dob, adresses, etc.), mais elle fait également partie d'autres fonctions commerciales (informations du comité de retour, de retour des informations de donateur / don, de retournement des candidats à la révision, etc. )
@Tayyab - je suis en désaccord. Si vous concevez votre système de cette façon, vous vous retrouverez avec beaucoup de code dupliqué ou une application étroitement couplée. Bien que cela fonctionne certainement, c'est plus que SOA. Dans une SOA, les consommateurs d'un service ne connaissent que le contrat du service, et non la mise en œuvre sous-jacente. Par exemple, si un service doit instancier une classe d'une DLL afin de réaliser son travail, il a une connaissance explicite de la mise en œuvre et non seulement du contrat, et que vous êtes bloqué sur la DLL à chaque service qui en a besoin chaque fois que Ses changements de mise en œuvre (couplage).
En mon point de vous avez des entités d'affaires (personne, réunions, etc.) et obtenir la liste des personnes ne devraient pas être un service. Vous appelez cela un service lorsqu'il effectue un processus commercial indépendant complet. Vous pouvez avoir des entités réutilisables telles que (personne, réunions, etc.) et vous pouvez utiliser ces entités dans plusieurs services, mais l'interdépendance entre les services n'a aucun sens. Lorsque vous pensez que des services ne pensent pas du point de vue du développeur. Essayez de penser du point de vue de l'analyste des affaires lorsque vous identifiez «ce qui devrait être un service».
@Brandonzeider: C'est une discussion distincte concernant la mise en œuvre interne du service. Et aussi, il est parfois juste d'avoir une connaissance explicite de certaines DLL pour le développeur qui codant le service. Le contrat de service est destiné au "consommateur" du service et le consommateur devrait pouvoir appeler un seul service pour une tâche ou un processus. Si le consommateur doit appeler plusieurs services pour compléter une tâche indépendante unique, vous demandez à un "consommateur" d'avoir une connaissance explicite de votre solution.
@Tayyab - N'oubliez pas que les services peuvent également être des consommateurs ou des clients d'autres services, et il est très courant d'avoir un service de haut niveau qui doit appeler plusieurs services afin d'accomplir sa tâche. Un exemple serait un service d'enregistrement. La méthode Register () peut appeler userservice.save (utilisateur utilisateur), e-mailservice.sendNewusernotification (utilisateur utilisateur), etc. Le userservice peut alors appeler encore plus de services pour enregistrer l'enregistrement d'utilisateur (utilisateur.Address, utilisateur.contact, etc.). Ainsi, alors que le consommateur initial pourrait appeler 1 service, ce service peut être un consommateur de nombreux services pour accomplir sa tâche.
@BrandonZeider: C'est tout sur la façon dont vous percevez SOA. Différentes communautés ont une perception différente de la SOA. Le concept dont vous parlez est appelé SOA par certains personnes Microsoft, mais je suis personnellement en désaccord avec cela. Je pense que c'est plus d'une architecture orientée de composants, pas une architecture orientée du service. Je suis d'accord davantage avec la perception de la SOA de la communauté open source où un service est un processus qui automatise des flux d'affaires. Donc, de votre exemple, je considérerais "Emailervice.SendNewusernotification (utilisateur utilisateur)" dans le cadre du "service de notification" mais "utilisateur" n'est qu'une entité commerciale.
@BrandonZeider: Il n'y a pas non plus de couplage lâche dans votre exemple. Il existe une communication synchrone entre «Enregistrer le service» et «Service utilisateur». Et aussi, le service de registre ne peut pas fonctionner sans dépendance forte sur «Service utilisateur», donc ce n'est pas indépendant.
@Tayyab: Je ne sais pas pourquoi nous parlons encore de cela ... mais ... nous pouvons être en désaccord sur la définition de SOA, c'est une chose assez commune à être en désaccord, mais mon exemple est couplé de manière lâche. Les différents services ne connaissent que le contrat de service et non la mise en œuvre du service. Sync / Async n'a rien à voir avec le couplage, c'est juste un détail d'invocation du consommateur. Je pense que vous êtes un peu confus. Même histoire avec une dépendance. La dépendance n'implique pas un couplage égal. Peu importe la manière dont vous la mettez en train de le mettre en œuvre (Objets VS Services), vous dépendez de quelque chose, mais cela ne signifie pas nécessairement que CoupliHng serré.
@BrandonZeider: C'est toujours bon à avoir une discussion. Je vous recommanderais que vous devriez avoir un coup d'œil en dehors de la boîte Microsoft. Permettez-moi de partager quelques liens, même si vous ne voulez pas lire tout, jetez un coup d'œil .... " blogs.sun.com/crupi/ientry/soa_service_granularité "
@BrandonZeider: Et je ne veux pas dire qu'un service ne peut pas appeler un autre service. Il peut y avoir des services composés qui appellent d'autres services. Mais nous ne devrions pas faire tout un service. Je dis simplement que "le processus d'inscription est un service" mais "un utilisateur est une entité, pas un service". Quoi qu'il en soit, je ne voulais pas imposer mes concepts sur vous ou quiconque ... c'est juste que nous sommes d'accord ou non que la discussion est toujours bonne.
@Tayyab: Merci pour le lien, mais cela donne un 404. J'en ai eu plusieurs regards en dehors de la boîte Microsoft. Microsoft a juste la main gagnante en ce moment avec .NET (taux d'adoption dans ma région, facilité d'utilisation, caractéristiques, etc.). Et vous avez raison, nous ne sommes pas d'accord sur ce qui devrait être des services, car utiliser WCF comme pile de mise en œuvre, je vous abonnez à la philosophie "Chaque classe en tant que service" pionnière de Juval Lowy. Je mettais toutes les fonctionnalités de la fonctionnalité / la récupération de données des points de récupération des données dans des services, ce qui mène à certaines personnes. ;) Oh, et l'utilisateur a toujours été une entité, ou un Datacontract, comme il s'appelle dans WCF.
Désolé, une citation a été ajoutée au lien, veuillez vérifier à nouveau blogs.sun.com/crupi/ientry / SOA_SERVICE_GRANULARITY
@Brandnzeider: Oui, vous avez raison, mais je suis fortement en désaccord avec Microsoft en ce qui concerne les solutions d'entreprise ... :) Et bien sûr, ils ont le meilleur ide et des composants faciles à utiliser, mais cela ne leur fait pas d'experts en architecture ... je ont lu Juval Lowy et il est aussi Microsoft Guy ... En ce qui concerne l'entreprise, je vais avec Sun / Oracle, SAP et IBM .. Ils proviennent ... peut-être que c'est juste ma haine pour Microsoft;) Mais je suis désespéré à Voir OpenSSource Kicking Microsoft hors de l'entreprise d'entreprise :)
Quel niveau de granularité est acceptable dans une écurie de services sans sacrifier la performance?
entités individuelles. Comme décrit par le consultant.
Suis-je trop sceptique des hits de performance Nous allons mettre en œuvre toutes nos entités en tant que services?
oui. Beaucoup trop sceptique.
Un cadre décent peut optimiser certaines de ces demandes afin qu'elles n'impliquent pas beaucoup de frais généraux de réseau.
Comme avec les bases de données SQL, les problèmes sont largement résolus. Vous constaterez que les applications sous-jacentes que vous présentez à mesure que les services sont les goulots d'étranglement. La couche SOA est en grande partie de la plomberie. Les bits doivent encore se déplacer dans les tuyaux, la couche SOA les organise simplement plus intelligemment que la plupart des alternatives.
Si les services ne doivent être mis en œuvre que lorsqu'ils sont nécessaires, avec la «préparation» se concentrant dans la conception de la couche d'entreprise pour la probabilité de services en cours de chute ultérieure?
oui.
C'est ce que "agile" signifie.
Trouver une histoire d'utilisateur. Construire uniquement les services (et entités) de cette histoire.
Vous aurez des frais généraux importants pour les premières histoires pour obtenir votre framework SOA tous carré et déployable comme une étape simple et répétable.
Ne jamais faire une "préparation" étendue pour des choses que vous avez «peut» besoin d'un avenir improbable. Lisez sur Agile et comment hiérarchiser un arriéré.
Je pense que je me trompais dans mes "services si les services ne seraient mis en œuvre que lorsqu'ils sont nécessaires" question. La question que je voulais demander était. Est-il prudent de ne mettre en œuvre que des objets / entités de service Web non-Web pour une solution, jusqu'à ce que le fait soit un besoin explicite pour un service Web pour cette fonctionnalité?
IMO Cela dépend de la baisse que vous voulez expédier ... Il y a une bonne façon de faire des choses (que vous pouvez éventuellement travailler vers) et une manière qui rend tout le monde heureux rapidement sans le travail supplémentaire.
Pourriez-vous s'il vous plaît répondre à Stackoverflow.com/Questtions/9538710/... ?
Tout d'abord, trouver le "Sweet Spot" dans le nombre de services est difficile à coup sûr. Trop de services et vos coûts d'intégration souffrent, trop peu, et vos coûts de mise en œuvre souffrent. Vous devez trouver un bon équilibre.
Mon conseil est de suivre Méthodologie de Juval Lowy en ce que vous devriez casser vos services par des domaines de la volatilité ou des zones de changement. Cela vous donnera votre niveau de granularité. Vous devriez aussi Lire son livre WCF si vous le pouvez .
Tant que la performance, WCF prend en charge de nombreux milliers d'appels par seconde en fonction de vos cas d'utilisation et de votre matériel. Services Les services d'appel ne sont pas un problème. La plate-forme la soutiendra si vous faites votre part. Par exemple, utilisez la reliure droite pour le scénario de droite (tuyaux nommés pour appeler des services sur la même machine et TCP pour appeler des services à travers la machine dans la mesure du possible). Vous devez également mettre en œuvre une tranche verticale de l'application et effectuer des tests de performance avant de créer le reste de l'application. Cela vérifiera votre architecture.
Pourriez-vous me signaler où dans le lien «Méthodologie de Juval Lowy», je peux aller avoir une idée de la méthodologie réelle?
Malheureusement, il n'y a pas qu'un seul endroit sur Internet pour apprendre sa méthodologie. Pour cela, vous devriez prendre la classe de sa maîtrise d'architecte. Ce que vous pouvez faire est d'écouter l'épisode de .Net Rocks, mettez-le, lisez son livre WCF et lisez ses meilleures pratiques de WCF. Tous ces liens se trouvent sur la page d'accueil de idesign.net sous ressources.
Pourriez-vous s'il vous plaît répondre à Stackoverflow.com/Questtions/9538710/... ?