Modelli di scambio dei messaggi dell'adapter
Adapter Framework BizTalk supporta un set completo di modelli di scambio dei messaggi che può essere utilizzato dagli adapter in molti efficaci scenari di messaggistica.
Unidirezionale (asincrono)
In questo caso il flusso messaggi si muove in una sola direzione.
In questo modello di scambio di messaggi, i messaggi passano in un modo per BizTalk Server attraverso un adattatore. Il motore di messaggistica pubblica il messaggio nel database MessageBox. Se un'orchestrazione dispone di una sottoscrizione attiva a un messaggio di quel tipo, il messaggio viene instradato a tale orchestrazione.
Dopo l'elaborazione del messaggio, l'orchestrazione pubblica il messaggio di nuovo nel database MessageBox prima che venga instradato a un adapter affinché venga trasmesso allo specifico endpoint.
Quando il messaggio viene inoltrato al motore, non è prevista una risposta. Nella parte in uscita, quando il messaggio viene trasmesso, non è prevista una risposta. Questo contesto viene generalmente definito messaggistica asincrona e rappresenta, sotto molti punti di vista, la base utilizzata dal motore per tutti gli scenari di messaggistica.
Protocolli di tipo Richiesta-Risposta (Sync-on-Async)
Uno scenario richiesta-risposta è basato sulla ricezione di un messaggio di richiesta, sulla sua elaborazione e sull'invio di un messaggio di risposta. Viene anche definito sincrono-on-asynchronous (sync-on-async) perché l'architettura BizTalk Server sottostante è asincrona per motivi di scalabilità. L'architettura del motore di messaggistica BizTalk, tuttavia, consente di esporre un modello di scambio dei messaggi sincrono su questi scambi asincroni. Per questo scopo, il motore gestisce la complessa operazione di correlazione dei messaggi di richiesta e risposta attraverso un'architettura con scalabilità orizzontale collegando una serie di scambi di messaggi asincroni per esporre un'interfaccia asincrona.
Ad esempio, una pagina Web che controlla l'inventario potrebbe effettuare una chiamata SOAP a un adattatore di ricezione SOAP BizTalk. BizTalk Server orchestra una serie di servizi Web che aggregano le informazioni e la restituiscono in una risposta SOAP. Al client questa risulta una chiamata SOAP sincrona, ma in realtà il motore unisce una serie di scambi di messaggi asincroni.
Protocolli di tipo Sollecitazione-Risposta
Questo scenario ha inizio con l'invio di un messaggio di sollecitazione e si conclude con la ricezione di un messaggio di risposta. È definito sollecitazione-risposta poiché il messaggio iniziale inviato sollecita un messaggio di risposta da un endpoint. Uno scenario che utilizza questo modello di scambio dei messaggi può includere un'orchestrazione che esegue una chiamata HTTP in uscita (una sollecitazione di risposta) e attende la risposta.
Richiesta-risposta multipla
Questo scenario è simile a quello di richiesta-risposta, con la differenza che in questo caso possono essere fornite più risposte per una determinata richiesta. Le API consentono di specificare un valore di timeout, pertanto tutte le risposte ricevute entro il periodo di timeout vengono restituite all'adapter di ricezione.
Loop-back
Questo scenario è simile a quello di richiesta-risposta, in quanto il messaggio di richiesta viene pubblicato normalmente, tuttavia il motore verifica che tale messaggio venga instradato alla stessa istanza di adapter che ha pubblicato il messaggio di richiesta. Poiché il messaggio di richiesta viene pubblicato nel database MessageBox, l'infrastruttura di rilevamento verifica che il messaggio di richiesta e quello di risposta vengano rilevati. Questo è anche un buon sistema per richiamare l'elaborazione di una pipeline di trasmissione per il messaggio e subito dopo inviare l'output all'adapter in modo che possa essere ulteriormente elaborato.
Un esempio di scenario è rappresentato da un client che richiede una ricevuta per un messaggio. Il messaggio in ingresso viene pubblicato nel database MessageBox. Quindi, il messaggio in ingresso e la ricevuta vengono restituiti all'adapter nello stesso batch. In questo caso, il messaggio in ingresso viene copiato e un'istanza viene restituita al cliente, mentre l'altra viene elaborata con la procedura normale. Questo scenario specifico richiede anche la scrittura di un disassembler XML personalizzato.