it-swarm.com.de

Was ist SOA (Serviceorientierte Architektur)?

Nennen Sie mich einen Troll, wenn Sie möchten, aber ich meine es ernst: Wie genau unterscheidet sich der neue SOA - Trend von der Client-Service-Architektur, die ich vor 15 Jahren errichtete? Ich höre ständig SOA, aber ich sehe nicht, wie es anders ist als das, was wir immer gemacht haben.

Vor zehn Jahren hatte mein Unternehmen mehrere Kunden (in mehreren Sprachen), die mit demselben Dienst gesprochen haben. Es war kein XML (es war ein binäres Protokoll mit dem Namen Microsoft DCOM) und es gab keine automatische Erkennung durch WSDL, aber das ist in Ordnung, da das Lesen der Dokumente genauso einfach war. Unser System war sogar "offen" in dem Sinne, dass wir es genug dokumentiert haben, um es Dritten zu ermöglichen, mit unseren Diensten zu sprechen. Wir waren keine Pioniere - jede andere Firma, die ich vor zehn Jahren kannte, tat dasselbe.

Der einzige Unterschied, den ich zwischen damals und heute sehe, ist, dass es jetzt einen einzigen Dienst im Internet gibt, während vor zehn Jahren jeder Kunde seine eigene Instanz des Dienstes hosten würde. Dies ist jedoch kein Architekturproblem - dort, wo der Service physisch lebt, ist er für jeden, der den Service nutzt, transparent.

Was genau ist SOA also anders als das, was wir seit Jahren machen? Ist SOA nur ein Marketingbegriff, der eine Best Practice darstellt, die vor langer Zeit tatsächlich verbreitet wurde? Oder verpasse ich ein wenig zu SOA, das sich von dem unterscheidet, was wir die ganze Zeit gemacht haben?

55
tavistmorph

Vergessen Sie XML. Vergessen Sie WSDL. SOA ist keine Technologie, die Sie kaufen können, obwohl sie oft auf diese Weise vermarktet wird.

Der eigentliche Punkt von SOA ist alles über IT Organisation . Das Ziel von SOA ist es, zu vermeiden, dass eine große Anzahl von "Anwendungen" mit isolierten Datenpools vorhanden ist, die entweder überhaupt nicht miteinander kommunizieren (und daher häufig Daten duplizieren) oder nur ineffizient sind , fehlerhaft durch Adapter-Layer oder EAI-Systeme.

Für große Unternehmen ist dies ein ernstes Problem - sie haben buchstäblich Hunderte von separaten Apps, die nicht ausreichend integriert sind. Überall gibt es doppelte und inkonsistente Daten, und die Kunden werden dadurch sauer und es geht um echtes Geld, weil die Rechnungsabteilung ständig Rechnungen für eine stornierte Bestellung sendet und der Kundendienstmitarbeiter die Bestellung nicht finden kann, da diese in der Auftragsverfolgung storniert wird System, aber nicht das Abrechnungssystem.

SOA soll dieses Problem lösen, indem jede App von Grund auf so konzipiert wird, dass ihre Services standardisiert und plattformübergreifend veröffentlicht werden, sodass andere Apps auf die Daten zugreifen können und diese nicht duplizieren müssen.

Aus betriebswirtschaftlicher Sicht ist dies sehr wünschenswert. Der Schlagwort-Hype und das Akronym Suppe sind nur Versuche der IT-Unternehmen, von diesem Wunsch Gebrauch zu machen. Unglücklicherweise hat dies (falsch) viele Leute (einschließlich CEOs) dazu gebracht, zu glauben, dass SOA ein Produkt ist, das Sie kaufen können, und wird Ihre IT magisch effizienter machen, ohne zu wissen, dass dies nur der Fall ist, wenn Sie sich auch neu organisieren Ihre gesamte IT (und möglicherweise auch Ihre Geschäftseinheiten) SOA-kompatibel sein.

84

