|
|
|
|
 |
|
XML Bibliothek |
XML und die Neuerschaffung der IT-WeltZweiter Teil: Electronic BusinessAutor: Karin OppelDie Ausführung von umfangreichen kommerziellen Transaktionen im Internet unter Einschluß zahlreicher großer und kleiner Unternehmen im Rahmen von Lieferketten überfordert EDI. Mit XML steht ein neuer Standard zur Verfügung, der die notwendige Flexibilität mitbringt. Aber auch an XML muß noch gearbeitet werden.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, XML für kommerzielle Transaktionen einsetzen zu können. Die IT-Welt hat sich in den letzten Jahren von verschiedenen Seiten her auf eine neuartige Form der Anwendung zubewegt, die nun meist mit dem Szenarium von Electronic Business umschrieben wird. Kunden und Lieferanten sind dabei online verbunden und wickeln die ihre Geschäftsbeziehungen weitestgehend digital ab. Die Lieferung von Ersatzteilen, Büchern, Pizzen usw., erfolgt natürlich weiterhin konventionell. Allerdings nimmt auch hier die Digitalisierung zu, zum Beispiel bei der Lieferung von Druckwerken 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 diesen Datensatz ohne weitere manuelle Bearbeitung. Probleme entstehen dabei ausschließlich wegen nicht kompatibler Systeme: die Finanzbuchhaltung zum Beispiel könnte mit dem Datensatz nichts anfangen, wenn er in einer EDI-Norm verschlüsselt wäre, aber sich nicht an die spezifische EDI-Variante des Empfängers halten würde. Andererseits läßt sich leicht erkennen, wie groß die Vorteile eines solchen Austausches wären, wenn er auf allgemein akzeptierten Standards beruhen würde. Damit ließen sich nicht nur größere Datenmengen verarbeiten, man könnte so auch die Fehleranfälligkeit manueller oder automatischer Konvertierungen vermeiden.
Ein Viertel Jahrhundert EDIEDI (Electronic Data Interchange) hat bereits seit über zwanzig Jahren eine systemübergreifende Normierung von Datensätzen versucht. EDI codiert Rechnungsnummer, Artikelpreis usw., so daß EDI-fähige 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 sehr bescheiden. Groß, weil es funktioniert und die Unternehmen, die es einsetzen, seit Jahren damit ihre Daten problemlos austauschen. Bescheiden, weil EDI andererseits nie einen Durchbruch auf breiter Ebene geschafft hat. Derzeit wenden weltweit erst etwa 125.000 Unternehmen und Organisationen EDI an – fast ein Vierteljahrhundert nach dem Start von EDI. Die größte Verbreitung hat EDI in den USA mit rund 80.000 Anwendern, das sind aber nur etwa 2 Prozent aller US-Unternehmen. Verbreitet wird EDI in Großunternehmen genutzt, etwa das VDA-Format bei KFZ-Herstellern. Banken arbeiten seit langem sehr erfolgreich mit dem EDI-Subset SWIFT, es ist vielleicht das bekannteste EDI-Produkt. Kleine und mittlere Unternehmen werden dagegen durch hohe Kosten und große Komplexität von traditionellem EDI abgehalten. Hier wirkt sich das Grundproblem von EDI besonders aus, daß nahezu jede Geschäftsbeziehung separat definiert und implementiert werden muß. In die neue Welt des Electronic Business passen solche Beschränkungen nur sehr schlecht. Das Transportieren von Datenfeldern im Batch-Verfahren reicht für das von spontaner Interaktivität geprägte Web nicht aus. Ziel ist schließlich, die durchgängige Verfügbarkeit des Internet, mit der nun erstmals jeder Arbeitsplatz, ja sogar jeder (kaufkräftige) Haushalt, direkt für die IT erreichbar ist, und seine Nutzung 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.
EDI und XMLVor diesem Hintergrund wird verständlich, warum Unternehmen und Organisationen aus den unterschiedlichsten Branchen sich dem neuen Standard XML zuwenden. Zum einen ist XML für den Einsatz im Web optimiert, es ist einfach und leicht verständlich, vor allem ist es aber über die Dokumentdefinition DTD (Document Type Definition) gut anpaßbar. Eine DTD beschreibt in einer für Menschen und Rechner lesbaren Form die Typisierung von Dokumenten, muß also branchen- bzw. anwendungsbezogen erstellt werden. Damit lassen sich spezifische Bedürfnisse umsetzen, ohne den allgemeinen Standard zu verletzen. Dazu kommt ein weiteres: im Unterschied zu EDI verfolgt XML einen viel allgemeineren Ansatz. EDI ist speziell für Datenaustausch zwischen Unternehmen geschaffen, XML erlaubt es, Dokumente aller Art zu beschreiben: Röntgenbilder, CAD-Files, Bestellungen, Fachbücher, Musikstücke. Jedes spezielle 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 von XML wie von selbst eingestellt: die Akzeptanz der Benutzergruppen, 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 allen Branchen haben sich Unternehmen und Organisationen zusammengefunden, um XML-Anwendungen zu entwickeln. Dabei werden auch Anwendungen speziell für Electronic Business erstellt, unter anderem:
Mit einem auf Basis von XML fortentwickelten EDI können nicht nur die Daten selbst transportiert werden, sondern auch ihre semantische Bedeutung, also vollständige Geschäftsobjekte. Die Objekte können das Mapping übernehmen, d.h. die Umsetzung von XML-Dokumenten in die relationalen Strukturen einer Datenbank. Sie können aber auch direkt einen XML-Datenserver adressieren. Während nämlich EDI nur ein Format für den Austausch ist, das bei jeder Transaktion sowohl beim Sender als auch beim Empfänger konvertiert werden muß, bietet XML weitergehende Möglichkeiten. Nicht nur der Transport der Daten, sondern auch die Verarbeitung, Darstellung und Speicherung können unmittelbar in XML erfolgen. Electronic Business an den Grenzen von XMLAuch 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, wenn man sich ein wenig eingelesen hat, ohne weitere Hilfestellung. Ein XML-fähiger Browser kann dergleichen mit Hilfe von XML Style Sheets (XSL) sofort auf dem Bildschirm darstellen, ohne daß vorher aufwendige Masken generiert werden müssen. Notfalls lassen sich auch zusätzliche Informationen übertragen, die nicht in der DTD vorgesehen sind. Demgegenüber bleibt die reine EDI-Information eine Kette unverständlicher Zeichen, die nur von einer Anwendung ausgewertet werden kann, die die EDI-Struktur kennt. Der XML-String ist mit seinen Tag-Informationen immer lesbar und kann von Browsern, Datenbanken, Workflow-Systemen usw. immer bearbeitet werden. XML-Dokumente enthalten genügend Meta-Informationen, um von entsprechenden flexiblen Systemen ohne aufwendige Voranpassung verwendet werden zu können. Kein Kunststück, könnte ein XML-Kritiker hier einwenden, denn es ist in diesem Beispiel ebenso offensichtlich, daß das XML-Dokument wesentlich umfangreicher geworden ist, wofür vor allem die reine Textgröße der Tags verantwortlich ist. Dieselbe Information benötigt hier in XML etwa achtmal mehr Platz als im EDI-Format. Also benötigt XML mehr Speicherplatz und mehr Bandbreite für die Übertragung. Das sollte allerdings kein Problem sein, da Speicherplatz immer billiger geworden ist und die Bandbreiten Im Internet heftig im Wachsen begriffen sind. Schätzungen gehen davon aus, daß EDI-Transaktionen, die auf Basis von XML durchgeführt werden, um etwa 35 Prozent anwachsen. Zum einen bringt XML also eine nicht unerhebliche Beanspruchung der Kommunikationstechnik, die wohl noch einige Hausaufgaben machen muß, bevor rund um den Globus Electronic Commerce und Electronic Business auf Basis der "dicken" XML-Dokumente abgewickelt werden können. 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: auch die Verarbeitung und Speicherung von XML-Dokumenten stellt auch ganz neue technische Anforderungen an die IT. Die schlichte Konvertierung von XML in SQL ist zwar prinzipiell machbar, kommt aber für hochvolumige Transaktionen nicht in Frage, wenn man den Anwendern eine angemessene Leistung hinsichtlich Datenspeicherung und –retrieval bieten will. Beim Mapping von hierarchisch mehrfach verschachtelten XML-Dokumenten auf relationeale SQL-Strukturen müßte man ja eine riesige Zahl von Tabellen, Spalten und Relationen nicht nur ansprechen, sondern auch mit einigen Overheads verwalten können. Daß das zu Problemen führen muß, wird deutlich, sobald man nicht die üblichen primitiven XML-Demos nach dem Schema "Name-Straße-Ort" vor sich hat, sondern wie im vorliegenden Beispiel praxisgerechte Fälle. Solche XML-Dokumente in Massen und in Echtzeit mit hoher Verfügbarkeit zu verarbeiten, stellt Anforderungen an die relationale Datenbanktechnik, die nur unter Laborbedingungen zu lösen sind. Hier werden absehbar "echte" XML-Server benötigt. Eine weitere Gefahr kommt aus der Logik von XML selbst. Da XML "nur" eine Meta-Sprache ist, hängt ihre praktische Relevanz ganz davon ab, was die jeweiligen Benutzergruppen aus XML machen. Da der Standard derzeit noch ganz am Anfang steht, ist es unproblematisch, daß zahlreiche anwendungsspezifische XML-Initiativen entstehen. Sobald aber für ein Gebiet mehrere konkurrierende Ansätze auf Basis von XML verfolgt werden, wird die schöne XML-Welt die ersten Risse bekommen. Das W3C-Konsortium ist ausschließlich für die Definition der Meta-Sprache zuständig. Man muß nur die Vielfalt von Organisationen betrachten, die den Protagonisten von XML/EDI zufolge für die Festlegung von DTDs in Frage kommen – und das Problem wird leicht erkennbar:
Daß alle diese heterogenen Gruppen ausgerechnet in Sachen XML auf Dauer am selben Strang ziehen sollen, erscheint fraglich. Schon wird deshalb vor der Gefahr einer Fragmentierung und "Balkanisierung" von XML gewarnt, die zu inkompatiblen DTDs führen könnten, und vermutlich wird es auch Versuche geben, auf XML-proprietäre Lösungen aufzusetzen. Schließlich sollte man bei alledem nicht ganz vergessen, daß sich XML und alles, was sich darum herum entwickelt, derzeit hauptsächlich noch im Ankündigungsstadium befindet. Praktische Erfahrungen mit Transaktionsvolumen unter XML gibt es noch nicht. So läßt sich die "XML-Unterstützung" für ein Produkt, etwa eine 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 festzustellen. Trotzdem wird sich Electronic Business durchsetzen und damit auch XML, denn die erwähnten konzeptionellen Vorteile von XML sind einfach zu groß. Es ist absehbar, daß die Kombination HTML-SQL-CGI bzw. IDAPI oder ASP (Active Server Pages),die derzeitige Basis für den Austausch von Unternehmensdaten im Internet, den kommenden Anforderungen des Electronic Business nicht mehr gewachsen ist. Hier bietet nur XML die Flexiblität, die notwendig ist, um auch externe Systeme ohne Aufwand anzubinden. Angesichts dieses Vorteils, den kein anderer Ansatz bietet, relativieren sich die mit XML verbundenen Probleme. Was die Kommunikationstechnik betrifft, kommt die Lösung nicht nur über verbesserte Bandbreiten, 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. Hinsichtlich der Speicherung und Verarbeitung der Informationen muß man sich von der Vorstellung verabschieden, einen neuen technologischen Ansatz, wie ihn XML zweifellos darstellt, mit den herkömmlichen Techniken abdecken zu können. Anders: relationale Datenbanken stellen für XML-Dokumente einfach nicht die geeignete Technologie für die persistente Speicherung von XML-Dokumenten dar. 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 hervorragende Dienste. XML-Dokumente stellen aber eine ganz
neue Art der Information dar: das "Dokument"
legt eine andere Sicht auf die Realität zugrunde als
der "Datensatz", dem man Dinge wie
hierarchische Strukturen oder Querverweise immer 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 benötigt man daher spezielle
Informationsserver, also eine eigenständige
Technologie, die von vorneherein auf die mit XML
verbundenen Anforderungen zugeschnitten ist.
Was ist XML?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 formalen Kriterien (wie Überschrift, Textkörper usw.) zu strukturieren, sondern auch nach inhaltlichen Gesichtspunkten. Um den ganz unterschiedlichen Inhalten des Web Rechnung zu tragen, ist XML dabei so flexibel, daß die jeweiligen inhaltlichen Strukturmerkmale von Benutzergruppen selbst definiert werden können. So wäre es beispielsweise denkbar, daß Meteorologen für den Austausch von Wetterdaten eigene 'Tags' wie etwa <Temperatur>, <Luftdruck>, <Windstärke> usw. 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 vom XML-Server aus verschiedenen Informationstypen oder auch aus vorhandenen relationalen Daten zusammengesetzt werden. 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. Tamino: ein Informationsserver für Electronic BusinessTamino ist ein XML-Informationsserver, der für Electronic-Business-Anwendungen optimiert ist. Eine Basistechnologie von Tamino ist XML, der neue Standard im Web. Tamino verfügt über eine native XML-Engine und über verschiedene Möglichkeiten, bestehende Datenhaltungssysteme direkt in die XML-Welt zu integrieren. Damit kann Tamino als umfassender Informationsserver fungieren und Web- mit Unternehmensdaten zusammenbringen.
Abbildung 1: Business-to-Bussiness-Kommunikation mit XML/EDI |
