Ein System zur Transformation von Geschäftsnachrichten

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Problemstellungen und Zielsetzung
1.3 Struktur der Arbeit

2 Beispielszenario
2.1 Eröffnung eines Akkreditivs
2.2 Änderung des Akkreditivs

3 Systemanforderungen
3.1 Übersicht
3.1.1 Integrationsanforderungen
3.2 Systemeigenschaften
3.2.1 Bidirektionalen Transformationen
3.2.2 Automatisierte Transformationen
3.2.3 Unterstützung unterschiedlicher Formate
3.2.4 Flexible Schnittstellen
3.2.5 Modularität
3.2.6 Erweiterbarkeit
3.2.7 Wartbarkeit
3.2.8 Übertragbarkeit
3.2.9 Wiederverwendbarkeit

4 Überblick XML-Verarbeitung
4.1 Einführung
4.1.1 XML als Sprache für das World Wide Web
4.1.2 XML trennt die Daten von ihrer Verarbeitung
4.1.3 XML als Metasprache
4.1.4 Transformation von XML-Dokumenten
4.2 XML: Informationsaustausch
4.2.1 Dokumententypdefinitionen (DTD)
4.2.2 XML-Schema
4.3 Die Transformationssprache XSL
4.3.1 Xpath
4.3.2 XSL
4.4 Die Abfragesprache XQuery
4.4.1 Was ist XQuery?
4.4.2 Transformationen mit XQuery
4.5 Überblick: XML und Java
4.5.1 XML-Parser in Java
4.5.2 XSLT-Prozessoren in Java
4.5.3 Die JAXP-API
4.5.4 Weitere APIs
4.6 Übersicht über bisherige Lösungsansätze
4.6.1 Einführung
4.6.2 Biztalk
4.6.3 GoXML
4.6.4 MessageObjects

5 Transformationstechniken
5.1 Grundlegende Konzepte
5.1.1 Konvertierung
5.1.2 Grammatiken
5.1.3 Sprachanalysatoren
5.1.4 Transformationsorientierte Software
5.2 Transformationsorientierte Verarbeitung von Texten
5.3 Transformierungsmethode
5.3.1 Transformationen mit XML als Zwischenschritt
5.3.2 Einfaches Transformieren
5.3.3 Komplexeres Transformieren
5.3.4 Generierung von Klassen auf der Basis einer Grammatik
5.4 Pipes & Filter-Architektur
5.5 Zusammenfassung

6 Systementwurf
6.1 Annahmen und Eingrenzungen
6.2 Konzepte und Technologien zur Realisierung der Anforderungen
6.2.1 Integration des Systems
6.2.2 Systemeigenschaften
6.3 Softwareentwurf
6.3.1 Vorüberlegungen
6.3.2 Verteilung der Daten
6.3.3 File Interface
6.3.4 Repository
6.3.5 Transform engine
6.3.6 Operator GUI
6.3.7 Ablauf
6.3.8 Zusammenfassung

7 Systemimplementierung
7.1 Beschreibung der Umgebung
7.1.1 Bank- und Kunde-System
7.1.2 Implementierungsumgebung
7.2 Implementierung des Softwareentwurfs
7.2.1 Verteilung der Daten
7.2.2 File Interface
7.2.3 Das Repository
7.2.4 Transformation engine
7.2.5 Operator GUI
7.2.6 Zusammenfassung

8 Zusammenfassung, Fazit und Ausblick
8.1 Zusammenfassung
8.2 Fazit und Ausblick

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

2.1 Eröffnung eines Akkreditivs
2.2 Sequenzdiagramm: Nachrichtenfluss

3.1 Anwendungsfalldiagramm: Überblick TestBank System

4.1 Einfache XML-Struktur
4.2 Einfache XML-Struktur mit Attributen
4.3 DTD zum Beispiel von Abbildung 4.2
4.4 XML-Schema zur DTD von Abbildung 4.3
4.5 Navigation mit Xpath
4.6 XSLT-Transformation
4.7 Template-Ausdruck
4.8 XQuery Beispiel
4.9 Mögliches Ergebnis der Anfrage von Abbildung 4.8
4.10 Beispiel einer XML-Struktur
4.11 Beispiel einer generierten Klasse bei JAXB
4.12 XQJ-Architektur
4.13 BizTalk-Dokument

5.1 Pipes & Filter Architektur bei Transformation eines Dokuments

6.1 Beispiel von Eingangs- bzw. Ausgangs Schnittstellen
6.2 Aufbau des Transformationssystems
6.3 Verzeichnisstruktur des File InterFaces
6.4 Verzeichnisstruktur des Repository
6.5 UML Diagramm: Hook-Object-Konstruktionsprinzip der Transform engine
6.6 Anpassung unter Zuhilfenahme eines Editors
6.7 Sequenzdiagramm: Ein mögliches Szenario des Prozess-Ablaufs

7.1 Verzeichnisstruktur des Transformationssystems
7.2 Struktur der Config.ini
7.3 Struktur der Transform.ini
7.4 Klassendiagramm des Transformationsmoduls mit der neuen Schnittstelle XquerySaxon
7.5 Implementierung der Methode transforming() von der Klasse Transform
7.6 Klassen und die Eingabe-Parameter
7.7 Teil einer SWIFT-Nachricht
7.8 Allgemeine XML-Struktur der SWIFT-700
7.9 XQuery-Skript zur Transformation von SWIFT-700 nach BOL-460
7.10 Teil des Ergebnis-Dokuments: Bolero-460
7.11 Haupt-Panel des Transformationssystems
7.12 Panel zur Verwaltung der Einstellungen
7.13 Panel zur Verwaltung der Log-Datei

1. Einleitung

1.1 Motivation

