BizTalk 2009 ESB Confusion

Question

Ho una piccola 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é hai bisogno di itinerari, non puoi semplicemente creare lo stesso utilizzando le porte e le orchestrazioni? Mi manca ovviamente qualcosa qui.

Un paio di questioni più generali:

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

Grazie in anticipo per eventuali approfondimenti.

Answer 1

on-rampe

L'on-rampe sono servizio web basato ricevere porta, ma sono un po 'diverso in quanto accetta messaggi XML generici. I messaggi avranno comunque un'intestazione SOAP molto speciale (una "busta" se lo si desidera) con tutte le proprietà necessarie per rendere possibile, ad esempio, l'itinerario dei messaggi. Troverai tutte le intestazioni possibili guardando in "EsbEnvGeneric.xsd"

itinerari

mi piace NealWalter rispondere sulla via. Tuttavia, vorrei solo aggiungere il messaggio che l'approccio dell'itinerario può potenzialmente salvare un sacco di tempo e lo sforzo di sviluppo. Può rendere le organizzazioni più agili e facilitare i cambiamenti nei loro processi. Se non dobbiamo sviluppare e distribuire un'intera nuova orchestrazione, cambiamo solo alcune configurazioni e usiamo i nostri bit esistenti che ovviamente possono risparmiare un sacco di tempo. E questo è il grande valore in un ESB e itinerario di messaggi come lo vedo io.

Message Box

messaggi in BizTalk devono sempre passare attraverso la finestra di messaggio. Nella prossima versione, MS ha suggerito uno scenario a bassa latenza in BizTalk - forse allora potremo ottenere un controllo un po 'maggiore, ma più ma per ora i messaggi vengono persi molte volte mentre si trovano in BizTalk e non c'è niente a riguardo.

Answer 2

Per la domanda generale, da quello che ricordo, sì, tutti i messaggi stanno passando attraverso la finestra di messaggio. Ma ho usato BizTalk 2006 R2. Guarda l'immagine here.

Per le altre due domande, non l'ho mai capito da solo. Non ho il tempo di indagare in questo momento, ma io probabilmente farlo se nessuno ci illumini :)

Answer 3

sto solo affrontando solo la tua seconda domanda:

2) Perché hai bisogno di itinerari, puoi non creare semplicemente la stessa usando le porte e le orchestrazioni ? Sono ovviamente manca qualcosa qui.

All'ultimo posto in cui ho lavorato, abbiamo lavorato al nostro ESB per circa un anno. L'idea di itenary è che quando un messaggio entra nell'ESB, dovrebbe magicamente andare nella giusta sequenza verso i sistemi appropriati.

Con un sistema Business Process Oriented (BPM), in genere si scrive un'orchestrazione per indirizzare il flusso della logica. In altre parole, si codifica l'itinerario o il percorso del messaggio nell'orchestrazione. Nell'ESB che abbiamo costruito, le regole aziendali hanno deciso dove andrebbe il messaggio. Avevamo ancora le orchestrazioni per gli end-point, ma in genere erano brevi e solo la mappatura e alcune funzionalità di base. In altri posti in cui ho lavorato, le orchestrazioni possono essere abbastanza grandi.

Quindi le regole di cosa fare con il messaggio devono essere da qualche parte. Nell'ESB, ogni punto finale dovrebbe essere totalmente agnostico e inconsapevole degli altri punti finali. Il campo ESB presume che il sistema debba cambiare in modo più dinamico senza dover ridistribuire il software (ad es. Orchestrazioni). Quindi, con il nostro ESB, puoi semplicemente modificare le regole aziendali e ridistribuirle.

Alcuni dei problemi più difficili con un ESB sono le transazioni, il rollback e in genere la creazione di un processo comune di gestione degli errori.

Neal Walters http://BizTalk-Training.com

Answer 4

Un paio di ulteriori vedute -

porte di ricezione/on-rampe - completamente d'accordo con la risposta di Riri e sarebbe sufficiente aggiungere - una rampa nel contesto di un'applicazione BizTalk ESB è una specifica implementazione di un porto di ricezione; un sottoinsieme; un caso privato. utilizza una porta di ricezione per implementare un modello dal mondo ESB; quindi - non sono diversi per-se.

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 il percorso richiesto con il messaggio di richiesta; un cliente meno esperto può semplicemente consegnare un messaggio e l'infrastruttura ESB (o meglio la sua implementazione) potrebbe risolvere l'itinerario rilevante per la richiesta specifica (questo può essere fatto usando resolver, out-of-the-box o personalizzato, che userebbe diversi metodi per decidere quale itinerario è necessario). In teoria i due possono anche essere combinati dove il cliente fornisce un itinerario, ma la rampa di accesso ESB lo sostituisce/cambia.