다음을 통해 공유

JAOO 2005 Article on Windows Workflow Foundation

  • 아티클

Originally Created: 2005-10-17

This is an article which was inlcuded in the JAOO 2005 Conference daily newsletter of Wednesday 28 September. Acknowledgements to Scott Woodgate and Paul Andrew, Microsoft Corporation, for the core discussion presented in this article which I turned into a written article for the conference.

The Windows Workflow Foundation

0) What is your background?

I’m born and brought up in Kenya. I now live in England working for Microsoft EMEA as Head of the Enterprise Team in the Developer and Platform Group. This is my first JAOO and my colleague, Beat Schwegler, said "You must come, it’s different". So far, I’m really glad I did! But, enough about me, you want to know more about WF…

 

1) OK, what is Windows Workflow Foundation?

Microsoft Windows Workflow Foundation (WF), which we announced at PDC 2005 (in September), adds workflow to the Windows platform. It will ship in WinFX, which is free by the way. WinFX also includes Windows Presentation Foundation, formerly Avalon, and Windows Communication Foundation, formerly Indigo. [See the Windows Vista Developer Center for more info.]

WF has the potential to enable every single application that you have ever written on Windows to have workflow capabilities - a bold statement indeed, but by adding this capability to the Windows platform we enable all the developers out there to add workflow directly into their applications whether those applications are console applications or web services applications or Windows form applications or future generation applications. In fact thinking about it another way, WF adds a new pattern to mainstream application development - I call this the " [externalized] workflow-first" design pattern.

Think about it, when you build UI you just reach for WinForms and/or the Windows Presentation Foundation; for data management you grab ADO.NET; and for distributed connectivity and messaging you use Enterprise Services, WSE, and/or Windows Communication Foundation. But for business services and business objects what do you do? We're starting to see the emergence of light, flexible modelling approaches based on DSLs to address this problem. They can give you a great start especially when used in conjunction with frameworks. But we still also see a huge amount of code that is simply branching logic - "if", "else," "while loops" and so on, this is opaque and is effectively workflow hard-coded directly into applications. Now imagine we are able to externalize the "workflow" aspects of applications and make them explicit through models. Suddenly an essential part of applications will be freed of their shackles - they will become more transparent. Furthermore, by providing graphical construction tools, we can make the workflow modelling experience even better. Try to imagine how powerful it would be to tie workflow models together with domain specific models in a DSL. I find that thought really exciting!

2) What is the development experience of using Windows Workflow Foundation?

Workflow is going to be new to a lot of developers so we've tried to make everything about building workflows as seamless as possible and easy to understand for .NET developers. We have an API set in System.Workflow to directly program workflows. But we also have a designer for developing workflow models integrated into Visual Studio 2005. This means you can build workflow models in Visual Studio and create workflow artifacts that become a regular part of your solution projects. You compile these as usual because they actually end up becoming VB.NET or C# code through model-based code generation.

The designer allows you to create the fundamental workflow component called activities. From these you can compose sequential workflows and event-driven or state transition based workflows. Behind the scenes, but not hidden from view, the designer is actually modifying the source code for the workflow which is comprised of statements which create the workflow as a model. The workflow ends up as a collection of activities with properties set via the designer. When run the generated source code creates your custom workflow type in memory and executes it on the workflow runtime. Since the workflow runtime has control of that type, it can manage both the lifetime of that workflow and the state that’s associated with it. The lifetime of the workflow need not be short like a procedural piece of logic, it can be long-running since it may be waiting for events from other parts of your application.

You can actually use an XML representation, XAML in fact, to create a workflow. So, it's very consistent with other technologies we have on the .NET Framework or in WinFX. Our customers demand transparency so you can literally write code and then load it into the designer which will reverse engineer the code into the graphical representation of the workflow. This is good for hard core developers who prefer code to graphical diagrams, but it also makes it a lot easier to learn this technology. Having this graphical-textual duality is also a boon for the modelling experience in general.

3) You said activities are fundamental. What are they?

Activities are the building blocks for workflows. You create activities much like you may create controls for Forms when you're building a Windows Forms application. There are built-in controls and custom controls and you simply drag them on to your Forms. You can do the same with activities. We have a bunch of activities that come out of the box and they appear on the toolbox when you create a workflow, be it a sequential workflow or a state-based workflow or another type of workflow - you just drag those on to the design surface and compose your workflow. Of course you can also create custom activities and we expect ISVs and other companies to build activities in different application domains. Within Microsoft the Office group is building a set of activities to support new collaboration and ad-hoc workflow features in the upcoming Office 12. Say an ISV in insurance, where there's a lot of workflow involved, wants to build a claims processing system? Well this process is very unique to each company, so you could imagine the ISV providing a set of customizable domain specific activities for many of the processes. Their insurance company customer would then use these to construct a specific instance of its own claims process.

