Inhaltsverzeichnis

   1

Inhaltsverzeichnis   

Inhaltsverzeichnis   1

Abbildungsverzeichnis   4

Tabellenverzeichnis. 5   

Quelltextverzeichnis.   6

1  Einführung  7

1.1  SpiW - Mobile Spedition im Web.  7

1.2  Architektur des SpiW-Kommunikationssystems  9

1.2.1  Fachliche Architektur  9

1.2.2  Systemtechnische Architektur  12

1.2.3  Softwaretechnische Architektur.  12

1.3  Aufgabenstellung.  13

1.4  Vorgehensweise  14

1.5  Rahmenbedingungen.  14

2  Event/Action-Mechanismus.  16

2.1  Begriffe.  16

2.1.1  Event  16

2.1.2  Event-Listener  17

2.1.3  Event-Modell  17

2.2  Anforderungen  20

2.2.1  Übertragung aller Daten  20

2.2.2  Erweiterbarkeit / Flexibilität  20

2.2.3  Anpassbarkeit  20

2.2.4  Zuverlässigkeit  21

2.2.5  Sicherheit.  21

2.2.6  Geringe Datenmenge.  21

2.2.7  Schnelligkeit  21

2.2.8  Skalierbarkeit.  21

2.2.9  Plattformunabhängigkeit.  21

2.3  Lösung  22

2.3.1  Optimale Granularität.  22

2.3.2  SpiwEvent.  24

2.3.3  Event-Modell  26

2.3.4  Mapping von Ereignissen nach Aktionen.  27

3  Beschreibung des XML-Datenformats.  33

3.1  Motivation  33

3.2  DTD  35

3.3  XML Schema.  36

3.4  Vergleich  36

3.5  XML Schema für SpiwEvent  37

4  Data-Binding.  43

4.1  Motivation  43

4.2  Grundkonzept  43

2

Inhaltsverzeichnis

4.2.1  Klassengenerierung  43

4.2.2  Marshalling  44

4.2.3  Unmarshalling  45

4.3  Data-Binding-Frameworks  46

4.4  Low-Level APIs  48

4.4.1  DOM  48

4.4.2  SAX.  50

4.4.3  Vergleich  51

4.5  Umsetzung des individuellen Data-Binding  51

4.5.1  XmlReader.  52

4.5.2  XmlWriter  54

5  Übertragung der XML-Daten.  56

5.1  Auswahl des Übertragungsweges  56

5.2  Web Service Grundlagen  57

5.2.1  SOAP.  58

5.2.2  WSDL  60

5.2.3  Lebenszyklus eines ASP.NET XML Web Services  61

5.2.4  Die push/pull-Problematik  63

5.2.5  Bewertung.  64

5.3  Erstellen eines ASP.NET XML Web Services.  66

5.4  Erstellen des SpiW-Web Services  67

5.4.1  Methoden des Web Services.  67

5.4.2  Umwandlung der Datentypen  68

5.4.3  WSDL-Beschreibung des SpiW-Web Services.  69

5.4.4  Alternative Methoden  69

5.4.5  Aktualisiertes Klassendiagramm  70

5.5  Erstellen einer Client-Anwendung.  72

5.6  Sicherheit.  76

5.6.1  SSL  76

5.6.2  Windows-Authentifizierung.  77

5.6.3  SOAP-Header  78

5.7  Alternativen zu XML Web Services  79

5.7.1  NET Remoting  79

5.7.2  Sockets  80

6  Zusammenfassung und Ausblick  81

6.1  Erfüllung der Anforderungen.  81

6.1.1  Übertragung aller Daten  81

6.1.2  Erweiterbarkeit / Flexibilität  81

6.1.3  Anpassbarkeit  82

6.1.4  Zuverlässigkeit  82

6.1.5  Sicherheit.  82

6.1.6  Geringe Datenmenge.  82

6.1.7  Schnelligkeit  83

6.1.8  Skalierbarkeit.  83

6.1.9  Plattformunabhängigkeit.  83

6.2  Besonderheiten bei der Implementierung.  83

6.2.1  Validierung.  83

6.2.2  Dynamisches Laden der Event-Handler  84

6.3  Ausblick.  85

6.3.1  Die Zukunft der Web Services  85

Inhaltsverzeichnis

   3

6.3.2  Die Zukunft des NET Frameworks.  87

6.3.3  Weiterer Forschungsbedarf  87

Literaturverzeichnis.   89

