anwendung der extensible markup language (xml): konzeption und implementierung einer webedi-lösung

1 Einleitung

Die Extensible Markup Language (XML)ist auf einem guten Weg, zum universellenDatenformat f�r das Web zu werden. Sowird XML von neuen Browsern ebensounterst�tzt wie von Standardsoftware-Systemen, zum Beispiel SAP R/3. Wie beiden meisten neuen Technologien sindNutzeffekte anfangs jedoch schwer abzu-sch�tzen, und es besteht selten Klarheit inBezug auf die Anwendungsm�glichkeiten.Jon Bosak, einer der V�ter von XML,nennt folgende Anwendungsgebiete f�rXML [Bosa97]:

, XML als standardisiertes Datenaus-tauschformat: In diesem Anwendungs-bereich werden Dokumente, wie zumBeispiel Rechnungen, Bestellungenoder Produktbeschreibungen, auf derBasis von XML beschrieben und zwi-schen unterschiedlichen Akteuren aus-getauscht. Zu diesem Anwendungs-gebiet geh�ren etwa XML-basierteEDI-L�sungen.

, XML zur variablen Darstellung von In-formationen: Durch die Trennung vonStruktur, Inhalt und Layout k�nnen aufXML-Dokumente in Abh�ngigkeitvom jeweiligen Anwendungszweck un-terschiedliche Sichten genommen wer-den. Aus einer Softwaredokumentationk�nnen zum Beispiel nur die f�r das je-weilige Betriebssystem interessantenInformationen angezeigt werden.

, Intelligentes Suchen nach Informatio-nen in XML-Datenbest�nden: Dahinterverbirgt sich der Gedanke, dass Soft-wareagenten zuk�nftig die Bedeutungvon in XML codierten Informationen„verstehen“ sollen, um beispielsweiseVergleiche zwischen imNetz angebote-nen und in XML beschriebenen Pro-dukten durchzuf�hren.

In diesem Beitrag wollen wir uns mit demerstgenannten Einsatzgebiet, der Nutzungvon XML als standardisiertem Datenaus-tauschformat, besch�ftigen. Weitere An-wendungsbeispiele finden sich etwa in[TuFe01]. Dabei besteht das Ziel in der De-monstration derM�glichkeiten dieser neu-en Sprache zur Realisierung von XML-ba-sierten EDI-L�sungen. Dazu stellen wirim zweiten Kapitel zun�chst den Statusquo und die damit verbundenen Problemeklassischer EDI-L�sungen dar. Gegen-stand des dritten Kapitels ist eine kurze

Einf�hrung in XML sowie die Vorstellungvon XML-Standardisierungsinitiativen.Im vierten Kapitel beschreiben wir Kon-zeption, Implementierung und Anwen-dung einer XML/EDI-L�sung zum Aus-tausch von Rechnungen �ber das Internet.Abschließend werden wir uns der Fragewidmen, ob klassische L�sungen noch eineDaseinsberechtigung haben oder ob sie zu-k�nftig durch XML/EDI abgel�st werden.

2 Electronic DataInterchange – Status quound neue Entwicklungen

Der Einsatz von EDI (Electronic Data In-terchange) in Unternehmen reicht bis indie sechziger Jahre zur�ck [Nigg94, 6].Dabei handelt es sich um den zwischen-betrieblichen Austausch von elektro-nischen Gesch�ftsdaten in standardisierterForm [WHB01, 6–7]. EDI erm�glicht da-bei den Partnern – nach Einigung auf dieVerwendung eines gemeinsamen Standards–, Gesch�ftsdokumente, wie etwa Bestel-lungen oder Rechnungen, zwischen ihrenComputersystemen auszutauschen, ohnedass, wie bei traditionellen papierbasierten

Transaktionen, menschliche Interventio-nen n�tig werden.

Da die Anforderungen an Gesch�fts-vokabulare als Grundlage eines automati-sierten Datenaustausches h�ufig bran-chen-, partner- und landesspezifisch sind,entstand schon fr�h eine Vielzahl unter-schiedlicher EDI-Standards. ProminenteBeispiele sind VDA in der Automobil-industrie, SWIFT in Banken, SEDAS in derKonsumg�terwirtschaft, DAKOSY f�r dieTransportbranche sowie TRADACOMSin England bzw. ANSI ASC X12 in denUSA [WHB01, 67–69; Neub94, 20–22].Um die Inkompatibilit�tsprobleme der

Prof. Dr. Peter Buxmann, TechnischeUniversit�t Freiberg, Lehrstuhl f�rABWL, insbesondereWirtschaftsinfor-matik, Lessingstr. 45, D-09596 Freiberg,E-Mail: [email protected];Dipl.-Kfm. Frank Ladner, Seals GmbH,Leipziger Str. 36, D-60487 Frankfurt/Main, E-Mail: [email protected];Dipl.-Kfm. TimWeitzel, Universit�tFrankfurt, Lehrstuhl f�r ABWL,insbesondereWirtschaftsinformatik undInformationsmanagement, Mertonstr. 17,D-60054 Frankfurt/Main,E-Mail: [email protected]

Anwendung der Extens ibleMar kup Language (XML):

Konzept ion undImplement ierung

einer WebEDI-L�sung

Peter Buxmann, Frank Ladner, TimWeitzel

WI – Aufsatz

WIRTSCHAFTSINFORMATIK 43 (2001) 3, S. 257–267 257

vielen Standards zu adressieren, entwickel-ten die Vereinten Nationen und die welt-weite Standardisierungsorganisation ISOals internationalen, branchenneutralenStandard UN/EDIFACT (EDI for Admi-nistration, Commerce and Transport, ISO9735). Dabei entstanden innerhalb desEDIFACT-Standards branchenspezifischeSubsets wie ODETTE in der Automobil-industrie, CEFIC in der chemischen In-dustrie, EDIFICE in der Elektronikindus-trie, EANCOM im Handel, EDICON inder Baubranche sowie RINET in der Ver-sicherungsbranche.

