Remote Application Tracingstatic.sws.bfh.ch/download/B36-08-doc.pdf · Zusätzlich wird vom Gesamtsystem für die gesicherte asynchrone Kommunikation ein JMS-Provider und für die

Diplombericht

Nr. B36.08

Remote Application Tracing

(Asynchrones Logging und Monitoring System)

Abstract: Remote Application Tracing (RAT) ist ein zentrales Messaging-System für die Übermittlung und Weiterverteilung von Log-Meldungen aus angeschlossenen Applikationen. Das System verteilt eingehende Log-Meldungen aufgrund frei konfigurierbaren Regeln auf beliebige Kanäle, um sie externen Auswertungs- und Analysetools zugänglich zu machen. Die Architektur des Gesamtsystems ist so konzipiert, dass jede Art von Applikation, die die Schnittstellen nutzen können, als Log-Produzenten bzw. Konsumenten (Analysetool) auftreten können. Autoren: Remo Ledermann

St.Urbanstrasse 39 4900 Langenthal Tel: 062 922 32 07

Roland Jost Haldenstrasse 60 4900 Langenthal Tel: 079 208 48 45

Betreuer: Stefan Thörner Bedag Informatik AG 3000 Bern

Erich Lambelet Bedag Informatik AG 3000 Bern

Experte: Stephan Fischli Software-Schule Schweiz Wankdorffeldstrasse 102 3000 Bern 22 Tel: 031 33 55 274

Datum: 13.11.2006

Diplomarbeit B36.08 Dokumentation

Diplombericht_V1.0.doc Seite 2

Zusammenfassung Einleitung In jedem Software-System besteht das Bedürfnis, Log-Meldungen zur Laufzeit zu überwachen und zu protokollieren, um später Auswertungen oder Fehleranalysen durchzuführen. Beim Einsatz von verteilten Systemen und den gängigen Logging-Mechanismen werden in der Regel die Log-Meldungen in Dateien geschrieben, die sich lokal auf der entsprechenden Systemumgebung befinden. In einem komplexen Umfeld ist es für Entwickler oder Systembetreuer schwierig, die Dateien für die Analyse zu finden. Oft müssen Administratoren oder Benutzer kontaktiert werden, um an die Dateien zu gelangen. Ausserdem ist die Analyse von File basierten Log-Meldungen aufgrund der Unübersichtlichkeit und Menge aufwändig und mühsam.

Zielsetzung Um der beschriebenen Problematik entgegen zu wirken, soll im Rahmen der Diplomarbeit ein Messaging-System entwickelt werden, das an einem zentralen Ort Log-Meldungen verschiedener Applikationen entgegen nimmt und den Benutzern direkt zur Verfügung stellt. Mit dem System soll der Aufwand zum Auffinden und Überwachen von Log-Meldungen verringert werden.

Das System soll zudem so entwickelt werden, dass Eingriffe in die angeschlossenen Applikationen möglichst gering gehalten werden. Ebenfalls soll das System keinen Einfluss auf bestehende Logging-Mechanismen haben. Weitere Zielsetzungen liegen in der offenen Architektur, der einfachen Erweiterbarkeit sowie einer bedürfnisgerechten Konfigurierbarkeit.

Realisierung Das Gesamtsystem besteht aus folgenden Hauptkomponenten:

• Dem RAT-Appender, der die Log-Events von der Applikation übernimmt und sie dem Server sendet.

• Dem RAT-Server, der als Konsument alle Log-Events empfängt und auf vorkonfigurierten Kanälen publiziert.

• Den Endkonsumenten, die Log-Events aus den Kanälen empfangen und weiterverarbeiten können.

Im Rahmen dieser Arbeit wurden der Appender und der Server realisiert. Die Implementation eines geeigneten Endkonsumenten ist Sache des nutzenden Systems.

Zusätzlich wird vom Gesamtsystem für die gesicherte asynchrone Kommunikation ein JMS-Provider und für die Persistierung eine Datenbank genutzt.

Entwickelt wurde das System mit Java.,Für das Webfronten der Serververwaltung wurde JSF verwendet.



Besprechung Die Muss-Ziele, die wir im Pflichtenheft definierten, konnten vollumfänglich realisiert werden. Damit haben wir ein funktionsfähiges und gut bedienbares System entwickelt.



Inhaltsverzeichnis

1 Vorbemerkungen ...................................................................10 1.1 Ausgangslage.................................................................................... 10 1.2 Leserkreis.......................................................................................... 10 1.3 Aufbau des Dokuments ..................................................................... 10 1.4 Referenzen........................................................................................ 10 1.5 Inhalt der CD-Rom ............................................................................ 11 1.6 Glossar .............................................................................................. 11

2 Analyse ..................................................................................13 2.1 Ausgangslage.................................................................................... 13 2.2 Projektziele........................................................................................ 14 2.3 Use-Case Übersicht .......................................................................... 15

2.3.1 Benutzerkreise (Actors) .........................................................................15 2.3.2 RAT-Appender .......................................................................................15 2.3.3 RAT-Server ............................................................................................16

3 Design....................................................................................17 3.1 Gesamtsystem .................................................................................. 17

3.1.1 Verteilungsmodell ..................................................................................17 3.1.2 Skalierbarkeit .........................................................................................18 3.1.3 Schnittstellen..........................................................................................19

3.2 RAT-Appender .................................................................................. 21 3.2.1 Klassenübersicht....................................................................................22 3.2.2 Funktionen .............................................................................................23

3.2.2.1 JMX-Schnittstelle..........................................................................23 3.2.2.2 Log4-Appender.............................................................................24 3.2.2.3 PropertyChangeSupport ...............................................................25 3.2.2.4 JMS-Anbindung ............................................................................25

3.2.3 Aktivitäten ..............................................................................................26 3.2.3.1 Appender Initialisierung ................................................................26 3.2.3.2 Log-Event Verarbeitung................................................................27

3.2.4 Fehlerhandling .......................................................................................28 3.3 RAT-Server ....................................................................................... 29

3.3.1 Packageübersicht Server.......................................................................30 3.3.2 Domain-Verwaltung ...............................................................................31

3.3.2.1 Domain-Model ..............................................................................31 3.3.2.2 Domain-Zugriffe............................................................................33 3.3.2.3 Persistierung (DAO) .....................................................................33 3.3.2.4 Datenbank ....................................................................................35

3.3.3 Tasks .....................................................................................................36 3.3.3.1 Definition.......................................................................................36 3.3.3.2 Implementation .............................................................................36

3.3.4 Dispatching ............................................................................................37 3.3.4.1 Übersicht ......................................................................................37 3.3.4.2 Verarbeitung .................................................................................38

3.3.5 Webfrontend ..........................................................................................40 3.3.5.1 Schichtenmodell (MVC)................................................................40 3.3.5.2 ManagedBeans ............................................................................42



3.3.5.3 Request/Response-Handling........................................................42 4 Realisierung ...........................................................................44

4.1 Entwicklungsumgebung .................................................................... 44 4.1.1 Eclipse ...................................................................................................44 4.1.2 Zusätzliche Tools ...................................................................................45

4.2 Testhilfen........................................................................................... 45 4.2.1 Simulator................................................................................................45

4.2.1.1 Implementation .............................................................................45 4.2.1.2 Bedienung ....................................................................................46

4.2.2 JUnit.......................................................................................................47 4.3 Eingesetzte Technologien ................................................................. 48

4.3.1 Java Development Kit ............................................................................48 4.3.2 Log4J .....................................................................................................48 4.3.3 Apache Tomcat......................................................................................48 4.3.4 JAXB......................................................................................................48 4.3.5 OpenJMS...............................................................................................49 4.3.6 Hibernate ...............................................................................................49 4.3.7 MySQL...................................................................................................50 4.3.8 JSF / MyFaces / Ajax .............................................................................51

4.4 Implementations Details .................................................................... 52 4.4.1 JMX HtmlAdaptorServer ........................................................................52 4.4.2 Persistierung mit Hibernate....................................................................54

4.4.2.1 Konfiguration ................................................................................54 4.4.2.2 O/R-Mapping ................................................................................55 4.4.2.3 Objekt-Zugriffe..............................................................................56 4.4.2.4 Session-Handling .........................................................................57

4.4.3 Live-Monitoring mit Ajax.........................................................................58 4.5 Build-Prozess .................................................................................... 61

4.5.1 RAT-Appender .......................................................................................61 4.5.2 RAT-Server ............................................................................................61 4.5.3 Simulator................................................................................................61

5 Testen ....................................................................................62 5.1 Einleitung........................................................................................... 62

5.1.1 Zweck der Tests.....................................................................................62 5.1.2 Testumgebung.......................................................................................62 5.1.3 Testaufbau.............................................................................................63 5.1.4 Vorgehen ...............................................................................................63

5.2 Funktionstests ................................................................................... 64 5.2.1 Test Serververwaltung ...........................................................................64

5.2.1.1 Login/Logout.................................................................................64 5.2.1.2 Applikationen verwalten................................................................64 5.2.1.3 Kanäle verwalten ..........................................................................65 5.2.1.4 Dispatching konfigurieren .............................................................66 5.2.1.5 Statistiken abfragen......................................................................66 5.2.1.6 Onlinehilfe.....................................................................................67 5.2.1.7 Onlinedokumentation....................................................................67

5.2.2 Test Appender .......................................................................................67 5.2.2.1 Simulator starten ..........................................................................67 5.2.2.2 LogEvent erstellen und senden ....................................................68 5.2.2.3 Zugriff auf Appender mit JMX.......................................................68

5.2.3 Test Gesamtsystem...............................................................................69 5.2.3.1 LogEvent mit Mail versenden .......................................................69



5.2.3.2 LogEvent in Topic Kanal senden..................................................69 5.2.3.3 LogEvent in DB Kanal senden......................................................70 5.2.3.4 Inhalt der Kanäle anzeigen...........................................................70 5.2.3.5 Skalierbarkeit testen .....................................................................71 5.2.3.6 Dispatcher Regeln überprüfen......................................................71

5.3 Performancetests .............................................................................. 72 5.3.1 LogEvents periodisch senden................................................................72 5.3.2 Antwortzeiten vom Webfrontend............................................................72

5.4 Zusammenfassung und Beurteilung der Tests .................................. 73 6 Installationsanleitung .............................................................74

6.1 Einbinden Appender in Applikationen................................................ 74 6.1.1 Voraussetzungen...................................................................................74 6.1.2 Einbinden...............................................................................................74 6.1.3 Konfiguration..........................................................................................75

6.2 RAT-Server in Tomcat deployen ....................................................... 76 6.2.1 Voraussetzungen...................................................................................76 6.2.2 Deployment............................................................................................76 6.2.3 JNDI-Definitionen...................................................................................76

6.3 Plugin-Task entwickeln und integrieren............................................. 77 7 Benutzerhandbuch.................................................................78

7.1 Einleitung........................................................................................... 78 7.2 Einführende Bemerkungen................................................................ 78

7.2.1 Navigation ..............................................................................................78 7.2.2 Hilfe........................................................................................................79 7.2.3 Bedienelemente auf den Verwaltungsseiten..........................................79

7.3 Frontend Verwaltung ......................................................................... 81 7.3.1 Startseite / Überwachung.......................................................................81 7.3.2 Verwaltung.............................................................................................82

7.3.2.1 Applikationen verwalten................................................................82 7.3.2.2 Kanäle verwalten ..........................................................................84 7.3.2.3 Dispatching Regeln ......................................................................87

7.3.3 Dokumentation.......................................................................................88 8 Besprechung..........................................................................89

8.1 Zielerreichung.................................................................................... 89 8.2 Lessons Learned............................................................................... 90

8.2.1 Vorgehensmodell RUP ..........................................................................90 8.2.2 Beurteilung der einzelnen Phasen .........................................................91 8.2.3 Projektmanagement und Organisation ..................................................91 8.2.4 Datensicherung......................................................................................92 8.2.5 Terminplan .............................................................................................92 8.2.6 Aufwandschätzung.................................................................................92

8.3 Ausblick ............................................................................................. 92

Anhang • Quellenverzeichnis

• Projektplan

• Erledigte Arbeiten (aus den Statusberichten)



• Pflichtenheft



Abbildungsverzeichnis Abbildung 2-1 : Ist Zustand ....................................................................................................13 Abbildung 2-2 : Soll Zustand ..................................................................................................14 Abbildung 2-3 : Use-Cases Appender....................................................................................15 Abbildung 2-4 : Use-Cases Server.........................................................................................16 Abbildung 3-1 : Verteilungsmodell..........................................................................................18 Abbildung 3-2 : Skalierbarkeit ................................................................................................19 Abbildung 3-3 : XML-Schema für Log-Events ........................................................................20 Abbildung 3-4 : RAT-Appender Klassenübersicht..................................................................22 Abbildung 3-5 : JMX-Schnittstelle ..........................................................................................23 Abbildung 3-6 : Log4J-Appender............................................................................................24 Abbildung 3-7 : JMS-Anbindung.............................................................................................25 Abbildung 3-8 : Appender Initialisierung.................................................................................26 Abbildung 3-9 : Log-Event Verarbeitung ................................................................................27 Abbildung 3-10 : Packageübersicht Server ............................................................................30 Abbildung 3-11 : Basis-Entitäten ............................................................................................31 Abbildung 3-12 : Fachliche-Entitäten .....................................................................................32 Abbildung 3-13 : Domain-Controller .......................................................................................33 Abbildung 3-14 : Domain-DAO...............................................................................................34 Abbildung 3-15 : System-Tasks .............................................................................................37 Abbildung 3-16 : Dispatching-Klassen ...................................................................................38 Abbildung 3-17 : Dispatching-Ablauf ......................................................................................39 Abbildung 3-18 : Sequenzdiagramm Dispatching ..................................................................40 Abbildung 3-19 : Schichtenmodell..........................................................................................41 Abbildung 3-20 : ManagedBeans ...........................................................................................42 Abbildung 3-21 : Request/Response-Handling ......................................................................43 Abbildung 4-1 : Java-Projekte in Eclipse................................................................................45 Abbildung 4-2 : Simulator .......................................................................................................47 Abbildung 4-3 : Junit-Tests.....................................................................................................47 Abbildung 4-4 : Hibernate Konfiguration ................................................................................50 Abbildung 4-5 : Filter im web.xml ...........................................................................................51 Abbildung 4-6 : JMX Konfiguration.........................................................................................52 Abbildung 4-7 : JMX Agent View............................................................................................53 Abbildung 4-8 : JMX MBean View..........................................................................................54 Abbildung 4-9 : Hibernate Initialisierung.................................................................................55 Abbildung 4-10 : Hibernate Mapping......................................................................................56 Abbildung 4-11 : Hibernate Controller ....................................................................................57 Abbildung 4-12 : Hibernate DAO............................................................................................57 Abbildung 4-13 : Hibernate Session Handling........................................................................58 Abbildung 4-14 : Ajax Bereiche ..............................................................................................59 Abbildung 4-15 : Ajax JSF Definition......................................................................................59 Abbildung 4-16 : LogEventListener-Interface .........................................................................60 Abbildung 5-1 : Testaufstellung..............................................................................................62 Abbildung 6-1 : Appender Jars...............................................................................................74 Abbildung 6-2 : Log4-Konfiguration........................................................................................75 Abbildung 6-3 : Tomcat ..........................................................................................................76 Abbildung 6-4 : Context.xml ...................................................................................................77 Abbildung 7-1 : Navigation .....................................................................................................78 Abbildung 7-2 : Hilfe ...............................................................................................................79 Abbildung 7-3 : Überwachung ................................................................................................82 Abbildung 7-4 : Applikationen verwalten ................................................................................83 Abbildung 7-5 : Kanäle verwalten...........................................................................................84



Abbildung 7-6 : Attribute DB Task ..........................................................................................85 Abbildung 7-7 : Attribute Topic Task ......................................................................................86 Abbildung 7-8 : Attribute Mail Topic .......................................................................................86 Abbildung 7-9 : Regeln verwalten ..........................................................................................88 Abbildung 7-10 : Dokumentation ............................................................................................88



1 Vorbemerkungen

1.1 Ausgangslage Das in diesem Dokument beschriebene System wird im Rahmen einer Diplomarbeit für das Nachdiplomstudium „NDS Software Engineering“ an der Software-Schule Schweiz realisiert.

Die Anforderungen an das System und der realisierte Lösungsansatz entstammen nicht direkt einem Auftrag aus der Wirtschaft oder Industrie. Sie entstanden vielmehr aus den Bedürfnissen der Diplomanden aus ihrem alltäglichen Arbeitsumfeld im Bereich der Softwareentwicklung und Systembetreuung.

1.2 Leserkreis Dieses Dokument richtet sich an den Experten, die Betreuer sowie an alle interessierten Personen, die sich mit diesem Thema auseinandersetzen wollen.

Das Dokument dient ausserdem als Grundlage für die Weiterentwicklung der Software und zur Integration des Systems in ein produktives Umfeld.

1.3 Aufbau des Dokuments Der Diplombericht baut auf dem Pflichtenheft [1] auf, in dem die Anforderungen in fachlicher und technischer Hinsicht für das zukünftige System aus Sicht des Kunden beziehungsweise des Benutzers beschrieben werden.

Das vorliegende Dokument beschreibt das Design der Applikation sowie dessen Realisierung. Weiter wird erläutert, wie das System getestet wurde und welche Ergebnisse die Tests lieferten. Ebenfalls ist aufgeführt, wie das System installiert wird. Das Benutzerhandbuch zeigt auf, wie das System bedient wird.

Im letzten Kapitel werden im Rahmen einer Besprechung die Zielerreichung sowie die Lessons Learned thematisiert.

1.4 Referenzen Referenzierte Dokumente:

• [1] Pflichtenheft



1.5 Inhalt der CD-Rom Doku: Unter der Dokumentation sind alle wichtigen Dokumente abgelegt, die im Zusammenhang mit der Diplomarbeit entstanden sind.

Die wichtigsten sind:

• Die Beschreibung des Diplomthemas

• Der Diplombericht

• Das Pflichtenheft

Code: Im Verzeichnis Code sind die Artefakte aus dem Softwareentwicklungsprozess abgelegt:

• Java Source-Code

• Javadoc

• Kompilierte JAR- und WAR-Archive

Workspace: Hier ist der gesamte Eclipse-Workspace aus dem Softwareentwicklungsprozess mit allen Teilprojekten enthalten.

1.6 Glossar Im Glossar sind die wichtigsten in diesem Dokument verwendeten technischen und fachlichen Abkürzungen kurz beschrieben. Eine detaillierte Beschreibung von Technologiestandards, die im System zum Einsatz kamen, kann dem Kapitel „Eingesetzte Technologien“ entnommen werden.

AJAX Asynchronous JavaScript and XML bezeichnet ein Konzept der

asynchronen Datenübertragung zwischen einem Server und dem Browser, welches ermöglicht, innerhalb einer HTML-Seite eine HTTP-Anfrage durchzuführen, ohne die Seite komplett neu laden zu müssen.

API Application Programming Interface ist eine Programmierschnittstelle die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird.

CRUD Ist ein Akronym, welches die grundlegenden Datenbankoperationen Create (Datensatz anlegen), Retrieve (Datensatz abfragen), Update (Datensatz aktualisieren), und Delete (Datensatz löschen) umschreibt.

DAO Data Access Object ist ein Java-Objekt, das Zugriffe auf persistente Daten kapselt.



JAR Java Archive ist eine ZIP-Datei mit zusätzlichen Metadaten.

JAXB Java Architecture for XML Binding bezeichnet eine Programmschnittstelle in

Java für die XML-Verarbeitung.

JDK Java Development Kit sind die Java-Entwicklungswerkzeuge Compiler und Laufzeitumgebung.

JMS Java Messaging Service ist ein API von SUN für den asynchronen Austausch von Nachrichten.

JMX Java Management Extension ist eine vom Java Community Process (JSR-3) entwickelte Spezifikation zur Verwaltung und Überwachung von Java-Anwendungen.

JSF Java Server Faces ist ein Framework-Standard im Bereich der Webanwendungen.

MVC Model-View-Control bezeichnet ein Architekturmuster zur Aufteilung von Softwaresystemen in die drei Einheiten Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller).

RAT Projekt Bezeichnung, steht für Remote Application Tracing

RUP Der Rational Unified Process ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung.

UML Unified Modeling Language ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen.



2 Analyse Die detaillierte Analyse mit den Anforderungen und eine Beschreibung der Anwendungsfälle wurden bereits im Rahmen der Vorarbeiten für das Pflichtenheft erstellt und können dem Pflichtenheft [1] im Anhang entnommen werden.

In diesem Kapitel wird in Form einer Einführung in das Thema eine kurze Übersicht über die Ausgangslage, die Ziele und die definierten Use-Cases beschrieben.

2.1 Ausgangslage In jedem Software-System besteht das Bedürfnis, Log-Meldungen zur Laufzeit zu überwachen und zu protokollieren, um später Auswertungen oder Fehleranalysen durchzuführen. Beim Einsatz von verteilten Systemen und den gängigen Logging-Mechanismen werden in der Regel die Log-Meldungen in Dateien geschrieben, die sich lokal auf der entsprechenden Systemumgebung befinden. In einem komplexen Umfeld ist es für Entwickler oder Systembetreuer häufig schwierig, die Dateien für die Analyse zu finden. Oft müssen Administratoren oder Benutzer kontaktiert werden, um an die Dateien zu gelangen. Ausserdem ist die Analyse von File basierten Log-Meldungen aufgrund der Unübersichtlichkeit und Menge aufwändig und mühsam.

Entw ickler

B usiness M odell IST

Applikation B

Applikation A

Applikation C

Applikation F

Applikation D

Applikation E

System betreuer

Entw ickler

Abbildung 2-1 : Ist Zustand



2.2 Projektziele Um der beschriebenen Problematik entgegen zu wirken, soll ein Messaging-System entwickelt werden, das an einem zentralen Ort Log-Meldungen verschiedener Applikationen entgegen nimmt und den Benutzern direkt zur Verfügung stellt. So kann der Aufwand für das Auffinden verringert werden.

Das System soll eine offene Architektur aufweisen, die es jeder Applikation (Produzent) ermöglicht, Log-Meldungen zu senden und durch ein beliebiges Analysetool (Konsument) auswerten zu lassen.

Dadurch soll ein Gesamtsystem entstehen, das den Entwicklern und Systembetreuern die Überwachung und Auswertung von Log-Meldungen erheblich erleichtert.

Server

Entw ickler

B usiness M odell SO LL

Applika tion B

Applika tion A

A pplikation C

C lient

C lient

C lient

Applika tion F

Applika tion D

Applika tion E

System betreuer

Entw ickler

Abbildung 2-2 : Soll Zustand

Die Ziele:

• Aufwand zum Auffinden und Überwachen von Log-Meldungen verringern.

• Die zentrale Verwaltung von Log-Meldungen sicherstellen.

• Eingriffe in die angeschlossenen Applikationen möglichst gering halten.

• Einfluss auf bestehende Logging-Mechanismen minimieren.

• Offene Architektur gewährleisten.

• Einfache Erweiterbarkeit sicherstellen.

• Bedürfnisgerechte Konfigurierbarkeit sicherstellen.

Die Analyse der Log-Meldungen kann das System den Benutzern jedoch nicht abnehmen. Nur gezielte und aussagekräftige Meldungen erleichtern die Fehlersuche in einer Applikation.



2.3 Use-Case Übersicht Das Kapitel beinhaltet eine kurze Übersicht über die definierten Use-Cases für den Appender und den Server. Die detaillierte Beschreibung ist im Pflichtenheft [1] aufgeführt.

2.3.1 Benutzerkreise (Actors) Actor Beschreibung Administrator Der Administrator sorgt für die korrekte Konfiguration des

