Dove si inserisce Windows Workflow Foundation nell'architettura middleware orientata alla messaggistica?

Ho dovuto usare WF prima in uno scenario di integrazione basato su un sistema di messaggistica Pub-Sub ... e abbiamo scoperto che usare WF era un rompicapo.

In primo luogo, è imbarazzante codificarci. All'inizio sarai tentato di codificare tutta la tua logica con le attività nel Designer, ma questa è una cosa molto brutta. Anche le cose semplici come l'istanziazione degli oggetti si trasformano in un pasticcio di attività di impostazione del valore, o sono difficili da seguire perché sono tutte nascoste all'interno dei valori predefiniti delle dichiarazioni delle variabili.

In secondo luogo, è terribile fare il debug con dio. Anche se sei abbastanza fortunato perché la tua stazione di lavoro sia una delle poche selezionate in cui il debugger in realtà sceglie di svegliarsi, ascoltare e fare il lavoro, allora preparati comunque a una terribile esperienza di debug. Il debugger si separa da processi apparentemente casuali e in realtà non fornisce informazioni di valore in alcun modo. Mi sarei aspettato che il debugger mi mostrasse le eccezioni quando venivano lanciate, ma non così sfortunatamente. Preparati a cospargere i blocchi catch con punti di rottura.

Se più sviluppatori avranno intenzione di lavorare sugli stessi flussi di lavoro, allora sarà difficile unire le modifiche. Questo perché i flussi di lavoro sono XML. Questo non sarebbe male se non fosse anche per il fatto che lo stato visivo del Designer WF è effettivamente memorizzato all'interno dello stesso XML. Certo, hanno finalmente spostato le informazioni sullo stato visivo in un blocco di testo contiguo (invece di decorare il 60% di tutti gli elementi XML), ma è comunque un rompicoglioni. Significa che ogni volta che espandi o comprimi un'attività il tuo file cambia. Il che significa che dovrai impegnare un lotto di modifiche inutili ... e poi rimarrai bloccato a navigare in seguito.

L'unica cosa che riesco a vedere WF è un flusso di lavoro di lunga durata.

NON come tecnologia per la creazione di un bus dei messaggi.

WF (Microsoft non lo chiama WWF per evitare battaglie con l'organizzazione di wrestling e il conservatorio) offre sia la pausa che il curriculum e offre anche l'orchestrazione delle attività.

Se un ESB può distribuire messaggi e un flusso di lavoro no, un flusso di lavoro ordina che la sequenza si verifichi.

I webhook sono nuovi per me ma sembra ancora che si tratti di distribuire messaggi. WF verrebbe utilizzato per creare un contesto di Attività avviato - > Chiama il Metodo 1 (il metodo mette un messaggio specifico in coda), chiama il Metodo # 2 (il metodo fa qualcosa), Sospendi fino a ..., Chiama il Metodo # 3 (il metodo legge dalla coda), ecc. Fino a quando il tuo contesto non è completo.

L'utilizzo della WF per sostituire le funzioni di scrittura è solo doloroso come MetaFight ha affermato in modo eloquente. Il suo scopo principale è fornire un contesto all'esecuzione di > 1 operazione. È in grado di organizzare operazioni in una GUI che può essere un valido strumento di visualizzazione del processo e fornisce le attività di sospensione / risveglio / compensazione per processi a lungo termine e fault-tolerant.

Ad esempio, e sto selezionando un breve processo qui piuttosto che uno lungo:

Il contesto è, l'utente accede

1. Scrivi il registro di controllo nel database tramite AuditOperation ();
2. Metti il messaggio in coda per informare gli amici che hanno effettuato l'accesso
3. Reindirizza l'utente alla pagina del profilo

L'esecuzione di ciascuna di queste operazioni non ha nulla a che fare con l'altra, ma la somma delle loro parti sta completando lo scenario. Per ulteriori informazioni, vorrei verificare Data-Context-Interaction ( link )