Living in the Tech Avalanche Generation

BizTalk Express - Oh well got the name wrong - they called it Dublin. I want to make this the last post where I use the term BizTalk Express.

PDC is on our doorstep and the last minute information leak is starting to turn to a  steady stream, the one that most interested me recently came from Darren Jefford just a few days ago. Darren speaks about how Dublin (the new WCF / WF Application Server Host) will help in making both those technologies scale to enterprise without developers having to write a whole lot of infrastructure code. Darren say’s….

“So if you want to expose [WF] workflow’s via [WCF] services but ensure performance and scalability (up to enterprise scale), you can now do this without having to write the code required to host these apps on Windows Server.  Ensuring performance and scale of WCF services and WF is hard to do today, hence it’s not done very often at least in my experience and sometimes causes a tendency to twist BizTalk into doing something it wasn’t necessarily designed to do which causes problems of their own (coupling Web Sites/UI’s directly to BizTalk for synchronous processing springs to mind).

We don’t want customers in this situation to be forced into writing huge amounts of hard plumbing code to achieve this, we need a server product to do this for you, which is where Dublin comes in.  Note some of the server features announced which will be familiar to BizTalk developers (content based routing, compensation, etc.).”

So it would appear that some of the benefits of BizTalk are being borrowed and leveraged to provide application developers the ‘Server’ or ‘Host’ product and even some content based routing (both requests in the call for BizTalk Express). However part of my previous assertions was that by providing BizTalk Express (conceptually), we might become the beneficiaries of a robust and scalable host for our messaging and long running workflow technologies, there is still one point that I maintain is of significant importance that should not be overlooked and that is the requirement for Publish / Subscribe. So I am still left with this question dangling:

“How deep will all this declarative tooling go? How far does Dublin reach down into the API? Do I get publish / subscribe with my WCF / WF messages / workflow’s? What about durable messaging regardless of transport and bindings - I don’t care to lose messages on the HTTP stack?”

Whilst the information seems to be coming a little thicker and faster, some of these questions remain unanswered. I am also very interested in how flexible these new shiny toys will be? I for one don’t particularly like the RPC / CRUD styled interfaces that you see being developed ad nauseam in the Web Service space, that approach does not feel at all like messaging to me - it’s more like remote RPC API calls than it is messaging. Does Dublin and the Oslo suite of tools offer me the environment to take advantage of sending business messages or will it continue to encourage RPC styled API calls with better hosting and scale features out of the box?

I’m sure there is a lot more to the Oslo story that will be unveiled in the next month and I remain hopeful that some of my wish list is on the menu.