Comments on: Things to know about WF http://winterdom.com/2006/10/thingstoknowaboutwf by dæmons be driven Tue, 16 Mar 2010 06:33:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Tomas Restrepo http://winterdom.com/2006/10/thingstoknowaboutwf/comment-page-1#comment-584 Tomas Restrepo Mon, 16 Oct 2006 21:05:58 +0000 http://winterdom.com/2006/10/thingstoknowaboutwf#comment-584 Thanks for the comment! Interesting post, I'll certainly be linking to it in a separate entry. That said, I've never said that WF is a toy; if I did, I wouldn't be spending as much time on it writing about it and coding for it. Heck, in fact it was you who suggested they were only examples in a thread in the WF forums, if I remember correctly ;) That said, I do have a certain things about I feel strongly about (and have commented on previously) where I think that the focus on extensibility and on providing a host-agnostic engine proves frustrating for people trying to use WF. Just to be perfectly clear, I think this is mostly a problem of expectations, and I think perhaps MS has provided a somewhat confusing message on the topic. On one hand, you've been touting workflow as being "everywhere" and I'm sure you guys want as many people using WF as possible. On the other hand, a lot of what's provided for V1 I feel is not what people really expect when they think of workflow, and particularly not what they expect when they talk about "human workflow" as such. Besides this, the current implementation of WF is, in a sense, a rough start more useful as is directly to either people who already build embedded workflow engines (i.e. K2.NET, and so forth) or people willing to do a significant investment in writing their own infrastructure to support WF in their own scenarios (even if they are fairly common ones). I think that a lot of people currently trying to use WF (and far more to come once it is released) will find themselves in those positions when they initially didn't expect to, thus causing them frustration (like the several cases one could point out in the WF forums) and in many cases extra work they were not aware would be needed. Now, that said, I do think that WF is a *great start* towards the goals MS set, but a start nonetheless. I'm very confident the following releases after V1 will get us something far nearer what a lot of people expect when they talk about workflow and get us more robust hosting infrastructure/facilities, and I'm very interested in seeing how the next BizTalk version after 2006R2 incorporates WF technologies (particularly since I do a lot of BizTalk work and have been working with it for the past few years). Thanks for the comment! Interesting post, I’ll certainly be linking to it in a separate entry. That said, I’ve never said that WF is a toy; if I did, I wouldn’t be spending as much time on it writing about it and coding for it. Heck, in fact it was you who suggested they were only examples in a thread in the WF forums, if I remember correctly ;)
That said, I do have a certain things about I feel strongly about (and have commented on previously) where I think that the focus on extensibility and on providing a host-agnostic engine proves frustrating for people trying to use WF. Just to be perfectly clear, I think this is mostly a problem of expectations, and I think perhaps MS has provided a somewhat confusing message on the topic. On one hand, you’ve been touting workflow as being "everywhere" and I’m sure you guys want as many people using WF as possible. On the other hand, a lot of what’s provided for V1 I feel is not what people really expect when they think of workflow, and particularly not what they expect when they talk about "human workflow" as such.
Besides this, the current implementation of WF is, in a sense, a rough start more useful as is directly to either people who already build embedded workflow engines (i.e. K2.NET, and so forth) or people willing to do a significant investment in writing their own infrastructure to support WF in their own scenarios (even if they are fairly common ones). I think that a lot of people currently trying to use WF (and far more to come once it is released) will find themselves in those positions when they initially didn’t expect to, thus causing them frustration (like the several cases one could point out in the WF forums) and in many cases extra work they were not aware would be needed.
Now, that said, I do think that WF is a *great start* towards the goals MS set, but a start nonetheless. I’m very confident the following releases after V1 will get us something far nearer what a lot of people expect when they talk about workflow and get us more robust hosting infrastructure/facilities, and I’m very interested in seeing how the next BizTalk version after 2006R2 incorporates WF technologies (particularly since I do a lot of BizTalk work and have been working with it for the past few years).

]]> By: Paul Andrew http://winterdom.com/2006/10/thingstoknowaboutwf/comment-page-1#comment-583 Paul Andrew Mon, 16 Oct 2006 20:42:03 +0000 http://winterdom.com/2006/10/thingstoknowaboutwf#comment-583 The services aren't nearly as bad as it's been suggested. We worked hard on these and they will be supported by Microsoft. They aren't toys. Check out my blog response to the original post by Harry. Regards, Paul The services aren’t nearly as bad as it’s been suggested. We worked hard on these and they will be supported by Microsoft. They aren’t toys. Check out my blog response to the original post by Harry.
Regards,
Paul

]]> By: Tomas Restrepo http://winterdom.com/2006/10/thingstoknowaboutwf/comment-page-1#comment-582 Tomas Restrepo Thu, 12 Oct 2006 07:47:47 +0000 http://winterdom.com/2006/10/thingstoknowaboutwf#comment-582 That's a great idea Scott, I like it. I think we do agree on the core issue: Source is needed, please :) That’s a great idea Scott, I like it. I think we do agree on the core issue: Source is needed, please :)

]]> By: Scott Allen http://winterdom.com/2006/10/thingstoknowaboutwf/comment-page-1#comment-581 Scott Allen Thu, 12 Oct 2006 07:39:47 +0000 http://winterdom.com/2006/10/thingstoknowaboutwf#comment-581 The ASP.NET team published the source code to the built in ASP.NET providers to make life easier for developers who need to implement custom providers. It's difficult to implement a robust,non-trivial provider, and having this source is a great benefit. I think it would be a boon for the WF ecosystme if the team published source code for the base activity library, persistence, tracking, and shared connection services. To write a bulletproof, non-trivial custom activity you need to master a lot of nuances. The best examples of how to approach this work would be to have the BAL implementation available as a reference. The ASP.NET team published the source code to the built in ASP.NET providers to make life easier for developers who need to implement custom providers. It’s difficult to implement a robust,non-trivial provider, and having this source is a great benefit.
I think it would be a boon for the WF ecosystme if the team published source code for the base activity library, persistence, tracking, and shared connection services. To write a bulletproof, non-trivial custom activity you need to master a lot of nuances. The best examples of how to approach this work would be to have the BAL implementation available as a reference.

]]>