4) How would you see this technology affecting human workflows?

We think about "workflow" as including both humans and software systems. Sequential workflow is ideally suited for system based workflows, they're very structured, they have a start and they have an end, they look like a flow chart and effectively you walk down a well trodden path.

On the other hand a state-based workflow is well suited for human interactions, where latency and exception conditions are the norm. Making a state machine available at the platform level for every developer to use is a really crucial thing we believe.

What we're doing here is consistent with ASP.NET or WinForms, it's just infrastructure belonging where it should - in the platform. There are many scenarios that you can build on top of this infrastructure and that's the value that you guys add and it'll run just fine on Windows XP, 2003 Server and Vista on the client. One thing to note is that this technology doesn't have its own standalone process nor its own executable; it actually runs in your process so the cost of execution is really low, and it can scale from a Windows console application all the way out to a line of business application or BizTalk Server or SharePoint and those kinds of things by allowing the workflow engine to be hosted as you see fit.

 

5) Are any standards being applied that you are aware of for workflow management?

Well, that's always a good question because many companies need to adhere to different standards when building workflow type applications. We've tried to build Windows Workflow Foundation so it can be made to work with different standards without restriction. For example, we've built a set of activities, which you can swap-out from the default activities, which allow our workflow engine to persist to BPEL format and read it back in. The BPEL pack will be available on the Windows Workflow Community website.

By making workflow generally and freely available in Windows, we had to avoid a fixed language grammar. I am sure things will be built using WF that will completely surprise us. Therefore the engine itself literally must not know what each of the grammar steps are in the language sentences made up of activities. When the engine executes an activity which might do an "if", a "while", or a "loop" it's the activity's own decision to do whatever it does not the engine's. The engine just chains together the set of activities. Out of the box we have the activities that you would expect, "if", "while", "else", "compensation transactions" and so on. But you can throw out our activities and still use our engine. You can implement a new standard, or invent your own via custom activities and you can still use the designer to support that. You can host the designer in your own application. And your custom activities would serialize out to XML in a manner that was appropriate with your standard.

6) If we have the ability to enable Workflow in any application, how does that affect BizTalk Server?

BizTalk Server is an excellent example of a Business Process Management application, and I think this really calls out the difference between infrastructure and product. BizTalk server is an excellent product for creating workflow - effectively "orchestration" - between applications. For example, say I have my Siebel application, my SAP application, and they might be Workflow enabled in themselves but what I want to do is integrate information in those applications together with my trading partners' information stores. So I have to create a Workflow that sits outside applications and BizTalk Server will absolutely continue to be vital to Microsoft's strategy in that role. In such scenarios you need to think about messaging, management, adapters, business activity monitoring and all of those standard capabilities of Business Process Management (BPM), all of which BizTalk provides you.

WF doesn't provide you with those features - it is a pure form of workflow technology and can be thought of as just the orchestration engine part of BizTalk Server, or BizTalk minus all the BPM stuff. Actually the next generation of BizTalk beyond 2006 will actually use WF as its base workflow engine. So, to be clear, a customer today wanting to integrate applications inside her firewall with applications outside her firewall using BPM should consider BizTalk server as the most cost-effective way to achieve this.

Just as a side note, WF is built by the same group of people that built BizTalk Server. This means there's a lot of experience being brought to bear on this problem space. And now that this group is part of Microsoft's Connected Systems division I think we'll see a lot of consistency in the combined WF, WCF and BizTalk strategy going forward.

7) How committed is Microsoft to this stuff?

The key thing is that this technology is going into Windows which means it is going to last for a very, very long time, and we absolutely expect there will be future standards in this space and future standards in each one of the many different scenarios this technology supports. We’ve created an engine that doesn't run on a fixed language but runs with general activities, so that future innovations can be enabled to support standards whilst maintaining consistency with the engine itself.

8) This all sounds great! Where can I find out more?

Sure, just point your browser to the Windows Workflow Community website here: https://www.windowsworkflow.net/. You can also pick up a great whitepapers on WF [1, 2] at the Microsoft stand in the exhibition area of JAOO. I'm also not surprised that there has been a fair amount of content in the JAOO agenda discussing workflow and orchestration. This area is hot and now WF has definitely broken the barrier to entry and adoption for application developers.

Have fun with WF - Thanks!

Comments