Process Engine, Service Bus, Event Bus: allesamt Möglichkeiten, die starre Kopplung von Services und Softwarekomponenten aufzulösen und diese lose miteinander zu koppeln. Ist nicht neu und der Anstrich „rocket science“ blättert auch. Trotzdem rangiert dieses Antipattern nicht nur in der Kategorie „famous classics“. Denn immer noch (oder wieder?) finden wir in der Praxis diese eng miteinander verwobenen Services, die nicht nur einander aufrufen, sondern auch noch jeder für sich ein tosendes Potpourri von Fach- und Ablauflogik darstellen. Ja, „historisch gewachsen“, is klar. Tatsächlich entstehen die Dinger aber immer noch neu. Aber was heißt das in Konsequenz für die System- bzw. Servicelandschaft?
Wiederverwendbarkeit und Wiederverwendung von Services
Einer der Eckpfeiler des Servicegedankens in der Software ist das Thema Wiederverwendung. Diese kann natürlicherweise nur dann stattfinden, wenn ein Service überhaupt wiederverwendbar ist. Dazu zählt ein sinnvoller Servicekontrakt (aka Schnittstelle und Beschreibung) aber auch ein auf Wiederverwendung ausgelegter Serviceschnitt. „Weiß“ nun aber ein Service A, dass im Gesamtablauf Service B folgt und A ruft diesen sogar selbst auf, schmälert das sofort die Wiederverwendbarkeit. Die Verwendung von A ohne B als direkten Nachfolger geht so nicht.
Das hier verletzte Prinzip schimpft sich „separation of concerns“, also die Trennung von Verantwortlichkeiten – in diesem Fall Fachlogik und Ablauflogik. Flexible und vor allem schnelle Anpassung von Abläufen und Kontexten, wo sich die Ablauflogik nicht nur eng an die Fachlogik schmiegt, sondern so richtig schön damit verwoben ist – ein Traum.
Refactoring in der Abhängigkeitshölle
Genauso lustig wird es, wenn es an bestehenden Services und deren Schnittstellen Refactorings gibt. Nicht nur, dass man dann jeden einzelnen Klienten anpassen muss, man muss diese zunächst mal identifizieren. Was dann folgt, ist irgendwas zwischen Forensik und Archäologie – der Abenteurer frohlockt.
Enge Kopplung und Deployment
Enge Kopplung heißt ja auch, dass die Services viel voneinander wissen und sich sehr aufeinander verlassen. Was liegt da näher, als sie gleich in einer großen Deloyment-Einheit zusammenzuwerfen? Und ehe man sich versieht, kommt man bei unternehmensweiten Releasezyklen von 4 Monaten raus. Bingo – sorry, ich meinte BOING. Ziemlich 80er.
Nachvollziehbarkeit
Ein nicht zu vernachlässigender Vorteil des Einsatzes von ESBs und vor allem Process Engines ist die Nachvollziehbarkeit der Abläufe. Gerade Prozessmodelle in BPMN haben sich mittlerweile als sehr hilfreich erwiesen, um in der Anforderungsermittlung und -beschreibung schneller zu besseren Lösungen zu kommen. Und darüber hinaus bieten diese Komponenten als Laufzeitumgebung auch noch einen sehr hilfreichen Blick in den Maschinenraum. Es ist jederzeit nachvollziehbar, wo ein bestimmter Geschäftsvorfall gerade steht oder wie viele Prozessinstanzen just auf die Bearbeitung eines bestimmten Schrittes warten. Bei einer bunten Sammlung von Services, die die Abläufe irgendwie selber regeln, ist dies deutlich schwieriger, aufwändiger und teurer.
Eulen, Athen und so…
Logisch, das sind alles keine neuen Erkenntnisse, und ihr wisst das (eigentlich) alles selber. Daher ist die Anregung, die oben genannten Aspekte im Auge zu behalten und zumindest für neu entstehende Services, Prozesse und sonstige Komponenten zu beachten auch eher als Wunsch und Plädoyer gemeint denn als Fazit.
