RNIF-Standard

Der RNIF-Standard (RosettaNet Implementation Framework) definiert, wie Systeme eine RosettaNet-Nachricht transportieren. Der RNIF-Standard ist ein robuster Übertragungs-, Routing-, Verpackungs- und Sicherheitsstandard. Alle RosettaNet-Messagingsysteme müssen dem RNIF-Standard entsprechen, um die RosettaNet-Zertifizierung zu erreichen.

Der Standard definiert die Nachrichtenstruktur, die Notwendigkeit von Bestätigungen, die MIME-Codierung (Multipurpose Internet Mail Extensions) und die digitale Signatur. Der Kernstandard umfasst Anforderungen für Authentifizierung, Autorisierung, Verschlüsselung und Nicht-Ablehnung. Der RNIF-Standard basiert auf HTTP-, MIME- und XML-Standards. Der RNIF-Standard gibt keine Plattform oder aktivierend anwendung an.

BizTalk Accelerator for RosettaNet (BTARN) implementiert zwei Versionen von RNIF: RNIF Specification v02.00.01 und RNIF Specification v1.1. RNIF 2.01 hat erhebliche Funktionen hinzugefügt, die über die von RNIF 1.1 hinausgehen, einschließlich Verschlüsselung, Anlagen und synchronen Transaktionen. RNIF 2.0 ist nicht abwärtskompatibel mit RNIF 1.1.

Messagingframeworkmuster

Die folgende Tabelle zeigt RNIF-Unterstützung für Messagingframeworkmuster und synchronen Nachrichtenaustausch. Eine Einzelaktionsnachricht ist eine Nachricht, die keine Antwort beinhaltet, während eine Doppelaktionsnachricht eine Anforderung und Antwort enthält.

Framework	Muster	Synchrone/ Asynchron
RNIF 1.1	Benachrichtigung	Asynch
RNIF 1.1	Transaktion	Asynch
RNIF 2.0	Double-Action	Synch
RNIF 2.0	Double-Action	Asynch
RNIF 2.0	Einzelaktion	Synch
RNIF 2.0	Einzelaktion	Asynch

Nachrichtendefinitionen

RNIF 1.1 und RNIF 2.01 definieren die RosettaNet-Nachricht unterschiedlich. Zu diesen Unterschieden gehören die Handhabung von Anlagen, der SMIME-Umschlag (Secure/Multipurpose Internet Mail Extensions), der Übermittlungsheader und die MIME-Verpackung. RNIF 2.01 umfasst insbesondere Anlagen; RNIF 2.01 fügt einen Übermittlungsheader hinzu, während RNIF 1.1 dies nicht tut.

Hinweis

BTARN unterstützt nicht die technischen Empfehlungen für RNIF 1.1, die vom RosettaNet-organization veröffentlicht wurden (eine für die Unterstützung von Anlagen und eine für synchrone Antworten).

Systeme verwenden die Teile von RNIF 1.1- und RNIF 2.01-Nachrichten für Die Identifizierung, das Routing und die Identifizierung auf Dienstebene. Vor dem Lesen und Antworten auf einen Textkörper von Dienstinhalten, bei dem es sich um den Standard Inhalt der Nachricht handelt, muss jede Seite die Headerwerte erfolgreich auffüllen oder interpretieren.

In der folgenden Abbildung werden die RnIF 1.1- und RNIF 2.01-Nachrichtendefinitionen beschrieben.

In der RNIF 1.1-Nachricht gibt die Versionsnummer die RNIF-Version an. Die Inhaltslänge ist die Länge der RosettaNet-Dienstnachricht. Die Dienstnachricht, die die Präambel, den Dienstheader und den Dienstinhalt enthält, ist eine mehrteilige/verwandte MIME-Entität. Die Signaturlänge ist die Länge der Signatur in Bytes. Wenn die Signatur vorhanden ist, handelt es sich um eine Public-Key Cryptography Standards (PKCS) #7-Signatur im Feld Dienstnachricht.

RNIF 2.01 enthält einen übertragungsprotokollunabhängigen Container, der die Geschäftsnutzlast, Headerkomponenten und andere Elemente zusammenfasst, die Systeme im Paket austauschen. Eine RosettaNet-Geschäftsnachricht (wie für RNIF 2.01 definiert) enthält eine Präambel, einen Übermittlungsheader, einen Dienstheader und Dienstinhalt. Systeme müssen alle Elemente anhand des Schemas für den Dokumenttyp überprüfen, der sie enthält, basierend auf den Regeln für die Grammatikvalidierung von RosettaNet-Standarddokumenttypdefinition (DTD). Dienstinhalte können eine Aktionsnachricht oder eine Signalnachricht sein. Wenn der Dienstinhalt eine Aktionsnachricht ist, kann die Nachricht eine oder mehrere Anlagen enthalten.

Eine RosettaNet Business Message ist eine mehrteilige/verwandte MIME-Entität. Wie in der vorherigen Abbildung gezeigt, werden die Header und Dienstinhalte mithilfe eines mehrteiligen/verwandten MIME-Konstrukts zusammengepackt, das dem PAKETSCHEMA RNIF 1.1 ähnelt. Optional können Systeme eine RosettaNet Business-Nachricht digital signieren. In RNIF 1.1 würden Sie zu diesem Zweck das RNO-Format (RosettaNet Object) verwenden. RNIF 2.0 eliminiert das RNO-Format und verwendet stattdessen die S/MIME-Standardcodierung.

Ein System kann die RNIF 2.01-Nutzlast oder den Nutzlastcontainer verschlüsseln. Zu diesem Ziel bündeln Sie die Teile, die Sie verschlüsseln möchten, in einer mehrteiligen/zugehörigen MIME-Entität und verschlüsseln sie dann. Anschließend packen Sie das resultierende S/MIME-Objekt als einzelnes Teil in der RosettaNet Business Message.

Eine Signalnachricht muss immer eine von RosettaNet definierte Signalnachricht instance sein. Für Aktionsmeldungen bietet die RNIF 2.01-Spezifikation die Möglichkeit, Geschäftsaktionsnachrichten in einem von Drittanbietern definierten Format zu senden. Der RNIF 2.01-Dienstheader enthält zusätzliche Felder für diesen Zweck, z. B. ein Feld, das den "Standardtext" identifiziert, und ein Feld, das die Version der Spezifikation identifiziert, der die Aktionsmeldung entspricht.

Nur Aktionsnachrichten (auch als Geschäftsinhalt bezeichnet) können nicht rosettaNet-Ursprungs sein. Systeme müssen diese Nachrichten in einem von RosettaNet definierten PIP austauschen. RosettaNet muss diese Nachrichten sanktionieren, indem die sanktionierte Drittanbieteraktionsnachricht in der PIP-Spezifikation explizit identifiziert wird. Darüber hinaus müssen Handelspartner in ihrer Handelspartnervereinbarung den Austausch von Geschäftsinhalten von Drittanbietern vereinbaren. Die Vereinbarung muss die Pip-Nutzlastbindungsinformationen enthalten, die angibt, welche Drittanbieter-Geschäftsinhalte Sie als Ersatz für eine bestimmte Aktionsnachricht in einer PIP verwenden würden.

Weitere Informationen

Nachrichtenstandards von RosettaNet und CIDX
RosettaNet-PIPs