A number of internal people in the field (myself included) have been working with the product team for a number of years now to help shape some of these new technologies and ensure they will address real-world customer scenarios based on our customer experience. It’s great to be able to start discussing what’s coming down the line, although the real detail won’t be available until the PDC.
So Dublin! Windows Server is our application server today and we’re now expanding it’s capabilities to deploy and manage .NET based applications (using WCF and WF) – no more roll your own!
If you appreciate the way BizTalk Server provides enterprise capabilities to host your Integration solutions today, you’ll see a lot of similarities in how these hosting capabilities are being introduced in “Dublin” for WCF and WF. For those who might have shied away from WF because of having to roll their own infrastructure, this is great news!
Note that in the press-releases that BizTalk is formally being referred to as an integration server, e.g:
Q: Will “Dublin” work with BizTalk Server’s enterprise connectivity services?
A: Yes. The integration server and application server workloads are distinct but complementary; customers want to be able to deploy them separately as needed to support their distinct requirements. For example, customers that don’t need the rich LOB or B2B connectivity provided by an integration server, will deploy the Windows Server application server to host and manage middle-tier applications. Likewise, customers that need to connect heterogeneous systems across an enterprise, but don’t need to develop and run of custom application logic, will deploy BizTalk Server. When customers need both capabilities, “Dublin” and BizTalk Server will work together nicely.
BizTalk is by no means “dead”, in fact Microsoft committed to future versions including BizTalk Server 2009 recently for the integration server workload, BizTalk = Integration, Dublin = Application.
So if you want to expose [WF] workflows via [WCF] services but ensure performance and scalability (up to enterprise scale), you can now do this without having to write the code required to host these apps on Windows Server. Ensuring performance and scale of WCF services and WF is hard to do today, hence it’s not done very often at least in my experience and sometimes causes a tendency to twist BizTalk into doing something it wasn’t necessarily designed to do which causes problems of their own (coupling Web Sites/UI’s directly to BizTalk for synchronous processing springs to mind).
We don’t want customers in this situation to be forced into writing huge amounts of hard plumbing code to achieve this, we need a server product to do this for you, which is where Dublin comes in. Note some of the server features announced which will be familiar to BizTalk developers (content based routing, compensation, etc.).
If however you need to use the extensive adapter support, B2B, EDI, RFID, BAM, BizTalk Mapper style features then you’ll still be wanting to use BizTalk. Both products will work together seamlessly through the WCF communication options so you can combine as appropriate.
Remember though that a number of BizTalk adapters have been re-written as WCF bindings and are available through the BizTalk Adapter Pack which offers some key LOB adapters. A new SQL adapter is in the works along with new Oracle adapters which you can find information on here. As these new adapters are exposed as WCF bindings you can leverage them with WCF and Dublin.
Dublin will also be the first and best consumer of the Oslo modeling platform, they’ll be more detail on this at the PDC but trust me – this is going to blow your minds!
WCF and WF get a big makeover as already announced, we get new workflow types in WF and an extension library of Activities out of the box. If you want to call a SQL stored procedure, why write half a page of code when you can just configure a database activity? Combine that with the 10x improvement in performance and things are looking good! Imagine a world when a typical software solution can be implemented (modeled) exclusively through a workflow and out-of-the-box activities? 😉
Notice also the subtle new feature in WF, “persistence control”. Low Latency scenarios with BizTalk are achievable but has to be carefully designed, we don’t currently have the ability in BizTalk to control when an Orchestration persists but imagine if we had this feature in WF – low-latency potentially becomes easier to achieve 😉
That’s enough for now, once more detail starts to emerge I’ll post some more information and will also work internally on locking down some clear “where to use what” style scenarios for BizTalk and Dublin using some real-world customer scenarios.