nicht angemeldet
Moin!
ich muss für die Vorlesung "Verteilte Systeme" verstehen was Service orientierte Architektur ist, tue mir da etwas schwer. Von daher hab ich mal das in meinen Worten aufgeschrieben. Könnte das jemand bitte verifizieren?
Die Recherche nach SOA bringt einen selbstverständlich erstmal zur Wikipedia: http://de.wikipedia.org/wiki/Serviceorientierte_Architektur
Allerdings: Wenn man sich den Artikel laut vorlesen lassen würde, würde man man mit Sicherheit jedes Bullshit-Bingo gewinnen. Das mache ich vor allem daran fest, dass es für SOA offenbar nur sehr schwammige Definitionen gibt - und dass im Wikipedia-Artikel als Beispiel und Erklärhilfe Realwelt-Beispiele verwendet werden, die mir schon bei der Erklärung der OOP nicht sehr gefallen. Realwelt-Beispiele wie "Ein Auto-Objekt hat eine Eigenschaft AnzahlReifen und eine Methode MotorStarten" greifen einfach zu kurz, um deutlicher zu machen, worum es bei der Abstraktion der OOP geht. Man hantiert, selbst in einer Applikation für Autohändler, nicht mit solchen Realwelt-Objekten, sondern verläßt die Ebene der elektronischen Daten eben gerade nicht.
Dasselbe Problem hat IMO die Erklärung von SOA in der Wikipedia. Aber wenigstens gibts dort weiterführende Links, und die Nummer 2 scheint mir deutlich brauchbarer, auch deshalb, weil sie von Anfang an viel selbstkritischer ist:
"Was ist SOA? (zurück)
Eine breit akzeptierte Antwort auf diese Frage gibt es nicht. Je nachdem, ob eine technische oder eine wirtschaftliche Sicht im Vordergrund steht, finden sich unterschiedliche Definitionen."
Dort im Blog trifft man auch auf Artikel wie diesen: Platzt die SOA-Blase?. Dem Blogartikel und auch den Kommentaren ist eindeutig zu entnehmen, dass das Schlagwort SOA eindeutig eine sehr hohe Hype-Komponente hat.
Wie schön, dass es auch dazu Erklärungsmodelle bzw. übergreifende Beobachtungen gibt: Den Hype-Zyklus (schöne Grafiken hier). Wenn ich sowohl die Erklärungsversuche, was SOA sein soll, als auch den Blasenartikel, zusammenfasse, dann dürfte SOA sich vermutlich gerade aus dem Tal der Enttäuschung herausarbeiten. Was wiederum bedeutet, dass sich aus der Vergangenheit eine überquellende Vielzahl von Erwartungen, Hoffnungen und sogar unrealistischen Phantasien angesammelt hat, was SOA denn alles sein soll und können kann, die zum heutigen Zeitpunkt noch nicht alle durchsortiert und auf Realismus geprüft wurden.
Soll heißen: Es gibt sicherlich realistische, durch die ersten enttäuschten Erfahrungen geläuterte Erkenntnisse, was SOA ist - aber genauso gibt es vor allem aus älteren Quellen noch ganz viel, was rückblickend einfach nur als Unsinn bezeichnet werden muss.
Sollte ich es definieren, würde ich es so versuchen:
Service-orientierte Architektur ist eine Herangehensweise zur Lösung von unternehmensweiten Softwareproblemen, die auf zwei Ebenen ansetzt:
1. Die globale Sicht: SOA erfordert das Isolieren und Unabhängigmachen von einzelnen Geschäftsprozessen. Damit das erfolgen kann, müssen alle Organisationseinheiten des Unternehmens, die Nutzer und/oder Anbieter solcher Services sein wollen, ihre Denkweise auf diese Struktur umstellen, nämlich dass ein erfolgreiches Unternehmen nur durch erfolgreiche Abwicklung von Geschäftsprozessen entsteht, diese Geschäftsprozesse sich aus erfolgreicher Abwicklung von jeweiligen Einzelschritten zusammensetzen, und dass die einzelnen Organisationseinheiten für ihren Teil dieser Einzelschritte verantwortlich sind, dies aber nur dann erfolgreich funktioniert, wenn über die gemeinsam definierte Schnittstelle der SOA eine erfolgreiche Zusammenarbeit mit anderen Organisationseinheiten erfolgt.
Es ist also eine unternehmensweite Umstellung der Denkweise erforderlich, damit SOA überhaupt funktionieren kann.
2. Die Implementierungssicht: Die technische Umsetzung von SOA zielt natürlich darauf, dass einheitliche Schnittstellen im Netz publiziert und genutzt werden, und dass ggf. auch Services intern komplett umgebaut werden können, weil sich die dahinter liegende Struktur ändern soll - dies aber keine Auswirkungen auf die Nutzung bzw. das Interface hat. Darüber hinaus ist SOA allerdings höchst schwammig definiert, wie das bei Paradigmen nun mal so ist: Implementierungsdetails werden dem Leser als Übungsaufgabe überlassen.
Im Prinzip könnte man auf dieser technischen Ebene SOA auch als "OOP via Netzwerkkommunikation" definieren. Und vermutlich läuft es bei der konkreten Realisierung auch genau darauf hinaus, dass man sich mit OOP das Serviceinterface und die dahinterliegende Logik zusammenbastelt, und eventuell seinerseits als SOA-Nutzer andere Services nutzt - genauso wie man in OOP eine Klasse schreiben würde, die ein Interface anbietet, und intern auch wieder andere Klassen eingebunden sind, die von woanders her stammen. Der Vorteil von SOA zu OOP wäre halt, dass durch das Service-Interface eine zusätzliche Abstraktion bzw. Trennung hinzukommt, die es ermöglicht, Services räumlich, zeitlich und implementierungsmäßig zu trennen. Nicht jeder Service muss in der gleichen Sprache geschrieben sein und auf dem gleichen Server bzw. am gleichen Standort stehen, und eventuell auch nicht sofort reagieren.
Ich erwarte selbstverständlich Widerspruch für meine obigen Ausführungen, denn ich gebe gerne zu, dass ich von der Materie, außer durch Lektüre der verlinkten Artikel, eigentlich keine Ahnung habe - noch nicht. :)
- Sven Rautenberg
"Love your nation - respect the others."