Clemens Vasters on Longhorn

Exploring Next Generation Web Services with Indigo

November 2003 - Posts

  • Listen to Joe Long!

    Filed under:

    Joe Long, the Product Unit Manager for XML Enterprise Services at Microsoft, talks about the Indigo migration story in this recorded presentation on MSDN. If you weren't at Joe's PDC talk and think you don't have 37 minutes time for this, you can still not afford to miss listening to the prescriptive guidance section starting at slide 60, if you ever have or will cross an application domain boundary with a Remoting, Enterprise Services or Web service call on the current stacks. And now leave here and go there.

  • Reporting Longhorn / Whidbey bugs useful?

    Filed under:

    Because most teams at Microsoft seem already a milestone or two ahead of what the Longhorn and Whidbey PDC builds reflect, how much is it worth to report bugs?

    Hello? Redmond? Comments?

  • Lightweight Transactions - A puzzle (I mean, really..)

    Filed under:

    Between PDC and now, I was in Redmond on Monday and Tuesday at a meeting with the Indigo team. One of the topics discussed were the new transaction management capabilities that are part of Indigo (which, for Longhorn, includes a lightweight transaction manager).

    Ingo was there, too, and we had a little argument about how hard it is to write transaction resource managers. Ingo thought that it would be awfully hard to write them and that average programmers would never do so and wouldn’t see the need for them. I said “hey, it’s really trivial”, explained that I consider transactions a very general programming paradigm for much more than just databases and told him that I would write a little demo to prove it. I wrote the demo on the plane going home in about 3 hours. Here it is.

    The “2 Phase Commit Puzzle” application is a little Windows Forms puzzle that doesn’t use Indigo or the Longhorn bits, but rather employs a little lightweight 2PC transaction manager that Steve Swartz and myself hacked up when we were on our Scalable Applications tour this spring.

    The puzzle uses four resource managers (transaction participants). The TileWorker keeps track of the tiles as they are moved around, always votes “yes” on Prepare, does nothing on Commit and rolls all tiles back into their original (shuffled) state on Abort. The TimeoutWorker votes “yes” if the puzzle is completed (pressing the “Done” button) within the preset time-span and “no” otherwise. It does nothing on either Commit or Abort otherwise. The GridWorker votes “yes” on Prepare if the puzzle is completed (order is correct) and otherwise “no”. It also does nothing on Commit or Abort. The OutcomeContingentMessage is a participant that will always vote “yes” on Prepare and shows a “Congratulations” message on Commit and a “You failed!” message on Abort.

    The great thing about this little puzzle is that I could add arbitrary other success/failure conditions for the outcome of the puzzle (e.g. number of moves) without having to rewrite or even touch the code determining the other conditions or the code emitting the result message. I would just have to hook in the new resource and feed it with information from the grid.

    Transactions aren’t just for databases. The discussion of the theory behind this is of course in our already well-known transaction deck.

    Over on my blog are the download links to the game executable (in IE, you need to right-click and save it to the local disk; it will not work if started directly from IE) and the source code archive, including the simple WorkSet transaction manager. Check it out.


  • Petzoldian-style Development on the road to Avalon Nirvana. Sigh!

    Filed under:

    Avalon is very promising. No doubt about that. I can very well imagine how Visual Studio "Orcas" (the one to follow Whidbey) will add fantastic designers for creating stunning Avalon UIs. However, today, my first steps with XAML remind me very much of my first little baby steps exploring the Win16 API back in 1990 using Charles Petzold's Windows Programming book. Of course, it's all on a vastly elevated level and some of the controls are stunningly powerful, but putting together an Avalon app that actually looks good is pretty difficult right now. I am not complaining -- it's very early and I am happy that Microsoft lets me play with the stuff. I am just so horribly spoiled by visual design tools.

    I figure that Avalon will create a lot of new jobs for designers. In fact, if you don't have a designer, your app will look really, really old, no matter how well you master the Avalon technology. 

    And I figure that I'll have to freshen up my math skills on trigonometry and linear algebra in a big way. Vector graphics is a very different ballgame.

    Oh... and MSBuild does really rock the house.