Konzeption und Entwicklung eines Event/Action-Mechanismus zur Kommunikation mit mobilen Endgeräten

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Quelltextverzeichnis

1 Einführung
1.1 SpiW - Mobile Spedition im Web
1.2 Architektur des SpiW-Kommunikationssystems
1.2.1 Fachliche Architektur
1.2.2 Systemtechnische Architektur
1.2.3 Softwaretechnische Architektur
1.3 Aufgabenstellung
1.4 Vorgehensweise
1.5 Rahmenbedingungen

2 Event/Action-Mechanismus
2.1 Begriffe
2.1.1 Event
2.1.2 Event-Listener
2.1.3 Event-Modell
2.2 Anforderungen
2.2.1 Übertragung aller Daten
2.2.2 Erweiterbarkeit / Flexibilität
2.2.3 Anpassbarkeit
2.2.4 Zuverlässigkeit
2.2.5 Sicherheit
2.2.6 Geringe Datenmenge
2.2.7 Schnelligkeit
2.2.8 Skalierbarkeit
2.2.9 Plattformunabhängigkeit
2.3 Lösung
2.3.1 Optimale Granularität
2.3.2 SpiwEvent
2.3.3 Event-Modell
2.3.4 Mapping von Ereignissen nach Aktionen

3 Beschreibung des XML-Datenformats
3.1 Motivation
3.2 DTD
3.3 XML Schema
3.4 Vergleich
3.5 XML Schema für SpiwEvent

4 Data-Binding
4.1 Motivation
4.2 Grundkonzept
4.2.1 Klassengenerierung
4.2.2 Marshalling
4.2.3 Unmarshalling
4.3 Data-Binding-Frameworks
4.4 Low-Level APIs
4.4.1 DOM
4.4.2 SAX
4.4.3 Vergleich
4.5 Umsetzung des individuellen Data-Binding
4.5.1 XmlReader
4.5.2 XmlWriter

5 Übertragung der XML-Daten
5.1 Auswahl des Übertragungsweges
5.2 Web Service Grundlagen
5.2.1 SOAP
5.2.2 WSDL
5.2.3 Lebenszyklus eines ASP.NET XML Web Services
5.2.4 Die push/pull-Problematik
5.2.5 Bewertung
5.3 Erstellen eines ASP.NET XML Web Services
5.4 Erstellen des SpiW-Web Services
5.4.1 Methoden des Web Services
5.4.2 Umwandlung der Datentypen
5.4.3 WSDL-Beschreibung des SpiW-Web Services
5.4.4 Alternative Methoden
5.4.5 Aktualisiertes Klassendiagramm
5.5 Erstellen einer Client-Anwendung
5.6 Sicherheit
5.6.1 SSL
5.6.2 Windows-Authentifizierung
5.6.3 SOAP-Header
5.7 Alternativen zu XML Web Services
5.7.1 .NET Remoting
5.7.2 Sockets

6 Zusammenfassung und Ausblick
6.1 Erfüllung der Anforderungen
6.1.1 Übertragung aller Daten
6.1.2 Erweiterbarkeit / Flexibilität
6.1.3 Anpassbarkeit
6.1.4 Zuverlässigkeit
6.1.5 Sicherheit
6.1.6 Geringe Datenmenge
6.1.7 Schnelligkeit
6.1.8 Skalierbarkeit
6.1.9 Plattformunabhängigkeit
6.2 Besonderheiten bei der Implementierung
6.2.1 Validierung
6.2.2 Dynamisches Laden der Event-Handler
6.3 Ausblick
6.3.1 Die Zukunft der Web Services 85
6.3.2 Die Zukunft des .NET Frameworks
6.3.3 Weiterer Forschungsbedarf

Literaturverzeichnis

Anhang A WSDL-Beschreibung des Web Services

Anhang B Beispielhaftes SpiwEvent als XML

Anhang C Beschreibung des mitgelieferten Prototyps

Abbildungsverzeichnis

Abbildung 1: SpiW-Datenmodell - Teil 1

Abbildung 2: SpiW-Datenmodell - Teil 2

Abbildung 3: Softwaretechnische Architektur des SpiW-Kommunikationssystems

Abbildung 4: Das .NET Framework im Überblick [Weye02]

Abbildung 5: Java 1.1 Delegation Model [Meie99]

Abbildung 6: Bestandteile der COS Event Channel Architektur [HaLS97]

Abbildung 7: Cambridge event architecture [BMBH00]

Abbildung 8: Rekursive Umwandlung von Geschäftsobjekten zu Events

Abbildung 9: Das Spiw-Event-Modell

Abbildung 10: Das „Strategy“-Entwurfsmuster [GHJV95]

Abbildung 11: Die Umsetzung des „Strategy“-Entwurfsmusters

Abbildung 12: Das „Flyweight“-Entwurfsmuster [GHJV95]

Abbildung 13: Die Umsetzung der Kombination von „Strategy“ und „Flyweight“

Abbildung 14: Spiw-Event-Modell mit Event-Handlern

Abbildung 15: Vergleich von Dokumenten mit einem Modell [Ray01]

Abbildung 16: Syntax einer DTD [Ray01]

Abbildung 17: Beziehung zwischen XML Schema, DTD und XML-Dokumenten

Abbildung 18: W3C XML Schema Typ-Hierarchie [Vlis02]

Abbildung 19: Prozessfluss bei der Klassengenerierung

Abbildung 20: Prozessfluss beim Marshalling [McLa02a]

Abbildung 21: Prozessfluss beim Unmarshalling [McLa02a]

Abbildung 22: Data-Binding Kontrollfluss [McLa02]

Abbildung 23: Data-Binding mit dem Microsoft .NET Framework

Abbildung 24: Beispielhafte DOM-Baumstruktur

Abbildung 25: Arbeitsweise einer Anwendung mit SAX-Parser

Abbildung 26: Web Services als mögliche Lösung für Problembereiche im Internet [Weye02]

Abbildung 27: Web Service Rollen, Operationen und Artefakte [Kreg01]

Abbildung 28: Infrastruktur von ASP.NET Web Services

Abbildung 29: SOAP Envelope gemäß SOAP-Spezifikation V1.1 [Weye02]

Abbildung 30: Elemente eines WSDL-Dokuments [Kreg01]

Abbildung 31: Lebenszyklus eines ASP.NET XML Web Services [Weye02]

Abbildung 32: Asynchroner Aufruf eines XML Web Services [Weye02]

Abbildung 33: Übermittlung der Events durch push/pull

Abbildung 34: Übermittlung der Events durch push/push

Abbildung 35: Verarbeitung einer HTTP-Anfrage in ASP.NET [Weye02]

Abbildung 36: Aktualisiertes Klassendiagramm

Abbildung 37: Beispielhafter Ablauf als UML-Sequenzdiagramm

Abbildung 38: Webverweis hinzufügen mit Visual Studio .NET

Abbildung 39: Projektmappen-Ansicht

Abbildung 40: Überblick über die Remoting-Architektur [Weye02]

Abbildung 41: Breitenanwendung von Web Services [CGEY02]

Abbildung 42: Erwartungen an den Geschäftsprozess [CGEY02]

Abbildung 43: Einloggen als Disponent

Abbildung 44: Einloggen als Fahrer

Abbildung 45: Anlegen eines neuen Transportes

Abbildung 46: Abrufen der Events für den Fahrer

Abbildung 47: Ändern eines Transports

Abbildung 48: Abrufen der Events für den Disponenten

Tabellenverzeichnis

Tabelle 1: Anforderungen an den EAM

Tabelle 2: Vor- und Nachteile der einzelnen Granularitätsstufen

Tabelle 3: Vor- und Nachteile des Strategy-Entwurfsmusters

Tabelle 4: Liste möglicher Event-Handler

Tabelle 5: Stärken und Schwächen von DTD und XML Schema

Tabelle 6: Übersicht über die verschiedenen Content Modelle [Vlis02]

Tabelle 7: Typen eines DOM-Node und die entsprechenden Schnittstellen [HaMe01]

Tabelle 8: Vor- und Nachteile von DOM und SAX

Tabelle 9: Member von XmlNodeType

Tabelle 10: Elemente eines WSDL-Dokuments

Tabelle 11: Vor- und Nachteile von Web Services

Quelltextverzeichnis

Listing 1: Das Interface ISpiwEvent

Listing 2: Auszug aus der Datei „mapping.txt“

Listing 3: Instanziierung eines EventHandler-Objektes

Listing 4: Das Grundgerüst eines Schemas

Listing 5: Das Grundgerüst eines Schemas mit Namensraumangabe

Listing 6: Das Grundgerüst eines Schemas mit Namensraumangabe und xsi-Attribut

