Traduzione dei modelli della soluzione orientata ai servizi
In questa sezione viene descritta la modalità di conversione del diagramma di modelli in elementi di BizTalk Server da parte della soluzione.
Connessioni e condizioni di completezza
Per la conversione dei modelli in componenti di BizTalk Server è possibile iniziare praticamente da qualsiasi punto. Poiché tuttavia le connessioni tra i componenti costituiscono in pratica l'infrastruttura dei componenti stessi, iniziare dalle connessioni sembra essere una buona soluzione. Nel caso inoltre del modello di aggregatore, è necessario valutare come indicare a tale modello che sono note tutte le informazioni necessarie. Questo ha impatto sia sulle connessioni ad altri componenti, sia sulla relativa struttura.
La soluzione deve consentire un utilizzo semplice e uniforme. L'interfaccia di servizio specifica come può essere utilizzata da altre applicazioni. Poiché la soluzione deve comunicare con un'applicazione legacy utilizzando IBM WebSphere MQ, questo componente deve far parte dell'interfaccia di servizio. Per le applicazioni più recenti tuttavia un'interfaccia di servizio Web sembra una scelta ovvia. Un'interfaccia di servizio Web offre la massima flessibilità per altre applicazioni che utilizzano il servizio. In questo caso è possibile utilizzare la flessibilità di BizTalk Server per disporre di due interfacce di servizio. Per informazioni sull'esposizione di orchestrazioni come servizi Web, vedere Come eseguire il mapping delle orchestrazioni ai servizi Web.
Le altre connessioni sono rappresentate dalle connessioni tra l'interfaccia di servizio e l'elenco destinatari, tra l'elenco destinatari e le applicazioni back-end e tra le applicazioni back-end, l'aggregatore e l'interfaccia di servizio.
Se la connessione all'elenco destinatari è sincrona, la soluzione non deve utilizzare correlazioni per garantire l'invio e la ricezione di tutti i messaggi dell'elenco destinatari. Le connessioni tra le applicazioni back-end e l'aggregatore possono essere sincrone per gli stessi motivi. L'aggregatore necessita delle risposte da tutte e tre le applicazioni back-end per completare la risposta a una query. I tempi di risposta devono essere brevi, in modo che le connessioni sincrone siano appropriate e semplifichino la soluzione.
Nel modello di aggregatore esiste in genere una condizione di completezza. In scenari con più server back-end e tempi di risposta lenti la condizione di completezza può essere costituita ad esempio dalla ricezione di almeno una risposta in un determinato periodo di tempo. Questa soluzione orientata ai servizi richiede tutte e tre le risposte per la creazione del messaggio finale. In questo caso pertanto la condizione di completezza è costituita dalla ricezione di tutte e tre le risposte.
Nota
Quando si ricevono richieste tramite IBM WebSphere MQ, la soluzione aggiunge un identificatore di correlazione copiando il valore MQMD_MsgId al MQMD_CorrelId del messaggio di risposta. Questo processo fa parte dell'utilizzo standard dell'adapter MQSeries in scenari di richiesta-risposta per evitare che si verifichi una possibile race condition. Per altre informazioni, vedere Correlare i messaggi usando Request-Reply.
Determinazione dei limiti delle orchestrazioni
La soluzione deve consentire le richieste provenienti da una coda IBM WebSphere MQ, nonché tramite l'interfaccia di servizio Web. L'inserimento dell'interfaccia di servizio in un'orchestrazione, dell'input di IBM WebSphere MQ in un'altra e della maggior parte delle operazioni di elaborazione in un'altra ancora consente di mantenere le comunicazioni esterne separate dall'elaborazione.
Conversione dei componenti in forme di orchestrazione
Nella soluzione finale i modelli da convertire in forme saranno inclusi in una singola orchestrazione. Esistono diversi modi per creare un router basato sul contenuto in BizTalk Server, ad esempio la creazione di sottoscrizioni MessageBox. Nella soluzione il routing utilizza le sottoscrizioni MessageBox. Una forma Espressione valuta se il messaggio include o meno i valori per i campi obbligatori. Una forma Decisione valuta la variabile impostata nella forma Espressione e seleziona il percorso tramite l'orchestrazione.
L'orchestrazione CustomerService usa la forma parallela per inviare messaggi alle applicazioni back-end e ricevere risposte contemporaneamente. Non deve attendere il completamento in un'applicazione per effettuare la richiesta successiva. Se il numero di applicazioni dovesse cambiare frequentemente o se le connessioni alle applicazioni non fossero affidabili, l'orchestrazione potrebbe dover convertire il modello in modo diverso.
Nella soluzione l'aggregatore deve combinare gli elementi da tre messaggi di risposta. L'utilizzo della forma parallela garantisce comunicazioni parallele con i sistemi back-end. Poiché inoltre la forma non termina finché non riceve tutte le risposte o finché non si verifica un timeout, l'aggregatore dispone sempre di un'indicazione per iniziare a procedere. L'orchestrazione utilizza una forma Trasforma che esegue il mapping dei tre messaggi di risposta back-end e del messaggio di richiesta originale agli elementi del messaggio di risposta.
Nota
Le comunicazioni con i sistemi back-end possono anche timeout. È possibile impostare il periodo di timeout racchiudendo la forma Receive in una forma Scope e impostando la proprietà Timeout dell'ambito.
Per un elenco completo delle forme di orchestrazione, vedere Forme di orchestrazione.
Vedere anche
Modelli della soluzione orientata ai servizi
Componenti della soluzione orientata ai servizi