Lassen Sie mich den berühmten Prügeljungen von Integration Hell: Telco verwenden.

In den 90er Jahren waren Handyfirmen in meiner Nachbarschaft sehr beliebt, fast so zahlreich wie die Weiterverkäufer, die durch die Deregulierung der Kommunikation Mitte der 90er Jahre möglich wurden. Nun, die Zeit vergeht, und Bell Atlantic wird zum Kraftpaket von Verizon und verschlingt Gesellschaft für Gesellschaft (und mindestens eine Baby Bell). Jedes einzelne dieser Unternehmen verfügt über Technologien, die in Türmen, in Schaltanlagen, in Abrechnungssystemen vorhanden sind, die VOLLSTÄNDIG miteinander inkompatibel sind.

Also geht das Unternehmen los und sagt: Okay, wir haben diese Modelle für unser Geschäft. Lassen Sie uns ALLES Technologie in Form von WSDL/SOAP/XSD mit einem freundlichen, konsistenten Gesicht versehen - jede Sprache und jedes System, die wir heute haben an dieses angeschlossen werden! Langsam, aber sicher, lässt das Unternehmen alle seine Systeme in der Lage sein, Berichte über Fähigkeiten zu erstellen, zu Last- und Rechnungszwecken abgefragt und zukünftigen Visionären zur Verfügung gestellt werden, um sie auf eine noch nicht abgerechnete Weise auszunutzen.

Jeder kann einen SOA -Client erstellen. Jeder mit wget und einem Texteditor. Und jeder kann die Ergebnisse (XML) analysieren.

Dies unterscheidet sich grundlegend von früheren Client/Server-Architekturen. Ich habe gerade neulich mit jemandem darüber gesprochen, wie man Cobol- und Smalltalk-basierte Systeme mit SOA-Architekturen verbindet. Das ist ein leicht zu lösendes Problem. Sagen Sie mir, Sie können dasselbe für Ihre DCOM-Systeme sagen.

13
Chris K

SOA ist nichts als eine Art Design , bei der die Module über "Dienste" miteinander kommunizieren. Es ist nur das und jetzt ist die nächste Frage: Was ist genau ein "Dienst" und was ist der Unterschied zu einer regulären "Methode"?

Ein Service ist ein Vorgang, der einen einzelnen, atomaren Geschäftsvorgang ausführt. Diese Atomizität macht es hoch wiederverwendbar aus vielen Modulen. Dann ist ein komplexer Geschäftsbetrieb nur das Instrument der Aufforderung, viele dieser Dienste in einer bestimmten Reihenfolge aufzurufen.

SOA hat nichts mit spezifischer Technologie zu tun, sondern ist nur eine bestimmte Art des Designs.

9
edutesoy

Professor Frank Leymann von der Universität Stuttgart nimmt SOA als Schlüsselkonzept für seine Service-Orientierte-Computing (SOC) -Forschungsarbeit, während er über SOA spricht. Man sieht ihn nach der Definition von SOA gefragt, und das folgende Gespräch könnte eine gute Lektüre sein.

Bitte beachten Sie, dass es in unserer Roadmap um "Service Oriented Computing (SoC)" geht, d. H. Um das Berechnungsparadigma der Serviceorientierung. Serviceorientierte Architektur (Service Oriented Architecture, SOA) ist eine architektonische Umsetzung dieses Rechenparadigmas. Sie können dies mit "Client/Server-Computing" als Paradigma und "Browser/Webserver" oder "DB-Client/gespeicherte Prozedur" als zwei (von verschiedenen anderen) Architekturrealisierungen dieses Paradigmas vergleichen.

...

SOA ist nicht völlig neu. Einige Einzelaspekte von SOA werden lange Zeit in der Praxis verwendet. Sehen Sie sich beispielsweise die "lose Kopplung" an: Unternehmen setzen seit Jahrzehnten auf zuverlässige Messaging-Technologie, um Anwendungen zu integrieren, d. H. Um sie lose zu koppeln. Versteht mich nicht falsch, es gibt neue Konzepte in SOA, z. Konzepte, die aus der Kombination von in SOA zusammengestellten Konzepten resultieren, d. h. sie entstehen durch das Auftauchen.

Web-Service-Spezifikationen machen die entsprechenden Technologien plattformübergreifend verfügbar. Das heißt Die entsprechenden Spezifikationen erfinden keine grundlegend neuen Konzepte, sondern definieren, wie diese Konzepte und die entsprechenden Implementierungen in heterogenen Umgebungen funktionieren. Die daraus resultierende Interoperabilität ist bahnbrechend, wodurch SOA real wird.

Zusammenfassend ist SOA eine Mischung aus reifen und neuen aufstrebenden Dingen.

Es gibt auch eine SoC-Papierreferenz vom April 2006.


Eine Google-Suche identifiziert Prof. Frank Leymann und seineWerke .

7
nik
4
Todd Stout

Ich denke, SOA ist sowohl ein Marketingbegriff als auch eine Integration bestehender Lösungen mit der Idee, anstatt die gesamte Software oder Maschine zu verkaufen, verkaufen wir die Dienstleistungen.

2
Mark Serrano

Eine serviceorientierte Architektur entsteht für mich, wenn ein Unternehmen eine Auswahl unterschiedlicher Anwendungen, die eine gemeinsame Domäne betreffen, in eine Reihe interoperabler Dienste integrieren möchte, die mit einer einzigen Datenquelle arbeiten.

Bei einem neuen Startup-Unternehmen mit einer Idee für eine Software/Suite von Software kann ich nicht erkennen, wie ein Unternehmen mit einer serviceorientierten Architektur von vorne anfangen kann. Zunächst sollte jede Lösung (die sich gut zu einem Dienst entwickeln kann, sodass sie interoperabel werden kann), ihren Problemraum isoliert lösen.

Vielleicht wird es in der Roadmap für eine Unternehmensfunktion oder -suite für jede Lösung stehen, ein interoperabler Dienst zu werden, sobald die Lösungen fertiggestellt sind und in Dienst gehen. Zu diesem Zweck werden die Entwicklungsteams möglicherweise einen modularen/komponentenorientierten Ansatz zur Erstellung der Lösung (eventueller Service) verfolgen, um die Integration der Lösung als Service in eine serviceorientierte Architektur zu erleichtern.

In dem Fall, in dem aus vorhandenen Software-Inseln zu interoperablen Diensten in einer serviceorientierten Architektur werden soll, ermöglicht der Ansatz, dass die Softwarekomponenten, die verteilt werden können und in verschiedenen Sprachen geschrieben werden können, über eine offengelegte API und/oder ein gemeinsames Protokoll kommunizieren (zum Beispiel eine Variante von Web-Service) und generisches Datenformat (zum Beispiel XML).

SOA ist ein Ansatz oder eine Idee. Es ist kein Rahmen oder Werkzeug. Wenn WDSLs und EJBs den Namen fallen lassen, wird dies oft vergessen ... und die Idee von SOA ist überhaupt nicht neu.

0
8bitjunkie

Tatsächlich verwendet SOA auch eine Client-Server-Architektur. Darüber hinaus können Sie mit SOA Ihre Software entwerfen. Angenommen, Ihre Anwendung kann in einfache und unabhängige Aufgaben wie das Durchsuchen eines Buches, das Hinzufügen eines neuen Buches, das Empfehlen eines Buches gemäß den Benutzerpräferenzen usw. unterteilt werden. Wenn Sie einen Dienst (eine API) für jede Aufgabe in Betracht ziehen, verwenden Sie tatsächlich SOA. Der Vorteil dieser Architektur ist, dass Sie keine Web-App oder mobile App erstellen, sondern nur die zuvor entwickelten Services (APIs) benötigen.

0
MRazian

