Einleitung - Universität Paderborn

Universität-Gesamthochschule Paderborn
Diplomarbeit
Austauschformate für die Interoperabilität heterogener, weitverteilter
Workflow-Management-Systeme – Auswahl, Bewertung und
prototypische Implementierung von Formatstandards für Message-
Objekte im Rahmen des Wide Area Group Flow Systems
Prof. Dr. Nastansky
Sommersemester 98
vorgelegt von:
Michael Groß
Wirtschaftsinformatik
Matrikel-Nr.: 3864124
Bödingsheide 22, 33397 Rietberg

Inhaltsverzeichnis
Seite:
1 Einleitung............................................................................................................... 1
1.1 Szenario ................................................................................................................. 1
1.2 Aufgabenstellung................................................................................................... 2
1.3 Aufbau der Arbeit .................................................................................................. 3
2 Grundlagen............................................................................................................. 4
2.1 Einordnung des Workflow-Managements in das Forschungsgebiet „Computer
Support Cooperative Work“ .................................................................................. 4
2.2 Interoperabilität durch Standards als Grundlage für unternehmensübergreifenden
Datenaustausch ...................................................................................................... 7
2.3 Wissenschaftliche und industrielle Ansätze für die Interoperabilität von
Workflow-Management-Systemen...................................................................... 10
2.3.1 Interface 4 der Workflow Management Coalition ......................................... 10
2.3.2 Panta Rhei ...................................................................................................... 13
2.3.3 Workconnector............................................................................................... 16
2.4 Formate für Übertragungscontainer..................................................................... 17
3 Arbeitsumgebung................................................................................................. 21
3.1 Lotus Notes als Entwicklungsplattform............................................................... 21
3.2 Wide Area Groupflow System............................................................................. 25
3.2.1 Konzeption von WAGS ................................................................................. 25
3.2.2 Architektur WAGS......................................................................................... 26
3.2.2.1 Die Komponenten der Workflow-Repository-Schicht .................. 28
3.2.2.2 Struktur eines Message-Objekts .................................................... 32
4 Austauschformate für den Transport von Workflow-Daten................................ 35
I

4.1 Anforderungen an Formate zur Übermittlung von Message-Objekten ............... 35
4.2 Untersuchung vorhandener Formate.................................................................... 39
4.2.1 Rich-Text-Format (RTF)................................................................................ 41
4.2.2 Portable Document Format (PDF) ................................................................. 45
4.2.3 Electronic Data Interchange (EDI) und EDIFACT........................................ 54
4.2.4 Multipurpose Internet Mail Extension (MIME)............................................. 60
4.2.5 Open Document Architecture (ODA) ............................................................ 66
4.2.6 Standard Generalized Markup Language (SGML) ........................................ 71
4.2.7 Hyper Text Markup Language (HTML) ........................................................ 78
4.2.8 Extensible Markup Language (XML)............................................................ 81
4.3 Abschlußbetrachtung und Auswahl geeigneter Formate..................................... 86
5 Konzeption und prototypische Realisierung........................................................ 90
5.1 Konzeption........................................................................................................... 90
5.1.1 Architektur des Konverters ............................................................................ 91
5.1.2 Definition des Austauschformats mit Hilfe der Document Type Definition . 92
5.2 Prototypische Realisierung .................................................................................. 95
5.2.1 Fallbeispiel ..................................................................................................... 95
5.2.2 Behandlung eines ausgehenden Message-Objekts......................................... 95
5.2.3 Annahme und Auswertung eines eingehenden Message-Objekts ............... 101
5.3 Kritische Betrachtung des Prototyps.................................................................. 104
6 Zusammenfassung und Ausblick....................................................................... 106
7 Literaturverzeichnis ........................................................................................... 108
8 Anhang............................................................................................................... 116
8.1 Relevante Internet-Ressourcen .......................................................................... 116
8.2 Message-Objekt-Definition ............................................................................... 117
8.3 Ausgehendes XML-Messageobjekt................................................................... 119
II

Abkürzungsverzeichnis
ANSI American National Standards Institute
ASC Accredited Standards Committee
BOS Back Office System
CSCW Computer Supported Cooperative Work
DIN Deutsches Institut für Normung, Berlin
EDI Electronic Data Interchange
EDIFACT Electronic Data Interchange for Administration Commerce and Transport
EDV Elektronische Datenverarbeitung
E-Mail Electronic Mail
IETF Internet Engineering Task Force
ISO International Organization for Standardization ( internationale Normierungs-
behörde)
ITU International Telecommunication Union (vormals CCITT)
LAN Local Area Network
PDF Portable Document Format
WAGS Wide Area Groupflow System
WAN Wide Area Network
WFMC Workflow Management Coalition
WWW World Wide Web
III

Abbildungsverzeichnis
IV
Seite:
Abbildung 1: Klassifikation von CSCW-Systemen gemäß der zeitlichen und räumlichen
Verteilung [vgl. Teufel 1996, S. 41].............................................................. 5
Abbildung 2: Klassifikation nach Unterstützung [vgl. Teufel 1996 S.41 ............................. 7
Abbildung 3: Workflow Management Coalition Reference Model [WFMC 1994, S.20]. 12
Abbildung 4: System Architektur Panta Rhei [Groiss/Eder 1996, S. 7] ............................. 14
Abbildung 5: Auszug aus einem EDIFACT-Dokument [vgl. Groiss/Eder 1996, S. 5] ...... 15
Abbildung 6: Umsetzung von EDIFACT in HTML [vgl. Groiss/Eder 1996, S. 6] ............ 15
Abbildung 7: Webzugriff auf Panta Rhei [Groiss/Eder 1996, S. 8].................................... 16
Abbildung 8: Steuerinformation des Workconnectors [Wewers/Faisst 1996, S. 174] ...... 17
Abbildung 9: Grundidee von WAGS [Riempp/Nastansky 1996b, S. 197]......................... 26
Abbildung 10: Architektur der WAGS-Umgebung [vgl. Riempp/Nastansky 1997, S. 491]27
Abbildung 11: WAGS-Repository [vgl. Saliger 1998, S. 49]............................................. 29
Abbildung 12: Content Management [Riempp/Nastansky 1996b, S. 202]......................... 31
Abbildung 13: Fluß der Message-Objekte und Aufgabe der Gateway Datenbank
[Riempp/Nastansky 1997, S. 279] ............................................................... 32
Abbildung 14: Struktur eines Message-Objekts [vgl. Riempp/Nastansky 1996b, S.200] .. 33
Abbildung 15: RTF Beispiel ............................................................................................... 42
Abbildung 16: RTF-Felddefinition ..................................................................................... 43
Abbildung 17: Erstellung einer PDF-Datei durch PDF Writer [vgl. Adobe 1996, S. 28] .. 46
Abbildung 18: Umwandlung von Postscript nach PDF [vgl. Adobe 1996, S. 29].............. 47
Abbildung 19: Auszug aus einer PDF-Datei....................................................................... 47
Abbildung 20: PDF-Komponenten [Adobe 1996, 34] ........................................................ 48
Abbildung 21: PDF-File-Struktur [Adobe 1996, 62] .......................................................... 49

Abbildung 22: Struktur eines PDF-Dokuments [vgl. Adobe 1996, S. 72].......................... 50
Abbildung 23: Beispiel EDIFACT-Nachricht [Deutsch 1994, S. 56]................................ 55
Abbildung 24: Struktur einer EDIFACT-Übertragungsdatei [Weid 1994, S. 40] .............. 57
Abbildung 25: Aufbau einer MIME-Nachricht................................................................... 61
Abbildung 26: Beispiel einer MIME-Nachricht [Grand 1993] ........................................... 64
Abbildung 27: Objektspezifikation in ODA [vgl. Appelt 1991, S. 44]............................... 69
Abbildung 28: SGML-konforme DTD Definition .............................................................. 73
Abbildung 29: SGML-Beispiel ........................................................................................... 74
Abbildung 30: SGML-Attribut-Definition.......................................................................... 74
Abbildung 31: Anforderungstabelle.................................................................................... 86
Abbildung 32: Architektur des Konverters ......................................................................... 91
Abbildung 33: Schematische Darstellung der Message-Objekt-Struktur ........................... 92
Abbildung 34: Document Type Definition ......................................................................... 94
Abbildung 35: Fallbeispiel [vgl. Saliger 1998, S. 74]......................................................... 95
Abbildung 36: Message-Objekt vor der XML-Umwandlung ............................................. 97
Abbildung 37: Message-Objekt nach der XML-Umwandlung........................................... 99
Abbildung 38: Darstellung eines XML-Message-Objekts................................................ 100
Abbildung 39: XML-Message-Objekt vor der Umwandlung ........................................... 101
Abbildung 40: Tabelle der XML-Elemente ...................................................................... 102
Abbildung 41: E-Mail-Objekt nach der XML-Konvertierung .......................................... 103
V

Tabellenverzeichnis
VI
Seite:
Tabelle 1: Bewertung des RTF-Formats ............................................................................. 45
Tabelle 2: Bewertung des PDF-Formats ............................................................................. 53
Tabelle 3: Bewertung des EDIFACT-Formats.................................................................... 60
Tabelle 4: Bewertung des MIME-Formats.......................................................................... 66
Tabelle 5: Bewertung des ODA .......................................................................................... 71
Tabelle 6: Bewertung des SGML-Formats.......................................................................... 77
Tabelle 7: Bewertung des HTML-Formats ......................................................................... 80
Tabelle 8: Bewertung des XML-Formats............................................................................ 85
Tabelle 9: Bewertungsübersicht der untersuchten Formate und Definitionssprachen ........ 88

Einleitung Seite 1
1 Einleitung
1.1 Szenario
Die Globalisierung der Märkte, die Reduktion von Produktentwicklungs- und Produktionszeiten
bei Verringerung der Fertigungstiefe und die Intensivierung der Zusammenarbeit
zwischen kooperierenden Unternehmen kennzeichnen die bestehende Wirtschaftssituation.
Eine zunehmende Dezentralisierung der Marktteilnehmer bei steigender Kooperationsdynamik
erfordert neue Formen der Zusammenarbeit. In der Vergangenheit wurden dazu
verschiedene Technologien und Verfahren eingeführt, die von der herkömmlichen Übermittlung
der Daten in Papierform über den Einsatz von Telekommunikationsmitteln (Telex,
Teletext, Fax) bis hin zum Einsatz von vernetzten Systemen (Electronic Data Interchange)
reichten.
Insbesondere im Büroumfeld werden seit Jahren Informationssysteme eingesetzt, die die
Geschäftsprozesse innerhalb der Organisation effizienter gestalten. Dazu gehören Anwen-
dungen aus den Bereichen der Kommunikation (E-Mail, Video-Konferenzsysteme) und
des Workflow-Managements, die die Kommunikation und Kooperation der am Prozeß be-
teiligten Personen unterstützen.
Die Gestaltung von Workflow-Management-Systemen für den Einsatz im lokalen Umfeld
eines Unternehmens war lange Zeit ein Hauptgegenstand der Forschung und führte zur
Entwicklung professioneller Applikationen (IBM Flow Mark, Siemens Nixdorf Workparty,
CSE Workflow etc.). Diese Systeme wurden mit verschiedenen Ansätzen auf unterschiedlichen
Hard- und Softwareplattformen implementiert. Ihr Einsatzbereich endete aber häufig
an den Unternehmensgrenzen. Als Folge der oben beschriebenen zunehmenden Dezentralisierung
und Kooperationsdynamik ergab sich die Anforderung der Marktteilnehmer, Daten
zwischen heterogenen und weitverteilten Workflow-Management-Systemen austauschen
zu können. Dieses Einsatzgebiet ist erst seit kurzer Zeit Gegenstand der Forschung.
Die Herausforderung der neuen Generation von Workflow-Management-Systemen besteht
darin, die bisherigen Begrenzungen zu überwinden, um die Bearbeitung von Geschäftsvorgängen
auch über die Unternehmensgrenzen hinweg zu ermöglichen.

Einleitung Seite 2
Zur Zusammenarbeit verschiedener Systeme bedarf es aber Normen und Standards, die zur
Zeit nur ansatzweise existieren. Die Workflow Management Coalition (WFMC), ein Zusammenschluß
verschiedener Anbieter von Workflow-Management-Systemen, hat sich
u. a. zum Ziel gesetzt, diese Normen und Standards zu entwickeln.
Die Verbindung von Workflow-Management-Systemen beinhaltet verschiedene Aspekte,
die rechtlicher, organisatorischer und technischer Art sein können. Der Fokus dieser Arbeit
liegt auf dem technischen Aspekt, insbesondere auf dem Schwerpunkt des Datenaustauschs
zwischen heterogenen Workflow-Management-Systemen.
1.2 Aufgabenstellung
An der Universität GH Paderborn wurde seit 1992 im Fachbereich Wirtschaftsinformatik II
das Workflow-Management-System Groupflow auf Basis der Groupware Plattform Lotus
Notes entwickelt. Mit Groupflow wird die Möglichkeit eröffnet, vordefinierte Arbeitsabläufe
im Büroumfeld (Workflows) zu modellieren und innerhalb von Local Area Networks
(LANs) durchzuführen. Nach Abschluß der Arbeiten wurde der Prototyp an eine kommerzielle
Firma übergeben, die das Produkt seit 1995 am Markt anbietet.
In den letzten Jahren wurde die Forschung und Weiterentwicklung konsequent in Richtung
der weitverteilten Modellierung und Ausführung von Workflows in Wide Area Networks
(WANs) vorangetrieben.
Die Ergebnisse der Weiterentwicklung mündeten in dem Prototyp Wide Area Groupflow
System (WAGS). Die in WAGS eingesetzten Mechanismen zum Austausch von Daten zwischen
Workflow-Systemen, zur Zeit nur zwischen weitverteiltenWAGS-Systemen reali-
siert, beruhen auf den proprieträren Mechanismen (Compound Documents) von Lotus
Notes.
Im Rahmen der vorliegenden Arbeit wird untersucht, welche Möglichkeiten des Datenaustauschs
auf Basis von Standards existieren und wie sie im Verbund von heterogenen
weitverteilten Workflow-Management-Systemen eingesetzt werden können. Diese Arbeit
fokussiert sich dabei auf die Suche nach einem geeigneten standardisierten Austauschformat,
mit dem die Workflow-Daten in einem Informationscontainer mittels E-Mail zwischen
heterogenen Systemen übertragen werden können. Als Arbeitsumgebung der prototypischen
Entwicklung wird Lotus Notes, die technische Plattform von WAGS, benutzt.

Einleitung Seite 3
1.3 Aufbau der Arbeit
Das nachfolgende Kapitel befaßt sich mit den Grundlagen, die für die Arbeit von Bedeutung
sind. Dazu werden zunächst wichtige Begriffe aus dem Umfeld der Interoperabilität
und der Workflow-Umgebung erläutert und Ansätze für die Verbindung von Workflow-
Systemen aufgezeigt.
In Kapitel 3 wird die zugrundeliegende Arbeitsumgebung Lotus Notes und die Anwendung
Wide Area Groupflow System eingeführt.
Die Anforderungen an ein Austauschformat und die in Frage kommenden Formate werden
in Kapitel 4 definiert und untersucht. Das Kapitel schließt mit einer entsprechenden Empfehlung.
Die letzten Kapitel beschäftigen sich mit der Konzeption und Präsentation des erstellten
Prototyps sowie der Zusammenfassung dieser Arbeit und einem Ausblick.

Grundlagen Seite 4
2 Grundlagen
In diesem Kapitel werden die Grundlagen erarbeitet, die für das Verständnis der Arbeit
notwendig sind. Dazu wird das Themengebiet Workflow-Management eingegrenzt sowie
die benötigten Begriffe eingeführt. Zusätzlich werden die Entwicklungsumgebung Lotus
Notes und die notwendigen zugrundeliegenden Konzepte des Wide Area Groupflow Systems
erklärt.
2.1 Einordnung des Workflow-Managements in das Forschungsgebiet „Computer
Support Cooperative Work“
Der Markt für Bürokommunikationssoftware erlebt zum gegenwärtigen Zeitpunkt einen
erneuten Wachstumsschub. War bis Ende der 80er Jahre die Unterstützung von Einzelfunktionen
(z. B. Tabellenkalkulation, Textverarbeitung) das Ziel der Anstrengungen, so
liegt der Erfolg dieser Systeme gerade in der Unterstützung komplexer Arbeitsabläufe.
Dies zeigt sich besonders auf der Arbeitsplatzebene, wo die verschiedenen am Markt
vorherrschenden Office-Systeme (z. B. „Microsoft Office“, „Lotus Smart Suite“) mit
einer Vielzahl von Funktionen eine integrierte und verzahnte Bearbeitung von Doku-
menten, Planung von Terminen und Aufgaben etc. ermöglichen.
Darüber hinaus werden im Bereich des teamorientierten Arbeitens eine Vielzahl von
Funktionen zur Koordination, Kommunikation und Kooperation von Mitarbeitern eines
Unternehmens angeboten [vgl. Deiters W., S. 30 ff.].
Unter dem Stichwort „Computer Support Cooperative Work“ (CSCW) sind seit Mitte der
achtziger Jahre vielfältige Forschungsanstrengungen unternommen worden, aus denen
sich verschiedene IT-basierte Lösungen (Groupware bzw. CSCW-Applikationen 1 ) entwickelt
haben. Diese unterstützen bzw. ermöglichen erst die effektive Teamarbeit (Gruppenarbeit).
1 Groupware bzw. CSCW-Applikationen sind aus Software und eventuell spezifischer Hardware bestehende Systeme,
durch die Gruppenarbeit unterstützt oder ermöglicht wird [Teufel 1996, S. 22].

Grundlagen Seite 5
Die Ziele der CSCW-Forschung erstrecken sich von der Verbesserung der Zusammenarbeit
von Menschen durch den Einsatz von Informations- und Kommunikationssystemen
bis hin zur Steigerung der Effizienz und Flexibilität [vgl. Hasenkamp/Syring 1994, S.15].
CSCW-Anwendungen integrieren meist mehrere Funktionen zur Unterstützung der
Gruppenarbeit, welche die Klassifikation der einzelnen Systeme sehr schwierig gestalten.
Innerhalb der Gruppen sind die Kommunikationsprozesse die Grundlage jeder Gruppenarbeit.
Sie werden durch die CSCW-Anwendungen mit verschiedenen Techniken unterstützt.
Die Verwendung unterschiedlicher Techniken legt daher die Klassifikation aus
technologischer Sicht nahe [vgl. Teufel 1996, S.23].
Eine mögliche Einteilung der Systeme kann nach dem Kriterium „Überbrückung von
Raum und Zeit“ vorgenommen werden.
asynchron
synchron
Zeit
verteilte
Hypertext-
Systeme
Sitzungs- und
Entscheidungsunterstützungssysteme
Workflow-
Management-
Systeme
elektronische
Postsysteme
spezielle
Datenbanken
Gruppeneditoren
benachbart entfernt
Bulletin Board
-Systeme
Video- bzw.
Desktop-Konferenzen
Raum
Abbildung 1: Klassifikation von CSCW-Systemen gemäß der zeitlichen und
räumlichen Verteilung [vgl. Teufel 1996, S. 41]
Workflow-Management-Systeme lassen sich aufgrund ihrer Merkmale (zeitversetzte,
sequentielle Verarbeitung) in den Bereich der CSCW-Systeme einordnen, die an einem
Ort (benachbart) und zu unterschiedlichen Zeiten (asynchron) die Gruppenarbeit ermöglichen.

Grundlagen Seite 6
Eine weitere Unterteilung dieses Bereiches kann anhand des Strukturierungsgrades der
kooperativen Tätigkeit vorgenommen werden. Dabei steht beim Workflow Management
der Prozeßgedanke der festgelegten, automatisierten Arbeitsabläufe im Vordergrund,
während beim Workgroup Computing der Schwerpunkt in der Unterstützung der Gruppen
bei der Durchführung ihrer Arbeitstätigkeiten liegt. Diese werden meist in Eigenverantwortung
und Selbstorganisation durchgeführt und erlauben somit eine größere Flexibilität.
Es darf aber nicht versucht werden, die Flexibilität und Strukturiertheit unabhängig
voneinander zu betrachten, weil dies an der Realität vorbei zur Entwicklung von
Insellösungen führen könnte. Vielmehr müssen beide Aspekte in die Gestaltung von
CSCW Systemen einfließen [vgl. Hasenkamp/Syring 1994, S. 26 ff].
In diesem Umfeld entstehen, je nach Art der Aufgabe, ähnliche Anwendungen, die sich
durch ihre Zielsetzung unterscheiden. So liegt der Schwerpunkt der Workflow-Management-Systeme
bei der Ausführung von Prozessen, während die Unterstützung von Pro-
jekten hinsichtlich Terminabsprachen, Kalkulationen etc. den Kernpunkt von Projekt-
Management-Systemen bildet. Dokument-Management-Systeme unterstützen ihrerseits
die Bewältigung der Masse an Dokumenten, Tabellen und Grafiken durch den Einsatz
von Dokumenten-Management- und Ablagesystematik, Recherche-Funktionalität und
Zugriffsschutz um eine effiziente Verwaltung der Daten zu ermöglichen [vgl.
Koch/Ziegler 1996, S. 25 ff.].
Zusätzlich zu den Kriterien, die Koch/Ziegler zur Unterscheidung von CSCW-Systemen
definieren, können CSCW-Anwendungen auch noch nach den Aspekten der Kommuni-
kation, Kooperation und Koordination klassifiziert werden. Die Kommunikationskomponente
beinhaltet dabei sowohl die Informationsverteilung als auch die fortlaufende Kommunikation
der Gruppenmitglieder untereinander. Mit der Kooperationsfähigkeit wird in
diesem Zusammenhang die Fähigkeit und Bereitschaft zur Zusammenarbeit und zur Unterordnung
in das Team verstanden. Diese soll zum Erreichen der Ziele führen. Um diese
Ziele schnell und effizient zu erreichen, benötigt die Gruppe die Koordination der Gruppenmitglieder.
Je nach Gewichtung der Kriterien können die verschiedenen CSCW-Anwendungen positioniert
und zu Systemklassen zusammengefaßt werden. In der Systemklasse des Workgroup-Computing
liegt der Schwerpunkt auf der Kooperationsunterstützung, in der

Grundlagen Seite 7
Workflow-Management-Klasse dagegen auf der Koordination- und Kommunikationsunterstützung.
Koordinationsunterstützung
Workflow-
Management-
Werkzeuge
spez.
Datenbanken
Kommunikationsunterstützung
E-Mail
Planungssysteme
Videokonferenzsysteme
Bulletin
Board-
Systeme
verteilte
Hypertext-
Systeme
EntscheidungsundSitzungsunterstützungs-
Systeme
Gruppen-
Editoren
Systemklasse
Kommunikation
Workflow Management
Workgroup Computing
Kooperationsunterstützung
Abbildung 2: Klassifikation nach Unterstützung [vgl. Teufel 1996 S.41
Mit diesen zwei Klassifikationsschemata wird sowohl die Positionierung der Workflow-
Management-Systeme innerhalb der CSCW-Forschung als auch die Abgrenzung zu anderen
Anwendungen gezeigt. Für die weitere Auseinandersetzung mit diesem Thema, das
den Rahmen dieser Arbeit sprengen würde, sei auf weiterführende Literatur [Hasenkamp
et al. 1994], [Coleman/Khanna, 1996] hingewiesen.
2.2 Interoperabilität durch Standards als Grundlage für unternehmensübergreifenden
Datenaustausch
Die Informationstechnologie und die daraus resultierende Kombination von Hard- und
Software, die sich in den letzten Jahrzehnten rasant entwickelt hat, bildet heute die
Grundlage für den Austausch von Unternehmensdaten. Dabei spielt es nur noch eine un-

Grundlagen Seite 8
tergeordnete Rolle, ob die Systeme innerhalb einer Organisation an einem Standort oder
in verschiedenen Organisationen an verschiedenen Standorten plaziert sind.
Ein wichtiger Gesichtspunkt der Interoperabilität ist das Streben nach Kompatibilität. Die
Forderungen reichen dabei von flexibler Konfiguration der Rechnersysteme über die Definition
von einheitlichen Entwicklungsumgebungen bis hin zum Austausch von Programmen
und Daten.
Die zunehmende Vernetzung der Systeme und die grenz- und branchenüberschreitenden
Anwendungen sind die vorrangigen Ziele der Bemühungen um die Interoperabilität der
verteilten Anwendungen [vgl. Rechenberg/Pomberger 1997, S. 907].
Interoperabilität bedeutet dabei die Fähigkeit zweier oder mehrerer Systeme (Computer,
Datenbanken, Netzwerke, Software und andere Informationstechnologien), miteinander
zu arbeiten und Daten auf Basis von festgelegten Methoden auszutauschen. [vgl. Nolan
1998]
Die Interoperabilität der Systeme wird durch die Verwendung von Standards ermöglicht.
Ein Standard ist eine Sammlung von Vereinbarungen (Schnittstellen, Protokolle). Nur
durch die Einhaltung der Vereinbarungen können unterschiedliche Systeme die auszutauschenden
Daten interpretieren und verarbeiten.
Ein weiteres Ziel der Verwendung von Standards ist die Erhaltung von möglichst vielen
Freiheitsgraden bei zukünftigen Entscheidungen. Dabei stehen wichtige Schnittstellen
zwischen den Komponenten nicht mehr unter der Kontrolle eines einzelnen Anbieters
[vgl. Hansen 1992, S 402].
Die Standards werden in unabhängigen Gremien (Normungsausschüsse oder herstellerübergreifende
Konsortien) definiert und verabschiedet. Um einen Standard zu erstellen,
müssen die notwendigen Schnittstellen, Protokolle, Formate und Verfahren auf Grundlage
von übereinstimmenden technischen Spezifikationen formuliert werden [vgl. Rechenberg/Pomberger
1997, S. 907].
Neben den unabhängigen Standards existieren noch die sog. Marktstandards oder Industriestandards.
Sie erlangen diesen Status dadurch, daß sie sehr weit im Markt verbreitet
sind entweder aufgrund mangelnder Normen/Standards oder der marktbeherrschenden

Grundlagen Seite 9
Stellungen der Hersteller. Als Beispiel können dabei die Firmen IBM und Microsoft angeführt
werden.
In der letzten Zeit ist aber die Tendenz festzustellen, daß auch diese Unternehmen dazu
übergehen, ihre Vorstellungen über unabhängige Gremien als Standards zu etablieren
[vgl. Rechenberg/Pomberger 1997, S. 911].
Die Entwicklung neuer und die Überarbeitung bestehender Standards erfolgt in folgenden
Gremien [vgl. Rechenberg/Pomberger 1997, S. 907 ff]:
• Normungsausschüsse
Die Normung ist auf regionaler, nationaler und internationaler Ebene organisiert. Auf
internationaler Ebene sind die folgenden Organisationen tätig:
- ISO, International Organization for Standardization, Genf
- IEC, International Electrotechnical Commission, Genf
- ITU-TS, International Telecommunication Union – Telecommunication Standar-
dization Sector, Genf.
Auf regionaler Ebene in folgenden europäischen Gremien:
- CEN, Comité Européen de Normalisation, Brüssel
- CENELEC, Comité Européen de Normalisation Electrotechnique, Brüssel
- ETSI, European Telecommunications Standards Institute, Nizza
und auf nationaler Ebene, am Beispiel Deutschlands:
- DIN Deutsches Institut für Normung
• Konsortien
Sie bestehen aus konkurrierenden Unternehmen, die über die freiwillige Mitarbeit in
diesen Arbeitsgruppen die Kompatibilität bzw. Interoperabilität ihrer Produkte sicherstellen
wollen. Die Arbeit wird projektorientiert organisiert, um die Spezifikationen
möglichst kurzfristig zu entwickeln und abzustimmen. Die Mitglieder verpflichten
sich, die notwendigen Ressourcen zur Verfügung zu stellen. Normalerweise bestehen
zwischen den Konsortien und Normungsgremien enge Verbindungen, die eine Überführung
der Ergebnisse in eine Norm erleichtern.

Grundlagen Seite 10
• Workshops
Grundlage von Workshops ist, gleich den Konsortien, die Orientierung an konkreten
Projekten. Allerdings sind sie, was die Mitwirkung anbetrifft, offener gestaltet. Die
Entwicklung von OSI-Normen wird z. B. von regionalen Workshops durchgeführt. In
Europa ist dafür die EWOS (European Workshop for Open Systems) gegründet worden.
• Branchen und Berufsverbände
Die Gremien der Branchen und Berufsverbände bestehen aus Personen, die aus individueller
Motivation, aufgrund ihrer Betriebszugehörigkeit und -erfahrung Spezifikationen
für die industrielle Anwendung neuer Techniken entwickeln wollen. Als Beispiele
können die IEEE (Institute of Electric and Elektronic Engineers) sowie die
mittlerweile weitaus bekanntere IETF 2 (Internet Engineering Task Force) genannt
werden.
2.3 Wissenschaftliche und industrielle Ansätze für die Interoperabilität von
Workflow-Management-Systemen
Im folgenden Abschnitt werden unterschiedliche Ansätze für die Interoperabilität von
heterogenen Workflow-Systemen vorgestellt und kurz erläutert. Der Schwerpunkt der
Untersuchung anderer Ansätze liegt im Bereich des Datenaustauschs.
2.3.1 Interface 4 der Workflow Management Coalition
Die Workflow Management Coalition (WFMC) wurde im Jahre 1993 gegründet. Ihr ge-
hören führende Hersteller von Workflow-Management-Systemen (IBM, Microsoft,
Staffware),
Systemen an.
Beratungsunternehmen und Anwender von Workflow-Management-
Die Ziele der WFMC sind
• die Verbreitung von Workflow-Management-Systemen zu fördern,
2 Die IETF definiert die Standards, die für das Internet gelten. Sie wird vom Internet Architecture Board (IAB) beauf-
sichtigt.

Grundlagen Seite 11
• die Entwicklung von Standards für die Terminologie des Workflow-Managements
im allgemeinen,
• die Spezifikation und die Etablierung von Schnittstellen von Workflow-
Management-Systemen.
Die WFMC hat ein Referenz-Modell (siehe Abbildung 3) entwickelt, das die Definition
von fünf Schnittstellen (engl. interfaces) beinhaltet. Mit dem Referenz-Modell wird ein
Rahmen geschaffen, in dem die Zusammenarbeit der verschiedenen Systemkomponenten
geregelt wird.
Durch die „Process Definition Tools“ (dt. Modellierungswerkzeuge) können die Geschäftsprozesse
analysiert und definiert werden. Diese Definitionen sollten in einem stan-
dardisierten Format abgelegt werden, so daß sie zur Laufzeit abgerufen werden können.
Zur Zeit existiert noch kein standardisiertes Format, was somit die Verwendung von unterschiedlichen
Produkten verschiedener Hersteller noch behindert.
Die modellierten Prozeßdaten werden von einer oder mehreren „Workflow-Enactment-
Services“ (dt. Workflow-Laufzeitumgebungen) zur Laufzeit ausgewertet und ausgeführt.
Die Kommunikation der Benutzer mit der Laufzeitumgebung erfolgt über die
„Workflow-Client-Applications“ (dt. Workflow-Client-Applikationen). Dazu können
begleitend „Invoked Applications“ (dt. Aufrufbare Applikationen) eingebunden werden,
die Bearbeitungsschritte teilweise oder ganz selbständig durchführen können oder den
Benutzer unterstützen.
Die „Administration & Monitoring“ Tools (dt. Administrations- und Überwachungswerkzeuge)
bieten vielfältige Möglichkeiten die Workflows zu kontrollieren und auszuwerten.

Grundlagen Seite 12
Administration &
Monitoring Tools
Interface 5
Workflow Client
Applications
Process Definition
Tools
Interface 1
Workflow API and Interchange format
Workflow
Engine(s)
Workflow Enactment Service
Interface 2 Interface 3
Invoked Applications
Interface 4
Workflow
Engine(s)
Other Workflow
Enactment Service(s)
Abbildung 3: Workflow Management Coalition Reference Model
[WFMC 1994, S.20]
Mit dem Interface 4 wurde eine abstrakte Schnittstelle konzipiert, die einen Rahmen für
die Interoperabilität von Laufzeitumgebungen schaffen soll. Das Ziel der Spezifikation
ist, den Herstellern von WFMS eine Experimentierbasis zur Verfügung zu stellen. Die in
diesem Umfeld gemachten Erfahrungen sollen über Rückmeldungen an die Arbeitsgruppen
in den zukünftigen Standard einfließen.
Die Workflow Management Coalition definiert die Interoperabilität von Workflow-
Management-Systemen wie folgt:
“the ability of two or more workflow engines to communicate and interoperate
in order to coordinate and execute workflow process instances across
those engines.”[WFMC 1996, S. 6]
Im Interface 4 werden zwei Möglichkeiten definiert , wie die unterschiedlichen Systeme
zusammenarbeiten können.
a) Die synchrone Zusammenarbeit, d.h. die Workflow-Systeme A und B kommunizieren
über Techniken (COM/CORBA), die eine zeitgleiche Verarbeitung
ermöglichen.
b) Die asynchrone Kommunikation, d. h. die Workflow-Systeme nutzen Technologien
(z.B. E-Mail), die ein zeitversetztes Arbeiten erlauben.