Listing 7: Das Grundgerüst des SpiwEvent-Schemas

Listing 8: Benutzung eines vordefinierten Typs

Listing 9: Deklaration der ersten SpiwEvent-Attribute

Listing 10: Beschränkung eines Standardtyps

Listing 11: Deklaration eines komplexen Typs

Listing 12: Deklaration des komplexen Datentyps valueType

Listing 13: SpiwEventSchema.xsd

Listing 14: DOM-Beispiel

Listing 15: Lesen eines Attributs

Listing 16: Setzen der Eigenschaft ValidationType

Listing 17: Hinzufügen des Schemas

Listing 18: Hinzufügen der Callback-Methode

Listing 19: Beispielhafter ValidationHandler

Listing 20: Schreiben eines Elements

Listing 21: Grundgerüst der Web Service-Klasse

Listing 22: Angaben zur Schemavalidierung

Listing 23: Types-Sektion des WSDL-Dokuments

Listing 24: Methoden zur Umwandlung eines SpiwEvent-Objektes zu einem String und umgekehrt ..

Listing 25: Grundgerüst des Proxys

Listing 26: Synchrone Methode des Proxys

Listing 27: Asynchrone Methode des Proxys

Listing 28: Korrekte ReceiveEvent-Methode des Proxys

Listing 29: Einfügen des Proxys

Listing 30: Einstellen der Windows-Authentifizierung

Listing 31: Benutzen der Windows-Authentifizierung

Listing 32: Beispielhafter SOAP-Header

Listing 33: Authentifizierungsmethode des Web Services

Listing 34: Benutzen der Authentifizierung über SOAP-Header

Listing 35: Präpozessordirektive

Listing 36: Dynamisches Laden aus einer DLL mit der Activator-Klasse

Listing 37: Dynamisches Laden aus einer DLL mit der Type-Klasse

Listing 38: WSDL-Beschreibung des Web Services

Listing 39: Beispielhaftes SpiwEvent als XML

1 Einführung

Die Diplomarbeit mit dem Titel „Konzeption und Entwicklung eines Event/Action-Mechanismus zur Kommunikation mit mobilen Endgeräten“ entsteht im Rahmen des Forschungsverbundprojektes „Mobile Spedition im Web“ (SpiW). Zunächst wird kurz dieses Projekt vorgestellt, bevor die Aufga- benstellung dieser Arbeit erläutert wird, gefolgt von den vorgegebenen Rahmenbedingungen.

1.1 SpiW - Mobile Spedition im Web

Auf die heutigen Logistikdienstleister kommen, verglichen mit früheren Jahren, eine Menge von gestiegenen Anforderungen zu, die sie bewältigen müssen, um wettbewerbsfähig zu bleiben. So stehen sie unter einem enormen Preisdruck durch den Wegfall von Tarifbindungen und Preisuntergrenzen sowie einer erhöhten Anzahl von Mitbewerbern vor allem aus osteuropäischen Staaten [ErKo01]. Der Preisdruck wird sich durch die neue LKW-Maut noch mehr verschärfen.

Durch die zunehmende Verbreitung des E-Commerce müssen immer kleinere Losgrößen transportiert werden, häufig direkt zu den Endkunden. Dieses erfordert eine höhere Flexibilität in der Disposition und Transportdurchführung [ErKo01]. Auch die Erfüllung individueller Kundenwünsche nimmt eine immer größer werdende Bedeutung für das Speditionsgewerbe ein. Es ist wichtig, dass flexibel auf kurzfristige Anforderungen reagiert wird [ErKr02]. Außerdem erwarten Kunden mittlerweile fast selbstverständlich zeitnahe Informationen über den Auftragsfortschritt sowie die Möglichkeit der Sendungsverfolgung.

Um diesen Anforderungen gerecht zu werden, ist es nötig, die Disposition und Transportdurchfüh- rung flexibler zu gestalten und sie durch den Einsatz zeitnaher Informations- und Kommunikations- systeme zu unterstützen. Zeitnah bedeutet, dass die Fahrer ihren Auftragsfortschritt ständig doku- mentieren, und dieses den Disponenten sofort mitteilen bzw. er ihnen sofort übermittelt wird. So ist es z.B. für den Disponenten wichtig zu erfahren, dass eine Annahmeverweigerung beim Empfänger aufgetreten ist, da die auf dem Fahrzeug verbliebene Ware den weiteren Arbeitsfortschritt behindert. Ist der Disponent gezwungen, diese Informationen aktiv zu beschaffen, wird er in seiner Flexibilität erheblich eingeschränkt [ErKr02].

Ohne den Einsatz eines modernen Kommunikationssystems kommt es zu einer Reihe von Kommuni- kationsproblemen zwischen Disponent, Fahrer und Kunde. So sind Disponent und Fahrer zu einem diskontinuierlichen, mündlichen Informationsaustausch gezwungen, der zu Zeitverzögerungen und Übertragungsfehlern bzw. Missverständnissen führt. Aufgrund fehlender Informationen über den Auftragsfortschritt ist eine kurzfristige Umdisposition nur begrenzt möglich. Außerdem sind Termin- und Sollabweichungen vom Disponenten nur beschränkt steuerbar bzw. korrigierbar. Eine Kalkulati- on der Betriebs- und Transportkosten ist zudem nur mit zeitlicher Verzögerung zu erreichen. Auch der Fahrer bekommt Probleme. So kann er Störungen nur fernmündlich kommunizieren, er hat nur geringen Einfluss auf die Gestaltung seiner Tagestour und er kann den Disponenten bei Rückfragen nicht ständig erreichen. Auf Seiten des Kunden ist der Auftragsfortschritt nicht transparent und Ver- spätungen sind nicht kalkulierbar [ErKo01]. Somit können Logistikunternehmen durch den Einsatz modernen Informations- und Kommunikationstechniken sowie der Integration von Dienstleistungen wie Tracking & Tracing und Auftragsfortschrittskontrolle einen entscheidenden Wettbewerbsvorteil erzielen.

Zu beachten ist, dass die Daten in den Systemen der Disponenten nicht ohne Weiteres in die in den Fahrzeugen installierten Informationssysteme übermittelt werden können, da diese an die Geschäfts- prozesse und Datenstrukturen der Spedition angepasst werden müssten [ErKo01]. Es ist deshalb er- forderlich, eine eigene Plattform einzusetzen, wie z.B. mobile Endgeräte. PDAs oder Handys sind nicht nur kostengünstig und leicht zu handhaben, durch ihre Portabilität können zudem Informationen zeitnah direkt zum Fahrer oder vom Fahrer übermittelt werden. Diese Informationen und deren Verarbeitung können zur Lösung der oben genannten Probleme beitragen.

Die heutigen Kommunikationssysteme für Logistikunternehmen werden immer zusammen mit Logis- tikanwendungen von verschiedensten Herstellern angeboten, wobei die Funktionalität bei diesen integrierten monolithischen Systemen immer unterschiedlich ist. Sie nutzen aber zur Übertragung der Daten allesamt GSM, das lediglich eine geringe Bandbreite (bis 9,6 kBit/s) besitzt. Damit können nur einfache Informationen wie Texte übertragen werden, die Übertragung von Videos oder Fotos ist da- mit nicht möglich. Die Anwendungen nutzen deshalb ebenfalls nur einfache Techniken (SMS, WAP). Der Einsatz neuer Techniken wie z.B. UMTS oder GPRS würde deshalb nicht zwangsläufig zu einer Verbesserung dieser Anwendungen führen, da diese nicht auf die Nutzung der neuen Techniken aus- gelegt wurden [GrSc03].

Es muss deshalb eine Anwendung entworfen und realisiert werden, die auf aktuelle und zukünftige Kommunikationstechniken ausgelegt ist. So lässt sich z.B. eine dauerhafte Kommunikationsverbin- dung aufrecht erhalten oder es lassen sich komplexe Informationen wie Bilder, Straßenkarten, Skizzen oder Videos übertragen. Zur Standortbestimmung und Sendungsverfolgung lassen sich terrestrische Techniken (Location Based Services) ebenso verwenden wie satellitengestützte Techniken (z.B. GPS). Außerdem sollte die Anwendung nicht an ein spezielles Speditionslogistiksystem gebunden sein, sondern es sollen bereits vorhandene Anwendungen verschiedener Anbieter über generische Schnitt- stellen integriert werden können. Durch diese Vorgehensweise wird eine Trennung zwischen den kaufmännischen Dispositions- und Logistiksystemen und dem Kommunikationssystem erreicht. Un- ternehmen sind dadurch nicht mehr gezwungen, monolithische, meist sehr teure Softwaresysteme mit einem großen Funktionsumfang zu kaufen und einzusetzen, nur um die Kommunikationsfunktionali- tät zu nutzen. Existierende Softwaresysteme können weiterhin genutzt werden, so dass sich die Neu- Investitionen in Grenzen halten. Dies ist vor allem für klein- und mittelständische Unternehmen von großer Bedeutung. Durch die Trennung von Kommunikationssystem und Logistiksystemen ist au- ßerdem die getrennte Wartung und Weiterentwicklung der Systeme möglich. Des Weiteren ist zu beachten, dass die Arbeitsabläufe in jedem Logistikunternehmen unterschiedlich sind, deshalb muss das Kommunikationssystem an diese Geschäftsprozesse angepasst werden. Diese Anpassung sollte ohne großen Programmieraufwand möglich sein, daher wird eine dynamische Geschäftsprozesssteue- rung realisiert [GrSc03].

