Vor ungefähr fünf Monaten hat Ralf Westphal in seinem Blog die Frage aufgeworfen, ob nachrichtenorientierte Komponenten den nächsten Schritt der Komponentenorientierung darstellen.

Als entsprechendes Architekturmodell hat die sogenannten Event-Based Components (EBC) vorgestellt: Ein einfaches Komponentenmodell mit einigen kompakten Regeln, dessen wesentliches Merkmal des Einsatz von Events als Kommunikationsmedium an Stelle klassischer Methodenaufrufe ist.

Im Prinzip ähnelt das Konzept der EBCs dem von Chips und Platinen: Ähnlich wie diese können auch EBCs zusammengesteckt werden und größere Komponenten bilden. Der Vorteil des Ganzen liegt in einer ausgesprochen geringen Kopplung – effektiv sind die einzelnen EBCs nicht mehr voneinander, sondern nur noch von gemeinsamen Typen abhängig.

Die funktionale Abhängigkeit ist aufgelöst. Die Vorteile liegen auf der Hand: EBCs sind einfacher zu instanziieren, einfach zu komponieren, einfacher zu isolieren und daher auch einfacher zu testen.

So weit, so gut. Die Frage ist, inwieweit dieses theoretisch interessante Konzept in der Praxis funktioniert.

In den vergangenen Tagen hatte ich die Gelegenheit, einen EBC-basierten Prototypen einer bestehenden Anwendung zu erstellen: Die zu erzielende Funktionalität war also vorgegeben, die einzige Aufgabe war also tatsächlich, das Konzept der EBCs in die Praxis umzusetzen.

Inzwischen ist dieser Prototyp so weit gediehen, dass er die ersten funktionalen Anforderungen der ursprünglichen Anwendung erfüllt. Zeit, im Rahmen einer kleinen Retrospektive zurückzublicken und ein erstes Fazit zu ziehen. Die aus meiner Sicht zwei wesentlichsten Aspekte sind:

• EBCs sind effizient: EBCs ersparen einem die Mühe, eine aufwändige Architektur zu entwickeln – sie implizieren eine kompakte Form. Diese kann in technischer Hinsicht auch leicht umgesetzt werden – auch oder erst recht mit TDD. Die geringe Kopplung wirkt sich hierfür enorm positiv aus. Die Erweiterbarkeit des gesamten Systems ist beeindruckend, und auch die Wart- und Evolvierbarkeit des Codes können sich sehen lassen. Noch mehr als von TDD alleine wird man durch den Einsatz von EBCs mit TDD gezwungen, sich zuvor fundierte Gedanken über das Design der Komponenten zu machen.
• EBCs sind ungewohnt: Der größte Makel von EBCs ist – für mich persönlich – derzeit ihre Andersartigkeit. Sie fühlen sich schlicht und ergreifend ungewohnt an, denn die Kommunikation zwischen den Komponenten folgt nicht mehr dem klassischen und zur Genüge gewohnten Aktion-Reaktion-Schema. Statt dessen modellieren EBCs einen Fluss von Daten durch die Anwendung. Die größte Herausforderung in den vergangenen Tagen war, gedanklich immer wieder zu diesem Fluss-basierten Modell zurückzukehren und sich zu überlegen, wie Funktionalität als Fluss implementiert werden kann.

Natürlich ist der zweite Punkt reine Gewohnheits- und Übungssache. Je öfter man EBCs modelliert, desto leichter gelingt dies. Der Einstieg in EBCs ähnelt daher dem Einstieg in TDD in gewissem Sinne – es ist gar nicht so sehr das rein technische Vorgehen, das kann kompakt und übersichtlich veranschaulicht werden, sondern es sind das fehlende Gefühl für EBCs und die fehlenden Best Practices.

Während das Gefühl nur jeder für sich entwickeln kann, indem er sich mit EBCs beschäftigt und die Arbeit mit ihnen ausprobiert, können Best Practices vermittelt werden – falls diese bereits bekannt sind. Hierzu ist es notwendig, einen Konsens oder zumindest verschiedene, fundierte und argumentativ belegte Meinungen zu finden.

Ralf hat zu EBCs seine Sicht der Dinge – ich habe meine. Aus diesem Grund werde ich in den kommenden Tagen viel über meine Erfahrungen und Erkenntnisse bezüglich EBCs schreiben.

Wenn ich eine andere Meinung vertrete oder EBCs anders nutze als Ralf, werde ich dies begründen – nicht, um Ralfs Position zu schwächen, sondern schlichtweg, um einen zweiten Standpunkt darzulegen.

Vielleicht ergeben sich in der Synergie aus Ralfs Sichtweise, meiner Sichtweise und der Sichtweise von allen anderen Verwendern von EBCs ja Best Practices, die es wert sind, weitergetragen zu werden.

EBCs an sich sind dies allemal wert – sie sind ein großartiges Konzept, das mir sehr gut gefällt. Der langfristige Nutzen wird sich noch beweisen müssen, aber so weit ich EBCs bislang beurteilen kann, sind sie definitiv ein wichtiger Schritt in die richtige Richtung für die moderne Softwareentwicklung.