Geeks With Blogs
Under the Influence of Integration Technologies Joe Klug

With "Dublin" on the horizon as the future distributed application server role for Windows, does it make sense for Microsoft to call this new role "Windows BizTalk Services"?  This would in many ways mimic the Windows SharePoint Services/Microsoft Office SharePoint Server paradigm.  The only problem in the short term is that BizTalk Server 2009 has just been released and looks nothing like Dublin.

The ideal set of products would first include Windows BizTalk Services, which includes all of the lightweight building blocks for creating basic distributed applications.  It could even provide some level of message and workflow persistence with SQL Server 2008 Express Edition.  The second product would be the premium BizTalk Server, which takes the "WBS" foundation and provides many Enterprise capabilities on top of it.  But, and this is a HUGE but, the premium server would have to build on top of WBS.  They can't just take the existing version and claim that it's the premium version of Dublin.  There has to be real symmetry between the two versions and a way to migrate from the basic services to the premium services.

Is this just a dream of mine or could MS actually do it???

Posted on Tuesday, May 26, 2009 2:37 PM | Back to top

Comments on this post: Windows BizTalk Services?

# re: Windows BizTalk Services?
Requesting Gravatar...
I don't think they want to do that.
Biztalk and Dublin are different products.
Biztalk is an application integration messaging server.
Dublin is an application server.
Biztalk integrates applications. Dublin runs applications.

Someone develops a line of business application or server for example like a CRM system.
They expose functionality to itself and to the outside world by installing bits in Dublin.

If you want to integrate your CRM system with some other system.
like an ordering application that takes thousands of orders from the internet.
you don't necessarily want your endpoints exposed to such high traffic.
You can drop those messages in Biztalk and it will queue them up for you
letting your downstream app "catch up"

Biztalk is all about receiving messages and queuing them quickly
with the ability to possibly transform those messages into a structure that you can handle uniformly.
A set of canonical types of just all XML.

In application architecture they have the n-tiered design.
They separate these things for logical and physical strategies.
In one of the tiers you might do ADO.NET in another you might do ASP.NET
Both of these things do similar things if you think about it.
They take some data from the user and processes it and spits back a response.
Both use similar patterns of OO, the .NET framework etc. etc.
But they are very different animals too.
even though you can manipulate both with visual studio.

The analogy is the same in Dublin vs. Biztalk.
Even though they have similar tools and provide similar patterns and abstractions they are different.. very different tools
for different strategies.
Yes they both exist in the applications integrations space but I think Dublin exists more on the application end. To host endpoints and their application protocols and whatnot.

If im an ISV selling an enterprise application that you can plug into your SOA
its gonna need to be able to host its workflows and endpoints in a technology like dublin.

and if im a high transaction company im going to need something like Biztalk to manage interactions between all those applications.

The ISV is not going to require that I install bits into my biztalk server.
What if some companies dont have Biztalk server but something else.

Biztalk is also a very mature and complete kindof appliance.

They are totally different.

Dont be fooled by the similar looking tools and workflow and similar looking management tools.
These actually might be standard things you SHOULD have in any system that takes and input and spits out an output.

Left by Juan Suero on Sep 01, 2009 1:47 PM

Your comment:
 (will show your gravatar)

Copyright © Joe Klug | Powered by: