Abstract:
Paul is the Product Manager and Matt is the Technical Evangelist for Windows Workflow Foundation. They are both experienced at consulting with customers on projects and would like to invite you to share your project ideas at this whiteboard session. Potential software architecture using Windows Workflow Foundation will be discussed with the audience.
Ich bin gespannt an diese Session gegangen, es nimmt mich ja Wunder, wie oder was für eine Diskussion da aufkommen wird.
Es wird die Frage nach Designer gestellt. Er zeigt einen Interessanten Workflow Manager, (Link weiter unten)wo ich jede WF Instanz öffnen kann und im Designer sehe, wo mein Workflow steht und wer bei welchem Step was gemacht hat.
Die Frage ist Hosting Designer vs. Custom Designer. Die Antwort hätt ich mir vorstellen können… Hängt davon ab, was du machen willst.
BizTalk vs. WF
Positioning ?
BizTalk ist ein Server Produkt, dass schon länger auf dem Markt. WF ist gemacht für Entwickler, um die Engine in ihren Produkten zu nutzen. Grundsätzlich machen die Produkte ziemlich ähnliche Sachen, jedoch sei der Fokus der Produkte ein anderer. BizTalk ist ein Produkt, WF eine engine "for free". In der nächsten Major Version wird BizTalk WinWF basiert sein. SSIS wird angesprochen, dass dies ja auch eine Art WF ist. Frage: Wird dies auch einmal mit WF gemacht ? Es gäbe 7-8 MS Produkte, die sich commited hätten, WF einzusetzen. Mit den guys von SSIS habe man Gespräche, entschieden sei noch nichts. Wenn man SSIS einsetze, könne es je nach case Sinn machen, dass man sich überlege auf WF zu schwitchen.
Sharepoint sei momentan ideal, um WF's zu hosten. Er meint aber nicht SP WF's, sondern WF's die auf Sharpoint gehostet werden und mit SP WF's interagieren. (Sven -> Eskalation ;-)) )
Updating exisitng workflows (Dynamic updates)
Dies ist nicht einfach zu beantworten. Es gibt ein Dynamic Update API… Er zeigt ein kleines Sample.Er klickt in seinem Workflow Designer bei einem laufenden WF auf "pause", dann auf den Button "Change WF" und fügt dann ein Activity hinzu (Der WF darf natürlich noch nicht da vorbei sein) , dann "Accept Changes" und "Resume", nun kommt der WF an diesem Activity vorbei und es wird dann natürlich ausgeführt. Hmm, interessantes sample, IMHO wird dies für uns und in der Realität nie funktionieren. Ich erklär Euch gerne warum, but not here…
Achtung: Watch this guys: Workflow Manager
Whats about WF scalability? More then 100k ? It's not possible to give a answer with a "Zahl". Es kommt drauf an, was das für WF's sind, was sie machen etc. 100k ist keine grosse Zahl, weil wir ja den persistence Service haben. D.h. es sind ja dann nie die 100k WF im memory. Es ist dann eher eine Frage der Skalierbarkeit der DB. Hier ein Bild, das zeigt, wie ich die WF's skalieren kann:
Locking mechanismen for SP Tasklists: Tasklist framework in SP ist great. Paul recommend, that we should use the oob Tasklist activitys.
Interessante Diskussion, ist noch schwierig dies hier alles so wiederzugeben. Viele Fragen haben wir uns schon selbst beantwortet, da wir schon etwas weiter sind, als die meisten hier. Ich kann Euch nur sagen, dass ich nichts gehört habe, dass wir uns irgendwo falsch entschieden hätten. Ich denke, Paul hätte Freude an unserem Projekt ;-)
Keine Kommentare:
Kommentar veröffentlichen