Die Evolution der IT-Architekturen

Die Anfänge der Integration verschiedene Anwendungen in einem Unternehmen reichen zurück zu sehr einfachen Architekturen. Wenn es nur darum geht, wenige Anwendungen zu verbinden, dann funktioniert das natürlich auch ohne komplexe SOA-Produkte. Eine Integration ohne entsprechende Produkte führt meistens zu Peer-to-Peer- oder Client-Server-Architekturen.

Peer-to-Peer-Architekturen

Peer-to-Peer-Architekturen sind der einfachste Weg zur Integration. Anwendungen werden hierbei direkt miteinander verbunden (Siehe Bild: Peer-to-Peer-Architektur). Vorteil des Peer-to-Peer-Verfahrens ist, dass die Integrationsmethode einfach zu erlernen ist. Die Integration liegt vollkommen in der Kontrolle des Entwicklungsteams, das zur Integration spezielle Adapter für andere Systeme entwickeln muss. In der Regel ist hier die Philosophie, dass das Nachbarsystem möglichst nicht verändert wird. Stattdessen liegt im Adapter die gesamte Integrationsarbeit. Ein anderer Weg ist es, dass das Nachbarsystem für die neuen Anforderungen angepasst und danach ein spezieller Adapter geschrieben wird.

Diese Adapter sind der erste gravierende Nachteil dieser Architektur. Dadurch, dass kein Standardverfahren für die Entwicklung solcher Adapter existiert, besteht die Gefahr, dass die Entwicklungsteams sehr spezielle Lösungen programmieren. Zudem müssen diese Lösungen individuell dokumentiert werden. Ihre Funktion ist daher unter Umständen für Außenstehende nur schwer zu verstehen und zu warten. Ein weiterer Nachteil von Peer-to-Peer-Architekturen ist die schlechte Wiederverwendung. Lösungen, die innerhalb der Anwendungen existieren, sind meistens so speziell auf das System zugeschnitten, dass sie anderweitig kaum einsetzbar sind.

Problematisch ist auch, dass mit solchen Architekturen die Gefahr eines Spaghetti-Designs der Unternehmenslandschaft steigt. Ein Wildwuchs von Verbindungen schafft sehr viele Abhängigkeiten. Erfahrungsgemäß sind diese Abhängigkeiten schlecht dokumentiert. Existiert kein Bebauungsplan (siehe Kasten "Glossar"), müssen die Abhängigkeiten durch aufwändige Revisionsprojekte ermittelt werden, um die Risiken zu minimieren. Migrationsprojekte sind in solchen Architekturen wegen der vielen unbekannten Abhängigkeiten aufwendig und teuer. Da man meistens nicht alle Abhängigkeiten feststellen kann, sind solche Projekte zudem riskant. Und nicht zuletzt skalieren solche Architekturen sehr schlecht, weswegen sie meistens durch eine Client-Server-Architektur abgelöst werden.

Glossar

Client-Server-Architekturen

Mit der Einführung einer Client-Server-Architektur werden die beteiligten Systeme aufgebrochen, so dass Services entstehen. Eine Anwendung ist in dieser Architektur üblicherweise zweigeteilt: Vielen identischen Clients steht normalerweise ein Server gegenüber (Siehe Bild "Client-Server-Architektur"). Zwischen dem Clients und dem Server lassen sich Load Balancer zwischenschalten, die Anfragen dorthin leiten, wo die Last am geringsten und eine Antwort daher schnell zu erwarten ist.

Die Vorteile der Client-Server-Architektur sind, dass man die Systeme im Vergleich zu Peer-to-Peer-Lösungen besser skalieren kann. Wird die Last auf den Server durch eine steigende Zahl von Anwendern größer, lassen sich einfach neue Server hinzufügen, ohne die Architektur ändern zu müssen. Unumgänglich sind solche Architekturen natürlich immer dann, wenn man monolithische Fat Clients durch schlanke Rich Clients ersetzen möchte. Mit dieser Architektur lassen sich zudem die Anzahl der Abhängigkeiten reduzieren.