XML (eXtensible Markup Language) ist schnell eine beliebte Sprache für den Austausch von Daten zwischen Organisationen bzw. Applikationen geworden. Ihre Popularität hat zu einer Konjunktur von XML Dialekten, Frameworks, Standards und Protokollen wie xCBL (XML Common Business Library), ebXML (Electronic Business XML), UDDI (Universal Description, Discovery and Integration) und WSDL (Web Services Description Language) geführt. Die Anzahl der Unternehmen, die XML als Dokument- und Nachrichten-Format für ihr Geschäft benutzen bzw. benutzen wollen, wächst ständig. Aus diesem Aufschwung ergibt sich die Forderung nach XML-Transformationen (siehe unten) für den Austausch von XML-Dokumenten, wie in den folgenden Fällen beschrieben ist:

a. Unternehmen wollen Geschäftsnachrichten in verschiedenen XML-Formaten austauschen.

b. Unternehmen, die als Haupt-Format für ihre Geschäftsdokumente einen Standard wie z.B. EDIFACT (EDI for Administration, Commerce and Transport) oder SWIFT (Society for Worldwide International Financial Telecommunication) benutzen, möchten Nachrichten mit anderen Organisationen austauschen, welche XML als Geschäftsnachrichten-Format benutzen.

Im einfachsten Fall wird z.B. ein Unternehmen „A“ mit Standard-Format „x“ nur mit einem Unternehmen „B“ im XML-Format „y“ Nachrichten austauschen. Häufiger und in der Umsetzung komplizierter wird das Unternehmen „A“ jedoch Nachrichten mit „B“ Format „y“, „C“ Format „z“, „D“ Format „q“ usw. Geschäftsnachrichten austauschen wollen.

Eine große Schwierigkeit hierbei sind die vielen verschiedenen XML-Dialekte, welche zurzeit benutzt werden. Die Markup-Sprache XML bietet durch die DTDs (Document Type Definition) und XML-Schemata die Möglichkeit freier Definitionen von Dokumententwürfen. Diese Eigenschaft wird oft für die Entwicklung neuer Standards von Geschäftsdokumenten bzw. Geschäftsnachrichten genutzt.

XML leitet sich, wie auch HTML (Hypertext Markup Language), aus SGML (Standard Generalized Markup Language) ab. Während HTML zur Beschreibung von Dokumenten benutzt wird, wird XML vorwiegend für die Beschreibung von

Daten verwendet. Wenn für das XML-Dokument eine DTD oder ein Schema existiert, dann können Regeln für das Verhalten der Daten definiert werden. Weitergehend bietet XML viele Möglichkeiten zur Verarbeitung von Dokumenten und bildet deshalb die beste Lösung zur Beschreibung von Geschäftsdokumenten. Wegen diesen Vorteilen und anderen Eigenschaften, welche im Kapitel 4 noch betrachtet werden, wird XML zur Grundlage dieser Arbeit genommen.

Ein großer neuer Standard ist das Bolero-System. Bolero (Bill of Lading for European Organisations) selbst betreibt eine Datenbank, welche über das Internet erreichbar ist und über die alle Teilnehmer am Bolero-System Nachrichten austauschen können. Die einzelnen Bolero-Dokumenttypen sind reine XML- Dokumente. Für jeden diesen Dokumenttypen gibt es verschiedene DTD-Versionen. Hieraus ergibt sich die Notwendigkeit von Transformationen für den Austausch von Nachrichten über das Bolero-Netz für Teilnehmer, die unterschiedliche Dokument-Versionen benutzen. Ein Beispiel eines Bolero-Dokuments kann in Abschnitt 7.2.4, Abbildung 7.10 betrachtet werden.

Die Swift-Gesellschaft definiert eine außerordentlich große Anzahl von verschiedenen Dokumenten zu allen nur denkbaren Zwecken, wie z.B. die Eröffnung eines Akkreditivs (Auslandskredit-Geschäft) oder deren Änderung. Finanztransaktionen sind beschrieben bei standardisierten strukturalen Nachrichtenarten, welche Feldkennzeichnungen (Tags) enthalten. In Folge dessen werden Regeln wie Pflicht- bzw. Optional-Feld, Reihenfolgewiederholungen etc. aufgebaut. Technisch betrachtet sind SWIFT-Nachrichten nichts anderes als einfache ASCII Dateien. Ein Beispiel der SWIFT-Syntax wird in Abschnitt 7.2.4, Abbildung 7.7 dargestellt.

1.2 Problemstellungen und Zielsetzung

Um die Zielsetzung dieser Diplomarbeit klarer zu machen, wird ein Beispielszenario aus der Branche des Auslandskredit-Geschäfts (Akkreditiv) angenommen. Eine Bank bietet ihren Kunden die Möglichkeit, mit ihr bestimmte Nachrichten im XML-Format über die Bolero-Plattform austauschen zu können. Die Bank benutzt das SWIFT-Netz, um mit anderen Banken und Finanzdienstleistern Nachrichten auszutauschen.

Ein Importeur sendet nun eine Bolero-Nachricht zur Eröffnung eines Akkreditivs an seine Bank. Mit dem Senden dieses Auftrages fängt der Austausch von Nachrichten an.

Aus dem Beispielszenario ergibt sich die Anforderung, dass eine Transformation von SWIFT-Nachrichten zu Bolero-Nachrichten in beiden Richtungen nötig ist. Da das Home-System der Bank ein SWIFT-basiertes System ist, muss sie eine Transformationslösung benutzen, welche dies ermöglicht. Zur Lösung dieser Problemstellung gibt es verschiedenen Alternativen.

Einige dieser Alternative sind:

- Ersetzung des SWIFT-basierten Systems durch eine neue Softwarelösung. Diese Alternative wird aus folgenden Gründen ausgeschlossen:
- es kostet viel Zeit, die Verwaltung bzw. die Funktionalität des neuen Produkts kennen zu lernen, denn in der Regeln sind dies sehr umfangreiche Systeme,
- es könnten Kompatibilitätsprobleme auftreten, z.B. bei der Anbindung an Datenbanken, Betriebssysteme, Peripherien etc.,
- das neue Produkt könnte trotzdem nicht alle Anforderungen erfüllen, die das alte System schon lösen konnte und
- solche Systeme sind in der Regel sehr teuer.
- Eine zweite Alternative wäre, das SWIFT-System so zu erweitern, dass es auch die Transformationen nach XML ausführen kann. Diese Alternative wird aus folgenden Gründen ebenfalls ausgeschlossen:
- es kostet viel Zeit,
- es fordert sehr gute Kenntnissen der neu eingesetzten Technologien,
- es müssen eigene oder externe Mitarbeiter dafür eingesetzt werden,
- die Ergonomie des bestehenden Systems kann negativ beeinflusst werden und
- es ist nicht günstig.
- Ausgehend von der Anforderung, die durch das Beispielszenario entsteht, ist die beste Alternative, ein Transformationssystem einzuführen, welches diese Anforderung, also die Transformation von SWIFT-Nachrichten zu Bolero-Nachrichten in beiden Richtungen, erfüllt. Einige Vorteile dieser Alternativlösung sind:
- das SWIFT-System bleibt unverändert und damit auch seine sämtlichen Funktionen,
- das SWIFT-System wird nicht negativ ergonomisch beeinflusst,
- ein System, das nur zur Transformationen zuständig ist, ist nicht sehr umfangreich und deshalb kann seine Funktionalität schnell erlernt werden,
- das Transformationssystem kann auch andere Formate unterstützen und
- das neue Transformationssystem gibt der gesamten Umgebung mehr Portabilität bzw. Flexibilität, da es nicht im gleichen Rechner des SWIFT-Systems installiert sein muss.

Ziel dieser Diplomarbeit ist:

Der Entwurf und die Implementierung einer Softwarelösung zu XML-Transformationen von Geschäftsnachrichten, welche die Anforderungen des gewählten Szenarios erfüllt.

1.3 Struktur der Arbeit

Als erstes wird im Kapitel 2 durch ein Beispielszenario erläutert, in welchem Kontext diese Arbeit steht und es werden bereits erste Anforderungen an das System skizziert.

In Kapitel 3 wird die Anforderungsanalyse im Allgemeinen bzw. für das Beispielszenario Transformationsverarbeitung in einer detaillierten Weise dargestellt. Des Weiteren werden die Eigenschaften, die das System erfüllen soll, definiert.

Die Mächtigkeit der XML-Verarbeitung wird im Kapitel 4 dargestellt. Hier werden die verschiedenen Methoden, Transformationssprachen und Abfragemöglichkeiten, die XML schon bietet bzw. welche mit XML angeboten werden, analysiert und bewertet. In diesem Kapitel wird außerdem ein Überblick über die Programmiersprache Java und die Möglichkeiten, welche das Programm für die Verarbeitung von XML zur Verfügung stellt, gegeben.

Kapitel 5 bietet eine Übersicht über gebräuchliche Transformationstechniken. Es werden dazu Konzepte, Architekturen und Methoden vorgestellt, die zum Entwurf des Transformationssystems nützlich sind.

Die Kapitel 6 und 7 stellen die entworfene Lösung dar. Im 6. Kapitel wird die in dieser Arbeit vorgeschlagene Lösung entworfen und im Kapitel 7 erfolgt die Implementierung.

Im letzten Kapitel werden die Ergebnisse der Arbeit zusammengefasst. Des Weiteren wird ein Ausblick darauf gegeben, wie sich das entworfene System erweitern ließe und was die Zukunft bringen wird bzw. bringen könnte.

2 Beispielszenario

In dem folgenden Beispielszenario geht es um ein fiktives Akkreditivgeschäftszenario. Bei einem Akkreditiv handelt es sich um die Verpflichtung einer Bank, dem Verkäufer einer Ware oder Dienstleistung bei fristgerechter Einreichung konformer Dokumente, die den erfolgten Versand der Ware oder erbrachten Dienstleistung ausweisen, einen bestimmten Betrag zu zahlen. In der Abbildung 2.1 wird ein allgemeines Akkreditivszenario dargestellt. Dabei sind vier Haupt-Schritte zu betrachten, die als nächstes kurz beschrieben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Eröffnung eines Akkreditivs

Im ersten Schritt werden der Importeur und der Exporteur Vertragsverhandlungen führen, in denen die Ware, der Preis und alle Zahlungsmodalitäten geklärt werden müssen. Wenn zwischen Importeur und Exporteur alles geklärt ist, dann muss der Importeur seiner Bank die Eröffnung eines Akkreditivs in Auftrag geben (Schritt 2). Die eröffnende Bank (die Hausbank des Importeurs), die im gleichen Land liegt wie die Firma des Importeurs, wird dann die Kreditwürdigkeit des Auftraggebers überprüfen. Erst nach dieser Absicherung lässt die eröffnende Bank der Bank im Lande des Verkäufers (Exporteurs) den Auftrag oder die Ermächtigung zugehen, dem Akkreditiv die Bestätigung beizufügen.

Das geschieht in Schritt 3. Danach prüft die Hausbank des Exporteurs den Inhalt und die Echtheit des Akkreditivs sowie die Bonität und Reputation der eröffnenden Bank. Fällt diese Prüfung positiv aus, wird sie nicht zögern, dem Akkreditiv ihre Bestätigung beizufügen und dann im Schritt 4 an den Exporteur weiterleiten.

Bei der Ausnutzung des Akkreditivs sendet der Exporteur dem Importeur die bestellte Ware zu. Dann erfolgt die Bezahlung derselben durch seine eigene Bank (Hausbank des Exporteurs). Das Konto des Importeurs wird durch seine Hausbank belastet und anschließend bekommt die Hausbank des Exporteurs die entsprechende Deckung von der Bank des Importeurs. Mehr Informationen zum Ablauf von Akkreditiv-Geschäften können in [Holtij 2004] vertieft werden.