Grundlagen Seite 13
Die Wahl der Zusammenarbeit hängt natürlich von den Parametern der Umgebung ab,
wie z.B. unterschiedliche Standorte oder rechtlich getrennte Unternehmen.
Die Spezifikation des Interface 4 umfaßt eine Sammlung von Befehlen („Request” und
„Answer”), die mit verschiedenen Attributen erweitert werden können. Dadurch können
Instanzen von Workflows in anderen Systemen verwaltet werden (Starten, Stoppen, Beenden,
Informationen einholen) und die Prozeßdaten eines Workflows übertragen werden.
Um die Funktionalität der abstrakten Definition zu demonstrieren, wurde die Spezifikation
mit Hilfe des Multipurpose Internet Mail Extension-Formats (MIME)[s. 4.2.4] implementiert.
Eine Reihe von Herstellern von Workflow-Management-Systemen hat die
Funktionalität des Interface 4 im Rahmen einer Messe bereits demonstriert
2.3.2 Panta Rhei
Das Workflow-Management-System Panta Rhei (von Heraklit: „alles fließt“) wurde an
der Universität Klagenfurt von Prof. J. Eder und Dr. H. Groiss entwickelt. Der Ansatz der
Lösung ist, daß die typische Kommunikation zwischen Unternehmen durch Austausch
von Dokumenten erfolgt (Formularfluß-Metapher). Für die Kooperation zwischen den
Unternehmen werden Formulare weitergeleitet, die für den Geschäftsprozeß notwendige
Daten enthalten [vgl. Groiss/Eder, 1996, S. 2].
Dazu werden normierte und strukturierte Dokumente (UN/EDIFACT, s. 4.2.3) eingesetzt,
wodurch ein hoher Grad an Interoperabilität erreicht werden kann [vgl. Groiss/Eder, 1996
S. 4].
Das Projekt stützt sich dabei auf Mechanismen, die das Internet bereitstellt. Die
UN/EDIFACT-Dokumente werden in HTML-Formulare konvertiert und über das Hyper-
Text-Transfer-Protokoll (HTTP) oder per E-Mail zwischen den Workflow-Systemen ausgetauscht
(siehe Abbildung 4).

Grundlagen Seite 14
Abbildung 4: System Architektur Panta Rhei [Groiss/Eder 1996, S. 7]
Die Interaktion zwischen den Partnern mit Hilfe von Formularen kann auf zwei Wegen
erfolgen. Ist das Ziel ein E-Mail Empfänger, so wird das komplette HTML-Formular zum
Empfänger übertragen und kann dort mit geeigneten Programmen (z. B. Browsern) bearbeitet
und zurückgesendet werden. Wird das Formular direkt an eine Workflow-Engine
gesendet, so werden nur die Formulardaten übertragen. Der empfangende Server überprüft
in diesem Fall anhand der EDIFACT-ID, ob das Formular bekannt ist und welche
Aktionen sich daraus ableiten (z. B. Starten eines Workflows). Unbekannte Formulartypen
werden einem Posteingangsbearbeiter zugewiesen. Die Voraussetzung für diese Art
der Zusammenarbeit ist die Übereinstimmung der Formularstrukturen auf beiden Seiten
[vgl. Groiss/Eder, 1996, S 4 ff.].
Bei der Umsetzung des EDIFACT-Standards wird nur die Struktur der Dokumente übernommen,
jedoch eine andere Syntax verwendet. Somit bleibt die Repräsentation mittels
HTML jedem Workflow-System selbst überlassen, z. B. Benennung der Felder, Beschriftung
und Erläuterung der Felder.
Das folgende Beispiel zeigt ansatzweise eine Umsetzung der EDIFACT-Struktur in ein
HTML-Dokument.

Grundlagen Seite 15
Segmente Erklärung
UNH+data‘
AAA+data‘
BBB:1+data‘ Item 1 von BBB
BBB:2+data‘ Item 2 von BBB
Abbildung 5: Auszug aus einem EDIFACT-Dokument
[vgl. Groiss/Eder 1996, S. 5]
EDIFACT-Dokumente bestehen aus einer Reihe vordefinierter Segmente. Diese Segmente
bestehen aus einem TAG – dem Namen des Segments – und den dazugehörigen
Daten. Diese werden durch + und ´ umschlossen, z. B. sind in Abbildung 5 AAA und BBB
Datensegmente.
.
.
.
.
UNH:
AAA:
BBB:
.
.
Abbildung 6: Umsetzung von EDIFACT in HTML [vgl. Groiss/Eder 1996, S. 6]
Die Verwendung des EDIFACT-Standards beschränkt die Zusammenarbeit der
Workflow-Systeme auf die vorhandenen, definierten Formulare. Darüber hinaus ist der
Informationsfluß nur möglich, wenn beide Seiten innerhalb der EDIFACT-Norm eigene
Formulare entwickeln.
Das System verfügt über einen Zugang per Webbrowser, um sich Informationen über den
Status der Workflows zu verschaffen.

Grundlagen Seite 16
Abbildung 7: Webzugriff auf Panta Rhei [Groiss/Eder 1996, S. 8]
Die Erstellung und Steuerung von Workflows erfolgt mit einer Beschreibungssprache;
ein Austausch dieser Beschreibungen ist nicht vorgesehen.
2.3.3 Workconnector
Der Workconnector wurde im Rahmen eines Projekts im Bereich der Abfallentsorgung
von Thorsten Wewers und Christoph Wargitsch [vgl. Wewers/Wargitsch 1998] entwi-
ckelt. Dem Projekt liegt der Arbeitsprozeß zwischen Kunden, Entsorgungsunternehmen
(Sonderabfall Entsorgung Franken, SEF, Gesellschaft zur Entsorgung von Sondermüll in
Bayern, GSB) und dem Landesamt für Umweltschutz (LFU) zugrunde. Die Kunden, die
ihren Abfall entsorgen wollen, füllen entsprechende Formulare aus und senden sie an die
Versorgungsunternehmen. Diese überprüfen die Formulare auf Vollständigkeit und klären
zusätzliche Fragen direkt mit den Kunden. Die vollständig ausgefüllten Formulare
werden dann dem LFU vorgelegt, das die notwendigen Genehmigungen erteilt.
Um diesen Prozeß elektronisch abzubilden, werden unterschiedliche Produkte eingesetzt.
Seitens der SEF wurde ein Workflow-Management-System mit Hilfe von Lotus Notes
4.5 realisiert. Die LFU hat bereits das Produkt Business Flow des Herstellers COI GmbH
(Herzogenaurach) im Einsatz, das um die notwendige Funktionalität erweitert wurde. Mit

Grundlagen Seite 17
Hilfe des Workconnectors werden die unterschiedlichen Workflow-Systeme auf Basis
eines E-Mail-Servers verbunden. Alle am Prozeß beteiligten Systeme erhalten einen eigenen
Workconnector.
Die Daten der Vorgänge werden in Arbeitsmappen organisiert. Verläßt eine Arbeitsmappe
die interne Arbeitsumgebung, so wird sie über den Workconnector mittels E-Mail versendet.
Die E-Mail besteht aus einem Steuerungsteil (siehe Abbildung 8) und den aktuellen
Daten. Über das Format in dem die Daten der Arbeitsmappen übertragen werden,
wird innerhalb der Publikationen [vgl. Wewers/Wargitsch 1998, S. 6] keine Aussage gemacht.
StartofMail
NameofProcess: ena_LFU
Request: start
Mode: NIL
Parameter NIL
ReplyAdress blfow@coi.ina.de
Abbildung 8: Steuerinformation des Workconnectors
[Wewers/Faisst 1996, S. 174]
Die Funktionen der Steuerungsmail umfassen das Starten eines Workflows, die
Abschlußbenachrichtigung sowie die Aktivitäten-Synchronisation. Das Format der Steuerungsinformationen
ist zur Zeit noch proprietär, es soll jedoch in die Spezifikation der
Workflow Management Coalition überführt werden. [vgl. Wewers/Wargitsch 1998, S. 6].
2.4 Formate für Übertragungscontainer
Seit der Entstehung der Datenverarbeitung und mit dem Beginn der Datenspeicherung
werden Formate eingesetzt. Dabei hat das Wort Format mehrere Bedeutungen.
Eine Bedeutung kommt aus dem Bereich der Dokumentengestaltung. Das Format eines
Dokuments, z. B. Geschäftsbrief, Broschüre, beinhaltet die Seitengröße, die Randeinstellungen,
das Format eines Absatzes, den Zeilenabstand, den Abstand zum Vor- und
Nachabsatz, die Ausrichtung des Absatzes (z. B. Blocksatz). Das Format von Zeichen
kann die Größe, Schriftart etc. umfassen.

Grundlagen Seite 18
Eine andere Definition von Format wird von Hansen in Verbindung mit Daten vorgenommen:
„Im EDV-Vokabular werden als Daten 3 oft nur jene Angaben bezeichnet,
die in einem für die maschinelle Interpretation besonders geeigneten,
festvereinbarten Aufbau aufgezeichnet sind. Solche Daten bezeichnet man
als formatierte Daten“ [vgl. Hansen 1992, S. 14].
Im Rahmen dieser Diplomarbeit wird ein Format als der strukturierte Aufbau von Daten
definiert. Diese Daten können in verschiedener Art und Weise gespeichert, gelesen oder
übertragen werden. Mit dem Format werden die Syntax (Ordnung von Zeichen und Zeichenkombinationen)
und die Semantik (Bedeutung und Inhalt der Zeichenfolge) festgelegt.
Im Bereich der Datenverarbeitung existieren verschiedene Ebenen, die unterschiedliche
Formate benötigen.
Die physikalische Ebene, z. B. das Speichern von Dateien auf Festplatte, erfordert ein
physikalisches Format (Definition von Spannungen), um die Daten in Form von Bits auf
die Festplatte schreiben zu können.
Auf der logischen Ebene, z. B. Dateiebene, werden Formate benötigt, um die Daten einer
Anwendung (Textverarbeitung, Datenbanken, Bildbearbeitung) in der für die Anwendung
notwendigen Art und Weise speichern zu können.
Aufgrund der Vielzahl von Anwendungen und der Notwendigkeit unterschiedliche Anforderungen
zu erfüllen, haben sich im Laufe der Zeit eine Vielzahl von verschiedenen
Formaten herauskristallisiert.
• Formate für Dokumente
Im Bereich der Dokumente, die neben Text, Gestaltungsinformationen (Formatierung),
Grafiken, bewegte Bilder und Audioinformationen enthalten können, sind
zur Zeit nur wenige genormte Standardformate definiert. An erster Stelle sind dabei
die Structured General Markup Language (SGML, DIN EN 28879) und die
3 Daten stellen Informationen (d.h. Angaben über Sachverhalte und Vorgänge) aufgrund bekannter oder unterstellter
Abmachungen in einer maschinell verarbeitbaren Form dar [vgl. Hansen, 1992, S.13].

Grundlagen Seite 19
Open Document Architecture (ODA, DIN ISO 8613) zu nennen. Eine weitere
Implementierung, die im Internet eine sehr starke Verbreitung erfahren hat, ist die
Hyper Text Markup Language (HTML).
Im Zusammenhang mit Textverarbeitungsprogrammen haben verschiedene Softwarehersteller
eigene Spezifikationen für die Darstellung und den Austausch von
formatiertem Text entwickelt. Beispiele dafür sind das Portable Document Format
(Adobe) und das Rich-Text-Format (Microsoft).
Ein weitverbreiteter genormter Standard für den Austausch von Geschäftsdokumenten
ist UN/EDIFACT. Dabei werden vordefinierte Dokumentstrukturen
verwendet, um Geschäftsdaten zwischen Unternehmen auszutauschen.
• Zeichensätze
Im Gegensatz zu den Dokumentformaten hat hier eine frühzeitige Normung stattgefunden.
Im Großrechnerbereich wird der EBCDIC-Zeichensatz und im Personal
Computer Umfeld der ASCII-Zeichensatz eingesetzt. Auf der Basis dieser beiden
Zeichensätze werden eine Großzahl weiterer Formate (HTML, SGML) realisiert.
• Multimediaformate
Seit der Einführung des Personal Computers (PC) als Arbeitsmittel und der Entwicklung
grafischer Benutzeroberflächen (Windows, OS/2, Macintosh) mit mul-
timedialen Funktionalitäten (Audio, Video) haben sich verschiedene Standards im
Bereich der Multimediaformate entwickelt. Dabei handelt es sich in den meisten
Fällen um herstellerspezifische Formate mit unterschiedlichem Verbreitungsgrad.
Für die Darstellung von Bildern seien als Beispiel JPEG (Joint Photographic Experts
Group) und TIFF (Tagged Image File Format), für Video und Audio MPEG
(Motion Picture Expert Group) sowie Microsoft’s AVI (Audio Visual Interface)
angeführt.
Die Daten, die das Ergebnis der Arbeit mit Programmen sind, benötigen Informationscontainer
als Zwischenspeicher. Dadurch wird die Wiederverwendung der Daten gesichert.
Als Informationscontainer können physikalische Objekte (Datei auf Festplatte)
oder Datenströme (Übertragung von Daten zwischen Sende- und Empfangsanwendung)
genutzt werden

Grundlagen Seite 20
Ist das Designziel des Formats die Weitergabe oder Übertragung von Daten über die
Systemgrenzen hinaus, so spricht man von einem Austauschformat.
Die Aufgabe dieser Diplomarbeit besteht darin, ein Austauschformat zu finden, mit dem
Informationen zwischen heterogenen Workflow-Systemen optimal übertragen werden
können. Ausgangsbasis ist das Message-Objekt, das auf Basis der proprietären Lotus
Notes Compound Document-Struktur beruht und mit dem bisher die Weitverkehrskommunikation
zwischen den homogenen Workflow-Management-Systemen WAGS reali-
siert ist

Arbeitsumgebung Seite 21
3 Arbeitsumgebung
Im folgenden Kapitel werden die zugrundeliegende Arbeitsumgebung Lotus Notes und der
damit realisierte WAGS-Prototyp vorgestellt und näher erläutert.
3.1 Lotus Notes als Entwicklungsplattform
Die Realisierung des WAGS-Prototyps und des Prototyps dieser Arbeit erfolgte auf der
Basis des Programms Lotus Notes 4.6, das aufgrund seiner Architekturmerkmale besonders
als Plattform für Groupwareanwendungen geeignet ist [vgl. Nastansky et al. 1995, S. 279].
Die Anforderungen an eine solche Plattform sind:
• verteilte Datenbanken,
• Dokumentenbearbeitung mit Compound Document und natürlichen Datentypen,
• integrierte Gruppenkommunikation,
• Text- und Dokumentenmanagement,
• Import- und Export von Daten,
• Elektronic Mail (E-Mail),
• Sicherheitskonzepte,
• Entwicklungsumgebung.
Nachfolgend werden die für diese Diplomarbeit wichtigen Merkmale erläutert.
Zum Zeitpunkt der Entwicklung lag Lotus Notes in der Version 4.6a vor. Das Programm
wurde als Client-Server-Applikation 4 konzipiert. Lotus Notes ist für alle gängigen Betriebssystemplattformen
(Windows NT/95, Novell, OS/2, Unix, MVS) sowohl in der Server-
als auch Client-Version verfügbar, so daß eine durchgängige Realisierung von
Groupware-Anwendungen in heterogenen Umgebungen erfolgen kann. Dies ist besonders
4
Man versteht darunter eine Architektur, bei der eine EDV-Anwendung einen benutzernahen Teil (Client, Frontend), der
auf dem Endsystem des Benutzers abläuft, und einen von allen Benutzern gemeinsam genutzten Teil (Server, Backend)
aufgeteilt ist.

Arbeitsumgebung Seite 22
in Großunternehmen wichtig, die aufgrund von historischen Entwicklungen i. d. R. über
mehr als eine Betriebssystem-Plattform verfügen.
Verteilte Datenhaltung
Die Informationsspeicherung erfolgt in replizierbaren, verteilten, dokumentorientierten
Datenbanken, die auf Server oder auch auf lokalen Rechnern (Standgeräte, Notebooks)
abgelegt werden können.
Compound Document
Innerhalb der Datenbanken werden die Informationen mittels Compound Documents (Dokumente)
gespeichert und verwaltet. Sie stellen eine proprietäre Rahmenstruktur zur Verfügung,
in der unstrukturierte und strukturierte Informationen in Datenfeldern abgelegt
werden können.
Die Datentypen reichen dabei von einfachen Typen, wie z. B. Text, Zahlen, Datum, bis hin
zum komplexen Datentyp Rich-Text. Der Inhalt eines Rich-Text-Felds kann deshalb for-
matierter Text, Sprachannotationen, Videosequenzen und Dateianhänge sein.
In der internen Struktur stellen Compound Documents objektorientierte Technologien zur
Verfügung, welche die Realisierung von intelligenten Dokumenten zulassen und offen sind
für die Integration objektorientierter (Fremd-)Applikationen [vgl. Nastansky et al. 1995, S.
281].
Sicherheitssystem
Die Forderung nach einem leistungsfähigen Sicherheitskonzept trägt Lotus Notes Rechnung,
indem es eine große Anzahl von Sicherheitsmechanismen auf verschiedenen Ebenen
bereithält. Diese reichen von einem hierarchischem Zugriffssystem über Authentizitätskontrollen
und elektronischen Unterschriften bis hin zur Verschlüsselung von Daten nach
dem standardisierten RSA 5 -Verfahren.
5
Der RSA-Standard wurde nach seinen Erfindern Ron Rivest, Adi Shamir und Leonard Adleman benannt und arbeitet
mit einem Zwei-Schlüssel-Verfahren, bei dem ein öffentlicher Schlüssel (Public Key) allen bekannt ist. Mit Hilfe dieses
Public Keys werden die Daten verschlüsselt und können nur mit dem privaten Schlüssel (Privat Key) wieder entschlüsselt
werden.

Arbeitsumgebung Seite 23
Die Zugriffe auf Lotus Notes-Dokumente können auf folgenden Ebenen kontrolliert werden:
• Serverebene
Es können nur Personen auf den Server zugreifen, die dafür auch zertifiziert wurden.
Das Zertifikat wird in der Benutzer-ID des Anwenders fest verankert.
• Datenbankebene
Der Zugriff auf Datenbanken wird über sog. Zugriffskontroll-Listen geschützt. Nur
eingetragene Benutzer, mit entsprechenden Rechten, können auf die Datenbank zugreifen.
Dabei lassen sich zwischen verschiedenen Zugriffsstufen unterscheiden, mit denen
festgelegt wird, welche Rechte der Benutzer hat und welche Aktionen er ausführen
darf.
• Dokumentebene
Auf Dokumentenebene kann festgelegt werden, welche Aktionen ein Benutzer mit dem
Dokument ausführen darf (Öffnen, Lesen, Verändern). Dabei können Rechte auf Da-
tenbankebene überschrieben werden.
• Feldebene
Mit Hilfe der Zugriffslisten kann auf Feldebene bestimmt werden, welcher Benutzer
die Felder lesen oder bearbeiten kann. Zusätzlich besteht die Möglichkeit, einzelne
Felder zu verschlüsseln und die Entschlüsselung der Felder nur einem bestimmten Personenkreis
zur Verfügung zu stellen.
E-Mail Unterstützung
Lotus Notes Mail unterstützt die Kommunikation der Anwender untereinander durch den
elektronischen Transport von Dokumenten zwischen Notes Anwendern. Die Dokumente
können dabei alle Datentypen enthalten. Zusätzlich können die Dokumente mit elektronischen
Unterschriften versehen und verschlüsselt versendet werden.
Es ist zusätzlich möglich, Nachrichten mit Hilfe von Message Transfer Agents an Empfänger
außerhalb der Lotus Notes Umgebung zu versenden. Unterstützt werden z. B. Simple
Message Transfer Protokoll (SMTP) für den Mailaustausch im Internet, X.400 für die
Kommunikation zwischen OSI-Mailsystemen und CC-Mail.

Arbeitsumgebung Seite 24
Replikationsmechanismus
Eine Basisfunktionalität in Lotus Notes ist die Replikation von Datenbeständen. Erst dadurch
wird es möglich, Informationen auf verschiedene Standorte zu verteilen und zu synchronisieren.
Als Kommunikationskanäle stehen dabei LAN, WAN und andere Verbindungen
(ISDN, Modem) zur Verfügung.
Es können beliebig viele Kopien (Repliken) einer Datenbank erstellt werden. Jeder dieser
Datenbanken erhält zu Identifikationszwecken eine eindeutige Replikations-ID. Während
des Replikationsprozesses (Synchronisation der Datenbestände) werden lediglich die Änderungen
ausgetauscht. Dabei kann die Synchronisation sowohl auf Dokumentebene als
auch auf Feldebene erfolgen. Die Replikation umfaßt nicht nur den Datenabgleich, sondern
auch die zusätzlich in der Datenbank eingebetteten Funktionalitäten (Masken, Program-
mierung). Somit ist es möglich, Anwendungen über mehrere Standorte hinweg zu synchronisieren.
Client Funktionalität
Die Präsentation der Compound Documents kann seitens der Clients mit Hilfe von Forms
(Formulare, Masken) erfolgen. Dabei können beliebige Datenfelder aus den Dokumenten
in vielfältiger Weise in den Masken angeordnet werden. Es ist möglich mit Hilfe von ver-
schiedenen Programmiertechniken Ablauflogik in die Formulare einzubetten, so daß Benutzereingaben
verarbeitet werden können.
Um den Inhalt einer Datenbank, die aus einer Vielzahl von Dokumenten besteht, zu präsentieren,
verwendet Lotus Notes das Konzept der Views. Sie erlauben das flexible Anzei-
gen durch die Auswahl von Datenfeldern aus den Feldinformationen der Datenbank und
einer dynamischer Berechnung vor dem Anzeigen. Die Views erlauben somit, verschiedene
Sichtweisen auf die Datenbank anzubieten und sind vergleichbar mit Abfragesprachen
im Bereich der relationalen Datenbanken (SQL). Die Views können durch vielfältige Optionen
sortiert und gruppiert werden.
Eine weitere Möglichkeit, den Inhalt von Datenbanken zu präsentieren, sind Ordner. Im
Gegensatz zu Views werden sie nicht dynamisch berechnet. Sie sind vergleichbar mit normalen
Aktenordnern, mit denen ein Benutzer eine eigene Ordnung festgelegt.

