Sto esaminando specificamente jBPM, ma penso che questo si applichi anche ad altri sistemi.
A quanto ho capito ..
Quando si posiziona un oggetto in un flusso di lavoro, generalmente non si mette un riferimento a quell'elemento, si mette l'intero articolo o documento serializzato nel flusso di lavoro. Ciò significa che lo stato del flusso di lavoro e l'oggetto in corso di flusso di lavoro possono essere tutti tenuti nel database dei sistemi di flusso di lavoro, rendendo più semplice la creazione di aggiornamenti atomici.
Alla fine di un flusso di lavoro, o talvolta in passaggi espliciti lungo il percorso, è possibile effettuare chiamate ai servizi downstream e questi possono apportare modifiche allo stato dei loro database. Come si gestisce questo?
È:
-
Il flusso di lavoro e i servizi dovrebbero essere distribuiti in un unico contenitore del server delle applicazioni e un gestore delle transazioni utilizzato per mantenere tutto coerente?
-
Si chiama un servizio, quindi lo stato del flusso di lavoro viene aggiornato, ma non in una transazione. Il fallimento e il riavvio del flusso di lavoro possono causare chiamate duplicate, se l'aggiornamento dello stato non è riuscito.
-
Li disaccoppia utilizzando una coda JMS transazionale. Quindi i sistemi downstream possono leggere da quella coda nella propria transazione. Gli aggiornamenti avvengono a livello transazionale e nell'ordine corretto.
O qualcos'altro, o qualsiasi combinazione di quanto sopra che ti piace.
Dovrei aggiungere, dove lavoro abbiamo i micro-servizi (qualunque cosa significhi). Significa che non abbiamo un server delle applicazioni, quindi le transazioni globali tra gli endpoint del servizio non sono possibili (no ws-tx, i servizi sono REST / json). La soluzione JMS è l'unica che è aperta a noi?