Ein Akkreditiv kann immer von zwei Seiten gesehen werden. Für den Importeur ist es ein Import-Akkreditiv, für den Exporteur ein Export-Akkreditiv. In unserem Beispielszenario werden wir uns nur mit dem Import-Akkreditiv beschäftigen.

In den folgenden Darstellungen werden die elektronischen Nachrichten betrachtet, die bei einem sehr vereinfachten Szenario der Eröffnung und Änderung eines Akkreditivs – also auf der Seite des Importeurs – ausgetauscht werden. Auf Grund des großen Umfanges werden dabei nicht alle Geschäftsvorfälle und Nachrichtenformate beschrieben, die bei einem solchen Geschäft tatsächlich benutzt werden könnten. Auch die Sicherheitsaspekte werden nachfolgend nicht betrachtet. Es werden also nur die notwendigen Transformationen zwischen SWIFT-Format und XML-Format (Bolero) in beide Richtungen beschrieben werden.

2.1 Eröffnung eines Akkreditivs

Der Importeur (TestClient) wird zur Eröffnung eines Akkreditivs seine Bank, die TestBank, beauftragen. Dafür sendet er eine Bolero-Nachricht 460 (Documentary Credit Application) über das Bolero-Netz an die TestBank. Die TestBank empfängt die Nachricht und mit einem Konverter wird die Nachricht von XML in das SWIFT-Format transformiert. Danach wird sie in ihr System als SWIFT-Transaktion MT700 (Issue of a Documentary Credit) importiert. Anschließend wird die Nachricht an den Akkreditiv-Manager (L/C Manager) zur Verarbeitung weitergeleitet. Die SWIFT-Nachricht MT700 entspricht der Nachricht 460 von Bolero.

Der Akkreditiv-Manager überprüft die Kreditwürdigkeit des Auftraggebers und die Gültigkeit des empfangenen Dokuments. Danach wird eine Antwort an dem Kunden zurückgesendet. Die Nachricht MT700, die jetzt die Bestätigung bzw. Ablehnung des Antrages enthält, muss in eine Bolero-Nachricht 466 (Documentary Credit Notification) transformiert werden.

2.2 Änderung des Akkreditivs

Will der TestClient eine Änderung in dem Akkreditivdokument machen, beantragt er die Änderungen bei der TestBank durch eine Bolero 470-Transaktion (Documentary Credit Amendment Request). Die eröffnende Bank, die TestBank konvertiert das Dokument in einem SWIFT MT707 (Amendment to a Documentary Credit), welches dann in dem Akkreditiv-Manager verarbeitet wird.

Nach der Überprüfung des Dokumentes sendet die Bank ihrem Auftraggeber die entsprechende Mitteilung zurück. Dafür wird die SWIFT-Nachricht MT707 (Status message: Amendment under an Import L/C) in eine Bolero 489 (Documentary Credit Amendment Advice) umgewandelt.

In der Abbildung 2.2 werden mit Hilfe eines UML-Sequenzdiagrammes die oben beschriebenen Szenarien zur Anschauung dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Sequenzdiagramm: Nachrichtenfluss

3 Systemanforderungen

3.1 Übersicht

Aus dem Beispielszenario lassen sich Aktionen und Zustände erkennen, welche einzelnen Rollen zugeordnet werden können. Sinnvoll ist in diesem Zusammenhang die Qualifizierung als Rolle des Importeurs, Systemadministrators und L/C Managers (Akkreditiv-Managers).

Die Abbildung 3.1 zeigt, in welchen Umgebungen die einzelnen Rollen agieren und welches die grundlegenden Zuständigkeiten bzw. Aktionen sind:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Anwendungsfalldiagramm: Überblick TestBank System

Der Importeur (Importer) nimmt die von der Bank (TestBank) angebotene Möglichkeit, in seinem eigenen Home-Format (Bolero) Nachrichten auszutauschen, in Anspruch. Der Systemadministrator ist für die Verwaltung und Unterstützung des

Systems zuständig. Alle Akkreditiv-Aktionen, wie z.B. die Überprüfung der empfangenen Dokumente und der Kredit-Bonität des Kunden, werden vom Akkreditiv-Manager (L/C manager) ausgeführt. Dieser kann auch das Transformationssystem, z.B. durch die Anpassung von Transformationsregeln (siehe Kap. 6) verwalten.

3.1.1 Integrationsanforderungen

In diesem Abschnitt werden allgemeine Anforderungen bei der Integration von unterschiedlichen Systemen betrachtet.

Um eine Integration von Systemen mit verschiedenen Architekturen, Datenmodellen und Nachrichtenformaten zu erreichen, braucht man eine Schnittstelle, durch die ein Datenaustausch ermöglicht wird. Im Folgenden werden zwei Arten von Integrationen analysiert und entsprechende Kopplungstypen definiert.

Integration durch globale Datenstruktur

Eine mögliche Vorgehensweise ist es, eine globale Datenstruktur zu verwenden, die von allen beteiligten Systemen unterstützt wird. Dies kann in einer begrenzten Zahl von Systemen gelingen, ist im Allgemeinen jedoch schwierig zu realisieren. Außerdem können Datenänderungen in einer Datenbank Auswirkungen auf Daten haben, die in anderen Systemen gespeichert sind.

Integration durch Datenaustauschformate

In diesem Fall werden bei Transaktionen durch jeden Teilnehmer eigene Dokumententypen verwendet, wie in unserem Beispielszenario (siehe Kap. 2) geschildert wurde. Soll der Geschäftsprozess erfolgreich von Rechnern gestützt werden, muss sichergestellt sein, dass alle beteiligten Seiten den Aufbau der Dokumente des Partners kennen und analysieren. Es muss folglich eine einheitliche Semantik geben. Grundsätzlich bestehen hierfür drei Möglichkeiten: Die Partner können sich auf einheitliche Formate einigen oder es muss eine Übersetzung von einem Format in ein anderes erfolgen oder die Formate beider Partner müssen in ein Austauschformat umgewandelt werden.

