BizTalk Server is an enterprise product; there is no second thought about it. Any enterprise product will go through the phase of being left out with very older version on production environment. Ones the code is up and running in a production environment with live business, it becomes mission critical. Enterprise just don’t upgrade either their applications drastically or the platform on which they are running until there is a compelling business case behind it.
The organisation I’m working on is also in a similar situation, and I been tasked to put the future road map for BizTalk Server in the organisation. I just need to come up with proper reasons, why we should move on to latest version of BizTalk Server (keeping in mind the cost associated with it). We are currently on BizTalk Server 2006 (not R2), and our plan is to move to BizTalk 2009 R2 (skipping 2 versions in between 2006 R2, and 2009).
This list is not going to be exhaustive, the scenarios will vary from organisation to organisation based on the usage (example: B2B integrations, SAP integration, Health care with flat files etc). In our case we use BizTalk for couple of different scenarios.
- A BPM process, more like a human workflow kind of solution interfacing with one of our internal in-house BPM software.
- A composite Business Services layer on top of our middle tier integrations services.
So both the solution uses lot of standard Orchestrations, Maps, Schemas, WSDL, SOAP adapter, MQSeries adapter, and a custom adapter to talk to in-house BPM software, BizTalk web publishing capabilities, and BAM
Note: Some of the features were available in BizTalk Server 2006 R2 and BizTalk Server 2009 (example: WCF Support). This list just shows the cumulative gain for moving from BizTalk 2006 to BizTalk 2009 R2
Reason #1: Nearing end of life (EOF) mainstream support
This is our number one reason for thinking about moving to BizTalk Server 2009 R2.
| Product |
Mainstream Support Retired |
Extended Support Retired |
| BizTalk Server 2006 |
12/07/2011 |
12/07/2016 |
It’s not just the BizTalk server end of life threatens us; it’s also the end of life for Windows Server 2003 R2.
| Product |
Mainstream Support Retired |
Extended Support Retired |
Service Pack Retired |
| Windows Server 2003 R2 Enterprise x64 Edition |
13/07/2010 |
14/07/2015 |
14/04/2009 |
Running your solution on out of support platform is going to be expensive and results in indirect costs. Apart from the cost reason, there may be scenario where the support cycle may take longer time to resolve issues.
Reason #2: Platform upgrade and performance gain
Platform upgrade for moving from BizTalk Server 2006 to 2009 R2 looks like this
| From |
To (at least) |
| Windows Server 2003 R2 |
Windows Server 2008 R2 |
| SQL Server 2005 |
SQL Server 2008 R2 |
| Visual Studio 2005 |
Visual Studio 2010 |
BizTalk Server (environment) performance is always closely tied to the performance of the platform upon which BizTalk server is installed/running. BizTalk Server heavily depends on the performance of SQL Server and Windows server itself. So moving to the latest platform should provide considerable performance gain (depending on the scenario) on the same application code base.
Reason #3: Virtualization Support:
Virtualization support for BizTalk Server 2006 is on best effort basis. Meaning, if you can reproduce the problem on a physical environment, support will be provided. But with 2009 Hyper-V based virtualization is fully supported.
Licensing around Virtualization
Text Snippet from
http://www.microsoft.com/biztalk/en/us/pricing-licensing-faq.aspx
“
Similar to SQL Server Enterprise, BizTalk Server 2009 ENT can be licensed for unlimited virtualized processors that are available on a single physical server. The customer will be required to license the number of physical processors on a server.”
This is one of the key factors for us; we are seeing more and more projects getting done in BizTalk Server within the organisation. In some cases due to the volume and size of the project its not worth having a dedicated BizTalk Server environment at the same time due the criticality of the applications its not possible to run the applications in a shared environment.
With the support for virtualization and liberal licensing model, it will help us to isolate the applications from one another and keep the costs low.
Reason #4: Support for Windows Communication Foundation
This is one of the key factors for us to think about migration. The web service support on BizTalk server 2006 is provided primarily by the SOAP adapter and Web Services publishing wizard. By moving to 2009 R2 will open up the opportunity to Microsoft’s unified distributed platform Windows Communication Foundation (WCF) seamlessly from BizTalk Servers. WCF provides great enhancement like support for lot of WS * protocols. There is also considerable gain on the WCF adapter configuration.
Examples:
- Choice of Encoding,
- Transactions support using WS-Atomic Transaction
- Imposing restrictions of received message size,
- Better control on the incoming and outgoing message (whole envelope, body, and xpath)
Overall you’ll get better web services support compared to the SOAP adapter story.
Reason #5: Developer productivity enhancements
Just by moving to latest Visual Studio platform opens up a lot of productivity enhancements for developers.
BizTalk Server 2009 R2 enhanced the mapper productivity to great extend. This is the first major update for the mapper tool UI since BizTalk Server 2004. There are features like
- Moving links between pages
- Searching for nodes
- Hiding out of context nodes
- Auto scrolling to the active nodes
- Relevance tree – show
only mapped nodes, to reduce clutter etc
BizTalk Administration console improvements like:
- Ability to configure polling interval on host level
- Ability to export/import setting from one environment to another (ex PERF to PROD)
- Ability to setup host instance registry settings from console.
Support for testing maps.
This is not an extensive list, but you get the idea
Reason #6: Moving to IIS 7.0 from IIS 6.0
This is one of the less highlighted features. As part of platform alignment, it will help us to move from Internet Information 6.0 to 7.0. The difference between 6.0 and 7.0 is revolutionary. IIS 7.0 works on the principal of bare bone configuration, you add required modules your application demand. Again this is going to indirectly support your BizTalk environment configuration if your solution is heavily dependant on Web Services based SOA integration.
Reason #7: Support for new Visual Studio project template and support for MSBuild
BizTalk Server 2006 uses its own proprietary visual studio project template with its own extension points. This makes it harder to do things like MSBuild /Continuous integration etc. Moving to 2009 R2 will give consistent experience with other Visual Studio projects like class libraries.
Reason #8: Enterprise Service Bus (ESB) Toolkit 2.0
This will be one of the great candidates for moving to 2009 R2. Microsoft fully supports the Toolkit which got some nice features like Exception Handling framework with portal. Transformation service, Dynamic routing, construction composite services without using orchestration etc.
More information can be found at
http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx
Even though we are not using it at the moment, moving to 2009 R2 will help us think/architect new solution by taking some of the advantages of ESB Toolkit reducing the plumbing work.
Reason #9: Support for Host Integration Server 2009
One of the reasons for move to 2009 is the support for Host Integration Server 2009 which includes WCF Channel for WebSphere MQ support. Being an enterprise coming from IBM background its not a surprise we use MQ heavily in the organisation.
Reason #10: BizTalk Adapter pack and custom WCF LOB Adapter framework
This is one of the nice to have features for us.
Reason #11: Extended BAM Interceptor support for WCF and WF
BAM interceptors extend the functionality enjoyed by BizTalk server to Windows Workflow Foundation (WF), Windows Communication Framework (WCF), and other runtimes. By using the BAM interceptors, you can track your business processes without recompiling your WF or WCF solution – integration is done through a configuration file.
This ability provides the opportunity to bring your external WCF services to participate in the same BAM monitoring framework you build for your applications.
Also, Microsoft relaxed the licensing requirement to use BAM outside BizTalk Server Environment as long as you got a standard or enterprise license in your organisation (I can’t find any links to support this statement, but I remember that was the case).
Reason #12: Better system with cumulative bug fixes in the past 3 year.
The obvious one is cumulative bug fixes in the past 3 years.
Big downside if you don’t have a Microsoft software assurance
To upgrade from BizTalk Server 2006 to BizTalk Server 2009, you need to acquire Microsoft Software Assurance for BizTalk Server 2006. Acquiring Software Assurance for BizTalk Server 2006 will ensure you receive BizTalk Server 2009 at no additional cost. Otherwise, customers will pay full price for BizTalk Server 2009 if they want to upgrade.
There are various other areas of improvements like RFID, EDI, B2B, Share point integration, etc worth investigating based on your requirements. I also didn’t highlight lot of features, which we are not using example SCOM package upgrade, improved trading partner management etc
There are some deprecated features as well from 2006 to 2009 R2, but none of them are relevant to us.
- Human Work flow support
- Business Activity Services Support
- Migration of HAT functionality to BizTalk Admin Console, etc
Nandri!
Saravana