Arbeitsumgebung Seite 25
Programmierung
Lotus Notes verfügt zur Erstellung eigener Anwendungen über ein breite Palette von Entwicklungswerkzeugen.
Diese Entwicklungswerkzeuge unterscheiden sich durch den
Schwierigkeitsgrad der Programmierung und die Leistungsfähigkeit der einzelnen Werkzeuge.
Ungeübte Anwender können die Simple Actions (einfache Funktionen) benutzen, um einfache
kleine Aufgaben zu programmieren.
Mit @Functions (Formeln und Befehle) werden dem Entwickler relativ unkompliziert zu
benutzende, aber bereits leistungsfähige Kommandos zur Verfügung gestellt.
Mit Lotus Script 3.1 können sehr komplexe Anwendungen erstellt werden. Es handelt sich
dabei um eine leistungsfähige, plattformübergreifende, objektorientierte und auf BASIC
basierende Programmiersprache. Dabei ist eine weitgehende Kompatibilität mit Microsoft‘sVisual
Basic for Application (VBA) eingehalten worden. Der Entwickler kann sog.
Script Libraries erstellen, die mit Funktionsbibliotheken auf Betriebssystemebene vergleichbar
sind. Diese Funktionsbibliotheken können separat von der Anwendung gespei-
chert und auf diesem Wege in andere Applikationen eingebunden werden.
Neu in der Familie der Programmiersprachen ist Java. Die Implementierung von Java-
Anwendungen kann dabei innerhalb von Dokumenten in Rich-Text-Feldern erfolgen oder
außerhalb der Lotus Notes Umgebung. Allerdings ist die Integration in den Lotus Notes
Kern noch nicht soweit fortgeschritten, daß man von einem vollständigen Ersatz von Lotus
Script sprechen könnte.
Eine letzte Möglichkeit Lotus Notes zu programmieren, wird durch APIs (Application
Programming Interface) zur Verfügung gestellt. Dabei handelt es sich Funktionsbibliotheken
auf Basis der Programmiersprachen C und C++.
3.2 Wide Area Groupflow System
3.2.1 Konzeption von WAGS
Das Wide Area Groupflow System (WAGS) ist eine Weiterentwicklung des lokalen
Workflow-Management-Systems Groupflow. Im Unterschied zum lokalen Workflow-
Management, bei dem auf der Basis von Groupware lokale Büros intern wohlstrukturierten

Arbeitsumgebung Seite 26
oder ad hoc Workflow betreiben, wird der strukturierte elektronische Austausch von definierten
Teilmengen der Informationen aus Workflows mit externen Partner als weitverteiltes
Workflow-Management definiert. [vgl. Riempp/Nastansky 1996b]
Die Grundidee von WAGS besteht darin, daß die Funktionalität der lokalen Workflow-
Management-Systeme hinsichtlich der Zusammenarbeit mit weitverteilten heterogenen
Systemen auf Basis von Informationscontainern erweitert wird. Diese Informationscontainer,
auch als Message-Objekte definiert, werden zwischen den lokalen Workflow-
Systemen ausgetauscht [vgl. Riempp/Nastansky 1997, S. 485].
Internes
WFMS
Gate-
way
Message
Objekt
Message
Objekt
Internes
WFMS
Gate-
way
Koordinations-
Stelle
Message
Objekt
Gateway
Internes
WFMS
Abbildung 9: Grundidee von WAGS [Riempp/Nastansky 1996b, S. 197]
3.2.2 Architektur WAGS
Der Architektur der WAGS liegt ein Schichtenmodell (siehe Abbildung 10) zugrunde, das
sich aus einer Komponente für das interne Workflow-Management und einer Erweiterung
für die externe Anbindung zusammensetzt [vgl. Riempp/Nastansky 1997, S. 491 ff.].

Arbeitsumgebung Seite 27
Infrastr.
Modeler
Organisationskonzepte,
Geschäftsprozeßanalyse
Prozeß
Modeler
Werkzeug-Schicht
Workflow Anwendungsschicht
Infrastruktur Information
Workflow Repository-Schicht
Basis-Umgebung
Prozeß
Analyzer
Prozeß
Hardware, Betriebssystem, LAN
Gegenseitiges Broadcasting
External
Directory
Gateway
WAN
External
Directory
Gateway des
externen
Partners
Komponenten für internes WFM Komponenten für Wide Area WFM
Abbildung 10: Architektur der WAGS-Umgebung [vgl. Riempp/Nastansky 1997,
S. 491]
Die unterste Schicht in diesem Modell wird durch die normalerweise vorhandene hetero-
gene Infrastruktur (Hardware, Betriebssystem, LAN) gebildet. Darauf aufbauend kommt in
der Basisschicht die Groupware-Anwendung Lotus Notes 4.6 zum Einsatz. Aufgrund der
Leistungsmerkmale von Lotus Notes (Compound Documents, Replikation, Sicherheitsmechanismen,
E-Mail) werden die Mittel zur Verfügung gestellt, die eine räumlich und zeit-
lich verteilte Informationsverarbeitung erst ermöglichen.
Die Workflow-Repository-Schicht beinhaltet alle Daten, die für das Workflow Manage-
ment notwendig sind. In unterschiedlichen Datenbanken werden die Daten über den Aufbau
der Organisation, die definierten Workflow-Prozesse sowie die eigentlichen
Workflow-Daten gespeichert.
Die Benutzerschnittstelle für das Workflow-Management wird innerhalb der Workflow-
Anwendungsschicht abgebildet. Die WAGS-Runtime-Engine übernimmt dabei die Aufgabe,
die Repository-Daten für die Bearbeitung aufzubereiten und abzuarbeiten.
Für die Bearbeitung und Analyse der Repository-Daten stehen eine Reihe externer Applikationen
zur Verfügung. So wird mit dem WAGS-Modeler die graphische Modellierung
der verwendeten Workflows und ebenso die Verwaltung des externen Adreßbuchs (Exter-

Arbeitsumgebung Seite 28
nal Directory) durchgeführt [vgl. Touchard 1997]. Die Auswertung der Workflows wird
mit Hilfe des WAGS-Analyzers ermöglicht, der die vorhandenen Tracking Informationen
auf unterschiedliche Weise analysieren und statistisch auswerten kann [vgl. Hein 1997].
Der Einsatz dieser Werkzeuge und Anwendungen erfolgt unter der Berücksichtigung der
bestehenden Organisationskonzepte und Geschäftsprozesse und ist im Normalfall das Ergebnis
einer umfassenden Untersuchung und Optimierung.
Die interne Komponente wird aus Sicherheits- und Vertraulichkeitsgründen durch den Einsatz
des External Directory und des Gateways von der Außenwelt abgeschirmt. Alle Adreßinformationen,
die für die Abwicklung eines Workflows eines Partners wichtig sind, werden
im External Directory veröffentlicht. Die Übermittlung der Workflow-Daten in Form
eines Message-Objekts, werden durch die Gateway-Datenbank vorgenommen. Innerhalb
der Gateway-Datenbank werden die notwendigen Operationen zum Schutz der internen
Komponenten und zur Interoperabilität mit anderen Workflow-Systemen durchgeführt.
Die für die WAGS-Umgebung wichtigen Daten werden innerhalb der Workflow-
Repository-Schicht verwaltet. Deshalb wird im nächsten Abschnitt das WAGS Repository
besprochen.
3.2.2.1 Die Komponenten der Workflow-Repository-Schicht
Innerhalb der WAGS-Architektur bildet das WAGS-Repository die zentrale Kommunikation
und Datenhaltungskomponente. Alle externen Anwendungen (WAGS-Modeler,
WAGS-Analyzer) und die WAGS-Engine greifen auf die darin enthaltenen Daten zu. Das
Repository besteht aus fünf Datenbanken, die die unterschiedlichen Informationen nach
Bedeutung und Funktion getrennt speichern [vgl. Saliger 1998, S. 48 ff.].

Arbeitsumgebung Seite 29
GroupOrga Modeler
File Edit Tools Settings
Organization
Structure
Database
Routing
Specification
Database
WAGS Modeler
File Edit Tools Settings
Process Ext. Directory
Application
Database
External
Directory
WAGS Analyzer
File Edit Views Statistics
Tracking
Database
WAGS Repository WAGS Runtime Engine
WAGS Repository
MO
Gateway
Database
Content
Management
Abbildung 11: WAGS-Repository [vgl. Saliger 1998, S. 49]
Eine Ausnahme stellt die Gateway Datenbank dar. Sie regelt die Kommunikation zwischen
den heterogenen Systemen durch die Erstellung abgehender und Bearbeitung eingehender
Message-Objekte.
Application Database
Die Application Database (dt. Anwendungsdatenbank) ist die zentrale Schnittstelle zwischen
Benutzer und Workflow-Management-System. In dieser Anwendungsdatenbank sind
alle Workflows gespeichert, ebenso die persönliche Arbeitsumgebung des Benutzers.
Die Strukturen und Eigenschaften von Workflows, erzeugt durch den WAGS-Modeler,
werden in der Routing Specification Database (dt. Ablaufdatenbank) abgelegt. Mit diesen
Daten führt die WAGS-Runtime-Engine die Vorgangsbearbeitung durch.
Organization Structure Database
Die Organizsation Structure Database (dt. Organisationsdatenbank) enthält die Aufbaustruktur
eines Unternehmens. Die Struktur setzt sich aus Einzelpersonen zusammen, die
in verschiedenen Formen (Abteilungen, organisationsweite Gruppen) organisiert sein kön-

Arbeitsumgebung Seite 30
nen. Weiterhin besteht die Möglichkeit mittels Rollen mehrere Personen mit gleichen oder
ähnlichen Aufgabenbereichen zusammenzufassen. Die Daten können mit Hilfe des
GroupOrga-Modeler manipuliert werden. Der GroupOrga-Modeler ist eine Komponente
des WFMS GroupFlow, der eine graphische Bearbeitung der Struktur ermöglicht.
Tracking Database
Mit Hilfe der in der Tracking Database (dt. Tracking Datenbank) gesammelten Information
können verschiedene Auswertungen erstellt werden. Die Tracking-Daten geben Auskunft,
welche Bearbeitungsstation ein Vorgang durchlaufen hat und wieviel Zeit dafür verwendet
wurde. Der WAGS-Analyzer wertet diese Daten ex post aus. Aufgrund der Ergebniss können
Maßnahmen eingeleitet werden, die zur Verbesserung der Durchlaufzeit eines Vorgangs
führen. Die anfallenden Daten werden, je nach Anforderung, entweder direkt oder
verzögert an die Tracking Datenbank übermittelt. Dabei können die Daten aus dem internen
Workflow stammen oder auch aus dem organisationsübergreifenden Umfeld per E-
Mail gesammelt werden.
External Directory
Im External Directory (dt. externes Adreßbuch) werden die für die Partnerorganisation
wichtigen Informationen (Adressen, Kommunikationskanal etc.) als Verbindungsknoten
gespeichert. Diese Daten ermöglichen dann die Kommunikation mit Hilfe der Message
Objekte. Aus Sicherheitsgründen besteht der Eintrag für eine Organisation aus einem internen
(Internal Routing Information, IRI) und einem externen (External Routing Information,
GRI) Adreßteil.
Der interne Teil der Adresse (IRI) kann nur vom internen Workflow-Management-System
genutzt werden. Über ihn werden die eingehenden Message-Objekte anhand der mitgelieferten
GRI der entsprechenden Workflow-Klasse bzw. Aufgabe zugeordnet.
Der öffentliche Teil der Adresse beinhaltet die Beschreibung des abhängigen Workflows
sowie die Spezifikationen der Kommunikationsschnittstellen. Die Spezifikation umfaßt
eine Feldbeschreibung der benötigten und zurückzuliefernden Felder, die entweder direkt
in der GRI als textbasierte Liste oder als Verweis auf einen Format-Server gespeichert
werden. Der Format-Server ist eine Sammlung von standardisierten Dokumenttypen (Angebot,
Bestellung), die auch als Kopie im External Directory vorliegen können.

Arbeitsumgebung Seite 31
Diese Zweiteilung sichert eine weitestgehende Abschirmung der internen Daten vor den
beteiligten Partnerorganisationen.
Gateway Database
Die Funktion der Gateway-Datenbank besteht darin, einen ordnungsgemäßen Austausch
der Message-Objekte zwischen selbständigen Organisationen zu gewährleisten. Anhand
der GRI werden die zur Übermittlung der Message-Objekte notwendigen Informationen
aus dem External Directory ermittelt.
Die Aufbereitung der ein- und ausgehenden Message-Objekte wird als Content-
Management bezeichnet. Aus den ausgehenden Message-Objekten werden die Adressierung
und internen Steuerungsinformationen entfernt sowie ausgewählte Nutz- und
Workflow-Felder hinzugefügt. Handelt es sich bei dem externen Workflow-Management-
System nicht um Lotus Notes, muß eventuell eine Formatkonvertierung (SGML, XML,
HTML) vorgenommen werden.
Compound
Document
Filterungs-
Prozeß
Inhalt
Interne
Darstel.
Pflicht-
Felder
Ausgewählte
Nutz-Felder
Workflow-
Felder
Absender
Empfänger
Datum-Zeit-Stempel
Betreff
......
Content Blöcke
Einzelne Felder, z.B.:
Brieftext, Grafik-Objekt,
Budget-Tabelle,
Versicherungs-Nr.
.....
Tracking Logik
Routing Logik
Status Management
......
Externe
Darstel.
Format-
konvertierung:
EDIFACT
Internet e-mail
HTML-mail
XML
Notes-mail
MAPI, VIM
......
Message
Objekt
Abbildung 12: Content Management [Riempp/Nastansky 1996b, S. 202]
Eingehende Message-Objekte werden nach verschiedenen Gesichtspunkten (Formate, Sicherheitskontrollen)
bearbeitet und mit Hilfe des in der GRI abgelegten IRI an die
Workflow-Engine weitergeleitet. Die nachfolgende Abbildung 13 zeigt den Fluß der Mes-

Arbeitsumgebung Seite 32
sage-Objekte, das Zusammenspiel zwischen den verschiedenen Datenbanken und ansatzweise
die Funktion der Gateway-Datenbank.
Wide Area GroupFlow - connection of organizations
Organization A Organization B
Ext. directory
address
(GRI)
Sending
Gateway
replication
(GRI)
Message
Object
sub-
Ext. directory
processes
address
(IRI)
main
processes
Receiving
Gateway
Black
box
Grey
box
tasks
role person(s)
White
box
Abbildung 13: Fluß der Message-Objekte und Aufgabe der Gateway Datenbank
3.2.2.2 Struktur eines Message-Objekts
[Riempp/Nastansky 1997, S. 279]
Die Basis für die Kommunikation mit anderen externen Workflow-Management-Systemen
bildet das Message-Objekt. Es beinhaltet alle Informationen (Daten und Steuerungsinfor-
mationen), die für die Interoperabilität notwendig sind. Diese Informationen bestehen aus
Listenfeldern zur Eintragung der einzelnen Stationen des Bearbeitungswegs (routing logic),
Protokollierungsfeldern zur nachträglichen Kontrolle des Workflow-Verlaufs (tracking
logic), Statusfeldern zur Darstellung des Zustands und der jeweiligen Aufgaben an
einer Bearbeitungsstation (status logic) sowie Identifikationsfeldern zur eindeutigen Kennzeichnung
von Workflows [vgl. Riempp/Nastansky 1996b, S. 6].

Arbeitsumgebung Seite 33
Message-Objekt
form
content
Repräsentation:
Methoden:
Eigenschaften:
Anordnung der Felder, grafische u. Bedienungselemente,
Anzeigen u. Verbergen von Eigenschaften, Dialoge etc.
Ereignisgesteuert: Zugriff u. Veränderung von Eigenschaften,
Benutzerführung, Starten externer Prozesse, etc.
Kundenadresse Vertriebsinf. Versicherung 1
Feld 1 Feld 2 Feld 3 Feld 4
Feldname Feldtyp Inhalt
Content Blöcke
Abbildung 14: Struktur eines Message-Objekts [vgl. Riempp/Nastansky 1996b,
S.200]
Die Struktur des Message-Objekts (siehe Abbildung 14) ist in drei Teile aufgeteilt. Mit
Hilfe der Form (Formular), bestehend aus Repräsentation und Methoden, kann das Message-Objekt
auf der Empfängerseite innerhalb des Workflow-Management-Systems bear-
beitet werden. Die Präsentationsinformationen regeln dabei den Aufbau und die Anzeige
auf dem Bildschirm, die Methoden übernehmen die Benutzerführung hinsichtlich des
Zugriffs und der Veränderungen von Informationen und dem eventuellen Starten von externen
Applikationen.
Die eigentlichen Workflow-Daten (Content) bestehen aus verschiedenen Contentblöcken,
die wiederum aus verschiedenen Feldern bestehen. Die Felder werden über den Feldnamen
und Feldtyp spezifiziert und mit dem eigentlichen Inhalt verbunden. Die Datentypen der
Felder können strukturierte Daten (Text, Zahl, Datum, Schlüssel) oder auch unstrukturierten
Text (Rich-Text) umfassen.
Diese Struktur auf der Basis des proprietären Lotus Notes-Verbunddokumentes (Compound
Document) ermöglicht den Datenaustausch zwischen weitverteilten WAGS-
Systemen.

Arbeitsumgebung Seite 34
Für eine ausführliche Beschreibung der WAGS Architektur und die Funktionalitäten der
einzelnen Komponenten sei an dieser Stelle auf die Diplomarbeit von Dietmar Saliger
[Saliger 1998] verwiesen.

Austauschformate Seite 35
4 Austauschformate für den Transport von Workflow-Daten
Im vorangegangenen Kapitel wurden die Arbeitsumgebungen Lotus Notes und WAGS
vorgestellt sowie der Datenaustausch zwischen WAGS Systemen auf Basis von Message-
Objekten in der homogenen Lotus Notes Umgebung erläutert. Im folgenden Kapitel werden
die Anforderungen an einen Datenaustausch zwischen heterogenen Workflow-
Systemen mit Hilfe von Austauschformaten daraus abgeleitet sowie einige ausgewählte
Formate untersucht und bewertet. Zum Abschluß der Untersuchung folgt eine Zusammenfassung
der Ergebnisse und eine Empfehlung, welche Formate für den Datenaustausch
geeignet sind.
4.1 Anforderungen an Formate zur Übermittlung von Message-Objekten
Das Ziel der Untersuchung ist, ein Austauschformat zu finden, mit dem die Message-
Objekte abgebildet werden können, um sie zu transportieren.
Für die Definition der Anforderungen sind die folgende Überlegungen Grundlage:
1. Die Struktur des Message-Objekts, die für den Datenaustausch zwischen heterogenen
Workflow-Systemen entworfen und mit Hilfe des Lotus Compound Document Mo-
dells realisiert wurde, hat sich in umfangreichen Tests innerhalb von homogenen
WAGS-Systemen hinsichtlich Funktionalität und Flexibilität bewährt. Infolgedessen
werden die Struktur des Message-Objekts (siehe Kapitel 3.2.2.2) und die Eigenschaften
und Möglichkeiten der Lotus Compound Document-Struktur (siehe Kapitel 3.1)
als Vorbild für die Anforderungen an ein Austauschformat herangezogen.
So enthalten die Message-Objekte Informationen zur Präsentation des Message-
Objekts (Maske, Methoden), Daten zur Steuerung des Workflows und Nutzdaten.
Ein Großteil dieser Daten wird mit verschiedenen einfachen Datentypen (Text, Zahl,
Datum) kodiert. Das Austauschformat muß deshalb einfache Datentypen unterstützen
oder sie in irgendeiner Form abbilden können (-> Unterstützung einfacher Datentypen).
Zusätzlich enthalten die Nutzdaten Felder, deren Inhalt von einfachen Notizen bis hin
zu komplexen Informationen (z. B. Produktbeschreibungen kombiniert aus Audio, Video
und formatiertem Text) reichen kann. Das Lotus Notes Compound Document

Austauschformate Seite 36
Modell enthält für diese Art von Daten den Feldtyp Rich-Text 6 . Ein geeignetes Austauschformat
muß die Möglichkeit bieten, auch solche komplexen Datenobjekte zu
beinhalten oder realisieren zu können (-> Unterstützung komplexer Informationsfelder).
Für den Zugriff und die Verwaltung der Felder werden entsprechende Informationen
benötigt (-> Identifikation von Feldstrukturen).
Die Informationen zur Präsentation des Message-Objekts bestehen neben der Definition
der Maske auch aus den Methoden zur Bearbeitung der Maske. Die Methoden
werden mit Programmierlogik realisiert. Sie könnten deshalb in den Unternehmen als
ein mögliches Sicherheitsrisiko angesehen werden. Aus diesem Grunde sollte es möglich
sein, die Präsentationsinformationen vom Inhalt (Workflow-Daten, Nutzdaten) zu
trennen, so daß zumindest ein Transport der Daten durchgeführt werden kann
(-> Trennung von Präsentation und Inhalt).
2. Die Kommunikation zwischen den Partnerunternehmen und somit auch der Transport
der Message-Objekte wird hauptsächlich mit vorhandenen E-Mail Systemen durchge-
führt. Diese E-Mail Systeme sind überwiegend für den Informationsaustausch im persönlichen
Arbeitsumfeld konzipiert. Sie enthalten meist keine Möglichkeit, Daten
strukturiert zu übergeben. Das Austauschformat sollte deshalb die Möglichkeit besitzen,
eigene Angaben, die Informationen über die Struktur und den Aufbau des For-
mats enthalten, zu übergeben (-> Unterstützung von Strukturinformationen).
3. Erfüllt ein Austauschformat nicht oder nur teilweise alle gestellten Anforderungen, so
müßte das Format erweiterbar sein, um die fehlenden Anforderungen durch Erweiterung
hinzufügen zu können. Die Grundstruktur und Grundfunktionalität des Formats
dürfen dabei nicht verletzt werden. Diese Möglichkeit ist auch im Hinblick auf eine
kontinuierliche Weiterentwicklung eines Formats wichtig (-> Erweiterungsfähigkeit).
6 Der Begriff „Rich-Text“ im Lotus Notes-Kontext bezeichnet einen Datentyp und wird oft mit dem Microsoft-Doku-
mentenformat „Rich-Text-Format“ verwechselt.

Austauschformate Seite 37
4. In den Unternehmen sind unterschiedliche Betriebssysteme und Anwendungen im
Einsatz. Deshalb sind Gesichtspunkte der Interoperabilität zu berücksichtigen. So
sollte das Einsatzgebiet eines Austauschformats nicht nur auf eine Plattform beschränkt
sein (->Plattformunabhängigkeit) und auch nicht ausschließlich von einem
Hersteller abhängig sein (-> Herstellerunabhängigkeit).
5. Die Integration eines Austauschformats in die Produkte der Hersteller erfordert eine
hohe Akzeptanz. Sie wird dadurch erreicht, daß das Austauschformat ein verabschiedeter
Standard oder auch Industriestandard ist oder aus anderen Gründen eine sehr
weite Verbreitung gefunden hat. Die Akzeptanz eines Formats läßt sich einerseits an
der Verfügbarkeit von Produkten, Teilprodukten (Werkzeugen) und Dienstleistungen
durch Drittanbieter, andererseits aber auch an den Bestrebungen, die Spezifikation über
Normungs- und Standardisierungsgremien zu standardisieren, ablesen (->Hohe
Akzeptanz).
Um das gesetzte Ziel (ein Austauschformat zu finden, mit dem die Message-Objekte abge-
bildet werden können, um sie zu transportieren) zu erreichen, können die ermittelten Anforderungen
hinsichtlich ihrer Notwendigkeit klassifiziert werden.
So ergibt sich aus den Beschreibung der Anforderungen, daß die
• Unterstützung einfacher Datentypen,
• Unterstützung komplexer Informationsfelder,
• Identifikation von Feldstrukturen,
• Trennung von Präsentation und Inhalt,
• Unterstützung von Strukturinformationen und
• hohe Akzeptanz
unbedingt zur Erreichung des Ziels notwendig sind. Erfüllt ein Format eine oder mehrerer
dieser Anforderungen nicht, so ist es nicht als Austauschformat geeignet. Im Gegensatz
dazu sind die Anforderungen:
• Erweiterungsfähigkeit,

Austauschformate Seite 38
• Plattformunabhängigkeit und
• Herstellerunabhängigkeit
nur zweitrangig für die Auswahl des geeigneten Formats. Sie unterstützen die Auswahlentscheidung,
wenn ein oder mehrere Formate den gleichen Funktionsumfang haben.
Ein Sonderstellung nimmt hierbei die Anforderung Erweiterbarkeit ein. Sie ist optional,
wenn ein Format bereits alle notwendigen Anforderungen erfüllt. Falls dies nicht der Fall
ist, muß das Austauschformat erweiterbar sein, um notwendige Anforderungen realisieren
zu können.
Nach Abschluß der Überlegungen, der Definition und Klassifikation der Anforderungen
wird im nächsten Abschnitt eine Auswahl geeigneter Formate spezifiziert, untersucht und
bewertet.

Austauschformate Seite 39
4.2 Untersuchung vorhandener Formate
Für die Untersuchung existieren eine Vielzahl von potentiell geeigneter Austauschformate,
die für die Abbildung der Message-Objekte genutzt werden können. Um die Anzahl der
Kandidaten für die Untersuchung einzuschränken, werden nachfolgende Kriterien bei der
Auswahl hinzugezogen.
1. Das Format ist für den Austausch von Objekten (z. B. Dokumenten, Daten, Nachrichten)
konzipiert.
2. Es hat ein hohen Bekanntheitsgrad oder ist aufgrund des Status als Standard oder Industriestandard
weit verbreitet.
Für die nähere Untersuchung wurden deshalb ausgesucht:
• Rich-Text-Format (RTF)
Im Bereich der Textverarbeitungsprogramme hat sich das Rich-Text-Format von
Microsoft als Industriestandard etabliert. Das Design ist für den Austausch von Doku-
menten konzipiert.
• Portable Document Format (PDF)
Das Portable Document Format ist für den Austausch von Dokumenten im heterogenen
Umfeld entwickelt worden. Es hat in der Industrie, wo es häufig zur elektronischen
Verteilung von Informationen (z. B. Produktspezifikationen, Handbücher etc.) einge-
setzt wird, einen hohen Bekanntheitsgrad.
• EDI /EDIFACT
Das EDIFACT-Format wurde für den Austausch von Daten aus Geschäftsdokumenten
entwickelt. Das Format ist ein weltweit genormter Standard und verfügt über eine hohe
Verbreitung.
• Multi Purpose Internet Mime Extension (MIME)
Das MIME-Format ist für den Austausch von Nachrichten im Internet entwickelt worden.
Es ist standardisiert und hat einen hohen Verbreitungsgrad im Internet.
• Open Document Architecture (ODA)
Die Open Document Architecture ist ein standardisiertes Format, das zur Beschreibung
und zum Austausch von Dokumenten entwickelt wurde und hat den Status einer Norm.

Austauschformate Seite 40
• Hyper Text Markup Language (HTML)
Das HTML-Format ist die Basis für die Beschreibung der Dokumente des World Wide
Web-Dienstes (WWW). Es ist teilweise standardisiert und hat einen sehr hohen
Verbreitungsgrad.
Sollte keines der untersuchen Austauschformate für die Abbildung und den Transport der
Message-Objekte geeignet sein, so werden vorbeugend folgende standardisierte Sprachen
untersucht, welche zur Definition von Austauschformaten geeignet sind:
• Standard Generalized Markup Language (SGML)
SGML ist ein genormte Sprache, die zur Beschreibung und zum Austausch von Dokumenten
entwickelt wurde. SGML ist im Bereich des Dokumenten-Managements weit
verbreitet.
• Extensible Markup Language (XML)
XML ist eine Sprache, mit der Dokumentstrukturen für das WWW erstellt und Dokumente
ausgetauscht werden können. Die Entwicklung von XML in den Standardgremien
befindet sich zur Zeit noch im Anfangsstadium. Das Interesse und die frühe Unterstützung
der Industrie lassen es für die Untersuchung als geeignet erscheinen.
Nicht in die Untersuchung einbezogen wurden, zum Beispiel:
• Postscript
Postscript ist eine Seitenbeschreibungssprache, die zur Ansteuerung von Druckern
entwickelt wurde.
• Text Encoding Initiative (TEI)
Das TEI-Format ist ein in SGML entwickeltes Format zur Beschreibung und Repräsentation
von wissenschaftlichen Dokumenten. Es ist nur im Hochschulbereich weitverbreitet
und auch speziell auf diese Bedürfnisse hin ausgerichtet.
• TeX
TeX ist eine Sprache zur Beschreibung der Formatierungen eines Dokumentes. Sie
wurde von Donald Knuth (Stanford University) entwickelt und wird hauptsächlich im
Universitätsbereich zur Erstellung von wissenschaftlichen Arbeit verwendet.

