Paul Andrew e Matt Winkler - Q&A Session
Ho fatto anche io la mia domanda :-D
- best practice to impletment "go-to", mutuata da un po' di elucubrazioni con Raffaele
Sulla lavagna per ora ci sono un sacco di domande la cosa si fa interessante...
Hosting designers vs building your own designer
Suggeriscono di costruire il ptoptio deisgner piuttosto che ostare quello fornito perchè è dev oriented e non end user oriented
XAML vs Code Behind
Se l'uso del solo XAML permette di persistere lo schema del workflow pressochè ovunque e di conseguenza di modificarlo molto facilmente non ci permette facilmente di benificiare di tutti i vantaggi del code behind uno su tutti le CodeActivity o le Custome Properties all'interno del Workflow
Migrating from exixting formats
Nulla di più semplice, si fa per dire. C'è la possibiolità di pluggare un proprio Loader per eseguire il parsing del proprio formato e costruire l'albero delle Activity
Dynamic updating existing and running Workflows
Sembra la cosa più facile di questa terra... ma non è proprio così comunque l'unico requisito è che il Workflow sia un "suspend state", c'è anche la possibilità di modificare via CodeDom del codice all'interno ad esempio di una CodeActivity... una nota importante è che le performance NON ci sono proprio, ma del resto stiamo facendo qualcosa di decisamente "tosto" ;-)
Custom Persistance Provider Service
Semplicemente suggeriscono di guardare gli esempi presenti nel Windows SDK
Scalbility with 100k instances running
Non è un problema perchè ci basta implementare una buona politica di persistenza quando il WF è on "idle state", il problema si pone se fossero tutti running ma comunque ci penserebbe il ThreadPool ad acccodarli in modo da non satuirare le risorse.
Se parliamo invece di scalabilità la cosa si fa un po' più tosta ma il problema si sposta sulla gestione dei messaggi in ingresso, è quindi possibile ad esempio avere un Front-End che fa poi dispatch dei messaggi in ingresso verso una batteria di server in load balancing che accedono tutti ad un Cluster di Sql Server per lostaorage implementando un proprio meccanismo di locking per controllare la concorrenza sugli eventualei WF running...
Compensation
Bell'esempio su come implementare ICompasatableActivity in una proprio Custom Activity per gestire il roolback in uno scerario si transazionale ma non basato su locking come invece è una transazione tradizionale
Go-To
Ritengono che la soluzione migliore sia quella di implemenatere un proprio tipo di WorkFlow, anche se una soluzione c'è usando uno "State Machine Workflow" che comunque non è la soluzione definitiva, all'interno del proprio tipo implementare delle Custom Activity che consentano di "saltare indietro" verso uno step precedente, certo che non è proprio una cosa banale ;-)
Molto ma molto interessante, bella questa sessione, è proprio un bel format.
.m