The BizTalk Server team blog sneaked out an announcement yesterday that you might have missed. I caught it due to an RSS feed. BizTalk Server 2010 R2 is coming. Now the question is when, and a better question will they change the name, as they should to BizTalk 2011?

We have a while to wait, no firm dates yet, but since it adds support for Windows Server 8 and SQL Server 2010 (codename Denali) which don’t have announced release dates yet either, that isn’t too much of a surprise. They are saying about six months after those products release. Support for Visual Studio 11 was also part of the announcement.

It doesn’t sound at all earth shattering, more just a bit of a jiggle. It may calm some of the fears as they are frequently bandied about from the title of the article, that BizTalk is a dying breed. Rest assured that QuickLearn will be on the forefront of training for this new product as soon as a beta is available.

In addition to support for the new platforms another point of interest is a change to licensing making it possible to provide BizTalk as a hosted service , and to transfer a license to a hosting provider. This is obviously a step in moving BizTalk into the cloud, a change that has long been planned. We’ll have to see what that means as to whether Microsoft will be a possible provider themselves (a la Office 365 and SharePoint online).

That’s about it for what’s new unless you are interested in IBM host integration there are some adapter improvements that way. For the whole article check out the BizTalk Team blog at http://blogs.msdn.com/b/biztalk_server_team_blog/archive/2011/12/08/biztalk-server-2010-r2.aspx

Until next time, see you in the funny papers.

OK, think fast! Name three features of BizTalk that you really love. Now name three that “need some work”. If you have been around BizTalk for more than a few weeks your answers to both of these questions included: “You mean I am limited to three?”, and the two lists likely have some overlap.

If you are reading this, you are interested in knowing what the future of BizTalk is, as am I. It seems that every time Microsoft releases a new technology such as the .NET framework 3.0 (with WF and WCF), Oslo, Dublin, Azure, AppFabric, whatever, the eminent demise of BizTalk is debated. These rumblings have been rolling around once again.

BizTalk isn’t perfect but warts and all it is, in my humble opinion, the best integration option out there. Most of what we know as BizTalk Server today has remained unchanged since BizTalk 2004. Sure there have been some improvements to the interface, and some performance tweaks, and some features have been added, (WCF and EDI support most notably) but the core processing engine has remained untouched.

In no small part I think this is because with an installed base of well over 10,000* customers worldwide Microsoft realizes that the transition to the next BIG version of BizTalk can’t look like the process of upgrading from BizTalk 2002 to 2004. That transition for those of you lucky enough to miss it was more of a wholesale rewrite then a simply upgrade.

The changes that are needed to bring integration into the current decade will be dramatic and will necessarily take some time; maybe even into the next decade if the timeline hinted at by Tony Meleg is anywhere near accurate. In a presentation given at the 2011 Microsoft Worldwide Partner Conference July , 2011, Tony outlined the roadmap for the next few versions of BizTalk and how that is going to play with technologies such as WF, WCF and AppFabric. http://digitalwpc.com/Videos/AllVideos/Permalink/e821e9f8-e379-45b0-8879-12fe271c86be#fbid=VRTVG4xyzMQ

In the presentation Tony identified some customer requests that they are hoping to address over the next few iterations of BizTalk and in the interim with Microsoft’s newest favorite buzzword “AppFabric”. I’ll discuss some of his requests later but for now on to…

My BizTalk Asks

Your list may vary from mine, and I am not going to limit myself to three “needs some improvement” features, but here goes, in no particular order:

Easier control over message box persistence: Since BizTalk always persists every message; it isn’t designed for super-low latency scenarios. Many people have asked for an easy switch to turn off persistence when it isn’t needed, and this happens more often than you might believe. Some competing products have taken a different approach, that is they don’t persist any messages, thus their throughput is much improved. In these systems when persistence is turned on, (frequently requiring additional servers and licenses) their performance positively tanks. This request is not a “simple-fix” since BizTalk at its very core is a publish/subscribe (hub and spoke if you prefer) engine.

Dynamic orchestration filtering: As BizTalk developers we are very aware changing the subscription for an orchestration isn’t a configuration change so much as a coding change. This typically requires versioning considerations, retesting, redeployment, etc. Although a well thought out orchestration design can reduce the frequency of these changes, when changes are necessary the process can be painful. Having a more loosely coupled holistic approach to the end-to-end design, including exposing the orchestration filter as configuration (much as send ports already are) would assist greatly in this area. This has been a long-term request of experienced BizTalk developers.

Support for mirrored databases: Many BizTalk administrators that we work with have asked why mirroring is not supported for the BizTalk databases. This is really more of an issue for the SQL team since that is where the issue originates. SQL server does not support mirroring of transactional databases (though clustering is of course supported). Since most of BizTalk’s core databases communicate with each other transactionally this is a big change and not one that can be implemented by the BizTalk team alone.