Austauschformate Seite 41
Die Untersuchung beginnt mit einem kurzen historischen Überblick über die Entwicklung
und den Werdegang des jeweiligen Formats. Danach erfolgt eine technische Beschreibung.
Anschließend erhält jedes Format eine Bewertung, inwieweit es den in Kapitel 4.1 definierten
Anforderungen genügt.
4.2.1 Rich-Text-Format (RTF)
Historie
Microsoft entwickelte Anfang der 90er Jahre mit dem Rich-Text-Format (RTF) eine Methode
zur Kodierung von formatiertem Text und Grafiken für den Transfer zwischen Anwendungen.
Im Vordergrund stand dabei die Interoperabilität des eigenen Produktes MS
Word, das auf den Betriebssystemplattformen Windows, OS/2 und Apple Macintosh verfügbar
war. Mittlerweile wird RTF auch von anderen Textverarbeitungs- und Desktop
Publishing-Programmen unterstützt und hat sich zum Marktstandard für den Austausch
von Dokumenten zwischen diesen proprietären Anwendungen entwickelt. Ziel der Ent-
wicklung von RTF war die Formatierung der Dokumente zu erhalten, die bei einem Transport
mittels reinem ASCII verloren gehen.
Technik
RTF nutzt den ANSI PC-8, Macintosh oder IBM PC Zeichensatz, um die Präsentation und
die Formatierung eines Dokuments zu kontrollieren. Die RTF Spezifikation ist unter der
Kontrolle der Microsoft Corp. und liegt derzeit in der Version 1.5 vor.
Zur Umwandlung der Originaldatei in RTF wird ein sogenannter Writer benötigt. Das Lesen
und Konvertieren einer RTF-Datei in ein proprietäres Format wird durch einen Reader
ermöglicht.

Austauschformate Seite 42
Eine RTF-Datei (siehe Abbildung 15) besteht aus unformatiertem Text, Kontrollwörtern,
Kontrollzeichen und Gruppen.
{\rtf\ansi\deff0{\fonttbl{\f0\froman Tms Rmn;}{\f1\fdecor ;}{\f2\fswiss Helv;}}
{\colortbl;\red0\green0\blue0;
\red0\green0\blue255;\red0\green255\blue255;\red0\green255\;\red255\green0\blue255;\
red255\green0\blue0;\red255\\blue0;\red255\green255\blue255;}
{\stylesheet{\fs20 \snext0Normal;}}
{\info{\author John Doe} {\creatim\yr1990\mo7\dy30\hr10\min48}
{\version1}{\edmins0}
{\nofpages1}{\nofwords0}{\nofchars0}{\vern8351}}\widoctrl\ftnbj
\sectd\linex0\endnhere \pard\plain \fs20 This is plain text.\par}
Abbildung 15: RTF Beispiel
Kontrollwörter sind definierte Befehle, die eingesetzt werden, um die Formatierung für
Drucker und Anwendungen zu kontrollieren. Sie beginnen mit „\“ und dem Kontrollwort,
das 32 Zeichen nicht überschreiten darf, z. B. \par zeigt den Beginn eines neuen Abschnittes
an. Ein Kontrollzeichen ist eine Kombination aus einem „\“ gefolgt von einem einzel-
nen nicht alphabetischen Zeichen, z. B.“ \~“ bezeichnet ein geschütztes Leerzeichen 7 .
Gruppen bestehen aus Text, Kontrollwörtern- und -zeichen und sind in Klammern „{ }“
eingeschlossen.
Der Aufbau einer RTF-Datei ist fest definiert. Auf der höchsten Stufe besteht sie aus dem
„Header“ (dt. Kopfinformation) und dem „Document“ (dt. Dokument). In den Kopfinformationen
werden die Informationen, wie z. B. die RTF-Version, die eingesetzten Zeichen-
sätze etc. definiert, wobei die Reihenfolge der Schlüsselwörter genau eingehalten werden
muß. Das Dokument besteht aus dem eigentlichen Text und Kontrollwörtern, die Struktur
und Formatierung kontrollieren. Eine RTF-Datei kann auch Bilder enthalten, die mit anderen
Anwendungen erzeugt wurden. Diese Bilder können in hexadezimalem (Standard) oder
binärem Format vorhanden sein. Als Bildformate werden u. a. JPEG, OS/2-Metafiles und
das MAC-Format unterstützt.
7 In Microsoft Word werden „Geschützte Leerzeichen“ beim Zeilenumbruch wie Buchstaben behandelt, so daß keine
automatische Trennung von zusammengehörigen Wortkombinationen erfolgt.

Austauschformate Seite 43
In RTF werden auch Feldstrukturen unterstützt. Diese Felder sind normalerweise Bestandteil
eines Word-Formulars. Als Datentypen stehen
• Regular Text,
• Number,
• Date,
• Current Date,
• Current Time,
• Calculation,
zur Verfügung 8 . Die nachfolgende Abbildung zeigt die RTF-Definition eines Textfeldes,
mit dem Namen „Kunde“, dem Feldtyp „Text“ und dem Inhalt „John Doe“.
{\*\formfield{\fftype0\fftypetxt0{\*\ffname Kunde}}}}}
{\fldrslt {\lang1024 John Doe}}}{{\*\bkmkend Text1}\par }}
Abbildung 16: RTF-Felddefinition
Zusätzlich können in Word-Dokumenten auch Objekte eingebettet werden. Diese Objekte
werden mittels der MS Technologie „Objekt Linking and Embedding (OLE)“ durch einen
Link (Zeiger auf das Ausgangsobjekt, z. B. Kalkulationstabelle) oder durch die Einkapselung
des Ausgangsobjekts in das Dokument repräsentiert. In RTF werden nur die Daten
des Objekts übergeben, nicht aber die Objektfunktionalität.
Bewertung
• Unterstützung einfacher Datentypen -> Erfüllt
In RTF-Dateien können Felder mit einfachen Datentypen eingebettet werden. Die
RTF-Spezifikation sieht dies im Rahmen der Formularverarbeitung vor.
8 Auf eine Übersetzung der Typen wurde in diesem Fall bewußt verzichtet, um die Bedeutung nicht zu verfälschen.

Austauschformate Seite 44
• Unterstützung komplexer Informationsfelder -> Nicht erfüllt
Die RTF-Spezifikation enthält keine Datentypdefinition, welche die Möglichkeit zur
Abbildung komplexer Datentypen bietet. Solch ein Datentyp kann auch nicht durch
Erweiterungen hinzugefügt werden.
• Identifikation von Feldstrukturen -> Teilweise erfüllt
Nur im Rahmen der Kodierung von Formularfeldern ist eine Identifikation der Felder
möglich.
• Trennung von Präsentation und Inhalt -> Nicht erfüllt
Die RTF-Spezifikation sieht keine Trennung von Inhalt und Präsentation (Formatierung)
vor. Durch eine Kombination von Struktur- (z. B. \par ) und Formatierungskontrollwörtern
wird ein Dokument beschrieben. Die Präsentation (z. B. Formatierung eines
Absatzes) und der Inhalt sind deshalb miteinander verwoben.
• Unterstützung von Strukturinformationen ->Nicht erfüllt
Ein RTF-Dokument enthält keine Information über die Struktur und den Aufbau der
Datei. Dies sieht die Spezifikation des RTF-Formats nicht vor.
• Erweiterungsfähigkeit -> Nicht erfüllt
Die Definition des RTF-Formats kann nicht erweitert werden, weil die Realisierung
und Weiterentwicklung neuer Funktionen allein von der Firma Microsoft bestimmt
wird.
• Plattformunabhängigkeit ->Teilweis erfüllte
Microsoft hat das RTF-Format vorwiegend für die Betriebssystem-Plattformen entwi-
ckelt, für die MS Word angeboten wird (OS/2, Macintosh, PC). Dadurch werden ein
Großteil der im Büroumfeld eingesetzten Betriebssysteme abgedeckt. Sein Fokussierung
auf den Transport von Word-Dokumenten läßt nur einen Einsatz im Textverarbeitungsbereich
zu.
• Hohe Akzeptanz ->Teilweise erfüllt
Das RTF-Format wird überwiegend im Bereich der Textverarbeitungen unterstützt,
weil MS Word dort eine marktbeherrschende Stellung hat. Der Großteil der Textverarbeitungsprogramme
anderer Hersteller kann das RTF-Format lesen und schreiben.

Austauschformate Seite 45
Zusammenfassung
Das RTF-Format wurde primär für die Weitergabe von MS Word-Dokumenten entwickelt.
Deshalb ist sein Design auf die korrekte Abbildung der Word-Texte und der Word-
Formatierungen ausgerichtet.
Anforderung Bewertung
Unterstützung einfacher Datentypen Erfüllt
Unterstützung komplexer Informationsfelder Nicht erfüllt
Identifikation von Feldstrukturen Teilweise erfüllt
Trennung von Präsentation und Inhalt Nicht erfüllt
Unterstützung von Strukturinformationen Nicht erfüllt
Erweiterungsfähigkeit Nicht erfüllt
Plattformunabhängigkeit Teilweise erfüllt
Herstellerunabhängigkeit Nicht erfüllt
Hohe Akzeptanz Teilweise erfüllt
Tabelle 1: Bewertung des RTF-Formats
Eine Erweiterung des Formats um notwendige Eigenschaften (z. B. Trennung von Präsentation
und Inhalt, Unterstützung komplexer Informationsfelder) ist aufgrund des Designs
und der Herstellerabhängigkeit nicht möglich.
Infolgedessen kann eine Message-Objekt-Struktur nicht vollständig abgebildet werden;
somit genügt das Format nicht den Anforderungen für den Datenaustausch zwischen heterogenen
Workflow-Systemen.
4.2.2 Portable Document Format (PDF)
Historie
Das Portable Document Format (PDF) wurde 1993 von Adobe System Inc. entwickelt. Ziel
ist es, ohne Berücksichtigung der Arbeitsumgebung (Anwendungssoftware, Betriebssysteme),
Benutzern einen einfachen und zuverlässigen Austausch elektronischer Dokumente
zu ermöglichen [vgl. Adobe 1996, S. 17]. Die Spezifikation des Formats liegt, zum jetzigen
Zeitpunkt, in der Version 1.2 vor.

Austauschformate Seite 46
Technik
PDF ist ein Derivat der Seitenbeschreibungssprache Postscript 9 von Adobe. Es nutzt die
Fähigkeit von Postscript, Grafik und Text in einer geräte- und auflösungsunabhängigen
Weise abzubilden.
Für die Erstellung einer PDF-Datei gibt es mehrere Möglichkeiten:
• Die eingesetzte Anwendung erstellt direkt eine Datei im PDF-Format.
• Die Anwendung nutzt das kostenpflichtige Programm Adobe Acrobat Writer. Diese
Zusatzsoftware simuliert innerhalb der Anwendung einen Drucker und wandelt den
Datenstrom in eine PDF-Datei um. Diese Option wird hauptsächlich im Umfeld von
grafischen Benutzeroberflächen und vom Desktop-Publishing-Systemen genutzt.
Macintosh
applications
Windows
applications
Quickdraw GDI
PDF-
Writer
PDF
Abbildung 17: Erstellung einer PDF-Datei durch PDF Writer
[vgl. Adobe 1996, S. 28]
9 Postscript wurde 1985 für die Ansteuerung von Druckern entworfen und ist im Markt für High-End-Drucker weitver-
breitet.

Austauschformate Seite 47
• Aus einer Postscript Datei wird mit Hilfe des Acrobat Distillers die PDF-Datei erzeugt.
Postscript
Acrobat
Distiller
PDF
Abbildung 18: Umwandlung von Postscript nach PDF [vgl. Adobe 1996, S. 29]
Die Dokumente werden dabei seitenweise analysiert und umgewandelt. Nach der Umwandlung
in das PDF-Format (siehe Abbildung 19) enthalten die Dateien nur noch ASCII-
Zeichen.
Mit dem Programm Adobe Exchange können zusätzliche Funktionen in die PDF-Dateien
eingefügt werden. Die Funktionen umfassen Paßwortschutz, Anmerkungen (Annotatio-
nen), Verknüpfungen (Hyperlinks), Lesezeichen, Thumbnails 10 , Filme, Sound und eine
einfache Formularfunktion.
%PDF-1.2
%âãÏÓ
8 0 obj
>
endobj
/Filter /LZWDecode
>>
stream
_Š ѨÐp._
4^F‹Ä"EC4Z_5_HÌq‰_Ü@($Šbf i__q Œ_ÃxŒ¸_1__£´_TæY_)_èc_Ä,p4__â&ØèÖ
Abbildung 19: Auszug aus einer PDF-Datei
10 Thumbnails sind verkleinerte Ansichten der Originalseiten.

Austauschformate Seite 48
Für die Anzeige einer PDF-Datei hat Adobe das kostenlose Anzeigeprogramm Arcrobat
Reader entwickelt. Der Reader ist auf allen gängigen Betriebssystemen (DOS, Windows
3.x, Windows NT/95, OS/2, Macintosh, Unix-Derivate) verfügbar.
Aufbauend auf der Acrobat-Technologie werden zahlreiche Erweiterungen von Adobe und
unabhängigen Drittherstellern angeboten. Die Bandbreite der angebotenen Werkzeuge
reicht von Konvertern für Fremdformate über zusätzliche Funktionsbausteine (Plug-Ins)
für den Acrobat Reader bis hin zur Unterstützung von Dokument-Management- und
Groupware-Systemen (z. B. Lotus Notes).
Die PDF-Spezifikation besteht aus vier Komponenten (siehe Abbildung 20). Die erste
Komponente besteht aus einem Satz von Objekttypen, die PDF für die Repräsentation von
Objekten (engl. objects) nutzt. Es existieren Basisobjekte vom Typ Boolean, Numbers,
Strings, Names, Dictonaries und Streams [vgl. Adobe 1996, S 43].
Objects
File
structure
Document
structure
Page
description
Abbildung 20: PDF-Komponenten [Adobe 1996, 34]
Objekte vom Typ Boolean können zwei Werte TRUE und FALSE annehmen. Numbers
können vom Typ INTEGER und REAL sein. Strings, z. B. {Dies ist ein Text}, können alle
ASCII-Zeichen aufnehmen. Sonderzeichen innerhalb eines Strings werden mit dem Postscript-Mechanismus
kodiert. Ebenso wie Strings bestehen Names aus „/“ und einer Kombination
von ASCII-Zeichen, z. B. /Name1. Der zusammengesetzte Objekttyp Array kann
eine Sequenz von unterschiedlichen Objekten aufnehmen, z. B. [0 {Text} 3.14 /Name].
Für die Speicherung von großen Datenmengen, z. B. Bilddaten oder Seitenbeschreibungen,
steht der Objekttyp Stream zur Verfügung. Ein Stream setzt sich aus einem Dictionary und

Austauschformate Seite 49
den Daten (kodiert in ASCII-Zeichen) zusammen, die durch STREAM und ENDSTREAM
abgeschlossen werden. Im Gegensatz zu Strings kann ein Stream fortlaufend eingelesen
werden.
Dictionaries bestehen aus zwei Elementen, dem Schlüssel (engl. key) und dem dazugehörigen
Wert (engl. value), z. B. .
Der Key muß vom Objekttyp Names sein und dient zur Identifikation des Dictionary. Der
zugehörige Wert kann alle Basistypen enthalten, so daß auf diese Weise komplexere Objekte
realisiert werden können. Die Objekte vom Typ Dictionary sind die Hauptbestandteile
eines PDF-Dokuments. Ein Großteil der Informationen, aus denen ein Dokument besteht,
z. B. Seiten, Fonts, Kopfzeilen, werden in diesem komplexen Objekttyp gespeichert.
Die zweite Komponente der PDF-Spezifikation (siehe Abbildung 21) ist die „File structu-
re“ (dt. Dateiaufbau), mit der festgelegt wird, wie und in welcher Reihenfolge die Objekte
in einer PDF-Datei angeordnet werden müssen.
Header
Body
Crossreference
table
Trailer
Abbildung 21: PDF-File-Struktur [Adobe 1996, 62]
Die Bestandteile eines PDF-Dokuments sind:
• Header
Im „Header“ wird die Information über die Version des PDF-Formats gespeichert.
• Body
Der „Body“ enthält die Objekte, die ein Dokument repräsentieren.

Austauschformate Seite 50
• Crossreference Table
Die „Crossreference Table“ ist vergleichbar mit einem Verzeichnis, das einen wahlfreien
(nicht sequentiellen) Zugriff auf die Objekte innerhalb der Datei ermöglicht. Es
wird dadurch vermieden, daß die ganze Datei gelesen werden muß, um einzelne Objekte
zu laden.
• Trailer
Der „Trailer“ ermöglicht Anwendungen das schnelle Auffinden der „Crossreference
table“ sowie spezieller Objekte.
Die dritte Komponente ist die „Document structure“, die im „Body“ der PDF-Datei gespeichert
wird. Ein PDF-Dokument wird als eine Hierarchie von Objekten beschrieben.
Der Großteil der Objekte sind vom Objekttyp „Dictionary“. Die Objekte sind durch Referenzen
miteinander verbunden, z. B. hat das Catalog-Dictionary 11 Verweise auf die Be-
schreibung der Seitenbäume (siehe Abbildung 22).
Page
Tree
Catalog
Outline
Tree
Page Page Page
Imageable
Content
Article
threads
Thumbnail Annotations
Abbildung 22: Struktur eines PDF-Dokuments
[vgl. Adobe 1996, S. 72]
Innerhalb der Spezifikation sind bereits eine Reihe von allgemeinen Datenstrukturen für
Objekte (Rechtecke, Hyperlinks, Fonts, Datum etc.) vordefiniert. Diese Objekte enthalten
11 Das Catalog-Dictonary ist das Objekt-Inhaltsverzeichnis einer PDF-Datei.

Austauschformate Seite 51
notwendigen Informationen, die der Acrobat Reader benötigt, um beispielsweise die Elemente
einer Seite zu beschreiben.
Die allgemeinen Datenstrukturen können um eigene Objekte erweitert werden. Allerdings
benötigt der Acrobat Reader dann eine Funktionserweiterung (Plug-In), oder die eigenen
Anwendungen müssen entsprechend erweitert werden. Zur Vermeidung von Namenskonflikten
bei der Bezeichnung von Objekten pflegt Adobe ein Register der vergebenen Namen.
Die letzte Komponente ist die „Page Description“ (dt. Seitenbeschreibung). Eine Seitenbeschreibung
kann als eine Sequenz von Grafikobjekten aufgefaßt werden. Dabei werden die
Grafikobjekte mittels des geräte- und auflösungsunabhängigen Koordinatensystems auf der
Seite plaziert. Der Acrobat Reader liest die Dokumentenstruktur und baut aus den einzel-
nen Grafikobjekten die Seite auf. Dieser Vorgang wird für jede Seite wiederholt.
Die PDF-Spezifikation enthält vier verschiedene Grafikobjekte:
1. Das „Path Object“
Es ist eine willkürliche Form, die aus Linien, Rechtecken etc. besteht.
2. Das „Text Object“
Es besteht aus verschiedenen Zeichen und kann überall auf der Seite in jeder Größe
und Orientierung gezeichnet werden.
3. Das „Image Objekt“
Es enthält Daten, die in ein Bild umgewandelt werden können.
4. Ein „external Objekt“ (dt. externes Objekt)
Das externe Objekt ist außerhalb eines „Streams“ definiert. Die Behandlung eines
externen Objekts hängt von seinem Typ ab. Zur Zeit unterstützt PDF drei Typen:
Bilder, Formulare und Postscript-Fragmente.
Das PDF-Format wird in einer Spezifikation, die 400 Seiten umfaßt, definiert. Die wesentlichen
Eigenschaften sind oben beschrieben. Weitere Details würden den Rahmen dieser
Arbeit sprengen.

Austauschformate Seite 52
Bewertung
• Unterstützung einfacher Datentypen -> Erfüllt
Die PDF Spezifikation enthält die Definition von Datentypen (Boolean, Numbers,
Strings, Names, Dictonaries und Streams), aus denen die Objekte gebildet werden, die
für die Kodierung der Dokumente notwendig sind. Die Objekte sind mit Feldern vergleichbar.
• Unterstützung komplexer Informationsfelder -> Nicht erfüllt
Die PDF-Spezifikation enthält keinen vordefinierten Datentyp mit dem komplexe Informationen
explizit gespeichert werden können. Im weitesten Sinne kann die Beschreibung
einer Seite, die aus den Elementen (Text, Bilder etc.) und der Beschreibung
der Anordnung dieser auf der Seite besteht, mit der Leistung eines Datentyps zur Aufnahme
von komplexen Informationen verglichen werden.
• Identifikation von Feldstrukturen -> Erfüllt
Die Objekte vom Datentyp Dictonary sind vergleichbar mit Feldern. Die Spezifikation
des PDF-Formats schreibt die Identifikation vor.
• Trennung von Präsentation und Inhalt -> Nicht erfüllt
Ein Trennung von Präsentation und Inhalt ist nicht möglich, weil beide Komponenten
zusammen für die korrekte Verarbeitung einer PDF-Datei benötigt werden.
• Unterstützung von Strukturinformationen -> Teilweise erfüllt
Ein PDF-Dokument enthält keine Informationen, die Auskunft über den korrekten
Aufbau des Formates geben. Jedoch sind verschiedene Informationen über die Struktur
von Dokumenten in Form von Dictonary-Objekten enthalten. Als Beispiel sei das
„Catalog Directory“ angeführt, das innerhalb der Definition der Dokumentstruktur
Verweise zu den einzelnen Komponenten enthält.
• Erweiterungsfähigkeit -> Erfüllt
Das PDF-Format kann um zusätzliche Funktionalitäten und Objekte erweitert werden.
• Plattformunabhängigkeit -> Erfüllt
Die Plattformunabhängigkeit war Ziel der PDF-Spezifikation. Durch die Verwendung
des ASCII-Zeichensatzes können die Dokumente ohne Probleme zwischen Anwendungen
weitergegeben werden. Zumindest das Anzeigeprogramm (Acrobat Reader) ist für

Austauschformate Seite 53
alle gängigen Office-Betriebssysteme verfügbar. Das Offenlegen der Spezifikation erlaubt
das Erstellen von PDF-konformen Applikationen.
• Herstellerunabhängigkeit -> Teilweise erfüllt
Durch die Möglichkeit, das PDF-Format um eigene Funktionalitäten zu erweitern, besteht
eine gewisse Unabhängigkeit vom Hersteller. Das PDF-Format selbst bleibt Eigentum
von Adobe. Eine Weiterentwicklung der Grundstruktur erfolgt ausschließlich
durch den Hersteller.
• Hohe Akzeptanz -> Erfüllt
Das PDF-Format wird überwiegend zur elektronischen Verteilung von umfangreichen
und hochqualitativen Informationsprodukten (z. B. Handbücher, Produktbeschreibungen,
Werbebroschüren) verwendet. Durch die kostenlose Bereitstellung der Acrobat
Reader-Software und die Möglichkeit, Eigenentwicklungen in das PDF-Format einzubetten,
genießt es eine hohe Akzeptanz.
Zusammenfassung
Adobe hat das PDF-Format zielgerichtet für die elektronische Weitergabe von Dokumenten
entwickelt.
Anforderung Bewertung
Unterstützung einfacher Datentypen Erfüllt
Unterstützung komplexer Informationsfelder Nicht erfüllt
Identifikation von Feldstrukturen Erfüllt
Trennung von Präsentation und Inhalt Erfüllt
Unterstützung von Strukturinformationen Teilweise erfüllt
Erweiterungsfähigkeit Erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Nicht erfüllt
Hohe Akzeptanz Erfüllt
Tabelle 2: Bewertung des PDF-Formats
Dabei stand die grafische Repräsentation der Dokumente auf unterschiedlichen Plattformen
im Vordergrund.
Ein Message-Objekt kann mit der Grunddefinition des PDF-Formats nicht abgebildet werden.
Zwar besteht die Möglichkeit, durch die Definition von eigenen Objekten zusätzliche
Funktionen zu implementieren, doch würde dies nach eingehender Untersuchung die

Austauschformate Seite 54
Grundkonzeption des PDF-Formats verletzen. Infolgedessen ist PDF nicht als Austauschformat
für Message-Objekte geeignet.
4.2.3 Electronic Data Interchange (EDI) und EDIFACT
Historie
Bereits in den 70er Jahren wurde die Notwendigkeit erkannt, den elektronischen Austausch
von Geschäftsdaten zu normieren. Der Austausch von Geschäftsdaten auf elektronischem
Wege ist auch unter dem Synonym „Elektronic Data Interchange“ (EDI) bekannt.
Die Basis von EDI sind Nachrichten mit vordefiniertem Aufbau. Der Aufbau der Nachrichten
und deren Bedeutung muß bei allen Beteiligten bekannt sein. Zu Beginn der EDI-
Bewegung vereinbarten die Geschäftspartner gemeinsam das Format, in dem die Daten
übertragen werden sollten. Aufgrund der steigenden Anzahl von EDI-Teilnehmern ent-
stand dann aber schnell die Notwendigkeit, die Formate zu standardisieren. Die Entwicklung
der Standards erfolgte in Gremien auf regionaler, nationaler und internationaler Ebene
und ebenso branchenabhängig und -unabhängig.
Um die Entwicklung eines internationalen und branchenunabhängigen Standards zu be-
schleunigen, setzte eine Kommission der Vereinten Nationen (UNECE 12 ) die Arbeitsgruppe
WP.4 ein.
Die Spezifikation dieser Norm wurde im März 1987 unter dem Name UN/EDIFACT (Elektronic
Data Interchange for Administration and Transport) als Empfehlung der
UNECE veröffentlicht. Kurze Zeit später wurde sie von der ISO unter der Bezeichnung
ISO-9735 übernommen. Die Europäischen Gemeinschaft und das Deutsche Institut für
Normung führten die Spezifikation unter dem Kennzeichen EN27 237 und DIN 16559 in
ihren Wirkungsbereichen ein.
Die EDIFACT-Normen, welche die Zeichensätze, Datenelemente und die Syntax beschreiben,
bestehen aus den sieben Vorschriften:
• EDIFACT-Syntax-Regeln (ISO 9735)
• EDIFACT-Handbuch der Datenelemente (EDED)
12 United Nations Economic Commission for Europe

Austauschformate Seite 55
• EDIFACT-Code-Liste (EDCL)
• EDIFACT-Handbuch der Datenelementgruppen (EDCD)
• EDIFACT-Handbuch der einheitlichen Nachrichtentypen (EDMD)
• Richtlinien der Nachrichtenentwicklung und Anwendung der Syntax-Regeln
• Einheitlichen Durchführungsregeln für den Handelsaustausch via Telekommunikation
Technik
Die Übermittlung von Nachrichten im EDIFACT-Format ist ein kontrollierter Austausch
von hierarchisch strukturierten Datensätzen, die den Inhalt eines Geschäftsdokuments dar-
stellen.
Im Unterschied zu anderen Austauschformaten, z. B. PDF-Format, wird in einer EDI-
Nachricht (siehe Abbildung 23) nur der Inhalt des Geschäftsdokuments (z. B. Lieferanschrift,
Absender, Bestellpositionen) nicht aber die Präsentation (Layout und Formatie-
rung) übermittelt.
Die EDI-Nachrichten werden mit zwei Zeichensätzen (A, B) kodiert, die dem 7-ASCII-
Zeichensatz (ISO 646) nachempfunden sind. Der Zeichensatz B enthält zusätzliche, nicht
druckbare Zeichen, die als Separatoren dienen. Binäre oder andere plattformabhängige
Zeichen dürfen nicht verwendet werden.
UNB+UNOA:2+54321:ZZZ+12345:ZZ+950112:1620+1111111‘
UNH+1+ORDERS+D:93A:UN‘
BGM+220+12345‘
DTM+137:19950112:102‘
DTM+2:19950201:102‘
NAD+BY+54321:ZZZ++Handels-
Office+Handelsstrasse1+Handelshausen++543212+DE‘
NAD+SU+12345:ZZZ++Hersteller+Herstellerstrasse1+Herstellerhausen++12345+DE‘
LIN+1+++22222:BP‘
QTY+21:2:PCE‘
UNT+13+1‘
UNZ+1+1111111‘
Abbildung 23: Beispiel EDIFACT-Nachricht
[Deutsch 1994, S. 56]

