build broken » Architektur

Asynchrone Kommunikation mit dem Async-Pattern (Refactored)

Thomas Christian — Thu, 06 May 2010 12:37:46 +0000

Nach dem ich meinen vorherigen Artikel zum Thema “Asynchrone Kommunikation mit dem Async-Pattern” vorgestellt hatte, hat Ralf Westphal auf seinem Blog “One Man Think Tank Gedanken” das Vorgehen zur Implementierung einer asynchronen Kommunikation mit Hilfe von Event-Based-Components vorgestellt, welches eine sehr gute Alternative zum Async-Pattern ist. Seinen Eintrag nehme ich zum Anlass, um meine Beispiel-Implementierung des Async-Pattern zu refaktorisieren, um eine bessere Trennung der Verantwortlichkeiten und somit eine bessere Lesbarkeit zu erreichen.

In das Form wird die Abhängigkeit “CalcProxy” injected.

static void Main()

{

CalcProxy calcProxy = new CalcProxy(new Calculator());

Application.EnableVisualStyles();

Application.SetCompatibleTextRenderingDefault(false);

Application.Run(new Form1(calcProxy));

}

Im Gegensatz zur vorherigen Version wird in der Form nun nicht mehr der Calculator direkt erzeugt und verwendet, sondern auf den injekteten CalcProxy zugegriffen.

