Serviceorientierte Architektur (SOA)

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. Herrn 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”.

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Email this to someone
War dieser Artikel hilfreich?
TUP - Redaktion (http://www.tup.com)
Die Redaktion der DR. THOMAS + PARTNER GmbH & Co. KG aus Karlsruhe hat die Plattform Logistik KNOWHOW ins Leben gerufen, administriert und koordiniert die Beiträge und erstellt selbst Inhalte zu verschiedenen Kategorien. Das Familienunternehmen DR. THOMAS + PARTNER realisiert seit über 30 Jahren modulare Intralogistik-IT-Systeme für nationale und internationale Unternehmen unterschiedlicher Größe und Branche.

2 Kommentare

Kritisch angemerkt sein, dass der Hype um SOA sich schon deutlich abgeschwächt hat und dass nicht wenige IT-affine Meschen behaupten, dass SOA als Konzept gänzlich gescheitert sei.

 

Hallo Frau Müller,
Da gebe ich Ihnen zum Teil natürlich Recht. Speziell der Aufwand der Planung sowie der Umsetzung der SOA erschwert es Unternehmen zunehmend, die Grundidee der SOA überhaupt anzupacken. In den meisten Fällen werden lediglich Teile dieser Idee mit berücksichtigt und in den jeweiligen Projekten implementiert. Es kostet schlicht zu viel Geld. Zur Info: Ich bin Mitglied der LKH-Redaktion.

 

Kommentar

Dies ist eine Pflichtangabe*