Gesamtsystems. Er definiert, welche Log-Meldungen auf welchen Kanal verteilt werden sollen.

SW-Betreuer Der Softwarebetreuer analysiert im Fehlerfall die Log-Meldungen. Applikation Die angebundene Applikation stellt als Systemactor den Auslöser

von Log-Events dar.

2.3.2 RAT-Appender Der Appender ist eine Library, die in eine Applikation eingebunden werden kann, um Log Events der Applikation über JMS an den Server zu senden.

ApplikationA ppender

R em oteTraceAppender

LogE ventabfangen

<<actor>>

JM X R em oteM anagem ent

Adm in istra tor

Abbildung 2-3 : Use-Cases Appender



2.3.3 RAT-Server Der Server ist die zentrale Komponente des Gesamtsystems und stellt ein Webfrontend zur Konfiguration und Überwachung zur Verfügung. Er übernimmt das Verteilen der eintreffenden Log-Events aufgrund freikonfigurierbarer Regeln und Kanäle.

Server

Adm inistrator

R em oteTraceServer

Kanäle anzeigen

Topic

D ispatch ingkonfigurieren

Applikationenverw alten

DB

Kanal ausw ählen<< include>>

S tatistikenerste llen

Kanäle verwalten


Abbildung 2-4 : Use-Cases Server



3 Design

3.1 Gesamtsystem Das Gesamtsystem besteht aus folgenden Haupt-Komponenten:

• Den Log-Produzenten, die mit oder ohne Hilfe des RAT-Appenders Log-Events an den Server übermitteln wollen.

• Dem Server, der als Konsument alle Log-Events empfängt und auf vorkonfigurierten Kanälen publiziert.

• Den Endkonsumenten, die Log-Events aus den Kanälen empfangen und zur Analyse aufbereiten können.

Zusätzlich wird vom Gesamtsystem für die gesicherte asynchrone Kommunikation ein JMS-Provider und für die Persistierung eine Datenbank genutzt.

Die Endkonsumenten (Analyse und Auswertungstools) sind keine in diesem Projekt realisierten Komponenten. Ein Auswertungstool richtet sich an der Art des Kanals aus, auf dem Log-Events veröffentlicht werden. Da das System offen gegenüber jeglicher Art von Kanal ist, ist es Sache desjenigen, der einen Kanal implementiert ein geeignetes Analysetool zur Verfügung zu stellen.

Mögliche Analysetools sind:

• Texteditoren

• E-Mail Client

• DB Abfrage und Reporting Tool

• Etc.

3.1.1 Verteilungsmodell Das Gesamtsystem ist als verteiltes System modular aufgebaut. Die einzelnen Komponenten können (müssen aber nicht) auf unterschiedlichen Systemen installiert und betrieben werden. Die Kommunikation untereinander muss aber über ein Netzwerk sichergestellt werden.

Mögliche Verteilung auf einzelnen Server-Systemen:



dd Verteilungsmodell

Serv er 1

+ Applikation A (Client-Appender)+ Applikation B (Client-Appender)

Serv er 2

+ Applikation C (Client-Appender)

Serv er 4

+ RAT-Server

Server 3

+ JMS-Provider

Serv er 5

+ Datenbank

«senden» «senden»

«empfangen»

«use»

Abbildung 3-1 : Verteilungsmodell

3.1.2 Skalierbarkeit Die offene Architektur des Systems erlaubt die Anbindung beliebiger Applikationen, die als Log-Produzenten die Log-Meldungen an den Server senden. Der Server verteilt die Meldungen über verschiedene Kanäle an die Endkonsumenten. Dies sind einerseits externe Analysetools, die die Log-Meldungen auswerten und analysieren. Andererseits kann auch eine andere RAT-Instanz als Konsument auftreten und dadurch ein skalierbares System bilden.

Ein RAT-Server kann Log-Meldungen von einer beschränkten Anzahl angeschlossener Applikationen verarbeiten. Damit eine grössere Anzahl Applikationen angeschlossen werden kann, besteht die Möglichkeit, mehrere RAT-Server parallel zu betreiben. Die gefilterten Log-Meldungen dieser vorgeschalteten RAT-Server werden an einen zentralen RAT-Server gesendet, so dass eine zentrale Überwachung über alle Applikationen sichergestellt ist.



id RAT Gesamtstruktur

Systemumgebung

Systemumgebung Systemumgebung

Applikation A Applikation B

RAT-Serv erRAT-Serv er

Analysetool

Applikation CApplikation D Applikation E

Analysetool

Applikation F

RAT-Serv er

Analysetool

Abbildung 3-2 : Skalierbarkeit

3.1.3 Schnittstellen Die Schnittstelle unter den Systemkomponenten, das heisst zwischen den angebundenen Applikation und dem Server, bildet die Log-Queue des JMS-Providers. Applikationen senden ihre Log-Events mit oder ohne Hilfe des RAT-Appenders auf die Queue. Das Format dieser Log-Events wird durch das XML-Schema logging-event.xsd vorgeschrieben. Nur so kann sichergestellt werden, dass alle Log-Events vom Server korrekt verarbeitet werden können.

Applikationen, die den RAT-Appender nicht verwenden, müssen ihre Log-Events zwingend als XML-String, der dem Schema entspricht, aufbereiten. Für die anderen Applikationen übernimmt diese Aufgabe der Appender.



Abbildung 3-3 : XML-Schema für Log-Events



3.2 RAT-Appender Der Appender übernimmt für Applikationen, die an das System angebunden werden sollen, die Kommunikation und Übermittlung von Log-Events an den JMS-Provider. In den Applikationen wird der Appender in Form einer JAR-Library eingebunden. Der Appender setzt zwingend den Einsatz von Log4J in der nutzenden Applikation voraus.

Der Appender stellt folgende Funktionalitäten zur Verfügung:

• Log4J-Appender

• JMX-Schnittstelle

• JMS-Anbindung

• PropertyChangeSupport

Log4J-Appender: Der integrierte Log4J-Appender ist die Schnittstelle zum Log4J-Framework. Er stellt den „Single Point of Contact“ für die nutzende Applikation dar. Die Kommunikation mit der Schnittstelle wird von Log4J übernommen, so dass die nutzende Applikation keinen direkten Kontakt zum Appender hat. Die gesamte Konfiguration des Appenders erfolgt durch die Konfiguration von Log4J.

JMX-Schnittstelle: Die JMX-Schnittstelle macht die aktuellen Konfigurationseinstellungen des Appenders remotemässig zugänglich. Dies soll es einem Administrator erleichtern, Applikationen zu überwachen und gegebenenfalls Einfluss auf die Konfiguration zu nehmen.

JMS-Anbindung: Der Appender übernimmt die gesamte Kommunikation mit dem JMS-Provider. Er konvertiert die Log-Events in XML-Format und sendet diese über die Log-Queue des JMS-Providers asynchron an den Server.

PropertyChangeSupport Da zur Laufzeit einer Applikation über die JMX-Schnittstelle Konfigurationsänderungen vorgenommen werden können, kann sich die nutzende Applikation beim Appender registrieren, um über Änderungen an der Konfiguration informiert werden zu können.



3.2.1 Klassenübersicht Das folgende Diagramm zeigt alle Klassen des Appenders und deren Abhängigkeiten auf. Die einzelnen Klassen werden in den nachfolgenden Kapiteln detailliert beschrieben.

cd RAT-Appender Klassenübersicht

AppenderSkeletonappender::RemoteTraceAppender

appender::RemoteTraceManager

JMSConnectionManagerappender::RemoteTracer

«interface»appender::RemoteTraceAppenderMBean

PropertyChange-Support

HtmlAdaptorServ er

«JMS»LogQueue

«realize»

Singleton

verwendet

Benutzt

Implementiert

«realize»

«send»

Abbildung 3-4 : RAT-Appender Klassenübersicht



3.2.2 Funktionen

3.2.2.1 JMX-Schnittstelle Die JMX-Schnittstelle wurde mit einem Standard MBean implementiert. Dies stellt den einfachsten Weg für die JMX-Instrumentierung dar. Die nach aussen offen gelegte Schnittstelle (Management Interface) wird spezifiziert durch das Interface RemoteTraceAppenderMBean. Dabei musste die Namenskonvention eingehalten werden, das heisst das Interface muss mit MBean enden.

Die Methoden liefern die Werte, die über die Konfiguration von Log4J gesetzt wurden. Mit Ausnahme der Methode changeLevel(..) sind alle Methoden als „read only“ definiert. Die Methoden des Interfaces werden durch die Klasse RemoteTraceAppender implementiert.

Die JMX-Schnittstelle wird durch die Klasse RemoteTraceManager beim MBean-Server registriert. Damit remotemässig auf die Schnittstelle zugegriffen werden kann, wird der Standard HtmlAdaptorServer von Sun verwendet. Dieser startet einen internen Webserver, der ein einfaches HTML-Frontend besitzt, über das dann die Methoden aufgerufen werden können.

cd JMX-Schnittstelle

«interface»appender::RemoteTraceAppenderMBean+ changeLevel(String) : void+ getApplicationID() : String+ getInitialContextFactoryClass() : String+ getJmxPort() : int+ getLevel() : String+ getLogQueueName() : String+ getProviderURL() : String



HtmlAdaptorServ er



«JMS»LogQueue

«realize»

Benutzt

Implementiert«realize»verwendet

«send»

Abbildung 3-5 : JMX-Schnittstelle



3.2.2.2 Log4-Appender Das Log4J-Framework bietet die Möglichkeit eigene Appender-Klassen zu implementieren. Dazu kann das AppenderSkeleton von Log4J als Basisklasse benutzt werden. Die Klasse RemoteTraceAppender ist als Subklasse dieser Basisklasse definiert und überschreibt die abstrakten Methoden. Für die Instanzierung und Initialisierung des eigenen Appenders sorgt das Log4J-Framework. Log-Events werden von Log4J automatisch an diesen Appender geleitet.

Die Initialisierung erfolgt durch Parameter, die im Log4J-Konfigurationsfile definiert sind und im Appender über entsprechende Setters als Properties gesetzt werden können.

Folgende Parameter sind über das Konfigurationsfile von Log4J zu setzen:

• Log-Level ab den der Appender aktiv sein soll.

• Den Klassennamen der Factory über die via JNDI-Lookup eine Connection zum JMS-Provider hergestellt werden kann.

• URL des JMS-Providers.

• Name der Log-Queue.

• Port auf dem die JMX-Schnittstelle eröffnet werden soll

• Applikations-ID, die zur Identifikation des Absenders im Server dient.

Log-Events werden über die Methode doAppend(..) von Log4J an den Appender weitergeleitet. Die weitere Verarbeitung erfolgt dann individuell. In unserem Fall werden die Log-Events mit Hilfe der Klassen RemoteTraceManager und RemoteTracer über JMS auf die Log-Queue gesendet.

cd Log4J-Appender


+ activateOptions() : void+ addPropertyChangeListener(PropertyChangeListener) : void+ append(LoggingEvent) : void+ changeLevel(String) : void+ close() : void+ doAppend(LoggingEvent) : void+ getApplicationID() : String+ getInitialContextFactoryClass() : String+ getJmxPort() : int+ getLevel() : String+ getLogQueueName() : String+ getProviderURL() : String+ removePropertyChangeListener(PropertyChangeListener) : void+ requiresLayout() : boolean+ setApplicationID(String) : void+ setInitialContextFactoryClass(String) : void+ setJmxPort(int) : void+ setLogQueueName(String) : void+ setProviderURL(String) : void+ setThreshold(Priority) : void





«JMS»LogQueue

HtmlAdaptorServ er

Singleton

verwendet

Benutzt

Implementiert«realize»

«send»

«realize»

Abbildung 3-6 : Log4J-Appender



3.2.2.3 PropertyChangeSupport Wenn über die JMX-Schnittstelle Konfigurationseinstellungen des Appenders verändert werden, kann es sein, dass die nutzende Applikation darüber informiert werden will. Dazu kann sich die nutzende Applikation in der Klasse RemoteTraceAppender als PropertyChangeListener registrieren damit sie bei Veränderungen der Konfiguration informiert wird.

Im Moment betrifft dies nur den Level, der über JMX verändert werden kann. Dieser Funktion könnte aber durch zukünftige Erweiterungen mehr Bedeutung zukommen.

3.2.2.4 JMS-Anbindung Die JMS-Anbindung wird durch die Klasse RemoteTracer realisiert. Die Klasse dient als JMS-Produzent, der die Log-Events auf die Queue sendet. Verwaltet und konfiguriert wird sie durch den RemoteTraceManager. Log-Events werden vom Appender an die Manager-Klasse geleitet, die dann mit Hilfe der Klasse RemoteTracer die Log-Events in XML-Format konvertiert und an die Log-Queue des JMS-Providers sendet.

cd JMS-Anbindung


+ browseQueue() : Vector<String>+ configure(RemoteTraceAppender) : void+ getInstance() : RemoteTraceManager+ getRemoteTraceAppender() : RemoteTraceAppender+ isConfigured() : boolean+ shutdown() : void+ trace(LoggingEvent) : void


+ RemoteTracer(RemoteTraceAppender, Properties)+ start() : void+ stop() : void+ trace(LoggingEvent) : void


«JMS»LogQueue


HtmlAdaptorServ er


«send»

verwendet

Benutzt

Implementiert

«realize»

«realize»

Abbildung 3-7 : JMS-Anbindung



3.2.3 Aktivitäten

3.2.3.1 Appender Initialisierung Die Initialisierung des Appenders wird durch Log4J übernommen. Durch die Konfiguration von Log4J wird indirekt auch der Appender initialisiert und konfiguriert.

Ablauf:

1) Log4J instanziert den Appender und ruft für alle Parameter aus dem Konfigurationsfile die entsprechende Setter-Methode auf, um die Properties zu setzen.

2) Danach wird die Methode requiresLayout(..) aufgerufen. In unserem Fall liefert diese immer false zurück, da wir kein bestimmtes Layout verwenden.

3) Log4J ruft die Methode activateOptions(..) auf. Hier wird über den RemoteTraceManager die gesamte Konfiguration des Appenders gestartet. Dazu gehört insbesondere das Starten einer JMS-Connection, um dann später Log-Events auf die Log-Queue senden zu können.

Abbildung 3-8 : Appender Initialisierung

sd Appender Initialisierung

Log4J appender::RemoteTraceAppender

seq Parameter aus Konfig-File setzten

appender::RemoteTraceManager appender::RemoteTracer

Create

call Setters

boolean:= requiresLayout()

activateOptions()

RemoteTraceManager:= getInstance()

configure(appender)

RemoteTracer(appender,props)

start()



3.2.3.2 Log-Event Verarbeitung Wird von der nutzenden Applikation über Log4J eine Meldung geloggt, wird dieses Log-Event an alle Appender gesendet, deren Log-Level nicht höher eingestellt ist als der Level der geloggten Meldung. Nach diesem Schema erhält auch unser Appender die entsprechenden Log-Events zur individuellen Weiterverarbeitung.

Ablauf:

1) Log4J ruft die Methode doAppend(..) in unserem Appender auf und übergibt das Log-Event.

2) Da der RAT-Appender und die von ihm benutzten Klassen und Libraries ebenfalls Log-Events generieren, wird zuerst geprüft, ob das Log-Event aus der nutzenden Applikation stammt. Nur Log-Events der nutzenden Applikation sollen berücksichtigt werden, da sonst die Gefahr von Endlosschlaufen besteht. Ausserdem sind die Logs aus dem RAT-Appender für die nutzende Applikation unwichtig. Stammt das Log-Event aus der nutzenden Applikation, wird die Methode append(..) aufgerufen.

3) In der Methode append(..) wird das Log-Event dem RemoteTraceManager übergeben durch Aufruf der Methode trace(..).

4) Der RemoteTraceManager prüft in der Methode trace(..), ob die JMS-Anbindung erfolgreich konfiguriert wurde, und übergibt das Log-Event dem RemoteTracer.

5) In der Methode trace(..) der Klasse RemoteTracer wird das Log-Event in XML-Format konvertiert und auf die Log-Queue des JMS-Providers gesendet.

Abbildung 3-9 : Log-Event Verarbeitung

sd Log-Ev ent Verarbeitung

appender::RemoteTraceAppenderLog4J appender::RemoteTraceManager appender::RemoteTracer

doAppend(logEvent)

append(logEvent)

RemoteTraceManager:= getInstance()

trace(logEvent)

trace(logEvent)



3.2.4 Fehlerhandling Der Appender lehnt sich an das Fehlerhandling von Log4J an. Da der Appender die nutzende Applikation nicht beeinflussen darf, ist dieser sehr fehlertolerant. Das heisst, falls bei der Initialisierung oder der Log-Event Verarbeitung ein unvorhergesehener Fehler auftritt, wird dies der nutzende Applikation nicht mitgeteilt.

Die Schnittstelle zu Log4J erlaubt keine Exception-Deklaration. Im Fall eines Fehlers wird das Log-Event vom RAT-Appender einfach nicht verarbeitet. Ähnlich verhält es sich auch bei den Standard-Appenders aus dem Log4J-Framework. Ein File-Appender, der in ein nicht existierendes Verzeichnis schreiben soll, gibt nur eine Meldung auf der Konsole aus.

Es existiert auch kein Backup-Konzept, um Log-Events, die nicht auf die Queue gesendet werden konnten, zu einem späteren Zeitpunkt zu versenden. Es wird davon ausgegangen, dass ein Log-Event ein Hilfsmittel zur Fehlersuche ist und keine Business relevante Datei. Eine gesicherte Auslieferung eines Log-Events ist erst gewährleistet ab dem Zeitpunkt, wenn sich das Log-Event auf der Queue des JMS-Providers befindet.



3.3 RAT-Server Der Server ist die zentrale Komponente des Gesamtsystems. Der Server besteht seinerseits aus folgenden Subsystemen:

• Domain-Verwaltung

• Tasks

• Dispatcher

• Webfrontend

Domain-Verwaltung: Als Domain werden die fachlichen Objekte, deren Beziehungen untereinander, die Zugriffe auf sie und die Persistierung verstanden. Der Server stellt zur Verwaltung dieser Objekte Funktionen zur Verfügung.

Tasks: Ein Task definiert die Art eines Kanals. Tasks sind Klassen oder Libraries, die bestimmte Anforderungen erfüllen müssen, um vom System als solche erkannt zu werden. Jedem Kanal wird ein Task zugeordnet, der dann die effektive Verarbeitung übernimmt.

Dispatcher: Das Dispatching aus Sicht des Servers ist das Empfangen von Log-Events über den JMS-Provider und das Publizieren beziehungsweise Weiterverteilen dieser Log-Events auf die vorkonfigurierten Kanäle.

Webfrontend Über das Webfrontend können die Domain-Objekte verwaltet, die Konfiguration des Dispatchers vorgenommen und das Dispatching überwacht werden.



3.3.1 Packageübersicht Server Das folgende Diagramm zeigt alle Packages des Servers sowie die Abhängigkeiten untereinander auf. Auf die einzelnen Klassen wird in den nachfolgenden Kapiteln genauer eingegangen.

cd Packageübersicht

v iew

+ AbstractBean+ ApplicationBean+ ChannelBean+ DispatchingBean+ MainMenu+ RuleBean+ converter

(from server)

domain

+ AbstractEntity+ AbstractMainEntity+ Application+ Channel+ ChannelParameter+ DispatchingRule+ LogEvent+ LogLevel

(from server)

util

+ ConverterUtil+ EmptySelectItem+ EnumUserType+ LogLevelUserType

(from server)

task

+ TaskClassLoader+ DispatchingTask+ system

(from server)

system

+ DBTask+ MailTask+ TopicTask

(from task)

dispatching

+ DispatchingThread+ LogEventDispatcher+ LogEventListener

(from server)

dao

+ AbstractDomainDAO+ DAOFactory+ HibernateSessionManager+ GenericDomainDAO

(from server)

application

+ RemoteTraceServerApplication+ RemoteTraceStartupContextListener

(from server)

conv erter

+ ApplicationConverter+ ChannelConverter

(from view)

controller

+ DomainController

(from server)

Abbildung 3-10 : Packageübersicht Server



3.3.2 Domain-Verwaltung

3.3.2.1 Domain-Model Im Domain-Model sind die die fachlichen Objekte (Entitäten) zusammengefasst. Jede Entität ist entweder direkt als Subklasse von AbstractEntity definiert, oder indirekt als Subklasse von AbstractMainEntity. Diese Basisklassen implementieren Gemeinsamkeiten aller Entitäten.

Von den Basis-Entitäten abgeleiten sind dann die effektiven fachlichen Entitäten. Jede dieser Entitäten widerspiegelt ein fachliches Objekt im System.

cd Basis-Entitäten

Serializabledomain::AbstractEntity

+ equals(Object) : boolean+ toString() : String

domain::AbstractMainEntity

+ AbstractMainEntity()+ AbstractMainEntity(String, String)+ equals(Object) : boolean+ getCreationTime() : Timestamp+ getDescription() : String+ getId() : Integer+ getIsMutable() : boolean+ getName() : String+ getUpdateTime() : Timestamp+ setCreationTime(Timestamp) : void+ setDescription(String) : void+ setId(Integer) : void+ setName(String) : void+ setUpdateTime(Timestamp) : void

Abbildung 3-11 : Basis-Entitäten



cd Entity-Model

AbstractMainEntitydomain::Application

+ Application()+ Application(String, String, String, String)+ getIsMutable() : boolean+ getJmxURL() : String+ getVersion() : String+ setJmxURL(String) : void+ setVersion(String) : void

AbstractMainEntitydomain::Channel

+ addParameter(String, String) : void+ Channel()+ Channel(String, String, String)+ getIsMutable() : boolean+ getParameters() : Set<ChannelParameter>+ getParamterMap() : Map<String,String>+ getTaskClassName() : String+ setParameters(Set<ChannelParameter>) : void+ setTaskClassName(String) : void

AbstractEntitydomain::ChannelParameter

+ ChannelParameter()+ ChannelParameter(String, String, Channel)+ equals(Object) : boolean+ getChannel() : Channel+ getKey() : String+ getValue() : String+ setChannel(Channel) : void+ setKey(String) : void+ setValue(String) : void

AbstractEntitydomain::DispatchingRule

+ DispatchingRule()+ DispatchingRule(Application, Channel, boolean, boolean, boolean, boolean, boolean)+ equals(Object) : boolean+ getApplication() : Application+ getApplicationName() : String+ getChannel() : Channel+ getChannelName() : String+ getDebug() : int+ getError() : int+ getFatal() : int+ getInfo() : int+ getWarning() : int+ setApplication(Application) : void+ setChannel(Channel) : void+ setDebug(int) : void+ setError(int) : void+ setFatal(int) : void+ setInfo(int) : void+ setWarning(int) : void

AbstractEntitydomain::LogEv ent

+ equals(Object) : boolean+ getApplication() : Application+ getAsXML() : String+ getEventTime() : Timestamp+ getId() : Integer+ getLevel() : LogLevel+ getLevelString() : String+ getLocation() : String+ getMessage() : String+ getSenderName() : String+ getShortMessage() : String+ LogEvent()+ LogEvent(ch.rat.common.xml.LogEvent, String)+ setApplication(Application) : void+ setAsXML(String) : void+ setEventTime(Timestamp) : void+ setId(Integer) : void+ setLevelString(String) : void+ setLocation(String) : void+ setMessage(String) : void

«enumeration»domain::LogLev el

+ fromValue(String) : LogLevel+ value() : String

0..*

betrifft

1

0..*

wurde gesendet von

1

1

gehört zu

1

0..*

gilt für

1

0..*

verwendet

1