Eine serviceorientierte Architektur (SOA) ist ein Architekturmuster, in dem Software als Baustein entworfen wird. d. h. Modulare Entwicklung, die Flexibilität bei der Montage nach Belieben ermöglicht. Wenn Sie ein neues Projekt beginnen möchten, anstatt von vorne zu beginnen, können wir die Dienste wiederverwenden, und wenn Sie einen neuen Service wünschen, können wir den vorhandenen Service problemlos integrieren, um ein neues Projekt zu erstellen. So können wir viel Zeit und Geld sparen. Die Grundprinzipien der serviceorientierten Architektur sind unabhängig von Anbietern, Produkten und Technologien.

Analogie: Spielzeuge bauen mit Lego-Bausteinen.

 Lego toys build using Lego bricks

0
Premraj

In Wirklichkeit ist SOA eine Sammlung genau definierter Dienste. Grundsätzlich verwenden SOA einen lose gekoppelten Dienst, um das gewünschte Ergebnis leicht zu erhalten. Die Implementierungsdetails eines Services sind für den Client/Consumer nicht sichtbar. Änderungen an der Implementierung wirken sich daher nicht auf den Service aus, bis der Vertrag zwischen ihnen geändert wird. Diensteanbieter sind Komponenten, die Geschäftslogik basierend auf vorgegebenen Ein- und Ausgängen ausführen und diese Funktionalität durch eine SOA -Implementierung verfügbar machen. Dies ermöglicht Systemen, die auf SOA basieren, schneller und kostengünstiger für das Unternehmen zu reagieren. Der Hauptunterschied zwischen Komponente und SOA besteht darin, dass SOA eine offene Standardnachricht bereitstellt, die für keine Programmiersprache oder Plattform spezifisch ist. Dadurch können Sie ein hohes Maß an loser Kopplung und Interoperabilität zwischen Plattformen und Technologien erreichen. In einer traditionellen Client-Server-Welt wird der Anbieter ein Server und der Verbraucher ein Client sein. Weitere Informationen zu SOA finden Sie hier: Serviceorientierte Architektur (SOA)

0
Mithun Patra

Die meisten Antworten scheinen zu vermitteln, dass es sich bei SOA (Service Oriented architecture) darum handelt, Anwendungen standardisiert zu erstellen, damit andere Anwendungen plattformunabhängig mit ihr interagieren können.

Ich bin nicht sicher, ob sich die Bedeutung seitdem geändert hat, aber ich hatte die Gelegenheit, mit einem Unternehmen zusammenzuarbeiten, das SOA Suite anbietet, und meine Gedanken dazu sind folgende.

Wenn Sie eine Anwendung entwerfen, können Sie natürlich nicht garantieren, dass sie plattformübergreifend ist. Nehmen Sie zum Beispiel stock Trading systems. Sie verwenden Fix protocol, um Nachrichten zu übertragen. Erwarten Sie jetzt, dass Daten im XML-Format zurückgegeben werden, damit sie als SOA -konform bezeichnet werden können? Definitiv nicht! SOA ist ein architektonischer Ansatz, der Ihnen helfen kann decouple your application/services und sie miteinander interagieren zu lassen. Das Backbone von SOA ist eine ESB (Enterprise Service Bus), mit der Daten von einem Dienst zu einem anderen übertragen werden. SOA Die Architektur sollte Formatkonvertierungen berücksichtigen. Zum Beispiel -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

Diese Konvertierungsmodule werden im Allgemeinen als adapters bezeichnet und sind im Allgemeinen Teil der SOA suite. Für etwas mehr Informationen verweisen wir auf eine andere Antwort -

Unterschied zwischen SOA und ESB

Sicher SOA ist ein Wort, das zu Marketingzwecken gehyped wird. Technisch gesehen ist dies so einfach wie das Deserialisieren und Serialisieren von Daten, so dass Dienste entkoppelt und plattformunabhängig sind, die Idee dahinter ist jedoch konkret.

Beziehen Sie sich auch auf Wiki-Seite für dasselbe.

0
Aniket Thakur