Treibende Kraft hinter der Initiative sind wie seinerzeit bei EDI erneut die Nordamerikaner. An vorderster Front stehen Global Player wie General Motors und Boeing, aber auch Branchen- und Industrieverbände wie AIAG (Automotive), OAG oder das papi-Net Konsortium der Papierindustrie. Nimmt man die gelisteten Projekte genauer unter die Lupe, so zeigt sich, dass insbesondere das Internet-basierende Messaging-Protokoll ebMS zum Einsatz kommt.
Auch Asien hat ein besonderes Verhältnis zu EDI und damit zu ebXML. Die aus den USA und Europa kommenden EDI-Lösungen und -Standards waren aufgrund des genutzten Ascii-Zeichensatzes in Asien allerdings nur bedingt einsetzbar. Diesen Zustand beendet ebXML, indem es wegen seiner XML-Fundamente Unicode nutzt. Damit lassen sich auch koreanische, chinesische und japanische Schriftzeichen codieren.
Zuversicht in puncto ebXML herrscht auch auf dem alten Kontinent. Europa hat sich stark an der technischen Entwicklung beteiligt, sogar die EU setzt sich vehement für den E-Business-Standard ein. Dass von konkreten Anwendungen noch nicht viel zu sehen ist, liegt primär daran, dass Europa später als die USA in das EDI-Geschäft eingestiegen ist. Entsprechend scheint der Leidensdruck noch nicht groß genug zu sein, um die alten Installationen auszumustern. Interessante Projekte sind hier der "European ebXML Interoperability Pilot" der eBES (E-Business Board for European Standardization Workshop, http://www.cenorm.be/isss/Workshop/eBES/Default.htm) sowie der CEN/ISSS (Cenorm/Information Society Standardization System, http://www.cenorm.be).
eBES will bekannte "Real-Life"-Prozesse mit EDI-Bezug auf pragmatische Weise implementieren. Von diesem Proof of Concept erhoffen sich die Initiatoren, dass damit die Interoperabilität der am Markt angebotenen beziehungsweise noch in Entwicklung befindlichen Prototypen unter Beweis gestellt werden können. Mit hohem Marketing-Aufwand will man Anwender für ebXML gewinnen und so eine hinreichende Vertrauensbasis für den neuen Standard schaffen.
Ein Teilprojekt dieses Workshops ist das eBES Vendor Forum, eine Initiative von Herstellern von ebXML-Lösungen. Dazu zählen etwa Dan Net, Drake Certivo, eXcelon, Ferrologic, GE GXS, Seeburger, Seagha, SAG, Sun, TIE und XML Global. Verständlicherweise liegt ihnen daran, dass die einzelnen Lösungen auch untereinander kompatibel sind. Zunächst wird in einem Test geprüft, ob sich ebMS als Grundlage für weitere Entwicklungen überhaupt eignet. Schließlich ist ebXML ohne kompatible Messaging-Systeme nicht einsetzbar und wäre zum Scheitern verurteilt.
Ein weiterer Aspekt des Tests widmet sich dem sicheren Transport von Nachrichten. Hier geht es um Fragen zu Signatur und Verschlüsselung, zu Übertragungsquittungen und Fehlerbehandlung. Ist der Testlauf erfolgreich bestanden, soll ein "Real Life Business Process Scenario" folgen. Sein Zweck besteht darin, Praxistauglichkeit zu demonstrieren und eventuell vorhandene Lücken aufzudecken. Mit ihrer Initiative wollen die Hersteller unter Beweis stellen, dass ebXML in Europa die Schwelle von der Theorie zur Praxis tatsächlich überschreiten kann.
Rivalität zwischen ebXML und UBL
Doch die Akzeptanz von ebXML wird vielleicht an einer ganz anderen Stelle beeinflusst. Völlig offen ist nämlich die Frage, auf welche Methodik für die Definition von Business-Dokumenten sich ebXML stützen kann. Genau genommen geht es hier um eine Konkurrenz zwischen den Core Components (CC) und der Universal Business Language (UBL). Beiden ist gemein, die durch XML entstandene Unübersichtlichkeit dank einer einheitlichen Sprache zu überwinden. So wird das CC-Konzept schwerpunktmäßig vom United Nations Centre for Trade Facilitation and Electronic Business (UN/Cefact) vorangetrieben, das seine Erfahrungen mit Edifact einbringt. Beispielsweise erinnern die Identifikatoren (UID) an die Edifact-Elemente, während die Aggregate sich eng an die Edifact-Segmente anlehnen.
UBL dagegen wird unter dem Dach der Organization for the Advancement of Structured Information Standards (Oasis) entwickelt. Im Unterschied zur eher akademisch ausgerichteten ebXML-Initiative, die benötigte Nachrichten aus einer CC-Bibliothek mit Hilfe der Unified Modelling Methodology (UMM) immer neu zusammenstellen lässt, versucht Oasis mit UBL, sich streng an der industriellen Praxis zu orientieren. Existierende Special-Purpose-XML-Standards wie zum Beispiel xCBL, Rosettanet, CIDX, PIDX, cXML, IXRetail oder Acord sollen aufgenommen und zu UBL konvergiert werden.
Konkurrenz auch zu Web-Services
Tatsächlich sind beide Vorgehensweisen kaum in Einklang zu bringen. Hinzu kommen politische Probleme. Ursprünglich waren die Aufgaben in der ebXML-Initiative klar verteilt: Während die Semantik, also die Dokumentendefinition, der UN/Cefact zugeschlagen wurde, sollte Oasis sich um Fragen der Infrastruktur (Messaging etc.) kümmern. Inzwischen wird Oasis der Vorwurf gemacht, mit UBL einen Ansatz zur Bildung von Dokumenten zu favorisieren. Dieser torpediere die Idee von ebXML, eine weltweit einheitliche und standardisierte Vorgehensweise zu definieren.
In der Tat ist die Entscheidung, welcher Methodik man den Vorzug geben soll, außerordentlich schwierig und sehr stark von der persönlich bevorzugten Arbeitsweise abhängig. Anwender beklagen völlig zu Recht, dass der Mangel an konkreten Business-Dokumenten nicht unbedingt für die reklamierte Vollständigkeit des ebXML-Standards spricht. Dies stellt auch die Einsatzfähigkeit von ebXML in Frage. Objektiv lässt sich der Vorwurf indes nicht belegen, zumal der Einsatz aller anderen ebXML-Elemente völlig unabhängig von Business-Dokumenten ist.
Doch mit der Auseinandersetzung um CC und UBL ist es nicht getan, ebXML reibt sich auch an den Web-Services. Bei genauerem Hinsehen jedoch entpuppt sich der Konflikt als Sturm im Wasserglas. Schließlich würde ebXML ohne die für Web-Services unabdingbaren Techniken und Protokolle gar nicht funktionieren. Im Einzelnen: ebMS, also das ebXML-Messaging, basiert auf dem Web-Services-Standard "Soap with Attachments" (SwA). Die ebXML-Initiative hat sich in ihren Statuten dazu verpflichtet, wo immer möglich vorhandene, offene Standards zu verwenden. Von daher war es nur konsequent, diesen Standard zu nutzen, zumal dieser mit seinen eingebauten Fähigkeiten wie der Möglichkeit, Daten zu transportieren, den Grundanforderungen entsprach.
Versucht man ebXML gegen Web-Services abzugrenzen, so stellt man fest, dass WebServices sehr stark aktionsorientiert sind, während ebXML den Fokus mehr auf die Daten legt. Web-Services sind zudem mehr technisch orientiert. Die Motivation für Web-Services entstammt der Notwendigkeit, ein konkretes technisches Problem zu lösen: eine Aktion beziehungsweise einen Funktionsaufruf via Internet sicher auszuführen. Ihre Keimzelle Soap wurde Schritt für Schritt um Schwesterstandards erweitert bis hin zu BPEL4WS, der es ermöglicht, Prozessketten zu dokumentieren.
ebXML dagegen agiert eine Ebene höher, kümmert sich um Daten und Abläufe. Die Motivation ist weniger technikgetrieben, sondern geht von der inhaltlichen Seite aus. Aktionen, die ausgeführt werden müssen, um Daten zu bewegen, sind hier nicht der Zweck, sondern nur Mittel. Während bei Web-Services synchrone Funktionsaufrufe in Echtzeit dominieren, beschäftigt sich ebXML mit dem nachrichtenbasierenden Datenaustausch. ebXML implementiert die Funktion der Übertragung von Business Dokumenten zwischen Unternehmen und nutzt dabei auf der technischen Ebene Web-Services. ebXML zielt auf die geschäftliche Sichtweise ab. Hier lautet das Ziel, komplexe Geschäftsprozesse zu standardisieren, angefangen vom Transport über Struktur und Inhalt der Geschäftsdokumente bis hin zu Prozess- und Dokumentenabläufen. Web-Services dagegen erlauben, Funktionsaufrufe via Internet und durch Firewalls hindurch unternehmensübergreifend zu realisieren. Im Document Style lassen sich auf der Basis von Web-Services auch Nachrichten übermitteln. Dass dies funktioniert, beweist wiederum ebXML, denn das ebXML-Messaging beruht selbst darauf, indem es den vorhandenen Web-Services-Standard nutzt und dabei erweitert.
Natürlich kann man Überschneidungen und Konflikte konstruieren. Anstelle Geschäftsprozesse mittels des ebXML-eigenen Business Process Specification Schema (BPSS) darzustellen, wäre es heute möglich, dies mit BPEL4WS zu tun. Wäre BPEL4WS bereits vor drei Jahren entstanden, so hätte die ebXML-Initiative gemäß ihrer Selbstverpflichtung, vorhandene Standards zu nutzen, die Definition von BPSS vielleicht direkt auf BPEL4WS aufgesetzt. Man könnte es noch weiter ausführen - es gibt keinen Kampf zwischen ebXML und Web-Services. Eher macht ebXML sich Web-Services zunutze, wo es passt.
Web-Services stellen Funktionen bereit, die über das, was zur Realisierung von ebXML benötigt wird, hinausgehen. Ein Entweder-Oder zu beschwören ist abwegig. Vielmehr werden beide Standards künftig koexistieren und sich ergänzen. Der Best-of-Bread-Ansatz gilt nicht nur für Unternehmensanwendungen, sondern auch für Integrationsverfahren. (ws)
*Matthias Feßenbecker ist Vice President Development der Seeburger AG in Bretten.
Angeklickt
Mit ebXML entwickelten das Hersteller-Consortium Oasis und die UN-Organisation UN/Cefact ein umfassendes Rahmenwerk für die Abwicklung elektronischer Geschäfte. Im Gegensatz zu zahlreichen XML-Initiativen gilt es als horizontaler Standard, der eine Reihe von Infrastrukturdiensten wie Nachrichtentransport oder zentrale Registrierungen definiert. Unklar stellt sich das Verhältnis zu anderen Standards dar, die selbst noch im Entstehen begriffen sind: die Universal Business Language (UBL) und die Web-Services. Die gelegentlich beschworene Rivalität zwischen Web-Services und ebXML will der Autor nicht sehen.
ebXML im ÜberblickOrganisation: Oasis und UN/Cefact
Internet-Präsenz: http://www.ebxml.org
http://www.oasis-open.org
Ziele: Offene technische Spezifikationen für globalen Austausch elektronischer Geschäftsdaten unter Berücksichtigung von Unternehmen an jedem Ort der Welt und in Unternehmen jeder Größe.
Elemente von ebXML
Business Process Specification Schema (BPSS): ebXML definiert und modelliert B-to-B-Geschäftsprozesse. Diese werden über XML-Nachrichten (Format: BPSS) beschrieben und können damit maschinell verarbeitet werden.
Collaboration Protocol Profile (CPP): Jedes Unternehmen beschreibt seine technischen Fähigkeiten, etwa seine http-Adresse(n) oder seine Schlüsselzertifikate, sowie die unterstützten Geschäftsprozesse in Form einer XML-Nachricht (Format: CPP). Derartige Profiles lassen sich per Software automatisch miteinander abgleichen.
Collaboration Protocol Agreement (CPA): Zwei Unternehmen, die elektronisch Daten austauschen, vergleichen (automatisch oder manuell) ihre CPPs. Das Ergebnis, beispielsweise das von beiden Parteien unterstützte Übertragungsprotokoll, wird wiederum in Form einer XML-Nachricht (Format: CPA) beschrieben und kann damit maschinell verarbeitet werden. Mit Hilfe der Informationen aus dem CPA kann somit die ebXML-Software automatisch konfiguriert werden.
Core Components (CC): Im Gegensatz zu anderen XML-Derivaten wie xCBL oder cXML definiert ebXML selbst keine Business-Dokumente wie Bestellung, Katalog oder Rechnung. Dafür gibt es die Core Components. Wie bei einem Baukasten lassen sich aus Core Components beliebige Nachrichten zusammensetzen. Jeder Baustein besitzt eine eindeutige ID, (vergleichbar den Edifact-Elementen) und einen definierten Namen. Dank dieser Eindeutigkeit lassen sich Zuordnungen automatisch erstellen.
Registries and Repositories: Geschäftspartner veröffentlichen ihre BPSS- und CPP-Daten. Während das Repository für die physikalische Speicherung der Nachrichten zuständig ist, stellt die Registry einen Index zur Verfügung. Er dient der komfortablen und schnellen Suche nach den Daten des gewünschten Geschäftspartners. ebXML hat sowohl den Aufbau als auch den Zugriff definiert und gewährleistet damit maschinelles Suchen, Herunterladen und Auswerten.
Messaging Service, [eb]MS: ebXML definiert eine Methode für den sicheren Nachrichtentransport via Internet. Transportiert werden können beliebige Nachrichten, sowohl XML- als auch klassische EDI- Nachrichten sowie Binärdaten (zum Beispiel Bilder). Technisch basiert ebMS auf dem Web-Services-Standard Soap with Attachments.
Abb: Abwicklung elektronischer Geschäfte
ebXML verfolgt den weitreichenden Anspruch, eine komplette Infrastruktur für die B-to-B-Integration zu bieten. In der vollen Ausbaustufe sollen sogar Ad-hoc-Geschäfte möglich sein. Quelle: ebXML.org