« March 2004 | Main | May 2004 »

April 2004

The Endangered Middle Tier

Harry has two interesting points at the end of his article which questions the middle tier as a necessary separate unit of physical deployment:

  • Will a service-oriented approach likely result in of boatloads of independent services where today we have one BIG app?
  • If yes, will the vast majority of these boatloads of independent services have modest enough scalability requirements to run on a single piece of hardware in the near future?

I'm personally not sure about the first one. Harry used the analogy of database tables which can run in one container if there are no special scalability needs, and which can be split out amongs multiple storage partitions if the need arises. In the services world - whatever that might be as of today - I don't see that we are there, or even near, yet. If you'd create the 100s or 1000s of services which Harry is referring to in his post, than you'll quite likely - as of today - and up in a maintainance nightmare. In fact, if a customer would walk up to me today to do a design review on an business application with 1000s of ASMX services, I'd quite likely point this out as a bad idea and would want to know about their motiviation for doing so.

However: I definitely see where Harry is heading to. I guess we'd need some sort of "container" - like the database server in his analogy - which manages the physical distribution of the services without changing any single bit of your implementation code. We'd need tools that allow administrators to do the equivalent of table partitioning to deploy the services.

This container however can not be IIS as it is today. It needs to allow the administrator to treat a service in a similar way a table is treated by a database server. As a unit of management and as a unit of deployment which might be concentrated on a single machine or split out amongs more of them if the need arises. (Just treating a service "as an ASMX file" is not enough) Furthermore, this new container must be *very* easy to use. A developer doesn't have to think too much (yes, I know, that's simplified and not 100% true) about the physical distribution of databases, logs, indexes, and tables amongst storage media when he issues his first "create table foo" command. If he follows sound development practices, a sysadmin will later be able to change this distribution depending on the scalability requirements. We'd need a similar container and administrative toolkit for service deployment.

For the second question, I think that, yes, most services which are used as backends for business applications don't have massive scalability requirements. But, you know, I still recommend most of my customers to run their services on a two-node W2K3 NLB cluster instead of on a single box. It's not that expensive. And it's not just about scalability. It's also about transparent failover and the ability to apply service packs and security hotfixes to single nodes in your cluster without taking down the whole application.

Your take on it, Harry?

Thank you, "Compare and Merge Documents"

You've heard it before: "Microsoft Word contains hundreds of features most people never use. "

But then again, one day you might need one of them and just one single feature might recoup the complete cost of the Office System. Let's just suppose that you have written a 400 page document some years ago. This document went through several revisions (in DOC), has been typeset in QuarkXPress, and has afterwards undergone several more cycles of copy editing and proofreading in PDF format with the result feed back to Quark. Several months later, you did some more revisions based on the PDF documents. Everything was fine, the world was bright.

At some point however, you decide that your document has to undergo a major revision which will significantly increase the size of the document as well. You now face the problem that all these PDF-based changes (literally, hundreds of them) never made it back to the DOCs. Ok. No big problem: just export them from Quark to DOC and work on these documents instead. But hey ... where did your styles go? Where is your nice formatting? Why are there so many Quarkisms in your documents?

Ok. Two options: use the old DOCs or try to ignore all the Quarkisms. Quite frankly: the second options doesn't appeal too much if you've ever seen one of these exports.

Now, there's one of these features in Word which hardly anyone ever uses: "Compare and Merge documents." This amazing thing has allowed me to take all the formatting/styles from the original DOCs and merge them with the changed text which has been exported from Quark. Without taking all the Quarkisms along. Seriously, this is like merging changes you made in the IL code back into your original C# sources. I'm totally blown away.

If you know the person on the Office team who's been resposible for implementing this feature, could you please tell him/her that I owe dinner the next time I visit Redmond?

Tomorrow: Casablanca

Next stop: Casablanca. Joining some friends to speak at NDC 2004 starting on Tuesday next week.

If you live in North Africa, you should really check out this conference's content. Normally, there either is no such thing as a free lunch or at least it seriously lacks in taste. This time it's totally different. Microsoft was able to assemble a group of extremely cool speakers. Next to some other great speakers, you'll meet the following Microsoft RDs: Andrew Brust, Clemens Vasters, Eric Groise, Goksin Bakir, Malek Kemmou, Scott Hanselman, Stephen Forte, Sylvain Duford, Yann Faure. Et moi.

Sessions will be in French or en anglais, avec traduction simultanée. (Yes, I learnt French for four years or so. No, really, my session will be in English. ;-))

Oh, and yes, it's free! [Registration.]

Update: I'm especially looking forward to Clemens' session on FABRIQ. This is going to be a world's first!