Messaggi richiesta-risposta
In un modello di messaggistica di tipo richiesta/risposta, un'entità invia un messaggio di richiesta e l'entità ricevente restituisce un messaggio di risposta. Due esempi tipici di elaborazione di tipo richiesta/risposta sono l'interazione tra un browser con un server Web mediante l'adapter HTTP e l'elaborazione di un servizio Web mediante l'adapter SOAP (Simple Object Access Protocol). In BizTalk Server, sia la richiesta che i messaggi di risposta vengono gestiti in modo tipico di pubblicazione/sottoscrizione. È importante tenere presente questo punto quando si ottimizzano le prestazioni di un'applicazione BizTalk, perché un sistema che necessita di una velocità effettiva elevata può essere configurato in modo diverso rispetto a un sistema che richiede una bassa latenza per i singoli messaggi.
Quando un messaggio viene ricevuto da un adapter di ricezione di tipo richiesta/risposta, BizTalk Server pubblica in primo luogo il messaggio di richiesta nel database MessageBox. Il messaggio viene quindi ricevuto dal sottoscrittore appropriato, in genere un'orchestrazione associata a una porta di ricezione. Il sottoscrittore formula un messaggio di risposta e lo pubblica nel MessageBox, insieme alle proprietà che provvedono a inviarlo alla porta di ricezione da cui è giunta la richiesta. Infine il messaggio di risposta viene prelevato dal server di pubblicazione della richiesta, l'adapter di ricezione che ha inviato la richiesta, e viene restituito all'applicazione chiamante. L'illustrazione seguente mostra una rappresentazione grafica dettagliata di questi passaggi.
Flusso del messaggio di richiesta/risposta ricevuto dall'adapter SOAP
L'adapter SOAP invia i messaggi a Gestione endpoint.
Gestione endpoint pubblica il messaggio nel MessageBox.
L'orchestrazione, che è associata alla porta di ricezione e pertanto ha una sottoscrizione per il messaggio, riceve il messaggio e lo elabora.
L'orchestrazione invia un messaggio di risposta che viene pubblicato nel MessageBox.
Gestione endpoint riceve il messaggio di risposta.
Gestione endpoint restituisce la risposta all'adapter SOAP
Se non si comprende l'implementazione interna, si rischia di trascurare le implicazioni di questo tipo di comportamento per quanto riguarda le prestazioni. Inizialmente BizTalk Server è ottimizzato per scenari di elevata velocità effettiva, ma può essere configurato anche per un ambiente con una velocità effettiva più bassa ma che richiede una latenza minore, particolarmente per quanto riguarda gli scenari di richiesta/risposta. In questo scenario, per ottenere l'ottimizzazione è necessario prendere in considerazione diversi componenti. In primo luogo i sottoscrittori vengono a conoscenza dei messaggi pubblicati tramite un meccanismo di polling. Se si imposta un intervallo di polling troppo alto, le interazioni a livello di richiesta/risposta possono avere una latenza maggiore di quella desiderata.
Si noti che in questo scenario sono presenti due sottoscrizioni da compilare: la sottoscrizione per il messaggio iniziale e quella per il messaggio di risposta e questo aumenta l'impatto di questo intervallo di polling. In secondo luogo, gli adapter di ricezione sono configurati in modo da inserire i messaggi nel MessageBox in batch di dimensioni variabili. La maggior parte degli adapter consentono di configurare le dimensioni del batch tramite la tipica interfaccia di configurazione degli adapter o tramite parametri in BizTalk Server o nel Registro di sistema. Se si impostano dimensioni del batch troppo elevate, può aumentare la latenza per i singoli messaggi. Per altre informazioni sulle caratteristiche delle prestazioni di BizTalk Server, vedere Planning for Sustained Performance.For more information about the performance characteristics of BizTalk Server, see Planning for Sustained Performance.