Die aus der Verwendung vonEDI resul-tierenden Vorteile, wie Kosteneinsparun-gen, beschleunigte Gesch�ftsprozesse oderdie M�glichkeit von Just-In-Time-Pro-duktion, malen ein sch�nes Bild[WWBK00, 176–179; Emme93, 8–11,17–29; MaCh93, 5–6]. Trotz dieser Nutz-effekte hatEDInicht die erwarteteVerbrei-tung gefunden. Nach Sch�tzungen nutzennur etwa f�nf Prozent der Unternehmen,f�r die die Nutzung vorteilhaft w�re, auchtats�chlich EDI [SePR97]. Der Haupt-grund liegt darin, dass vor allem kleine undmittelst�ndische Unternehmen die erhebli-chen Setup- und Betriebskosten traditio-neller EDI-L�sungen scheuen. Verst�r-kend f�hrt die oben angesprochene Viel-zahl unterschiedlicher und in der Regel in-kompatibler EDI-Standards zu einer Unsi-cherheit, welcher der geeignete ist, und zudamit verbundenen Koordinationskostenbilateraler Implementierungsvereinbarun-gen. Vor diesem Hintergrund ist traditio-nelles EDI vornehmlich Großunterneh-men vorbehalten, die durch hohe Trans-aktionsvolumina einen h�heren Nutzenaus verbesserten Gesch�ftsprozessen reali-sieren k�nnen als die kleineren Partner inder Wertkette. So nutzen nach einer Studie52 Prozent der deutschen und 75 Prozentder amerikanischen GroßunternehmenEDI [WWBK00, 177–178], 98 Prozent der„Nicht-Fortune 1.000“ hingegen nicht.

Da ein bedeutender Kostenfaktor beitraditionellem EDI die Kosten f�r VANs

(Value Added Networks) zur �bermitt-lung der EDI-Nachrichten waren, war dern�chste Schritt der Evolution von EDI der�bergang auf das Internet als Transport-medium. So zahlte ein Unternehmen mitca. 25.000 EDI-Nachrichten zwischen14.000 und 25.000 US-Dollar im Monat anseinen VAN-Provider [Curt96]. W�hrendbei VANs die Kosten f�r die Nutzung derLeitungen oft nach der Anzahl der gesen-deten Nachrichten oder auch nach der An-zahl der gesendeten Zeichen berechnetwerden, gibt es bei der Nutzung des Inter-net eine solche Abrechnung nicht. Die At-traktivit�t des Internet f�r Benutzer beste-hender EDI-Systeme ist so groß, dass bei-spielsweise 3Com schon heute erwartet, inden n�chsten f�nf Jahren nahezu 100 Pro-zent des EDI-Verkehrs �ber das Internetabzuwickeln [WWBK99].

Im Folgenden werden wir untersuchen,inwieweit XML eine Grundlage f�r solcheEDI-L�sungen sein wird.

3 Die Extensible MarkupLanguage: Grundlagen undAnwendungsperspektivenf�r moderne EDI-L�sungen

3.1 Warum XML?Das HTML-DilemmaDie Extensible Markup Language (XML)wurde vom World Wide Web Consortium(W3C) entwickelt und liegt seit Februar1998 als so genannte „Recommendation“vor [W3C00c]. Das W3C definiert XMLals „data format for structured documentinterchange on the Web“ [W3C00]. Dabeiliegt die Betonung auf der Beschreibungstrukturierter Dokumente, wie etwa Be-stellungen, Rechnungen oder Produkt-beschreibungen, die �ber das Web aus-getauscht bzw. weiterverarbeitet werdenk�nnen.

Nun stellt sich die Frage, warum �ber-haupt ein neuer Standard notwendig ist, damit HTML doch eine einfache und etab-lierte Sprache existiert, um Inhalte im Webdarzustellen. Der Grund liegt darin, dasses sich bei HTML um eine reine Pr�senta-tionsbeschreibungssprache handelt. Diedaraus resultierenden Probleme werdenauch als HTML-Dilemma zusammenge-fasst [Bosa97]:

1) Erweiterbarkeit: HTML erlaubt wederdie Definition eigener Tags noch dasSpezifizieren individueller Attributezur semantischen Auszeichnung vonDaten. Ein in HTML codiertes Doku-ment enth�lt nur Informationen, wieInhalte darzustellen sind; weitergehen-de Informationen �ber die Semantikdes Inhalts sind nicht abbildbar.

2) Struktur: In HTML k�nnen keine Da-tenstrukturen jenseits von Formatinfor-mationen beschrieben werden. Der Zu-sammenhang der Daten untereinanderist nicht beschreibbar.

3) Validierung: HTML fehlen Sprachspe-zifikationen, die den Anwendungen ei-ne �berpr�fung der strukturellen Vali-dit�t der Daten erlauben.

Die Vorteile von XML werden beim Ver-gleich mit einem HTML-Dokument deut-lich. In Bild 1 sind Informationen �ber ei-nen Artikel von Jon Bosak mit dem Titel„XML, Java, and the future of the Web“ inHTML undXML dargestellt.

W�hrend sich HTML auf die Darstel-lung von Informationen beschr�nkt – sowird etwa „Jon Bosak“ fett dargestellt –k�nnen wir durch die M�glichkeit, Tagsfrei zu benennen, mithilfe von XML aus-dr�cken, dass es sich bei den Elementendes Dokuments aus Bild 1 um einen Arti-kel handelt. Dar�ber hinaus k�nnen wirmit XML die Struktur von Dokumentendefinieren. Die Struktur eines Dokumentsergibt sich in XML aus der Verschachte-lung der Tags; im Beispiel hat der Artikel,der als Wurzeltag (root element) das Do-kument umschließt, einen Titel und einenAutor. Auf M�glichkeiten der Validierungwerden wir im folgenden Abschnitt einge-hen.

3.2 Grundlagen von XML

Betrachtet man die Entwicklung vonXML, dann wird klar, dass das Prinzip derEinfachheit einen hohen Stellenwert hat;

HTML XML

 Bosak, Jon XML, Java, and the future of the Web

<?xml version=„1.0“?><ARTIKEL>

<AUTOR>Bosak, Jon</AUTOR><TITEL>XML, Java, and the future of the Web </TITEL>

</ARTIKEL>

Bild 1 HTML versus XML

258

es schl�gt sich auch in sechs der zehn Ent-wurfsziele des W3C nieder (http://www.mintert.com/xml/trans/REC-xml-19980210-de.html#1). Ein konkretes Zielbei der Entwicklung von XML war dabeietwa die Vorgabe, dass ein durchschnittlicherfahrener Programmierer in h�chstens ei-ner Woche in der Lage sein sollte, einenXML-Parser zu programmieren. Das Prin-zip der Einfachheit kommt auch darin zumAusdruck, dass ein XML-Dokument nurwenige Anforderungen zu erf�llen hat:

, Jeder ge�ffnete Tag muss geschlossenwerden.

, Tags ohne Inhalt (wie in HTML)m�ssen in XML explizit geschlossenwerden. So wird aus entweder oder kurz .

, Das Markup muss hierarchisch geglie-dert sein.

, Es d�rfen keine Markup-Zeichen (<oder &) im Text vorkommen.

, Am Anfang des Dokuments sollte derHinweis auf die XML-Version erfol-gen: <?xmlversion=,,1.0‘‘?>.

Erf�llt ein XML-Dokument diese Anfor-derungen, bezeichnet man es als wohl-geformt, wie etwa unser Beispieldokumentaus Bild 1.

Zu XML-Dokumenten kann dar�berhinaus eine explizite Definition eines zuge-h�rigen Dokumenttypen geh�ren. Hierf�rverwendet XML eine formale Grammatik,die so genannte Document Type Definiti-on (DTD). Auf diese Weise wird auf Typ-ebene die Struktur der zugeh�rigen Doku-mente festgelegt. Zudem wird definiert,welche Elemente in Dokumenten enthal-ten sein m�ssen bzw. optional sind. EinDokument, dem eine DTD zugeordnet ist,wird als g�ltig (valid) bezeichnet, wenn indem Dokument gegen keine der in derDTD definierten Regeln verstoßen wird.Ein wohlgeformtes XML-Dokument kannsomit ein g�ltiges werden, sofern es die Re-geln der DTD erf�llt [Mach97]. Ein Bei-spiel f�r ein g�ltiges XML-Dokument„Bestellung“ ist in Bild 2, die zugeh�rigeDTD in Bild 3 dargestellt. Eine DTD kannin das XML-Dokument selber eingef�gtoder mittels eines Links referenziert wer-den, wie im Beispiel von Bild 2 mit:<!DOCTYPE BESTELLUNG SYSTEM,,BESTELLUNG.DTD‘‘>. In diesem Fallliegt die DTD BESTELLUNG.DTD indemselben Verzeichnis wie die Instanz;hier k�nnte auch eine beliebige URL ange-geben werden.

Kernpunkte f�r dasManagement

Die Extensible Markup Language (XML) ist ein neuer Standard f�r dasWorldWideWeb, mit dem sich innovative Einsatzm�glichkeiten er�ffnen. In diesemBeitrag wird am Beispiel des Austauschs von Rechnungen das Potenzial diesesneuen Standards f�r EDI-Anwendungen aufgezeigt. Wir stellen Konzeption undImplementierung einer WebEDI-L�sung sowie deren Anwendung bei LufthansaAirPlus vor. Die wesentlichen Ergebnisse lauten:, XML ist ein neuer Web-Standard, der f�r eine Vielzahl von Anwendungen

genutzt werden kann., XML ist in einem Stadium, dass es in der Praxis eingesetzt werden kann., XML besitzt das Potenzial, EDI zu revolutionieren und EDI-Netze auch f�r

kleine und mittelst�ndische Unternehmen zu �ffnen.

Stichworte: EDI, Gesch�ftsprozess,WebEDI, XML

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE BESTELLUNG SYSTEM "BESTELLUNG.DTD"><BESTELLUNG>

<AUFTRAGSKOPF><NAME>Mustermann</NAME><DATUM>02.10.2000</DATUM><E-MAIL>[email protected]</E-MAIL>

</AUFTRAGSKOPF><AUFTRAGSPOSITIONEN>

<POSITION><BEZEICHNUNG>Festplatte</BEZEICHNUNG><ARTIKELNUMMER>123456</ARTIKELNUMMER><ANZAHL>5</ANZAHL>

</POSITION><POSITION>

<BEZEICHNUNG>Monitor</BEZEICHNUNG><ARTIKELNUMMER>9876</ARTIKELNUMMER><ANZAHL>1</ANZAHL>

</POSITION></AUFTRAGSPOSITIONEN>

</BESTELLUNG>

Bild 2 G�ltiges XML-Dokument „Bestellung“

<!ELEMENT BESTELLUNG (AUFTRAGSKOPF, AUFTRAGSPOSITIONEN)><!ELEMENTAUFTRAGSKOPF (NAME, DATUM, E-MAIL )><!ELEMENT NAME (#PCDATA)><!ELEMENT DATUM (#PCDATA)><!ELEMENT E-MAIL (#PCDATA)><!ELEMENTAUFTRAGSPOSITIONEN (POSITION)+><!ELEMENT POSITION (BEZEICHNUNG, ARTIKELNUMMER, ANZAHL)><!ELEMENT BEZEICHNUNG (#PCDATA)><!ELEMENTARTIKELNUMMER (#PCDATA)><!ELEMENTANZAHL (#PCDATA)>

Bild 3 DTD der Bestellung

Anwendung der Extensible Markup Language (XML)

259

Mithilfe der DTD ist es Programmen nunm�glich, ein XML-Dokument auf struktu-relle Fehler zu �berpr�fen oder eine neueInstanz dieses Dokumenttyps zu bilden.Eine DTD erweist sich insbesondere dannals vorteilhaft, wenn mehrere verschiedeneInstanzen angelegt werden sollen. Dabeidient die DTD als allgemeines Muster, dasAngaben dazu enthalten kann, welche derElemente durch eine Instanz benutzt wer-den m�ssen oder welche beliebig h�ufig(also gar nicht, einmal oder mehrfach) er-scheinen d�rfen. Ohne hier tief auf Syntax-regeln eingehen zu k�nnen, ist es etwam�glich, Inhalte der Elemente allgemeinals optional (A?) oder als alternativ (A|B)bzw. mit mindestens einem (A+) oder be-liebig vielen (A*) Inhalten vorzugeben[W3C00c].

Eine Schw�che des DTD-Konzeptesbesteht darin, dass es sich bei DTDs nichtum XML-Dokumente handelt. Daherk�nnen beispielsweise Zugriffsmodellewie das Document Object Model (DOM)nicht auf diese angewendet werden. Ausdiesen Gr�nden entwickelt das W3C der-zeit so genannte Schemata, die die Rigidi-t�ten des derzeitigen DTD-Konzeptes�berwinden sollen. Dabei erf�llen Sche-mata letztlich die gleiche Funktion: Sie ex-plizieren formale syntaktische Anforde-rungen an XML-Dokumente. Die Vorteileeines Schemas gegen�ber einer DTD liegenvor allem in folgenden Punkten:

, Ein Schema ist ein XML-Dokument., Es werden erweiterte Datentypen (der-

zeit �ber 30 verschiedene, wie beispiels-weise Ganzzahl, Datum etc.) unter-st�tzt.

, Es soll ein Vererbungskonzept imple-mentiert werden.

, F�r alle Elemente k�nnen erweiterteStrukturspezifikationen definiert wer-den (zum Beispiel, wie h�ufig sie min-destens/h�chstens vorkommen m�s-sen/d�rfen: minOccur,maxOccur).

, �quivalente Felddefinitionen sindm�glich (zum Beispiel Element PREIS= Element PRICE).

, Offene und/oder unvollst�ndige Defi-nitionen der Inhaltsmodelle sollenm�glich sein.

Der aktuelle Stand der Entwicklungen istjeweils auf den Seiten des W3C abrufbar[W3C00].

Neben der Entwicklung von XMLSchemata ist eine der bedeutendsten Ar-beiten des W3C f�r XML derzeit die Defi-

nition eines Standards zur Pr�sentationvon XML-Dokumenten. Die Darstellungeines XML-Dokuments erfolgt dabei mit-hilfe einer Formatvorlage, eines StyleSheet. In diesem Style Sheet wird das Lay-out des Dokumentes festgelegt. Auf StyleSheets wird durch entsprechende proces-sing instructions verwiesen, zum Beispiel:<?xml-stylesheet type =,,text/css’’ href = ,,style1.css’’?>. Aufdiese Weise wird eine Trennung der Pr�-sentation von Inhalt und Struktur des Do-kuments erm�glicht. Das W3C entwickeltderzeit mit der Extensible Style SheetLanguage (XSL) eine eigene Style-Sheet-Sprache f�r XML [W3C00a]. Danebentreibt das W3C seit 1996 die Entwicklungvon Cascading Style Sheets (CSS) weiter,die auch die Darstellung von HTML-Do-kumenten erm�glichen. Im Gegensatz da-zu kann XSL Dokumente transformieren.Beispielsweise ist XSLT, ein Subset vonXSL, in der Lage, eine Konvertierung zwi-schen unterschiedlichen XML-Dokumen-ten durchzuf�hren oder diese in HTML/CSS-Dokumente umzuwandeln.

Wie schon sichtbar wurde, resultiert dieM�chtigkeit von XML auch daraus, dassdas W3C mehr als nur ein Datenformatentwickelt hat. Vielmehr besteht die„XML-Familie„ aus einer Vielzahl ver-wandter Standards, die auch die Verarbei-tung von in XML ausgezeichneten Datenerm�glichen. Neben DTDs oder Schematasowie Style Sheets entwickelt das W3C et-wa erweiterte Linkingmodelle (XLink,XPointer), XMLNamespaces zur Vermei-dung semantischer Kollisionen bei Ver-wendung fremder bzw. mehrerer unter-schiedlicher XML-Dokumente oder dasDocument Object Model (DOM) als stan-dardisiertes Datenzugriffsmodell undSchnittstelle f�r die Verarbeitung vonXML-Dokumenten, zum Beispiel mithilfevon Java-Programmen [W3C00b].

3.3 Standardisierungsinitiativen

Bei XML handelt es sich um einen Stan-dard, der lediglich eine allgemeine Sprachezur Beschreibung von Dokumenten defi-niert, jedoch keine Aussagen �ber die In-halte trifft. Das bedeutet, dass sich auf Ba-sis von XML etwa beliebige Gesch�fts-dokumente und damit auch grunds�tzlichalle heute vorhandenen EDI-Standards ab-bilden lassen. Vor diesem Hintergrund istmittlerweile eine Vielzahl unterschiedli-

cher Standardisierungsinitiativen entstan-den [Stef00]. Diese werden durch neueKonsortien, wie OASIS, OAG oder Ro-settaNet, getrieben, w�hrend traditionelleEDI-Standards beispielsweise durch dasANSI (X12) oder UN/ECE (EDIFACT)entwickelt wurden. Eine Studie aus demHerbst 2000 identifiziert insgesamt 250verschiedene E-Business-Vokabulare [Ko-to00]. Quelle der Untersuchung sind Ver-zeichnisse von XML.com, OASIS/RobinCover, Schema.Net, IBMs alphaWorks so-wie Vokabulare, die bei XML.org (OA-SIS), Microsoft (BizTalk) und DISA regis-triert oder gepflegt werden.

Einer der fr�hesten Beitr�ge ist das„XML/EDI-Framework“ der XML/EDI-Group aus deren Gr�ndungsjahr 1997(http://www.xmledi.com). Darin wird be-schrieben, wie traditionelles EDI unter Er-haltung einer 100%igen R�ckw�rtskom-patibilit�t in die XML-Welt gef�hrt wer-den kann. Grundlage sind die f�nf Basis-technologien EDI (auf Grundlage vonEDIFACT und ANSI ASC X12), XML(Datenformat), Templates (Prozesslogik),Agenten (Aufgabenerf�llung) und Reposi-torys. Auch wenn von dieser Gruppe seit-dem nicht mehr viel Neues entwickeltwurde, sind ihre „K�pfe“, wie Bruce PeatundMartin Bryan, inzwischen die treiben-den Kr�fte hinter weiteren �hnlichen Ini-tiativen, wie insbesondere ebXML(http://www.ebxml.org).

Neben dieser Entwicklung der XML/EDI-Group ist heute das Entstehen einerVielzahl von umfassenden XML-Frame-works zu beobachten. Diese bieten eineGrundlage f�r den strukturierten Doku-mentenaustausch zwischen verschiedenenPartnern sowohl innerhalb als auch zwi-schen Branchen. Sie beschreiben den ge-samten Kommunikationsprozess undnicht bloße inhaltliche Spezifikationen be-stimmter Nachrichtentypen. Ein bedeu-tendes XML-Framework ist MicrosoftsBizTalk (http://www.biztalk.org), das dieInfrastruktur bereitstellt, um beliebige Ge-sch�ftsdokumente auf XML-Basis aus-zutauschen. Weitere bekannte Frame-works sind Electronic Business XML(ebXML) von UN/CEFACT und OASIS,das eCo Framework von CommerceNet,Commerce XML (cXML) von Ariba oderRosettaNet [WHB01, 76 u. 79–133].

Daneben existieren Ans�tze, die sichauf das Bereitstellen von XML-Inhaltenbeschr�nken. Dazu geh�rt etwa die Com-mon Business Library (xCBL) von Com-

260

merceOne (http://www.xcbl.org). Com-merceOne selbst bezeichnet xCBL als „setof XML building blocks and a documentframework“. Dahinter verbirgt sich eineSammlung von XML-Spezifikationen und-Modulen f�r Gesch�ftsdokumente. Beidiesen Dokumenten handelt es sich bei-spielsweise um Produktbeschreibungen,Bestellungen oder Rechnungen. F�r dieDefinition der Inhalte der xCBL dientenerneut etablierte EDI-Standards alsGrundlage. Ausgangspunkt waren hierbeidie UNSMs (United Nations StandardMessages) des EDIFACT-Standards unddie Transaktion Sets aus ANSI X12.

Andere Beispiele f�r solche Ans�tze,die sich auf die Bereitstellung von Doku-menten und Dokumenttypen konzentrie-ren, sind Guideline XML (gXML) vonCommerceDesk (EDIFECS) oder das In-formation and Content Exchange Protocol(ICE) der GCA [WHB01, 148–155].

Daneben gibt es Initiativen, die sich aufden Nachrichtenaustausch innerhalb einerBranche oder eines bestimmten Gebietesspezialisieren. Beispiele sind die Mathema-tical Markup Language, Astronomical In-strument Markup Language, die Bio-Poly-mer Markup Language, Chemical MarkupLanguage, Financial Products MarkupLanguage und nicht zuletzt auch die Theo-logical Markup Language [WHB01,77–78].

F�r eine ausf�hrliche Beschreibung die-ser Standardisierungsinitiativen siehe[WHB01, 75–155].

4 Konzeption undImplementierung einer XML-basierten EDI-Anwendung

4.1 �berblickIn diesem Kapitel wollen wir Konzeption,Implementierung und Anwendung einerXML/EDI-L�sung vorstellen. Auf Basisdieser L�sung k�nnen sich die Kunden ei-nes Unternehmens ihre Rechnungsdatenvon einem Webserver manuell oder auto-matisch herunterladen. Die Rechnungenwerden dabei in XML codiert, und es wirddie Bereitstellung von kundenspezifischenXML-Formaten unterst�tzt, das heißt, je-dem Rechnungsempf�nger kann ein eige-nes XML-Format zugeordnet werden. In

diesen unterschiedlichen Formaten k�n-nen zudem verschiedene Style Sheets refe-renziert werden, was neben dem kunden-spezifischen Datenformat auch ein indivi-duell angepasstes Layout der Rechnungs-daten erm�glicht.

Das Ziel bestand in der Entwicklung ei-ner L�sung, die weitestgehend auf offenenWeb-Standards aufbaut. Dahinter stecktdie Idee, auf diese Weise einen Beitrag zuleisten, die Barriere f�r den EDI-Einstiegauch f�r kleine und mittelst�ndische Un-ternehmen zu senken. Zur Anwendungder L�sung ist auf Client-Seite nur einXML-f�higer Webbrowser, zum Beispielder Microsoft Internet Explorer 5.0, not-wendig. Die von der L�sung f�r den auto-matischen Rechnungsabruf bereitgestellteJava-Applikation ist auf jeder Java 2-kom-patiblen Virtuellen Maschine lauff�hig.Die Serverkomponente ben�tigt dar�berhinaus noch einen Webserver, welcher dieJava Servlet API unterst�tzt.

Ausgangspunkt der Anwendung ist einServer des Rechnungsstellers, der dieRechnungsdaten als XML-Daten im Webbereitstellt. Aus Sicht des Rechnungsemp-f�ngers werden die drei folgenden Anwen-dungsszenarien unterst�tzt (siehe auchBild 4):

, Keine Integration: Pr�sentation undAusdrucken der XML-Rechnungen�ber denWebbrowser,

, Manuelle Integration: Herunterladender XML-Rechnungen �ber einenWebbrowser und Integration in Inhou-se-Systeme sowie

, Automatische Integration: Herunter-laden der XML-Rechnungen �ber eineJava-Applikation mit automatischer In-tegration in Inhouse-Systeme.

Im Folgenden geben wir zun�chst einen�berblick �ber die Funktionalit�t (Ab-schnitt 4.2) und technische Implementie-rung (Abschnitt 4.3) des Prototypen. Da-bei treffen wir jeweils eine Unterscheidungzwischen der Server- und Clientseite. An-schließend skizzieren wir in Abschnitt 4.4die Anwendung bei Lufthansa AirPlus.

4.2 Funktionalit�t des Prototypen

4.2.1 Die Server-Seite

Der Server, welcher die Rechnungsdatenbereitstellt, besteht aus verschiedenen Mo-dulen. Dabei handelt es sich um einenKonfigurationseditor zum Erstellen derempf�ngerspezifischen XML-Datenfor-mate, eine Benutzerverwaltung zur Ver-

Bild 4 Anwendungsszenarien


261

waltung der Rechnungsempf�nger und derihnen zugeordneten Datenformate sowie

eine Protokollfunktion, die alle Zugriffeder Rechnungsempf�nger festh�lt.

Beim Rechnungssteller liegen zun�chstdie Rechnungsdaten in einer relationalenDatenbank vor. Mithilfe des Konfigurati-onseditors werden Elemente, Struktur so-wie die Inhalte der XML-Rechnungen de-finiert. Dar�ber hinaus k�nnen auch vor-handene Dokumente sowie DTDs ausexistierenden Bibliotheken eingeladen undals Template f�r die Rechnungsformateverwendet werden. Zur Bearbeitung k�n-nen alle Funktionen eines XML-Editors,wie XML-Dateien laden oder speichern,sowie Optionen, wie Kopieren, Aus-schneiden, Einf�gen und L�schen, genutztwerden. Bild 5 zeigt auf der linken Seitedie Struktur einer XML-Vorlage undrechts die Datenbankfelder. Die Zuord-nung zwischen den Elementen der XML-Vorlage und den Datenbankfeldern, wel-che die Rechnungsdaten enthalten, erfolgt„perMausklick“.

, In der Benutzerverwaltung werden dieRechnungsempf�nger angelegt und ih-nen die im Konfigurationseditor er-zeugten Formatbeschreibungen zuge-ordnet. Damit ist f�r jeden Empf�ngerein Rechnungsformat festgelegt. Zudemk�nnen jedem Rechnungsempf�ngerStyle Sheets zur individuellen Pr�senta-tion der Rechnungsdaten zugeordnetwerden.

Die Protokollfunktion registriert alle Zu-griffe auf das System, um beispielsweisebelegen zu k�nnen, dass eine Rechnungauch vom Rechnungsempf�nger abgerufenwurde.

4.2.2 Die Client-SeiteAus der Perspektive des Client, also desRechnungsempf�ngers, stellt sich die L�-sung wie folgt dar: Im Falle des manuellenAufrufs mit oder ohne Integration (sieheAbschnitt 4.1) greift der Rechnungsemp-f�nger mit seinem Browser auf das Systemzu und authentifiziert sich mit User-Idund Passwort. Daraufhin erh�lt er eineListe der f�r ihn vorliegenden Rechnun-gen. Der Client w�hlt nun eine Rechnungaus, die ihm dann im Browser mithilfe ei-nes Style Sheet pr�sentiert wird. Er kanndiese Rechnung als XML-Datei speichernund in seinen XML-f�higen Systemen wei-terverarbeiten oder aber sie ausdruckenund somit als „normale“ Papierrechnungverwenden. Bild 6 zeigt rechts die XML-Datei einer Rechnung und links die Pr�-sentation dieser Rechnung mittels einesStyle Sheet im Browser.

Bild 5 Konfigurationseditor

Bild 6 XML-Rechnung mit zugrunde liegender XML-Datei

262


Alternativ zu diesem manuellen Rech-nungsabruf Server wurde, wie in Abschnitt4.1 bereits dargelegt, ein automatisierterZugriff realisiert. Hierbei greift das System

ohne weiteren Benutzereingriff auf denServer zu, holt die vorliegenden Rechnun-gen automatisch ab und importiert diese indie relationale Datenbank des Empf�ngers.

Dabei kann der Benutzer das Zeitintervall,in dem das System auf den Server zugreift,frei definieren, wie Bild 7 zeigt.

Im Folgenden wollen wir auf die tech-nische Implementierung des Prototypenn�her eingehen.

4.3 Implementierungdes Prototypen

4.3.1 �berblick

Die Softwarearchitektur der L�sung glie-dert sich in vier Module. Die Basisklassen-bibliothek, das Administrationsmodul unddas Webservermodul laufen auf dem Ser-ver, die Java-Applikation f�r den auto-matisierten Rechnungsabruf wird auf derClient-Seite betrieben. Die Module auf derServerseite kommunizieren untereinander�berMethodenaufrufe der entsprechendenObjekte. Die Java-Applikation f�r den au-tomatisierten Rechnungsabruf kommuni-ziert mit dem Server, wie auch der Benut-zer beim manuellen Rechnungsabruf, �bereine SSL-verschl�sselte HTTP-Verbin-dung. Damit basiert der Prototyp vollst�n-dig auf offenen Web-Standards. Die linkeSeite von Bild 8 pr�sentiert die Server-Sei-te, w�hrend die rechte die Client-Seite dar-stellt.

Die Benutzeroberfl�chen des Adminis-trationsmoduls und des Tool f�r den auto-matischen Rechnungsimport wurden mitder Swing API realisiert. Die Oberfl�chender Webserverkomponente f�r den Zugriffmit demWebbrowser werden aus XML er-zeugt, das mit einem XSLT Style Sheetvom Browser in HTML umgewandeltwird.

4.3.2 Die Server-Seite

Als Basis der Serverkomponenten wird ei-ne Basisklassenbibliothek genutzt, welchedie vom Administrationsmodul und demWebservermodul genutzten Java-Klassenenth�lt. Dies sind im Wesentlichen dieKlassen f�r den Datenbankzugriff sowiedie Gesch�ftslogik.

Das Administrationsmodul ist eine ei-genst�ndige Java-Applikation und ben�-tigt somit außer einer Java 2-kompatiblenVirtuellen Maschine keine dar�ber hinaus-gehende Umgebung. Sie stellt die Oberfl�-chen und die Vorgangssteuerung f�r die inAbschnitt 4.2.1 beschriebenen Serverkom-ponenten bereit.

Bild 7 Automatischer Rechnungszugriff

Bild 8 Architektur der L�sung

264


Die Webserverkomponente �bertr�gtdie Rechnungsdaten in dasWeb. Sie basiertauf der Java Servlet API und ist auf jedemWebserver lauff�hig, der diese API unter-st�tzt. F�r den Prototyp kam der IPlanetWeb Server zum Einsatz.

Die serverseitige Erzeugung der XML-Rechnungen erfolgt durch einen XML-Prozessor, der Bestandteil der Basisklas-senbibliothek ist. Hierf�r wird zun�chstdie mit demKonfigurationseditor erzeugteFormatvorlage vom Prozessor geladen.Die Daten werden dann aufgrund dieserVorlage vom Prozessor �ber die JDBC-Schnittstelle aus der Datenbank gelesenund in eine XML-Datei eingef�gt. Der Zu-griff auf die Datenbank ist mithilfe einerDatenbankkomponente realisiert, welchedie hierf�r ben�tigten SQL-Aufrufe kap-selt. Wird nun durch ein Objekt der Ge-sch�ftsklassen ein Datenbankzugriff vor-genommen, so erfolgt dieser durch denAufruf der entsprechenden Methode imDatenbankobjekt. Die notwendigen SQL-Befehle m�ssen somit nicht in den Ge-sch�ftsklassen implementiert werden.

Bild 9 zeigt eine Formatvorlage f�r denXML-Prozessor. Dabei sind Teile der Vor-lage, die sich nicht �ndern, wie etwa Datenzum Rechnungssteller, fester Bestandteil.Die Elemente, die mit den Inhalten derDatenbank gef�llt werden, sind mit <xdi:insert…> f�r die Felder, die nur einmalvorkommen, und mit <xdi:insertposition…> f�r die sich wiederholenden Felder derRechnungspositionen gekennzeichnet.Die Verarbeitung der Formatvorlage er-folgt mithilfe der API des DOM. DieseAPI wird von dem f�r den Prototyp ver-wendeten XML-Parser, es handelt sichhierbei um XML4J von IBM, bereit-gestellt.

In der Zieldatei werden nun die Steuer-kommandos durch die aus der Datenbankgelesenen Daten ersetzt. Die auf diesemWeg erzeugte XML-Rechnung wird da-nach an den Rechnungsempf�nger �bertra-gen.

Die Tags zur Steuerung der Verarbei-tung und die Platzhalter werden einemNamespace xdi zugewiesen, um Namens-konflikte mit Tags einer m�glicherweisezugrunde liegenden DTD zu vermeiden.

Im Folgenden werden wir die Client-Seite n�her betrachten.

4.3.3 Die Client-Seite

Der Zugriff auf die Serverkomponente mitdem Webbrowser erfolgt �ber die von derWebserverkomponente erzeugten Websei-ten. Auf der Clientseite kommen somitkeine Softwarekomponenten zum Einsatz,solange auf den automatisierten Rech-nungsabruf verzichtet wird.

Der automatisierte Rechnungsabrufwurde als Java-Applikation realisiert, dielediglich eine Java 2-kompatible VirtuelleMaschine ben�tigt. In dieser Komponentekommt dasselbe Konzept zum Einsatz wieauf dem Server: Die Objekte der Ge-sch�ftsklassen, welche die Logik der An-wendung enthalten, greifen �ber entspre-chende Methodenaufrufe der Datenbank-komponente auf die Datenbank zu.

Da sowohl der menschliche Benutzerals auch das Tool f�r den automatischenRechnungsabruf mithilfe von XML mitdem Server kommunizieren, kann dieselbeSchnittstelle genutzt werden. F�r den

menschlichen Nutzer werden die XML-Daten mit einem Style Sheet kombiniertund so f�r ihn lesbar gemacht. Das Toolf�r den automatischen Rechnungsabruf in-terpretiert die in den XML-Daten enthal-tenen Informationen und f�hrt die dort de-finierten Aktionen aus. Der Prototyp ver-wendet also ein XML-Kommunikations-protokoll, welches auf dem Transportpro-tokoll HTTP aufsetzt.

Die Verarbeitung der eintreffendenRechnungsdaten durch das Importtool er-folgt analog dem Export auf der Serversei-te in umgekehrter Richtung. Dem Import-tool ist die Struktur der Zieldatenbankdurch eine anpassbare Konfigurationsdateibekannt. Basierend auf dieser Konfigurati-onsdatei werden nun, wiederum mithilfeder API des Document Object Models, dierelevanten Daten aus der empfangenenRechnung gelesen und dann in die Ziel-datenbank importiert.

<?xml version="1.0" encoding="UTF-8"?><root xmins:xdi="http://www.frank-ladner.de/">

<Absender><Name>Musterfirma</Name><Adresse>Musterstrasse 4</Adresse><PLZ>0815</PLZ><Ort>Musterstadt</Ort><Rechnungsdatum>

<xdi:insert name="Rechnungsdatum"></xdi:insert></Rechnungsdatum><Rechnungsnummer>

<xdi:insert name="RechnungsNr"></xdi:insert></Rechnungsnummer>

</Absender><Positionen>

<xdi:positionen><Artikel_nr>

<xdi:insertposition name="ArtikelNr"></xdi:insertposition></Artikel_nr><Menge>

<xdi:insertposition name="Anzahl"></xdi:insertposition></Menge><Summe>

<xdi:insertposition name="Endpreis"></xdi:insertposition></Summe>

</xdi:positionen></Positionen><Rechnungssumme>

<xdi:insert name="Gesamtsumme"></xdi:insert></Rechnungssumme>

</root>

Bild 9 Formatvorlage f�r den XML-Prozessor


265

4.4 Anwendung:Lufthansa AirPlus

Auf Grundlage des im letzten Abschnittvorgestellten Prototypen wurde von derFirma Seals GmbH (http://www.seals.net)eine L�sung InvoiceXchange entwickelt,die mittlerweile auch im Praxiseinsatz ist.Der Prototyp hatte dabei die Funktion ei-ner Machbarkeitsstudie; die Anwendungwurde komplett neuentwickelt. Anhanddes Beispiels vonLufthansaAirPluswollenwir im Folgenden den praktischen Einsatzvon InvoiceXchange darstellen. LufthansaAirPlus ist eine Tochter derDeutsche Luft-hansa AG und bietet seinen Kunden ins-besondere Dienstleistungen auf dem Ge-biet des Business TravelManagement an.

Die Rechnungsdaten von LufthansaAirPlus liegen in einem propriet�ren For-mat namens Lars (Lufthansa AirPlusRechnungssatz) vor. Diese Lars-Rechnun-gen werden nun in XML konvertiert unddann in einer Datenbank gespeichert. DasFormat entspricht weitgehend dem Invoi-ce-Standard der xCBL (siehe hierzu Ab-schnitt 3.3); eine Vorlage kann unter http://www.xcbl.org herunter geladen werden.

Die Rechnungsempf�nger erhalten nungenau wie in dem zuvor beschriebenenPrototypen die M�glichkeit, ihre Rech-nungen herunterzuladen. Im Gegensatz zuunserem Prototypen erfolgt die Authenti-fizierung mittels einer SmartCard, auf derdas digitale Zertifikat des Rechnungsemp-f�ngers gespeichert ist. Die Rechnungs-daten werden �ber eine verschl�sselte SSL-Verbindung (128 Bit) in dem vom Rech-nungsempf�nger gew�nschten Format he-runter geladen.

Ein weiterer Unterschied zu unseremPrototypen besteht darin, dass InvoiceX-change nicht ausschließlich auf XML alsEmpfangsformat beschr�nkt ist. So kannder Rechnungsempf�nger bei InvoiceX-change zwischen unterschiedlichen For-maten w�hlen. Dazu geh�ren EDIFACT,SAP IDOCs zur Integration in SAP-Sys-teme oder auch CSV (Comma SeparatedValues) zur Weiterverarbeitung zum Bei-spiel mit Microsoft Excel. Außerdem ist esm�glich, das Rechnungsdokument inHTML zu erhalten. F�r diesen letzt-genannten Fall wird das XML-Dokumentserverseitig in HTML umgewandelt, umauch Kunden, die �ber keinen XML-f�hi-gen Browser verf�gen, die Pr�sentationder Dokumente zu erm�glichen. Bei allen

Konvertierungsleistungen kommt der Vor-teil zum Tragen, dass XML-Dokumenteleicht weiterverarbeitbar sind.

5 Ausblick : XML –Die Zukunft von EDI?

In diesem Artikel haben wir gezeigt, dassXML eine Grundlage f�r web-basierteEDI-L�sungen sein kann. Damit stellt sichdie Frage, ob und inwieweit XML/EDIklassisches EDI abl�sen wird. Zur Beant-wortung dieser Frage bietet es sich an, ei-nen Blick auf die Merkmale von XML/EDI zu werfen und diese mit klassischemEDI zu vergleichen. Die �berlegungensollen anhand der im letzten Kapitel dar-gestellten L�sung erl�utert werden. Wirwollen die Ergebnisse in f�nf Thesen zu-sammenfassen:

1. XML/EDI �ffnet Netze.2. XML/EDI erleichtert die Weiterver-

arbeitung vonDaten.3. XML/EDI f�hrt zu h�herer Flexibili-

t�t.4. XML/EDI erleichtert die Konvertie-

rung zwischen Formaten.5. XML/EDI senkt die Kommunikations-

kosten.

Unsere erste These lautet, dass XML/EDINetze �ffnen und einen Beitrag zur Sen-kung der Einstiegsh�rde f�r die Teilnahmean EDI-Netzen leisten wird. Dass eine sol-che H�rde heute existiert, wird darandeutlich, dass lediglich etwa f�nf Prozentder Unternehmen EDI nutzen, f�r die eineNutzung vorteilhaft w�re. Dies liegt ins-besondere an dem hohen Aufwand unddem zum Teil fehlenden Know-how, daszumAufbau klassischer EDI-Beziehungengebraucht wird. Demgegen�ber ist in dervorgestellten L�sung lediglich ein XML-f�higer Browser erforderlich, um ein Ge-sch�ftsdokument zu empfangen. Soll eineIntegration in die Inhouse-Systeme durch-gef�hrt werden, ist jedoch auch bei XML-L�sungen ein individueller Aufwand zurAnpassung notwendig. Die entsprechen-den Erfahrungswerte f�r die im viertenKapitel vorgestellte L�sung belaufen sichauf 1–2Manntage.

Die zweite These lautet, dass mit XML/EDI die Weiterverarbeitung von Datenvereinfacht wird. Dies wird erm�glichtdurch die Verf�gbarkeit von Programmier-

schnittstellen wie dem DOM. Auf dieseWeise lassen sich mithilfe frei verf�gbarerParser beispielsweise Auswertungspro-gramme erstellen, was bei klassischemEDI tendenziell zu einem h�heren Auf-wand f�hren w�rde.

Gem�ß unserer dritten These kannXML/EDI zu einer h�heren Flexibilit�tbeitragen. So handelt es sich bei XML umeinen „Metastandard“, der beispielsweisedie Abbildung verschiedener EDI-Stan-dards erm�glicht. Weiterhin lassen sichXML-Vorlagen leicht �ndern, wenn etwaneue Elemente in die auszutauschendenGesch�ftsdokumente aufgenommen wer-den. Dies kann zum Beispiel mit einemKonfigurationseditior durchgef�hrt wer-den, wie wir ihn in Abschnitt 4.2.1 dar-gestellt haben. Ebenso l�sst sich mithilfeder Zuordnung zu Style Sheets die Pr�sen-tation von Dokumenten relativ flexibelhandhaben.

Die vierte These lautet, dass mit XML/EDI die Konvertierung zwischen unter-schiedlichen Standards erleichtert wird.Entgegen h�ufig ge�ußerten Erwartungenkann aber auch XML nicht alle Kompati-bilit�tsprobleme per se l�sen. XML ver-spricht jedoch eine Vereinfachung: So exis-tieren Ans�tze, etwa auf der Basis des Stan-dards XSLT, mit denen eine Konvertierungzwischen unterschiedlichen XML-Stan-dards und auch in Fremdformate vor-genommenwerden kann.

Unsere f�nfte These lautet, dass XML/EDI zu niedrigeren Kommunikationskos-ten f�hrt. Dieser Vorteil ist nat�rlich nichtder Verwendung von XML im engerenSinne zu verdanken, sondern kommt auf-grund der Nutzung des Internet als Infra-struktur zustande. Im Vergleich zu den va-riablen Kosten, die an VANs zu zahlensind, sind diese Kosten bei Nutzung desInternet nahe null.

Bislang haben wir die Vorteile vonXML/EDI betont. Demgegen�ber sinddie Nachteile insbesondere darin zu sehen,dass bislang relativ wenig Erfahrungen mitder Nutzung dieser neuen Technologievorliegen und viele wichtige Standardisie-rungsaktivit�ten noch nicht abgeschlossensind.

Traditionelle Einw�nde gegen die Nut-zung des Internet als Grundlage f�r Ge-sch�ftskommunikation, denen man immernoch begegnet, sind u. E. etwas r�ckw�rts-gewandt und k�nnen – zumindest tech-nisch – als �berholt angesehen werden.Authentifizierung auf der Basis von Smart-

266


Cards und eine 128-bit-Verschl�sselung si-chern ein ausreichendes Maß an Vertrau-lichkeit f�r den Austausch von Handels-dokumenten, wie Bestellungen oder Rech-nungen.

Unter dem Strich kann XML einen gu-ten Beitrag dazu leisten, Netze f�r EDI-Anwendungen zu �ffnen. Dies kann einer-seits dazu f�hren, dass auch kleinere undmittelst�ndische Unternehmen in die Lageversetzt werden, relativ einfach eigeneEDI-Netze aufzubauen. Dar�ber hinauslassen sich bestehende EDI-Netze erwei-tern. Nicht von heute auf morgen, abernach und nach wird dies in vielen Berei-chen zu einer Abl�sung klassischer EDI-Netze f�hren.

Literatur

[BeMi00] Behme, H.; Mintert, S.: XML in derPraxis: Professionelles Web-Publishing mit derExtensible Markup Language. 2. Aufl., Bonn2000.

[Bosa97] Bosak J.: XML, Java, and the future ofthe Web. http://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.html,1997-10-03, Abruf am 2001-01-20.

[Curt96] Curtis, C.: EDI over the Internet: Letthe games begin. In: Internetweek, Issue 627,1996-09-09.

[Emme93] Emmelhainz, M. A.: EDI: ATotal Ma-nagement Guide. NewYork 1993.

[Kili94] Kilian, W.; Picot, A.; Neuburger, R.;Niggl, J.; Scholtes, K.; Seiler, W.: Electronic Da-ta Interchange. Baden-Baden 1994.

[Koto00] Kotok, A.: Extensible and more. AnUpdated Survey of XML Business Vocabula-ries. http://www.xml.com/pub/2000/08/02/ebiz/extensible.html, 2000-08-02, Abruf am2001-01-20.

[Mach97] Macherius, I.: XML: Professionelle Al-ternative zu HTML. http://www.heise.de/ix/artikel/1997/06/106/, 1997-05-10, Abruf am2001-01-20.

[MaCh93] Marcella, A.; Chan, S.: EDI Security,Control, and Audit. Norwood 1993.

[Neub94] Neuburger, R.: Electronic Data Inter-change: Einsatzm�glichkeiten und �konomi-sche Auswirkungen.M�nchen 1994.

[Nigg94] Niggl, J.: Die Entstehung von Electro-nic Data Interchange Standards. Wiesbaden1994.

[SePR97] Segev, A.; Porra, J.; Roldan, M.: Inter-net-Based EDI Strategy. Working paper97-WP-1021, Haas School of Business, Univer-sity California of Berkeley, Berkeley 1997.

[Stef00] Steffen, T.: Internet-Quellen zu XML/EDI. In: Wirtschaftsinformatik 42 (2000) 1, S.78–86.

[Tuck97] Tucker, M.: EDI and the Net: A profita-ble partnering. In: Datamation, April 1997.

[TuFe01] Turowski, K.; Fellner, K.: XML in derbetrieblichen Praxis. Standards, M�glichkei-ten, Praxisbeispiele. Heidelberg 2001.

[W3C00] World Wide Web Consortium: Exten-sible Markup Language (XML). http://www.w3.org/XML/, 2000-05-03, Abruf am 2001-01-20.

[W3C00a] World Wide Web Consortium: Exten-sible Stylesheet Language (XSL). http://www.w3.org/Style/XSL/, 2000-05-06, Abrufam 2001-01-20.

[W3C00b] World Wide Web Consortium: Docu-ment Object Model (DOM). http://www.w3.org/DOM/, 2000-04-14, Abruf am 2001-01-20.

[W3C00c] World Wide Web Consortium: Exten-sible Markup Language (XML) 1.0 (SecondEdition) W3C Recommendation 2000-10-06.http://www.w3.org/TR/REC-xml, Abruf am2001-01-20.

[WHB01] Weitzel, T.; Harder, T.; Buxmann, P.:Electronic Business und EDI mit XML. Hei-delberg 2001.

[WWBK99]Westarp, F.; Weitzel, T.; Buxmann, P.;K�nig, W.: The Status Quo and the Future ofEDI – Results of an Empirical Study. In: Pro-ceedings of the European Conference on Infor-mation Systems (ECIS‘99), Copenhagen, S.719–731.

[WWBK00]Westarp, F.; Weitzel, T.; Buxmann, P.;K�nig, W.: The Standardization Problem inNetworks – AGeneral Framework. In: Jakobs,K.: Information Technology Standards andStandardization: A Global Perspective. Hers-hey, PA, 2000.


267

anwendung der extensible markup language (xml): konzeption und implementierung einer webedi-lösung

Documents