Comments on: Workflow Communication http://ajdotnet.wordpress.com/2007/10/02/workflow-communication/ Thoughts and informations I think worthwhile to share... Fri, 18 Sep 2009 01:42:12 +0000 http://wordpress.com/ hourly 1 By: ajdotnet http://ajdotnet.wordpress.com/2007/10/02/workflow-communication/#comment-5530 ajdotnet Thu, 04 Oct 2007 05:05:09 +0000 http://ajdotnet.wordpress.com/2007/10/02/workflow-communication/#comment-5530 @Tim: Der allgemeine Fall (ohne Synchronisierung) ist ja out-of-the-box abgebildet, wenn ich keine explizite Snychronisierung über ein AutoResetEvent mache. Der hier unterstellte Use Case ist aber gerade: Ich habe eine Liste von Daten, ich stoße eine Verarbeitung an und ich möchte mit dem Page Refresh sehen, daß das übernommen wurde (alleine schon, damit der Anwender die Verarbeitung nicht nochmal anstößt). Und ich unterstelle außerdem, daß das sehr zeitnah passiert. Hier ist Synchronisierung sinnvoll, die Alternative wäre Pollen oder Hoffen. Fragwürdig wird das ganze sicher dann, wenn diese Verarbeitung längere Zeit benötigt. In diesem Falle würde ich die hier beschriebene Synchronisierung auf das Entgegennehmen das Auftrags beschränken (also einen künstlichen Zwischenzustand "ist gerade in Verarbeitung" einführen). (Diese Variante wird später in der Serie nochmal aufgegriffen.) HIH, AJ.NET @Tim: Der allgemeine Fall (ohne Synchronisierung) ist ja out-of-the-box abgebildet, wenn ich keine explizite Snychronisierung über ein AutoResetEvent mache. Der hier unterstellte Use Case ist aber gerade: Ich habe eine Liste von Daten, ich stoße eine Verarbeitung an und ich möchte mit dem Page Refresh sehen, daß das übernommen wurde (alleine schon, damit der Anwender die Verarbeitung nicht nochmal anstößt). Und ich unterstelle außerdem, daß das sehr zeitnah passiert. Hier ist Synchronisierung sinnvoll, die Alternative wäre Pollen oder Hoffen.
Fragwürdig wird das ganze sicher dann, wenn diese Verarbeitung längere Zeit benötigt. In diesem Falle würde ich die hier beschriebene Synchronisierung auf das Entgegennehmen das Auftrags beschränken (also einen künstlichen Zwischenzustand “ist gerade in Verarbeitung” einführen). (Diese Variante wird später in der Serie nochmal aufgegriffen.)

HIH,
AJ.NET

]]> By: Tim http://ajdotnet.wordpress.com/2007/10/02/workflow-communication/#comment-5523 Tim Wed, 03 Oct 2007 20:09:04 +0000 http://ajdotnet.wordpress.com/2007/10/02/workflow-communication/#comment-5523 Sehr interessanter Artikel. Was mir nicht ganz klar wird ist das Design sync-on-async. Wenn Sie eine Webanwendung bauen, die Workflows mit dem obigen Service verwendet, ist es nicht ein fragwürdiges Design, einen Thread der Webanwendung zu blockieren, bis die Verarbeitung abgeschlossen ist? Zumal die workflow runtime hinsichtlich des Scheduling eine Black box zu sein scheint. Es kann sein, dass die Workflowinstanz den Request sofort bearbeitet, vielleicht sogar auf dem selben Thread(?), es kann aber auch sein, dass es dauert. Wie lange, wer kann das wissen? Gibt es nicht bessere Patterns, solche Situationen speziell in Webanwendungen, die ja hochgeradig skalierbar sein sollen, abzubilden? Sehr interessanter Artikel. Was mir nicht ganz klar wird ist das Design sync-on-async. Wenn Sie eine Webanwendung bauen, die Workflows mit dem obigen Service verwendet, ist es nicht ein fragwürdiges Design, einen Thread der Webanwendung zu blockieren, bis die Verarbeitung abgeschlossen ist? Zumal die workflow runtime hinsichtlich des Scheduling eine Black box zu sein scheint. Es kann sein, dass die Workflowinstanz den Request sofort bearbeitet, vielleicht sogar auf dem selben Thread(?), es kann aber auch sein, dass es dauert. Wie lange, wer kann das wissen? Gibt es nicht bessere Patterns, solche Situationen speziell in Webanwendungen, die ja hochgeradig skalierbar sein sollen, abzubilden?

]]>