Allora....oggi ne discutevo con William sul messenger e la cosa sembra essere decisamente complessa. Alla base c'è un ragionamento (grazie Wil per il chiarimento) relativo allo scheduler. In sostanza, guardando come è ralizzato il runtime, il responsabile dell'esecuzione del workflow è lo scheduler. Demandare la gestione dei thread alle activity potrebbe essere controproducente (ammesso che si riesca a fare al 100%).
Ma allora come fare a realizzare un reale parallelismo? Dunque....la strada dell'invoke workflow potrebbe essere una. In effetti, come mi faceva notare Wil stamattina, l'invoke workflow non fa altro che richiamare il metodo StartWorkflow e poi uscire (codice tratto da reflector):
....
Guid guid1 = workflow1.StartWorkflow(this.TargetWorkflow, dictionary1);
if (guid1 == Guid.Empty)
{
throw new InvalidOperationException(SR.GetString("Error_FailedToStartTheWorkflow"));
}
this.SetInstanceId(guid1);
return ActivityExecutionStatus.Closed;
}
In effetti, come puoi facilmente accorgerti facendo qualche test, una volta invocato il workflow "annidato" (eseguito in un thread diverso), l'activity si conclude ed il workflow ospite viene eseguito.
Per fare un parallelismo, dovresti:
- creare la parallel activity
- in ogni ramo usare l'invoke workflow
- sospendere il workflow "padre" in ogni ramo in attesa che i workflow child vengano eseguiti
- gestire la fine dell'esecuzione dei workflow "figli" (e qui potrebbero nascere problemi con le eccezioni, esecuzioni lunghe, tracking, eventuale persistenza etc)
- in ogni ramo, continuare l'esecuzione quando i wf child hanno finito
Tale metodologia, su 2 piedi (e a quest'ora 
) non mi sembra riutilizzabile. Ti toccherebbe rifartela ogni volta che hai l'esigenza.
L'altra strada, quella architetturalmente più elegante, sarebbe quella di creare una custom activity ma ci si scontra sempre con il vincolo che le activity non dovrebbero governare i thread.
Insomma....se non s'è capito, la cosa non è delle più semplici e bisogna capire se davvero ne vale la pena.
WF è davvero un ottimo strumento ma immagino che in determinati scenari, l'uso di BizTalk sia ancora da preferire.
Comunque ci ragioniamo....perchè il problema è stimolante.
Per curiosità, potresti postare lo schema del tuo wf in modo da capire come è strutturato? (sempre se non è un problema).
In ultimo, da uno sguardo qui: http://blogs.msdn.com/advancedworkflow/archive/2006/02/23/538160.aspx Da qualche spiegazione in più circa la parallel ed il threading.
Il succo è: a prescindere dal fatto che si possa fare o meno, ha davvero senso farlo?