Von CW-Redakteur Wolfgang Sommergut

MÜNCHEN (COMPUTERWOCHE) - Die Zusammenarbeit des Herstellerkonsortiums Oasis und der UNO (UN/Cefact) soll zu einem globalen Standard für das E-Business führen. Dieses ehrgeizige Vorhaben kollidiert allerdings in vielen Belangen mit Technologien, die große Hersteller im Rahmen der proklamierten Web-Services unterstützen.

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.

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.

Repositories als Kernstücke

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 UML-Diagramme (Unified Modeling Language) 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.

Überschneidungen mit UDDI?

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.

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.

UDDI vs. ebXML: Der Unterschied liegt im Prinzip

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.

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.

[...]

ebXML Version 1.0

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.

Wir geben den Artikel an dieser Stelle aus Platzgründen nur auszugsweise wieder. Den vollständigen Text lesen Sie in der COMPUTERWOCHE Nr. 23 vom 8. Juni 2001.