Introducing Azure App Service

If you have been keeping up with cloud based platforms, I am sure that you have realized it has become a very competitive landscape.  Some cloud platforms focus on websites ,infrastructure, and database platforms, while others focus on integration or API management.  We even have Mobile backend as a service platforms that we can choose from. While organizations can choose to cherry pick from each of these different platforms, they can also get first class capabilities, that encompasses all of these domains, from Microsoft’s Azure platform.

At the Integrate 2014 conference in December, 2014 Microsoft gave us a preview of its next generation ‘App’ platform.  At the time, the term Microservice was being used to describe the “architecture style” of the applications that can be built using this new platform.  While the Microservice name did not make its way into the product, the concepts that were discussed at that event have not changed. The day has finally arrived when this Next Generation has emerged in the form of a Preview Service.  The name of this service is called Azure App Service.

For Microsoft this is a PLATFORM PLAY.  No longer do we see disparate product lines in the areas of Integration, API Management, Web Development, Mobility and Workflow.  In addition to these characteristics, we also have the rest of Azure that we can leverage including Service Bus, Analytic Engines(both Microsoft and 3rd party), Databases and Infrastructure.  When you think of all of these different capabilities, using a common platform, common authentication schemes, common tooling, common billing and a global reach for providing these services, Azure is more than just compelling.
Using the Azure App Service we can now create the following types of Apps:

• Web Apps
  • Build and deploy mission critical Web Apps that can leverage Azure’s hyper-scale capabilities.
• Mobile Apps
  • The evolution of Azure Mobile Services that allows developers to build engaging Mobile Applications.
• API Apps
  • Expose your own WebAPIs, consume APIs including 3rd party SaaS based connectors for many popular SaaS platforms.
• Logic Apps
  • Build workflow application in a declarative manner using a Web browser.

What are some use cases of an API App?
An example of an API app may be a SalesForce connector.  Consider a scenario where you have a mobile application that requires data from SalesForce.  There may be good reasons to place this request on a messaging bus (and don’t worry you still can!) but there may also be good reasons to plug into a connector directly.  Consider a low latency situation where you want to by-pass a monolithic ESB in favor of something lighter.  You could use an API Client library that allows you to consume this SalesForce connector without having a complicated auth scenario.   If you have ever looked at a Mobile Service client, you will feel very comfortable working with API App Client.  When I saw an insider’s demo of this functionality, I was really happy to see the similarities to a paradigm that I am used to.
Similarly, what if you have built an ASP.Net Web API and you want to consume it from a Web Application.  While it can be fun constructing a json message using a String Builder (not really), wouldn’t it be nice to leverage a strongly typed API Client instead?  Yes it would!  So once again much like Azure Mobile Services client we can use something similar in the form of an API App Client.
Another aspect of API apps is that Swagger is a first class citizen of Azure App Service.  We have the ability to generate contracts between the client and API Server which aids in having strongly typed client libraries.

A point worth making is that when building or consuming API apps you are in Visual Studio and there is an accompanying Visual Studio SDK to leverage in order to build or call these API Apps.
Another interesting aspect of this platform is the Cross Platform capabilities.  You can choose to build your APIs in the language of your choice (Java, PHP, Node.js, Python + .Net) and expose them as an HTTP endpoint which you can then consume from other applications.

What are some use cases of a Logic App?
A Logic App is really a workflow application.  Personally, I am not a big fan of Logic App name but it is preview so maybe it will change.  One of the first questions that comes to mind is this workflow based upon Windows Workflow and the answer is no.  Perhaps this is why Microsoft stayed away from using “Workflow App”.

What is interesting about a Logic App is that this is a Workflow that you would construct in a Web Browser without writing code. While some people have made some references to IFTTT (If This Then That), Microsoft feels that this is a much more robust, Enterprise grade, platform.
Below is a screenshot of a “work in progress” Logic App. In this example we can retrieve records from SQL Server, create contacts in Salesforce and then send a welcome tweet all without writing a line of code.

In order to add a connector we simply drag and drop it onto our Logic App canvas and then configure it.

A question you may be asking is well if I am composing a workflow in the cloud, how can I add some version control around this?  Behind the scenes, the Logic App Workflow itself is based upon JSON and we have the ability to save/export this JSON data and subsequently store in TFS/GIT etc.

So where does BizTalk(Integration) fit into this platform?
The BizTalk brand continues to exist both on-premise in its BizTalk Server sku but also in the form of an API App or what is being called a BizTalk API App.  Since building integration applications requires more than just connectivity we can expect to still perform valuable functions such as:

• Rules Engine
• Batching/Debatching
• Encoders/Decoders
• VETR messaging patterns (Validate, Extract, Transform, Route)
• EDI
  • X12
  • EDIFACT
  • AS2
• Hybrid Connectivity

We can drag these BizTalk API Apps onto our Logic App Canvas much like any other connector. I have highlighted a few of them.

It is important to remember that this is a Platform play.  BizTalk, within Azure, now participates in the broader platform.  You can think of the platform as a series of building blocks.  As a developer you now have the ability to select the different building blocks that you need in order to build a compelling solution.  As an example of the breadth of this platform, you do not see Workflow currently listed in the BizTalk section, but that doesn’t mean that the capability doesn’t exist.  This is a capability that is part of Logic Apps. As a BizTalk person we need to start thinking more about Azure and that is a good thing due to the vast amount of capabilities that exist.  Let’s be honest, in the past BizTalk seemed to be a distant cousin of Azure, but it clearly has a place at the family table in this new paradigm.

This is good news for developers.  In the past BizTalk has been accused of being too bulky of a platform with too much ‘lift’ required for developers to be productive.  With this new platform Microsoft is democratizing integration and bringing the toolset that BizTalk Developers are used to using to a broader audience.  This will enable more use cases that involve BizTalk and as a result we will see more integrated Web and Mobile applications leveraging BizTalk capabilities.
In addition to these core BizTalk API capabilities we will also see Connectors in the form of SaaS Connectors, Premium Connectors and Protocol Connectors.
SaaS Connectors

• Office 365
• SalesForce
• Sugar CRM
• OneDrive
• DropBox
• Marketo
• Facebook
• Box
• QuickBooks

We will also see Premium Connectors in the form of:

• SAP
• Seibel
• Oracle
• DB2

and Protocol Connectors in the form of:

• FTP
• SFTP
• POP3/IMAP
• SMTP
• HTTP
• SOAP

Conclusion
I have heard many people refer to this release as the “Back to BizTalk 2004” release.  What I mean by this is that back in 2004, Microsoft released BizTalk which at the time was the most modern Integration platform available.  While we are still in preview and there is a lot to learn, there are a lot of expectations about this release.  The current version of BizTalk is extremely robust, but it could benefit by having some very modern capabilities and being able to efficiently run in the cloud.  What we are seeing today are the initial steps of BizTalk once again becoming the most modern Integration platform available. 

