Nach eigenem Bekunden brachten die beiden Kooperationspartner ihre jeweiligen Stärken in die ebXML-Initiative ein: die Organisation for the Advancement of Structured Information Standards (Oasis) ihr technisches Know-how, die UN/Cefact als Schöpferin von Ansi X.12 und Edifact ihre Erfahrung mit Geschäftsprozessen. Vor kurzem schloss ebXML die Spezifikation eines übergreifenden Frameworks ab, das die Grundlage für weltweite elektronische Transaktionen bildet. Es soll sogar die Automatisierung von Geschäftsabläufen zwischen Partnern erlauben, die noch nie zuvor miteinander in Kontakt standen oder die aufgrund ihrer geografischen Distanz oder verschiedener Branchenzugehörigkeit unterschiedliche Terminologien für bestimmte Prozesse verwenden.
Damit leistet dieses Vorhaben weit mehr, als die Semantik von Edifact beziehungsweise des vornehmlich in den USA genutzten X.12 in XML-Syntax neu zu formulieren. Das haben schon Initiativen wie Xedi oder XML/EDI getan. Außerdem überwindet ebXML die bei den bisherigen EDI-Standards übliche Punkt-zu-Punkt-Kommunikation und nutzt anstatt proprietärer und kostspieliger Value Added Networks (VANs) Internet-Protokolle zur Datenübertragung. Gerade Letzteres soll kleineren Unternehmen und solchen aus der Dritten Welt den Zugang zu elektronischen Märkten erleichtern.
Weitreichende Spezifikationen
Die im Rahmen der ebXML-Arbeitsgruppen entwickelten Spezifikationen decken vom Auffinden möglicher Geschäftspartner und ihrer Profile über die Definition von Workflows bis hin zur Übertragung von Aufträgen oder Rechnungen alle Schritte von elektronischen Geschäftsbeziehungen ab.
Als Kernstücke von ebXML gelten allgemein Repositories, in denen alle Informationen hinterlegt werden, die Business-Partner benötigen, um Geschäfte elektronisch abzuwickeln. Neben firmenspezifischen Informationen wie beispielsweise Geschäftsprozessen, die als Unified-Modeling-Language-(UML-) Diagramme vorliegen sollten, finden sich dort auch vordefinierte Nachrichten, Muster für Trading-Partner-Agreements und die Core Components. Letztere sollen eine möglichst abstrakte, branchen- sowie länderübergreifende Definition von Business-Entitäten leisten und damit verhindern, dass diese für alle möglichen Kontexte neu definiert werden. Beispielsweise werden Kunden in diversen Branchen unterschiedlich bezeichnet: Bei Fluggesellschaften heißen sie Passagiere, für Hotels Gäste oder im Handel Käufer. Trotz dieser Abweichungen weisen die derart bezeichneten Geschäftsobjekte zahlreiche Übereinstimmungen auf, etwa Name, Vorname, Adresse
oder Kreditkartennummer. Die Kernkomponenten fassen solche Merkmalsgruppen unter einer eindeutigen Kennung zusammen. Ein umfangreiches, im Repository hinterlegtes Wörterbuch ordnet diese abstrakten Einheiten dann über ihre ID automatisch bestimmten Branchenbegriffen oder länderspezifischen Bezeichnungen zu. Neben der Nutzung dieser allgemeinen, branchen- und länderübergreifenden Entitäten besteht natürlich auch die Möglichkeit, industriespezifische Komponenten zu definieren und ebenfalls in ebXML-Repositories zu hinterlegen.
Betrachtet man die Aufgaben, die im Rahmen von ebXML für Repositories vorgesehen sind, dann fallen schnell Überschneidungen mit dem Service "Universal Description, Discovery and Integration" (UDDI) auf. Dieser fungiert als Verzeichnisdienst für Web-Services und enthält Informationen darüber, welche Firmen welche Dienste anbieten. Zusätzlich verweisen UDDI-Einträge auf detaillierte Servicebeschreibungen, die der Anbieter auf seiner eigenen Website mittels der Web Services Description Language (WSDL) erstellt. Daraus geht beispielsweise hervor, über welche Protokolle die entsprechenden Dienste erreichbar sind oder welche Parameter bei ihrem Aufruf übergeben werden müssen.
Arbeitsteilung: ebXML und UDDI
Bei ebXML übernehmen Repositories ebenfalls die Registrierung von Unternehmen. Sie bieten zudem die Möglichkeit, nach Anbietern bestimmter Dienste zu suchen. Nachdem das von Ariba, IBM und Microsoft ins Leben gerufene UDDI bereits erheblichen Rückhalt in der Industrie gewonnen hat, wird es für ebXML schwer, von Firmen eine erneute Registrierung derartiger
Basisinformationen zu verlangen. Deshalb scheinen die Initiatoren von ebXML eine Arbeitsteilung mit UDDI anzustreben, bei der sich Letzteres auf die Funktion Gelber Seiten reduziert und die weitergehenden Services - beispielsweise die Core Components oder die Hinterlegung von Geschäftsprozessen im UML-Format - ebXML vorbehalten bleiben. Eine derartige Koexistenz erscheint auch realistisch, weil sich wichtige Unterstützer von ebXML wie Sun Microsystems vor einiger Zeit auch der UDDI-Initiative angeschlossen haben. Zudem publizierte die entsprechende Arbeitsgruppe von ebXML bereits eine Fallstudie, wie die beiden Dienste konkret kooperieren könnten.
Trotz dieser Konvergenz bleiben aber grundsätzliche Unterschiede zwischen den beiden Registrierungen. UDDI folgt einem Peer-to-Peer-Konzept vom Typ "Napster", bei dem ein zentrales Verzeichnis zum Auffinden dezentral hinterlegter Servicebeschreibungen dient. Hingegen nimmt sich ebXML den stärker zentralisierten Domain Name Service (DNS) zum Vorbild. Diese Übereinstimmung gilt auch für Pläne, wie dieser Service betrieben werden soll. Bei ebXML herrscht eher die Meinung vor, dass Repositories für Business-Informationen Teil einer öffentlichen Infrastruktur sein sollten, während bei UDDI nicht klar ist, ob es sich dabei um eine Spezifikation handelt, deren praktische Umsetzung den Gründungsunternehmen vorbehalten bleibt.
Bei Messaging Konflikte mit Soap
Die Kollision, die sich zwischen den proklamierten Web-Services und ebXML bei Repositories abzeichnet, fand bei den Transportmechanismen für Geschäftsdaten bereits statt. Sie endete damit, dass die ebXML-Initiative einlenkte und nun das Simple Object Access Protocol (Soap) für den Versand von Geschäftsdaten unterstützt. Als die Arbeitsgruppe "Transport, Routing and Packaging" Soap anfangs für dieses Zweck in Erwägung zog, war die von Microsoft und IBM favorisierte Technik noch auf reine XML-Nutzlasten beschränkt. Dies erschien den beteiligten Ingenieuren als ein zu großes Manko, weil über einen solchen Transportmechanismus auch binäre Daten wie CAD-Zeichnungen oder Röntgenbilder verschickt werden sollten. Deshalb entstand im Rahmen von ebXML ein eigenes Protokoll, das Nutzlasten in einem Multipart-Mime-Umschlag versendet. Seine praktische Umsetzung fand dieser Mechanismus bereits in den "Java APIs for XML Messaging" (JAXM), die Sun als
zukünftigen Bestandteil seiner Plattform ankündigte. Die schnell wachsende Popularität von Soap und die Definition von "Soap with Attachments", das auch binäre Daten transportieren kann, zwang schließlich ebXML Anfang März zur Integration dieses Protokolls. Problematisch dabei waren jedoch die Urheberrechte für Soap, weil die UNO mit ebXML ein offenes und frei zugängliches Framework für die Abwicklung elektronischer Geschäfte vorlegen wollte.
IBM und Microsoft gewährten der Initiative deshalb eine entsprechende Lizenz. Den von ebXML angestrebten sicheren und verlässlichen Transport der zumeist sensiblen Daten kann Soap aber nicht gewährleisten: Beispielsweise kann beim Auftreten von Übermittlungsproblemen nicht sichergestellt werden, dass etwa ein Auftrag nur genau einmal verschickt wird. Die Mitglieder der zuständigen ebXML-Arbeitsgruppe ersannen daher ein Verfahren, Soap um Features des von ihnen entwickelten Messaging-Mechanismus zu erweitern. Dies geschieht, indem die gesamte Soap-Nachricht in den Kopf einer ebXML-Message gepackt wird. Unklar ist noch, ob ebXML mittels Soap nur Transaktionen tätigen will oder ob wie bei UDDI damit auch Abfragen und Registrierungen im Repository möglich sein sollen.
Das Aufeinandertreffen der zwei rivalisierenden Kerntechnologien Registrierung/Repository und Transport demonstrieren beispielhaft die unterschiedlichen Konzepte der beiden E-Business-Architekturen. Das ehrgeizige Bemühen von ebXML, ein vollständiges und konsistentes Framework für weltweiten elektronischen Handel zu entwerfen, verfolgt primär einen Top-down-Ansatz: Erst sollen möglichst umfassende und weit reichende Spezifikationen verabschiedet werden, anschließend ist es Aufgabe von Herstellern, sie zu realisieren. Umgekehrt setzen die von vielen Softwarehäusern ausgerufenen Web-Services auf Techniken, die nicht als Teil eines übergreifenden und komplizierten Frameworks entstanden und deshalb relativ schnell Verbreitung fanden. Dies gilt vor allem für Soap. Der Fall UDDI hingegen zeigt einmal mehr, dass Hersteller unter Zugzwang geraten können, wenn sie offene, aber langwierige Prozesse wie ebXML unterstützen. Das ist besonders dann der Fall, wenn
Konkurrenten wie Microsoft versuchen, in der Zwischenzeit ihr eigenes Konkurrenzprojekt aus dem Boden zu stampfen. Vermutlich die Angst, eine wichtige Entwicklung zu verpassen, veranlasste etwa Sun als einen der stärksten ebXML-Befürworter, sich UDDI anzuschließen.
IBM hält sich alle Optionen offen
Einen Mittelweg zwischen Eigenentwicklung und Warten auf den umfassenden Standard ging das Oasis-Mitglied IBM, das einen Vorschlag zur Definition und Umsetzung elektronischer Kontrakte in das Konsortium einbrachte. Diese Trading Partner Agreement Markup Language (tpaML) dient der Arbeitsgruppe "Trading Partners" als Grundlage für ihre Tätigkeit und sollte deren Arbeit beschleunigen. IBM gibt sich sonst in Sachen ebXML eher zurückhaltend und setzt bei der Produktentwicklung, beispielsweise dem Applikations-Server "Websphere" und der DB2-Datenbank, vornehmlich auf Soap, UDDI und WSDL.
Insgesamt sehen einige Beobachter trotz der Überlappungen zwischen den Web-Services und ebXML auch viele sich ergänzende Funktionen. So befürwortet Sun-Mitarbeiter und XML-Miterfinder Jon Bosak Soap und UDDI besonders für einfache Dienste, komplexere Transaktionen werden aber nach seiner Meinung stärker ebXML in Anspruch nehmen. David Webber und Anthony Dutton von XML Global Technologies sehen den Hauptunterschied zwischen den beiden Initiativen vornehmlich darin, dass sich UDDI aufgrund seiner vorwiegenden Middleware-Funktionalität in erster Linie für die Einbindung von Unternehmen in virtuelle Marktplätze eigne, während ebXML die B-to-B-Integration generell zu standardisieren versuche.
Keine Rivalität mit Rosetta Net
Die Überschneidungen von ebXML mit den Web-Services hat für die UN-gestützte Initiative besondere Bedeutung, weil sich um Letztere bereits zahlreiche große Hersteller scharen. Darüber hinaus stellt sich aber noch die Frage, in welchem Verhältnis ebXML aufgrund seines weit reichenden Anspruchs zu anderen Initiativen für den elektronischen Handel steht. Weniger Reibungsflächen gibt es zwischen ebXML und Rosetta Net, einem Konsortium von mehr als 400 IT-Firmen und Halbleiterproduzenten. Dieses will für seine Industrie einen E-Business-Standard etablieren und hat daher im Gegensatz zu ebXML eine stärke vertikale Ausrichtung. Es bereitet Rosetta Net daher keine Probleme, für Geschäftsdaten eigene Formate zu vereinbaren und für deren Austausch Basistechnologien von ebXML zu nutzen. Deshalb gab die Herstellervereinigung Ende April ihre Unterstützung für die Messaging-Spezifikation von ebXML bekannt.
Keineswegs als Ergänzung, sondern als direkte Konkurrenz zu ebXML gilt Microsofts Biztalk. Die Gates-Company will damit ebenfalls eine möglichst weithin akzeptierte Plattform für elektronische Geschäftsabläufe etablieren. Aufgrund seiner Marktmacht konnte der Desktop-Monopolist eine Reihe von Herstellern auch für dieses Vorhaben gewinnen. Die Entwicklung des Repositorys und der dazugehörigen Spezifikationen gingen Hand in Hand mit der Programmierung dazu passender Software, allen voran dem "Biztalk Server". Gegenüber ebXML kann Microsoft mit einem erheblichen Entwicklungsvorsprung aufwarten. Es wird sich zeigen, ob ebXML diesen durch die Unterstützung zahlreichen Firmen und Organisationen wettzumachen vermag.
Schritte zu ebXML
Mittels ebXML sollen Unternehmen weltweit elektronischen Handel betreiben können. Drehscheibe ist dabei eine Registrierung für Geschäftsprozesse und Firmenprofile.
Ins Leben gerufen wurde die Initiative namens Electronic Business XML (ebXML) von der UNO-Teilorganistion UN/ CEFACT und dem Herstellerkonsortium Organization for the Advancement of Structured Information Standards (Oasis).
Ziel ist es, ein technisches Rahmenwerk zu entwickeln, das die weltweit konsistente Nutzung von XML für den Austausch von Geschäftsdaten erlauben soll. Die beiden beteiligten Organisationen betrachten es als zentrale Aufgabe des Projekts, kleineren Unternehmen und solchen aus der Dritten Welt den Zugang zu elektronischem Handel zu erleichtern.
Die Version 1.0 von ebXML, die Anfang Mai vorgestellt wurde, umfasst sechs Hauptaspekte, denen sich jeweils eine eigene Arbeitsgruppe widmet. Dazu zählen:
Die technische Architektur,
Repository und Registrierung,
Transport, Routing und Packaging,
Geschäftsprozesse,
Kernkomponenten sowie ein
globales Wörterbuch der ebXML-Definitionen.