Austauschformate Seite 56
Der Aufbau von EDIFACT-Nachrichten ist streng hierarchisch und besteht aus den Elementen:
Nachrichten, Segmenten und Datenelementen (siehe Abbildung 24). Die Nachrichten,
die ein Geschäftsdokument repräsentieren (z. B. Rechnung) setzen sich aus Segmenten
zusammen, die wiederum aus Datenelementen oder Datenelementgruppen zusammengesetzt
sind.
Die einzelnen Bestandteile der EDIFACT-Nachricht werden durch verschiedene Separatoren
getrennt. Innerhalb einer Gruppe werden die Elemente durch „:“ getrennt. Zwischen
Elementgruppen oder einzeln vorkommenden Elementen steht ein „+“. Segmente werden
durch „‘“ beendet.
Die Basiskomponenten des Formats sind die Datenelemente, z. B. Menge, Uhrzeit. Die
Definition der Elemente wird im Handbuch der Datenelemente (EDED) aufgelistet. Sie
enthält den Schlüssel, die Bezeichnung, eine Beschreibung und das Datenformat, z. B.
2001 – Datum, codiert; n6; JJMMTT. Das bedeutet, daß das Element 2001 ein Datum, nu-
merisch und 6-stellig ist und in der Form JJMMTT kodiert werden muß. EDIFACT Datenelemente
können nur numerische oder alphanumerische Daten enthalten. Die Interpretation
des Datentyps wird im Handbuch der Datenelemente (EDED) spezifiziert. Am Beispiel des
Datenelements 2001 ist ersichtlich, daß bei der Umwandlung des Datenelements auf Emp-
fängerseite eine Übertragung in den korrekten Datentyp „Datum“ erfolgen muß. Diese Information
kann jedoch nicht direkt aus dem Datenstrom entnommen werden, weil auf der
Datenelement-Ebene keine Bezeichnung mitgesendet wird.

Austauschformate Seite 57
UNA
Verbindungsaufbau
Übertragungsdatei
bestehende
Verbindung
Übertragungsdatei
Verbindungsabbau
Übertragungsdatei
entweder
oder einzelne
UNB ' Nachrichten-
UNZ
gruppe
Nachrichten
UNG ' Nachricht Nachricht Nachricht UNE
UNH ' Segment Segment Segment UNT
Seg.-
Bez.
einfaches
Datenelement-
+ +
'
Datenelement
gruppe
Kennung : Zähler
Wert GD :
'
'
'
GD
Wert
Wert
Abbildung 24: Struktur einer EDIFACT-Übertragungsdatei
[Weid 1994, S. 40]
Die Elementgruppen werden als logische Einheit aus mehreren Elementen zusammengesetzt.
Eine Elementgruppe wird mit einem „c“ und einer dreistelligen Zahl bezeichnet,
z. B. c033 – Datum/Zeit der Referenzangabe. Die Elementgruppe „c033 Datum“ setzt sich
aus den beiden Elementen „Datum codiert“ (numerisch, 6-stellig) und „Uhrzeit“ (nume-
risch, 4-stellig) zusammen. Die Bezeichnung der Elementgruppen, ihre Bedeutung und
Zusammensetzung wird im EDIFACT-Handbuch der Datenelementgruppen (EDCD) ver-
öffentlicht.
Aus den Elementgruppen und den Elementen können Segmente zusammengesetzt werden.
Die Bezeichnung der Segmente wird aus drei Großbuchstaben gebildet, z. B. NAD = Name
und Adresse. Sie wird im EDIFACT-Handbuch der Datenelementgruppen (EDCD) veröffentlicht
und enthält die Bedeutung und die Vereinbarungen, wie ein Segment zusammengesetzt
werden kann. Die Bezeichnung der Segmente wird bei der Datenübertragung dem
Segment vorangestellt. Mit Hilfe dieser Bezeichnung kann die EDI-Anwendung die Zusammensetzung
des Segments aus einem elektronischen Verzeichnis ermitteln und aus der
Definition auf die Datenelemente schließen.

Austauschformate Seite 58
Durch die Kombination verschiedener Segmente werden schließlich die Nachrichten gebildet.
Dabei können einzelne Segmente mehrfach vorkommen (z. B. Bestellpositionen).
Die Nachrichten sind das Abbild eines Geschäftsvorgangs, z. B. eine Rechnung. Die Definition
und Zusammensetzungen der Nachrichten werden im EDIFACT-Handbuch der einheitlichen
Nachrichtentypen (EDMD) veröffentlicht.
Die Entwicklung neuer Nachrichten, Segmente, Datenelementgruppen und Datenelemente
wird in den Normungs- und Standardisierungsgremien durchgeführt. Zur Zeit existieren
etwa 40 Nachrichtentypen für Geschäftsvorfälle, weitere sind in Vorbereitung [vgl.
Deutsch 1994, S. 39 ff.].
Bewertung
• Unterstützung einfacher Datentypen -> Teilweise erfüllt
Die Abbildung von Daten erfolgt in der EDIFACT-Norm in Form von Datenelemen-
ten. Die EDIFACT-Spezifikation unterstützt jedoch nur numerische und alphanumerische
Datentypen.
• Unterstützung komplexer Informationsfelder -> Nicht erfüllt
Für die Aufnahme von komplexen Informationen ist innerhalb der EDIFACT-Spezifikationen
kein Datentyp vorgesehen.
• Identifikation von Feldstrukturen -> Teilweise erfüllt
Eine Identifikation von Datenelementen kann nicht innerhalb der Datenstruktur vorge-
nommen werden. Sie wird im Handbuch der Datenelemente festgelegt. Die Bezeichnung
und Definition der Datenelemente kann nur über die Segment-Bezeichnung ermittelt
werden.
• Trennung von Präsentation und Inhalt -> Nicht erfüllt
EDI-Nachrichten enthalten nur die Daten eines Geschäftsvorgangs. Eine Übertragung
von Präsentationsinformationen war nicht das Designziel von EDIFACT.

Austauschformate Seite 59
• Unterstützung von Strukturinformationen -> Nicht erfüllt
Der Aufbau einer EDIFACT-Nachricht wird im EDIFACT-Handbuch der einheitlichen
Nachrichtentypen (EDMD) definiert und durch die EDI Anwendung sichergestellt. Eine
Übermittlung von Informationen über den korrekten Aufbau einer EDIFACT-
Nachricht erfolgt während der Übertragung nicht.
• Erweiterungsfähigkeit -> Teilweise erfüllt
Der EDIFACT-Standard kann erweitert werden. Jedoch können nur Elemente und
Segmente kombiniert werden, um daraus neue Nachrichten zu definieren. Die Definiton
neuer Datentypen oder die Ergänzung um Funktionen ist nicht vorgesehen.
• Plattformunabhängigkeit -> Erfüllt
EDIFACT ist mit dem Ziel der Plattformunabhängigkeit entwickelt worden. Die Verwendung
des ISO 646-Zeichensatzes zur Kodierung des Inhalts ermöglicht die Über-
tragung und Verarbeitung auf allen Betriebssystem-Plattformen.
• Herstellerunabhängigkeit -> Erfüllt
Die EDIFACT Spezifikationen werden in den Standardisierungsgremien durchgeführt.
• Hohe Akzeptanz -> Erfüllt
Der Einsatz von EDI und EDIFACT wurde in den vergangen Jahren besonders im
Großkunden- und Behördenbereich massiv vorangetrieben. Deshalb hat sich ein großer
Markt um die EDI-Welt gebildet, auf dem alle Arten von Anwendungen und Dienst-
leistungen erhältlich sind.
Zusammenfassung
Die Entwicklung des EDI-Standards EDIFACT ist sehr stark von den Möglichkeiten der
Datenverarbeitung der 80er Jahre bestimmt. Das Ziel war es, die Daten, die in Geschäftsvorgängen
auf Papier kodiert wurden, auf elektronischem Wege zu transportieren.

Austauschformate Seite 60
Anforderung Bewertung
Unterstützung einfacher Datentypen Teilweise erfüllt
Unterstützung komplexer Informationsfelder Nicht erfüllt
Identifikation von Feldstrukturen Nicht erfüllt
Trennung von Präsentation und Inhalt Nicht erfüllt
Unterstützung von Strukturinformationen Nicht erfüllt
Erweiterungsfähigkeit Teilweise erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Erfüllt
Hohe Akzeptanz Erfüllt
Tabelle 3: Bewertung des EDIFACT-Formats
Mit den vorhandenen Möglichkeiten und Eigenschaften von EDIFACT ist ein Transport
der Message-Objekte nicht möglich. Die fehlenden Anforderungen, z. B. die Unterstützung
komplexer Informationsfelder oder die Identifikation von Feldstrukturen, können durch
Erweiterungen nicht implementiert werden.
Auf Grund dessen ist EDIFACT nicht als Austauschformat geeignet.
4.2.4 Multipurpose Internet Mail Extension (MIME)
Historie
Neben dem World Wide Web (WWW) ist das Versenden von elektronischen Nachrichten
(E-Mail) wohl der bekannteste und am häufigsten genutzte Dienst im Internet. Die Nach-
richten werden mit Hilfe des Übertragungsprotokolls Simple Mail Transfer Protocol
(SMTP) über das Internet übertragen. Die Spezifikation des SMTP-Protokolls wurde im
Jahre 1982 von der Internet Engineering Task Force (IETF) veröffentlicht. SMTP enthält
eine Reihe von Einschränkungen, die durch die Entwicklung von MIME überwunden wurden.
Die Erweiterung des SMTP-Protokolls wurde 1993 unter dem Namen Multipurpose Internet
Mail Extension (MIME) verabschiedet. Mit der Nutzung von MIME ist es nun möglich:
• Nachrichten in unbegrenzter Größe zu versenden,
• die Zeilenlänge von 1000 Bytes zu überschreiten,
• unterschiedliche Datenobjekte in einer Nachricht einzubinden,

Austauschformate Seite 61
• internationale Zeichensätze und Textformatierungen zu erhalten.
Zusätzlich unterstützt MIME die Übertragung von Bildern, Videosequenzen und binären
Daten aus Fremdapplikationen.
Technik
Eine MIME-Nachricht besteht aus einem Kopfteil (engl. header), der Informationen über
die MIME-Version, Absender, Empfänger und Betreff enthält. Der Hauptteil (engl. body)
enthält die zu übertragenden Nachrichten.
Header
Body
Content-Block
Nested Content-Block
Nested Content-Block
Abbildung 25: Aufbau einer MIME-Nachricht
Die Nachrichten werden mit dem 7-Bit ASCII-Zeichensatz erstellt. Dies ist besonderes
wichtig, weil die Datenübertragung der Nachrichten im Internet überwiegend mit dem
SMTP-Protokoll (7-Bit ASCII basiert) erfolgt.

Austauschformate Seite 62
Im Hauptteil der Nachricht werden die Daten in Form von Blöcken (engl. contentblock 13 )
gespeichert. Jedem Block wird eine Kennung (engl. content-type header) vorangestellt, der
Auskunft über den Typ und die Kodierung der Daten gibt. Dies wird durch eine Paarkombination
von „Type“, „Subtype“ und zusätzlich durch die Angabe von Parametern geleistet.
Die Syntax für die Kennung ist:
Content-Type := type "/" subtype [";" parameter]
Die Nachrichten können sich aus folgenden Basistypen zusammensetzen:
• Text
Der Datenblock kann einfache Texte in unterschiedlichen Zeichensätzen ent-
halten.
• Multipart
Mit Multipart können unterschiedliche Typen von Daten, getrennt durch spezielle
Separatoren (engl. boundary), in einem Block oder einer Nachricht kombiniert
werden.
• Application
Der Datenblock enthält Daten aus anderen Anwendungen (z. B. Excel) oder binäre
Daten.
• Message
Innerhalb des Blocks ist eine Nachricht eingekapselt.
• Image
Der Block besteht aus Bild-Daten.
• Audio
Der Block enthält Sound- oder Sprachdaten.
• Video
Der Block enthält Videodaten.
13 Die Definition „Contentblock“ ist eine MIME-Spezifikation und nicht mit der Definition von Content-Block im Rah-
men des WAGS-Systems identisch.

Austauschformate Seite 63
Diese Basistypen können aber nicht den gesamten Umfang aller für eine spezielle Anwendung
notwendige Datentypen abdecken. Deshalb ist es möglich, die MIME-Spezifikation
zu erweitern.
Die erste Möglichkeit ist die Verwendung des „X-„ im Subtyp-Schlüssel, z. B. Content-
Type:Application/X-my-application. Dadurch können eigene Datentypen implementiert
werden.
Die zweite Möglichkeit ist die Registrierung des neuen Subtype-Schlüssels über die Internet
Assigned Numbers Authority (IANA). Die IANA überwacht die Entwicklung neuer Typen
und führt ein entsprechendes Register aller Typen. Mit der Registrierung ist die Veröffentlichung
der Spezifikation verbunden. Auf Grund dessen kann ein neuer Standard-
Datentyp für alle Benutzer der MIME-Spezifikation zugänglich gemacht werden.
Zur Bearbeitung von MIME-Nachrichten wird ein User Agent (UA) benötigt. Dieser User
Agent kann das MIME-Format lesen, die darin enthaltenen Content-Blöcke dekodieren, die
Daten darstellen oder sie an Anwendungen übergeben. Er kann entweder in Anwendungen
(z. B. E-Mail Programme) integriert oder komplett durch MIME-Anwendungen ersetzt
werden.
Um eine MIME-Nachricht zu erstellen, benötigt der UA einen MIME-Message Builder (dt.
Nachrichten-Ersteller). Der Message Builder kommuniziert mit dem Netzwerk und den
Konvertern. Darüber hinaus wird ein Message Designer benötigt, der die Nachricht mit den
unterschiedlichen Typen korrekt zusammensetzt.
Die nachfolgende Abbildung zeigt ein Beispiel einer vollständigen MIME-Nachricht.
MIME-Version: 1.0
From: Nathaniel Borenstein nsb@nsb.fv.com
To: Ned Freed ned@innosoft.com
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed; boundary=unique-boundary-1
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
--unique-boundary-1
... Some text appears here ...

Austauschformate Seite 64
[Note that the blank between the boundary and the start
of the text in this part means no header fields were
given and this is text in the US-ASCII character set.
It could have been done with explicit typing as in the next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part, but
illustrates explicit versus implicit typing of body parts.
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here ...
--unique-boundary-2
Content-Type: image/jpeg Content-Transfer-Encoding: base64
... base64-encoded image data goes here ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched
This is enriched.
as defined in RFC 1896 Isn't cool?
--unique-boundary-1
Bewertung
Abbildung 26: Beispiel einer MIME-Nachricht
[Grand 1993]
• Unterstützung einfacher Datentypen -> Teilweise erfüllt
Das MIME-Format hat keine einfachen Datentypen. Die Anforderung könnte erfüllt
werden, wenn entsprechende Contentblock-Strukturen entwickelt würden, z. B
Content-type: application/X-wfdata fieldname=Name fieldtype =Txt
• Unterstützung komplexer Informationsfelder -> Teilweise erfüllt
Das MIME-Format enthält bereits Definitionen für die Aufnahme einiger komplexer
Datentypen (Audio, Video), jedoch keine entsprechende Datendefinition. Sie kann aber
durch Eigenentwicklung hinzugefügt werden.

Austauschformate Seite 65
• Trennung von Präsentation und Inhalt -> Teilweise erfüllt
Das MIME-Format ist nur ein Rahmen zur Übertragung von ASCII-Zeichen. Das MI-
ME Format enthält keine Präsentationsinformationen. Durch die Entwicklung eines eigenen
Contentblocks könnten die Präsentationsinformationen getrennt übertragen werden.
• Unterstützung von Strukturinformationen -> Teilweise erfüllt
MIME-Nachrichten enthalten keine Informationen über den möglichen oder erlaubten
Aufbau einer Nachricht. Der Rahmen für die MIME-Struktur wird durch die MIME-
Spezifikation festgelegt. Durch die Verwendung der Contentblock-Strukturen kann aber
eine MIME Nachricht strukturiert werden.
• Erweiterungsfähigkeit ->Teilweise erfüllt
Mit Hilfe der Contentblock-Strukturen können zusätzlichen Datentypen implementiert
werden. Die Grundstruktur des MIME-Formats kann jedoch nicht geändert werden.
• Herstellerunabhängigkeit -> Erfüllt
Die MIME Spezifikation wird von der IETF gepflegt. Somit besteht keine Abhängigkeit
von einem Hersteller.
• Plattformunabhängigkeit -> Erfüllt
Die MIME-Spezifikation ist für die Nachrichtenübertragung mit dem 7-Bit ASCII-Zeichensatz
definiert. Infolgedessen kann das Format auf allen Betriebssystem-
Plattformen verarbeitet werden.
• Hohe Akzeptanz ->Erfüllt
MIME genießt eine sehr hohe Akzeptanz in der Industrie. Nahezu alle Hersteller
proprietärer E-Mail-Systeme haben das MIME-Format als Standard in ihre Produkte
integriert oder bieten entsprechende Konverter.

Austauschformate Seite 66
Zusammenfassung
MIME wurde hauptsächlich entworfen, um die Probleme des E-Mail Protokolls (SMTP) zu
überwinden und definiert ein universelles Rahmengerüst zum Transport von Objekten.
Anforderung Bewertung
Unterstützung einfacher Datentypen Teilweise erfüllt
Unterstützung komplexer Informationsfelder Teilweise erfüllt
Trennung von Präsentation und Inhalt Teilweise erfüllt
Unterstützung von Strukturinformationen Teilweise erfüllt
Erweiterungsfähigkeit Teilweise erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Erfüllt
Hohe Akzeptanz Erfüllt
Tabelle 4: Bewertung des MIME-Formats
Mit der aktuellen Version der MIME-Spezifikation ist die Abbildung der Message-Objekte
nicht möglich. So fehlen beispielsweise einfache Datentypen und die Unterstützung kom-
plexer Informationsfelder, sowie die Trennung von
Durch die Entwicklung spezieller Content-Block-Strukturen könnten die Voraussetzungen
für den Datenaustausch geschaffen werden. Als positives Beispiel ist hier die Workflow
Management Coalition (WFMC) anzuführen. Sie hat eine Contentblock-Spezifikation für
ihre Art des Datenaustauschs zwischen Workflow-Systemen entwickelt und im Rahmen
einer Konferenz demonstriert.
Auf Basis von MIME könnte deshalb der Austausch von Message-Objekten realisiert werden.
4.2.5 Open Document Architecture (ODA)
Historie
Open Document Architecture (ODA) ist ein Standard, der für den Austausch von Verbunddokumenten
14 (Compound Document) zwischen Anwendungen (z. B. Textverarbei-
tungsprogramme) entwickelt wurde.
14
In der ODA-Norm wird ein Verbunddokument als eine Kombination von Text, Grafik, Rastergrafik (Bildern) definiert.
Die Definition des Begriffs entspricht nicht der Lotus Notes Compound Document-Definition.

Austauschformate Seite 67
Obwohl die Arbeiten an vergleichbaren Standards bereits in den frühen 80ern begannen,
wurde ODA erst 1985 von der European Computer Manufacture’s Association (ECMA)
als ECMA-101 veröffentlicht. Dieser Entwurf wurde auch an andere Organisationen (ISO,
CCITT) weitergegeben, um einen gemeinsamen Standard für den Dokumentenaustausch
zu entwickeln. 1988 wurde ODA als ISO-Standard unter der Bezeichnung ISO 8613 und
als T.410-Empfehlung der CCITT veröffentlicht. Aus Kompatibilitätsgründen glich die
ECMA ihre Spezifikation im gleichen Jahr an die anderen Spezifikationen an.
Der Standard besteht aus 8 Teilen:
Part 1: Introduction and general principles
Part 2: Document structures
Part 4: Document profile
Part 5: Office document interchange format (ODIF)
Part 6: Character content architectures
Part 7: Raster graphics content architectures
Part 8: Geometric graphics content architectures
Part 10: Formal specifications
In der aktuellen Spezifikation sind Part 3 und Part 9 nicht enthalten. Sie sind im Laufe der
Entwicklung in andere Bereiche eingeflossen [vgl. Appelt 1991, S. 1].
Technik
Zusammengefaßt besteht der ODA-Standard aus zwei Teilen: erstens der Architektur 15 , mit
der ein Rahmen zur Abbildung von Dokumenten (ODA) geschaffen wird. Zweitens der
Definition des Open Document Interchange Format (ODIF), mit dem die ODA-Dokumente
für den Austausch kodiert werden.
15 Die Architektur stellt hier letztendlich auch eine Sammlung von Definitionen dar.

Austauschformate Seite 68
Das ODA-Modell beschreibt ein Dokument mit drei Komponenten:
• Layout information (dt. Layout-Struktur)
Die Layoutinformationen sind das Ergebnis der Analyse eines Dokumentes hinsichtlich
seiner Präsentation auf einem Ausgabemedium (z. B. Bildschirm, Papier). Sie bestehen
aus einer Hierarchie von Positionierungsobjekten (Block, Rahmen, Seite und Seitengruppen),
die in einer Baumstruktur angeordnet sind. Der Block ist das Grundelement
zur Aufnahme des eigentlichen Inhalts (engl. content). Ein oder mehrere Blöcke können
in einem Rahmen zusammengefaßt werden. Diese Rahmen können dann auf einer
Seite plaziert werden. Mehrere Seiten können in einer Seitengruppe gesammelt werden.
• Logical information (dt. Logische Struktur)
Die „Logical information“ kennzeichnet die Beziehungen zwischen sogenannten logischen
Objekten und ihren Attributen, z. B. ein Buch besteht aus mehreren Kapitel, das
wiederum mehrere Abschnitte enthält. Mit diesen Beziehungen werden die Hierarchie
und die Reihenfolge der Objekte festgelegt. ODA standardisiert weder die Bezeich-
nungen der logischen Objekte, z. B. Kapitel, noch die Hierarchie der Objekte. Ebenso
wie die „Layout information“ werden diese Informationen “ in einer Baumstruktur ge-
speichert.
• Content (dt. Inhalt, hier die Kombination aus Text, Grafik, Bildern)
Der Content besteht aus sichtbaren Elementen, z. B. Text, Grafiken und Bildern (hier
sind Rastergrafiken gemeint). Außerdem sind unsichtbare Informationen, wie z. B.
Kontrollzeichen (Leerzeichen, Absatzende, Zeilenumbruch), enthalten.
Die Layout-Struktur und die Logische Struktur können getrennt übergeben werden.
Zusätzlich zu diesen drei Komponenten besitzt ein ODA Dokument ein Dokumentenprofil.
Dieses Profil enthält Informationen über das Dokument, den Autor, die verwendeten Zeichensätze
etc.
Zur Beschreibung der ODA-Komponenten werden standardisierte Objekte, z. B. Document
logical root, eingesetzt (siehe Abbildung 27). Diese Objekte werden im 2. Teil des Standards
definiert und enthalten Attribute, die den Inhalt des Objektes näher definieren.

Austauschformate Seite 69
Document logical root:=
{object identifier,
subordinates, ........}
Abbildung 27: Objektspezifikation in ODA
[vgl. Appelt 1991, S. 44]
Jedes Objekt enthält ein Identifikationsattribut (object identifier), das als Referenz auf das
Objekt genutzt wird.
Für die Attribute stehen verschiedene Datentypen zur Verfügung. Der am häufigsten verwendete
Typ ist INTEGER. Hierbei handelt es sich um ganze Zahlen, die sowohl positiv
als auch negativ sein können. Die Werte einiger Attribute sind vom Datentyp STRING,
d. h. eine Sammlung von Zeichen. Verwendet werden zwei Zeichensätze: erstens Zeichen
des „ISO 6937 Part 2 16 “-Zeichensatzes und zweitens Zeichensätze, die im Dokumentenprofil
definiert wurden. Zusätzlich kann auch ein OCTET STRING eingesetzt werden. Mit
Hilfe des OCTET STRINGs können Daten repräsentiert werden, deren Bedeutung außerhalb
des Standards liegt.
Im zweiten Teil der ODA-Spezifikation wird das Open Document Interchange Format
(ODIF) definiert. Die ODA-Spezifikation enthält keine Definition über die Art und Weise
wie ein Dokument in einer ODA-konformen Applikation gespeichert werden sollte.
Mit Hilfe von ODIF können die Dokumente für den Datenaustausch zwischen unter-
schiedlichen Textverarbeitungsprogrammen kodiert werden. Die Kodierung basiert auf den
ISO Standards 8824 und 8825 Abstract Syntax Notation One (ASN.1). ASN.1 ist ein standardisiertes
binäres OSI-Austauschformat. Auf eine nähere Untersuchung von ODIF wird
verzichtet, weil mit ODIF nur die Struktur und Dateninhalte von ODA kodiert werden.
16 ISO 6937, Part 2 („Coded character sets for text communication – Part 2: Latin alphabetic and non-
alphabetic graphic characters)

Austauschformate Seite 70
Bewertung
• Unterstützung einfacher Datentypen -> Erfüllt
Der ODA-Standard enthält für die Beschreibung von Objekt-Attributen einfache Datentypen.
• Unterstützung komplexer Informationsfelder -> Nicht erfüllt
Innerhalb des ODA-Standards sind keine Strukturen vorhanden, welche komplexe Informationsfelder
abbilden können.
• Identifikation von Feldstrukturen -> Erfüllt
Die mit Feldern vergleichbaren standardisierten Objekte werden über das Identifikationsattribut
(object identifier) identifiziert.
• Trennung von Präsentation und Inhalt -> Erfüllt
Durch die getrennte Speicherung der Layout und Logical informations sowie des Contents
ist die Anforderung erfüllt.
• Unterstützung von Strukturinformationen -> Nicht erfüllt
ODA-Dokumente enthalten keine Informationen über Struktur und Aufbau des ODA-
Standards.
• Erweiterungsfähigkeit -> Nicht erfüllt
Die ODA-Struktur kann nicht erweitert werden. Sie erfolgt in den Gremien von ISO
und CCITT.
• Plattformunabhängigkeit -> Erfüllt
Die ODA-Architektur ist eine abstrakte Definition, die nicht an eine Anwendung oder
Plattform gebunden ist.
• Herstellerunabhängigkeit -> Erfüllt
Der ODA-Standard wurde in den unabhängigen Gremien von ISO und CCITT entwickelt
und unterliegt deshalb nicht der Kontrolle eines Herstellers.
• Hohe Akzeptanz -> Nicht erfüllt
Aufgrund der Komplexität des ODA-Standards und der großen Verbreitung proprietärer
Lösungen hat sich der ODA-Standard nicht im Markt der Textverarbeitungsprogramme
durchsetzen können. Deshalb ist die Unterstützung von ODA sehr gering.

Austauschformate Seite 71
Zusammenfassung
Mit dem ODA/ODIF-Standard ist ein Rahmen geschaffen worden, mit dem Dokumente
plattformunabhängig ausgetauscht werden können.
Anforderung Bewertung
Unterstützung einfacher Datentypen Erfüllt
Unterstützung komplexer Informationsfelder Nicht erfüllt
Identifikation von Feldstrukturen Erfüllt
Trennung von Präsentation und Inhalt Erfüllt
Unterstützung von Strukturinformationen Nicht erfüllt
Erweiterungsfähigkeit Nicht erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Erfüllt
Hohe Akzeptanz Nicht erfüllt
Tabelle 5: Bewertung des ODA
Das Design des ODA-Standards ist auf die Anforderung zur Abbildung von Dokumenten
ausgerichtet. Die in ODA enthaltenen Objekte sind speziell für die Speicherung dieser Informationen
konzipiert worden. Die Anpassung des Standards an die Anforderungen zur
Abbildung von Message-Objekten ist nicht möglich. Einerseits findet die Entwicklung des
Standards in unabhängigen Gremien statt, andererseits wird die Grundstruktur von ODA
verletzt.
Infolgedessen ist ODA nicht als Austauschformat für Message-Objekte geeignet.
4.2.6 Standard Generalized Markup Language (SGML)
Historie
Die Anfänge der Standard Generalized Markup Language (SGML) gehen auf ein Forschungsprojekt
der IBM im Jahre 1969 zurück. Charles Goldfarb, Edward Mosher und
Raymond Loire entwickelten die Generalized Markup Language (GML), die es erlaubte,
mit unterschiedlichen Textverarbeitungssystemen (Editoren, Formatierern und Suchsystemen)
ein gemeinsames Dokument zu pflegen. GML basiert auf der Idee des generischen
Markup (engl. generic markup) von Rice und Tunnicliffe. Große Teile von GML wurden
von IBM und anderen Unternehmen in der Großrechnerwelt implementiert.

Austauschformate Seite 72
1978 begannen innerhalb einer Arbeitsgruppe des American National Standards Institute
Committee on Information Processing die Arbeiten an einer Textbeschreibungssprache auf
Basis von GML. Zu den Mitgliedern dieser Arbeitsgruppe gehörte Charles Goldfarb.
Die Ergebnisse dieser Arbeitsgruppe wurden im Laufe der 80er Jahre auch von anderen
Standardisierungs-Organisationen übernommen. Die Verabschiedung als internationaler
Standard durch die ISO als ISO 8879 erfolgte dann im Jahre 1986.
Die Verwendung von SGML ermöglicht die plattform-unabhängige Beschreibung und den
plattform-übergreifenden Austausch von Dokumenten.
Technik
Grundsätzlich ist SGM eine Meta-Sprache, die zur Beschreibung von Dokumenten entwickelt
worden ist. Es können die Bestandteile (Struktur, Layout und Inhalt) eines Dokuments,
z. B. Buch oder Geschäftsbrief, getrennt beschrieben werden. Dies geschieht durch
die Verwendung von generischen Anmerkungen (engl. generic Markup 17 ). Die generischen
Anmerkungen sind Informationen, die Aufschluß über die Art und Eigenschaft des nach-
folgenden Inhalts geben, z. B. der nachfolgende Text ist ein Abschnitt.
Technisch wird dies durch Einfügen einer Kombination von Tags (dt. Identifizierungs-
kennzeichen) erreicht, z. B.
Dies ist ein Abschitt
Die Bedeutung von PARA ist nicht standardisiert, sondern kann nur von einer SGMLkonformen
Applikation, z. B. einem Textverarbeitungsprogramm, entsprechend interpretiert
werden.
Mit SGML können die Bezeichnungen der verschiedenen Kennzeichen und die Anwendung
der Kennzeichen frei definiert werden, z. B. die Reihenfolge, in der die Tags aufeinanderfolgen
dürfen oder können. Die Definition der Kennzeichen und der Anwendungsregeln
ist vergleichbar mit der Grammatik einer Sprache. Allerdings kann die Bedeutung
eines Tags nur durch ein geeignetes Programm interpretiert werden.
17 Im Gegensatz zum Generic Markup wird in anderen Austauschformaten oder Textverarbeitungsprogrammen das
descriptive Markup verwendet (engl. descriptive markup), z. B. Microsoft RTF-Format.

Austauschformate Seite 73
Die Bestimmung der Kennzeichen und der Regeln erfolgt in der Document Type Definition
(DTD).
Die Erstellung einer DTD verlangt die Untersuchung der Dokumente hinsichtlich der
Struktur und der darin vorkommenden Elemente (z. B. Bilder, Absätze, Links etc.) sowie
der Art und Weise wie die Elemente angeordnet sind.
Die drei wichtigsten Deklarationen, die in einem DTD vorkommen, sind:
a) Element-Deklarationen
Durch die Elementdeklaration werden die Kennzeichen (engl. tags), ihr Aufbau und
die Anwendungsregeln definiert.
Der Aufbau einer Element-Deklaration wird am nachfolgenden Beispiel eines Memos
erläutert.
]>
Abbildung 28: SGML-konforme DTD Definition
Die erste Deklaration besteht in der Definition des Dokumententyps memo. Danach
werden die Elemente und die Reihenfolge der einzelnen Elemente festgelegt. Ein
Memo besteht aus der Elementgruppe: to, from, date und subject. Das Element subject
kann, muß aber nicht vorkommen. Dies wird durch das „?“ definiert. Die Anordnung
dieser Gruppe ist nicht vorgegeben (definiert durch „&“). Aus dieser Gruppe wird aber
der Einsatz des Elementes text verlangt (definiert durch „ , “).
Das Element text kann aus mehreren para Elementen zusammengesetzt werden; das
para Element muß jedoch mindestens einmal im Dokument enthalten sein (angezeigt
durch „+“). Durch die Definition wird festgelegt,
daß der Inhalt aus Zeichen (parced character data) besteht. Die gleiche Definition
erfolgt in der nächsten Zeile für die Elemente to, from, date, subject.