One particular pattern that I am going to be interested in exploring is the hybrid connectivity scenarios that exist.  As you may have noticed above, we do have an Azure Service Bus Connector.  We also have an Azure Service Bus Adapter in BizTalk Server.  So suppose you have an async messaging requirement that involves on-premises systems but you want to tap into one of these cloud based systems.  Well now you can leverage the Service Bus to ‘bridge’ your on-prem envionment with the Azure App Platform Service where we can then leverage one of these fancy new SaaS connectors to talk to SaaS system like Box, Marketo, Dropbox etc without having to do any custom work in BizTalk Server.  It allows you to take advantage of robust on-premise messaging while tapping into modern, SaaS base connectivity and allows you to migrate these workflows to the cloud at a cadence that you are comfortable with and that make business sense.

It is also worth mentioning that I am just scratching the surface on these new capabilities and we are still in Preview mode.  I think being a Microsoft platform developer is going to get even more exciting than it already is.  I think developers will be able to build some compelling, mobile, connected apps using a vast array of building blocks.
Expect much more to come on this blog regarding this release.

Upcoming Presentation: BizTalk Boot Camp

 

BizTalk Boot Camp 2015 – Microsoft Campus, Charlotte North Carolina

In addition to me speaking at the BizTalk Summit in London,  I will also be speaking about Azure API Management at the BizTalk Boot camp at the Microsoft campus in Charlotte on April 29th/30th.

I had the opportunity to speak at this event two years ago and was happy to come back.  The event is being organized by Mandi Ohlinger who works for Microsoft and is responsible for a lot of the technical content that you find on Azure BizTalk Services and BizTalk Server.

This is a free event and registration is required.

My topic will be an introduction to Azure API Management and how you can leverage this new Azure capability with your existing BizTalk Services.

Upcoming Presentation: BizTalk Summit

 

BizTalk Summit 2015 -  April 13/14 London, England

The BizTalk Summit has become an annual, must attend, event in London.  This event is once again being organized by BizTalk360 in conjunction with Microsoft and the BizTalk Product group.  BizTalk360 has organized several large events and I expect this one to be even bigger than some of the other events they have hosted including the very successfully Integrate 2014 event they put on in Redmond in December 2014.

There have been over 250 attendees registered and you can still take advantage of some discounted tickets being available.  This event provides a great opportunity to learn and network with Integration experts from all over the world including Microsoft BizTalk and Service Bus product team members.  Please visit this link for registration information.

My buddy Sandro Pereira has put together a blog post called Top 7 reasons to attend BizTalk Summit 2015 which I thought was an interesting read.  You can take a look at that article here.

Recently, some of the BizTalk Summit session abstracts have been posted, including mine, so I thought I would update my blog as my the sessions were not public when I previously announced I would be speaking.

My topic is on API Management and more specifically Azure API Management.  You can read the details below.

Session Abstract

API Management Part 1 – An Introduction to Azure API Management

Building APIs is not just about technology. APIs enable many new business opportunities, but only if done correctly. As a result of lucrative opportunities, many Software vendors have emerged or pivoted from their SOA management roots to provide API Management capabilities. These API Management platforms provide the building blocks behind a successful API program.

In this session, Kent will introduce you to Microsoft’s Azure API Management platform by providing an overview that highlights its capabilities and the opportunities that emerge for organizations. As part of this presentation, Kent will demonstrate how developers can create their first API and discuss strategies for transforming existing services to leverage Azure API Management.

This presentation will consist of general guidance on API Management, an Azure API Management portal walk-through and demos that re-enforce the concepts that were introduced.

You may be asking yourself – “Part 1” well what is “Part 2”?  There will be another session that includes Azure API Management by Tomasso Groenendijk. We have been working together to ensure there is no overlap and he will pick up where I leave off from an Azure API Management capability perspective.  

BizTalk Summit 2015 – London

Last year I had the opportunity to participate in the BizTalk Summit in London.  It was a great event with more than 200 attendees from 20 different countries present.  For a recap of this trip please check out this blog post.

I was recently asked if I was interested in coming back to speak at this year’s event which I gladly accepted.

More details will be available in coming weeks but the agenda is shaping up to be excellent with sessions from the BizTalk Product group, other Microsoft employees and several Microsoft Integration MVPs. I think this event will be even bigger than the recent Integrate event in Redmond which was a big success.  If you are in Europe, you do not want to miss this event.

My session abstract has been put forward and should be up on the event website in the coming days so I don’t want to ruin that surprise, but you can expect it to be focused on Azure API Management and how it plays a role in a BizTalk developer’s toolset.

Integrate 2014 Summit

 

Recently Microsoft and BizTalk360 have announced the continuation of the Global BizTalk Summit that is held annually in the greater Seattle area.  This year the event moves from downtown Seattle to Redmond and has been branded Integrate 2014. The event will take place December 3rd – 5th, 2014 on the Microsoft campus.  If you are interested in Microsoft Integration technologies, this is a must attend event. 

Based upon the current Session Schedule you will be exposed to:

• New BizTalk Adapter Framework for BizTalk Services
• New Workflow designer in BizTalk Services
• New BizTalk Rules Engine in BizTalk Services
• B2B Improvements in BizTalk Services
• Internet of Things (Service Bus)
• Hybrid Connectivity
• Azure API Management
• Customer Success Stories
• Ask the Experts (MVP) interactions

As you can see there is a lot of unique and progressive content on display at this event.  I will be attending the event as will many other familiar faces from the Microsoft Integration community.

Registration is now open and there are some early bird tickets available until November 15th, 2014.

See you there!!!

BizTalk Summit 2013 Wrap-up

On November 21st and 22nd I had the opportunity to spend a couple days at the 2nd annual BizTalk Summit held by Microsoft in Seattle.  At this summit there were approximately 300 Product Group members, MVPs, Partners and Customers.  It was great to see a lot of familiar faces from the BizTalk community and talk shop with people who live and breathe integration.

Windows Azure BizTalk Services reaches GA

The Summit started off with a bang when Scott Gu announced that Windows Azure BizTalk Services has reached General Availability (GA)!!!   What this means is that you can receive production level support from Microsoft with 99.9% uptime SLA. 

 

During the preview period, Microsoft was offering a 50% discount on Windows Azure BizTalk Services (WABS).  This preview pricing ends at the end of the year.  So if you have any Proof of Concept (POC) apps running in the cloud that you aren’t actively using, please be aware of any potential billing implications.

Release Cadence

The next exciting piece of news coming from Microsoft is the release cadence update for the BizTalk Server product line.  As you have likely realized, there is usually a BizTalk release shortly after the General Availability of Platform updates.  So when a new version of Windows Server, SQL Server or Visual Studio is launched, a BizTalk Server release usually closely follows.  Something that is changing within the software industry is the accelerated release cadences by Microsoft and their competitors.  A recent example of this accelerated release cadence is Windows 8.1, Windows Server 2012 R2 and Visual Studio 2013.  These releases occurred much sooner than they have in the passed.  As a result of these new accelerated timelines the BizTalk Product Group has stepped-up, committing to a BizTalk release every year!  These releases will alternate between R2 releases and major releases.  For 2014, we can expect a BizTalk 2013 R2 and in 2015 we can expect a full release.

BizTalk Server 2013 R2

So what can we expect in the upcoming release?

• Platform alignment(Windows, SQL Server, Visual Studio) and industry specification updates (SWIFT).
• Adapter enhancements including support for JSON (Yay!), Proxy support for SFTP and authorization enhancements for Windows Azure Service Bus.  A request I do have for the product team is please include support for Windows Server Service Bus as well.
• Healthcare Accelerator improvements.  What was interesting about this vertical is it is the fastest growing vertical for BizTalk Server which justifies the additional investments.

 

Hybrid Cloud Burst

There were a lot of good sessions but one that I found extremely interesting was the session put on by Manufacturing, Supply Chain, and Information Services (MSCIS).  This group builds solutions for the Manufacturing and Supply Chain business units within Microsoft. You may have heard of a “little” franchise in Microsoft called XBOX.  The XBOX franchise heavily relies upon Manufacturing and Supply chain processes and therefore MSCIS needs to provide solutions that address the business needs of these units.  As you are probably aware, Microsoft has recently launched XBOX One which is sold out pretty much everywhere.  As you can imagine building solutions to address the demands of a product such as XBOX would be pretty challenging.  Probably the biggest hurdle would be building a solution that supports the scale needed to satisfy the messaging requirements that many large Retailers, Manufacturers and online customers introduce.

In a traditional IT setting you throw more servers at the problem.  The issue with this is that it is horribly inefficient.  You essentially are building for the worst case (or most profitable) but when things slow down you have spent a lot of money and you have poor utilization of your resources.  This leads to a high total cost of ownership (TCO). 

Another challenge in this solution is that an ERP is involved in the overall solution.  In this case it is SAP(but this would apply to any ERP) and you cannot expect an ERP to provide the performance to support ‘cloud scale’.  At least not in a cost competitive way. If you have built a system in an Asynchronous manner you can now throttle your messaging and therefore not overwhelm your ERP system.

MSCIS has addressed both of these major concerns by building out a Hybrid solution. By leveraging Windows Azure BizTalk Services and Windows Azure Service Bus Queues/Topics in the cloud they can address the elasticity requirements that a high demand product like XBOX One creates. As demand increases, additional BizTalk Services Units can be deployed so that Manufacturers, Retailers and Customers are receiving proper messaging acknowledgements.  Then On-Premise you can keep your traditional capacity for tools and applications like BizTalk Server 2013 and SAP without introducing significant infrastructure that will not be fully utilized all the time.

Our good friend, Mandi Ohlinger ,who is a technical writer with the BizTalk team, worked with the MSCIS  to document the solution.  You can read more about the solution on the BizTalk Dev Center.  I have included a pic of the high-level architecture below.

While Microsoft is a large software company(ok a Devices and Services company) what we often lose sight of is that Microsoft is a very large company (>100 000) employees and they have enterprise problems just like any other company does.  It was great to see how Microsoft uses their own software to address real world needs.  Sharing these types of experiences is something that I would really like to see more of.

Symmetry

(These are my own thoughts and do not necessarily reflect Microsoft’s exact roadmap)

If you have evaluated Windows Azure BizTalk Services you have likely realized that there is not currently symmetry between the BizTalk Service and BizTalk Server.  BizTalk Server has had around 14 years (or more) of investment where as BizTalk Services, in comparison, is relatively new.  Within Services we are still without core EAI capabilities like Business Process Management (BPM)/Orchestration/Workflow, Business Activity Monitoring (BAM), Business Rules Engine (BRE), comprehensive set of adapters and complete management solution.

With BizTalk Server we have a mature, stable, robust Integration platform.  The current problem with this is that it was built much before people started thinking about cloud scale.  Characteristics such as MSDTC and even the MessageBox have contributed to BizTalk being what it is today (a good platform), but they do not necessarily lend themselves to new cloud based platforms.  If you look under the hood in BizTalk Services you will find neither of these technologies in place.  I don’t necessarily see this as a bad thing.

A goal of most, if not all, products that Microsoft is putting is the cloud is symmetry between On-Premise and Cloud based offerings.  This puts the BizTalk team in a tough position.  Do they try to take a traditional architecture like BizTalk Server and push it into the cloud, or built an Architecture on technologies that better lend themselves to the cloud and then push them back on premise? The approach, going forward,  is innovating in the cloud and then bringing those investments back on-premise in the future.

Every business has a budget and priorities have to be set.  I think Microsoft is doing the right thing by investing in the future instead of making a lot of investments in the On-Premise offering that we know will be replaced by the next evolution of BizTalk.  There were many discussions between the MVPs during this week in Seattle on this subject with mixed support across both approaches. With the explosion of Cloud and SaaS applications we need an integration platform that promotes greater agility, reduces complexity and addresses scale in a very efficient manner instead of fixing some of the deficiencies that exist in the current Server platform. I do think the strategy is sound, however it will not be trivial to execute and will likely take a few years as well.

Adapter Eco-system

Based upon some of the sessions at the BizTalk Summit, it looks like Microsoft will be looking to create a larger ISV eco-system around BizTalk Services.  More specifically in the Adapter space.  The reality is that the current adapter footprint in BizTalk Services is lacking compared to some other competing offerings.  One way to address this gap is to leverage trusted 3rd parties to build and make their adapters available through some sort of marketplace. I think this is a great idea provided there is some sort of rigor that is applied to the process of submitting adapters.  I would not be entirely comfortable running mission critical processes that relied upon an adapter that was built by a person who built it as a hobby.  However, I would not have an issue purchasing an adapter in this fashion from established BizTalk ISV partners like BizTalk360 or /nSoftware.

Conclusion

All in all it was a good summit.  It was encouraging to see the BizTalk team take BizTalk Services across the goal line and make it GA.  It was also great to see that they have identified the need for an accelerated release cadence and shared some news about the upcoming R2 release.  Lastly it was great to connect with so many familiar faces within the BizTalk community.  The BizTalk community is not a huge community but it is definitely international so it was great to chat with people who you are used to interacting with over Twitter, Blogs or LinkedIn.

In the event you still have doubts about the future of BizTalk, rest assured the platform is alive and well!

