Microsoft announced BizTalk Server 2009 today, and gave the green light to talking about the new version. It’s due for release in the first half of next year, and is shaping up nicely. Microsoft is casting BizTalk Server 2009 as a major new version in its own right, rather than just an updated 'release' of BizTalk Server 2006. This is an important move, and one I strongly welcome. There is certainly enough in BizTalk Server 2009 to warrant thinking of it as a major revision of the product, although it retains the same familiar functionality and tooling we have been using since 2006 (or even 2004).
I've been fortunate in getting my hands on the current non-public CTP in the last month or so, and putting aspects of the new version through its paces. It's not wise to go into much detail about this first CTP because some of those details will doubtless change in forthcoming betas, driven in part from the feedback Microsoft is getting. However, I will say a little about the new development and build features and expand just a little on the press releases. These are the areas I have been looking at in depth.
BizTalk Server 2009 will ship with bindings for Visual Studio 2008, and you will need to upgrade to this version of the IDE if you are still using Visual Studio 2005 (which you will be, of course, if you are a BizTalk Server 2006 user). It happens that, in previous months, I've seen more than one BizTalk shop where developers are having to run both versions of the IDE side by side in order to continue developing for BizTalk Server 2006 whilst exploiting features like WCF and WF in .NET 3.5. For many, the changes in BizTalk Server 2009 will come as a relief. This is not a cynical ploy by Microsoft to force people into upgrades for no additional benefit. The move to Visual Studio 2008 is accompanied by a very welcome move to a new project format, bringing BizTalk Server 2009 into line with mainstream .NET development. The new BizTalk project type is defined using MS-Build, just like C# or VB.NET projects. This has major implications in a number of areas. First, it means that, if you use TFS Build, you can now build BizTalk Server 2009 projects without having to write complex scripts that shell out to DevEnv. Just like C# projects, you can let TFS Build do the majority of the grunt work for you, and concentrate your attention more fully on ensuring that your automated build scripts are comprehensive and robust. This is worth the upgrade in its own right, and removes a major source of current irritation. Thanks to the rough edges in the current CTP, one of my colleagues has had the opportunity to get to grips with this side of BizTalk Server 2009 in some depth, and we can report that it is all looking very good indeed, once a few remaining gremlins have been chased out.
The other aspect of BizTalk Server 2009 which we have spent some time on is unit testing and debugging. In one sense, this is not really so much about new functionality, but more about bringing what has previously been considered 'black-belt' into the mainstream. In Biztalk Server 2006, we currently use BizUnit to drive black-box (grey-box?), end-to-end testing, but we have also created some additional code of our own to support unit testing of BizTalk maps, schemas and pipelines. Similarly, if you know the undocumented registry key in BizTalk Server 2006, you can get BizTalk to retain the generated C# code for debugging purposes, manually attaching to BtsNtSvc.exe processes in order to debug into orchestrations, etc. This has proved a life saver in certain situations. The new version of BizTalk Server is now designed to support these approaches seamlessly. Of course, it is designed to work with the integrated unit testing features of the IDE, rather than BizUnit. There are currently some outstanding questions with regard to the debugging support which I won't go into here, because they simply reflect the unfinished state of the first CTP. However, unit testing certainly works smoothly with BizTalk Server 2009 projects, and will help to raise the bar in terms of the approach that is taken to development of BizTalk solutions. Again, I will avoid going into further here because I will hit issues that are still to be fully resolved, but things are generally looking good.
I have only mentioned those areas of BizTalk Server 2009 which I have been looking at in any depth. There is a lot, lot more. One thing I will monitor closely is the inclusion of ESB Guidance 2.0. I have some problems with some aspects of ESB Guidance 1.0, like the unfortunate way in which the UDDI resolver violates the UDDI standard! However, having spent the last year doing little else but designing and implementing service bus patterns using BizTalk Server and WCF (or, in one case, WSE), I regard the inclusion of ESB Guidance 2.0 as a really intriguing, and hopefully worthwhile, aspect of the new version. It is also intriguing that Microsoft has decided to release their implementation of UDDI 3.0 as part of the BizTalk package. Let no one tell you that BizTalk has no role to play in building service buses, or that it is to be regarded as 'merely a hub-and-spoke message broker'. In my experience, the exploitation of the dynamic features of BizTalk (dynamic ports, BAM interception, the rules engine, etc.,) in a rigorous, policy-driven fashion provides good support for implementing many of the core patterns described within the world of ESB. The core design of BizTalk Server predates later ESB thinking, but is much better aligned to it that some people will admit.
Roll on 2009.