Le macchine statiche di Windows Workflow Foundation sono adatte per scenari ad alte prestazioni?

Question

Attualmente mi occupo di un sistema in cui devo tenere traccia dello stato di diverse migliaia di oggetti in parallelo che inviano possibili aggiornamenti di stato un paio di volte al minuto. Inoltre devo eseguire calcoli aggiuntivi (niente cose IO lento, solo usando la CPU).

Attualmente utilizzo un'implementazione di macchina di stato personalizzata. tuttavia, poiché WF viene utilizzato all'interno di altre parti del sistema, mi chiedo se la macchina WF di stato potrebbe essere adatta a uno scenario di questo tipo con una manciata di stati (<).

Temo che il sovraccarico potrebbe essere troppo grande quando si tratta di prestazioni. Poiché la documentazione MS non copre argomenti relativi alle prestazioni delle macchine a stato WF, mi chiedo se qualche membro SO abbia alcune informazioni o risorse che registano le prestazioni delle macchine a stato WF?

saluti j.

Answer 1

macchine statali sono l'ideale per un sistema ad alte prestazioni. Se hai davvero bisogno di prestazioni molto elevate usando la base del flusso di lavoro, aggiungi un sacco di complessità e sovraccarico. Ho trovato biztalk essere totalmente inadatto per prestazioni molto elevate.

Answer 2

Microsoft sta attualmente utilizzando WF nei propri prodotti server e lo stanno espandendo. Ad esempio, il motore WF può essere trovato in Share Point Server (MOSS) e in BizTalk Server. Entrambe le scale si adattano abbastanza bene e consentono di scalare gli scenari, ad esempio aggiungendo altro hardware (economico) in un cluster con bilanciamento del carico, se è necessaria una maggiore potenza di calcolo.

HTH, Thomas

Answer 3

Questo non parla direttamente alle prestazioni, ma se si prevede di passare a WF 4.0 si dovrebbe essere consapevoli del fatto che StateMachineActivity probabilmente won't be making the cut.

Answer 4

Se si sta cercando una macchina a stato ad alte prestazioni basata su. NET, suggerirei Stateless. Ecco un estratto dal sito del progetto: sono supportati

La maggior parte dei costrutti macchina a stati di serie:

• supporto generico per gli stati e trigger di qualsiasi tipo .NET (numeri, stringhe , enumerazioni, ecc)
• stati gerarchici entrata/uscita eventi per gli Stati
• clausole della Guardia di sostegno condizionato transizioni
• Introspezione

Alcune utili estensioni sono forniti anche:

• Possibilità di memorizzare lo stato esternamente (ad esempio, in una proprietà rilevata da da Linq a SQL)
• parametrizzato innesca
• stati rientrante

configurazione è la seguente:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook); 

phoneCall.Configure(State.OffHook) 
    .Permit(Trigger.CallDialed, State.Ringing); 

phoneCall.Configure(State.Ringing) 
    .Permit(Trigger.HungUp, State.OffHook) 
    .Permit(Trigger.CallConnected, State.Connected); 

phoneCall.Configure(State.Connected) 
    .OnEntry(() => StartCallTimer()) 
    .OnExit(() => StopCallTimer()) 
    .Permit(Trigger.LeftMessage, State.OffHook) 
    .Permit(Trigger.HungUp, State.OffHook) 
    .Permit(Trigger.PlacedOnHold, State.OnHold); 

// ... 

phoneCall.Fire(Trigger.CallDialled); 
Assert.AreEqual(State.Ringing, phoneCall.State); 

E la cosa bella è che dal momento che implementa Generics, è possibile utilizzare int o una stringa per rappresentare gli stati e trigger, che consente di integrarsi molto facilmente con il database o l'ORM. Il bello è che non vi è alcun host di runtime aggiuntivo di cui preoccuparsi, basta caricare la macchina a stati con lo stato corrente di un oggetto o di un record e si è pronti per partire.