Fehlervertrag
Dieses Dokument beschreibt die Erstellung und Anwendungen von Fehlerverträgen im Schleupen-Kontext. Fehlerverträge werden für Dienste definiert, um mögliche Fehler die bei der Nutzung des Dienstes auftreten können zu beschreiben. Die für den Dienst bzw. dessen Operationen erstellen Fehlerverträge werden Teil der Schnittstellenbeschreibung des Dienstes und können vom Client in Form von Metadaten eingesehen werden. Diese Technik ermöglicht eine klare Servicegrenze bei der Handhabung von Ausnahmen, da der Client durch die Metadaten über mögliche Fehler in Kenntnis gesetzt werden kann ohne dass der Dienst interne Informationen veröffentlichen muss.
Design
Wie alle Daten, die über den ESB integriert werden. Hierzu wird in den fachlichen Kontext eine Klasse mit Stereotyp «Fault» hinzugefügt, wie in der folgenden Abbildung zu sehen ist.
Dieser Fault muss dann im Kanonischen Servicemodell an den Stellen verwendet werden, wo dieser Fehler auftreten kann, zum Beispiel wie in Abbildung 2 zu sehen. Hierbei muss der Fault kopiert werden (mit den Attributreferenzen auf das kanonische Datenmodell) und eine (usage) Verwendung vom OperationsResponse modelliert.
Mittels KaMoTo können dann Serviceschnittstellen (WSDL und .cs) generiert werden, die alle notwendigen Attribute beinhalten.
namespace Schleupen.ZentraleDaten_20130422.NatuerlichePersonEntityService;
[ServiceContract]
public interface NatuerlichePersonEntityService
{
[OperationContract]
[FaultContract(typeof(NatuerlichePersonBereitsVorhandenFaultContract))]
CreateResponse Create(CreateRequest request);
}
Stärken und Schwächen
Stärken
- Ermöglicht lose Kopplung von Client & Service
- Standardisierte Metadaten können durch andere Technologien/Clients interpretiert werden -> plattformunabhängig
- Implementierungsdetails bzw. vertrauenswürdige Informationen werden nicht zwangsläufig zum Client transportiert
Schwächen
- Erhöhter Modellierungsaufwand