computerwoche.de

Archiv

XML für den Austausch von Business-Informationen

"Wir definieren Grundlagen für den Welthandel"

30.06.2000
MÜNCHEN (ws) - Die Organization for the Advancement of Structured Information Standards (OASIS) will produktunabhängige Formate wie SGML, XML und HTML fördern. In ihr sind mehr als 100 Hersteller vertreten. Sun Microsystems stellt mit Bill Smith den Präsidenten. CW-Redakteur Wolfgang Sommergut sprach mit ihm über neue XML-Funktionen in Java sowie über die Aussichten der von OASIS und der UNO getragenen ebXML-Initiative.

CW: Sun bewirbt Java als die ideale Ergänzung zu XML: Plattformunabhängige Programme für plattformunabhängige Daten. Aber was tun Sie konkret, um die Verarbeitung von XML-Dokumenten mit Java zu vereinfachen?

Smith: Wir haben dazu im Rahmen des Java Community Process (JCP) drei Initiativen ins Leben gerufen: sie betreffen das Parsen von XML-Daten, Data-Binding und Messaging. Im ersten Fall arbeiten wir an einer API mit dem Namen JAXP, die Standardschnittstellen zu DOM- und SAX-Parsern definiert.

CW: Das Document Object Model (DOM) und die Simple API for XML (SAX) sind ja schon Standardschnittstellen für Parser. Wozu soll dann JAXP gut sein?

Smith: JAXP ist die Umsetzung von DOM und SAX in Java. Sie werden unter dieser Bezeichnung Teil der Java-API.

CW: Wie stehen Sie zu unabhängigen Vorschlägen wie JDOM, die Alternativen zu DOM fordern, weil dieses sprachunabhängig gehalten ist und daher die Möglichkeiten von Java nicht ausschöpfe?

Smith: Wir sehen in DOM die offizielle Schnittstelle des W3-Consortium (W3C) zu HTML- und XML-Dokumenten. Die unterstützen wir. Zusätzlich bieten wir Java-Programmierern mit dem Data-Binding die Möglichkeit, XML-Daten zu verarbeiten, ohne dass sie sich mit dieser Technologie im Detail auseinander setzen müssen. Dabei werden Schemata zu Java-Klassen kompiliert. Dieses Verfahren eignet sich nicht für alle XML-Dokumente, aber besonders für solche, die Geschäftspartner beim E-Business austauschen, beispielsweise Bestellungen oder Rechnungen. Für den Entwickler präsentieren sich diese dann als eine Menge von Java-Klassen statt als XML-Dokumente. Dabei muss viel weniger Code geschrieben werden als mit DOM oder gar SAX. Außerdem haben wir erst vor kurzem mit der Ausarbeitung von Schnittstellen für XML-Messaging begonnen. Diese sollen besonders auf den Austausch von XML-Daten zugeschnitten sein, der den Vorschlägen der ebXML-Initiative folgt (Anmerkung der Red.: ebXML ist eine Kooperation von OASIS und der UNO zur Definition von XML-Schemata für den Austausch von Business-Informationen).

CW: Mit der Unterstützung von ebXML stellt sich Sun gegen das Microsoft-Projekt "Biztalk". Können deshalb die Java-APIs für das XML-Messaging als Antwort auf Microsofts Biztalk-Server gesehen werden?

Smith: Es gibt da Ähnlichkeiten, allerdings beschränkt sich unsere Spezifikation darauf, wie XML-Nachrichten ausgetauscht werden. Der Biztalk-Server leistet mehr. Unsere Entwicklung findet zudem im Rahmen des offenen ebXML-Standardisierungsprozesses statt.

Smith: In vielen Fällen bewährt sich eine Arbeitsteilung, bei der das W3C die Spezifikation entwickelt und Organisationen wie Apache eine freie Referenzimplementierung leistet. Beispiele sind der Parser "Xerces" oder der XSLT-Prozessor "Xalan". Als dritte Säule kommt dann das Herstellerkonsortium OASIS hinzu, das die nötigen Testwerkzeuge anbietet, um die Standardkonformität zu überprüfen.

CW: Dieses Modell lässt aber nicht viel Raum für kommerzielle Varianten solcher Produkte?

Smith: Auch ohne Open Source wäre mit solcher Basistechnologie wenig Geschäft zu machen. Beim Design von XML gingen wir davon aus, dass ein guter Programmierer weniger als drei Wochen für einen Parser braucht. In der Praxis dauert es etwas länger, vielleicht sechs Wochen. Aber damit kann man nicht viel Geld verdienen.

CW: Wenn das so einfach sein soll, wie erklären Sie dann, dass so große Firmen wie Oracle oder Microsoft bis heute keine standardkonformen Parser anbieten können?

Smith: Das kann ich nicht verstehen.

CW: Eine XML-Anwendung, für die Apache mit Hilfe von IBM eine Referenzimplementierung entwickelt, ist das Simple Object Access Protocol (SOAP). Es wurde ursprünglich von Microsoft vorgeschlagen, aber von Sun abgelehnt. Diese Haltung haben Sie mittlerweile aufgegeben. Woran liegt das?

Smith: Microsoft legte den Entwurf für die Version 1.0 von SOAP der Internet Engineering Task Force (IETF) vor. Dieser wies aber derartige technische Defizite auf, wie sie ein Standard nicht haben darf. Trotzdem versuchten wir an der Weiterentwicklung teilzunehmen. Dies scheiterte vorerst aber, weil bei den von Microsoft organisierten Treffen angeblich alle Hotels bereits ausgebucht waren. Sun hat aber dann von sich aus Veranstaltungen zu diesem Zweck organisiert. Die Version 1.1 wurde schießlich von uns zusammen mit IBM und Microsoft als Vorschlag an das W3C übergeben. Die deutlichen Verbesserungen seit der ursprünglichen Fassung gehen hauptsächlich auf das Konto von IBM. Für die Weiterentwicklung von "SOAP for J", das IBM an Apache übergeben hat, stellen wir eigene Programmierer ab.

