Einsatzgebiete von Web Services

Es gibt heute drei unterschiedliche Einsatzgebiete für Web Services. Zum einen ist dies im Bereich Enterprise Application Integration, wenn eine sehr lose Kopplung gefordert wird - sprich, wenn neue Systeme hinzugefügt werden müssen, deren Anforderungen man noch nicht genau kennt. Hier konkurrieren die Web Services allerdings mit Message-Brokern wie z.B. Microsoft BizTalk Server.

Das zweite Einsatzgebiet sind öffentliche Services (Funktionen), die über das Internet zur Verfügung gestellt werden. Die immer wieder angeführten Beispiele hierfür reichen vom Kalender bis zum Rating-System. Um diese öffentlichen Web Services zu finden, gibt es UDDI (Universal Description, Discovery and Integration), sozusagen die Gelben Seiten für Web Services und deren Beschreibung. Mit diesen öffentlichen Services geht es aber nur schleppend voran. Selbst bei Microsoft, wo man innerhalb der .NET My Services-Initiative verschiedene Web Services anbieten wollte, hängt man hier der Planung hinterher (derzeit ist nur der Passport-Service verfügbar), was an der Sicherstellung der Verfügbarkeit und der Frage des Pricings liegen mag. Wer ist schon interessiert, einen öffentlichen Service zur Verfügung zu stellen, wenn er diesen nicht verrechnen kann?

Weder öffentliche Web Services noch der Einsatz von Web Services zur Integration von Applikationen hatten bisher einen durchschlagenden Erfolg. Ganz in Gegensatz zur folgenden, dritten Einsatzvariante.

Komponenten + Internet

Ein Web Service ist grundsätzlich nichts anderes als Funktionalität, die über das Web aufgerufen werden kann. Dass dies, sofern als Protokoll HTTP und als Datenformat XML verwendet wird, auch plattformunabhängig ist - so kann z.B. eine Java-Applikation auf einen .NET-Service zugreifen und umgekehrt - sei hier nur am Rande bemerkt. Implizit heißt dies aber, dass auch andere Protokolle und andere Datenformate gewählt werden können.

Nun aber zur eigentlichen Verwendung. Aus früheren Zeiten kennt man den Aufruf von Unterprogrammen innerhalb eines Programms. Dies führte zu einer gewissen Modularität des Programms, der Wiederverwendung von Code, besseren Testmöglichkeiten usw. Bald kam dann der Anspruch, auch Programmteile oder Komponenten innerhalb eines Programms verwenden zu können, die zwar auf dem selben Rechner, nicht aber im selben Programm zu finden waren. Dies führte zu RPC (Remote Procedure Calls) oder COM, dem Common Object Model von Microsoft. Aber wenn man schon allgemeine Komponenten in seinen Programmen einbinden konnte, warum ging dies nur auf der selben Maschine und nicht innerhalb eines Netzwerks? Die Lösungen hierfür hießen schließlich CORBA und DCOM.

Waren nun alle Probleme erschlagen? Leider nein. Denn sowohl CORBA als auch DCOM arbeiten mit speziellen Protokollen und Datenformaten, die eine sichere Firewall nicht durchlässt. Ergo musste eine neue Technologie entwickelt werden - die Web Services.

Genau mit diesem Hintergrund setzt das Beratungsunternehmen Zühlke [1] diese Technologie ein: Mittels Web Services werden Rich Clients (ausführbare Programme) an Serverapplikationen angebunden, die nur über das Internet Zugang haben. Dass diese Technologie natürlich auch innerhalb eines Intra- oder Extranets funktioniert, versteht sich von selbst. Und so kommen Web Services auf schlichte Art und Weise in geschlossenen Applikationen zu ihrem Einsatz, als einfache Weiterführung von Komponenten-Architekturen über das Internet.

Projektbeispiel: Lärmdatenerfassung