Austauschformate Seite 74
Aus dieser Definition kann dann das folgende Dokument abgeleitet werden.
Everyone
Heike Musterfrau
8. August
Cats and Dogs
Please remember to keep all cats and dogs indoors tonight.
b) Attribut-Deklarationen
Abbildung 29: SGML-Beispiel
Für die weitere Charakterisierung der Elemente können Attribute (siehe Abbildung 30)
definiert werden, z. B. Informationen über den Status, Sicherheit etc.
Mit der Entity-Definition im DTD wird die Grundlage geschaffen, Datenquellen (Bilder,
Ton) in das Dokument zu integrieren und Zeichen zu kodieren, die unterschiedliche
Präsentationen auf verschiedenen Plattformen haben (z. B. deutsche Umlaute).

Austauschformate Seite 75
Für die Kodierung der Dokumente wir der ISO 646 Zeichensatz eingesetzt, der aber durch
Vereinbarungen im DTD erweitert werden kann. Aufgrund dieser Zusatzdefinitionen können
länderspezifische Zeichensätze im Dokument eingebunden werden.
Ein vollständiges SGML-Dokument muß eine Document Type Definition oder zumindest
einen Entity-Verweis auf eine DTD enthalten. Damit enthält das Dokument eine Beschreibung
seiner Struktur, mit der die Vollständigkeit und die Korrektheit des Dokuments sichergestellt
werden kann.
Für die Definition des Layouts eines Dokumentes wurde die Document Style Semantics
and Specification Language (DSSL, ISO/IEC 10179) in den Standardgremien entwickelt.
Mit ihr kann die Präsentation für die Tags generiert werden. Die Beschreibung des Layouts
und der Inhalt können so getrennt verwaltet und getrennt ausgetauscht werden.
SGML ist eine Metasprache, d. h. es können jegliche Art von Tags zur Beschreibung von
Dokumenten entwickelt werden. Die Definition von SGML, die in den Standardgremien
gepflegt wird, beinhaltet nur die Vorschriften über Aufbau und Anwendung der Grammatik
zur Erstellung von DTDs und der damit erstellten Dokumente.
Das Ergebnis einer SGML DTD-Definition wird auch als SGML-Applikation bezeichnet.
Bekannte SGML-Applikationen sind die Hyper Text Markup Language (HTML) und die
Text Encoding Iniative (TEI).
Die Motivation für die Entwicklung der SGML-Sprache war die Beschreibung von Doku-
menten mit generischem Markup. Aber aufgrund der Flexibilität der Sprache ist keine Begrenzung
in der Entwicklung von SGML-Applikationen gesetzt.
Bewertung
• Unterstützung einfacher Datentypen -> Erfüllt
Die SGML-Sprache unterstützt keine einfachen Datentypen. Doch durch die Entwicklung
eines geeigneten Tag-Sets können diese Datentypen abgebildet werden, z. B.
Kunde
INTEGER
Reco GmbH

Austauschformate Seite 76
• Unterstützung komplexer Informationsfelder -> Erfüllt
Eine Unterstützung komplexer Informationsfelder ist in SGML ebenfalls nicht vorgesehen.
Die Anforderung könnte jedoch durch eine Eigenentwicklung eines geeigneten
Tag-Sets erfüllt werden.
• Identifikation von Feldstrukturen -> Erfüllt
Durch die Freiheit bei der Entwicklung einer Struktur zur Abbildung von Variablen
kann eine Identifikation von Feldstrukturen ermöglicht werden. Die Identifikation der
Feldstrukturen könnte durch eine Tag-Kombination (siehe oben) oder mit Hilfe von
Attributen realisiert werden, z. B.
Reco GmbH.
• Trennung von Präsentation und Inhalt -> Erfüllt
Die SGML-Definition sieht die Trennung von Inhalt und Präsentation vor. Dies wird
durch die Kodierung des Dokumentes mit Hilfe von Tags und der Beschreibung der
Präsentation der Tags durch DSSL erreicht.
• Unterstützung von Strukturinformationen -> Erfüllt
Die Document Type Definition ist die Beschreibung der Struktur eines Dokuments. Sie
kann im Dokument mitgesendet werden.
• Erweiterungsfähigkeit -> Erfüllt
Die SGML-Spezifikation kann nicht erweitert werden. Sie wird in den Standardisie-
rungsgremien gepflegt. Die Entwicklung und Erweiterung einer Document Type Definition
ist aber jederzeit möglich.
• Plattformunabhängigkeit -> Erfüllt
SGML ist mit dem Ziel entwickelt worden, Dokumente plattformübergreifend austauschen
zu können.
• Herstellerunabhängigkeit -> Erfüllt
Die Spezifikation von SGML wird in den Standardisierungsgremien durchgeführt. Eine
Herstellerabhänigkeit besteht nicht.

Austauschformate Seite 77
• Hohe Akzeptanz ->Teilweise erfüllt
SGML ist hauptsächlich im Bereich der plattformübergreifenden Dokumentenverarbeitung
und des Dokumenten-Managements bekannt. Besonders bei Regierungsunternehmen,
Behörden und Großkunden wird SGML sehr oft zur Erstellung und Pflege
von einheitlichen Dokumenten (z. B. Handbücher) genutzt. Verschiedene Benutzergruppen
versuchen die Entwicklung und Standardisierung von bestimmten Dokumententypen
(z. B. Dissertationen) voranzutreiben. Als Beispiel sei hier die Text Encoding
Initiative (TEI) angeführt. Im Office-Bereich ist SGML aufgrund der marktbeherrschenden
Stellung von proprietären Textverarbeitungsprogrammen weniger bekannt.
Zusammenfassung
Grundsätzlich ist die SGML-Sprache nicht für den Austausch von Daten konzipiert worden.
Aber die Flexibilität von SGML macht es möglich, ein Modell zu entwickeln, mit
dem Daten in Form von Dokumenten übermittelt werden können. Alle Anforderungen, die
zur Abbildung eines Message-Objekts notwendig sind, können mit Hilfe von SGML nachgebildet
werden. Die Konsistenz und die Redundanz der Daten werden durch die Verwen-
dung des DTD sichergestellt.
Anforderung Bewertung
Unterstützung einfacher Datentypen Erfüllt
Unterstützung komplexer Informationsfelder Erfüllt
Identifikation von Feldstrukturen Erfüllt
Trennung von Präsentation und Inhalt Erfüllt
Unterstützung von Strukturinformationen Erfüllt
Erweiterungsfähigkeit Erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Erfüllt
Hohe Akzeptanz Teilweise erfüllt
Tabelle 6: Bewertung des SGML-Formats
Somit kann mit SGML ein Datenaustausch zwischen heterogenen Workflow-Management-
Systemen realisiert werden.

Austauschformate Seite 78
4.2.7 Hyper Text Markup Language (HTML)
Historie
Die Hyper Text Markup Language (HTML) beruht auf einer Idee, die von Tim Berners-
Lee Ende der 80er Jahre vorgestellt wurde. Sie ist die Grundlage des World Wide Web-
Dienstes. Mit HTML können Dokumente über das Internet in einer plattform- und anwendungsunabhängigen
Weise übertragen werden.
Die erste offizielle Version wurde 1992 von der Internet Engineering Task Force (IETF)
als RFC 1866 veröffentlicht und erreichte in der Folgezeit eine weltweite Bedeutung für
die Informationsverteilung im Internet.
1997 wurde die bisher letzte Entwicklung in Form der Version 4.0 vom World Wide Web
Consortium (WWWC) veröffentlicht.
Technik
HTML nutzt die SGML-Idee des generischen Markups, d. h. mit Hilfe eines festgelegten
Satzes von Identifikationskennzeichen (engl. tags) werden die HTML-Dokumente gegliedert
und formatiert.
Die Benennung der Tags und ihr Funktionsumfang ist durch die Normungsgremien der
IETF und des WWWC festgelegt und kann nicht geändert werden, ohne daß die Grundfunktionalitäten
der eingesetzten Programme leidet.
Die Spezifikation von HTML umfaßt Kennzeichen für:
a) die Gliederung der Dokumente, z. B. , , ,
b) die Formatierung der Dokumente, z. B. = Fett , = kursiv
c) Hypertext-Mechanismen, z. B.
d) Formularfunktionalität, z. B.
HTML-Dokumente werden mit Hilfe des ASCII-Zeichensatzes kodiert. Innerhalb der Dokumente
können neben dem Text auch Bild-, Ton-, Video-Informationen enthalten sein,
die über Hypertext-Mechanismen zur Laufzeit vom Server geladen werden.
Die Entwicklung von HTML-Spezifikationen wird zwar von den Standardisierungsgremien
des WWWC durchgeführt. Doch führende Hersteller von HTML-konformer

Austauschformate Seite 79
Software (WWW-Server und Browser) haben in der Vergangenheit immer wieder eigene
Interpretationen und Erweiterungen in den HTML-Funktionsumfang und ihre Software
eingebracht. Somit kann nicht mehr von einer hundertprozentigen Plattformunabhängigkeit
gesprochen werden. Die Gründe dafür waren einerseits fehlende Funktionen (z. B. Rahmentechnologie)
zu implementieren und damit das Erlangen eines Marktvorteils gegenüber
Mitbewerbern. Andererseits ist die Weiterentwicklung des HTML-Standards in den Standardisierungsgremien
von IETF und WWWC ein langwieriger Prozeß.
Bewertung
• Unterstützung einfacher Datentypen ->Nicht erfüllt
Die HTML-Definition unterstützt keine einfachen Datentypen. Die Dateneingabe im
Rahmen der Formularverarbeitung beschränkt sich nur auf Zeichen.
• Unterstützung komplexer Informationsfelder ->Nicht erfüllt
Die Unterstützung komplexer Informationsfelder ist nicht in der Spezifikation der
HTML-Sprache enthalten.
• Identifikation von Feldstrukturen -> Teilweise erfüllt
Im Rahmen der Formularverarbeitung können die Felder benannt werden. Die Grund-
konzeption von HTML enthält jedoch keine klassischen Feldstrukturen.
• Trennung von Präsentation und Inhalt ->Nicht erfüllt
Die Präsentation und der Inhalt sind in HTML-Dokumenten eng verwoben, z. B.
Test der Textformatierung
bedeutet, daß der Text, der nach folgt, fett angezeigt wird. Die Definition, wie das
-Tag vom Formatierer zu interpretieren ist, kann nicht festgelegt werden, sondern
ist Bestandteil der HTML-Spezifikation.
• Unterstützung von Strukturinformationen ->Nicht erfüllt
Die HTML-Definition ist zwar von SGML abgeleitet, es ist jedoch nicht vorgesehen,
daß die Dokumente eine Definition ihrer Struktur enthalten. Selbst bei falsch kodierten
Dokumenten wird es der Software überlassen, wie die Dokumente behandelt werden.

Austauschformate Seite 80
• Erweiterungsfähigkeit -> Nicht erfüllt
Die Spezifikation von HTML kann nicht erweitert werden, die Entwicklung neuer Eigenschaften
und der dazugehörigen Tags obliegt dem WWWC.
• Plattformunabhängigkeit -> Teilweise erfüllt
Die Spezifikation der Sprache wird zwar von World Wide Web Consortium (W3C) gepflegt,
sie wird allerdings durch die Hersteller in ihrem Bestreben um Marktvorteile
immer wieder eigenmächtig erweitert. Dadurch ist eine Plattformunabhängigkeit nicht
mehr sichergestellt.
• Herstellerunabhängigkeit -> Teilweise erfüllt
In der Grundkonzeption ist HTML herstellerunabhängig. Die eigenmächtige Erweiterung
der Sprache im Kampf um Markvorteile hat die Herstellerunabhängigkeit aber
weitgehend unterhöhlt.
• Hohe Akzeptanz -> Erfüllt
Seit 1992 hat sich das Internet exponentiell vergrößert. Das WWW hat eine entsprechende
Akzeptanz in Bevölkerung und Wirtschaft erfahren und ist im Begriff, sich neben
den klassischen Mitteln der Informationsverteilung (Fernsehen, Zeitung, Rund-
funk) zu etablieren. In diesem Umfeld betätigen sich eine Vielzahl von Unternehmen
als Anbietern verschiedenster Werkzeuge und Dienstleistungen.
Zusammenfassung
Die Konzeption von HTML zielt in erster Linie auf die Informationsverteilung mit Hilfe
von Dokumenten ab.
Anforderung Bewertung
Unterstützung einfacher Datentypen Nicht erfüllt
Unterstützung komplexer Informationsfelder Nicht erfüllt
Identifikation von Feldstrukturen Teilweise erfüllt
Trennung von Präsentation und Inhalt Nicht erfüllt
Unterstützung von Strukturinformationen Nicht erfüllt
Erweiterungsfähigkeit Nicht erfüllt
Plattformunabhängigkeit Teilweise erfüllt
Herstellerunabhängigkeit Teilweise erfüllt
Hohe Akzeptanz Erfüllt
Tabelle 7: Bewertung des HTML-Formats

Austauschformate Seite 81
Eine Abbildung des Message-Objekts ist mit den vorhandenen Möglichkeiten und Eigenschaften
des HTML-Formats nicht möglich. So werden entscheidende Anforderung, z. B.
die Unterstützung einfacher Datentypen und komplexer Informationsfelder nicht erfüllt.
Eine Erweiterung des HTML-Formats ist nicht möglich, weil die Entwicklung des HTML-
Funktionsumfang in den Normungsgremien erfolgt.
Somit ist HTML nicht als Austauschformat für Message-Objekte geeignet.
4.2.8 Extensible Markup Language (XML)
Historie
Mitte 1996 gründete eine Gruppe von 80 SGML-Experten zusammen mit dem World Wide
Web Consortium eine SGML-Arbeitsgruppe unter der Führung von Jon Bosak (SUN Microsystems).
Ihr Ziel war es, eine Markup-Sprache zu entwickeln, welche die gleiche gene-
relle Verwendbarkeit wie SGML haben sollte. Zudem sollten bestehende Schwächen des
WWW-Dienstes überwunden und eine einfache Implementierung in die Strukur des
WWW-Dienstes ermöglicht werden.
Im November 1996 wurde der erste Entwurf der Extensible Markup Language (XML) auf
der SGML-Konferenz in Boston veröffentlicht. Nach der Publikation des zweiten Entwurfs
im April 1997 wurden Anfang Juli 1997 die Ergebnisse, gemäß den Richtlinien des World
Wide Web Consortiums, standardisiert. Zur gleichen Zeit wurde die SGML-Arbeitsgruppe
in die W3C-XML-Arbeitsgruppe überführt.
Seit dieser Zeit hat die Entwicklung von XML sowie die damit verbundenen Aktivitäten in
der EDV-Industrie und verschiedener XML/SGML-Arbeitsgruppen einen ähnlich stürmischen
Verlauf genommen wie 1992 das Internet und der World Wide Web-Dienst.
Technik
XML ist eine Untermenge der Standard Generalized Markup Language (SGML), d. h. die
Grundkonzepte von SGML (siehe Kapitel 4.2.6) wurden übernommen. Komplexe Spezifikationen,
die speziell zur Dokumentenerstellung in SGML enthalten sind, wurden auf das
notwendige Maß für den WWW-Dienst reduziert. Dieser Umstand kann am Umfang der
Spezifikationen sehr gut abgelesen werden. Die Definition von SGML umfaßt ca. 500
Seiten, während die XML-Spezifikation ca. 30 Seiten stark ist.

Austauschformate Seite 82
Mit XML werden einige Schwächen der HTML-Sprache überwunden, die bis heute eine
grundlegende Komponente des WWW-Dienstes sind. Sie liegen einerseits im eingeschränkten
Umfang der HTML-Tags und andererseits in der unzureichenden Möglichkeit,
die HTML-Sprache an individuelle Anforderungen anzupassen. Darüber hinaus sind in
HTML der Inhalt eines Dokumentes und die Layoutinformationen miteinander vermischt.
Diese können nun durch die Verwendung von XML und XSL getrennt behandelt werden.
Der XML-Standard wird nach Vollendung der Arbeiten 18 drei Teile umfassen:
• XML-Sprachdefinition
Die Definition der Grundkonzeption von XML.
• XML-Link:
Die Definition und die Konventionen für das Erstellen von Hyperlinks, z. B. das Linking
von Dokumenten innerhalb von XML-Dokumenten und über den WWW-Dienst.
• XSL:
Die Definition der Sprache mit der das Layout (Style) bestimmt werden kann. XSL ist
eine Untermenge der DSSL-Sprache.
XML ist eine Meta-Sprache, die auf der Idee des generischen Markups aufgebaut. Ebenso
wie mit SGML können die Tags und die Grammatik in einer Document Type Definition
definiert werden. Im Vergleich zu SGML sind die Regeln für das Erstellen einer XML-
konformen DTD jedoch erheblich vereinfacht worden.
Eine Neuerung von XML ist das Konzept des korrekten Aufbaus des Dokumentes (engl.
well formness) und die Einhaltung der Syntaxregeln (engl. validation). Enthält eine XML-
Dokument eine Document Type Definition oder den Verweis (engl. link) darauf, so kann
die lesende Anwendung (z. B. Parser) überprüfen, ob das Dokument gemäß den darin enthaltenen
Regeln erstellt wurde. Ohne die DTD kann überprüft werden, ob ein Anfangstag
immer ein Endtag besitzt und die Tags korrekt in der Tiefe geschachtelt sind. Durch diesen
Ansatz können Anwendungen, die nur eine kleine Anzahl von Tags benötigen, schnell und
einfach erstellt werden, ohne daß eine spezielle DTD entwickelt werden muß, wie dies die
SGML-Spezifikation vorschreibt.
18 Ein Teil der Spezifikationen liegt den Gremien als Entwurf vor und muß noch verabschiedet werden.

Austauschformate Seite 83
Aufgrund der verwandtschaftlichen Nähe zu SGML ist bereits eine große Anzahl von
SGML-Herstellern in der Lage, XML-Produkte anzubieten. Zusätzlich ist bereits mit der
Integration von XML-Funktionalitäten in die Software des WWW-Dienstes begonnen
worden.
Bewertung
• Unterstützung einfacher Datentypen -> Erfüllt
Die XML-Sprache unterstützt keine einfache Datentypen. Aber ebenso wie mit SGML
können durch die Entwicklung eines geeigneten Tag-Sets diese Datentypen abgebildet
werden, z. B.
Kunde
INTEGER
Reco GmbH
• Unterstützung komplexer Informationsfelder -> Erfüllt
XML hat standardmäßig keine Unterstützung komplexer Informationsfelder. Aber mit
den Mitteln von XML ist es möglich, eine solche Funktion durch die Entwicklung eines
geeigneten Tag-Sets abzubilden.
• Identifikation von Feldstrukturen -> Erfüllt
Durch die Freiheit bei der Entwicklung einer Struktur zur Abbildung von Variablen
kann eine Identifikation von Feldstrukturen ermöglicht werden. Die Identifikation
könnte durch eine Tag-Kombination (siehe oben) oder mit Hilfe von Attributen realisiert
werden, wie z. B.
Reco GmbH
• Trennung von Präsentation und Inhalt ->Erfüllt
Die XML-Definition sieht, ebenso wie SGML, die Trennung von Inhalt und Präsentation
vor. Dies wird durch die Kodierung des Dokumentes mit Hilfe von Tags und der
Beschreibung der Präsentation der Tags durch XSL erreicht.

Austauschformate Seite 84
• Unterstützung von Strukturinformationen -> Erfüllt
Die Document Type Definition definiert die Struktur eines Dokuments. Sie kann im
Dokument mitgesendet werden.
• Erweiterungsfähigkeit -> Erfüllt
Die XML Spezifikation kann nicht erweitert werden. Sie wird in den Standardisierungsgremien
gepflegt. Die Entwicklung und Erweiterung einer Document Type Definition
ist aber jederzeit möglich.
• Plattformunabhängigkeit -> Erfüllt
XML ist mit dem Ziel entwickelt worden, plattformunabhänig Daten in Form von Dokumenten
zu kodieren und austauschen zu können.
• Herstellerunabhängigkeit -> Erfüllt
Die Spezifikation von XML wird in den Standardisierungsgremien des World Wide
Web Consortium (WWWC) vorgenommen; eine Abhängigkeit von bestimmten Her-
stellern besteht nicht.
• Hohe Akzeptanz -> Erfüllt
Die weite Verbreitung des WWW und die Notwendigkeit die Nachteile der HTML-
Sprache mit Hilfe eines Standards zu überwinden, lassen XML für die Industrie als die
ideale Lösung erscheinen. Die Akzeptanz ist enorm hoch, was sich an der Beteiligung
führender Unternehmen (IBM, Microsoft, Oracle) und Arbeitsgruppen an der Entwicklung
der XML-Sprache in den Standardgremien ablesen läßt. Die Verfügbarkeit
von Produkten, die XML unterstützen ist bereits in diesem frühen Stadium der XML-
Entwicklung sehr hoch.
Zusammenfassung
Ebenso wie SGML ist die XML-Sprache nicht mit den notwendigen Anforderungen für die
Übertragung des Message-Objekts ausgestattet. Die Flexibilität von XML erlaubt es jedoch,
durch die Entwicklung eines geeigneten Tag-Sets diese Anforderungen nachzubilden.

Austauschformate Seite 85
Anforderung Bewertung
Unterstützung einfacher Datentypen Erfüllt
Unterstützung komplexer Informationsfelder Erfüllt
Identifikation von Feldstrukturen Erfüllt
Trennung von Präsentation und Inhalt Erfüllt
Unterstützung von Strukturinformationen Erfüllt
Erweiterungsfähigkeit Erfüllt
Plattformunabhängigkeit Erfüllt
Herstellerunabhängigkeit Erfüllt
Hohe Akzeptanz Erfüllt
Tabelle 8: Bewertung des XML-Formats
Somit kann auf der Basis von XML der Datenaustausch mittels Message-Objekten zwischen
heterogenen Workflow-Management-Systemen realisiert werden.
Nach Abschluß der Untersuchungen der potentiell geeigneten Kandidaten für die Realisie-
rung des Datenaustauschs mit Message-Objekten zwischen heterogenen weitverteilten
Workflow-Management-Systemen, werden im folgenden Abschnitt die Ergebnisse zu-
sammengefaßt und eine Auswahl des geeigneten Kandidaten für die prototypische Realisierung
vorgenommen.

Austauschformate Seite 86
4.3 Abschlußbetrachtung und Auswahl geeigneter Formate
Grundlage der Untersuchungen waren die Anforderungen, die im Kapitel 4.1 aufgestellt
wurden. Diese resultierten aus den Überlegungen hinsichtlich der Abbildung und des
Transports der Message-Objekten mittels der Lotus Compound Document-Struktur, Gedanken
zur Sicherheit und der Interoperabilität von heterogenen Systemen. Zusätzlich
wurden die Anforderungen in notwendige und optionale Anforderungen (siehe Abbildung
31) kategorisiert. Die Kategorisierung orientierte sind daran, ob eine Anforderung unbedingt
erfüllt sein muß, um das Ziel (Abbildung und Transport des Message-Objekts) zu
erreichen. Die Anforderungen, die nur die spätere Entscheidungsfindung unterstützen,
wurden als optional eingestuft.
Anforderung Zum Erreichen des Ziels
Unterstützung einfacher Datentypen Notwendig
Unterstützung komplexer Informationsfelder Notwendig
Identifikation von Feldstrukturen Notwendig
Trennung von Präsentation und Inhalt Notwendig
Unterstützung von Strukturinformationen Notwendig
Erweiterungsfähigkeit Optional/Notwendig
Plattformunabhängigkeit Optional
Herstellerunabhängigkeit Optional
Hohe Akzeptanz Notwendig
Abbildung 31: Anforderungstabelle
Ein Sonderstellung nimmt hierbei die Anforderung Erweiterbarkeit ein. Sie ist optional,
wenn ein Format bereits alle notwendigen Anforderungen erfüllt. Falls dies nicht der Fall
ist, muß das Austauschformat erweiterbar sein, um notwendige Anforderungen realisieren
zu können.
In einer Vorauswahl der potentiell geeigneten Kandidaten wurden solche ausgewählt, die
für den Transport von Objekten (Dokumenten, Daten, Nachrichten) schon definiert waren.
Zudem verfügten alle über einen entsprechenden Bekanntheitsgrad aufgrund ihres Status
als Norm oder Industriestandard.
Falls kein untersuchtes Austauschformat geeignet sein sollte, so wurden vorbeugend Sprachen
zur Definition von Austauschformaten in die Untersuchung aufgenommen

