Qu'est-ce que SOA "en clair anglais"?
Quelqu'un peut-il expliquer en anglais simple qu'est-ce que SOA all about? J'entends SOA ici, SOA mais je ne peux pas comprendre exactement ce que c'est et à quoi sert-il. Était-ce un concept simple et a évolué plus tard en quelque chose d'énorme ou quoi?
Tous les documents, y compris wiki, sont un peu abstraits ou peut-être que je suis un idiot et ne l'obtiens pas. Y a-t-il un guide d'idiot à ce sujet?
Qu'y a-t-il exactement derrière ces trois lettres?
Vous pourriez trouver cet article (Qu'est-ce que la SOA? - SOA et les services Web expliqués)) utile.
Un petit teaser:
La SOA est un style d’architecture des applications qui se compose d’agents logiciels discrets dotés d’interfaces simples et bien définies et orchestrés par un couplage faible permettant d’exécuter une fonction requise.
Dans la SOA, deux rôles sont utilisés: fournisseur de services et consommateur de services. Un agent logiciel peut jouer les deux rôles. SOA n'est pas un concept entièrement nouveau - toutefois, cet article porte principalement sur SOA tel qu'il est implémenté avec des services Web.
SOA est un nouveau badge pour des idées très anciennes:
Divisez votre code en modules réutilisables.
Encapsulez dans un module toute décision de conception susceptible de changer.
Concevez vos modules de manière à pouvoir être combinés de différentes manières utiles (parfois appelées "famille" ou "ligne de produits").
Ce sont tous des principes fondamentaux de développement de logiciels, dont beaucoup ont été formulés pour la première fois par David Parnas.
Quoi de neuf dans SOA est
Vous le faites sur un réseau.
Les modules communiquent en échangeant des messages entre eux via le réseau, plutôt que par le biais de mécanismes de langage de programmation plus classiques, tels que les appels de procédure. En particulier, dans une architecture orientée services, les composants ne partagent généralement pas les états mutables (variables globales dans un programme traditionnel). Ou bien, s'ils partagent l'état, cet état est soigneusement verrouillé dans une base de données qui est elle-même un agent et qui peut facilement gérer plusieurs clients simultanés.
Je vois de nombreuses réponses expliquant une architecture SOA (Service Oriented Architecture) en utilisant des mots et des termes techniques encore plus avancés. Je voudrais tenter de l'expliquer pour le profane, en utilisant une analogie en anglais simple.
mais d'abord une description d'une SOA
La SOA pourrait être décrite en trois couches, comme indiqué dans l'image ci-dessous. D'un côté, nous avons le fournisseur et de l'autre côté, le consommateur , séparés par un pont où les deux côtés communiquent.
Le consommateur utilise un certain nombre d'applications nécessaires à son activité et le fournisseur utilise des composants fournissant des informations à ces applications. Ils communiquent via un ensemble de services en utilisant une architecture commune.
l'analogie
Imaginez une maison à la campagne qui, à bien des égards, fait partie d’une communauté plus vaste, comme une ville ou un village. La ville a ses propres systèmes complexes d'approvisionnement en eau et en électricité, de traitement de l'assainissement, de transport et d'autres services publics. La maison est le consommateur de ce modèle, la ville (ou communauté). ) est le fournisseur et les tuyaux, égouts, lignes électriques, fibres optiques, etc. est l’infrastructure dans laquelle ils communiquent.
Ce modèle pourrait être comparé de manière lâche à une SOA. Les personnes à la maison utilisent différentes "applications" telles que radiateurs, ordinateurs, toilettes, lampes, chauffage au sol, baignoires, etc. Ces applications ne tiennent pas compte de la façon dont la ville produit de l'eau, crée de l'électricité ou traite les déchets aussi longtemps. comme cela fonctionne. Les composantes de la ville sont des groupes électrogènes, des pompes à eau et des zones d’assainissement. Il fournit à la maison tous ces besoins, mais c'est à la maison de l'utiliser comme bon lui semble.
J'espère que cela a donné à au moins une meilleure image d'une SOA.
Supposons que vous avez quatre cuisiniers. En SOA, vous supposez qu'ils se détestent, vous vous efforcez donc de les laisser parler le moins possible.
Comment tu fais ça? Eh bien, vous allez d’abord définir les rôles et l’interface - cuisinier 1 préparera la salade, cuisinier 2 préparera la soupe, cuisinier 3 préparera le bifteck, etc. Ensuite, vous placerez les plats bien organisés sur la table interfaces) et dites: "Tout le monde, veuillez placer votre création dans les assiettes assignées. Ne vous souciez de personne.".
De cette façon, les quatre cuisiniers doivent se parler le moins possible, ce qui est très bon pour le développement de logiciels - pas nécessairement parce qu'ils se détestent, mais pour d'autres raisons telles que la localisation physique, l'efficacité dans la prise de décision, etc.
Cela signifie également que vous pouvez recombiner les plats à votre guise. Par exemple, vous pouvez utiliser le dessert pour servir un café, ou simplement prendre la soupe et la combiner avec un pain acheté auprès d’une autre entreprise pour proposer un menu moins cher, ou laisser d’autres restaurants utiliser vos salades pour combiner leurs plats, etc. .
L’une des implémentations les plus réussies de SOA était chez Amazon. Grâce à leur conception, ils ont pu reconditionner l’ensemble de leur infrastructure et la vendre au format Amazon Web Service.
* Ceci n'est qu'un aspect de la SOA.
La SOA est un style architectural mais aussi une vision sur la manière dont une application hétérogène doit être développée et intégrée. Le but principal de SOA est de s’éloigner de applications monolithiques et d’avoir à la place un ensemble de services réutilisables pouvant être composé pour créer des applications .
IMHO, SOA n'a de sens qu'au niveau de l'entreprise et ne signifie rien pour une seule application.
Dans de nombreuses entreprises, chaque service avait son propre ensemble d’applications d’entreprise, ce qui impliquait
Des fonctionnalités similaires ont été implémentées plusieurs fois
Les données (par exemple, les données des clients ou des employés) doivent être partagées entre plusieurs applications.
Les applications étaient centrées sur les départements.
Avec la SOA, l’idée est de mettre des services réutilisables à la disposition de l’ensemble de l’entreprise, de sorte que les applications puissent être construites et composées à partir de ces services. La promesse de SOA sont
Pas besoin de réimplémenter des fonctionnalités similaires à plusieurs reprises (par exemple, fournir un service client ou employé)
Facilite l'intégration d'applications ensemble et l'accès à des données ou fonctionnalités communes
- Effort de développement centré sur l'entreprise.
La vision SOA nécessite un décalage technologique ainsi qu'un changement organisationnel. Si elle résout un problème, elle en introduit également d'autres, par exemple la sécurité est beaucoup plus difficile avec SOA qu'avec une application monolithique. Par conséquent SOA est sujet à discussion pour savoir si cela fonctionne ou non.
Ceci est la vue de 1000 pieds de SOA. Cependant, cela ne s'arrête pas là. Il existe d'autres concepts complémentaires SOA tels que l'orchestration des processus métier (BPM), le bus de service d'entreprise (ESB), le traitement des événements complexes (CEP), etc.), etc. Ils abordent tous le problème de Alignement informatique/entreprise, c’est-à-dire comment l’informatique peut prendre en charge l’activité de manière efficace.
SOA est l'acronyme de Service Oriented Architecture.
SOA conçoit et écrit des applications logicielles de telle sorte que des modules logiciels distincts puissent être intégrés de manière transparente avec un degré élevé de réutilisation.
La plupart des gens limitent SOA en écrivant des services-logiciels-Web-logiciels client/serveur. Mais le contexte de SOA est trop petit. SOA est beaucoup plus grand que cela. et au cours des dernières années, les services Web ont été le principal moyen de communication, ce qui explique probablement pourquoi les gens pensent à SOA) en tant que services Web limitant de manière générale les limites et la signification de la SOA.
Vous pouvez penser à écrire un module d'accès à la base de données qui est si indépendant qu'il peut fonctionner seul, sans aucune dépendance. Ce module peut exposer des classes pouvant être utilisées par tout logiciel hôte nécessitant un accès à une base de données. Il n'y a pas de configuration de démarrage dans l'application hôte. Tout ce qui est nécessaire ou requis est communiqué via des classes exposées par le module d'accès à la base de données. Nous pouvons appeler ces classes en tant que services et considérer le module comme compatible avec les services.
Pratiquer SOA donne un degré élevé de réutilisation en appliquant DRY [ne vous répétez pas] qui donne lieu à un logiciel hautement maintenable. La maintenabilité est la première chose à faire. toute architecture logicielle pense à - SOA vous le permet.
Autant que je sache, le concept de base est que vous créez de petits "services" qui fournissent quelque chose d’utile aux autres systèmes et évitent de construire de grands systèmes qui ont tendance à tout faire à l'intérieur du système.
Ainsi, vous définissez un protocole que vous utiliserez pour l’interaction (par exemple, il pourrait s’agir de SOAP)) et laissez votre "système-qui-fait-certains-travail-travail" pour interagir avec le petits services pour atteindre votre "grand objectif".
Je vous suggérerais de lire les articles de Thomas Erl et Roger Sessions, cela vous donnera une idée précise de ce qui est SOA). Ce sont aussi de bonnes ressources, regardez le SOA expliqué à votre patron, un pour un profane
Atteindre l'intégrité dans une SOA
Une seule suggestion: -
Lire Concepts, technologie et conception SOA par Thomas Erl.
Il a très magnifiquement donné les détails sur SOA en clair et avec des études de cas.
ce qui a tendance à se produire dans les grandes organisations est qu’au fil du temps, tout est soit monolithique, soit disparate partout, soit un peu des deux. Quelqu'un finit par arriver et dit que nous avons un gâchis. Maintenant, vous voulez repenser (argent à quelqu'un) tout ce qui doit être orienté dans une sorte de monotlithique dépend du paradigme qui vous paye, tout en pouvant ajouter des pièces et des pièces indépendamment du maître/monolithe.
Donc, vous achetez le SOA) d’Oracle et Oracle devient le patron de toutes vos parties. Tous les autres joueurs entrant doivent travailler avec SOA via un service (service Web ou quoi que ce soit d'autre.) Le monolithe Oracle s'occupe de tout (monolithe n'est pas péjoratif.) Ah oui, vous avez ASP.NET MVC au premier plan ou autre chose.
l’essentiel est d’intégrer et de sortir sans heurt les choses de leur système et de garder le fournisseur Oracle SOA, Microsoft WCF, au cœur de tout cela. tout est bon, fluide, les choses bougent avec peu ou pas d'impact, même les services humains, pas seulement les ordinateurs.
Pour moi, cela signifie simplement un ensemble de services Web (ou ce que nous appelons à l'avenir) avec un bon frontal. Et si vous possédez la base de données, frappez-la et arrêtez de vous inquiéter des mots à la mode. ça va.
de blogs ittoolbox.
Ce qui suit décrit les similitudes et les différences avec les techniques de conception antérieures:
• SOA versus programmation structurée o Similitudes: ce qui est similaire aux appels de sous-routines où les paramètres sont passés et le fonctionnement de la fonction extrait de l'appelant - par exemple, lien CICS et execute et mot réservé CALL COBOL. Les cahiers servent à définir la structure de données qui est généralement définie comme un schéma XML pour les services: o Différences: SOA est faiblement couplé, ce qui implique que les modifications apportées à un service ont moins d’impact sur le consommateur (les "appels" programme) et les services sont interopérables entre les langues et les plates-formes.
• SOA versus OOA/OOD o Similitudes: encapsulation, abstraction et interfaces définies o Différences: SOA est vaguement couplé à aucune hiérarchie de classe ou héritage, Bas niveau abstractions - niveau de classe par rapport au service aux entreprises
• SOA versus développement à base de composants (CBD) hérité - par exemple, CORBA, DCOM, EJB o Similitudes: réutilisation via l'assemblage de composants, interfaces, appels distants o Différences: adoption large des normes, schémas XML vs. Marshaled Objects, Orchestration de services, La conception en vue de la réutilisation est plus facile, les services sont centrés sur les entreprises plutôt que sur les technologies de l'information, les services aux entreprises sont bien plus détaillés.
• SOA (pour l'intégration) par rapport à EAI) o Similarités: meilleures pratiques (interfaces bien définies, schémas normalisés, architecture pilotée par les événements), interfaces réutilisables, schémas communs o Différences: normes, adoption et amélioration des outils
En lisant les réponses ci-dessus, il me semble que SOA est ce que les développeurs (bons au moins) font depuis le premier jour.
Eh bien, vous voyez .. SOA signifie Service Oriented Architecture ...). En termes simples, vous écrivez un morceau de code très générique, c’est-à-dire qu’il fait quelque chose qui peut être utilisé beaucoup d’applications ... peut ressembler à un carnet d’adresses ou à une calculatrice et que vous lancez ce code sur IIS, vous fournissez donc un service par le biais de votre code. Vous êtes donc un fournisseur de services. Il n'a alors plus besoin d'écrire le code, il utilise simplement votre code, peut-être par le biais d'un service Web, d'où il devient un consommateur de service. Par conséquent, la création d'un programme utilisant de tels services s'appelle SOA. fournisseur et le consommateur peuvent être en interaction même s'ils utilisent des langages de programmation diff.
Cela pourrait aussi signifier "Struct of Arrays" (par opposition à "Array of Structs") qui est un sujet commun dans la programmation parallèle (en particulier SIMD), mais je suppose que ce n'est pas ce que vous voulez dire ici!
La SOA est un mot à la mode qui a été inventé par les fournisseurs de technologies pour aider à vendre leurs technologies liées au bus de service d'entreprise. L'idée est de rendre vos applications de petit îlot dans l'entreprise (par exemple: système de comptabilité, système de contrôle des stocks, etc.), des services exposés, de sorte qu'ils puissent être orchestrés de manière flexible dans des "applications", ou plutôt devenir des éléments d'une entreprise globale agrandie. logique.
Fondamentalement, une charge de vieilles conneries qui ne fonctionnent presque jamais, car elle passe à côté du fait que la technologie est telle qu’elle est dans une organisation, cela tient à la culture, à l’évolution, à l’histoire de la firme et au verrou toute tentative de restructuration de la technologie est vouée à l’échec.
Ça dépend de qui vous êtes!
Si vous êtes propriétaire d’une entreprise, SOA est une solution pour augmenter vos revenus et votre agilité. Si vous êtes un architecte d’entreprise, SOA est un moyen dessiner un logiciel agréable et propre sur une toile vierge. Si vous êtes architecte SOA est la solution pour concevoir des services à couplage lâche sur une plate-forme d’intégration, il suffit de les brancher à des prises. vous êtes un développeur SOA est un paradigme de programmation dans lequel un service est au centre de la conception et du code.
Vous devriez lire 100-SOA-Questions [pdf]
À votre santé
L'architecture logicielle SOA (Service Oriented Architecture) est un style d'architecture logicielle qui crée des applications sous la forme d'une collection d'éléments enfichables, qui peuvent être réutilisés par d'autres applications.
Écoutez l'édition de cette semaine du podcast Floss Weekly , qui couvre SOA. Les descriptions sont plutôt de haut niveau et n'entrent pas dans trop de détails techniques (bien que des exemples plus concrets et reconnaissables de SOA aient été utiles).
Une architecture d'application traditionnelle est:
- Une interface utilisateur
- Trucs non définis (implémentation) encapsulés/cachés derrière l'interface utilisateur
Si vous souhaitez accéder aux données par programme, vous devrez peut-être recourir à la récupération d'écran.
La SOA me semble être une architecture centrée sur l’exposition de données et/ou d’API lisibles par machine, plutôt que sur l’exposition d’UI.
Une architecture SOA ou orientée service est un modèle d’architecture logicielle dans lequel des applications ou des systèmes sont construits à partir de services logiciels sous-jacents (et généralement distribués) conformes à un ensemble spécifique de caractéristiques, à savoir:
- Interface, politique et contrat
- Transparence de localisation
- Autonome
- Abstrait
- Réutilisable
- Composable
- Apatride
- Découvrable
- Extensible
- Couplage lâche
L’objectif principal de SOA est l’agilité de développement du logiciel, c’est-à-dire la capacité de réagir au changement facilement et à moindre coût, permettant ainsi aux entreprises de réagir rapidement à l’évolution des marchés.
Les services sont généralement (mais en aucun cas exclusivement) implémentés en tant que services Web, c’est-à-dire qu’ils fonctionnent sur le protocole HTTP Web omniprésent et qu’ils sont implémentés soit à l’aide de XML SOAP ) REST paradigme.