Unless you’ve been in a cave somewhere, you’ve probably
heard that Microsoft has made some changes to the next
version of Windows. If you’re like most, you’re probably wondering what
this means for application developers. It probably seems like a long way off,
but the announcements made earlier this month will have an effect on your
development a lot sooner than you think. Here’s a brief overview of what’s
changed, and what you can look forward to in the near future.
Waiting for WinFS
Two columns walk into the Longhorn bar at the bottom of
Whistler Mountain. They are talking amongst themselves, not paying attention to
the people in the room. They sit down, and are surprised to see someone they
were told had died earlier that day. The one column, Indigo, looks at the other
column, Avalon, in shock. The third, named WinFS and obviously unharmed, puts
down the glass of brandy, smiling smugly while saying, “Reports of my
death have been greatly exaggerated.”
The removal of WinFS from
Longhorn’s initial release had even the
most respected developers screaming, “Cairo!” But just because
it’s not going to be in the initial release doesn’t mean it’s not going to be
in there at some point. WinFS will be great, when it is finally ready. It’s not
one of those “can be mediocre until V2” products. Microsoft can’t
trip on this one out of the starting block.
Now, Microsoft won’t officially comment on a specific
release scenario or ship date, but this author has a few predictions. First,
you’re probably going to see WinFS ship at the same time as Longhorn Server,
which will probably be named Windows Server 2007. At that time, they’ll have a
client installer as well.
From that point, you’ll probably see WinFS on Longhorn
Client by default either in a Longhorn Service Pack 1, or in a Longhorn
re-release à la Windows Server 2003 R2. Microsoft has
seen success with their out-of-band releases on that platform, like Active
Directory Application Mode or Identity Integration Server 2003. I wouldn’t be
surprised if we saw the same strategy again on the client-side.
Extending Avalon’s reach
The next piece of news that affects all developers relates
to Avalon, the new desktop management system for Longhorn.
Microsoft talked to a lot of independent software vendors (ISVs) and other
enterprises about the Professional Developers Conference (PDC) bits, and some
of the new capabilities possible with Extensible Application Markup Language (XAML) programming. XAML is a way to write code using an XML-like
syntax that can be opened up like a document, and compiled on the fly. Its
greatest potential lies in its ability to bring the UI separation model
inherent to ASP.NET development down to the desktop.
That’s great news for software developers who can’t design
an intuitive user interface to save their lives. They can leave that work to
the graphic design professionals now. That model has worked very well in
ASP.NET development circles, and should work well here too. Look for a number
of professional design tools from Adobe, Macromedia, and others, to start
supporting XAML output in the next 6-12 months.
But the feedback Microsoft got was that Longhorn would lack
the install base for it to make sense for ISVs to start targeting it
exclusively. Microsoft says it will be “widely available” in 2006,
but that doesn’t mean it will be “widely installed” anytime before
the next even-numbered year. I mean, some companies still don’t think that the
security, usability, and stability improvements in Windows XP are enough reason
to upgrade from Windows 98 and 2000, so ISVs can’t be banking on huge
enterprise Longhorn rollouts within the first six months it is available.
So Microsoft decided that the best course of action would be
to backport many of the features in Avalon Longhorn onto Windows XP and Windows
Server 2003. This is great news for developers, because now the ease of XAML
programming will be available on older platforms. There are going to be some
performance issues to solve, as Joe Beda, formerly of the Avalon team, described
in his blog. Avalon wasn’t designed for the Windows XP Driver Model, so
it’s just not going to be able to do the kinds of graphic enhancements it can
on Longhorn’s hardware-rendered desktop. But just because Avalon runs on
Windows XP, doesn’t mean that there still isn’t a valid reason to run it on
Longhorn. It will still be extremely compelling, as Joe discussed at length
before jumping ship for Google.
Here comes Indigo
The really exciting stuff, and the pillar that is much
closer to being finished, is Indigo. Indigo is the codename for Microsoft’s new
communications platform, which combines Web Services, Remoting, COM+, MSMQ, and
peer-to-peer communication into one unified framework. If you’ve heard the
latest catchphrase “service-oriented architecture,” that’s what
Indigo hopes to enable. Just to jog your memory, SOA is
an architectural paradigm in which programs are designed as a series of
interconnected, discoverable services that work together.
So why bring everything under one roof? Because right now,
it takes an ungodly amount of code to build a secure, transacted pipeline using
today’s tools. It’s insane, and I personally wouldn’t touch WSE with a ten-foot
pole. It’s just too much code to learn for the kinds of tasks that I generally
need to accomplish. Thankfully, help is on the way.
At PDC 2003, Chris Anderson and Don Box showed a 500+ line WSE-enhanced secure, transacted
message pipe, and accomplished the same task with no more than 15 lines of code
on Indigo. It shouldn’t take a genius to connect these dots: communication is
about to get a whole lot easier.
Microsoft’s plan for Indigo from the beginning has been for
Indigo to be available for all current (WinXP/2003) and future Windows
platforms. They haven’t set any specific launch dates yet, but this writer is
going to predict that you’ll see Indigo released as part of, or slightly after,
the “Yukon” wave (which consists of .NET 2.0, Visual Studio 2005, and
SQL Server 2005). Those products are currently slated to ship in June 2005, so
be on the lookout for it.
Bringing it all together
Longhorn’s priorities have changed. It happens in every
software development project, and it was going to happen here. Building
software is about finding a balance between three critical issues: Resources,
Features, and Schedules. The first part of the project is about a term my CEO calls
“dreamstorming” or coming up with all the things you’d like the
program to be able to do if the world were a perfect place. Not long after that
though, the team has to get its head out of the clouds, and its feet firmly
planted in the reality of ship schedules and shareholders.
Microsoft changed some of its Longhorn strategy in order to
make the technology available to a wider audience, and still ship in a
reasonable time frame. Developers can rightly mourn the loss of WinFS from the
initial release, but there are plenty of other reasons to be excited, even more
so now that there is a “downlevel” story. Ultimately, they made the
best decision possible.
I have to end with the “o-blog-itory” shameless
plug. Over on LonghornBlogs.com,
Interscape’s award-winning home of all things Longhorn, I’ve been discussing
the ramifications of Microsoft’s changes in great detail. The series is called
“The Longhorn Shake-up”, and I’ve already put out two parts of the
four-part series. Part One discusses the social perspective
and the events leading up to the decision, while Part Two explains the lessons
learned in Microsoft’s “software wave” strategy.
Robert McLaws is
President of Interscape
Technologies, Inc., a .NET solutions firm in Mesa, Arizona. He’s also a
Microsoft ASP.NET Most Valuable Professional (MVP). He can be contacted through