Erfolgreiches kitEvent zu Serviceorientierten Architekturen
Serviceorientierte Architekturen (SOA) helfen, das für viele Organisationen aufwändige und komplexe Integrationsproblem zu lösen. Christian Bertmann, Senior Executive Accenture GmbH, zeigte beim kitEvent am 18. März 2010 Chancen und Lösungsansätze der SOA auf und blickte optimistisch in die Zukunft.
Christian Bertmann gab dem Publikum aus Informatikern und IT-Spezialisten wertvolle Tipps und Beispiele aus der Praxis.
Nach der Veranstaltung fragte kit e.V zumThema SOA genauer nach:
Was versteht man genau unter Serviceorientierter Architektur (SOA)?
Bertmann: SOA ist ein Architekturstil für die Entwicklung von IT-Systemen. Der Schwerpunkt liegt auf einer effektiven und effizienten Integration zwischen Applikationen. SOA soll die lose Kopplung von Applikationen auf unterschiedlichen Systemplattformen ermöglichen, dadurch Abhängigkeiten reduzieren und größere Flexibilität ermöglichen. Die Integration wird mit Hilfe von Services, Service Bus und einem Service Repository realisiert, die als die wesentlichen Bausteine einer SOA gelten. SOA forciert die Umsetzung von Architekturprinzipien wie Design by Contract, Abstraktion, lose Kopplung, Komposition oder Zustandslosigkeit. Die Etablierung von Standards (WS*) hat dazu geführt, dass sich SOA als Architekturstil zusammen mit den Bausteinen als ein wichtiges Architekturparadigma etabliert hat, vergleichbar mit Client/Server und Web-Architekturen.
Wie hat sich SOA entwickelt?
Bertmann: In fast jeder Organisation der Privatwirtschaft und der öffentlichen Verwaltung finden sich heterogene Systemlandschaften mit Applikationen auf unterschiedlichen Plattformen. Zusätzlich haben die Abgrenzungen zwischen Abteilungen und die relativ eigenständige Führung von Unternehmensbereichen dazu geführt, dass IT-Systeme sowohl in ihrer Funktionalität als auch den verarbeiteten Daten Redundanzen aufweisen. Hinzu kommt der Trend zur Globalisierung und Vernetzung von Organisationen untereinander. Damit steigt zum einen der Bedarf, unterschiedliche Verfahren miteinander effektiv und effizient zu verbinden. Zum anderen möchte man Redundanzen abbauen, indem Funktionalität und Datenhaltung so realisiert werden, dass sie anderen Bereichen angeboten und mehrfach wieder verwendet werden können. SOA liefert für diese Problemstellungen sinnvolle Konzepte und einheitliche Standards. Der Markt liefert dazu die passenden Produkte. Aufbauend auf diesen Grundelementen einer SOA können Mehrwertdienste entwickelt werden, die die Orchestrierung von Services und die Überwachung der Geschäftsaktivitäten anhand der über den Service Bus laufenden Kommunikation ermöglichen.
Was verstehen Sie unter Orchestrierung?
Bertmann: Ein Service stellt eine Funktionalität und/oder Daten auf einem Abstraktionsgrad zur Verfügung, der eine Relevanz für das Geschäft hat. Das Niveau ist also wesentlich höher als man es von typischen Schnittstellen zwischen Systemen auf API-Ebene kennt. Ein Beispiel wäre die Registrierung eines neuen Kunden oder die Erstellung eines Angebots für einen Versicherungsantrag. Sobald in einer Organisation eine Reihe von Services mit diesem Abstraktionsgrad zur Verfügung stehen, können diese sinnvoll in unterschiedlichen Prozessen nacheinander genutzt werden. Die Steuerung des Ablaufs in Abhängigkeit der Ergebnisse, die die Services liefern, liegt in einer separaten Anwendung: einer „Prozessengine“. Die Prozessengine orchestriert das Zusammenspiel der Services, also den Ablauf der Aufrufe in einem Prozessfluss.
Welche Vorteile hat der Kunde durch SOA?
Bertmann: SOA hilft, das Integrationsproblem zu lösen: Durch Konzepte und auf dem Markt verfügbare Produkte. Dort, wo wieder verwendbare Services realisiert werden können, vereinfacht SOA die Bereitstellung und Nutzung der Services. Mit Hilfe der Orchestrierung von Services über eine Prozessengine können Änderungen in den Prozessabläufen schneller umgesetzt werden als bei einer Abbildung in einer klassischen Anwendungsarchitektur, die oft Prozesslogik mit Logik auf niedrigerem Abstraktionsniveau vermischt. Die meisten Organisationen werden zum heutigen Zeitpunkt den Nutzen im Bereich der Integration erfahren. Erst wenn ausreichend Services mit Wiederverwendungspotenzial verfügbar sind und Geschäftsprozesse umfassend in IT-Verfahren abgebildet werden, können die anderen Vorteile genutzt werden. Dies wird aber in der Regel nicht in der gesamten Breite der Organisation möglich sein, sondern zunächst nur dort, wo die passenden Rahmenbedingungen bestehen und zum Beispiel schnelle Änderungen der Prozesse überhaupt erforderlich sind.
Gibt es besondere Anforderungen an SOA?
Bertmann: Wie für jedes Werkzeug muss man auch für die Verwendung von SOA das passende Einsatzgebiet wählen. Es macht zum Beispiel keinen Sinn, eine Applikation, die zielgerichtet und abgeschlossen für eine begrenzte Benutzergruppe entwickelt wird, mit Services, ESB und Repository zu „überfrachten“, wenn gar kein Bedarf für die Wiederverwendung in anderen Bereichen besteht. Auch muss einem klar sein, dass mit SOA zusätzliche Architekturschichten und Infrastrukturebenen eingeführt werden, die sowohl die Performance des Gesamtsystems reduzieren als auch neue Anforderungen an Entwicklung und den Betrieb stellen.
Es muss also ein sehr guter Architekt gefunden werden, der mit den neuen Werkzeugen sinnvoll umgehen kann, um ein gutes Gebäude zu entwickeln. Unter dem Begriff der SOA Governance wird dieser Aspekt sowie die strategische Ausrichtung der SOA von den ersten Erfahrungen bis hin zum breiten Einsatz adressiert. Was mit einer SOA erreicht werden soll und im gegebenen Umfeld auch erreicht werden kann, sollte vor wichtigen Entscheidungen hinsichtlich der Vorgehensweise und möglichen Investitionen ausreichend geklärt werden. Zum Beispiel in einem Architekturboard, das mit Verantwortlichen der Geschäfts- und IT-Seite besetzt ist.
Wie sieht die zukünftige Entwicklung von SOA aus?
Bertmann: SOA wird aus meiner Sicht in Verbindung mit anderen aktuellen Architekturstilen eine Rolle bei der Realisierung von Verfahren spielen, die eine umfassende Anzahl von Geschäftsfunktionen vielen Benutzern zur Verfügung stellen und dabei mehrere Systeme miteinander integrieren müssen. Zum anderen werden immer mehr Hersteller ihre Produkte so erweitern, dass diese „SOA-ready“ sind. Wo früher der Zugriff auf Funktionalität einer Anwendung über low-level APIs möglich war, werden zukünftig Services angeboten. Auch ist es denkbar, dass große SW-Lösungen eben nicht mehr als Monolithen realisiert werden, sondern eine Aufteilung in Applikationen, die Services bereit stellen, die Infrastruktur zu Kommunikation, eine Prozessengine und ein Portal zur Nutzung der Services sowie eine Komponente zum Monitoring der Geschäftsaktivitäten. Drittens ist sicher die wachsende Anzahl von Services zu sehen, die im Internet verfügbar sind und als Mehrwert in eigene Lösungen integriert werden oder sogar als Ersatz für selbst entwickelte oder gekaufte Funktionen genutzt werden können.
Quelle: www.kit-network.de