Ein wesentlicher Grund für die rasante Entwicklung von XML und die überaus große Akzeptanz, die dieser neue Standard in der gesamten IT-Welt gefunden hat, liegt in der Aussicht, ihn für kommerzielle Transaktionen einsetzen zu können. Viele Unternehmen haben sich in den letzten Jahren von verschiedenen Seiten her auf eine neuartige Form der Anwendung zubewegt, die nun meist als Electronic Business umschrieben wird. Kunden und Lieferanten sind dabei online verbunden und wickeln ihre Geschäftsbeziehungen weitestgehend digital ab. Die Lieferung von Ersatzteilen, Büchern, Pizzen etc., erfolgt natürlich weiterhin konventionell. Allerdings nimmt auch hier die Digitalisierung zu, zum Beispiel bei der Lieferung von Texten, Bildern und Musikstücken über das Internet.
Electronic Business umfaßt natürlich mehr, als eine Bestellung oder eine Rechnung per E-Mail zu versenden. Im Prinzip geht es darum, daß die IT-Systeme bei Sender und Empfänger direkt verbunden werden. Dabei sendet beispielsweise ein Warenwirtschaftssystem eine Rechnung als Datensatz, und die Finanzbuchhaltung des Empfängers importiert diese Daten ohne weitere manuelle Bearbeitung. Probleme entstehen dabei durch nicht kompatible Systeme: Die Finanzbuchhaltung zum Beispiel kann mit den Daten nichts anfangen, wenn sie nicht in spezifischen EDI-Varianten der Finanzbuchhaltung verschlüsselt sind. Ferner lassen sich die Vorteile eines solchen Austausches leicht erkennen, wenn es allgemein akzeptierte Standards gäbe. Damit wären nicht nur größere Datenmengen zu verarbeiten, man könnte so auch die Fehleranfälligkeit manueller oder automatischer Konvertierungen vermeiden.
Ein Vierteljahrhundert EDI
Mit EDI (Electronic Data Interchange) versucht man bereits seit über zwanzig Jahren die systemübergreifende Normierung von Datensätzen. Rechnungsnummer, Artikelpreis etc. werden so codiert, daß Anwendungen Daten mit Hilfe eines Konverters im Batch-Verfahren im- und exportieren können. Der Erfolg von EDI und von Abkömmlingen wie Edifact war groß und zugleich doch bescheiden. Groß, weil es funktioniert und die Unternehmen, die es einsetzen, seit Jahren damit ihre Daten problemlos austauschen; bescheiden, da EDI nie einen Durchbruch auf breiter Ebene geschafft hat.
Derzeit wenden weltweit erst etwa 125000 Unternehmen und Organisationen EDI an - fast ein Vierteljahrhundert nach dem Start des Verfahrens. Die größte Verbreitung hat EDI in den USA mit rund 80000 Anwendern. Das sind aber nur etwa zwei Prozent aller US-Unternehmen. Vor allem Großunternehmen nutzen EDI, etwa die Autohersteller das VDA-Format. Banken arbeiten seit langem sehr erfolgreich mit dem EDI-Subset "Swift". Es ist vielleicht das bekannteste EDI-Produkt. Kleine und mittlere Unternehmen schrecken dagegen bislang die hohen Kosten und große Komplexität von traditionellem EDI ab (vergleiche Seite 98). Hier wirkt sich das Grundproblem dieses elektronischen Datenaustausches besonders aus: Nahezu jede Geschäftsbeziehung muß separat definiert und implementiert werden.
In die neue Welt des Electronic Business passen solche Beschränkungen nur sehr schlecht. Das Transportieren von Daten im Batch-Verfahren reicht für das von Interaktivität geprägte Web nicht aus. Ziel ist schließlich, die durchgängige Verfügbarkeit des Internet. Jeder Arbeitsplatz, sogar jeder Privathaushalt soll direkt elektronisch erreichbar sein, auch für kommerzielle Transaktionen. Anders ausgedrückt: Electronic Business braucht einen allgemeinen Standard für den Datenaustausch, den das starre Konzept von EDI nicht bieten kann.
Verständlich also, daß sich Unternehmen und Organisationen aus den unterschiedlichsten Branchen dem neuen Standard XML zuwenden. Er ist für den Einsatz im Web optimiert, einfach und leicht verständlich und bietet vor allem mit der Dokumentdefinition DTD (Document Type Definition) die notwendige Flexibilität. Eine DTD beschreibt in einer für Menschen und Rechner lesbaren Form die Typisierung von Dokumenten, muß also branchen- beziehungsweise anwendungsbezogen erzeugt werden. Damit kann man spezifische Bedürfnisse erfüllen, ohne den allgemeinen Standard zu verletzen.
Dazu kommt ein weiteres: XML verfolgt einen viel allgemeineren Ansatz als EDI. Letzteres dient speziell dem Datenaustausch zwischen Unternehmen, XML erlaubt es, Dokumente aller Art zu beschreiben: Röntgenbilder, CAD-Files, Bestellungen, Fachbücher, Musikstücke. Jedes Aufgabengebiet läßt sich als Anwendungsfall der XML-Logik abdecken. Und da dies, zumindest auf den ersten Blick, mit relativ einfachen Mitteln zu bewerkstelligen ist, hat sich die wesentliche Voraussetzung für den Erfolg der Meta-Sprache wie von selbst eingestellt: die Akzeptanz der Benutzer, die sich ja auf gemeinsame DTDs verständigen müssen. In der Industrie gibt es bereits zahlreiche Initiativen zur Einführung von XML als Standard für den Datenaustausch. In vielen Branchen haben sich Unternehmen und Organisationen zusammengefunden, um entsprechende Anwendungen zu entwickeln. Dabei werden auch Normen speziell für Electronic Business definiert, unter anderem:
Commerce XML (cXML): ein neu eingeführter Standard zur Beschreibung von Kataloginhalten und für sichere kommerzielle Transaktionen.
Open Buying on the Internet (OBI): ein Standard für den Business-to-Business-Handel übers Internet auf Basis von HTML, SSL, SET und X.509.
Open Trading Protocol (OTP): eine Umgebung für den Verkauf an Verbraucher übers Web einschließlich Regelung von Zahlungsmodalitäten.
Open Financial Exchange (OFX): das von Intuit Quicken und Microsoft Money benutzte Format für die Kommunikation mit Banken.
Mit einem auf Basis von XML fortentwickelten EDI lassen sich nicht nur die Daten selbst transportieren, sondern auch ihre jeweilige Bedeutung, also vollständige Geschäftsobjekte. Sie übernehmen auch das Mapping, das heißt die Umsetzung von XML-Dokumenten in die Strukturen einer Datenbank. Die XML-Objekte können aber auch direkt einen XML-Datenserver ansprechen. Während EDI nur ein Format für den Austausch ist und die Daten bei jeder Transaktion sowohl beim Sender als auch beim Empfänger konvertiert werden müssen, bietet XML weitergehende Möglichkeiten. Nicht nur der Transport der Daten, sondern auch die Verarbeitung, Darstellung und Speicherung können unmittelbar in XML erfolgen.
Auch die wirkliche Welt wurde nicht an einem Tag erschaffen, und man darf nicht erwarten, daß mit dem Einsatz einer neuen Meta-Sprache, so mächtig sie sein mag, gleich alle (technischen) Probleme des Electronic Business gelöst sind. Das Beispiel im Kasten zeigt Stärken, aber auch Schwächen des XML-Ansatzes. Den XML-Code versteht man mit einiger Übung ohne weitere Hilfestellung. Ein XML-fähiger Browser kann entsprechende Dokumente mit Hilfe von XML Style Sheets (XSL) sofort auf dem Bildschirm darstellen, ohne daß man vorher Masken generieren muß. Notfalls lassen sich auch zusätzliche Informationen übertragen, die nicht in der DTD vorgesehen sind.
Mehr Speicherplatz und Übertragungsleistung nötig
Demgegenüber bleibt die reine EDI-Information eine Kette unverständlicher Zeichen, die nur eine Anwendung auswerten kann, welche die EDI-Struktur kennt. Der XML-String ist mit seinen Tag-Informationen immer lesbar und läßt sich von Browsern, Datenbanken, Workflow-Systemen etc. stets bearbeiten. XML-Dokumente enthalten genügend Meta-Informationen, um von entsprechenden flexiblen Systemen ohne aufwendige Voranpassung verwendet werden zu können.
Kein Kunststück, so ein XML-Kritiker, denn es ist in diesem Beispiel ebenso offensichtlich, daß das XML-Dokument wesentlich umfangreicher ist, was vor allem an der reinen Textgröße der Tags liegt. Dieselbe Information benötigt in XML etwa achtmal soviel Platz wie im EDI-Format. Also braucht XML mehr Speicherplatz und eine höhere Übertragungsleistung. Das sollte allerdings kein großes Problem sein, da Speicherplatz immer billiger wird und die Bandbreiten im Internet kräftig wachsen.
Zum einen beansprucht XML also nicht unerheblich die Kommunikationstechnik und sie muß wohl noch einige Hausaufgaben machen, bevor Electronic Commerce rund um den Globus auf Basis der "dicken" XML-Dokumente stattfinden kann. Während die Industrie an diesem Problem aber ohnehin - ganz unabhängig von XML - arbeitet, wird eine andere Implikation von XML-Business noch nicht überall gesehen: Die Verarbeitung und Speicherung von XML-Dokumenten stellt auch ganz neue technische Anforderungen an die IT. Die Konvertierung von XML in SQL läßt sich zwar prinzipiell bewerkstelligen, kommt aber für hochvolumige Transaktionen nicht in Frage, wenn man den Anwendern eine angemessene Leistung hinsichtlich Datenspeicherung und -retrieval bieten will.
Beim Abbilden von hierarchisch mehrfach verschachtelten XML-Dokumenten auf relationale Strukturen müßte man eine hohe Zahl von Tabellen, Spalten und Relationen nicht nur ansprechen, sondern auch verwalten können. Sobald man nicht die üblichen primitiven XML-Demos nach dem Schema "Name-Straße-Ort" vor sich hat, sondern praxisgerechte Fälle, führt das zu Problemen. Solche XML-Dokumente in Massen und in Echtzeit mit hoher Verfügbarkeit zu verarbeiten, stellt Anforderungen an die relationale Datenbanktechnik, die bisher nur unter Laborbedingungen zu erfüllen sind. Hier benötigt man "echte" XML-Server.
Ein anderes Problem erwächst aus dem Wesen von XML selbst. Da es sich "nur" um eine Meta-Sprache handelt, hängt die praktische Bedeutung von XML ganz davon ab, was die jeweiligen Benutzer daraus machen. Der Standard steckt derzeit noch in den Kinderschuhen und es ist unproblematisch, daß schon zahlreiche anwendungsspezifische XML-Initiativen entstehen. Sobald für ein Gebiet mehrere konkurrierende Ansätze auf Basis von XML verfolgt werden, dürfte die schöne XML-Welt die ersten Risse bekommen.
Die Gefahr der "Balkanisierung"
Das W3C-Konsortium ist ausschließlich für die Definition der Meta-Sprache zuständig. Man muß nur die Vielfalt von Organisationen betrachten, die für die Festlegung von DTDs in Frage kommen, und das Problem wird leicht erkennbar:
- Internationale Standardisierungsgremien,
- Industrievereinigungen,
- Teilnehmer von bi- oder multilateralen Abkommen zum Informationsaustausch,
- Unternehmen, die Lieferanten oder Kunden Informationen zur Verfügung stellen wollen,
- Unternehmen, die von Lieferanten oder Kunden Informationen erhalten wollen.
Daß alle diese verschiedenen Gruppen in Sachen XML auf Dauer am selben Strang ziehen sollen, erscheint fraglich. Schon gibt es deshalb Warnungen vor der Gefahr einer Fragmentierung und "Balkanisierung" von XML. Inkompatible DTDs könnten entstehen, und vermutlich wird es auch Versuche geben, auf XML proprietäre Lösungen aufzusetzen.
Die Probleme mit XML relativieren sich
Schließlich sollte man bei alledem nicht vergessen, daß sich XML und alles, was sich darum herum entwickelt, derzeit hauptsächlich noch im Ankündigungsstadium befindet. Praktische Erfahrungen mit Transaktionsvolumina unter XML gibt es noch nicht. So läßt sich die "XML-Unterstützung" für ein Produkt, etwa einer Datenbank, schnell verkünden. Ob es die XML-Daten tatsächlich in natürlicher Form abspeichert oder doch die Konvertierung in relationale Strukturen vornimmt, bleibt abzuwarten.
Trotzdem wird sich Electronic Business durchsetzen und damit auch der Standard XML, denn er bietet die erwähnten konzeptionellen Vorteile. Die Kombination HTML-SQL-CGI beziehungsweise IDAPI oder ASP (Active Server Pages) - die derzeitige Basis für den Austausch von Unternehmensdaten im Internet - ist den kommenden Anforderungen des Electronic Business nicht mehr gewachsen. Hier besitzt nur XML die Flexiblität, die man braucht, um auch externe Systeme ohne Aufwand anzubinden. Angesichts dieses Vorteils, den kein anderer Ansatz bietet, relativieren sich die mit XML verbundenen Probleme.
Was die Anforderungen an die Kommunikationstechnik betrifft, kommt Hilfe nicht nur über verbesserte Übertragungsleistungen, sondern auch von XML selbst.
XML/EDI sieht beispielsweise den Einsatz von Repositories vor, in denen Templates abgelegt sind, oder von Tokens, die XML-Tags verwalten; damit wird die Nachrichtenmenge reduziert.
Die Speicherung und Verarbeitung der Informationen können bei XML nicht die herkömmlichen Techniken übernehmen. Anders gesagt: Relationale Datenbanken bieten XML-Dokumenten einfach nicht die geeignete Technologie für die Speicherung. RDBMS wurden vor rund 20 Jahren geschaffen für Massendaten, die sich leicht in Form von relationalen Tabellen darstellen lassen, und dafür leisten sie auch gute Dienste.
XML-Dokumente stellen aber eine ganz neue Art der Information dar: Dem "Dokument" liegt eine andere Sicht auf die Realität zugrunde als dem "Datensatz", dem man hierarchische Strukturen oder Querverweise nur mit Klimmzügen beibringen kann - Klimmzüge, die sich außerhalb der Entwicklungslabors in Leistungseinbußen niederschlagen. Für Verarbeitung und Speicherung von XML-Daten benötigt man daher spezielle Informationsserver, also eine eigenständige Technologie, die auf die mit XML verbundenen Anforderungen zugeschnitten ist.
Angeklickt
XML ist eine universelle Konvention zur Beschreibung von Daten auf der Basis von SGML und geht weit über den bislang im Web hauptsächlich verwendeten HTML-Standard hinaus. Anders als HTML ist XML in der Lage, Daten nicht nur nach den allgemein üblichen formalen Kriterien (wie Überschrift, Textkörper etc.) zu strukturieren, sondern auch nach inhaltlichen Gesichtspunkten. XML trägt dabei den ganz unterschiedlichen Inhalten des Web Rechnung und ist so flexibel, daß die Benützer selbst die jeweiligen inhaltlichen Strukturmerkmale definieren können. So wäre es beispielsweise möglich, daß Meteorologen für den Austausch von Wetterdaten eigene "Tags" wie etwa , , etc. festlegen und diese Definitionen in entsprechenden Templates ablegen. XML-fähige Anwendungen könnten dann derartige Web-Seiten direkt verarbeiten, also beispielsweise Wetterdaten automatisch per Web auswerten.
XML bietet die Möglichkeit, vom Browser aus direkt auf XML-fähige Server zuzugreifen und Informationen zu recherchieren, die der XML-Server aus verschiedenen Informationstypen oder auch aus vorhandenen relationalen Daten zusammensetzt. Den gleichen Service kann auch eine Anwendung benutzen. Beide verwenden die URL-Adresse für die Verbindung zum gewünschten XML-Server. Klassische Anwendungen können weiterhin parallel dazu laufen und auf ihre SQL-Daten zugreifen.
*Karin Oppel ist Produkt-Marketing-Manager bei der Software AG in Darmstadt.