BizTalk 2010 R2 CTP meet BizTalk 2013 Beta

Microsoft released some exciting news on Monday for people who live and breathe Middleware.  They have released BizTalk 2010 R2 CTP’s successor: BizTalk 2013 Beta.  The new name signifies a major release and rightfully so, it does deserve it.

Back in June 2012, I was at TechEd North America where the BizTalk team provided a glimpse into the future of BizTalk.  At that point, I did feel that they were adding enough new functionality to warrant the full release but it was only until today that they officially announced the name change.

What is included in this release?

Many of the features that they did speak to at TechEd have been included in the CTP including:

• Integration with Cloud Services via SB-Messaging Adapter
• Support for RESTful Services (both Send and Receive)
• Platform Support (Windows Server 2012, Visual Studio 2012 and SQL Server 2012)
• Azure BizTalk VMs (IaaS)

The BizTalk team has now added some more features within the Beta including:

• Enhanced SharePoint Adapter (No longer do we need to install an agent(web service) on the SharePoint Server)
• Secure FTP (SFTP) Adapter
• ESB Toolkit Integration
• Dependency Tracking (The dependencies between artifacts can now be viewed and navigated in Admin console)
• Improvements to Dynamic Send Ports (ability to set host handler per adapter, instead of always using the default send handler of the adapters)

After I discovered the Microsoft post I sent it off to my team and a lively discussion was held.   There was a bit of a debate over which of the feature we can benefit from the most.  The interesting thing is that we can benefit from each of these new features. 

SharePoint Adapter

We do a lot of work with SharePoint and in addition to running a multi-node BizTalk farm we also have a multi-node SharePoint farm.  The BizTalk team does not like installing the Adapter Web Service on the SharePoint Web Front ends so you can imagine that the SharePoint team isn’t a big fan of it either.  To make things worse, try to perform an upgrade from BizTalk 2009 to BizTalk 2010 and ask a SharePoint person to come in on the weekend to assist with the install.  Not going to make many friends that way.

Secure FTP (SFTP) Adapter

It is great to see a native SFTP adapter being included “in the box”. Back in BizTalk 2009, Microsoft provided an FTPS adapter but that protocol is not nearly as pervasive as SFTP, in my opinion anyways. As you may have seen on my blog previously, I do have several posts about a 3rd party SFTP adapter.  The adapter has been a pretty good adapter for us.  Yes there have been a few bugs, but the vendor has always provided top notch support.  However, it is a pain to deal with another vendor, pay another invoice and get license keys. 

ESB Toolkit Integration

We don’t do much with ESB itineraries but we do heavily leverage the Exception Management Portal that is included in the toolkit.  We have made some small modifications, to the exception portal,  and many of our Business Units rely upon it for Business level exceptions that occur within the Middleware or other systems like SAP.  There are many opportunities for improvement and the installation is certainly one of them.  So even though the description on the Microsoft link is rather vague, I am really hoping for a seamless experience this time around.

Dependency Tracking

We have a fairly large BizTalk environment.  It is something that we have been building upon for the last 7 years.  I can confidently say that our Business runs on top of BizTalk.  If BizTalk doesn’t function, there are widespread impacts to our employees and customers.  A Vice President was asking me about BizTalk and he was purely amazed that it supported so many Business processes within the company.  With that said, we try to leverage common components and leverage previous investments.  Overtime this can be difficult to manage so this feature is definitely welcomed.

Improvements to Dynamic Send Ports

We do have a few different scenarios where we need to determine the route that a message will take at run-time and has been a bit of a pain that these messages will always be processed by the default send handler for that Adapter.  It will be nice to have some more granularity.

RESTful Services

Looking back there have been a few different integration scenarios where could have benefited by a ‘lighter weight’ service construct.  I don’t expect this to be our de facto standard when exposing services but I do recognize the benefit in having a more flexible option than SOAP.

Integrations with Cloud Services via SB-Messaging Adapter

If you have been following my blog recently, I have quite a few posts (Post 1, Post 2, Post 3, Post 4 and Post 5)  on the new SB-Messaging Adapter which allows us to connect Service Bus Queues and Topics.  I actually have a blog post currently in the works with the CTP version but I will now save it and implement it with the new Beta. So far I have been very impressed with this new capability.  It is very easy to get this to work.  It will be this adapter that allows for many(but not all) hybrid integration scenarios with on-premise Line of Business (LOB) systems.  I fully expect BizTalk PaaS to participate in LOB integration scenarios but for those customers who have heavily invested in BizTalk, leveraging the SB-Messaging adapter has many benefits.

Azure VM BizTalk IaaS

I haven’t actually had a chance to try this out.  We do a lot of On-Premise integration so it just hasn’t been a big of a priority for me. I do recognize the value for some people though.  It creates a much lower barrier of entry for some organizations and allows them to get their “feet wet” with BizTalk before investing more significant capital in a larger environment.

Host Integration Services 2013 Beta

In addition to all of these BizTalk features a Beta of Host Integration Services (HIS) has also been released.  This version includes the following updates:
• Data Integration – Several key updates in integration with DB2.
• Application Integration – Updates to Transaction Integrator designer, tools and accounting.
• Network Integration – Direct connectivity from Server/Client to IBM mainframe systems using fully managed TN3270E runtime.
• Message Integration – WCF Channel Support for WebSphere MQ v7.5 and v7.1.
• Platform Support – Introducing the support for Window Server 2012, Visual Studio 2012, SQL Server 2012, BizTalk 2013 and IBM Systems.

Conclusion

From what I have seen with the BizTalk 2010 R2 CTP, the BizTalk team has been working very hard on this next release of BizTalk.  I think they are already demonstrating that the end product will be very solid as they have put together two compelling “pre-releases” of BizTalk.   I really encourage you to download the new bits and take the new BizTalk for a spin.  There are a lot of great features included.

BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 1

Back in June 2012, I had the opportunity to attend TechEd North America.  At this event the BizTalk team gave us a glimpse into the next version of BizTalk and went over the Product Road map.  You can read more about this Roadmap session here.

One of the areas that Microsoft wanted to address was better/seamless integration with Azure and more specifically with Service Bus Queues and Topics.  The BizTalk team released a feature pack back in October 2010 that better enabled BizTalk to leverage the Service Bus Relay capabilities.  This feature pack does work well but did not allow for connectivity to Service Bus Queues and Topics since they weren’t even available back then.

In the fall of 2011, the talented Paolo Salvatori wrote a very detailed article on how you can integrate BizTalk 2010 with Service Bus Queues and Topics.  While Paolo’s solution does work it does require some additional effort and some people may be a little overwhelmed by the solution.  But I do give credit to Microsoft and Paolo for coming up with a solution considering BizTalk 2010 was released much before Service Bus Queues and Topics were commercially available.  Their solution just validates why BizTalk leveraging WCF is a good idea.  When investments are made to WCF, BizTalk usually benefits. All in all, it was a good stop-gap for anyone desperate to integration BizTalk 2010 with Azure.