Abbildung 3-12 : Fachliche-Entitäten

Klassen: Channel und ChannelParameter Ein Channel (Kanal) entspricht einem Ziel, in das der Dispatcher ein Log-Event publizieren soll. Einem Kanal ist immer eine Task zugewiesen, der dann die effektive Verarbeitung übernimmt. Diese Tasks sind parametrisierbar, so dass ein Task mit unterschiedlichen Parametern in verschiedenen Kanälen referenziert werden kann. Diese Parameter werden durch die Kasse ChannelParameter repräsentiert.

Klasse: Application Ein Objekt der Klasse Application entspricht einer angebundenen Applikation, die Log-Events übermittelt. Eine Applikation identifiziert den Absender eines Log-Events.

Klasse: LogEvent und LogLevel



Ein LogEvent wird aus dem übermittelten XML-String erstellt. Er repräsentiert die Meldung, die von der sendenden Applikation an den Server übermittelt wurde. Ein LogEvent ist im Prinzip das Objekt-Abbild des XML-Strings.

Klasse: DispatchingRule Eine DispatchingRule ist eine Regel, die definiert, welches Log-Event auf welchen Kanal publiziert werden soll. Sie stellt eine Verbindung zwischen einem Kanal und einer Applikation dar. Zusätzlich definiert sie einen Filter aufgrund des Levels, um nur spezifische Meldungen in den Kanal zu übergeben.

3.3.2.2 Domain-Zugriffe Alle Zugriffe auf die Domain-Objekte werden durch die Klasse DomainController ausgeführt. Sie stellt CRUD-Methoden (Create, Read, Update, Delete) für alle Entitäten zur Verfügung.

Der DomainController führt selber keine Datenbankzugriffe aus. Er holt sich über eine DAO-Factory ein DAO-Objekt und ruft die Methoden auf dem DAO auf. Er sorgt aber für das Transaktionshandling, das heisst Commits und Rollbacks von Datenbankoperationen werden durch den DomainController ausgelöst.

cd Domain-Controller

Observablecontroller::DomainController

- dataChanged(AbstractEntity) : void+ deletetApplication(Application) : void+ deletetChannel(Channel) : void+ deletetRule(DispatchingRule) : void+ getApplication(Integer) : Application+ getApplicationByName(String) : Application+ getApplicationList() : Collection<Application>+ getChannel(Integer) : Channel+ getChannelList() : Collection<Channel>+ getDispatchingRule(Integer) : DispatchingRule+ getDispatchingRules(Channel) : Collection<DispatchingRule>+ getDispatchingRules() : Collection<DispatchingRule>+ getDispatchingRulesForLogEvent(LogEvent) : Collection<DispatchingRule>+ getDomain() : DomainController+ getTaskClasses() : Collection<String>- handleException(String, Exception) : void+ insertApplication(Application) : Application+ insertChannel(Channel) : Channel+ insertRule(DispatchingRule) : DispatchingRule+ updateApplication(Application) : Application+ updateChannel(Channel, Set<ChannelParameter>) : Channel+ updateDispatchingRule(DispatchingRule) : DispatchingRule

dao


(from server)

-sIntance

Abbildung 3-13 : Domain-Controller

3.3.2.3 Persistierung (DAO) Die Persistierung (Speicherung auf die Datenbank) wird durch DAO-Objekte vorgenommen. Für jede persistente Entität existiert eine eigene DAO-Klasse. Alle DAO-Objekte können nur über die DAO-Factory instanziert werden. Zugriffe auf die DAO-Objekte erfolgen immer über den DomainController.



cd DomainDAO

TID:extends Serializable

dao::AbstractDomainDAO

+ AbstractDomainDAO()+ beginTransaction() : Transaction+ closeSession() : void+ commitTransaction() : void+ deleteEntity(T) : void+ executeQuery(String, Object[]) : List<T>+ findAll() : List<T>+ findById(ID) : T- getPersistentClass() : Class<T># getSession() : Session+ rol lbackTransaction() : void+ saveEntity(T) : T

dao::DAOFactory

+ getApplicationDAO() : ApplicationDAO+ getChannelDAO() : ChannelDAO+ getDispatchingRuleDAO() : DispatchingRuleDAO+ getInstance() : DAOFactory- instantiateDAO(Class) : AbstractDomainDAO

dao::HibernateSessionManager

+ closeSession() : void# currentSession() : Session+ getInstance() : HibernateSessionManager+ initialize() : void

«interface»dao::GenericDomainDAO~ deleteEntity(T) : void~ findAll() : List<T>~ findById(ID) : T~ saveEntity(T) : T

«static»dao::DAOFactory::ApplicationDAO

«static»dao::DAOFactory::ChannelDAO

+ deleteParameter(ChannelParameter) : void

«static»dao::DAOFactory::DispatchingRuleDAO

-factoryInstance

-sInstance

Abbildung 3-14 : Domain-DAO

Interface: GenericDomainDAO Das Interface definiert die grundlegenden CRUD-Operationen, die auf jeder Entität ausgeführt werden sollen. Das Interface arbeitet mit Generics und wird durch die Instanzierung parametrisiert, dadurch wird die Typensicherheit gewährleistet.

Klasse: AbstractDomainDAO Die Klasse implementiert alle Methoden aus dem generischen Interface und bildet die Basis für die konkreten DAO-Objekte. Die Klasse ist abstrakt definiert, obschon sie keine abstrakten Methoden besitzt. Grund dafür ist, dass die konkreten DAO-Objekte von dieser Klasse abgeleitet werden können und sie beziehungsweise das generische Interface, parametrisieren müssen.

Klasse: DAOFactory Die Klasse instanziert konkrete DAO-Objekte pro Entität und parametrisiert dabei das generische Interface.

Klassen: ApplicationDAO, ChannelDAO, DisptachingRuleDAO Dies sind die konkreten DAO-Klassen. Abgesehen vom ChannelDAO der eine zusätzliche Methode zum Löschen von Parametern besitzt, sind die anderen leere Implementationen der Basisklasse AbstractDomainDAO und dienen der korrekte Parametrisierung des generischen Interfaces.



3.3.2.4 Datenbank Durch den Einsatz von Hibernate als Objekt-Relationales Datenbanktool erübrigt sich das Design einer Datenbank. Hibernate erstellt aufgrund des Mappings von Objekten auf Datenbank-Tabellen das gesamte Datenbank-Schema. Die von Hibernate erstellten Tabellen und deren Beziehungen untereinander entsprechen dem Design des Domain-Models.



3.3.3 Tasks

3.3.3.1 Definition Ein Task ist eine Klasse oder Library, die einem Kanal zugeordnet wird. Er bestimmt damit die Art eines Kanals. Der Task beinhaltet die Logik, die nötig ist, um ein Log-Event auf einen bestimmten Kanal zu publizieren. Jeder Task kann zusätzliche Parameter haben, die beim Erfassen eines Kanals angegeben werden können. So kann der gleiche Task mit unterschiedlichen Parametern in verschiedenen Kanälen referenziert werden.

Beispiel: Der fiktive „SMSTask“ ist eine Klasse, die ein Log-Event per SMS versenden kann. Dazu benötigt sie als Parameter die Natel-Nummer des Empfängers. Dieser Task könnte nun in zwei Kanälen referenziert werden, einmal mit einer privaten Natel-Nummer und einmal mit der Geschäfts-Natel-Nummer als Parameter.

Es gibt zwei Arten von Tasks:

• Die Systemtasks sind die bereits standardmässig im System integrierten Tasks. Diese Tasks sind relativ einfach implementiert und dienen hauptsächlich zur Demonstration des Systems. In einem produktiven Umfeld würden diese die speziellen Bedürfnisse kaum abdecken können.

• Zusätzlich zu den Systemtasks können eigene Plugin-Tasks ins System (auch zur Laufzeit) integriert werden. Diese Tasks können den spezifischen Anforderungen eines produktiven Systems gerecht werden.

3.3.3.2 Implementation Tasks sind keine Entitäten wie Kanäle oder Applikationen, die verwaltbar sind. Damit das System einen Task als solchen erkennt, muss er zwingend das Interface DispatchingTask implementieren.

Das Interface definiert zwei Methoden:

• String[] getParmKeys()

• process(String,Map)

In der Methode getParmKeys() soll der Task seine Parameter, die er für die Verarbeitung braucht, in Form von „Keys“ ausgeben. Die Methode wird vom Frontend bei der Erfassung eines Kanals aufgerufen, damit Parameterwerte dazu eingegeben werden können.

Wenn der Dispatcher einen Task starten will, ruft er die Methode process(..) auf und übergibt ihm als erstes Argument das Log-Event als XML-String und eine Map mit Key/Value-Paaren, die den „Keys“ aus dem Task und den dazu eingegebenen Parametern entsprechen.

Eigene Tasks müssen in einem JAR-File in ein bestimmtes Verzeichnis kopiert werden, damit sie vom System erkannt werden. Das dynamische Laden von Klassen ausserhalb des Klassenpfades übernimmt der TaskClassLoader.

Folgendes Diagramm zeigt alle System-Tasks:



cd System-Tasks

«interface»task::DispatchingTask

+ getParmKeys() : String[]+ process(String, Map<String,String>) : void

system::TopicTask

+ getParmKeys() : String[]+ process(String, Map<String, String>) : void

system::MailTask

+ getParmKeys() : String[]+ process(String, Map<String,String>) : void

system::DBTask

+ getParmKeys() : String[]+ process(String, Map<String, String>) : void

task::TaskClassLoader

+ findImplementors() : List<String>+ loadClass(String) : DispatchingTask+ TaskClassLoader()

«instantiate»

Abbildung 3-15 : System-Tasks

3.3.4 Dispatching

3.3.4.1 Übersicht Das Dispatching ist die zentrale Aufgabe des Servers. Der Dispatcher ist der Konsument aller Log-Events, die über die Log-Queue an den Server übermittelt werden. Beim Start der Server-Applikation wird der Dispatcher automatisch gestartet, sofern er eine Verbindung zum JMS-Provider herstellen kann. Danach werden vom Dispatcher sämtliche eingehenden Log-Events verarbeitet. Wenn beim Applikationsstart keine Verbindung zum JMS-Provider hergestellt werden kann, wird der Dispatcher nicht gestartet und kann nachträglich über das Webfrontend aktiviert werden.

Die Klasse LogEventDispatcher ist der MessageListener, über den alle Log-Events empfangen werden. Die Verarbeitung beziehungsweise das Publizieren eines Log-Events auf einen Kanal wird in einem eigenen Thread, dem DispatchingThread gestartet. Dieser instanziert und startet den Task, der vom Kanal referenziert wird. Damit ist die Aufgabe des Dispatchers beendet. Die weitere Verarbeitung wird nun vom Task übernommen und läuft unabhängig vom Dispatcher ab.

Folgendes Diagramm zeigt die am Dispatching beteiligten Klassen:



cd Dispatching

Threaddispatching::DispatchingThread

+ DispatchingThread(Channel, LogEvent)+ run() : void

JMSConnectionManagerMessageListener

dispatching::LogEv entDispatcher

+ addLogDispatchListener(LogEventListener) : void+ addLogReceivedListener(LogEventListener) : void- dispatch(LogEvent) : void+ getIgnoredCnt() : long+ getPublishCnt() : long+ getReceivedCnt() : long+ getTrashCnt() : long+ LogEventDispatcher()- notifyLogDispatchListeners(LogEvent, Channel) : void- notifyLogReceivedListeners(String) : void+ onMessage(Message) : void+ removeLogDispatchListener(LogEventListener) : void+ removeLogReceivedListener(LogEventListener) : void+ start() : void+ stop() : void

task

+ TaskClassLoader+ DispatchingTask+ system

(from server)

«use»

«use»

Abbildung 3-16 : Dispatching-Klassen

3.3.4.2 Verarbeitung Die Verarbeitung des Dispatchers gliedert sich in folgende Schritte:

• Log-Events empfangen und den XML-String in ein LogEvent Objekt konvertieren. Stimmt das Format der empfangenen Meldung nicht, oder misslingt die Konvertierung (Schema-Validierung), wird die Meldung ignoriert und verworfen.

• Aus dem Log-Event wird die absendende Applikation ermittelt und alle Regeln geladen die für diese Applikation definiert sind, geladen.

• Pro gefundene Regel wird geprüft, ob das Log-Event mit dem Level aus der Regel übereinstimmt.

• Mit dem Log-Event und dem Kanal aus der Regel wird ein neuer DispatchingThread gestartet.

• In diesem Thread wird eine Instanz des referenzierten Tasks erstellt und über die Methode process(..) gestartet.



ad Dispatching

LogEventDispatcher

DispatchingThread

Pro gefundene Regeliterativ e

ActivityInitial

Konv ertieren (XML-Stringin LogEvent-Objekt)

Lesen Regeln zuLogEv ent-Absender

Stimmt dasMessage-Format?

Stimmt dasMessage-Format?

Regeln gefuden?Regeln gefuden?

Start DispatchingThread

Task-Instanz zu Kanalladen

Task starten

FlowFinal

Validierunggegenüber XML-Schema ok?

Validierunggegenüber XML-Schema ok?

FlowFinal

FlowFinal

ActivityFinal FlowFinal

[nein]

[ja]

[ja]

[nein]

[ja]

[nein]

Abbildung 3-17 : Dispatching-Ablauf



Folgendes Diagramm zeigt den detaillierten Sequenzablauf und alle beteiligten Klassen beim Verteilen eines Log-Events:

sd Dispatching-Sequenz

dispatching::LogEventDispatcherJMS xml::LogEventConverter controller::DomainController dispatching::DispatchingThread task::TaskClassLoader «interface»task::DispatchingTask

onMessage()

LogEvent:= xmlToLogEvent()

dispatch()

Collection<DispatchingRule>:= getDispatchingRulesForLogEvent()

DispatchingThread()

start()

TaskClassLoader()

DispatchingTask:= loadClass()

process()

Abbildung 3-18 : Sequenzdiagramm Dispatching

3.3.5 Webfrontend Das Webfrontend ist als JSF-Applikation im RAT-Server integriert.

Es dient der Konfiguration und Überwachung des Gesamtsystems. Dabei nutzt das Webfrontend serverseitig verschiedene Funktionen aus den anderen Subsystemen.

Über das Webfrontend können folgende Aufgaben wahrgenommen werden:

• Verwaltung der fachlichen Objekte (Entitäten)

• Konfiguration des Dispatchers

• Überwachung des Dispatchers

3.3.5.1 Schichtenmodell (MVC) Das Design des Webfrontend ist in die drei Schichten nach dem MVC-Prinzip aufgebaut. Dieser Ansatz erlaubt es, einzelne Schichten auszutauschen. Insbesondere die View-Schicht mit dem Webfrontend könnte in einem produktiven Umfeld unter Umständen mit einem Fat-Client, der mehr Möglichkeiten in Bezug auf ein Live-Monitoring bieten würde, ersetzt werden.



cd Schichtenmodell

Vie

wC

ontr

olle

rM

odel

«JSF»Userinterface

controller

+ DomainController

(from server)

dao


(from server)

v iew

+ AbstractBean+ ApplicationBean+ ChannelBean+ DispatchingBean+ MainMenu+ RuleBean+ converter

(from server)

«datastore»Datenbank

dispatching

+ DispatchingThread+ LogEventDispatcher+ LogEventListener

(from server)

Abbildung 3-19 : Schichtenmodell

View: Die View-Schicht besteht aus dem Userinterface (JSF-Seiten), also der Schnittstelle zum Benutzer, und den Beans, die die Präsentationslogik beinhalten. Für jedes Userinterface existiert serverseitig ein ManagedBean. Die Beans stellen die Kommunikation und den Datenaustausch zwischen dem Userinterface und der serverseitigen fachlichen Logik sicher. Dadurch wird die Logik für die Präsentation von der Verarbeitungslogik getrennt.

Controller: Die Controller-Schicht beinhaltet die fachliche Logik. Die Hauptkomponente ist dabei der DomainController. Für die Verwaltungsaufgaben des Webfrontends stellt er die Funktionalitäten zur Verfügung. Zur Überwachung des Dispatchers nutzen die Beans Funktionen der Dispatching-Komponenten.

Model: In der Model-Schicht sind die Datenzugriffe und die Datenbank angegliedert. Zugriffe auf die Daten erfolgen immer über die Controller-Schicht und nie direkt aus der View-Schicht.



3.3.5.2 ManagedBeans In der Präsentationsschicht existiert für jede JSF-Seite ein ManagedBean, das die Präsentationslogik für dieses spezifische Userinterface beinhaltet. Gemeinsamkeiten aller Beans, wie zum Beispiel das Fehlerhandling, sind in der gemeinsamen Oberklasse AbstractBean ausgelagert.

Folgende Übersicht zeigt alle ManagedBean und die angegliederten JSF-Seiten: cd ManagedBeans

view::AbstractBean

v iew::ApplicationBean

ValueChangeListenerObserver

v iew::ChannelBean

ObserverValueChangeListener

v iew::DispatchingBean

Observerv iew::RuleBean

«JSF»Applikationen v erwalten

«JSF»Regeln definieren

«JSF»Kanäle v erwalten

«JSF»Überwachung

Abbildung 3-20 : ManagedBeans

3.3.5.3 Request/Response-Handling Nachfolgend wird exemplarisch am Vorgang „Applikation erfassen“ der Ablauf eines Requests und der darauf folgenden Response aufgezeigt. Das Schema dieses Ablaufs gilt auch für alle anderen Vorgänge.



ad Request/Response-Handling

Controller/DAOManagedBeanJSF-Seite

Applikation speichern Validierung derBenutzereingaben

Validierungkorrekt?Validierungkorrekt?

Fehlermeldungaufbereiten

Fehlermeldung anzeigen

Applikations-DAOinstanzieren

Transaktion starten

Applikation speichern

DB-Zugrifferfolgreich?DB-Zugrifferfolgreich?

Transaktion commitenErfolgsmeldungaufbereiten

Erfolgsmeldung anzeigen

Transaktions rollback

[nein]

[ja]

[ja]

[nein]

Abbildung 3-21 : Request/Response-Handling



4 Realisierung

4.1 Entwicklungsumgebung Hier wird die Entwicklungsumgebung beschrieben, die verwendet wurde, um das Projekt zu realisieren. Es soll als Hilfestellung dienen, um die Wartung oder Weiterentwicklung des Systems zu erleichtern.

4.1.1 Eclipse

Das gesamte Projekt wurde mit Eclipse 3.1.1 und der integrierten Anbindung an die Versionsverwaltung CVS (Concurrent Versions System) entwickelt. Als einziges zusätzliches Plug-in wurde das Tomcat-Launcher Plug-in von Sysdeo verwendet.

Im Eclipse-Workspace wurden für das gesamte System folgende Teil-Projekte angelegt:

• RemoteTrace_Appender Dieses Projekt beinhaltet die Source- und Ressource Dateien des Appenders. Das Projekt besitzt Referenzen auf das Common-Projekt, um auf gemeinsam genutzte Klassen zugreifen zu können. Der Appender besitzt keine ausführbaren Klassen und kann nur im Zusammenhang mit dem Simulator getestet werden.

• RemoteTrace_Common Im Common-Projekt sind gemeinsame Klassen definiert, die von den anderen Teil-Projekten genutzt werden. Dieses Projekt soll redundanten Code verhindern.

• RemoteTrace_Server Das Server-Projekt beinhaltet das gesamte Webfrontend und die Dispatching-Logik. Das Projekt ist als Tomcat-Projekt definiert und nutzt ebenfalls Klassen aus dem Common-Teil.

• RemoteTrace_Simulator Das Simulator Projekt dient in erster Linie als Testwerkzeug, um den Appender und den Server zu testen. Es besitzt deshalb Referenzen auf das Appender-Projekt.

Zur einfacheren Konfiguration und Überwachung wurde auch OpenJMS und Tomcat als eigenständige Projekte in den Workspace integriert. Folgende Abbildung zeigt die Projektansicht in Eclipse:



Abbildung 4-1 : Java-Projekte in Eclipse

4.1.2 Zusätzliche Tools Neben den verschiedenen Text-Editoren von Eclipse und den gängigen Office-Programmen wurden noch folgende zusätzliche Tools eingesetzt:

Oxygen 6.2 (XML-Bearbeitung)

Enterprise Architect 6.0 (UML-Design)

4.2 Testhilfen

4.2.1 Simulator Da für das System im Moment keine produktiven Applikationen existieren, die den Service nutzen könnten, wurde ein Simulator entwickelt, der die Rolle einer solchen ans System angebundenen Applikation einnehmen kann.

Der Simulator erwies sich als sehr nützlich und wurde deshalb als Java-Webstart Applikation im Webfrontend integriert.

4.2.1.1 Implementation Der Simulator ist eine einfache Swing-Applikation, die den RAT-Appender nutzt, um Log-Events an den Server zu übermitteln. Er dient also auch als Demonstrations-Projekt für die Anbindung einer beliebigen Applikation an das System und zur Einbindung des Appenders. Der Simulator wurde so konzipiert, dass er in mehreren Instanzen gestartet werden kann und dabei die Rolle verschiedener Applikationen einnimmt.

Durch die Log4J-Konfiguration, die für den Simulator zur Laufzeit geändert werden kann, wird dem Simulator eine Applikations-ID zugewiesen, unter der er Log-Events an den Server übermittelt.



4.2.1.2 Bedienung Der Simulator kann im Menü „Dokumentation“ im Webfrontend des Servers als Webstart-Applikation heruntergeladen werden.

1. Nach dem Start des Simulators kann über den Button ein Dialog zum Auswählen eines Log4J-Konfigurationsfiles geöffnet werden.

2. Der Simulator konfiguriert danach Log4J mit der ausgewählten Datei und zeigt die Einstellungen des RAT-Appenders an.

3. Über die Dropdown-Liste kann der gewünschte Log-Level gewählt werden.

Der ausgewählte Level muss mindestens die gleiche Priorität aufweisen wie der Level aus dem Konfigurationsfile, sonst wird das Log-Event von Log4J nicht an den RAT-Appender weitergeleitet!

4. Der zu loggende Text kann nun in das Textfeld eingeben werden.

5. Mit dem Button wird das Log-Event vom Simulator auf dem gewählten Level geloggt. Dadurch wird das Log-Event durch Log4J an den RAT-Appender übermittelt.

6. Um eine Meldung mehrfach zu senden, kann der Button benutzt werden. Danach kann die Periodizität in Sekunden angegeben werden und der Simulator loggt den eingegebenen Text periodisch.

7. Log-Events, die der RAT-Appender auf die Queue gesendet hat, vom Server aber noch nicht abgeholt wurden, sind im unteren Textbereich angezeigt sichtbar.



Abbildung 4-2 : Simulator

4.2.2 JUnit Neben den manuellen Tests mit dem Simulator sind im Server-Projekt automatisierte Tests mit JUnit integriert.

Diese Tests sind ausgerichtet, um die Domain-Zugriffe über Hibernate zu testen. Die Gesamttests des Systems wurden nicht mit JUnit, sondern manuell mit dem Simulator durchgeführt.

Abbildung 4-3 : Junit-Tests



4.3 Eingesetzte Technologien Die hier beschriebenen Technologien wurden für die Realisierung des Gesamtsystems eingesetzt. Es soll einen Überblick verschaffen über die Konfiguration und den Einsatzort der Technologien im System.

4.3.1 Java Development Kit Für alle Java-Komponenten wurde das JDK 1.5.0_09 eingesetzt. Aus den neuen Sprach-Features wurde vor allem Folgendes verwendet:

• Generics

• For-Each Loop

• Enumerations

4.3.2 Log4J Log4j ist ein Framework zum Loggen von Anwendungsmeldungen in Java. Es wird von unzähligen OpenSource- als auch kommerziellen Softwareprodukten verwendet und hat sich als Defacto-Standard etabliert.

Der Appender setzt voraus, dass die nutzende Applikation Log4J einsetzt, da er eine Schnittstelle zu Log4J bereitstellt. Auch der Server verwendet als Logging-Framework Log4J.

4.3.3 Apache Tomcat Apache Tomcat stellt eine Umgebung zur Ausführung von Java-Code auf Webservern bereit, die im Rahmen des Jakarta-Projekts der Apache Software Foundation entwickelt wird.

Für den RAT-Server dient Apache Tomcat 5.5.4 als Servlet-Container und Compiler für die JSF-Seiten. Für die Initialisierung der Webapplikation beim Start des Webservers ist ein ServletContextListener verantwortlich.

Die URL (Context), unter dem die Webapplikation ansprechbar ist heisst:

• http:<host>:8080/RAT (Remote Application Tracing).

Details zur Konfiguration von Tomcat sind dem Kapitel „Installationsanleitung“ zu entnehmen.

4.3.4 JAXB JAXB bezeichnet eine Programmschnittstelle in Java, die es ermöglicht, Daten aus einem XML-Schema automatisch an Java-Klassen zu binden, und diese aus einer XML-Schema-Instanz heraus zu generieren. Damit soll ein Arbeiten mit XML-Daten möglich werden, ohne auf XML-Parsing-Technologien SAX und DOM angewiesen zu sein.



JAXB aus dem Java Webservices Developer Pack 2.0 wurde verwendet, um anhand des XML-Schemas eines Log-Events Java Source-Code zu generieren.

Mit Hilfe der JAXB-Libraries und der generierten ObjectFactory wird während der Verarbeitung aus den über die Log-Queue empfangenen XML-Strings konkrete Instanzen eines Log-Events erstellt.

4.3.5 OpenJMS Als JMS-Provider wurde die Open Source Implementation OpenJMS 0.7.7-alpha-3 aus der sourceforge.net-Plattform verwendet. OpenJMS hält sich an die JMS-Spezifikation 1.1 von SUN.

Für die JMS-Anbindung wurden keine OpenJMS spezifischen Schnittstellen genutzt. Damit bleibt das System unabhängig vom eingesetzten JMS-Provider. In der Konfiguration von OpenJMS wurde nur die Log-Queue definiert. Die Connections und Sessions werden von OpenJMS über einen JNDI (Java Naming and Directory Interface) - Lookup hergestellt.

Folgender Ausschnitt stammt aus dem Konfigurationsfile openjms.xml und zeigt die Definition der Log-Queue:

4.3.6 Hibernate Hibernate (engl. für „Winterschlaf halten“) in der Version 3.1.3 wurde als Open-Source-Persistenz-Framework für Java eingesetzt. Das Framework ermöglicht es, den Zustand eines Objekts in einer relationalen Datenbank zu speichern und aus entsprechenden Datensätzen wiederum Objekte zu erzeugen.

Das Erstellen des gesamten Datenbank-Schemas wurde Hibernate überlassen. Das Datenbankmodell entspricht damit den Mapping-Definitionen für Hibernate. Aufgrund der im Moment noch relativ dürftigen Dokumentation wurde das Mapping nicht mit „Annotations“ gemacht, sondern in den Mapping-Files beschrieben.

Folgende Abbildung zeigt das gesamte Konfigurationsfile hibernate.cfg.xml mit den einzelnen Referenzen auf die Mapping-Files:



Abbildung 4-4 : Hibernate Konfiguration

4.3.7 MySQL Als Datenbank verwendeten wir MySQL 5.0. Durch den Einsatz von Hibernate beschränkte sich die Konfiguration der Datenbank auf das Erstellen eines Datenbank-Schemas und der Definition eines Users.

• Schemaname: rat

• Username/Passwort: admin/root

• Datenbanktreiber: mysql-connector-java-3.1.11

Als sehr nützlich erwies sich der mit MySQL ausgelieferte QueryBrowser, um SQL-Abfragen und Auswertungen beim Testen vornehmen zu können.



4.3.8 JSF / MyFaces / Ajax Das gesamte Webfrontend wurde mit JSF implementiert. Dazu wurden Komponenten aus dem Standard API von SUN mit zusätzlichen Komponenten aus MyFaces und Ajax4Jsf kombiniert.

Folgende Versionen wurden eingesetzt:

• MyFaces 1.1.4

• Ajax4Jsf 1.0.2

Für den Einsatz von MyFaces und Ajax4Jsf mussten im web.xml der Applikation spezielle Filter definiert werden.

Abbildung 4-5 : Filter im web.xml



4.4 Implementations Details In diesem Kapitel beschreiben wir detailliert einzelne Kernelemente aus dem Gesamtsystem. Das Schwergewicht liegt dabei auf der Realisierung, um einen Einblick in die Implementation zu geben.

4.4.1 JMX HtmlAdaptorServer Der RAT-Appender stellt eine JMX-Schnittstelle zur Überwachung der Konfiguration zur Verfügung. Damit auf diese remotemässig zugegriffen werden kann, verwendeten wir die Referenzimplementierung des HTML Adapters von SUN. Dieser Adaptor selber implementiert ebenfalls ein MBean.

Der folgende Codeausschnitt aus der Klasse RemoteTraceManager zeigt das Instanzieren des HtmlAdaptorServers (Zeile 113) und die Registration der beiden MBeans beim PlatformBeanServer (Zeile 116+117):

Abbildung 4-6 : JMX Konfiguration

Nach dem Start des Adaptors steht die Schnittstelle zur Verfügung und kann über einen Webbrowser aufgerufen werden. Die URL ist dabei abhängig vom Port, der über die Log4J-Konfiguration vom Appender verwendet wurde, und entspricht folgendem Schema: http://<host>:<port>/



Dadurch gelangt man auf die Übersicht aller beim MBean-Server registrierten MBeans der so genannten „Agent View“. Das MBean mit dem Namen ratAppender ist unser eigenes, über das wir zur Detailansicht der „MBean View“ gelangen.

Abbildung 4-7 : JMX Agent View



Abbildung 4-8 : JMX MBean View

4.4.2 Persistierung mit Hibernate

4.4.2.1 Konfiguration Hibernate bezieht seine Konfiguration über das File hibernate.cfg.xml, das sich im Klassenpfad befinden muss. Den Anstoss zur Initialisierung muss aber aus der Applikation erfolgen. Dazu ruft der ServletContextListener die Methode initialize(..) in der Klasse HibernateSessionManager auf.

Folgender Code-Ausschnitt zeigt diese Methode und das Erstellen der SessionFactory für Hibernate (Zeile 48):



Abbildung 4-9 : Hibernate Initialisierung

4.4.2.2 O/R-Mapping Um eine Klasse auf eine relationale Datenbank zu speichern, müssen sogenannte Mapping-Dateien erstellt werden. Darin wird definiert, welche Objekte persistent (also von Hibernate verwaltet) sein sollen und welche Properties aus dem Objekte auf welche Attribute in der Datenbank gemappt werden sollen.

Folgender Ausschnitt zeigt das Mapping der Klasse Channel. Der Primärschlüssel wird in Zeile 12-15 zugewiesen und als automatisch generiert definiert. Da ein Kanal mehrere Parameter haben kann, wird eine 1-n Beziehung zu der Klasse ChannelParameter definiert (Zeile 18-21). Alle Properties aus der Klasse werden danach auf die Tabellen-Attribute gemappt (Zeile 24-38):



Abbildung 4-10 : Hibernate Mapping

4.4.2.3 Objekt-Zugriffe Persistente Objekte stehen immer unter der Verwaltung von Hibernate. Hibernate bemerkt Änderungen an den Objekten selbstständig und synchronisiert diese mit der Datenbank. Um selber die Kontrolle darüber zu haben, wann ein Objekt mit der Datenbank synchronisiert werden soll (Stichwort Transaktionshandling), werden die Objekte nach dem Einlesen von der Datenbank aus der Hibernate-Session herausgelöst (detached) in dem die Session geschlossen wird.

Der DomainController lädt eine Entity mit Hilfe eines DAOs (Zeile 452). Wenn die Entity erfolgreich geladen wurde, werden ihre Beziehungen zu den Parametern nachgeladen (Zeile 455+456). Durch das Schliessen der Session (Zeile 467) wird das geladene Objekt detached, das heisst Hibernate sorgt nicht mehr selbstständig für die Synchronisation mit der Datenbank:



Abbildung 4-11 : Hibernate Controller

Abbildung 4-12 : Hibernate DAO

4.4.2.4 Session-Handling Folgender Codeausschnitt aus der Klasse HibernateSessionManager zeigt, wie eine Hibernate-Session in der Methode currentSession(..) an den lokalen Thread mit Hilfe eines ThreadLocal Objektes gebunden und später in der Methode closeSession(..) wieder freigegeben wird.

Dadurch soll verhindert werden, dass in einem Thread verschiedene Sessions vorhanden sind. Dies könnte sonst zu einem inkonsistenten Zustand zwischen den Sessions und der Datenbank führen.



Abbildung 4-13 : Hibernate Session Handling

4.4.3 Live-Monitoring mit Ajax Damit der Dispatcher über das Webfrontend „live“ überwacht werden kann, wurden einzelne Teilbereiche das Frontends mit Ajax-Support ausgestattet. Dadurch ist ein manuelles Refreshen der Seite nicht mehr nötig, sie zeigt die eingehenden Meldungen in „Echtzeit“ an.

Folgende Markierungen zeigen die mit Ajax ausgerüsteten Teilbereiche:



Abbildung 4-14 : Ajax Bereiche

In der JSF-Seite wurde eine Komponente aus dem Projekt „ajax4jsf“ implementiert, die ein periodisches Polling auf den Server startet und einzelne Komponenten dadurch refresht.

Abbildung 4-15 : Ajax JSF Definition

Die einzelnen Attribute haben folgende Bedeutung:

• enabled: Das Polling soll aktiviert sein, wenn der Dispatcher gestartet ist.

• Action: Die Methode im Bean, die periodisch aufgerufen wird.



• reRender: Id’s derjenigen Komponenten, die refresht werden sollen.

• Interval: Periodizität in Millisekunden.

Dadurch ist gewährleistet, dass die JSF-Seite regelmässig das Bean nach den neuesten Daten anfragt. Das Bean seinerseits bekommt die eintreffenden Log-Events vom Dispatcher geliefert. Es implementiert das Interface LogEventListener, über das der Dispatcher das Bean über neu eingetroffene Log-Events informiert.

Der folgende Codeausschnitt zeigt das LogEventListener-Interface:

Abbildung 4-16 : LogEventListener-Interface



4.5 Build-Prozess Der Build-Prozess wurde soweit wie möglich mit Apache Ant automatisiert. In den Teil-Projekten des Appenders und des Servers existieren entsprechende Build-Files. Alle Artefakten aus dem Build-Prozess stehen in den jeweiligen Teilprojekten im Verzeichnis „build/dist/“ zur Verfügung.

4.5.1 RAT-Appender Beim Buildvorgang des Appenders werden sämtliche benötigten Sourcen, Libraries und Ressourcen zusammenkopiert, kompiliert und in ein JAR-File gepackt, das in eine Applikation eingebunden werden kann.

Artefakten:

• Appender als Jar-File

• Gezippte JavaDoc

• Gezippte Sourcen

4.5.2 RAT-Server Für den Server wird aus den Sourcen, Libraries und Ressourcen ein Web-Archiv (WAR-File) erstellt, das in einen standalone Tomcat deployt werden kann. Damit im Server die aktuellsten Downloads für den Simulator, das Task-Api und dem Appender vorhanden sind, müssen diese aus den entsprechenden Teilprojekten manuell ins Download-Verzeichnis des Servers kopiert werden.

Artefakten:

• Server als WAR-File

• Task-Api als JAR-File

• Gezippte JavaDoc

• Gezippte Sourcen

4.5.3 Simulator Der Simulator und alle von ihm verwendeten Libraries werden beim Build-Prozess als signierte JAR-Dateien für Webstart bereitgestellt. Sie müssen allerdings manuell ins Webstart-Verzeichnis des Servers kopiert werden.

Artefakten:

• Diverse Libraries als JAR-Files

• Simulator als JAR-File



5 Testen

5.1 Einleitung

5.1.1 Zweck der Tests Hauptziel der Tests ist die Überprüfung der Funktionalitäten und damit die Erbringung des Nachweises, dass alle Funktionalitäten gemäss den definierten Anforderungen implementiert wurden.

Weiter dienen die Tests der Qualitätssicherung. Die Tests ermöglichen das Auffinden von Fehlern in der Analyse, dem Design sowie in der Realisierung. Mit den Tests sollen Fehlfunktionen verhindert werden.

Der Testaufbau wurde so definiert, dass er eine Wiederholbarkeit und damit ein standardisiertes Vorgehen sicherstellt. Der Testaufbau sowie die definierten Testfälle werden in den nachfolgenden Kapiteln erläutert.

5.1.2 Testumgebung Die Testumgebung beschreibt die Hardware, welche wir zur Durchführung der Tests einsetzten

Damit das System verteilt getestet werden kann, benutzen wir drei PCs, die über ein WLAN miteinander verbunden wurden.

Auf dem PC1 wird der RAT Server und der OpenJMS Server gestartet. Auf den PC2 und PC3 wird der Simulator gestartet und ein Browser geöffnet, damit auf die Verwaltung des RAT Servers zugegriffen werden kann.

Die nachfolgende Abbildung zeigt die Testumgebung grafisch auf:

Testaufstellung

PC 3- RAT Browser- Simulator

PC 2- RAT Browser- Simulator

PC 1- RAT Server- JMS

WLANmit Internet

Abbildung 5-1 : Testaufstellung



5.1.3 Testaufbau Der Testaufbau beschreibt erstens, welche Testarten durchgeführt wurden und zweitens welche Bereiche des Systems getestet wurden.

Im Sinne von Testarten führten wir Funktions- und Performancetests durch. Mit den Funktionstests werden die funktionalen Anforderungen gemäss den Use Cases an das System überprüft. Die Performancetests erlauben die Beurteilung der Leistungsfähigkeit des Systems in Bezug auf die Verarbeitungsgeschwindigkeit.

Im Rahmen der Funktionstests testeten wir die Serververwaltung, der Appender sowie das Gesamtsystem.

5.1.4 Vorgehen In einem ersten Schritt wurden während der Entwicklung die einzelnen Klassen des Servers getestet. Diese Einzeltests werden automatisiert mit JUnit durchgeführt. Die Tests werden beim Erstellen der jeweiligen Klasse definiert und erstellt. Sie sind hier nicht weiter aufgeführt.

In einem zweiten Schritt werden die Funktionstests in Bezug auf den Server, den Appender sowie das Gesamtsystem durchgeführt.

In einem dritten Schritt folgt schliesslich die Überprüfung der Performance.

Die folgende Grafik zeigt den Testaufbau sowie das Vorgehen:

Die Resultate der Tests sind jeweils direkt in den Testfällen aufgelistet.

Die Tests wurden am 31.10.2006 durchgeführt.

Testfälle:• Login/Logout• Applikationen

verwalten• Kanäle verwalten• Dispatching

konfigurieren• Statistiken abfragen• Onlinehilfe• Online-

dokumentation

Testfälle:• Simulator starten• LogEvent erstellen

und senden• Zugriff auf Appender

mit JMX prüfen

Testfälle:• LogEvent mit Mail

versenden• LogEvent in Topic

Kanal senden• LogEvent in DB

Kanal senden• Inhalt der Kanäle

anzeigen• Skalierbarkeit testen• Dispatcher Regeln

überprüfen

JUnit-Tests auf Klassen

Testfälle:• LogEvents periodisch senden• Antwortzeiten vom Webfrontend

Testbereiche

Performance-tests

Funktions-tests

Test

arte

n

Serververwaltung Appender Gesamtsystem



5.2 Funktionstests

5.2.1 Test Serververwaltung

5.2.1.1 Login/Logout Aktivität Erwartetes Resultat Tatsächliches

Resultat Befund

Aufrufen des Servers über einen Browser mit: http://<host>:8080/rat

Login Seite wird angezeigt. Die Startseite wird angezeigt.

Nicht implementiert.

Bestehender User und Passwort eingeben. Login drücken.

Home Seite wird angezeigt. Ist nicht vorhanden. Nicht implementiert.

Falscher User oder falsches Passwort wird eingegeben. Login drücken.

Login Seite wird wieder angezeigt.

Ist nicht vorhanden. Nicht implementiert.

5.2.1.2 Applikationen verwalten Vorbedingungen:

• Server läuft Aktivität Erwartetes Resultat Tatsächliches

Resultat Befund

Im Menü Applikationen auswählen.

Screen wird angezeigt. Vorhandene Applikationen werden aufgelistet.

Screen wird angezeigt. Vorhandene Applikationen werden aufgelistet.

Ok.

Erfassen Felder ausfüllen und Speichern drücken. Name: SWS WebServer Beschreibung: Text JMX-Schnittstelle: http://localhost:9500

Applikation wurde erfasst. Wird mit einer Meldung bestätigt und die Applikation erscheint in der Liste.

Applikation wurde erfasst. Wird mit einer Meldung bestätigt und die Applikation erscheint in der Liste.

Ok.

Ändern Applikation aus Liste auswählen. Werte verändern und Speichern drücken. Es dürfen nur Applikationen geändert werden, für die keine Regeln definiert sind.

Attribute werden in den Feldern angezeigt. Applikation erscheint mit geänderten Werten in der Liste. Diese können in der Liste nicht ausgewählt werden.

Attribute werden in den Feldern angezeigt. Applikation erscheint mit geänderten Werten in der Liste. Diese können in der Liste nicht ausgewählt werden.

Ok.

Plausibilität auf Feldern prüfen: - Im Feld Name > 20 Zeichen

eingeben. - Beschreibung > 200 Zeichen

eingeben.

Fehlermeldung: zu lang. Fehlermeldung: zu lang.

Es können nicht mehr Zeichen eingegeben werden. Es können nicht mehr Zeichen eingegeben

Ok.



- Im Feld URL nur Zahlen

eingeben. - Keine Eingaben.

Fehlermeldung: keine URL. Fehlermeldung: Es muss ein Wert eingegeben werden.

werden. Fehlermeldung: keine URL. Fehlermeldung: Es muss ein Wert eingegeben werden.

Löschen Applikation aus Liste auswählen. Löschen drücken.

Applikation erscheint nicht mehr in der Liste

Meldung, dass Applikation gelöscht wurde. Sie erscheint nicht mehr in der Liste

Ok.

5.2.1.3 Kanäle verwalten Vorbedingungen:

• Server läuft • Task ist implementiert

Aktivität Erwartetes Resultat Tatsächliches Resultat

Befund

Im Menü Kanäle auswählen Screen wird angezeigt. Vorhandene Kanäle werden aufgelistet.

Screen wird angezeigt. Vorhandene Kanäle werden aufgelistet.

Ok.

Erfassen Felder ausfüllen und Speichern drücken. Name: DB Test Beschreibung: Text Task auswählen und Werte eintragen.

Felder können ausgefüllt werden. Kanal erscheint in der Liste. Felder sind wieder leer.

Felder können ausgefüllt werden. Kanal erscheint in der Liste. Felder sind wieder leer.

Ok.

Ändern Kanal aus Liste auswählen. Werte verändern und Speichern drücken.

Attribute werden in den Feldern angezeigt. Kanal erscheint mit geänderten Werten in der Liste.

Attribute werden in den Feldern angezeigt. Kanal erscheint mit geänderten Werten in der Liste.

Ok.

Plausibilitätsprüfung auf Feldern prüfen: - Im Feld Name > 20 Zeichen

eingeben. - Beschreibung > 200 Zeichen

eingeben. - Nichts eingeben.

Fehlermeldung: zu lang. Fehlermeldung: zu lang. Fehlermeldung: Es muss ein Wert eingegeben werden.

Es können nicht mehr Zeichen eingegeben werden. Es können nicht mehr Zeichen eingegeben werden. Fehlermeldung: Es muss ein Wert eingegeben werden.

Ok.

Plausibilitätsprüfung auf Feldern der Taks prüfen: Es dürfen max. 100 Zeichen erfasst werden können.

Fehlermeldung: zu lang.

Es können nicht mehr Zeichen eingegeben werden.

Ok.

Löschen Ok.



Kanal aus Liste auswählen. Löschen drücken.

Kanal erscheint nicht mehr in der Liste.

Meldung, dass Kanal gelöscht wurde. Kanal erscheint nicht mehr in der Liste.

5.2.1.4 Dispatching konfigurieren Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst


Befund

Im Menu das Dispatching auswählen.

Screen wird angezeigt. Die vorhandenen Regeln werden in einer Liste angezeigt.

Screen wird angezeigt. Liste ist vorhanden.

Ok.

Erfassen Im Konfigurationsbereich ein Kanal und eine Applikation ausgewählen. Die LogLevel ausgewählen

Kanäle und Applikationen können ausgewählt werden. Die LogLevel können ausgewählt werden.

Kanäle und Applikationen können ausgewählt werden. Die LogLevel können ausgewählt werden.

Ok.

Ändern Aus einer Liste die gewünschte Regel auswählen. Im Konfigurationsbereich die LogLevel verändern.

Regel kann ausgewählt werden und die Details werden angezeigt. Auswahl kann verändert werden.

Regel kann ausgewählt werden und die Details werden angezeigt. LogLevel kann verändert werden.

Ok.

Löschen Regel aus der Liste löschen.

Regel kann aus der Liste gelöscht werden.

Regel kann aus der Liste gelöscht werden.

Ok.

5.2.1.5 Statistiken abfragen Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Auf der Tabelle für das Eingangsprotokoll sind Daten vorhanden


Befund

Im Menu Statistiken auswählen.

Screen wird angezeigt Menu gibt es nicht. Nicht implementiert.

Applikation, Log-Level auswählen. Zeitraum eingeben. Start drücken.

Daten werden angezeigt. Grafik wird angezeigt.

Ist nicht möglich.

Nicht implementiert.



5.2.1.6 Onlinehilfe Vorbedingungen:


Resultat Befund

Auf jedem Screen kann die Onlinehilfe aufgerufen werden.

Die Onlinehilfe wird in einem separaten Fenster geöffnet. Es werden Informationen zum Inhalt und dem Gbrauch des entsprechenden Screens angezeigt.

Hilfefenster werden geöffnet.

Ok.

5.2.1.7 Onlinedokumentation Vorbedingungen:


Resultat Befund

Im Menu Dokumentation auswählen.

Der Screen wird angezeigt. Der Screen wird angezeigt. Ok.

Dokumentation öffnen. Die Dokumentation des Systems kann als PDF geöffnet werden.

Die Dokumentation des Systems kann als PDF geöffnet werden.

Ok.

5.2.2 Test Appender

5.2.2.1 Simulator starten Vorbedingungen:

• JMS Service läuft Aktivität Erwartetes Resultat Tatsächliches

Resultat Befund

Den Simulator starten. Der Simulator wird gestartet. Es öffnet sich ein Fenster.

Simulator wird gestartet. Ok.

Konfigurations-File laden. Verbindung wird erstellt. Simulator ist bereit.

File kann eingelesen werden, die Verbindung zum JMS wurde hergestellt.

Ok.



5.2.2.2 LogEvent erstellen und senden Vorbedingungen:

• Simulator läuft • JMS Service läuft und Simulator ist damit verbunden


Befund

Im Simulator den Log-Level auswählen. Einen Meldungstext eingeben. Senden drücken.

Meldung wird gesendet. Mit Queue Browser überprüfen.

Es ist eine Meldung in der Queue.

Ok.

5.2.2.3 Zugriff auf Appender mit JMX Vorbedingungen:

• Server läuft • Simulator mit Appender läuft


Befund

Im Menu Applikationen auswählen.

Screen wird angezeigt. Screen wird angezeigt. Ok.

Auf die URL der gewünschten Applikation klicken.

JMX Schnittstelle wird in einem separaten Fenster angezeigt. Der Modus online/offline kann verändert werden. Der LogLevel, ab dem die Events gesendet werden, kann verändert werden.

Wird geöffnet. Modus kann nicht umgestellt werden. LogLevel kann verändert werden.

Ok. Nicht implementiert. Ok.



5.2.3 Test Gesamtsystem

5.2.3.1 LogEvent mit Mail versenden Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft • Verbindung mit dem Internet ist hergestellt


Befund

Mail Kanal erfassen. Empfänger: [email protected] Betreff: RAT Mail

Kanal kann erfasst werden. Kanal konnte erfasst werden. Ok.

Im Simulator eine Meldung erzeugen, die gemäss den Dispatching-Regeln ein Mail versendet.

Der Mail Empfänger erhält eine Mail mit dem LogEvent als Inhalt.

Mail wurde empfangen. Ok.

5.2.3.2 LogEvent in Topic Kanal senden Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft


Befund

Kanal für ein Topic erfassen. Destination: queue1 ProviderURL: tcp://localhost:3035

Kanal kann erfasst werden. Kanal konnte erfasst werden.

Ok.

Im Simulator eine Meldung erzeugen, die gemäss den Dispatching-Regeln in eine Queue weitergeleitet werden soll.

Mit einem Queue-Browser in der entsprechenden Queue den Inhalt überprüfen.

Es ist eine Meldung in der Queue.

Ok.

mailto:[email protected]



5.2.3.3 LogEvent in DB Kanal senden Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft • Datenbank und Tabelle sind angelegt


Befund

DB Kanal erfassen. Datenbank: jdbc:mysql://loacalhost:3306/ratdb Passwort: admin User: root DriverClass: com.mysql.jdbc.Driver

Kanal kann erfasst werden. Kanal konnte erfasst werden.

Ok.

Im Simulator eine Meldung erzeugen, die gemäss den Dispatching-Regeln in die DB gespeichert werden soll.

Mit einem DB-Viewer in der entsprechenden Tabelle den Inhalt überprüfen.

Die Meldung wurde in der Tabelle eingetragen. Ok.

5.2.3.4 Inhalt der Kanäle anzeigen Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft


Befund

Auf dem Kanal-Browser einen Kanal auswählen.

Kanal kann ausgewählt werden.

Kanal kann ausgewählt werden. Ok.

Mit Simulator eine Meldung erzeugen.

Die Meldung ist im Browser ersichtlich. Weitere Meldungen werden automatisch angezeigt.

Die Meldung ist im Browser ersichtlich. Weitere Meldungen werden automatisch angezeigt.

Ok.



5.2.3.5 Skalierbarkeit testen Vorbedingungen:

• 2 Server laufen • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft


Befund

Es muss ein Kanal erfasst werden, der auf die Queue eines RAT Servers zeigt.

Kanal kann erfasst werden. Kanal kann erfasst werden. Ok.

Regel erfassen, dass LogEvents weitergeleitet werden.

Regel kann erfasst werden. Kanal kann erfasst werden. Ok.

LogEvent erzeugen. LogEvent wird vom ersten Server empfangen und an den zweiten weitergeleitet.

Das LogEvent wird vom zweiten Server empfangen

Ok.

5.2.3.6 Dispatcher Regeln überprüfen Vorbedingungen:

• Server läuft • Kanäle und Applikationen sind erfasst • Simulator mit Appender läuft • Regeln sind erfasst • JMS Service läuft und Simulator ist damit verbunden


Befund

Im Simulator eine Meldung erzeugen, die gemäss den Dispatching-Regeln in einen Kanal weitergeleitet werden soll.

Meldung erscheint im Kanal. Meldung erscheint im Kanal.

Ok.

Im Simulator eine Meldung erzeugen, die gemäss den Dispatching-Regeln, nicht weitergeleitet werden soll.

Meldung erscheint in keinem Kanal.

Meldung erscheint in keinem Kanal. Ok.



5.3 Performancetests

5.3.1 LogEvents periodisch senden Vorbedingungen:

• X Simulator laufen • Kanäle und Applikationen sind erfasst • Regeln sind erfasst • JMS Service läuft und Simulator ist damit verbunden


Befund

Meldung auf einem Simulator erzeugen und in einem Intervall von einer Sekunde senden.

Meldungen werden empfangen und weiterverarbeitet.

Meldungen werden empfangen und weiterverarbeitet.

Ok.

So lange weitere Simulatoren starten, bis es zu einem Engpass kommt.

Damit die Anforderungen gemäss dem Mengengerüst erfüllt sind, sollten 12 Simulatoren parallel Meldungen senden können.

? Nicht durchgeführt, neuer Testfall definiert (siehe nächster Testfall)

In dem Loop Kanal wird der TopicTask verwendet. Dort wird der Output auf den Input vom RAT Server geleitet (localhost).

Es gibt einen Loop. Wie hoch ist der Durchsatz?

Der Durchsatz beträt ca. 30 Meldungen pro Sekunde. Bei dem Erhöhen der Meldungen stauen sich diese in der import Queue.

Liegt um das doppelte so hoch wie gefordert! Der RAT Server ist der schwächere.

5.3.2 Antwortzeiten vom Webfrontend Vorbedingungen:

• Mit dem Loop Meldungen seden Aktivität Erwartetes Resultat Tatsächliches

Resultat Befund

Im Menu die einzelnen Menupunke anwählen.

Die Seiten sollten in 2 Sekunden neu aufgebaut sein.

Der Server braucht zwischen 2 bis 3 Sekunden, bis die Seiten aufgebaut sind.

Die Anforderung wurde beinahe erreicht.



5.4 Zusammenfassung und Beurteilung der Tests Die Funktionstests in Bezug auf die Testbereiche Serververwaltung, Appender und Gesamtsystem haben gezeigt, dass die definierten Funktionen erfüllt werden. Während den Funktionstests mussten keine Fehler identifiziert werden. Gesamthaft betrachtet unterstreichen die Funktionstests, dass das System qualitativ hochstehend implementiert werden konnte.

Die Funktionen Login/Logout sowie Statistiken konnten im Rahmen der Funktionstests nicht überprüft werden, da diese nicht implementiert wurden. Beide Funktionen haben wir aus Zeitgründen bewusst nicht umgesetzt (siehe auch Kapitel 8.1 Zielerreichung).

In Bezug auf die Performance liegen die Testergebnisse etwas unter den Anforderungen. Der Aufbau von Seiten dauerte statt den erwarteten 2-3 Sekunden bis zu 5 Sekunden, je nach Auslastung des Servers.

Zusammenfassung der Testergebnisse:

☺ ☺ ☺☺

Testbereiche

Performance-tests

Funktions-tests

Test

arte

n

Serververwaltung Appender Gesamtsystem



6 Installationsanleitung Die Installationsanleitung beschreibt die Schritte, die nötig sind, um das Gesamtsystem betreiben zu können. Dabei gehen wir davon aus, dass OpenJMS als JMS-Provider und MySQL als Datenbank eingesetzt wird und zur Verfügung steht.

Sollen andere Produkte eingesetzt werden, hat dies Einfluss auf die Konfigurationseinstellungen und die benötigten Libraries.

6.1 Einbinden Appender in Applikationen

6.1.1 Voraussetzungen Um den RAT-Appender in eine Applikation einzubinden, müssen folgende Voraussetzungen erfüllt sein:

• Applikation verwendet als Logging-Framework Log4J.

• Der JMS-Provider muss über das Netzwerk erreichbar sein.

• Offener Port für die JMX-Schnittstelle muss zur Verfügung stehen.

6.1.2 Einbinden Der RAT-Appender steht als JAR-File zur Verfügung und muss in der nutzenden Applikation in ein im Klassenpfad befindliches Verzeichnis kopiert werden. Der RAT-Appender kann vom Frontend des Servers als Download bezogen werden.

Neben dem Appender werden diverse zusätzliche Libraries im Zusammenhang mit XML-Verarbeitung, JMX und der JMS-Anbindung benötigt. Die zusätzlichen JAR-Files können dem Simulator entnommen werden.

Übersicht aller für den Appender notwendigen Libraries:

Abbildung 6-1 : Appender Jars



6.1.3 Konfiguration Im Konfigurations-File von Log4j muss der RAT-Appender mit den gewünschten Parametern definiert werden:

Abbildung 6-2 : Log4-Konfiguration

Threshold: Definiert den Log-Level ab dem ein Log-Event auf die Queue gesendet werden soll. Mögliche Werte sind:

• DEBUG

• INFO

• WARNING

• ERROR

• FATAL

• OFF

• ALL

InitialContextFactoryClass: Die Factory-Klasse, über die mit einem JNDI-Lookup eine Connection zum JMS-Provider erstellt werden kann.

ProviderURL:

Die URL, auf der der JMS-Provider erreichbar ist.

LogQueueName:

Name der Queue, auf die Log-Events gesendet werden sollen.

JmxPort: Port, auf dem die JMX-Schnittstelle eröffnet werden soll.

ApplicationID:

Identifikation der nutzenden Applikation.



6.2 RAT-Server in Tomcat deployen

6.2.1 Voraussetzungen Als Voraussetzung für die Installation des Servers muss sichergestellt sein, dass die Kommunikation mit dem JMS-Provider und der Datenbank gewährleistet ist.

Der Vorgang für ein korrektes Deployment ist abhängig von der eingesetzten Version von Tomcat. Der nachfolgend beschriebene Vorgang wurde mit Tomcat Version 5.5.20 getestet.

6.2.2 Deployment Das ausgelieferte WAR-File beinhaltet sämtliche für die Server-Applikation benötigten Dateien und kann in eine standalone Tomcat-Installation integriert werden.

Das „RatServer.war“ kann direkt in das Webapp-Verzeichnis von Tomcat kopiert werden. Tomcat entpackt anschliessend das WAR-File und startet die Applikation.

Abbildung 6-3 : Tomcat

6.2.3 JNDI-Definitionen Der Server verwendet Ressourcen die von Tomcat als JNDI-Ressourcen bereitgestellt werden müssen. Dazu gehört die „DataSource“ die von Hibernate verwendet wird um eine Connection über eine JNDI-Lookup zur Datenbank herstellen zu können. Zusätzlich müssen Environment-Variablen definiert sein, die für den Lookup einer Connection zu dem JMS-Server verwendet werden.

Alle Ressourcen sind im File „context.xml“ im META-INF Verzeichnis der Applikation definiert. Tomcat kopiert beim Deploymentvorgang dieses File ins Verzeichnis



„conf/Catalina/localhost“. Falls eine andere Datenbank oder ein anderer JMS-Provider verwendet werden soll, können in diesem File die Werte entsprechend angepasst werden.

Abbildung 6-4 : Context.xml

6.3 Plugin-Task entwickeln und integrieren Um eigene Tasks zu entwickeln, sind nur das Interface DispatchingTask und das Schema logging-event.xsd nötig. Beides kann über das Webfrontend als downloadbares API bezogen werden.

Schema: Das Schema dient dazu das Log-Event, dass als XML-String dem Task übergeben wird zu parsen und gegebenenfalls in die Objektwelt zu konvertieren.

Interface: Das Interface dient dem System dazu einen Task als solchen zu erkennen. In der Methode getParmKeys(..) soll der Task seine gewünschten Parameter als „Keys“ ausgeben, damit der Dispatcher beim Aufruf von process(..) das Log-Event als XML und die Werte zu den „Keys“ übergeben kann.

Ein neuer Task muss am Schluss als JAR-File vorliegen. Das JAR-File kann beliebige Source- und Ressource Dateien beinhalten. Allerdings darf nur die Einstiegsklasse das Interface DispatchingTask implementieren. Diese Klasse wird vom Dispatcher aufgerufen um ein Log-Event zu verarbeiten.

Die Integration eines neu entwickelten Tasks kann auch während der Laufzeit des Servers erfolgen:

1) JAR-File in Verzeichnis „task-lib“ des Servers kopieren.

2) Auf Seite „Kanäle“ navigieren (oder Seite refreshen)

3) „Neuer Kanal“ auswählen

4) In der Auswahlliste sollte der neue Task sichtbar sein, und kann verwendet werden.



7 Benutzerhandbuch

7.1 Einleitung Das vorliegende Benutzerhandbuch soll dem User eine Hilfestellung in der Anwendung des Systems bieten.

Das Handbuch erläutert zuerst die Navigation, die Hilfe-Funktion und die wichtigsten Bedienelemente des Systems. Anschliessend wird aufgezeigt, wie der Anwender Log-Meldungen überwachen kann. Ebenfalls wird erläutert, wie der Anwender neue Applikationen, Kanäle und Regeln erfassen respektiv bereits erfasste Applikationen, Kanäle und Regeln bearbeiten kann. Schliesslich stehen dem Anwender im Frontend auch verschiedene Dokumentationen zur Verfügung, die ihm weitergehende Hilfestellungen und Informationen präsentieren.

7.2 Einführende Bemerkungen Die Serverapplikation wird über das Internet/Intranet mit der Eingabe der URL http://<host>:8080/rat gestartet.

Nachfolgend werden die Navigation, die Hilfe-Funktion sowie die wichtigsten Bedienelemente des Systems beschrieben.

7.2.1 Navigation Über die Navigation auf der linken Bildschirmseite können die einzelnen Menu-Punkte angewählt werden. Die Navigation zeigt alle aufrufbaren Seiten auf und bleibt in dieser Form immer sichtbar.

Abbildung 7-1 : Navigation

Navigation



7.2.2 Hilfe Für jeden Menupunkt stehen dem Anwender kontextbezogene Informationen im Sinne von Hilfestellungen zur Verfügung. Diese pdf-Dokumente können durch Anklicken des Help Buttons aufgerufen werden.

Abbildung 7-2 : Hilfe

7.2.3 Bedienelemente auf den Verwaltungsseiten Im Menupunkt „Verwaltung“ stehen dem Anwender auf den Seiten „Applikationen“, „Kanäle“ und „Regeln“ immer dieselben Bedienelemente zur Verfügung:

Bedienelement Erklärung

Details anzeigen: Durch Anklicken des Symbols werden die Details zum Listeninhalt angezeigt.

Im Menupunkt „Regeln“ können grundsätzlich keine Details angezeigt werden.

Editieren: Durch Anklicken des Symbols können die Details zum Listeninhalt bearbeitet werden. Änderungen können durch Anklicken des Buttons „Speichern“ gespeichert werden. Nach erfolgter Speicherung erfolgt eine Bestätigung durch das System. Sollen die Änderungen nicht gespeichert werden, kann die Bearbeitung mit Anklicken des Buttons „Abbrechen“ abgebrochen werden.

Editierbar sind nur Applikationen und Kanäle, für welche keine Regeln definiert sind.

Hilfe



Bedienelement Erklärung

Löschen: Durch Anklicken des Symbols kann das entsprechende Objekt gelöscht werden.

Gelöscht werden können nur Applikationen und Kanäle, für welche keine Regeln definiert sind.

Blättern: In der Liste werden immer nur 5 Objekte angezeigt. Durch Anklicken auf die nachfolgenden Symbole kann in der Liste geblättert werden:

An den Anfang der Liste

5 Objekte zurück

5 Objekte vorwärts

An den Schluss der Liste



7.3 Frontend Verwaltung

7.3.1 Startseite / Überwachung Auf der Startseite erscheint der Menupunkt „Überwachung“. Hier soll der Dispatching-Vorgang überwacht werden können. Dazu wird eine Verarbeitungsstatistik angezeigt mit folgenden Informationen:

• Anzahl empfangene Log-Meldungen. • Anzahl verteilte Log-Meldungen (wie viele der empfangenen Log-Meldungen

auf Grund der definierten Regeln verteilt wurden). • Anzahl ignorierte Log-Meldungen (bei wie vielen Log-Meldungen keine Regel

gefunden wurden; diese Log-Meldungen werden vom System ignoriert). • Anzahl ungültige Log-Meldungen (Log-Meldungen die vom System nicht

gelesen werden konnten).

Eingehende Log-Meldungen werden in einer Liste (maximal 10 Zeilen) angezeigt. Diese Liste zeigt jedes empfangene Log-Event das dem erwarteten Format entspricht an.

Über den Button kann der Dispatcher gestartet oder gestoppt werden. Dadurch wird der Empfang von Log-Events aus der Queue angehalten beziehungsweise fortgesetzt.

Im unteren Bereich der Seite kann ein Kanal aus der Drop-Down-Box gewählt werden, um in tabellarischer Form alle Log-Events anzuzeigen die vom Dispatcher in diesen Kanal gesendet wurden.



Abbildung 7-3 : Überwachung

7.3.2 Verwaltung Unter dem Menupunkt „Verwaltung“ können die Applikationen, Kanäle und Regeln erfasst, bearbeitet oder gelöscht werden.

7.3.2.1 Applikationen verwalten Im Menupunkt „Verwaltung – Applikationen“ können Applikationen neu erfasst, bearbeitet oder gelöscht werden.

Sollen LogMeldungen von einer Applikation mit dem RAT verarbeitet werden können, muss die Applikation zuerst im RAT erfasst werden. Dies geschieht durch Anklicken des Buttons „Neu“. Für die Erfassung von neuen Applikationen müssen folgende Attribute in der Detailansicht definiert und gespeichert werden:

Attribute Erklärung

Id Die Id wird vom System automatisch generiert.

Name Erfassung des Namens der Applikation. Es wird empfohlen, einen möglichst kurzen und prägnanten Namen zu wählen.

Version Erfassung der Version der Applikation.

Beschreibung Erfassung von wichtigen Zusatzinformationen zur Applikation, wie zum Beispiel Ansprechperson.




JMX-Schnittstelle Erfassung der JMX-Schnittstelle. Über die JMX-Schnittstelle kann der Appender beeinflusst werden. Es kann definiert werden, ab welchem LogLevel Meldungen gesendet werden sollen.

Mit dem Bedienelement „Editieren“ können bereits erfasste Applikationen bearbeitet werden. Dies ist jedoch nur möglich, sofern keine Regeln zur Applikation erfasst sind.

Mit dem Bedienelement „Löschen“ kann eine bereits erfasste Applikation aus dem RAT gelöscht werden, sofern keine Regeln zur Applikation erfasst sind. LogMeldungen von dieser Applikation werden damit nur noch an das RAT gesendet, können aber nicht mehr weiter verarbeitet werden.

Abbildung 7-4 : Applikationen verwalten



7.3.2.2 Kanäle verwalten Damit die LogEvents verteilt werden können, müssen die Kanäle im System erfasst werden. Wie die Applikationen müssen auch die Kanäle erfasst sein, damit die LogMeldungen vom System verarbeitet werden können.

Zur Erfassung eines neuen Kanals müssen zuerst folgende Attribute eingegeben werden:


Id Die Id wird vom System automatisch generiert.

Name Erfassung des Namens des Kanals. Es wird empfohlen, einen möglichst kurzen und prägnanten Namen zu wählen.

Beschreibung Erfassung von wichtigen Zusatzinformationen zum Kanal, wie zum Beispiel zum Anwenderkreis, der den Zugriff auf die LogMeldungen auf dem definierten Verteilkanal wünscht.

Task-Klasse Mit der Task-Klasse wird definiert, mit welcher Technologie die LogMeldungen verteilt werden sollen. Die Task-Klassen sind im System vordefiniert und können mit einem Pull-Down-Menu ausgewählt werden. Folgende Task-Klassen stehen zur Auswahl:

• DBTask LogMeldungen werden auf eine Datenbank geschrieben.

• TopcTask LogMeldungen werden an eine Queue oder ein Topic gesendet.

• MailTask LogMeldungen werden via E-Mail versendet.

Die notwendigen Attribute zur Erfassung der Task-Klasse sind in den nachfolgenden Kapiteln detailliert beschrieben.

Abbildung 7-5 : Kanäle verwalten



DBTask Damit LogMeldungen auf eine Datenbank geschrieben werden, müssen folgende Attribute der Task-Klasse definiert werden:


Datenbank Eingabe der Datenquelle.

DriverClass Eingabe des Datenbanktreibers.

User Eingabe des Namens des Datenbank-Users.

Passwort Eingabe des Passwortes des Datenbank-Users.

Als Datenbank ist aktuell MySQL installiert. Soll eine andere Datenbank verwendet werden, dann kann diese installiert und mit dem entsprechenden Datenbanktreiber angesprochen werden.

Abbildung 7-6 : Attribute DB Task

TopicTask Damit LogMeldungen an eine Queue oder ein Topic gesendet werden, müssen folgende Attribute der Task-Klasse definiert werden:


ProviderURL Angabe URL und Port des JMS-Servers.

Destination Name der Queue oder des Topics.



Abbildung 7-7 : Attribute Topic Task

MailTopic Damit LogMeldungen via E-Mail versendet werden, müssen folgende Attribute der Task-Klasse definiert werden:


Subject Betreff des E-Mails.

Recipient Empfänger des E-Mails.

Abbildung 7-8 : Attribute Mail Topic



7.3.2.3 Dispatching Regeln Mit den Regeln wird definiert, welche eingehenden LogMeldungen vom RAT weiterverarbeitet und an einen definierten Kanal weitergeleitet werden.

Regeln werden auf einem bestimmten Kanal auf einer bestimmten Applikation definiert. Entsprechend müssen sowohl die Applikationen als auch die Kanäle erfasst sein, damit Regeln definiert werden können.

In der Übersicht sind die bereits erfassten Regeln aufgelistet. Es ist ersichtlich, welche Applikation mit welchen LogLevels in welchen Kanal schreibt. Folgende LogLevels sind definiert:

LogLevel Erklärung

FATAL

ERROR

WARNING

INFO

DEBUG

Eine neue Regel kann durch Anklicken des Buttons „Neu“ erfasst werden. In einem Pull-Down-Menu können der Kanal und die Applikation ausgewählt werden. Weiter muss mittels der zur Verfügung stehenden Check-Boxes der gewünschte LogLevel definiert werden.

Bereits erfasste Regeln können mit dem Bedienelement „Editieren“ in der Detailansicht editiert werden. Wie bei der Neuerfassung einer Regel kann der Kanal, die Applikation und der LogLevel ausgewählt resp. geändert werden.

Weiter kann eine bestehende Regel mit dem Bedienelement „Löschen“ aus der Liste und damit aus dem System gelöscht werden.



Abbildung 7-9 : Regeln verwalten

7.3.3 Dokumentation Im Menupunkt „Dokumentation“ stehen weitere Informationen zur Verfügung:

Abbildung 7-10 : Dokumentation



8 Besprechung

8.1 Zielerreichung Die Zielerreichung in Bezug auf die im Pflichtenheft spezifizierten und mit dem Experten vereinbarten Muss-, Kann- und Soll-Zielen ist in der nachfolgenden Tabelle im Überblick dargestellt: Nr. Beschreibung Muss Soll Kann Zielerreichung1 Komponenten 1.1 RemoteTraceAppender X ☺ 1.2 RemoteTraceServer X ☺ 1.3 Simulator X ☺ 2 Technische Anforderungen 1 Skalierbarkeit X ☺ 2.2 JMX-Schnittstelle X ☺ 2.3 Plugin-Prinzip für Verteilkanäle X ☺ 3 Verteilkanäle 3.1 Topics X ☺ 3.2 Datenbank X ☺ 3.3 SMS X 3.4 E-Mail X ☺ 4 Funktionale Anforderungen 4.1 UC_1.0: Log-Event abfangen X ☺ 4.2 UC_1.1: JMX Remote

Management X ☺

4.3 UC_2.0: Dispatching konfigurieren X ☺ 4.4 UC_2.1: Applikationen verwalten X ☺ 4.5 UC_2.2: Kanäle verwalten X ☺ 4.6 UC_2.3: Statistiken erstellen X 4.7 UC_2.4: Kanäle anzeigen

(statisch) X ☺

4.8 UC_2.4 Variante: Kanäle anzeigen (dynamisch)

X ☺

4.9 UC_2.5: JMX Remote Management

X

4.10 UC_2.6: Login X 5 Nichtfunktionale Anforderungen 5.1 Unterstüzung von

Mehrsprachigkeit X ☺

5.3 Einfache Installation X ☺ 5.4 Onlinehilfe X ☺ 5.5 Downloadbare Dokumentation X ☺



Legende:

☺ Anforderung wurde realisiert.

Anforderung wurde nicht oder nur teilweise realisiert; es handelt sich jedoch um ein Soll- oder ein Kann-Ziel.

Anforderung im Sinne eines Muss-Zieles, die nicht realisiert wurde.

Die Muss-Ziele wurden alle erreicht.

Weiter wurden neun Soll-Ziele definiert, wobei hier drei Soll-Ziele nicht erreicht wurden:

• Statistiken erstellen: Die Funktion zur Erstellung von Statistiken wurde aus Zeitgründen nicht implementiert.

• JMX Remote Management: Auf die Realisierung des JMX Remote Managements des Servers wurde aus Zeitgründen verzichtet.

• Login: Wenn das RAT in einer Firma eingesetzt wird, werden die bestehenden Login Mechanismen verwendet. Aus diesem Grund wurde auf die Implementierung verzichtet.

Von den vier definierten Kann-Zielen wurden deren drei realisiert. Einzig auf die Realisierung des Verteilkanals SMS wurde verzichtet.

Weiter gilt es festzuhalten, dass neben den oben aufgeführten Komponenten und Anforderungen keine weiteren zusätzlichen Funktionen implementiert wurden oder werden mussten. Dies unterstreicht, dass in der Analysephase die Anforderungen in einem detaillierten Umfang definiert wurden. Dies stellte ein zielgerichtetes Arbeiten in der Design- und Implementierungsphase sicher.

8.2 Lessons Learned

8.2.1 Vorgehensmodell RUP Als Vorgehensmodell wurde das RUP gewählt. Es hat sich gezeigt, dass sich dieses Vorgehensmodell für ein Projekt in diesem Rahmen bestens bewährt. Das Vorgehensmodell stellte insbesondere sicher, dass die wichtigsten Meilensteine frühzeitig gesetzt wurden. Dies gewährleistete ein zielorientiertes Voranschreiten der Arbeiten. Gleichzeitig erlaubt das Vorgehensmodell aber auch ein iteratives Vorgehen, so dass wo notwendig mit verschiedenen Varianten gearbeitet werden konnte.



8.2.2 Beurteilung der einzelnen Phasen Analyse: Im Rahmen der Studie führten wir eine Analyse der Ist-Situation und der Bedürfnisse durch. Weiter definierten wir die Anforderungen an das System.

Als Schwierigkeit zeigte sich hier, dass das zu entwickelnde System von keinem konkreten Auftraggeber gefordert wurde. Entsprechend war es schwierig, die Bedürfnisse und die Anforderungen zu definieren. In dieser Phase musste das vorgängig festgelegte Zeitbudget um rund 20 Prozent überschritten werden.

Konzept / Design: Im Rahmen dieser Phase erfolgten die Architekturbeschreibung sowie das Design der einzelnen System-Komponenten. Weiter erstellten wir die Klassendiagramme und das Benutzer-Frontend.

Positiv hervorgehoben werden kann in dieser Phase, dass die Anforderungen im Rahmen der Studien-Phase detailliert beschrieben wurden. Dies stellte ein zielgerichtetes Design der einzelnen System-Komponenten sicher.

Weiter sind wir davon überzeugt, dass die Verifizierung der eingesetzten Technologien mittels Prototypen sich bewährt hat. Dies bedeutete zwar einen relativ hohen Aufwand, reduzierte das Technologie-Risiko jedoch wesentlich.

Realisierung: Im Rahmen der Realisierung wurde die Software entwickelt und getestet.

Bei der Realisierung tauchten kaum unerwartete Schwierigkeiten auf. Hier zeigte sich nun, dass sich der Aufwand in Bezug auf die detaillierte Definition der Anforderungen und insbesondere auch die Verifizierung der eingesetzten Technologien auszahlte.

Dadurch, dass wir in keinem Auftragsverhältnis standen, entfiel der zusätzliche Aufwand, der sich aus wechselnden Anforderungen der Kunden ergeben kann.

Einführung: Die Einführung beinhaltete in erster Linie die Abnahmetests des Systems sowie die Fertigstellung der Systemdokumentation und die Abgabe und Präsentation der Diplomarbeit.

Die Abnahmetests wurden mit einer gewissen Spannung erwartet. Hier zeigte sich nun, ob das System gemäss den definierten Anforderungen funktioniert. Erfreulicherweise brachten die Tests keine gravierenden Mängel zum Vorschein.

8.2.3 Projektmanagement und Organisation Die Erstellung einer Diplomarbeit zu zweit stellte eine gewisse Herausforderung dar. Um die Arbeiten aufeinander abzustimmen, den Projektfortschritt zu überwachen und Doppelspurigkeiten zu vermeiden, führten wir wöchentlich eine Teamsitzung durch.

Die Erstellung einer Diplomarbeit zu zweit wurde als positiv empfunden. Erstens gewährte dies einen interessanten Know-How-Austausch und ermöglichte einen



hohen Lerneffekt. Zweitens wurde es auch als motivierend empfunden, zu zweit ein System zu entwickeln. Drittens wurden alle Arbeitsergebnisse von beiden Projektmitarbeitern geprüft. Dies stellte sowohl einen hohen Lerneffekt als auch eine hohe Qualität des Systems sicher.

Eher schwierig gestaltete sich insbesondere in der Design-Phase das Finden eines gemeinsamen Vorgehens. Pragmatisch ausgedrückt kann Roland Jost als „Planer und Konzeptler“ und Remo Ledermann als „Hacker“ charakterisiert werden. Entsprechend unterschiedlich traten wir jeweils an die einzelnen Aufgaben heran. Es wurde aber darauf geachtet, dass beide an allen Bereichen des Systems gearbeitet haben. Obschon es einen gewissen Mehraufwand bedeutet, sich jeweils „gegenseitig zu finden“, wird gerade dies auch als wertvolle Erfahrung beurteilt, die im Berufsleben eine wichtige Rolle spielt.

8.2.4 Datensicherung Wie wichtig eine konsequente Datensicherung ist, zeigte sich im Rahmen des Projektes, als eine Harddisk einen Crash hatte. Die Daten waren unwiderrufbar verloren. Da die Daten aber auf mehreren PCs gehalten und zudem auf einem externen Datenträger gesichert wurden, musste kein gravierender Datenverlust verzeichnet werden.

8.2.5 Terminplan Der Terminplan konnte grösstenteils eingehalten werden. Während der Design-Phase kamen wir etwas in Verzug. Das ist aber grösstenteils auf die Sommerferien zurückzuführen, die wir uns gönnten.

Die Feinplanung wurde rollend gemacht: Es wurde wöchentlich und situativ entschieden, welche Aufgaben in welcher Tiefe bis wann gemacht werden mussten.

Der detaillierte und nachgeführte Terminplan ist im Anhang abgebildet.

8.2.6 Aufwandschätzung Leider haben wir es versäumt, die investierte Zeit aufzuschreiben. Somit ist eine genaue Nachkalkulation nicht möglich. Wir schätzen, dass wir das Zeitbudget von 730 Stunden um rund 10 Prozent überschritten haben.

8.3 Ausblick Das RAT wurde ohne tatsächlichen Auftraggeber aus der Wirtschaft entwickelt. Wir sind aber davon überzeugt, dass ein Bedürfnis nach einem solchen System besteht. Softwarebetreiber kämpfen immer wieder mit dem Problem, die notwendigen Log-Meldungen zum Lösen von aufgetretenen Problemen aufzufinden.

Das RAT wurde im Rahmen der Diplomarbeit als lauffähiges System entwickelt, das mit den notwendigen Erweiterungen in Bezug auf die Sicherheitsaspekte in einem Betrieb eingesetzt werden könnte. Wir hoffen, dass wir mit dem entwickelten System eine Art Initialzündung setzen können. Potenziellen Interessenten kann mit dem Prototyp aufgezeigt werden, wie mit diesem zentralen Messaging-System Log-Meldungen übermittelt, gespeichert und weitergeleitet werden können.



Nach der Präsentation der Arbeit in der Bedag wurde ein Interesse signalisiert, dass das Produkt in einem zurzeit in der Entwicklung befindlichen Projekt eingesetzt werden könnte. Es wurde die Absicht geäussert, das System verbreitet zum Einsatz zu bringen, falls es sich bewährt.



Anhang



Quellenverzeichnis [1] Othmar Bürgi, Skript Projekt-Management von SW-Entwicklungsprojekten,

2005

[2] Urs Küenzler, Skript Objektorientiertes Software Engineering

[3] Bernd Oestereich, Obektorientierte Softwareentwicklung, 6. Auflage 2004

[4] Christoph Kecher, UML 2.0 das umfassende Handbuch, 2005

[5] Ian Sommerville, Software Engineering, 6. Auflage 2001

[6] Bruno Jenny, Projektmanagement in der Wirtschaftsinformatik, 5. Auflage

2001

[7] Beispiele guter Diplomarbeiten

http://www.sws.bfh.ch/studienbetrieb/dip/index.xhtml

[8] Diverse Informationen

http://de.wikipedia.org

[9] Weiss leider nicht alles

http://www.google.ch

[10] Online-Artikel von Madhusudhan Konda

http://www.javaworld.com/javaworld/jw-05-2004/jw-0510-logging.html



Projektplan



Die erledigten Arbeiten (aus den Statusberichten) • Das Kick Off wurde durchgeführt • Die grobe Projektplanung wurde erstellt • Mögliche Architekturen des Systems wurden aufgezeichnet • Die Risikoanalyse wurde mit einem Prototypen abgeklärt • Erste Bedürfnisabklärungen wurden durchgeführt • Sitzung mit dem Experten wurde durchgeführt • Die Nachbesprechung der Sitzung wurde abgehalten • Der erste Prototyp mit JMS und Log4j läuft • Die Architektur des Systems konnte offener gestaltet werden • Die Grafik der Systemübersicht wurde angepasst • Erster Entwurf für das Server Frontend liegt vor • Das Grundgerüst für das Pflichtenheft wurde erstellt • Das Pflichtenheft füllt sich langsam mit Inhalt • Die Systemgrenzen wurden definiert • Der Prototyp läuft auch verteilt (auf 3 Rechnern) • Bis jetzt wurden 15 Use Cases identifiziert und grob beschrieben • Erstes Review beim Pflichtenheft wurde durchgeführt • Der Prototyp mit Datenbank und Toplink liegt vor • Die System-Architektur wurde im Pflichtenheft beschrieben • Die Sitzung mit dem Betreuer konnte abgehalten werden • Der Prototyp mit den gewählten Technologien ist lauffähig • Zweites Review vom Pflichtenheft wurde durchgeführt • Das Pflichtenheft wurde ergänzt (nicht funktionale Anforderungen) • Die Anwendungsfälle wurden verfeinert • Der Terminplan wurde erstellt (MSProject) • Die Umgebung wurde bereit gestellt • Die Aufwandschätzung wurde verfeinert • Das Review des Pflichtenhefts mit den Betreuern / Experten wurde durchgeführt • Die Endfassung des Pflichtenheftes wurde erstellt • Das Pflichtenheft wurde abgegeben • Das Design des Gesamtsystems liegt vor • Das Design der Datenbank liegt vor • Die Schnittstellen wurden genauer beschrieben (XML Schema) • Der Bildschirmablauf wurde bestimmt • Der Inhalt für den Diplombericht wurde definiert • Das Design der Screens wurde erstellt • Das Design des Appenders wurde erarbeitet • Das Design des Simulators wurde erarbeitet • Das Design des Servers liegt vor • Die Dokumentation der Designphase wurde erarbeitet • Die Klassendiagramme wurden erstellt • Die CVS Anbindung und der Abgleich wurden vorgenommen • Die SQL Skripte wurden durch Hibernate und JUnit abgelöst • Das Design des Appenders und des Simulators wurden erstellt • Der Appender und Simulator wurden in einer Vorabversion realisiert • Der Webfrontend-Framework wurde aufgebaut • Die Design Serverkomponenten wurden erarbeitet • Die Dokumentation der Designphase liegt vor • Die Testfälle wurden definiert • Die Kommunikation unter den Komponenten wurde aufgebaut • Die Domains wurden implementiert • Die Webfrontend Tasks wurden implementiert



• Die Webfrontend Applikationen wurden implementiert • Die Webfrontend Kanäle wurden implementiert • Der Webfrontend Kanal Browser wurde implementiert (statisch) • Webfrontend Kanal Browser (Ajax Prototyping) wurden implementiert • Das Redesign der Datenzugriffe wurde vorgenommen • Die Hibernate-Anbindung wurde komplett überarbeitet • Das Dispatching wurde implementiert • Die Verwaltung der Webfrontend Regeln wurde implementiert • Einzeltests wurden durchgeführt • Die Besprechung mit dem Experten wurde durchgeführt (Design) • Mail Task wurde implementiert • Topic Task wurde implementiert • Das Live-Monitoring der Kanäle und Queue wurde implementiert • Präsentation der Applikation für die Betreuer wurde erstellt • DB Task wurde implementiert • Das Code-Review durch Betreuer wurde durchgeführt • Das Testen und die Fehlerbehebung im Gesamtsystem wurden durchgeführt • Die Vorstellung beim Experten wurde vorbereitet • Die Dokumentation wurde überarbeitet und als PDF erstellt • Der Vortrag wurde erstellt und vorbereitet • Die Dokumentation wurde gedruckt • Der Inhalt der CD wurde zusammengestellt

Pflichtenheft Diplomarbeit

Nr. B36.08

Remote Application Tracing

(Asynchrones Logging und Monitoring System)

Abstract: Remote Application Tracing (RAT) ist ein zentrales Messaging-System für die Übermittlung, Speicherung und Weiterverteilung von Log-Meldungen aus angeschlossenen Applikationen. Das System verteilt eingehende Log-Meldungen aufgrund freikonfigurierbarer Regeln auf beliebige Kanäle (DB, Topics), um sie externen Auswertungs- und Analysetools zugänglich zu machen. Die Architektur des Gesamtsystems ist so konzipiert, dass jede Art von Applikationen, die die Schnittstellen nutzen können, als Log-Produzenten, beziehungsweise Konsumenten (Analysetool) auftreten können. Autoren: Remo Ledermann

St.Urbanstrasse 39 4900 Langenthal Tel: 062 922 32 07

Roland Jost Haldenstrasse 60 4900 Langenthal Tel: 079 208 48 45

Betreuer: Erich Lambelet Bedag Informatik AG 3000 Bern

Stefan Thörner Bedag Informatik AG 3000 Bern

Experte: Stephan Fischli Software-Schule Schweiz Wankdorffeldstrasse 102 3000 Bern 22 Tel: 031 33 55 274

Datum: 07.08.2006

Diplomarbeit B36.08 Pflichtenheft

Pflichtenheft.doc Seite 2

Inhaltsverzeichnis 1. Vorbemerkungen.............................................................................4

1.1. Ausgangslage .............................................................................................. 4 1.2. Leserkreis..................................................................................................... 4 1.3. Zweck des Dokuments ................................................................................. 4 1.4. Definitionen und Abkürzungen ..................................................................... 4 1.5. Referenzen................................................................................................... 4

2. Allgemeine Beschreibung ...............................................................5 2.1. IST-Situation ................................................................................................ 5 2.2. SOLL-Zustand.............................................................................................. 5 2.3. Projektziele................................................................................................... 6 2.4. Projektrisiken................................................................................................ 6 2.5. Wirtschaftlichkeit .......................................................................................... 7 2.6. Umfeld / Rahmenbedingungen..................................................................... 7 2.7. Abgrenzungen.............................................................................................. 7 2.8. Mögliche Erweiterungen............................................................................... 7

3. Systemarchitektur ...........................................................................9 3.1. Skalierbarkeit................................................................................................ 9 3.2. Systemstruktur ........................................................................................... 10 3.3. Kommunikations-Ablauf ............................................................................. 12

4. Funktionale Anforderungen...........................................................13 4.1. Benutzerkreise (Actors).............................................................................. 13 4.2. RemoteTraceAppender .............................................................................. 13

4.2.1. UC_1.0: Log Event abfangen .........................................................................13 4.2.2. UC_1.1: JMX Remote Management ...............................................................14

4.3. RemoteTraceServer ................................................................................... 15 4.3.1. UC_2.0: Dispatching konfigurieren .................................................................15 4.3.2. UC_2.1: Applikationen verwalten....................................................................16 4.3.3. UC_2.2: Kanäle verwalten ..............................................................................16 4.3.4. UC_2.3: Statistiken erstellen ..........................................................................17 4.3.5. UC_2.4: Kanäle anzeigen...............................................................................17 4.3.6. UC_2.5: JMX Remote Management ...............................................................18 4.3.7. UC_2.6: Login.................................................................................................18

5. Technische Anforderungen ...........................................................20 5.1. RemoteTraceAppender .............................................................................. 20

5.1.1. Log4J-Appender .............................................................................................20 5.1.2. JMX-Schnittstelle ............................................................................................20

5.2. RemoteTraceServer ................................................................................... 20 5.2.1. Dispatcher.......................................................................................................21 5.2.2. Verteilkanäle ...................................................................................................21 5.2.3. Dispatching-Regeln ........................................................................................21 5.2.4. Webfrontend ...................................................................................................21 5.2.5. JMX-Schnittstelle ............................................................................................22

5.3. Allgemeine Systemkomponenten ............................................................... 22 5.3.1. Log-Events......................................................................................................22 5.3.2. Externe Produzenten/Konsumenten...............................................................23 5.3.3. Simulator.........................................................................................................23

5.4. Technologien.............................................................................................. 23 5.5. Schnittstellen.............................................................................................. 23



6. Nichtfunktionale Anforderungen....................................................25 6.1. Mehrsprachigkeit ........................................................................................ 25 6.2. Installation und Softwareverteilung............................................................. 25 6.3. Onlinehilfe .................................................................................................. 25 6.4. Dokumentation ........................................................................................... 25 6.5. Sicherheitsanforderungen .......................................................................... 25 6.6. Performance............................................................................................... 25 6.7. Mengengerüst ............................................................................................ 26 6.8. Verfügbarkeit .............................................................................................. 26

7. Zielklassifizierung..........................................................................27 8. Projektmanagement ......................................................................28

8.1. Vorgehen.................................................................................................... 28 8.2. Organisation............................................................................................... 28 8.3. Datensicherung .......................................................................................... 29 8.4. Change Management................................................................................. 29 8.5. Qualitätssicherung...................................................................................... 29 8.6. Terminplan ................................................................................................. 30 8.7. Aufwandschätzung ..................................................................................... 31

9. Anhang..........................................................................................32 9.1. Projektplan ................................................................................................. 32 9.2. Glossar....................................................................................................... 33 9.3. Quellenverzeichnis ..................................................................................... 34 9.4. Versionskontrolle........................................................................................ 34



1. Vorbemerkungen

1.1. Ausgangslage Das in diesem Dokument beschriebene System wird im Rahmen einer Diplomarbeit für das Nachdiplomstudium „NDS Software Engineering“ an der Software Schule Schweiz realisiert.

1.2. Leserkreis Dieses Dokument richtet sich an den Experten, die Betreuer sowie an alle interessierten Personen, die sich mit diesem Thema auseinandersetzen wollen.

1.3. Zweck des Dokuments Das Dokument beschreibt die Anforderungen in fachlicher und technischer Hinsicht für das zukünftige System aus Sicht des Kunden beziehungsweise des Benutzers. Es definiert die Rahmenbedingungen, Systemgrenzen und Ziele des Systems.

Das Pflichtenheft dient als Ausgangslage für die Realisierung und als Grundlage für die spätere Beurteilung der Arbeit.

1.4. Definitionen und Abkürzungen Sämtliche technische und fachliche Abkürzungen und Definitionen können dem Glossar im Anhang dieses Dokuments entnommen werden.

1.5. Referenzen Referenzierte Dokumente:

• [1] Beschreibung des Diplomthemas


2. Allgemeine Beschreibung

2.1. IST-Situation In jedem Software-System besteht das Bedürfnis, Log-Meldungen zur Laufzeit zu protokollieren, um später Auswertungen oder Fehleranalysen durchzuführen. Beim Einsatz von verteilten Systemen und den gängigen Logging-Mechanismen werden in der Regel die Log-Meldungen in Dateien geschrieben, die sich lokal auf der entsprechenden Systemumgebung befinden. In einem komplexen Umfeld ist es für Entwickler oder Systembetreuer oft schwierig, die Dateien für die Analyse zu finden. Oft müssen Administratoren oder Benutzer kontaktiert werden, um an die Dateien zu gelangen. Ausserdem ist die Analyse von File basierten Log-Meldungen aufgrund der Unübersichtlichkeit und fehlenden Suchfunktionen aufwendig und mühsam.

Entw ickler

B usiness M odell IST

Applikation B

Applikation A

Applikation C

Applikation F

Applikation D

Applikation E

System betreuer

Entw ickler

2.2. SOLL-Zustand Um der in der IST-Situation beschriebenen Problematik entgegen zu wirken, soll ein Messaging-System entwickelt werden, das an einem zentralen Ort Log-Meldungen verschiedener Applikationen entgegen nimmt und die Analyse und Auswertung vereinfacht. Das System soll eine offene Architektur aufweisen, die es jeder Applikation (Produzent) ermöglicht, Log-Meldungen zu senden und durch ein beliebiges Analysetool (Konsument) auswerten zu lassen.

Dadurch soll ein Gesamtsystem entstehen, das den Entwicklern und Systembetreuern die Überwachung und Auswertung von Log-Meldungen erheblich erleichtert.



Server

Entw ickler

B usiness M odell SO LL

Applika tion B

Applika tion A

A pplikation C

C lient

C lient

C lient

Applika tion F

Applika tion D

Applika tion E

System betreuer

Entw ickler

2.3. Projektziele Das zentrale Ziel des Projektes ist es, den Aufwand zum Auffinden, Analysieren und Überwachen von Log-Meldungen zu verringern.

Weitere Projektziele:

• Zentrale Verwaltung von Log-Meldungen

• Geringe Eingriffe in die angeschlossenen Applikationen

• Kein Einfluss auf bestehende Logging-Mechanismen

• Offene Architektur

• Einfach erweiterbar

• Bedürfnisgerecht konfigurierbar

Wie gut die Projektziele erreicht werden können, hängt nicht zuletzt vom Inhalt der gelieferten Log-Meldungen ab, auf die das System aber keinen Einfluss hat. Nur gezielte und aussagekräftige Meldungen erleichtern die Fehlersuche in einer Applikation.

2.4. Projektrisiken Die Neuentwicklung eines Systems beinhaltet immer gewisse technologische und quantitative Risiken. Im Rahmen einer Analyse wurde versucht, die Risiken zu identifizieren und diese mit geeigneten Massnahmen zu reduzieren.

Identifizierte Risiken: • Der Umfang der zu realisierenden Komponenten wird zu gross. • Es existiert kein eigentlicher Auftraggeber, der seine Anforderungen an das

