|
|
Browse by Tags
All Tags » Architecture (RSS)
-
Scott Bellware discusses some interesting things here regarding transactions and extensibility hooks and even considering Ruby on Rails as a web front end. I'll ignore the Ruby thing, but I do want to talk about his comments on transactions and workflows. If I understand right, Scott is basically providing a way to extend his application through user-defined workflows that are executed at specific and controlled extensibility points. This is a very cool scenario for WF that enables very interesting possibilities. His concern, however, seems to center around controlling what happens when one of those user-defined workflows fails, to ensure the entire system is not left in an inconsistent state. This is certainly a valid concern, but it is one that I feel isn't quite as simple to solve as simply "use transactions". Let's take WF out of the picture for a moment and assume we were using a good old code-based extensibility model (or even a script-based one). Even with the help of System.Transactions and distributed transactions, there's really no way to guarantee that whatever code users of the system put into the extensibility hooks would still work correctly in the event of failure. This revolves around the fundamental fact that there's no guarantee that whatever is put in there is even transaction-aware . Granted, there's a big chance that code put in there is indeed transaction aware, but that's only because a lot of what comes directly into the core .NET framework is tightly integrated Read More...
|
-
Harry Pierson posted a story about Windows Communication Foundation and his "epiphany" (my words) on the usefulnes of WS-ReliableMessaging in Web Services. I found several comments here that made me think. Sam Gentile recently commented as well on the importance of WS-RM, and I did a few quick posts there. Let me first start this discussion that I believe that the basic concept behind reliable messaging (and WS-RM) is indeed very important and very needed in the Web Services World to make it easier to implement reliable services and integrate disparate applications. That said, I've been frank in the past and say that I believe that the WS-RM spec, as it exists right now, is remarkably lacking. Harry mentioned the core point: It does not demand persistence of the message and conversation state from the endpoints involved in the communication. Thus, as WS-RM currently exists, and how platforms such as WCF implement it, it means you don't really have the guarantee of reliablity. At best, all you have is the illussion of reliability. The only thing you can be sure of is that one of your endpoints is gonna fail, sooner or later. If there is one thing that I have learned from my work on Application Integration (with and without BizTalk), is that ensuring reliable communication across a distributed application infrastructure is a tough nut to crack. There's a lot of very significant issues that can arise here, depending on the type of problem domain you're solving: Message delivery, Read More...
|
-
Here are some articles I found interesting that I've read recently: Workflow in Application Integration : Kevin Francis talks a bit about application integration architecture in the enterprise on the Architecture Journal 9. Despite the title, it doesn't really talk much about Workflow, but rather about the whole architectural perspective on integration. Commonwealth Bank of Australia CommSee Solution: An interesting look at a case study, in this case the CommSee application at the CBA. Part 1 focuses on the overall backend architecture for the application; Part 2 focuses on the front end: a Smart client Windows Forms application and Part 3 focuses on the infrastructure and development/test process. A few other architecture case studies can be found here . Building Interoperable Insurance Systems with .NET 3.0 Technologies : An interesting case study on building an insurance system based on insurance standards ( ACORD ), WCF and Web Services, Windows Workflow Foundation, a smart client and BizTalk Server 2006. It also appears to use "SQL Server 2006" . Some really interesting bits here... Architecture , WCF , BizTalk Server , WF Read More...
|
-
Jon Flanders weights in on the complexity of Windows Workflow Foundation, saying he disagrees with some of the points raised by Brian and Scott . I think he exaggerates a little bit when he says we think it is too complex, I just said it was complex :-). While Jon raises many good points, I don't quite buy his argument. Seems to me he's saying WF is simple bacause, well, it behaves as it was supposed to behave based on the design the WF team chose for the product. Jon does raise the very good point that, as any other technology, you have to understand it in order to use it effectively, which is something I do agree with (see? we do agree on something! ;-)). However, I'll like to explain my comments on WF complexity a little more (though I know it's something Jon and I disagree on ). I expected WF to be a complex technology, because the underlying problem domain is complex. And for what it's worth, complexity is not bad, and I personally happen to like a lot about WF.However, I don't think that going for this complexity is warranted in everycase, which seems like it is what MS is advocating when they raised the "Workflow is Everywhere" mantra. For example, I happen to think that going for the complexity of WF for your website navigation (PageFlows) is unwarranted in most cases, unless you have some seriously complex scenarios to tailor to. There will definitely be a need for good architectural guidelines as to when going with WF is really a good investment. But besides that, my Read More...
|
-
Brian Noyes postes here about the complexities in developing for Windows Workflow Foundation. In general, I have to agree with his sentiment. Workflow in general is not trivial and requires approaching it with a somewhat different mindset, and it's no different with Workflow Foundation. Some of what Bryan talks about is caused in part by this conceptual model differences, and partly just because of the way WF works. But, up to a point, most of what he mentions is just the superficial issues. Things get far more complex once you start diving deeper into it, and there are quite a few issues that will bite you if you're not aware of the WF model. Some examples: The execution model is not exactly trivial (though it is extremely powerful). It has several points that are not very intuitive and the overal design-time experience might make you feel it should work different than what it actually does. For example: WF workflows (or rather activities) basically operate as prototype definitions at runtime. This can cause issues when manipulating properties, so you need to be careful to ensure you are manipulating the executing instance and not the prototype instance. The WF execution model and thus the behavior of running workflows can be substantially affected by what services are configured in the WF runtime. This can be quite surprising in some scenarios and can easily break your workflow definitions. The threading model in WF is far more complex than your regular .NET code (which is expected), Read More...
|
-
The Advanced Workflow blog has an interesting post on choosing the correct scheduling service for the Windows Workflow Runtime when you are going to be running workflows from within ASP.NET applications. The recommendation is to use the ManualWorkflowSchedulerService instead of the DefaultWorkflowSchedulerService that is normally used in other scenarios, because it forces an explicit model instead of stealing threads from the ASP.NET Thread Pool. The benefit of this is that it solved some potential problems under stress and guarantees a more optimal use of the threads available. The downside is that it becomes the responsability of the developer and the ASP.NET application that hosts the runtime choosing when to allow workflows to be executed. In other words, the flow of the execution context from regular ASP.NET code to Workflow Code becomes explicit: you have to choose when to yield your execution thread over to the workflow runtime. This is significant because you are responsible for doing this every time, including when indirect behavior in the workflow is triggered, such as a long-running workflow getting reloaded for execution, or when a delay fires. Basically, I think this means that your developer responsability as a workflow scheduler is somewhat more complex than just calling workflows when necessary (there are quite a lot of discussions about this topic over on the WF forums ). Personally my opinion is: while hosting WF in ASP.NET can be seen as useful (and possibly Read More...
|
|
|
|