Auch hier stehen den Vorteilen der vergleichsweise einfachen Architektur einige Nachteile gegenüber. Zu nennen wäre etwa der Grad der Wiederverwendung. Dadurch, dass der Server in der Regel speziell für "seine" Client-Landschaft entwickelt wurde, können seine Funktionen meist nicht wiederverwendet werden. Ein weiterer Nachteil sind die aufwendigen Adapter zu nennen, die für die Integration mit weiteren Systemen geschrieben werden müssen. Da das Programmiermodell für solche Adapter nicht durch Standards genormt ist, besteht die Gefahr von sehr speziellen Individualentwicklungen. Zudem ist auch hier oftmals nicht klar, wie viele Abhängigkeiten zu Nachbarsystemen bestehen.

Enterprise Application Integration

Die nächsthöhere Stufe bei der Integration von verschiedenen Produkten nennt sich "Enterprise Application Integration" (EAI). Bei dieser Art der Integration ist ein zentraler Integrations-Server der Mittler zwischen den verschiedenen Systemen. Jedes System muss einen Adapter zu diesem Integrations-Server entwickeln. Die Adapter sind hierbei durch eine Standardschnittstelle des Integrations-Servers im Gegensatz zu den vorher genannten Architekturen relativ einheitlich aufgebaut. Der Ansatz der EAI ist konservativ: Die Produkte, die integriert werden müssen, werden normalerweise nicht angepasst. Das Verfahren bewährt sich daher besonders dort, wo Legacy-Anwendungen eingebunden werden müssen, bei denen Änderungen riskant wären. Ein anderer Anwendungsfall ist die Anbindung von Standardanwendungen wie SAP, die nur mit großem Aufwand angepasst werden könnten. Eine EAI-Architektur verlagert den Integrationsaufwand von der Anpassung einer Anwendung zur Entwicklung eines speziellen Adapters.

Die Nachteile der Enterprise Application Integration sind, dass die Produkte vergleichsweise kompliziert und teuer sind. Dadurch, dass bestehende Systeme in der Regel nicht aufgebrochen werden, zementiert man ihre Defizite. Das für andere Anwendungen wertvolle Know-how dieser Systeme bleibt verborgen. Der Grad der Wiederverwendung ist daher eher gering und die Adapter sind nach wie vor aufwendig zu programmieren. Ein weiterer Nachteil ist, dass sich die Services, die über den Integrations-Server angeboten werden, nicht unbedingt an den Geschäftsprozessen orientieren.

Serviceorientierung

Seit der Einführung von SOAP (Simple Object Access Protocol) haben sich Web-Services in vielen Unternehmen verbreitet. Sie sind vergleichsweise einfach zu programmieren und basieren auf der standardisierten Web Service Definition Language (WSDL) für die Serviceschnittstelle. Die WSDL gliedert eine Schnittstelle in ein definiertes Datenmodell, in Nachrichten und in Protokolle. Die Schnittstellenbeschreibung enthält zudem die Netzwerkadresse, unter der ein Service verfügbar ist. Dadurch, dass die Serviceschnittstellen aufgrund der standardisierten Schnittstellensprache WSDL beschrieben werden, ergeben sich viele Vorteile, zum Beispiel lassen sich Adapter für Service Consumer (Clients) vergleichsweise einfach entwickeln sind. Entsprechende Frameworks können sowohl die Beschreibung der Schnittstelle als auch den Rohbau von Adaptern zu großen Teilen generieren.

Solche Services fördern sehr schnell die Wiederverwendung in einem Unternehmen. Funktionen, die zuvor nur in einer Anwendung vorhanden waren, lassen sich auslagern und somit für andere öffnen.

Ohne eine entsprechende SOA-Infrastruktur besteht hier aber wieder die Gefahr, Peer-to-Peer-Architekturen mit Services aufzubauen. In diesem Fall vernetzen sich die Anwendungen wieder wild untereinander, was zu einer starken Kopplung führt. Die Folge ist, dass Migrationen ähnlich riskant sind, wie zuvor bei Peer-to-Peer-Lösungen. Als man diese Gefahr erkannt hat, hat man versucht, die Vorteile der Enterprise Application Integration mit der Serviceorientierung zu verknüpfen.

