In diesem Artikel beschreibe ich den Nutzen von Serviceorientierter Architektur, das Vorgehen bei der Einführung und die grundlegenden Fragen bei der technischen Umsetzung. Hier werden allgemeine Tipps und Ansätze skizziert.

 

 

SOA bedeutet serviceorientierte Architektur und ist damit ein architektonischer Gegensatz zu Monolithischen Systemen.

Nutzen von SOA

Höhere Flexibilität

Eine IT-Systemarchitektur, die aus Services (meinst Webservices) aufgebaut ist, kann schneller und gefahrloser geändert werden, da die anzupassenden Funktionen in den Services gekapselt sind. Die Auswirkungen von Änderungen sind dadurch beschränkt.

Kosteneinsparung durch

Sofern bestimmte Services schon vorliegen, verkürzt sich die Entwicklungszeiten bei neuen Produkten sehr stark, da sich der Aufwand der Neuprogrammierung reduziert (Aufsetzen auf Bestehendem). Die kürzeren Entwicklungszeiten führen zu einer Kosteneinsparung.

Weiterhin ist eine schnellere Anpassung von bestehenden Produkten möglich, da ggf. nur die Webservices an zentraler Stelle (für alle angeschlossenen IT-Systeme) geändert werden müssen. Der Ort der Anpassung kann zudem schneller gefunden werden, da die Auslagerung in Services zu mehr Übersichtlichkeit in der IT-Architektur führt.

Auch eine Wiederverwendung ist möglich. Hier sollte jedoch überlegt vorgegangen werden, da eine Wiederverwendung nicht immer sinnvoll ist.

Was ist bei der Einführung zu beachten?

Die Einführung von SOA muss mit Bedacht durchgeführt werden. Es muss der Rahmen der SOA-Einführung genau eingegrenzt werden und man sollte schrittweise planen. Ein SOA-Kompentenzteam, welches Rückendeckung vom Management hat, sollte eingerichtet werden. Das Changemanagement sollte eingebunden werden. Es sollte ein initialer Mehraufwand eingeplant werden. Die Wiederverwendung sollte pragmatisch gesehen werden.

Die Einführung kann in zwei Varianten erfolgen: entweder Bottom-Up-Vorgehen bzw. Top-Down-Vorgehen.

Buttom-Up-Ansatz

• Anforderungen sind genau bekannt
• Geringes Risiko bei der Realisierung
• Einzelne Funktionen sollen als Webservices wiederverwendet werden

Bei diesem Ansatz sind die Anforderungen genau bekannt. Da nur einzelne Funktionen als Webservice wiederverwendet werden, ist der Resourcenverbrauch gering. Zudem wird das IT-System nicht komplett umgestellt. So ist der operative Betrieb bei Fehlern im System nicht akut gefährdet.

Top-Down-Ansatz

• Existierende IT entspricht nicht den Anforderungen des Unternehmens
• Unternehmensweite Einführung
• Große Herausforderung
• Umsetzung in Teilprojekten –> Motivation für weitere Projekte
• Öffnung und Verbindung nach Außen

Bei dem Top-Down-Ansatz wird SOA im gesamten Unternehmen eingeführt, um die Systeme nach Außen zu öffnen und zu verbinden (B2B). Dies stellt eine große Herausforderung dar, da das Risiko des Scheiterns erheblich höher zu bewerten ist und viel mehr Resourcen angesetzt werden müssen. Eine Umsetzung erfolgt meist in Teilprojekten um den Aufwand aufzuteilen. Positiver Erfolg in den Teilprojekten wird als Motivation für das weitere Vorgehen genommen.

Hinweise zur technischen Umsetzung

Plattform

Es muss die Entscheidung getroffen werden, ob für die SOA-Plattform, dem Enterprise Service Bus (ESB), eine Eigenentwicklung durchgeführt (wenn keine geeigneten Systeme vorhanden sind) wird oder die Plattform eines Technologieanbieters verwendet wird. Grundsätzlich gilt, dass Eigenentwicklungen erstellt werden müssen, dass problemlos zu Software eines Technologieanbieters gewechselt werden kann (Stichpunkt: Erweiterbarkeit, Anpassbarkeit).

Nachrichtenaustausch und Schnittstellen

SOA kann im Rahmen des Webservice-Stack entwickelt werden. Dabei wird WSDL und SOAP angewandt. Eine asynchrone Kommunikation ist z.B. über Java Message Service (JMS) möglich.

Management

Während des Betriebs sollte das operative Management eine Konfiguration und Überwachung der Services problemlos vornehmen können.

Repository

Im Repository werden alle Daten zu den Services hinterlegt, welche so für alle im Unternehmen sichtbar sind. Ein gültiger Standard ist z.B. UDDI.

Funktionen eines SOA-Repositories

Ein Repository in einer SOA-Architektur sollte folgende Funktionalitäten bieten:

• Versionierung
• Veröffentlichungsfunktion
• Freigabeprozess
• Suche
• Hinterlegung von Daten für SLAs

Sicherheit und Zuverlässigkeit

Die über Services ausgetauschten Nachrichten sollten im Falle einer Übertragung per Https (Webservices) zusätzlich verschlüsselt werden, damit eine Übertragung ohne komplette Entschlüsselung zwischen Webservices erfolgen kann. Die Sicherheit wird durch Einhaltung des Webservice-Security-Standard (WSS) gewährleistet.

 

Quellen (ohne Zitate):

„SOA in der Praxis – Wie Unternehmen SOA erfolgreich einsetzen“, Berlecon Research 2006, www.berlecon.de/soa