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.