Fast forward to July 2012 when Microsoft released this BizTalk 2010 R2 CTP.  Microsoft has delivered on making integration with Service Bus Queues and Topics very simple.  The BizTalk team recently released a blog post which provides an overview of some of these new features.  I thought it would be beneficial to provide a walk through for anyone interested in more details than what Microsoft included in that post.

Scenario

The scenario that we are about to explore includes a client application that will publish a typed Brokered message from a Console application to a Service Bus Queue.  BizTalk will then use the new SB-Messaging adapter to retrieve the message and simply write it to the file system.  As an experienced BizTalk guy, I like strongly typed messages and I am not afraid to admit it.  So as part of this solution I am going to include a strongly typed BizTalk schema that I am going to deploy.  For this walkthrough I am not going to transform this message but for anyone familiar with BizTalk they will be able to take this solution adapt it for their needs.

Client Application

• Launch Visual Studio 2012 and create a C# Console application.  I called my application BrokeredMessageToBizTalk

• Next I will use the Nuget Package manager and installing the Windows Azure Service Bus package.  You can access Nuget by clicking the following within Visual Studio: Tools - Library Package Manager - Manage Nuget Packages for Solution.

• Since I want deal with typed messages I am going to create a class called PowerOut.  Since I work in the Power Industry I will over-simplify a use case that involves a customer whose power is out.  They will send a message from a client application (it could be a web page, mobile phone app etc) to a Service Bus Queue.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace BrokeredMessageToBizTalk
{
    public class PowerOut
    {
        public string CustomerName;
        public string PhoneNumber;
        public string Address;
       
    }
}

• Within our Program.cs file we want to include the following code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using System.Runtime.Serialization;
using System.IO;

namespace BrokeredMessageToBizTalk
{
    class Sender
    {
   
        const string QueueName = "PowerOutageQueue";
        static string ServiceNamespace = "YOUR_NAMESPACE";
        static string IssuerName ="owner";
        static string IssuerKey = "YOUR_KEY”;

        static void Main(string[] args)
        {
            //*****************************************************************************************************
            //                                   Get Credentials
            //*****************************************************************************************************          
            TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(Sender.IssuerName, Sender.IssuerKey);
            Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb", Sender.ServiceNamespace, string.Empty);

            MessagingFactory factory = null;

            try
            {
                //***************************************************************************************************
                //                                   Management Operations
                //***************************************************************************************************       
                NamespaceManager namespaceClient = new NamespaceManager(serviceUri, credentials);
                if (namespaceClient == null)
                {
                    Console.WriteLine("\nUnexpected Error: NamespaceManager is NULL");
                    return;
                }

                Console.WriteLine("\nCreating Queue '{0}'...", Sender.QueueName);

                // Delete if exists
                if (namespaceClient.QueueExists(Sender.QueueName))
                {
                    namespaceClient.DeleteQueue(Sender.QueueName);
                }

                namespaceClient.CreateQueue(Sender.QueueName);

                //***************************************************************************************************
                //                                   Runtime Operations
                //***************************************************************************************************
                factory = MessagingFactory.Create(serviceUri, credentials);

                QueueClient myQueueClient = factory.CreateQueueClient(Sender.QueueName);

                //***************************************************************************************************
                //                                   Sending messages to a Queue
                //***************************************************************************************************
               

                Console.WriteLine("\nSending messages to Queue...");

                //Create new instance of PowerOut object
                PowerOut po = new PowerOut();
                po.CustomerName = "Stephen Harper";
                po.PhoneNumber = "613-123-4567";
                po.Address = "24 Sussex Drive";

                BrokeredMessage message = new BrokeredMessage(po, new DataContractSerializer(typeof(PowerOut)));
              
                myQueueClient.Send(message);
             

                //Uncomment this code if you want to write a sample file to disk

                //using (FileStream writer = new FileStream("c:/temp/file.xml",FileMode.Create, FileAccess.Write))
                //{
                //    DataContractSerializer ser = new DataContractSerializer(typeof(PowerOut));
                //    ser.WriteObject(writer, po);
                //}

                Console.WriteLine("\nAfter running the entire sample, press ENTER to exit.");
                Console.ReadLine();
            }
            catch (Exception e)
            {
                Console.WriteLine("Unexpected exception {0}", e.ToString());
                throw;
            }
            finally
            {
                // Closing factory close all entities created from the factory.
                if(factory != null)
                    factory.Close();
            }
           
        }

    }
}

Of the code above I want to highlight a couple different lines:

• The first one deals with the DataContractSerializer as seen below.        

BrokeredMessage message = new BrokeredMessage(po, new DataContractSerializer(typeof(PowerOut)));

If you do not use a DataContractSerializer you can expect undesirable results when BizTalk retrieves the message from the queue.  As mentioned in the recent BizTalk team blog post: “Brokered Message .NET API uses Binary encoding. To avoid this issue, you will need to use Text by explicitly provide your own serializer, instead of the default serializer.”

• The next deals with the few lines that have been commented out.  Since I want to use typed messages within BizTalk, I can generate a sample XML message using the code below.  This will allow me to generate a BizTalk schema using tools provided within Visual Studio.

    //using (FileStream writer = new FileStream("c:/temp/file.xml",FileMode.Create, FileAccess.Write))
                //{
                //    DataContractSerializer ser = new DataContractSerializer(typeof(PowerOut));
                //    ser.WriteObject(writer, po);
                //}

*As a side note – wouldn’t it be nice if BizTalk supported native .Net Classes (from a messaging perspective) - hint, hint *

BizTalk Application

We can now create a BizTalk application.  Since we are using the new BizTalk 2010 R2 CTP we can also use the latest version of Visual Studio 2012.  As I mentioned earlier I want to process typed messages so our BizTalk solution will be very simple.  It will only include a Schema.  We will deploy this message to BizTalk so that when an instance of this message is published to the MessageBox that we will have a known schema deployed that will match this message type.

• We can now create a new BizTalk application. I have called mine PowerOutage and I have also added a Strong Name Key called PowerOutage.snk.

• Next I want to create a new Schema based upon the sample file that we previously generated.  I can create this new schema by right mouse clicking on BizTalk project (PowerOutage) - Add - Add Generated Items.
• When prompted, click on the Generate Schemas label and then click the Add button.

• Select Well-Formed XML from the Document type dropdown and then we need to provide the name of our sample file.  Click OK to proceed.

• We will now have a schema added to our solution that represents our PowerOutage class.