CW: Glauben Sie, dass sich SOAP neben der Kommunikation zwischen Objekten auch für den Austausch von Business-Informationen eignet. Ist das der Grund, warum sich ebXML mit SOAP befasst?

Smith: SOAP könnte dafür durchaus als Transportmechanismus dienen. Allerdings fehlen ihm heute noch wichtige Funktionen für Business Messaging, beispielsweise Empfangsbestätigungen. ebXML wird solche Kommunikationsdienste aber erfordern. Es besteht dann die Möglichkeit, diese auf Grundlage von SOAP umzusetzen. SOAP wird aber dabei nur ein Transportmedium neben SMTP oder HTTP sein.

CW: Lassen Sie uns noch ein bisschen über die Rolle von Standardvokabularen wie ebXML und Schema-Portalen wie Biztalk und xml.org von OASIS sprechen. Momentan findet zwischen letzteren ein merkwürdiges Wettrennen darum statt, wer denn mehr Schemata hinterlegt hat. Sie dienen in der Praxis bestenfalls als Gelbe Seiten für branchenspezifische Anwendungen. Welchen Nutzen sollen sie denn überhaupt den Anwendern bieten?

Smith: Die Position von OASIS zu diesen Repositories ist relativ klar. Mit steigender Verbreitung und Nutzung von XML entsteht ein Bedarf nach zentraler Registrierung von Schemata. Anwender können dann die für sie relevanten finden, beispielsweise jene für Schuherzeuger oder Motorenhersteller.

Wichtiger wird mit der Zeit die Aufgabe werden, dass Applikationen dort automatisch die passenden Schemata abrufen können. Wenn Sie einen Auftrag für ein Paar Schuhe an einen Schuster in Taiwan geben, dann hat der wahrscheinlich nicht das passende Schema. Eine Anwendung, die diese Order bearbeiten soll, wird dann lokal nachsehen. Wenn sie es dort aber nicht findet, wird sie es von einem Repository abrufen. Dieser Dienst wird nach unserer Vorstellung ähnlich dezentral funktionieren wie der Domain Name Service (DNS). Er wird ein wesentlicher Bestandteil der Computer-Infrastruktur werden, auf dem der globale Handel im nächsten Jahrhundert beruht.

CW: Sollten Repositories die eingereichten Schemata qualifizieren? Wenn für einen bestimmten Zweck mehrere redundante Entwürfe eingehen oder bestimmte Schemata qualitativ schlecht sind, sollte da ein derartiger Dienst nicht eingreifen?

Smith: Im Moment beurteilt OASIS noch nicht die eingereichten Schemata, auch wenn sie redundant sind. Mit steigender Zahl der Vokabulare könnte sich aber durchaus eine Nachfrage nach einem solchen Service ergeben. Wir sind natürlich auch an qualitativ hochwertigen Schemata interessiert.

CW: Solche Orientierungshilfen sind umso dringender, als zahlreiche Initiativen konkurrierende Standards setzen wollen. Da rivalisiert nicht nur ebXML mit Biztalk, daneben existieren noch Rosettanet, BASDA oder cXML. Zusätzlich sind diese untereinander verflochten. So ist Microsoft, mit Biztalk Hauptkonkurrent des von OASIS und der UNO gemeinsam betriebenen ebXML, gleichzeitig Mitglied von OASIS. ebXML macht massive Anleihen bei "eCo" von Commerce One, diese Company ist aber wieder bei Biztalk mit von der Partie. Wie sollen Anwender da noch zurecht kommen?

Smith: Ich glaube, dass sie ebXML folgen sollten, wenn es in einem Jahr abgeschlossen ist. Dabei handelt es sich um eine wirklich offene und herstellerunabhängige Initiative. Jeder kann daran teilnehmen. Es entsteht unter Mitwirkung der UNO, die schon Edifact entwickelt hat und diese Erfahrung einbringen kann. ebXML bringt das Wissen der UN-Handelsorganisationen mit dem technischen Wissen von OASIS zusammen.

CW: Trotz des engen Zeitrahmens von 18 Monaten, den Sie sich für ebXML gesetzt haben, sind derart offene Prozesse mit so vielen Teilnehmern eher langsam. Das wirkt sich vor allem auf Produkte aus, in denen die entstehenden Spezifikationen umgesetzt werden. Dem gegenüber hat Microsoft als treibende Kraft hinter Biztalk die Möglichkeit, schon während der Spezifikationsphase mit der Entwicklung von Software zu beginnen. Tatsächlich wird in Kürze der Biztalk-Server auf den Markt kommen. Sun war nicht einmal in der Lage, auf der Basis der hauseigenen Java-Technologie ein ertragreiches Geschäft aufzubauen. Droht da ebXML nicht in erster Linie eine Ansammlung von viel Papier zu werden?

Smith: Bei unserem letzten Treffen vor einem Monat in Brüssel konnten wir bereits einen Prototypen solcher Software vorführen. Auf Basis des Entwurfs für das Verpacken und den Transport von Business-Informationen simulierten wir anhand von Benutzerprofilen die Buchung von Flügen und Mietwagen. Wir haben also bereits funktionierenden Code. Viele der Hersteller, die hinter ebXML stehen, meinen es ernst mit der Umsetzung in Produkten. Mit der Fertigstellung des Standards werden wir solche auch haben.