Verteilung auf Teufel komm' raus?

25.08.2009 Permalink

Die Idee ist verführerisch: ein Service, einmal implementiert und in Betrieb genommen, bleibt als kleiner, autonomer Funktionsbaustein der Unternehmens-IT stets zur Verfügung. Er ist durch WSDL (fast) selbstbeschreibend und man kann ihn aus jedem Consumer heraus ansprechen. Künftige Anwendungen bedienen sich dieses Dienstes einfach, und schon verkürzt sich der Zeitraum, mit dem ein Unternehmen seine IT an geänderte Bedürfnisse anpassen kann.

Nicht wenige Anwendungen werden heute mit Begeisterung nach SOA Prinzipien gebaut. Es findet eine Zerlegung in funktionale Komponenten statt, und -- schwupps -- jede Komponente ist ein eigenständiger Service mit einem entsprechenden Kontrakt. Dieses Vorgehen führt zu hochgradig verteilten Systemen. Doch Verteilung erzeugt immer Mehrkosten in Form von Komplexität, Laufzeiteinbußen und wahrscheinlich zusätzlichen Betriebskosten, z.B. durch erforderliche Sicherheitsmaßnahmen, aufwändigere Installation, zusätzliches Monitoring und Application Management (vgl. hierzu Eight Fallacies und Eight Fallacies explained).

Hohe Verteilung

Mit SOA scheinen diese realen Probleme wieder in den Hintergrund zu treten, doch sie sind weiterhin vorhanden. Es ist also gefährlich, ohne klare Kriterien, wie Komponenten verteilt werden sollten, nur nach funktionalen Gesichtspunkten zu entscheiden. Aber wie können solche Kriterien aussehen? Die mir bekannte Literatur zu Software Design und SOA gibt mir keinen ausreichenden Aufschluss, also unternehme ich hier mal einen eigenen Versuch:

Wenn wir in einem groben Design eines neuen Systems nach Prinzipien wie Separation of Concerns mehrere funktionale Komponenten identifiziert haben, wie können wir dann entscheiden, wie wir diese auf verschiedene Teilsysteme verteilen wollen?

Schritt 1:
Dem ersten Reflex folgend ist mein Ausgangspunkt: Verteile nicht! Ich habe in den letzten Jahren mehr Probleme durch unnötige Verteilung kommen als gehen sehen. Damit einer Komponente der ehrwürdige Status eines Dienstes im Sinne einer SOA verliehen wird, muss ihre Autonomie erst begründet werden.

Schritt 2:
Welche Gründe kann es trotzdem für die Eigenständigkeit einer Komponente zur Laufzeit geben?

  1. Die Bedeutung und Lebensdauer der Komponente weicht deutlich von der des zu bauenden Systems ab:
    • Sie existiert längst in Form einer bestehenden Applikation oder eines Service.
    • Sie soll unabhängig von der Entwicklung ausgetauscht oder eigenständig in völlig anderen Zusammenhängen eingesetzt werden.
    • Sie ist für sich so groß und/oder inhaltlich so eigenständig, dass sie als autonomes Teilsystem behandelt werden soll.
  2. Die Komponente ist in nicht-funktionaler Hinsicht besonders:
    • Sie wird an einem anderen Ort laufen (z.B. in einem mobilen oder entfernten Client).
    • Es gelten besondere Anforderungen hinsichtlich Durchsatz, Antwortzeitverhalten, Skalierbarkeit, Verfügbarkeit, Ausfallsicherheit oder Verwaltbarkeit.
    • Sie ist bzgl. technologischer Plattform oder verfügbarer Kommunikationstechnologien besonders.

Schritt 3:
Welche möglichen Umstände je Komponentenpaar sprechen wiederum gegen die Verteilung?

  1. Zwei Komponenten müssen miteinander sehr häufig Daten austauschen.
  2. Zwei Komponenten müssen transaktional zusammenwirken.
  3. Zwei Komponenten pflegen in einem fachlichen Prozess einen gemeinsamen Zustand.

a) und b) "ziehen" Komponenten also in verschiedene Teilsysteme, c) bis e) "drängen" sie wieder zusammen oder veranlassen uns zumindest, über Workarounds nachzudenken.

Ich plädiere also dafür, solche Komponenten in einem Teilsystem zusammenzufassen, denen Fachlichkeit, Lebenszyklus und nicht-funktionale Anforderungen gemeinsam sind. Ein solches funktional und nicht-funktional kohäsives Stück Software kann dann natürlich nach außen verschiedene Servicekontrakte anbieten, d.h. wie verschiedene Services wirken. Innerhalb dieses Teilsystem gelten weiterhin die üblichen Regeln modularen Software Designs.

Geringere Verteilung

Das Design eines verteilten Systems ist also schwieriger, da mehr Gesichtspunkte zu berücksichtigen sind als in nicht verteilten Systemen. Man sollte sich allein deshalb gut überlegen, ob SOA mit allen Konsequenzen das richtige Paradigma für eine neu zu bauende Anwendung ist. Wer glaubt, Verteilung würde die verabscheuungswürdigen "Monolithen" und "Silos" der "alten Welt" in Zukunft verhindern, der wird sich in einer noch unangenehmeren Softwarewelt wiederfinden, in der sich die Probleme unwartbaren Programmcodes mit den Schwierigkeiten verteilter Systeme verbündet haben.