Da das SpiW-Projekt ein Verbundprojekt ist, erfolgt die Entwicklung des Kommunikationssystems interdisziplinär. So werden die Arbeitsprozesse in Speditionsunternehmen analysiert und Verbesse- rungsvorschläge erarbeitet. Die verbesserten Arbeitsprozesse fließen in die Entwicklung des Kommu- nikationssystems mit ein. Es wird ebenfalls untersucht, welche Auswirkungen der Einsatz dieses Sys- tems auf die Arbeitsprozesse hat. Diese Analysen werden von Spezialisten der Universität Dortmund, Fachgebiet Informatik & Gesellschaft, durchgeführt. Durch den Einsatz des Kommunikationssystems erfahren auch die Logistikprozesse eine Veränderung, so können z.B. Güterumschläge oder Begeg- nungsverkehr reduziert werden. Die Analyse und Verbesserung dieser Prozesse übernimmt der Lehr- stuhl für Logistik der Universität Bremen. Der Entwurf und die Realisierung des Systems schließlich erfolgt durch die Universität Leipzig, Lehrstuhl für Angewandte Telematik und e-Business, unter- stützt durch Mitarbeiter der Universität Dortmund, Lehrstuhl für Softwaretechnologie. Als industriel- le Partner konnten die Stute Verkehrs-GmbH in Bremen sowie die Dekra AG in Stuttgart gewonnen werden. Das Projekt hat eine Laufzeit von 30 Monaten und wurde bereits im November 2001 begon- nen.

1.2 Architektur des SpiW-Kommunikationssystems

Da vorhandene Logistikanwendungen verschiedenster Hersteller integriert werden sollen, ist bei der Modellierung der Geschäftsobjekte (Entwurf der fachlichen Architektur) und bei der Erstellung der system- und softwaretechnischen Architektur auf größtmögliche Flexibilität zu achten. Es muss si- chergestellt werden, dass alle Geschäftsobjekte der angebundenen Logistikanwendungen eine Ent- sprechung im Kommunikationssystem haben. Nur so kann garantiert werden, dass alle benötigten Daten zur Verfügung stehen.

1.2.1 Fachliche Architektur

Durch die fachliche Architektur werden die Geschäftsobjekte eines Softwaresystems beschrieben. In objektorientierten Softwaresystemen werden Unternehmensdaten durch solche Objekte repräsentiert. Geschäftsobjekt: Ein Geschäftsobjekt „repräsentiert einen Gegenstand, ein Konzept, einen Ort oder eine Person aus dem realen Geschäftsleben in einem fachlichen geringen Detaillierungsgrad, d.h. einen fachlich elementaren Begriff (Vertrag, Rechnung etc.).“ [Oest98]

Alle Geschäftsobjekte, die in dem System existieren, werden in einem Klassendiagramm dargestellt. Die Notation entspricht der Unified Modeling Language (UML). Kernstück des Modells ist der Trans- port, der im Fokus der Kommunikation zwischen Fahrer und Disponent steht. Die zu einem Transport gehörende Sendung sowie der dazugehörige Auftrag werden dennoch im System abgebildet. Dies ermöglicht dem Fahrer, zusätzliche Informationen einzusehen, die über einen Transport hinausgehen.

Die oberste Ebene ist der Auftrag. Er beinhaltet die Preisvereinbarungen und dient somit letztlich der Abrechnung mit dem Kunden. Der Auftrag wird dann in Teilaufträge zerlegt, so genannte Sendun- gen, die den Warenfluss vom Beladeort (Beladestelle) bis zum Zielort (Entladestelle) beschreiben. Eine Zuweisung zu Fahrzeugen kann auf dieser Ebene noch nicht erfolgen, da weiterhin offen ist, ob die Waren zunächst vorgeholt werden, um sie für Hauptläufe zusammenzufassen, oder ob ein Nachlauf zur Verteilung der Waren an den Endkunden sinnvoll ist. Aus der Unterteilung einer Sendung in Vor- , Haupt- und Nachlauf resultieren die Transporte. Ein einzelner Transport ist für die Durchführung einem Fahrzeug zuzuordnen. Die Durchführung eines einzelnen Transportes besteht aus Sicht des Fahrers aus mehreren abzuarbeitenden Teilprozessen (Jobs). Ein Job kann ein Beladevorgang (Belade- job) oder ein Entladevorgang (Entladejob) sein. Ein Transport enthält eine Menge von Ladungspositi- onen (Ladung). Eine Ladungsposition beschreibt ein Gut bzw. eine Menge von Gütern.

Ein Speditionsfahrzeug kann mehrere Transporte gleichzeitig ausführen. Alle Transporte, die von einem Speditionsfahrzeug ausgeführt werden, werden zu einer Tour zusammengefasst. Eine Tour ist eine Auflistung von Transporten, die der Disponent dem Fahrer zuteilt. Die Zusammenstellung von Transporten zu einer Tour erfolgt durch den Disponenten nach unterschiedlichen Kriterien (Rundrei- se, Planungsintervall (Tag, Woche), Auslieferungs- oder Sammelverkehr). Diese Auflistung von Transporten kann durch den Fahrer nach verschiedenen Kriterien (Kundenpriorisierung, Ladereihen- folge, Zeitfenster, etc.) geändert werden. Die sich daraus ergebende Liste von Transporten wird als Route bezeichnet. Im SpiW-Kommunikationssystem wird allerdings nicht zwischen Tour und Route entschieden. Die folgende Abbildung zeigt das resultierende UML-Klassendiagramm, in dem noch andere Aspekte eingearbeitet sind, wie z.B. Handlungsanweisungen, Transportstati, GPS- Lokalisierung usw. Das SpiW-Datenmodell ist auf den folgenden Seiten dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: SpiW-Datenmodell - Teil 1

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: SpiW-Datenmodell - Teil 2

1.2.2 Systemtechnische Architektur

Die Systemarchitektur des Kommunikationssystems besteht aus drei Komponenten: mobilen Endgeräten für die Fahrer, stationäre Endgeräte für die Disponenten und einem Anwendungsserver. Die mobilen Endgeräte nutzen ein leiterungebundenes Medium wie Mobilfunk (GSM, GPRS, HSCSD, UMTS) zur Kommunikation mit dem Server, die stationären Endgeräte stellen die Verbindung über ein lokales Netzwerk (LAN) her, ein leitergebundenes Medium.

1.2.3 Softwaretechnische Architektur

Die Softwarearchitektur des SpiW-Kommunikationssystems folgt dem Client/Server-Paradigma. Ein Anwendungsprogramm oder ein Prozess fungiert als Client, und eine Anwendung als Server. Der Server ist stets bereit, Daten von einem Client zu empfangen, dieser übernimmt den aktiven Teil des Verbindungsaufbaus und bestimmt dessen Zeitpunkt.

Der Server besteht aus drei Serverkomponenten. Die Datenbank-Komponente ist für das Speichern und Laden der Geschäftsobjekte zuständig. Sie liest die Attribute der Objekte aus und schreibt sie in die Datenbank, umgekehrt erstellt sie ein neues Objekt und füllt die Attribute mit den gelesenen Da- ten. Auch Transaktionsmanagement gehört zu ihren Aufgaben. Die fachlichen Geschäftsprozesse, die durch das Kommunikationssystem unterstützt werden sollen, werden durch sogenannte Workflows beschrieben. Durch jeden Workflow wird genau ein Prozess mit seinen Bedingungen und Entschei- dungen beschrieben. Zu beachten ist, dass sie andere Workflows auslösen oder beeinflussen können. Die Geschäftsprozesse, die für den Server relevant sind, laufen in seiner Workflow-Engine, seiner zweiten Komponente. Der dritte Teil ist der Kommunikationsserver. Er ist für den Austausch von Daten mit den Clients zuständig.

Die Clients gliedern sich in drei Gruppen. Es gibt mobile Clients, die auf den mobilen Endgeräten laufen und mit denen die Fahrer arbeiten, Dispo-Clients, die auf stationären Endgeräten installiert sind und für die Disposition zuständig sind, und Legacy-Systeme wie Speditionssoftwaresysteme, die ebenfalls als Clients angesehen werden. Auf mobilen und Dispo-Clients laufen ebenfalls WorkflowEngines, die die dortigen Arbeitsprozesse steuern. Abbildung 3 veranschaulicht die softwaretechnische Architektur des SpiW-Kommunikationssystems.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Softwaretechnische Architektur des SpiW-Kommunikationssystems

Da Teile der Geschäftslogik auf die Clients verlagert werden, können sie als Thick-Clients bezeichnet werden. Im Gegensatz dazu verfügen Thin-Clients über keine eigene Geschäftslogik, sondern nutzen ausschließlich die vom Server bereitgestellten Dienste. Da Thin-Clients in der Regel weniger Ressour- cen beanspruchen, eignen sie sich daher besonders für Endgeräte mit geringer Prozessorleistung und Speicherausstattung. Trotzdem werden hier Thick-Clients angewendet, da nicht immer sichergestellt werden kann, dass die Kommunikationsverbindung zwischen mobilen Endgeräten und Server über ein leiterungebundenes Medium verfügbar ist. Es ist zwingend erforderlich, dass die Fahrer auch ohne Verbindung weiter mit der Anwendung arbeiten können. Nur so kann die benötigte Flexibilität für die Fahrer trotz fehlender Verbindung sichergestellt werden. Deshalb werden Teile der Geschäfts- logik durch eine lokale Workflow-Engine bereitgestellt. Auf Seiten des Dispo-Clients kommt ebenfalls ein Thick-Client zur Anwendung, obwohl hier ein längerer Ausfall der Kommunikationsverbindung eher unwahrscheinlich ist, da ein leitergebundenes Medium wie LAN (Local Area Network) benutzt wird[GrSc03].

Um Daten zwischen den Clients und dem Server auszutauschen, muss ein Kommunikationsmecha- nismus gefunden werden. Idealerweise wird dieser auch dazu benutzt, externe Speditionssoftware- systeme zu integrieren. Deshalb muss der Mechanismus mindestens folgende Anforderungen erfüllen [GrSc03]:

- Anpassbarkeit: Unterschiedliche Speditionssoftwaresysteme können mit geringem Aufwand integriert werden.
- Flexibilität / Erweiterbarkeit: Neue Anforderungen an das Kommunikationssystem müssen ohne Veränderung des Mechanismus umsetzbar sein.

Aufgrund dieser Anforderungen bietet es sich an, den Mechanismus nach dem Event/Action-Modell zu realisieren. Er wird also zweifach eingesetzt, erstens für den Austausch von Daten zwischen den verschiedenen Clients und dem Server und zweitens für den Austausch von Daten zwischen dem Server und dem Speditionssoftwaresystem; das Format dieser Daten ist XML. Die Entwicklung des Kommunikationsmechanismus ist Gegenstand der Diplomarbeit. Im nächsten Abschnitt wird die Aufgabenstellung genauer erläutert.

1.3 Aufgabenstellung

Es sollen komplexe Objekte, zum einen Geschäftsobjekte, zum anderen Ereignisse (Events), übertragen werden, die dann auf dem Server bzw. auf den Clients Aktionen auslösen. Die Geschäftsobjekte und Events müssen vor der Übertragung in ein XML-Format umgewandelt und nach der Übertragung wieder zurück gewandelt werden. Dieser Mechanismus muss sowohl auf dem Server als auch auf den Clients zur Verfügung stehen.

In der Arbeit soll ein Konzept erstellt werden, durch das Ereignisse und Geschäftsobjekte mit XML beschrieben werden können. Das Konzept muss flexibel erweiterbar sein, um auf geänderte Rahmen- bedingungen (neue Ereignisse und Geschäftsobjekte) eingehen zu können. Dann muss überlegt wer- den, wie ein solches XML-Dokument erzeugt werden kann bzw. wie aus einem XML-Dokument Ob- jekte erzeugt werden können. Die tatsächliche Übertragung von XML zum Server bzw. zu den Clients ist auch Teil dieser Arbeit. Außerdem soll bei auftretenden Events eine Ableitung erfolgen, welche Aktionen ausgeführt werden müssen (Mapping). Die prototypische Realisierung, durch die die Prak- tikabilität des Gesamtkonzeptes nachgewiesen werden soll, muss sich problemlos in die SpiW- Architektur einfügen können.

1.4 Vorgehensweise

In Kapitel 2 wird der Event/Action-Mechanismus spezifiziert, indem das dazugehörige Event-Modell definiert wird und die Verknüpfungen zwischen Ereignissen und resultierenden Aktionen festgelegt werden. In Kapitel 3 wird ein entsprechendes XML-Datenformat definiert, bevor in Kapitel 4 untersucht wird, wie aus Objekten XML-Dokumente werden bzw. umgekehrt aus XML-Dokumenten wieder Objekte werden. In Kapitel 5 wird schließlich der Übertragungsweg bestimmt.

1.5 Rahmenbedingungen

Die einzusetzende Entwicklungsumgebung ist Microsoft Visual Studio .NET 2003. Mit Microsoft .NET steht eine vorgefertigte Infrastruktur zur Verfügung, mit der sich übliche Probleme bei der Entwick- lung von Internet-Applikationen lösen lassen. Die Entwicklungsumgebung baut dabei auf dem .NET Framework auf. Diese Laufzeit-Umgebung unterstützt den Programmierer, guten und stabilen Code schnell zu schreiben, zu verwalten, einzusetzen und zu überarbeiten [Plat01]. Es bildet die Basis für alle .NET Anwendungen. Die Programmiersprache, die für die Umsetzung des SpiW- Kommunikationssystems und somit für die Implementierung des Event/Action-Mechanismus benutzt werden soll, ist C# .NET (im folgenden kurz C# genannt). Die folgende Abbildung veranschaulicht die Struktur des .NET Frameworks.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das .NET Framework im Überblick [Weye02]

Die Basis für die Ausführung von Code ist die Common Language Runtime (CLR). Der Programmie- rer entwickelt mit einer einheitlichen Klassenbibliothek, der Base Class Library (BCL). Aufbauend auf der BCL kann ein Entwickler dann Datenbank- und XML-orientierte Applikationen erstellen. Die Imp- lementierung Web-basierter Applikationen ist ein großer Bestandteil der Programmierung mit dem .NET Framework. Diese Applikationen lassen sich in zwei Teile zerlegen. Zum einen die Applikatio- nen mit grafischer Benutzungsoberfläche für die Interaktion mit den Anwendern, zum anderen die XML Web Services, die in Kapitel 5 noch genauer erläutert werden. Zur Implementierung stehen ver- schiedene Programmiersprachen zur Auswahl. Diese Sprachen entsprechen den Richtlinien der Common Language Specification (CLS). Sie sind innerhalb von .NET absolut gleichberechtigt. Somit ist es egal, welche Sprache genutzt wird, der erzeugte Code wird immer von der CLS ausgeführt [Weye02].

Während die Server-Komponente für die Kommunikation sowie die Clients für die Disponenten mit Hilfe des .NET Frameworks entwickelt werden, wird für die Implementierung der mobilen Clienten das Microsoft .NET Compact Framework genutzt. Dies ist quasi die „Light“-Version des .NET Fra- meworks. Es enthält lediglich einen Teil der BCL des „großen“ Frameworks sowie einige wenige neue Klassen, die speziell für den Einsatz auf mobilen Endgeräten zugeschnitten sind. Dazu gehören z.B. Klassen zur Benutzung einer Infrarot-Schnittstelle (IrDA). Die CLR des Compact Frameworks ist komplett neu implementiert, um effizient auf den in Sachen Speicher und Prozessorleistung einge- schränkten mobilen Endgeräten laufen zu können. Die ersten Ausgabe des Compact Frameworks ist für die Betriebssysteme Microsoft Pocket PC 2000 und 2002 sowie Windows CE .NET Version 4.1 (o- der später) ausgelegt. Die einzusetzende Entwicklungsumgebung Visual Studio .NET 2003 enthält alle Tools und Bibliotheken, die der Entwickler braucht, um Applikationen zu erstellen, die auf mobilen Endgeräten laufen, auf denen das Compact Framework installiert ist.

