Serviceorientierte Architektur (SOA)

Durch die serviceorientierte Architektur, Service-Oriented Architecture (engl) – kurz SOA, ist die Programmlogik (Ablauforganisation/Rechenschritte einer Software) nicht mehr Bestandteil einzelner Software; vielmehr werden ihre verknüpften fachlichen Dienste (etwa Webservices, Speicher, Schnittstellen) und die spezifischen Funktionalitäten der Software selbst allgemein zur Verfügung gestellt; jede dieser Funktionen ist dabei separat im Netzwerk nutzbar. Es werden dabei ausschließlich Prozesse betrachtet, die über verschiedene Programme realisiert werden. Einzelne und in sich agierende Applikationen sind nicht Bestandteil des SOA-Gedankens.

Serviceorientierte Architektur (SOA) ist eine Anwendungsarchitektur, in der alle Funktionen als unabhängige Services mit wohldefinierten, aufrufbaren Schnittstellen vorliegen, so dass eine Auswahl – in einer sinnvollen Reihenfolge aufgerufen – einen Geschäftsprozess abdeckt.

Dr. Ulf Rerrer-Brusch (2007)

Die serviceorientierte Architektur minimiert also Abhängigkeiten einzelner Elemente innerhalb einer Software. Die entsprechenden Elemente werden gleich zu Beginn so entwickelt, dass sie als eigenständige Dienste eingesetzt werden können. Dabei stellt jeder dieser Dienste allerdings auch bestimmte Anforderungen für seine reibungslose Nutzung. Werden die unten aufgeführten Richtlinien erfüllt, ermöglicht die Flexibilität des jeweiligen Dienstes, dass die unterschiedlichen Services sich leicht miteinander kombinieren lassen und sich mittels Baukastensystem und einigen Anpassungen sogar völlig neue Systeme entwickeln können. Die zugrundeliegende IT-Architektur fungiert folglich als Informationsplattform, auf der der jeweilige Prozess abgewickelt wird.

Serviceorientierte Architektur in der Praxis

SOA definiert, wie zwei Recheninstanzen/Programme interagieren, sodass eine Instanz eine Arbeitsleistung im Auftrag einer anderen Instanz ausführt. Dabei werden die Serviceinteraktionen durch eine oder mehrere Beschreibungssprachen definiert. Jede Interaktion ist grundsätzlich in sich geschlossen, aber von Prozessen abgekoppelt. Sie ist von anderen Interaktionen somit unabhängig. Das Baukastenprinzip erlaubt einen leichten Zugriff und zügige Modulation, weil es im Prinzip wie eine Art Lego-Stecksystem funktioniert. Eine durchgehende Standardisierung von Schnittstellen, beispielsweise in Verbindung mit XML oder JSON (einheitliche textbasierte Datenformate), sorgt für die zwingend erforderliche Interoperabilität (flüssige Zusammenarbeit der Dienste).

Anforderungen:

• Dienste sind in sich abgeschlossen
• Dienste sind eigenständig nutzbar
• Dienste sind in einem Netzwerk verfügbar
• Dienste müssen eine standardisierte Schnittstelle haben
• Dienste sind Pattform-unabhängig (unterschiedliche Betriebssysteme, unterschiedliche Programm-Sprachen, unterschiedliche Webservices – Java/HTML, PHP usw.)
• Dienste müssen in einem Verzeichnis registriert sein
• Dienste werden erst dynamisch bei der Ausführung verknüpft

Vorteile:

• Wiederverwertung älterer Services
• Software-Upgrades verbessern gleich mehrere Prozesse
• Modifikationen werden zentralisiert
• Unternehmen sparen Geld und Zeit bei der Entwicklung

Weitere Informationen zu Softwarearchitektur finden Sie unter „Die Bedeutung des Begriffes „Architektur“ im Zusammenhang mit Informationssystemen“.