Integration und Kopplung von Systemen

Die Integration der Systeme kann eng oder lose organisiert werden. Unter einer engen Kopplung wird die direkte Verbindung von Datenbanken des gleichen Typs oder mit fest definierten Austauschregeln verstanden. Für jeden neu anzubindenden Typ muss eine neue Konvertierungsrichtlinie festgelegt werden.

Eine lose Kopplung beinhaltet die Überführung eines Eingabeformates in eine unabhängige Zwischenrepräsentation. Dabei übernimmt eine Vermittlungsschicht die Konvertierung der Daten mit Hilfe von Ein- und Ausgangstransformationen.

In dieser Diplomarbeit wird nur die Integration durch die Transformationen von Datenaustauschformaten betrachtet. Wird nachfolgend von Integration von Systemen gesprochen, dann meint dies die lose Kopplung zwischen Systemen.

3.2 Systemeigenschaften

In diesem Abschnitt werden die Eigenschaften eines Transformationssystems definiert, welches sowohl die Anforderungen aus dem Beispielszenario (siehe Kap. 2) und als auch Basisanforderungen aus der Informatik dauerhaft erfüllt. Diese Anforderungen haben sich in der Informatik über Jahre herauskristallisiert.

3.2.1 Bidirektionale Transformationen

Wenn verschiedene Systeme Nachrichten austauschen wollen, dann geht es immer um Eingangs- bzw. Ausgangsnachrichten. Sofern ein Transformationssystem dazwischen wirksam werden soll, weil die auszutauschenden Nachrichten unterschiedliche Formate haben (siehe Kap. 2), dann ist dies nur sinnvoll, wenn die Transformationen in beiden Richtungen erfolgen können. Vereinfacht müsste es wie im folgenden Beispiel ablaufen:

Format „x“ à Format „y“ bzw. Format „y“ à Format „x“

3.2.2 Automatisierte Transformationen

Die Automatisierung der Transformationen und überhaupt die gesamte Austausch-Funktionalität ist Voraussetzung für den Erfolg der Softwarelösung. Das Transformationssystem muss die Fähigkeit haben, den Nachrichtenstrom so zu verarbeiten, dass keine manuelle Anpassung von Benutzern während des Transformationsprozesses nötig wird.

3.2.3 Unterstützung unterschiedlicher Formate

In unserem Beispielszenario (siehe Kap. 2) werden verschiedene Nachrichten in zwei unterschiedlichen Formaten ausgetauscht. Aktuell existieren, außer den traditionellen Geschäftsnachrichten-Formaten, wie z.B. SWIFT oder EDIFACT, auch viele unterschiedliche XML-Dialekte. Daher ist es erforderlich, dass ein Transformationssystem mehrere unterschiedliche Nachrichten-Formate unterstützen kann, um eine gute Akzeptanz auf dem Markt zu erreichen. Genauso muss das System die Fähigkeit besitzen, auf eine unkomplizierte Weise um die Unterstützung von neueren Formaten erweitert werden zu können. Diese Eigenschaft - die Möglichkeit der Erweiterung - werden wir in Abschnitt 3.3.7 näher betrachten.

3.2.4 Flexible Schnittstellen

Das System muss flexibel bezüglich der Einbindung bestehender Systeme sein.

Trotz Integration müssen die Funktionalitäten der beteiligten Systeme unabhängig bleiben. Daher muss man logische Schnittstellen entwickeln, die diese Unabhängigkeit gewährleisten. Diese können als Unterprogramm- oder als Datei-Schnittstelle (mit eigenen Datenkapselungsmodulen) ausgeführt werden.

Ein Beispiel von Unterprogramm-Schnittstellen wäre z.B. eine Funktion „ call “, die mit entsprechenden Parametern arbeitet, durch die alle Informationen mitgeteilt werden, die das andere System zur Durchführung irgendeiner Verarbeitung braucht.

Datei-Schnittstellen sind dann wünschenswert, wenn ein fertiges Dokument einem anderen System zur weiteren Bearbeitung übergeben werden muss.

Die Flexibilität betrifft nicht nur die Einbindung von Schnittstellen anderer Produkte, sondern auch den Grad der Übertragbarkeit (siehe Abschnitt 3.3.8) des Systems.

3.2.5 Modularität

Es ist sinnvoll zuerst den Begriff des Moduls zu definieren, bevor das Konzept der Modularität näher betrachtet wird.

Ein Modul ist eine logische oder physische Einheit mit klar umgrenzter Aufgabe in einem Gesamtzusammenhang, das folgende Bestandteile hat:

- Exportschnittstelle: Ressourcen, die andere Module benutzen können,
- Modulrumpf: Die Realisierung der Aufgabe des Moduls,
- Importschnittstelle: Vom betrachteten Modul benutzte andere Module [Kahlbrandt 2001, S. 75].

Modularität bedeutet die Zerlegung des Gesamtssystems in Module (=Komponenten).

Diese Eigenschaften erlauben übersichtliches und damit sicheres Programmieren und einen leichten Austausch von Programmteilen. Bei der Fehlersuche können einzelne Module ganz isoliert betrachtet werden. Viele Verbesserungen können nachträglich ohne die geringste Änderung in sämtlichen Umgebungs- bzw. Anwendungsprogrammen übernommen werden.

Die Modularität ist also Basis für die Wiederverwendbarkeit (siehe Abschnitt 3.3.10) des Systems.

3.2.6 Erweiterbarkeit

Unter Erweiterbarkeit versteht man die Eigenschaft eines Softwaresystems, die es erlaubt, neue Objekte oder Funktionalitäten einzufügen, ohne es in seinen wesentlichen Eigenschaften verändern zu müssen, insbesondere ohne größere Codeänderungen [Kahlbrandt 2001, S. 58].

