Leseprobe
Inhaltsverzeichnis
Abkürzungsverzeichnis
1 Einführung
1.1 Entstehungshintergrund
1.2 Ziele
1.3 Anwendungsbeispiel
1.4 ebXML Architektur
2 Geschäftsprozessmodellierung
2.1 Von Kernkomponenten zum Geschäftsprozess
2.2 Business Process Specification und Information Modeling
3 Collaboration Protocol Profile und Collaboration Protocol Agreement
3.1 Collaboration Protocol Profile
3.2 Collaboration Protocol Agreement
3.3 Anwendungsbeispiel
4 ebXML Registry
4.1 Architektur
4.1.1 Registry Services
4.1.2 Registry Clients
5 Messaging Service
5.1 Einbindung von SOAP
5.2 Module des Messaging Service
5.3 Aufbau einer ebXML Message
6 Resümee und Ausblick
Literaturverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einführung
1.1 Entstehungshintergrund
Bereits seit Mitte der 1960er hatten Unternehmen die Vision eines Austauschs von Geschäftsinformationen auf elektronischem Weg. Immer leistungsstärker und erschwinglicher werdende EDV-Systeme sowie die Aussicht auf effizienten, automatisierbaren und kostengünstigen Datenaustausch zwischen verschiedenen Unternehmen begünstigten diese Entwicklung. Doch zwischen Wunschvorstellung und technischer Umsetzung klaffte eine nicht zu unterschätzende Lücke. Es stellte sich die Frage, wie der Nachrichtenaustausch zwischen zwei verschiedenen Unternehmen mit unterschiedlicher Infrastruktur und Softwaresystemen realisiert werden konnte. An ein homogenes Netz wie das Internet dachte damals schließlich noch niemand und die heute bekannten gängigen Kommunikationsprotokolle (wie z.B. HTTP, FTP, SMTP, usw.) waren auch noch nicht verfügbar. Es bedurfte also eines Standards, auf dessen Basis der elektronische Datenaustausch stattfinden konnte.
Ein erster Ansatz wurde 1982 mit ANSI ASC X.12 veröffentlicht, der Datenstrukturen zum Nachrichtenaustausch zwischen verschiedenen Computersystemen beschreibt. Dieser Standard fand jedoch vornehmlich nur in den USA Verbreitung. Der erste übergreifende europäische Ansatz wurde 1988 mit EDIFACT vorgestellt. Diese Lösung unterschied sich vor allem hinsichtlich des Nachrichtenaufbaus von ANSI ASC X12 und entwickelte sich in der Folgezeit zum bedeutendsten Projekt in Europa.
Doch auch EDIFACT vermochte es letztendlich nicht sich flächendeckend zu verbreiten. Ein Grund waren sicherlich die hohen Investitionskosten in die Infrastruktur und die benötigten Softwarekomponenten. Somit beschränkte sich der Einsatz von EDIFACT in der Praxis im Wesentlichen auf große Firmen, die in der Lage waren die hohen Kosten zu tragen; bei kleineren und mittleren Unternehmen fand es jedoch kaum Verbreitung. Zudem ist dieser Standard nun auch schon fast 20 Jahre alt. Zwar wurden in der Zwischenzeit aufgekommene neue Technologien genutzt, wie z.B. das Internet oder auch schon die Markup Language XML. Diese nachträgliche Einbeziehung stellt jedoch keine optimale Lösung dar, da EDIFACT ursprünglich nicht auf diese Basis aufbauend konzipiert wurde.
Außerdem bieten die erwähnten Ansätze keine ausreichende Möglichkeit kurzfristige Geschäftsbeziehungen aufnehmen und direkt miteinander kommunizieren zu können. Vielmehr ist im Prinzip eine vorherige Absprache gefolgt von einer zeitintensiven Implementierung bzw. Anpassung der benötigten Systeme notwendig. Eine weitere Schwachstelle der bisher bekannten Systeme zum elektronischen Datenaustausch ist ihre nur bedingte Eignung für brachenübergreifende Kommunikation. Es existieren zwar einige gute Ansätze, doch sind diese zumeist nur auf den Einsatz für eine bestimmte Branche oder sogar nur für den Austausch zwischen wenigen Unternehmen ausgelegt und somit nicht massentauglich.
Um diese Probleme zu überwinden, riefen die Organisation for the Advancement of Structured Information Standards (OASIS) und UN/CEFACT 1999 ebXML ins Leben. Hierbei brachte OASIS technisches Know-how und UN/CEFACT, als Entwicklerin von ANSI X.12 und EDIFACT, Erfahrung mit Geschäftsprozessen ein. Dem Projekt gehören im Wesentlichen alle bedeutenden Unternehmen - wie z.B. die ASC X12-Gruppe, IBM oder Sun – sowie verschiedene Standardisierungsorganisationen an. Lediglich Microsoft ist als einziges bedeutenderes Unternehmen nicht involviert. Insgesamt wurden in der Entwicklungsphase von ebXML 14 Länder und ca. 1000 Unternehmen repräsentiert.
Nach 18monatiger Entwicklungszeit wurde der erste Projektabschnitt mit der Veröffentlichung aller unabhängig voneinander entwickelten Spezifikationen – deren Gesamtheit ebXML bildet – im Jahr 2001 abgeschlossen. Danach folgte eine zweite Entwicklungsphase in der die meisten Spezifaktionen noch ergänzt bzw. angepasst wurden. Mit dem Ende dieser zweiten Phase wurde die Entwicklung von ebXML 2003 als abgeschlossen erklärt. Trotzdem arbeiten die Entwickler immer noch an neuen Versionen der einzelnen Spezifikationen. Diese Arbeiten beschränken sich aber im Wesentlichen auf Optimierung und Behebung noch auftretender Fehler sowie die Anpassung an veränderte Umweltbedingungen, wie z.B. Modifizierungen der benutzten Techniken (z.B. XML, Übertragungsprotokolle, usw.). Das in den ersten beiden Entwicklungsphasen geschaffene technische Gesamtkonzept bleibt hierbei jedoch unangetastet.
1.2 Ziele
Das Bestreben der ebXML-Initiative ist, „einen einheitlichen, weltweiten, konsistenten Austausch elektronischer Geschäftsdaten auf der Grundlage von XML [zu] ermöglichen.“ [1] Ein besonderes Augenmerk liegt hierbei auf der Minimierung von Eintrittsbarrieren für kleine und mittlere Unternehmen (KMU), ebenso wie für Entwicklungsländer. Außerdem soll der Datenaustausch zwischen unterschiedlichen Branchen angehöriger Unternehmen erleichtert werden. Wie schon erwähnt sind dies wesentliche Schwachstellen des bisherigen Quasi-Standards EDIFACT.
ebXML soll keinen Gegenpol zum schon seit fast 30 Jahren praktizierten Electronic Data Interchange (EDI) darstellen, sondern eher darauf aufsetzen und ein einheitlicheres System – ohne ein schwer überschaubares Geflecht von proprietären Teillösungen – bilden. Hierbei sollen die durch XML neu entstandenen Möglichkeiten genutzt werde, womit es für Unternehmen wesentlich einfacher und kostengünstiger werden soll, Systeme zum elektronischen Datenaustausch zu implementieren und zu betreiben. Dies ist ein wesentlicher Punkt um das oben genannte Ziel der Minimierung von Eintrittsbarrieren für KMU und Entwicklungsländer zu erreichen.
Ziel des Projektes ist es jedoch nicht nur, einen reinen Standard zum Austausch von Geschäftsnachrichten zu schaffen, sondern vielmehr ein komplettes Rahmenwerk an Spezifikationen bereitzustellen. Sicherlich ist der automatische Austausch von Geschäftsdaten das letztendliche Ziel, doch ist hierfür auch eine nicht zu unterschätzende Vorarbeit nötig. Hierzu gehören z.B. das Auffinden geeigneter Geschäftspartner, die Klärung von Detailfragen hinsichtlich der Datenübertragung (z.B. benutzte Ports) oder auch die Modellierung von Geschäftsprozessen. ebXML will alle hierfür notwendigen Mechanismen zur Verfügung stellen.
Das ebXML-Projekt ist also modular angelegt, so soll es ermöglicht werden, einzelne Features getrennt voneinander zu entwickeln und weiterzuentwickeln sowie unabhängig voneinander implementieren und einsetzen zu können. Letzteres hat wiederum eine potentiell breite Zielgruppe und Anwendungsszenarien zur Folge.
1.3 Anwendungsbeispiel
Abbildung 1 zeigt ein exemplarisches Szenario wie ebXML in der Praxis genutzt werden kann.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Überblick Interaktion zwischen zwei Unternehmen, aus: [3]
Unternehmen A fordert in dem Beispiel im ersten Schritt Daten und Information über Geschäftsszenarien bzw. Kernkomponenten an, die in einem Datenbanksystem – der sogenannten ebXML Registry – gespeichert sind. Auf Basis dieser Daten implementiert es – selbst oder mit Hilfe eines Drittanbieters – ein lokales ebXML kompatibles System. In Schritt drei registriert es sich, indem es sein Unternehmensprofil in der Registry ablegt. Dieses Profil kann allgemeine Informationen zum Unternehmen wie z.B. Branche, Unternehmenssitz, unterstützte Transportprotokolle, Netzwerkadressen, Kontaktinformationen, aber auch Daten zu seinen unterstützten Geschäftsszenarien beinhalten. Diese Informationen können nun von anderen Unternehmen abgefragt werden. In der Beispielgrafik findet Unternehmen B bei einer Anfrage an die ebXML Registry Unternehmen A, etwa weil es relevante Geschäftsszenarien unterstützt und über kompatible Schnittstellen verfügt. Nun kann eine Geschäftsvereinbarung zum Austausch von Daten via ebXML abgesprochen werden. Nach einer eventuellen Verhandlungsphase wo z.B. Fragen bezüglicher technischer Details wie Transportkanäle und Verschlüsselungsmethoden geklärt werden, erfolgt der Vertragsabschluss. Alle getroffenen Vereinbarungen werden in Form des Collaboration Protocoll Agreements (CPA) in der Registry hinterlegt. Nachdem jedes Unternehmen, sich an der CPA orientierende Applikationen und Schnittstellen geschaffen hat, kann eine Transaktionsabwicklung über ebXML realisiert werden.
1.4 ebXML Architektur
ebXML besteht aus mehreren Komponenten, die alle in sogenannten Spezifikationen beschrieben und definiert werden:
- Technical Architecture Specification Version 1.04
- Business Process Specification Schema Version 1.01
- Registry Information Model Version 2.0
- Registry Services Specification Version 2.0
- Requirements Specification Version 1.06
- Collaboration-Protocol Profile and Agreement Specification Version 2.0
- Message Service Specification Version 2.0
Bevor im Detail auf die einzelnen Komponenten und wesentlichen Pfeiler des ebXML-Projektes eingegangen wird, soll zum besseren Verständnis anhand einer Abbildung ein Über-blick über die Architektur und deren wichtigster Komponenten gegeben werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Architektur von ebXML
Wie in Abbildung 2 zu erkennen, lässt sich die Architektur von ebXML in zwei Teile gliedern. Dies ist zum einen die Entwicklungsphase (Design Time Phase) und zum anderen die Laufzeitphase (Run Time Phase). Letztere spiegelt den eigentlichen Nachrichtenaustausch zwischen zwei Geschäftspartnern wider. Bis jedoch dieser automatische Austausch erfolgen kann, ist eine Vorarbeit nötig. Unternehmen müssen sich finden und anhand ihrer jeweiligen Unternehmensstrukturen und Geschäftsprozessen abwägen können, ob es für sie möglich als auch sinnvoll ist, Geschäftsdaten auszutauschen. Weiterhin müssen sie vertragliche Rahmenbedingungen für den Nachrichtenaustausch festlegen. ebXML bringt für alle erwähnten Punkte die benötigten Werkzeuge mit, die der Entwicklungsphase zugeordnet werden. Diese Phase steht also im zeitlichen Verlauf vor der Laufzeitphase die sozusagen auf die in der Entwicklungsphase geleistete Vorarbeit aufsetzt. Die bereitgestellten Werkzeuge der Entwicklungsphase müssen jedoch nicht alle genutzt werden bzw. kann auch ganz auf sie verzichtet werden. Unternehmen die sich schon kennen, müssen sich z.B. nicht noch extra suchen und finden. Ebenso wenig müssen Unternehmen, die schon längere Zeit miteinander EDI betreiben nicht zwangsläufig noch einmal vertragliche Aspekte aushandeln.
In Abbildung 2 ist die zentrale Rolle zu erkennen, die der ebXML Registry während der Entwicklungsphase zuteil wird. Sie dient als Speicherort für alle geschäftsprozess- (Geschäftsdokumente und Kernkomponenten) sowie unternehmensspezifischen (Collaboration Protocol Profile und Collaboration Protocol Agreement) Daten.
Die Entwicklungsphase wird bisweilen noch einmal in zwei weitere Abschnitte untergliedert. Dies ist zum einen die Implementierungsphase in der die ebXML Spezifikationen, Kernkomponenten und Geschäftsdokumente sowie Informationen über potentielle Handelspartner beschafft und analysiert werden sollten. Dies ist der Grundstein um überhaupt eine ebXML konforme Schnittstelle erstellen zu können. Natürlich kann diese Aufgabe auch von einem Drittanbieter übernommen werden falls ein Unternehmen nicht über das nötige Know-how oder genügend Kapazitäten verfügen sollte. In der folgenden Discovery und Retrieval Phase wird vertieft nach den Eigenschaften und Anforderungen anderer Unternehmen geforscht, die zum Aufbau eines Datenverkehrs zu beachten sind.
In den folgenden Kapiteln werden die zugrunde liegenden Spezifikationen und wesentlichen Prinzipien der bereits erwähnten Komponenten der Entwicklungs- und Laufzeitphase dargestellt. Bewusst wurde hier jeder Komponente ein eigenes Kapitel gewidmet um den modularen Aufbau von ebXML bestmöglich widerspiegeln zu können.
Begonnen wird mit der Geschäftsprozessmodellierung. Hier wird zunächst auf das Bilden von Geschäftsprozessen aus Kernkomponenten und später auf die Modellierungstechnik eingegangen. In Kapitel 3 wird anschließend gezeigt wie unternehmensbezogene Daten dargestellt und wozu diese genutzt werden können. Im folgenden Kapitel wird die Aufgabe und Organisation der ebXML Registry näher erläutert bevor dann die Spezifikation des Messaging Services erklärt wird. Im letzten Kapitel werden neben einer Zusammenfassung noch Vor- und Nachteile sowie Konkurrenten von ebXML genannt.
2 Geschäftsprozessmodellierung
2.1 Von Kernkomponenten zum Geschäftsprozess
Das ebXML-Projekt hat sich bei der Frage wie die Modellierung von Geschäftsprozessen organisiert werden soll auf ein System mit so genannten Kernkomponenten gestützt. Aus diesen Kernkomponenten können recht einfach umfassendere Geschäftsprozesse zusammengesetzt werden. So kann z.B. der Geschäftsprozess „Verkauf einer Ware“ aus den Kernkomponenten „Bezahlung“ und „Lieferung“ zusammengesetzt werden. Natürlich ist dies nur ein sehr einfaches Beispiel und in der Praxis bestehen Geschäftsprozesse zumeist aus einer weitaus größeren Anzahl an einzelnen Komponenten.
[...]