ebXML - Kurzanleitung

Unternehmen interagieren unweigerlich auf verschiedene Weise miteinander. Bis in die letzten Jahre kommunizierten viele große Unternehmen automatisch über Electronic Data Interchange (EDI), wodurch zwei Unternehmen über vorgegebene Signale kommunizieren können.

Das Problem mit EDI ist, dass es sehr teuer ist und ursprünglich für die Mainframe-Welt entwickelt wurde. Jetzt ersetzt ebXML EDI.

Definition

ebXML steht für ELectronic BUsiness E.xspannbar MArkup LSprache. Es ist ein globaler Standard für das elektronische Geschäft, der es jedem ermöglicht, über das Internet mit jedem Geschäftstransaktionen durchzuführen.

Eigenschaften

Die Funktionen von ebXML sind wie folgt:

ebXML ist ein End-to-End-B2B-XML-Framework.
ebXML ist eine Reihe von Spezifikationen, die ein modulares Framework ermöglichen.
ebXML stützt sich auf die im Internet vorhandenen Standards wie HTTP, TCP / IP, MIME, SMTP, FTP, UML und XML.
ebXML kann auf praktisch jeder Computerplattform implementiert und bereitgestellt werden.
ebXML bietet konkrete Spezifikationen, um dynamische B2B-Kollaborationen zu ermöglichen.

ebXML Vision

ebXML wurde entwickelt, um einen globalen elektronischen Marktplatz zu schaffen, auf dem Unternehmen jeder Größe und überall:

einander elektronisch finden.
Geschäfte abwickeln -
- Verwenden des Austauschs von XML-Nachrichten.
- gemäß Standard-Geschäftsprozesssequenzen.
- mit klarer Geschäftssemantik.
- Verwendung von handelsüblichen Geschäftsanwendungen.
- gemäß einvernehmlich vereinbarten Handelspartnerprotokollvereinbarungen.

Warum ebXML?

Bestehende B2B-Frameworks sind nicht ausreichend:
- EDI und RosettaNet sind zu schwer und zu steif.
- BizTalk ist proprietär, ein Anbieter und eine Plattform.

SOAP (Simple Object Access Protocol); Web Service Definition Language (WSDL); und Universal Description, Discovery und Integration (UDDI) allein sind nicht ausreichend:
- WSDL befasst sich nicht mit geschäftlicher Zusammenarbeit.
- SOAP in seiner Grundform bietet keine sichere und zuverlässige Nachrichtenübermittlung.
- UDDI bietet keine Repository-Funktion für Geschäftsobjekte.

Es besteht eine wachsende Anforderung, geschäftliche Kooperationen zu standardisieren, um Folgendes zu erreichen:
- Arbeitsprozesse
- Die an der geschäftlichen Zusammenarbeit beteiligten Parteien und ihre Rollen
- Austausch von XML-Dokumenten in der Geschäftszusammenarbeit
- Sicherheits-, Zuverlässigkeits- und Servicequalitätsanforderungen für die geschäftliche Zusammenarbeit
All diese Anforderungen werden von ebXML erfüllt.

ebXML-Gründungsorganisationen

ebXML ist eine gemeinsame Initiative von UN / CEFACT und OASIS.

UN/CEFACT:

Es steht für das Zentrum der Vereinten Nationen für Handelserleichterungen und elektronisches Geschäft.
Es behält die UN / EDIFACT-Standards für den elektronischen Datenaustausch (EDI) bei.

OASIS:

Es steht für Organisation zur Weiterentwicklung strukturierter Informationsstandards.
Es erstellt und verwaltet XML-Interoperabilitätsspezifikationen und bietet umfassende Unterstützung für die Branche.

Per Definition ist der iterative Lebenszyklus von B2B collaboration umfasst die folgenden Schritte:

Prozessdefinition
Partnererkennung
Partner-Anmeldung
Elektronisches Plug-In
Prozessausführung
Prozessmanagement
Prozessentwicklung

Die allgemeinen ebXML-Spezifikationen sollen fast den gesamten Prozess der B2B-Zusammenarbeit abdecken und die oben beschriebenen Anforderungen erfüllen.

Die vom ebXML-Team definierte ebXML-Architektur bietet:

Eine Möglichkeit, Geschäftsprozesse und die damit verbundenen Nachrichten und Inhalte zu definieren.
Eine Möglichkeit, Geschäftsprozesssequenzen mit zugehörigem Nachrichtenaustausch zu registrieren und zu ermitteln.
Eine Möglichkeit, Firmenprofile zu definieren.
Eine Möglichkeit, Handelspartnervereinbarungen zu definieren.
Eine einheitliche Nachrichtentransportschicht.

Folglich besteht die technische Architektur von ebXML aus fünf Modulen:

Geschäftsprozessspezifikationen
Partnerprofil und Vereinbarungen
Registrierung und Repository
Kernkomponenten
Messaging-Dienst

Diese Module werden in den nächsten fünf folgenden Kapiteln behandelt. Das Diagramm zeigt die vereinfachte Architektur von ebXML:

Ein Geschäftsprozess ist etwas, das ein Unternehmen tut, z. B. der Kauf von Computerteilen oder der Verkauf eines professionellen Service. Es geht um den Informationsaustausch zwischen zwei oder mehr Handelspartnern auf vorhersehbare Weise.

Die Spezifikationen für die Definition von Geschäftsprozessen ermöglichen es einer Organisation, ihre Geschäftsprozesse so auszudrücken, dass sie für andere Organisationen verständlich sind. Es ermöglicht die Integration von Geschäftsprozessen innerhalb eines Unternehmens oder zwischen mehreren Unternehmen.

Das ebXML Business Process Specification Schema (BPSS)Bietet die Definition eines XML-Dokuments, das beschreibt, wie eine Organisation ihre Geschäfte abwickelt. Ein ebXML-BPSS ist eine Erklärung der Partner, Rollen, Kooperationen, Choreografien und des Austauschs von Geschäftsdokumenten, aus denen ein Geschäftsprozess besteht.

Das folgende Diagramm gibt eine konzeptionelle Ansicht des Geschäftsprozesses.

Geschäftskooperationen

Eine Geschäftszusammenarbeit ist eine choreografierte Reihe von Geschäftstransaktionsaktivitäten, bei denen zwei Handelspartner Dokumente austauschen.

Die häufigste ist eine binäre Zusammenarbeit, bei der zwei Partner Dokumente austauschen. Eine Zusammenarbeit zwischen mehreren Parteien findet statt, wenn Informationen zwischen mehr als zwei Parteien ausgetauscht werden.

Mehrparteien-Kollaborationen sind tatsächlich choreografierte binäre Kollaborationen.

Auf der untersten Ebene kann eine geschäftliche Zusammenarbeit in Geschäftstransaktionen unterteilt werden.

Geschäftliche Transaktionen

Eine Geschäftstransaktion ist die atomare Arbeitsebene in einem Geschäftsprozess. Es ist entweder erfolgreich oder schlägt vollständig fehl.

Geschäftstransaktionen sind Transaktionen, bei denen Handelspartner tatsächlich Geschäftsdokumente übertragen.

Geschäftsdokumentabläufe:

Ein Geschäftsvorgang wird realisiert, wenn ein Geschäftsdokument zwischen anfordernden und antwortenden Rollen fließt. Abhängig von der gewünschten Transaktionssemantik gibt es immer ein anforderndes Geschäftsdokument und optional ein antwortendes Geschäftsdokument, z. B. Einwegbenachrichtigung oder Zweiwegkonversation.

Die tatsächliche Dokumentdefinition wird mithilfe der ebXML-Kernkomponentenspezifikationen oder durch eine Methode außerhalb von ebXML erreicht, die jedoch zu einer DTD oder einem Schema führt, auf die eine ebXML-Geschäftsprozessspezifikation verweisen kann.

Choreographie:

Choreografie wird in Zuständen und den Übergängen zwischen ihnen ausgedrückt. Eine Geschäftstätigkeit wird als abstrakter Zustand bezeichnet, wobei Geschäftskooperationen und Geschäftstransaktionsaktivitäten als konkrete Zustände bezeichnet werden. Die Choreografie wird im ebXML-Geschäftsprozessspezifikationsschema anhand von Aktivitätsdiagrammkonzepten wie Startstatus, Abschlussstatus usw. beschrieben.

Geschäftsdokumente

Geschäftsdokumente bestehen aus Geschäftsinformationsobjekten oder kleineren Informationsblöcken, die zuvor identifiziert wurden.

Diese Chunks oder Komponenten enthalten natürlich keine Informationen. Es handelt sich lediglich um Strukturen wie ein XML-Schema oder eine DTD, die Informationen und Präsentationen definieren. Das Endergebnis ist eine vorhersehbare Struktur, in die Informationen eingefügt werden, sodass der Empfänger des endgültigen Dokuments diese interpretieren kann, um die Informationen zu extrahieren.

Beispiel für eine Geschäftsprozessspezifikation

Ein Teilbeispiel der Geschäftsprozessspezifikation ist unten angegeben:

<BusinessTransaction name="Create Order">
    <RequestingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P2D"
        timeToAcknowledgeAcceptance="P3D">
    <DocumentEnvelope BusinessDocument="Purchase Order"/ >
    </RequestingBusinessActivity>
    <RespondingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P5D">
    <DocumentEnvelope isPositiveResponse="true"
        BusinessDocument="PO Acknowledgement"/>
    </DocumentEnvelope>
    </RespondingBusinessActivity>
</BusinessTransaction>

Fazit

Eine Geschäftsprozessspezifikation:

Beschreibt die Zusammenarbeit zwischen zwei Partnern
Definiert Rollen, Beziehungen und Verantwortlichkeiten
Definiert die Choreografie von Geschäftsdokumenten
Ausgedrückt im plattform- und herstellerneutralen Format
Kann mit UMM modelliert werden (UN / CEFACT Modeling Methodology)
Formal beschrieben durch Business Process Specification Schema (BPSS)
Referenziert von CPP und CPA.
Bezieht sich auf Geschäftsdokumentdefinitionen.

Profil des Kollaborationsprotokolls

Ein Collaboration Protocol Profile (CPP) enthält alle erforderlichen Informationen darüber, wie ein bestimmter Handelspartner elektronische Geschäfte tätigen möchte. Ein CPP definiert die folgenden Attribute eines Handelspartners:

Geschäftsfähigkeiten durch Geschäftsprozesse.
Die Rolle (Käufer oder Versicherer), die sie innerhalb einer Zusammenarbeit spielen.
Lieferkanäle und Transportprotokolle. (HTTP, SMTP usw.)
Verpackungsart von Geschäftsdokumenten.
Sicherheitsbeschränkungen (SSL, digitale Zertifikate).
Konfiguration pro Partei gemäß Geschäftsprozessspezifikationen.

Ein CPP wird in der ebXML-Registrierung mit einer GUID (Globally Unique Identifier) gespeichert, und Geschäftspartner können den CPP des anderen über die Registrierung finden.

Die Informationen innerhalb des CPP können durchsucht werden, sodass ein potenzieller Handelspartner bestimmen kann, ob das Unternehmen über die erforderlichen Geschäftsfunktionen verfügt.

Struktur eines CPP

CPP definiert Namespaces in seinem Stammelement und eine Version, um nachfolgende Änderungen zu unterscheiden. Die Struktur eines CPP besteht aus einem Stammelement des Collaboration Protocol-Profils mit folgenden Elementen:

PartyInfo: Das PartyInfo-Element enthält Informationen zur Organisation.
Packaging:Das Packaging-Element enthält Informationen darüber, wie Nachrichten tatsächlich erstellt werden. Nachrichten werden als SOAP-Nachrichten verarbeitet.
Signature: Optionaler Teil des Dokuments
Comment elements: kann enthalten sein.

<CollaborationProtocolProfile
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1">
<PartyInfo>
    ...
    <!--REQUIRED, Repeatable-->
...
</PartyInfo>
<Packaging id="ID">
    ...
    <!--REQUIRED-->
    ...
<Packaging>
<ds:Signature>
    ...
    <!--OPTIONAL-->
    ...
</ds:Signature>
<Comment>
    ...
    <!-- OPTIONAL -->
    ...
</Comment>
</CollaborationProtocolProfile>

Handelspartnervertrag

Ein Handelspartnervertrag (TPA) ist ein Vertrag, der sowohl die rechtlichen Bedingungen als auch die technischen Spezifikationen für beide Partner in der Handelsbeziehung definiert. Ein CPA wird von CPPs von Handelspartnern abgeleitet.

Die im elektronischen TPA festgelegten Regeln sind unabhängig von den Geschäftsprozessen beider Parteien. Eine technische Beschreibung der Allgemeinen Geschäftsbedingungen aus dem TPA wird in einem XML-Dokument ausgedrückt, in dem jedes IT-System für den Betrieb gemäß den Vertragsregeln konfiguriert wird.

Zu den TPA-Eigenschaften gehören Name, Partnernamen, Start- und Enddatum, Rollen und andere Parameter. In der Regel generiert eine Partei einen CPA und bietet ihn der anderen Partei zur Genehmigung an. Sobald beide Seiten eine Einigung erzielt haben, nehmen sie jeweils eine elektronische Kopie desselben CPA und konfigurieren damit ihre Systeme.

Die CPA kann auch als Referenz zur Registrierung hinzugefügt werden, dies ist jedoch keine Standardanforderung.

Struktur eines CPA

CPA definiert Namespaces in seinem Stammelement und eine Version, um nachfolgende Änderungen zu unterscheiden. Die Struktur eines CPP besteht aus einem Stammelement der Collaboration Protocol Agreement sowie den folgenden Elementen:

Start and End: Diese Elemente repräsentieren in koordinierter Weltzeit den Beginn und das Ende des Zeitraums, in dem diese CPA aktiv ist.
PartyInfo:Das PartyInfo-Element enthält Informationen zur Organisation. Hier sind PartyInfo-Elemente für beide an der Vereinbarung beteiligten Parteien enthalten.
Packaging:Das Packaging-Element enthält Informationen darüber, wie Nachrichten tatsächlich erstellt werden. Nachrichten werden als SOAP-Nachrichten verarbeitet.
Signature: Optionaler Teil des Dokuments.
Comment elements: kann enthalten sein.

<CollaborationProtocolAgreement
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink = "http://www.w3.org/1999/xlink"
cpaid="http://www.example.com/cpas/CPAS"
version="1.7">
<Status value = "proposed"/>
<Start>1998-04-07T18:50:00</Start>
<End>1999-04-07T18:50:00</End>
<ConversationConstraints invocationLimit = "150"
concurrentConversations = "10"/>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
    </PartyInfo>
<Packaging id="N20">
    ...
    <!--REQUIRED, repeatable-->
    ...
</Packaging>
<ds:Signature>
    <!--OPTIONAL-->
</ds:Signature>
<Comment xml:lang="en-gb">
    <!--OPTIONAL-->
</Comment>
</CollaborationProtocolAgreement>

Was ist Registrierung und Repository:

Eine ebXML-Registrierung dient als Index- und Anwendungsgateway für ein Repository nach außen und enthält die API, die regelt, wie Parteien mit dem Repository interagieren. Ein ebXML-Repository ist der Inhaber der Komponenten.

Die ebXML-Registrierung ist von zentraler Bedeutung für die ebXML-Architektur.
Die Registrierung kann auch als API für die Datenbank mit Elementen angesehen werden, die E-Business mit ebXML unterstützen.
Die ebXML-Registrierung dient als Datenbank für den Austausch relevanter Unternehmensinformationen für ebXML-Geschäftstransaktionen, z. B. Unternehmensfunktionen, Geschäftsprozesse, technische Entwürfe, Bestellformulare, Rechnungen usw.
Elemente im Repository werden durch Anforderungen an die Registrierung erstellt, aktualisiert oder gelöscht.
Repositories bieten Handelspartnern die gemeinsame Geschäftssemantik.
Die ebXML-Registrierung ist eine Schnittstelle für den Zugriff auf und die Ermittlung der gemeinsam genutzten Geschäftssemantik.
Die Registrierungsschnittstelle ist so konzipiert, dass sie unabhängig vom zugrunde liegenden Netzwerkprotokollstapel ist, z. B. HTTP oder SMTP über TCP / IP.

Die Registrierung bietet einen stabilen, dauerhaften Speicher für übermittelte Inhalte, einschließlich XML-Schema und -Dokumenten, Prozessbeschreibungen, Kernkomponenten, Kontextbeschreibungen, UML-Modellen, Informationen zu Parteien und sogar Softwarekomponenten. Dies kann wie unten gezeigt als Software-Stack von Diensten dargestellt werden:

Ziele der ebXML-Registrierung

Ziel der ebXML-Registrierung ist es, den Informationsaustausch zwischen interessierten Parteien zum Zwecke der Integration von Geschäftsprozessen zwischen ihnen zu ermöglichen.

Vorteile der ebXML-Registrierung

Eine ebXML-Registrierung bietet die folgenden Vorteile:

Entdeckung und Pflege von registrierten Inhalten.
Unterstützung für die kollaborative Entwicklung, bei der Benutzer XML-Inhalte erstellen und zur Verwendung und potenziellen Verbesserung durch die autorisierten Parteien an die Registrierung senden können.
Persistenz von WS-BPEL (Business Process Execution Language), WSDL und Geschäftsdokumenten für Webdienste während der Interaktion zwischen Handelspartnern.
Sichere Versionskontrolle von registrierten Inhalten.
Föderation kooperierender Register, um eine einheitliche Ansicht registrierter Inhalte durch nahtloses Abfragen, Synchronisieren und Verschieben registrierter Inhalte bereitzustellen.
Ereignisbenachrichtigung per E-Mail oder Webdienst.

Beachtung

Gemäß der ebXML Registry Services-Spezifikation entspricht eine Registrierungsimplementierung der ebXML-Spezifikation, wenn sie die folgenden Bedingungen erfüllt:

Es unterstützt das ebXML-Registrierungsinformationsmodell.
Es unterstützt die Syntax und Semantik der Registrierungsschnittstellen und die Sicherheit.
Es unterstützt die ebXML-Registrierungs-DTD.
Die Unterstützung der Syntax und Semantik der SQL-Abfrage in der Registrierung ist optional.

Eine Registrierungsclient-Implementierung entspricht der ebXML-Spezifikation, wenn sie die folgenden Bedingungen erfüllt:

Es unterstützt den ebXML CPA- und Bootstrapping-Prozess.
Die Syntax und die Semantik der Registrierungsclient-Schnittstellen.
Die ebXML-Fehlermeldung DTD.
Die ebXML-Registrierungs-DTD.

Registrierungsobjekte und Metadaten

Registrierungsobjekte

Bezieht sich auf ein Objekt, das zur Speicherung und Aufbewahrung an die Registrierung gesendet wird

genannt 'Repository-Element'
XML-Dokument oder DTD, Geschäftsprozessmodelle, CPPs usw.

Metadata

Es wird von der Registrierung zum Klassifizieren und Verwalten von Registrierungsobjekten verwendet.
Es wird durch den Registrierungseintrag dargestellt

Registrierungsinformationsmodell (RIM)

Das Registry Information Model (RIM) bietet einen allgemeinen Entwurf für Metadaten in der ebXML-Registrierung. Dies kann als Software-Stack von Diensten oder als Dienstpyramide dargestellt werden, wie in der folgenden Abbildung dargestellt. Die Elemente des Informationsmodells repräsentieren Metadaten zum Inhalt, nicht zum Inhalt selbst im Repository. Das Registrierungsinformationsmodell definiert die Arten von Objekten, die in der Registrierung gespeichert und organisiert sind.

Das Informationsmodell ist eine Roadmap zum Typ der Metadaten und den Beziehungen zwischen Metadaten. Das Registrierungsinformationsmodell kann einem relationalen Datenbankschema, einem Objektdatenbankschema oder einem anderen physischen Schema zugeordnet sein.

"Eine Kernkomponente erfasst Informationen über ein Geschäftskonzept der realen Welt und Beziehungen zwischen diesem Konzept und anderen Geschäftskonzepten. Eine Kernkomponente kann entweder eine einzelne Geschäftsinformation oder eine Familie von Geschäftsinformationselementen sein. Sie ist Kern, weil sie auftritt in vielen verschiedenen Bereichen des Informationsaustauschs zwischen Industrie und Wirtschaft "

... Definitionsform xbXML vereinfacht von Eric Chiu

Eine Kernkomponente ist ein grundlegender, wiederverwendbarer Baustein, der Informationen enthält, die ein Geschäftskonzept darstellen. Einige Beispiele für Kernkomponenten für Teile einer Bestellung sind Bestelldatum, Umsatzsteuer und Gesamtbetrag.

Im Allgemeinen werden Kernkomponenten in vielen verschiedenen Bereichen, Branchen und Geschäftsprozessen verwendet. In der ebXML-Umgebung sind Kernkomponenten die Bausteine für XML-Semantik und Geschäftsvokabular, die in Nachrichten und Dokumenten verwendet werden.

Aus einem bestimmten Geschäftsdokument in einem Geschäftsprozess können wir auf eine Kernkomponente verweisen, die nur minimale E-Business-Informationen enthält. Wenn die Geschäftsprozesse die Verben im E-Business sind, repräsentieren die Kernkomponenten die Substantive und Adjektive.

Eine Kernkomponente kann in mehreren Geschäftsbereichen verwendet werden, sie kann jedoch auch kontextspezifisch für eine Geschäftsdomäne werden, z. B. für einen einzelnen Branchenbereich.

Eine Kernkomponente arbeitet mit einer Registrierung, da sie mit einer Standard-ebXML-Registrierung gespeichert und abgerufen werden kann. Eine zentrale Kernkomponentenbibliothek dient als Referenzdokument für gängige Geschäftspraktiken in branchenübergreifenden Geschäftsprozessen.

Werkzeuge und Referenzen

Die Liste der wesentlichen Referenzen und Tools für Kernkomponenten, die ebXML für den geschäftlichen und technischen Analysten bereitstellt, lautet wie folgt:

Context and the Re-usability of Core Components: Dieses Dokument enthält Kontextdefinitionen, die Quellen für Klassifizierungswertelisten und ein Bildmodell, das die Beziehungen zwischen Kernkomponente und Kontextdeskriptor darstellt.
Catalog of Context Drivers: Dieses Dokument enthält einen Katalog mit Kontexttreibern.
Document Assembly and Context Rules: Hier werden die Verfahren und Schemata zum Zusammenstellen von Dokumenten unter Verwendung kontextbezogener Kernkomponenten beschrieben.
Core Components Dictionary:Dieses Dokument ist in Abschnitte unterteilt. Jeder Abschnitt beginnt mit den Informationen zur jeweiligen Kategorie und zum Kernkomponententyp.
Core Components Editor and Browser: Mithilfe dieser Tools können Analysten vorhandene Kernkomponenten durchsuchen und integrieren, um das Format der zwischen Handelspartnern ausgetauschten XML-Nachrichten zu definieren und die Kontextregeln ordnungsgemäß zu definieren und anzuwenden.

Beispiele für Kernkomponenten:

Kernkomponente A:
- Anbieter (Industrie1)
- Hersteller (Industrie 2)
- Lieferant (Industrie 3)
Kernkomponente B:
- Händler (Industrie 1)
- Großhändler (Industrie 2)
- Händler (Industrie 3)
Kernkomponente C:
- Geschäft (Industrie 1)
- Outlet (Industrie 2)
- Einzelhändler (Industrie 3)

Fazit

Kernkomponenten sind -

Eindeutig identifizierbar.
Wiederverwendbare Low-Level-Datenstrukturen
- -eg, Partei, Adresse, Telefon, Datum, Währung
- -Context-sensitive
Wird zum Definieren von Geschäftsprozess- und Informationsmodellen verwendet.
Erleichtert die Interoperabilität zwischen unterschiedlichen Systemen.
Eine Kernkomponente in ebXML kann eine andere Kernkomponente enthalten.

Eine vollständige Nachricht wird als Nachrichtenpaket bezeichnet. Hierbei handelt es sich um ein MIME-Objekt (Multipurpose Internet Mail Extensions). Das Nachrichtenpaket enthält zwei Hauptteile:

SOAP Message Container: Dieser Teil der Nachricht ist erforderlich und enthält die SOAP-Erweiterungselemente für ebXML, z. B. Routing-Informationen, Handelspartnerinformationen, Nachrichtenidentifikation und Informationen zur Übermittlungssemantik.
Payload Containers: Dies ist ein optionaler Teil der Nachricht und kann jede Art von Informationen enthalten, die zwischen Parteien ausgetauscht werden sollen.

Messaging-Designkriterien

Gemäß der Messaging-Dienstspezifikation lauten die Entwurfsziele für den ebXML-Nachrichtendienst:

Nutzen Sie vorhandene Standards, wo immer dies möglich ist.
Seien Sie einfach zu implementieren.
Unterstützen Sie Unternehmen jeder Größe.
Unterstützt eine Vielzahl von Kommunikationsprotokollen (HTTP, SMTP, FTP usw.)
Unterstützt Nutzdaten aller Art (XML, EDI-Transaktionen, Binärdaten usw.)
Unterstützt zuverlässiges Messaging.
Sicherheit gewährleisten.

Messaging-Architektur

Der ebXML-Nachrichtendienst wurde entwickelt, um im Gesamtkontext der ebXML-Initiative zu arbeiten. Die technische Architektur von ebXML ist jedoch modular aufgebaut, und der Nachrichtendienst kann unabhängig von ebXML verwendet werden.

Der ebXML-Nachrichtendienst verfügt über drei logische Architekturebenen zwischen der Geschäftsanwendung und den Netzwerkprotokollen:

The Message Service Interface (MSI):Es ist eine Anwendungsschnittstelle für Geschäftsanwendungen zum Aufrufen der Nachrichtenbehandlungsfunktion zum Senden und Empfangen von Nachrichten. Ähnlich wie bei ODBC, JDBC und anderen abstrakten Dienstschnittstellen wird die Message-Handler-Funktionalität als definierter Satz von APIs für Entwickler von Geschäftsanwendungen verfügbar gemacht.
The Message Service Handler (MSH): Es verfügt über grundlegende Dienste wie Header-Verarbeitung, Header-Analyse, Sicherheitsdienste, zuverlässige Messaging-Dienste, Nachrichtenverpackung und Fehlerbehandlung.
The Message Transport Interface (MTI):Es wurde entwickelt, um Nachrichten über verschiedene Netzwerke und Kommunikationsprotokolle auf Anwendungsebene zu senden. Die Transportschnittstelle wandelt ebXML-spezifische Daten in andere Formen um, die von Netzwerkdiensten und -protokollen übertragen werden. Dies beinhaltet einen vollständigen Austausch zwischen zwei Parteien, wobei die vorhandenen Protokolle im Netzwerkstapel huckepack genommen werden.

Die ebXML-Messaging-Architektur ist in der folgenden Abbildung dargestellt.

Nachrichtenformatierung:

Eine ebXML-Nachricht muss gemäß der ebXML-Nachrichtendienstspezifikation formatiert sein und der MIME-Syntax, dem Format und den Codierungsregeln entsprechen. Die Definition der XML-Elemente wird durch ein XML-Schema bereitgestellt, das SOAP erweitert, um den ebXML-Nachrichtenkopf, den Ablaufverfolgungskopf, das Manifest, den Status und die Bestätigung zu definieren.

Fazit

Das ebXML-Messaging -

Verwendet SOAP mit Anhängen als Nutzlastumschlag.
Läuft über verschiedene Kommunikationsprotokolle wie HTTP, SMTP, FTP.
Unterstützt übergeordnete Semantik, die bei Geschäftstransaktionen benötigt wird. (Sicherheit und Zuverlässigkeit)

Das folgende Diagramm zeigt ein ebXML-Szenario, das es einfach macht, das Konzept von ebXML zu erlernen. Das Beispiel stammt aus der Spezifikation für die technische Architektur.

Das Beispiel zeigt, wie sich Unternehmen auf ebXML vorbereiten, nach neuen Handelspartnern suchen und sich dann im elektronischen Geschäft engagieren.

Unternehmen A durchsucht die ebXML-Registrierung, um festzustellen, was online verfügbar ist. Im besten Fall kann Unternehmen A alle vorhandenen Geschäftsprozesse, Dokumente und Kernkomponenten seiner Branche wiederverwenden, die bereits in der ebXML-Registrierung gespeichert sind. Andernfalls entwirft Unternehmen A die fehlenden Teile, speichert sie in der ebXML-Registrierung und stellt sie seinen Industriepartnern zur Verfügung.
Unternehmen A beschließt, elektronisches Geschäft auf ebXML-Weise zu betreiben, und erwägt die Implementierung einer lokalen ebXML-kompatiblen Anwendung. Ein ebXML Business Service Interface (BSI) stellt die Verbindung zwischen dem Unternehmen und der externen ebXML-Welt her. Das Unternehmen muss ein Collaboration Protocol Profile (CPP) erstellen, das die unterstützten Geschäftsprozessfunktionen, Einschränkungen und technischen ebXML-Informationen wie die Auswahl von Verschlüsselungsalgorithmen, Verschlüsselungszertifikaten und die Auswahl von Transportprotokollen beschreibt.
Unternehmen A übermittelt seinen CPP an die ebXML-Registrierung. Ab diesem Zeitpunkt ist Unternehmen A öffentlich in der ebXML-Registrierung aufgeführt und wird wahrscheinlich von anderen Unternehmen entdeckt, die nach neuen Handelspartnern fragen.
Unternehmen B ist bereits im ebXML-Register registriert und sucht neue Handelspartner. Unternehmen B fragt die ebXML-Registrierung ab und erhält den CPP von Unternehmen A. Unternehmen B verfügt dann über zwei CPPs: den CPP von Unternehmen A und einen eigenen. Die beiden Unternehmen müssen eine Vereinbarung über die Geschäftsabwicklung treffen, die in der ebXML-Terminologie als Collaboration Protocol Agreement (CPA) bezeichnet wird. Unternehmen B verwendet ein ebXML-CPA-Bildungstool, um aus den Anforderungen der beiden CPPs einen CPA abzuleiten
In diesem Szenario kommuniziert Unternehmen B direkt mit Unternehmen A und sendet den neu erstellten CPA zur Annahme an Unternehmen A. Nach Vereinbarung des CPA durch Unternehmen A sind beide Unternehmen für das elektronische Geschäft bereit.
Die Unternehmen verwenden dann das zugrunde liegende ebXML-Framework und tauschen Geschäftsdokumente gemäß CPA aus. Dies bedeutet, dass beide Unternehmen die im CPA definierten Geschäftsprozesse befolgen.