System definiert. Ein zielgerichtetes Arbeiten gestaltet sich dadurch schwierig. Dadurch besteht das Risiko einer Verzettelung.

• Es werden Technologien eingesetzt, über die noch keine Erfahrung vorhanden ist.

Getroffene Massnahmen:




• Der Umfang der Arbeit wurde genau definiert. Die detaillierte Projektplanung ermöglicht zudem ein Controlling.

• Es wurde ein Katalog mit den klassifizierten Anforderungen erstellt. • Die Arbeitsweise und das Vorgehen richten sich nach der Projektplanung. • Das technologische Risiko wurde mit Prototypen minimiert. • Es bestehen wenig externe Abhängigkeiten.

Es ist damit zu rechnen, dass während der Arbeit weitere Probleme auftauchen, die dann spezifisch analysiert und mit entsprechenden Massnahmen behoben werden müssen.

Die wirtschaftlichen Risiken müssen im Rahmen der Diplomarbeit nicht berücksichtigt werden.

2.5. Wirtschaftlichkeit Die Wirtschaftlichkeit steht nicht im Zentrum der Betrachtung. Dennoch sei hier auf die schnelle Amortisation eines solchen Systems hinzuweisen.

Der Aufwand für das System zu installieren und zu unterhalten ist nicht sehr gross. Der Nutzen wird durch den verringerten Suchaufwand als hoch bewertet. So kann das System auch für kleine Systemlandschaften schnell zu einem häufig eingesetzten Werkzeug werden.

2.6. Umfeld / Rahmenbedingungen Da kein direkter Auftrag für die Realisierung dieses Projektes vorliegt, sind die Rahmenbedingungen und das Umfeld nicht definiert. Das System soll aber bei Bedarf in ein produktives J2EE-Umfeld integriert werden können.

2.7. Abgrenzungen Das System soll sich bewusst auf Log-Meldungen aus Applikationen beschränken. Grundsätzlich wäre es denkbar, auch andere Log-Produzenten wie Router, Firewalls, Server etc. zu integrieren.

Das Monitoring (Überwachen) von Applikationen, wie es im Dokument „Beschreibung des Diplomthemas“ [1] erwähnt wird, wird nach Absprache mit dem Experten nicht realisiert, sondern als mögliche Erweiterung beschrieben.

Den Sicherheitsaspekten wird im Rahmen der Diplomarbeit bewusst keine grosse Beachtung geschenkt. Die Arbeit soll sich auf die technologische Umsetzung der Projektziele konzentrieren und nicht auf das Konzipieren und Realisieren von gesicherten Systemen, da diese Anforderungen durch das Umfeld gestellt werden und dies durch den fehlenden Auftraggeber nicht definiert ist.

2.8. Mögliche Erweiterungen Sämtliche unter dem Titel „Abgrenzungen“ aufgeführten Punkte könnten Teil einer Erweiterung werden.

Erweiterungsmöglichkeiten:

• Applikations-Monitoring

• Anbindung weiterer Log-Produzenten (Netzwerkkomponenten, Server und Programme in anderen Programmiersprachen)



• Implementierung weiterer Verteilkanäle (E-Mail, SMS)

• Erweiterte Zugriffsberechtigungen (Datenschutz)

• Ausfall- und Backupkonzept (Datensicherheit)

• Druckfunktionalitäten

• Erweiterte grafische Auswertungen und Statistiken

• Eigenes Analysetool


3. Systemarchitektur

3.1. Skalierbarkeit Die offene Architektur des Systems erlaubt die Anbindung beliebiger Applikationen, die als Log-Produzenten die Log-Meldungen an den Server senden. Der Server verteilt die Meldungen über verschiedene Kanäle an die Endkonsumenten. Dies sind einerseits externe Analysetools, die die Log-Meldungen auswerten und analysieren. Andererseits kann auch eine andere RAT-Instanz als Konsument auftreten und dadurch ein skalierbares System bilden.

Ein RAT-Server kann Log-Meldungen von einer beschränkten Anzahl angeschlossener Applikationen verarbeiten. Damit eine grössere Anzahl Applikationen angeschlossen werden kann, besteht die Möglichkeit, mehrere RAT-Server parallel zu betreiben. Die gefilterten Log-Meldungen dieser vorgeschalteten RAT-Server werden an einen zentralen RAT-Server gesendet, so dass eine zentrale Überwachung über alle Applikationen sichergestellt ist.

id RAT Gesamtstruktur

Systemumgebung

Systemumgebung Systemumgebung

Applikation A Applikation B

RAT-Serv erRAT-Serv er

Analysetool

Applikation CApplikation D Applikation E

Analysetool

Applikation F

RAT-Serv er

Analysetool




3.2. Systemstruktur Remote Application Tracing (RAT) ist ein zentrales Messaging-System für die Übermittlung, Speicherung und Weiterverteilung von Log-Meldungen aus angeschlossenen Applikationen. Das System verteilt eingehende Log-Meldungen aufgrund freikonfigurierbarer Regeln auf beliebige Kanäle (DB, Topics), um sie externen Auswertungs- und Analysetools zugänglich zu machen. Die Architektur des Gesamtsystems ist so konzipiert, dass jede Art von Applikationen, die die Schnittstellen nutzen können, als Log-Produzenten, beziehungsweise Konsumenten (Analysetool) auftreten können.

Zum Realiserungsumfang des Projektes gehört auch eine JAR-Library (RemoteTraceAppender), die in eine Applikation eingebunden werden kann. Der Appender übernimmt die Kommunikation mit dem Server. Die programmatischen Eingriffe in der Fremdapplikation können so auf ein Minimum beschränkt werden.

Über das im Server integrierte Webfrontend können sämtliche Konfigurationen für das Verteilen von Log-Events auf die verschiedenen Kanäle vorgenommen werden. Ausserdem können über das Webfrontend die Kanäle und deren Inhalte angezeigt werden.

Die Kommunikation unter den einzelnen Subsystemen erfolgt über den JMS-Provider und dessen Destinations (Queues und Topics) und über die Datenbanken. Das Gesamtsystem bildet dabei die bekannten Komponenten eines Messaging-System folgendermassen ab:

Meldungen: Sind die Log-Events.

Produzenten: Sind die angeschlossenen Applikationen, die Log-Meldungen produzieren und an den Server übermitteln. Der Server selber tritt ebenfalls als Produzent auf, in dem er Log-Meldungen auf verschiedenen Verteilkanälen veröffentlicht.

Konsumenten: Der Server ist der Konsument aller eingehenden Log-Events. Die Analysetools und der integrierte Channel-Browser sind die Konsumenten der Log-Events, die vom Server auf den Verteilkanälen veröffentlicht wurden.


cd Remote-Application-Tracing

RemoteTraceServ er (RTS)

JMX-Interface

Applikation

RemoteTraceAppender (RTA)

Log4JAppender

JMX-Interface

LogEv ents

«JMS»LogQueue

LogEv entDispatcher

«DB»LogDB

«JMS»Topic

External Producers

External Consumers

Fremdapplikation die direkt (ohne Appender) LogEvents sendet. (Bsp. Cobol , C++...)

Fremdapplikation (Analysetool) die sich auf einen Kanal verbindet und als Konsument die Log-Events zur Auswertung entgegenimmt. (Bsp. Cobol, C++...)

Der RemoteTraceAppender ist eine eigenständige Library die die Appl ikation von der Kommunikation und dem Versenden der LogEvents entlastet

Webfrontend

Log4Appender der die Log-Events aus der Appl ikation abfängt

Über die LogQueue werden al le LogEvents an den Server übermittel t. Sie sorgt für eine sichere asynchrone ausl ieferung der Events.

ChannelTask

DB-Channel JMS-Channel

Configuration

Channel-Brow serother

Statistics

«other»Destination

«datastore»ConfigDB

«datastore»ProtokollDB

JMX-Schnittstel le über die Konfigurationseinstel lungen im Appender verändert oder abgefragt werden können (z.Bsp. onl ine/offl ine, URL der LogQueue etc.)

JMX-Schnittstel le über die Verarbei tungsinformationen (Mengenangaben) und Konfigurationen abgefragt werden können.

Der Dispatcher vertei l t die eingehenden LogEvents auf verschiedene Ausgabekanäle

Vertei lkanäle können nach dem Plugin-Prinzip implementiert werden, sie können die LogEvents publ izieren und anzeigen

«receive»

«send»«send»

«read»

«receive»

«publ ish»

«publ ish»

«publ ish»



3.3. Kommunikations-Ablauf Im folgenden Diagramm ist der Gesamtablauf des Systems aufgezeigt.

ad Messaging-Ablauf

RemoteTraceServ er

w hile true

for all channels

Applikation

RemoteTraceAppender

Activi tyIni tial

«log4j»LogEvent

«log4j»LogEvent

FlowFinal

Transform to XML

Send LogEv ent

«XML»LogEvent

«XML»LogEvent

Receiv e LogEv ent

FlowFinal

Load Channel

Publish LogEv ent

«XML»LogEvent

FlowFinal FlowFinal

Subscribe

«XML»LogEvent

Receiv e LogEv ent

Show LogEv ent

Activi tyFinal

Externes Analysetool

[val id]

[mode=offl ine]

[mode=onl ine]

[not val id]

1)

5)

3)

2) 4)

1) Ein Log-Event wird in der Applikation ausgelöst.

2) Der Appender fängt das Log-Event ab und transformiert es in XML-Format, um es auf die Log-Queue zu publizieren.

3) Der Server empfängt von der Log-Queue das Log-Event und prüft es auf seine Gültigkeit. Log-Events in ungültigem Format oder mit einem unbekannten Absender werden vom Server ignoriert.

4) Das Log-Event wird auf alle Kanäle, die gemäss den Dispatching-Regeln zutreffen, weiterverteilt.

5) Ein externes Analysetool registriert sich auf einen Kanal und erhält alle Log-Events über diesen Kanal zur individuellen Weiterverarbeitung.

Anstelle des externen Analysetools könnte auch der interne Channel-Browser stehen, der die Log-Events im Kanal sichtbar macht.



4. Funktionale Anforderungen Die funktionalen Anforderungen werden als Anwendungsfälle (Use-Cases) definiert. Sie beschreiben, was das System aus Benutzersicht macht. Folglich werden die Interaktionen mit dem System beschrieben.

4.1. Benutzerkreise (Actors) Für die verschiedenen Subsysteme existieren aus Benutzersicht verschiedene Benutzerrollen. In den nachfolgend aufgeführten Use-Cases wird auf diese Rollen Bezug genommen.

Actor Beschreibung Administrator Der Administrator sorgt für die korrekte Konfiguration des

Gesamtsystems. Er definiert welche Log-Meldungen auf welchen Kanal verteilt werden sollen.

SW-Betreuer Der Softwarebetreuer analysiert im Fehlerfall oder zur Überwachung die Log-Events.

Applikation Die angebundene Applikation stellt als Systemactor den Auslöser von Log-Events dar.

4.2. RemoteTraceAppender

ApplikationA ppender

R em oteTraceAppender

LogE ventabfangen

<<actor>>


Adm in istra tor

4.2.1. UC_1.0: Log Event abfangen Der Appender fängt die von der Applikation generierten Log-Events ab und sendet sie über die Log-Queue an den Server.

Name Log-Event abfangen

Nummer 1.0

Beteiligte Akteure Applikation

Vorbedingungen Log4J muss richtig konfiguriert sein

Eingehende Daten Log-Event von Log4J

Ergebnis Log-Event wird auf Queue gestellt

Ausgehende Daten Log-Event als XML-String

Nr. Akteur Was Ablauf: 1 Applikation Loggt einen Systemzustand




2 Appender Fängt Log-Event ab

3 Appender Konvertiert Log-Event in einen XML-String

4 Appender Sendet XML auf Log-Queue

Nr. Akteur Was Varianten: 3.1 Appender Der Appender ist im „offline“-Modus, das Log-Event wird nicht

gesendet

4.2.2. UC_1.1: JMX Remote Management Der Administrator kann über die JMX-Schnittstelle Konfigurationseinstellungen des Appenders einsehen und zur Laufzeit verändern.

Einsehbare Einstellungen:

• Modus (online/offline)

• Applikations-ID

• Log-Level aus log4j-Konfiguration

• URL der Log-Queue

Name JMX Remote Management

Nummer 1.1

Beteiligte Akteure Administrator

Vorbedingungen Die JMX-Schnittstelle des Appenders muss erreichbar sein

Eingehende Daten Benutzereingaben

Ergebnis Konfiguration ist geändert

Ausgehende Daten -

Nr. Akteur Was 1 Administrator Der Administrator gibt die URL der JMX-Schnittstelle im Browser

ein

2 Appender Der Appender zeigt über einen HTTP-Adaptor die zur Verfügung stehenden JMX-Operationen und Attribute an

3 Administrator Der Administrator ändert eine Konfiguration

Ablauf:

4 Appender Der Appender übernimmt die neue Konfigurationseinstellung


4.3. RemoteTraceServer

Server

Adm inistrator

R em oteTraceServer

Kanäle anzeigen

Topic

D ispatch ingkonfigurieren

Applikationenverw alten

DB

Kanal ausw ählen<< include>>

S tatistikenerste llen

Kanäle verwalten


4.3.1. UC_2.0: Dispatching konfigurieren Die Regeln für das Dispatching (welche Log-Meldung soll auf welchem Kanal publiziert werden) können vom Administrator über das Webfrontend konfiguriert werden.

Benötigte Daten sind:

• Kanal

• Applikations-ID (Kurzname)

• Log-Level

• Meldungsinhalt (Textpattern)

Name Dispatching konfigurieren

Nummer 2.0


Vorbedingungen Applikationen und Verteilkanäle sind erfasst


Ergebnis Neue Dispatching-Regeln sind erfasst und aktiv

Ausgehende Daten -

Nr. Akteur Was 1 Server Zeigt erfasste Applikationen an

Ablauf:

2 Administrator Auswählen einer Applikationen




3 Administrator Kanal auswählen

4 Administrator Kriterien erfassen (Level)

5 Administrator Einstellungen speichern

6 Server Aktiviert die Dispatching-Regel

Nr. Akteur Was 1.1 Server Zeigt erfasste Kanäle an

2.1 Administrator Auswählen eines Kanals

4.1 Administrator Kriterien erfassen (Applikation, Level)

Varianten:

4.2 Administrator Die Kriterien können den Meldungsinhalt überprüfen (kann Ziel)

4.3.2. UC_2.1: Applikationen verwalten Damit das System den Absender der eingehenden Log-Meldungen identifizieren kann, müssen die angeschlossenen Applikationen dem System bekannt sein. Dazu können die Applikationen vom Administrator verwaltet werden.


• Applikations-ID (Kurzname)

• Beschreibung

• URL der JMX-Schnittstelle

Name Applikationen Verwalten

Nummer 2.1

Beschreibung Applikationen verwalten


Vorbedingungen -

Eingehende Daten Benutzer Eingaben

Ergebnis Neue Applikation / gelöschte Applikation / geänderte Applikation

Ausgehende Daten -

Nr. Akteur Was 1 Server Zeigt erfasste Applikationen an

2 Administrator Applikation auswählen

3 Administrator Daten ändern

Ablauf:

4 Administrator Speichern

Nr. Akteur Was 2.1 Administrator Neue Applikation erfassen

Varianten:

2.2 Administrator Applikation löschen

4.3.3. UC_2.2: Kanäle verwalten Die Kanäle, auf die der Dispatcher die Log-Meldungen verteilt, können vom Administrator verwaltet werden. Topics und Tabellen werden als administrierte Objekte angesehen, das heisst diese müssen existieren. Die Applikation erstellt oder löscht selber keine Topics oder Datenbanken!


• Name der Tabelle oder des Topics

• URL der Datenbank oder des JMS-Providers

Name Kanäle Verwalten

Nummer 2.2




Vorbedingungen Topic oder Datenbank existiert


Ergebnis neuer Kanal / gelöschter Kanal / veränderter Kanal

Ausgehende Daten -

Nr. Akteur Was 1 Server Zeigt erfasste Kanäle an

2 Administrator Kanal auswählen

3 Administrator Daten ändern

Ablauf:

4 Administrator Speichern

Nr. Akteur Was 2.1 Administrator Neuen Kanal erfassen

Varianten:

2.2 Administrator Kanal löschen

4.3.4. UC_2.3: Statistiken erstellen Der Server stellt für Mengen-Auswertungen, bei denen über einen bestimmten Zeitraum die Anzahl der Log-Events beobachtet werden muss, eine grafische Übersicht bereit.

Mögliche Auswertungskriterien sind:

• Applikations-ID

• Log-Level

• Zeitraum

Name Statistiken erstellen

Nummer 2.3


Vorbedingungen Auf der Protokoll-DB sind Einträge vorhanden

Eingehende Daten Auswahlkriterien

Ergebnis Grafische Darstellung

Ausgehende Daten -

Nr. Akteur Was 1 Administrator Auswertungskriterien eingeben

2 Server Daten lesen und Statistik aufbereiten

Ablauf:

3 Server Statistik anzeigen

4.3.5. UC_2.4: Kanäle anzeigen Zur Kontrolle und Überwachung kann der Inhalt der Kanäle angezeigt und mit Auswahlkriterien gefiltert werden. Die Inhalte werden in einem ersten Schritt statisch angezeigt. Als Erweiterung ist geplant die Inhalte der Kanäle dynamisch in Echtzeit darzustellen. Dies ist abhängig vom Webfrontend, da dieses eine dynamische Anzeige unterstützen muss.


• Kanal

• Auswahlkriterien (Applikations-ID,Log-Level)

Name Kanäle anzeigen

Nummer 2.4




Vorbedingungen -

Eingehende Daten Auswahlkriterien

Ergebnis Inhalt des Kanals wird angezeigt

Ausgehende Daten Log-Events

Nr. Akteur Was 1 Server Stellt eine Liste mit den Kanälen zur Auswahl

2 Administrator Wählt einen Kanal und Kriterien aus

3 Server Ermittelt den Inhalt des Kanals

Ablauf:

4 Server Zeigt Inhalt an (statisch)

Nr. Akteur Was Varianten: 4.1 Server Zeigt Inhalt an (dynamisch)

4.3.6. UC_2.5: JMX Remote Management Der Administrator kann über die JMX-Schnittstelle Konfigurationseinstellungen des Servers einsehen und zur Laufzeit verändern. Zusätzlich können Variablen über die Auslastung des Systems abgefragt werden.

Einsehbare Einstellungen/Informationen:

• Startzeit des Servers

• Anzahl verarbeitete Log-Events

• URL der Log-Queue

Name JMX Remote Management

Nummer 2.5


Vorbedingungen Die JMX-Schnittstelle des Appenders muss erreichbar sein


Ergebnis Konfiguration ist geändert

Ausgehende Daten -

Nr. Akteur Was 1 Administrator Der Administrator gibt die URL der JMX-Schnittstelle im Browser

ein

2 Appender Der Appender zeigt über einen HTTP-Adaptor die zur Verfügung stehenden JMX-Operationen und Attribute an

3 Administrator Der Administrator ändert eine Konfiguration

Ablauf:

4 Appender Der Appender übernimmt die neue Konfigurationseinstellung

4.3.7. UC_2.6: Login Das Webfrontend des Servers kann nur über ein einfaches Login verwendet werden.


• User-ID

• Passwort

Name Login

Nummer 2.6




Vorbedingungen Administrator ist als User auf der entsprechenden DB erfasst

Eingehende Daten Username und Passwort

Ergebnis Administrator ist angemeldet

Ausgehende Daten -

Nr. Akteur Was 1 Server Dialog für Username und Passwort anzeigen

2 Administrator Username und Passwort eingeben

3 Server Die Eingaben prüfen

Ablauf:

4 Server Webfrontend zur Nutzung freigeben

Nr. Akteur Was Varianten: 3.1 Server Die Eingaben sind falsch; es wird wieder das Login angezeigt



5. Technische Anforderungen

5.1. RemoteTraceAppender Der RemoteTraceAppender (RTA) wird als eigenständige Java-Library in die Applikationen eingebunden. Er übernimmt die Kommunikation und den Versand der Log-Events an den Server.

Das bestehende Logging-Konzept einer Applikation wird durch die Integration des Appenders nicht beeinträchtigt. Es ist also nach wie vor möglich, parallel Logfiles lokal auf der Systemumgebung zu haben. Aufgrund dieser Tatsache wird bewusst auf eine Transaktionssicherheit verzichtet. Das heisst, wenn die Log-Queue für den Appender nicht erreichbar ist, wird dieser das Log-Event ignorieren, in der Annahme, dass andere Log4J-Appender das Event erfolgreich verarbeiten konnten. Tritt ein Fehler auf, so wird dieser gemäss dem Log4J Fehlerhandling behandelt.

5.1.1. Log4J-Appender Der Appender stellt gegenüber der Applikation keine direkte Schnittstelle zur Verfügung. Er implementiert dafür einen Log4J kompatiblen Appender, über den Log-Events abgefangen werden können. Dadurch sollen Eingriffe in die bestehende Applikation auf ein Minimum verringert werden. Die Eingriffe in der Applikation beschränken sich auf die Konfiguration des Log4J-Frameworks.

5.1.2. JMX-Schnittstelle Der RemoteTraceAppender stellt ausserdem eine JMX-Schnittstelle in Form eines Http-Adaptors zur Verfügung, über die Konfigurationseinstellungen eingesehen und bei Bedarf verändert werden können.

Auch der Modus des Appenders kann über die JMX-Schnittstelle geändert werden. Da die Log-Meldungen einer problemlos laufenden Applikation in der Regel nicht interessant sind, kann der Appender zwei Zustände haben:

• Online: => Alle Log-Events werden an den Server übermittelt.

• Offline: => Log-Events werden ignoriert und nicht gesendet.

Folgende Informationen und Operationen sollen über JMX zugänglich sein: Information Zugriff (read/write) Bemerkung Log-Level read/write Damit wird definiert, ab welcher Stufe

Log-Events an den Server übermittelt werden sollen.

Modus read/write Umschalten zwischen „online/offline“. Applikations-ID read Absenderadresse Version read Zeigt die installierte Version an. URL der Queue read/write Adresse der Queue, an die die Log-

Events gesendet werden.

5.2. RemoteTraceServer Der RemoteTraceServer (RTS) ist die zentrale Komponente des Gesamtsystems und stellt ein Webfrontend zur Konfiguration und Überwachung zur Verfügung. Er



übernimmt das Verteilen aller eintreffenden Log-Events aufgrund freikonfigurierbarer Regeln und Kanäle.

5.2.1. Dispatcher Der Dispatcher nimmt alle eingehenden Log-Events entgegen und verarbeitet sie. Jeder eingehende Log-Event wird vom Dispatcher auf eine Datenbank protokolliert, um statistische Auswertungen zu ermöglichen.

Aufgrund der konfigurierten Regeln entscheidet er, auf welchen Verteilkanal der Log-Event weitergeleitet werden soll. Ein Log-Event muss aber nicht zwingend weitergeleitet werden. Die meisten unkritischen Log-Events können vom Dispatcher ignoriert werden. Sie werden in ein File geschrieben, das täglich gelöscht wird.

5.2.2. Verteilkanäle Der Server kann eingehende Log-Events auf verschiedene Verteilkanäle publizieren. Ein Verteilkanal muss nicht zwingend eine Destination des Messaging-Providers sein. Auch eine Datenbank, E-Mail oder ein SMS wird als Verteilkanal angesehen. Ein Verteilkanal bildet die Schnittstelle zu einem externen Analysetool beziehungsweise Konsumenten. Im jetzigen Umfang des Projektes sind folgende Verteilkanäle vorgesehen:

• Topics