Für die prototypische Testumgebung des SpiW-Kommunikationssystems steht als mobiles Endgerät ein HP iPAQ 3660 mit Pocket PC 2002 zur Verfügung. Die Server-Komponente ist auf einem PC (Intel Pentium 4, 2,0 GHz, 1 GB RAM, Windows 2000 Server) installiert, der Dispo-Client läuft dort eben- falls. Da hier auch Visual Studio .NET 2003 installiert ist, dient er gleichzeitig als Entwicklungsplatt- form.

2 Event/Action-Mechanismus

Es wird ein Event/Action- Mechanismus (im folgenden EAM) gesucht, mit dem sowohl auftretende Ereignisse wie ein Stau, ein Unfall oder ein Systemfehler als auch Geschäftsobjekte zu und von mobi- len Endgeräten übertragen werden können. Zuerst werden die zentralen Begriffe erläutert, mit einer Einordnung in den wissenschaftlichen Kontext, bevor dann die Anforderungen an den zu entwi- ckelnden EAM untersucht werden. Ist dies geschehen, kann damit begonnen werden, den EAM ge- nau zu spezifizieren. Hierfür wird eine (oder mehrere) Event-Klasse(n) definiert, dann das dazugehö- rige Event-Modell festgelegt, und anschließend wird diskutiert, wie die Beziehungen zwischen auftre- tenden Ereignissen und durch sie auszulösende Aktionen (Mapping) flexibel und erweiterbar gestaltet werden kann.

2.1 Begriffe

In diesem Kapitel werden die zentralen Begriffe erläutert, die man kennen muss, um zu verstehen, was ein EAM ist. In der Literatur finden sich unzählige Definitionen für ein und den selben Begriff, weshalb jeweils eine Definition ausgewählt wird.

2.1.1 Event

Der Begriff „Event“ bedeutet, aus dem Englischen übersetzt, nichts anderes als „Ereignis“. Irgendwo im System passiert etwas (man sagt: „Ein Event tritt auf“), und bestimmte Parteien sind daran interes- siert, davon zu erfahren, um entsprechend reagieren zu können. In der Literatur gibt es viele ver- schiedene Definitionen von Events. [McPR03] z.B. definiert ein Event als das Abbild eines asynchro- nen Ereignisses. In [DiGa00] wird ein Event (hier: Ereignis) folgendermaßen definiert: „ Ein Ereignis kennzeichnet ein bestimmtes punktuelles Geschehnis, dem letztlich immer ein Zeitpunkt zugeordnet werden kann; es legt also ein WAS und ein WANN fest. “ Laut [GrTh00] kann über ein Event „ das Eintreten einer spezifischen Situation innerhalb eines Softwaresystems “ signalisiert werden. Ein Event wird in dieser Ar- beit wie folgt definiert:

Event: Ein Event ist das Abbild eines asynchronen Ereignisses innerhalb eines Softwaresystems, auf welches das Programm reagieren muss.

Ein solches Ereignis kann ein Mausklick oder ein Tastendruck auf der Oberfläche des Programms, oder auch eine Veränderung einer bestimmten Variablen, ein auftretender Fehler oder unendlich viele weitere Möglichkeiten sein. Im objektorientierten Sinne muss man unterscheiden zwischen der Event- Klasse und einem Event-Objekt, einer Instanz der Event-Klasse. Events können in primitive und zu- sammengesetzte Events unterschieden werden. Zusammengesetzte Events können als Erweiterung der primitiven Events verstanden werden, und bestehen aus primitiven oder selbst wieder zusam- mengesetzten Events [DiGa00].

Häufig ist es auch noch wichtig zu wissen, wo ein Event erzeugt bzw. ausgelöst wurde. Dieser Ort nennt sich Event-Quelle, häufig auch Supplier oder Auslöser.

Event-Quelle: Die Komponente, in der das Event ausgelöst wurde, heißt Event-Quelle.

2.1.2 Event-Listener

Das Eintreten eines Ereignisses kann für manche Parteien von großem Interesse sein. Diese müssen dann benachrichtigt werden, um auf das Ereignis reagieren zu können. Diese Parteien werden Event- Listener, in der Literatur aber auch häufig Consumer (Konsumenten) oder Empfänger genannt.

Event-Listener: Objekte, die über das Auftreten eines Events benachrichtigt werden sollen, heißen Event-Listener (oder kurz: Listener).

Diese Listener sind jeweils auf bestimmte Event-Klassen spezialisiert, d.h. für jede Event-Klasse gibt es einen Event-Listener. Beim Auftreten eines Events wird eine standardisierte (dem Event zugeordnete) Methode bei allen für diese Event-Klasse angemeldeten Listener-Objekten aufgerufen, wodurch dann eine oder mehrere Event-Actions ausgeführt werden.

Event-Action: Eine Event-Action (oder kurz: Action) spezifiziert, wie auf das Eintreten eines Events reagiert werden soll.

Wichtig ist, dass diese Aktionen asynchron aufgerufen werden. Synchrone Methodenaufrufe können zu Verzögerungen (Delays) beim Aufrufenden führen.

Die Aktionen werden in einem Event-Handler gebündelt. Dieser kann eine eigene Klasse sein, oder aber der Event-Listener enthält die Handling-Methoden.

Event-Handler: Ein Event-Handler beinhaltet die Aktionen, die ausgeführt werden, um auf ein be- stimmtes Event zu reagieren.

Ist ein Listener für mehrere Events registriert, muss festgelegt werden, welche Events welche Aktionen bedingen.

Event-Action-Mapping: Die Zuordnung zwischen Event und der auszuführenden Aktion nennt man Event-Action-Mapping.

2.1.3 Event-Modell

Alle bisher beschriebenen Bestandteile können in einem Event-Modell zusammengefasst werden:

Event-Modell: Ein Event-Modell besteht aus einer Menge von Regeln, die ein Kommunikations- modell beschreiben, das auf Events basiert [MeCa02].

Diese Regeln legen z.B. fest, wie die Events verschickt werden oder ob die Listener direkt oder indirekt aufgerufen werden. Es gibt drei verschiedene Kategorien von Event-Modellen: Peer-to-Peer, Mediator und Impliziter Aufruf [MeCa02]. Ein Peer-to-Peer Event-Modell erlaubt es Event-Listenern, sich direkt bei Event-Quellen zu registrieren und es erlaubt Event-Quellen, den registrierten EventListener die jeweiligen Events direkt zukommen zu lassen. Ein Beispiel für ein solches Modell ist ist die Arbeit von [BBHM95] oder auch das Java 1.1 Delegation Event Model.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Java 1.1 Delegation Model [Meie99]

Der Event-Listener registriert sich bei der Quelle (Event Source). Tritt ein Event auf, schickt die Quelle allen registrierten Listenern das jeweilige Event zu, indem es die korrekte Methode (fooOccurred oder fooHappened) aufruft.

Event-Modelle, die einen Vermittler (Mediator) benutzen, erlauben Listener, sich bei einem bestimm- ten Mediator zu registrieren. Die Quellen senden ein auftretendes Event an diesen Vermittler, der dann die entsprechenden Listener informiert. Der Vorteil dieser Architektur ist, dass das Filtern der Events nicht mehr den Event-Quellen überlassen wird, sondern nun zentral beim Vermittler ge- schieht. Dadurch werden die Quellen entlastet. Ein Mediator kann noch weitere Funktionalitäten beinhalten. So kann durch den Einsatz eines Vermittlers verhindert werden, dass Events, die für mo- bile Benutzer interessant sind, verloren gehen, falls die Benutzer nicht mit dem System verbunden sind. Er speichert die Events ab, und sobald der Benutzer wieder verfügbar ist, sendet er ihm die gela- gerten Events. Alternativ kann der Benutzer auch diese Events abrufen [BMBH00].

Ein weiterer Vorteil bei der Benutzung eines Vermittlers ist, dass die Event-Quellen unberührt bleiben, wenn Event-Listener hinzugefügt oder entfernt werden. Andersherum benötigen die EventListener keine Kenntnisse über die Event-Quellen. Außerdem ist es möglich, auch Quellen hinzuzufügen oder zu entfernen, ohne die Listener zu ändern [HaLS97].

Der CORBA Event Service (COS) nutzt einen solchen Vermittler („Event Channel“), die folgende Abbildung veranschaulicht die Architektur:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Bestandteile der COS Event Channel Architektur [HaLS97]

Die Consumer sind die Ziele der Events, also quasi die Event-Listener, die Supplier die Quellen. Beide Parteien können sowohl aktiv (push) als auch passiv (pull) sein. Die zentrale Rolle spielt der Event Channel, der zwischen Consumer und Supplier vermittelt. Dabei tritt er als Proxy auf: er erscheint dem realen Supplier als Consumer auf der einen Seite, und erscheint dem realen Consumer als Supplier auf der anderen Seite des Channels. [HaLS97] legen den Fokus aber auf das push-Modell.