Austauschformate Seite 87
Für die Untersuchung wurden folgende Formate und Definitionssprachen ausgewählt:
• Rich-Text-Format (RTF)
• Portable Document Format (PDF)
• Elektronic Data Interchange for Administration and Transport (EDIFACT)
• Mulitpurpose Internet Mail Extension (MIME)
• Open Document Architecture (ODA)
• Hyper Text Markup Language (HTML)
• Standardard Genealized Markup Language (SGML) und
• Extensible Markup Language
Die nachfolgende Abbildung zeigt die Zusammenfassung aller Bewertungstabellen der
Untersuchung:
Format RTF PDF
Unterstützung einfacher
Datentypen
Unterstützung
komplexer Informationsfelder
Identifikation von
Feldstrukturen
Trennung von Präsentation
und Inhalt
Unterstützung von
Strukturinformationen
Austauschformate
EDI-
FACT
Definitionssprachen
MIME ODA HTML SGML XML
+ + 0 0 + - + +
- - - 0 - - + +
0 + - 0 + 0 + +
- + - 0 + - + +
- 0 - 0 0 - + +

Austauschformate Seite 88
Erweiterungsfähigkeit
Plattformunabhängigkeit
Herstellerunabhängigkeit
- + 0 0 0 - + +
0 + + + + 0 + +
- - + + + 0 + +
Hohe Akzeptanz 0 + + + - + 0 +
Legende: - = Nicht erfüllt 0 = Teilweise erfüllt + = Erfüllt
Tabelle 9: Bewertungsübersicht der untersuchten Formate und Definitionssprachen
Die Untersuchung zeigte, daß kein Austauschformat zur Abbildung eines Message-Objekts
geeignet ist. Dies ist hauptsächlich dadurch zu begründen, daß die Austauschformate immer
auf die speziellen Anforderungen der zu transportierenden Objekte hin konzipiert
wurden. Die untersuchten Austauschformate haben deshalb Stärken und Schwächen hin-
sichtlich der Eignung als Austauschformate für Message-Objekte. So wurden beispielsweise
einfache Datentypen immer nur dann unterstützt, wenn sie zur Beschreibung von Attributen
(ODA, PDF) benötigt wurden, die für das Objekt wichtige Informationen transportieren
sollten.
Die Unterstützung komplexer Informationsfelder war in keinem Format vorgesehen, weil
die Objekte (z. B. EDIFACT-Nachrichten, Word-Dokumente, PDF-Dokumente) grundsätzlich
keine solche spezielle Funktionalität benötigten.
Ein Sonderstellung nimmt MIME ein. Es könnte durch Eigenentwicklungen um notwendige
Funktionalitäten zur Abbildung der Message-Objekte erweitert werden, da es aufgrund
seines Designs zum generellen Transport von Objekten konzipiert wurde.
Die in die Untersuchung mit einbezogenen Sprachen zur Definition von Austauschformaten
(SGML, XML) könnten jedoch alle notwendige Anforderungen (siehe Tabelle) erfüllen,
wenn damit ein eigenentwickeltes und vorerst proprietäres Austauschformat realisiert

Austauschformate Seite 89
würde. Dem proprietären Format würde aber die notwendige Plattformunabhängigkeit,
Herstellerunabhängigkeit und somit auch die Akzeptanz fehlen. Dieser Nachteil wird aber
dadurch kompensiert, daß mit diesen standardisierten Sprachen universelle Werkzeuge zur
Verfügung stehen, die über die notwendige Unabhängigkeit und Akzeptanz verfügen. Sie
sind mit der standardisierten Programmiersprache C vergleichbar, die als kleinster gemeinsamer
Nenner für die plattformübergreifende Realisierung von Programmen gilt und über
eine hohe Akzeptanz verfügt.
Ein weiterer Vorteil gegenüber MIME ist, daß SGML und XML Strukturinformationen,
die bereits in der Spezifikation der Sprachen vorgesehen sind, über den zulässigen Aufbau
des Formats mitliefert. Dies erlaubt eine Überprüfung des Inhalts eines kodierten Message-
Objekts auf Vollständigkeit und Richtigkeit. Zudem besitzen beide Sprachen die Möglich-
keit, Inhalt und Präsentation voneinander getrennt zu behandeln. Dabei kann die prototypische
Implementierung eines Austauschformats durch kontinuierliche Weiterentwicklung in
eine professionelle überführt werden. MIME müßte um diese Funktionen zusätzlich erweitert
werden.
Für den Austausch der Message-Objekte wird deshalb die prototypische Entwicklung eines
Austauschformats mit Hilfe von XML vorgeschlagen. XML wird SGML vorgezogen, da
es ein effiziente Untermenge von SGML ist und über eine sehr hohe Akzeptanz in der Industrie
verfügt.
Im nächsten Kapitel werden die Konzeption eines Austauschformates auf Basis von XML
vorgestellt. Dieses Austauschformat wird im folgenden MOTF (Message Objekt Transport
Format) genannt. Zusätzlich wird die Funktionsweise anhand eines Prototypen demonstriert.

Konzeption und prototypische Implementierung Seite 90
5 Konzeption und prototypische Realisierung
Nach der Untersuchung und Bewertung potentieller Austauschformate im vorangegangen
Kapitel und der Entscheidung ein eigenes Austauschformat zu entwickeln, wird im folgenden
Kapitel die Definition des Austauschformats MOTF (Message Objekt Transport Format)
mit XML und seine Funktionsweise innerhalb der WAGS-Systemumgebung durch
eine prototypische Implementierung dargestellt.
Im Rahmen dieser Darstellung werden in einem Fallbeispiel WAGS-Message-Objekte in
einem aktiven Workflow-Prozeß zwischen zwei Unternehmen ausgetauscht. Dazu wird ein
ausgehendes Message-Objekt, das auf der Basis der Lotus Notes Compound Document-
Struktur realisiert ist, in das Austauschformat umgewandelt. Ebenso wird anhand einer
eingehenden E-Mail, die ein in MOTF kodiertes Message-Objekt enthält, die Konvertie-
rung in ein Lotes Notes-konformes WAGS-Message-Objekt demonstriert.
Für den Umwandlungsprozeß wird ein Konverter benötigt, der die Message-Objekte bear-
beiten kann. Zusätzlich muß für das Austauschformat eine Document Typ Definition entwickelt
werden, welche die vorgegebene Struktur des Message-Objekts abbildet.
5.1 Konzeption
Die prototypische Realisierung wird innerhalb des WAGS-Systems durchgeführt, dessen
Konzeption und Architektur im Kapitel 3.2 erläutert wurde.
Für die prototypische Realisierung werden folgende Annahmen und Anforderungen definiert:
1. Für das Austauschformat MOTF wird eine Document Type Definition benötigt. Die
Entwicklung der XML Document-Type-Definition sollte sich an der vorgegebenen
Struktur der Definition von Message-Objekten von Dietmar Saliger [Saliger 1998,
S.106] orientieren.
2. Der Konverter sollte innerhalb der Gateway-Datenbank implementiert werden, weil die
Formatumwandlungen der Message-Objekte ein Teilprozeß der Gateway–Bearbeitung
ist.
3. Der Konverter sollte die WAGS Message-Objekte in das Austauschformat konvertieren
können.

Konzeption und prototypische Implementierung Seite 91
4. In eingehenden E-Mails sollte das Austauschformat erkannt werden sowie die Daten
extrahiert werden können.
5. In Hinblick auf allgemeine Verwendbarkeit sollte der Konverter so beschaffen sein,
daß auch weitere Formate verwendet werden können.
5.1.1 Architektur des Konverters
Der Konverter ist Bestandteil der Gateway-Datenbank und wird im Laufe der Bearbeitung
der Message-Objekte durch Verarbeitungsroutinen aktiviert. Er besteht aus einem Umwandlungsmodul
OUT für ausgehende Message-Objekte und einem Umwandlungsmodul
IN für eingehenden Message-Objekte (siehe Abbildung 31).
Die Umwandlungsmodule (IN/OUT) sind modular aufgebaut. Jedes Formatmodul (XML,
SGML, MIME) könnte deshalb unabhängig von der Gesamtfunktionalität entwickelt und
in den Konverter integriert werden.
OUT
IN
Basistools
XML
SGML
MIME
andere
Abbildung 32: Architektur des Konverters
Für alle Formate wird eine Funktion zum Erstellen des Formats (Builder) und eine Funktion
zum Lesen und Analysieren (Parser) des Datenstroms benötigt. Sowohl der Builder als
auch der Parser für XML wurden mit Hilfe der Programmiersprache Lotus Script realisiert.
Parser und Builder können später eventuell durch professionelle externe Programme von
Drittanbietern ersetzt werden.
Für die Umwandlung der Notes-konformen Message-Objekts in MOTF wurden String-
Funktionen zum Auslesen und Erstellen von Rich-Text-Feldern benötigt. Für die Rück-

Konzeption und prototypische Implementierung Seite 92
umwandlung der in MOTF kodierten empfangenen Message-Objekte wurden Funktionalitäten
aus dem Bereich der Feld-, Zeichen- und Rich-Text-Feldbearbeitung benötigt. Sie
sind entweder Bestandteil von Lotus Script, z. B. String-Operationen, oder wurden mit
Hilfe von Lotus Script als Funktionen, z. B. Herausfiltern von Schlüsselwörtern aus einer
Zeichenfolge, programmiert.
Die Bearbeitung der Rich-Text-Felder, insbesondere das Auslesen und Analysieren der
Inhalte, ist in Lotus Script noch nicht ausreichend implementiert. Es fehlen Funktionen, die
das Extrahieren weitergehender Informationen, wie z. B. Formatierung des Textes, Bildinformationen
etc., erlauben. Aufgrund der Komplexität dieser Aufgabe wurde auf eine Eigenentwicklung
verzichtet. Die Umwandlung der Rich-Text-Felder beschränkt sich deshalb
auf die unformatierten ASCII-Texte.
5.1.2 Definition des Austauschformats mit Hilfe der Document Type Definition
Die Entwicklung der Struktur der Document Type Definition für das Austauschformat
MOTF richtet sich nach der Definition des Message-Objekts von Dietmar Saliger [Saliger
1998, S.106] (siehe Anhang 8.2).
Die Definition des Message-Objekts (siehe Abbildung 33) ist schematisch wie folgt aufgebaut:
Header
Workflow-
Steuerungs-
Daten
Content
Block 1
Block 2
Block n
Variable 1
Variable 2
Variable n
Name
Typ
Inhalt
Abbildung 33: Schematische Darstellung der Message-Objekt-Struktur
1. Die für die E-Mail notwendigen Felder werden im Header-Bereich definiert. Sie bestehen
aus der Empfänger-Adresse und dem Betreff.

Konzeption und prototypische Implementierung Seite 93
2. Im Workflow-Steuerungs-Datenbereich werden die Felder definiert, die für die Verwaltung
des Workflows wichtig sind.
3. Der Content-Bereich enthält die Content-Blöcke. Die einzelnen Variablen werden mittels
einer Meta-Struktur (Generic_Name_X, Generic_Typ_X, Generic_Body_X) beschrieben.
Aus dem Namen eines Content-Blocks (Generic_Block_X) und dem Meta-
Variablennamen (Generic_Name_X) wird der Variablenname gebildet.
Beispiel:
Variable Inhalt
Generic_Block_1 Kunde
Generic_Name_1 Name
Generic_Typ_1 TXT
Generic_Body Reco GmbH
Aus diesen Informationen kann die Variable: „Kunden_Name“ mit dem Feldinhalt
„Reco GmbH“ vom Datentype Text erstellt werden.
Diese Struktur wurde in eine entsprechende XML-konforme Document Type Definition
(DTD) überführt. Ein XML-Parser kann mit Hilfe dieser DTD die notwendigen Überprü-
fungen auf Vollständigkeit der Struktur und Korrektheit der Syntax vornehmen.
Die DTD besteht aus vier Definitionsbereichen (siehe Abbildung 33).
1. Strukturbeschreibung des Message-Objekts
Mit dem Eintrag „“
wird die Grobstruktur des XML-Objekts festgelegt. Dadurch wird sichergestellt, daß
die definierten Elemente vorhanden sind und die Reihenfolge eingehalten wird. Enthält
ein XML-Dokument eine falsche Reihenfolge oder ist ein Feld nicht vorhanden, so
wird ein XML-Parser den Validierungsprozeß mit einer Fehlermeldung abbrechen.
2. Bereich für die Workflow-Felder (Declaration of Workflowfields)
Dieser Bereich enthält die Definition der Felder, die für die Steuerung des Workflows
notwendig sind, z. B. messageobjektid. Durch den Eintrag „(#PCDATA)“ wird festgelegt,
daß das Feld nicht weiter untergliedert wird, sondern die Daten in Form von Zeichen
enthält.

Konzeption und prototypische Implementierung Seite 94
3. Bereich der Content-Blöcke (Declaration of Contentblocks)
Die Definition des Content-Blocks enthält eine oder mehrere Variablen, die zu diesem
Block gehören. Mit der Definition
„
wird festgelegt, daß jeder Block ein Identifikations-Attribut (ID) enthalten kann. Das
ID-Attribut „name“ wird zur Bildung des Variablennamens genutzt.
4. Bereich der Variablen-Definition (Declaration of Variable)
In diesem Bereich werden die Variablen abgebildet. Jede Variable wird durch die Meta-Struktur
(vartype, varhelp, varbody) beschrieben. Für die Bildung des Variablennamens
muß jede Variablendefinition das Identifikations-Attribut „name“ enthalten.
me,mocode,moconcerning,mocontentblocks,modbapplid,modbapp
lmail,modbgatewaymail,moleafid,momailtype,momessageobject
id,momessagereferenceid,momessagereplyto,moprocessid,mowo
rkflowid,momessagetype,contentblock?) >
name ID #IMPLIED>
name ID #REQUIRED>
Abbildung 34: Document Type Definition

Konzeption und prototypische Implementierung Seite 95
5.2 Prototypische Realisierung
In diesem Abschnitt wird anhand eines Fallbeispiels die Umwandlung eines ausgehenden
Notes-konformen Message-Objekts in das Austauschformat MOTF sowie die Rückumwandlung
eines eingehenden Message-Objekts demonstriert.
5.2.1 Fallbeispiel
In dem nachfolgenden Fallbeispiel wird von der Stadt Emmerich ein Projekt durchgeführt,
bei dem eine Containeranlage (Bürokomplex) benötigt wird. Als Anbieter von Bürocontainern
wird der Reco GmbH im Laufe des Projekts ein Message-Objekt mit den notwendigen
Informationen zugeleitet und in das lokale Workflow-System eingespielt. Nach der
Bearbeitung durch die Reco GmbH werden die neuen Informationen wieder an die Stadt
Emmerich zurückgeleitet [vgl. Saliger 1998 S. 74].
Workflow-Abonnent (Stadt Emmerich) Workflow-Anbieter (Reco GmbH)
Projekt
spezifizieren
Angebot
prüfen
Projekt
abschließen
Prozeß:
Planung
Containeranlage
in
out
Angaben
prüfen
Kostenvoranschlag
erstellen
Angebot
erstellen
Angebot
versenden
in
out
Bestellung
aufnehmen
Produktion
informieren
Auftragsbestätigung
versenden
Abbildung 35: Fallbeispiel [vgl. Saliger 1998, S. 74]
5.2.2 Behandlung eines ausgehenden Message-Objekts
Prozeß:
Angebot
erstellen
(Reco GmbH)
Prozeß:
Bestellung
(Reco GmbH)
Nachdem das Projekt als Instanz in der Workflow-Umgebung gestartet und die Projektdaten
innerhalb des ersten Bearbeitungsschritts eingegeben wurden, sollen diese Projektdaten
und die Workflow-relevanten Daten an die Zielumgebung (Reco GmbH) gesendet werden.

Konzeption und prototypische Implementierung Seite 96
Dazu wird von der WAGS Engine mittels des Content-Managements (siehe Kapitel
3.2.2.1) eine inhaltliche Filterung der Daten vorgenommen und das erzeugte Message-
Objekt von der Applikationsumgebung in die Gateway-Datenbank weitergeleitet. [vgl.
Saliger 1998, S. 75 ff]. Zum Zeitpunkt des Eintreffens in der Gateway-Datenbank befindet
sich das WAGS Message-Objekt noch in der Lotus Notes Compound Document-Struktur.
Die Gateway-Datenbank hat bei ausgehenden Message-Objekten die Aufgaben
• die Message-Objekte auf Vollständigkeit zu prüfen,
• aus dem External Directory die zur Weiterleitung notwendigen Informationen (Kom-
munikationskanal, Globale Routing Information) zu entnehmen,
• die internen Identifikationsmerkmale zu entfernen,
• die Trackinginformationen zu verarbeiten,
• die Formatkonvertierung (z. B. XML etc.) aufgrund der Kommunikationskanal-
Information durchzuführen
• und das ordnungsgemäß bearbeitete Objekt mit Hilfe der E-Mail-Komponenten von
Lotus Notes an den Adressaten weiterzusenden.
Diese Aufgaben werden durch einen Server Agenten (Incoming Mail) durchgeführt. Dieser
Hintergrundprozeß wird periodisch aktiviert und sammelt alle unbehandelten Lotus Notes
Dokumente (Message-Objekte und E-Mails) in einer Bearbeitungstabelle. Durch die Auswertung
der im Message-Objekt enthaltenen Statusfelder entscheidet der Prozeß, ob es sich
um ein ausgehendes oder eingehendes Message-Objekt handelt.
Im vorliegenden Fall handelt es sich um ein ausgehendes Message-Objekt. Der Server Agent
analysiert den Kommunikationskanal, erhält die Information „XML“ und übergibt das
Message-Objekt an den XML-Konverter.
Die nachfolgende Abbildung zeigt ausschnittsweise die in einem Message-Objekt enthaltenen
Workflow-Steuerungsfelder (z. B. moProcessID) und Content-Block-Datenfelder
(z. B. Generic_Block_1, Generic_Name_1) vor der XML-Umwandlung. Im linken Bereich
der abgebildeten Fenster sind die Feldnamen aufgeführt, im rechten der Inhalt des schwarz
markierten Feldes.

Konzeption und prototypische Implementierung Seite 97
Abbildung 36: Message-Objekt vor der XML-Umwandlung
Der XML-Konverter erzeugt nun im ersten Schritt ein Rich-Text-Feld mit dem Namen
Body. Dieses Feld ist der Container für das XML-Dokument und Bestandteil der E-Mail,
die an die Partnerorganisation gesendet wird. Daran anschließend werden mittels Rich-
Text-Feld-Operationen die grundlegenden XML-Informationen in das Feld eingefügt.

Konzeption und prototypische Implementierung Seite 98
Nach Abschluß des ersten Schritts enthält das Feld folgende Informationen:
Im zweiten Schritt werden gemäß der Document Type Definition die Workflow-
Steuerungsfelder konvertiert. Dazu werden die einzelnen Felder aus dem Message-Objekt
ausgelesen und im Body-Feld mit Hilfe von String-Operationen in die entsprechende Reihenfolge
überführt, z. B.
2296232376A8B008C12565BB0049C415.
Im dritten Schritt werden die einzelnen Content-Blöcke bearbeitet. Beginnend mit dem
Feld „Generic_Block_1“ wird die Bezeichnung des ersten Content-Blocks entnommen und
zum Body-Feld hinzugefügt. Enthält das Feld „Generic_Block_1“ die Information „Kunde“
(siehe zweites Fenster der Abbildung 36), so ist das Ergebnis der Umwandlung:
Im vierten Schritt werden die Variablen umgewandelt, die zu einem Content-Block gehö-
ren.
[txt]
Name der Kundenadresse
Stadt Emmerich
Der vierte Schritt wird durch eine Schleifenoperation so lange wiederholt, bis keine Variablen
für den Content-Block vorhanden sind. Der Content-Block wird dann im Body-Feld
durch die Einfügung
abgeschlossen.
Wenn keine weiteren Variablen mit dem Name „Generic_Block_x“ (x >0) existieren, wird
als letzte Operation der Eintrag

Konzeption und prototypische Implementierung Seite 99
im Body-Feld eingetragen. Damit endet die Umwandlung des Message-Objekts in MOTF.
Nach Abschluß der Konvertierung (siehe Abbildung 37) enthält das Body-Feld nun alle
relevanten Felder des Message-Objekts in der entsprechenden MOTF-Struktur. Im Anhang
8.3 ist ein vollständiger Ausdruck des Body-Felds zu finden.
Abbildung 37: Message-Objekt nach der XML-Umwandlung
In der nachfolgenden Abbildung wird der Inhalt des Body-Felds mit Hilfe des Javabasierten
XML-Viewers von Microsoft [Microsoft 1998] dargestellt. Dies zeigt exempla-
risch, daß das Message-Objekt außerhalb des WAGS-Systems verarbeitet werden kann.
Der XML-Viewer nutzt zur Auswertung der XML-Struktur einen vollständig implemen-
tierten XML-Parser, der ebenso mit Java programmiert wurde. Im ersten Teil der Abbildung
sind die Workflow-Steuerungsinformationen zu sehen. Im zweiten Teil der Abbil-
dung werden die Strukturen eines Content-Blocks mit den dazugehörigen Variablen dargestellt.
Mit Hilfe eines solchen XML-Parsers könnten so die Daten auf anderen Plattformen extrahiert
werden.

Konzeption und prototypische Implementierung Seite 100
Abbildung 38: Darstellung eines XML-Message-Objekts

Konzeption und prototypische Implementierung Seite 101
5.2.3 Annahme und Auswertung eines eingehenden Message-Objekts
Hat die Reco GmbH ihrerseits nun den internen Prozeß abgearbeitet, so wird ein entsprechendes
in MOTF-kodiertes Message-Objekt erstellt und mittels E-Mail in die Gateway-
Datenbank der Stadt Emmerich übermittelt.
Der Server-Agent (Incoming Mail) untersucht nun alle eingegangenen E-Mail-Objekte
hinsichtlich ihrer Eigenschaften. Enthält das Objekt keine Notes-konformen Merkmale
(z. B. „FORM“-Feld), so wird eine Formatumwandlung vorgenommen. Dazu wird das
Objekt an den Konverter übergeben.
In der nachfolgenden Abbildung zeigt das, für die Rückumwandlung relevante Feld Body,
das Bestandteil der eingegangenen E-Mail ist.
Abbildung 39: XML-Message-Objekt vor der Umwandlung
Der Konverter extrahiert aus dem Objekt das Body-Feld in ein temporäres Text-Feld und
untersucht es hinsichtlich formatspezifischer Kennzeichen (z. B. XML, MIME, SGML).
Im vorliegenden Fall wird das Kennzeichen „XML“ gefunden und das temporäre Feld wird
an das XML-Formatmodul übergeben.
Aus diesem Feld erstellt der Parser eine eindimensionale Tabelle, die einerseits die Kennzeichen
(engl. tags) enthält, andererseits aber auch die Daten (siehe Abbildung 40). Dazu
wird eine zeichenweise Auswertung des Datenstroms vorgenommen und die Struktur hinsichtlich
der Kombination von „“untersucht.

Konzeption und prototypische Implementierung Seite 102
Abbildung 40: Tabelle der XML-Elemente
Aus dieser Tabelle können dann die Feldinformationen gewonnen und das Message-Objekt
aufgebaut werden.
Die Tabelle wird dazu folgendermaßen ausgewertet:
1. Analyse und Auswertung der XML-Anweisungen, z. B. ?XML Version „1.0“?
2. Analyse und Umwandlung der Workflow-Steuerungsfelder (z. B. mocode). Diese Felder
werden als Notes-Felder an die bestehende E-Mail angehängt.
3. Durchsuchen der Tabelle auf Content-Block-Strukturen. Der Beginn eines Content-
Blocks wird durch die Kennung „contentenblock name=“xxxxx“ gekennzeichnet. Aus
diesem Eintrag wird die ID des Content-Blocks in das entsprechende Notes-Feld (Generic_Block_x)
übertragen.
4. Umwandlung der Variablen in Lotus Notes Felder und Übertragung der Dateninhalte,
die zu einem Content-Block gehören.
5. Die Schritte 3 und 4 werden so lange wiederholt, bis das Ende der Tabelle erreicht
wurde.
Nach erfolgreicher Umwandlung sind alle Informationen aus dem XML-Dokument extrahiert
und als Notes-Felder an die E-Mail angehängt (siehe Abbildung 41). Damit das

Konzeption und prototypische Implementierung Seite 103
E-Mail-Objekt weiterverarbeitet werden kann, wird abschließend das Form-Feld erzeugt
und an das Objekt angehängt.
Abbildung 41: E-Mail-Objekt nach der XML-Konvertierung
Damit ist die Arbeit des XML-Formatmoduls abgeschlossen, und die Verarbeitung des
Notes-konformen Message-Objekts wird fortgeführt.
Das Message-Objekt wird dabei einer Sicherheitskontrolle und Vollständigkeitsüberprüfung
unterzogen. Aus dem External Directory werden die Internal Routing Informationen
(IRI) entnommen. Die Tracking Informationen werden verarbeitet. Im Fehlerfall wird eine
entsprechende Behandlung des Objekts vorgenommen (z. B. Information der Verantwortlichen).
Andernfalls wird das Message-Objekt an die Applikationsdatenbank weitergeleitet
und mit dem nächsten unbearbeiteten Eintrag in der Bearbeitungstabelle fortgefahren. Ist
kein weiterer Eintrag mehr in der Bearbeitungstabelle enthalten, wird der Server-Agent
von Lotus Notes in den Wartezustand zurückversetzt.

Konzeption und prototypische Implementierung Seite 104
In diesem Kapitel wurde die Konzeption des Austauschformates MOTF und seine prototypische
Realisierung in der WAGS-Umgebung gezeigt. Dazu wurden entsprechende Konzeptionen
hinsichtlich des Konverters und des XML-Formats getroffen und die Architektur
des Konverters sowie die Struktur der XML Document Type Definition für das Austauschformat
erläutert.
Mit zwei Fallbeispielen wurde die Funktionsweise des MOTF-Formats anhand eines Prototyps
demonstriert. Dazu wurde ein Lotus Notes-konformes WAGS-Message-Objekt, das
an eine andere Organisation gesendet werden sollte, aufgrund der Informationen aus dem
External Directory an das XML-Formatmodul weitergeleitet. Innerhalb des Formatmoduls
wurde dann gezeigt, wie die Felder des Notes-konformen Message-Objekts ausgelesen und
in ein MOTF-Dokument umgewandelt wurden. Gleichfalls wurde anhand eines eingegan-
genen E-Mail-Objekts demonstriert, wie die Erkennung des Formats erfolgte und die Konvertierung
des in MOTF-kodierten Message-Objekts in ein Lotus Notes-konformes
WAGS-Message-Objekt funktionierte.
Nachfolgend wird die Leistung des Austauschformates und seiner prototypischen Imple-
mentierung einer kritischen Betrachtung unterzogen.
5.3 Kritische Betrachtung des Prototyps
Der Prototyp des Konverters wurde nur als „proof of principle“ für das XML Austauschformat
MOTF implementiert. Die Ergebnisse der Untersuchung aus Kapitel 4 ergaben, daß
SGML und MIME ebenfalls als Basis für Austauschformate geeignet sind. Deshalb wurden
bei der Programmierung des Konverters die Erkennung anderer Formate und die Wei-
terleitung der Format-Dokumente an die entsprechenden Format-Module berücksichtigt.
Der Parser, der im XML-Formatmodul zum Einsatz kommt, ist nach der XML-
Spezifikation nicht vollständig implementiert. So kann nicht überprüft werden, ob ein
XML-Dokument korrekt aufgebaut ist (Wellformness). Ebenso kann zur Zeit nicht sichergestellt
werden, daß ein XML-Dokument gemäß den Syntax-Regeln der Document Type
Definition für XML-Dokumente erstellt wurde. Das Problem könnte durch die Verwendung
von frei erhältlichen Java-Parsern (Microsoft, IBM etc.) gelöst werden. Die Einbindung
solcher Programme innerhalb der Programmierumgebung von Lotus Notes ist grund-

