Web Services B2B-Implementierung: Komponenten, Ausnahme-Behandlung und Logging

Jede Komponente ist außerdem für das Logging von Ausnahmen verantwortlich, die von ihr verursacht wurden. Daher wird eine Business-Komponente niemals eine Ausnahme der Datenbank-Schicht protokollieren. Die Tabelle zeigt das Muster der Ausnahmen und Logging-Aufzeichnungen.

Ursprung der Ausnahme Reaktion DbTier-Komponente Ausnahme wird protokolliert und DbTierException wird an die auslösende Quelle weitergereicht (thrown). BizTier-Komponente Ausnahme wird protokolliert und BizTierException wird an die auslösende Quelle weitergereicht (thrown). DbTierExceptions werden aufgefangen (caught), nicht protokolliert und dann an die auslösende Quelle zurückgegeben. ASPX-Schicht Keine direkte Ausnahmebehandlung erforderlich, außer in bestimmten Fällen. Global.asax kümmert sich um alle von der ASPX-Schicht ausgelösten Ausnahmen und protokolliert diese. Ebenso werden alle Ausnahmen behandelt, die von der Business- und Datenbank-Komponente zurückgegeben werden. Web Service-Schicht Ausnahme wird protokolliert und WSException ausgelöst. Sowohl BizTierExceptions als auch DbTierExceptions werden aufgefangen (caught) aber nicht protokolliert und zurück zum Web Service-Consumer geschickt. WSB2BUtil-Komponente Keine direkte Ausnahmebehandlung erforderlich. Dies stellt sicher, dass Ausnahmen der richtigen Quelle zugeordnet und entsprechend protokolliert werden.

Für die Zwecke der Beispielanwendung protokollieren die Logging-Funktionen nur Ausnahmen. Logging ist eine recht allgemeine Funktion und wird daher in der WSB2BUtil-Komponente implementiert, so dass diese Funktion für andere Projekte wiederverwendet werden kann. Dazu klickt man mit der rechten Maustaste auf die WSB2BUtil-Komponente und wählt Add | Add Class (Hinzufügen | Klasse hinzufügen). Als Klassennamen gibt man Log.vb ein und kopiert den Code aus Listing F in diese neue Log-Klasse.

Es werden zwei grundlegende Methoden bereitgestellt, die zwei unterschiedliche Typen von Ausnahme-Klassen akzeptieren. Damit können reguläre System-Ausnahmen ebenso wie Ausnahmen individueller Komponenten protokolliert werden. Man beachte, dass der Dateiname der Logdatei über die Eigenschaft AppSettings der Klasse ConfigurationSettings angegeben wird. Nun muss noch der Web.config-Datei ein Schlüssel hinzugefügt werden, um diese Funktion zu ermöglichen. Für Toms Anwendung wird das folgende XML-Element dem -Knoten in der Web.config-Datei im Stammverzeichnis hinzugefügt:

Und für Johns Anwendung:

Schließlich muss noch in beiden Anwendungen die Datei Global.asax angepasst werden, um regelmäßige Ausnahmen von der ASPX-Schicht zu protokollieren. Den Code aus Listing G fügt man dem Ereignis Application_Error hinzu.

Dieses Ereignis wird jedes Mal automatisch ausgelöst, wenn eine Ausnahme innerhalb einer ASP.NET-Anwendung ausgelöst wird. Da die einzelnen Komponenten ihre jeweiligen Ausnahmen selbst protokollieren, müssen hier nur die übrigen Ausnahmen protokolliert werden.

Die Implementierung eigener Logging-Funktionen mag etwas viel des Guten erscheinen, da es eine Reihe von entsprechenden bereits eingebauten Funktionen gibt. Allerdings bietet diese Lösung mit einigen Modifikationen größere Flexibilität für komplexere Anwendungen, z. B. eine individuelle Ausgabe als XML, E-Mail-Benachrichtigungen oder die Festlegung von Schwellenwerten für den Schweregrad der Ausnahmen. Außerdem kann man so zur Laufzeit den Namen der Logdatei ändern.

Die in Listing H gezeigte Klasse ist verantwortlich für alle sonstigen Funktionen, die in kein OO-Schema passen – üblicherweise Konvertierung, Manipulation und Validierung von Datentypen usw.

In der nächsten Folge wird es um die Implementierung der notwendigen Datenbank-Verbindungen und Aufrufe der Beispielanwendungen gehen.