Using BizTalk vs. Rolling Your Own

  • Article

A customer and former coworker of mine recently sent me a link to this blog post, whose author asks the question "When to use BizTalk vs. roll your own solution."  Good question!

BizTalk Server allows developers to quickly develop loosely-coupled, services-oriented applications for connecting multiple desperate systems in a highly-available, highly-scalable way.  Can you do everything BizTalk Server does with just writing .NET code?  Sure... BizTalk is written on .NET (2.5 million lines of code), and you could develop a similar solution I'm sure with millions of dollars and a large, experienced team of developers.

BizTalk lends itself well to certain types of projects:

  • Enterprise application integration (EAI)
  • Legacy application integration
  • Trading partner scenarios (B2B)
  • Message brokering
  • Business process management (BPM)

Let's look at an EAI example using BizTalk Server and custom .NET code.  In this scenario, we have an ERP system which needs to send customer adds/updates/deletes to our CRM system.  Let's assume we'll talk directly to the database for the ERP system -- say, if the customer table has a trigger which writes to an update table that we can poll via a SQL stored procedure -- and for the CRM system we'll send it information using a SOAP web service layer that the application exposes.

.NET way: We develop a windows service which will call the SQL stored procedure at a configurable interval.  When we receive an updated record, we will take the columns from the data set and copy each element to its corresponding class item from the SOAP proxy class.  Then we'll call the corresponding web service method and pass it the customer object.

BizTalk way: We'll create a receive port using the SQL adapter which will call the stored procedure at a configured interval.  Upon receiving an update from the stored procedure, we'll map it in the port to our canonical format (not required but a good practice) and publish the customer record to the message box.  Next we'll create a send port using the SOAP adapter pointing to our CRM web service.  Within this send port we'll create a subscription to the customer messages and map it from our canonical format to the CRM type.

Scalability and High Availability

Both of these approaches are simple and fairly quick to develop, test, and deploy.  Now let's mix it up.  After running successfully in production for a couple of months, we're told by the business department that they expect the transaction volume to increase 10-fold.  Since we didn't have this requirement up front, there's a very good chance that you'll have to rearchitect your .NET service to ensure it's multi-threaded and able to handle the increased load.

Now a requirement comes down from on high that our application needs to be made highly-available, i.e. we need to enable the service to run on multiple systems in case one of them fails.  Back to the drawing board for many .NET applications.  With BizTalk Server, we just add another server to the group, and ensure our SQL message box is highly-available, probably using an active/passive cluster.

Business Activity Monitoring

Next comes a requirement for instrumentation of the application, and the statistics should be made available on the company's SharePoint portal.  With BizTalk, we don't need to touch the code in production; we simply create a BAM observation model, deploy that model, and apply a tracking profile to the BizTalk service.  The BAM data can be viewed using an out-of-the-box portal component which can be dropped into the SharePoint page.  There are a number of ways to do the same thing using .NET of course, but needless to say you'll need to create a data repository, and open up your service code to drop data into the repository at set milestones during the process.  Should the observation model ever change, you'll be reopening your code to make the changes yet again, unlike with BAM.

Loose Coupling

Finally, a year later your company is going to deploy a customer portal which is hosted offsite and uses its own data repository for customer data, and will need to receive the updates from the ERP system as well.  With .NET, you'll likely end up writing a new service for the 1:1 integration.  With BizTalk, we just add another send port and have it subscribe to the customer messages already being published by the ERP system.

In this example, I've admittedly oversimplified, but I think the points are valid.  Also, I've completely ignored one of BizTalk's biggest advantages in this space: its adapters.  There are a huge number of adapters for BizTalk to connect to line-of-business systems.  If our ERP or CRM systems have a BizTalk adapter available, we have to do very little custom development to talk to these LOB apps.  With .NET, there may be an API available, but you'll be doing a lot of manual development.

Not For Everything / Future Direction

BizTalk Server is not for everything, but what it does, it does very well and at a fraction of the cost of competitors in this space.  In the future, I see BizTalk becoming more of a generic application platform.  Say, for example, you develop an application using WCF and WF, and then you need to scale these apps out or apply any of the scenarios outlined above.  I would expect future versions of BizTalk to be WCF and WF-based, and you should be able to take your WCF/WF applications and host them inside of BizTalk Server.  Pretty cool, I think.

 

Technorati tags: BizTalk