public partial class Form1 : Form {

private readonly ICalcProxy m_calcProxy;

public Form1(ICalcProxy calcProxy) {

InitializeComponent();

m_calcProxy = calcProxy;

m_calcProxy.CalcCompleted += CalculatorCalcCompleted;

}

private void Run_Click(object sender, EventArgs e) {

int number;

if (Int32.TryParse(txbEingabe.Text, out number)) {

m_calcProxy.CalcAsync(number, number);

}

void CalculatorCalcCompleted(object sender, CalcEventArgs eventArgs) {

lblCounter.Text = eventArgs.UserState.ToString();

}

Der CalcProxy wiederum bekommt die Abhängigkeit zum Calculator injected und stellt für die Calculator.Calc-Methode sowohl eine synchrone als auch eine asynchrone Methode zur Verfügung.

public class CalcProxy : ICalcProxy {

private readonly ICalculator m_calculator;

public event CalcCompletedEventHandler CalcCompleted;

private AsyncOperation m_asyncOperation;

private bool m_isRunning;

public CalcProxy(ICalculator calculator) {

m_calculator = calculator;

}

public int Calc(int number) {

return m_calculator.Calc(number);

}

public void CalcAsync(int number, object userState) {

lock (this) {

if (m_isRunning) {

throw new InvalidOperationException("Diese Operation wird bereits ausgeführt");

}

m_isRunning = true;

m_asyncOperation = AsyncOperationManager.CreateOperation(userState);

ThreadPool.QueueUserWorkItem(ExecuteCalc, number);

}

private void ExecuteCalc(object state) {

var result = Calc((int)state);

m_asyncOperation.PostOperationCompleted(CalcCompletedSuccessful, result);

}

private void CalcCompletedSuccessful(object result) {

if (CalcCompleted != null) {

CalcCompleted(this, new CalcEventArgs(null, false, (int)result, result));

}

Nun enthält der Calculator nur noch die Methode die für den Calculator notwendig ist, nämlich die Calc-Methode.

public class Calculator : ICalculator {

public int Calc(int number) {

Thread.Sleep(10000);

return number * number;

}

Asynchrone Kommunikation mit dem Async-Pattern

Thomas Christian — Wed, 05 May 2010 14:52:17 +0000

Bevor ich anhand eines Beispiels zeige, wie man mit Hilfe des Async-Pattern ein asynchrone Kommunikation implementieren kann, möchte ich kurz beschreiben, wo der Unterschied zwischen der synchronen und der asynchronen Kommunikation liegt und wofür die asynchrone Kommunikation nützlich ist.

Synchrone Kommunikation

Bei der synchronen Kommunikation handelt es sich um eine Echtzeit-Kommunikation. Das bedeutet, dass Anfragen und Antworten jeweils vollständig nacheinander abgearbeitet werden. Kommuniziert ein Prozess mit einem Webserver synchron, so ist der Prozess solange blockiert, bis er die vollständige Antwort vom Webserver erhalten hat.

Asynchrone Kommunikation

Im Gegensatz zur synchronen Kommunikation handelt es sich bei der asynchronen Kommunikation nicht um eine Echtzeit-Kommunikation. Das bedeutet, dass bei der Kommunikation eines Prozesses mit einem Webserver der Prozess nicht blockiert. Der Prozess verschickt lediglich die Anfrage an den Webserver und kehrt danach sofort zur weiteren Prozessausführung zurück. Der Prozess geht dabei davon aus, dass die Anfrage an den Webservice korrekt gestellt wurde. Die Antwort wird dann zu einem unbestimmten Zeitpunkt vom Webservice geliefert, und zwar dann, wenn dieser mit der Abarbeitung der Anfrage fertig ist.

Warum Asynchrone Kommunikation

Asynchrone Kommunikation bietet sich in unterschiedlichsten Situationen an. So ist es z.B. sinnvoll, dass eine WinForms-Anwendung asynchron mit einem Webservice kommuniziert, da der Haupt-Thread der WinForm-Anwendung sonst so lange blockiert wäre, bis der Webservice die Antwort auf die Anfrage liefert. Die Folge wäre, dass im Titel der Anwendung stehen würde, dass die Anwendung nicht antwortet (s. Abbildung 1). Viele Benutzer denken dass es sich bei dieser Meldung um einen Fehler im Programm handelt und beenden das Programm fix über den Task-Manager. Dabei lag es nur an der etwas länger dauernden Kommunikation zwischen der WinForm-Anwendung und dem Webservice.

Abbildung 1

Ein weiterer Grund für eine asynchrone Kommunikation wäre, wenn eine Anwendung nur Nachrichten verschicken möchte und es im Grunde keine Rolle spielt, ob diese Nachricht korrekt verarbeitet wurde. Vorstellbar wäre hier Loggen von Aktionen. Mir wäre es jetzt egal, ob die Nachricht korrekt gespeichert wurde oder nicht. Ich will nur nicht, dass meine Anwendung, nur weil Daten geloggt werden müssen, langsamer wird. Es handelt sich ja bei den Log-Daten nicht um Informationen die für die Abarbeitung notwendig sind.

Ein weiterer Fall wäre z. B. das Skalieren von Datenbankabfragen. So könnten mehrere Threads gleichzeitig Daten von gleichen oder unterschiedlichen Datenbeständen abfragen um schnellere Antwortzeiten zu erhalten.

Beispiel

Um die asynchrone Kommunikation zu realisieren gibt es unterschiedliche Möglichkeiten. Ich habe mich allerdings für eine Event-Based-Variante entschieden. Der große Vorteil von einem Event-Based Async-Pattern liegt in meinen Augen darin, dass der Nutzer von asynchrone Methoden sich nicht wirklich mit Multithread-Umgebungen auskennen muss. Für den Nutzer ist es völlig transparent wie die Threads im Hintergrund erzeugt werden und wie die Synchronisation der einzelnen Thread funktioniert. Für den Nutzer ist es nur wichtig zu wissen, dass er eine Methode aufrufen kann die asynchron abläuft und somit nicht den erwarteten Rückgabewert besitzt wie die synchrone Methode und dass ein Event ausgelöst wird, wenn die Methode komplett abgearbeitet wurde und der erwartete Rückgabewert zur Verfügung steht.

Nun aber genug geredet, jetzt wird programmiert. Für das Beispiel habe ich mich für eine WinForm-Anwendung entschieden, die nichts anderes tut, als die eingegebene Zahl zu quadrieren. Diese Berechnung dauert aufgrund eines Thread.Sleep() zehn Sekunden, um eine verzögerte Ausführung zu simulieren. Die Berechnung habe ich dabei in eine extra Komponente ausgelagert, die eine Schnittstelle zur asynchronen Kommunikation bereitstellt. Dabei gilt es eine gewisse Namenskonvention einzuhalten. Neben der synchronen Methode „Calc“, wird die asynchrone Methode mit dem Zusatz „Async“ bezeichnet („CalcAsync“). Da das Async-Pattern Event-Based ist, muss ein Event bereitgestellt werden, welches ausgelöst wird, wenn die asynchrone Verarbeitung beendet wurde. Laut Namenskonvention muss solch ein Event „Completed“ heißen. Mein Event heißt somit „CalcCompleted“.

Die Abbildung 2 zeigt die UI der Anwendung. Bei dem Drücken des „Run“-Buttons, soll die eingegebene Zahl asynchron quadriert werden und im Anschluss in das Feld „Ergebnis“ ausgegeben werden.

Abbildung 2

Der Code hinter der UI sieht folgendermaßen aus. Beim instanziieren des Forms, wird eine Instanz des Calculators erstellt und ein Delegate auf das „CalcCompleted“-Event registriert. Dieses Event wird aufgerufen sobald der Calculator mit der Berechnung fertig ist.

Bei dem Drücken des „Run“-Buttons, wird die Methode Calculator.CalcAsync(…) aufgerufen.

public partial class Form1 : Form {
        private ICalculator m_calculator;
        public Form1() {
            InitializeComponent();
            m_calculator = new Calculator();
            m_calculator.CalcCompleted += Calculator_CalcCompleted;
        }
 
        private void Run_Click(object sender, EventArgs e) {
            int number;
            if (Int32.TryParse(txbEingabe.Text, out number)) {
                m_calculator.CalcAsync(number, number);
            }
        }
 
        void Calculator_CalcCompleted(object sender, CalcEventArgs eventArgs) {
            lblCounter.Text = eventArgs.Result.ToString();
        }
    }

Sobald die Berechnung fertig ist, wird das CalcCompleted-Event ausgelöst und somit die Calculator_CalcComplete-Methode aufgerufen und das Ergebnis der Berechnung in ein Label geschrieben. Der große Vorteil ist, dass man sich an dieser Stelle nicht mehr um die Synchronisierung der Threads kümmern muss, sodass man direkt auf das Label schreiben darf und es nicht zu einem threadübergreifenden Zugriff kommt.

Der Calculator sieht wie folgt aus:

       
public interface ICalculator {
        event Calculator.CalcCompletedEventHandler CalcCompleted;
        int Calc(int number);
        void CalcAsync(int number, object userState);
    }
 
    public class Calculator : ICalculator {
        public delegate void CalcCompletedEventHandler(object sender, CalcEventArgs eventArgs);
        public event CalcCompletedEventHandler CalcCompleted;
        private AsyncOperation m_asyncOperation;
        private bool m_isRunning;
 
        public int Calc(int number) {
            Thread.Sleep(10000);
            return number * number;
        }
 
        public void CalcAsync(int number, object userState) {
            lock (this) {
                if (m_isRunning) {
                    throw new InvalidOperationException("Diese Operation wird bereits ausgeführt");
                }
                m_isRunning = true;
                m_asyncOperation = AsyncOperationManager.CreateOperation(userState);
                ThreadPool.QueueUserWorkItem(ExecuteCalc, number);
            }
        }
        .
        .
        .
    }

Wie man im Interface des Calculator sieht, gibt es eine synchrone und eine asynchrone Methode für die Berechnung. Uns interessiert allerdings nur die asynchrone Methode. Das lock und die Prüfung auf m_isRunning verhindern lediglich, dass die asynchrone Methode während ihrer Ausführung öfter aufgerufen wird. Das Wesentliche an dieser Methode ist der Aufruf von AsyncOperationManager.CreateOperation, denn dieser Aufruf stellt einen Synchronisationskontext bereit, der die Threads miteinander synchronisiert. Für die eigentliche Berechnung wird sich über den ThreadPool ein neuer Thread besorgt, der sich dann um die Abarbeitung der ExecuteCalc in einem eigenen Thread kümmert.

public class Calculator : ICalculator {
        .
        .
        .
        private void ExecuteCalc(object state) {
            int result = Calc((int)state);
            m_asyncOperation.PostOperationCompleted(CalcCompletedSuccessful, result);
        }
 
        private void CalcCompletedSuccessful(object result) {
            if (CalcCompleted != null) {
                CalcCompleted(this, new CalcEventArgs(null, false, (int)result, result));
            }
        }
    }
    public class CalcEventArgs : AsyncCompletedEventArgs {
        public CalcEventArgs(Exception error, bool cancelled, int result, object userState)
            : base(error, cancelled, userState) {
            Result = result;
        }
        public int Result { get; private set; }
    }

Sobald die Berechnung abgeschlossen ist, wird der Thread mit dem MainThread über den Aufruf von PostOperationCompleted synchronisiert und das CalcCompleted-Event ausgelöst und das Ergebnis in das Label geschrieben (s. o.).

6 public partial class Form1 : Form {

7 private ICalculator m_calculator;

8 public Form1() {

9 InitializeComponent();

10 m_calculator = new Calculator();

11 m_calculator.CalcCompleted += Calculator_CalcCompleted;

12 }

14 private void Run_Click(object sender, EventArgs e) {

15 int number;

16 if (Int32.TryParse(txbEingabe.Text, out number)) {

17 m_calculator.CalcAsync(number, number);

18 }

19 }

21 void Calculator_CalcCompleted(object sender, CalcEventArgs eventArgs) {

22 lblCounter.Text = eventArgs.UserState.ToString();

23 }

24 }

Softwarezellen – eine Lösung um die Komplexität zu beherrschen

Christina Hirth — Wed, 27 Jan 2010 10:01:52 +0000

Wir haben wie viele von uns in der Webentwicklung vor vielen Jahren mit Scriptsprachen und mit prozeduralen – Spaghetti-Code – angefangen. Mit der Zeit wuchs unsere Webpräsenz zu einer unüberschaubaren Anwendung mit manchen Seiten, die keiner von uns mehr anfassen wollte – aus Angst vor den Konsequenzen.

Um etwas Ordnung in die Webanwendungen zu bringen, haben wir also vor 4 Jahren angefangen, nach einem 3-Schichten-Modell zu entwickeln. Wir haben neue Funktionalitäten und neue Anwendungen nur noch so gebaut und wir waren für eine kurze Zeit zufrieden. Alles lief gut. Als wir den Umstieg auf .NET begonnen haben, haben wir weiterhin nach einem Mehr-Schichten-Modell gearbeitet, wir haben nur die Anzahl der Schichten erhöht.

Die Anwendungen wuchsen weiter, wir haben immer mehr Bereiche ausgelagert und diese hauptsächlich mit Webservices angesprochen. Währenddessen waren wir daran, unser Hauptprodukt, ein Portal für unseren Kunden mit der neuen Technologie entsprechend der alten Anforderung neu zu bauen. Und dann ist es passiert: ehe wir uns versahen, hatten wir ein riesiges Projekt, das alle mögliche Anwendungen eingebunden bzw. durch Webservices angesprochen hat. Die Grenzen waren fließend, eventuelle Änderungen an anderen Anwendungen konnten das Projekt unbuildbar machen, also ein ähnlicher Zustand wie vor paar Jahren zuvor.

Die Weiterentwicklung hat nicht nur in unserer Art zu Programmieren stattgefunden, wir selbst haben uns auch weiterentwickelt, wir haben die Community kennen gelernt. Bei den Open Space-Veranstaltungen haben wir Stefan und Ralf kennengelernt und durch sie eine andere Sichtweise der Dinge: die Modellierung einer Lösung durch Softwarezellen.

Wir haben sie zu uns eingeladen und uns die Idee erklären lassen. Das Stichwort heißt Holon. Wikipedia definiert ein Holon folgendermaßen:

Der Begriff Holon (von griech. ὅλος, hólos und ὀν, on „ganzes Seiendes“) wurde von Arthur Koestler geprägt und bedeutet ein Ganzes, das Teil eines anderen Ganzen ist. Es wird auch als “Ganzes/Teil” umschrieben.

Jede Anwendung ist ein Ganzes, die aus Teilen besteht, die ihrerseits auch als Ganze zu betrachten sind.

Seit dem Besuch von Ralf und Stefan haben wir uns die Artikelserie von Ralf von dotnetpro durchgelesen, die Webcasts (Teil 1, Teil 2) angeschaut und wir haben angefangen, diese Modellierung auszuprobieren.

Wir haben noch einen langen und interessanten Weg vor uns, aber eins ist jetzt schon sicher: wir werden versuchen unsere nächste Projekte durch Softzellen modellieren.

Solange die Komplexität nicht wieder die Überhand gewinnt

Design by Contract – jetzt auch mit C# – Teil 2

Christina Hirth — Thu, 05 Nov 2009 07:51:51 +0000

Der vorherige DbC-Artikel ist ziemlich “abstrakt” ausgefallen, es haben einfach Beispiele gefehlt. Das möchte ich hiermit nachholen.

Erstens muss man die IDE anpassen: im März kommt .NET 4.0 raus und da wird Design by Contract mitgeliefert. Man kann das Konzept aber jetzt schon anwenden, wenn man die Assembly zusätzlich installiert. Danach muss man die dll referenzieren und im Eigenschaftenfenster des Projektes im neuen Tab Code Contracts das Runtime Checking einstellen.

Jetzt zum Code: Nehmen wir eine ganz einfache Klasse Bill deren Objekte mit einem IRepository gespeichert bzw. geladen werden.

    1 using System.Diagnostics.Contracts;
    2 namespace ContractsPrototyp
    3 {
    4     public class Bill
    5     {
    6         public int Id { get; set; }
    7         public string Number { get; set; }
    8         public double Value { get; set; }
    9     }
   10 
   11
   12     public interface IRepository
   13     {
   14         Bill GetBill(string number);
   15         void SaveBill(Bill bill);
   16     }

Die Kontrakte kann man in den einzelnen Methoden oder für eine ganze Klasse schreiben (unter dem Attribut ContractInvariantMethode) aber ich finde am schönsten, dass man die auch auslagern kann: durch eine gegenseitige Markierung können Kontrakt-Klassen und Interfaces als “Paare” definiert werden:

   11     [ContractClass(typeof(RepositoryContracts))]
   12     public interface IRepository
   13     {
   14         Bill GetBill(string number);
   15         void SaveBill(Bill bill);
   16     }
   17     [ContractClassFor(typeof(IRepository))]
   18     public class RepositoryContracts:IRepository
   19     {
   20         public Bill GetBill(string number)
   21         {
   22             Contract.Requires(!string.IsNullOrEmpty(number));
   23             return null;
   24         }
   25 
   26         public void SaveBill(Bill bill)
   27         {
   28             Contract.Ensures(bill.Id > 0);
   29         }
   30     }

Eine Vorbedingung wird mit Contract.Requires und eine Nachbedingung mit Contract.Ensures definiert. Beide Methoden bekommen boolische Ausdrücke. Diese Ausdrücke müssen frei von Seiteneffekten sein.

Die eigentliche Implementierung der Klasse schaut dann so aus:

   31     public class Repository:IRepository
   32     {
   33         public Bill GetBill(string nummer)
   34         {
   35             //Würde das Objekt aus Datenhaltung laden
   36             return new Bill();
   37         }
   38 
   39         public void SaveBill(Bill bill)
   40         {
   41             //Würde das Objekt speichern und ihm eine Id zuweisen
   42             if (BillIsValid( bill )) bill.Id++;
   43         }
   44 
   45         private static bool BillIsValid(Bill bill)
   46         {
   47             return !string.IsNullOrEmpty(bill.Nummer);
   48         }
   49     }

Woher können wir wissen, dass das funktioniert? Es ist einfach, wir schreiben ein Paar Tests dazu!
Bei Kontraktverletzung wird eine Exception geworfen. Um diese – und dadurch die genaue Verletzung – überprüfen zu können braucht man etwas Workaround:

   55     [TestFixture]
   56     public class BillTests
   57     {
   58         private IRepository m_repository;
   59         private string m_message;
   60 
   61         [SetUp]
   62         public void Setup()
   63         {
   64             m_repository = new Repository();
   65             m_message = string.Empty;
   66             Contract.ContractFailed += ( sender, e ) =>
   67             {
   68                 e.SetUnwind();
   69                 m_message = e.Message;
   70             };
   71         }

Danach sind die Tests dann einfach:

   73         [Test]
   74         public void Laden_mit_leerer_Nummer_verletzt_Kontrakt()
   75         {
   76 
   77             try
   78             {
   79                 m_repository.GetBill( null );
   80             }
   81             catch
   82             {
   83                 //Nichts 
   84             }
   85 
   86             Assert.That( m_message, Is.EqualTo( "Precondition failed: !string.IsNullOrEmpty(number)" ) );
   87         }
   88 
   89         [Test]
   90         public void Speichern_Rechnung_ohne_Nummer_verletzt_Kontrakt()
   91         {
   92 
   93             try
   94             {
   95                 m_repository.SaveBill( new Bill{Value = 25} );
   96             }
   97             catch
   98             {
   99                 //Nichts 
  100             }
  101 
  102             Assert.That( m_message, Is.EqualTo( "Postcondition failed: bill.Id > 0" ) );
  103         }

Ich hoffe, das Beispiel ist ausführlich genug, um die Vorteile von DbC zu highlighten. Stefan, vielen dank noch mal für den Artikel, ich habe mich natürlich von dir inspirieren lassen.

Design by Contract – jetzt auch mit C#

Christina Hirth — Mon, 26 Oct 2009 08:03:39 +0000

Bald kommt .NET 4.0 raus, zusammen mit einem für C# neuen Konzept: Kontrakte im Code mit Spec# festzulegen.

Wikipedia definiert DbC folgendermaßen:

Design by contract (kurz DbC; englisch Entwurf gemäß Vertrag) oder Programming by Contract ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen. Entwickelt und eingeführt wurde es von Bertrand Meyer mit der Entwicklung der Programmiersprache Eiffel.

Stefan Lieser hat über das neue Konzept einen sehr guten Artikel in www.visualstudio1.de geschrieben, mit Begriffsklärung und Anwendungsbeispiele. Kurz zusammengefasst ist die Rede von Folgendem: anstelle, dass man in jeder Methode auf not-null or not-empty usw. prüft, schreibt man die Erwartungen als Code hin. Diese werden von Tools wie z.B. Resharper erkannt und bei fehlerhaften Aufruf der Methode, wird der Entwickler gewarnt. Am besten finde ich, dass man den Kontrakt-Code z.B. für einen Interface in eine separate Klasse schreiben kann und diese wird durch Attribute (ContractClassFor) gefunden. Also wird dadurch der eigentliche Code nicht größer.

Das soll nicht bedeuten, dass der Entwickler der Methode die Verantwortung von sich schiebt , sondern dass er Bedingungen der “Nutzung” offenlegt, Informationen, die bisher nur durch das Anschauen des Codes oder durch mündliche/schriftliche Mitteilung möglich war. Mit Spec# kann man die Intention-Revealing Interfaces ganz genau schreiben: mit veröffentlichten und kompilierten Bedingungen.