• Deploy our BizTalk Application
• When we launch the BizTalk Admin Console we will discover our PowerOutage application.
• We now need to create a Receive Port and corresponding Receive Location.  In this situation we are going to use the SB-Messaging Adapter.

• When we click the Configure button we will have a few more properties to fill out including our URL.  Our URL is going to include our Namespace (highlighted in Green) and our QueueName (highlighted in Orange)

• Next we need to click on the Authentication tab.  Within this tab we will provide our Namespace as it relates to the Access Control Servers (ACS), an our Issuer Name and Key.

• The Properties tab is not used in this example.  I will further examine it in a later post.

• With our Receive Port and Receive Location created we can no move on to our Send Port.  For this example we are simply going to create a File Drop where we can write out the file that we have received from the Service Bus Queue.

• Since we do not have any Orchestrations we do need to wire up a subscription for our inbound message.  In order to do this we will simply create a “Send Port Subscription” by setting filter.

• We can now Start our BizTalk application and bounce our Host Instance(if applicable)

Testing our scenario

• Next, launch our Console Application and we will discover that our message has been sent to our Queue.

• If we check the File Drop that was specified in our Send Port we should see a newly created file.  When we open this file we should recognize the content that we populated in our Console application.  Since we now have typed data within BizTalk it will be easy to transform it into other message types so that we can exchange data with other systems such as Line of Business (LOB) systems.

Conclusion

Now that wasn’t so bad was it?  For experienced BizTalk people this process should be a breeze.  The only area that initially hung me up was the DataContractSerialzer that is specified in our console application.  The other good news is that we are just scratching the surface in this blog post.  Look for more posts related to BizTalk and Service Bus integration using the new BizTalk 2010 R2 CTP.

Building Integration Solutions Using Microsoft BizTalk On-Premises and on Windows Azure - Javed Sikander and Rajesh Ramamirtham

Update:  This session has now been posted to Channel 9 and you can view the video here.  Feel free to post any comments at the bottom of this post.

 

This was a follow up session to the Application Integration Futures – The Road Map and what's next on Windows Azure  session that was discussed here.  The primary focus of this session was to demonstrate some of the new capabilities of BizTalk On-Premises, BizTalk IaaS and BizTalk PaaS. 

During the presentation there were many questions as to what the differences between the On-Premises version and the IaaS version would exist.  After many questions about a particular feature (BAM, ESB Portal etc) Bala  stepped in and declared that all features that exist in the On-Premises version will exist in the IaaS version.  After a further discussion after the session, it looks like there is a little more work to do in the area of clustered host instances but otherwise we can expect symmetry between these two versions.

Since BizTalk Next (aka “R2”) will be released as part of the latest Microsoft platform offering (Windows Server, SQL Server, Visual Studio), all BizTalk projects will target the .Net 4.5 platform.

The primary purpose of this session was to demonstrate some of these new features lets get into some of the scenarios/demos that were discussed.

BizTalk Consuming REST services

In the first example, the team demonstrated BizTalk consuming a REST feed from the Azure Data Market.  Specifically, the feed was related to flight delays.  BizTalk connected using the new WCF-WebHttpBinding and performed a GET operation against this particular feed.  Since the foundation for authentication when communicating with Azure is the Access Control Service (ACS), Rajesh demonstrated the out of box ACS authentication configuration.

BizTalk consuming SalesForce.com over REST API

Once again BizTalk was configured to consume a REST service.  In this case it was a SalesForce customer feed.  Within the Send Port, the “SOAP Action Header” was populated and once again included the GET operation.  A custom transport behavior was used to provide the appropriate credentials. When executed, a list of customers was returned from SalesForce.

Next, the URI in the SOAP Action header was modified and a hard coded id was provided for a particular customer.  In this case only this particular customer was returned.  Both myself and Bill Chestnut were thinking “great, but how do we inject a dynamic customer id to this GET request”?  Once again the BizTalk team had an answer for this and it came in the form of a new Variable Mapping button.  When clicked an interface that will allow us to specify the name of a context/promoted property.  Bottom line is that we can drive this dynamic value from message payload or context.

Finally, the last SalesForce demo included a POST, where they were able how to demonstrate how to update a customer record in SalesForce.com. 

 

BizTalk PaaS: Azure EAI Services

The team then switched gears and started talking about BizTalk PaaS: Azure EAI Services.  I have no idea as to whether this will be the official name.  This is what the title of their slide included so I am using it here.  I do like it.  I do like that BizTalk is still associated with this type of functionality.  I must caution that the product team did indicate not to look too much into naming/branding at this point.

Some of the functionality(some new, some old) that we can expect in the PaaS solution includes:

• Sequence of activities to perform impedance mismatch
• Flat file disassembly
• Message validation
• Transforms
• Content based routing
  • XPath, FTP properties, Lookup (against SQL Azure), Http properties, SOAP
• Hosting custom code
• Scripting functoid to host .Net Code
• XSLT support
• New Service Bus Connect Wizard
• BizTalk connectivity to Azure Artifacts (Service Bus Queues, Topics, XML bridges)

EDI Portal

• Metro UI for managing trading partners
• Manage and monitor AS2, X12 agreements
• View resources like Transforms, Schemas, Certificates

EDI Bridge

• Archiving
• Batching
• Tracking

Other

• IaaS will be a public TAP
• Other BizTalk releases(On-Premises/PaaS) will be “regular” TAP
• On a lighter side, I did ask if we can expect a Metro version of the BizTalk Admin Console.  Don’t expect it any time soon .  Basically any new UIs that need to be created will follow the Metro styling but other than that don’t expect many updates to previous tools.

Conclusion

This was a great session that included many demos and really proved that what the Product team was speaking to in the previous session wasn’t just lip service.  Having been at the MVP Summit, I must say I was pleasantly surprised at the amount of functionality that they have been working on.  Once again, I love the direction that they are heading in.  It has an updated feature set that should please customers no matter what their ideal deployment model is (On-Premises, IaaS, or PaaS).  You can also tell that they are serious about symmetry although it may take a while for PaaS to be closer aligned to On-Premises/IaaS but I think they are headed in the right direction.

Application Integration Futures – The Road Map and what's next on Windows Azure

This presentation has hosted by Bala Sriram and Rajesh Ramamirtham

 

Blog Update: I have added a conclusion where I have provided a summary and some of my thoughts on this release.  Also, this session has now been posted so feel free to take a look at it here.  You can also add any comments that you have regarding this session at the bottom of this post.

Key takeaway from Bala: We are innovating in BizTalk!

General Update

• BizTalk Server “R2” release will be available around 6 months after Windows 8
• CTP expect this summer
• Commitment to releasing server for years to come. Publicly indicating there will be at least another release beyond “R2”
• 12k+ BizTalk customers
• 81% of Fortune Global 100 use BizTalk
• 79% of customers are using BizTalk 2010
• CU delivered every quarter with product enhancements
• Best NSAT in the industry
• 6 of 8 largest US Pharmaceutical Companies use BizTalk
• Continue to bet on BizTalk – We will take your investments forward!
• Enabling new Azure based BizTalk scenarios for EAI & EDI
  • Bringing together BizTalk on-premises and in Azure

What customers are telling us?

• Keep me current with platform, standards and LOB changes
• Reduce time and cost of developing of Integration solutions
• Let me focus on business challenges, not technology infrastructure
• Cloud advantages
  • Cost-effective, scalable infrastructure for easy deployment
  • Some scenarios like b2b are amenable to cloud
• Cloud Challenges
  • Data privacy, isolation , control more integration
  • LOB assets will continue to be on-premise
• Phased cloud adoption on my terms
  • One size does not fit all

How BizTalk will meet these requirements?

• Upgrade to latest MS platform
• Improved reach for B2B customers
• Better performance and manageability
• BizTalk on Azure IaaS
  • Eliminate HW procurement lead times
  • Reduce time and cost to setup and maintain BizTalk environments
• BizTalk on Azure PaaS for EAI and EDI
  • Reduce partner onboarding and management cost
  • Leverage existing BizTalk artifacts
  • Rapid configuration-driven development for common integration patterns
• All of these working together seamlessly as one BizTalk
  • Trying to work under “one umbrella” but no naming can be implied at this time

BizTalk Server On-Premise Update

• Platform Update
  • Support for:
    • VS 2012,
    • Window 8 Server
    • SQL Server 2012
    • Office 15
    • System Center 2012
• B2B enhancements:
  • EDI
  • HL7 2.5.1, 2.6
  • SWIFT 2012 Message Pack
• Better Performance
  • In Order Delivery process
    • Serialization created delays
  • Improved dynamic send ports and ESB via host handler association of Send ports
    • Can configure a dynamic send port host handler in Admin Console
  • MLLP adapter performance
  • HIS DB2 client transaction load balancing, client bulk insert (15 times faster)
• Better manageability
  • Visualize BizTalk artifact dependencies in BizTalk admin console
  • ESB toolkit as core part of BizTalk setup and product
  • HIS Administration using Config files with application metadata stored in XML
• Improved connectivity
  • Consume REST Services directly in BizTalk
    • WebHttpBinding will be used when calling REST Services
    • ACS support
  • Simplified SharePoint integration experience
    • No more adapter web service installs on SharePoint
  • Improvements to existing adapters (HIS, SMTP)
    • improved macros
  • Easy connectivity to Service Bus Relay, Queues and Topics
  • CICS http client connectivity to Windows

BizTalk running in Azure (IaaS)

• Use case :

  • First step in the cloud adoption
    • Eliminate hardware procurement lead times
    • Reduce time and cost to setup and maintain BizTalk environments
    • Move applications from on premise and back
  • Create a virtual network in Azure and enable connectivity to on-premise network
    • User logs into Azure Portal
    • User creates a new VM and selects BizTalk stock image
    • User specifics BizTalk environment topology and adds them to existing virtual network
    • New VMs are provisioned for user in Azure IaaS
    • User logs into the provisioned VM which has BizTalk installed and configured and starts using it.
• Targeting same Windows 8 timeframe
• Microsoft will provide guidance on performance
• MSDTC support in Azure?
  • It is supported now in IaaS and was brought in to support BizTalk
• All features that work on premise will work in IaaS

Goals

• Seamlessly connect with Azure artifacts
• Enable hybrid applications that span Azure and on-premises
• Expose LOB services both on Premise and to the cloud

Conclusion

Wow…that was a lot of content in a short 1:15 h session.  There was actually more information released related to EDI support in the EDI Services (PaaS) but I just couldn’t keep up between writing this blog and tweeting with the European BizTalk community.

What I liked:

• REST support event if it is only Send
• Cleaner integration with SharePoint.  A similar statement was made with BizTalk 2010 but talking with the product team members after the presentation I know that this is not lip service.  The Adapter Web Service is gone.  No more installs on SharePoint servers.  Also, no more consuming SharePoint’s legacy “Lists.asmx” web services.  Yay!
• Ordered Delivery performance.  It will be nice to have some improved performance while maintaining sequential integrity.
• First class ACS support in selected “cloud enabled” Adapters
• BrokeredMessage property/BizTalk Context property support
• BizTalk IaaS – should open new capabilities
• I can see the symmetry between on-premises and PaaS starting to materialize

What I would love to see:

• Exposing REST end points
• Single Mapper/Transformation experience between On-Premises and PaaS offering
• Support for other sterilizers than XML (JSON, C#)  - stay tuned?
• Service Bus Connect – Receiving requests from LOB systems (SAP IDOCS)

 

Overall the tone was extremely encouraging.  Personally, I haven’t seen this much innovation come from the BizTalk team since BizTalk 2006 R2 when support WCF/WCF LOB adapters was introduced.  Yep..I said it.  The next release of BizTalk is no longer “just a platform update” .  In my opinion, this is a full release and should be named accordingly.  For those that think BizTalk is dead – better think again.  The operation was successful and the patient is still alive.

BizTalk Server 2010 R2 Announced

In a previous post, I discussed Microsoft’s integration road map particularly related to Microsoft BizTalk Server.  The foundation of that post was based upon Tony Meleg’s presentation from the World Partner Conference.  The good news is that today, Microsoft has given us a glimpse into what is to come with respect to BizTalk Server.  Previously, Tony cautioned us that Microsoft will continue to support BizTalk and will introduce incremental changes to the platform.  Where as most of the innovation will occur in the Azure AppFabric space.

The next version of BizTalk Server is currently called BizTalk Server 2010 R2.  I suspect they are calling this an “R2” release since it is an evolutionary release that particularly focuses on platform alignment with Windows Server 8, SQL Server 12 and Visual Studio 11.  For those of you who do follow the BizTalk scene closely you may recall that BizTalk Server 2010 was originally called BizTalk Server 2009 R2 when it was in beta.  It was renamed to BizTalk Server 2010 prior to RTM.  So who knows if the BizTalk 2010 R2 name will stick but for now that is the name we will go with.

In addition to the platform alignment that I have already mentioned, we can look forward to some new features in the areas of:

• Adapter connectivity to new data sources including IBM Informix V11 and IBM IMS/DB V11
• Updates to industry schemas like HIPPA, HL7, SWIFT and SWIFTNet
• Improved Performance and Scalability
• Tighter integration with the Azure Service Bus
• Adjustment to licensing geared towards cloud hosting

Of the features mentioned, I certainly will not complain about improved performance and am happy to see tighter integration with Azure AppFabric.  I really hope that they introduce a smoother way of integrating with Azure AppFabric Queues and Subscriptions.

I am a little disappointed that there was no mention of fully supported REST endpoints, but it is early so I am hoping that Microsoft will surprise us with that feature.

I have only touched on some of the new features that will be available.  You can find the complete post from Microsoft here.

BizTalk Server still has a pulse

While this information is now well known and has been covered by both Richard Seroter and Saravana Kumar, I wanted to throw my 2 cents out there as I was away on vacation when this information was released. Now that I am back, I have had some time to watch Tony Meleg’s presentation from the  2011 World Partner Conference. I have a feeling that this “talk” will be one of those that is referenced for years to come.  Much like we continue to bring up certain “Scott Woodgate” talks.

 

A New Platform is born

For the past couple years, Microsoft has put significant emphasis on cloud computing and providing software and platform services that run in Microsoft’s data centers.  From a platform perspective, these investments have been made to Azure.  Today we have capabilities  to run Web and Worker roles, SQL and Azure Storage, Caching and relay messaging in a production environment.

Microsoft continues to invest in this platform and is increasing the amount of capabilities that are provided in this platform.  We are now starting to see some of the “middleware” capabilities being introduced in the form of CTPs that include Workflow, Pub/Sub and Queues.  A future CTP will showcase additional “integration” capabilities including pipelines that will host message transformations.

 

New Platform’s impact on BizTalk

It has been very clear that Microsoft is betting on the cloud and as a result all new software investments will occur in the cloud first and then make its way to on-premise. The first example of this strategy was the release of CRM 2011 which was available in the cloud prior to making its way into on-premise.  

To align with Microsoft’s cloud strategy, some tough decisions had to occur in order to include BizTalk functionality in the cloud.  A key area that had an impact on BizTalk’s ability to move to the cloud was in the area of Workflow.  A decision had to be made as to which “Workflow-ish” technology Microsoft would pursue between Windows Workflow Foundation and Xlang.  The driver for this decision was Microsoft’s desire to reduce the amount of duplication of efforts across their platforms.  As you can see from Tony’s presentation, Xlang did not make the cut.  In my opinion, it makes sense to decide upon Windows Workflow as it can be used outside of BizTalk and is already used in other platforms like CRM and SharePoint.   Tony does mention in his presentation that removing the Xlang Orchestration engine from BizTalk is like performing a major heart surgery and will take several years to fulfill.

Microsoft also has aspirations of ensuring symmetry between cloud and on-premise versions of its software.  The current BizTalk architecture just didn’t provide a good fit especially when consider the desire to reduce the duplication of efforts across platforms.  It was pretty clear that Workflow would be the engine of choice being a .Net based technology and its adoption by other platforms.

Another area that is at the top of customer’s “ask list” was more flexible messaging options.  While BizTalk’s current durable messaging is a core requirement for many customers, the ability to by-pass durable messaging in order to increase performance is a core requirement for others.  We have the ability to perform non-durable messaging with WCF and WF today so once again this is a natural fit over trying to change the existing BizTalk messaging engine.

Platform end state

Below is an image that I snagged from Tony’s presentation.  It represents the new platform’s “end-state” in terms of capabilities.  Within this diagram you should be able to find existing BizTalk capabilities and their alignment to the new platform including:

• Adapters
• Rules
• Pub/Sub
• Transformations
• Pipelines
• BAM
• TPM

We also have some enhancements or new capabilities not found within BizTalk natively like Caching, Web Apps, Workflow and the new Composition Model and AppFabric App Manager.  I have discussed a few of the Composition Model and AppFabric Manager on my other blog http://www.MiddlewareInTheCloud.com and am looking forward to “BizTalk” app development being able to leverage these features.  I was reminded of the convenience of the Composition Model when I recently deployed a BizTalk application to multiple servers that included deploying Web Services.  The BizTalk deployment model could be optimized in my opinion when it comes to distributed deployments. Yes there are tools that help like MSBuild and the BizTalk deployment framework but it should be simpler.  I would love to see the simplicity that the AppFabric Application model provides to “BizTalk” applications.

 

Timing

Tony asks people to “lower expectations” and “think long term”.  Microsoft recognizes that they will not be able to move existing BizTalk functionality to this new platform in either the cloud or on-premise any time soon.  It will take multiple releases to achieve the goals of the platform.  Their timeline is somewhere around 5 years.  In the mean time Microsoft is going to continue to release versions of BizTalk Server.  Yes, you read that right…BizTalk is not dead.  However, Tony cautions that we will not see a lot of innovation being baked into the new BizTalk bits.  The updates to BizTalk server will be to align to updated platforms like Windows Server, SQL Server and Visual Studio.  Updates may also include bug fixes or key customer asks that are reasonable to implement.  However,  the innovation will occur in this new platform.

In the short term, we will see features of the new platform being rolled out in the form of CTPs.  We shouldn’t expect the new middleware features to hit production until sometime in 2012.

(another image that I swiped from Tony’s presentation)

Migration

As we move from our existing platform to the new platform, we should be expect some pain.  Obviously Microsoft will take reasonable steps to ensure of smooth transitions to the new platform but we can expect some challenges along the way.  There will not be an “easy button”.

 

Guidance  (my opinion – take it as is without warranty)

The first piece of advice is: DON’T PANIC.  It is still early and nothing is written in stone at this point.  Microsoft has mentioned that this is a long term strategy and it will take multiple releases to address the vision.  In the mean time they will continue to support and release more BizTalk.  From a personal perspective, I am responsible for a Middleware team at a good sized Energy Distribution provider.  We run BizTalk 2009 and I can confidently say that our business runs on top of BizTalk.  If BizTalk goes down, many parts of our business slow down if not grind to a halt.  We have been making significant investments in BizTalk for over 5 years.  My intentions are to continue use BizTalk.  We have an upgrade planned in the next 8 months and that will be a BizTalk upgrade.  Most likely 2010, but if a newer v.Next release miraculously appears we will consider it.

From a developer perspective, this news is a bit of a wake up call.  It is time to start diversifying your skill set.  Microsoft is providing initial looks at this technologies through CTPs.  Get involved!  Download the bits, try them out and get familiar with some of the new concepts and models.  I don’t think there is any reason to be really nervous though.  The underlying core integration skills that you have built up over the years will not be for nothing.  Some of the terminology will change, the toolset will probably change but many existing integration patterns will continue to exist whether there is a “cloudy thing” or not.  If anything, I think there will be a lot of new opportunities for developers with Microsoft Integration skill sets.  There will be a lot of existing BizTalk –> New Platform migrations that will need to occur in the next 3-10 years.  Who better to work on these projects than people with BizTalk experience who have adopted the new technology.