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)