My impressions on Longhorn Developer Preview [part 2] (and a little indigo rambling)

On the afternoon we had 2 sessions. I think i will once again separate this post into 2, because i think i have a lot to talk (digress is probably more correct) about the afternoon sessions.

The first session on the afternoon is allways the thoughest for a presenter. It has to pass what i call the nap test. You want to listen what the presenter is trying to say, but your fully filled stomach just wants you to sleep (kinda like captain picard trying to defeat the borg by issuing a sleep command into the collective :-) ).

The first session “Indigo”: The Longhorn Communications Architecture, was presented by Clemens Vasters. For me this was the most waited session. The sesssion content and format changed a little bit before the Lisbon session and i got a little heated :-). Clemens replied that i was exagerating and he didn't removed that much, he was right, my fears were unfounded, to paraphrase Twain, the rumours about the death of a good presentation were greatly exagerated. Since i only have version 1.0 of the slides, i can only compare them by memory. But from what i remember, the presentation has not been "dumbed" down at all, the removed slides were acessory (SP?) and the ones that were introduced only made the presentation better (although i had already seen them on the scalability tour).

Your honor before we proceed i want to say a few words in my defense. Dariuz jumped on to the thread and stated :


  1. As this are in most places one day events with one track you automatically stay in the session. Even if you never designed distributed systems. I guess this is still pretty much of the audience as there is more to see like Avalon and WinFS for example.
  2. The bits are still in development and especially the Indigo team mentioned that the next milestone will have a bunch of changes. So to demo something is not without risk as what you show could be completely changed in a few weeks."


I feel i was a little misunderstood (the story of my life). When i read clemens post i thought, he had transformed "what is indigo, how can it make your life better and how can you prepare for it" kind of session into a "distributed systems 101" (only). I didn't thought he only removed demos. I don't care for demos that much, nor in syntax examples for the matter. I only care for "what is", the juice. I feel that such kind of presentations are not meant for schooling people into why, to lay down the foundations of a sound architecture or schooling the basics into people foreheads. Those should be prerequisites (Period). When i read this great story. It makes me wonder if these people didn't knew squat about transactions,a presentation like this with all the whys would have helped?

Little me present you a little story that is mildly related (just barely, but with a stretch of imagination this makes some sense and seems to be related :-)).

Some years ago (~3 years ago) i inherited a system which 99.5% had already gone into production. The previous team left, and i was in charge of placing the remaining 0.5% into production (it was already developed but barely tested). Without going into details, the small missing part, was a tipical system integration. My system had to be called by some backoffice application (ASP), i would return some information from my database and the system would format the information in a way that it could be drilled down (again calling my system). Not exactly rocket science. My memory may be a little blurred on the details, but this is what i found:

  • Some COM+ components in visual basic that gathered information,they were to be executed in my system machines.
  • COM+ components being exposed to the outside as a web service,via a wizard present in the Soap Toolkit 2.0. (the components would be activated locally on the machine, client machines would only invoke a web service, so they didn't care if it was COM,cobol or little green meen inside the machine issuing soap envelopes and xml by hand)
  • Some ASP pages invoking the COM+ components using the MS Soap Toolkit 2.0 and formatting HTML using XSLT

[Context: i had full control over my system machines (all seven of them) but absolute no control over the client system (3 machines if memory doesn't fail me)]

I started scratching my head, and doubts begun to wandering through my mind:

  • COM+? for exposing some data of the database? Sure direct database was out of the question, i didn't want some external system acessing my DB server and there were firewalls involved.
  • Install Soap Toolkit on the client? i was already seeing the system administrator telling me:
    • You want to install what? why? how it will affect my system?
    • Does it require a reboot? these guys take their SLA's very seriously and i was not the idiot who was going to be put between them and their SLA's. [yes the system was fully load balanced, but who likes to take chances?]. Although this new component were not vital, these would run inside a system that was critical (both internally and externally).
    • We can schedule the intervention in 2 months.
  • Have to deploy the COM's in all machines? (and the damn wizard DIDN't worked right after installation, you had to manually install some dll that was distributed with Visual studio)

Since i am stupid by design, the KISS principle is something i live and breathe by. So the questions kept poundering my head. Why COM, why COM. (i hope it wasn't just a case of the love of COM mantra)

Ah it must be because there are distributed transactions involved i thought. I started looking at the source code, and found some SetComplete and SetAbort calls. But something wasn't adding up, as far as i knew there where no writes involved, only database reads. I continued digging, and alas only read accesses [simple fire & forget selects, there were no repeatable read semantics involved or anything like that]. Now i was completely puzzled, why using MTS at all for a simple read?

I (think) i don't have the NIH sindrome but a rewrite seemed to be in order. I probably rewrote the damn thing (less than 20 minutes) in less time than it took me to find the visual studio CD's and install VB on my machine :-). I used winHttp on the client and SqlXml on the server. Simple and effective.

I don't know if this was a classic case of a resume driven architecture,astronaut architecture or something else, i will let you make your own judgement :-).

[update] perhaps Fabrice is right when he says " Architects are much likely to come up with complex and costly solutions, especially if the problem is simple! ". But i highly doubt this i was the case,noneteless this is an interesting angle.

That said, let's talk about the presentation. I think the presentation was quite good, Clemens has been up to it's usual level (very good). Indigo is surely upping raising the bar when it comes to distributed architectures. From what i've understood it will give us asynchcrouns calls, one way calls, callbacks,secure transactions,and distributed transactions the whole shebang (and some other goodies). Using standards and only standards, fully interopable with different systems as long as they are standards abiding. Most of all it will allow us to abstract from the plumbing (thank god).

I think the presentation was a little short on the juice, but there was nothing that it could be done about it. It was merely not possible to compress more content on that schedule. On overall it was great.

From what i've read (rumors?) indigo will include some orchestraction borrowed from BizTalk as a standard but that wasn't mentioned. Pity i would like to hear something about it. I guess it's still too early for that.

But i must say there is something that worries me about indigo (aren't you starting to see a pattern here? i'm never happy, there is ALLWAYS something i must complain about :-)), it's not about indigo per se, it's about distributed transactions (WS-Transaction). [Sure Clemens, Steve Swartz  and Pat Helland already wrote a lot about this (fiefdoms and such)].

A Distributed transaction is not something i would take lightly (on a intranet it is debatable; on the internet i would probably say out of the question buster), on most of the RDBS (the ones not implementing Multi-version-concurrency-control, like sql server) an ACID transaction performs a lock on the table(s). I wouldn't like to risk my system performance (or risking it being halted for that matter) by a system i know nothing about. I would put most transactions using web services in the long duration transaction category. For that problem we already have a long proven solution already: Sagas and compensations (i think it's presented on Jim Gray's book). What i'm trying to say is, while i think this feature of indigo is very interesting, i'm very wary of it's use. It will probably be used (misused?) and abuesed by those that just follow the flavor of the day or just press the knobs because they are there. Because they don't know what is under the hood or understand it's consequences (like use MTS transactions for a single select :-)). Oh well maybe, it's the price of progress. :-)

This could bring us to a plea such as this A plea for Architectural training. I totally subscribe to this kind of reasing, but i also think such a mindset change will take a lot of time. (i probably won't live to see the day) 

While looking for Saga references, found this interesting message from Jim Gray. Also found this paper (that seems to be very interesting)(only skimmed, but i've put it on the pile "to read later"). It is titled Web Services and Business Transactions 

Let those comments flow.


No Comments