Anforderungen an den Web-Service
Der Web-Service hatte zwei Aufgaben zu erfüllen. Die Kommunikation mit der MS-SQL-Server Datenbank und die Dateizugriffe abzuwickeln.
Eine Besonderheit des Systems, für die MS-SQL-Datenbank wird ein selbst entwickelter OR-Mapper verwendet. Als das Projekt 2003 startet, war noch kein, unserem Projektleiter passender, OR-Mapper von der Stange erhältlich. Also bekam ich die Aufgabe, einen OR-Mapper selbst umzusetzen.
Die erste Umsetzung des Web-Service arbeitete wie vorgesehen. Für jede Funktion war eine spezialisierte Methode implementiert. Mit der steigenden Komplexität des Projektes vermehrten sich die Methoden schlagartig. Was den Nachteil hatte, einen erheblichen Programmieraufwand zu verursachen.
Ein weiteres Manko dieser vielen Methoden, jeder Aufruf hat eine Antwortzeit, die sich aus der Laufzeit durchs Netz zum Web-Service, und der Verarbeitung auf dem Server zusammensetzt. Grobe Faustregel 1-2 Sekunden Laufzeit pro Verarbeitung. Müssen nun 10 Abfragen zum Aufbau einer Maske durchgeführt werden, kommen da schnell 10 – 15 Sekunden zusammen. Der Anwender hat es nicht bemängelt, aber mir hat dieses Verhalten keine Freude bereitet.
Die besondere Lösung war relativ einfach. Es wurde ein Web-Service Handler Objekt WS geschaffen, welches die SQL Anfragen aufzeichnen konnte.
In die Ausführungsschicht des OR-Mappers wurde eine Weiche eingefügt.
Wenn man den OR-Mapper in den Aufzeichnungsmodus umschaltete, wurden die SQL-Befehle im WS Objekt erst einmal aufgezeichnet.
Waren alle Aufträge aufgenommen, wurde dieses Objekt an den Web-Service gesendet.
Der Web-Service führt nun die Aufträge sinnvoll sortiert durch. Insert und Update Aufträge zuerst, darauf folgend die Select Anforderungen.
Der große Trick bei dieser Lösung, anstelle 10 Aufträge hintereinander durchzuführen, wurde nur noch ein Auftrag an den Web-Service gesandt.
Wenn die Operationen Daten zurückliefern sollten, wurden diese ins WS Objekt geschrieben, welches der Web-Service zurück lieferte.
Somit wurde bei einem Auftrag, der 10 Operationen durchführte, 9 mal die Laufzeit zum Server wegrationalisiert, also anstelle von 15 Sekunden Laufzeit nur noch eine Laufzeit von 4-5 Sekunden, je nach Dauer der Verarbeitung auf dem Server.
Wie bekommt man nun diese Innovation in den vorhandenen, umfangreichen Quellcode?
Bei mehreren Tests dieser Funktion zeigte sich eine erhebliche Antwortzeitverkürzung durch das ein Web-Service Handler Objekt WS. Also musste eine Lösung gefunden werden, wie man diese Erweiterung im Laufe der Zeit ohne große extra Entwicklungsaufwand implementiert bekommt.
Der erste Ansatz war, einfach den OR-Mapper so zu erweitern, dass dieser im Web-Service Mode arbeitete.
Was bedeutete, entweder wurden Aufträge aufgezeichnet und auf Anforderung gemeinsam ausgeführt, oder ein einzelner Auftrag wurde direkt über die neue Schnittstelle WS Modul durchgeführt.
Somit arbeitete der vorhandene Source Code direkt mit dieser neuen Technik, wenn man die Aufrufe der einzelnen spezialisierten Methoden einfach aus dem Source Code löschte. Dieser Vorgang dauerte zwar einige Zeit, da immer nur bei Änderungen an einem Modul die Technik umgestellt wurde, führte aber zum Erfolg.
Eine weitere Besonderheit dieses Projektes, die große Masse der Eingabemasken und der erforderliche Business Logik Quellcode werden von einem von mir umgesetzten Code Generator erzeugt. Hier waren es nur ein paar Module, deren Source Code Generierung überarbeitet werden mussten. Alle Code Pattern wurden dann mit direktem Support für das WS Objekt erzeugt.
Die Erweiterung Datei Funktions-Schnittstelle
Was mir jetzt noch nicht so richtig gefallen hatte, waren die Arbeitsschritte Dateien hochladen oder herunterladen. Diese Funktionen liefen noch über spezialisierte Funktionen des Web-Service. Da hier hin und wieder ebenfalls Funktionen erweitert wurden, waren immer noch Updates am Web-Service erforderlich. Zudem war der ganze Zoo an Web-Service Versionen ebenfalls zu pflegen.
Die Lösung dockte ich einfach an das Web-Service Handler Objekt WS an. Ein zweites ähnliches Auftragsmodul WS_File wurde hinzugefügt. Dieses Modul hat für jede erforderliche Dateioperation eine Funktion im Angebot.
Das Ergebnis dieser Umsetzung: Es gibt nur noch genau eine Methode im Web-Service über die alle erforderlichen Serverzugriffe aller Windows-Forms Anwendungen durchgeführt werden. Ein Update ist nur in den seltensten Fälle überhaupt erforderlich. Die Zeit zur Umsetzung dieser Änderungen erstreckt sich über ca. 2 Jahre.
Ob nun direkt auf dem Server oder über die Web-Service Schnittestelle zugegriffen wird unterscheidet sich im Source Code nur noch in der Parametrierung der Schnittstelle. Bei der Datenabfrage gibt es nur eine Kleinigkeit zu beachten, Aufträge im Block definieren und dann gemeinsam ausführen lassen. Da sämtliche Zugriffe durch die Windows Forms Anwendungen in einem separaten Thread durchgeführt werden, ist es sehr einfach diese Position zu finden und den Source Code entsprechend anzupassen.
Zum Anschluss: Komprimierung und Verschlüsselung
Mit dieser Technik ließ sich nun erheblich besser und schneller entwickeln als vorher.
Ein kleiner Wehmutstropfen war ein Kollege von mir, der mir eine lange Nase machte. Er durfte ein neues Projekt aufsetzen und aus allen Erfahrungen lernen. Er hatte ebenfalls einen fertig gekauften OR-Mapper einsetzen dürfen. Die lange Nase machte er mir mit Web-Service 2.0. Dieser komprimierte automatisch die Anfragen und Antworten bevor diese übertragen wurden.
Hier wurde dann der letzte Evolutionsschritt umgesetzt. Es war relativ einfach die beiden Web-Service Objekte mittels einer vorhandenen Bibliothek zu komprimieren und bei der Gelegenheit gleich noch zu verschlüsseln. Da das System über die Jahre gewachsen war, war die Datenmenge mittlerweile immens, wenn man als Super Admin sinnlose Anfragen an das System absetzte.
Was ist eine sinnlose Abfrage an die Datenbank? Hallo System, liefere mal alle Projekte. Zu dem Zeitpunkt waren es ca. 9000. Selbst bei reinen Datenanfragen wurde somit durch die Komprimierung einiges an Datenmenge pro Aufruf des Web-Service reduziert.
Aber der Hauptvorteil dieses Web-Service liegt heute in seiner extrem einfachen Wartbarkeit. Änderungen in der Datenbank erfordern keinerlei Änderungen am Web-Service. Die Business Logik des OR-Mappers wird um eine weitere Tabelle oder Sicht erweitert und kann direkt verwendet werden.
Durch den Code Generator unterstützt, lassen sich so neue Datenstrukturen in sehr kurzer Zeit implementieren. Die Erweiterungen im Code Generator erzeugen mittlerweile direkt funktionierende fertige Windows Forms Dialoge zur Auswahl und Bearbeitung der Daten. Es bleibt nur etwas Designarbeit an der Oberfläche. ASP.net User Controls sind ebenfalls generierbar, allerdings nicht so ausgereift wie die Lösungen der Windows Forms.
Eine echte Besonderheit war die 2013 erfolgte Erweiterung für Visual WebGui. Da Visual WebGui fast 1:1 Windows Forms abbildet, konnte ich den Code Generator mit wenig Aufwand um die Code Generierung für Visual WebGui erweitern.
Bilder werden geladen...