SOA richtig verstehen und verwenden

Bisherige IT-Landschaften sind von verschiedenen Anwendungen geprägt, die viel Wissen über einen speziellen Bereich des Unternehmens enthalten. Selbst wenn diese Anwendungen sauber aufgebaut sein sollten, ist es meistens schwierig, Teile der Anwendungen für andere Zwecke einzusetzen. Das liegt daran, dass kaum ein Projekt ohne massiven Druck von außen wiederverwendbare Komponenten für andere Projekte entwickeln wird. Die Entwicklung solcher Komponenten ist aufwendig und schwer planbar. Solche Komponenten sind daher nicht im Interesse eines Teams, sein Projekt zeitgerecht fertig zu stellen. Im Gegenteil: Nicht selten entwerfen die Entwicklungsteams einzelne Teile ihrer Anwendungen so, dass eine Wiederverwendung sogar innerhalb der eigenen Anwendung schwierig ist. Die Folge dieser Fehlentwicklung: Es entstehen Anwendungslandschaften mit vielen Redundanzen. Die Wartung ist solcher Anwendungen ist aufwendig, Änderungen und Neuentwicklungen oftmals sehr ineffizient.

Ende des Burgendenkens

Serviceorientierte Architekturen sind angetreten, dieses "Burgendenken" zu beenden. Eine serviceorientierte Architektur legt hierzu die verborgenen Funktionen innerhalb der Anwendungen bloß und versucht, sie für alle Anwendungen zu öffnen. Das wichtigste Rezept hierzu ist eigentlich sehr einfach und altbekannt: Die Anwendungen werden in wiederverwendbare Services aufgeteilt, zu denen öffentliche Schnittstellen existieren.

Ein Beispiel hierzu: Es besteht die Anforderung an mehrere Anwendungen eines Unternehmens, tabellarische Ansichten in PDF-Dokumente umzuwandeln. Die verschiedenen Anwendungen haben das bisher so gelöst, dass sie einen speziellen Dokumentgenerator innerhalb einer Anwendung implementiert haben. Jedes Team hat hierbei immer wieder die gleiche Probleme lösen müssen. Die historisch gewachsenen Strukturen werden beim Wechsel zu einer serviceorientierten Architektur aufgebrochen: Hier tritt an die Stelle der verschiedenen internen Dokumentgeneratoren ein singulärer Service, der für alle Anwendungen Dokumente an einer zentralen Stelle zeugen kann (siehe Bild).

Die speziellen Dokumentgeneratoren der verschiedenen Anwendungen waren maßgeschneidert auf die Anwendungsfälle und Dokumentvorlagen, die die Anwendungen benötigten. Mit der Implementierung eines zentralen Services ist der Anspruch an diesen generischen Dokumentgenerator sehr viel höher. Durch die höhere Last im Vergleich zur Einzelanwendung muss er über eine sehr robuste Implementierung verfügen. Dadurch, dass die Last viel höher ist, muss er zudem skalierbar sein. Der Service muss außerdem alle Anwendungsfälle der verschiedenen Clients abdecken, damit er seine Aufgabe erfüllen kann. Durch die Vielzahl der Anforderungen ist das Design einer öffentlichen Schnittstelle schwieriger als bei einer speziellen Implementierung für nur eine Anwendung.