Konzeption und prototypische Implementierung Seite 105
sätzlich möglich, scheitert aber zur Zeit noch an der unzureichenden Unterstützung von
Java durch Lotus Notes.
Ein weiteres Defizit ist die Konvertierung der Rich-Text-Felder von Lotus Notes. Diese
Felder zeichnen sich durch ihre hohe Leistungsfähigkeit hinsichtlich der Aufnahme von
unstrukturierten Daten (formatierter Text, Bilder, Ton- und Videosequenzen, Hyperlinks
etc.) aus. Die Felder besitzen deshalb einen sehr komplexen Aufbau. Die Lotus Script
Sprache stellt aber nur eingeschränkt Funktionen zur Bearbeitung der Rich-Text-Felder zur
Verfügung. So können bereits mit den vorhandenen Lotus Script-Befehlen unformatierter
Text sowie Dateianhänge eines Rich-Text-Felds extrahiert werden. Das Analysieren und
Verwalten der Zusatzinformationen über Aufbau und Anordnung der Rich-Text-Felder ist
jedoch nicht möglich. Dadurch wird der Umfang der Konvertierung von Rich-Text-Feldern
erheblich gemindert. Die Suche nach Programmbibliotheken mit entsprechender Funktionalität
blieb erfolglos. Auf eine Eigenentwicklung wurde an dieser Stelle verzichtet. Sie
hätte den Rahmen dieser Diplomarbeit mit ihrer prototypischen Implementierung gesprengt.
Die Entwicklung der Document Type Definition (DTD) orientierte sich an der Definition
des Message-Objekts von Dietmar Saliger [Saliger 1998, S. 106], dem Aufbau der
Compound Document-Struktur und der Lotus Notes-Programmierumgebung. Das Ergebnis
zeigt, daß die Struktur des Message-Objekts nahezu vollständig übernommen werden
konnte. Im Austauschformat MOTF sind zur Zeit noch keine Strukturen enthalten, die zur
Aufnahme der Daten aus Rich-Text-Feldern geeignet sind. Weiterhin können grundlegende
Bestandteile der Lotus Notes Compound Document-Struktur, wie z. B. Formulare,
Zugriffslisten, digitale Signaturen etc. noch nicht konvertiert werden. Durch die Flexibilität
und Erweiterbarkeit der XML Document-Type-Definition ist es aber möglich, diese Funktionen
durch zukünftige Entwicklungen zu implementieren.

Zusammenfassung und Ausblick Seite 106
6 Zusammenfassung und Ausblick
Im Rahmen dieser Arbeit wurde die Aufgabenstellung bearbeitet, standardisierte Austauschformate
zu untersuchen und auszuwählen, die für den Datenaustausch, basierend auf
Informationscontainern, zwischen heterogenen weitverteilten Workflow-Management-
Systemen geeignet sind. Zusätzlich wurde eine prototypische Kommunikation auf der Basis
des WAGS-Informationscontainers (Message-Objekte) mit Hilfe eines Austauschformats
realisiert.
Die Arbeit beginnt mit einer Einführung in das Themengebiet und einer Einordnung der
Workflow-Management-Thematik in die CSCW-Forschung. Die notwendigen Begriffe für
diese Arbeit sowie andere Ansätze zum weitverteilten Workflow-Management in heterogenen
Umgebungen werden im Rahmen des Grundlagenkapitels 2 vorgestellt. Die Arbeitsumgebungen
Lotus Notes und das Wide Area Groupflow System werden in dem darauffolgenden
Kapitel 3 beschrieben und grundlegend eingeführt.
Die Definition der Anforderungen zur Abbildung von WAGS-Message-Objekten, die Untersuchung
und Auswahl von geeigneten Implementierungsformaten in Kapitel 4 sowie die
prototypische Realisierung in Kapitel 5 bilden den Hauptteil dieser Arbeit.
Ein Ergebnis der Untersuchung ist, daß keines der untersuchten Austauschformate für den
Transport der Message-Objekte geeignet war. Die Gründe liegen einerseits im Design der
Formate, die ursprünglich speziell für die jeweils zu transportierenden Objekte (z.B. Do-
kumente, Daten, Nachrichten) konzipiert wurden. Sie sind deshalb nicht oder nur teilweise
in der Lage die notwendigen Anforderungen für die Abbildung von Message-Objekten zu
erfüllen. Andererseits ist die Idee, Workflow-Daten mit Hilfe von Message-Objekten zu
transportieren noch sehr neu und revolutionär. Infolge dessen ist zur Zeit der Bedarf der
Industrie noch nicht groß genug, ein standardisiertes Austauschformat zu entwickeln, das
für den Transport solcher Informationscontainer geeignet ist.
Dennoch konnte die Aufgabenstellung durch die Entwicklung eines eigenen Austauschformats
MOTF (Message Objekt Transport Format) ansatzweise gelöst werden. MOTF
wurde mit der Extensible Markup Language (XML) realisiert, die für die Definition von
Austauschformaten vom World Wide Web Consortium entwickelt wurde.

Zusammenfassung und Ausblick Seite 107
Die Wahl fiel deshalb auf die XML-Sprache, weil sie sowohl ein verabschiedeter Standard
ist als auch Eigenschaften und Möglichkeiten besitzt, die es ermöglichen die definierten
Anforderungen zur Abbildung der Message-Objekte zu erfüllen. Ein weiterer wichtiger
Grund ist die stetig steigende Akzeptanz und große Unterstützung von XML durch führende
Hersteller und Arbeitsgruppen.
So wird XML bereits in den Produkten von SAP (SAP R/3), Oracle (Applicationserver),
Microsoft (Internet Explorer, Internet Information Server) und Netscape (Navigator), um
nur einige zu nennen, unterstützt, oder die Integration in die entsprechenden Produkte ist
angekündigt. Überdies gibt es große Bestrebungen, mit der Sprache XML standardisierte
Austauschformate für vielfältige Zwecke zu entwickeln. Die größten Hersteller von
Workgroup-Computing-Produkten (Lotus, Netscape, Microsoft) haben bereits gemeinsam
die Implementierung eines Formats zum Austausch von Kalenderinformationen (iCal) begonnen.
EDI-Arbeitsgruppen haben Vorschläge veröffentlicht, wie zukünftig EDI-Formate
mit XML transportiert werden könnten. Damit ist XML auf dem besten Wege, das bevorzugte
Werkzeug zur Entwicklung und Realisierung von Datenaustauschformaten zu wer-
den.
Die Entwicklung des MOTF-Formats mit XML ist zwar vorerst proprietär, jedoch kann
das Format aufgrund der Eigenschaften, Möglichkeiten und Flexibilität von XML jederzeit
an neue Anforderungen angepaßt werden. Deshalb sollte an der Entwicklung von MOTF
auch weiterhin gearbeitet werden, um die fehlenden Eigenschaften, z. B. die Unterstützung
komplexer Informationsfelder, zu ergänzen. Besser wäre es sogar, die Idee eines XML-
basierten Austauschformats in das Standardisierungsgremium der Workflow Management
Coalition einzubringen.
Um die Funktionalität des Austauschformats zu überprüfen und damit weitere Erfahrungen
zu sammeln, wären Tests mit Systemen anderer Workflow-Hersteller und eine Praxiserprobung
wünschenswert.

Literaturverzeichnis Seite 108
7 Literaturverzeichnis
[Adobe 1996]
Adobe System Incorporated, Portable Document Format, Reference Manual, Version 1.2,
1996
[Appelt 1991]
Appelt, Dr. rer. nat. Wolfgang: Document Architecture in Open Systems: The ODA Standard;
Springer Verlag Berlin Heidelberg 1991
[Aubrey 1996]
David Aubrey: MIME your mail, MIME protocol takes your messaging into the future. In
Computer Shopper, 1996.
[Behme/Minert 1998]
Behme, Henning; Minert Stefan; Professionelles Web-Publishing mit der Extensible Mar-
kup Language, Addision-Wesley-Longman, Bonn 1998
[Brorenstein/Freed 1993]
Brorenstein/Freed: MIME (Multipurpose Internet Mail Extensions) ,
Part One:Mechanisms for Specifying and Describing the Format of Internet Message Bo-
dies, 1993.
[Bryan 1988]
Bryan, Martin: SGML an author’s guide to the standard generalized, markup language,
Addison-Welsley Publishing Company, 1988
[Bryan 1997]
Bryan, Martin: An Introduction to the Extensible Markup Language (XML). Aus:
http://www.personal.u-net.com/~sgml/xmlintro.htm am 05.01.1998
[Coleman/Khanna 1996]
Coleman, D.; Khana, R. (Hrsg.): Groupware, Technology and Applications, Prentice Hall,
New York, 1996
[De la Crux 1996]

Literaturverzeichnis Seite 109
Del la Crux, Irvel, Les Thaler: Inside Mapi, Microsoft Press, 1996
[Deiters, W.]
Dr. Wolfgang Deiters, Groupware- versus Workflow Management Systeme, Teamorientiertes
Arbeit im Netz; Client Server Computing Nr. 1/98
[Dierker/Sander 1996]
Dierker, Markus; Sander, Martin: Lotus Notes 4.x, Arbeiten im Team, Addison-Wesley, 1.
Auflage, Bonn, 1996.
[Deutsch 1994]
Deutsch, Markus: Unternehmenserfolg durch EDI - Strategie und Realisierung des elektronischen
Datenaustausches, Vieweg Verlag, Braunschweig, 1994.
[Fischer 1992]
Fischer, J.: EDI-gestützte unternehmensübergreifende Teamarbeit, in: Nastansky, Ludwig
(Hrsg.): Betriebswirtschaft aktuell - Workgroup Computing, Steuer und Wirtschaftsverlag,
Hamburg, 1992.
[Fischer 1993]
Fischer, J.: Unternehmensübergreifende Datenmodellierung - der nächste folgerichtige
Schritt der zwischenbetrieblichen Datenverarbeitung!, Wirtschaftsinformatik, 35/3, 1993,
pp. 241-254.
[Fischer/Herold/Dangelmeier/Nastansky/Wolf 1995]
Fischer/Herold/Dangelmeier/Nastansky/Wolf 1995: Bausteine der Wirschaftsinformatik –
Kapitel 2 Büroinformationssystem, Teamorientiertes konzeptionelles Infrastrukturmanagement,
1995, pp. 269 – 290]
[Gifkins 1989]
Gifkins, Mike: EDI Technology, Blenheim Online, London, 1989
[Grand 1993]
Grand, Mark: MIME Overview, Mark Grand,
http://www.mindspring.com/~mgrand/mime.html, 1993.
[Groiss/Eder 1996]

Literaturverzeichnis Seite 110
Groiss, Herbert; Eder, Johann: Kooperation von Workflow-Systemen im World-Wide
Web, in: Tagungsband der EMISA Jahrestagung, Aachen, 1996.
[Georg/Gruber 1995]
Georg, Thorsten; Gruber, Peter: Elektronischer Geschäftsverkehr - EDI in deutschen Unternehmen,
Computerwoche Verlag, München, 1995.
[Hansen 1992]
Hansen, Hans R.: Wirtschaftsinformatik I - Einführung in die betriebliche Datenverarbeitung,
Gustav Fischer Verlag, 6. Auflage, Stuttgart, 1992.
[Hasenkamp/Syring 1994]
Hasenkamp, U.;Syring, M.: CSCW in Organisationen – Grundlage und Probleme, in: Hasenkamp,
U. et al (Hrsg): CSCW – Computer Supported Cooperative Work, Informations-
system für dezentralisierte Unternehmensstrukturen, Addision-Wesley, Bonn, 1994, S. 15 -
37
[Hasenkamp et al. 1994]
Hasenkamp, U.; Kirn, S; Syring, M. (Hrsg.): CSCW – Computer Supported Cooperative
Work, Informationssysteme für dezentralisierte Unternehmensstrukturen, Addision-
Wesley, Bonn, 1994
[Hein 1997]
Hein, O.: Grapfische Visualisierung und Analyse verteilten Workflow Managements, Kon-
zeption und prototypische Implementierung des Wide Area GroupFlow Analyzers, Diplomarbeit,
Paderborn, 1997
[Hilpert 1994]
Hilpert, Wolfgang: The GroupFlow System: Workflow Management in Distributed Organizations,
White Paper, University of Paderborn, Business Computing, 1994.
[Hilpert/Nastansky/Riempp 1995]
Hilpert, Wolfgang; Nastansky, Ludwig; Riempp, Gerold: Die Produktivität Groupwarebasierter
Anwendungen im Workflow Management, in: Krcmar, H. (Hrsg.): Tagungsband
des 14. Baden-Württemberg-Kolloquiums "Computer Supported Cooperative Work und

Literaturverzeichnis Seite 111
Computer Aided Team - Verbesserung der Gruppenarbeit durch Computer", Universität
Hohenheim, Hohenheim, 1995, pp. 271-290.
[Hofland/Utsler 1997]
Hofland Peter;Utsler, Jim:Web-smart, business-process-aware applications are jum-starting
a new era of work-flow proficiency. In Byte Magazin Vol 5. (1997)
[Koch/Zielke 1996]
Koch, G. O. ; Zielke F.: Workflow Management, Prozeßorientierten Arbeiten mit der Unternehmens-DV,
Markt & Technik, Haar bei München, 1996]
[Light 1997]
Light, Richard: presenting XML, sams.net, Indianapolis, 1997
[Mace/Flohr/Dobson/Graham]
Mace, Scott; Flohr, Udo; Dobson, Rick; Graham, Toni: Die (R)evolution im World Wide
Web, Deutschland Byte, April 1998, pp. 42-51
[Mertens 1966]
Mertens, Peter: Die zwischenbetriebliche Kooperation und Integration bei der automati-
sierten Datenverarbeitung, Verlag Anton Hain, Meisenheim am Glan, 1966.
[Mertens 1985]
Mertens, Peter: Zwischenbetriebliche Integration der EDV, in: Informatik-Spektrum, Nr. 8,
2, 1985, pp. 81-90.
[Mertens 1993]
Mertens, Peter: Integrierte Informationsverarbeitung 1, Gabler Verlag, 9. Auflage, Wiesbaden,
1993.
[Mertens/Bodendorf/König/Picot/Schumann 1996]
Mertens, Peter; Bodendorf, F.; König, W.; Picot, Arnold; Schumann, M.: Grundzüge der
Wirtschaftsinformatik, Springer Verlag, 4. Auflage, Berlin, Heidelberg, 1996.
[Microsoft 1998]
XML Viewer aus http://www.microsoft.com/XML

Literaturverzeichnis Seite 112
[Nastansky et al. 1995]
Nastansky, L.; Schicker, T.; Behrens, O. M.; Ehlers, P.: Büroinformationssysteme, in:
Fischer, J.; Herold W.; Dangelmaier, W.; Nastansky. L.; Wolff, R. (Hrsg.): Bausteine der
Wirtschaftsinformatik, S + W Steuer- und Wirtschaftsverlag, Hamburg, 1995,
S. 269-369
[Nastansky/Hilpert 1994]
Nastansky, Ludwig; Hilpert, Wolfgang: The GroupFlow System: A Scalable Approach to
Workflow Management between Cooperation and Automation, in: Wolfinger, Bernd (Ed.):
Innovationen bei Rechen- und Kommunikationssystemen - Eine Herausforderung an die
Informatik, Proceedings of 24th Anual Conference of the German Computer Society during
13th World Computer Congress, IFIP '94, Springer Verlag, Berlin, Heidelberg etc.,
1994, pp. 473 - 479.
[Nastansky/Hilpert 1995]
Nastansky, Ludwig; Hilpert, Wolfgang: Das GroupFlow System für Workflow-
Management, Balance zwischen Struktur und Flexibilität, in: Business Computing, Vogel-
Verlag , Würzburg, Nr. 7, Juli, 1995, pp. 30 - 31.
[Nolan 1998]
Nolan, Suzanne D.: Interoperability and Standards. Aus
http://www.libraries.wayne.edu/~jlitman/nolan.html , 1998.
[Rechenberg/Pomberger 1997]
Rechenberg, Pomberger: Informatik Handbuch, Carl Hanser Verlag; München Wien; 1997
[Riempp 1997a]
Riempp, Gerold: Lotus Notes Anwendungen im World Wide Web, in: Hasenkamp, U.;
Reiss, O. (Hrsg.): Tagungsband des Workshops "Lotus Notes im Internet: Technologien
und Konzepte", Marburg, April, 1997, pp. 33-56.
[Riempp 1997b]
Riempp, Gerold: Workflow Management between distributed organizations - Wide Area
GroupFlow System, Poster on the International Conference Wirtschaftsinformatik '97
(WI'97), Berlin, February, 1997.

Literaturverzeichnis Seite 113
[Riempp 1998]
Riempp, Gerold: Wide Area Workflow Management - Conceptions and Solutions for Intraand
Interorganizational Coordination and Interaction among Distributed Workflow Management
Systems, Springer Verlag, London etc., 1998 (in publication).
[Riempp/Nastansky 1996a]
Riempp, Gerold; Nastansky, Ludwig: Von lokalem zu verteiltem Workflow Management -
das Wide Area GroupFlow Phasenmodell zur Einführung und Optimierung verteilter Vorgangsbearbeitungssysteme,
Arbeitspapier, Universität Paderborn, Lehr- und Forschungseinheit
Wirtschaftsinformatik 2, Paderborn, 1996.
[Riempp/Nastansky 1996b]
Riempp, Gerold; Nastansky, Ludwig: Workflow Management zwischen verteilten Group-
ware-basierten Büros (Wide Area OfficeFlow), Die WideOffice-Infrastruktur zur Interaktion
vernetzter Teams, in: Uellner, St. (Hrsg.): Tagungsband des GI-Workshops "CSCW in
großen Unternehmungen", Telekom AG, Darmstadt, 1996, pp. 193-207.
[Riempp/Nastansky 1997]
Riempp, Gerold; Nastansky, Ludwig: Workflow Management between distributed organizations
- the Wide Area GroupFlow Approach, in: Lehner, F.; Dustar, S. (Hrsg.): Teleko-
operation in Unternehmen, Deutscher Universitäts Verlag, Gabler Edition Wissenschaft,
Wiesbaden, 1997, pp. 265-282.
[Robinson 1990]
Robinson, Peter J. : Office Document Architecture, ELEDIS Journal No. 5, November –
December 1990, Belgium. Aus: http://www.home.fh-
karlsruhe.de/~bath0011/nwapps/oda.html
[Saliger 1998]
Saliger, Dietmar: Laufzeitumgebung für Groupware-basiertes verteiltes Workflow Management,
Diplomarbeit, Universität GH Paderborn, 1998
[Simon 1998]

Literaturverzeichnis Seite 114
Simon, Stefan: Zwischenbetriebliche Integration - Stand der Forschung und Praxis bei der
Verbindung operativer Informationssysteme über Organisationsgrenzen hinweg, Diplomarbeit,
Universität GH Paderborn, 1998
[Sievert 1996]
Sievert, Jörg:Kooperation durch Dokumente. Aus: http://www.telematik.informatik.uni-
karlsruhe.de/forschung/klung96/node19.html am 16.02.1998
[Stein 1996]
Stein, Dominik: Definition und Klassifikation der Begriffswelt um CSCW, Workgroup
Computing, Groupware, Workflow Management, Seminararbeit, Universität Gesamthochschule
Essen, 1996
[Teufel 1996]
Teufel, Stefanie: Computerunterstützte Gruppenarbeit - eine Einführung, in: Österle, H.;
Vogler, P. (Hrsg.): Praxis des Workflow Managements, Vieweg, Braunschweig, Wiesba-
den, 1996, pp. 35-63.
[Touchard 1997]
Touchard, J.: Modellierung verteilter vorgangsbearbeitung, Konzeption und prototypische
Implementierung eines graphischen Vorgangseditors für verteiltes, Groupware-basiertes
Workflow Management, Diplomarbeit, Universität GH Paderborn, 1997
[Weid 1994]
Weid, Hubert: Wettbewerbsvorteile durch Electronic Data Interchange, Hussverlag, München,
1994
[Wewers 1996]
Wewers, Thorsten: Zwischenbetrieblich integrierte Informationsverarbeitung für die Abfallwirtschaft
- dargestellt am Beispiel eines Workflow-Management-Systems für die Entworgung
von Sonderabfällen, Arbeitspapier Nr. 4/96 des Bereichs Wirtschaftsinformatik 1,
Universität Nürnberg-Erlangen, 1996.
[Wewers/Faisst 1996]

Literaturverzeichnis Seite 115
Wewers, Thorsten; Faisst, Wolfgang: Kooperierende Workflow-Management-Systeme für
Virtuelle Unternehmen, in: Uellner, St. (Hrsg.), Tagungsband des GI-Workshops "CSCW
in großen Unternehmen", Telekom AG, Darmstadt, 1996, pp. 167-175.
[Wewers/Wargitsch 1997]
Wewers, Thorsten; Wargitsch, Christoph: Zwischenbetrieblich integriertes Workflow-
Management - dargestellt am Beispiel der Sonderabfallentsorgung, in: Mambrey, P.;
Streitz, N.; Sucrow, B.; Unland, R. (Hrsg.): Rechnergestützte Kooperation in Verwaltungen
und großen Unternehmen, Tagungsband zum Workshop während der Informatik '97,
Aachen, 1997, pp. 64-85.
[Wewers/Wargitsch 1998]
Wewers, Thorsten; Wargitsch, Christoph: Four Dimensions of Interorganizational, Document-Oriented
Workflow: A Case Study of the Approval of Hazardous-Waste Disposal, in:
Proceedings of the 31st Hawaii International Conference on System Sciences, Hawaii,
1998.
[WFMC 1994]
Workflow Management Coalition (Hrsg.): The Workflow Reference Model, Brussels, November,
1994
[WfMC 1996]
WfMC, Workflow Management Coalition: Workflow Standard - Interoperability Abstract
Specification, Document Number WFMC-TC-1012, Version 1.0, 20-Oct, 1996.
[Whipple 1997]
Whipple, Larry C.: Electronic data interchange, making it happen, 1997 Advisor Publications
Inc. , Databased Web Advisor, 1.06.97, 1997.

Anhang Seite 116
8 Anhang
8.1 Relevante Internet-Ressourcen
Die in der Tabelle aufgeführten Einträge, enthalten in vielen Fällen weitergehende Verweise.
Nr Kurzbeschreibung URL
1. XML Http://www.xml.com
http://www.w3.org
http://www.csclub.uwaterloo.ca/u/relander/XML/htt
p://www.xmlinfo.com/
http://www.xmlsoftware.com/
http://www.sil.org/sgml/xml.html
2. HTML Http://www.w3.org
3. SGML Http://www.sgmlopen.org
http://www.sil.org/sgml/sgml.html
4. EDI/EDIFact Http://www.unicc.org/unece/trade/untdid/Welcome.
5. Information on the European
Commission's Open Information
Interchange service
6. XML for Electronic Data
Interchange
html
Http://www2.echo.lu/oii/en/oii-home.html
Http://www.geocities.com/WallStreet/Floor/5815/gu
ide.htm
7. Internet Mail Consortium Http://www.imc.org
8. World Wide Web Journal Http://www.w3j.com

Anhang Seite 117
8.2 Message-Objekt-Definition
Ein Message Objekt setzt sich aus den drei unterschiedlichen Typen von Felder zusammen:
Mail-Felder, Workflow-Felder und Nutz-Felder
Mail-Felder
Feldname Beschreibung
SendTo
(Text)
Subject
(Text)
Workflow-Felder
Ziel-Adresse für die E-Mail, i.d.R. die Gateway-DB oder
die Applicationen-DB
z.B. WAGS Application @ Janus
Titel und Beschreibung des Message Objekts
z.B. Angebotsanfrage
Feldname Beschreibung
MoAddressName
Name des GRI-Elements bzw. EMail-Adresse (je nach
(Text)
Richtung)
z.B. Hardware Profis GmbH/Angebot erstellen/Hardware
MoCode
(Text)
MoMessageObjectID
(Text)
MoMessageReferenceID
(Text)
moMessageReplyTo
(Text)
Knoten-ID des sendenden Knotens
z.B. 2-190DEAD4D933899DC125651E004E1132
ID des aktuellen Message Objekts, das dieses eindeutig
kennzeichnet (i.d.R. DocumentUniqueID),
z.B. 6A4000F8BDF00112C125654E0037E55C
ID des Message Objekts, auf das sich das aktuelle Message
Objekt bezieht (vergleichbar mit der Angebotsnummer,
die man bei einer Bestellung angibt)
Standard ist ""
ID des Message Objekts, auf das das aktuelle Message
Objekt antwortet.
Standard ist ""

Anhang Seite 118
moProcessID
(Text)
Workflow-ID des aktuellen Vorgang, aus dem das Message
Objekt gesendet wurde. Dieses wird in der sendenden
Gateway-Datenbank für die interne Verwaltung der
Message Objekt benutzt, aber extern nicht weitergegeben.
Bei eingehenenden MOs ist dieses Feld nicht vorhanden
oder "".
moWorkflowID
ID des Workflow-Typs
(Text)
Standard ist ""
????? einige Felder für das Tracking, die noch nicht näher spezifiziert
sind
moMessageType (Text) Werte: Oneway, Request, Answer, Sync
moMessageSource (Text) Werte: internal, external (Verbleibt in der sendenden
Gateway-DB)
Nutz-Felder
Feldname Beschreibung
Generic_Block_X mit X > 0
(Text)
Generic_Name_X mit X > 0
(Text)
Generic_Type_X mit X > 0
(Text)
Generic_Help_X mit X > 0
(Text)
Generic_Body_X mit X > 0
(Rich-Text)
ContentBlock_ContentField
(je nach Typ)
Enthält den Namen des aktuellen Content-Blocks
z.B. Adresse
Enthäl den Namen des aktuellen Content-Fields. Der
Feldname setzt sich somit aus dem zuletzt benutzten
Content-Block-Namens und dem Content-Field-Namen
zusammen
z.B. Kunde => Adresse_Kunde
Bestimmt den Typ des Content-Fields.
Mögliche Werte: "[txt]" = Text, "[rtx]" = Rich-Text,
"[num]" = Number, "[tim]" = Date/Time oder "[???]" =
unbekannt
Enthält den Hilfetext zu dem aktuellen Content-Field.
Enthält den Inhalt des Content-Blocks
Falls die Felder nicht über die generischen Subform dargestellt
und übermittelt werden. Der Content-Block-
Name entspricht dem in dem Feld moContentBlocks
z.B. Adresse_Kunde

Anhang Seite 119
8.3 Ausgehendes XML-Messageobjekt
Reco GmbH/Angebotsanfrage
2-39B528C02033AB3EC125655E00611AA0
Generic
C1256487:002CE875
WAGS1_Application @ WAW
WAGS1_Gateway @ WAW
FF0012BE1C14DC65C1256559003B8660
MessageObject
B0F0363B422E92C8C12565BB0049FD07
Request
WAGS1_Tracking @ WAW
*!*wfCode||2-
39B528C02033AB3EC125655E00611AA0:1*!*wfTask||Sending
Message*!*
*!*wfProcessID||2296232376A8B008C12565BB0049C415*!*wfType||Planung
Containeranlage*!*wfJob||Projekt Tackenweide*!*wfStartDate||02.03.98
14:25:43*!*wfFinishDate||*!*
*!*wfTrackPrevCode||1-
39B528C02033AB3EC125655E00611AA0:0*!*wfTrackPrevTask||Projekt
spezifizieren*!*
[txt]
Name der Kundenadresse
Stadt Emmerich
[txt]
Straße oder Postfach der Kundenadresse
Postfach 5 10 43
[num]
Postleitzahl des Kundenadresse
46446
[txt]

Anhang Seite 120
Ort der Kundenadresse
Emmerich
[txt]
Kundennummer falls bekannt
SE 42 65 43
[txt]
Name des Ansprechpartners
Dietmar Saliger
[txt]
Telefonnummer des Anprechpartners oder anderen
Verantwortlichen
(02822) 5371-0
[txt]
Faxnummer des Ansprechpartners oder anderen Verantwortlichen
(02822) 5371-10
[txt]
E-Mail Adresse
dsaliger @notes.uni-paderborn.de
[txt]
möglichst genaue Beschreibung des Standort sowie evtl. Ansprechpartner
vor Ort
Tackenweide 4
4664 Emmerich
[tim]
Gewünschter Zeitpunkt der Lieferung
01.04.98
[num]
Angabe der Mietdauer in Wochen
10

Anhang Seite 121
[rtx]
möglichst genaue Beschreibung des Projekte (z.B. mit
Planskizze)
Beschreibung wie folgt: ...

Danksagung
Mein Dank gilt allen, die zum Gelingen dieser Diplomarbeit beigetragen haben. Besonders
bedanken möchte ich mich bei Prof. Dr. Ludwig Nastansky, Diplom Wirtsch. Ing. Gerold
Riempp und Dr. Dirk Hoppen für die Betreuung und die Anregungen im Rahmen vieler
Gespräche.
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, daß ich die vorliegende Arbeit selbständig und nur unter
Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt
oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Rietberg, den 15.09.1998
(Michael Groß)