Stirnrunzeln über das Neueste von Microsoft seit geschnitten Brot [OOP 2010]

Grad scheint Microsoft wieder mal “the best thing since sliced bread” erfunden, wie es scheint. Der Reactive Framework (Rx) zaubert jedenfalls einiges breites Grinsen auf Gesichter bei Microsoft, hier der Erfinder des Ganzen, Erik Meijer, in einem Interview über Rx.

(Achtung: Dieses Interview ist auf sehr hohem Abstraktionsniveau! Eine Beschreibung von Rx für Praktiker sucht man hier vergebens.)

Den schätze ich eigentlich sehr, nicht nur für sein früheres “brainchild” Linq. In der letzten Zeit zaubert Erik Meijer aber zumindest mir kein beseeltes Grinsen mehr auf Gesicht, sondern Stirnrunzeln. Da war zuerst das ganz unglückliche Project Volta, welches fundamentalen Erkenntnissen zu verteilten Anwendungen zuwiderlief und jetzt zurecht offline ist. Und jetzt kommt der Reactive Framework.

Was ist der Rx? Das kann man hier und hier recht gut lesen. Ich möchte das jedoch lieber nicht selbst wiedergeben. Denn für mich besteht das Problem darin, dass ich neues Vokabular für etwas Altes benutzen müsste. Meine Kritik am Rx ist: es ist eben keine tolle neue Erfindung seit geschnitten Brot, sondern etwas lange Bekanntes in aufgehübschtes Gewand kleidet.

Mit Rx ist Microsoft aus meiner Sicht nur über Complex Event Processing (CEP) gestolpert. Wenn Erik Meijer die Rx-Interfaces als komplementär zu IEnumerable/IEnumerator ansieht und damit Linq-Queries auf Strömen von Events visioniert, dann ist das nichts anderes als eben CEP: statt auf fixen Daten Queries zu fahren, liest man Ströme von Daten ein und verarbeitet sie mit Queries. Das ist nicht neu, das ist kein Hexenwerk.

Wer wirklich einmal ausprobieren will, was man mit einer Abfragesprache auf Event-Strömen tun kann, der kann mit NEsper spielen: http://esper.codehaus.org/. Das ist (zusammen mit seinem Java-Bruder Esper) ein enterprise ready Open Source CEP Framework. Hier ein kurzes Beispiel für die Ermittlung des Durchschnittspreises “vorbeirauschender” Bestellungen (OrderEvent) innerhalb von jeweils 30-Sekunden-Fenstern.

select avg(price) from org.myapp.event.OrderEvent.win:time(30 sec)

Das ist grundsätzlich nichts anderes tut Rx (s. dazu das Beispiel zur Generierung von Mouse Drag Events hier).

Oder nehmen wir einfach nur Datenflüsse (data flows). Wo ist denn der Unterschied zwischen Rx, das nun wundersamerweise z.B. Mausereignisse als abfragbare Ereignisflüsse sieht? Oder als Flüsse, auf denen man Ereignisbehandlungsroutinen notieren kann. Tut mir leid, da ist nichts neues für mich dabei. Wenn ich im etablierten Paradigma data flow denke, dann ist das etwas uraltes und kann mit heutigen Mitteln bewältigt werden.

Hier ein einfacher Event-Strom mit “Event-Handler”:

new[] {1, 2, 3}.Subscribe(Console.WriteLine);

Der “Event-Handler” braucht nur das altbekannte IEnumerable:

static class EnumExt

{

    public static void Subscribe<T>(this IEnumerable<T> eventStream,
                                    Action<T> handleEvent)

    {

        foreach (T e in eventStream)

            handleEvent(e);

    }

}

Aber damit nicht genug! Man kann auch IEnumerable-Ströme zusammenstecken zu “Pipes and Filters”. Das ist dann ein Flow. Warum nicht aus einer Zahlenliste die ungeraden herausziehen und negieren?

Zahlen –> UngeradeZahl | ZahlNegieren –> Liste der negierten ungerade Zahlen

Die Formulierung in Code ist denkbar einfach:

new[] {1, 2, 3, 4, 5, 6, 7}
    .Where(n => n%2 != 0)
    .Transform(n => -n)
    .Subscribe(Console.WriteLine);

Und wenn noch ein Schritt dazukommen soll – z.B. die Quadratur der ungeraden Zahlen –, dann wird der einfach eingefügt:

new[] {1, 2, 3, 4, 5, 6, 7}
    .Where(n => n%2 != 0)
    .Transform(n => n*n)
    .Transform(n => -n)
    .Subscribe(Console.WriteLine);

Die Transformationsmethode ist straightforward eine Extension Method wie oben Subscribe():

public static IEnumerable<TOut> Transform<TIn, TOut>(
                 this IEnumerable<TIn> eventStream, 
                 Func<TIn, TOut> processEvent)

{

    foreach (TIn e in eventStream)

        yield return processEvent(e);

}

Wer will, kann sowas auch asynchron machen. Das habe ich schon in früheren Blogposts beschrieben:

http://ralfw.blogspot.com/2009/07/ccr-flows-asynchrone-prozesse-mit-der.html
http://ralfw.blogspot.com/2009/07/verstandnisvorteil-fur-flows.html

Flows habe ich aber natürlich nicht erfunden. Die sind alt. Hier eine Quelle, die das Paradigma schon in den 1970ern propagiert hat: http://jpaulmorrison.com/fbp/. Mainstream ist es aber nicht geworden, wie wir sehen. Schade. Denn in die Schritte in einem Flow steigern die Evolvierbarkeit von Software, finde ich.

Jetzt noch die Umsetzung von Mausbewegungen in einen Strom, den man abfragen kann:

public partial class Form1 : Form

{

    private readonly EventStream mouseMovements = new EventStream();

 

    public Form1()

    {

        InitializeComponent();

 

        this.MouseMove += this.mouseMovements;

    }

    …

Eine Klasse EventStream sorgt dafür, die Mausbewegungen (oder auch andere Events) in ein IEnumerable zu transformieren. Das kann man dann z.B. so durchlaufen:

this.mouseMovements.Events<MouseEventArgs>()
    .Where(args => args.X < 100 && args.Y < 100)
    .Subscribe(args => Console.WriteLine("{0}, {1}", args.X, args.Y));

Wie macht EventStream das? Die Windows Message Loop darf ja nicht aufgehalten werden. Es geht nur asynchron. Also rufe ich die Concurrency Coordination Runtime (CCR) zur Hilfe:

class EventStream

{

    public class Event

    {

        public object Sender;

        public EventArgs Args;

    }

 

    private Port<Event> events = new Port<Event>();

 

 

    private void EventListener(object sender, EventArgs args)

    {

        this.events.Post(new Event{Sender = sender, Args=args});

    }

 

 

    public IEnumerable<TEvent> Events<TEvent>() where TEvent : EventArgs

    {

        Event e;

        while (this.events.Test(out e))

            yield return (TEvent)e.Args;

    }

 

 

    public static implicit operator MouseEventHandler(EventStream stream)

    {

        return stream.EventListener;

    }

    …

}

Mit der impliziten Konvertierung kann ich den EventStream einfach an einen Eventhandler für die Mausbewegungen binden, ohne zu verraten, wer intern die Verarbeitung übernimmt.

Der Eventhandler schiebt dann jeden Event in einen CCR Port. Das ist sogar Thread-sicher. Und wenn ich die aufgelaufenen Events prozessieren will, dann hole ich sie mir über Events() als IEnumerable wieder heraus.

Alternativ könnte ich natürlich auch einen Eventhandler registrieren, der life auf neue Events reagiert und sie z.B. in einen asynchronen Flow einspeist. Dann könnte ich in einer Kette von asynchronen Schritten filtern, transformieren, reagieren. Auch da wären Where(), Transform() und Subscribe() wie oben in den synchronen Beispielen möglich.

Wo also ist das entscheidend neue beim Rx? Beats me. Ich kann nur die grübelnd die Stirn runzeln.

Ok, der Rx mag hier und da etwas einfacher machen, weil er schon Abstraktionen bietet, die ich vielleicht erst bauen muss/müsste. Das wäre ne nette Sache – aber deshalb hat Erik Meijer nun nicht gleich “the best thing since sliced bread” erfunden. Er steht nur in einer langen Tradition. Die zu erwähnen und weniger die Flügel zu schlagen, um nicht zuviel Hype-Staub aufzuwirbeln, das fänd ich angemessen.

PS: Oder übersehe ich hier die eigentliche Erfindung? Geht der brilliante Innovationshub an mir vorbei? Ich bitte um Erhellung.