Prior to joining Microsoft, I can’t tell you how many times I heard “will there be a convergence between BizTalk orchestrations and Windows Workflow Foundation? When do I use what? Are BizTalk Orchestrations going away?”. Since joining Microsoft, I’ve heard it even more. In fact, it has got to be the number one question I hear, and I’m sure that’s also true for many of you.
Last week at PDC 2009, Sriram did two things, he announced BizTalk Server 2009 (as I blogged about here), but also, he demonstrated some early prototype work that was being done around bringing together BizTalk, Windows Workflow Foundation, and Windows Server AppFabric. That announcement of R2 and the sneak preview of V.Next are significant enough that I decided to do a separate blog post about each.
Before we start though, let’s set expectations. What was shown in terms of WF/BizTalk integration was a very early prototype. This is NOT something you’ll be able to download next week, and put into production next month. This is early-stage code showing the direction the team is heading in. Have said that, if you follow my blog, you know that’s exactly the stage I like to get involved at :), and I feel it’s very important to keep an eye on the horizon and know what direction you’re heading in.
There are actually a few aspects to what was shown.
First and foremost, was WF integration into BizTalk. Let’s consider some of the motivations behind this:
- a common ask from customers is a low-latency solution (not all integrations require it, but in some cases, it can be a must-have). BizTalk is a reliable messaging platform, once a message is received, it is never, ever, lost. That reliability has a cost, as it means that there has to be durable storage (in our case SQL Server), and no matter how well tuned, persisting a message in durable storage has a latency cost associated with it
- sometimes people aren’t sure which way to go as there are four ways to compose services on the Microsoft stack (usually capabilities lead to a decision, but there can be overlap), with no easy migration path between them:
- using BizTalk orchestration
- using Windows Workflow Foundation
- using BizTalk ESB itineraries
- using custom code
Of those four, custom code is an option, but it puts a lot of responsibility on the developer to do “plumbing”. If or example you compose 3 services, and service #2 is unavailable, what do you do? You need to code protectively to respond to that. Or, service #2 returns a fault, what does that mean in terms of the overall composition and flow? Personally, I think a more efficient way to go about this is to let something else worry about the minutiae of the plumbing, which is what we get with the integration server capabilities of BizTalk Server. So, although there will always be times where it is the right way to go, let’s leave custom code off the list for the rest of this post.
That leaves us with three options, two of which are BizTalk options, and then WF which is currently completely outside BizTalk. As you probably know, with WF 3.5, if you wanted to host a workflow, you had two choices: use the hosting capabilities in SharePoint, or write your own host (which can be a daunting task depending on far you go towards being a fully featured enterprise-grade host). With .NET 4, that changes with the announcement of Windows Server AppFabric (which I blogged about here). What Sriram showed was a preview of what it make look like if WF were integrated into BizTalk.
From a BizTalker and SOA perspective, I really like the idea of having WF integrated into BizTalk, as it makes it centralizes the service composition mechanisms, and to some degree, helps mitigate the “when to use what” question as that can be reduced to a set of “common” guidelines. However, what he showed goes well beyond just using BizTalk projects as a shell from which to get at the WF designer, the integration goes much deeper than that, even in this early prototype. Bringing WF into BizTalk doesn’t change BizTalk, it extends it.
Here’s look at this from a Visual Studio perspective, notice the XAMLX files in a BizTalk project. Notice also the workflow designer. This is the same workflow designer that people will be used to working with Visual Studio 2010.
Bringing WF into the BizTalk environment brings benefits to the WF developers too. One of those is mapping, the screen shot below shows how you can have either a data contract or a schema on both source and destination sides, and regardless of which you pick, the experience is the same. That also means you get all of the new BizTalk Server 2009 R2 mapper goodness that I blogged about here. From there, as Sriram shows at about the 45 minute mark of his presentation, it’s a one-click operation to generate a workflow custom activity to invoke that map, and you can then work with in the WF designer by just dragging it from the palette onto the design surface.
From a deployment perspective, there was a crude prototype shown, this is obviously not what it would look like in final release. The thing to notice here is the fact that the workflow is being hosted in the BizTalkServerApplication host. So, if you follow that logic a step further (rampant speculation on my part!), then that means you could use the standard BizTalk host instance model to have certain workflows running in certain hosts, and then you have instances of those hosts on selected machines.
There’s a lot of cool stuff in this video, and it points to an interesting convergence of technologies in a future release of BizTalk. It also raises a bunch of questions for me, and adds to a long wish list (which I’ve communicated to the team :)). The bottom line though is that WF integration will give BizTalk developers the ability to handle low latency scenarios in a standard framework supported way, and it also add value for WF developers, as it provides them with the possibility of migrating their workflows into BizTalk and gaining additional capabilities as they do so.
What about Windows Server AppFabric and Windows Azure AppFabric?
What remains to be seen is how this fits into AppFabric, something the team is exploring now. An obvious one to me (rampant speculation!) is that AppFabric is just another host for the workflow (as it could be if the workflow were not part of a BizTalk project), be it Windows Server AppFabric or Windows Azure AppFabric, however perhaps getting there through the BizTalk deployment model and taking things like transformation activities with it. Even today, with BizTalk Server 2009, we have integration from BizTalk into Windows Server AppFabric (and also in the other direction) by going through WCF. So, the integration exists, and will only get deeper in future releases.
Finally.
The last point I want to make is something that may or may not be clear from these two BizTalk announcements. The announcements show Microsoft’s firm commitment to the 10,000+ current BizTalk customers, as well as to the product itself. The capabilities planned for BizTalk Server 2009 R2 and the capabilities shown last week for the release beyond that show the level of commitment and investment that Microsoft is making in the platform. As an insider who’s been involved with BizTalk since before the first release, I can tell you that the degree of enthusiasm and excitement in the product team is very, very real. They have great vision, and the resources they need to execute on that vision. The future keeps getting brighter, this has been a fun ride, and it looks like we have even more fun ahead.
The video of all of this is at http://microsoftpdc.com/Sessions/SVR15. The things I’ve talked about in this post are in the second half of the video.