Im Auftrag des Bundesamtes für Verkehr (BAV) werden an sechs Standorten entlang des SBB-Schienennetzes Lärmdaten und statistische Größen von Zugdurchfahrten erhoben (z.B. mittlerer Pegel, Achszahl, Dauer, Zuggeschwindigkeit). Zühlke erhielt den Auftrag, eine Softwarelösung zu entwickeln, die auf dem Know-how eines früher realisierten Luftqualität-Informationssystems basierte, jedoch dem aktuellen Stand der Softwaretechnologie entsprach. Die einfache Erweiterbarkeit für ähnliche Monitoring-Projekte (z.B. Straßenverkehrsdaten) war neben einer sehr kurzen Entwicklungszeit eine der Hauptanforderungen.

In dieser .NET Applikation für das Monitoring von Lärm- und Zugdurchfahrtsdaten an Bahnstrecken wurden nach oben genanntem Prinzip erstmals bei Zühlke Web Services in einem kommerziellen Projekt eingesetzt. Die Messdaten werden in Messstationen an den Bahnstrecken erhoben und über FTP auf einen Server transferiert. Die Serveranwendung importiert diese Daten unterschiedlichsten Formats dann zeitgesteuert in die Datenbank. Die Aufbereitung der Messdaten erfolgt auf dem Server selbst. Über den Client, der als eigenständige Applikation realisiert wurde, werden die Rohdaten, bzw. aus den Rohdaten berechnete Verdichtungsdaten via Web Service vom Server abgerufen. Die entsprechenden Berechnungen werden auf dem Server ausgeführt. Die Vorgaben für die Berechnungen (z.B. Mittelwert, Maxima, Minima) erfolgen auf dem Client. Auch die Verwaltung der Stammdaten sowie die Konfiguration der Applikation wird über den Client vorgenommen. Der Web Service ist nicht über UDDI registriert, da die Funktionalität und die Art der Verwendung bekannt sind (geschlossene Applikation). In der aktuellen Systemkonfiguration (Firewall) kann nur innerhalb einer DMZ (demilitarisierten Zone) auf den Service zugegriffen werden. Die Daten werden im XML-Format übertragen, was bei größeren Datenmengen eine erheblichen Netzwerkbelastung verursacht. Daher werden diese Daten vor der Übertragung komprimiert und mittels eines frei erhältlichen Tools (SharpZipLib, [2]) binär serialisiert, um die Übertragungsgeschwindigkeit zu steigern. Die Sicherheit der Datenübertragung wird über die Verwendung eines SOAP-Authentication-Headers und die in der Datenbank integrierte Benutzerverwaltung gewährleistet.

Die Umsetzung

Basierend auf der .NET-Technologie wird eine 3-Tier-Applikation entwickelt, die Messdaten in der Datenbank ablegen, bearbeiten (Plausibilisierung, Visualisierung) und in tabellarischer Form auf dem Client darstellen und verarbeiten kann. Die Lösung besteht aus drei Komponenten:

Der Scheduler, realisiert als Windows-Service, ist für das zeitgesteuerte und vollautomatische Starten von Prozessen zuständig. Der Benutzer definiert die Prozesse, bestehend aus einem oder mehreren parallelen oder seriellen Tasks, die zeitgesteuert vom Scheduler gestartet werden. Beispiele für solche Tasks sind das Transferieren von Textdateien vom FTP-Server, die Konvertierung dieser Textdateien in standardisierte XML-Datein oder das Importieren der Daten einer XML-Datei in die Datenbank.

Im Client (GUI-Applikation) werden die Messdaten visualisiert und editiert, die Stammdatenverwaltung (Messstationen, Messparameter, Berechnungsdefinitionen etc.) durchgeführt, Prozesse und Tasks für den Scheduler definiert und manuell gestartet und administrative Aufgaben wie die Konfiguration oder die Benutzerverwaltung durchgeführt. Der Client ist modular aufgebaut. Die aktuelle Ausbaustufe enthält die Module Basisdaten, Messdaten, Taskplaner und Administration (siehe Abb. 2).