Bei einem impliziten Event-Modell registrieren sich die Event-Listener für verschiedene Event-Typen; tritt dann ein solches Event auf, werden die dafür registrierten Listener benachrichtigt. Die „Cambridge event architecture“ basiert auf einem impliziten Event-Modell, dem „publish-register-notify“- Paradigma [BMBH00].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Cambridge event architecture [BMBH00]

Jedes Event hat, neben seinen normalen synchronen Methodenaufrufen, eine Methode, mit der Clients sich für ein bestimmtes Event registrieren können. Tritt ein solches Event auf, wird eine Nachricht an den Client geschickt. Diese Architektur lässt sich gut mit den beiden oberen Event-Modellen kombi- nieren.

Die vorgestellten Event-Modelle arbeiten alle nach dem push-Prinzip: die Events werden den Listenern zugestellt. Allerdings sind auch alle Lösungen plattformabhängig, was ihren Einsatz bei der Integration von Legacy-Systemen schwierig gestaltet. Deshalb ist nach einem eigenen Modell zu suchen. Möchte man einen EAM für das SpiW-Kommunikationssystem entwickeln, muss man sowohl das Event-Modell definieren als auch das Mapping erstellen.

Event/Action-Mechanismus: Ein Event/Action-Mechanismus (EAM) besteht aus zwei Teilen: dem Event-Modell und dem Event-Action-Mapping.

2.2 Anforderungen

Als nächstes bietet es sich an, die in Kapitel 1.2.3 angerissenen Anforderungen an den EAM genauer zu analysieren bzw. zu erweitern.

2.2.1 Übertragung aller Daten

Die erste Anforderung an den zu entwickelnden Event/Action-Mechanismus ist, dass alle in dem SpiW-Kommunikationssystem anfallenden Daten übertragen werden sollen, und zwar in Form von Events. Das betrifft sowohl auftretende Ereignisse als auch Geschäftsobjekte. Die im SpiWKommunikationssystem existierenden Geschäftsobjekte können Kapitel 1.2.1 entnommen werden. Ereignisse im Kommunikationssystem können sein:

- Melden neuer Transporte an den Fahrer
- An-/Abmelden Disponent/Fahrer
- Neuen Fahrer im System anlegen
- Neuen Transport im System anlegen
- Neue Transportposition im System anlegen
- Änderung der Transportdaten durch den Disponent
- Anpassung einer Tour und Bildung einer Route
- Änderung der Transportdaten durch den Fahrer
- Informierung des Disponenten über Änderung von Transportdaten durch den Fahrer
- Benachrichtigung des Fahrers über einen neuen Transport
- Mitteilung von Routenänderungen
- Systemfehler

Im Prinzip kann man alle nur denkbaren Ereignisse durch Events übertragen, es muss also darauf geachtet werden, dass neue Events leicht hinzugefügt werden können (siehe 2.2.2).

2.2.2 Erweiterbarkeit / Flexibilität

Der EAM muss so gestaltet werden, dass er bei einem neuen Ereignis oder einem neuen Geschäftsobjekt ohne großen Aufwand erweitert werden kann. Da zum Zeitpunkt der Entwicklung nicht bekannt ist, welche Geschäftsobjekte neu dazu kommen könnten, muss das Ganze so entworfen werden, dass alle denkbaren Geschäftsobjekte übertragen werden können.

2.2.3 Anpassbarkeit

Unterschiedliche Speditionssoftwaresysteme sollen ohne großen Aufwand integriert werden können. Es müssen Anpassungen an schon bestehenden Geschäftsobjekten und Ereignissen leicht möglich sein.

2.2.4 Zuverlässigkeit

Da der Event/Action-Mechanismus in einer mobilen Anwendung eingesetzt werden soll, d.h. das System läuft in mobilen Endgeräten, muss der EAM zuverlässig sein. Es dürfen keine Events verloren gehen oder fehlgeleitet werden.

2.2.5 Sicherheit

Der Übertragungsweg muss sicher sein, d.h. Dritte dürfen nicht an die übertragenden Daten gelangen. Dazu müssen Verschlüsselungs- und Authentifizierungsmechanismen eingebaut werden.

2.2.6 Geringe Datenmenge

Da die Daten über Mobilfunk übertragen werden sollen, sollte die Datenmenge möglichst klein sein, um die anfallenden Übertragungskosten zu minimieren.

2.2.7 Schnelligkeit

Auftretende Ereignisse sollten möglich schnell beim Empfänger ankommen, nur so kann ein Fahrer oder ein Disponent schnell und flexibel auf solche Ereignisse reagieren. Dazu zählt nicht die Bandbreite des Übertragungsmediums, denn die ist nicht beeinflussbar (Festlegung auf Mobilfunk). Ferner ist die Zeit gemeint, die benötigt wird, ein Event zu generieren und die Zeit, die ein Empfänger braucht, auf ein erhaltendes Events zu reagieren.

2.2.8 Skalierbarkeit

Der EAM muss auch mit einer großen Anzahl von Anwendern zurecht kommen. In einem großen Logistikunternehmen können mehrere hundert Fahrer und Disponenten beschäftigt sein. Außerdem muss der Mechanismus mit einer steigenden Anzahl von Geschäftsobjekten umgehen können.

2.2.9 Plattformunabhängigkeit

Durch den EAM sollen Legacy-Systeme einfach und ohne große Anpassungen angebunden werden. Deshalb ist es nötig, dass der Mechanismus plattformunabhängig gestaltet wird.

Die Anforderungen an den zu entwickelnden Event/Action-Mechanismus noch mal im Überblick:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Anforderungen an den EAM

2.3 Lösung

Der erste Schritt, ein Event-Modell zu entwickeln, das den obigen Anforderungen genügt, besteht darin, die Event-Klasse(n) zu spezifizieren, die übertragen werden soll(en). Die wichtigste Entscheidung bei der Spezifikation ist, die optimale Granularität der Events zu bestimmen.

2.3.1 Optimale Granularität

Werden die Events zu grob granular definiert, könnten unter Umständen wichtige Informationen verloren gehen bzw. nicht darstellbar sein. Ist die Granularität zu fein gewählt, könnte der Programmieraufwand sehr hoch werden. Da sowohl Ereignisse als auch Geschäftsobjekte übertragen werden sollen, gibt es folgende Alternativen:

1. Zu jedem Attribut jedes Geschäftsobjektes und für jedes Ereignis eine Event-Klasse (feine Granularität)
2. Zu jedem Geschäftsobjekt und für jedes Ereignis eine Event-Klasse (mittlere Granularität)
3. Nur eine einzige Event-Klasse (grobe Granularität) Jede Alternative wird im folgenden näher beleuchtet.

2.3.1.1 Feine Granularität

Für jedes Attribut jedes Geschäftsobjektes und für jedes Ereignis wird eine Event-Klasse definiert. Ändert sich zum Beispiel die Stückzahl einer Transportposition, wird ein „Transportposition- Stückzahl-Update“-Event verschickt. Diese Lösung hat den Vorteil, sehr einfache Event-Klassen defi- nieren zu können, die jeweils nur einem bestimmten Zweck dienen und somit leicht zu warten sind. Allerdings wird man mit dieser Vorgehensweise eine sehr große Anzahl von Klassen erhalten, wo- durch die Übersichtlichkeit leiden dürfte. Außerdem gibt es für jede Event-Klasse als „Gegenstück“ einen Event-Listener (siehe 2.1), womit man dann auch eine große Anzahl von Listener-Klassen erhält. Möchte man das zu Grunde liegende Datenmodell erweitern, in dem man zum Beispiel einem Ge- schäftsobjekt ein neues Attribut gibt, muss eine neue Event-Klasse (und somit auch eine neue Event- Listener-Klasse) definiert und implementiert werden. Ein EAM, der mit fein granularen Events arbei- tet, ist also schwer zu erweitern und somit nicht sehr flexibel. Ein weiteres Problem tritt auf, wenn man ganze Geschäftsobjekte verschicken will: für jedes Attribut muss ein separates Event gesendet werden, was einen ungerechtfertigt hohen Aufwand erzeugt.

2.3.1.2 Mittlere Granularität