Durch diese Eigenschaft kann man das System den zukünftigen Anforderungen entsprechend anpassen, „ohne es in seinen wesentlichen Eigenschaften verändern zu müssen“, wie oben bei der Definition der Erweiterbarkeit schon erwähnt wurde. Das erleichtert die Anpassungsarbeit bzw. macht diese überhaupt möglich.

3.2.7 Wartbarkeit

Unter Wartbarkeit versteht man die Eigenschaft eines Systems, Fehlerursachen mit geringem Aufwand erkennen und beheben zu lassen [Kahlbrandt 2001, S. 59].

Diese Eigenschaft ist eng mit der Erweiterbarkeit verbunden. Das Beheben von Fehlern bzw. das Hinzufügen und Entfernen von Funktionalitäten soll zu jeder Zeit ohne großen Aufwand möglicht sein.

3.2.8 Übertragbarkeit

Die Übertragbarkeit oder Portabilität-Eigenschaft einer Software ist ihre Fähigkeit, von einer Umgebung in eine andere übertragen zu werden. Die Umgebung kann eine organisatorische Umgebung oder die Hardware- bzw. Software-Umgebung sein.

3.2.9 Wiederverwendbarkeit

Wiederverwendbarkeit (Reusability) ist die Anwendung von bereits entwickelten Software-Komponenten in anderen Umgebungen, für die sie ursprünglich nicht geplant waren [Raasch 93, S. 35].

Die Komponenten einer Software sollen als Basis bzw. Weiterentwicklung anderen Problemlösungen dienen.

4 Überblick XML-Verarbeitung

4.1 Einführung

Die Extensible Markup Language (XML) ist ein einfaches, universales Format für den Austausch strukturierter Dokumente, wie zum Beispiel Geschäftsnachrichten. Wie im Abschnitt 1.1 bereits erwähnt wurde, ist die XML-Sprache als Grundlage dieser Arbeit gewählt worden, da zurzeit keine bessere Alternative zur Beschreibung von Geschäftsnachrichten zur Verfügung steht. Da XML eine große Anzahl von Möglichkeiten zur Definition, Überprüfung und Verarbeitung von Geschäftsdokumenten präsentiert, bietet es sich an, damit Softwarelösungen für jede Art von Geschäftsdokument-Verarbeitung, wie zum Beispiel die Transformation der Dokumente in verschiedene Formate, zu realisieren. Neben anderen nützlichen Eigenschaften bietet XML hierfür den Vorteil der Programm- bzw. Plattform-Unabhängigkeit.

In diesem Kapitel soll die Vielfalt der XML-Sprache vorgestellt werden. Dazu werden einige wichtige Merkmale und Einsatzgebiete der Sprache betrachtet, mit Schwerpunkt auf die Transformationen von XML-Dokumenten. Es werden dazu Transformationswerkzeugen wie XSL, XPath und die Abfragesprache XQuery betrachtet sowie ein Überblick über die XML-Verarbeitung in der Java-Programmiersprache vermittelt. Anschließend wird ein Überblick über aktuell auf dem Markt zu findende XML-Softwarelösungen gegeben.

4.1.1 XML als Sprache für das World Wide Web

XML ist von dem World Wide Web Consortium [W3C 2005] offiziell empfohlen worden. XML ist eigentlich eine vereinfache Form der Standard Generalized Markup Language (SGML), eines internationalen Dokumentationsstandards, der seit Anfang der 80er Jahre existiert. Der Hauptgrund für die Entstehung von XML war, dass die SGML-Syntax sehr komplex ist, besonders für das Web. XML ist somit ursprünglich als Alternative zu SGML erstanden.

Während HTML (Hypertext Markup Language) nur die Benutzung von statischen Tags wie z.B. <Head> und <Body> erlaubt, die im HTML-Standard direkt integriert sind, bietet die Sprache XML die Möglichkeit, eigene Markup-Tags zu erstellen, die gemäß den Anwendungsforderungen angepasst werden können. Diese Elemente (Tags) können durch Dokumenttypdefinitionen und Stylesheets angepasst und in verschiedenen XML-Dokumenten verwendet werden.

4.1.2 XML trennt die Daten von ihrer Verarbeitung

Mit der Verwendung von XML bzw. XML-basierten Strukturen hat man die Möglichkeit der Verarbeitung von Daten mit einer Vielzahl von Anwendungen zur Verfügung. Dem Programmierer bleibt die Entscheidung vorbehalten, welche Software er zur Verarbeitung der Daten heranziehen möchte. Mit anderen Worten erlaubt XML die Beschreibung, Manipulation, Darstellung und den Austausch von strukturierten Daten durch geeignete Applikationen.

XML ist ein Textformat, welches es den Menschen erleichtert, die XML-Dokumente und die in ihnen enthaltenen Informationen zu verstehen. Das For- mat macht auch die Informationsverarbeitung unabhängiger von bestimmten technischen Implementierungen, z.B. im Vergleich mit binären Formaten.

4.1.3 XML als Metasprache

XML ist eine „Metasprache“, mit der sich Sprachen für konkrete Anwendungssituationen entwerfen lassen. XML-Dokumente gehören meist zu exakt definierten Dokumenttypen. Diese Dokumenttypen werden für spezielle Bedürfnisse und Anwendungssituationen entworfen. Es lässt sich auch einfach maschinell überprüfen, ob bestimmte Dokumente einem Dokumenttyp oder Schema entsprechen.

4.1.4 Transformation von XML-Dokumenten

XML-Dokumente lassen sich in andere Formate transformieren. Dafür gibt es mittlerweile verschiedene Werkzeuge, wie z.B. die XSLT-Transformationssprache. Es werden Regeln zur Transformation definiert, die dann als XML-Dokument eines Typs, wie XSLT-Dateien, gespeichert werden können. So kann zum Beispiel bei Bedarf ein XML-Dokument in ein HTML-Format (zur Darstellung im World Wide Web) oder in einen anderen XML-Dialekt transformiert werden.