Über den als Web Service implementierten Server erfolgen die Zugriffe vom Client und Scheduler auf die Datenbank. Der Serverzugriff auf die Datenbank erfolgt über ADO.NET und typisierte Datasets. Der Server verfügt über ein Berechnungsmodul, mit dem die Messdaten statistisch ausgewertet werden können. So können Mittelwert, Maxima und Minima gepictureet und weitere algebraische Berechnungen durchgeführt werden. Die Definition der Berechnungen wird vom Benutzer am Client vorgenommen und in der Datenbank persistent abgelegt. Die Durchführung der Berechnungen erfolgt on demand, das heißt, sobald der Benutzer die entsprechend berechneten Daten im Client visualisieren will. In der Datenbank selbst sind nur die Rohdaten, also effektiv gemessene Werte persistent gespeichert. Für die Kommunikation zwischen Web Service und Scheduler wird das Windows Messaging verwendet. Dies wird insbesondere beim manuellen Starten von Prozessen durch den Benutzer ausgenutzt.

Nora ist bereits für Mehrsprachigkeit vorbereitet; sämtliche angezeigten Texte und Menüs sind in Resource-Dateien ausgelagert, die bei einem künftigen Bedarf durch weitere Sprachversionen ergänzt werden können -ohne Änderungen im Sourcecode.

Der Kundennutzen

Dank der modularen und flexiblen Architektur können zukünftige Investitionen für die Entwicklung ähnlicher Softwarelösungen (z.B. für Überwachung von Luftschadstoffen oder Straßenlärm, Verkehrszählungen etc.) erheblich reduziert werden. Die künftige Entwicklung eines Browser-Clients ist durch den Einsatz von Web Service-Technologie bereits vorbereitet und wird in einer nächsten Ausbaustufe realisiert. Abpictureung 3 zeigt die geplante Architektur. Zur Realisierung wird der Scheduler um einen Task erweitert, der Messdaten aus der Nora-Datenbank in eine eigenständige Nora-Web-Datenbank exportiert. Da es sich bei den zu exportierenden Daten meist um verdichtete, berechnete Daten (Mittelwerte etc.) handelt, von denen nur die Berechnungsdefinition in der Nora-Datenbank gespeichert ist, kann dazu kein Datenbank-Mechanismus (z.B. Replikation, DTS) verwendet werden.

Für den Zugriff auf die Nora-Web-Datenbank wird ein neuer Middle-Tier entwickelt, der ebenfalls als Web Service realisiert wird. Der Zugriff auf die Messdaten erfolgt dann allerdings read-only. Dieser Web Service kann bei Bedarf in UDDI publiziert werden, sodass Drittanbieter dessen Funktionalität nutzen könnten.

Weiterhin wird ein ASP.NET-Client entwickelt, der auf diesen Web Service zugreift und die vom Browser-Benutzer ausgewählten Messdaten grafisch, tabellarisch oder zum Download bereitstellt.

Wäre so etwas früher nicht auch möglich gewesen?

Prinzipiell ja, sofern man auf UDDI und WSDL verzichtet hätte. Was also ist nun so spektakulär? Das wirklich faszinierende an Web Services, zumindest unter der .NET-Plattform von Microsoft, ist, dass es ganz einfach ist, einen Web Service zu erzeugen und dass der IIS (Internet Information Server) diesen dann problemlos ausführen kann. Der Aufruf des Web Services erfolgt ohne Registrierung oder andere Klimmzüge. Er wird über eine URL aus dem Programm heraus aufgerufen. Sozusagen kinderleicht und kostengünstig und daher wirklich zu empfehlen.
Werner Wittich ist Business Unit Manager Windows Enterprise Solutions bei der Zühlke Engineering AG. Markus Karrer ist Projektleiter und Software Ingenieur bei der Zühlke Engineering AG

Links und Literatur

• [1] Zühlke Engineering AG: www.zuehlke.com
• [2] SharpZipLib: www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx