- Categorizing Cloud Platforms: Beyond IaaS and PaaS
- What is Application Lifecycle Management (ALM)?
- SOAP vs. REST: Complements or Competitors?
- Conference: Shaping the New Age of Application Dev...
- Amazon Reserved Instances and Cloud Capacity Planning
- Introducing Windows Azure
- The Most Important Profession in the World
- Cloud Platform Storage: Relational vs. Scale-Out
- Why It's Hard for Enterprises to Save Money with C...
- The Sixth Platform
Opinari
Subscribe
The Workflow Way
# Monday, May 18, 2009
Windows Workflow Foundation (commonly called just WF) is a useful technology. It's not so simple to understand and use, however, and so it's not a widely used choice among enterprise Windows developers today. A primary goal of WF's next release is to change this, making the technology more approachable and more popular. For this to happen, people need to understand what WF really offers.
Toward this end, I've written a new introduction to WF. Called The Workflow Way: Understanding Windows Workflow Foundation, the paper's goal is to explain WF to mainstream Windows architects and developers in a straightforward way.
To me, everybody who builds software on Windows ought to understand the basics of WF--it's a fundamental part of the application platform. And while workflow isn't always the right approach, it's sometimes just what you need.
8 comments :: Post a Comment
Comments:
This white paper is indeed a good introduction for developers who want to understand who to decompose their applications into a flow of activities. Good work!
Thanks very much, Edwin. Especially given your strong background in this area, I really appreciate your comments.
Respect. Thank you for making this complex topic [WF] crystal-clear for me.
By now, I believe I could actually explain how and when to use WF.
Cheers,
Brian Berry - Houston, TX
By now, I believe I could actually explain how and when to use WF.
Cheers,
Brian Berry - Houston, TX
# posted by 
: May 29, 2009 1:04 PM
: May 29, 2009 1:04 PM
Hi! WF is very good for business process but this kind of iniciatives are not good for new companies.
# posted by : June 09, 2009 2:55 PM
: June 09, 2009 2:55 PM
Hi David, this was a good read. Very informative. I never considered WF up until now, but the new release seems promising.
I'm a bit concerned about the persistence store though. Couldn't that be a scalability bottleneck? From one of your diagram, it looked like it was shared by multiple WF runtimes. I was wondering if it is possible to scale that part of the system too and how.
thanks
stefano
I'm a bit concerned about the persistence store though. Couldn't that be a scalability bottleneck? From one of your diagram, it looked like it was shared by multiple WF runtimes. I was wondering if it is possible to scale that part of the system too and how.
thanks
stefano
# posted by : June 17, 2009 4:26 AM
: June 17, 2009 4:26 AM
David,
I really appreciate all your clarification of Microsoft technologies.
However, here, IMHO, you oversimplify the WFW classical "competition".
No decent server is single threaded as you describe in Fig. 1. The code is that way but multiple threads share it, and consequently share data and locks (state) in process memory .
So the issue is more a matter of sharing state in memory vs sharing state on disk (Fig. 2).
This changes the way to present how WFW helps. As I see it, its value is to handle in the run time (and so hide from the programmer) the necessary locking and persisting of activities' shared state at some synch points.
So the trade-off between traditional multi-threaded server and WFW-based server is caring about shared variables in memory or analyzing your problem using activities and messages.
I really appreciate all your clarification of Microsoft technologies.
However, here, IMHO, you oversimplify the WFW classical "competition".
No decent server is single threaded as you describe in Fig. 1. The code is that way but multiple threads share it, and consequently share data and locks (state) in process memory .
So the issue is more a matter of sharing state in memory vs sharing state on disk (Fig. 2).
This changes the way to present how WFW helps. As I see it, its value is to handle in the run time (and so hide from the programmer) the necessary locking and persisting of activities' shared state at some synch points.
So the trade-off between traditional multi-threaded server and WFW-based server is caring about shared variables in memory or analyzing your problem using activities and messages.
# posted by : July 20, 2009 2:30 AM
: July 20, 2009 2:30 AM
You're right, Jacques--I think the paper is a bit oversimplified in this area.
My target audience, though, was mainstream .NET developers, especially enterprise developers for whom multi-threading isn't such a familiar concept. Accordingly, I chose to make the story a bit simpler than the one you describe.
It's always a challenge to write something that's clear, accurate, and simple. Maybe I can tackle the perspective you suggest in a future revision of this paper.
Post a Comment
My target audience, though, was mainstream .NET developers, especially enterprise developers for whom multi-threading isn't such a familiar concept. Accordingly, I chose to make the story a bit simpler than the one you describe.
It's always a challenge to write something that's clear, accurate, and simple. Maybe I can tackle the perspective you suggest in a future revision of this paper.
<< Home