Domanda

Ho un po 'di esperienza con BizTalk e sto cercando di capire BizTalk 2009 ESB Toolkit 2 senza usarlo. In primo luogo, mi chiedo se qualcuno può chiarire un paio di concetti per me:

  1. Qual è la differenza tra una "rampa" e di una "porta di ricezione"?
  2. Perché avete bisogno di itinerari, può non solo creare le stesse che utilizzano porti e orchestrazioni? Sono ovviamente manca qualcosa qui.

Un paio di questioni più generali:

  1. Do tutti i messaggi devono ancora passare attraverso la finestra di messaggio?

Grazie in anticipo per qualsiasi comprensione.

È stato utile?

Soluzione

On-rampe

L'on-rampe sono servizio Web basate porta di ricezione, ma sono un po 'diverso in quanto accetta messaggi XML generici. I messaggi saranno comunque avere una speciale intestazione SOAP (una "busta" se si vuole) con tutte le proprietà necessarie per fare ad esempio un messaggio itinerario possibile, troverete tutte le possibili colpo di testa di dover guardare in "EsbEnvGeneric.xsd"

itinerari

Mi piace NealWalter rispondere sulla via. Io però solo aggiungere l'approccio messaggio itinerario può salvare potenziale molto di tempo e sforzo di sviluppo. Si può fare una delle organizzazioni più agili e facilità cambiamenti nei loro processi. Se non abbiamo per sviluppare e distribuire una nuova orchestrazione ma solo cambiare un po 'la configurazione e utilizzare i nostri bit esistenti che possono ovviamente risparmiare un sacco di tempo. E questo è il grande valore in un itinerario ESB e il messaggio come la vedo io.

Message Box

I messaggi in BizTalk devono sempre passare attraverso la finestra di messaggio. Nella prossima versione di MS sono stati suggerendo di una bassa scenario di latenza in BizTalk - forse allora possiamo guadagnare un po 'più di controllo, ma di più, ma per ora i messaggi otteniamo persistito molte volte sulla loro strada attraverso BizTalk e non c'è niente al riguardo <. / p>

Altri suggerimenti

Sono solo affrontando solo la tua seconda domanda:

  

2) Perché avete bisogno di itinerari, può   Non è sufficiente creare la stessa utilizzando   porti e orchestrazioni? sono   evidentemente manca qualcosa qui.

Al ultimo posto ho lavorato, abbiamo lavorato sul nostro ESB per circa un anno. L'idea del fantastico itinerario è che quando arriva un messaggio nella ESB, dovrebbe magicamente andare nella giusta sequenza ai sistemi appropriati.

Con un sistema di Business Process (BPM) Oriented, in genere si scrive un'orchestrazione per dirigere il flusso della logica. In altre parole, si codifica l'itinerario o il percorso del messaggio nell'orchestrazione. Nel ESB che abbiamo costruito, le regole di business deciso dove il messaggio sarebbe andata. Avevamo ancora orchestrazioni per end-point, ma in genere rimasti a corto e solo fatto mappatura e alcune funzionalità molto di base. In altri luoghi con cui ho lavorato, le orchestrazioni possono essere abbastanza grandi.

Quindi, le regole di ciò che a che fare con il messaggio devono essere da qualche parte. Nel ESB, ciascun punto finale dovrebbe essere completamente agnostico e inconsapevole degli altri punti finali. Il campo ESB presume che il sistema ha bisogno di cambiare in modo più dinamico, senza dover ridistribuire il software (cioè orchestrazioni). Quindi, con il nostro ESB, basta solo cambiare le regole di business e di ridistribuire.

Alcune delle questioni difficili con un ESB sono operano le transazioni, rollback, e di solito la creazione di un processo di gestione degli errori comuni.

Neal Walters http://BizTalk-Training.com

Un paio di punti di vista complementari -

porte di ricezione / on-rampe - completamente d'accordo con la risposta di Riri e sarebbe semplicemente aggiungere - una rampa nel contesto di un'applicazione BizTalk ESB è una specifica implementazione di una porta di ricezione; un sottoinsieme; un caso privato. utilizza una porta di ricezione per implementare un modello dal mondo ESB; così - non sono differenti per-sé

.

Itinerari - ancora una volta - sono d'accordo sia con Neal e Riri e aggiungerei, in risposta alla sua domanda - il BizTalk ESB può utilizzare itinerari in modi diversi - un client 'clued-up' in grado di fornire la richiesto itinerario con il messaggio di richiesta; un client meno clued-up può semplicemente consegnare un messaggio, e l'infrastruttura ESB (o meglio - l'implementazione di esso) potrebbe risolvere il percorso relativo per la richiesta specifica (questo può essere fatto utilizzando resolver, out-of-the-box o personalizzato, che avrebbe utilizzato diversi metodi per decidere quale itinerario è necessario). Teoricamente i due possono anche essere combinati in cui il client fornisce un percorso ma l'ESB rampa sostituisce / modifica.

Per la questione generale, da quello che mi ricordo, sì, tutti i messaggi vengono in corso attraverso la finestra di messaggio. Ma io sono stato utilizzando BizTalk 2006 R2. Guardate la foto qui .

Per gli altri due domanda, non ho mai completamente capito io. Non ho il tempo di indagare in questo momento, ma io probabilmente farlo se nessuno ci illumini:)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top