In che modo gli strumenti del flusso di lavoro (jBPM) mantengono lo stato delle transazioni coerente?

1

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?

È:

  1. 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?

  2. 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.

  3. 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?

    
posta user2800708 18.05.2015 - 11:13
fonte

1 risposta

1

Non essendo un ragazzo Java, la mia risposta potrebbe essere deludente.

"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"

Penso che la parola "in generale" sia la chiave qui. La decisione sulla collocazione di un riferimento o dell'intero articolo dovrebbe essere caso per caso. Se l'oggetto è costante tra le istanze del flusso di lavoro e il flusso di lavoro deve sapere quando cambia, non collocarlo nel flusso di lavoro. Usa invece un riferimento. È più facile che creare un meccanismo per notificare le istanze al di sotto del cambiamento. I dati del registro sono il mio primo esempio.

Anche la modalità di aggiornamento del database dall'istanza del flusso di lavoro è una decisione caso per caso. Alcuni aggiornamenti dovrebbero essere atomici (i flussi di lavoro non dovrebbero poter continuare ad ordinare l'adempimento se la transazione del database che aggiorna il saldo del cliente fallisce). Anche se non in una transazione, il flusso di lavoro può essere modellato attorno ad esso.

Altre volte il flusso di lavoro può continuare anche se il database non si aggiorna con un semplice avviso all'utente ("Non siamo stati in grado di aggiornare il tuo indirizzo nel nostro registro in questo momento, ma il tuo ordine verrà consegnato al nuovo indirizzo") . Puoi anche accodare l'aggiornamento.

Quindi, usa le transazioni quando è necessario, fallisci con garbo quando è necessario e accoda le cose che non sono sensibili al fattore tempo.

Nessun proiettile d'argento. Siamo spiacenti.

    
risposta data 20.05.2015 - 14:31
fonte

Leggi altre domande sui tag