4.2 XML: Informationsaustausch

Ziel dieses Abschnittes ist es, einen kurzen Überblick über Grundlagen der XML-Syntax zu vermitteln und die Eignung der XML-Sprache für den Austausch von Informationen zu zeigen.

Die Elemente eines XML-Dokumentes heißen Tags (ähnlich wie bei HTML). Tags werden von spitzen Klammern umschlossen, wie es in folgender Abbildung ersichtlich ist:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1: Einfache XML-Struktur

In dem Beispiel enthält das Element (Tag) „ Reference“ den Wert „ ABN00347“. Zu jedem sich öffnenden Tag muss es einen abschließenden geben.

Mit XML kann man durch die Definition eigener Markup-Tags eigene Datenmodelle erzeugen.

Tags umschließen Informationseinheiten. Diese Einheiten können z.B. Texte oder andere Tags sein. Tags können auch Attribute enthalten, die eine weitere Möglichkeit zum Ablegen von Information bieten.

Das folgende Beispiel zeigt eine Erweiterung des Tags „ Reference “ von oben stehender Abbildung mit zwei neu definierten Attributen, „ referenceType “ und „ referenceNumber “:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.2: Einfache XML-Struktur mit Attributen

XML-Dokumente sind hierarchisch aufgebaut. Sie besitzen einen einzelnen Wurzelknoten, in dem die anderen Tags hierarchisch eingebettet sind.

Zur Validierung eines XML-Dokumentes werden DTDs (Document Type Definitions) und XML-Schemata benutzt. Bei beiden Möglichkeiten wird die Struktur eines Dokumentes definiert. Ein DTD- bzw. Schema-Validator kann anhand einer DTD überprüfen, ob ein Dokument gültig und syntaktisch korrekt ist. Die Entscheidung für die Benutzung von DTD oder XML-Schema erfolgt gemäß der Problemstellung. Im Folgenden wird ein kurzer Überblick über beide Definitionssprachen gegeben. Eine detaillierte Beschreibung von DTDs und Schemata wäre in diesem Rahmen zu umfangreich, eine kurze Betrachtung dieser Begriffe ist jedoch notwendig.

4.2.1 Dokumenttypdefinitionen (DTD)

Dokumenttypdefinitionen dienen zur Beschreibung von Strukturen der XML-Dokumente. Dabei wird das Zusammenspiel zwischen den Elementen innerhalb des Dokumentes beschrieben. Sie stellen Grammatiken für die Dokumente und ihre Elemente zur Verfügung, mit denen man die Gültigkeit des Dokumentes überprüfen kann.

Wenn ein XML-Dokument gemäß den Syntax-Regeln der XML-Sprache gebildet wurde, dann ist von einem wohlgeformten Dokument die Rede. Sollte das Dokument außerdem gemäß der Regeln seiner zugehörigen DTD definiert worden sein, dann ist es gültig. Eine mögliche DTD-Regel für das obige „ Reference “-Beispiel wird in Abbildung 4.3 gezeigt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3: DTD zum Beispiel von Abbildung 4.2

Mit dem Schlüsselwort „ !ELEMENT“ werden die Elemente (Tags) in DTDs deklariert. Im obigen Beispiel wird ein Element namens „ Reference “ deklariert, welches mindestens ein Element „ type “ enthalten muss. Gleich danach kann eine Beschreibung (description) vorgenommen werden. Die Kardinalität kann an den entsprechenden Symbolen erkannt werden: „ + “ steht für mindestens einmal und „ ? “ für keinmal, einmal oder mehrere Male.

Das Element „ type “ bezieht sich auf zwei Elemente, „ referenceType “ und „ referenceNumber “, deren Wert vom Datentyp „ #PCDATA “ sein muss. PCDATA steht für „ Parsed Character Data “, das heißt, es können nur geparste Zeichendaten als Wert vorkommen. Eine Alternative ist der Datentyp „#CDDATA“, in dem auch Sonderzeichen abgelegt werden können.

4.2.2 XML-Schemata

Eine Alternative gegenüber der Verwendung von DTDs zur Beschreibung von XML-Auszeichnungssprache (Markup-Language) sind XML-Schemata. Da die DTDs recht einfach strukturiert sind, kann man mit ihnen ein Dokument nur grob beschreiben.

XML-Schemata dagegen bieten eine Reihe von Möglichkeiten mehr, die insgesamt eine viel bessere Beschreibung der gewünschten Strukturen anbieten. Zwei dieser vielen Möglichkeiten sind die Benutzung von üblichen Datentypen und die genaue Angabe von Kardinalitäten.

Eine weitere Möglichkeit, die von XML-Schemata angeboten wird, ist die Definition von komplexen Typen. Diese komplexen Typen können dann in verschiedenen Elementtypdeklarationen verwendet werden, was eine viel bessere Unterstützung der Wiederverwendung von Definitionen gegenüber DTDs ist.

Wie schon oben erwähnt wurde, lassen sich XML-Dokumente gegen XML-Schemata validieren, das heißt, auf ihre Gültigkeit prüfen. Um die Unterschiede zwischen DTDs und Schemata klarer zu veranschaulichen, wird im Folgenden eine XML-Schema-Definition, welche der DTD von Abbildung 4.3 entspricht, abgebildet:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.4: XML-Schema zur DTD von Abbildung 4.3

Wie in der oberen Abbildung ersichtlich, ist die Syntax eines XML-Schemas komplexer als die der DTD. Sie ist dennoch nicht schwer zu verstehen und mit dieser Syntax gelingt die Beschreibung derselben XML-Struktur viel genauer.

