Traduzione dei modelli della soluzione orientata ai servizi

In questa sezione viene descritto come la soluzione traduce il diagramma del modello in elementi di BizTalk Server.

Connessioni e condizioni di completezza

È possibile iniziare praticamente ovunque con la conversione dei modelli in componenti di BizTalk Server. Tuttavia, le connessioni tra i componenti sono, in effetti, l'infrastruttura per i componenti in modo che sembri un buon punto di partenza. Inoltre, nel caso del modello aggregatore, dobbiamo pensare a ciò che gli dirà che ha tutte le informazioni necessarie. Ciò influisce sulle connessioni ad altri componenti e sulla relativa progettazione.

La soluzione deve fornire un modo pratico e coerente di essere usato. L'interfaccia del servizio specifica il modo in cui altre applicazioni possono usarle. Poiché la soluzione deve comunicare con un'applicazione legacy usando IBM WebSphere MQ, IBM WebSphere MQ deve far parte dell'interfaccia del servizio. Tuttavia, per le applicazioni più recenti, un'interfaccia del servizio Web sembra una scelta ovvia. Un'interfaccia del servizio Web offre la massima flessibilità per altre applicazioni che usano il servizio. In questo caso, è possibile usare la flessibilità di BizTalk Server per avere un'interfaccia a doppio servizio. Per informazioni sull'esposizione di orchestrazioni come servizi Web, vedere Come eseguire il mapping delle orchestrazioni ai servizi Web.

Le altre connessioni sono quelle tra l'interfaccia del servizio e l'elenco dei destinatari, tra l'elenco di destinatari e le applicazioni back-end e tra le applicazioni back-end, l'aggregatore e l'interfaccia del servizio.

Se la connessione all'elenco dei destinatari è sincrona, la soluzione non deve usare correlazioni per garantire che tutti i messaggi all'elenco dei destinatari vengano inviati e ricevuti. Le connessioni tra le applicazioni back-end e l'aggregatore possono essere sincrone per gli stessi motivi. L'aggregatore necessita delle risposte di tutte e tre le applicazioni back-end per completare la risposta alla query. I tempi di risposta devono essere brevi in modo che le connessioni sincrone siano appropriate e semplificano la soluzione.

Nel modello di aggregatore è in genere presente una condizione di completezza. Nei casi in cui sono presenti più server back-end e tempi di risposta sono lenti, la condizione di completezza potrebbe essere, ad esempio, la ricezione di almeno una risposta in un determinato periodo di tempo. Questa soluzione orientata ai servizi richiede tutte e tre le risposte per costruire il messaggio finale. In questo caso, la condizione di completezza riceve tutte e tre le risposte.

Annotazioni

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 fa parte del metodo standard di utilizzo dell'adattatore MQSeries in modalità richiesta-risposta per evitare una possibile condizione di competizione. Per altre informazioni, vedere Correlazione dei messaggi tramite Request-Reply.

Determinazione dei limiti di orchestrazione

La soluzione deve consentire le richieste da una coda IBM WebSphere MQ e tramite l'interfaccia del servizio Web. Inserire l'interfaccia del servizio in un'orchestrazione, l'input IBM WebSphere MQ in un'altra e la maggior parte dell'elaborazione in un terzo mantiene la comunicazione esterna separata dall'elaborazione.

Conversione dei componenti in forme di orchestrazione

I modelli da tradurre in forme saranno, nella soluzione finale, in un'unica orchestrazione. Esistono diversi modi per creare un router basato su contenuto in BizTalk Server, inclusa la creazione di sottoscrizioni MessageBox. Nella soluzione il routing usa le sottoscrizioni MessageBox. Una forma di espressione valuta se il messaggio include o meno valori per i campi obbligatori. Una forma decisionale valuta il set di variabili nella forma dell'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 è necessario attendere il completamento di un'applicazione prima di effettuare la richiesta successiva. Se il numero di applicazioni dovesse cambiare frequentemente o se le connessioni alle applicazioni non erano affidabili, l'orchestrazione dovrà tradurre il modello in modo diverso.

Nella soluzione l'aggregatore deve combinare elementi da tre messaggi di risposta. L'uso della forma parallela garantisce che la comunicazione con i sistemi back-end sia parallela. Inoltre, poiché la forma non termina finché non riceve tutte le risposte o un timeout, l'aggregatore saprà sempre quando può procedere. L'orchestrazione usa una forma di trasformazione che esegue il mapping degli elementi dei tre messaggi di risposta back-end e del messaggio di richiesta originale agli elementi nel messaggio di risposta.

Annotazioni

Anche le comunicazioni con i sistemi back-end possono anche andare in timeout. È possibile impostare il periodo di timeout racchiudendo l'elemento Receive in un elemento Scope e impostando la proprietà Timeout dello scope.

Per un elenco completo delle forme di orchestrazione, vedere Forme di orchestrazione.

Vedere anche

Modelli nella soluzione orientata ai servizi
Componenti della soluzione orientata ai servizi