Kann jemand im Klartext erklären, worum es bei SOA geht ? Ich höre SOA hier, SOA dort, aber ich kann nicht genau verstehen, was es ist und wofür es verwendet wird. War es ein einfaches Konzept und entwickelte sich später zu etwas Großem oder was?
Alle Dokumente, einschließlich Wiki, sind etwas abstrakt oder ich bin ein Idiot und verstehe es nicht. Gibt es einen Idiotenführer dazu?
Was genau steckt hinter diesen drei Buchstaben?
Antworten:
Dieser Artikel (Was ist SOA? - SOA und Web Services Explained) ist möglicherweise hilfreich.
Ein kleiner Vorgeschmack:
SOA ist ein Architekturstil für Anwendungen, bei dem sie aus diskreten Software-Agenten bestehen, die über einfache, genau definierte Schnittstellen verfügen und über eine lose Kopplung koordiniert werden, um eine erforderliche Funktion auszuführen.
In SOA gibt es zwei Rollen: einen Dienstanbieter und einen Dienstkonsumenten. Ein Software-Agent kann beide Rollen spielen. SOA ist kein völlig neues Konzept. Dieser Artikel konzentriert sich jedoch hauptsächlich auf SOA, wie es mit Webdiensten implementiert wird.
quelle
SOA ist ein neues Abzeichen für einige sehr alte Ideen:
Teilen Sie Ihren Code in wiederverwendbare Module.
Fassen Sie in einem Modul jede Entwurfsentscheidung zusammen, die sich wahrscheinlich ändern wird.
Entwerfen Sie Ihre Module so, dass sie auf verschiedene nützliche Arten kombiniert werden können (manchmal als "Familie" oder "Produktlinie" bezeichnet).
Dies sind alles Grundprinzipien für die Softwareentwicklung, von denen viele zuerst von David Parnas formuliert wurden.
Was ist neu in SOA ist
Du machst es in einem Netzwerk.
Module kommunizieren, indem sie Nachrichten über das Netzwerk aneinander senden, anstatt durch traditionellere programmiersprachliche Mechanismen wie Prozeduraufrufe. Insbesondere in einer serviceorientierten Architektur teilen sich die Teile im Allgemeinen keinen veränderlichen Zustand (globale Variablen in einem herkömmlichen Programm). Wenn sie den Status gemeinsam nutzen, wird dieser Status sorgfältig in einer Datenbank gesperrt, die selbst ein Agent ist und problemlos mehrere gleichzeitige Clients verwalten kann.
quelle
Ich sehe viele Antworten, die eine serviceorientierte Architektur (SOA) mit noch fortgeschritteneren Wörtern und Fachbegriffen erklären. Ich würde gerne versuchen, es dem Laien anhand einer Analogie in einfachem Englisch zu erklären .
Zunächst könnte jedoch eine Beschreibung einer SOA-
SOA in drei Schichten beschrieben werden, wie im folgenden Bild dargestellt. Auf der einen Seite haben wir den Anbieter und auf der anderen Seite den Verbraucher , getrennt durch eine Brücke, auf der die beiden Seiten kommunizieren.
Der Verbraucher verwendet eine Reihe von Anwendungen, die für sein Geschäft erforderlich sind, und der Anbieter verwendet Komponenten , die diese Anwendungen mit Informationen versorgen. Sie kommunizieren über eine Reihe von Diensten unter Verwendung einer gemeinsamen Architektur.
Die Analogie
Stellen Sie sich ein Haus auf dem Land vor, das in vielerlei Hinsicht Teil einer größeren Gemeinschaft ist, wie eine Stadt oder ein Ort. Die Stadt verfügt über eigene komplexe Systeme zur Bereitstellung von Wasser und Strom, zur Sanitärversorgung, zum Transport und zu anderen Versorgungsunternehmen. Das Haus ist der Verbraucher in diesem Modell, die Stadt (oder Gemeinde) ist der Anbieter und die Rohre, Abwasserkanäle, Stromleitungen, Lichtwellenleiter usw. sind die Infrastruktur, in der sie kommunizieren.
Dieses Modell könnte lose mit einer SOA verglichen werden. Die Leute im Haus verwenden eine Reihe verschiedener "Anwendungen" wie Heizkörper, Computer, Toiletten, Lampen, Fußbodenheizung, Badewannen usw. Diese Anwendungen kümmern sich nicht darum, wie die Stadt das Wasser erzeugt, den Strom erzeugt oder den Abfall so lange behandelt wie es funktioniert. Die Komponenten der Stadt sind Generatoren, Wasserpumpen und Sanitärbereiche. Es versorgt das Haus mit all diesen Bedürfnissen, aber es liegt an dem Haus, es so zu nutzen, wie es ihm passt.
Ich hoffe, das hat zumindest jemandem ein besseres Bild von einer SOA gegeben.
quelle
Nehmen wir an, Sie haben vier Köche. In SOA nehmen Sie an, dass sie sich hassen, und bemühen sich daher, dass sie so wenig wie möglich miteinander sprechen müssen.
Wie machst du das? Nun, Sie werden zuerst die Rollen und die Schnittstelle definieren - Koch 1 macht Salat, Koch 2 macht Suppe, Koch 3 macht das Steak usw. Dann legen Sie die Gerichte gut organisiert auf den Tisch (das sind also die Schnittstellen) und sagen: "Jeder, bitte platzieren Sie Ihre Kreation in Ihren zugewiesenen Gerichten. Kümmern Sie sich nicht um andere."
Auf diese Weise müssen die vier Köche so wenig wie möglich miteinander sprechen, was in der Softwareentwicklung sehr gut ist - nicht unbedingt, weil sie sich hassen, sondern aus anderen Gründen wie dem physischen Standort, der Effizienz bei der Entscheidungsfindung usw.
Dies bedeutet auch, dass Sie die Gerichte (Dienstleistungen) nach Ihren Wünschen neu kombinieren können. Zum Beispiel können Sie das Dessert einfach verwenden, um ein Café zu bedienen, oder einfach die Suppe nehmen und mit einem Brot kombinieren, das Sie von einer anderen Firma gekauft haben, um ein billigeres Menü anzubieten, oder andere Restaurants Ihre Salate verwenden lassen, um sie mit ihren Gerichten usw. Zu kombinieren .
Eine der erfolgreichsten Implementierungen von SOA war bei Amazon. Aufgrund ihres Designs konnten sie ihre gesamte Infrastruktur neu verpacken und als Amazon Web Service verkaufen.
* Dies ist nur ein Aspekt von SOA.
quelle
SOA ist ein Architekturstil, aber auch eine Vision, wie heterogene Anwendungen entwickelt und integriert werden sollten. Der Hauptzweck von SOA besteht darin, sich von monolithischen Anwendungen abzuwenden und stattdessen eine Reihe wiederverwendbarer Dienste bereitzustellen , die zum Erstellen von Anwendungen zusammengestellt werden können.
Meiner Meinung nach ist SOA nur auf Unternehmensebene sinnvoll und bedeutet nichts für eine einzelne Anwendung.
In vielen Unternehmen hatte jede Abteilung ihre eigenen Unternehmensanwendungen, was implizierte
Ähnliche Funktionen wurden mehrmals implementiert
Daten (z. B. Kunden- oder Mitarbeiterdaten) müssen von mehreren Anwendungen gemeinsam genutzt werden
Die Anwendungen waren abteilungsorientiert.
Mit SOA sollen wiederverwendbare Dienste unternehmensweit verfügbar gemacht werden, damit daraus Anwendungen erstellt und zusammengestellt werden können. Das Versprechen von SOA sind
Es ist nicht erforderlich, ähnliche Funktionen immer wieder neu zu implementieren (z. B. einen Kunden- oder Mitarbeiterservice bereitzustellen).
Erleichtert die Integration von Anwendungen und den Zugriff auf gemeinsame Daten oder Funktionen
Die SOA-Vision erfordert sowohl einen technologischen als auch einen organisatorischen Wandel. Während es einige Probleme löst, führt es auch andere ein, zum Beispiel ist die Sicherheit bei SOA viel schwieriger als bei monolithischen Anwendungen. Daher wird über SOA diskutiert, ob es funktioniert oder nicht.
Dies ist die 1000-Fuß-Ansicht von SOA. Hier hört es jedoch nicht auf. Es gibt andere Konzepte, die SOA ergänzen, wie z. B. Business Process Orchestration (BPM), Enterprise Service Bus (ESB), komplexe Ereignisverarbeitung (CEP) usw. Sie alle befassen sich mit dem Problem der IT / Business-Ausrichtung , dh der Art und Weise, wie die IT eingerichtet wird in der Lage sein, das Geschäft effektiv zu unterstützen.
quelle
SOA ist die Abkürzung für Service Oriented Architecture.
Sie können sich vorstellen, ein Datenbankzugriffsmodul zu schreiben, das so unabhängig ist, dass es ohne Abhängigkeiten eigenständig arbeiten kann. Dieses Modul kann Klassen verfügbar machen, die von jeder Host-Software verwendet werden können, die Datenbankzugriff benötigt. Es gibt keine Startkonfiguration in der Host-Anwendung. Was auch immer benötigt oder benötigt wird, wird über Klassen kommuniziert, die vom Datenbankzugriffsmodul verfügbar gemacht werden. Wir können diese Klassen als Services aufrufen und das Modul als service-fähig betrachten.
quelle
Soweit ich weiß, besteht das Grundkonzept darin, dass Sie kleine "Dienste" erstellen, die anderen Systemen etwas Nützliches bieten, und vermeiden, große Systeme zu erstellen, die dazu neigen, alles innerhalb des Systems zu tun .
Sie definieren also ein Protokoll, das Sie für die Interaktion verwenden (z. B. SOAP-Webdienste), und lassen Ihr "System, das einige geschäftliche Aufgaben erledigt" mit den kleinen Diensten interagieren, um Ihr "großes Ziel" zu erreichen. .
quelle
Ich würde vorschlagen, dass Sie Artikel von Thomas Erl und Roger Sessions lesen. Dadurch erhalten Sie einen festen Überblick darüber, worum es bei SOA geht. Dies sind auch gute Ressourcen. Schauen Sie sich die SOA an, die Ihrem Chef erklärt wurde, um eine Erklärung für Laien zu erhalten
Erstellen einer SOA
SOA-Entwurfsmuster
Integrität in einer SOA erreichen
Warum sollte Ihre SOA wie ein VW-Käfer sein?
SOA erklärt für Ihren Chef
WCF-Serviceleistung
quelle
Was in großen Organisationen häufig vorkommt, ist, dass im Laufe der Zeit alles entweder monolithische oder unterschiedliche Systeme überall oder ein wenig von beidem ist. Irgendwann kommt jemand herein und sagt, wir haben ein Durcheinander. Jetzt möchten Sie alles neu gestalten (Geld für jemanden), um sich in einer Art Monotlith zu orientieren. Dies hängt davon ab, wen Sie als Paradigma bezahlen, und gleichzeitig in der Lage sein, Teile und Teile unabhängig vom Master / Monolithen hinzuzufügen.
Sie kaufen also die SOA von Oracle und Oracle wird zum Chef aller Ihrer Teile. Alle anderen Spieler müssen über einen Dienst (Webdienst oder was auch immer) mit SOA arbeiten. Der Oracle-Monolith kümmert sich um alles (Monolith ist nicht abfällig gemeint). Oh ja, Sie haben ASP.NET MVC auf der Vorderseite oder etwas anderes.
Die Hauptsache ist, Dinge ohne Auswirkungen in das System hinein und aus dem System heraus zu bewegen und den Anbieter Oracle SOA, Microsoft WCF, als Kopf des Ganzen zu behalten. Alles ist alles in Ordnung, flüssig, Dinge, die sich mit wenig bis gar keinen Auswirkungen hinein- und herausbewegen, sogar menschliche Dienste, nicht nur Computer.
Für mich bedeutet dies nur eine Reihe von Webdiensten (oder wie auch immer wir sie in Zukunft nennen) mit einem guten Frontend. Und wenn Sie die Datenbank besitzen, klicken Sie einfach auf die Datenbank und machen Sie sich keine Gedanken mehr über Schlagworte. es ist in Ordnung.
quelle
Nur ein Vorschlag: -
Lesen Sie SOA-Konzepte, Technologie und Design von Thomas Erl.
Es hat die Details zu SOA sehr schön in einfachem Englisch und mit Fallstudien angegeben.
quelle
Nun, Sie sehen ... SOA steht für Service Oriented Architecture ... In einfachsten Worten, Sie schreiben einen Code, der sehr allgemein gehalten ist, dh etwas tut, das in vielen Anwendungen verwendet werden kann ... kann so etwas wie sein ein Adressbuch oder kann ein Taschenrechner sein. und Sie starten diesen Code auf dem IIS. Sie bieten also einen Service über Ihren Code an. Sie sind also ein Dienstleister. Jetzt möchte jemand einen ähnlichen Code verwenden, dann muss er den Code nicht erneut schreiben. Er verwendet Ihren Code einfach, möglicherweise über einen Webdienst. Somit wird er ein Dienstleistungskonsument. Daher wird das Erstellen eines Programms unter Verwendung solcher Dienste als SOA bezeichnet. Und die lose Kopplung ist vorhanden, da der Dienstanbieter und der Verbraucher möglicherweise interagieren, selbst wenn sie verschiedene Programmiersprachen verwenden. Ich hoffe du verstehst.
quelle
von ittoolbox Blogs.
Im Folgenden werden die Ähnlichkeiten und Unterschiede zu früheren Entwurfstechniken beschrieben:
• SOA versus strukturierte Programmierung o Ähnlichkeiten: Am ähnlichsten wie Unterprogrammaufrufe, bei denen Parameter übergeben werden und die Funktionsweise vom Aufrufer abstrahiert wird - z. B. CICS Link and Execute und das reservierte Wort COBOL CALL. Copybooks werden verwendet, um die Datenstruktur zu definieren, die normalerweise als XML-Schema für Dienste definiert wird. o Unterschiede: SOA ist lose gekoppelt, was bedeutet, dass Änderungen an einem Dienst weniger Auswirkungen auf den Verbraucher haben (das "aufrufende" Programm), und Dienste sind sprach- und plattformübergreifend interoperabel.
• SOA versus OOA / OOD o Ähnlichkeiten: Kapselung, Abstraktion und definierte Schnittstellen o Unterschiede: SOA ist lose ohne Klassenhierarchie oder Vererbung gekoppelt. Abstraktionen auf niedriger Ebene - Klassenebene versus Business Service
• SOA versus Legacy Component Based Development (CBD) - z. B. CORBA, DCOM, EJB. O Ähnlichkeiten: Wiederverwendung durch Zusammenstellen von Komponenten, Schnittstellen, Remote-Aufrufe ist einfacher, Services sind geschäftsorientiert vs. IT-fokussiert, Business-Services sind kursorientiert (breit gefächert)
• SOA (für Integration) versus Enterprise Application Integration (EAI) o Ähnlichkeiten: Best Practices (gut definierte Schnittstellen, standardisierte Schemata, ereignisgesteuerte Architektur), wiederverwendbare Schnittstellen, allgemeine Schemata o Unterschiede: Standards, Übernahme und verbesserte Tools
quelle
Wenn ich die obigen Antworten lese, scheint es mir, dass SOA das ist, was Entwickler (zumindest gute) vom ersten Tag an getan haben.
quelle
Es könnte auch für "Struct of Arrays" (im Gegensatz zu "Array of Structs") stehen, was ein häufiges Thema bei der parallelen (insbesondere SIMD) Programmierung ist, aber ich denke, das meinen Sie hier nicht!
quelle
SOA ist ein Schlagwort, das von Technologieanbietern erfunden wurde, um den Verkauf ihrer Enterprise Service Bus-bezogenen Technologien zu unterstützen. Die Idee ist, dass Sie Ihre kleinen Inselanwendungen im Unternehmen (z. B. Buchhaltungssystem, Bestandskontrollsystem usw.) alle Dienste verfügbar machen, damit sie flexibel in "Anwendungen" orchestriert werden können oder vielmehr Teil des gesamten Unternehmensgeschäfts werden Logik.
Grundsätzlich eine Menge alter Blödsinns, die so gut wie nie funktionieren, weil sie den Punkt verfehlen, dass die Gründe, warum Technologie so ist, wie sie in einem Unternehmen ist, auf Kultur, Evolution, Unternehmensgeschichte und die Bindung zurückzuführen sind, die so hoch ist wie keine Der Versuch, die Technologie neu zu strukturieren, schlägt fehl.
quelle
Hören Sie sich die dieswöchige Ausgabe des Floss Weekly- Podcasts an, der sich mit SOA befasst. Die Beschreibungen sind ziemlich umfangreich und befassen sich nicht mit zu vielen technischen Details (obwohl konkretere und erkennbarere Beispiele für SOA-Projekte hilfreich gewesen wären.
quelle
Eine traditionelle Anwendungsarchitektur ist:
Wenn Sie programmgesteuert auf die Daten zugreifen möchten, müssen Sie möglicherweise auf Screen-Scraping zurückgreifen.
SOA scheint mir eine Architektur zu sein, die sich darauf konzentriert, maschinenlesbare Daten und / oder APIs bereitzustellen, anstatt Benutzeroberflächen bereitzustellen.
quelle
SOA oder serviceorientierte Architektur ist ein Softwarearchitekturmuster, bei dem Anwendungen oder Systeme aus zugrunde liegenden (und normalerweise verteilten) Softwarediensten erstellt werden, die einem bestimmten Satz von Merkmalen entsprechen, nämlich:
Das Hauptziel von SOA ist die Agilität der Softwareentwicklung, dh die Fähigkeit, auf Änderungen einfach und kostengünstig zu reagieren, sodass Unternehmen schnell auf sich ändernde Märkte reagieren können.
Dienste werden normalerweise (aber keineswegs ausschließlich) als Webdienste implementiert, dh sie arbeiten über das allgegenwärtige Web-HTTP-Protokoll und werden entweder mithilfe von XML-basiertem SOAP oder dem leichtgewichtigen (und populäreren) REST-Paradigma implementiert.
quelle
Kommt darauf an wer du bist!
Wenn Sie ein Geschäftsinhaber sind, ist SOA eine Lösung, um Ihr Einkommen und Ihre Geschäftsagilität zu steigern. Wenn Sie ein unternehmerischer Architekt sind, ist SOA eine Möglichkeit, eine schöne und saubere Software auf eine leere Leinwand zu zeichnen. Wenn Sie ein Architekt sind, ist SOA die Lösung, um lose gekoppelte Dienste über eine Integrationsplattform zu entwerfen und Dienste einfach an Steckdosen anzuschließen. Wenn Sie ein Entwickler sind, ist SOA ein Programmierparadigma, bei dem ein Service im Mittelpunkt des Designs und des Codes steht.
Sie sollten 100-SOA-Fragen lesen [pdf]
Prost
quelle
Service Oriented Architecture (SOA) ist ein Software-Architekturstil, mit dem Anwendungen als Sammlung steckbarer Teile erstellt werden, die jeweils von anderen Anwendungen wiederverwendet werden können.
quelle