Reflections on BizTalk Services

I had the pleasure of spending some more time this week with some integration legends – Richard Seroter, Michael Stephenson, Steef-Jan Wiggers, Sam Vanhoutte and Saravana Kumar amongst others.

When my dear wife asked me, as I set off for our dinner, whether we’d spend all evening talking about BizTalk I was adamant we would not. I was right of course – we only talked about integration for around 70% of the time!

Anyhow – discussion flowed on many topics and there’s much to reflect on, the first thing I want to go back to is BizTalk Services

These days I’m asked at least once a week, if not twice,  to position BizTalk vs. Service Bus vs BizTalk Services. This very much reminds me the early days of Windows Server AppFabric. There’s a lot of confusion out there as to how these all fit together and what’s the direction. or – in short – is BizTalk dead? 🙂

I always thought that the story from Microsoft makes reasonable sense, but that it was a difficult one to communicate; Following our dinner, and Sam’s talk at the event the following day I think I’ve managed to distil this a little bit –

Thinking about BizTalk Services capabilities (ignoring tooling for the moment) I think there are three big ticket items missing; The first two are –

1. Better routing – ‘first match’ routing is too basic. A more comprehensive routing solution is needed which allows distributing messages to n endpoints, Ideally allowing adding/removing them outside of code. sound familiar?

2. Persistence. BizTalk Services is a light weight solution. it takes a message, performs some mediation and delivers it to a destination. It does not provide any persistence and so it does not provide any ability to handle any exceptions – there are not retries, no suspended queue, no backup transport, etc.

Thinking about these two it is easy to be tempted by concluding that both could be mitigated by finally adding integration with the Azure Service Bus on the receive side of BizTalk Services. the Service Bus obviously has persistence and a pretty good routing capability using Topics and Subscriptions. Is that the future answer?

Not quite – the service bus is passive and with a very thin administration layer. to handle the configuration of the routing and certainly to handle the end-to-end scenarios with retries etc one will have to build a solution on top of these two services. Not to mention technical log/monitoring and business activity monitoring if these were deemed important.

Which leads me to number 3 – error handling, monitoring and administration

Hold on – we’re building BizTalk all over again, aren’t we?

I truly don’t think that this is Microsoft’s intention. I equally don’t think that BizTalk Services is a bad direction, I just think they serve wholly different purposes. at least for the foreseeable future - 

BizTalk Server is a full blown integration-platform/Middleware / SOA / ESA / all that Jazz.     ‘nough said.

To me – BizTalk Services is emerging as a better way to connect an application with the outside world. But it’s probably still best viewed as a part of a specific solution rather than a generic messaging platform.

If you like – it’s a better way to do point to point integration.

Viewed this way it is the overall solution that takes responsibility for the end-to-end message delivery, including monitoring and error handling. BizTalk Services merely provides a ‘bridge’ (that term finally makes some sense!) between the application to the outside world, exposing easier ways(?) to deliver the mediation – enrichment/fransformation/adaptation.

Sure – there’s still some way to go for BizTalk Services, particularly around the tooling, and certainly there’s many more features that would be very nice to have, but when I think about it this way I am less annoyed that there’s no built in integration with the service bus or that there’s not much you can do by way of routing, etc.

If I’m deploying a web application to the cloud and need a light weight integration with a known third party, or indeed on-premises system, I might consider BizTalk Services for the job. if I don’t need, or can’t afford, a full blown integration platform, that is.

And of course – if BizTalk Services is an extension to a solution, providing mediation through the cloud, the solution itself could be BizTalk Server, either on-premises or in the cloud, too. At Solidsoft we see quite a few opportunities these days of using Windows Azure Service Bus in conjunction with BizTalk. BizTalk Services fits the very same pattern building on BizTalk’s persistence, configuration, error management, logging, etc. 

Final note – in many respects this is in par with my thinking of light-weight ESBs such as nServiceBus and the likes – they are very good frameworks/platforms (well – some are!) but they are light weight, and are typically suited as a component in a particular solution which will wrap them nicely.

About Yossi Dahan
I work as a cloud solutions architect in the Azure team at Microsoft UK. I spend my days working with customers helping be successful in the cloud with Microsoft Azure.

5 Responses to Reflections on BizTalk Services

  1. Hi Yossi

    I think you summed it up well yesterday when you compared BizTalk Services Bridge as it is now to being a traditional “BizTalk Port + Pipeline + Map”.

    Its a small subset of an integration solution and one which might cover all of your requirements for some customers but that it likely to be just for specific cases.

    To me BizTalk Services should be about bringing platform-based integration to the masses (both small and large). In particular those small shops who cant afford BizTalk Enterprise but as they grow they end up with millions of likes of spaghetti custom coded integration solutions.

    BTW you need to blog more!


    • Yossi Dahan says:

      Thanks Glenn, Mike

      Mike – I’m starting to think that the reason that I don’t blog as much is simply because we don’t meet as often! 🙂

      • Itai Raz says:

        Great post Yossi!
        Sounds like a very interesting dinner…

        I had the same thoughts regarding BizTalk Services raising similar questions to what we’ve heard in the past regarding WF vs. AppFabric vs. BizTalk vs. Service Bus vs. and the list goes on…

        Until things mature and get figured out there is always confusion and uncertainty, and sometimes technology moves on to a new and different thing and things never get figured out…

        But I certainly agree, BizTalk Services is not meant and should never be the same as BizTalk, it is solving problems in the same domain but different problems and in a new era.

  2. Hi Yossi,
    It is interesting article.
    One point, BizTalk Server is dead in terms of the Microsoft investments. BizTalk Services are still on the main development investments. It is not Oslo, AppFabric, etc. Not yet. Services might have some future. It might get some improvements in covered scenarios.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: