Standard RNIF
Lo standard RNIF (RosettaNet Implementation Framework) definisce il modo in cui i sistemi trasportano un messaggio di RosettaNet. Si tratta di un solido standard di trasmissione, routing, creazione di pacchetti e sicurezza. Tutti i sistemi di messaggistica RosettaNet devono essere conformi allo standard RNIF per ottenere la certificazione RosettaNet.
Lo standard definisce la struttura dei messaggi, la necessità di acknowledgement, la codifica MIME (Multipurpose Internet Mail Extensions) e la firma digitale. Lo standard principale include i requisiti di autenticazione, autorizzazione, crittografia e non ripudio. Lo standard RNIF è basato sugli standard HTTP, MIME e XML. Lo standard RNIF non specifica una piattaforma o un'applicazione di abilitazione.
BizTalk Accelerator for RosettaNet (BTARN) implementa due versioni di RNIF: RNIF Specification v02.00.01 e RNIF Specification v1.1. 2.01 RNIF ha aggiunto funzionalità significative rispetto a quelle supportate da RNIF 1.1, tra cui crittografia, allegati e transazioni sincrone. RNIF 2.0 non è compatibile con RNIF 1.1.
Modelli di framework di messaggistica
La tabella seguente illustra il supporto RNIF per i modelli di framework di messaggistica e scambio di messaggi sincrono. Un messaggio ad azione singola non prevede una risposta, mentre un messaggio a doppia azione include una richiesta e una risposta.
Framework | Modello | Sincrono/ Asincrono |
---|---|---|
RNIF 1.1 | Notifica | Asincrono |
RNIF 1.1 | Transazione | Asincrono |
RNIF 2.0 | Doppia azione | Sincrono |
RNIF 2.0 | Doppia azione | Asincrono |
RNIF 2.0 | Azione singola | Sincrono |
RNIF 2.0 | Azione singola | Asincrono |
Definizioni dei messaggi
RNIF 1.1 e RNIF 2.01 definiscono il messaggio di RosettaNet in modo diverso. Le differenze includono la modalità di gestione degli allegati, l'envelope S/MIME (Secure Multipurpose Internet Mail Extensions), l'intestazione del recapito e la creazione del pacchetto MIME. A differenza di RNIF 1.1, RNIF 2.01 include specificatamente gli allegati e aggiunge un'intestazione del recapito.
Nota
BTARN non supporta le raccomandazioni tecniche per RNIF 1.1 pubblicate dall'organizzazione RosettaNet (una per il supporto degli allegati e una per le risposte sincrone).
I sistemi usano la parte dei messaggi RNIF 1.1 e RNIF 2.01 per l'identificazione delle parti, il routing e l'identificazione del livello di servizio. Prima di leggere e rispondere a un corpo di contenuto del servizio, ovvero il contenuto principale del messaggio, ogni parte deve popolare o interpretare correttamente i valori di intestazione.
La figura seguente mostra le definizioni dei messaggi RNIF 1.1 e RNIF 2.01.
Nel messaggio RNIF 1.1 il numero di versione indica la versione di RNIF. La lunghezza del contenuto è la lunghezza del messaggio di servizio di RosettaNet. Il messaggio di servizio, che include il preambolo, l'intestazione del servizio e il contenuto del servizio, è un'entità MIME multiparte/correlata. La lunghezza della firma è la lunghezza della firma in byte. Se la firma esiste, è una firma Public-Key Cryptography Standards (PKCS) #7 nel campo del messaggio di servizio.
RNIF 2.01 include un contenitore indipendente dal protocollo di trasferimento che riunisce il payload di business, i componenti di intestazione e gli altri elementi che i sistemi si scambieranno nel pacchetto. Un messaggio RosettaNet Business Message (secondo la definizione per RNIF 2.01) contiene un preambolo, un'intestazione del servizio e il contenuto del servizio. I sistemi devono convalidare tutti gli elementi a fronte dello schema per il tipo di documento che lo contiene, in base alle regole di convalida della grammatica DTD (Document Type Definition) dello standard RosettaNet. Il contenuto del servizio può essere un messaggio di azione o un messaggio di segnalazione. Se si tratta di un messaggio di azione, il messaggio può includere uno o più allegati.
Un messaggio RosettaNet Business Message è un'entità MIME multiparte/correlata. Come illustrato nella figura precedente, le intestazioni e il contenuto del servizio sono riuniti in un pacchetto usando un costrutto MIME multiparte/correlato, simile allo schema di creazione di pacchetti di RNIF 1.1. Facoltativamente, i sistemi possono firmare digitalmente un messaggio RosettaNet Business Message. In RNIF 1.1 viene usato il formato RNO (RosettaNet Object ) a questo scopo. RNIF 2.0 elimina il formato RNO e usa la codifica S/MIME standard.
Un sistema potrebbe crittografare il payload o il contenitore di payload RNIF 2.01. A questo scopo occorre aggregare le parti da crittografare in un'entità MIME multiparte/correlata e quindi crittografarle. In seguito l'oggetto S/MIME risultante viene inserito in un pacchetto come parte singola nel messaggio RosettaNet Business Message.
Un messaggio di segnalazione deve essere sempre un'istanza di messaggio di segnalazione definita da RosettaNet. Per i messaggi di azione, la specifica RNIF 2.01 prevede la possibilità di distribuire i messaggi di azione di business in un formato definito da terze parti. L'intestazione di servizio RNIF 2.01 include campi supplementari a questo scopo, ad esempio un campo che identifica il “corpo standard” e un campo che identifica la versione della specifica a cui è conforme il messaggio di azione.
Solo i messaggi di azione (detti anche contenuto di business) possono essere di origine non RosettaNet. I sistemi devono scambiare questi messaggi in un PIP definito da RosettaNet. RosettaNet deve sanzionare questi messaggi identificando in modo esplicito il messaggio di azione di terze parti sanzionato nella specifica PIP. Inoltre, i partner commerciali devono approvare lo scambio di contenuti di business di terze parti all'interno dell'accordo tra partner commerciali. L'accordo deve includere le informazioni di associazione del payload PIP, che identificano i contenuti di business di terze parti da usare in sostituzione di un particolare messaggio di azione in un PIP.
Vedere anche
Standard di messaggistica RosettaNet e CIDX
PIP di RosettaNet