application complètement SOA?

Question

Est-il judicieux de construire une grande application entièrement basée sur la SOA? Ou juste quelques portions? Connexion au compte utilisateur, comptabilité, cartographie gis, ventes, etc?

En d'autres termes, serait-il sage de construire une interface graphique pour une telle application en HTML & Javascript qui fait tout son échange via AJAX vers les services Web .NET sur le back-end?

Je ne vois pas la peine de perdre toutes les fonctionnalités .net .aspx telles que l'authentification par formulaires, l'état d'affichage, etc. Mais mon collègue dit que si nous allons SOA, il n'y a pas besoin de .NET à l'avant. Mais je pense qu'il devrait y avoir une sorte d'équilibre. Où dessinez-vous la ligne? Tous les appels à la base de données doivent-ils passer par les services Web?

Answer 1

Les mots de la chanson «Si j'avais un marteau» me viennent à l'esprit. SOA is an architectural approach pour développer des logiciels en tant que série de services. À mon avis, cela est mieux pour les systèmes qui ont moins de latence immédiate et une bande passante limitée, et un coût élevé d'accès, etc. (tout cela est évidemment hautement subjectif). Vous n'avez pas besoin de SOA complète juste lâche entre les composants qui, je dirais, est un bon objectif à atteindre.

Les appels DB peuvent passer par un service, prendre des services de données ADO.NET par exemple, mais vous devez vraiment peser avec ce que le service doit fournir. Prenez la mise en cache. Une approche décente de SOA considérera que les données peuvent avoir besoin d'être mises en cache pour réduire la charge de service. Vos données peuvent donc être périmées dans l'interface utilisateur? Autorisez-vous ce cas d'utilisation? Est-ce juste pour les informations de connexion pour être périmé (un exemple approximatif je sais mais peut-être quelque chose que peut doivent être adressées).

Dans l'ensemble, cela dépend. Je pense que certaines choses se prêtent très bien à la SOA. Si vous adoptez une approche DDD, les services qui représentent les domaines le feront probablement. De cette façon, votre interface utilisateur parle aux services de domaine et pas aux lignes dans la table car la base de données est abstraite derrière les services de domaine. Ne pas utiliser une seule méthodologie pour résoudre tous les problèmes.

Voir cette SO question trop

Answer 2

Je veux juste dire que « avec SOA nous construisons pour le changement, alors qu'avec l'ingénierie des systèmes traditionnels, nous construisons pour la stabilité. » Le problème avec la stabilité, bien sûr, est que cela ne prend que l'entreprise jusqu'à présent - si l'organisation a besoin d'agilité commerciale, alors il vaut mieux mettre en œuvre SOA. Donc, cela dépend uniquement de ce que vous voulez accomplir, vous êtes celui qui devrait dessiner la limite. Je l'ai lu dans l'article sur SOA quelques jours en arrière car je travaille trop sur SOA.

---

EDIT:

En attendant, je suis tombé sur l'article this et de la pensée de partager avec vous. La vidéo explique assez bien le scénario actuel de SOA et ses vues par des personnes différentes.

Answer 3

C'est une architecture orientée services, pas une architecture exclusive.

La logique de présentation et la plomberie doivent vivre quelque part; Tout dépend de l'endroit où cela a le plus de sens de vivre. Par exemple, supposons que vous ayez un composant d'interface utilisateur qui repose sur un ensemble d'appels hautement bavard mais efficace vers une base de données pour générer une analyse complexe de quelque chose (faites votre choix). Si votre navigateur Web effectue tous ces appels, vous introduisez des problèmes de latence et de concurrence simultanés. Si un service Web effectue tous ces appels, vous mettez potentiellement en place une logique de présentation pour formater ce résultat.

Si vous utilisez un état de session (ou une période de services Web), vous utilisez ASP.Net de toute façon. Essayez de le désinstaller et vérifiez si vos services Web fonctionnent toujours.

Si la logique de présentation doit vivre du côté serveur, il est préférable qu'elle vive dans un cadre destiné à la présentation plutôt qu'à un service Web, IMO. Si vous n'avez pas regardé MVC 2, faites-le. Il est incroyablement facile de configurer une application qui fusionne la prise en charge de l'interface utilisateur du navigateur et du serveur (par exemple, les contrôles de validateur jQuery soutenus par la validation côté serveur). Inversement, le navigateur Web fournit une plate-forme expressive. En supposant que le navigateur et la connaissance de l'équipe, l'architecture AJAX/SOA que vous décrivez est une bonne. Je l'utilise de plus en plus et essaye de rendre mes pages de serveur plus propres et plus simples mais je n'ai pas l'intention d'exclure ASP.Net de ma boîte à outils de sitôt.

Answer 4

L'implémentation du client doit être complètement déconnectée du service Web principal dans un SOA. Le service devrait pouvoir être consommé par n'importe quel client. Si vous utilisez .NET à l'arrière et à l'extrémité car ils peuvent être codés pour communiquer directement, alors vous manquez le point, car maintenant ils sont étroitement couplés et ce que vous avez maintenant est une application de tuyau de poêle. Le client ne devrait avoir aucune idée de la façon dont le côté serveur est implémenté - cela ne devrait pas poser de problème si le service Web principal est construit en utilisant .NET, Java ou autre. Dans une véritable architecture SOA, vous devriez pouvoir rechercher des services dans le référentiel de services, lier éventuellement les sorties avec d'autres services ou utiliser XSLT pour créer d'autres sorties qui n'étaient pas forcément prises en compte lors de la construction du service d'origine, et le consommer d'une manière standard dans n'importe quel client sur le front end.

Il semble que ce que vous demandez vraiment, c'est comment créer une seule application. Le but d'une SOA est de fournir des ensembles de données standard à travers des interfaces réutilisables, qui n'ont pas d'application ou d'implémentation spécifique en tête. Commencer à construire une seule application avec tout le back-end composé de services SOA serait une entreprise énorme. Dans MY l'esprit, chaque service principal devrait être construit en raison de sa valeur intrinsèque tout seul et être fourni à l'ensemble du «domaine» SOA. Puis quand vous ou moi décidons de faire un client qui fait X, Y et Z, nous pouvons simplement aller trouver ces capacités dans la SOA et les blesser.