Welcome to Windows Workflow Foundation (WF)
Top Tasks :

WF Community Bloggers

Browse by Tags

All Tags » BizTalk » Workflow   (RSS)

  • The Future of BizTalk/WCF/WF

    Walter Michel commented on my recent entry on the BizTalk and WCF Messaging Models and asked if I had some guesses as to what the architecture of a future BizTalk version might look like in regards to WF/WCF integration. I think that, at this point in time, it is anybody's guess what it might look like, as it is just too early to tell. Honestly, I don't know what it might end up looking like, and I can't even say I can make an educated guess (and there are people with far more criteria for making such educated guesses than me, such as Jon Flanders ). Instead, I'll address the question in a different way, by mentioning what I consider a few challenges I see regarding the integration and other things like that. The Impact of Significant Architecture Changes One key aspect of the whole integration process between the three technologies is what the impact of significant changes to the core BizTalk architecture. Microsoft already went down that path during the transition between BizTalk 2002 and 2004, and while those of us developing BizTalk solutions are extremely grateful for the benefits that the new architecture brought over, companies with large investments in BizTalk 2000/2002 solutions were not so happy. For most of them, going to BizTalk 2004/2006 meant a complete rewrite of their integration solutions, and that can be very expensive, and though to justify to the business side, not only because of cost, but also because of the associated risks. With BizTalk 2004/2006, BizTalk brought over not only a significantly revamped platform, but also a new, effective, and very welcome extensibility model that has been tested with time. That's why the current core product architecture has been good for three release cycles already, and the fact that even complex things like WCF could be integrated without significant changes to it is pretty substantial. A lot of Microsoft clients and partners have made significant investments in that architecture and its not clear how that investment might be preserved (or at least their loss mitigated a bit) if significant architecture changes happen. I'm pretty sure the people at the Connected Systems Division at Microsoft are aware of this, and from my own, outside perspective, I can only say that it seems like a daunting and complex decision to make. Whatever way they decide to go, it's not going to be easy. So, what happens if the complex changes do become a reality? We can only hope that good migration tools are not left by the side; but even with those migration tools, you'd probably be looking at a complete rewrite scenario again for the most part. Messaging In my previous entry, I commented that the current WCF integration in BizTalk 2006 R2 leverages the existing BizTalk messaging extensibility model (the adapter framework) on top of the messaging engine. However, I think that in the long run, keeping both is probably not the best solution. Despite their differences, there's still a lot of common ground and responsibilities Read More...
  • Workflow Services in Orcas

    One of the new power features in .NET 3.5, sorely missing when .NET 3.0 was released is the integration between Windows Communication Foundation and Windows Workflow Foundation, in the way of the new Workflow Services model. Besides providing an easy way to invoke WCF services from WF without resorting to using BasicHttpBinding on the services or invoking a [wrapper] client class form a code activity in your workflow, it also provides a way to expose a workflow as a WCF service to the outside. The second functionality is the one that, naturally, interests me the most. After looking at it for a while, I've made a few observations that I'd like to share. Implementing Services A very interesting thing is how you implement services as workflows. If you know how to create WCF services the right way, then you [mostly] know how to implement services as workflows. The reason for this is that most of the tasks you'd normally when creating a WCF service still apply when creating a workflow service. That is, you will still declare your service contract (interface) as well as your message/data contracts. The only key differences really is how you implement that contract. When using workflow services, you implement a contract by using the new Receive activity introduced in .NET 3.5, and select which operation of the contract you'd be implementing. You still need to do the activity binding dance for parameters as well as (possibly) create response messages for the incoming requests. Basically, the Receive activity works as a kind of sequential activity where the child activities represent the tasks to execute after the request message is received until the response message is sent (if this is a request/response service). You'd also need to do a lot of the usual work in setting up your service host, only instead of using the regular ServiceHost class you'll be using the new WorkflowServiceHost class. Guy Burstein has a good entry on getting started on exposing workflows as services here you might want to check out. Starting Workflows One very interesting option in the Receive Activity is the CanCreateInstance property. You can use this property to have the WorkflowServiceHost automatically create and start a new instance of your Workflow when a new message arrives at the service endpoint for the implemented operation, without having to write manual code to receive the message and create the new workflow instance. People familiar with BizTalk 2004/6 will recognize this option as being similar to the Activate property of the Receive Shape in BizTalk orchestrations. It also serves, in a way, a similar purpose as the CanCreateInstance property of the new [DurableOperationBehavior] attribute introduced for WCF in .NET 3.5 as part of WCF Durable Services infrastructure. Jesus Rodriguez has an excellent article introducing this new feature. Something I found a bit curious about the CanCreateInstance property of the Receive Activity is that there's currently no validation Read More...

<October 2008>
SuMoTuWeThFrSa
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us