Serviceorientierte Architektur

Verbindet man die Vorteile einer Enterprise Application Integration mit Services, entstehen serviceorientierte Architekturen (SOA). Das zentrale Element solcher Architekturen ist natürlich der zustandslose (Web-)Service. Im Gegensatz zur Enterprise Application Integration werden die Anwendungen in einer SOA nicht so belassen, wie sie sind. Im Gegenteil: Das progressive Konzept einer SOA ist, die Anwendungslandschaft so stark zu ändern, dass interne Funktionen der Anwendungen als leicht wiederverwendbare Services offengelegt werden müssen. Das Design der Services muss sich hierbei an den Geschäftsprozessen des Unternehmens orientieren, sonst ist der Fortschritt im Vergleich zum EAI-Konzept eher gering.

Die Anwendungen, die Services zu Verfügung stellen, nennen sich Service Provider oder Serviceanbieter. Die Anwendungen, die Services konsumieren, nennen sich Service Consumer oder Servicekonsumenten. Sie kommunizieren in einer SOA niemals direkt. Um sie zu verbinden, besitzt eine Serviceorientierte Architektur das Konzept des zentralen Enterprise Service Busses (ESB).

Viele Experten sagten bei der Einführung einer SOA, das sei lediglich eine Weiterentwicklung des EAI-Integrationsservers. Und tatsächlich sind die Ähnlichkeiten nicht zu übersehen. Wie bei der Enterprise Application Integration muss sich jeder Servicekonsument, der von den Services innerhalb des Unternehmens profitieren möchte, an diesen ESB über einen Adapter anschließen, um zu anderen Serviceanbietern Kontakt aufzunehmen. Eine direkte Kommunikation analog zu Peer-to-Peer-Architekturen ist in einer SOA der reinen Lehre verboten, weil sie wieder zu einer starken Kopplung zwischen Provider und Consumer führen würde.

Der Umweg über den Enterprise Service Bus schafft Raum für die Eckpfeiler einer serviceorientierten Architektur: Entkopplung von Services, Lastverteilung, Governance und Mediation. Die Entkopplung von Services wird dadurch erreicht, dass der originale Serviceendpunkt, also die Netzwerkadresse des Services nur dem ESB bekannt ist. Dadurch, dass der ESB als Rückgrat der Servicelandschaft fungiert, kann er verschiedene Serviceaufrufe zu unterschiedliche Instanzen der Service-Provider weiterleiten und so die Last verteilen. Er ist in der Lage, die Einhaltung von Service Level Agreements zu überprüfen und Clients durch Mediation von unerwünschten Änderungen des Service-Providers zu schützen.

Wird eine SOA-Suite noch durch eine zum ESB-Konzept passende Entwicklungsumgebung ergänzt, kann das die Produktivität deutlich steigern. Der Entwickler erhält damit eine einheitliche Entwicklungsumgebung für den Zugriff auf alle Bausteine der SOA-Suite. Er kann Web-Services über die SOA-Registry ermitteln, anbinden, eigene Services entwickeln und umgehend wieder in der SOA-Registry publizieren. Er ist in zudem in der Lage, BPM-Prozesse zu designen, mit Web-Services zu verknüpfen, sie danach zu testen und direkt von der Entwicklungsumgebung aus zu verteilen. Eine einheitliche Entwicklungsumgebung kann nicht zuletzt erleichtern, Web-Oberflächen zu entwickeln und mit BPM-Prozessen zu verbinden.

Zusammenfassung

Das Konzept der serviceorientierten Architektur greift das Konzept traditioneller Integrationslösungen auf und kombiniert deren Teile zu einem neuen Ganzen. Nicht für jede Firma ist eine solche komplizierte Infrastruktur angemessen. Für größere Unternehmen kann aber der Wechsel zu einer serviceorientierten Architektur entscheidende Vorteile wie eine höhere Produktivität mit einer besseren Wiederverwendung bringen. (jha)