ESB like capabilities easier to implement: This is really two requests in one. First it seems that the ESB way of dealing with exceptions really should just become the default. Expecting operations personnel to troubleshoot problems using only the Group Hub and event logs seems rather arcane when compared to the slick web based interface available with the ESB management portal. Second for those companies that desire itinerary processing abilities as available in ESB I’d like a switch that turns that on. Of all the items in the list this one (seemingly) would be the easiest to implement, and may be coming to BizTalk sooner than some of the others.

Ability to change the host used by dynamic send ports: This is a sub-request related to the preceding one. Since the ESB toolkit so heavily leverages dynamic send ports, the ability to change what host they are running on would be really nice. While we are on the topic, how about the ability to dynamically change the pipeline and/or map used by a dynamic port. This feature is effectively offered using the ESB toolkit, but how about making it easier if I don’t want the “whole itinerary thing?”

Callback support for WCF adapters: I’d like to be able to have a client initiate a process via a web service call and then have the process call the client back when it completes. This is certainly supported in WCF itself but at present neither BizTalk’s WCF adapters nor AppFabric supports callbacks.

Microsoft’s BizTalk Asks

In his presentation Tony identified several additional Asks that Microsoft has identified. I don’t doubt that some customers have asked for these features but some of them are going to be big for Microsoft as well.

Low Latency: (already discussed above).

More Flexible Messaging: Tony ignored this point in the presentation so I’m going to say I have addressed it in my Asks above.

Alignment to Windows Workflow: This means different things to different people. Tony identified it as “replace the orchestration engine with the WF engine”. I myself don’t really care whether we call it an orchestration or a workflow what I want is scalability and robustness which at least (so far) we don’t really have in WF. Would it make sense to do this? Sure, having a single engine to maintain makes a lot more sense than two very similar engines but this will not be a trivial change, (Tony identified it as “heart surgery”!)

Put BizTalk on Azure: This seems to have become Microsoft’s solution to almost everything, and who can blame them? Instead of selling you software that you pay for and install once, how much better to sell you software as a service where you get the latest and greatest functionality instantaneously (plus for you) and Microsoft gets to charge you over and over again for it, (plus for Microsoft). That’s what we call a win-win situation? Considering the issues that all cloud providers have experienced over that last few months I think it is going to be a while until companies are going to be fully comfortable outsourcing something as mission critical as integration.

Service Virtualization/Discovery/Tooling: As services become more ubiquitous there is a definite need to enable automatic discovery and integration with these services. Whether the provider and/or consumers are BizTalk this need exists. UDDI held the initial promise for a part of this, while for other parts Microsoft hasn’t really offered a solution. This is one of those things that the BizTalk team likely won’t own, but they have a tight dependency on the eventual solution, whatever it may be.

And I’m going to lump Tony’s last two bullets together: Align Business Rules, and Invest in BAM, improve tooling and make them work across the Microsoft stack: As any of my former students can attest to, I am a huge proponent of using these two features of BizTalk. They are each easy enough to implement if you are using orchestrations, but their abilities go so far beyond that, and I don’t think Microsoft has done a good enough job selling them. For a long time I have seen these as two pieces that could certainly be spun off to stand alone and simply be used by BizTalk as they could be by any other .NET component. As much as I’d hate to see them go, I welcome all developers to use them, so long as we still can!

Any one of these features on its own could; if really fixed to my satisfaction, be quite an effort. Taken as a collection they are going to be very challenging and will necessarily take a long time. The cadence that has been identified is that the changes will come first to the AppFabric space and will be evolutionary, two to three releases per year. I see AppFabric as an incubator where some features will live, some will die, and where change will be frequent. If you are not comfortable with living on the bleeding edge I’d stay clear for now.

BizTalk will continue to be developed and new releases will come every couple of years. The best and the brightest of the AppFabric changes will be integrated a few at a time. If you remember WSE 1.0, 2.0, 3.0 which finally morphed into WCF, the cycle will be similar with AppFabric being the WSE releases and BizTalk being the WCF release.

When I look at BizTalk as a 10 year old product, and considering that the evolution to the eventual BizTalk replacement at least as Tony sees it is being 10 years, I’m feeling pretty good about my decision to stick with BizTalk Server, but I’m also going to keep a weather eye on WF, WCF, and all the AppFabric(s).

For anyone that read this whole thing and watched Tony’s presentation here is my concept of a cloudy thing! Asperatus is a new and upcoming type of cloud. Maybe this should be the code name for the BizTalk in the cloud. It has to be better than v-next right?

*The latest published numbers for customers is from the BizTalk 2009 release and at that time the number was 10,500. With the previous years’ rates of growth this is likely approaching 12,000, but we can only speculate since Microsoft has not released more recent numbers.

Students frequently ask my opinion on which BizTalk Books will be most helpful. I have reviewed several books, and will recommend a few of them here. I haven’t really seen any terrible BizTalk 2006 books (and believe me, I have seen some terrible technical books in the past!), so this is really a ranking of several really good books. It should be noted that many of the books below mention BizTalk Server 2006 R2 only in passing, because they were all written prior to the release of R2. I do not know if updates are planned for them.

