Kennen Sie Paul Watzlawicks kleinen Band “Anleitung zum Unglücklichsein”? Er bricht rigoros mit der Vorstellung, das Ziel des Menschen sei das Streben nach Glück. Dazu analog eine “Anleitung zum Unglücklichsein mit Services”.
Der Weg zum unglücklichen Servicedesign
Das Sommerloch hat zugeschlagen – auch in unserem Weblog – nun denn – in den letzten Wochen haben wir neben den verschiedenen laufenden Projekten auch mit den Partnern bei unseren Kunden das Thema Ausbildung im Bereich Servicedesign und -schnitt besprochen. Ziel ist es den Mitarbeitern dort ein besseres Verständnis und insbesondere Gefühl für ein gutes Design von Services in deren SOA zu geben. Dazu passt ein guter Blogeintrag von Eric Roch über Reducing Service Complexity, den ich gestern gelesen habe. Dort beschreibt er den Fokus auf die einzelnen Domains zu setzten. Dies hat sich definitiv in unseren Projekten – in großen wie auch kleinen Umgebungen – immer wieder als sehr hilfreich ergeben. Zudem passt dies einerseits im Bereich von Business Services und andererseits auf der Ebene der notwendigen Composite Mediationsservices. Ein Aufteilung orientiert an den Domains hilft auch beim Aufbau der Service Registry (oder Registries im Fall von federated ESBs).
Diese Fauxpas gilt es zu vermeiden
Erich Roch listet am Ende einige “stupid things” – Also auf zu unglücklichem Service Design.
- Erzeugen Sie CRUD Services – Create, Update, Read, Delete für jeden Datenbankservice!
- Schaffen Sie ein Paket von Utiliy Service statt Business Services
- Statt einer zentralen Verwaltung der Services sollten Sie die gleichen oder sehr ähnlichen Dienste immer wieder neu erzeugen – Wer braucht denn Governance?
- Gut ist auch eine ausgefeilte Infrastruktur, um tausend Services zu bedienen, wenn Sie nur zwei haben
Diese Punkte kennen wir aus verschiedenen Umgebungen, welche wir analysieren sollten, da die Unternehmen einfach zu zufrieden mit Ihren Lösungen waren. Dazu ergänzend einige weitere:
- Baue eine SOA nur auf BPEL Prozessen und einem Process Server als Ablaufumgebung auf und nutze keine Mediationsschicht
- Wenn schon ein ESB im Einsatz ist, verwende nur die Basis Mediationen und baue keine Composite Mediationsdienste, sondern realisiere dies als Prozessflow.
- Bei der Nutzung von verteilten ESBs und entsprechenden Architekturen nutzen Sie nur eine Registry/Repository, statt für jede Domain ein eigenes und kein Metaregistry für die Zusammenfassung der Domainregistries
- Und anknüpfend an Erics letzten Punkt: Bauen Sie eine Architektur mit hunderten von Diensten auf einer Infrastruktur auf, welche nur für zwei ausgelegt ist.
Verwendete Produkte:
Autor
Wolfgang Schmidt