Das Element „ Reference “ besitzt also einen komplexen Typ, der aus einer Sequenz der Elementtypen „ type “ und „ description “ besteht. Das Schlüsselwort „ sequence “ definiert die Reihenfolge des Eintretens der Elemente. Das Element „ type “ ist selbst ein komplexer Typ und wird durch die Sequenz von Referenztypen (referenceType) und Referenznummern (refernceNumber) beschrieben. Die Referenztypen müssen vom Datentyp „ String“ sein, während die Referenznummern vom Datentyp „ Integer“ sein müssen. Kardinalitätsangaben können in den Attributen minOccurs und maxOccurs abgelegt werden. Beide Attribute besitzen den Default-Wert „1“. Die Angabe maxOccurs=“unbounded“ für das Element „ type “ besagt also, dass beliebig viele Typen aufgeführt werden dürfen, aber mindestens einer, da für minOccurs der Default-Wert gilt. Bei „ description “ wird durch minOccurs=“0“ hingegen festgelegt, dass dieses Element optional ist.

4.3 Die Transformationssprache XSL

Mit der Hilfe von Transformationssprachen wird XML für bestimmte Bedürfnisse besser nutzbar gemacht. Mit diesen Sprachen können XML-Dokumente in verschiedene XML-Dialekte und in andere Datei-Formate transformiert werden. In diesem Abschnitt wird die bekannteste und verbreitetste XML-Transformationssprache vorgestellt, nämlich die Extensible Style Language (XSL). Weiterhin wird auf Xpath eingegangen, eine sehr nützliche Sprache zur Navigation in XML-Dokumenten.

Zunächst wird Xpath kurz vorgestellt, da diese Sprache oft zusammen mit Transformations- und Abfragesprachen benutzt wird.

4.3.1 Xpath

XPath ist eine Empfehlung des Word Wide Web-Konsortiums [W3C 2005] um in XML-Dokumenten zu navigieren. XPath ist nicht entworfen worden, um isoliert benutzt zu werden, sondern wird nur in Verbindung mit anderen Werkzeugen wie XSLT oder XQuery genutzt (siehe folgende Abschnitte). Diese Werkzeuge nutzen XPath als Erweiterung.

Das XPath-Datenmodell betrachtet ein XML-Dokument als einen Baum, der sich aus Knoten unterschiedlicher Typen zusammensetzt. Mit XPath werden die Knoten des Baums lokalisiert und zwischen ihnen navigiert. Die Syntax von XPath hat seinen Ursprung in der Syntax zur Beschreibung von Pfaden in Unix-basierten Dateisystemen.

Bei XPath sind drei Haupt-Fähigkeiten zu unterscheiden: Die Auswahl von Teilstrukturen, die Auswahl von Knotenmengen und die Formulierung von Auswahlbedingungen

Die Auswahl von Knotenmengen und Teilstrukturen erfolgt über so genannte Lokalisierungspfade (Location Paths). XPath definiert absolute (ab Wurzelelement) und relative (zu anderen Elementen) Lokalisierungspfade, die sich an den Navigationsachsen eines Elementes orientieren. Achsen werden von XPath bereitgestellt, damit erfolgt die Auswahl von Teilen eines Baums bezüglich eines bestimmten Knotens, nämlich den Kontextknoten.

Die Abbildung 4.5 zeigt eine Auswahl von möglichen Navigationsachsen eines XPath-Ausdrucks. In diesem Fall ist Self der Kontextknoten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.5: Navigation mit Xpath

Beispiele der Navigation mit Xpath sind:

- Book
- Aus den Kindelementen des Kontextknotens (self) werden die < book> -Elemente ausgewählt.

- book/title
- Wählt die <title> -Elemente aus, die wiederum Kindelemente der <book> -Elemente und diese wiederum Kindelemente des Kontextknotens sind.

- title/@id
- Wählt das id -Attribut der <title> -Elemente aus, die Kindelemente des Kontextknotens sind.

- . . /book
- Wählt die <book> -Elemente aus, die Kindelemente des Elternelements des Kontextknotens sind.

- //book[1]
- Wählt das erste <book>-Element eines Dokumentes.

- //book[@title=’XPath’]
- Wählt das <title> -Element eines Dokumentes, dessen Attribut title die Zeichenkette Xpath als Wert hat.

Außer der Navigation stellt XPath auch eine Reihe von Funktionen zur String- und Zahlverarbeitung zur Verfügung, die das Steuern der Auswahl von Knotenmengen erleichtern. Beispiele dafür sind:

- count(Knotenmenge)
- Liefert die Anzahl der Knoten zurück, die in der angegebenen Knotenmenge enthalten sind.

- concat(String1, String2,…)
- Liefert die Zeichenverkettung aller Argumente zurück.

- String(Object)
- Das Argument Object, das von beliebigem Typ sein kann, wird in eine Zeichenkette (String) umgewandelt.

4.3.2 XSL

XSL (Extensible Style Language) besteht im Wesentlichen aus zwei Sprachen, XSLT und XSL-FO. XSLT ist eine Transformationssprache, während XSL-FO (XSL Formating Objects) eine Formatierungssprache ist. Mit XSL-FO können Formatierungsregeln für die Darstellung von XML-Dokumenten angegeben werden. Diese Regeln können Schriftart, Farbe oder Seitenlayout umfassen. Da die Formatierung mittels XSL nicht das Thema dieser Diplomarbeit ist, beschränkt sich dieser Abschnitt darauf, einen Überblick über die Transformationssprache XSLT zu vermitteln. Außerdem kann XSLT unabhängig von der Formatierungssprache verwendet werden.

Die Fähigkeit von XSLT, Daten aus einer XML-Struktur in eine andere umzuwandeln, macht sie zu einem wichtigen Werkzeug für das XML-basierende E-Commerce, den elektronischen Datenaustausch, den Austausch von Metadaten und für Anwendungen, bei denen verschiedene XML-Repräsentationen mit gleichen Daten umgewandelt werden müssen. Mit der Hilfe von XSLT können XML-Dokumente auch in andere, nicht XML-basierende Strukturen konvertiert werden.

[...]