Domanda

Sto valutando WF per l'utilizzo in linea di applicazioni aziendali sul Web e mi piacerebbe ascoltare alcuni recenti racconti di prima mano su questa tecnologia.

Il mio interesse principale qui è nel migliorare la manutenibilità dei progetti e forse nell'aumentare la produttività degli sviluppatori quando si lavora su processi complessi che cambiano frequentemente.

Mi piace molto l'idea di WF, tuttavia sembra essere relativamente sconosciuta e molti commenti più vecchi mi sono imbattuto menzionando che è estremamente complesso una volta che ci entri.

Se è sovrastampato al punto da essere inutilizzabile (o un cattivo compromesso) per un progetto di piccole e medie dimensioni, è qualcosa che devo sapere.

Naturalmente, è uscito dalla fine del 2006, quindi forse è maturato. In tal caso, è un'altra informazione che sarebbe molto utile!

Grazie in anticipo!

È stato utile?

Soluzione

Windows Workflow Foundation è un prodotto molto capace ma ancora nella sua prima versione :-(

I motivi principali per l'uso includono:

  1. Modellazione visiva dei requisiti aziendali.
  2. Separazione della logica aziendale dalle regole aziendali ed esternalizzazione delle regole come file XML.
  3. Separando il flusso aziendale dall'applicazione esternalizzando i flussi di lavoro come file XML.
  4. Creazione di processi a esecuzione prolungata con la capacità automatica di reagire se non è successo nulla per un lungo periodo di tempo. Ad esempio, una fattura non viene pagata.
  5. Persistenza automatica di flussi di lavoro a esecuzione prolungata per limitare l'utilizzo delle risorse e consentire il riavvio di un processo e / o una macchina.
  6. Tracciamento automatico dei flussi di lavoro che aiuta a soddisfare i requisiti aziendali.

WF viene fornito come libreria / framework, quindi la maggior parte delle volte è necessario scrivere l'host che crea un'istanza del runtime WF. Detto questo, l'utilizzo di WCF ospitato in IIS è una soluzione praticabile e consente di risparmiare molto lavoro. Tuttavia, l'accoppiamento WCF / WF è tutt'altro che perfetto e richiede un lavoro serio. Vedi qui http : //msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx per maggiori dettagli. Aspettatevi alcune modifiche / miglioramenti nella prossima versione.

WF (e WCF) sono piuttosto centrali per molte delle nuove cose che escono da Microsoft. Puoi aspettarti alcuni annunci interessanti durante il PDC.

A proposito, mantenere in esecuzione più versioni di un flusso di lavoro richiede un po 'di lavoro, ma si tratta principalmente di .NET standard. Ho appena pubblicato una serie di post di blog sull'argomento a partire da qui: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

Informazioni sulla modellazione visiva dei requisiti aziendali. In teoria questo funziona abbastanza bene con una separazione di intenti e implementazione. Tuttavia, in pratica, lascerai cadere alcune attività extra su un flusso di lavoro puramente per motivi tecnici e quel tipo di sconfigge lo scopo poiché devi dire a un analista aziendale di ignorare metà delle forme e delle linee.

Altri suggerimenti

Domanda correlata: Quando utilizzare Windows Workflow Foundation? La mia risposta :

  

Potresti aver bisogno di WF solo se uno dei   quanto segue è vero:

     
      
  1. Hai un processo di lunga durata.
  2.   
  3. Hai un processo che cambia frequentemente.
  4.   
  5. Volete un modello visivo del processo.
  6.   
     

Per maggiori dettagli, vedi Paul Andrew's   post: Cosa utilizzare Windows Workflow Foundation per ?

     

Non confondere o riferire WF   con programmazione visiva di qualsiasi tipo.   È sbagliato e può portare a molto male   decisioni di architettura / design.

Quindi, se hai tali requisiti, allora WF è un buon candidato. Ovviamente è relativamente complesso, ma menziona che anche i problemi che sta cercando di risolvere sono complessi (e talvolta molto complessi). IMHO, ad esempio, è molto complesso disidratare / reidratare oggetti a cui sono associati gestori di eventi (con eventi che possono essere attivati ??quando l'oggetto non è in memoria).

Non posso giudicare cosa intendi per "progetto di piccole e medie dimensioni", ma in generale direi che se il tuo progetto ha almeno due requisiti dall'elenco sopra, puoi considerare WF come una soluzione.

Abbiamo usato WF in un'applicazione SharePoint di grandi dimensioni e posso dire che è OK. Ha molta potenza e flessibilità. e, come menziona Kevin, una volta che hai capito i concetti alla base dei flussi di lavoro, puoi fare praticamente tutto ciò che vuoi con esso.

D'altra parte, ha alcuni problemi molto seri, come la mancanza di controllo delle versioni, che può davvero danneggiare l'applicazione in futuro. Siamo stati costretti a distribuire fino a 3 versioni parallele dello stesso flusso di lavoro denominato xxx-v1, xxx-v2 e xxx-v3 per mantenere attive le istanze meno recenti e fare in modo che le nuove istanze utilizzino le versioni aggiornate. Un vero dolore nel culo. Oh, e ci sono anche alcuni concetti davvero non intuitivi (token di correlazione, wtf ??)

Avevamo al lavoro un progetto in cui ero coinvolto nell'uso dei flussi di lavoro. L'idea (dalla direzione) era che noi programmatori avremmo scritto le attività del flusso di lavoro insieme al "motore" e quadro. Quindi i non programmatori si occuperebbero di tutto il resto compilando i propri flussi di lavoro in DLL che il motore carica automaticamente.

La gestione è stata venduta su questa idea di non programmatori che utilizzavano Workflow per aiutare a sviluppare software ed era praticamente una completa perdita di tempo. Il problema che stavamo cercando di risolvere con questo progetto era relativamente complesso e sapevamo fin dall'inizio che il software avrebbe dovuto essere modificato quasi costantemente (i suoi calcoli dipendevano da altre società e governi).

Il risultato finale è stato che non siamo riusciti a rendere i moduli del flusso di lavoro abbastanza generici per essere utilizzati da chiunque altro. Quindi i programmatori sono stati quelli che sono stati costretti a lavorare con i flussi di lavoro, e tutto ciò che ha fatto è stato ostacolarli.

Ho usato Workflow 4.0 negli ultimi mesi e sebbene per lo più colpito, ho trovato estremamente difficile da imparare.

Per la versione più recente (fornita con .NET 4.0 RC), non c'è quasi nessuna documentazione sul web, in nessun libro o nessun corso di formazione disponibile. Ho trovato solo articoli relativi alla versione 3.0 ormai defunta. Anche la documentazione su MSDN è leggera sul terreno.

Il progettista del flusso di lavoro non è così intuitivo come dovrebbe essere, quindi l'apprendimento è molto difficile. Ho dovuto fare affidamento sulle risposte di una sola persona su StackOverflow (grazie a proposito Maurice!) - e sarei stato riempito senza il suo aiuto.

Quindi, in sintesi, penso che abbia un potenziale, ma saresti abbastanza pazzo per impararlo ancora - attendi più formazione, documentazione e libri, altrimenti ti caccerai al buio!

L'anno scorso abbiamo completato un'applicazione funzionante con WF, ora utilizzata come spina dorsale di un sistema incredibilmente enorme che viene utilizzato da una banca molto grande per il suo processo ipotecario. Il processo pe ha molti passaggi che vanno dall'applicazione del cliente all'approvazione del credito.

Sebbene sia stato un successo, ci sono stati così tanti problemi e crisi lungo tutto il percorso. E non ne vale la pena per progetti di dimensioni minori.

Considero MS WF come una libreria di flusso di lavoro di basso livello piuttosto che un prodotto di flusso di lavoro aziendale completo come K2. Ti consentirà di creare un'applicazione abilitata per il flusso di lavoro, ma non è di per sé un'applicazione per il flusso di lavoro. La mia esperienza in questa capacità è stata positiva, anche se abbiamo dovuto costruire molta della nostra propria infrastruttura attorno ad essa (un pub / sottostruttura, un gestore della vita di worlkflow ecc.). Gran parte della documentazione disponibile è abbastanza semplicistica e non copre la creazione di un'applicazione per il flusso di lavoro aziendale basata su MS WF.

Difficile da imparare. Abbastanza flessibile Da non confondere con uno strumento visivo per gli utenti finali, solo per i programmatori. Non sono sicuro se mi piace l'approccio della proprietà di dipendenza.

Dipende davvero da cosa vuoi farci. L'ho usato solo un po ', ma rispetto a prodotti più maturi come MetaStorm (so che tecnicamente è un BPM, ma c'è ancora un componente del flusso di lavoro), Process Choriographer e IBM MQ workflow, non c'è paragone. Non è abbastanza maturo. D'altra parte è gratuito dove gli altri non lo sono e probabilmente può fare il lavoro. Non so se ci piazzerei un'operazione da molti milioni di dollari, ma con quelli più piccoli, ci darei un altro tentativo. Il vero ostacolo che dovrai affrontare è il cambiamento nel processo di pensiero che richiede. Se non hai sviluppatori che hanno lavorato con sistemi statali prima, questo può essere un vero ostacolo.

Brian, non posso rispondere al tuo commento, ma comunque, per controllo delle versioni intendo apportare modifiche al codice sottostante del flusso di lavoro senza interrompere le istanze già in esecuzione e applicare con garbo gli aggiornamenti ai flussi di lavoro esistenti. Non sono sicuro del WF "stock", ma almeno in ambiente SharePoint non esiste il concetto di versioni del flusso di lavoro, quindi le nuove versioni devono essere distribuite come flussi di lavoro completamente diversi che diventano un incubo per la manutenzione. Questo non ha nulla a che fare con la "reidratazione", la reidratazione è il processo mediante il quale si riporta un flusso di lavoro "dormiente" all'attività dopo un evento o un cambiamento di stato. Questo viene gestito in modo trasparente dal runtime del flusso di lavoro.

WF è integrato in SharePoint (WSS 3.0) e ho creato diversi flussi di lavoro per vari siti Web di SharePoint, quindi posso raccontare la mia esperienza di WF in SharePoint. Rispetto ad altri framework di flusso di lavoro, WF ottiene buoni risultati. È stabile (non ho riscontrato alcun errore misterioso), i flussi di lavoro sono abbastanza facili da progettare (grazie al progettista del flusso di lavoro in Visual Studio) e puoi utilizzare non solo flussi di lavoro sequenziali ma anche con macchine a stati.

Non è perfetto, ovviamente, e uno sviluppatore avrà sicuramente bisogno di un po 'di tempo per capire il concetto (ovvero il Modello di attività); ma è sicuramente utilizzabile, anche per "piccoli compiti".

Non ho mai provato WFF, ma ricordo di aver letto questo articolo su WFF di Leon Bambrick dove in sostanza dice che l'intero genere di strumenti di sviluppo software non ha senso. Potrebbe aiutarti a decidere in un modo o nell'altro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top