• Log-Datenbanken

Dazu kommt ein so genannter Trash-Kanal (DB oder File) auf den alle Log-Events publiziert werden, die sonst keiner Dispatching-Regel entsprechen.

Im Hinblick auf mögliche Erweiterungen soll darauf geachtet werden, dass das Implementieren weiterer Verteilkanäle ohne grosse Eingriffe möglich wird (Plugin-Prinzip). Dazu wird ein Interface vorgegeben über das die Applikation auf einen Kanal schreibend (für das Dispatching) und lesend (für den Channel-Browser) zugreifen kann und sich nicht um die technische Implementierung kümmern muss. Dies ist Sache des Verteilkanals.

5.2.3. Dispatching-Regeln Mit den Dispatching-Regeln wird individuell bestimmt, welcher Log-Event auf welchen Verteilkanal veröffentlicht werden soll. Die Regeln sollen frei definierbar sein und sich am Inhalt des Log-Events ausrichten.

Kriterien für Dispatching-Regeln sind:

• Absender (Applikations-ID)

• Log-Level

• Meldungsinhalt

5.2.4. Webfrontend Das im Server integrierte Webfrontend ermöglicht einem Administrator, die Konfiguration des Gesamtsystems vorzunehmen. Dazu gehört das Verwalten folgender Objekte:

• Applikationen

• Verteilkanäle



• Dispatching-Regeln

Über die vom Dispatcher protokollierten Informationen können Mengen-Auswertungen in Form von Statistiken über einen bestimmten Zeitraum erstellt und angezeigt werden.

Ausserdem wird im Webfrontend ein so genannter Channel-Browser integriert, mit dem Inhalte der einzelnen Verteilkanäle eingesehen werden können. Dieser nutzt dazu die vordefinierten Schnittstellen der verschiedenen Kanäle um den Inhalt auszulesen. Es ist also Sache der Verteilkanäle die Inhalte auslesen zu können, der Channel-Browser kümmert sich nur um die optische Darstellung.

In einem ersten Schritt wird der Channel-Browser die Inhalte statisch anzeigen. Später sollen die Inhalte aber dynamisch in Echtzeit angezeigt werden.

5.2.5. JMX-Schnittstelle Wie der Appender, stellt auch der Server eine JMX-Schnittstelle in Form eines Http-Adaptors zur Verfügung, über den Konfigurationseinstellungen und die Systemauslastung eingesehen werden können.

Grundsätzlich werden über die JMX-Schnittstelle alle Konfigurationseinstellungen sichtbar gemacht. Für die Anzeige der Systemauslastung werden intern dieselben Operationen ausgeführt wie beim erstellen von Statistiken (ohne grafische Darstellung).

Folgende Informationen und Operationen sollen über JMX zugänglich sein: Information Zugriff (read/write) Bemerkung Startzeit des Servers

read -

URL der Queue read/write Adresse der Queue von der die Log-Events empfangen werden.

Systemauslastung read Dito Statistiken erstellen, ohne grafische Darstellung

5.3. Allgemeine Systemkomponenten

5.3.1. Log-Events Die Log-Events sind die zu verteilenden Informationen. Sie werden von den angeschlossenen Applikationen an den Server gesendet und von ihm zur weiteren Verarbeitung auf den definierten Verteilkanälen publiziert. Der Inhalt dieser Meldungen wird von den angeschlossenen Applikationen bestimmt. Die Struktur dieser Log-Events wird aber vorgegeben.

Aufgrund der weiten Verbreitung im J2EE-Umfeld lehnt sich das Format der Log-Events stark an Log4J an. Insbesondere der RemoteTraceAppender wird spezifisch für Java-Applikation mit Log4J implementiert. Damit aber auch andere Applikationen das System nutzen können, werden keine Java-Objekte an oder vom Server versendet, sondern ein XML-Abbild eines Log4J Log-Events (siehe class org.apache.log4j.spi.LoggingEvent).

Die wichtigsten Bestandteile eines Log-Events sind:

• Applikations-ID (Absender)

• Log Level



• Message

• Timestamp

5.3.2. Externe Produzenten/Konsumenten Externe Produzenten und Konsumenten sind nicht Bestandteil des Systems. Sie sollen nur demonstrieren, dass jede Art von Produzent (Applikation, die Log-Events sendet) und Konsument (Analyse- und Auswertungstool) ans System angebunden werden kann.

Voraussetzung für externe Produzenten und Konsumenten ist, dass sie die definierten Schnittstellen des Messaging-Providers und der Datenbank nutzen können.

5.3.3. Simulator Aufgrund fehlenden produktiven Applikationen, die das Gesamtsystem nutzen könnten, und zu Testzwecken, wird ein Simulator erstellt. Dieser soll in mehreren Instanzen mit unterschiedlichen Konfigurationen eine produktive Umgebung simulieren können. Der Simulator dient zusätzlich als Referenzapplikation des RemoteTraceAppenders.

Technische Anforderungen an den Simulator:

• Referenzapplikation des RemoteTraceAppenders

• Verwendet Log4J

• Simuliert verschiedene Applikationen

• Kann Log-Events in verschiedenen Levels generieren

• Einfache Installation

5.4. Technologien Die einzusetzenden Technologien richten sich an einem J2EE-Umfeld aus. Alle Subsysteme werden in Java 1.5 realisiert.

Übersicht der vorgesehenen Technologien:

• Log4J (Logging-Framework)

• JMX (Java Management Extension)

• Hibernate (O/R-Mapping)

• JSF (Java Server Faces) / Ajax (kann Ziel)

• Tomcat (Webserver)

• OpenJMS (JMS Implementation)

• MySQL (Datenbank)

5.5. Schnittstellen Zwischen den einzelnen Subsystemen erfolgt keine direkte Kommunikation. Die Schnittstellen werden durch den JMS-Provider und seine Destinations und die Datenbanken definiert.



Schnittstelle Nutzer Beschreibung LogQueue Applikationen, Server Die Log-Queue wird durch den JMS-

Provider verwaltet, nimmt sämtliche Log-Events aus den Applikationen entgegen und sorgt für eine gesicherte, asynchrone Auslieferung an den Server. Das Format der Log-Events wird aufgrund eines XML-Schemas definiert.

ConfigDB Server Datenbank mit allen Konfigurationseinstellungen des Systems. Dazu gehören die Verteilkanäle, Dispatchingregeln und die angeschlossenen Applikationen.

Verteilkanäle Analysetools, Channel-Browser

Vom Benutzer definierte Verteilkanäle (Topic, DB), auf die der Server die Log-Events für die Analyse und Überwachung veröffentlicht.



6. Nichtfunktionale Anforderungen In diesem Kapitel werden die Anforderungen beschrieben, welche die Funktionalität des Gesamtsystems nur indirekt beeinflussen.

6.1. Mehrsprachigkeit Das Userinterface muss ohne programmatische Eingriffe Mehrsprachigkeit unterstützen. Die Default-Sprache ist deutsch und wird als einzige Sprache implementiert.

6.2. Installation und Softwareverteilung Das System soll möglichst einfach installiert und konfiguriert werden können. Einzelne Systemkomponenten wie der Appender und der Simulator sollen über das Webfrontend als Download verfügbar sein.

6.3. Onlinehilfe Den Benutzern soll in Bezug auf die Anwendung dort eine Onlinehilfe zur Verfügung gestellt werden, wo eine Bedienung des Systems nicht intuitiv ersichtlich ist, sondern weiterführende Erklärungen notwendig sind. Als Beispiel ist eine Onlinehilfe zur Erfassung eines neuen Kanals sinnvoll.

6.4. Dokumentation Die Gesamtdokumentation des Systems soll über das Webfrontend als Download zur Verfügung gestellt werden. Die Dokumentation umfasst die Systemdokumentation, das Benutzerhandbuch, die Konfigurationsbeschreibung sowie die Installationsanleitung.

Als Alternative dazu könnte eine Online Hilfe über das ganze System in Form eines Wikis erstellt werden.

6.5. Sicherheitsanforderungen Da das System im Rahmen der Diplomarbeit ohne direkten Auftraggeber entwickelt und (noch) nicht produktiv eingesetzt wird, muss dem Aspekt der Sicherheit keine grosse Beachtung geschenkt werden. Sicherheitsaspekte sollen aber in das Design des Systems einfliessen. Effektiv umgesetzt wird ein einfaches Benutzer-Login.

6.6. Performance Die Performance spielt in vier Bereichen eine zentrale Rolle:

• Die Applikation darf nicht beeinträchtigt werden Die an das System angeschlossenen Applikationen benötigen einen gewissen Aufwand, um die Log-Events durch den Appender zu verarbeiten. Die Verarbeitung der Log-Events darf die Applikation in ihrer eigentlichen Aufgabe nicht beeinträchtigen. Es ist jedoch schwierig, Performance-Beeinträchtigungen, welche durch die Verarbeitung der Log-Events entstehen, zu messen.



• Leistungsfähigkeit des Messaging-Systems Es kann nicht abgeschätzt werden, wie leistungsfähig das eingesetzte Messaging-System (OpenJMS) ist. Verfügt dies nicht über die gewünschte Leistungsfähigkeit, kann der Datenfluss bei der Weiterleitung der erzeugten Log-Events von den Applikationen zum Server ins Stocken geraten. In einer produktiven Umgebung müsste unter Umständen das Messaging-System durch ein kommerzielles Produkt ersetzt werden.

• Verarbeitungsgeschwindigkeit des Servers (Dispatching) Die Log-Events, die an den Server gesendet werden, durchlaufen im Server mehrere Verarbeitungsschritte. Das Dispatching sollte so konzipiert sein, dass grössere Datenmengen verarbeitet werden können. Wo die Leistungsgrenze liegt, kann momentan noch nicht vorausgesagt werden. Bei entsprechenden Lasttests wird diese Grenze sicher aufgezeigt.

• Antwortzeiten vom Webfrontend des Servers Das Webfrontend, das zur Konfiguration des Servers und zur Überwachung der Verteilkanäle genutzt wird, soll eine maximale Antwortzeit von 2 Sekunden nicht überschreiten.

6.7. Mengengerüst Die Anzahl der zu verarbeitenden Log-Meldungen hängt erstens von der Anzahl der angeschlossenen Applikationen und zweitens von der Anzahl generierter Log-Meldungen durch die Applikationen ab. Drittens wird die Anzahl der vom Server zu verarbeitenden Log-Meldungen durch den in den Applikationen eingestellten Log-Level beeinflusst.

Im Rahmen der Diplomarbeit gehen wir von folgenden Annahmen aus:

• Eine Applikation produziert (mit Log-Level = Debug) 100 Log-Events pro Minute.

• Es sind 10 Applikation angeschlossen.

Ergibt 1000 Log-Meldungen, die pro Minute verarbeitet werden müssen.

6.8. Verfügbarkeit Das System muss so ausgelegt sein, dass ein 7 x 24 Stunden Betrieb möglich ist. Das Wartungsfenster sollte sich auf 2 Stunden pro Woche beschränken.



7. Zielklassifizierung Die in den vorangehenden Kapiteln beschriebenen Komponenten sowie die technischen, funktionalen und nichtfunktionalen Anforderungen werden hier nach ihren Prioritäten klassifiziert.

Muss: Sind Anforderungen mit höchster Priorität, die im Rahmen der Diplomarbeit zwingend zu realisieren sind, da deren Nicht-Erfüllung die Funktionsweise des Gesamtsystems in Frage stellen würde.

Soll: Sind Anforderungen, die ebenfalls im Umfang der Diplomarbeit realisiert werden sollten. Eine Nicht-Realisierung, aufgrund nicht voraussehbarer Umständen (Zeitnot, technischen Risiken) würde die Muss-Anforderungen des Gesamtsystems aber nicht gross beeinflussen. Sie können auch mit eingeschränkten Funktionalitäten implementiert sein.

Kann: Dies sind Anforderungen, die im Umfang der Diplomarbeit nicht realisiert werden, aber Teil einer Erweiterung des Systems sein könnten. Sie sollen deshalb im Design des Systems berücksichtigt werden.

Nr. Beschreibung Muss Soll Kann 1 Komponenten 1.1 RemoteTraceAppender X 1.2 RemoteTraceServer X 1.3 Simulator X 2 Technische Anforderungen 2.1 Skalierbarkeit X 2.2 JMX-Schnittstelle X 2.3 Plugin-Prinzip für Verteilkanäle X 3 Verteilkanäle 3.1 Topics X 3.2 Datenbank X 3.3 SMS X 3.4 E-Mail X 4 Funktionale Anforderungen 4.1 UC_1.0: Log-Event anfangen X 4.2 UC_1.1: JMX Remote Management X 4.3 UC_2.0: Dispatching konfigurieren X 4.4 UC_2.1: Applikationen verwalten X 4.5 UC_2.2: Kanäle verwalten X 4.6 UC_2.3: Statistiken erstellen X 4.7 UC_2.4: Kanäle anzeigen (statisch) X 4.8 UC_2.4 Variante: Kanäle anzeigen

(dynamisch) X

4.9 UC_2.5: JMX Remote Management X 4.10 UC_2.6: Login X 5 Nichtfunktionale Anforderungen 5.1 Unterstüzung von Mehrsprachigkeit X 5.3 Einfache Installation und SW-Verteilung X X 5.4 Onlinehilfe X 5.5 Downloadbare Dokumentation X 5.7 Onlinehilfe X



8. Projektmanagement

8.1. Vorgehen Zur Entwicklung des RAT wurde das Vorgehensmodell nach RUP gewählt. Das zu entwickelnde RAT ist Architektur-getrieben. Zudem unterstützt das RAT verschiedene Anwendungsfälle. Beide Aspekte werden durch das Vorgehensmodell nach RUP optimal unterstützt.

Ein weiterer Vorteil des Vorgehensmodells liegt in der iterativen Vorgehensweise. Im Rahmen der Diplomarbeit wird mit der Analyse, dem Design, der Entwicklung und der Einführung eine Iteration realisiert. Die effektive Implementierung in ein produktives Umfeld könnte anschliessend in einer zweiten Iterationsschlaufe erfolgen. Weiter gilt das Vorgehensmodell heute als „Best Practice“.

Das Projekt gliedert sich entsprechend in 4 Phasen:

• Studie: Im Rahmen dieser Phase wird eine Analyse der Ist-Situation und der Bedürfnisse durchgeführt. Weiter werden die Anforderungen an das System definiert.

• Konzept / Design: Im Rahmen dieser Phase erfolgen die Architekturbeschreibung sowie das Design der einzelnen System-Komponenten. Weiter werden die Klassendiagramme erstellt und das Benutzer-Frontend definiert.

• Realisierung: Im Rahmen der Realisierung werden die einzelnen System-Komponenten entwickelt.

• Einführung: Unter der Einführung wird die Abgabe der Diplomarbeit verstanden. Das beinhaltet einen Gesamttest des Systems, die Fertigstellung der Systemdokumentation sowie die Abgabe und Präsentation der Diplomarbeit.

Parallel zu diesen vier Hauptphasen laufen begleitende Prozesse ab, welche die Projektplanung, die Qualitätssicherung, Meetings zur Kontrolle des Projektfortschritts und der Abstimmung der Aufgaben, Meetings mit Betreuern und Experten sowie die laufende Dokumentation des Systems beinhalten.

8.2. Organisation Diese Arbeit wird von einem zweier Team mit folgenden Hauptaufgaben erstellt.

Remo Ledermann

• Systemdesign

• Serverprogrammierung

• Appenderprogrammierung

• Technologien

• Prototypen



Roland Jost

• Projektplanung

• Datenbank

• Dokumentation

• XML

• Webfrontend

• Simulator

Grundsätzlich findet wöchentlich eine Sitzung der beiden Projektmitarbeiter zur Abstimmung der Aufgaben und zur Kontrolle des Projektforschritts statt. Nach Bedarf werden zusätzliche Sitzungen kurzfristig einberufen.

8.3. Datensicherung Die Datensicherung wird durch folgende Massnahmen gewährleistet:

• Daten werden auf verschiedenen PCs gehalten

• Wöchentliche Sicherung der Daten auf einem externen Datenträger

8.4. Change Management Dokumente Ausgehend von einer Vorlage kann parallel an einem Dokument gearbeitet werden. Die einzelnen Teile können dann zusammengefügt werden. Zum Überarbeiten ist dann das gesamte Dokument bei einem Studenten. Damit auch weiterhin parallel gearbeitet werden kann, wird ein klar definierter Bereich als Delta geliefert und eingefügt.

Code Jeder Student soll eine möglicht aktuelle Version des Projekts auf seinen Computern haben.

Es wird in regelmässigen Abständen (14 Tage) das Projekt zusammengefügt und wider zum laufen gebrach.

8.5. Qualitätssicherung Das Qualitätsmanagement soll sicherstellen, dass die Software wenige Fehler aufweist und den erforderlichen Standards, insbesondere für die Wartbarkeit, Zuverlässigkeit und Portierbarkeit entspricht. Die Aktivitäten des Qualitätsmanagements umfassen die Qualitätssicherung, die Berücksichtigung von Normen für die Softwareentwicklung, die Qualitätsplanung sowie die Qualitätskontrolle, welche die Artefakte mit den gängigen Standards vergleicht.

Es ist die Pflicht der Projektmitarbeiter, die gängigen Standards und Normen, die im IT Umfeld bekannt sind, anzuwenden.

Der Umfang der existierenden Standards und Normen wird als zweckmässig und ausreichend erachtet, so dass im Rahmen der Diplomarbeit keine zusätzlichen, eigenen Standards entwickelt und berücksichtigt werden.


Die Qualität der erstellten Arbeiten wird durch Reviews sichergestellt. Grundsätzlich wird jedes Arbeitsergebnis durch beide Projektmitarbeiter geprüft.

8.6. Terminplan Der Terminplan gilt als zeitlicher Leitfaden für dieses Projekt. Er definiert, wann welche Arbeiten zu erledigen sind. Es ist wichtig, dass die Endtermine eingehalten werden, da sonst er Abgabetermin gefährdet ist.

Die Feinplanung wird rollend gemacht: Es wird wöchentlich und situativ entschieden, welche Aufgaben in welcher Tiefe bis wann gemacht werden müssen.

Nachfolgend wird der grobe Terminplan präsentiert. Der detaillierte Terminplan ist im Anhang abgebildet.




8.7. Aufwandschätzung Task Aufwand Studie Istanalyse 10 Bedürfnisanalyse 20 Risikoanalyse 10 Anwendungsfälle definieren 20 Einzusetzende Technologien evaluieren 20 Mögliche System-Architekturen 15 Varianten prüfen und entscheiden 10 Technische Beschreibung 20 Prototypen erstellen 20 Projektplan erstellen 12 Aufwandschätzung 3 Pflichtenheft erstellen 40 Review Pflichtenheft 10 Abgabe Pflichtenheft 2

Zwischentotal 212 Konzept / Design Design des gesamten Systems 20 Schnittstellen Definieren (XML Schema) 10 Design Appender 20 Design des Simulators 20 Design Server 30 Datenbank Modell 10 Screens und Screen-flow für Server 20 Klassendiagrmme erstellen 20 Testfälle definieren 10

Zwischentotal 160 Realisierung Umgebung bereitstellen + JMS 10 Simulator 30 Appender 35 Server 60 Server Webfrontend 40 Einzeltests 20

Zwischentotal 195 Abgabe Diplomarbeit Testen des gesamten Systems 20 Dokumentation Aufbereiten 20 Abgabe Diplomarbeit 5 Präsentation vorbereiten 20 Präsentation + Ausstellung 5

Zwischentotal 70 Begleitende Prozesse Dokumentation 50 Projektplanung 20 Meetings 20

Zwischentotal 90

Total Aufwand in Stunden 727


9. Anhang

9.1. Projektplan




9.2. Glossar Channel-Browser Im Webfrontend integrierte Funktion, um den Inhalt der Verteilkanäle anzeigen zu

können.

DB Abkürzung für Datenbank.

Dispatching / Dispatcher Der Dispatcher ist die Systemkomponente, die für das Verteilen der Log-Events auf die verschiedenen Kanäle zuständig ist

Hibernate Hibernate wird als objekt-relationales Mappingtool und zur Kapselung der Datenzugriffe verwendet.

Http-Adaptor Adaptor, der eine JMX-Schnittstelle in Form einer einfachen Website darstellen kann.

J2EE Java 2 Platform Enterprise Edition (J2EE). Spezifikation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in Java programmierten Webanwendungen.

JAR Java Archive, gepackte Archivdatei ähnlich wie ZIP.

JMS / JMS-Spezifikation Java Messaging Service, Schnittstellendefinition von SUN. JMS-Provider Ein JMS-Provider ist ein Produkt, das die JMS-Spezifikation umsetzt.

JMX JMX (Java Management Extension) ist eine Technologie für das Management und

Monitoring von Java-Applikationen.

JSF JSF (Java Server Faces) ist ein Framework für Webapplikationen.

Log-Event / Log-Meldung Log-Event und Log-Meldung sind gleichwertige Bezeichnungen. Sie werden von einer angeschlossenen Applikation ausgelöst.

Monitoring überwachen / kontrollieren

MySQL MySQL ist ein Open-Source Datenbanksystem.

OpenJMS OpenJMS ist eine Open-Source Implementation der JMS-Spezifikation von Sun. OpenJMS wird als JMS-Provider eingesetzt und sorgt für die gesicherte asynchrone Kommunikation.

RAT Abkürzung für Remote Application Tracing, Bezeichnung des Gesamtsystems

RemoteTraceAppender Appender für Applikationen, der das Senden von Log-Events übernimmt

RemoteTraceServer Zentraler Server, der alle Log-Events verarbeitet

RUP Abkürzung für Rational Unified Process, iterativer Softwareentwicklungsprozess.

Tomcat Ist ein Open-Source Servlet-Container, der als einfacher Webserver eingesetzt wird.

Verteilkanal Aus Sicht von RAT ist ein Verteilkanal ein Ziel, auf das ein Log-Event publiziert wird.

http://de.wikipedia.org/wiki/Spezifikation

http://de.wikipedia.org/wiki/Softwarearchitektur

http://de.wikipedia.org/wiki/Transaktion_%28Informatik%29

http://de.wikipedia.org/wiki/Java_%28Programmiersprache%29

http://de.wikipedia.org/wiki/Webanwendung



9.3. Quellenverzeichnis

[1] Othmar Bürgi, Skript Projekt-Management von SW-Entwicklungsprojekten,

2005

[2] Urs Küenzler, Skript Objektorientiertes Software Engineering

[3] Bernd Oestereich, Obektorientierte Softwareentwicklung, 6. Auflage 2004

[4] Christoph Kecher, UML 2.0 das umfassende Handbuch, 2005

[5] Ian Sommerville, Software Engineering, 6. Auflage 2001

[6] Bruno Jenny, Projektmanagement in der Wirtschaftsinformatik, 5. Auflage

2001

[7] Beispiele guter Diplomarbeiten

http://www.sws.bfh.ch/studienbetrieb/dip/index.xhtml

[8] Diverse Informationen

http://de.wikipedia.org

[9] Weiss leider nicht alles

http://www.google.ch

[10] Online-Artikel von Madhusudhan Konda

http://www.javaworld.com/javaworld/jw-05-2004/jw-0510-logging.html

9.4. Versionskontrolle

Version Datum Bemerkung 1.0 24.07.2006 Grundversion 1.1 05.08.2006 Überarbeitete nach Review mit Experte und Betreuer 2.0 07.08.2006 Abgabeversion

Documents

Remote Application Tracingstatic.sws.bfh.ch/download/B36-08-doc.pdf · Zusätzlich wird vom Gesamtsystem für die gesicherte asynchrone Kommunikation ein JMS-Provider und für die