|
|
Browse by Tags
All Tags » WF (RSS)
-
I've had alot of people ask when I am teaching WF next - if you are interested in sitting through me talking about WF for four intense days - come to laid-back Australia. Pluralsight is teaming up with Readify to offer the course. I'm super excited since this will be my first trip to Australia. I can't wait. If you are in the area - or just want an excuse to come to Australia - sign up ;-) Applied Windows Workflow Foundation in Australia Nov 13-17th Check out my BizTalk R2 Training . Read More...
|
-
So I started this sample out as an off-the-cuff kind of thing and it seems a number of people are using it. Lenny Fenster from Microsoft found another bug - when the child workflow would terminate with an exception - the CallWorkflowService was sending the exception to the Queue - but the custom Activity listening for the message wasn't re-throwing the exception. Its been fixed - so if you are using this sample - you should download the new code. Orginal Post . My samples page. Check out my BizTalk R2 Training . Read More...
|
-
Having spoken, taught, and consulted about Windows Workflow Foundation for over two years I've run into a number of common misconceptions about WF. One common misconception is that WF is a write-once run-anywhere technology. Some people feel like if they write a workflow to run inside of a particular host (let's take SharePoint) - that those workflows will be able to run inside of another host (let's imagine the next version of BizTalk which has already been announced will run WF workflows natively as its "Orchestration" engine). The answer is almost *all* cases is a resounding NO (there are a few small exceptions to this rule but they are hardly worth mentioning). In WF a Host has to know how to interact with Workflows, when to create them, when to use an existing Workflow Instance, and most importantly how to communication with a running workflow (this is probably the #1 reason why workflows are not portable among workflow hosts). So a workflow you build today for SharePoint is intended only to run in SharePoint. A workflow you build for a custom Host is likely only to run in that custom Host - it is very very unlikely that you'll be able to take a workflow built for a custom Host and run it in the next version of BizTalk (and I have no inside knowledge of what workflows inside of the next version of BizTalk will look like - although I think you can probably intuit that from what's in Orcas in terms of the WCF-WF integration). This blog post came to me when I was doing a talk Read More...
|
-
I just got done with my TechEd session on using WF and WCF - if you attended the session - here is the code: teched2007.zip (474.59 KB) . If you didn't attend my session "This is not the code you are looking for ....." ;-) Thanks for everyone who came (295 people - wow!). BTW - here are the three best and worst thing about teched 2007 according to the people in my session: BEST 1)HOL (hands on labs) 2)Just the Information 3)BOF (birds of a feather sessions) Worst 1)Bathrooms (this was the men only of course) 2)Buses(slow/scalable) 3)Session are too short Read More...
|
-
Thanks to my friend and fellow BizTalk MVP Brian Loesgen - I'll be speaking May 22nd at the San Diego .NET User Group on two of my favorite technologies - WF and WCF and how to use them together successfully today - even without Orcas! Come out if you are in the SD area. Read More...
|
-
So if you are interesting in how to integrate WCF and WF today (yes all the cool new WCF/WF stuff in Orcas is really cool - but still some number of months away) - please come to my pre-con at TechED US - https://www.msteched.com/public/precons.aspx#PRCN15 I'll be doing it with my good friend Richard Blewett - which should be a good combination of technical learning and fun. Read More...
|
-
Back in November I delivered a presentation to the Twin Cities BizTalk User Group titled 'Rule Engines: Workflow Rules vs. BizTalk Rules'.
Since then I have been working with the Rules Team in Redmond and with their input I have updated and added content to that presentation. Hopefully the presentation will help you when you get questions about how the Workflow Rules compare and relate to the BizTalk Rules Engine. 
|
-
Paul Andrew announced recently a coming CTP [1] that will provide BPEL 1.1 support to Windows Workflow Foundation. This will provide a set of custom WF activities that map to BPEL 1.1 constructs as well as tooling to import BPEL processes into WF XAML workflows and export the other way around. I think overall this is very good news and, as Paul says, highlights the power and flexibility offered by the domain-neutrality of the WF runtime. Paul also mentions that this will, in the end, be supported in a future release of BizTalk Server, once the orchestration engine is built on top of WF, and by that time the toolkit support should have already been expanded to provide BPEL 2.0 compatibility in both WF and BizTalk. Pretty exciting stuff which I'm sure will provide some good selling points for both products (even if many people don't use it eventually). One important aspect of this that is interesting to consider: the WF approach to writing workflows means that, if BPEL compatibility is an aspect you care about, you'll need to restrict yourself to a subset of the power of WF in order to remain compatible (and meaning being able to later export your WF workflows into BPEL). This is something I completely expected and understand (and even welcome, to a point), but it's something some people might not realize right away. [1] Am I the only one getting lost along the miriads of CTPs coming out of Redmond lately? Seems pretty imposible to keep up if you actually have a day job! Technorati tags: Windows Workflow Foundation , BizTalk Server , WF , BPEL Read More...
|
-
I got a review copy of K. Scott Allen 's " Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C# " book and I just finished reading it recently, and wanted to take a moment to mention my opinion about it. First of all, I'm probably not quite Scott's target audience, seeing how I was already familiar with WF before getting into the book. From my point of view, the book aims to provide a quick introduction to what WF is and how to get started programming it. In that aspect, I think it does a pretty good job. The book starts by quickly introducing what WF and what it is composed of (the runtime, activities, designer, XAML and so on). Chapter 2 then talks in a bit more detail about how to create and design workflows, covering both the principal aspects of how the VS designer works, as well as writing workflows in code and XAML. But this chapter also goes a bit further and covers using the workflow compiler both from the command line (wfc.exe) as well as programmatically and XAML workflow activation. Chapter 3 is dedicated to writing sequential workflows, though it also covers basic host <-> workflow communication using the workflow runtime events, workflow parameters and external data services. The latter are taken up in more detail in chapter 4, which covers most of the basic activities in the base activity library. Chapter 5 introduces how to write custom activities. While the cover here is somewhat light (as expected given the breath of the topic), Scott does quickly cover important topics like activity binding and dependency properties and gives a quick look to readers of how to write custom activity designers and validators. Chapter 6 covers the hosting facilities in WF, including how to correctly use the WorkflowRuntime class, and all the built-in runtime services, including scheduling, persistence and tracking. Chapter 7 covers State-Machine workflows, including some simple examples of how to interact with the workflow from the host (like quering possible transitions from the current state). Chapter 8 covers host <-> workflow communication in detail, including the use of correlation tokens, role authorization and an explanation of workflow queues. Finally, Chapter 9 covers the rules engine in WF and using code and rule conditions in activities. As I said earlier, I'm probably not the the target reader for the book. Many of my readers probably won't also, so if you're looking for a comprehensive, in depth look at WF, you'll want to find some other source. However, if you are not familiar with WF yet, I believe Scott's book is a pretty good place to start. Here's why: The book is short, about 230 pages. Most people should be able to go through the book pretty quickly. Scott's writing is very much to my liking. He's direct, goes straight to the point without any B.S. and he's style is pretty engaging overall, so you won't get easily bored. Chapters are also very reasonably paced and good in length, 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, delayed deliver, synchronous and asynchronous interchanges, ordered deliver (and even tougher, in-order processing), lost and duplicated messages and so on. A spec like WS-RM doesn't try to solve all this issues, for obvious reasons, and that really is fine. A lot of these issues cannot be taken into account by themselves, but only in the context of the overall architecture and requirements. In particular, how the individual endpoints are designed can make a huge impact in which of the issues mentioned before are significant and how significant. Some architectural choices will make some of these problems go away without having to write more code for it. For example, a given service might have a set of messages created in such a way that the operations they represent are idempotent. In that case, duplicated messages should not be a problem, and spending a lot of time to avoid them would not be an efficient use of your development budget, as they are a non issue. In other contexts, for example, missing one or two messages during high load might also not be important because perhaps the contents can be reconstructed from subsequent exchanges. So given this, why do I make so much fuss about WS-RM if it wasn't meant to be the end-all solution anyway? Because of the way it has been positioned by the marketplace: It is usually portrayed as saying that it "finally solves the reliable messaging problem for Web Services". It doesn't. Unfortunately, the WCF literature hasn't helped clear Read More...
|
-
Two new articles just got published to MSDN covering the Tracking facilities in Windows Workflow Foundation in great detail. The first one is " Windows Workflow Foundation: Tracking Services Introduction ", by David Gristwood, and provides a high-level introduction to what Tracking is and how it works in WF. It also shows how to instrument (add tracking) to a workflow and a brief example of how to use SqlTrackingQuery on your app to read the information written by the workflow tracking service. Towards the end, the article discusses Tracking Profiles and what they do. The second article is " Windows Workflow Foundation: Tracking Services Deep Dive " by Ranjesh Jaganathan, and this one focuses on the underpinings of the tracking facilities. One thing I liked here was the whole discussion about how profiles, trackpoints and locations are related to one another, as they provide a clear overview of how it works for anyone wanting to create custom tracking profiles, as well as how to use Extracts in your trackpoints to extract the data you want tracked from your workflow and activity instances. Technorati tags: Windows Workflow Foundation , WF , Tracking Read More...
|
-
Harry Pierson talked a bit about the stuff he's learning on BizTalk Server in Morning Coffee 12 entry (btw, loving the, keep it up!). Looks like he's attending a great class with Matt Milner . A few comments that sparked my interest: Harry says that conceptually BizTalk hasn't changed all that much since the 2000/2002 days. I'm not sure I'd agree, but that would depend on what he means by "conceptually" I'd say that from an architecture point of view, the the change between 2002 and 2004 was a very significant one, requiring you to adapt to a lot of new stuff. Here's why I feel this way: The orchestration engine was pretty much rewritten. The designer by itself is a great improvement, but it's far more than that: There's no more interpreted XLANG, now we have XLANG/s Orchestrations (*.odx) are compiled down to C# and then to MSIL. Now we have a pretty powerful correlation mechanism as well as convoys. Native .NET support (it is .NET after all!) The messaging model changed significantly: Most of the terminology changed. Remember channels, AICs and Receive Functions? The messaging model is now mostly symmetrical, unlike in 2000/2002 where the send and receive sides were very different. The pipeline model is far nicer (have I mentioned I love pipelines? they're fantastic!). The adapter framework. Sure beats down anything we had in 2000/2002! Writing adapters is still hard, but writing them in .NET is far easier. Application Integration Components (AIC) were a kludge, anyway. New features: Enterprise Single Sign-On Business Activity Monitoring: Don't disregard the power of BAM, it's one of the coolest features in BizTalk and coming soon to WCF and WF thanks to the new BAM interceptors for WCF and WF in BizTalk 2006 R2. Business Rules Engine Maybe it's just me, but I do consider that the change between 2002 and 2004 to be very significant and a much needed improvement. But I'd agree that from some points of view, yes, BizTalk is still BizTalk (e.g. you still use it for the same and a lot of the usage scenarios haven't changed at a conceptual level). Personally, I consider understanding the BizTalk architecture an absolute must for any BizTalk developer, and as you can see, I get all excited talking about it Harry also mentioned something I've heard a lot of people say: that the Pub/Sub engine in the BizTalk MessageBox was mostly useful for messaging-only scenarios. I agree that's what it might seem so at first but just to reinforce what Matt said in the class: The Message Box really is the heart of BizTalk and the Pub/Sub engine in it is exactly what gives it that power! So let me briefly enumerate just why the Pub/Sub engine is extremely relevant to orchestrations in BizTalk: The Pub/Sub engine processes any message that comes into BizTalk, and that includes messages that fire orchestration instances. Even when you do the simplest Port to Orchestration bindings, subscriptions are still created/evaluated/matched in the MessageBox to enable the processing 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... Technorati tags: Architecture , WCF , BizTalk Server , WF Read More...
|
-
I love doing User Group talks - nothing better than doing one less than 10 miles from home! Anyone in So Cal - please come here me talk about WF at the San Gabriel Valley .NET Developers Group on January 17th. Read More...
|
-
So the company I did some Windows Workflow Foundation (WF) consulting for last summer has recently gone public with how they are using WF in their SaaS application. You can watch a set of videos here - http://msdn2.microsoft.com/en-us/architecture/bb190630.aspx . I helped them with their basic WF architecture, as well as with a custom Root model (the part where they talk about a top-level Sequential Model that runs StateMachine workflows as children activities), as well as their Workflow Designer for their end-users. I think they are a great example of the power of using WF in your application and the benefits you get from using WF to build a cusotmizable pluggable system. Read More...
|
|
|
|