Anhang A  WSDL-Beschreibung des Web Services  93

Anhang B  Beispielhaftes SpiwEvent als XML  99

Anhang C  Beschreibung des mitgelieferten Prototyps  109

4

Abbildungsverzeichnis   

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 DO-MBaumstruktur  

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   

   5

Tabellenverzeichnis   

Tabelle 1:  Anforderungen an den EAM.  22

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

Tabelle 3:  Vor- und Nachteile des Strategy-Entwurfsmusters.  28

Tabelle 4:  Liste möglicher Event-Handler.  28

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

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

Tabelle 7:  Typen eines DO-MNode und die entsprechenden Schnittstellen HaMe01  49

Tabelle 8:  Vor- und Nachteile von DOM und SAX  51

Tabelle 9:  Member von XmlNodeType.  53

Tabelle 10:  Elemente eines WSDL-Dokuments  60

Tabelle 11:  Vor- und Nachteile von Web Services  65

6

Quelltextverzeichnis   

Quelltextverzeichnis   

Listing  1: Das Interface ISpiwEvent.  26

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

Listing  3: Instanziierung eines EventHandler-Objektes  31

Listing  4: Das Grundgerüst eines Schemas  38

Listing  5: Das Grundgerüst eines Schemas mit Namensraumangabe  38

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

Listing  7: Das Grundgerüst des SpiwEvent-Schemas  38

Listing  8: Benutzung eines vordefinierten Typs  39

Listing  9: Deklaration der ersten SpiwEvent-Attribute.  39

Listing  10: Beschränkung eines Standardtyps.  40

Listing  11: Deklaration eines komplexen Typs.  40

Listing  12: Deklaration des komplexen Datentyps valueType  41

Listing  13: SpiwEventSchema.xsd.  42

Listing  14: DO-MBeispiel.  49

Listing  15: Lesen eines Attributs  53

Listing  16: Setzen der Eigenschaft ValidationType  54

Listing  17: Hinzufügen des Schemas  54

Listing  18: Hinzufügen der Callback-Methode  54

Listing  19: Beispielhafter ValidationHandler.  54

Listing  20: Schreiben eines Elements  55

Listing  21: Grundgerüst der Web Service-Klasse  67

Listing  22: Angaben zur Schemavalidierung.  68

Listing  23: Types-Sektion des WSDL-Dokuments  69

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

Listing  25: Grundgerüst des Proxys  74

Listing  26: Synchrone Methode des Proxys  74

Listing  27: Asynchrone Methode des Proxys  75

Listing  28: Korrekte ReceiveEvent-Methode des Proxys.  75

Listing  29: Einfügen des Proxys.  75

Listing  30: Einstellen der Windows-Authentifizierung  77

Listing  31: Benutzen der Windows-Authentifizierung  77

Listing  32: Beispielhafter SOAP-Header.  78

Listing  33: Authentifizierungsmethode des Web Services  78

Listing  34: Benutzen der Authentifizierung über SOAP-Header  78

Listing  35: Präpozessordirektive  84

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

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

Listing  38: WSDL-Beschreibung des Web Services  98

Listing  39: Beispielhaftes SpiwEvent als XML  108

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 Aufgabenstellung 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ührung flexibler zu gestalten und sie durch den Einsatz zeitnaher Informations- und Kommunikationssysteme zu unterstützen. Zeitnah bedeutet, dass die Fahrer ihren Auftragsfortschritt ständig dokumentieren, 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 Kommunikationsproblemen 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 Kalkulation 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 Verspä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-