Zu jedem Geschäftsobjekt und jedem Ereignis wird eine Event-Klasse definiert. Neue Attribute bedin- gen bei dieser Lösung keine neuen Event-Klassen, sondern nur neue Geschäftsobjekte oder Ereignisse. Die Event-Struktur ist leicht nachzuvollziehen. Beim Einfügen ganzer Geschäftsobjekte muss nur ein Event verschickt werden. Bespiele für Events sind „Transportposition-Update“ oder „Transport- Insert“. Trotzdem ergeben sich noch relativ viele Event-Klassen, die jetzt auch etwas schwieriger zu warten sind, und man braucht auch viele Event-Listener, nämlich für jede Event-Klasse einen. Somit ist auch diese Lösung schwierig zu erweitern. Ein großes Problem stellen auch Geschäftsobjekte dar, die Attribute eines anderen Geschäftsobjektes sind. Man muss die Frage klären, ob die Unterobjekte in das selbe Event gekapselt werden oder in separate Events. Dann muss aber eine Verknüpfung der Unterobjekte mit dem Oberobjekt existieren.

2.3.1.3 Grobe Granularität

Es wird nur eine globale Event-Klasse definiert, die alle möglichen Geschäftsobjekte und Ereignisse in sich kapseln kann. Die Vorteile liegen auf der Hand: man braucht nur einen Event-Listener, Änderungen geschehen nur an einer zentralen Stelle, wodurch das Konzept gut erweiterbar ist. Allerdings gibt es auch Nachteile: die resultierende Event-Klasse könnte sehr kompliziert und unübersichtlich werden, und es entspricht nicht unbedingt dem Sinn des objektorientierten Programmierens. Wie auch bei der mittleren Granularität muss das Problem der Unterobjekte gelöst werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Vor- und Nachteile der einzelnen Granularitätsstufen

2.3.2 SpiwEvent

Es gilt nun, die Vor- und Nachteile der vorgestellten Alternativen abzuwägen und dadurch zu einer optimalen Lösung zu gelangen. Um das Konzept so flexibel und erweiterbar wie möglich zu gestalten, sollte man nur eine globale Event-Klasse definieren. Diese muss aber in der Lage sein, alle existieren- den Geschäftsobjekte sowie alle auftretenden Ereignisse in sich zu kapseln. Außerdem muss die Klas- se auch geänderte bzw. neue Geschäftsobjekte und Ereignisse kapseln können. Ein Listener muss leicht ermitteln können, welches Ereignis ein Event-Objekt gerade repräsentiert bzw. welches Ge- schäftsobjekt ein Event-Objekt gerade in sich trägt. Dies bedeutet, dass sich nur der Inhalt eines Event- Objektes ändert, nicht die Struktur.

Wie kann ein Listener erkennen, welches Ereignis durch ein ankommendes Event-Objekt dargestellt wird? Würden verschiedene Event-Klassen existieren, würde automatisch der richtige Listener und somit der korrekte Event-Handler aufgerufen. Da es aber nur eine Event-Klasse gibt, muss sie einen (oder mehrere) Schlüssel in sich tragen, die das jeweilige Ereignis anzeigen. Denkbar wäre zum Bei- spiel ein Schlüsselpaar: erstens einen Schlüssel („CategoryKey“), der die Haupt-Kategorie anzeigt (also z.B. Insert, Update, Delete) und zweitens einen Schlüssel („SubKey“), der, falls nötig, eine Unter- kategorie repräsentiert.

Falls ein Event-Objekt ein Geschäftsobjekt kapselt, muss auch hier der Listener wissen, welches Objekt genau gemeint ist. Dies wird durch den Schlüssel „ObjectType“ angezeigt. Die Attribute der Ge- schäftsobjekte sind in einer Tabelle (Hashtable) gespeichert. Ein Eintrag in dieser Tabelle besteht aus einem eindeutigen Schlüssel, der den Namen des Attributes anzeigt, und dem Wert des Attributs. Dadurch ist sichergestellt, dass alle vorhandenen und zukünftigen Attribute in diese Tabelle eingetra- gen (und leicht wieder ausgelesen) werden können. Die Attribut-Schlüssel müssen dem Event- Listener bekannt sein.

Ein noch zu lösendes Problem wurde schon weiter oben angerissen: Was ist, wenn ein Attribut eines Geschäftsobjektes selbst ein Geschäftsobjekt ist? Die Lösung ist einfach: das Unterobjekt wird in ein separates Event umgewandelt, das dann in die Attribut-Tabelle des Oberobjektes eingetragen wird. Durch diese Vorgehensweise entsteht ein zusammengesetztes Event, das eine Baumstruktur beinhal- tet, die rekursiv durchlaufen werden kann. Ein einfaches Beispiel: Ein Transport hat mehrere Unterob- jekte, z.B. Lieferschein, Belade- und Entladestelle und Transportpositionen. Jede Transportposition hat noch zwei Unterobjekte, Status und Barcode. Um nun das Transportobjekt in ein Event umzuwan- deln, müssen erst rekursiv die Unterobjekte durchlaufen und diese jeweils in Events gekapselt wer- den. Auch die Rückrichtung muss funktionieren: die Events müssen wieder in die jeweiligen Ge- schäftsobjekte gewandelt werden. Die folgende Abbildung veranschaulicht den Sachverhalt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Rekursive Umwandlung von Geschäftsobjekten zu Events

Das beschriebene Event wird „SpiwEvent“ genannt, und wird als Schnittstelle „ISpiwEvent“ spezifi- ziert. Es gibt Set- und Get-Methoden zum Setzen und Lesen der einzelnen Attribute eines Events. Die Attribute categoryKey, subKey, objectType und die Hashtable Attributes wurden schon oben er- klärt. Damit nicht immer alle Listener alle Events bekommen, wird in jedem Event das Ziel eingetra- gen (target). Dies ist quasi der Schlüssel, nach dem entschieden wird, welchem Event-Listener wel- ches Event zugestellt wird. Um zu ermitteln, von wo das Event kommt, kann man das Attribut sour- ce auslesen. Im Attribut message kann man noch bei Bedarf eine kurze Nachricht eintragen. uuid ist die eindeutige ID des Objekts, und parentUuid die ID eines eventuellen Eltern-Objektes. Der C#- Quelltext sieht folgendermaßen aus:

Abbildung in dieser Leseprobe nicht enthalten

Listing 1: Das Interface ISpiwEvent

2.3.3 Event-Modell

Nach der Definition des Events, das verschickt werden soll, muss noch das zu Grunde liegende Event- Modell spezifiziert werden. Wie schon in Kapitel 2.1 erwähnt, gibt es drei Kategorien von Event- Modellen: Peer-to-Peer, Mediator und Impliziter Aufruf. Da es sich um ein verteiltes System handelt, d.h. die Event-Listener befinden sich in den mobilen Clients, wird ein Mediator-Event-Modell bevor- zugt. In einer Vemittler-Klasse könnten Mechanismen eingebaut werden, um Verbindungen aufzu- bauen, Events zwischenzuspeichern, Übertragungssicherheit herzustellen usw. Hier das dazu gehöri- ge UML-Klassendiagramm:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Das Spiw-Event-Modell

Die Schnittstelle ISpiwEvent wurde schon in 2.3.2 vorgestellt. Ein Event-Listener registriert sich beim Mediator über die Methode AddEventListener. Möchte die Quelle ein Event verschicken, ruft es die Methode ReceiveEvent auf und übergibt dem Mediator das zu sendende Event. Da, wie in 2.3.2 be- reits erwähnt, das Ziel im Event gespeichert ist, weiß der Vermittler, welchem Listener er es schicken soll. Er durchsucht dafür die Liste der bei ihm registrierten Event-Listener. Ist das Ziel registriert, ruft der Mediator im jeweiligen EventListener-Objekt die Methode DoAction auf. Dieses Modell arbeitet somit nach dem push-Prinzip: die Event-Listener sind passiv, sie werden vom Vermittler benachrich- tigt, die Events werden ihnen zugestellt.

2.3.4 Mapping von Ereignissen nach Aktionen

Aus den in 2.2 ausgeführten Anforderungen ergibt sich, dass ein flexibles und ohne großen Aufwand erweiterbares und änderbares Mapping-Verfahren benötigt wird. Je nachdem, welches Event gerade auftritt, müssen bestimmte Aktionen angestoßen werden. Diese Aktionen finden in einem Event- Handler statt, der wiederum von einem der Event-Listener aufgerufen wird. Die Aktionen könnte sich im Laufe einer Software-Evolution ändern (es wäre z.B. denkbar, dass eine andere Datenbank ange- bunden werden soll), oder es kommen weitere Aktionen dazu. Somit wäre es sicherlich wünschens- wert, den Event-Handler einfach auszutauschen, oder aber wenigstens leicht zu modifizieren.

Es existiert ein Entwurfsmuster, das bei diesem Problem anwendbar ist. Es heißt „Strategy“ und definiert eine Familie von Algorithmen, wobei jeder dieser Algorithmen einzeln gekapselt wird und somit austauschbar ist. Je nach Situation kann dann ein anderer Algorithmus angewendet werden [GHJV95]. Die Struktur des Entwurfsmusters sieht folgendermaßen aus:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Das „Strategy“-Entwurfsmuster [GHJV95]