In the interest of full disclosure, I should mention that QuickLearn has received a slew of books from Apress that we occasionally pass out in classes (thanks, Apress). Also, Darren Jefford, the author of one of the other books, is a friend and has provided signed copies of books that we have given away at various conferences. Despite my affiliations, I hope to provide a fair assessment of the literature.

The top of my list is Professional BizTalk Server 2006, by Darren Jefford, Kevin B. Smith, and Ewan Fairweather, published by Wrox Publishers. "Wrox" is pronounced like "Rocks," which is exactly what this book does. It’s very telling that, as I was writing this post, Amazon has eight listed reviews, and all eight give the book full marks (five stars) - I would definitely give it the same. Because this book assumes a moderate level of existing BizTalk knowledge, it is definitely not a good book to learn BizTalk from scratch (it's a great companion book to our Deep Dive). Nevertheless, it's a book by three guys who have been there, done that, and own the tee shirt when it comes to BizTalk implementation. This is a book that I refer to frequently.

Coming in at a close second on my list of favorites is Pro BizTalk 2006, by George Dunphy and Ahmed Metwally, published by Apress. (These books share more than a similarity in their names!) This is also an excellent book with very similar coverage to the Wrox book (Deep Dive level). If you own either of these books, you’re in good shape. I prefer the writing style of the authors of the Wrox book, but you may like this one better. Either one or the other of these is great, but you probably won’t need both.

If you’re looking for a book for someone totally new to BizTalk, consider Foundations of BizTalk Server 2006, by Daniel Woolston, published by Apress. This book contains good, concise description of common BizTalk terms (BizTalk vocabulary on steroids), and is a great pre-class primer for QuickLearn's BizTalk Server Developer Immersion. If you've already attended any of QuickLearn's BizTalk classes, you will probably find this book overly simple.

If you've identified a problem in your design/development, and you're looking for a quick way to solve it, your best choice is BizTalk 2006 Recipes: A Problem-Solution Approach, by Mark Beckner, Ben Goeltz, Brandon Gross, and Brennan O'Reilly, published by Apress. This may not be the best book for learning BizTalk from scratch, but it's a necessity for every BizTalk shop. This book takes a no-nonsense approach to "Here’s the problem, now how do I fix it?", and identifies the implementation of the patterns necessary to solve the problem.

Although not a BizTalk book, per se, a good general overview of messaging and other integration patterns can be found in Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, by Gregor Hohpe and Bobby Woolf. DO NOT EXPECT TO LEARN ANYTHING ABOUT BIZTALK FROM THIS BOOK! I am recommending this book as an excellent resource about integration in general non-Microsoft terms; however, many BizTalk-related documents, available from Microsoft sources, reference the patterns revealed in this book. So do the BizTalk 2006 scenarios (more on these later, if you aren’t familiar with them). Gregor maintains a site http://www.eaipatterns.com that contains much of the information available in the book, but the book still makes a great paperweight, (it’s big and hardcover) J. I have been referencing it in my classes for so long that I thought I better mention it here as well.

QuickLearn is in the process of updating our now famous BizTalk Deep Dive course (NEW and IMPROVED!). As I have been collecting and reviewing content for the advanced mapping module, I am reminded of one of the most common "Eureka" moments for many students is the realization of just how easy it is to create custom maps without using functoids. Many people come to BizTalk after having developed a custom integration project that required them to create their own XSLT. Often I am asked, "Can’t I leverage the work that I've already done and use the XSLT I’ve created? Do I have to use all those functoids?” The answer: Of course you can use your own XSLT, and some of the best maps do! You really have three options here: The first two involve the use of Scripting functoids; the third relies strictly on the XSL that you provide.

Inline XSLT

Many times, the result of chaining several functoids together can be more concisely defined in a little custom XSL. When using the inline XSLT option, the Scripting functoid cannot have any input links; rather, it should contain references to the source schema nodes through XPath expressions. The functoid must link directly to a record or field in the destination schema (it cannot be input for other functoids).

Inline XSLT Call Templates

Like an inline XSLT script, the inline XSLT call template must connect directly to a destination node; however, it may receive input through links coming from other functoids, or from the source schema. On the map grid, setting the Custom Extension XML property enables Scripting functoids, configured as either Inline XSLT or Inline XSLT Call Templates, to make calls to external assemblies.

Custom XSLT Code (Look ma, no functoids!)

If you have XSLT code you have written to convert instance messages, you can use that code directly, instead of creating a map.

1. Create an empty map and set the source and destination schemas as you normally would.
2. With the map grid selected, configure the Custom XSLT Path property to use the file containing your custom XSL.

NOTE – Using custom XSL overrides all links and/or functoids in the map.

Remember that you can always validate your map to access the generated XSL, which will be executed for the map. Also remember that maps do not validate the messages generated, except while testing in Visual Studio. The warnings you receive in Visual Studio provide design-time assistance to identify possible problems. BizTalk is totally content with generating exactly the message that you tell it to, valid or not!

Until next time, have a great day.