8 1 Einführung

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 Logistikanwendungen 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 damit 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 ausgelegt 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 Kommunikationsverbindung 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 Schnittstellen integriert werden können. Durch diese Vorgehensweise wird eine Trennung zwischen den kaufmännischen Dispositions- und Logistiksystemen und dem Kommunikationssystem erreicht. Unternehmen sind dadurch nicht mehr gezwungen, monolithische, meist sehr teure Softwaresysteme mit einem großen Funktionsumfang zu kaufen und einzusetzen, nur um die Kommunikationsfunktionalitä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äftsprozesssteuerung 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 Kommunikationssystems mit ein. Es wird ebenfalls untersucht, welche Auswirkungen der Einsatz dieses Systems 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 Begegnungsverkehr reduziert werden. Die Analyse und Verbesserung dieser Prozesse übernimmt der Lehrstuhl 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, unterstützt durch Mitarbeiter der Universität Dortmund, Lehrstuhl für Softwaretechnologie. Als industrielle 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 sichergestellt werden, dass alle Geschäftsobjekte der angebundenen Logistikanwendungen eine Entsprechung 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.

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 Sendungen, 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 (Beladejob) oder ein Entladevorgang (Entladejob) sein. Ein Transport enthält eine Menge von Ladungspositionen (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 (Rundreise, Planungsintervall (Tag, Woche), Auslieferungs- oder Sammelverkehr). Diese Auflistung von Transporten kann durch den Fahrer nach verschiedenen Kriterien (Kundenpriorisierung, Ladereihenfolge, 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.

10

1  Einführung  

Abbildung  1: SpiW-Datenmodell - Teil  1

1  Einführung  

   11

Abbildung  2: SpiW-Datenmodell - Teil  2

12 1 Einführung

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 Daten. 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 Entscheidungen 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 Workflow-Engines, die die dortigen Arbeitsprozesse steuern. Abbildung 3 veranschaulicht die softwaretechnische Architektur des SpiW-Kommunikationssystems.

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 Ressourcen 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äftslogik 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 Kommunikationsmechanismus gefunden werden. Idealerweise wird dieser auch dazu benutzt, externe Speditionssoftwaresysteme zu integrieren. Deshalb muss der Mechanismus mindestens folgende Anforderungen erfüllen [GrSc03]:

Anpassbarkeit: Unterschiedliche Speditionssoftwaresysteme können mit geringem Aufwand ^- integriertwerden.

Flexibilität / Erweiterbarkeit: Neue Anforderungen an das Kommunikationssystem müssen ^- ohneVerä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 Rahmenbedingungen (neue Ereignisse und Geschäftsobjekte) eingehen zu können. Dann muss überlegt werden, wie ein solches XML-Dokument erzeugt werden kann bzw. wie aus einem XML-Dokument Objekte 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 Praktikabilität des Gesamtkonzeptes nachgewiesen werden soll, muss sich problemlos in die SpiW- Architektur einfügen können.

14 1 Einführung

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 Entwicklung 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 4: Das .NET Framework im Überblick [Weye02]

Die Basis für die Ausführung von Code ist die Common Language Runtime (CLR). Der Programmierer 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 Implementierung 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 Applikationen 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 verschiedene 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 eingeschrä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 (oder 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 ebenfalls. Da hier auch Visual Studio .NET 2003 installiert ist, dient er gleichzeitig als Entwicklungsplatt- form.

16 2 Event/Action-Mechanismus

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 mobilen 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 entwickelnden EAM untersucht werden. Ist dies geschehen, kann damit begonnen werden, den EAM genau 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 auftretenden 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 interessiert, davon zu erfahren, um entsprechend reagieren zu können. In der Literatur gibt es viele verschiedene Definitionen von Events. [McPR03] z.B. definiert ein Event als das Abbild eines asynchronen 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 Arbeit wie folgt definiert:

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 zusammengesetzte Events unterschieden werden. Zusammengesetzte Events können als Erweiterung der primitiven Events verstanden werden, und bestehen aus primitiven oder selbst wieder zusammengesetzten 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.

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.

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.

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.

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

2.1.3 Event-Modell

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

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, Me-diator 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 Event-Listener 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 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 (fooOccur- red oder fooHappened) aufruft.

Event-Modelle, die einen Vermittler (Mediator) benutzen, erlauben Listener, sich bei einem bestimmten 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 geschieht. 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 mobile 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 gelagerten 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 Event-Listener 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 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 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 kombinieren.

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.

20 2 Event/Action-Mechanismus

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 SpiW-Kommunikationssystem existierenden Geschäftsobjekte können Kapitel 1.2.1 entnommen werden. Ereignisse im Kommunikationssystem können sein:

Melden neuer Transporte an den Fahrer ^- An-/AbmeldenDisponent/Fahrer ^- NeuenFahrer im System anlegen ^- NeuenTransport im System anlegen ^- NeueTransportposition im System anlegen ^- Änderungder Transportdaten durch den Disponent ^- Anpassungeiner Tour und Bildung einer Route ^- Änderungder Transportdaten durch den Fahrer ^- Informierungdes Disponenten über Änderung von Transportdaten durch den Fahrer ^- Benachrichtigungdes Fahrers über einen neuen Transport ^- Mitteilungvon Routenänderungen ^- Systemfehler ^- ImPrinzip 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:

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 Program-mieraufwand 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 definieren 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, wodurch 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 Geschä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