Quel est SOA (Service orienté architecture)?
Appelez-moi un troll si vous voulez, mais je suis sérieux: en quoi la nouvelle tendance SOA est-elle différente de l'architecture de service client que je construisais il y a 15 ans? Je continue à entendre SOA mais je ne vois pas en quoi c'est différent de ce que nous avons toujours fait.
Il y a 10 ans, mon entreprise avait plusieurs clients (dans plusieurs langues) qui communiquaient avec le même service. Ce n'était pas du XML (c'était un protocole binaire appelé Microsoft DCOM) et il n'y avait pas de détection automatique via WSDL mais c'est correct puisque la lecture de la documentation était tout aussi facile. Notre système était même "ouvert" dans le sens où nous l'avons suffisamment documenté pour permettre à des tiers de parler à nos services. Nous n'étions pas des pionniers - chaque entreprise que je connaissais il y a 10 ans faisait la même chose.
La seule différence que je vois entre hier et aujourd'hui est qu’il n’ya maintenant qu’un seul service disponible sur Internet, alors qu’il ya 10 ans, chaque client hébergeait sa propre instance du service. Mais ce n'est pas un problème d'architecture - où le service vit physiquement est transparent pour quiconque l'utilise.
Alors, qu'est-ce que SOA est différent de ce que nous faisons depuis des années? SOA est-il simplement un terme marketing représentant une meilleure pratique devenue courante il y a très longtemps? Ou suis-je en manque subtilement à SOA qui est différent de ce que nous avons toujours fait?
Oubliez XML. Oubliez WSDL. SOA n'est pas une technologie que vous pouvez acheter, même si elle est souvent commercialisée de cette façon.
Le vrai point de SOA concerne uniquement les technologies de l'information organisation . L’intérêt de SOA est d’éviter de créer un grand nombre d’applications comportant des pools de données isolés et ne parlant pas du tout (et donc dupliquant souvent des données), ou seulement de manière inefficace. , chemin bogué à travers les couches d’adaptateur ou les systèmes EAI.
Pour les grandes entreprises, il s’agit d’un problème grave: elles disposent de centaines d’applications distinctes insuffisamment intégrées. Il y a des doublons et des données incohérentes partout et le résultat est que les clients sont énervés et perdent de l'argent réel, car le service de facturation continue à envoyer les factures pour une commande annulée et le représentant du service clientèle ne peut même pas trouver la commande car elle est annulée dans le suivi des commandes système, mais pas le système de facturation.
La SOA est censée résoudre ce problème en concevant chaque application de manière à publier ses services de manière standardisée, afin que d’autres applications puissent accéder aux données sans avoir à les dupliquer.
D'un point de vue commercial, cela est hautement souhaitable. Le mot à la mode et la soupe à l'acronyme ne sont que des tentatives des entreprises informatiques pour tirer profit de cette opportunité. Malheureusement, cela a (mal) amené de nombreuses personnes, y compris des PDG, à croire que SOA est un produit que vous pouvez acheter et qui rendra votre système informatique plus efficace, sans se rendre compte que cela ne se produira que si vous vous réorganisez également. votre système informatique (et peut-être même vos unités commerciales) soit compatible SOA.
Permettez-moi d'utiliser le célèbre fouetteur de Integration Hell: Telco.
Dans les années 90, les entreprises de téléphonie mobile étaient très nombreuses dans mon quartier, presque aussi nombreuses que les revendeurs longue distance rendus possibles par la déréglementation des communications du milieu des années 90. Le temps passe et Bell Atlantic devient la centrale électrique de Verizon et engloutit entreprise après entreprise (et au moins une Baby Bell). Chacune de ces sociétés a mis en place des technologies, dans des tours, des équipements de commutation, des systèmes de facturation COMPLETEMENT incompatibles les uns avec les autres.
Ainsi, la société déclare: «D'accord, nous avons ces modèles de gestion des affaires. Donnons un visage convivial et cohérent à TOUTE notre technologie, sous la forme de WSDL/SOAP/XSD - chaque langue et système que nous avons aujourd'hui peuvent être interfacé à cela! Lentement mais sûrement, la société rend tous ses systèmes capables de rendre compte de leurs capacités, d’être interrogés à des fins de chargement et de facturation, et d’être exploités par des futurs visionnaires, d’une manière qui n’a pas encore été prise en compte.
Tout le monde peut créer un client SOA. N'importe qui avec wget et un éditeur de texte. Et tout le monde peut analyser les résultats (XML).
C’est ce qui est fondamentalement différent des architectures client/serveur antérieures. L'autre jour, je parlais à quelqu'un de la possibilité d'interfacer des systèmes basés sur Cobol et Smalltalk avec des architectures SOA. C'est un problème facile à résoudre. Dites-moi que vous pouvez dire la même chose pour vos systèmes DCOM.
SOA n’est rien d’autre qu’un moyen de conception , dans lequel les modules communiquent entre eux par le biais de "services". C'est juste cela, et maintenant la question suivante est: qu'est-ce exactement qu'un "service" et quelle est sa différence avec une "méthode" régulière ??
Un service est une opération qui effectue une seule opération métier atomique. Cette atomicité le rend hautement réutilisable à partir de nombreux modules. Une opération commerciale complexe consiste alors simplement à lancer l'invocation de plusieurs de ces services dans un ordre spécifique.
La SOA n’a rien à voir avec une technologie spécifique, c’est juste une façon spécifique de concevoir.
Le professeur Frank Leymann de l’Université de Stuttgart prend SOA comme concept clé de son service de recherche en informatique (SOC) alors qu’il parle de SOA . On le voit interrogé sur la définition de SOA et la conversation qui s'ensuit pourrait être une bonne lecture.
Veuillez noter que notre feuille de route concerne "l'informatique orientée service (SoC)", c’est-à-dire le paradigme de calcul derrière l’orientation service. L'architecture orientée services (SOA) est une réalisation architecturale de ce paradigme de calcul. Vous pouvez comparer cela à "informatique client/serveur" en tant que paradigme et à "navigateur/serveur Web" ou "procédure client/base de données DB" en tant que deux réalisations architecturales (de diverses autres) de ce paradigme.
...
La SOA n'est pas complètement nouvelle. Certains aspects individuels de SOA sont utilisés dans la pratique depuis longtemps. Par exemple, jetez un coup d’œil sur le "couplage faible": les entreprises utilisent depuis des décennies une technologie de messagerie fiable pour intégrer des applications, c’est-à-dire pour les coupler de manière lâche. Ne vous méprenez pas, il existe de nouveaux concepts dans la SOA, par exemple. les concepts résultant de la combinaison de concepts mis en place dans la SOA, c’est-à-dire qu’ils résultent de l’émergence.
Les spécifications de service Web rendent les technologies correspondantes disponibles sur plusieurs plates-formes. C'est à dire. les spécifications correspondantes n'inventent pas de concepts fondamentalement nouveaux, mais définissent le fonctionnement de ces concepts et de leurs implémentations dans des environnements hétérogènes. L'interopérabilité qui en résulte est révolutionnaire, rendant SOA réel.
En résumé, SOA est un mélange de choses matures et de nouvelles choses émergentes.
Il existe également un référence de l’article SoC daté d’avril 2006.
Une recherche sur Google identifie Prof. Frank Leymann et histravaux .
Neal Ford a de nombreuses opinions bien arrêtées concernant la SOA. Vous pourriez trouver son point de vue intéressant.
Tactiques contre stratégie (SOA & The Tarpit of Irrelevancy)
Standard vs. vs. Standardized (SOA et Tarpit of Irrelevancy)
Outils et anti-comportement (SOA & Tarpit of Irrelevancy)
La cabine de Rubick (SOA et le Tarpit of Irrelevancy)
Le triomphe de l'espoir sur la raison (SOA & The Tarpit of Irrelevancy)
Je pense que SOA est à la fois un terme marketing et une intégration de solutions existantes, dans le but de vendre les services au lieu de tout le logiciel ou de la machine.
Pour moi, une architecture orientée service survient lorsqu'une entreprise souhaite intégrer une sélection d'applications disparates concernant un domaine commun dans un ensemble de services interopérables fonctionnant sur une source de données unique.
Dans le cas d'une nouvelle entreprise en démarrage ayant une idée pour un logiciel/une suite de logiciels, je ne vois pas comment une entreprise peut démarrer avec une architecture orientée service dès le départ. Au début, chaque solution (qui pourrait bien devenir un service permettant de devenir interopérable) devrait chercher à résoudre son espace de problèmes de manière isolée.
Ce sera peut-être dans la feuille de route pour une fonctionnalité ou une suite d'entreprise pour que chaque solution devienne un service interopérable à mesure que les solutions seront complétées et entreront en service. Pour cela, les équipes de développement adopteront peut-être une approche modulaire/par composants pour la construction de la solution (service éventuel), afin de faciliter l’inclusion de la solution en tant que service dans une architecture orientée service.
Dans le cas où des îlots de logiciels existants deviendraient des services interopérables dans une architecture orientée service, l'approche permet aux éléments logiciels - qui peuvent être distribués et écrits dans différentes langues - de communiquer via un API exposé et/ou un protocole commun (par exemple une sorte de service Web) et un format de données générique (par exemple, XML).
La SOA est une approche ou une idée. Ce n'est pas un cadre ou un outil. Lorsque les WDSL et les EJB sont supprimés, cela est souvent oublié ... car l'idée de SOA n'est pas nouvelle.
En fait, SOA utilise également une architecture client-serveur. De plus, SOA est un moyen de concevoir votre logiciel. Supposons que votre application puisse entrer dans des tâches simples et indépendantes telles que rechercher un livre, ajouter un nouveau livre, recommander un livre en fonction des préférences de l'utilisateur, etc. Si vous envisagez un service (une API) pour chaque tâche, vous utilisez en fait une architecture SOA. L'avantage de cette architecture est que vous construisez une application Web ou une application mobile, vous n'avez besoin que des services développés ci-dessus (API).
Une architecture orientée services (SOA) est un modèle architectural dans lequel les logiciels sont conçus comme des blocs de construction. C'est-à-dire le développement modulaire, qui offre la souplesse nécessaire pour assembler à notre guise. Si vous souhaitez démarrer un nouveau projet au lieu de repartir de zéro, nous pouvons réutiliser les services et si vous souhaitez créer un nouveau service, nous pouvons facilement l'intégrer au service existant pour créer un nouveau projet. Nous pouvons ainsi économiser beaucoup de temps et d’argent. Les principes de base de l’architecture orientée services sont indépendants des fournisseurs, des produits et des technologies.
Analogie: Les jouets sont construits avec des blocs de construction Lego.
En réalité, SOA est un ensemble de services bien définis. Fondamentalement, SOA utilise un service faiblement couplé pour obtenir facilement le résultat souhaité. Les détails d'implémentation d'un service sont masqués pour le client/consommateur, ainsi toute modification de l'implémentation n'affectera pas le service jusqu'à ce que le contrat entre eux soit modifié. Les fournisseurs de services sont des composants qui exécutent une logique métier en fonction d'entrées et de sorties prédéterminées et exposent cette fonctionnalité via une implémentation SOA. Cela permet aux systèmes basés sur SOA de réagir plus rapidement et à moindre coût pour l'entreprise. La principale différence entre composant et SOA est que SOA fournit un message de normes ouvertes qui n'est spécifique à aucun langage ou plate-forme de programmation. En conséquence, vous pouvez obtenir un haut degré de couplage lâche et d'interopérabilité entre plates-formes et technologies. Dans un monde client-serveur traditionnel, le fournisseur sera un serveur et le consommateur, un client.Vous pouvez en savoir plus sur SOA ici: Architecture orientée service (SOA)
La plupart des réponses semblent indiquer que SOA (Service Oriented architecture) concerne la création d'applications de manière standardisée, de sorte que d'autres applications puissent interagir avec celles-ci de manière indépendante de la plate-forme.
Je ne sais pas si le sens a changé depuis, mais j’ai eu l’occasion de travailler avec une entreprise qui propose la suite SOA et les idées suivantes.
Bien sûr, lorsque vous concevez une application, vous ne pouvez pas garantir qu'elle sera compatible avec toutes les plates-formes. Prenons par exemple stock Trading systems. Ils utilisent Fix protocol pour transférer des messages. Vous attendez-vous maintenant à renvoyer les données au format XML afin qu'elles puissent être appelées ainsi conformes à la norme SOA? Définitivement pas! SOA est une approche architecturale qui peut vous aider à decouple your application/services et à les laisser interagir les uns avec les autres. L'épine dorsale de SOA est une ESB (Enterprise Service Bus) utilisée pour transférer des données d'un service à un autre. SOA l'architecture devrait prendre en charge les conversions de formats. Par exemple -
FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)
Ces modules de conversion sont communément appelés adapters et font généralement partie de la suite SOA. Pour un peu plus d'informations, reportez-vous à une autre réponse -
Bien sûr, SOA est un mot utilisé à des fins marketing. Techniquement, c'est aussi simple que de désérialiser et sérialiser des données afin que les services puissent être découplés et indépendants de la plate-forme, mais l'idée sous-jacente est concrète.
Voir également Page Wiki pour les mêmes.