Die Klasse Strategy deklariert ein Interface, über das alle erbenden Klassen angesprochen werden können. Sie kann, wie in der Abbildung, als abstrakte Klasse oder als Interface realisiert werden. Die Klassen ConcreteStragety erben von Strategy und implementieren den konkreten Algorithmus. Die Klasse Context schließlich aggregiert ein Strategy-Objekt. Über die Methode ContextInterface könnte, wenn nötig, das Strategy-Objekt auf Daten des Context-Objektes zugreifen.

Die Vorteile bei der Nutzung dieses Entwurfsmusters liegen auf der Hand. Hierarchisch angeordnete Strategy-Klassen bilden eine Familie von verwandten Algorithmen. Durch Vererbung können be- stimmte Funktionalitäten der Algorithmen wiederverwendet werden. Außerdem sind die Algorith- men durch die Kapselung in separate Klassen leichter austauschbar, verständlicher und erweiterbar. Durch diese Vorgehensweise werden lange Konditionalanweisungen wie if-schleifen oder switch- Anweisungen vermieden. Es gibt aber auch potentielle Nachteile des Entwurfsmusters. Die Context- Klasse muss die einzelnen Strategy-Klassen kennen und deren Unterschiede verstehen. Sie muss wissen, welche Strategy-Klasse in welcher Situation eingesetzt werden kann bzw. muss. Außerdem entsteht eine erhöhte Anzahl von Objekten in der Anwendung, was sich negativ auf die Performance und den Speicherbedarf auswirken könnte.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Vor- und Nachteile des Strategy-Entwurfsmusters

Wird Strategy bei dem Event-Handler-Problem angewandt, so muss für jedes Event ein Event- Handler (ConcreteStrategy) definiert werden. Alle Event-Handler lassen sich über dieselbe Schnitt- stelle ansprechen (Strategy). Der Event-Listener (Context) muss dann in der Lage sein, den korrek- ten Event-Handler für das empfangene Event aufzurufen. Dieser kann, bei Bedarf, über die Schnitt- stelle ListenerInterface() auf Daten des Listeners zugreifen. In UML-Notation sieht das so aus:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Die Umsetzung des „Strategy“-Entwurfsmusters

Die Methode ListenerInterface der Klasse EventListener könnte in der endgültigen Implementierung durch statische Methoden ersetzt werden, so dass die Event-Handler keine Instanz des EventListeners benötigen, sondern nur den Namen der Klasse kennen müssen.

In der obigen Abbildung wurden exemplarisch nur drei konkrete Event-Handler aufgeführt. Es gibt weitere, für jede mögliche CategoryKey/SubKey-Kombination einen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Liste möglicher Event-Handl

Ein Nachteil des Strategy-Entwurfsmusters ist, wie oben beschrieben, die erhöhte Anzahl von Objek- ten, die zu Performance-Problemen und erhöhten Speicherbedarf führen könnten. Um diesen entge- gen zu wirken, wäre es vorteilhaft, wenn alle EventListener die EventHandler-Objekte gemeinsam nutzen würden. Diese würden dann nur jeweils einmal im System (je Anwendung) existieren. Auch für dieses Problem existiert ein Entwurfsmuster, nämlich das „Flyweight“-Entwurfsmuster:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Das „Flyweight“-Entwurfsmuster [GHJV95]

Die Klasse Flyweight ist eine abstrakte Klasse (oder ein Interface), die eine Schnittstelle bildet, über diese die konkreten Flyweights fremde Daten (extrinsicState) empfangen und verarbeiten können. Die Klasse ConcreteFlyweight implementiert die Schnittstelle und verwaltet eigene Daten (intrin- sicState). Die Objekte müssen gemeinsam benutzt werden können, sie dürfen keine externen Daten speichern, um kontextunabhängig agieren zu können. Die Objekte der UnsharedConreteFlyweight- Klasse dagegen werden nicht geteilt, sind deshalb nicht auf interne Daten beschränkt. Die Flyweight- Factory ist für die Erzeugung und Verwaltung der Flyweight-Objekte zuständig. Der Client stellt die Anfrage für eine Referenz auf ein Flyweight-Objekt, und speichert außerdem die externen Daten, die den Flyweights beim Aufruf von Operation zur Verfügung gestellt werden (allerdings speichern sie diese Daten nicht s.o.).

Die Benutzung des Flyweight-Entwurfsmusters könnte Kosten zur Laufzeit bedingen, für das Auffinden und Erzeugen der Flyweight-Objekte. Allerdings werden diese Kosten durch Speicherplatzreduzierungen aufgehoben. Je mehr Objekte geteilt werden, desto größer sind diese Einsparungen. Durch die Benutzung von gemeinsamen Speicher (extrinsicState) wird noch mehr eingespart.

Dieses Entwurfsmuster eignet sich hervorragend zur Kombination mit dem „Strategy“- Entwurfsmuster. Die ConcreteStrategy-Klassen (bzw. die EventHandler) können als Flyweights realisiert werden. Der EventListener spielt die Rolle des Clients, und die EventHandlerFactory ist für die Verwaltung der Event-Handler zuständig.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Die Umsetzung der Kombination von „Strategy“ und „Flyweight“

Möchte der Event-Listener an ein konkretes EventHandler-Objekt gelangen, muss er die EventHan- derFactory ansprechen. In Abhängigkeit vom übergebenen Event ermittelt die Fabrik den jeweiligen Event-Handler. Dabei ist zu berücksichtigen, das die Handler nun Flyweights sind, d.h. sie existieren nur einmal im System und werden deshalb geteilt. Existiert der benötigte Handler schon, wird eine Referenz auf das existierende Objekt zurückgegeben, andernfalls muss erst ein neues Objekt erzeugt werden.

Nun muss die Frage geklärt werden, wie die Fabrik bestimmt, welchen Event-Handler sie für ein empfangenes Event aufrufen muss. Die erste Möglichkeit besteht darin, die Beziehungen zwischen Events und Event-Handler mit Hilfe eines switch-case-Konstrukts „hart zu verdrahten“. Der Nachteil dieser Lösung besteht darin, dass bei einer Definition eines neuen Events (also neue Category- Key/SubKey-Kombination) genau dieser Codeteil geändert werden muss, der sich normalerweise tief im Programmcode befindet. Ohne genaue Kenntnisse der Programmstruktur ist eine Änderung des Codeteils meistens sehr schwierig. Ein weiterer Nachteil ist, dass bei zunehmender Anzahl der Schlüssel die Übersichtlichkeit des Codes abnimmt. Eine bessere Möglichkeit ist es, eine Mapping- Tabelle in Form einer Textdatei zu erstellen, den Namen der benötigten EventHandler-Klasse daraus auszulesen, daraus dann eine Instanz zu erzeugen und die HandleEvent-Methode aufzurufen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2: Auszug aus der Datei „mapping.txt“

Sobald man den korrekten Klassennamen ermittelt hat, muss daraus eine Instanz des jeweiligen E- vent-Handlers erzeugt werden.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3: Instanziierung eines EventHandler-Objektes

Durch diese Vorgehensweise hat man auch einen der Nachteile des Strategy-Entwurfsmusters umgangen. Wie oben beschrieben, muss die Context-Klasse die einzelnen Strategy-Klassen kennen und genau wissen, welches Objekt es in welcher Situation erzeugen bzw. aufrufen muss. Dies ist nun nicht mehr erforderlich.

Da die EventHandler-Objekte Flyweights sein sollen, dürfen sie nur einmal im System existieren. Dazu wird ein Cache angelegt, in dem die Objekte nach ihrer Instanziierung abgelegt werden und bei Bedarf wieder ausgelesen werden. Durch diesen Mechanismus kann man sowohl den Speicherbedarf als auch die Zugriffszeit erheblich verkleinern.

Der Event-Listener ruft die Methode GetEventHandler der Fabrik auf, diese gibt dann das geforderte Objekt zurück. Der Listener kennt aber nur die Schnittstelle EventHandler, die Implementierungs- klassen bleiben ihm verborgen. Das eigentliche Aktionen für das Event-Handling geschehen in der Methode HandleEvent, die jede Implementierungsklasse speziell für das jeweilige Event realisiert.

Abschließend wird hier noch einmal ein Klassendiagramm gezeigt, dass alle Teilentwürfe in sich ver- eint:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Spiw-Event-Modell mit Event-Handlern

Nach der Definition von SpiwEvent und der damit übertragenden Daten muss nun geklärt werden, wie das Event in XML beschrieben werden kann.

[...]