Suggerisci una strategia persistente per un sistema di workflow

Question

Io sono nel processo di creazione di uno strumento di configurazione di interfaccia utente per il mio progetto pet. Un aspetto di questo strumento permette all'utente finale definire la sua orchestrazione. Ho quindi bisogno di salvare questa definizione di orchestrazione in un database. Ci sarà una versione eseguibile di questa definizione in un sistema in esecuzione. La versione eseguibile viene creato in modo dinamico on-demand.

L'idea è di separare il DEFINIZIONE EXECUTABLE versione in modo da avere la flessibilità di scegliere la versione di runtime tra BPMN o JPDL o una soluzione POJO flusso di lavoro basato (BeanFlow) .

Limitazione :. Non posso usare gli editor BPMN che vengono con framework come jBPM, Activiti ecc come ho wan't di utilizzare la mia interfaccia utente che è specifico per il mio dominio

Ho bisogno di suggerimenti su come rendere persistente la definizione.

1. Devo usare RDBMS tabelle? Se è così, c'è uno schema db posso prendere in prestito che è vicino ai concetti di orchestrazione?

2. Dovrei serializzare la mia definizione di BPMN / JPDL documento di istanza XML?

3. Ci sono altri formati semplici che posso utilizzare?

Answer 1

Con il termine "orchestrazione" Sto assumendo si intende un Finite State Machine . Dove i dettami stato attuale ciò transizioni possono essere seguite per altri stati. La rappresentazione di stati e transizioni come spigoli e vertici spesso produce una diretto aciclico grafico , tuttavia ci sono momenti quando il ciclo grafico di volontà (ad esempio progetto - sottoporre per l'approvazione -> in attesa di approvazione - respingere -> progetto).

In pratica, separando la definizione di chiamate di esecuzione per un formato di persistenza che può facilmente ospitare personalizzazione. Man mano che le si evolve di sistema si trova un certo numero di casi limite imprevisti la cui soluzione non dovrebbe richiedere la modifica di uno schema di persistenza, solo il codice. Ciò implica XML o una soluzione NoSQL - qualcosa di cui schema è facilmente cambiata o inesistente.

Ora, avendo scritto la mia definizione XML per questo scopo (per ragioni poco interessanti io escludo), il mio suggerimento sta usando JPDL (o BPMN). La ragione è probabile che le loro definizioni incorporano tutto ciò si sta valutando ora, sarà in futuro, e consentono la personalizzazione - quali appendere dati o comportamenti arbitrari fuori di loro in un determinato punto. Si ottiene anche il vantaggio di strumenti già costruito - non solo UI -. Per trattare con il rilevamento di ciclo e garantire c'è un percorso per il completamento ad esempio

Alcuni dei interessante, presenta lo so JPDL possiede sono una capacità di aiutare unione biforcuta processi, cronometrato attività (compresi quelli che si ripetono periodicamente), e le strutture per l'invio di notifica. Questo ultimo elemento - Notifica - porta qualche ulteriore esposizione. Una delle cose che ho trovato con il mio sistema è la necessità per l'invio di e-mail il cui contenuto è configurabile sulla base dei dati che fluiscono attraverso. Questi motori esistenti fanno si che relativamente semplice, fornendo un modo per plug-in variabili, per esempio in testo che viene poi valutata in modo dinamico in fase di esecuzione prima della trasmissione. Inoltre forniscono un ponte tra l'archivio utente del motore e tutto ciò per fini di invio di notifiche a gruppi di persone, li tasking e l'applicazione di policy di sicurezza.

Infine, a seconda della portata del vostro sistema, sarà probabilmente ancora utilizzando un database pure. Quello che suggerisco è la memorizzazione fuori dal XML e dati che vengono orchestrato nel database in un formato serializzato. Poi, se i dati vengono modificati mentre viaggia attraverso l'esecuzione, scrivere serializzazioni dei dati - e, forse, il flusso di lavoro se è cambiato anche -. In una tabella registro cronologico / audit nonché

Answer 2

non voglio usare RDBMS tavoli, o se lo fai, memorizzare le definizioni come BLOB di testo. Cercando di fare dischi per la definizione è una cattiva idea, perché è molto più inflessibile e difficile da cambiare la sua definizione nel corso del tempo. Molte persone avrebbero usato diversi approcci, ma mi piacerebbe utilizzare JSON o YAML, e XML evitano. La motivazione di ciò è di rendere il più semplice possibile. Cercando di utilizzare XML, in particolare di un formato specifico formalizzata di XML sta per farvi trascorrere molto più tempo soddisfare una specifica precisa che in realtà non fare nulla per aiutare ciò che si sta cercando di realizzare. JSON e YAML sono entrambi molto facile da lavorare da una prospettiva codice. YAML è più facilmente leggibile dagli esseri umani e più facili da modificare e non è così difficile per la punteggiatura e fuggire come JSON. JSON è più ampiamente utilizzato, ed è più piccolo di YAML. JSON ha anche una controparte binario, BSON, se la dimensione del documento è una preoccupazione.

Una volta che avete un importatore / esportatore che va da / per gli oggetti interni al formato dei dati, quindi persistente con RDBMS, o di altri meccanismi, sarà semplice. Si potrebbe anche usare CouchDB, che potrebbe offrire altri vantaggi per la vostra applicazione e può essere una grande misura.

Answer 3

Molto bella domanda! Ecco i miei due centesimi:

1. RDBMS :? Se fate questo sarete in grado di interrogare le istanze del flusso di lavoro, ad esempio, che i token sono a 'nodo X'
2. Memorizzazione XML come CLOB: la semplicità è la verità di questa soluzione, ma non si può davvero interrogare questi solo farli da id
3. nosql : ci sono un sacco di soluzioni diverse per problemi diversi. MongoDB è una soluzione popolare, fornisce documenti persistenza oriented.

Answer 4

Che ne dite di una semplice serializzazione del composto UI utilizzando, ad esempio xstream e quindi memorizzare i bit serializzato nel database come una colonna binaria. Poi, quando utente si collega, ottenere i dati associati, deserialise, inizializzazione se necessario e la visualizzazione.