Longhorn and Whidbey (staged information from compiled public sources by Sandor Nacsa, Microsoft Hungary)
Next Wave of Software Opportunities:


Jim Allchin: highlights on new application programming model for Windows
Bill Gates: highlights on next wave of software development
o enable developers to build a new generation of "smart," connected applications
http://longhorn.msdn.microsoft.com/lhsdk/longhornoverview/dtconintroduction.aspx:
"Longhorn" provides a platform for writing a new type of software that combines the best of Windows and the Web.
"Longhorn" is optimized for applications that are characterized by a combination of network awareness and local resource
utilization. These applications communicate with other nodes (servers or other clients) in a network (the Internet or an
intranet), and participate in a larger service-oriented architecture. They use local resources (CPU, GPU, storage,
bandwidth, and so on) to deliver an efficient and effective end-user experience and can function offline or online.
Although there are many examples of applications that already conform to this definition, developing smart, connected,
applications is not a trivial undertaking. A number of challenges arise when attempting to develop such applications, from the
problems associated with supporting both online and offline experiences to concerns about deployment and maintenance of the
application. The system services and new APIs in "Longhorn" were specifically designed to handle many of these issues, so that
application developers can focus on offering an experience suited to the particular problem that their software is addressing.
"Longhorn" applications can have the following characteristics:







Function online or offline with no-touch deployment.
Connect with peers and servers over any network topology.
Collaborate with others through shared data, events, and communications.
Leverage shared data and metadata schemas.
Present data and/or media to the user with high fidelity.
Run safely within code access security (CAS) policies.
Recognize associations among people and groups.
"Longhorn" also provides backward compatibility with existing applications. Not only will almost all current
applications run as expected on "Longhorn", but "Longhorn" allows you to incorporate new functionality into
existing applications incrementally. Some developers will choose to rewrite entire applications using the new APIs and
functionality exclusively, while others will choose to incorporate only a subset of these features into their existing applications.
Many organizations will need to continue to maintain an existing code base for legacy clients. "Longhorn" supports all of these
strategies.
Key characteristics of the next wave:



developers building connected systems using Web services that reflect the dynamic nature of the real world;
software making oceans of digital information more meaningful and actionable (i.e. information driven); and
new breakthrough user experiences, improving interactions between people, groups and organizations.
WinFX [Windows [.NET] Framework eXtension]: all those are managed classes


the application programming model for the next generation of Windows,
evolves the Microsoft .NET Framework’s programming model, greatly increasing developer productivity as well as
application security and reliability.
Allchin on WinFX:
To have this great functionality [i.e. “Longhorn”] you need a way to be able to interface into it, and we call that WinFX TM. And
what is WinFX?
1




It is the next step beyond Win32.
And if you've programmed to the .NET Framework, it's going to seem like second nature.
It's very well-structured.
This is something that we expect to last decades, and so we've spent a lot of time thinking about how the classes, the
types, the methods, the properties, the events all fit together so it's a holistic environment.

Actually, every time that a new extension is put into the system, it's reviewed by a set of system architects and then it's
usability tested by a set of developers. We think we're doing a good job. We're going to be interested in what you provide
to us as feedback about this.

Of course, another thing that we wanted to do was increase the capability of what you're able to do in your code. And at
least for me, the number of lines of code that I can write is about the same; actually in my case a little bit less than what
I used to do. But in the last ten years, I don't think the productivity in terms of number of lines of code has really gone
up that much.

So what can you do about it? Well, I have a saying. The best line of code that you do is the one that you don't have to
do. And what we're trying to do in WinFX is bring up that capability so things like add ref and release you don't have to
think about, so you can make your code more resilient and write your code faster.

Lastly, in this next step in WinFX, we're trying to continue on our commitment to compatibility. So if you have a Win32 bit
app or you have a .NET Framework app and you want to start taking advantage of some of the extensions that we have
in WinFX, you'll be able to do it in a fairly straight ahead way.
.....

In terms of, now, how do you get there:
o
o
o
o
o
If you have Win32 bit app today, barring security issues and the like, those applications should be able to
run on "Longhorn."
If you're working with the .NET Framework today, those applications would work on "Longhorn," and
you're on your way to the WinFX APIs.
If you have a Win 32 bit app, or a .NET Framework app, you can start taking advantage of the WinFX
APIs.
And perhaps, you can't rewrite your code to manage. It's OK. Just start using the functionality in the
system that you need for your application, whatever it would be. We've designed the system specifically
for that purpose.
And then, finally, if you're writing a new application and it's in the "Longhorn" timeframe, then you can
take advantage of the full WinFX environment.

Now, we don't have WinFX APIs today, certainly, in the bits that we're going to give out here that cover the entire
system. But it should be very clear that's the path that we're on, to basically make that the new layer, surface area for
the system.

In terms of schedule, this is only the client. Obviously, there are separate schedules for server. They've both got the
same general technology in server, but I'm only going to get into the client schedule. Quickly,
o
o
o
o
the media center just shifts.
The "Longhorn" developer preview, that's the bit that we're going to provide to you today.
In the first half of 2004, there will be a service pack for Windows XP, and a new updated Tablet, which
has dramatically better recognition capabilities, as well as several other very, very nice facilities.
In the summer time, and second half of the year, we'll be coming out with:

a 64-bit edition for AMD, as well as

"Longhorn" Beta 1. Beta one will be where we take it to the next level and ask a lot more
people besides you.

We are listening. We have a show net here called http://commnet. There's an application that, if you already haven't
downloaded, I propose that you do that. Give us feedback. I know there's been, already, a bunch of information coming. I
was walking back stage, looking at some of the information. It's great. It's a great way for you to get with your peers. It's
a great way to tell us what's going on. We are listening, and we're very invested in your success.

There's a set of things that we think you should do. This would be what we would call our call to action. They're very
straight ahead.
o
o
o
o

Now, you get the bits today. In fact, as you go to lunch, you're going to be able to get the bits. You should have gotten a
card, which is in your conference bags. There's a lot of information on these discs. There are:
o
o
o
o
o
o

Fundamentals: We think fundamentals are really important. We, together, have to nail the security
infrastructure so that people can trust these systems.
Web services: it's the way to get great inter ops.
Managed codes: it's the way to avoid arrows, pointers, get higher productivity.
Smart clients: you want high, interactive, rich experience. You need to take advantage of those and help
us be better in community. We're trying to really work on that, as you'll see with the application we've
got here -- all of the people that are into blogs, and other things. We're really trying to connect with you,
and that's what this conference is about.
two CDs just of "Longhorn" and different versions -- a 32-bit version, 64-bit, both of IE 64 as well as AMD
64. We also talked about that as X64.
There is the "Longhorn" driver kit, along with the SDK.
There is Visual Studio, the would-be version,
Yukon the sequel, newest update of that.
There is the Virtual PC 2004 version. Now, that's a virtual machine technology that does actually work
with these "Longhorn" bits. And
there's lots of white papers, and samples, and other things.
Now, I want to set the context for where we are in this release. We still are very early. We've never shared bits this early.
So you're going to see a lot of work. There's things in terms of the programming model that we haven't cleaned up yet.
Performance is not good. ... You should put on only high end machines, and I propose that you not put it on any
production machines, and I propose that you not connect it -- at least not knowingly -- to the Internet, in the sense that,
2
it's fine if you put on the Internet connection firewall, which should be on by default. But you should be thinking, you
should know that these are early bits.
Longhorn fundamentals:



extended security technologies in development for Windows XP to protect against malicious exploits, as well as
new security improvements at the architecture level that developers can take advantage of to help extend security across
applications and services
performance improvements from new technologies such as
o
SuperFetch, which will help applications launch more quickly, and
o
ClickOnce installation, which will speed and simplify application deployment
[Longhorn has a] New Windows presentation technologies, code-named "Avalon":


the graphics subsystem in Windows "Longhorn" and
a foundation for the Windows "Longhorn" shell
that will enable developers to build breakthrough user experiences.



provides a unified architecture for presenting user interface, documents and media
enables developers to easily take advantage of leading-edge graphics hardware, and
provides native support for declarative, markup-based programming, making it simpler to build Windows-based
applications
Anderson on Avalon:




This is the Common Language Runtime's face in the next version of Windows. Developers want the ability to deliver rich
text and great user experiences, and they want to blend those capabilities seamlessly with things like animation or video.
The next generation of the Windows platform will support all of this much more simply.
With "Avalon," we're exploring the types of experiences developers want to enable, and then looking back at the
technology, we have to let them accomplish those tasks.
By integrating two-dimensional and three-dimensional graphics, documents, video, audio, and animation, as well as tools
to distribute and protect digital content, developers can more easily build software that is visually remarkable and offers a
breakthrough experience to customers.
Security is a supreme priority for all of the design work in Windows "Longhorn." In "Avalon," we've spent a lot of time
thinking about how we're going to have these rich, interactive applications that work across the network and make them
run securely. So we're building on all the code access security work that happened in the .NET Framework. That enables us
to have applications that are running in a less-privileged environment. So even if there is some potential to exploit security
vulnerabilities, we're making it less likely that such vulnerabilities can be accessed.
Longhorn will introduce a declarative programming model (code name "XAML" [XML Application Markup Language]), that will complement
existing programming languages and Windows Forms by improving productivity when developing Longhorn-specific client UI.
Petzold on Avalon:
” The most recent Win32 API version of this program (called COLORS1 in the fifth edition of Programming Windows) is 250 lines
long. The Windows Forms version in Programming Microsoft Windows with C# is about 100 lines. This new version is only about
60 lines long, and I'm pretty sure that it can be pruned even more by using inheritance. From 250 lines to 100 and now 60.
And that, my friends, is what is commonly called progress.”
(Charles Petzold, Code Name Avalon – Create Real Apps Using New Code and Markup Model, from the January 2004 issue of MSDN Magazine,
http://msdn.microsoft.com/longhorn/understanding/pillars/avalon/default.aspx?pull=/msdnmag/issues/04/01/Avalon/default.aspx)
From: User Experience (Aero) http://msdn.microsoft.com/longhorn/understanding/ux/default.aspx
From: Aero User Experience Guidelines: Sampler for PDC 2003 , Microsoft User Experience Group, October 2003
http://msdn.microsoft.com/Longhorn/default.aspx?pull=/library/en-us/dnaero/html/samplerintro.asp


„Aero is the new Windows user experience. Aero consists of guidelines, recommendations, and user experience values
that help your applications get the most out of the Microsoft® Windows® Code Name "Longhorn" pillars:
o
rich presentation (Code Name "Avalon"),
o
data (Code Name "WinFS"), and
o
communication (Code Name "Indigo").
The WinFX™ managed classes make it easy to build your applications with the Aero user experience. In addition,
applications that apply the Aero user experience guidelines have opportunities to integrate more deeply with the Windows
shell and thereby get more exposure to more potential customers. Aero's advances in usability and aesthetics will help
excite and empower your customers.”
[Longhorn also introduces] New Windows communications technologies, code-named "Indigo"


Indigo will also be provided as a separate download for Windows XP and Windows Server 2003.
How does Indigo relate to "Whidbey"?
o
"Whidbey" is the code name of the next release of the .NET Framework and Visual Studio® .NET
development tools, incorporating new features such as support for 64-bit platforms. "Whidbey" is still in
development and is being made available in developer preview form at the Professional Developers
Conference 2003.
3
o
o




Indigo is a set of additional .NET managed class libraries, and is fully compatible with the "Whidbey" Visual
Studio tools.
”Longhorn and Whidbey represent two distinct milestones in the Microsoft roadmap. Whidbey is expected to
ship several months before Longhorn, so that when Longhorn is released, an updated version of Whidbey
[?Orcas?] will be included that provides core services in Longhorn.” (Dino Esposito, A First Look at Writing
and Deploying Apps in the Next Generation of Windows, from the January 2004 issue of MSDN Magazine,
http://msdn.microsoft.com/longhorn/understanding/pillars/fundamentals/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx)
a new approach to building and running connected systems built from the ground up around the Web services architecture
[WSA]
provides [through its advanced Web services support] capabilities for more-secure, reliable and transacted messaging and
interoperability
unifies a broad array of distributed systems capabilities in a composable and extensible way, spanning transports, security
systems, messaging patterns, encodings, network topologies and hosting models.
a unified model for developing connected applications on the Windows platform that seamlessly merges remote procedure
calls, messaging, and remote object invocation
Box on Indigo:







The main concept we deal with is that a single program by itself is nowhere near as interesting or useful as several
programs that can work together in concert.
We've spent a lot of energy in the past five years working with the industry to develop interoperable protocols based on
Web services, XML and service orientation.
What we're doing with "Indigo" is giving people a simple, unified way to take advantage of virtually any program that's out
there and to incorporate it into their world in an easy, reliable and secure way.
With "Indigo," we've built in secure protocols down to the metal so that every message can be secure. As soon as data and
information go out of the box, there is a strong security infrastructure in place, based on decentralized authentication,
federated identification, message-based securities, and more.
In addition to making sure we have excellent implementation, we're working with industry partners to ensure we're all
heading in the same direction so we can all provide the system interoperability that people want.
The end result is connected systems that wire all the individual pieces together.
The "Indigo" team actually manages several technologies that are already out in the field, such as COM, COM+, MSMQ and
DTC, all of which were developed in the late '80s and early '90s. At this year's PDC, we will let people know that we won't
leave them behind when it comes to those technologies. People's investments in those technologies are going to move
forward, as will those folks who recently invested in .NET. It's very exciting to be able to share with developers the birthing
of the whole platform, including an operating system. It's all pretty profound.
Anderson (otherwise working on Avalon):




With .NET, we took the first step toward elevating the whole platform, and Longhorn is all about continuing that journey
based on developer, partner and customer demand.
One of the things we're doing in the evolution of the Microsoft platform and "Longhorn" specifically is applying the concept
of managed systems in more than just code.
We're going to have a notion of managed applications, which means that, by redefining what it means to be an application,
the system can provide more services and value in the ecosystem around those applications.
It's all linked together to help developers focus on solving the problems they have rather than being preoccupied with the
infrastructure they need to build around the problems.”
Anderson: "WinFS" gets to store your data, while "Indigo" lets you talk to other machines, applications, systems and devices.
Everything you see and feel on the PC goes through the presentation layer, which we've code-named "Avalon".
WinFS [the Windows File System]:



the next generation of data storage that provides vastly improved ways to find, relate and act on information
the storage subsystem in Windows "Longhorn" that more securely stores both structured and unstructured data.
[with "WinFS"] developers can take advantage of prebuilt data structures in their applications, and extend those structures
to handle their specific requirements and add unique value to the application by creating new structures
Gates on WinFS:



WinFS" -- this is unified storage.
Some of you here have heard me talk about unified storage for more than a decade. The idea of taking the XML flexibility,
database technology, getting it into the file system: that's been a Holy Grail for me for quite some time. And here it is.
Thank goodness we have got the powerful systems to be able to do this thing. Thank goodness we have the evolution
around XML and user interface capabilities, so that this can all come together.
Clark on "WinFS" [the code name for a fundamental new storage capability].



As part of this managed-code platform, it will enable a whole new set of storage-based applications and capabilities that
allow users to easily find and relate things and act on data that they have in their systems.
With today's storage systems, users have to remember things like, "What is the path to the PowerPoint slides I need?"
With "WinFS," users think about their data more naturally, and can get questions answered like, "Where are the slides I
presented last week to this customer? What's it related to? Who worked on this? Have I received any feedback?"
4



Along with "WinFS," the emergence of XML and Web services has made information easier to describe and organize, and
enabled a standardized way to store, process and share it.
People tell me they can see how "WinFS" will revolutionize how people manage data on the PC. People are talking about
innovations in their applications that they previously didn't think were even possible. That helps validate our efforts and
reassures us we're on the right path.
Security is being designed into "WinFS" from the ground up. The design has the full bearing of the Windows security model
and the CLR security infrastructure behind it. For the things that are stored in "WinFS," we have a security model that
allows full authentication and authorization control.
From: The Windows File System, Microsoft User Experience Group, October 2003
http://msdn.microsoft.com/Longhorn/default.aspx?pull=/library/en-us/dnaero/html/wux_topic_storage.asp
… Within the user experience "WinFS" has many roles and capabilities, but principally "WinFS" is:
A storage medium for all end-user data.
As a storage platform, "WinFS" extends beyond a traditional file system and relational database system. It is the store for all
types of data, whether structured, semi-structured, or unstructured. By default this includes events, locations, tasks, contacts,
appointments, annotations, and other types of data. The data structure follows a well-defined schema that explains clearly what
the data is for and how it can be used.
A data model built on relational database technology and NTFS.
The "WinFS" platform supports an extensible programming model that can access data in the underlying store using relational,
object-oriented, and XML-based APIs. An application can also access data using the existing Win32 file system API, which
means that Win32 applications can continue to work with files on "Longhorn" and take advantage of some "WinFS" capabilities
with little or no extra programming effort.
A more secure place to store data.
Every item in "WinFS" is protected by its own security descriptor. "WinFS" controls access to stored items, and audits user
actions. Like the Windows security model, "WinFS" security uses discretionary access control to enable access to "WinFS" items
by users and by resource manager applications such as file and print services.
A set of domain-specific schemas.
"WinFS" contains a set of common schemas called Windows types—for example, Contacts, Sound Tracks, Messages, and
Pictures. Windows Explorer provides a way to display and manipulate these types. If the Windows types don't meet your
application needs, with "WinFS" you can customize, or extend, a type. Applications can also create new types.
A set of services that make data actionable.
"WinFS" provides a set of data services for monitoring, managing, and manipulating items. "WinFS" is active, meaning that it is
a data-driven platform in which data flow can be monitored and managed. Users or applications can be notified of various
events and can create custom rules that determine how and when notifications should be delivered. For example, you can use
"WinFS" to forward e-mail messages to a mobile device when the recipient is in a meeting.
A new user experience in the "Longhorn" interface.
"Longhorn" takes the Windows XP task-based folders to a new level by letting users categorize their data, and then filtering
their view of the information by criteria that they assign. For example, a user could organize music by song title, artist, album,
year released, track, song duration, or genre, and then filter the view of the matching music so that they see only songs titles
beginning with the letter "L." With "WinFS" users can access anything they need by familiar contexts rather than by digging
through a hierarchical folder tree.
…
WinFX Now, the PDC has begun, I could spill the beans. October 27, 2003
http://wesnerm.blogs.com/net_undocumented/2003/10/winfx.html
It's official. "WinFX" is the new name for next evolution (or, should I say, revolution) of .NET Frameworks. It encompasses all of
the managed APIs that Microsoft will ship in Longhorn, including Avalon, Indigo, and WinFS, and .NET Frameworks.
Microsoft made a HUGE bet on .NET with the next version of Windows. How huge! I doubt there are any new traditional Win32
API calls; they are all managed. Like it or not, you will be dragged into .NET; you will have to deal with managed code. Virtually
everything in the OS is being rewritten in managed code. The new shell is managed, which I also think will make it easier for
developers to extend, who can simply inherit from shell objects.
5
I urge you to look at the Longhorn SDK reference at longhorn.msdn.microsoft.com. It has the new Longhorn namespaces. Tthe
number of classes and namespaces have grown several fold.
The Avalon APIs resides in the System.Windows.* namespace and acts as a new Windows presentation layer, that no longer
uses but completely bypasses USER or GDI. That's right. Avalon utilizes DirectX and it does away with the Windows message
loop. When you program in Avalon, you won't see System.Drawing anymore--it's gone; GDI calls don't work on Avalon
windows. In return, you get visual effects that you only see in video games and Flash apps. The programming model is
declarative, not just in markup but in code, which has a one-to-one correspondence with code. You use Windows Vector
Graphics (essentially, SVG) to render graphics. Graphics is done on top of Managed DirectX, but most programmers won't go
that even go that to level.
WinFS likes in System.Storage.*. This API completely changes how you program against the filesystem. The harddisk is
basically a database--storage has become relational rather than hierachical. You no longer think about or use physical files, you
think about high-level objects that you use.
An application can still use both WinForms with Avalon. WinForms and Avalon will be separate windows, which can each be
hosted on the other. Plus, there are lots of other support, like document support API, that Avalon and WinFX provides, that are
available to WinForm apps. I've heard that XAML, Avalon's markup language, may work with WinForms as well.
Analysis and Design [phase of the [IT/SW] lifecycle] —"Design for Operations" [style which
differentiates MS tooling strategy]
Once the requirements for the application are gathered, organizations often design a detailed architectural model for their
solution. In addition, application architects must be able to reconcile their application designs with the logical infrastructure in
which their solutions will be deployed. In effect, application architects must be able to design their solutions with the operations
infrastructure in mind.
Visual Studio "Whidbey" [therefore] includes a set of tools (code-named "Whitehorse"):
”Longhorn and Whidbey represent two distinct milestones in the Microsoft roadmap. Whidbey is expected to ship several
months before Longhorn, so that when Longhorn is released, an updated version of Whidbey [?Orcas?] will be included that
provides core services in Longhorn.”
(Dino Esposito, A First Look at Writing and Deploying Apps in the Next Generation of Windows, from the January 2004 issue of MSDN Magazine,
http://msdn.microsoft.com/longhorn/understanding/pillars/fundamentals/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx )







enables architects and developers to easily design service-oriented applications and operations infrastructure
simultaneously
uses a drag-and-drop design surface to connect XML Web services, and then validates the resulting applications against the
deployment environment using the System Definition Model (SDM), saving both time and money
o
The System Definition Model (SDM), a part of the DSI, is a live Extensible Markup Language (XML)
blueprint that spans the IT life cycle and unifies IT operational policies with the operational requirements of
applications. It is relevant at both design time and at run time. At design time, it will be exposed through
Visual Studio to enable IT operators to capture their policies in software and developers to describe
application operational requirements. At deployment time, the SDM description of the application will
enable the operating system to automatically deploy the complete application and dynamically allocate a
set of distributed server, storage, and networking resources that the application requires. Throughout
ongoing operations, the SDM also enables the operating system to easily grow and shrink the necessary
resources that are associated with a particular application, based on changing business needs.
o
Dynamic Systems Initiative (DSI) is a broad Microsoft and industry initiative uniting hardware, software
and service vendors around a new software architecture based on the System Definition Model (SDM). This
new architecture is becoming the focal point for how we are making product investments to dramatically
simplify and automate how our customers will develop, deploy, and operate applications and IT
infrastructure. Over time, support for the SDM will be delivered in Visual Studio, across the Windows Server
System family, and in our management tools - known as System Center.
o
March’03 (DSI announcement): The Dynamic Systems Initiative is backed by a growing industrywide effort,
supported by companies such as Centrata Inc., Computer Associates International Inc., Consera Software
Corp., Dell Computer Corp., EDS, HP, Opsware Inc. and Think Dynamics Inc. The SDM-based architecture
will unleash new hardware innovations, bring new capabilities to development tools, result in rich new
management solutions and enable service providers to bring leading-edge offerings to market more
quickly. The SDM, already based on industry-standard XML, is straightforward and open, enabling
customers and partners to build innovative new products and service offerings around this architecture.
designers will provide modeling support for describing applications and components, along with corresponding policy
for security, protocols, and more
In many cases, enterprise architects and developers will favor a more code-centric view of their solution. Visual Studio
Whidbey will also include a rich class designer (Figure 20) so that even the largest software projects can be quickly
understood and designed.
[The major advance – however – is] The service-oriented application designer is built upon these three founding
blocks:
o
service-oriented architectures,
o
design for deployment [operations], and
o
executable design.
The service-oriented application designer is an early demonstration of Visual Studio's support for the SDM. What you are
seeing in service-oriented application designer version 1.0 is the first iteration of Microsoft Dynamic Systems Initiative
(DSI). There will be far more from Microsoft on this in the future.
The service-oriented application designer can interoperate with existing J2EE services using the WSDL.
6

We are not distributing bits for service-oriented application designer at the PDC. We will make the toolset available in a
forthcoming public beta. The timing for this beta is not yet available.

Service-Oriented Architectures –Service-oriented architectures are expected to serve as the basis for the next generation of
distributed applications, but it is difficult to visualize their necessarily fragmented application structure as an integral whole.
Microsoft is countering this problem in two major ways: the recently announced "Indigo" platform will provide the industryleading implementation of service-oriented applications and the service-oriented application designer will specifically
help application architects visualize and design applications as a whole.
o
The service-oriented application designer will support constraining and validating your design against the
Web Services Enhancements (WSE), IIS Security, SQL Security, and ASP.NET Security. In addition, for
each host and service component relationship, we have enabled pre-built constraints that you can use. For
example, you can ensure that an application component requiring Windows authentication will only deploy
to an IIS server that supports Windows authentication. In addition, we support the authoring of simple
constraints as well as specifying custom settings for the security requirements of your own organization.
Your simple and custom constraints can be validated by the service-oriented application designer too.

Design for Operations – The service-oriented application designer creates diagrams to represent the application layer and
the host layer of a system. These diagrams help those who design and deploy applications to validate an application
configuration against operational requirements when the application is first deployed and throughout its lifetime, as the
services that comprise it evolve.

Executable Design – Through the unified model in the service-oriented application designer, application and infrastructure
architects capture rich metadata during the design process. This metadata can be used both to generate code and to
validate application design against the data center definition. This model lets application architects create a more formal
and rigorous design. The design stays synchronized with the code, remaining relevant throughout the application's lifetime,
which helps application architects maintain and extend the application as needed.
Figure 1
Service-Oriented Application Designer Workflow

Fundamentally, the service-oriented application designer consists of four designers that work in concert:
o
Distributed Service Designer is used to create a visual representation of the various services and
application components that comprise a service-oriented application
o
Logical Systems Architecture Designer is used to visualize and describe the logical structure of a data
center, including the settings and constraints that define the restrictions and capabilities of the data center.
o
Subsystem Designer is used to configure components into logical subsystems for deployment.
o
Subsystem Hosting Designer is used to create a virtual deployment of a subsystem into the logical
representation of the data center. This designer enables validation of application settings and configuration
against the settings and constraints of the intended deployment environment.

The Distributed Service Designer (DSD) provides a design surface for diagramming services, creating components (that is,
generating interfaces for services), and creating a reverse-engineered view of code that incorporates Web services. With
the DSD, application architects define communication pathways by wiring services together. They can then experiment with
the application settings and design before generating skeleton implementations for developers to fully implement.

The Logical Systems Architecture Designer (LSAD) is used to create diagrams that represent the logical structure of a data
center for the purpose of communicating important information to the developer about the target deployment environment.
With the LSAD, an infrastructure architect can create a diagram of interconnected hosts (software run-time environments)
and specify the topology of the data center by representing system entities such as Web servers, database servers,
security zones, inbound and outbound communication pathways, and communications endpoints. Specifying these and
other details of host-specific configuration (such as protocols and security configurations) informs and constrains
application development. The infrastructure architect can use the LSAD to define constraints on specific application settings
that are consistent with the requirements and needs of the data center. The LSAD can also use pre-defined diagrams
provided by Microsoft that describe recommended system architectures.

The Subsystem Designer (SSD) is used to develop multiple configurations of components defined in the DSD and address
application scaling issues. With the SSD, application architects can generate a deployable configuration of application and
7
service components. For example, application architects can use the Subsystem Designer to configure applications to
support multiple uses of the same service.

The Subsystem Hosting Designer (SHD) is used to create a virtual deployment of a subsystem into the logical
representation of the data center. It uses input from the SSD and the LSAD to form a binding. The Subsystem Hosting
Designer enables validation of application topology constraints against the target data center. It evaluates the
communication requirements of the application, and ensures that there is a valid, compatible open pathway between bound
software components and logical hosts of the data center as defined by the LSAD. It also evaluates whether the proper
protocols are supported, and validates user-specified constraints against application and host settings to ensure that they
are compatible with the requirements and needs of the target environment.

The Process:
o
The infrastructure architect uses the Logical Systems Architecture Designer (LSAD) to capture the
metadata about the data center that is useful to the application architect and developers. With this
information, the infrastructure architect can inform and constrain the work of the development team. If the
data center already exists, the LSAD is used to define a known configuration to enable the application
architect and developers to validate their application against it. If the data center does not exist, the LSAD
can be used to describe the requirements for a new data center to support a particular application. Using
the LSAD, infrastructure architects can constrain application settings early in the life cycle, which enables
validation at design time against the known settings. This allows for early identification and resolution of
conflicts, which leads to higher probability of a successful deployment and results in reduced costs and
faster deployment.
o
The application architect uses the Distributed Service Designer (DSD) to experiment with service
partitioning and application design. After settling on a design, the application architect can deliver it to the
development team.
o
The development team can generate skeleton implementations of the Web services directly from the
designer and create Visual Studio projects that they will use to implement functionality.
o
Application architects can also annotate designs, print them, paste them into documents, and provide
developers with a hard copy of the system specification. This greatly simplifies the task of asking a
developer to implement a service in such a way that it integrates with the work of others.
o
Both diagrams and code are always kept in sync. Any changes made to the interfaces in code are
automatically reflected in the design diagram and vice versa.
o
When it is time to deploy the application in the data center, the application architect can use the
Subsystem Hosting Designer to map the application components to the data center described in the logical
systems architecture diagram. Using the Subsystem Hosting Designer, the application architect can specify
both application- and host-level settings, add constraints based on the relationships between settings, and
validate the application against those constraints. By mapping the application to the data center, the
application architect can verify that developers have met all of the constraints defined by the data center
prior to deployment. The Subsystem Hosting Designer provides feedback on any validation errors
encountered, giving the developer the opportunity to fix any violations before deployment and making it
more likely that deployment will succeed.
Additional tools coming with Whidbey:




Microsoft will work with its life-cycle tools partners to deliver products with support for:
o
requirements gathering,
o
software analysis and design, [own set of tools: “Whitehorse”, see earlier]
o
application construction, [new own engine: MSBuild]
o
configuration and change management, [only for small teams: improved and extended Visual SourceSafe]
o
application testing, and
o
software deployment and operations [own set of tools: “Whitehorse”, see earlier, in conjunction with a
variety of additional Microsoft and third-party software, including the Enterprise Instrumentation
Framework, Microsoft Operations Manager, and more].
Together, Microsoft and its partners will offer teams of enterprise developers the features they need to quickly and
efficiently complete mission-critical software projects.
Configuration Management
o
Software Configuration Management (SCM) is a disciplined approach to managing and controlling the
evolution of software development and maintenance practices as they change over time. With SCM,
enterprise developers can make safe alterations to existing code, track changes across developers,
projects, and time, manage the build process effectively, and track project defects and issues. By providing
project-oriented software management, Microsoft Visual SourceSafe delivers integrated SCM support for
developers using Visual Studio.
o
In Whidbey, Microsoft will improve upon the Visual SourceSafe tools and offer programmers working in
small teams the technology they need to manage source code, as well as other files in their solution.
Visual SourceSafe will be extended to offer support for Web service and Unicode projects, helping
programmers more effectively meet the challenges of today's business. Further, programmers will enjoy
improved performance and tighter integration between Visual SourceSafe and the Visual Studio IDE.
Product Build
o
Historically, developers have struggled when trying to map a complicated build infrastructure into the
Visual Studio IDE. Roadblocks traditionally center around the inability to fully customize or understand
what happens when a project is built within the development environment; the failure to reproduce a build
within a build lab environment where Visual Studio is not likely to be present; and the limitations of a build
system that was not optimized to model entire products, but rather single projects.
8
o

The Whidbey release of Visual Studio will radically improve this area of software development by
introducing a new build engine called MSBuild. Key design goals for MSBuild include: delivering a file
format that is well-documented and backed up by a published XML schema definition; making the MSBuild
engine an integral part of the .NET Framework redistributable; allowing developers to customize, augment
or completely redefine the build process; and providing seamless integration with the Visual Studio
Whidbey IDE.

First, MSBuild will introduce a new XML-based file format that is simple to understand and easy
to extend. The MSBuild file format will enable developers to fully describe what artifacts need to
be built, as well as how they need to be built under different configurations. In addition, the file
format will enable developers to author reusable rules which can be factored into separate files
so that builds can be done consistently across different projects within a product.

Second, MSBuild will ship as a core part of the Whidbey .NET Framework redistributable. This
shift in philosophy will allow developers to rely on the MSBuild infrastructure regardless of IDE
presence and licensing issues. In addition, by providing MSBuild class libraries as a core part of
the .NET Framework, developers will be able to create and debug components of a customized
MSBuild process using the managed language of their choice.

Third, MSBuild will be completely transparent with regards to how it processes and builds
software. All build steps will be explicitly expressed in the XML project file regardless of whether
it was authored by hand or auto-generated by the Visual Studio Whidbey IDE. This also means
that Visual Studio no longer treats any part of the "F5" build experience as a black box. A user
can now understand, replicate, edit, remove, or augment any part of the build process.

Finally like its predecessors, MSBuild will be fully integrated into the Visual Studio Whidbey IDE.
This tight integration will enable developers to take advantage of all the built-in productivity
features Visual Studio offers, while allowing developers to scale, customize, and adapt the
Whidbey build system to their unique infrastructure needs.
Deployment and Operations
o
In the last phase of the software life cycle, the completed application is placed into a production
environment. The activities in this phase involve creating deployment packages and an operations plan that
covers tasks, such as expected availability, backups, updates, and disaster recovery.
o
Visual Studio Whidbey, in conjunction with a variety of additional Microsoft and third-party software,
including the Enterprise Instrumentation Framework, Microsoft Operations Manager, and more, will enable
organizations to deploy and operate solutions after they are constructed and tested.
o
Moreover, the aforementioned Web services design tools will enable operations managers to participate
more closely with the overall development team.
Visual Studio "Orcas":




Designed to take advantage of the features introduced in Windows Longhorn. These features include support for Longhorn:
o
advanced user interface capabilities (code name "Avalon"),
o
storage services (code name "WinFS"), and
o
Web services capabilities (code name "Indigo").
For example, Longhorn will introduce a declarative programming model (code name "XAML"), that will complement existing
programming languages and Windows Forms by improving productivity when developing Longhorn-specific client UI.
In addition, Orcas will enable developers to take advantage of the WinFS capabilities to find, relate, and act on information,
including support for event-based actions and synchronization classes.
Finally, Orcas will deliver support for Indigo, Microsoft's next generation programming model for building Web services.
Indigo introduces a unified model for developing connected applications on the Windows platform that seamlessly merges
remote procedure calls, messaging, and remote object invocation.
PressPass: How can developers get started on the road to "Longhorn" today?
Anderson: A great first step is to come to this year's PDC. But for those who can't, there will be a ton of detailed and useful
information at the new "Longhorn" Developer Center on the Microsoft Developer Network site (see link at right). The best
general advice is to write managed code for new applications and start to exploit managed code selectively from existing
applications, use Web services for your connections with other systems, and take advantage of all the enormous power we have
on the PC today.
Box: Honestly, there is a lot of innovation happening in the current platform already. But I would tell folks to move to managed
code and the .NET Framework, because doing so will make it so much easier to integrate with the "Longhorn" platform. In
Windows XP, you can write in managed code, but most of the core capabilities were written in native code. With Windows
"Longhorn," if you're writing in managed code, you're going to have a lot of advantages.
Web/Services PDC’03
“Indigo": Services and the Future of Distributed Applications (Don Box)
WSV201 "Indigo" is Microsoft's programming model and framework for building connected applications and
Web services. "Indigo" brings together the best of .NET Remoting, MSMQ, ASMX and .NET Enterprise
Services to form a unified model and runtime for building connected applications on the Windows
platform. Learn about the architectural components of "Indigo" as well as the conceptual model
shared by all "Indigo" applications.
Web/Services WSV203 “Indigo”: Connected Application Technology Roadmap (Joe Long; Angela Mills)
This session addresses the confusion around overlapping connected application technologies (such as
.NET Remoting and ASP.NET Web services) and provides prescriptive guidance on when to use which
9
technology. Explore the roadmap for migrating existing applications to "Indigo."
Web/Services WSV301 “Indigo”: Building Services (Part 1): The Fundamentals (Don Box; Steve Swartz)
"Indigo" is Microsoft's programming model and framework for building connected applications and
Web services. Despite its breadth, "Indigo" is based on a small set of concepts, interfaces, and rules
that permeate all "Indigo" applications. This session presents those core concepts so that developers
and architects can get the most out of "Indigo" as quickly as possible.
Web/Services WSV302 “Indigo”: Building Services (Part 2): Secure, Reliable, Transacted Services (Don Box; Steve Swartz)
Once you get a simple "Indigo" application running, you'll want to know how to build more complex
apps: apps that implement security, apps that use transactions, apps where messages are reliably
ordered and delivered. Like COM+ and Enterprise Services before it, "Indigo" supports two ways of
getting at these services: a simple declarative model for common cases, and a powerful object model
for dropping into the infrastructure and doing exactly what you want. This session is the best way to
get the big picture of "Indigo" as it relates to Enterprise applications. Part 2 of a two part series.
Web/Services WSV303 "Indigo": Using XSD, CLR Types, and Serialization in Web Services (Doug Purdy)
Serialization is one of the most important areas of any Web services platform infrastructure. Joining
the worlds of XSD and CLR, serialization works to ensure the creation of interoperable and flexible
Web services using the .Net languages and tools you are familiar with. This talk will focus on the next
generation serialization support found in Indigo. Learn the new mechanisms for importing & exporting
schemas, customizing Web service schemas, and controlling the serialization of CLR types. Whether
you write schemas by hand or generate them from classes, this session will help you to design and
implement world-class Web services
Web/Services WSV304 "Indigo": Building Secure Distributed Applications with Web Services (Steve Millet)
Learn how to develop, deploy and administer secure Web service applications using "Indigo". See the
default security behavior of an "Indigo" application; then learn how to secure specific methods and
classes of a Web application using code attributes and configuration settings--how these facilities can
be varied for different deployment (single node, Web farm, etc.) and security infrastructures (intranet,
Internet and b2b). This session briefly discusses the security object model and architectural details of
how message bus supports familiar security services such as identity, authentication, authorization,
confidentiality and integrity. Explore the extensibility of some of these security services
(authentication, authorization and token frameworks) with the goal of demonstrating how a Web
service developer can integrate their existing deployments with a new Web service-based application
and explain how developers can extend their Web applications to facilitate federation across
organizations in different trust domains.
Web/Services WSV306 "Indigo": Building Peer-to-Peer Applications (Daniel Jette; Todd Manion)
Peer-to-Peer networking provides an infrastructure that enables people to communicate and share
information securely with one another while being mobile. Learn how "Indigo" enables ISVs and
corporate developers to easily develop, deploy and operate applications and services that work well
together and scale without limit. Focus on the peer-to-peer landscape, the underlying technologies,
and get an overview of the managed APIs developers can use to write applications.
Web/Services WSV370 ASP.NET: Building Next Generation Web Services in ASP.NET Web Applications (Shanku Niyogi)
See how to build next generation "Indigo" Message Bus Web service endpoints within ASP.NET Web
applications. Learn how you can now receive and process Web service requests on non-http protocols
(and how you can extend this to add your own), how you can integrate Web services with ASP.NET
caching services, and build integrated Web applications that expose both UI and data functionality.
Microsoft "Indigo" Frequently Asked Questions
http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp
Microsoft Corporation
October 2003
Applies to:
Microsoft® "Indigo"
Microsoft .NET Common Language Runtime
Microsoft Windows® XP
Microsoft Windows Server 2003
Summary: Find out the answers to some common questions about Microsoft "Indigo," including what it is, the features and
benefits of it, and more.
Contents
The Basics
Migration and Interoperability
Release Plans: Schedules, Vehicles, Features, Quality
The Basics
What is Microsoft Indigo?
Indigo is a set of .NET technologies for building and running connected systems.
Indigo is a new breed of communications infrastructure built around the Web services architecture. Advanced Web services
support in Indigo provides secure, reliable, and transacted messaging along with interoperability. Indigo's service-oriented
programming model is built on the .NET Framework and simplifies development of connected systems. Indigo unifies a broad
array of distributed systems capabilities in a composable and extensible architecture, spanning transports, security systems,
10
messaging patterns, encodings, network topologies, and hosting models. Indigo will be an integral capability of Windows
"Longhorn" and will also be supported on Windows XP and Windows Server 2003.
Microsoft has also done significant work to integrate Indigo with existing Microsoft technologies for building distributed
systems including COM+, MSMQ, and ASP.NET Web services. Applications built with those existing technologies can now be
exposed as services without modification to the application. This infrastructure-level solution greatly assists developers in
exposing existing applications as services. Indigo also provides simple and mechanical mechanisms to migrate applications
that use .NET Remoting, ASP.NET Web services, and .NET Enterprise Services to natively use the Indigo programming model.
How will Indigo change the way developers build applications?
Indigo is built from the ground up on the principle of service-orientation. Service-orientation differs from object-orientation
primarily in how it defines the term "system." Object-oriented development views a system as a set of class libraries
communicating directly in a tightly coupled fashion over a network. Service-oriented development views a system as a set of
autonomous services that can easily communicate across both private and public networks.
What is "service-orientation"?
Service-orientation describes a new method for architecting connected systems, and is based upon three simple concepts:

A service is a program that other programs interact with using messages.

A client is a program that makes services usable to people.

A connected system is a collection of inter-connected services and clients.
Instead of integrating disparate applications via direct object activations as in distributed object systems, applications expose
a set of "services" that other applications can utilize. With service-orientation, applications running on different platforms and
programmed using different development platforms can fully interoperate. In addition, application developers and system
integrators do not require specific knowledge of the underlying object models, type systems and protocols of the software
being integrated. Instead, all applications expose their services using standards-based protocols and policy definitions that
can be dynamically acquired. This 'uncoupling' of the applications that comprise connected systems enables simpler
integration, more flexibility in adapting systems to changes over time, and also enables more reliable operations.
Why is service-orientation important?
Service-orientation, as opposed to distributed object architectures such as J2EE, more closely reflect real-world processes and
relationships. Hence, service-orientation represents a much more natural way to model and build software that solves realworld business processing needs. For example, distributed object systems are tightly coupled, and modifying one part of a
distributed object system will break other parts of the system unless these other parts are modified as well and then the
changes are deployed in unison. But such an approach is not practical, especially when different parts of the system are
developed and operated by different organizations, such as in B2B scenarios. In addition, typically distributed object systems
require that different parts of the system be created using the same underlying development language and object
architecture—again an unrealistic requirement. Service-oriented systems, however, are loosely coupled and designed to
support change. Services can be programmed in any language using any development tool, and can run on different
platforms yet still be easily integrated.
Does service-oriented development conflict with object-oriented development?
No. Service-oriented development complements OO development. OO continues to fulfill an important role in the internal
design of services. Service-orientation deals with how to interconnect services to build connected systems. To use an
architecture analogy, OO addresses the architecture within a single building (a "service"), while service-orientation addresses
the issues around city planning (a "system").
What is hard about service-oriented development today, and how specifically will Indigo make service-oriented
development easier?
Today, it is difficult to model and build service-oriented systems due to the lack of a service-oriented programming model and
the required communications infrastructure for interconnecting services within and across organizational and platform
boundaries. Web services have provided a great start based upon standards such as SOAP v1.1, XML, and WSDL, and .NET
today provides the best development platform for building Web services. But as the services get more complex and are used
to solve bigger business problems, it is clear that both the Web service standards and the programming model needs to
continue to evolve. For example, robust connected systems need transactions, reliable messaging, and integrated security—
features that Indigo fully incorporates within its communication infrastructure. In addition, developers need a simple
programming model for building services and clients in a productive way, another critical requirement Indigo addresses.
How is Indigo different than J2EE for building service-oriented applications?
J2EE is deeply rooted in a classic distributed object architecture (based on EJBs)—an architecture that has proven to be
complex and brittle for Internet and enterprise-scale business integration scenarios. Service-oriented development is a
fundamentally better way for building connected systems. But with its distributed object architecture, J2EE is not designed for
service-oriented development. Indigo builds on .NET's leading-edge support for Web services, and provides a complete
service-oriented programming model and integrated communications infrastructure for building and running connected
systems in a productive and reliable way.
Migration and Interoperability
How will Indigo be made available to developers?
11
Indigo is part of Windows Longhorn and is available to every Longhorn application. Indigo will also be available as a separate
download for Windows XP and Windows Server 2003.
How hard will it be to migrate to Indigo?
Indigo is designed to enable smooth migration of existing applications, and allows organizations the flexibility to migrate
applications if and when they choose. All Indigo features are exposed via .NET managed APIs, and Indigo applications are
built using the .NET framework. Indigo extends and enhances the .NET infrastructure technologies including ASP.NET Web
services/ASMX, Web Service Enhancements (WSE), .NET Remoting, System.Messaging, and Enterprise services. From a
scenario perspective, Indigo will also provide a superset of the functionality provided by MSMQ and COM+. In many cases the
Indigo infrastructure can upgrade these features with few changes to existing .NET applications. In addition, new Indigo
applications will interoperate with applications that use current .NET Framework 1.1 technologies, MSMQ, and COM+ via wirelevel interoperability. This means that existing applications and Web services can be upgraded incrementally with new Indigo
features or integrated "as-is" with no changes. Finally, all existing technologies will remain in place as fully supported .NET
technologies. This strategy ensures that customer investments in existing Microsoft technologies are fully preserved.
How much of a learning curve will developers experience in adopting Indigo as a way to build connected systems?
Developers will be able to quickly and easily take advantage of the Indigo programming model because it is designed to fit
naturally with existing .NET programming concepts while dramatically simplifying service-oriented development. Indigo is
based on the .NET CLR and the Indigo programming model is accessible via any .NET language (C#, VB.NET, J#, COBOL,
etc.). In addition, the Indigo communications infrastructure dramatically reduces the amount of manual development that is
today required to build transacted, reliable, and secure service-oriented applications.
For developers building applications today, what should they do to insure an easy transition to exploit Indigo
when it ships?
Developers should do the following to build applications today that can easily transition to the Indigo communications
infrastructure and programming constructs in the future:
1.
Build services using the ASP.NET (ASMX) Web service model.

Enhance your ASMX service with WSE if you need the WSE feature set.
2.
Use object technology in a service's implementation.
3.
Use System.Messaging if you need the reliable messaging and queuing features in MSMQ.
Specific Caveats:
1.
ASMX

2.
Avoid or abstract using low-level extensibility such as the HTTP Context object.
.NET Remoting

3.
Avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels.
Enterprise services

Avoid passing object references inside of ES.
4.
Do not use COM+ APIs—use System.EnterpriseServices.
5.
Do not use MSMQ APIs—use System.Messaging.
Will Indigo replace ASP.NET Web services? How will I convert my existing ASMX-based applications?
Indigo will not replace ASP.NET Web services. Existing ASP.NET Web services will interoperate with services and clients built
on Indigo. For developers who want to migrate ASP.NET Web services to Indigo, the migration will be simple and
straightforward, with the caveats noted above.
Will Indigo replace Enterprise services? How will I convert my existing ES applications?
Indigo will not replace Enterprise services (such as transactions). Existing ES applications will interoperate with services and
clients built on Indigo. For developers who want to migrate ES applications to Indigo, the migration will be simple and
straightforward, with the caveats noted above.
Will Indigo replace COM+?
COM+ is a feature of Windows and will continue to be supported. Existing COM+ components can be integrated within Indigo
applications via the existing .NET/COM+ interoperability, or COM+ components can be migrated incrementally to .NET
including the new Indigo features. In addition, the Longhorn version of COM+ will be upgraded to support Indigo services.
Will Indigo replace MSMQ? How easily will MSMQ applications transition to take advantage of the Indigo message
infrastructure?
12
Indigo will not replace MSMQ. MSMQ will continue to be supported as a part of Windows, and the Longhorn version of MSMQ
will be upgraded to fully support Indigo services such that MSMQ applications can communicate with Indigo services and vice
versa.
Will Indigo replace WSE? How easily will WSE applications transition to take advantage of the Indigo
infrastructure?
WSE is a vehicle for early adopters to take advantage of leading edge Service Oriented technology, such as the latest
standards for transactions and security for Web services. Indigo provides a better, more complete communications
infrastructure and programming model for building service-oriented programs than WSE. While Indigo applications will
interoperate with applications built on the last version of WSE, WSE should only be used when gaining a first mover
advantage is more important than having code portability to the next major revision of the platform. Migrating WSE code to
Indigo may require a non-trivial development investment.
How does Indigo relate to SOAP? Will Indigo applications interoperate with Web services built in J2EE, or built
with other technologies?
Indigo includes support for the latest Web services standards, including SOAP. Applications built with Indigo will interoperate
with any application built on infrastructure that also conforms to these standards. This includes IBM WebSphere, BEA
WebLogic and other Web services built in J2EE that are SOAP-standards compliant. Microsoft is deeply committed to platform
interoperability, and an active member of the key standards organizations defining the latest standards for Web services
including SOAP and XML.
Release Plans: Schedules, Vehicles, Features, Quality
When will Indigo ship?
We have not announced a release date for Indigo. A developer preview version is being made available to developers
attending the Professional Developers Conference in the fall of 2003.
How does Indigo relate to Longhorn?
Indigo is a major feature of the Longhorn version of Windows. Indigo will be available to all Longhorn applications.
When can developers start building Indigo applications?
Developers can start learning about Indigo and building working prototypes using the preview release provided at the
Professional Developers Conference.
Will Indigo be made available only through Longhorn?
Indigo will also be provided as a separate download for Windows XP and Windows Server 2003.
How does Indigo relate to "Whidbey"?
"Whidbey" is the code name of the next release of the .NET Framework and Visual Studio® .NET development tools,
incorporating new features such as support for 64-bit platforms. "Whidbey" is still in development and is being made available
in developer preview form at the Professional Developers Conference 2003. Indigo is a set of additional .NET managed
class libraries, and is fully compatible with the "Whidbey" Visual Studio tools. A developer preview of Indigo is also
being provided at the Professional Developers Conference 2003.
Is the PDC preview release of Indigo feature complete?
No. The version of Indigo being delivered at the PDC is a developer preview. Later releases will incorporate new functionality
into Indigo, although no specific announcements are being made at this time. Also, Microsoft continues to work with a broad
set of customers to ensure Indigo meets their core requirements before it ships.
http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/migratevideo/
The Road to Indigo Technology Roadmap
Learn about preserving and enhancing your existing Microsoft platform investments. See how you can ensure a smooth
migration path between existing Microsoft technologies and "Indigo."

100k Version

300k Version
http://msdn.microsoft.com/longhorn/letters/
Welcome to the Longhorn Developer Center
Chris Sells, 10/27/03
"Longhorn" is the code name for Microsoft's next version of Windows, announced at the 2003 Professional Developer's
Conference in Los Angeles and provided in pre-alpha form to PDC attendees and to MSDN subscribers. As editor, my goal for
the Longhorn Developer Center (LHDC) is to help developers take advantage of Longhorn's rich new client features in their
applications. Towards that end, the LHDC is split into the following areas:
13

Product Information. This is where you can find Longhorn product information, including a self-guided tour from a
user point-of-view and instructions for getting your hands on the Longhorn CDs if you weren't able to get to the PDC.

Understanding. This is your first stop when learning to develop for Longhorn and includes an excellent whitepaper on
preparing for Longhorn migration and interoperation as well as coverage of material for each pillar of Longhorn, including
technical articles, columns, and book chapters from books still under development. Here's also where you'll also find the
reference documentation for both application and driver developers.

Community. The community area of the LHDC is where developers with questions, answers, and samples should go.
Here you'll find the Longhorn newsgroups, news about upcoming training and events, as well as links to third-party
Longhorn sites. When there are things happening in the Longhorn community of particular note, I'll be highlighting them in
the Editor's Web Blog, which I'll be keeping up-to-date as things happen. If I've missed something that you think is
interesting, please be sure to let me know.
Also, because business issues are just as important as technology issues when it comes to taking advantage of the
Windows platform, I have a budding "Business of Software" section. This is where I'll put non-technical articles and links to
sites that I think corporate developers, ISVs, and shareware developers will find useful when it comes to saving and
making money with Windows. Please let me know if you've got a contribution for this section or something you'd like to see
here.

Tools & Code Samples. Stop by this section of the LHDC for the latest code samples and tools from Microsoft and
the community at large. Even better, if you've built something, put it up for all of us to share!
The Longhorn Developer Center isn't my site. It isn't even Microsoft's site. This site belongs to the Longhorn developer
community. If you'd like to be a contributor to the site, let's talk. If I've missed something or gotten something wrong, let me
know. I can't promise that I can make all of your Longhorn developer community hopes and dreams come true, but I'm sure
going to try.
Chris Sells
Editor/Content Strategist
MSDN Longhorn Developer Center
csells@microsoft.com
www.sellsbrothers.com
http://msdn.microsoft.com/Longhorn/understanding/pillars/default.aspx?pull=/library/en-us/dnfoghorn/html/foghorn10272003.asp
Living La Vida Longhorn
Chris Sells
Microsoft Corporation
October 27, 2003
Summary: Chris Sells kicks off his inaugural installment of the Longhorn Foghorn column by defining the pillars of
"Longhorn," the next generation of the Windows operating system, and providing an overview of each pillar. (13 printed
pages)
In 1995, my 70-year old grandmother called me from Fargo, North Dakota and asked me if I thought that she needed
Microsoft Windows® 95. After overcoming the shock that she even knew that Windows 95 existed, I managed to remind her
that she didn't have a computer on which to run it. "I know that," she said, "but don't you think I need it?"
I don't know if there will ever be a time when another operating system will come with such a perceived benefit as Windows
95 did. However, even though we're not even to alpha yet, I can imagine when we finally ship it, that people will line up
around the block to purchase Microsoft's new Windows operating system, codenamed "Longhorn." Longhorn is as different
from current versions of Windows as Windows 95 was from Windows 3.1 and offers as much opportunity for users and
developers. The problems that we face in managing our personal and professional data continue to grow faster than features
can be added to applications. While Bill Gates and I rarely exchange e-mails (read: never), it's my impression that these
mounting problems are what caused him to give up his CEO position in favor of Chief Software Architect. Longhorn, and the
underlying technologies it brings together, comes as a result of the industry's need to take another look at what we've come
to expect from our computers, making radical changes when necessary, while still making sure that existing managed and
unmanaged applications and components continue to work.
Based on the .NET Framework
First and foremost, while Windows Server 2003™ embraced managed code by being the first operating system to ship with
the .NET Framework preinstalled, Longhorn is the first operating system whose major new features are actually based on the
.NET Framework. This focus on the managed .NET Framework means that to prepare for your Longhorn applications of
tomorrow, you should be writing managed code today.
In addition, you should be paying particular attention to the Code Access Security (CAS) model. CAS will be the core security
model for the new features, so embracing that model today will help you prepare. Check the References section for more
information on the .NET Framework and CAS.
The Pillars of Longhorn
14
The amount of new technology that's going into Longhorn is so large that it's broken up into pillars, as shown in Figure 1.
Figure 1. The pillars of Longhorn
A pillar is a set of functionality provided in WinFX, which is the name for the newest API set in Windows. The pillars that
implement WinFX represent the most fundamental advances in the Windows platform in a decade:

Fundamentals: supporting the Trustworthy Computing initiative and integrated ClickOnce application deployment

Avalon: declarative, vector-based, compositing user interface (UI)

WinFS: typed, transactional storage integrated at the file system level

Indigo: reliable, secure, service-oriented messaging
Fundamentals
The Fundamentals form the foundation on which the rest of WinFX is built, including performance, security, and deployment.
The new deployment technology is called "ClickOnce" and debuts in "Whidbey," the next version of the .NET Framework, with
further integration into Longhorn. At first glance, ClickOnce seems like a combination of the functionality of no-touch
deployment in the existing .NET Framework and the functionality of the Updater Application Block provided for download from
the Microsoft Patterns & Practices group (see the References section for details). However, it's much more than that. With its
handling of versioning, support for all kinds of delivery media, and integration into Visual Studio® .NET, ClickOnce is a fullblown solution for delivering Windows applications as seamlessly as Web applications (with all the richness left in, of course).
The new security support in Longhorn adds more of the features of the Trustworthy Computing initiative by running
applications in the Secure Execution Environment (SEE) and providing further support for digital rights management.
Performance enhancements reduce application load times and working set, as well as taking maximum advantage of your
graphics card's Graphics Processing Unit (GPU), even for 2D graphics. Other enhancements include application updating and
application feedback mechanisms, like the error report dialog provided in the Windows XP (as shown in Figure 2), but for 3rd
party applications as well.
15
Figure 2. The Windows XP Error Report Dialog
The Foundation is about continuing to improve existing basic functionality even as the platform grows to include completely
new functionality.
Avalon
While Windows Forms continues to be supported and grow in functionality, the new UI framework for Longhorn is Avalon.
Avalon is a new graphics and windowing stack built from the ground up to provide entirely new functionality. One key
difference in Avalon is its declarative nature using a dialect of XML called XAML (XML Application Markup Language). For
example, the following XAML draws three rectangles:
<!-- Window1.xaml -->
<Window
xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:def="Definition"
def:Class="Application3.Window1"
Text="My Three Rectangles">
<FlowPanel>
<FlowPanel.Resources>
<Style>
<Rectangle Fill="Red" Width="150" Height="100" Margin="10" />
</Style>
</FlowPanel.Resources>
<Rectangle />
<Rectangle />
<Rectangle />
16
</FlowPanel>
</Window>
Declaratively, this code sets the styles of all rectangles to be red, 150 pixels wide by 100 pixels high, and 10 pixels away from
anything else. "Drawing" a rectangle of this style is a matter of declaring one using the Rectangle tag. If you're familiar with
HTML, this style of programming looks familiar. If you're versed in ASP.NET, you'll expect to be able to write event handlers in
your managed language of choice, and you can by specifying the CodeBehind element. For example, to change the fill of the
rectangles when the mouse hovers over them, you can let a rectangle know to call a method from the code-behind file:
<Window
xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:def="Definition"
def:Class="Application3.Window1"
def:CodeBehind="Window1.xaml.cs"
Text="My Three Rectangles">
<FlowPanel>
...
<Rectangle IsMouseOverChanged="rectangle_IsMouseOverChanged"/>
...
</Window>
The code to handle the event belongs in the code-behind file:
// Window1.xaml.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Shapes;
namespace Application3 {
public partial class Window1 : Window {
void rectangle_IsMouseOverChanged(
object sender,
DependencyPropertyChangedEventArgs args) {
Rectangle rect = (Rectangle)sender;
if( rect.IsMouseOver ) rect.Fill = Brushes.Green;
else rect.Fill = Brushes.Red;
17
}
}
}
However, this is not my favorite code to write. What I'd like to do is leave all the UI to someone with the correct sensitivities,
which is why XAML lets me define all kinds of interesting behaviors declaratively, leaving the code for the non-UI logic. For
example, I can set a visual trigger on a style to take care of filling the rectangles without writing any C# code:
<FlowPanel>
<FlowPanel.Resources>
<Style>
<Rectangle Fill="Red" Width="150" Height="100" Margin="10" />
<Style.VisualTriggers>
<PropertyTrigger Property="IsMouseOver" Value="true">
<Set PropertyPath="Fill" Value="Green"/>
</PropertyTrigger>
</Style.VisualTriggers>
</Style>
</FlowPanel.Resources>
<Rectangle />
<Rectangle />
<Rectangle />
</FlowPanel>
Figure 3 shows the results of this XAML usage.
Figure 3. Sample XAML application
This is such a tiny subset of the power of Avalon that I'm embarrassed that I can't show you more in this article. Avalon fully
supports themes, allows control overriding by specifying property overrides or styles, provides for custom control creation
using composition of elements at an enormously granular level, handles scaling seamlessly because everything is vectorbased, utilizes the power of your graphics card by packaging up intentions to be processed by the GPU, does animation,
thumbnails, sub-pixel ClearType, dynamically generates UI at run-time based on application data, data-binding even for
trees, provides a full list of multimedia functionality, hugely flexible layout, and the list just keeps on going.
18
For a broader look at Avalon, I recommend Create Real Apps Using New Code and Markup Model by Charles Petzold.
WinFS
Just as Avalon is the new face of Windows, WinFS is the new backbone, providing a type-aware, transactional file system. By
driving type knowledge into the file system, applications can take advantage of standard types that WinFS knows about out of
the box, like contacts, e-mail, audio, video, or events, or you can define custom types for WinFS, making those types
available to other applications. For example, when browsing audio files, the Longhorn shell uses WinFS to access metadata
like artist, album, and genre, and allows you to see files stacked in that manner, regardless of any one file's position in the
folder hierarchy. Figure 4 shows my audio files stacked by artist.
Figure 4. Audio files stacked by Artist as tracked by WinFS
This dynamic set was generated by clicking on the Artists link. Stacking by Albums instead yields a different set, as shown in
Figure 5.
Figure 5. Audio files stacked by Album as tracked by WinFS
In this case, most of the audio files have metadata that classifies them as being part of an album. Files without this kind of
metadata show up outside of a stack. Opening any of these stacks shows the properties of the individual files in the set.
Of course, sorting by artists and albums is not a new feature. Media jukebox applications have provided this kind of
functionality for a long time. What makes this capability new is the support by the operating system for any kind of data.
Neither WinFS nor the shell is handling audio files specially. Instead, WinFS exposes the metadata associated with the files
19
and the shell uses this information to provide pivoting and filtering on that data. Any other set of metadata would get similar
treatment from WinFS and the shell, even custom data used by your own applications and defined for WinFS consumption.
While it can work with any type defined for WinFS, the shell can also make use of extra data as "hints" to provide a better
user experience.
In addition to the data that the shell uses to provide the sets, WinFS provides additional type-based services, including
searching, data change events, transactions, synchronization and access to WinFS data through XML style-queries, relational
queries or object-oriented collections (depending on developer preference), and backwards compatibility with NTFS.
For more of the coding details of WinFS, I recommend Revolutionary File Storage System Lets Users Search and Manage Files Based
on Content by Richard Grimes.
Indigo
In the old days, a brand new UI stack and a brand new storage subsystem would have been enough. Not any more.
Applications, no matter how rich, no longer exist by themselves. In fact, it's hard to find applications that don't rely on other
code to get their job done. Sometimes, the code your application needs to reside in memory in the form of a DLL. However,
increasingly the code your application needs is running on another machine. In the '90s, we invented component
technologies, like COM and Java, to bring DLLs into memory and we were very proud of ourselves. Unfortunately, we were so
proud that we stretched the metaphor too far with technologies like DCOM, CORBA, and Java RMI. The problem is the idea of
a proxy, which was designed to serve as an in-process stand-in for the remote code, hiding the fact that each method call
was a round-trip of uncertain duration and uneven reliability. Indigo, on the other hand, is a platform technology that breaks
from this metaphor to use a decidedly different way of connecting applications together. Specifically, Indigo uses services, not
components, to model reusable units of code.
The basic idea of service-orientation is that communication between applications is explicit. Services are self-contained
chunks of code that are most often deployed independently from the applications that make use of the service. Applications
interact with services using simple message exchanges rather than method calls and marshaled objects. This kind of loose
coupling is useful in all kinds of situations, including cross-machine and cross-process, but even cross-AppDomain and crossDLL when an application's communications are meant to be explicit.
This style of communication is what separates component usage from service usage. A component was built to be brought
seamlessly into an application's memory and therefore might be called like so without fear of repercussions:
class PiShower : ... {
...
void ShowPi() {
PiCalc component = new PiCalc();
component.Digits = 21;
string pi = components.CalcPi();
...
}
}
Since the PiCalc component is part of the application, the application and the component share intimate details like type
information and state. Likewise, while a method call can cause an arbitrarily long time, that's a rarity, as are reliability
problems.
A service, on the other hand, is built to be independent of any specific application. Under Indigo, you can expect that
communicating with a service will look something like this:
class PiShower : ..., IPiCalcResult {
...
void ShowPi() {
ServiceChannel<IPiCalc, IPiCalcResult> channel
= ServiceChannel<IPiCalc, IPiCalcResult>.Create();
channel.Inbound = this;
channel.Outbound.StartCalcPi(21);
20
...
}
}
Note This specific code will not work with the PDC 2003 Longhorn operating system, but reflects the most recent hopes and
dreams of the Indigo team at the time of this writing. However, the Indigo samples that come with the Longhorn SDK provided
at the PDC 2003 exhibit the same semantics if not the same syntax.
Notice the call to the Create method instead of using the new keyword. This is to make explicit the binding of a
communication channel to a service. Because the service is independent of the application, when the channel is created, the
service still has no idea that a request is coming.
The second thing to notice is that instead of setting a property as a means of communicating a value to the underlying code,
the value is sent as part of the request message. The Inbound property is set on the channel, but that's to let the channel
know who's making the request and this information is not sent to the service itself.
Finally, notice the Start prefix on the StartCalcPi method. This indicates that we're communicating a request to the
service. As parts of the result of this request become available, the result messages will be dispatched to the IPiCalcResult
implementation set as the Inbound property on the channel.
Early forms of this kind of explicit communications model can be seen in the Begin and End methods on the current .NET
Web services client-side proxy classes. Indigo goes beyond this by allowing arbitrary message exchange patterns, not just
simple request/response pairs. This gives developers significantly more flexibility in how they model service interactions.
Making developers aware that they're really communicating with services and not components is but one part of Indigo. In
addition, Indigo services are scale-invariant, meaning you can deploy them in-process or across the Internet. Indigo services
are interoperable and support the latest SOAP-based protocols for security, reliability, and transactions. Perhaps most
importantly, Indigo provides a single unified developer and administration experience that marries the best of ASMX, .NET
Remoting, and .NET Enterprise Services. For a more thorough look at these features of Indigo, I recommend Code Name
Indigo: A Guide to Developing and Running Connected Systems with Indigo by Don Box.
Getting Started
All of this talk of grand plans is interesting, but by now, you're probably itching to get started. Towards that end, I
recommend the Longhorn SDK. Not only will it get you started with a wealth of information, it provides a bunch of code
samples that demonstrate the new features of Longhorn. Once the Longhorn SDK is installed from the PDC CD, there are two
important parts to know about it. One is the Longhorn SDK documentation itself, which is provided under Start | Programs |
Microsoft Longhorn SDK | Longhorn SDK Document. Even though the Whidbey preview of Visual Studio .NET runs very
nicely on Longhorn, you may prefer to launch and use the help manually instead of pressing F1 from within Visual Studio
.NET. There are two reasons for this:

You may not be using Visual Studio .NET.

F1 turns off the Search feature in this preview version of the Longhorn SDK documentation.
Once you've launched the SDK, you'll probably want to dig around a bit, but eventually you'll want to build some code. I
encourage that kind of behavior and recommend that you start with a sample to ease yourself into this new world. Clicking on
the Samples tab brings up a list of more than 500 samples. I like A Simple Dynamic Application as a good place to start.
Clicking on the sample lets you view the source code and download the entire sample. When you've downloaded the sample,
you can open the .sln file in Whidbey version of Visual Studio .NET, building it and running it as you would any Visual Studio
.NET solution, or you can build from the command line, using the new MSBuild tool.
To get a command line with the appropriate environment set up to build Longhorn applications, go to Start | Programs |
Microsoft Longhorn SDK | Open Build Environment Window | Longhorn Build Environment. This will start a
command shell from which you can run the SDK tools, like msbuild.exe. MSBuild is two things. First, it's a new XML-based
command line build tool. Second, it's the new Visual Studio .NET build back-end. That is, it's what the new Visual Studio
.NET will be using to build projects. What this means is that you can load a .sln, .vbproj, or .csproj file into Visual Studio
.NET, or you can build from the command line using MSBuild applied to a .sln, .vbproj or .csproj file, as shown in Figure 6 on
an SDK sample.
21
Figure 6. Running MSBuild against a .csproj file
The output from building in Visual Studio .NET or using MSBuild against the QuickStart_4 sample (A Simple Dynamic
Application) will be three files—a .exe, a .deploy, and a .manifest. Running the .exe file executes as you'd expect. Running
the .deploy file executes as well, but first establishes an appropriate environment for the application, which includes things
ranging from adding entries to the Start menu to establishing the appropriate permissions. The permissions needed are
defined in the .manifest file. The .deploy and .manifest files drive ClickOnce deployment under Longhorn, which you can see
by setting up an IIS application and surfing to the .deploy file using an URL (although you'll want to check out ClickOnce in
the Longhorn SDK for the details of what's going on and how to manage things appropriately).
You should know, as you explore the Longhorn SDK and Longhorn itself, that not everything is perfect. In fact, given the
distance of our ship date from the present as measured in years, there is a lot of stuff that's not perfect. Most of it is
intentional, as we've got a lot of feature development time left, let alone debugging time. However, some of what we wanted
to work doesn't. A lot of work-around information can be found in the Release Notes that comes with the Longhorn SDK.
We've also got the Latest Longhorn SDK Release Notes, which provides more information that we found after we sent the bits
off to the CD reproduction vendor.
For more reading, samples, and Longhorn developer news, you'll want to check out the MSDN Longhorn Developer Center,
where I'll be posting articles and samples from myself and my Microsoft brethren and highlighting interesting stuff from the
community. As of this writing, I'm planning for there to be more than a dozen articles, ranging from introductory pieces on
Longhorn published in MSDN Magazine, to a self-guided tour for new Longhorn developers exploring the user experience. My
hope is for the Longhorn Developer Center to be a hub of activity in the budding Longhorn developer community and if I'm
missing something, don't be shy about letting me know.
After exploring the LHSDK and the developer center for a while and building samples, you'll gradually tire of building someone
else's code and feel the desire to write your own. This is a good feeling, so go with it. I'd advise you to use the samples as
good examples of lots of features of Longhorn. Also, if you have Visual Studio .NET, you can use the Longhorn project
templates, shown in Figure 7, as a great place to start new things.
22
Figure 7. Visual Studio .NET Longhorn Project Templates
Between the Longhorn SDK, the samples, and the Visual Studio .NET project templates, you should be able to go pretty far on
building cool stuff. However, when you run into trouble, stop by the Longhorn newsgroups (as listed in the References section)
to ask your questions and see what other folks are doing.
Of course, after a while, you'll fall prey to the Achilles heel of all developers, the need to build tools and reusable components
instead of applications. It has something to do with showing off for one's friends, I think. Still, this kind of behavior is to be
encouraged. When you've got something you'd like to share, either post it on your own Web site, if you have one, or post it
as a Longhorn User Sample on GotDotNet.com so that we can all appreciate your work. Don't be shy—we're all new to this.
Where Are We?
If you haven't yet figured it out, you're reading the inaugural issue of the Longhorn Foghorn column. My goal with this column
is to document what I find out as I "live la vida Longhorn" (live the Longhorn life). I'll be exploring the new developer
technologies and trying to build real applications for this new version of Windows, taking advantage of the new technologies,
and then documenting my progress. Along the way, I'll be digging into the Longhorn SDK, hanging out on the Longhorn
newsgroups, reading Longhorn blogs, building my own stuff, posting it, and keeping you up to date on the Longhorn
Developer Center.
In short, I'm going to try to be a contributing member of the Longhorn developer community, kicking the tires and sending
my feedback to the various product teams about my progress. I encourage you to do the same. Longhorn is by no means
done, so if you've got issues with how Microsoft is doing things, let us know! Use the newsgroups and the feedback links and
your own blogs and Web sites and tell us how we're doing.
Of course, the only way you'll really know what's right and what's wrong is to dig in yourself. I'm not saying that you should
drop everything and move all of your company's products to Longhorn today. Longhorn isn't going to ship for a while. The
2003 PDC was our way of letting folks know what we're thinking and to encourage early feedback. The bits aren't even to an
alpha stage yet, but if you've got some time to play, please do. The more time you spend playing with Longhorn and the
development platform, and the more feedback you send us, the better job we can do making sure that when Longhorn does
ship, it kicks butt.
References

.NET Framework Developer Center

Security Developer Center

Longhorn Developer Center

Longhorn SDK

Latest Longhorn SDK Release Notes

Longhorn newsgroups
23

Longhorn user samples

Create Real Apps Using New Code and Markup Model by Charles Petzold

Revolutionary File Storage System Lets Users Search and Manage Files Based on Content by Richard Grimes

Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo by Don Box

A First Look at Writing and Deploying Apps in the Next Generation of Windows by Dino Esposito

Updater Application Block, Microsoft Patterns & Practices, June, 2003
Chris Sells is a Content Strategist for MSDN Online, currently focused on Longhorn, Microsoft's next operating system. He's
written several books, including Mastering Visual Studio .NET and Windows Forms Programming in C#. In his free time, Chris
hosts various conferences, directs the Genghis source-available project, plays with Rotor and, in general, makes a pest of
himself in the blogsphere. More information about Chris, and his various projects, is available at http://www.sellsbrothers.com.
Microsoft Details Next Wave of Software Innovation to Developers at the Microsoft
Professional Developers Conference 2003
Showcases Windows Platform Developer Opportunities; Unveils New Windows Platform
Technologies and WinFX, the Next-Generation Windows Programming Model
LOS ANGELES, Oct. 27, 2003 -- Today Bill Gates, chairman and chief software architect of Microsoft Corp., outlined Microsoft
Corp.’s vision for the next wave of software development and detailed plans to help developers take advantage of the next
wave of software opportunities at Microsoft® Professional Developers Conference (PDC) 2003. Highlighting platform software
and development tools designed to enable developers to build a new generation of "smart," connected applications, Microsoft
gave thousands of developers in attendance an early look at a technical preview of the next major release of Windows ®, codenamed "Longhorn." The company also unveiled the next-generation Windows programming model, named WinFX™, which
provides a high productivity approach for building applications.
The Next Wave of Computing
Gates discussed key catalysts in software development, pointing to a
variety of trends driving the next wave, including Web services
interoperability, proliferation of smart clients and software and hardware
innovation. He highlighted key characteristics of the next wave:
developers building connected systems using Web services that reflect the
dynamic nature of the real world; software making oceans of digital
information more meaningful and actionable; and new breakthrough user
experiences, improving interactions between people, groups and
organizations.
Gates detailed several waves of Microsoft platform software to facilitate
applications development, including the Visual Studio® "Whidbey"
development tools, Microsoft SQL Server TM "Yukon," smart device software
and Windows "Longhorn." Gates highlighted how Microsoft’s integrated
platform approach, with support from a broad developer ecosystem,
provides a strong foundation for developers to pursue the next wave of
software opportunities.
Bill Gates outlines Microsoft's vision for the
next wave of software development at the
Microsoft Professional Developers
Conference in Los Angeles, Oct. 27, 2003.
Click image for high-res version.
"It’s an exciting time to be a software developer," Gates said. "Continuing
hardware advances, powerful tools and the potential of anything on the
Internet to become a building block all make it a great time to do
pioneering work. Microsoft is investing heavily to make Windows the
optimal platform for developers who want to build on this next wave of innovation."
WinFX: The Next-Generation Windows Programming Model
Also delivering a keynote address at PDC was Jim Allchin, group vice president of the Platforms Groupat Microsoft, who
introduced WinFX, the application programming model for the next generation of Windows, and a number of new Windows
platform technologies for developers. WinFX evolves the Microsoft .NET Framework’s programming model, greatly increasing
developer productivity as well as application security and reliability.
Allchin discussed four major areas of platform innovation for developers in Windows "Longhorn":
24

Focus on the fundamentals. Windows "Longhorn" builds on Microsoft’s
investments around increasing security, performance, connectivity and
scalability. "Longhorn" will extend the security technologies in
development for Windows XP to protect against malicious exploits, as
well as introduce new security improvements at the architecture level
that developers can take advantage of to help extend security across
applications and services. Performance improvements will come from
new technologies such as SuperFetch, which will help applications launch
more quickly, and ClickOnce installation, which will speed and simplify
application deployment.

New Windows presentation technologies, code-named "Avalon."
"Avalon" is the graphics subsystem in Windows "Longhorn" and a
foundation for the Windows "Longhorn" shell that will enable developers
to build breakthrough user experiences. It provides a unified architecture
for presenting user interface, documents and media. "Avalon" enables
developers to easily take advantage of leading-edge graphics hardware,
and provides native support for declarative, markup-based programming,
making it simpler to build Windows-based applications.

New Windows storage technologies, code-named "WinFS." "WinFS" is the next generation of data storage that
provides vastly improved ways to find, relate and act on information. "WinFS" is the storage subsystem in Windows
"Longhorn" that more securely stores both structured and unstructured data. With "WinFS," developers can take
advantage of prebuilt data structures in their applications, and extend those structures to handle their specific
requirements and add unique value to the application by creating new structures.

New Windows communications technologies, code-named "Indigo." "Indigo" is a new approach to building
and running connected systems built from the ground up around the Web services architecture. "Indigo’s" advanced
Web services support provides capabilities for more-secure, reliable and transacted messaging and interoperability.
"Indigo" unifies a broad array of distributed systems capabilities in a composable and extensible way, spanning
transports, security systems, messaging patterns, encodings, network topologies and hosting models.
Jim Allchin, Microsoft group vice
president, introducing a new
application programming model for
Windows at PDC 2003.
Click image for high-res version.
Allchin discussed how developers that invest today in managed code with the .NET Framework, smart client applications and
Web services were well positioned to take advantage of the opportunities ahead.
Putting New Platform Technologies to Work
To illustrate the variety of new opportunities these new Windows platform technologies create for independent software vendors
(ISVs), Web and corporate developers, Allchin was joined onstage by representatives from Adobe Systems Inc., Amazon.com
Inc. and Merck & Co. Inc. to demonstrate prototype applications exploiting the new Windows "Longhorn" technologies.
"Platform innovation creates new possibilities for developers by building on today’s investments to advance the application
development process," said Allchin. "The success of ‘Longhorn’ will come about through our commitment to working with the
software-development community — the people who turn the potential of Windows into the power of personal computing."
Adobe Systems, a leading developer of software for consumers, creative professionals and enterprises, demonstrated the
possibilities for ISVs created by integrating the new "Avalon" presentation technology and declarative programming techniques
for Windows. Using these technologies, a prototype version of Adobe After Effects showed how developers could unify
documents, cutting-edge graphics and media. For example, developers would now be able to build animated charts and graphs
that are linked to back-end data sources to produce a smart solution that displays stock prices, sales and other information
within a high-end professionally designed format.
"Many developers have not taken the visual design of their applications seriously enough, with the most innovative work
restricted to creative professional software and games," said Greg Gilley, vice president of Graphics Applications Development
at Adobe. "‘Longhorn’s’ new ‘Avalon’ technology brings the designer and developer closer, so they can truly collaborate on
creating software applications that are as beautiful as they are functional."
Online retailer Amazon.com joined Allchin to show how new technologies such as "Avalon" and "WinFS" can enable Web-based
businesses to create more seamless experiences for online shoppers. Amazon Chief Technology Officer Allan Vermeulen showed
off a prototype application, built using Visual C#(R) and "XAML," a declarative markup language for "Avalon," that demonstrates
how the Windows user interface subsystem builds on the features available through Amazon Web Services to create an entirely
seamless experience for users.
"Microsoft’s platform innovations have the potential to empower Amazon Web Services developers to quickly and easily build
more-connected, information-driven applications that start to blur the line between traditional applications and the Web,"
Vermeulen said. "With Windows ‘Longhorn,’ PC applications come to life — enabling developers to deliver an experience capable
of conveying a unique brand identity in a desktop application."
Pharmaceutical research firm Merck and Co. and clinical trial automation developer DataLabs Inc. also took the stage, with an
application that connects information from patients, doctors and technology systems to automate collection and processing of
data in clinical trials based on the interoperability functionality of the "Indigo" technologies. The application will have the ability
to connect thousands of clinical trial participants in remote locations, reducing the five- to seven-year time frame typically
required for clinical trials by eliminating redundancies in the data collection process.
"Each clinical trial has hundreds of patients, physicians, scientists and regulators that all need to work together, who are rarely
under the same roof, or in the same organization, or on the same network," said Rich Gleeson, vice president of Enterprise
Solutions at DataLabs. "With the developer capabilities in Windows ‘Longhorn,’ we will have the ability to build a new class of
25
more-secure and connected business applications that connect real-world relationships among people with powerful software to
drive greater business efficiencies across the entire clinical trial process.
About the Professional Developers Conference
The Microsoft Professional Developers Conference (PDC) is Microsoft’s premier developer event. The PDC brings together the
world’s top developers to get an early look at Microsoft software innovations, to interact with the technology leaders within
Microsoft and the broad Microsoft development community, and to discover the opportunity presented by targeting the
Microsoft platform.
About Microsoft
Founded in 1975, Microsoft (Nasdaq "MSFT") is the worldwide leader in software, services and Internet technologies for
personal and business computing. The company offers a wide range of products and services designed to empower people
through great software — any time, any place and on any device.
Microsoft, Windows, WinFX, Visual Studio and Visual C# are either registered trademarks or trademarks of Microsoft Corp. in
the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
http://www.microsoft.com/billgates/speeches/2003/10-27PDC2003.asp
Remarks by Bill Gates, Chairman and Chief Software Architect, Microsoft Corporation
Microsoft Professional Developers Conference 2003
Los Angeles, California
October 27, 2003
BILL GATES: There are a lot of lessons there to guide us as we go forward.
Microsoft talks about this decade as the Digital Decade. What we mean by that is that activities like listening to music,
organizing your photos, annotating those, sharing them, buying products, all of these things will be dramatically driven by
software in a way that they were not at the start of the decade. When we map this into business productivity we can say that
the increase in productivity will be much stronger in this decade even than it was in the last, even though it won't be
accompanied by some of that same hype.
Now, part of that is that the expectations of the last decade, some of them required more time. The idea of e-commerce
required a new platform. What is that platform? It's the industry standards of Web services and companies like Microsoft
with .NET creating tools that make building those applications practical, creating the standards for the exchange of
information.
In this decade there's no doubt we'll see every form-factor advance, and the form-factors are very complimentary, from the
wrist-sized to the pocket-sized to Tablet-sized to desk-size to the wall-size as well. And so across a large range of activities,
whether it's organizing calendars with friends, scheduling business appointments, understanding sales results, filling out what
used to be paper forms, searching for information, all of these things will get software involved in a very deep way.
Now, we've had too much complexity, too many different commands, different ways that information has been stored that
people have to understand, so in order to achieve this we not only need to solve things like security and applications, but also
a lot of unification of the different things that have existed on the PC.
We certainly can think of this as having three characteristics that I'll go through: connected systems, information driven and
complete end-to-end experiences.
Connected systems, we can think of lots of different networks, the whole Customer Relationship Management things about
a network of customers, social networks that we're seeing through neat software approaches, personal networks, scientific
networks connecting up to see data, for example, what has been done using Web services in the whole field of astronomy,
where you have all the databases at different sites and you can reason about principles of astronomy and gather information
to see if the data is consistent with that.
Connecting those things together so you don't think about the physical locations, so that it's easy to set up and easy to
secure, there are some deep capabilities that are required in the platform for these connected systems.
What are the breakthroughs? Well, first and foremost we have the advanced Web services. I hope all of you have been
following the progress in this area, and it was very exciting just in the last month to have an event that both Microsoft and
IBM created where we showed IBM's WebSphere and Microsoft's Windows .NET connecting up with deep security, transaction
capabilities and reliable messaging. Those are the key features that characterize the advanced Web services and those
specifications are in a very strong form today. We're soliciting comments, having workshops, even doing interoperability fests
and we hope to have those finalized in standards bodies by the end of next year.
The workflow capabilities come in once you can do the connections and exchange the information, tracking the state of things
and not just a programmatic level, letting end users come in and device workflow, see the state of these things; that will be
part of the platform.
Workflows often transition from a pure software-driven state to a user-driven state. And so making that boundary a simple
one is something that we have got to do in the platform
26
Distributive management: Management software historically has been a whole other set of concepts. It gets layered on
top. It has its own way of doing data storage, inspections, self-description. You have to read both manuals, and it's just a
world apart.
With Web services we're not going to do that. We're going to use the mainstream architecture to build in a level of
management capabilities that goes beyond what traditional management systems did -- including things like policies on how
quickly you expect something to execute; including policies on how you deal with certain error conditions, and so that as
much automatic activity can take place as possible; understanding what kind of failure might take place, and being able to
model those so that it's not just thousands of error messages when, say, the network connection goes down.
These technologies will have to work with systems that are disconnected. You know, you may have seen what we've done
with e-mail in the latest round of Exchange and Outlook, where it's cache-mode. That is, we will replicate whenever we can,
but it works great offline. We don't have the notion of the mail client being in online mode or offline mode. It's always
working in whatever connectivity is there -- we'll go out and get the new information. That sort of architecture needs to be
available to all the applications.
Likewise, peer-to-peer networking -- peer-to-peer is very, very important, and it's something that the rich messaging
architecture built into the system will have to support. And that's why we'll be able to thinking of computing in a different
way, because those connection things won't have to be recreated by every piece of software.
Users want to manage information. We have the information in silos -- mail is separate from the files, is separate from the
Web pages. And the information has not been structured. All the operating system knows about files is that they are binary
screened. That's it. You know, something like the address book is at the application level, not at the platform level. So if
you want to share address book across applications, you can't even do that. The ideas with searching -- the search command
is different in every application. So learning how to search mail and navigate mail is different than learning that for files.
When you get attachments sent to you, storing those, understanding the different versions you might be getting -- it's very
complex. And so just dealing with information has not been very rich. We don't have standard schemas for the concepts.
We have the clipboard, but we haven't gone beyond the clipboard to structure the information, to make replication in
searching just a very straightforward thing that you expect out of the system.
So in the next wave we've got to have those rich views, got to have content indexing, got to unify the storm. We have got to
have the schemas allow you to classify things so that things even appear to organize without you getting involved.
We see a little bit of this in the Outlook Client, where you have search folders, so that if you want to see all your mail from
one person, you just click on that folder. You don't have to drop something in there, because it's essentially a standing
query. And so information can be in many locations; it's just a matter of defining the criteria, not having to move it around.
The ability to intermix files and mail and notes into one hierarchy that is organized the way that you want it to be is a ver y
different thing. And this ability to say, "When do you want to be notified?" -- what we call information agent -- that, OK, if
something new comes into this folder, that's urgent for me -- you know, "Contact me on my cell phone or interrupt what I'm
doing," depending on the context. That again needs to be in the platform. Because if you don't do information agent in the
platform, every application is constantly trying to get on top and set up its host and will hurt the user. And there's no
framework for making sure that the user's time is what you optimize for -- letting them be in control, not just for mail but for
all the different events that take place in the system.
We need to bring this together with full end-to-end experiences. And that means the visualization being richer and more
engaging; it means taking greetings and having it be very attractive on the screen, so that the tasks you do on paper shift
very substantially towards doing notes on the screen -- even things like managing subscriptions for people or the very rich
search and replications that I talked about are key to these experiences.
We will build speech capabilities into the system -- a big advance for that in "Longhorn," in both recognition and synthesis,
real-time. You're seeing that become more and more important. We've got now the instant-messaging capabilities. We've
got real-time connections add-ons. But this is something every application will use in the next generation. I talked about
reading and visualization.
The hardware level is key here, these qualitative changes where desktop displays will be either very large or multi-screen;
you know, three 21-inch LCDs, or a single 26-inch LCD will cost only $500 or $600 in three or four years. So we have to
think about managing the windows and letting people see a lot more than they can today.
The graphics processor I mentioned will be a lot better there. So we can use all of this for ink, animation, sound processing -a different way of the system.
Two examples that I like here: a consumer example is managing your memory -- not just your photos, but all of the timeline
and schedules and annotations and movies that you make, and making those rich and easy to navigate. That's something
that people are interested in, and it unifies a lot of things that have been separate. Until we had a lot of this database
technology, we couldn't unify those things. The photo application stored things its way, the sound application its way, and
they were not brought together.
Another, thinking about meetings in the future, how you prepare for them, schedule them, the meeting itself with people not
local, using things like Live Meeting to connect up and share. And then after the meeting, having that transcript that's made
automatically -- automatic direction, where you take the audio signal and know which visual view would be most appropriate,
and therefore let people watch the meeting later, but watch it faster than in real time, and just watch the parts that they're
interested in. So each of these is a pretty dramatic example that drives the platform and can make a very big difference.
So it's going to come together in "Longhorn." This is our next major release. Jim will make sure -- it's very clear we're at the
beginning of this process. You know, we're opening it up to you, showing you what we're thinking, because we need your
feedback. We need your involvement to get this right.
This is going to be a very big release -- the biggest release of this decade, the biggest since Windows 95. We're tackling
three different areas: the fundamentals -- that means the security, the auto-installation; applications not interfering with
each other. There's a lot in the fundamental area. Jim has very deep passion for this, and he'll be going through all the
different things that we've been able to do there.
It's an advance for customers, being able to connect up, being able to have your information appear on all your different
devices; having that information structured without you doing a lot of work; having less commands despite the new richness
27
that's there, and using capabilities around the agent to take and put you in control, so that understanding your privacy and
what mail is coming into you. You feel like you have a few simple things you do that put you back in the driver's seat there,
so you have confidence and control.
For developers, we want to take the things that people have had to duplicate and bring those into the platform so you can
focus on other capabilities. So faster developments are driven by the major new sub-systems.
Here's the simple diagram of "Longhorn." You'll see this many times over the course of the next few days. The
fundamentals, of course, are down in the base. Avalon is the presentation system. This is a timely advance. GDI, user,
those are cool things, but those were really architected with memory limitations and graphics limitations from a long time
ago. We're even seeing some applications go around and use direct decks, like Movie Maker does, to try to get a new level of
visual capability. But it's time we brought that all into the mainstream -- the clear-type reading capabilities that a few
applications are using, and that you know some people don't even know are there to turn on even when they're using that
LCD display. Well, we can go a lot further by designing it in.
So it's a built from the bottom up, built around XML, new display system. It's organized around a compositing approach, very
rich, very extensible.
"WinFS" -- this is unified storage. Some of you here have heard me talk about unified storage for more than a decade. The
idea of taking the XML flexibility, database technology, getting it into the file system: that's been a Holy Grail for me for quite
some time. And here it is. Thank goodness we have got the powerful systems to be able to do this thing. Thank goodness
we have the evolution around XML and user interface capabilities, so that this can all come together.
And then, finally, the piece that takes a lot of things that were extra cost options -- queuing software, transaction software,
pub sub software -- and takes this new messaging approach and makes it built into the platform. So connecting up between
applications, whether it's within the system or across the entire globe, that is very straightforward.
We want to give you a quick glimpse of some of these things and how they come together, and so I want to invite the person
who is really driving the user interface to come together to give you a look. So let me ask Hillel Cooperman to come up and
give you a sense of what Longhorn is all about. Good morning, Hillel.
HILLEL COOPERMAN: Good morning. (Applause.) Thanks, Bill. How's everybody doing? OK? Well, maybe we can get you
a little more excited. Do you want to see "Longhorn?" (Cheers.) All right, let's take a look. Let's bring it up on the screen
here. Now, we are going to start off with CTRL-ALT-DEL, because it wouldn't be Windows without CTRL-ALT-DEL, right?
(Applause.) Clapping for CTRL-ALT-DEL. That's all right, you can clap for it. Save your claps -- I've got better stuff.
All right, see here, we are going to log in, and when I log in I want to show you the brand-new "Longhorn" desktop. Here it
is. Let's open up a window. See how that comes in?
A couple of things going on here. First, there's a new look. And, as excited as we are about that, and we hope you think it's
exciting and beautiful and professional, but it's still early. The most exciting part is that making a new look is relatively easy.
Building this deep into the platform as part of the platform that you get to take advantage of, that's tough, and that's what
we have been working on. So, if you notice, things like the transparency that we have here on the Windows -- watch as I
move this kind of under this guy on the side -- you can see it in the background there. Let me open up a couple more
windows. Watch how these actually animate onto the screen. And this is using things that are part of "Avalon," just like Bill
talked about -- including things like pixel shaders, the desktop composition -- all this advanced graphics functionality that to
date has been typically the domain of game developers, now available to actually render you either on the desktop and, of
course, in your applications.
And just in case anyone is thinking that maybe this is some kind of prototype or something, let's run a classic application.
Anyone remember VisiCalc? There it is. It's 20 years' commitment to compatibility. (Applause.) And now we are going to
see if we have 20 years' commitment to usability, because I am going to figure out how to quit this thing -- forward-slash, S,
Q, Y -- oh, yeah, there we go. (Applause.)
All right, so let's take a quick look at the desktop. And before we move on to some of the big pillars that Bill talked about, I
want to talk to you guys about that guy on the side there. It looks pretty prominent, so we should address it. Right now
we're calling it the Sidebar. We'll figure out what the final name is at some point. But what's interesting about this is a
couple of things. First, it actually built in these common parts that show information, notification, services, that a user might
really be interested in seeing when they're working on their main application, without popping up a window that covers it. For
example, the time or their buddy list or a slide show, which, of course, you can add and remove these tiles here -- or even an
RSS-feed built right into the sidebar. (Applause.) And you want to hear blogging or about to blog when they get -- who is
going to be the first person after the keynote to go and post on their blog. Scobel, OK. Well, we'll see. It's going to be a
race. But the best part about this is not that we have this functionality built into Windows. The best part, like everything I'm
going to show you today, is that this is part of the platform. This is part of the SDK that you guys are going to get, you guys
can write to it, and we think you can do great, great things with this.
All right, so let's dive into some of the things Bill talked about. Let me open up this documents window. Now, in some ways
this is a pretty straightforward screen. This is essentially the evolution of my document, but a couple of things are different.
First of all, we are showing almost 1,100 items in this view, which, frankly, given today's experience, it would be a little not
useful. And, in fact, these items are not sitting in one folder. They're located across the system. And this view is actually a
dynamic view that is generated for you right in the system, and of course available as part of the platform.
So let's do a simple thing that you think would be simple today, but "WinFS" is going to provide built-in search facilities. So I
have 1,100 items. I want to find all the items that have something to do with "Longhorn." So as I type I want you to watch
the number right here, 1095, go down to 30, and see how fast that happens. By the time I'm done typing, we're down from
1,110 to 30 items right there in the system. (Applause.)
Now, built-in search capabilities -- this is something you're going to expect. But let's talk about the kind of self-organization
that Bill talked about in "WinFS." For example, let's say we want to take these 1,100 items and organize them by a property,
a property that is built into the schema. So right here we have author. We click on "author," and we could actually filter
down the 1,100 based on who the author is, or we can do this new thing called stack. And when I click on "stack," it actually
draws a new view that shows all these items in these stacks by who wrote them. And in fact, if you look carefully at the
stacks, they have different heights, depending on how many items are represented in them. And because they are not
physical locations, one item can show up in more than one stack. And these are folders that when created this dynamic view
28
being built for me on the fly based on the rich structured meta data that is sitting in "WinFS" on these items. So let's doubleclick on "Bill."
Now, the properties that are built into the schema are well and good. But of course you are going to want to add your own.
And it's not just users and IT professionals, but of course developers that are going to go extend these schema in any way
they want. So let's actually add a property right now. Let's add project to our view. I click right here on "project" and I can
stack by project. And in fact I can go down here and see here's all the stacks, and these five items down here aren't attached
to any projects. So you might think, based on how it works today, the painting metadata on an item in the file system is
difficult -- right-click and go into the tabs and it's kind of a cumbersome process. I'm going to take this document right here - and anyone who loves their Tablet will notice that we have ink file names right in the shell view. I'm going to take this,
each collaborating file name, and I'm going to take this and I'm going to -- painting metadata on it, for example the Windows
"Longhorn" project -- is as simple as drag and drop. And in fact I didn't actually put it in a folder. I just painted metadata on
it. If I double-click on Windows "Longhorn", sure enough that document is going to show up in our query results right here.
Here it is.
All right, one more thing. You might say, "Well, I understand that these views are generated dynamically. I understand this
is all based on this structured metadata that Bill was talking about, but I could kind of approximate this with folders today. I
could make a bunch of folders for authors, and then in them have project folders." I'll tell you something you couldn't do.
You couldn't do it, have that exist, and do the reverse; for example, be able to navigate first author, then project or first
project then author. So let's actually take a look. And if you notice, by the way, notice where my cursor is, as I've gone
through the system it's actually built the query for me right in the user interface. So let's go back up. The document -- and
instead of documents-Bill Gates-Windows "Longhorn" -- let's go add "project" to this view again. Let's stack by project, scroll
down and go to Windows "Longhorn" -- all getting dynamically generated by "WinFS," stack by author, double-click on Bill,
and there's the same 50 documents that we showed in the original query coming at us from a different direction.
And the best part about this is not just that you can do this in the system, but all this is available to you as developers as part
of the platform whether you want to use the com controls or talk directly to WinFS, and render any way you want.
(Applause.)
All right, so there are a lot of documents in the world but having structured information in your system is not just about
documents. For example, what about people? Bill talked about actually having all the different ways that people get out of
sync today. You store people in cell phones, people in groups in your buddy lists, in your address book, in your corporate
directory. Right now we're going to represent this non-file item right here, again another one of these views, this is people
and groups, again viewed in the same way that we view documents.
This first thing right here is a group. All these are people. I can right-click on Bill, for example, and, in fact, there's a bunch
of things I can do with him here. So I could add him to my side bar so he would end up right here on my buddy list. Bill and
I are often having buddy list conversations late into the night.
And I could do something called Show Communication History. Today if I want to see all the faxes, all the files that Bill
shared with me, all the notifications or e-mails, I have to go to several different programs to go see all that stuff. Right here
I can actually generate this view dynamically right in the system coming out of WinFS because all these items, faxes, RTC
conversations, e-mails documents setup are all part of the basic schema and we can generate this view on the fly, and again
this is part of what is available to you in the platform. (Applause)
So I keep talking about the platform but I keep showing you how we're using it ourselves. So we thought about let's show
you an application using this stuff. And instead of starting off with an application that's built top to bottom, on top of
"Longhorn" we said we thought we'd start with something that's already a big investment in Win 32. Anyone here have any
Win 32 investments? Just a couple.
And, as you already know from what Bill said, if you've already been investing in .NET on XP, you're well on your way to a
bunch of this stuff, but we really want to make sure that you can leverage the most out of your existing investment.
So, here we are in this Win 32 application. We took it, it's an OE built-in Windows mail app. And again, notice as I type I get
this little choice here to find more names. What this brings up is a common file dialogue, but for people. It's not files after
all; they're people sitting in WinFS and it lets me actually look at this entire list in this big corporation of all the people I can
choose from or even search my corporate directory. I think we have the corporate directory from Microsoft here, but I can
search, let me search for Chris. It's very convenient that there's only one Chris at Microsoft. I don't know how we made that
happen. All right.
And now notice, by the way, that's just bringing up the dialogue, I can embed that right in my application. As I start typing I
get an "Avalon" common control embedded right in my application that let's me pick from a variety of people to actually go
and address my mail.
So, we can go, send the body of text: "No need to write your app to take --" let's see if I can get through this without a
typo. Oh yeah! And, hit Send. There you go. Existing application, leveraging the platform, right with your existing
investment and already getting the benefit right out of the box.
All right. So. If you've been paying close attention you may have noticed up on my Sidebar I have a buddy list and this
person is offline, these people are online, but here it says Craig is nearby. And, in fact, if any of you've been watching up on
the stage Craig is in-fact nearby. Hey, Craig.
CRAIG BEILINSON: Hey, I am nearby. More importantly though, my laptop is nearby.
HILLEL COOPERMAN: Hey Craig, how's it going?
CRAIG BEILINSON: Fabulous, how are you?
HILLEL COOPERMAN: Great.
CRAIG BEILINSON: Hey, good demo so far, but I thought really before the PDC gets kicked off, I thought, I've been taking
some notes, I can give you some feedback on your presentation.
HILLEL COOPERMAN: Actually, now is not a good time. (Laughter)
CRAIG BEILINSON: We're among friends, aren't we. You know, the nicest thing about this is how natural and unscripted it
sounds. (Laughter) Feels very natural to talk just like this.
29
HILLEL COOPERMAN: All right. So, Craig wants to do a pretty simple thing that everyone can relate to. He wants to share
some information with me. He has a peer-to-peer connection with me, this persistent peer-to-peer connection that's again
part of the platform in the communication stack and he wants to share something. But he doesn't just want to share it, he
wants to do a little bit of show and tell.
So, in fact, what Craig has done, he's done a couple of things already. One, he's made it possible for me to see him on our
network right here because he's nearby. So, not everyone can do that, he's allowed that to be possible. And he's already
started publishing the presentation on our network, so he's projecting his screen onto the network. If there were more folks
with this type of machine right here, you'd all be able to see it projected. It's kind of like a broadcast.
So, I could either click on Craig or I could go right here in the Start Menu and get a list of all the available presentations that
are being broadcast. So let's view the presentation, here's Craig. Now what's going to come up on my screen is actually a
live view of what's on Craig's machine. You can see his Start Menu, Task Bar, et cetera, and he can actually move around as
we go. This is not a static image. This is a live broadcast of what Craig is doing. Right now it's one-to-one, but it could be
one-to-many right off the "Longhorn" PC.
Now, as cool as that may be, let's actually resize that. You may think -- no there is no bathroom breaks here, I'm sorry. You
may think that actually resizing would mean all sorts of unmanageable scrollbars and having to go and move around to try
and see everything at once. In fact, I'm just going to hit Restore and watch what happens to the window automatically
because of our "Avalon" presentation services. Automatic resize on the fly; even as I resize it, it moves around and Craig is
doing it live right on my desktop. (Applause)
Alright, so let's move this down here. So in some ways we've done the hard part. Craig has done this personal TV broadcast
essentially to my machine. The easy part, you would think, would be just sharing a file, not broadcasting but just simple file
sharing over this persistent peer-to-peer relationship that we have. In fact, that frankly is pretty hard these days too. So,
Craig is now going to open up one of these dynamic views that I showed you before like the communications history, like
documents, like contacts of all the files that I've shared with him.
Here they are. Now I want you to watch this space closely. I'm now going to move over to my desktop, I'm going to right
click on this file, this image, and I'm going to hit Share with Craig and watch. When I click, what happens over on Craig's
machine: 3,2,1, boom, there it is. Instantly replicated over to Craig's machine. Even if he were to disconnect, he has access
to it. Craig, double-click, let's make sure it's the same one. There it is. (Applause)
All right, so, if I check our clock here, we are running out of time so I'm going to move along. Thank you, Craig, great job.
(Applause)
OK, so again. I've talked to you about the fact that we're building a lot of it that on top of this technology we're building a
ton of the Windows experience. But the fact is we want to show you how an application that's built top to bottom might look
on top of the pillars that Bill talked about.
So, for example, let's open up this Web page here. This is a common situation. You have an application whether it's an
internal application or a commercial application that you want to deploy to your customer. Today deployment is hard. It's
expensive to test, you have to make trade-offs between building a Web application or a client application. It leads to all sorts
of different switches and results when it comes to deploying your app.
I'm going to click right here on the Web site from this developer and what is going to happen right now is the app is getting
installed on my machine as we speak. I can tell you of no worse fear for a demoer than installing a demo in front of a big
audience.
So, there's no big dialogue. This is essentially just the delay while we go and make sure the app is going to work. We do all
the security stuff, all the bits come down off the wire and we get this brand new Avalon-based application launched right on
our screen, one click. (Applause)
All the things that I showed you before are also available in here. The search facility built into WinFS, I just go type my
string, bit goes, sure enough there is my item.
Now, what are these things? We talked to you before about viewing items that are in WinFS right in the shell and how that is
available as part of the platform. Well, here's a bunch of items in WinFS that are shown in this application.
Furthermore, we talked about extending the schema and how a developer could do that. So, we have arguments and
evidence and precedents and people, all schema extensions that this developer did in this sample application to the bases
scheme that comes with Windows.
We talked about creating relationships between items in WinFS. Notice as I hover over each of these items, the items that
show up in yellow are actual relationships. And so if I were to click, for example, right on this person, watch. All the items
related to it show up in this custom "Avalon" view. (Applause)
I want to show that you one more time because I want to show you how seamless it is. Remember, yes, "Avalon" provides
built-in common controls that you can use to get up and running fast and they're very flexible, very powerful, but at the same
time you can always talk to "Avalon" lower in the stack and decide you want to go do your own custom view. And the
transition between these is just seamless. Click, animate, there's the custom view.
Now, "Avalon" is not just about showing you why, it's not just about graphics, it's about media as well. So here as part of
evidence we have a video, let's click on that video and I want you to see how this developer and their sample app has tried to
show that integrated into the application itself. This is video of the actual accident. How convenient that we have
professional camera crews filming the accident from multiple angles. I don't know how that happened.
But, again, look at that again. I mean, right in the application they decided they wanted a circle, they decided what to show,
they decided to face it back out into the UI, all built on the platform that we're providing in Longhorn.
All right. So let me do something else. Now I talked a lot about Win FS, talked a lot about "Avalon." I want to talk a little bit,
because we don't have too much time, about Indigo. When you think about Indigo you should think about Web services. It's
really on that path that Bill talked about in terms of making all those connections between all the information at work and at
home.
So, in this application, they've exposed a Web service Lexus/Nexus. What happened? Lexus/Nexus decided that they wanted
to expose their service as a Web service. This ISV decided to consume that Web service. We showed you before searching
30
across the local machine, across the corporate network and now let's add searching across this Web service. So I click here,
hit Search. Sure enough, I get results from all three places. Go to Lexus/Nexus. Here's my document and remember,
secure authentication, the transactions have all happened in the background. And in order to consume this data from this
Web service we don't have to go to the Lexus/Nexus application. Lexus/Nexus information is showing right in this developer's
app courtesy of Indigo.
And, if I want to bring this information right into my application and my network, or this document rather, I can click on it,
drag and then drop it and go create a relationship on the fly straight from the Web services. Let's drop it on Jeff and then
notice as I hover over Jeff, here's the document, when I hover over the document, there's the relationship with Jeff. I click
on Jeff. Let's click on Jeff. Here it is.
Now, I talked about "Avalon" being this great platform for showing media and UI and great graphics. But you know what?
Text and layout and integrating that into the flow is also very, very critical. So, I'm going to click on this "Avalon" formatted
document, and you will notice it's courtesy of the Lexus/Nexus Court Link Web service. And, in fact, this is all rendered via
"Avalon". If I were to, for example, hover over the scroll bar here at the bottom, notice I get this rich thumbnail as a third
page. Click on it. Navigate. Click on it. Navigate. (Applause)
Now, let's open another one of these. Now, here's another example with a document with text and video integrated. I can
go do that same little thumbnail preview on the scroll bar. I click, navigate to page three and here's the big question. If I
hover over the area of the scroll bar for the second page, will I get live video in the thumbnail? Yes, yes, let's do it. Click,
there it is, live video, right there you can see it. Let me click and go straight to the page of the document itself. (Applause)
All right. That's all the time I have but if there's three things you take away, one, we are very excited to show you this.
There's several thousand developers up in Redmond watching us live right now, thrilled that we finally get to show you some
of our early work and very excited to hear to your feedback.
Second, we're using this ourselves. We're building the next generation of Windows on top of this great technology.
And third, we're thrilled to see what you're going to do with it. There's a lot more great stuff coming up. Thank you, very
much. (Applause)
BILL GATES: Well, it's fun to see "Longhorn" coming together.
We have three different waves of software over the years ahead. We have the software that's out now and this year we had
more new product introductions than in any year in Microsoft's history. Just what we call the Office System that was
introduced in New York last week had a lot of different pieces driving XML into the Office platform, letting document-sharing
work on the server with SharePoint in new ways, bringing real time in, so a lot of neat things that we can take advantage of
today, including real focus on the fundamentals for even the existing software packages.
You'll hear a lot tomorrow about the wave that includes the next generation of SQL Server and Visual Studio, and then,
of course, most of what this event is about is "Longhorn." But targeting your work against each of those waves we think is
pretty important, so you don't miss any of the opportunities.
We're already seeing some neat things happening in the marketplace. PC growth is back at a reasonably healthy level this
year. The kind of applications we're seeing on the smaller devices, this is a Motorola phone called an MPX 200, of course, it's
got .NET built in, neat new things, these are really just coming into the marketplace but the popularity has been pretty
incredible. Motorola is a new partner for us, just announced. Also Samsung has this, which is their I600, which is a very rich
media focused experience.
So in the mobile scenario the second generation of tablets coming along, 64-bit servers, connection out to Xbox with some of
the things we're doing there; all of these opportunities are starting to unfold but it's going to take a major new platform leap
to be able to have the full capabilities that these things demand.
So a quick summary, first the fundamentals: We've got some online things that talk about applications and security
applications and working with software updating, which for us is our SUS and SMS products, management packs around our
MOM capability, all of those things fitting into that fundamentals area. Designing around Web services, making sure you've
got that as your extensibility architecture, your connection architecture, you're seeing us drive forward with that. Using
managed code for any new things you do and yet we allow managed code to work with existing code. Exploiting the client,
delivering data in the form of XML to the client and then having local rich rendering while still being able to have mapping to
HTML for reach, that's something we're making very simple. Eric Rudder tomorrow will really go through how that approach
is becoming mainstream.
The final point is we want your involvement in telling us what we've got right with Longhorn, what we've got wrong with
Longhorn. We've got years of work here and it's going to be shaped by your involvement in the community activities. And
we've done a lot of new things, including the ways we've refined this event, getting our developers online, to really make sure
that the community component drives "Longhorn" to be exactly what it should be.
So I'm excited about the opportunity, thrilled to have you all here kicking off the "Longhorn" generation.
http://www.microsoft.com/presspass/exec/Jim/10-27pdc03.asp
Transcript of Remarks by Jim Allchin, Group Vice President, Platforms
Professional Developers Conference 2003
Los Angeles, California
October 27, 2003
JIM ALLCHIN: So what do you think of "Longhorn?" Huh? (Cheers, applause.) You want to know how to do some of that
stuff? That's what my talk is about. And we're going to start with this eye chart. (Laughter.) This is going to be up on
http://commnet right after my talk. It's also going to be on MSDN.
Now, during the next four days you're going to have an opportunity -- talking with some of the best architects -- to drill down
in all the boxes on this slide, and there's more besides what I showed here.
What I'm going to do is just focus on the four areas that Bill already mentioned. I'm going to talk about the fundamentals of
"Avalon," "WinFS" and "Indigo," and we're going to do what I call a lap around "Longhorn" to get you sort of in the roadmap
31
about all how those pieces fit together. And then during the rest of the conference you're going to be able to drill down into
those.
Now, if you have all this great functionality you need a way to be able to interface into it, and we call that WinFXTM. And what
is WinFX? It is the next step beyond Win32. And if you've programmed to the .NET Framework, it's going to seem like second
nature. It's very well-structured. This is something that we expect to last decades, and so we've spent a lot of time thinking
about how the classes, the types, the methods, the properties, the events all fit together so it's a holistic environment.
Actually, every time that a new extension is put into the system, it's reviewed by a set of system architects and then it's
usability tested by a set of developers. We think we're doing a good job. We're going to be interested in what you provide to
us as feedback about this.
Of course, another thing that we wanted to do was increase the capability of what you're able to do in your code. And at least
for me, the number of lines of code that I can write is about the same; actually in my case a little bit less than what I used to
do. But in the last ten years, I don't think the productivity in terms of number of lines of code has really gone up that much.
So what can you do about it? Well, I have a saying. The best line of code that you do is the one that you don't have to do.
And what we're trying to do in WinFX is bring up that capability so things like add ref and release you don't have to think
about, so you can make your code more resilient and write your code faster.
Lastly, in this next step in WinFX, we're trying to continue on our commitment to compatibility. So if you have a Win32 bit
app or you have a .NET Framework app and you want to start taking advantage of some of the extensions that we have in
WinFX, you'll be able to do it in a fairly straight ahead way.
Now, I believe in your bags you will have gotten this chart. This is the namespace chart. And I encourage you to study it
because it will help you understand, especially using Visual Studio, but help you understand how the namespaces fit together
from all the areas that I'm about to talk about.
So now what I want to do is start the lap. In the fundamentals area, even though we didn't really show any of it in Hillel's
demo -- he basically just showed a top-level view -- "Longhorn" is really about fundamentals as much as about any of the
other areas that we're trying to move ahead.
Today, it's still too easy for a driver to confuse other drivers or confuse the operating system, it's still too easy for applications
to confuse other applications, and we're spending time trying to create more firewalls, more sandboxing between these
applications and drivers so that you have a more resilient environment.
So the big challenge today: deployment, huge challenge, huge. It's probably the number one I hear following security. And
it's not just when you deploy your app, it's how you service your app after the fact through patching or whatever.
And then there's this incredible growing security burden. It's not only in our code, it's in your code and it's not just looking at
the code that's been done today, it's the new changes dealing with Digital Rights Management, because authors are going to
want to get compensated as this new evolving world that everything moves to a digital form, they're going to want to be able
to ensure that we're doing the right thing. We need people to be able to trust their computers and trust their content.
Last, performance is a continual problem. Today we don't take advantage of the GPU, except in certain games, and just
basically because of memory leaks and the like it's very easy to have a system that is running for a long period of time to
degrade in performance.
Those are some of the challenges that we're trying to address in "Longhorn."
And how are we doing it? Well, I'm going to talk about each of those areas very quickly. In terms of deployment and
servicing, we have a technology that we call "Click Once," and Click Once is the ability to just do an xcopy -- the equivalent of
an xcopy -- to a machine, and you've installed it, very easy to get an app there, very easy to deinstall an app.
No reboots: I'm on a campaign to get rid of reboots, not only in our code but in any of the code -- (applause) -- any of your
code. So we have new servicing APIs that we're putting into the system to be able to tell applications you have a new set of
capabilities that you need to integrate in and at the appropriate time you should shut down and take up -- shut down that
part of your app and bring in the new piece.
This is also true of the operating system. We've made a lot of progress in Windows XP and Windows 2003, but we need to do
a lot more.
And I could go on and on. Migration, going from one machine to another, today it's a weekend of work if you're at home.
We'll have migration from machine to machine or migration that goes on the same machine, upgrades, it's the same code.
And we're not talking about hours; we're going to get it down to where it's in the minutes range. We're not going to
demonstrate that today but that's the progress, and I think it's actually in some of the bits that you'll be getting today.
Reliability: I talked about it. Built into "Longhorn" will be essentially a flight data recorder. It's going to be able to trace, on all
the time, and if your application has a problem, you'll be able to back up and see what happened, true for the operating
system as well.
Another area in here that I'm particularly excited about is driver verification. I really want us to take the next step and be
able to put an analysis on a driver to ensure that the driver, before you even go through an operational mode of stress
testing, you know that the thing is correct. I could go on about other improvements in that space.
Performance: We have improvements going on in the paging system, something called "Super Fetch." Now, what's Super
Fetch? Super Fetch is the idea that we can look at what's going on in a system and in a much smarter, semantic, heuristic
way, determine what you're going to need again in the future. And Super Fetch is dramatic in terms of its performance
improvements. We're adding a lot of code in "Longhorn" and we're going to be able to hold performance, once we work
through all the other problems that we've got to work through by the time we ship it, we're going to hopefully hold about the
performance we've got today by the fact that we'll have the capabilities such as Super Fetch.
Glitch free: We want to be able to manage a media stream while other things are going on in the system. If you want to do
some of the beautiful stuff you just saw, you need a glitch free environment, full GPU exploitation.
The last area in fundamentals I wanted to mention is about security. And frankly, Bill brought up just some of the things that
we're doing in SP2 in the near term. In "Longhorn," we're going much farther. We're going to basically soup to nuts [address
32
security] from the entire lifecycle of when you're writing applications: When the system boots, starting, running,
communicating securely, building and then staying secure. So we're spending a lot of time thinking about the fundamentals
and going back and seeing what we can do to improve them.
There are a couple I'll highlight here. You really need to be able to communicate effectively between nodes and between
people, and do it in a secure fashion. We've spent a lot of time in the Web services area and with protocol specifications such
as WS Security. We will continue to ensure that those capabilities are built into the system so you, as an application
developer, you don't have to think about and worry about whether or not your communication is secure.
Another area I wanted to highlight and Bill highlighted a little bit is the way we're trying to work with hardware in a deeper
way. The NGSCB, this wonderful acronym that we have, used to be called "Palladium," we're working with the hardware
vendors to be able to create a system so that we can boot and ensure that we're booting securely and that we can create
shadowed memory where code can execute but you can't debug it. You can if you actually needed to debug it, but in the
running case, the idea is that it's in a curtained memory, which means that it will be very, very hard to penetrate that.
Another case in hardware, we're adding no execute capability to pages in the system. And by that I mean today's 32-bit
processors, until recently, have not had any way in order to lock a page and say there's no execute here. And so with heap
data it could always be corrupted; we'll have a solution to that with the no execute flag as we work with the hardware
vendors.
There's a lot that we're doing in this space. There's a lot of talk at this conference. I encourage you to go to those sessions
and learn how you can write the most secure apps that you can.
So next part of the lap, presentation. Now, today there's basically two models. There's the Windows app and then there's the
Web app and both have great characteristics. If you want to have great interactivity, great performance, if you want to have
offline capabilities, if you want to integrate in with things like the Start menu, a Windows app is the perfect thing to do.
Of course, there are a few downsides to that. If you want to have a great Web app, there are great things that you can get
out of that. You get, for example, text free flowing very easily, you get easy deployment and, of course, you can't put a
Windows app in your browser favorites; in other words, it's designed in two separate worlds.
What do we think people want? We think they want one world. And it's been a long path for us to get here, but we're
incredibly excited that we think that we're on a path to solve these problems.
Now, you saw some of the demonstrations that Hillel did. Those are some of the screen shots from that. What we're doing in
"Avalon" is creating a unified presentation model for Windows apps, for Web apps and for media and animation type
applications. This is a big step forward. We're going to take the best of both worlds and create one programming model that
you can count on.
Another huge innovation in "Avalon" is a vector-based compositioning engine. Now today, there isn't a single system for
hardware drivers. There's a 2-D one and a 3-D one. In "Longhorn," there's just one, there's just one driver model that you
can get access to, whether it be the text, media, any of the capabilities that you might have had to switch before. You get
better performance, because you don't have to switch between the pipelines, between the 2-D and the 3-D.
And this compositing engine works not just as you saw earlier, not just between an app with the alpha blending that you saw
in the transparent Windows, not just an app in the operative system, but even between apps, because of this cross-process
compositing engine.
And it's vector-based. Any of you who have tried to play with a high density screen size in there, or becoming higher density,
you'll know that if you did a bitmap-oriented font or bitmap-oriented icons and the like, it basically just doesn't work. So this
is all vector-based, which, of course, is also faster.
Another area where we're making a huge step forward in "Avalon," from our perspective, is native input for a variety of new
input needs. You've seen Media Center -- very cool little guide with a remote control -- you can get native input into "Avalon"
from the remote control. How about ink? One standard API for getting ink in. And even speech, you'll be able to have one
interface into the system.
Now, as you look across here in this diagram, you can see that we're going to let "Avalon" come in through documents UI or
media, with a common form. And then, as you can see, it gets down to a direct 3-D graphic box that you can see there on
your right.
Now, the last innovation that we're doing, we think, is huge. It's moving to the declarative programming. Now, each time,
through the ages, as we've moved from assembly language to C to VB, we've made steps up in the capability of what you can
do. So the declarative of this is better in a variety of ways. And we are introducing a code name, "XAML," as part of our work
in "Longhorn," and it's a new markup language that lets you have the ability to build a Windows app in a declarative way.
And, of course, we all know that the declarative things are typically easier to read, learn and write.
We also have the ability with this declarative language to separate the coding from the content. And to have some of the rich
experiences that we all are used to now on the Web, you really have to have incredible designers in addition to incredible
programmers. Today, it's sort of all mixed up together. And what XAML does is give us an ability to separate what's called
"code behind" from the designers. And so, you can have collaboration between those designers and the developers.
And, as I mentioned, it's very easy for tools to generate as well as consume declarative text. So on the screen, it shows you
what a button would be in XAML. Now, the cool thing is that you can use any C OS language as well to generate that same
button. So these three snippets of code generate the same type of button, a huge step forward.
So with that, I want to get down a little bit more, the next level down in the system, and have Don Box and Chris Anderson,
Windows architects, come out and do a little programming in "Avalon"."
Chris, Don?
CHRIS ANDERSON: Thanks, Jim. Hillel got to show you a great preview of what "Longhorn's" going to be like to use it, what
it's going to be like for IT professionals and consumers. Well, Don and I, we get to show you what it's going to be like to
develop it, what the code's going to look like.
So, of course, everything starts in a console, right? (Applause.) All right, Don. Let's start a C# file. We're going to start coding
our application in C#. (Laughter, applause.) Don -- Don, you use EMACs?
33
DON BOX: Yes. All right. Remember, Chris, the premise here is we're walking up to a vanilla "Longhorn" box, we're looking
at what's on everybody's box. I go to my mom's house, I want to hack.
CHRIS ANDERSON: OK, so we're at your mom's house.
DON BOX: And naturally, my mom, the only app she will have installed is EMAC. (Laughter.)
CHRIS ANDERSON: So this is all I have to rely on.
DON BOX: Wow. I don't want to be on your Christmas list.
CHRIS ANDERSON: OK, so we start with some using statements. All the APIs, all the functionality you've seen in "Longhorn"
today are exposed through a simple set of managed APIs. We're going to import the system namespace, the MS "Avalon"
Windows, and Windowsdotcontrols namespace. We're going to create a namespace. I'm sure you guys are all pretty familiar;
we're going to keep going here.
Create a class -- we're going to derive this class from Windows. Windows is the base type for all the top-level frames in
"Avalon"."
There's already people critiquing your coding, Don. It's sad.
DON BOX: There's already what?
CHRIS ANDERSON: People critiquing you. So we're going to create a main -- (audience member, off mike)
DON BOX: Ah, ah, I hear them. Hold on.
CHRIS ANDERSON: Thank you. We have a solution. We have solved this technical problem. Good? (Applause.)
CHRIS ANDERSON: Hold on -- I have one better.
DON BOX: Watch this. Font, lock, mode -CHRIS ANDERSON: Get rid of that nasty color-coding.
DON BOX: Excellent.
CHRIS ANDERSON: The contrast is really a local thing for me. People in the back, they don't want to see all that fancy color
stuff, because they want to see true systems programming.
OK, we have a main. Inside of our main we're going to create a new application. OK, new, My Window. We're going to create
this. Now, this is actually instantiated in a class. The key thing to remember here is in "Longhorn," this isn't creating some
wrapper that's underneath the covers calling create Window. This is actually instantiating the real code that is going to
execute this app.
We're going to set some properties -- text, invisible. Like our forefathers, we are making the default visibility of all Windows
to be invisible. We're going to run -- and Don, I think I need to make you flash back to history. You remember COM -DON BOX: Yes.
CHRIS ANDERSON: OK, if you remember COM, I'd like you to put SPH right on the main, proving developer continuity on
the platform. Yes, that's why we did it: developer continuity.
DON BOX: Great.
CHRIS ANDERSON: All right, so let's go to console. We're going to compile this now. We're going to invoke the C# compiler.
Now remember, Don said this is only the software on his mom's machine. The C# compiler is now included in the default
Windows client installation.
(applause)
CHRIS ANDERSON: Going to include a bunch of new DLLs, make it a Windows executable, and compile.
DON BOX: Just a warning: don't be alarmed; it's fine. My mom's got these crazy environment variables on her box. I never
know what she's doing.
CHRIS ANDERSON: You've got to talk to her.
DON BOX: Yeah.
CHRIS ANDERSON: OK, let's run the app.
DON BOX: This is it -- drum roll.
CHRIS ANDERSON: OK, it's the first "Longhorn" application compiled at the PDC. You'll notice it is not gray. It is now white.
That is our improvement. Hold on -- hold on.
DON BOX: Oh, my goodness. Look at all the stuff you can do with this app. This is that "Avalon" thing you guys have been
spending like three years on, right?
CHRIS ANDERSON: Yeah, it's that "Avalon" -- yeah, thanks Don, thanks.
DON BOX: All right.
CHRIS ANDERSON: Just wait. All right, so that command line's not going to satisfy us for the rest of this conference, and we
really need to make an improvement here. In "Longhorn," we're introducing a new build system, a unified build system that
unifies Visual Studio, the platform, and the SDK with a single build format. It's included in the box. It will ship in every
"Longhorn" machine.
So, Don --
34
DON BOX: So my mom does not have to suffer the tedium of running this command line.
CHRIS ANDERSON: Correct, yeah. It's another consumer -- a home feature. So let's create a project file. MS Build projects
are, of course, XML-based. We're going to start with a project tag that consists of three main types of tags: properties, tasks
and items. We're going to set some properties. Specifically, we want to have, you know, C# as our language, because we're
not going to go change the code right now.
We're going to say the target name, give it, you know, whatever random names Don feels like today. Vanilla, this is great.
We'll do chocolate later, but we weren't quite ready for that. In our items, we're going to include all the C# projects -- all the
C# files, rather. Excellent. Flight in -- very tough, very tough.
Import -- so now, we need to get all the tasks. We have properties and items to find, and we're going to get all of our tasks
from the Windows application dot target file, which is kind of the default for everyone. I think we're good. It looks great. Let's
try for the console.
Oh, we don't need that anymore. Instead, I type "MS Build" -DON BOX: Yes.
CHRIS ANDERSON: And what we've done is we've produced a lot more console output. We're trying to increase the amount
of console output in this build. So, Don, let's run the next app. Well, actually, I could run it -- there's insects here. There's a
bug in our demo already. Look at that.
DON BOX: Oh!
CHRIS ANDERSON: You know, as a hardcore EMACs user, there's something I've always wanted, which is that thing that
you Visual Studio guys have -- what is it -- where you hit the F5 key.
DON BOX: I love F5.
CHRIS ANDERSON: I think I can get that. I think this is an enabling technology here. If I set this to Build, Run -DON BOX: That's not going to work.
CHRIS ANDERSON: That won't work?
DON BOX: Try it. Let's see.
CHRIS ANDERSON: I think it will work.
DON BOX: We're trying -- you know, F5 and EMACs wasn't the top priority here, so -CHRIS ANDERSON: This is the second "Longhorn" app of the conference. (Applause.) And oddly, it still looks like a boring
white window.
DON BOX: Yes. But wait until we add some more angle brackets. (Laughter.)
CHRIS ANDERSON: OK, so -- all right. Jim talked about that great new declarative programming language, that higher level
of distraction over, you know, the vanilla C# -- or, well, really Vanilla C# now. So what we'd like to do, I want to take that C#
file and convert it into XAML. So, Don, maestro, if you would please: a new XAML file.
So in XAML, the syntax is relatively straightforward. The root tag is the class you want to derive from. We're going to include
the XML namespace, which, by the end of this conference, you will all have memorized. It is
schemas.Microsoft.com2003XAML. We will repeat over and over again.
We're going to include the definition namespace. This let's us do directives to the language compiler. So we're going to use
that same class name in the same namespace as the code behind file -- excellent. So what we're really doing is we have two
source files now that are going to generate -- we're defining the type, we're splitting the definition across two files.
DON BOX: Yes.
CHRIS ANDERSON: So that means down here, I have to go and say "correct."
DON BOX: This is a new "Whidbey" feature, actually.
CHRIS ANDERSON: Yes.
DON BOX: Where you're able to have, in C# have multiple source files contribute to the same class. In this case, we're using
a markup file as one of our sources.
So let's move those property sets out of, you know, that rather old school C# and into the new revolution that is XAML.
CHRIS ANDERSON: Let's move this code into the 21st century.
DON BOX: Wow.
CHRIS ANDERSON: You can't use semicolons in the 21st century?
DON BOX: No, we don't need them anymore. We have angle brackets.
CHRIS ANDERSON: Wow. (Laughter.) Great, all right. So the last thing we need to do, we need to tell the project system
that we want to compile that. So let's go and open the project file, and we're going to say that we want to include, as pages,
all the XAML files -- that's XAML, Don.
DON BOX: Yeah.
CHRIS ANDERSON: Yeah.
DON BOX: OK, so -- Web build? Did you change the -- is anyone going to know?
CHRIS ANDERSON: No, no, no -- no one will know that it's XAML. Hold on -- don't look away, look away.
35
DON BOX: That was not the third act. Wait for it. Go to the XAML file. Yes -- oh, this is going to be much better. This will be
exciting. And we build and run. Hello, world, from XAML. (Laughter, applause.)
What happens is as we ran the build system it took the XAML and it converted it into code and resources and it took the C#
file and put those together as we compiled.
Now, alas, that is still but a mere reflection of what we want. Will I ever come back to the source code or now am I like just
XML-boy?
CHRIS ANDERSON: Don, you've always been XML-boy.
DON BOX: Yes. (Scattered cheer.) We have one other XML-boy in the audience. Excellent, excellent. (Laughter.)
CHRIS ANDERSON: A true believer if ever there was one.
DON BOX: Let's add some content. So create a closed window tag and inside of here we want to include a text box and some
buttons.
CHRIS ANDERSON: While I drink.
CHRIS ANDERSON: We're going to set the width and height. You remember Jim talked about those high dpi monitors? In
Windows, we're going to natively support physical measurements, inches, points, pixels.
Don, your code is so clean.
We run Office, it's beautiful. Don, you are a guru, and everyone can see our patented "jello" button effect as he clicks. Yes,
you get that for free. But, Don, your app is sitting there, you're poking the app and it's not giving anything back. You're
getting nothing back. It's not an interaction, it's not a dialogue between the software and the human.
So, we want to add an event handler. So if you use ASP.NET, this should come as no surprise. We should also declare the
event handlers in the markup. So, we're going to add an ID to the text box, and we can programmatically access it, and we're
going to have a quick handler. Your names are poetic. I'm a code poet. Excellent, fabulous.
So, we create our event handler object, and take the click event art, and we decided here we're just going to be a little
mundane, we'll get to the exciting stuff in a moment. We're going to show a message box. The message box shows, and
we're going to access Bob, Bob, text. The text box was a variable called Bob, and it has a property called text.
Shall we, let's do it. So, we build, we run, we see a window. Type the text, we have interactivity, it's a message box, it will
get better, don't worry.
We have our code and markup separated. We're able to out of the box. The developer experience on the platform has a
simple to program declarative markup. We have this new build system. But the next thing we want to get into is the app
looks pitiful. Hillel is actually in the back crying, I can see him from here.
So, let's go in and add a little more polish to this. We're going to put a text box. Jim talked about this unification of UI,
documents, and media, and here you can see that we can put rich text right in the middle of our UI flow. In addition, all of
"Avalon" supports a composeable layout model, so we're creating a text panel, and that's going to be laid out inside of the
window. I'm able to embed really interesting text. See, we should have rehearsed more of the text Don was going to type.
We're going to put that in, we're going to build, we're going to run. We see text. No we don't … actually, I can barely see the
text. They don't see the text. Well, I can see it down here. Let's make this a little bigger, let's make it so everyone can see it.
"Longhorn" and "Avalon" has this great vector-based drawing system, and maybe when Jim was saying that you kind of said,
'So what, you know, vectors are all new fangled, they're for games, or whatever. I like my bitmaps.' But, alas, bit maps don't
scale very well. So, in "Longhorn" we're moving to this composeable vector-based graphics system, and so we're just going to
scale this up, right there. And that's going to just zoom the whole UI. Let's bring it up.
We've failed. Gone. We've failed for the first time in front of this audience.
DON BOX: Our code has failed, how about that. Would that be better?
CHRIS ANDERSON: That would be much better. I think the compiler will also like that much better. But what we saw was
compile time error checking. That was a feature demonstration.
DON BOX: Did you see that build thing where they did the Behind the Technology?
CHRIS ANDERSON: Yes.
DON BOX: You know the characteristic parts of those videos, I think we can actually capture that in "Avalon," you have
behind the technology. So, if I do this, I think that will get us to look more or less like those interview shots, like with Puff
Daddy, P. Diddy, Sean Coombs.
CHRIS ANDERSON: Excellent, much better.
DON BOX: Does the text box still work?
CHRIS ANDERSON: Of course it does.
DON BOX: Don't try this at home.
CHRIS ANDERSON: So, we've seen text, we've seen graphics, we've seen the rotation and the scale. But the last thing we
talked about was media, the ability to integrate media into your application.
DON BOX: There's no blinking lights yet. Which is a cool Altair inside thing with the blinking lights.
CHRIS ANDERSON: Bingo. OK, but we want to do a little more modern version of the Altair. So what we want to do is, let's
add a video into our application. So, in Hillel's demo, you saw how he was able to zoom into that video and it was really easy
from a user standpoint. But how hard is that from a developer standpoint? If you tried this before, of course, you know that
you need DirectX, and you probably need Windows Media Player, and implement maybe two or three hundred interfaces to
try to host it. But here, we've gotten all that down to one single tag with a lot of attributes on it.
36
So, we set the width, we set the height, tell it to stretch, and we repeat for a really long time, and we set the source.
The last thing we're going to do, we're going to layer the video behind the text. We want to show a really great integration
where they're seamless. So, we're going to have this canvas, and now we should be able to build and run. And let's see, what
does the future hold?
Clouds.
(Applause.)
DON BOX: Now that I have these new-found graphical skills, I right now feel like I should critique this the way many of us
critique other artwork produced by Microsoft, I think it's a little harsh, a little Fisher Price, if you will, too much primary color,
not enough subtlety. We need more pastels.
CHRIS ANDERSON: OK, let's go for pastels.
DON BOX: The future is not harsh and Lego-like, it's more pastels and friendly.
CHRIS ANDERSON: So, in here what we're going to do is, we're going to set the opacity on the video, every element
supports opacity. The entire "Avalon" composition system is built from the ground up with the ability to apply a transform, an
opacity transform, effectively, to everything. In addition, every color reference, you remember the RGB, but it was always
short of a quad, you always added that fourth bit. We found a use for that bit. And we've packed in alpha into that. So, every
place you use a color, you can specify an opacity.
DON BOX: Which is the left most thing.
CHRIS ANDERSON: The left most. Let's go. Video, notice it's playing behind the text box. And it's stretching, and we can
type, and the button actually works, all of this running at the video refresh frame rate doing real-time alpha composition. In
the bits, this is running, by the way, in the directly on the video card. We've moved all of that processing directly onto the
GPU, so it's consuming very few cycles.
(Applause.)
So, and this is also running on just the vanilla PDC bits. Eventually, at some point, who knows when, in the future, you'll
actually be able to reproduce this exercise themselves.
What we've seen is a great vector-based compiling engine with composition, media, UI and documents all running together
that even Don can write a great looking application on, even you.
With that, I think we should turn it back to Jim.
DON BOX: We've gone way too long without a senior executive on the stage.
CHRIS ANDERSON: We need a senior executive. IS there a senior executive in the house? Excellent.
(Applause.)
JIM ALLCHIN: As I said earlier, no tradeoffs. You can see even though these aren't some of our best graphic designers here,
that you really don't have to have tradeoffs like you've had in the past. I want to move into storage, the next piece of our
wraparound "Longhorn."
Today, data is generally trapped inside the application. What's happened is the managed aspects of the data are often put,
not only because there has to be a separate storage, but they are wired into the procedure code that's inside the application.
What does this mean? Well, in some cases, it's not a big deal because you really don't need to export it. If you really want to
export it and let other people take advantage of it, the fact is the schema isn't visible, meaning that other applications can't
go and add interesting value to it. We also find that developers have to tool their own store all the time, because the file
system today does stream. It does stream really well. But you might want to have very small items that you manipulate. So
we find application developers creating their own stores to try to manage their particular data.
We also find that relationships can often be buried, and if I say something like let's do a meeting, you know immediately that
there's going to be an agenda, maybe not at Microsoft, but in most companies. But there's going to be and agenda, and you
want to know when is the time of the meeting is going to be, and who it is going to be with, so you know all that. And so you
want the systems to understand those links and be able to present them. So, if I say 'Bill Gates,' or 'William Gates,' you know
that I'm talking about the same person. Systems could have better semantic knowledge to make those links very visible.
And the last area that we think is a huge challenge, and you've already seen demonstrated how we're addressing it, is that if
you want to have separate views today in the system, you have to create your own folders. If you have photos sorted by
date, 2001, 2002, 2003, and you can work on it that way and it's great. But now let's suppose that you want to look at your
photos based on perhaps a vacation that you went on, you have to go in and physically reorganize. There's no logical versus
physical separation.
On this screen, it shows little people, little funny people, representing that today contacts are sort of buried in a whole bunch
of different places. When you put an author on a document, is that the same name space of contacts as in the Instant
Messaging system? Is that the same one that's in e-mail? So we think that's a problem, because we think that if you have
APIs that expose that and let you manipulate it, you could do a lot of cool things.
So, what we're trying to do in "WinFS" is do a couple of things. First, schematize the data, and provide a great store that you
could use if you decide to. They're really two separate concepts. We think that moving ahead in schema is going to be a great
step whether that data is, in our case, in Active Directory or someplace else. And we also think that store will let you do very
exciting applications. So we have an extensible XML schema. We have a set built into the system, things like people, user,
infrastructure, and you can add extensibility into those XML schemas for those particular ones.
For example, if you have a specific attribute that you want to add on to a user, then you could do that. You can also, you
notice on the far right, that you can add your own huge new data type. So, your applications can install the schema, and then
your applications take advantage of it.
We have logical views, which gives you this separation between the physical and the logical views, so you can look at the data
in lots of interesting ways. Programmatic relationship: again, you've already seen the things that we're doing in Hillel's demo,
37
and the app where it let us look at the different data, the linkages between them, and you can program those so that you can
surface them through a variety and number of applications.
Synchronization is today extremely difficult, whether it's PC to PC or PC to a Web Service, or PC to a device, and so we spent
a great deal of time. If you store your data in "WinFS," we'll be able to move it around in a consistent way between the
devices without you having to do a significant amount of work.
Lastly, when data changes today, you can get things like an "on change notify," you know something changed, but then you
have to go grapple to figure out what in the world happened. There's something called Information Agent that will let you run
specific pieces of code when things happen. If I get an e-mail from somebody that's really important, I could have an
Information Agent rule that looks at that and says, ah, it's from such-and-such a person, I want to go ahead and send me an
IM that goes to my phone.
In terms of the general architecture, some of the things I want to highlight on this chart, and hopefully you can see this one,
is that there's lots of different programming interfaces that you can come into "WinFS" with. You can come into it through
objects, you can come into it through a SQL. You can come into it through an XML interface. There's a whole set of services
being provided by the system, such as synchronization, I've already mentioned, an information agent, built in schemas, and
then beneath it there's a data model that lets us build up these great schemas above it, things like items, relationships, and
extensions. This is built on a transactive NTFS system, so the streams that you have in "WinFS" are actually stored in NTFS.
Of course, "WinFS" itself is stored as a stream in NTFS. So there's a very good synergy between these.
So with that I want to ask Chris and Don to continue on, and take us around the lap with "WinFS."
CHRIS ANDERSON: Actually, Jim, I have this is my first PDC since joining the firm. And I sat up there all these years, and
this is like my seventh of eighth PDC in my life, and I've always wondered why doesn't the executive write some code. And I
think it would be nothing would please me more, I'd be honored if you wouldn't mind being my code monkey for this leg of
the lap.
JIM ALLCHIN: It depends, do you have like a good editor in here?
CHRIS ANDERSON: Well, as you know, we have EMACs, if you were watching back stage, we have god's editor, I think.
JIM ALLCHIN: How about VI?
CHRIS ANDERSON: Let's see what we have. Why don't you bring up the editor of your choice. Windows is a big tent, we
love everybody here, so you use what you want to use. We're going to edit vanilla.tf, which was the source file we were just
working on. Now, you'll notice that, unlike EMACs, VI doesn't retain the font setting. And they want at least that, that's good.
So you just told us about "WinFS", I'd like to see some "WinFS" coding. The first thing we're going to need to do is, why don't
we talk about how people work. Right, we saw there's this unification of people in the store, why don't we bring up a contact
ticket dialogue and see what that looks like. So replace my message box, which it looks like you've already done, and make
yourself a contact ticker dialogue. So a contact ticker dialogue, give it a variable name, whatever you feel like, equals new
contact ticker dialogue. Great. And we're going to need to set up properties so that the dialogue knows that we're looking for
contacts explicitly. So why don't we go ahead and say dialogue that was a request property, request properties property
request.
JIM ALLCHIN: I think it's property request.
CHRIS ANDERSON: Excellent, we agree, you lose.
JIM ALLCHIN: I could be wrong. I just work here.
CHRIS ANDERSON: Type what you will, we'll work it out.
JIM ALLCHIN: The compiler will probably help with that.
CHRIS ANDERSON: And we need to set the property type. Just because, the contact ticker has all that great functionality,
you can select multiple items, you can say addresses, or e-mail names, or properties, anything.
DON BOX: Chris, you're sugar coating it, it's a very verbose API that we have to code around.
CHRIS ANDERSON: Contact properties dot contact, that I am certain in the fullness of time this line of code will become
unnecessary. For now, this is a real bit, so we have to
DON BOX: We know, it's a couple of words.
CHRIS ANDERSON: Unlike "Avalon," where everything is perfect.
JIM ALLCHIN: Guys, move on.
DON BOX: So, Jim would you go ahead and show the dialogue, to do a show dialogue, which will do a modal dialogue on this
sucker, pass your object reference there, compare to dialogue result dot OK. If and only if this works, what we want to do is
grab the selected contacts, which is a property on the dialogue
JIM ALLCHIN: Is that the thing you call BOB?
DON BOX: Yes, the edit control is BOB, of course. We've been trying to teach Don Hungarian, but he just refuses to learn.
CHRIS ANDERSON: Yes, I thought now that Charles isn't with the company anymore we could pick our own variable names.
DON BOX: So, selected contacts zero, dot contact, dot display name, dot value, dot string, dot text. I'm sorry. I got a little
carried away. That's looking pretty good, do we have enough close curlies there?
JIM ALLCHIN: One more.
DON BOX: I think you've got the exact right numbers. Now, hold on Jim, let me channel a much younger Don before I
became enlightened, will you hit escape, colon, W. Is that it?
JIM ALLCHIN: Yes.
38
DON BOX: Sweet.
JIM ALLCHIN: These young people.
DON BOX: Can we go back to the shell? Now, I don't know if you noticed, what I did when I wrote the original make for the
project file, I went ahead and put the build run in the target. So we now have F5 for both EMACs and VI. So if you want to
just write MS build, and go ahead and click the button.
DON BOX: Fantastic. So why don't we go ahead and find in contacts. These are real bits, remember that. I picked Mr.
Anderson. Great, fantastic. OK, VI boy, let's see what else you can do with this thing. Let's see how this VI works with XML, a
more modern syntax. So why don't you crank open the vanilla. So what we're going to do is add some more user interface
goop at the bottom of this form. So after that go ahead and put in a line break, so that we get a visual
CHRIS ANDERSON: Because we want to make it look better.
DON BOX: We want to make it look better. Let's see, let's get a button and a list box. So, a button, we're going to have an
event handler, which is going to be the button event handler is click equals whatever, search.
CHRIS ANDERSON: Good name.
JIM ALLCHIN: Like that?
CHRIS ANDERSON: Yes, I like that.
DON BOX: And close angle bracket.
CHRIS ANDERSON: Yours are actually a little better than Don's, they actually have good variable names, you code a little
better. You've been doing this longer.
DON BOX: He's more experienced, he's more seasoned, as we say.
JIM ALLCHIN: We call it old.
DON BOX: And let's go ahead and drop a list box in here, and we're going to give it a programmatic variable, so capital ID
equals the variable name of your choice. You're not going to say LB list, in honor of Charles. And you're going to need to
make that a string with quotes. Result list, and you're going to get all visual fancy with this VI thing, fine, you go girlfriend,
whatever you want. That's amazing. And why don't we put in a dummy item in there, so that it comes up looking fairly
reasonable, because as it turns out if we don't, it's the size of the content, and we get a very tiny list box. Close that sucker
out. Looking beautiful, close off the list box. What do you think of this XML stuff?
JIM ALLCHIN: I don't think it's going to blow over.
DON BOX: You don't think it's going to blow over?
JIM ALLCHIN: I think it's here to stay.
DON BOX: You think it's here to stay. I'll quote you on that one.
CHRIS ANDERSON: That makes Don happy, we can keep him employed now.
DON BOX: That was actually one of my review goals.
CHRIS ANDERSON: That XAML looks as good as XAML can possibly look. Why don't we go ahead and go back to our source
file, and
DON BOX: Just give me a second. Did you overwrite our vanilla?
CHRIS ANDERSON: No, I think it's just ul, again, the French spelling. So as I recall, in the button you declared an event
handler called search, so would you mind writing a new event handler next to
DON BOX: I think we should get that "WinFS" namespace in there, right?
JIM ALLCHIN: I think so, too.
DON BOX: So let me put something about storage, because that's not core enough for us.
CHRIS ANDERSON: That is truly the core of the core.
DON BOX: Uber core.
CHRIS ANDERSON: We were going to have core.ex, but we decided we'll wait until next version.
DON BOX: It didn't make the LAPI design timeline.
CHRIS ANDERSON: So go ahead and write us an event handler search object, sender, click event
DON BOX: Jim knows the guidelines, it's sender, E.
JIM ALLCHIN: Yes.
CHRIS ANDERSON: OK. Great. And what we're going to do is issue a query. So there are some documents on this machine
I'd like to see what we've got available. So to make a query in "WinFS," the most important thing we need is this thing called
an item context, which is really a query scope. Because the query might take a few moments, just a few, let's clear out the
list box so the users knows what's going on. And now we're going to declare an item context, C, and we're going to get it by
saying item context dot open. So this is kind of the master control object from which we're going to issue all our queries. So
now that we've got this, we're going to issue our careers are looking shorter and shorter. So when we issue the query,
because we're in CLR land, where things are very productive and developer friendly, the query is going to return a collection.
So we'll do a for-each, and we're going to get back documents. This is a strongly typed object, right?
CHRIS ANDERSON: Yes, it is.
39
DON BOX: So we've schematized all that common data stuff, all the everyday information. So we'll do a C dot find all, type of
document, that's exactly the number of
CHRIS ANDERSON: One more, I think one more will do it.
DON BOX: I like that number. So let's get a block of code after. So for each one of these guys what we're going to do is
create a new list box item, so we say result list dot item, dot add. There we go. And the title of the document will come from
D, and there's a property called title, and we're cooking with gas there, you can close off another curly brace, and that VI is
just an amazing tool. So why don't we go back to the shell and do a built. So there's our new button and our list box.
JIM ALLCHIN: Should I push it?
DON BOX: Again, it's thinking.
JIM ALLCHIN: What do you think?
DON BOX: Now, Jim I noticed that we got everything. In fact, we got so much everything we got two of everything, it was so
happy to cough up these items. Is there anyway we can pare this down without going through like four loops, trimming these
things out? I remember from SQL it was always better if you get the engine to do
JIM ALLCHIN: Yes, in fact, this is about as inefficient as you can do it, because we're dragging everything we can, and then
we could do a compare if we wanted to. Maybe we should just let the engine do the search.
DON BOX: I would love to see us do that. I think we should let the engine do the search.
CHRIS ANDERSON: So let's go to our find all, find all is overloaded, the first version that we used simply takes a type
predicate, which says, 'Find all things in this store that are affiliated with this type, and the type we used was documents.'
What we're going to do now is put in a predicate, which allows us to actually reason about, and express constraints against
the schema of what is stored in the store. So the second parameter to find all is going to be a query string, and author's dot
display name equals Mr. Anderson, looks good. And if you can put a comma right after type of document.
JIM ALLCHIN: Of course.
DON BOX: The dreaded line wrap.
CHRIS ANDERSON: That insert
JIM ALLCHIN: I did, I did.
CHRIS ANDERSON: So that's looking as good as it can possibly look. Why don't we go back, save it out, go to the shell, dare
we? Hit the search button, and I'll bet we get a few less files this time.
JIM ALLCHIN: How about that? Great. (Applause.)
CHRIS ANDERSON: Jim, before we move onto the next part, I don't know if you watched that video with the Halo stuff, with
the red and blue and all that, one of the challenges of PDC is to get a vice president, even better a Group Vice President, such
as yourself, to say developer 37 times. Would you please say developer 37 times? (Laughter.)
JIM ALLCHIN: Developer 37 times. (Laughter, applause.)
CHRIS ANDERSON: Thank you.
JIM ALLCHIN: Oh, gosh, what can I say.
OK, well on to the next part of the lap around, which is about communication. And I think we've made a bit step ahead in
Web services. We've spent a lot of time working with the industry to come up with the protocols, but if you really want to
have a Web service today, you're going to have to do a lot of work. It's a lot more just coding up some simple SOAP
messages. You need security, you need to handle things like transactioning, guarantee that you can handle the resiliency and
the recovery. You need to be able to handle the trust issues of security to cross boundaries between companies.
You have a decision to make: Are you going to do objects? And there's some advantages there or there's some
disadvantages. Are you going to do services? And there's some advantages and disadvantages there. How are you going to
deal with the fact that you might want to do this little peer thing that you saw here but you also might want to do this crosscompany or cross just your enterprise? So there's a lot of code you have to do if you want it to take place today.
So what we're doing in "Indigo" is creating a subsystem that you can access that does everything for you. It starts by
addressing the basics, so that you can do transacted messages in a reliable way, that you've got security built in it, you've
got heterogeneous interoperability also built in it; the messaging capabilities, so that you can do just very, very simple th ings
like send a message, or you can get down really low level and dirty and be able to play with exactly how the sequencing is to
work.
Now, there are programming models that extend the existing models that you are used to, whether it be what's available in
COM+ or the like, so it naturally fits into all of those environments. And the bottom line is that this simplifies the building of
services in a fairly dramatic way.
And if you can see -- this picture of course is not quite as big from the architecture -- but from the top, we start off and we
have facilities for you to create services so you don't have to do much thinking. You can either do a lot in declarative
statements to let you build these services. If you go to the next level down in the architecture, there are connectors and
channels for you to import for you to be able to fine-tune the way you want the system to operate.
Finally, beneath that you have a variety of hosting environments that you can have these applications run in. You could have
them run in a Web context, you could have them run as an NT service, you could have them run in DLL host in the COM+
world, so there's a lot of different ways that you can have your application and still be able to service the messages, and not
handle all the issues that you typically would have to about scheduling threads and synchronization characteristics.
So that's what "Indigo" is about. And, with that, I think I want to cover one more thing before I have these guys come back
up here.
40
We talk about "Indigo" for communications. There's also a collaboration piece that we put underneath the "Indigo" name. And
today in the collaboration space, there are way too many contacts for you to deal with them if you want to have an RTC
communication. It's just tremendously confusing. There's no single API for really doing the peer-to-peer or enterprise level
environment that you want when you set up an app to do to real time. And today you can't get any of our UI to really
integrate in with your application. Let's suppose you want to do a video call inside your application. There aren't any controls
that we're making available for you. So that's a big problem.
And then the problem of apps and firewalls, both enterprise and then with the home, block so much of communication that
you are really stuck with some hard problems if you want to have a guaranteed, end-to-end real-time communications
environment.
So what we are trying to do in this space is create a single namespace and environment for contacts so that you can find the
contact and you can get the presence -- presence meaning is the person there right now? And in "Longhorn," as you'll see in
the bit, that there is a single concept of contacts that everyone is using, whether real-time or things like e-mail. We are
adding controls so that you can get the capabilities for doing collaboration up into your app without you doing all the code,
single platform, peer-to-peer and enterprise. And it's easy to traverse namespaces, even the peer-to-peer ones that are being
dynamic. And if you move from a peer-to-peer into the enterprise, then that still works with the same APIs that would have
worked on a simple code.
And now -- now back to you, John and Chris. (Applause.)
DON BOX: Thank you, Jim. (Applause.) So I've decided this time maybe I'd have someone a little less seasoned, who I could
push around a little bit more. So Chris, would you mind coding?
CHRIS ANDERSON: I'd love to.
DON BOX: And I don't even want to think about what text editor you're going to use. So what we are going to do now is take
our program, which is a fairly lonely program -- it's a program that just sits all by itself -- and what we are going to do is
allow it to reach out to other programs that are running out in the world.
So what I want to do is let's go ahead and do some blog work, right? So you know the PDC bloggers, .NET, everybody is into
Web logs now. I know your simplegeek.com is becoming a cottage industry, generating three or four times your salary.
CHRIS ANDERSON: Click through.
DON BOX: Click through.
CHRIS ANDERSON: Google click through.
DON BOX: So why don't we go ahead and add some blogging capabilities using "Indigo" with this little program.
So what we are going to do is, would you mind opening the XAML file, because we're going to have to set up a little bit of
user interface? So what I'd like you to do is after -- or before actually -- I don't care where you put it -- I'm going to need
three edit controls, so three text boxes and a button. So that looks like as good a place as any. So I'd like a text box -- ID
equals -- we're going to put the title of our blog entry here.
CHRIS ANDERSON: Title you said? Is that close enough to Hungarian?
DON BOX: Yeah, good point. And do you want to make the width 100 percent?
CHRIS ANDERSON: Yes, Don, you've been listening when I've been talking, haven't you.
DON BOX: Did you just say something? What's interesting is that was actually spontaneous when I did that -- shocking. Yet
it got no laughs.
CHRIS ANDERSON: Don't try, don't try. So go ahead and mark up these variables. So we've got three variables. And you
might want to put a little label there so that other users who come along -DON BOX: Usability.
CHRIS ANDERSON: Programs that other people use are often more useful than programs that only you use.
DON BOX: Put a line break at the end. Oh, my goodness, where's your black beret in Macintosh? Great work on -CHRIS ANDERSON: And we need a button. We need a button.
DON BOX: A button?
CHRIS ANDERSON: That will actually invoke the blogging code that we are going to write in "Indigo." So we have a button,
invokes the blogging code. Fine, close off that tag. And go ahead and put a click handler in there. Blog it, then copy.
So we've done all the XAML work, and now what we need to do is go over to our program and write some "Indigo" code.
So the first thing we are going to do is get the event handler in place. And the event handler looks astonishingly similar to
every other event handler. If anyone in the audience would like to help out, you can -DON BOX: Great, we're auditioning later.
CHRIS ANDERSON: And what we are going to do is bring in system.message box, which is the namespace for "Indigo," and
we are going to take the three edit controls, bundle them into a data structure and send them over through a SOAP message
to my blog.
DON BOX: A data structure?
CHRIS ANDERSON: We call those classes. Is that what you're -DON BOX: Fine. So public class item, and I need three public fields of type string, title -CHRIS ANDERSON: Wait, wait, title? I'm guessing, description?
41
DON BOX: You are so good.
CHRIS ANDERSON: Yes, content, fantastic. So we've got a data structure, also known as a class, that we are going to work
with. We quickly marshal that off of the form into the -DON BOX: Now, I really should be using data binding. There are some people backstage who are going to yell at me because
I'm not.
CHRIS ANDERSON: That's okay.
DON BOX: There's great data binding -- I'm just letting you guys know.
CHRIS ANDERSON: Yeah, yeah, plug away.
DON BOX: My monitor has gone blank. That's not very fun. I.description equals the title. -CHRIS ANDERSON: Actually it would be the description.
DON BOX: The description.text. Thank you, Chris.
CHRIS ANDERSON: It's harder to read when I have to look down at that -DON BOX: Great. So while Chris fills this up, this thing we're going to do next, which is actually the important "Indigo" piece
-- this was actually just a bunch of bootstrapping code so we could get our app to work. What we are going to do now is
declare a port. A port is the central focal point in the API for "Indigo." A port is also a great kind of wine.
CHRIS ANDERSON: Yes, it is.
DON BOX: And the port is the way messages come into and leave a given app domain. And so I've got my port set up. What
I'm going to do now is create a channel. Actually, I'm going to do a port.open -- so P.open.
CHRIS ANDERSON: I think we should also close it at some point.
DON BOX: Yes, let's close it.
CHRIS ANDERSON: Practicing good coding practices.
DON BOX: Good for you.
CHRIS ANDERSON: You taught me well.
DON BOX: Yes, thanks. Yes. So what we are going to do now is create a channel. So "Indigo" is all about ports, which are
these places in network place, and channels, which are these little IO devices we use to get messages into and out of a port.
So we are going to need a send channel, and we're going to call "p.createsendchannel." And open-paren, new-URI -colon,
HTTP colon, whack-whack, www.gotdotnet, whack team, whack ebox, whack Indiepost.asp. Cool. Close, close, close, semicolon. And now we've got a channel. So we are ready. We are poised to get the message out to the server.
CHRIS ANDERSON: I'm poised.
DON BOX: Yes, you are poised. What we are going to do now is create a new message -- so we are going to create a
message object, M equals new message. We are going to give it an action URI -- and get ready for this -- UUID, colon, 0002,
0812-0000-0000-C000-000000000046.
CHRIS ANDERSON: So you made that up off the top of your head?
DON BOX: No, my friends on the Excel team really wanted to see their name in lights. (Laughter.) So, go ahead and pass "I"
as the body of the message. So we are basically creating an in-memory SOAP envelope.
CHRIS ANDERSON: Did you pass "I" as the second parameter? Oh, that was just too fast for me.
DON BOX: So we've got a channel, we've got a message. If only we could -- actually show me what you want to type.
CHRIS ANDERSON: You know, I just want to introduce somebody. I really want that to be the code that I have to type.
DON BOX: Yes, and of course this is real bits. This is not the final product. There is a grotesque line of code I need to type. I
would like everyone to look down or away from the screen while Chris types this. (Laughter.) Look away. This will not be in
the final product. It is a horrible hack, M-doting coding equals new system.text encoding. And by the way, this has got
nothing to do with system.text. This has to do with the way our plumbing dispatches messages. And
system.text.encoding.UTAF8, close paren, semi-colon. Do not do diddly-squat. Go to my blog, go to the shelf -- go to our -no, no, not there. Get rid of that. What are you? Got to the shell that we've got. Please do a start,
http://www.gotdotnet/team/dbox, and fine.
So let's go take a look at my blog. This is just a blog which any of you folks in the room can -CHRIS ANDERSON: You have a Sunday PDC post-world?
DON BOX: This is the thing I blogged at 3:00 a.m. this morning, before I went to bed. And what I'd like to do is blog
something new. So why don't you go ahead and build and run and our app. And this is builds, F5 for visual slick edit as well.
That M is billed as very enabling.
CHRIS ANDERSON: You know, I'm sorry, Don is -- or Jim has been sending me mail all day about this, and so I have got to
fix it. So we -DON BOX: Great. So Chris is going to tweak the UI a little bit. There we go. For "Indigo" we want things to look perfect.
CHRIS ANDERSON: Yes, there we go.
DON BOX: Great. So why don't you go ahead and exercise your creativity. You have wanton access to my blog. Please be
gentle with her. "Chris is the best demo god in the world." Yeah. "I only wish I could be that cool." You're right, Chris, I do.
42
Now, before you hit the button, moment of silence, a hush -- a hush falls across the room. Go ahead and hit it. I don't want
to think about the number of moving parts in this demonstration -- across the Internet. While this button remains depressed
a moment or two, it's sad -- oh, it came back. Why don't you go hit refresh on your Web browser? (Applause.) That was
great, Chris.
So we've seen a classic scenario where there's some service running on the Internet, we've got security built in, we're using
"Indigo," we're doing the dance. I think "Indigo" is actually a lot more interesting than just talking to things that are Web
sites.
What I'd like to do now is to use that same technology to build some funky UI that will make me feel better about "Avalon."
CHRIS ANDERSON: Excellent. I like to think you'd feel better about "Avalon."
DON BOX: And, you know, I've noticed something about you. We've been spending time together recently, and I've noticed
that you have tendencies which you're fighting -- (laughter) -- that you have been somewhat in denial for the past few years.
And I think today is the day we come to terms. And it's often -- you know, you -CHRIS ANDERSON: No, no, don't say it. They can't handle it.
DON BOX: Yes. I think the next piece of code should be written using the language you really know in your heart of hearts
you want to use, the language that you knew from the age of five you were attracted to, even though you couldn't explain it.
(Laughter.) (Applause.) So what Chris is going to do is create a tile. A tile is one of those fancy gadgets over on the left-hand
side of the shelf. And we have got a new tile project -- have you already created the project?
CHRIS ANDERSON: It's done.
DON BOX: Great. So we are going to create a tile project. What we are going to do is comment out the text of the tile, and
you might want to bump up the font size.
CHRIS ANDERSON: Hey, this is way better than those tech centers we've been using. There's Intellisense and save
incompletions.
DON BOX: There might be something there.
CHRIS ANDERSON: There's something to this Visual Studio thing.
DON BOX: There might be a future in this VS thing. (Applause.) And give it a variable. Great. OK, fine, be creative,
whatever. Fantastic. Chop, chop, chop. Take me to the code. OK, fantastic.
What we are going to do is write a service. We are going to write an "Indigo" service that runs inside this task bar. And to do
that, we are going to write a new class inside of our class that we have got here already. We are going to bring up a systemup message box of course.
CHRIS ANDERSON: I like system-up message. It's one of my new favorite namespaces.
DON BOX: I know it is. So go ahead and declare a new class, so public class My Service. And it is going to inherit from synch
message handler, which is a type-in message box. And, oh, wow, look at that.
CHRIS ANDERSON: In the body.
DON BOX: Oh, that's excellent.
CHRIS ANDERSON: I actually am pretty attracted to this language. It's pretty cute. It's -DON BOX: Yes.
CHRIS ANDERSON: I like it.
DON BOX: I wonder if I could do both. So, why don't we go ahead and what we are going to do is this message is going to be
a little bit simpler than the message we used before. We're just going to put a string in the body. So declare string. And I
want you to go ahead and crack that out as a message. So even though the message in that is in XML, is 100 percent SOAP
conformant, what are we going to do is just program against it as if it's an object, and then it's easier in this case. So we do a
message.content.getobject. This gives me a reference to the content. I then ask it to be coerced to string, and then there's
some VB magic syntax to make the cast work.
CHRIS ANDERSON: It's a cast.
DON BOX: Yes, welcome to the new world.
CHRIS ANDERSON: I am getting used to it rapidly.
DON BOX: Fantastic. Now, we've got the string. Again, this is one of these -- the code I would like to write. Actually, first
we've got a new class. That class doesn't have any reference to the foreground. So why don't we declare a field of type tile
foreground, and we'll set that up later on. We don't have to worry about that yet. What we really want to do is the
tile.thetext.
CHRIS ANDERSON: That's statement completion against the mark-up as well, so we haven't built -- thought we had -- well,
I did built it actually.
DON BOX: Great. Cool. And what we are going to do -- what we want to do is just assign it F. Now, this is the ideal world we
wish we lived in. Today what we are going to have to do to get this to work is a little magic. So what we are going to do is put
that code into a function that takes an object as a parameter and returns an object as a result, and we're also going to have
to -CHRIS ANDERSON: Do we have to return null or nothing or -DON BOX: We do. Or we don't?
CHRIS ANDERSON: VB takes care of that for us.
43
DON BOX: OK, great. So is that all you need to do in the function?
CHRIS ANDERSON: We need to cast the string.
DON BOX: So we'll pass the string in through that parameter. Fantastic.
CHRIS ANDERSON: I need to remember to put commas in the right place.
DON BOX: Yeah, great. Fantastic. And so now, what we need to do is this is again a line of code -- don't take too seriously,
but it's needed to make this demo work against the live bits. So look away from the screen. We're going to call
context.begininvoke. What this does is it takes the context in our thread, which is not the user interface thread. This is a
service in "Indigo" that the incoming message will be dispatched on an arbitrary thread. What we need to do in this build of
"Longhorn" is flip from that arbitrary thread to the thread that has user interface access. And to do that we do
context.begininvoke, passing it to delegates of the code we actually want to run.
CHRIS ANDERSON: So this is also VB doing multi-threaded programming with method type, talking to "Indigo" across any
protocol?
DON BOX: Yeah, yeah.
CHRIS ANDERSON: That's pretty good too.
DON BOX: Fantastic.
CHRIS ANDERSON: Great service.
DON BOX: That code is looking good.
CHRIS ANDERSON: It is.
DON BOX: Did we give it a good name?
CHRIS ANDERSON: We gave it the name of My Service, which I think is a great name.
DON BOX: Great. Let's go ahead and wire it up. So what we are going to do is create a new port. This is "Indigo." So we
create a port -- that's where all life begins in "Indigo." And this time what we are going to do is pass a constructor, which is
the URI that we are going to listen on. And I don't really want this thing to be accessible across the Internet. I only want it to
be accessible on my local box. So "Indigo" ships with a variety of transports. One of them has the MS.SOAP -- or cope -- dotXproc -CHRIS ANDERSON: And you were complaining about the other APIs?
DON BOX: Yeah, I know -- colon, and then put in an identifier of your choice here. One -- an identifier, great.
So we've got our port. Before we open the port, we need to wire up our service as a receive channel or on a receive channel,
so go ahead and say P-dot -- make your service, initialize it, and then go ahead and go port.P.receivechannel.handler equals
S and now release the hounds. Do a P.open and at this point all kinds of stuff's going to happen in my app.
CHRIS ANDERSON: Oh, but watch this. Everyone pay close attention here. I'm going to now install the tile. Let's hope I get
the right one. So, inside the build environment, I have Visual Studio automatically register that with the side bar so I didn't
have to do anything extra.
DON BOX: That's a very nice productivity enhancement.
CHRIS ANDERSON: It's a productivity enhancer.
DON BOX: Yes, great. (Applause.)
CHRIS ANDERSON: So, why don't we go modify our client to take advantage of this? So, we'll just use the existing XAML -this is the last piece of code we're going to write, so we're just going to ripping -DON BOX: Oh, I'm just going to start tearing this apart.
CHRIS ANDERSON: Yeah, get rid of that stuff. That looks -- oh, change the URI to point to the real one that we just typed
in, which is MS.SOAP.XPROC, an identifier, very good. We'll be living with that identifier for awhile.
DON BOX: Can we actually use the same UUID?
CHRIS ANDERSON: No, actually I'd like you to change the first eight digits very quickly.
DON BOX: OK, first eight digits.
CHRIS ANDERSON: 00000000, eight zeros, great.
DON BOX: This is in honor of the tune do, like an I unknown.
CHRIS ANDERSON: And pass a string, which we'll get from the bob.text. And, nuke that onerous, horrible line.
DON BOX: Gone.
CHRIS ANDERSON: You're cooking with gas, dude.
DON BOX: Fabulous.
CHRIS ANDERSON: Please go build. Have we had any demos tank, that just didn't work at all?
DON BOX: Not so anyone would know. (Laughter)
CHRIS ANDERSON: So I think, since this is our last demonstration it would be okay if it tanked.
DON BOX: OK
44
CHRIS ANDERSON: If it doesn't work -DON BOX: So we'll set expectations low and then if it works -CHRIS ANDERSON: You almost need accepting of that. So in the pink box type something. Yeah, of course, literal boy. And
then go ahead and say push me on. Actually I'm going to hit the invoke blogging code.
DON BOX: Oh, is that where we are?
CHRIS ANDERSON: Ah, argument null exception. I know what the failure is. I knew about this one before, and I have failed
you, Don. I have caused the only demo to tank. I've always wondered what it would be like to have your demo fail in front of,
you know, 7,000 or however many of thousands of people are here and now I truly know.
DON BOX: So, you're going to fix it in real time.
CHRIS ANDERSON: I am going to fix it in real time. So the error, for those of you who would like to know, is that I am still
woefully inadequate in my ability to use my language that I love truly and I miss, yes, pass the data to the background
thread.
DON BOX: Ah. It's all about data. So you still haven't come to terms. You were conflicted.
CHRIS ANDERSON: Great. OK, chow, chow, let's make this one happen in a successful way. OK. Or I could say that was my
attempt to show people that -- all right -- it's not coming up.
DON BOX: Really.
CHRIS ANDERSON: And, I know why. You see we have this -- remember this (in-proc ?), the ports, right, so we have a port
that's dangling and you never want to have a dangling port. But because we have that dangling port I'm going to make a
minor little change.
DON BOX: Ah.
CHRIS ANDERSON: And we're going to fix this. I can recover because I've paid attention in school and I know how to make
this work. So what happened was the -- something wedged, we left a transport port open. So we need to go change the
identifier. This is why the tool bar, the task bar was glowing.
DON BOX: OK, so we have our hole of PDC.
CHRIS ANDERSON: It showed.
DON BOX: Now, Chris, just do it.
CHRIS ANDERSON: OK. Please work. Yes. (Applause)
DON BOX: My brother, my brother. So that didn't use IIS, nothing.
CHRIS ANDERSON: No IIS, no nothing, very fast, very light weight, very cheap.
DON BOX: Great. This feels like a reasonable time, Jim. Thanks for having us.
JIM ALLCHIN: Thank you. And not too bad for whippersnappers, huh? (Applause)
Well, I've got a hard decision to make. We've got some incredible demos that we're about to go into, but we've already kept
you here a long time. Would you just like to stand for a few minutes or keep going?
AUDIENCE: Demo, demos!
JIM ALLCHIN: OK, we're going on.
The next thing that we are going to cover is how apps can take advantage of the great system you just saw and we have
been out working with a set of partners, both from the commercial side, corporate developers and Web developers to see how
they might take advantage of some of the great stuff that you're seeing.
So, we're going to have Adobe, Merck and Amazon come up and show. We're going to show what they're working on and the
first demo is going to be from Adobe and you know they're a premier graphic design company and most people aren't building
in notepad by EMAC slick edit; they have to use something very, very high end and I think Greg Gilley is here with his team
and is going to come out and give us a little demonstration on how they are going to take advantage of Longhorn. Hey, Greg.
(Applause)
GREG GILLEY: So, I assume everybody's familiar with PhotoShop, right? So Adobe does also had professional video tools.
One of them is Adobe AfterEffects. AfterEffects is used for motion graphics, compositing and special effects that gets used in
films and commercials and things like that, anyplace that you really want to add sizzle to your presentation. So, let me run a
real quick video here to show you an example of some of the things that AfterEffects can do.
(Video segment.)
So, pretty cool stuff. And, as we've been talking with Microsoft and as they were showing us some of the capabilities of
"Avalon," the "WinFS" stuff, we were thinking what if you could use a tool like this to design your user interface for your
application. So we decided we would sit down and try and see what we could do. So, we got Len who's a UI designer and
Chris, who's our coder. They're going to come out and show you a little example of what might be possible.
LEN: All right, thanks, Greg. Say, as a designer sitting down to build a new application for Windows today, if I wanted to find
a UI, I have very few options.
The way it is today is I sit down with a static image editing program, maybe like PhotoShop, and I create a bitmap of what I
want to produce. It's a really manual process. I take that bitmap and the first thing I do is print it out and hand it to my friend
Chris. And as a developer, he's going to sit down and try to recreate what I've done.
In an ideal world, I'd like to be able to use the tools that I know how to use as a designer, like After Effects from Adobe. And
what your seeing on the screen here is AfterEffects 6.0 with a program that we've written that exports to XAML.
45
So, what I've got here on the screen is actually some UI, which we use AfterEffects for, like Greg showed you, to build motion
graphics and special effects. So what you can see, this is sort of a motion graphic effect like you'd see for a stock check on an
evening news program, right, showing stock data coming in, except you'll notice it's not complete.
What it is actually is not just a video that I'm saving out, but a template for a UI. The way I might do this in today's world is
to build a video, put the data in there as a fixed value and then just save it out to something like Windows Media format.
Now, once that's done it sticks, I can't change it. What I've done here is created the charts, the animation. I put in some
parameters here for Chris to use later. And now I can save this as instead of a video that's fixed in time, I can save it as a
piece of UI and give it to Chris and he can go do something like bind it to a Web service to get real time data.
So what I want to do is save that, go over to export, export it to XAML, put it in a directory where Chris can pick it up. Going
to go ahead and write over this. And now that it's done, Chris can take over and add some logic to this and build some code
on top of my UI. So let's see what you can do, Chris.
CHRIS: Thank you, Len. So, the first thing as a developer, Len and I spoke, and we decided on a class name. And I went
ahead and I build a project. You can see that I had a dummy file, or a XAML file that Len has created in AfterEffects and
delivered to me. The first thing I'm going to do is load in his files and rebuild the application that I was working on just to
make sure that Len gave me what we discussed.
As you can see here, it's up, the animation loads, it looks beautiful, the fidelity is almost exactly what you have in After
Effects, except for some of the metadata that Len had in there, which soon I'll be binding to a Web service.
Additionally, you can see some elements that I added across the bottom, there's a portfolio and a news button and a little
text edit field for symbol look up.
So, let's go ahead and add some event handlers, but I'll actually bind this to the Web service and make this animation
dynamic and interactive. The first one we're going to add is just a loaded handler. I've already gone ahead and written some
of the code to handle this, but that will go ahead and bind this to the Web service and get the data dynamically.
The second one I'm going to add is an on-selection change handler for the list box. And what this will do is this will allow us to
handle changes in the list box and repopulate the data from the Web service.
So, I'm go ahead and send this again. Once again this is just XAML that I got for Len. I did not have to go into Notepad and
re-edit this. You can see now we have data that we've pulled from the Web Service running live on this machine. This is stock
data (Applause.) Pretty cool, huh?
And, in addition to that, you have this lit box down here where you can select different ones, and once again the animation
starts over, and you can see more data has been pulled off the server. But this is still XAML. So not only did I not have to
code the XAML, which I'm very happy about it, but I get to take advantage of the properties inherent in XAML such as the fact
that it's resolution independent, it's vector based. I can lay it back out and it has relayout built into it for me automatically. So
regardless of what this runs on, by Len and I working together we created this excellent UI and I didn't have to code any
XAML.
LEN: Wow, that's impressive. (Applause)
CHRIS: So you can see that's a great example of the kind of user interfaces that you can create inside "Avalon" and the nice
thing is there wasn't any EMAC involved. (Laughter) And, if I could make one final plea, so I know there's a lot of desktop app
guys out there and I know you guys probably already have UI designers that help you with this, but for you enterprise app
guys, could you please hire UI designers to take advantage of some of these new capabilities. Thank you. (Applause.)
JIM ALLCHIN: "Avalon." It's fabulous. The problem that often happens today that prevents a huge step up in the
productivity is the fact that doing things across organizations and with different systems that exist in different organizations,
it's virtually impossible. So if you really want to have a huge jump for any of the business apps you really have to do
something that's sort of different. And, we have Merck here who's going to give you an idea of how they're approaching a big
jump ahead using Indigo. So Jim Karkanias is here I think with his team and is going to give you an idea of what his group is
going to be able to do.
JIM KARKANIAS: It's good to be here. (Applause) Well, as you've heard, I'm Jim Karkanias. I head operations for part of
Merck, and what operations means is we basically solve problems that we encounter in the business of clinical trials. Now, you
may know already that clinical trials is a complex business, complex for a lot of reasons. Some of the inherent reasons are
that it's research and discovering the unknown is sort of inherently a difficult task, as you can understand.
But there are others factors that contribute to this. For example, clinical trials, just one clinical trial, one piece of a clinical
trial, would involve as many people as would fill this room, so you can imagine how many interactions you need to take into
account.
As a developer, if you're going to build a system to handle that or an application to handle that, you can appreciate that that's
a challenging task, so how might you approach that.
We're going to suggest that information management is a key here, and focusing on the information itself from a supply chain
standpoint and working it into the workflow of the folks involved -- the patients in the trials, the physicians taking care of
those patients, the regulatory agencies, the hospitals that are involved -- allowing them to work in a way that's natural for
them and allows us to collect the data at the same time is a much easier way to implement such a system.
So obviously "Indigo" is an opportunity to connect all these things together and we'll show you what we mean by that.
I thought we'd take the opportunity to put together a demo that talks about a hypothetical clinical trial. This will be an allergy
study and we'll just show you a few of the participants that would normally be encountered in such a thing.
This is Rich Gleeson, who's going to be playing the part of a physician taking care of patients in the trial, Jim King, who will be
playing the part of a clinical monitor managing the data in the trial and, Jim, if you wouldn't mind being the patient in the
trial.
JIM KING: I'm still breathing.
JIM KARKANIAS: OK, great. We'll get you set up and come back to you.
46
So let's talk about how you might deploy a system. I just finished telling you that we don't think that you can achieve a
solution here by approaching it from a classical direction, so how do you even get the software to the people that need to use
it, and we'll show you that. I'll turn it over to Rich, who will walk us through one-click install.
RICH GLEESON: Great. So, the first step as the physician for this trial is I need to get the software installed onto my
desktop. And we're going to do the one-click "Longhorn" deployment. I'm going to click on My Studies site initiation, and this
is going to pull down the client to my desktop.
So now instead of the old world of just having a Web page I have a full rich client that is going to allow me to participate with
this trial.
Now, the next step is I need to add a patient to my study, I need to add Jim here, so I'm going to Select Patient. And you're
going see the "Longhorn" contact picker, but customized for my application. So this is showing me my contacts that qualified
for the study, of which I've got Jim. So using the "Longhorn" identity system, I have this contact and I can trust that I know
who he is, and I'm going to add him to my study. I've got a lock showing I've got a trust. I also have a pathway for data to
Jim.
So let's see how he's doing. Let's check his real-time readings. I should start taking data from him. There you go.
RICH GLEESON: Thank goodness. (Laughter.) So that's pretty cool. What you're seeing here is real-time data coming from
Jim. He's holding a device here, as you can see. This is a measurement device from QRS Diagnostics, and it connects to an
iPAQ. And you remember I said let's try and create an environment that allows the patient or the participants in the trial to
work in the way that is natural to them.
This is an allergy trial, so we need to collect data on pulse, oxygenation, respiratory function. And we could ask Jim to go to a
hospital or schedule a visit with a physician, but instead allow him to work at home, for example, and collect data on his
terms. This is wirelessly communicating with a PC. It could be in his own. The data is traversing Net gateways, a whole host
of intermediate servers, making it in real time to the physician's office. And the applications developed along the way don't
need to know the details of that and "Indigo" helps to bridge that environment.
So the data is looking pretty good. On these screens here you should be seeing the real-time data. Let's create an anomaly
that we need to handle. So, Jim, if you wouldn't mind, just take a shallow breath into that tube. And I'll explain that, of
course, Merck needs to make sure that we understand what's going on at all times in our trial to maintain maximum safety
and efficacy of our product. So the physician is being notified of an anomalous event and he's going to start a collaboration
session with Merck to talk about this data. And you'll see how "Indigo" bridges a disconnected environment in that case.
I'll turn it over to Jim King, who will walk us through that.
JIM KING: Thanks, Jim. As Jim said, I'm playing the part of the Merck clinical monitor, so I'm going to receive notification
that you just saw pop up on the screen there. And that's in a position indicating that there's something to investigate. So I'm
going to go ahead and look at he's sending me data.
Let's see what we're actually looking for. We're going to go to real time. And remember, when data was sent, I wasn't
connected. Now I'm looking for that cue to respond and feed me all that data. You see it all catching up here, and I didn't
have to do anything but go ahead and click on it.
Thank you. (Applause.) Also, there's an anomaly noted here, so clearly that's what he wants to look at. So we're going to go
ahead and do a little bit more work. And again, we're going to make use of some of the features that are available here;
specifically "Avalon" for the visualization and then we're going to use "Indigo" again to make another Web services call and
really do some more drilling into this.
You see, there's three patients here who look like they share the same anomaly. You've got a threshold here that they all fall
below. So we're going to drill into these three patients. And I'm going to use a Web Service call out to MapPoint to pull all this
together. So I've got data coming from many different places, from the patient to the physician, back into my office. And right
off the bat, I'm able to draw an initial conclusion by looking at the geographic proximity of these three patients. They're all in
a cluster here. And MapPoint allowed me to do that.
But that doesn't tell me enough, so we're going to drill into it a little bit more and overlay the pollen count or for all of us
maybe smoke would be a little bit more appropriate with everything we're dealing with. But we're going to overlay the pollen
count. We'll see what happens. Almost immediately, you see that everybody's in the pollen zone who had the anomalous
event.
So we can draw an initial conclusion. To make it more compelling and understand if there's a temporal aspect here let's roll
back the block and again we're going to use the feature of "Avalon." Notice the alpha blending of the overlay and the data
binding we're able to do as I roll this back. That's pretty powerful stuff right there.
So we roll it back. We're able to draw an initial conclusion, and say that it looks like the data that was sent to me indicates
that the anomalies are definitely pollen-related, and I can collaborate with a physician on that information.
JIM KARKANIAS: Thanks a lot, Jim. That's awesome. (Applause.)
So you can see -- let's review what we've seen here. We have a multitude of systems involved, connected here, all with
applications written, without regard to the infrastructure. "Indigo" helps to map all that together. We're getting the right
information to the right people in the right time frame. And we are working with the IT barriers that are created as a function
of all the different systems that are in existence as a result of this large population that we have to deal with in clinical trials,
much like what other large businesses are faced with in today's world.
So we encourage you to talk with us more about this. There's a booth to visit, the "Indigo" booth, and a partner pavilion. But
now Don Box will be talking about the code and walking us through some of that. Thanks a lot. (Applause.)
JIM ALLCHIN: Thank you. Well, we're going to have Don come out. He's back there someplace. He's just going to give you a
little bit -- a snippet of exactly how the "Indigo" code worked.
DON BOX: Thanks, Jim. Let's take a look at this machine here. Let me minimize all these fancy windows. Here's some code.
What I'd like to do is take a quick glance at the code that made that Merck program work. I'm going to open up a simple C#
file, which is already written. This uses "Indigo," as we said already.
47
This one actually uses a different part of "Indigo" than we used in the lab. In the lab, we were programming at the low-level
messaging layer. This uses a more higher-order-of-service model. And notice that we simply write a class. We mark it with
Dialogue Port Type. What Dialogue Port Type says is I expect arbitrary messages to come in and go out; it's not a strict
request reply disciple.
And notice also that I was able to annotate methods with a variety of attributes to control what the contract was between the
service and consumer. And in this case, not only was I able to control the shape of the messages and the message exchange
pattern, but I was also able to declaratively say, 'Here are the security requirements I need' -- in this case, pointing to a blob
of config XML, which controls the concrete details of the security, as well as a logical role name, which I'm going to use for
standard authorization of incoming messages.
JIM ALLCHIN: You did it all with just those few lines of code?
DON BOX: Yeah, with just those few lines of code.
JIM ALLCHIN: Fantastic. Thanks.
DON BOX: Thanks. (Applause.)
JIM ALLCHIN: So you've now seen two of the demonstrations. I want to do another one with Amazon that ties it all
together. And this will show what can be done in an application using "Avalon," how it can be used and store information in
"WinFS" and get new views out of that, and then finally, how to use "Indigo" for the Web services.
Al Vermeulen is here from Amazon. Al, you want to come out and show us cool stuff? Great.
AL VERMEU: All right. Thanks, Jim. (Applause.) Hi. How are you all doing? Are you starting to see kind of the possibilities of
what you'll be able to build with "Longhorn" and "Avalon" and "Indigo" and these things? Are you starting to kind of get
excited about this stuff? (Applause.) Or are you just at the point now where you've had a couple of cups of coffee and some
water and been sitting there for three years?
And the reason I ask if you're getting excited about what it is I'm doing here, is that we got together with some folks from
Microsoft and some folks from Amazon -- oh, I don't know, maybe a month or so ago -- just to talk a little bit about what
we're doing at our respective companies. The Microsoft folks, they told us about "Longhorn," a lot of the things that we're
seeing here.
And at Amazon, we told them about our Web services strategy. And our Web services strategy is really pretty simple. What it
really comes down to is take all of the elements of our e-commerce platform that you all know and love through interacting
with our Web site. I assume everybody here is boxed up on Amazon.com. If you haven't, we run this Web site. You can go
there and buy stuff. I encourage you to go for it.
Our Web services strategy is to take all of that functionality, all of that data, all the algorithms that we've developed over the
last several years, and expose them to applications via Web services. That's it -- pretty simple, pretty straightforward.
When we got together with the Microsoft people, we started thinking, "Well, how is it that we can create innovative new
things using "Avalon" and "WinFS," these rich client technologies, to create interesting shopping experiences for our
customers? What kind of things can we do by combining Amazon Web services and "Longhorn?"
And we came up with all kinds of ideas. Unfortunately, I only have a few minutes so I'm just going to sort of show you a
couple of those ideas. And what I'll do first is fire up the Amazon rich shopping application. This is just a demonstration that
we put together. And you can see right away, just as we fire this up, that this is not your normal HTML Web page. Right?
We've got some video happening here. That's kind of cool. We've got this shopping cart control so you can sort of check out
what's in your shopping cart at any time without having to go and, you know, actually change to a different Web page. That's
kind of neat.
This is something interesting here. You've got recommendations, and the recommendations are actually cycling through. One
of the things that we know at Amazon is that material that we put -- we call this above the fold -- stuff near the top of the
Web page is much more likely to convert; that is, people are much more likely to click on it than stuff below the Web page.
So some clever person here said, "Well, we can use that space above the fold and rotate some recommendations through it."
Now, why would a developer do this? One of the things about our Web services that's really kind of interesting is that
developers who build things on Amazon Web services actually have a bit of an economic model that they can leverage. OK,
this is an important thing we do with our Web services.
The model goes like this. If you write an application and you distribute it out to folks and they use that application to buy
things on Amazon.com, then, via our Associates program, we give you a piece of the action. So you get a cut. And there's
actually a lot of people who build things on Web services that are making a reasonable living at it. So that's kind of cool.
Let's actually use this thing now to buy something. So I'm going to do a search for a digital camera. It turns out that my wife
this weekend has gone to visit her sister. Her sister just had a child. And when your sister has a child, you have to go and
visit her. The other thing you have to do is you have to take your camera, because you can't have too many pictures of a
four-month-old baby.
So that left me without a camera. And I got to thinking, well, I really ought to have two, because I'd love to be able to take
pictures of all these fine people. And so we'll go ahead and search for a digital camera. What's happened while I was talking is
that the application, this rich shopping application, has hit Amazon's Web services, asked for a digital camera, and then gone
and retrieved all of the rich information we have about 300 cameras that match that search criteria. It took all of that rich
information and stuck it into "WinFS" so that we can have "Avalon" controls that could, you know, quickly and easily go ahead
and search through that information to find things. If I was Don Box, I'd actually in real time build this app and show you just
how easy it is to do this. But I am not Don Box.
So we can go ahead and we can do things like filtering operations. Let's say we're only interested in cameras that are really
kind of well-liked by our customers, that got, say, four stars or better, and we've cut down from several hundred cameras
down to 31. That's kind of fun. We can sort by brand. Let me reset this. We can sort by brand. Let's say we're interested in -can we sort -- we can sort by brand; just ask for, say, Canon cameras and Vivitar cameras.
So that's kind of neat. We can do some basic sort of filtering things here. We can get detailed information on any camera. And
you notice the detail information. This camera doesn't have any reviews. The detail information includes reviews and price
48
and all kinds of stuff like that. That's great. Let's see. Does this one have reviews? Oh, I've picked two cameras without
reviews. That's okay.
But at the end of the day, this is still kind of a relatively flat sort of a list, right? I mean, it's cool, but it's not kind of what
you'd hoped for in this rich graphical environment that we're expecting with this new operating system.
So let's take a look at another way to display this information. So this is kind of cool. This is the "Avalon" carousel control. So
taking all of that data about cameras that we retrieved from Amazon, and put it in this really kind of nifty control, we display
all several hundred cameras at once. And I can go through and rotate through. (Applause). Doesn't that look slick? It's just
beautiful.
It's not only beautiful; it's actually practical, too. This is a really kind of useful way to be able to check out stuff. Let's see. I
can filter on price and you can see the number of panels kind of diminishes there. I want to pay -- you know, I probably want
something more than US$200, and I don't really want to spend more than $583.81. So that's great.
I can go through, and let's actually buy one of these now. Let's see, how about this one? And here we go. This one actually
has reviews, so you can see that I was telling the truth when I said there was additional information about all of these
products that's available.
Now, to buy this, again, we'll just do a nice simple graphical metaphor. We'll grab this thing and we'll just drag it over here
into the shopping cart. There we go. And we've got a shopping cart now. That's kind of fun. And now, to check out, all we
have to do is push the button.
One of the things that I want to point out here is that all of this stuff is real. OK, this is all real code. So Amazon Web
services, this all works today. You can go home and write these kind of applications on top of the Amazon platform and you
can use the "Longhorn" bits, once they're available, to actually build this kind of UI. So that's very cool. We can go ahead and
change things about our shipping options, and let's actually place that order.
The reason -- this is the one thing, actually, that was dummied up in this demo is the demo doesn't actually place real orders.
Otherwise I'd own a lot of cameras by now. And you know the nice thing about that? When I buy that camera, buying things
from Amazon makes you happy. (Laughter.) It's a great thing.
OK, so that's one thing we can do. We have a nice, rich client shopping experience. What else can we do? Like I said, we
came up with a lot of things. The other one I'm going to show you right now involves the calendar control, and this is the idea
that at Amazon we have lots of, you know, products that release all the time. And it's a big deal to people to know when do
products release.
So we can go ahead and get that data again from Amazon Web services and display it on this nice calendar control, and you
can see that the David Bowie album came out on the 21st. Actually, my family has already bought the two things at the top
this week, the Indiana Jones and the David Bowie, and we'll be buying "The Two Towers" as soon as it comes out. My son is
just a huge "Lord of the Rings" fan. So this is kind of nice.
What I would really like to do, though, is see how this fits in with my personal life, if I'll have time to actually watch these
movies and so on. So I can overlay my calendar on top of this calendar. What's interesting about this -- you heard Jim talk
about this already -- it used to be very difficult to get at my calendar information, because it was buried somewhere in
Outlook or in Exchange or something. I don't know; it was hidden way down there. And there's probably a lot of people in this
crowd who are smart enough to know how to get that stuff out and dig it out of there and put it on this page, but it's difficult
for mere mortals. Well, with "WinFS" it's easy, because that data is exposed.
It's really interesting to think about the Amazon information you're seeing here, because really our Web services strategy is
the same thing. All of the Amazon data used to be buried behind a Web site. It was hard to get at. What we've done with Web
services is make it easy to get at. Right? So now we can take this easy data to get out from Amazon, the nice data from
"WinFS," and put it together in this one control. So that's great. I can see I'm at the PDC this week. This is something else
that was made up. I'm not really going to Hawaii. It'd be nice.
But this is actually true. This is really true. November the 2nd is my mom's birthday. And I look at this and I go, 'You know,
this is terrible, because it's Monday. My mom's birthday is on Sunday and I haven't bought her anything.' This is actually
literally true. I've known about her birthday for a while and I still haven't bought her anything.
The reason we know this is mom's birthday is because in "Avalon," we have information about all of my friends and family.
We go ahead and we look there. We see that there's birthday information. So we know that this is the actual birthday of a
friend of mine. We can build functionality into the app, which we've done, to go through and purchase a gift for my mom. So
we'll go and we'll purchase a gift for my mom.
What we've done now is we've hit Amazon.com Web services and gotten hold of my mom's wish list. And this actually is my
mom's wish list, just to show that this is real stuff. And you can see my mom likes cool things, unlike Don Box's mom, who
installs E-Max and probably owns all the O'Reilly books; it turns out that my mom quilts and listens to Elton John.
So I can go ahead and I think I'll buy here the Elton John CD, and again I wish the ordering thing was actually hooked up
here because I've done this several times now and I still haven't bought my mom a present. (Laughter.)
So we'll go ahead and drop that in and again I'll go ahead and buy this. I can add a few more things. I can put a message
into my mom for her birthday, so that's a good idea. So I'll write my mom just a little note. OK, that's cool. And it knows it's a
birthday gift, so it's automatically set up gift wrapping. I can turn that off, but I actually want gift wrapping for my mom. It
knows I'm buying something for my mom's birthday, so you notice that the people picker, the contact address has already set
this up automatically to ship to my mom. That's great. If I wanted to, I could fire up the people picker and go ahead and
change that or I could change it and have it build somewhere else. That's great. Standard shipping will be fine because her
birthday is in five days. So we're all set, we'll go ahead and place that order.
And there we go. Now, if this was actually hooked up at the end to do the order, my mom would have her gift. So that's cool.
The last thing I want to show you -- thank you. (Applause.)
The last thing I'm just going to touch on very briefly, and that's to show that this whole environment could be integrated. And
what we've done is, over here, in order status, as I'm placing these orders, I go ahead and I drop them into my sidebar.
Something really interesting that we've discovered about our customers at Amazon is that they love to see what's happening
with the stuff they've ordered.
49
And I'll bet you've done this too, right? People love to track their orders. They love to know that UPS has picked it up in
Fernley, Nevada, and it's now going down whatever interstate, and it's getting dropped off here, and so on. So what we're
imagining that we could do here -- and this is not real yet, we haven't built this -- what we're imagining we could do is with a
notification service, we can actually be sending notifications, via Web services, and a client, like an "Avalon" client, could
receive those notifications and sort of show you, in real time, where your order is going. So that's kind of neat.
So this is what I want to talk about, is the rich client experience. So in closing, let me just again mention that this was,
except for the very last part, all real stuff built on Amazon Web services. We've released -- I believer there's been something
over 35,000 developers who are currently using Web services, built lots of cool applications, lots of orders coming through
that channel.
If you want to learn more, I think we have a booth setup here, and we'll have somebody there to man it, and you can come
and talk to them. I encourage you to download the software and play with it. Thank you very much.
JIM ALLCHIN: All of the underlying code that you've seen is real. Think about it. It's not that way in some other events.
(Laughter.) And nothing crashed. It's not that way in other events too. "Longhorn" is truly a milestone event for Microsoft,
who has been sort of the receiving end of not moving fast enough on the Internet. You know, we pay attention and try to get
a lead on as many things as we possibly can. We think that this is an area where, if you invest early and get with the train
and learn, then you can receive some disproportionate share of the gains that will take place.
We've got a lot of technology. We're also going to invest to help you make money in deeper ways than what we have before.
Typically, we try to push marketing. We push the product out there, give you a lot of what we would call sockets for your
applications. We're going to go beyond that this time. We don't have this all worked out, but some of the things that I wanted
to mention at this event was that we've done some system design reviews, some early reviews of this with developers, and
they keep saying, 'How about helping us out on licensing? How about putting an automated system in there so you could
license your product, if you're a commercial vendor?'
That is something that we are going to do. We have continued to work on that technology, so we'll have a facility for you to
be able to license your product and do it at scale if you want to, in whatever licensing models that you want to use. But the
infrastructure would be in place. That's one thing.
Second thing is that we have a very, very, very simple Windows catalogue today. Think about us taking it to a whole other
level, where you will be able to have your product and be able to take it from end to end. And we will push, push, push those
out to people so that they can see the best Windows "Longhorn" applications. And, of course, there will be more coming. We
will make this a tremendously large event.
In terms of, now, how do you get there, if you have Win32 bit app today, barring security issues and the like, those
applications should be able to run on "Longhorn." If you're working with the .NET Framework today, those applications would
work on "Longhorn," and you're on your way to the WinFX APIs. If you have a Win 32 bit app, or a .NET Framework app, you
can start taking advantage of the WinFX APIs.
And perhaps, you can't rewrite your code to manage. It's OK. Just start using the functionality in the system that you need
for your application, whatever it would be. We've designed the system specifically for that purpose.
And then, finally, if you're writing a new application and it's in the "Longhorn" timeframe, then you can take advantage of the
full WinFX environment. Now, we don't have WinFX APIs today, certainly, in the bits that we're going to give out here that
cover the entire system. But it should be very clear that's the path that we're on, to basically make that the new layer,
surface area for the system.
In terms of schedule, this is only the client. Obviously, there are separate schedules for server. They've both got the same
general technology in server, but I'm only going to get into the client schedule. Quickly, the media center just shifts. The
"Longhorn" developer preview, that's the bit that we're going to provide to you today.
In the first half of 2004, there will be a service pack for Windows XP, and a new updated Tablet, which has dramatically better
recognition capabilities, as well as several other very, very nice facilities. In the summer time, and second half of the year,
we'll be coming out with a 64-bit edition for AMD, as well as "Longhorn" Beta 1. Beta one will be where we take it to the next
level and ask a lot more people besides you.
I mean, honestly, we've shown "Longhorn" to no one before today -- just a few set of people, like the ISVs here, to get their
feedback. We will be going bigger there. We're not going to make other commitments about when we're going to get done
with this product. We're going to try to focus on getting to Beta. See, you will have a pretty good idea, with the bits, about
where we're at. We still have a long way to go.
We are listening. We have a show net here called http://commnet. There's an application that, if you already haven't
downloaded, I propose that you do that. Give us feedback. I know there's been, already, a bunch of information coming. I
was walking back stage, looking at some of the information. It's great. It's a great way for you to get with your peers. It's a
great way to tell us what's going on. We are listening, and we're very invested in your success.
There's a set of things that we think you should do. This would be what we would call our call to action. They're very straight
ahead. We think fundamentals are really important. We, together, have to nail the security infrastructure so that people can
trust these systems. Web services: it's the way to get great inter ops. Managed codes: it's the way to avoid arrows, pointers,
get higher productivity.
Smart clients: you want high, interactive, rich experience. You need to take advantage of those and help us be better in
community. We're trying to really work on that, as you'll see with the application we've got here -- all of the people that are
into blogs, and other things. We're really trying to connect with you, and that's what this conference is about.
Now, you get the bits today. In fact, as you go to lunch, you're going to be able to get the bits. You should have gotten a
card, which is in your conference bags. There's a lot of information on these discs. There are two CDs just of "Longhorn" and
different versions -- a 32-bit version, 64-bit, both of IE 64 as well as AMD 64. We also talked about that as X64. There is the
"Longhorn" driver kit, along with the SDK. There is Visual Studio, the would-be version, Yukon the sequel, newest update of
that.
There is the Virtual PC 2004 version. Now, that's a virtual machine technology that does actually work with these "Longhorn"
bits. And there's lots of white papers, and samples, and other things.
50
Now, I want to set the context for where we are in this release. We still are very early. We've never shared bits this early. So
you're going to see a lot of work. There's things in terms of the programming model that we haven't cleaned up yet.
Performance is not good. (Laughter.)
I mean, there's no other way to talk about it. Performance is not good yet. You should put on only high end machines, and I
propose that you not put it on any production machines, and I propose that you not connect it -- at least not knowingly -- to
the Internet, in the sense that, it's fine if you put on the Internet connection firewall, which should be on by default. But you
should be thinking, you should know that these are early bits.
We think it's incredibly cool, and we hope it's what you need in order to get really familiar with the system and provide us
that feedback that we want. We're incredibly excited about it. We think it is the next generation. And with that, I want to
thank you.
Have a good lunch and good conference. Thank you very much.
51
http://www.microsoft.com/presspass/exec/ericr/10-28pdc2003.asp
Transcript of Remarks by Eric Rudder, Senior Vice President, Servers and Tools, Microsoft
Corporation
Microsoft Professional Developers Conference 2003
Los Angeles, California
October 28, 2003
ANNOUNCER: Ladies and gentlemen, please welcome Senior Vice President Eric Rudder. (Applause.)
ERIC RUDDER: Well, good morning. Thanks for your warm welcome. Thanks for putting up with some travel hassles to join
us at the PDC. And most of all, thank you for really making our technology sing. You guys over the past couple years have
been taking advantage of technology on the leading edge and producing some really great applications and we all know we're
not successful without the great work that you do, so I want to make sure, if nothing else today, that I get a chance to thank
you.
You'll notice in some of the handouts in your PDC there's this little book called ".NET Momentum" and there's a bunch of case
studies highlighted on how people are using the technologies in production today and I encourage you to flip through it. It
might kind of give you some ideas on how you can solve some problems of your own.
Well, like you, I was actually impacted by some of the travel delays on the way here and so I had a bunch of time to do some
extra sightseeing. But no matter what I did, I kind of couldn't get the PDC off my mind. And even while I was trying to relax, I
kept starting to think about Longhorn and then I started to think about the components of "Longhorn," "Indigo," "Avalon,"
"WinFS." And then I started thinking about my keynote a little bit today and Gordon's keynote. We're going to talk about kind
of the "Yukon" and "Whidbey" wave of technologies. And then I started to relax and think about the week and then I started to
think about what I wanted to be for Halloween, and then I kind of got back to the PDC again.
So I'm going to actually go through some of the tools technology in "Whidbey" that complement the platform technology that
Jim talked about yesterday.
So I didn't bring out the poster but you guys all remember this from yesterday, the "WinFS" kind of taxonomy and overview.
I'm going to talk about how tools complement that technology as a great leading edge.
I had a chance to talk to many of you yesterday and in the weeks past, months past since the last PDC and we got a lot of
feedback from developers. And I think the feedback is fairly consistent along lots of lines. The first I hear is, "Hey, as you guys
introduce a new platform, please don't make me rewrite everything." I hear things about, "I need more samples. The way I
learn is samples, samples, samples; give me more sample code. And when you give me sample code, give it to me in my
language of choice. So if I'm a C++ developer, I want to see it that way. If I'm a VB .NET developer, show me VB samples. If
I'm a J# developer, show me in Java. And if I'm C#, show me in C#."
And so we've actually changed how we do documentation both in our products and for the PDC at large. For our products
we've actually gone to a model where the Visual Studio environment will automatically update itself so you can actually go up
now if you have Visual Studio 2003 and update a new set of samples and actually since we've shipped Visual Studio .NET 2003,
which is only a few short months ago, we actually have a new 5,279 samples have been added and linked with help and
indexed and it's very nice to search.
And literally the SDK for "Longhorn," and for "Yukon" and for all the technologies that were introduced, is a live SDK, linked to
the Internet. We'll show you in the demo kind of how you can comment, and you can write Microsoft a note saying, "Hey, this
thing in your documentation is buggy," or "I need samples here or please fix this stuff," and it will be a living document and a
living update so you can respond kind of in real time.
We hear a lot about, "Hey, writing the application is great but still moving code from development to production is too hard and
I need better support and better facilities for partnering with IT." And we'll show you some of that technology in the demo
today.
And I hear a lot about, you know, especially with the latest news on security, "How can you help me make my code secure?"
A lot about devices I hear. People see the Tablet PCs, is that hard, is it easy, how do I add Tablet PC support; I'll talk a little bit
about that.
"What do I need to do to support devices? Do I need to completely rewrite my app? How do I factor my app? Can I kind of
have a common code base but add some features? "
I hear a lot about, "Please make sure I can interoperate with other vendors' technology. I have to access Oracle databases or
my own system." Or, "I've got IBM middleware involved," and all the technology continues to interoperate as we move forward
into "Longhorn."
And finally here are concerns about deployment and we'll show you some of the Click-Once technology as well.
52
Well, first I want to assure you that we're listening and we understand that the road to "WinFS" is a long one and people have a
lot of code in Win 32 today. We at Microsoft actually have some Win 32 code ourselves. And we expect people to transition
gradually.
So the first call to action really is to think about new features that you're adding, move to managed code now. It will position
you much better to maximize "Longhorn's" capabilities.
But absolutely you can take your Win 32 native code and without rewriting everything you manage take advantage of the
"Longhorn" features. And it works much like the interop works between Win 32 and the .NET Framework does today. We have
COM interop and remoting and it's nice. It's a great way to get started, it's a great way to prototype. I do expect most
applications over the long term to be managed, but it's not required, you don't need to rewrite everything, and you can
certainly take advantage of all the code that you've written to date.
The second great way to really kind of take advantage of some of the new technologies is to think about using Web services as
a wrapper to what you're doing. It's very easy to take an existing system and put a Web-service front end on it and expose
it out to the world.
Web services are based on open standards. You can put a Web-service front end in terms of any platform. It's protocolbased. So again there's good industry support, good interoperability, and I expect a lot of people to take this solution going
forward.
At the PDC last time, we actually kind of were just at the cusp of the Web-services revolution. We had XML, we had SOAP,
WSDL, UDDI and we were really working to put together the basic Web services profile and we've made great progress on that.
At the time, you could only run Web services over HTTP. That was the only way we specified it. And we heard a lot of
feedback from folks on, "Hey, this is a great start, we like the direction, but we need more. We need to run over other
transports. Sometimes we'd actually like to use mail, because it's our reliable store. Or we may have an investment in reliable
messaging infrastructure, either (MSNQ or MQ Series or ?????); can I run Web-services applications over that transport."
And we heard a lot of feedback about people wanting to write secure, reliable transactive Web services and that our platform
needed to grow and enhance and make that easier.
And so I have some good news coming on in how we're going to make it easier to write connected applications using the
"Indigo" technology going forward.
We heard a lot about language choice and people's existing code and at the last PDC we had a broad selection of languages. I
think we announced about 27 languages. This kind of surprised me. We've done nothing but continue to expand the support
for languages in .NET. You can see some commercial like Delphi, some F# and P#, so you might want to reserve; there's only
about 20 letters left in the alphabet if you want to get your own # up there.
And then I asked kind of people to go out and see what the research community is doing on top of the .NET Framework
because we get many of our ideas from the research community on how to put new features in or do language enhancements.
And the team came back with a project at the University of Denmark called Pizza. Besides the fact that I thought that was kind
of a cheesy example, I did wonder like, well, is this real? (Groans from audience.) All right, I think the boos are fair, it's OK.
(Laughter.)
I thought, you know, is this real, are they just trying to put it on my slide to see if I'll go through or do I do an edit. It is a real
project. It actually started off based on some Java extensions. They've now ported over to the .NET Framework.
The great thing is you see some of the features, whether it's script or error-handling or string-manipulation, you'll see a lot of
these features coming into the .NET environment going off in the future.
I'm going to talk a lot about Visual Studio "Whidbey." You have a copy of Visual Studio "Whidbey" in your bag. We always like
to get the tools out in front of the wave, because I think in many ways tools drive the wave and you need great tools to take
advantage of the platform.
So you can actually absolutely use "Whidbey" to take advantage of "Longhorn." We'll actually deliver "Whidbey" in final form
way before "Longhorn" ships, so you can expect another update from the tools around the time that "Longhorn" ships.
We spent a lot of time really continuing to craft innovation in the language, so you'll see support for generics, iterators, partial
types, operator-overlaying in languages that didn't have it, like VB .NET. There's good support in C++, not only for
interoperating with .NET and some of the type system unification work that we're doing but there's nice coexistence. If you're
used to C++ templates, you can now use them with CLR types and that also works with the way we're doing generics, super
powerful examples there.
We've worked super hard on IDE productivity and we'll show you in some of the demos we have support for refactoring, code
expansions, which is kind of a new feature that I don't think we've seen in any editors that people are going to get super
interested in, and we've expanded out our XML documentation across languages and again working with the interactive help
system and really drawing the community in to the IDE itself.
53
And really that was one of our goals is rather than have to sit in Visual Studio and kind of start a Web browser and kind of
interact back and forth, most of the extensions that we have in Visual Studio for acting in the community, you can actually do
right in line in Visual Studio and we just post Web services on Microsoft.com and trade information back and forth between the
IDE and the services.
We've done some great work in debugging. Edit-and-continue is back for VB. (Applause.) We've got some new data tips and
a data visualizer. This actually allows you to see custom visualizations for specific types that may be important for your
application. For example, if you have a cursor type coming back from a database and kind of the last thing you want to do is
sit in a debugger and go through it row by row or array by array. You can actually write your own visual representation of that
data structure to debug it, which is kind of cool.
I mentioned some of the template support. We actually have this feature called STL .NET. If you like STL programming in the
C++ world and want to come over to .NET I think people will find that attractive.
And then for people doing scientific computing and high-end applications, we've added support for Open MP.
Well, even if all these great productivity features and editor enhancements and IDE, I still hear, "God, I still have so much code
to write. I still have so much work to do. I still have this huge application backlog. Please help me." And I thought I'd
actually go through some examples kind of from the years past to where we're going and what it looks like and what we're
doing to reduce the amount of code that you have to write.
Here's an example actually of a secure, reliable, transacted Web services example that we built using Visual Studio .NET. And
I think this kind of proves the point. You absolutely could build this solution. It's a real sample solution we build. But it took
about 50,000 lines of code, which is a non-trivial production effort. And that's great if you're a rocket scientist and you have a
couple of rocket scientists around to write it, but we knew we could do a lot better.
And so we created what we call WSE, the Web Services Enhancements toolkit. We focused really hard on security, because
that was the feedback that we got from customers first, make the security easier, it's too error prone, I don't want my guys
coding security, I just want to do declarative operations and help me.
And we took a dramatic reduction; we went down to about 27,000 lines of code from the previous version and that I think can
be coded by mere mortals and a development team going forward.
But that still isn't good enough, especially for a guy like me that wants to get up there and do demos. So we took this
sample and we had a go in Indigo to actually code it in a slightly more aggressive fashion and so using the same example in
Indigo we actually get down to three lines of code. (Applause.)
So that's pretty impressive. I think the most impressive thing is that we actually get down to the rocket scientist to someone
like me actually being able to go and write an example.
We've also simplified printing. This is a lot of feedback we got, especially from the VB community on printing and print
previews, way too much code dealing with printers. Visual Basic "Whidbey" actually has a feature to deal with any object,
literally that print preview function takes an object, you can customize it, super nice. I think people are really going to
appreciate that.
We heard a lot of feedback about user management on Web sites. Lots of people want to store names, provide for
personalization, and today that's a real pain. It involves sending up the schema, managing SQL Server, sending scripts, getting
the code right to do the storage, getting all the encryption right and then actually running the code in your application itself to
store the information in and out.
And so I'm happy to say in "Whidbey" we've actually also taking a dramatic step forward and built in a user management
system to ASP .NET and Scott Guthrie will show us that later. And so we kind of get all that hassle down to these three lines of
code, which I think is pretty impressive.
I think the other thing besides the, "Hey, make a more productive IDE, make less code," is in addition to all of these
technologies, you know, help me bring together the technology into a complete solution. I hear that again and again. I hear
about the lifecycle, I hear about, "Hey, these snippets are great but I have to build complete applications."
So I thought it would be fun today to actually have as part of my demos an integrated demo scenario. So what we have is a
fictional company called Woodgrove Insurance and we've exposed a set of Web services. And what we're going to do today is
take advantage of Visual Basic .NET to build a claims processing application. This is the guy in the office who decides yes or
no, I'll pay the app or not.
We're going to use ASP .NET and Visual Studio "Whidbey" to actually build an end user application. This is the customer going
to Woodgrove Insurance, looking at his claim history and who his adjuster is and who is agent is and all that other good stuff.
And then we'll actually look at what it's like to be a guy in the field making a claim and you're out in the field, you have a little
device, you need to record data and send it back to the Woodgrove corporate headquarters.
54
So we'll have all of these scenarios working together and then we'll show how when it's all done we can actually not just deploy
the client software -- you'll see that in the demos -- but also deploy and manage the Web services themselves consistent with
IT policies.
So with that introduction I'd like to bring out Ari Bixhorn. Ari is going to show us Visual Studio "Whidbey" and we'll kind of do a
quick lap around. Welcome, Ari. (Applause.)
ARI BIXHORN: Hey, Eric. Good to see you.
Good morning, ladies and gentlemen. Are you ready to see "Whidbey?" (Cheers, applause.) All right, not too bad for pretty
early in the morning.
So Eric was talking about some of the productivity enhancements that we're introducing in "Whidbey." And we really are
aiming to take productivity to new heights, particularly for Visual Basic developers. So in this demo we'll see how VB
developers, who are the Woodgrove Insurance Corporation, take an existing version of that claims processing application,
update it using VB "Whidbey" and then redeploy it out to the Tablet PCs that it's running on.
Now, we'll start the demo with the application as it exists today. It's already running in Version 1 and it's been deployed using
Click Once, so we know that when we run it we'll always be getting the most updated version of the bits.
Now, for those of you who saw the "Avalon" demos yesterday, get ready to get blown away by some really, really nice UIs.
So let's start off this demo on our Tablet and let's launch this application. Gorgeous Flash screen, there it is. (Cheers,
whistles.) Yes, thank you, thank you.
ERIC RUDDER: And for those that kind of like the tilting by 10 degrees, that's kind of the VB 6 version. (Laughter.)
ARI BIXHORN: So as we can see, the application is -- well, it's a little lifeless. It needs a UI scrub. I don't know, it doesn't
take advantage of the Tablet PC capabilities and we need to pretty much overhaul this application.
So with that, let's switch over to our development machine and see how we can do this. So here we are inside of "Whidbey."
And we can see our application or our form as it exists today. The first thing I'm going to do is simply go ahead and close this
out and I'm also going to close that gorgeous Flash screen and exclude them from this project because we don't need them
anymore.
Now, let's make a little bit more room so that we can have as much space to code as possible. Now, remember the tool
window docking model that we introduced in VS .NET. Well, we've made that better in "Whidbey." So watch what happens as I
go ahead and click on my data source fields window and we're going to drag and drop that over into our solution explorer.
Watch what happens. We now get guides that tell us exactly where I'm going to be dragging and dropping that particular tool
window; pretty cool. (Applause.)
All right, now let's add some data. And I'll switch over to the new version of my claims form. We can see here it's looking a
little nicer. Now, remember all of that ADO .NET code that we can write today to wire up data adaptors and connections? Well,
if you want you can still do that or in "Whidbey" what we can do is simply click on a field, in this case it's a Web service, we
drag and drop it onto our form, boom, automatically generated data-bound UI. (Applause.) All right.
Now, what I'm going to do is format this data grid so it's not taking up quite as much space on the screen. Now, what happens
if we need to get some help within our application? Well, we have a help system today but it can always be improved, right?
We have a new help system in "Whidbey" called My Help and it integrates a better searching mechanism, it's got a great
hierarchical view of the data that we need access to and it also integrates community features.
So I'm going to go ahead and launch My Help and what we can do here is drill into our How Do I section. So I'll drill into
Windows forms, controls, and let's check out one of the new data controls. Let's check out grid view. And we get a list of
topics here. We've drilled down into this pretty quickly. We also get some really good filtering capabilities, either by language
or by technology.
Now, watch what happens when we go into this first topic here, just an overview of the grid view. It looks like a pretty
standard help topic, but what I'm going to do is scroll down and we'll see some community integration.
At the bottom of this help topic we can see the annotations in our help. Now, these annotations allow either Microsoft or the
customer to update information, post discussions, code samples and so on directly into the help topic. So we can see Microsoft
has posted some information about the data view being converted to a grid view, we can see SQL Big Man has posted some
information here, and we can really post anything we want here, so we're always getting updated help.
All right, let's go ahead and close out My Help and now let's tweak our UI a little bit. We talked a little bit about the
productivity features in the designer and what I'm going to do is click on a Smart Tag that we have here on our form. This
Smart Tag is a new feature that we have inside of the designer that will allow me to customize the look and feel of that UI
without writing any code. So in this case I'm going to change that data grid to a details form just with the click of a mouse.
55
So we've got our data-bound UI, we haven't written a single line of code. Now, I'm going to delete these last three
fields here. These actually represent binary data that we're pulling from our SQL Server database, ink data and picture data
about this particular claim.
Instead, I'm going to use the advanced data binding capabilities of "Whidbey" to wire these up to an ink picture control, so we'll
go into the advanced data binding tab, we'll pull the picture of the car accident that's represented in this claim, and then we'll
bind it to some ink data inside of SQL Server so that I can leave annotations on my form about the car accident.
ARI BIXHORN: We'll scroll down into the form, and we have another ink-enabled control here. This is the custom ink notes
control, and we'll wire that up for Tablet PC support as well. Close that out. And now we're ready to move on.
So, we get this rad data binding that's also very flexible. Now, what about printing, for any of you VB developers who have
ever tried to print using Visual Basic 6, or even VB.NET, you know what a joy it can be, right? A couple of you out there feel
my pain. All right. So, in "Whidbey," we make printing a lot easier. So, what I'm going to do is go into our code editor, and
I'm going to make use of the My Classes. My Classes in "Whidbey" allow me to go ahead and get access to commonly used
framework functionality very easily. So, I'm going to type With My and when I type a dot, I get a list of resources from our
Web Services to our Forms collection. In this case, I'm going to select computer, and from there I get resources related to the
computer, from the mouse to the registry. In this case, I'll select the printer selection, and from there the default printer.
Now, we can set the output type of this print to be a print preview, and with that I can do self-printing. Notice that the print
method takes an object, and it's overloaded with a bunch of different data types, so we can pretty much patch in anything that
we want to this print control. Now, instead of doing that, what we're going to do is drag and drop a couple of lines of code into
our code editor that will allow us to print out this frame.
Something else to point out, notice the yellow highlights on the left-hand margin of our IDE. These allow me to keep track of
where I've made changes in my code book before and after I've saved it. (Applause.)
All right. So back to the designer, we've wired it up for printing. Now, let's go ahead and add the ability to e-mail this form to
someone else in our organization, or maybe to the client themselves. I've got a submit button down at the bottom right hand
side of the form, and it's anchored to the bottom right. I'm going to create a copy of this, and then paste it back onto the form
so that we'll have a button that we can wire up for e-mails. I'll paste that onto the form, and now watch what happens as I
drag this button, and as we get closer to the original proximity of that submit button. As I drag it closer, that button is going to
get locked in using a snap line. Snap lines allow me to line up my controls on the designer very easily. (Applause.)
And we talked about Smart Tags a little bit, check out the Smart Tag that I've got on this button. It recognizes the fact that
this button is within close proximity of another button that's anchored to the bottom right of the form. So, it gives me the
option, without jumping back and forth between the properties window to set the anchor property. All right.
Now, speaking of jumping back and forth between the properties window, what if I want to edit some text on this button? I'm
going to enter a new mode called Edit Properties. And this is going to allow me to edit all of the properties of the controls on
my form without going back and forth to that properties window. So, I'll select View Edit Properties mode. It's going to bring
up a little tray at the bottom of my designer, and as we can see, I've got the names of all these controls directly accessible to
me, and easy to edit right on that form. So, how I can select the text, move back over, I'll type e-mail, and now we can exit
out of Edit Properties mode, and we're ready to wire up some code behind this button.
I'll double click on that button, and I'm going to dim up the new mail message. Now, watch what happens when I type up a
syntax error. The mail message as new mail massage. Not only do I get a squiggly, but I also get a nice little smart tag here
that allows you to auto-correct that functionality. (Applause.)
For the purposes of this demo, I'm going to show you a new feature in the code editor called Code Snippet. Rather than write
this code manually, we're delivering a bunch of code snippets as part of "Whidbey" that allow you to interact with files, to
register, essentially perform common tasks. So, in this case, we've got an e-mail snippet. I'll go ahead and enter that into my
editor. Now, check this out, this is actually more than just a code snippet. It's actually a template where I can fill in the
blanks, and have easier access to that code. Pretty cool, huh? (Applause.)
All right. Let's test out this application. We're almost ready to redeploy it to the tablet. Let's go ahead and debug our code
first. I'm going to go ahead and start the application. we should get an updated version of that pretty splash screen. And here
we are inside of our app. So, let's go ahead and test out that no code data binding. Bingo. Yes. This is --
ERIC RUDDER: This is why you want to be careful before you agree to beta test the Auto PC Nav Sys.
ARI BIXHORN: It looks like a three-point turn that's gone horribly awry here in the alley. So, we've got our form, we've got
it bound to the picture. Let's test out our print functionality. So, I'll click print preview, and we hit a run-time exception.
Check this out, we've got a run-time exception helper. This provides information about the exception, and also some tips that
will help you work through it. I can see here that I've made a mistake, and I've call "incident.date" "incident.dat". Wouldn't it
be great if I could just edit this code inside of the debugger? Not have to restart it, and simply continue? Yes. Edit and
continue. Yes, indeed, back in Visual Basic. (Applause.)
56
All right. So, we've thoroughly tested this application.
ERIC RUDDER: We ran it.
ARI BIXHORN: We ran it, yes. Now, let's go ahead and redeploy it to that tablet. To do this, I'm going to invoke the Click
Once Deployment Wizard. And so what I will do is, I'll right click on my project, select "publish project" and this is going to
invoke the wizard. This is going to allow me to deploy this application to a Web Server which can then be downloaded
automatically on to that tablet PC and run seamlessly. So, we can select the location. I can specify whether I want the app to
be available both online and offline, or just online. In this case, we'll go ahead and make sure that it's online and offline. And
now, we'll click finish.
With that, Visual Studio should invoke Internet Explorer, and give us a test page where we can test the deployment of this
application. But, instead, let's switch back to our tablet PC. All right. So, we've still got Version 1 of the application running on
the tablet. Let's go ahead and close this down. Now, when I click on the icon this time, we're going to go up and check out the
latest version of those bits, automatically download them to my tablet PC, and run the updated version of the application. All
right. (Applause.)
So, we can go ahead and load up our data. I can make some annotations here, nice one, OK. We can scroll around in our
data.
ERIC RUDDER: This one is actually the boat's fault.
ARI BIXHORN: The thing that gets me about this is, look at the look, the expression on the client's face. It's like this is an
everyday thing. All right, we ran into a bug again. Now, the thing that I'm not quite sure about here is, how did the client get
out of the car without plunging into the water. She's dry. This looks suspicious to me, folks. All right.
So, we've seen a lot of new features in VB "Whidbey" today. What are the main things we want to take away? Well, whether
we're talking about rad data access, whether we're talking about the new designer features, the new code editor features, or
edit and continue, we're going to take VB developer productivity to new heights in Whidbey, and in VB "Whidbey," you're going
to get much more productivity whether you're developing, debugging, or deploying applications.
Thank you.
Thanks, Eric. (Applause.)
ERIC RUDDER: Well, we may not be able to help you drive, but I think we can help you write some code.
So, you saw the example of the Web services talking to a smart client there, and really leveraging the advantages that these
things have. The ability to run offline, to be able to support tablet, we could add speech, we could add lots of cool features.
But sometimes we really need to take advantage of Web services and provide reach in different ways, and we feel it will be
great for Web development as well, and we've made some fundamental changes there that I think are worth spending a minute
on.
The first change is that with "Whidbey" you can open any Web from any place. So, while the FrontPage server extensions are
still fully supported, they're not required. You can directly open an FTP site, you can open a file system directly, it's
synchronized.
We've improved page design quite a bit with a notion of master pages, which allow you to do visual inheritance. I think that's
going to be quite sexy. We do a much better job with HTML source preservation, always a touchy topic. We can generate
SHTML markup for those that want SHTML compliance. We've added some fantastic validation features for Section 508
compliance. We have an accessibility feature. You can choose your browser target dynamically, and do real-time validation
against the browser target. We have intelli-sense for inline code in the browser, which is super nice, in CSS and the Web config
file.
We'll up the performance of our Web server quite a bit. We'll allow for database caching, and cache invalidation, kind of in an
open architecture to let you to use multiple drivers. Like everything else in Whidbey, there's full support for 64-bit, and we've
57
done a great job, improving the administration, and by synchronizing with MMC providing a configuration API that you can take
advantage from your own management systems, scripts, or however you want to do health monitoring for IIS, fully, as well.
So here actually I think, again, a demo is more powerful than the features. So I'm going to invite Scott Guthrie to come out
and show us a little bit about how "Whidbey" works for Web development.
Good morning, Scott.
(Applause.)
SCOTT GUTHRIE: Thanks, Eric.
So what I'm going to show over the next few minutes is how the combination of ASP.net, and Visual Studio Whidbey enable
Web applications to be built easier and faster than ever before. Specifically, I'm going to go ahead and build the customer
facing Internet site for Woodrow Insurance, one that enables logged in clients to access their information, as well as create a
personalized view on top of that data.
So to begin with I'm going to spend a little bit of time working on the overall UI and layout of my site. Now, as you know, one
of the challenges for Web applications today is coming up with a design that you can apply cleanly and consistently throughout
your pages. Doing that today, with today's tools and technologies is pretty hard, with "Whidbey" we're making it easy.
Specifically, as Eric mentioned, we have a new feature we call master pages, that we're adding both runtime and design time
support for. Master pages is an ASP.NET page that can have any HTML or server control content on it, as well as some regions
that can be replaceable or filled in by other pages within the site, and that enables you to have a consistent look and feel across
the site, and have everything sort of be based on top of that master template.
For example, what I'm going to go ahead and do here is open up a Woodrow master page in our Visual Studio designer. Right
now there's just some HTML on here, we have a header, kind of a navigation bar on the site, and a little bit of a footer . What I
want to go ahead and do is have this region right here in the center be what all the pages on my site kind of fill in, and keep
that outer chrome around them. So to do that I can go ahead and add a new control we shipped in "Whidbey" called a content
placeholder control to the page. Hit C, and now when I build any new pages on my site I can choose to have that page be built
on top of this master template, hit okay.
What Visual Studio will then go ahead and do, when I edit this page it will automatically import that master template around
the top and around the side, it's going to gray it out, because I can't edit it, because that's only defined on the master. And
instead I can now go ahead and add content directly to this page.
ERIC RUDDER: This is a great feature for when the VP decides at the last minute he doesn't like the look of the demo.
SCOTT GUTHRIE: Which Eric has been known to do. So basically you can see I have a unified view in the designer at the
source level, all I'm saving in the source file is the actual content for that home page specifically. Everything else is stored in
the master file, which means if Eric does decide to change the look and feel on the fly, which hopefully he won't right now,
basically if he does decide to change it, all the pages on the site built off that master file will automatically update and take
effect at run time.
(Applause.)
As you can see at runtime ASP.NET will automatically merge the two together, and send back a single HTML page to the
browser.
Now, we're building an insurance site, and so we probably don't want to have "Welcome to the PDC" be the main text on our
home page. Obviously, instead we probably want to have some insurance information, insurance rates, market data, claim
history information, et cetera. So to help with that, I've actually built a few existing Woodrow controls that are going to provide
some default information that we can take advantage of on our page. What I want to go ahead and do is lay out that
information in kind of a nice, clean, modular fashion, and to help with that I can take advantage of some new controls that
we're shipping in the "Whidbey" time frame called the Web Part Zone Controls.
What a zone control does, it serves as a sort of a container for all the other controls on the page. So, for example, you can see
this Web Part Zone here, and there's a news and a rate control here. What a zone control does then is it provides kind of this
nice modular look and feel for the controls in the page. You can see it in design time, if I go back and hit refresh in our
browser, it also shows up at runtime.
So it promotes a consistent toolbar, the minimize and the close button, it kind of lets me lay out that information in a nice clean
way on the page. A little bit later on I'm also going to be showing how you can take advantage of some cool personalization
features as far as these controls, to really kind of extend and customize the site.
Now, right now all the information on this homepage is kind of fixed. So you'll notice we have breaking news, market data, et
cetera. Nothing is customized for the incoming client actually visiting the site. And the reason for that is right now this
application, we don't actually know who's visiting a site. There's no authentication mechanism, there's no way to know who is
logged into the system. So that's what we're going to go ahead and add now.
58
How many people build sort of their own membership system with an Internet-based Web site today. A number of hands. It
involves writing, as Eric showed earlier, probably about at least 1,000 lines of code, to securely store your user credential,
possibly implement rule management, security, et cetera. The nice thing with "Whidbey" is all that functionality is built in.
There's now a membership and rule management system that will securely store your credentials, manage all those user
accounts for you, and you can write very little code in order to integrate it to your site. To show that I'm just going to go
ahead and add a log in page, I'm going to base it again off this master template, so it will have a consistent look and feel
across our site. Now, within this log in page what I want to do is prompt the user for their user name and password, and
somehow authenticate them into the system.
Now, as Eric showed earlier, I could write one line of code, and build my own UI that calls that in order to grab the user name
and password and log them in, or I can actually take advantage of any set of what we call log in controls that we're shipping
with ASP.NET "Whidbey", and one of them is called the ASP.NET Log-In Control. And what this does is basically do all that
work for me. The UI control that provides the log in screen, I can richly customize the look and feel, and under the covers it
will then automatically talk to the membership system for me, and if the user name and passwords match it will log the
incoming user into the system.
(Applause.)
So we have a log in page now on our site. Let's go ahead and integrate it into our master page so people can actually find it.
And to do that I'm going to go ahead and add one more log in control to the page, this one is called log in status. And what
this will do is it will automatically toggle either log in or log out, depending on if the user visiting the site is logged in, or if
they're actually not currently authenticated. And it will point the person at the log in page if necessary.
Let's go ahead and refresh in our browser. You'll notice we now have a log in link, I'm not currently authenticated onto the
system. I click this link, enter in my e-mail account, it's going to go ahead, log me in automatically to the membership system,
identify me on the site. You'll notice we now have a little welcome Scott message on the top left hand corner. And if I wanted
to click that link again it would automatically sign me out. So now programmatically from within the site I know exactly who is
visiting on a particular page request, and I can start to customize the experience based on that. So let's go ahead and do that.
Right now the information that's being displayed on this home page, it's kind of fixed. It's breaking news, market data, there
isn't anything customized for the incoming user. We now know who the user is, though, and so we can go ahead and add it,
add some content that is based on that user. And so specifically what I'm going to go out and do is I'm going to add a new
control to the page, called claim history. So what I want to do from this control is access the back-end Web service, using the
logged in identify of the user. Get some claims history information from them, and then display it on the page. So to do that
I'm going to take advantage of a new control we have called a grid view, and then I'm going to use Visual Studio to walk
through binding this control to either a Web service, or a back end object. I'm going to call this service the insurance service.
You know, Visual Studio automatically reflects what methods are available on top of that object that I want to bind against, so
I'm going to say I'm going to bind to the look up claims.
The other nice thing about our controls in "Whidbey" is you no longer need to handle customer code in order to enable paging
and sorting, all that is now built into the control. So all I have to do is say, allow paging, allow sorting, and now that Web
service data that's returned is automatically sorted and pageable within my grid.
The only code I do need to write is one line of code, so I'll write it right now. I'm just going to go ahead and pass to that Web
service the identity of the incoming user, we're just going to pass a customer ID argument here, and I'll pull out the value of
the log in user name.
Last but not least, we're just going to go ahead and format this grid to be a little bit more attractive, we'll make it 100 percent
wide, so it will fill up that whole column. Now I have a reusable control that I can add to my home page. To do that I'm going
to go back to the page, go ahead and enable some editing, and I'm just going to drag and drop the claim history control onto a
page, come back here, hit refresh, and you'll seen now my claims history control shows up within my site. It has the same nice
title bar that the rest of the controls have, I could obviously customize the exact name of it. And you'll notice that I have
automatic sorting and paging support across my data, I didn't have to write any code to do it.
There's one thing missing from this site right now, and that is the ability for the end user to richly customize what the layout is,
personalize what the look, or the overall structure of the site. Instead right now you'll notice the locations of all the controls
are basically hard coded in by the page developer. What I'd ideally like to do is be able to have the logged in user, who is a
client of mine, be able to say, gosh, I really want to move this site around, and actually structure it for how I want to see it as a
user, not just how the developer thought it made the most sense.
Doing that type of customization or personalization today typically requires several thousand lines of code, with "Whidbey" it
becomes really easy. All I need to do as a page developer is provide some way for an end user to switch the ASP.NET page into
what we call personalization mode, and then ASP.NET will basically do the rest. It enables controls to be dynamically re-laid
out, and automatically save those settings for him.
So I'm going to go ahead and enable this, add a link button to my site, I'm going to go ahead and call this link button
personalize. As a developer I'm going to double click to handle the appropriate click events of this link button, and write one
line of code, which is going to switch this page into what we call display mode, or editable mode. So this is what I write as the
developer. Go ahead and save, come back to our Web site.
59
Now, you'll notice I'm logged in as Scott onto the site, there's now a personalize link that's showing up here. If as an end user
running in a standard browser I click this, you'll notice that the page is going to shift into a slightly different mode than we had
before, there's now, for example, a left column and right column showing. And as an end user in the browser, I can now go
ahead and drag and drop any of the controls on the page, customize the layout of it, so let's move our claims history down a
little bit.
(Applause.)
I can go ahead and remove any controls I want from the page, so go into our little catalogue gallery up here, I can also link off
the other controls that I expose on my site, so that if they want to add them back in it's pretty easy to do so. And when the
end user clicks close on the browser, what will happen is ASP.NET will figure out what are the changes that were made, how is
the page personalized, and automatically write those layout changes to the new ASP.NET personalization store that ships as
part of "Whidbey." Now if I were to log out of this browser, go to a completely different machine and log back in, I'd see the
exact same settings personalized for me that I customized right here.
(Applause.)
So in summary, in the last couple of minutes what we've built, we've built a site that now has a clean, consistent look and feel
using master pages, enables great developer and designer cooperation. We've added a secure authentication method to our
site, so that now our customers can log in. We've gone ahead and connected to a back-end Web service to get claim history
information. We're binding that data directly to the page, and now I can go ahead and personalize the site in a rich way, and
really build a customer experience that rocks. And you saw, it didn't take much code at all, it didn't take much time. And it
really enables your applications to go to the next level.
ERIC RUDDER: Thanks, Scott.
SCOTT GUTHRIE: Thanks.
(Applause.)
ERIC RUDDER: I want you to remember when you're trying "Whidbey" in your office, and some day it saves you thousands of
lines of code, I want you to give a little bit more applause, even if you're in your office we'll still hear it. It's kind of like
Tinkerbell and if you believe in peanut butter. So now we have a smart client, which you saw developed with VB.NET, we saw
Scott take us through "Whidbey" on the Web. And if you remember the third part was really taking advantage of devices,
connecting back to the Web services.
And we're doing a lot of work with our Windows Mobility group making sure we've got a great support story for devices, and our
Web service support. We're going to take all of our managed code APIs for messaging, telephony, multimedia, make sure
they're available on the Compact Framework. We've enhanced the Compact Framework to support the new devices, and make
sure we can support things like cameras, or new features, the new resolutions of the devices. You can build and deploy
applications for Windows mobile devices today. And you can use the same toolset, Visual Studio, for Pocket PC, or Pocket PC
Phone Edition, or Smart phones, or Tablet PCs.
As a matter of fact, everyone who attends here will actually get in the mail the Tablet PC SDK update, which not only allows
you to add basic inking support to your application by dragging the RIO control, the rich ink object, but it also allows you as the
developer to kind of conspire with the Tablet recognition system. So you can actually give the Tablet information, called
context tagging, about your application. And you know in your application, hey, this feels -- it's a number, it's a Social Security
ID, or it's a name, so you'll actually get improved recognition. The more information you give the Tablet about what data to
expect the better job it can do for you. So we give that control back to the developer, and it's something we're very excited
about.
I think we kind of have to decide which device we're going to support for our demo on Windows Mobile. And there's actually a
huge choice of Windows-powered devices now. So I'd actually like to invite Kevin Lisota, our a.k.a. Batman, to show us some
of the Windows Mobile devices.
(Applause.)
How are you?
KEVIN LISOTA: Thanks, Eric.
So as you can see I've got a utility belt here loaded up with the latest Windows Mobile 2003 devices.
ERIC RUDDER: That it awesome, I've heard of utility computing, but utility belt computing sounds much more exciting.
KEVIN LISOTA: Actually all of the devices here that I'm going to show you today actually do have the .NET Compact
Framework in ROM, so that you can target the devices using VisualStudio.NET and the Compact Framework. Actually all the
devices that I have here have been either released or launched in just the last couple of weeks. Let's take a look at the great
60
work that some of our hardware partners are doing. If I fumble around with these. Keep in mind that these devices are not
necessarily designed for these big, heavy gloves.
So the first device I've got here, this is from our friends at Toshiba, this is actually the E-800 device. It's got integrated WIFI
capabilities, but the interesting thing about this device is it actually is the first Pocket PC device to have VGA resolution.
ERIC RUDDER: That's kind of incredible, my first PC didn't have VGA resolution, let alone color.
Microsoft Expands Mobile Opportunities for Windows Developers
New Tools and Enhanced Services for Windows Mobile Software Platform
Facilitate Wireless Application Innovation
Los Angeles -- Oct. 28, 2003 -- Today at the 10th Microsoft® Professional Developers Conference, Microsoft Corp.'s Mobile
Devices Division unveiled plans to deliver a new set of tools, technologies and service offerings, including support for
Microsoft Visual Studio® "Whidbey," Microsoft .NET Compact Framework "Whidbey" and managed-code APIs, as well as
expanded support for various screen resolutions. These updates will enable Windows® desktop developers to embrace new
opportunities in the growing wireless software industry and apply their existing skills to develop wireless applications for the
Windows Mobile (TM) software platform. In addition, Microsoft announced an upgrade to the Windows Mobile Smartphone
Device Developer Kit for developing applications for Windows Mobile 2003 software for Smartphones. The company also
revealed enhancements to its Mobile2Market program, which facilitates accelerated delivery of mobile applications via
distribution channels including retailers, e-tailers and mobile operators.
"Our Windows Mobile platform has experienced very positive growth over the past two years, in terms of unit volume and a
broader range of Windows Mobile-based products available to customers. There has never been a more attractive addressable
opportunity for developers," said Juha Christensen, corporate vice president of Mobile Devices Division at Microsoft. "We've
built Windows Mobile software with the future in mind, to evolve as the market expands, enabling desktop and mobile
developers to take advantage of the volume opportunity for smart devices and deliver innovative applications and services to
market."
The recent U.S. availability of the Motorola MPx200 with Windows Mobile software and the European launch of the Orange
SPV E200 with Windows Mobile software expands the market opportunity for professional developers to easily apply their
existing skills to Smartphone application development. More than 11,000 applications have been registered by Microsoft
Mobile Solution Partners, and more than 380,000 professional Windows Mobile developers worldwide are poised to take
advantage of this new and rapidly growing market.
Future Developer Investments
Corresponding with the innovation by device manufacturers, the Windows Mobile development platform will expand to support
screen resolutions including square screen, portrait and landscape, VGA, and QVGA. The continued focus on providing a
standard software platform coupled with various device form factors will enhance the application development environment
and create more choice for end users and mobile operators.
In line with Microsoft's overall investment in the upcoming version of Visual Studio, code-named "Whidbey," Windows Mobile
developers will benefit from a familiar environment and the highest developer productivity. More specifically, Visual Studio
"Whidbey" will be the first development tool for Windows Mobile developers that unifies the development environment to
include the native Microsoft Visual C++® development system, managed Microsoft Visual Basic® .NET and Microsoft Visual
C#® development tool, and Web ASP.NET Mobile controls -- all in a single integrated development environment.
The success of the Microsoft .NET Compact Framework should accelerate in the future with major enhancements planned to
the core run-time environment and the base class libraries. .NET Compact Framework "Whidbey" will include execution
environment enhancements to improve overall performance, as well as better native interoperability with COM interop
functionality and a richer set of base class libraries.
The Windows Mobile development platform will continue to increase its overall investment in .NET by further building out the
platform with a managed code API set including support for the following: messaging, telephony, multimedia and gaming,
connectivity, and personal information management (PIM).
Taken together, these investments in the software platform, development tools and API set create a compelling offering for
Windows and mobile developers that are ready to take advantage of the high-growth wireless market.
Availability of Smartphone Device Developer Kit Upgrade
To meet the demand for native support of Web services in Windows Mobile software for Smartphones via the .NET Compact
Framework and Visual Studio .NET, Microsoft is providing an upgrade to the Smartphone Device Developer Kit. This kit offers
developers everything needed to build, test and deploy Window Mobile-based Smartphone applications, including a
precommercial Windows Mobile-based Smartphone with 2003 software and accessories, a null SIM card, and development
tools and resources. Information on how to receive the Windows Mobile Smartphone Device Developer Kit and pricing can be
found at http://www.microsoft.com/windowsmobile/developer/.
Mobile2Market Enhancements
Microsoft's Mobile2Market is a comprehensive program designed to empower developers and independent software vendors
(ISVs) to generate incremental revenues through application distribution channels, such as mobile operators, while extending
customer reach and reducing time to market. The Mobile2Market process is made up of steps including application logo
certification and inclusion in the Mobile2Market Application Catalog. To date, there are more than 650 certified Mobile2Market
applications in the Mobile2Market Application Catalog.
61
In an effort to help developers, ISVs and application distribution channels derive even more value from this program, the
following enhancements will be made:

Process enhancements. Microsoft is working with its Mobile2Market logo certification and code-signing partners to
drastically enhance the process of logo certification and market readiness of applications via code signing.

Catalog enhancements. The Mobile2Market Application Catalog is being enhanced to provide visitors with a unified
view into where and how to easily purchase mobile applications (http://www.microsoft.com/windowsmobile/catalog/).

Extranet enhancements for Mobile2Market partners. Application distribution channels such as e-tailers, retailers
and mobile operators will have increased functionality with their secure access privileges to reach the rapidly
expanding number of ISVs and applications that are in the catalog.
More information about the Mobile2Market program can be found at
http://www.microsoft.com/windowsmobile/mobile2market/.
Founded in 1975, Microsoft (Nasdaq "MSFT") is the worldwide leader in software, services and Internet technologies for
personal and business computing. The company offers a wide range of products and services designed to empower people
through great software -- any time, any place and on any device.
Microsoft, Visual Studio, Windows, Windows Mobile, Visual C++, Visual Basic and Visual C# are either registered trademarks
or trademarks of Microsoft Corp. in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at
http://www.microsoft.com/presspass/ on Microsoft's corporate information pages. Web links, telephone numbers and titles
were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may
contact Microsoft's Rapid Response Team or other appropriate contacts listed at
http://www.microsoft.com/presspass/contactpr.asp.
Developer Productivity Takes Center Stage in Future Versions of Microsoft
Visual Studio and SQL Server
Microsoft Introduces Visual Studio "Whidbey" and SQL Server "Yukon" Features
for the Next Wave of Connected, Information-Driven Applications
LOS ANGELES -- Oct. 28, 2003 -- Kicking off the second day of the Microsoft® Professional Developers Conference (PDC)
2003, Microsoft Corp. gave PDC attendees prerelease versions of Visual Studio®, code-named "Whidbey," and SQL Server™,
code-named "Yukon," the next versions of Microsoft's development tools and database. These releases center on continued
advancements in developer productivity, making Web services easier and more powerful, and simplifying data access and
management by taking advantage of the latest in Extensible Markup Language (XML) and managed code technologies.
Microsoft expects beta versions of these products to be widely available to MSDN® Universal subscribers in 2004.
"We are focused on making information easier to find, organize and act on, and at the same time on making developers as
productive as possible building connected and information-driven applications," said Eric Rudder, senior vice president of
Servers and Tools at Microsoft. "With these new products on the horizon, we are enabling customers to succeed today while
getting ready for technology that will help enable new opportunities in the long term."
"Whidbey": Advancing Developer Productivity
Microsoft demonstrated the productivity enhancements in Visual Studio "Whidbey" and the Microsoft .NET Framework
"Whidbey" that enable developers and architects to more easily design and build applications including simple Web and client
applications, mobile applications, and global-scale, service-oriented applications. Key innovations and enhancements in
"Whidbey" include the following:

Web services designer. Visual Studio "Whidbey" includes a set of tools (code-named "Whitehorse") that enables
architects and developers to easily design service-oriented applications and operations infrastructure simultaneously.
"Whitehorse" uses a drag-and-drop design surface to connect XML Web services, and then validates the resulting
applications against the deployment environment using the System Definition Model (SDM), saving both time and
money.

Programming language enhancements. "Whidbey" continues Microsoft's commitment to developer productivity,
introducing a set of language features, ranging from "edit-and-continue" - a core rapid-application development
technology - to simplified abstractions for many common tasks, and the introduction of generics in the Common
Language Runtime (CLR). In addition, development of data-centric applications in Visual Basic® .NET is simplified
with a new drag-and-drop design-time experience to produce highly scalable information-driven applications.

Enhancements to ASP.NET. "Whidbey" introduces services and controls to reduce code in common scenarios by up
to 70 percent, and new design tools that enable developers to deliver a personalized browsing experience for end
users. ASP.NET "Whidbey" will also deliver support for themes and master pages, making it easy to create and
maintain Web sites that have a consistent look and feel, and new management and configuration capabilities that
simplify the management and deployment of Web applications.

Improvements to application deployment and operations. The "Whidbey" version of the .NET Framework
also boasts support for 64-bit processors to enable scaling to the largest processors requiring little work on the part
of the developer, and a new deployment technology, code-named "ClickOnce," that enables applications to be
installed, updated and even rolled back to previous versions more easily.
62
Demonstrating the industry's anticipation and enthusiasm for the upcoming tools and technologies, more than 40 industry
partners today announced their plans to build development products that integrate with and support Visual Studio and the
.NET Framework "Whidbey," including AmberPoint Inc., Compuware Corp., Intel, LogicLibrary Inc. and Merant and other
industry-leading companies. Just three months after expanding the Visual Studio Industry Partner (VSIP) program to three
levels of membership, the ecosystem has experienced tremendous growth, from 175 partners, delivering more than 300
products, and an additional 7,500 new partners that have downloaded the VSIP Software Development Kit and joined the
Affiliate level of the program.
SQL Server "Yukon": Significantly Enhanced Database Development Experience
Microsoft detailed features available with SQL Server "Yukon" (a member of the Windows Server System™), which will
provide developers with integrated tools for improved database development. Building on the technology provided in SQL
Server 2000, SQL Server "Yukon" will offer rich XML support and deeper integration with .NET Framework technologies and
Microsoft development tools. Through the enhancements outlined below, SQL Server "Yukon" will significantly increase
developer productivity and flexibility while reducing complexity:

Expanded language support. The most notable developer advancement for SQL Server "Yukon" is that the
Common Language Runtime will be hosted in the database engine. This will enable developers to choose from a
variety of familiar languages including Transact-SQL, Visual Basic .NET and Visual C#® .NET to develop stored
procedures in databases and user-defined types.

XML and Web services. SQL Server "Yukon" will also include substantial advancements for XML and Web services
such as support for XQuery and XML, including a native XML datatype. These technologies will enable organizations to
more easily connect internal and external systems. In addition, by supporting both relational and XML data natively,
enterprises will be able to store, manage and analyze data in the format that best suits their needs. SQL Server
"Yukon" will also include support for existing and emerging open standards such as HTTP, XML, Simple Object Access
Protocol (SOAP), XQuery and XML Schema Definition (XSD).

Improved tools. Microsoft has made significant investments to enhance tools in SQL Server "Yukon" that will enable
developers to utilize one development tool for Transact-SQL, XML, Multidimensional Expression (MDX) and XML for
Analysis (XML/A). By integrating with Visual Studio, SQL Server "Yukon" will enable more efficient development and
debugging of line-of-business and business intelligence applications.
With nearly 2,000 customers and partners participating in the early beta program, "Yukon" promises to not only deliver on
the promise of making developers and customers more productive, it will also be the most broadly tested version of SQL
Server released to date.
Advances in Mobile Application Development
Microsoft also announced three milestones for developers targeting the industry's broadest mobile application development
platform. They include updates to the Tablet PC SDK, the next version of the Windows Mobile Smartphone Device Developer
Kit and updates to Microsoft's Mobile2Market program. The alpha release of Tablet PC SDK 1.7 adds support for inking on the
Web, enhanced contextual support for handwriting recognition and a real-time stylus. The new Windows Mobile Smartphone
Device Developer Kit includes the latest version of Windows Mobile™ for Smartphone 2003 and features tight integration with
Visual Studio .NET. Windows Mobile for Smartphone 2003 and Pocket PC 2003 feature the .NET Compact Framework in readonly memory (ROM). Enhancements to the Mobile2Market program bring developers three steps closer to their customers by
lowering the cost of application signing, broadening the potential base of customers and improving the overall catalog
experience.
About the Professional Developers Conference
The Microsoft Professional Developers Conference (PDC) is Microsoft's premier developer event. The PDC brings together the
world's top developers to get an early look at Microsoft software innovations, to interact with the technology leaders within
Microsoft and the broad Microsoft development community, and to discover the opportunity presented by targeting the
Microsoft platform.
About Microsoft
Founded in 1975, Microsoft (Nasdaq "MSFT") is the worldwide leader in software, services and Internet technologies for
personal and business computing. The company offers a wide range of products and services designed to empower people
through great software - any time, any place and on any device.
Microsoft, Visual Studio, MSDN, Visual Basic, Windows Server System, Visual C# and Windows Mobile are either registered
trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at
http://www.microsoft.com/presspass/ on Microsoft's corporate information pages. Web links, telephone numbers and titles
were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may
contact Microsoft's Rapid Response Team or other appropriate contacts listed at
http://www.microsoft.com/presspass/contactpr.asp.
Developers Talk to Developers about New Windows Innovations
LOS ANGELES, Oct. 27, 2003 - This week at the Microsoft Professional Developers Conference (PDC), Microsoft will debut
Windows "Longhorn," the code name for the next generation of the Windows platform, along with such additional key, nextgeneration Microsoft platform technologies as Visual Studio "Whidbey" and SQL Server "Yukon." The PDC is an important first
step in the journey to delivering the next version of the Windows platform and enabling the next wave of computing. Building
on developer excitement for today's platform capabilities and the benefits of managed code and the .NET Framework, Microsoft
is enabling developers to build great applications that connect people, groups and organizations and make mountains of digital
information meaningful and actionable.
63
To get a fuller sense of what the development community can expect from the next version of the
Windows platform, PressPass spoke with three of their peers at Microsoft: Chris Anderson, Don
Box, and Quentin Clark, who are all helping architect Windows "Longhorn."
PressPass: How would you describe the driving forces behind the next generation of
Windows?
Clark: Windows "Longhorn" largely represents Microsoft's effort to provide a new spectrum of
possibilities and opportunities for developers. Much of what we are doing is based directly on what
software developers, our partners, and our customers have told us they want from the platform.
Windows "Longhorn" is about opening up innovation and getting the whole industry excited about
the new kinds of applications they can build.
Chris Anderson
Box: We've found that the vast majority of developers need to build programs that talk to other
programs. That's a vitally important scenario in an increasingly connected world, and I think there's
lots of innovation within "Longhorn" that will enable developers to integrate code from a variety of
sources. That's going to make it much easier for developers, both to integrate applications with the
Windows platform as well as solve a lot of common business problems - many of which depend on
programs that don't run on Windows.
Anderson: With .NET, we took the first step toward elevating the whole platform, and Longhorn is
all about continuing that journey based on developer, partner and customer demand. One of the
things we're doing in the evolution of the Microsoft platform and "Longhorn" specifically is applying
the concept of managed systems in more than just code. We're going to have a notion of managed
applications, which means that, by redefining what it means to be an application, the system can
provide more services and value in the ecosystem around those applications. It's all linked together
to help developers focus on solving the problems they have rather than being preoccupied with the
infrastructure they need to build around the problems.
Don Box
PressPass: How is each of you involved with the platform developments Microsoft is
talking about at PDC?
Clark: I work on "WinFS," the code name for a fundamental new storage capability. As part of this
managed-code platform, it will enable a whole new set of storage-based applications and capabilities
that allow users to easily find and relate things and act on data that they have in their systems.
With today's storage systems, users have to remember things like, "What is the path to the
PowerPoint slides I need?" With "WinFS," users think about their data more naturally, and can get
questions answered like, "Where are the slides I presented last week to this customer? What's it
related to? Who worked on this? Have I received any feedback?" Along with "WinFS," the emergence
of XML and Web services has made information easier to describe and organize, and enabled a
standardized way to store, process and share it.
Quentin Clark Click
image for high-res
version.
Box: In "Indigo," which is what I work on, the main concept we deal with is that a single program by itself is nowhere near as
interesting or useful as several programs that can work together in concert. We've spent a lot of energy in the past five years
working with the industry to develop interoperable protocols based on Web services, XML and service orientation. What we're
doing with "Indigo" is giving people a simple, unified way to take advantage of virtually any program that's out there and to
incorporate it into their world in an easy, reliable and secure way. In addition to making sure we have excellent
implementation, we're working with industry partners to ensure we're all heading in the same direction so we can all provide
the system interoperability that people want. The end result is connected systems that wire all the individual pieces together.
Anderson: "WinFS" gets to store your data, while "Indigo" lets you talk to other machines, applications, systems and devices.
Everything you see and feel on the PC goes through the presentation layer, which we've code-named "Avalon," and which is my
area. You could say "Avalon" is the Common Language Runtime's face in the next version of Windows. Developers want the
ability to deliver rich text and great user experiences, and they want to blend those capabilities seamlessly with things like
animation or video. The next generation of the Windows platform will support all of this much more simply. With "Avalon,"
we're exploring the types of experiences developers want to enable, and then looking back at the technology, we have to let
them accomplish those tasks. By integrating two-dimensional and three-dimensional graphics, documents, video, audio, and
animation, as well as tools to distribute and protect digital content, developers can more easily build software that is visually
remarkable and offers a breakthrough experience to customers.
PressPass: What's the significance of PDC 2003?
Clark: We're walking into PDC this year with an incredibly integrated, broad platform offering that addresses many of the key
needs of our customers and industry partners. We have a long way to go until we ship "Longhorn," certainly. But it's very clear
to the three of us in this room what our roles are and how what we're doing all fits together. And it will also be clear to
everyone that there is a great path forward that starts today with managed code and the .NET Framework. Developers'
investments in skills, code and tools will carry them into the future.
Anderson: I think this PDC is so amazing. I worked on PDC 2000, when we announced .NET, and I believe that this year's
event is going to absolutely eclipse that one. Even with all the enthusiasm that's been building up before the PDC, people don't
really understand what we're going to show them this week. PDC will showcase some incredible innovations, from "Whidbey"
[the next version of the Microsoft Visual Studio .NET developer tool system] to "Yukon" [the next version of the Microsoft SQL
Server database management and analysis system] to Windows "Longhorn." It's exciting because we're building on the .NET
vision that generated so much buzz three years ago; we're setting the stage for people to use those tools and move the .NET
Framework forward.
64
Box: We have spent a lot of time thinking about developer continuity. The "Indigo" team actually manages several technologies
that are already out in the field, such as COM, COM+, MSMQ and DTC, all of which were developed in the late '80s and early
'90s. At this year's PDC, we will let people know that we won't leave them behind when it comes to those technologies. People's
investments in those technologies are going to move forward, as will those folks who recently invested in .NET. It's very
exciting to be able to share with developers the birthing of the whole platform, including an operating system. It's all pretty
profound.
PressPass: What kinds of reactions are you hearing from developers who have had the chance to experience some
of the code that is being passed out at PDC?
Anderson: Developers were expecting us to do some innovations, but they are just amazed. We've got something like 10
gigabytes of new stuff for developers at the PDC. People have been very surprised with what we've been willing to undertake in
the next version of Windows. We're advancing our user interface, our GDI [graphics device interface], huge portions of our
networking stack, and our file system. We're moving over the majority of our code from the kernel memory manager to the
Common Language Runtime.
Clark: What I'm hearing is a lot of gears turning. People tell me they can see how "WinFS" will revolutionize how people
manage data on the PC. People are talking about innovations in their applications that they previously didn't think were even
possible. That helps validate our efforts and reassures us we're on the right path.
PressPass: How does the next version of Windows build on the work that developers are already doing today?
Box: Developers who have embraced .NET will see their investments bear fruit. Their experience with writing in C#, Visual
Basic .NET, or any other managed language will be a very useful skill in the "Longhorn" world. Understanding how to build XML
and Web services, which we obviously put a lot of effort into in the first round of developing .NET technologies, will also serve
developers well in the next generation of Windows.
Anderson: I often say that we spent a lot of time making sure we could leverage the developer, but maybe not always the
code. There are cases where the developer will write new code to take advantage of the new innovations. But we wanted to
make integration to the platform as easy as possible. For instance, you can actually access a good portion of "WinFS" with the
standard Win32 file library. If you want the richer functionality, then you can exploit the new API in your code.
PressPass: How is Microsoft addressing the issue of security in the "Longhorn" development process?
Anderson: Security is a supreme priority for all of the design work in Windows "Longhorn." In "Avalon," we've spent a lot of
time thinking about how we're going to have these rich, interactive applications that work across the network and make them
run securely. So we're building on all the code access security work that happened in the .NET Framework. That enables us to
have applications that are running in a less-privileged environment. So even if there is some potential to exploit security
vulnerabilities, we're making it less likely that such vulnerabilities can be accessed.
Clark: Security is being designed into "WinFS" from the ground up. The design has the full bearing of the Windows security
model and the CLR security infrastructure behind it. For the things that are stored in "WinFS," we have a security model that
allows full authentication and authorization control.
Box: With "Indigo," we've built in secure protocols down to the metal so that every message can be secure. As soon as data
and information go out of the box, there is a strong security infrastructure in place, based on decentralized authentication,
federated identification, message-based securities, and more.
PressPass: How can developers get started on the road to "Longhorn" today?
Anderson: A great first step is to come to this year's PDC. But for those who can't, there will be a ton of detailed and useful
information at the new "Longhorn" Developer Center on the Microsoft Developer Network site (see link at right). The best
general advice is to write managed code for new applications and start to exploit managed code selectively from existing
applications, use Web services for your connections with other systems, and take advantage of all the enormous power we have
on the PC today.
Box: Honestly, there is a lot of innovation happening in the current platform already. But I would tell folks to move to managed
code and the .NET Framework, because doing so will make it so much easier to integrate with the "Longhorn" platform. In
Windows XP, you can write in managed code, but most of the core capabilities were written in native code. With Windows
"Longhorn," if you're writing in managed code, you're going to have a lot of advantages.
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx
Microsoft Developer Tools Roadmap 2004-2005
In February 2002, software developers and architects worldwide were introduced to Visual Studio .NET and
the Microsoft .NET Framework. This landmark release, four years in the making, offered a unified development
environment and programming model for constructing a range of software solutions. With the recent launch of
Visual Studio .NET 2003, customers gained the benefits of enhanced tool and framework functionality, as well
as increased performance, security and scalability for building enterprise-critical software.
65
As the needs of businesses continue to evolve, Microsoft remains committed to ensuring the success of its
customers by providing innovative developer tools that meet these ever-changing requirements. To help
organizations plan future software development efforts, Microsoft is providing a roadmap to the following
planned releases of its developer tools:

Visual Studio code name "Whidbey" (2004). This release of Visual Studio and the .NET Framework will
offer innovations and enhancements to the class libraries, common language runtime (CLR), programming
languages, and the integrated development environment (IDE). In addition, this product will provide deep
support for SQL Server code name "Yukon" by enabling developers to write stored procedures using
managed code.

Visual Studio code name "Orcas" (2005). This version of Visual Studio and the .NET Framework will provide
tools support for the Windows operating system, code name "Longhorn."
Figure 1. Developer Tools Roadmap 2004–2005
Microsoft developer tools have always been built to enable developers to take advantage of the latest
advances in the Windows platform. As shown in Figure 1, Microsoft will continue this tradition by providing
tools that support upcoming versions of SQL Server and the Windows operating system.
Top of Page
Visual Studio "Whidbey" (2004)
The Whidbey release of Visual Studio and the .NET Framework will make strides in all dimensions of
application development. First, Visual Studio Whidbey will set a new bar for developer productivity by tailoring
the software development experience to the needs of the individual developer. This "personalized
productivity" will deliver features across the development environment and .NET Framework class libraries to
help developers overcome their most pressing challenges in minimal time. Second, Whidbey will enable
developers to apply existing skills across a broader range of application development scenarios through
improved integration with the Microsoft Office System and SQL Server Yukon. Finally, Whidbey will deliver a
new set of tools and functionality that will help satisfy the application development needs of today's largescale enterprises.
Key focus areas for Whidbey include:

Language and IDE Productivity. Microsoft will build on the distinctive characteristics of each of the four
languages delivered as part of Visual Studio (Visual Basic, Visual C++, Visual C#, and Visual J#). This
language innovation will enrich the programming experience for each of the respective developer
communities without sacrificing existing language functionality and interoperability. Features surfaced
66
through language innovation will be manifested throughout the Whidbey IDE, delivering personalized
productivity for all developer communities.

The Microsoft .NET Framework. Whidbey will introduce enhancements across the .NET Framework class
libraries. Windows client application development will be simplified through new controls and designer
features, while the introduction of "ClickOnce" technology will dramatically ease Windows client application
deployment. ASP.NET Whidbey will introduce a collection of new features that refine Web application
development and radically reduce coding effort. Other enhancements include more productive ADO.NET
data access, support for the latest Web services standards, and expanded functionality for device-based
development.

Microsoft Office Solution Development. The Whidbey release of Visual Studio Tools for the Microsoft Office
System will bring significant enhancements to the development of business solutions based on Microsoft
Office Excel 2003 and Microsoft Office Word 2003. Developers building Office solutions will benefit from
improved integration between Whidbey and Office, a familiar coding experience, and improved security and
deployment.

SQL Server Yukon Solution Development. SQL Server Yukon integrates the development and debugging of
database objects into the Whidbey development environment, enabling developers to use the same tools
for building and deploying database objects that they use to write managed components and applications
today.

Enterprise Development and Life-Cycle Support. Microsoft plans to deliver improved support for architects
and enterprise developers in the Whidbey release. New tools will deliver enhanced project analysis and
design, software configuration management, and deployment, as well as a scalable new build engine to
ensure that Microsoft developer tools span the application life cycle.
Language and IDE Productivity
Microsoft offers four programming languages for building software with Visual Studio. In Whidbey, Microsoft
will expand upon the unique strengths of Visual Basic, Visual C++, Visual C#, and Visual J# to deliver a rich
language offering for developing a range of software. These language innovations, surfaced through the
Whidbey IDE, will work in concert with enhanced IDE profiles and an intuitive Help system to deliver
productive, customized development experiences based on the needs of the developer community (figure 2).
Figure 2. Customized Help and improved IDE profiles will enable developers to use the Whidbey development
environment to access information more effectively.
Top of Page
Visual Basic
The Whidbey release of Visual Basic will radically improve developer productivity while continuing to provide
full access to the .NET Framework. Key design goals for Visual Basic Whidbey include: reducing the amount of
code required to accomplish common tasks; dramatically reducing programming errors at design time;
simplifying data access; improving the RAD debugging experience; and delivering high-end features for
advanced Visual Basic developers.
67
Visual Basic Whidbey will reduce the coding associated with many common programming tasks by over 50
percent. New objects and methods will provide efficient access to the most frequently used functionality within
the .NET Framework, including project-related resources, such as forms, data sources, and Web services, as
well as machine-level components, such as printers, the file system, and the registry. The code in figure 3
shows one example of how these Visual Basic language extensions will dramatically simplify the code required
for common operations.
Visual Basic .NET 2003
Const GreetingName As String = "Greeting"
Dim sDisplay As Object
Dim ResMgr As ResourceManager
ResMgr = New ResourceManager("ResourcesSample.MyStrings",_
Me.GetType.Assembly)
sDisplay = ResMgr.GetString(GreetingName)
Visual Basic Whidbey
My.Resources.MyStrings.Greeting
Figure 3. Use of the My. classes provides Visual Basic developers with faster access to commonly used
functionality within the .NET Framework.
In addition, the Visual Basic code editor will provide pre-built code templates that enable developers to "fill in
the blanks" and focus on solving the problem at hand rather than on language syntax (figure 4). Developers
will also be able to easily create and distribute their own customized code snippets.
Figure 4. Code snippets automatically author common programming tasks.
New features in the Visual Basic code editor will dramatically reduce programming errors for both beginning
and advanced developers at design time. Providing similar functionality to the Microsoft Word spelling and
grammar check, Visual Basic Whidbey will suggest corrections for common syntax errors.
Figure 5 shows a smart tag offering corrections for a misnamed type. Examples of errors that will be trapped
include: forgetting to reference a required assembly, attempting to override a method with an incorrect
signature, and misspelling a class name. In addition, the compiler will warn developers of semantically
incorrect code that would otherwise cause runtime errors, such as attempting to access code elements prior to
initialization.
68
Figure 5. Smart tags provide automatic syntax correction mechanism for Visual Basic code.
Visual Basic Whidbey will also radically enhance the experience of manipulating and retrieving data. Simplified
data source design from within the development environment will be available for local and remote data,
business objects, and Web services. Whidbey will also reintroduce the ability to create data-bound forms
without code. Ideal for many common data access scenarios, yet robust and scaleable enough for the most
demanding distributed applications, this feature will enable developers to automatically generate
customizable, data-bound UI when a table or columns are dragged and dropped onto a form.
Whidbey will deliver a debugging experience that is both powerful and familiar to the Visual Basic developer.
With the reintroduction of Edit and Continue, developers will be able to modify and test source code without
stopping and restarting the debugging session. Debugger advances will allow developers to intercept
exceptions, get additional information about the exception, and continue if appropriate (figure 6). This
iterative development and debug cycle, combined with advanced error correction and code analysis in break
mode, will provide developers using Visual Basic with a debugging experience that is both powerful and
flexible.
Figure 6. Exception Helpers enable developers to more effectively diagnose runtime errors.
Following development, Visual Basic Whidbey will simplify the task of deploying a completed Windows client
application to a user's machine with the introduction of "ClickOnce" deployment. Using this technology,
developers will be able to create an application package that can be distributed through a Web page, file
share, or other medium. Application users will simply click on the distribution package to install the application
and all of its prerequisites. Further information on ClickOnce deployment and other deployment advances in
Visual Basic Whidbey are covered later in this document.
For developers who have existing investments in Visual Basic 6.0 code, Whidbey will include several key
improvements to the Visual Basic Upgrade Wizard. While the current version of the upgrade wizard available
with Visual Basic .NET 2003 will successfully upgrade up to 95 percent of an application, advances in Whidbey
will improve upon this rate with support for upgrading COM+ projects, additional Visual Basic 6.0 controls,
including the TreeView, ListView and MaskedEdit controls, and enhanced support for upgrading code that
involves programmatic printing. The Upgrade Wizard will also take advantage of many of the new language
features being introduced in Whidbey to produce even cleaner and more maintainable upgraded code.
For the more advanced Visual Basic developer, language enhancements include support for operator
overloading, unsigned data types, and partial types. In addition, developers using Visual Basic will have
access to the CLR implementation of generics that promote code reuse across a variety of data types. Visual
Basic Whidbey will introduce inline XML-documentation comments that will assist developers in creating well
documented applications ready for deployment inside or outside the enterprise. Finally, Visual Basic Whidbey
developers will continue to have full and direct access to all of the classes and functionality within the .NET
Framework.
Like its predecessors, Visual Basic Whidbey will focus on enabling developers to rapidly build applications that
span all tiers. Planned enhancements across the visual designers, code editor, language, and debugger will
greatly enhance productivity, enabling developers to create robust, elegant applications faster and deploy
them across the Web, a business group, or an enterprise.
Top of Page
69
Visual C++
In Whidbey, Visual C++ will offer even more power and fine-grained control than its predecessors for systems
and application developers targeting both Windows and the .NET Framework. Key improvements are planned
across all areas of the product, including the language, compiler, and core libraries. These enhancements will
enable C++ developers to more effectively target the CLR, optimize their code for performance, target 64-bit
Windows, and improve application security. Moreover, Visual C++ Whidbey will enable developers to build
native C++ applications for mobile devices directly within the Visual Studio Whidbey IDE. (More information
about embedded C++ development can be found in the Device-Based Development section).
With Visual C++ .NET versions 2002 and 2003, Managed Extensions enable developers to explicitly take
advantage of the CLR and the .NET Framework. In Whidbey, the existing Managed Extensions syntax will
continue to be fully supported. In addition, Visual C++ will offer expanded support for the CLR and the .NET
Framework with powerful new features and a more elegant syntax for writing managed code. This syntax is
now undergoing ECMA standardization as a C++ binding to the ECMA-standardized Common Language
Infrastructure (CLI). The new syntax will be called C++/CLI.
The C++/CLI subset of the C++ language will be largely implemented in Visual C++ Whidbey, and will offer
Visual C++ developers a number of new capabilities. For the first time, C++ developers will be able to write
.NET-connected applications using true C++ programming paradigms. For example, C++ templates and C++style deterministic finalization will be enabled for code and data managed by the CLR and the garbage
collector. Additionally, C++/CLI brings many CLR programming paradigms to C++, including the CLR
implementation of generics.
C++/CLI also streamlines the manner in which managed data types are defined and consumed. The new
standard introduces keywords that are more intuitive to C++ developers than the underbar-underbar
keywords of current Managed Extensions. In C++/CLI, the ref keyword is used in a manner similar to the
Managed Extensions __gc keyword to define a garbage-collected class:
ref class MyRefClass { /* … */ };
In addition, C++/CLI introduces a new category of type, the handle, which is used to signify the use of
automatic garbage collection. Handles borrow the syntax of pointers, but use the carat (^) in place of the
asterisk (*). The keyword gcnew is used to create these garbage collected objects, and returns a handle:
MyRefClass ^ c = gcnew MyRefClass();
With C++/CLI, developers will also be able to incorporate traditional C++-style deterministic finalization for
handle types. This means that a reference type may be optionally instantiated as an object using normal C++
stack-allocation syntax. In doing so, the object will automatically have its destructor called when it falls out of
scope. This feature enables a style of programming not available in other languages targeting the CLR.
In addition to C++/CLI support, the Visual C++ compiler will offer several code-generation enhancements for
CLR-targeting code. These enhancements include the ability to specify a "pure" image that includes no nativex86 instructions and a "safe" image that passes the CLR verification process. Furthermore, the Visual C++
Whidbey compiler will be able to optimize MSIL beyond what is possible with other managed languages.
One of many enhancements planned for the C++ compiler in Whidbey is Profile Guided Optimizations (POGO).
POGO technology enables the compiler to instrument an application and collect information on how the
application is used at runtime. This information enables Visual C++ to further optimize generated code based
on real-world application usage patterns. Pre-release versions of 64-bit POGO technology currently ship in the
freely downloadable Platform SDK (PSDK). In Whidbey, this technology will be extended to the core 32-bit
compiler, and support will be integrated into the IDE (figure 7).
Figure 7. POGO support in Visual C++ Whidbey will optimize applications through instrumentation and
runtime analysis.
70
Whidbey will also include the 64-bit C++ compilers that are currently only available in pre-release form within
the PSDK. These compilers enable Visual C++ developers to write unmanaged code that target the 64-bit
versions of Windows running on both Intel and AMD hardware. Support for targeting 64-bit Windows will be
fully integrated into the IDE (figure 8).
Figure 8. Platform support in Visual C++ Whidbey is extended to include 64-bit Windows, as well as various
mobile devices.
In addition to language and compiler enhancements, Visual C++ Whidbey will deliver improvements and
additions to core C++ libraries, such as the Microsoft Foundation Classes (MFC), the Standard Template
Library (STL), and the C-runtime library (CRT). These additions will enable C++ developers to better support
the .NET Framework and deliver built-in application security.
First, a new version of the Standard Template Library (STL) will be introduced. This version of STL will be
tuned for interacting with managed code and data. Programmers who are comfortable using STL for writing
traditional C++ applications will find they will be able to apply the same coding techniques to writing CLRbased applications. Second, a new version of the C-runtime library (CRT) with enhanced security features will
be released with Whidbey. As part of Microsoft's ongoing commitment to the Trustworthy Computing initiative,
this release of the CRT will help increase the collective security of applications that integrate the CRT.
With Whidbey, developers will continue to choose Visual C++ to build their most demanding applications and
components. Whidbey expands on the core set of capabilities delivered in the 2003 release of Visual C++
.NET with an exciting offering of new and refined features for the control and performance-conscious C++
developer.
Top of Page
Visual C#
In Whidbey, Microsoft plans to infuse C# with a variety of language and code editor features that will provide
C# developers with "code-focused RAD," delivering productivity for creating business frameworks and
reusable object-oriented components. Included among these features are generics, iterators, anonymous
methods, partial types, and refactoring.
As projects increase in sophistication, programmers often need a means to better reuse and customize
existing component-based software. To achieve such a high level of code reuse, programmers typically
employ a feature called generics. In Whidbey, the CLR will include a type-safe, high-performance, compile
time-verified version of generics that differs slightly in syntax and greatly in implementation from the
templates as found in C++ and the generics as proposed for the Java language. Generics allow developers to
author, test, and deploy code once and reuse that code for a variety of different data types with negligible
performance impact. The CLR implementation of generics will also reduce code bloat when compared to other
strongly-typed implementations, leading to more readable and maintainable source.
In the example below, a generic Stack class is created that will accept the type for which they are created and
store data of that type natively, rather than forcing conversions to and from the base class type:
public class Stack
{
private ItemType[] items;
71
public void Push(ItemType data)
{
...
}
public ItemType Pop()
{
...
}
}
The type used by the generic Stack class is only specified upon instantiation. In this example, the Stack class
is instructed to use a primitive integer type by specifying it as a parameter using the angle notation in the
instantiation statement:
Stack stack = new Stack;
stack.Push(3);
int x = stack.Pop();
In addition to improving code reuse through generics, Visual C# will provide support for iterators to eliminate
the often repetitive chores associated with implementing enumerator patterns. Based on similar features in
research languages, such as CLU, Sather, and Icon, iterators make it easy for types to declare how the
foreach statement will iterate over their elements. Rather than having to create the classes and build the state
machine for manually implementing the enumerator pattern, the C# compiler will translate iterator code into
the appropriate classes automatically.
Anonymous methods are practical language constructs that will enable programmers using Visual C# Whidbey
to create code blocks that can be encapsulated in a delegate and executed at a later time. They are based on
a language concept called a lambda function and are similar to those found in Lisp and Python. Anonymous
methods are defined dynamically at the point at which they are used, rather then being pre-defined as a
named method of a specific class. Anonymous methods make some types of operations more convenient,
particularly when the method signature or body needs to be changed at runtime.
In this example, an anonymous method is used to directly modify a ListBox on a form, foregoing the creation
of an entirely new method for the class and instead directly referencing the executable steps contained
therein. The code used to modify the list box is stored within the scope of execution immediately following the
delegate creation statement:
public class MyForm
{
ListBox listBox;
TextBox textBox;
Button button;
public MyForm()
{
listBox = new ListBox(...);
textBox = new TextBox(...);
button = new Button(...);
button.Click += new EventHandler(sender, e)
{
listBox.Items.Add(textBox.Text);
};
}
}
Whidbey will also enable C# developers to split types consisting of a large amount of source code into several
different source files using partial types. Providing easier development and code maintenance, partial types
enable developers to separate machine-generated and user-written parts of a type in order to more effectively
supplement or modify code generated by a tool.
In addition to extending the C# language, Whidbey will introduce C# developers to a number of code editor
enhancements. Among these is code refactoring—the process of restructuring code in a disciplined way (figure
9). With refactoring, C# developers can improve the design and efficiency of code after it has been written.
Whidbey will include the following Refactoring types: Rename, Encapsulate Field, Change Method Signature,
Extract Method, and Extract Interface.
72
Figure 9. Refactoring enables developers to effectively manage code that is poorly organized.
Other C# code editor enhancements include "fill-in-the-blank" code expansions for common coding constructs,
such as for loops and try/catch blocks (figure 10), improved IntelliSense support for attributes and generics,
and a rich set of options for customizing how the IDE formats C# code.
Figure 10. Code expansions provide templates for common coding constructs.
With its focus on language innovation, C# will remain the language of choice for many framework designers
and software architects. By supplementing its modern syntax with component-oriented features, modern
language constructs, and code editor enhancements, C# will continue to deliver on the promise of codefocused RAD.
Top of Page
Visual J#
The Whidbey release of Visual J# will introduce several features planned to enhance the Java-language
development experience. First, Visual J# Whidbey will include a number of enhancements to the language
syntax to improve code migration and interoperability scenarios. Second, the Whidbey release of Visual J# will
be a full CLS Extender, enabling better interoperability with other CLS-compliant languages. Third, Visual J#
will integrate J# Browser Controls (currently available as an add-on) to facilitate the migration of Java applets
to run within the context of the .NET Framework.
In order to improve cross-language interoperability and support future Windows operating system features,
Visual J# Whidbey will include several language additions and enhancements. These language enhancements
enable developers using Visual J# to write code that is more efficient, secure, and expressive. First, Visual J#
will introduce support for the volatile keyword to improve code flexibility in optimized code scenarios. Second,
Visual J# Whidbey will enable support for .NET-style serialization, providing greater interoperability when
exchanging data. Third, the APTC attribute (Allow Partially Trusted Callers) will be enabled for the J#
Redistributable, meaning that developers can deploy applications that run with partial trust, given the
73
appropriate code access security settings. Finally, Visual J# will provide support for consuming generics to
ensure cross-language consistency in future releases of the .NET Framework:
Queue q;
// System.Collections.Generic.Queue
Stack s; // System.Collections.Generic.Stack
KeyValuePair k;
In addition to syntax enhancements, Visual J# Whidbey will become a full CLS Extender by adhering to the
Common Language Specification rules for language interoperability. Visual J# .NET 2003 is a full CLS
Consumer, but a limited CLS Extender, meaning that Visual J# applications can fully access and utilize CLScompliant frameworks, but cannot always create them due to some limitations in the language. In Whidbey,
Visual J# will overcome these limitations by adding support for authoring value types and typesafe enums.
Value types are often thought of as lightweight classes. The primary difference between a value type and a
class is that a value type does not require heap allocations and contains the data of the type, whereas a
variable of a class type contains a reference to the data. Also referred to as user-defined value types, value
types enable scenarios in which objects are used in a similar fashion to primitive types—without the overhead
associated with garbage collection. The syntax for creating a value type in Visual J# is similar to creating a
class type, with the exception that the value type extends from System.ValueType:
public final class Point extends System.ValueType
{
public int x;
public int y;
}
An enum (or typesafe enumeration) type is a kind of value type. Each enum type has a corresponding integral
type called the underlying type. This underlying type must be able to represent all of the enumerator values
defined within the enumeration. Enums are typesafe, they improve code readability, and they can be used as
the control type in a switch statement. An enum type is similar to a value type, except that it extends from
System.Enum:
public final class Color extends System.Enum
{
public static final int Red = 1;
public static final int Green = 2;
public static final int Blue = 3;
}
The enum type above can then be instantiated as follows:
Color c = new Color();
int i = (int) c.Red; //i = 1
As a full CLS Extender, Visual J# Whidbey will also support the CLSCompliant attribute that developers can
apply to their assemblies to indicate whether or not a given component uses only CLS compliant features in
the APIs that it exposes.
Since the inception of Visual J# in 2002, members of the Java community have requested the ability to
migrate Java applets to managed code so that they run within the context of the .NET Framework. In addition
to providing greater functionality and security than applets, such a technology would alleviate concerns over
the planned end of life for the Microsoft Java Virtual Machine. In response to these customer requests,
Microsoft has developed a technology known as J# Browser Controls. J# Browser Controls enable developers
to migrate existing applet source code to run on the .NET Framework simply by opening their source code and
recompiling with minimal or no code changes. Once this conversion is complete, developers can embed the J#
Browser Control within a Web page in a way similar to embedding applets today. Additionally, J# Browser
Controls have full access to the .NET Framework and will include support for consuming Web services. J#
Browser Controls will be provided as part of the J# Redistributable in the Whidbey timeframe, and are
available today as an add-on to the .NET Framework 1.1. See J# Browser Controls.
With its familiar syntax and object-oriented functionality, Visual J# continues to offer the most productive way
for Java-language developers to start building applications with the .NET Framework. Enhancements in Visual
J# Whidbey will broaden the spectrum of capabilities available to students, teachers, and professors, as well
as developers using the Java language and Visual J++.
Top of Page
The Microsoft .NET Framework
Developed in concert with Visual Studio .NET, the Microsoft .NET Framework provides a dependable
foundation for constructing Windows, Web, and mobile device-based applications that integrate by design,
and deploy efficiently across the enterprise. In Whidbey, the .NET Framework will further extend the
74
capabilities of developers by introducing significant enhancements across each of its functional areas. New
classes will give developers more efficient access to frequently used components, such as printers, the file
system, and the registry. Advances to Windows Forms and ASP.NET classes will reduce code in common
scenarios by up to 70 percent. Reliability and scalability will also be significantly improved through support for
64-bit processors from Intel and AMD, improved ASP.NET caching and page processing, and overall improved
working set and application startup time.
Windows Client Application Development (Windows Forms)
Windows Forms empowers developers with the full power of the Windows client PC. In Whidbey, the Windows
Forms classes will be enhanced to include an improved application deployment model, increased developer
productivity, and simplified data access. Whidbey will also include notable enhancements to Windows client
application performance and security.
First, Whidbey will improve upon the .NET Framework No-Touch Deployment strategy with the introduction of
"ClickOnce," a new technology that will bring the ease and safety of Web application deployment to Windows
client applications (figure 11). Building on the strengths of self-describing assemblies, component manifests,
and side-by-side component installation, ClickOnce will enable a developer to publish, install, and service
Windows client applications without fear of breaking existing functionality on the client operating system.
Whereas traditional deployment builds an MSI package which may require modifications to the system
registry and installation to shared system folders, ClickOnce publishing is tailored to install isolated,
registration-free assemblies. Developers will have the choice of choosing which model is best for their
Windows client application: ClickOnce Publishing, MSI Deployment, or a combination of both.
New capabilities for Windows client applications installed using ClickOnce will include: support for running
applications offline, rolling back to previous versions of an application, and listing an application in the
Windows Start menu, as well as the Remove Programs catalog within the Control Panel. Additionally,
ClickOnce Deployment in Whidbey will enable developers to distribute the .NET Framework with a Windows
client application.
Figure 11. The Publish Wizard enables Windows client applications to be deployed as easily as Web
applications.
To further support this deployment model, significant investments are being made in code access security,
which protects users from malicious code by governing the capabilities of applications deployed from a remote
Web server. In Whidbey, the scope of permissible actions that may be carried out safely by the deployed
application will be expanded. Additionally, enhancements to the .NET Framework will make it easier for
systems administrators to safely roll out updates to code access security policy.
Second, Windows Forms will include features and controls that increase developer productivity. These features
and controls include the following: an Active Document Container for hosting Office documents, a Microsoft
Office-style toolbar, intuitive splitter controls, a sound component that can run in partial trust, a Web browser
control that can be accessed safely by way of managed code, and layout controls that automatically position
and resize controls on a form as screen resolution or form dimensions change. In addition, implementation of
multithreaded applications will be simplified through large investments in the Windows Forms asynchronous
75
programming model. Many Windows Forms controls will feature asynchronous properties and will be
complemented by a new, intuitive BackgroundWorker component to manage asynchronous tasks.
These new controls and components will work with enhancements planned for the Windows Forms designer,
including smart tags, Snap Lines, data preview, and more. Using smart tags, Windows client application
developers can easily customize the look and behavior of data-bound controls with a click of the mouse (figure
12); Snap Lines will simplify the layout of groups of controls within a form, and data preview will enable
developers to view populated data-bound controls at design time.
Figure 12. Smart tags provide easy customization of data-bound controls and forms.
Web Application Development (ASP.NET)
Providing the thin-client counterpart to Windows client development is the Web application infrastructure
ASP.NET, introduced as part of version 1.0 of the .NET Framework. Through dramatically improved
performance, productivity and security, Visual Studio Whidbey and ASP.NET will deliver a simplified, high
performance, and powerful Web development experience. In the Whidbey release, ASP.NET will feature a new
set of controls and infrastructure that simplify Web-based data access and will include functionality that
facilitates code reuse, visual consistency, and aesthetic appeal.
First, ASP.NET data access will be refined in the Whidbey release through the introduction of new controls for
interacting with data. The DataSource control will be used declaratively or programmatically in an application
to encapsulate the query logic required to work with data from databases, XML files, middle-tier business
objects, and other sources. The DataSource exposes a set of common interfaces so that data-bound controls
can easily consume different types of data without requiring a unique API for each data type it supports.
While the DataSource control helps simplify the retrieval and update of data, ASP.NET will also provide new
controls that display and manipulate data. The GridView control is the successor to the ASP.NET DataGrid that
adds the ability to automatically handle paging, sorting, editing, and deleting of data (figure 13). The
DetailsView is a data-bound control that renders a single record at a time from its associated data source.
Similar to the Form View of a Microsoft Access database, the DetailsView provides paging buttons to navigate
between records. Developers can use the DetailsView control in a master-details scenario for updating and
inserting new records where the selected record of the master control determines the DetailsView display
76
record. The added functionality of these and other controls dramatically simplifies the building of dynamic,
data-driven Web sites and Web applications.
Figure 13. The GridView control provides paging, sorting, editing, deleting, and selection of grid elements
without additional code.
Second, Whidbey will include features that ensure consistency and code reuse across pages within a Web site.
The introduction of Master Pages will enable developers to quickly share layout across multiple pages by
designing templates that specify the location of controls, menu bars, headers, and footers (figure 14). Similar
to visual inheritance in Windows Forms, Master Pages allow other pages on a Web site to inherit from a
Master Page, automatically acquiring its look and feel. When a developer wishes to change the layout of all
the pages, it is only necessary to make updates to the Master Page. Other platform productivity
enhancements include a set of framework services that simplify many common Web scenarios, such as
authentication, site navigation, administration, personalization, and more. These enhancements will reduce
code bloat, increase maintainability, and simplify the implementation of most common Web application
development tasks.
Figure 14. Master Pages enable efficient sharing of Web site layout across multiple pages. The gray area
within the designer represents Master Page layout; the white represents editable page content.
77
Also new to ASP.NET is the ability to incorporate themes and skins to enhance the appearance of Web
applications. A skin is a set of properties, templates, and custom code that can be used to standardize the
size, font, and other characteristics of controls on a page. A theme incorporates multiple skins and stylesheets
to specify the overall look and feel of a Web site. Themes and skins will be simple to package, transfer, and
apply to other Web sites. In addition, ASP.NET will provide several built-in themes that developers can use to
build aesthetically appealing Web sites out of the box.
Third, Web application developers using Whidbey will be able to increase their application performance by
taking advantage of SQL cache invalidation. This method of data caching facilitates significant performance
improvements by caching data retrieved from a SQL Server database until an update to that data is made.
With currently available versions of SQL Server, ASP.NET will poll the database at specified intervals to
determine if an update to the data has been made. Then, only when an update to the data is indicated will
ASP.NET requery the database. When developing against a SQL Server Yukon database, however, developers
will be able to cache data-driven pages for an indeterminate amount of time. This ability is due to Yukon's
ability to proactively notify ASP.NET of changes made to the data. Internal testing of SQL cache invalidation
has demonstrated performance benefits of up to 10 times that of non-cached data scenarios.
Fourth, Web application developers will experience dramatic improvements in productivity through the use of
the Visual Studio Whidbey IDE itself. With the new Web Developer IDE profile enabled, Whidbey will optimize
the development environment and user experience by exposing only that functionality which is pertinent to
Web application development. In addition, a new directory-based project model will remove the overhead of
solution files while enabling Web developers to enjoy a traditional file system-based project paradigm with
support for direct IIS enumeration, FTP, and file system access. As a result, FrontPage Server Extensions are
no longer a requirement for building ASP.NET pages.
Finally, enhancements to the ASP.NET code-behind model remove the reliance on fragile tool-generated code
traditionally needed to coordinate an ASP.NET Web page with its associated class file. Using partial classes,
ASP.NET will provide a more robust model to separate presentation markup from code. Partial classes will also
enable developers to easily write code inline (figure 15), thereby aligning with the model familiar to many
Web developers. Other IDE productivity enhancements for Web development include a design-time validation
engine, in-line CSS support, more flexible debugging, and more.
Figure 15. IntelliSense within script blocks enables statement completion and syntax checking at design time.
With improvements planned across the control set, visual designers, and coding experience, ASP.NET Whidbey
will reduce the amount of code required to accomplish common coding scenarios by up to 70 percent,
drastically streamlining and simplifying the Web application development experience.
Top of Page
Device-Based Development
With the release of Visual Studio .NET 2003 and the .NET Compact Framework, developers using Visual Basic
and Visual C# gained the ability to build device-based applications using the same tools and methods used for
desktop and Web-based development. In Whidbey, smart device programmability will be extended to include
an updated version of the .NET Compact Framework and support for native Visual C++ smart device
development from within the IDE.
78
The inclusion of native Visual C++ smart device development in Whidbey provides developers with greater
flexibility when developing applications for the Pocket PC, Smartphone, and other Microsoft Windows-powered
devices. Developers targeting mobile devices will benefit from the tight integration of the native Visual C++
development features and a consistent development experience across all Visual Studio project types, ranging
from smart devices to Windows servers.
For developers building managed applications using the .NET Compact Framework, Whidbey will enable
creation of applications that run on the latest devices, including Smartphone, Windows CE .NET 4.2-based
devices, and the newest versions of the Pocket PC. This release will also introduce new classes and controls
for accessing telephony features, messaging (MSMQ), and Short Message Service (SMS). Finally, native code
interoperability enhancements, including improved marshalling, COM Interoperability, and runtime hosting will
improve the smart device application development experience.
Data Access (ADO.NET)
With the initial release of the .NET Framework, Microsoft introduced ADO.NET, the evolution of ActiveX Data
Objects (ADO). Designed to natively support XML as well as traditional datasets, ADO.NET offered stronglytyped, distributed data access and ensured against unnecessary occupation of database ports by making
extensive use of local data caching and open database connections. The resulting improvements in
performance and scalability have provided a foundation on which to enhance future versions of ADO.NET.
In the Whidbey release of the .NET Framework, data access will be enhanced not only through the addition of
new data access controls, services, and the ability to integrate more seamlessly with SQL Server Yukon, but
also through improvements to the ADO.NET class libraries themselves. These enhancements focus on ease-ofuse, code reusability, and improved support for XML.
First, numerous improvements will be made to the usability of the data access object model. While initial
versions of the .NET Framework concentrated on providing a strong core for data access developers, Whidbey
will extend this core with additional classes to further increase developer productivity. In addition, tracing
support will be improved for fine-grained debugging of data access components across multiple tiers and into
.NET Framework managed code, as well as native code.
Second, Whidbey will include enhanced tools for editing, debugging, and coding XML and related technologies
(figure 16). In addition to delivering increased performance when accessing and managing XML, the Whidbey
release of the .NET Framework will provide expanded functionality for performing common tasks involving the
manipulation of XML as well as other XML based standards and technologies.
Figure 16. The new XML Editor supports outlining, validation, and editing of XSLT.
79
Finally, enhancements for creating XML schemas in Whidbey include the ability to infer an XSD schema from
any existing XML document, as well as native support for XML-based data processing using XML Query
Language (XQuery).
Advanced Web Services
With Visual Studio .NET 2002 and 2003, developers benefited from the simplicity with which they could
create, consume, discover, and deploy Web services. In Whidbey, Microsoft's ongoing commitment to Web
services will be demonstrated through support of the latest industry standards, implemented in the Web
Services Enhancements (WSE) libraries. Updates to WSE will facilitate the creation of business-critical Web
services that involve multiple trust domains, long-running operations, and peer-to-peer communication.
In addition, as WSE gains broad adoption and industry specifications for advanced Web service development
mature, the WSE libraries will be integrated into the .NET Framework. Future releases of WSE will contain the
latest version of these specifications and will include a policy framework, enhanced security model, and a
SOAP messaging infrastructure. In addition, WSE will support hosting outside of IIS (as an executable or a
Windows Service) and will support both HTTP and TCP communication.
Top of Page
Microsoft Office Solution Development
In October 2003, Microsoft released Visual Studio Tools for the Microsoft Office System. This new technology
brings .NET Framework-based development to Word 2003 and Excel 2003 solutions by enabling developers to
write managed code that responds to events within the Word and Excel automation models. Building on the
long-standing success of Visual Basic for applications (VBA) and COM-based automation, Visual Studio Tools
for Office (VSTO) provide developers with significant benefits for building Office solutions, including a familiar
coding experience, improved deployment and maintenance of solutions, and improved security.
The Whidbey release of VSTO brings significant enhancements to the development of business solutions based
on Microsoft Office Excel 2003 and Microsoft Office Word 2003. Building on the foundation provided by this
version of VSTO, Whidbey Visual Studio Tools for Office will address some of the biggest challenges facing
Office solution developers today, including separation of data and view elements, deployment of Office
solution assemblies, server-side and offline scenarios, and seamless integration with the Visual Studio toolset.
One of the primary goals of Whidbey VSTO is to separate "data" from "view" in Office documents in order to
simplify the creation of Office-based solutions. Today, Excel spreadsheets and Word documents consist of an
amalgamation of either cell values or text (representing the data) and descriptive information about the data,
such as the font (representing the view). Because Word and Excel have no built-in concept of programmatic
data, developers are limited in their ability to effectively develop solutions around the data stored within the
documents.
Whidbey VSTO will separate the data from the view in Office documents by enabling data to be embedded as
an XML data island. This provides a well understood and easily addressable structure that developers can rely
on when programming. The developer is able to separate view and data, and is thus able to update the data
directly without concern of writing view code. Typed data sets will be used to provide a schema-oriented
programming model for interacting with the data island, ensuring IntelliSense support for the managed code
being written. Data binding will be used between the data island and the view to keep these two entities in
sync. The developer will also be able to add validation code to the data that is independent from the
document view components.
Programming directly to data by way of an XML schema-based model provides dramatically improved
productivity for developers. Code that works with data does not need to address the Excel and Word object
models. This simplifies much of the code involved in building Office solutions and makes solutions resilient to
changes in the document. The resulting code is less brittle because it does not rely as heavily on references to
specific cells, ranges and tables that can be arbitrarily moved around by end users. Rather, the managed code
directly accesses XML data islands.
Making data in Office documents a transparent, directly accessible component enables new server-side
opportunities. First, the data island embedded in the document can be manipulated without starting the Office
application. This is a dramatic shift from the current model, by which, in order for code to manipulate the
contents of the document, Excel or Word must be running. This limitation blocks many customers from
implementing a common solution requirement—creating Office documents from within an ASP.NET
application.
By contrast, the Whidbey VSTO runtime will support instantiation on a server without the need to run Excel or
Word. The data island in a document could then be manipulated from the server-side code. When the user
opens the associated Office document the view would be re-synchronized with the data island and the user
would be automatically presented with the updated data. In this model, Excel and Word are not needed to
write to the data on the server, but rather only to view it on the client. This updated model will provide the
scalability customers desire and the ability to perform high performance batch processing of documents
containing data islands on the server.
Storing the data in a data island also provides a mechanism for enabling robust offline scenarios. When a
document is first requested from the server or first opened by the user, the data island will be filled with the
80
most recent data. The data island would then be cached in the document and made available offline. The data
could be manipulated by the user and by code without a live connection. When the user reconnects, the
changes to the data could be propagated back to a server data source.
In addition to radically improving the data programming model, the Whidbey release of VSTO will introduce
enhancements to the way developers programmatically access user interface, or view, elements, such as
ranges, lists, and bookmarks. Even though developers can write code today to manipulate these elements,
they are impacted by the extent to which the Office object models expose events, properties, and methods.
For example, the Excel object model provides a WorkSheet_Change event, but does not provide similar events
for individual cells or ranges, necessitating additional code to handle the occurrence of a change to a specific
element. Whidbey VSTO introduces enhancements to the Excel and Word object models in the area of view
elements. Elements, such as cells, ranges, lists, and bookmarks will become first class controls that can be
easily accessible in code. Each control will be uniquely identified, will enable data binding and will provide a
more complete event model.
Whidbey VSTO will also lower the barriers that currently exist when building Office solutions with managed
code by integrating Excel and Word with Visual Studio. Currently, developers write managed code in Visual
Studio .NET. Then, they must switch to Excel or Word in order to create the user interface. In Whidbey VSTO,
Excel and Word will be hosted directly in the Visual Studio Whidbey IDE as designers (figure 17). Developers
will be able to design Office documents within the Visual Studio environment using the full collection of
Windows Forms controls in Excel and Word by simply dragging and dropping managed controls, including
third-party controls, from the Toolbox. As expected, double-clicking on a managed control in Excel or Word
will invoke the code view in which customizations can be written inside the auto generated event handler for
that control.
Figure 17. The Whidbey IDE will support the hosting of Excel spreadsheets, as well as Word documents.
Managed control hosting within Word and Excel documents, combined with Excel and Word integration within
the Visual Studio IDE, will reduce the differences that exist today between Office solution development and
Windows and Web-based solution development.
Finally, Whidbey VSTO extends the deployment options for Excel and Word solutions. As with the current
version of VSTO, assemblies can live outside the Office document and be automatically downloaded when the
document is opened. In addition, developers will be able to embed assemblies into documents and thus have
them available even if there is no live connection to the server. A mechanism will exist to update the
embedded assembly if the code changes. Adding the ability to embed assemblies in the document provides a
broader range of options for deploying Office solutions, both online and offline.
Top of Page
SQL Server Yukon Solution Development
As part of Microsoft's plans to coordinate future versions of its developer tools with important platform
milestones, Whidbey will deliver deep integration and support for SQL Server Yukon. Yukon will incorporate
CLR functionality into its database engine to bring a new level of integration between database and tool,
reducing code and effort when developing data-centric applications.
81
First, Yukon will introduce the ability to create database objects in managed code. This enables developers to
build SQL Server procedural objects including functions, stored procedures, and triggers using languages,
such as Visual Basic, Visual C++ and Visual C#. In addition, developers will be able to use managed code to
build new SQL Server objects introduced in Yukon, including User-Defined Types and Aggregates. As a result,
a development team could use Whidbey to not only create and debug the presentation and middle tiers of a
distributed application, but also the database objects that comprise the data tier. Moreover, the .NET
languages will in many respects be richer than traditional Transact-SQL, offering an enhanced programming
model with constructs and capabilities previously not available to the SQL developer.
Second, database objects written in managed code will provide enhanced safety and security. Because these
database objects will run in a CLR environment hosted in the database engine, they will operate within the
context of the fine-grained CLR security model. This model is more inherently secure than the extended
stored procedures available in earlier versions of SQL Server. It also gives administrators greater control to
define a permissible set of actions for the code when attempting to access or manipulate resources either
internal or external to Yukon.
Finally, the use of managed languages to build Yukon database objects will often yield notable gains in
performance and scalability. Because of optimizations built into the Whidbey language compilers and
execution model, database objects, such as stored procedures, functions, and triggers written in managed
code will deliver substantially improved performance over T-SQL in many circumstances.
Enterprise Development and Life-Cycle Support
Satisfying the application development needs of today's large-scale enterprises frequently requires complex,
highly specialized sets of tools, technologies, and design methods. To address these needs, Microsoft will work
with its life-cycle tools partners to deliver products with support for requirements gathering, software analysis
and design, application construction, configuration and change management, application testing, and software
deployment and operations. Together, Microsoft and its partners will offer teams of enterprise developers the
features they need to quickly and efficiently complete mission-critical software projects.
In the Whidbey timeframe, enterprise architects, developers, and testers will benefit from new Visual Studio
enterprise features designed to enrich the application development life cycle. Enterprise customers will gain a
highly productive, tightly integrated suite of tools for project analysis and design, software configuration
management, product build, and deployment.
Analysis and Design—"Design for Operations"
Once the requirements for the application are gathered, organizations often design a detailed architectural
model for their solution. In addition, application architects must be able to reconcile their application designs
with the logical infrastructure in which their solutions will be deployed. In effect, application architects must
be able to design their solutions with the operations infrastructure in mind.
With Visual Studio Whidbey, Microsoft will deliver a set of tools (code-named "Whitehorse") that enable
architects and developers to easily design service-oriented applications and operations infrastructure
simultaneously. Whitehorse uses a drag-and-drop design surface to connect XML Web services, and then
validates the resulting applications against the deployment environment. (Figure 18).
Figure 18. The Web services designer will enable development organizations to complete applications to the
original specification.
82
In offering a comprehensive Web services design tool, Visual Studio Whidbey will enable organizations to
more effectively complete their applications on time and to the original specification. Moreover, rather than
using complex and domain-specific modeling languages as an intermediary format for the application
architecture, the design tools in Visual Studio Whidbey will provide coarse-grained abstractions from classes
to components, Web services, assemblies, activities and processes, and maintain dynamic synchronization
between the application model and the underlying source code.
When creating mission-critical software, application architects often find themselves communicating with their
counterparts who manage data center operations. In the process of delivering a final solution, the
application's logical design is often found to be at odds with the actual capabilities of the deployment
environment. Typically, this communication breakdown results in lost productivity as architects and operations
managers reconcile an application's capabilities with a data center's realities. In Visual Studio Whidbey,
Microsoft will mitigate these differences by offering a logical infrastructure designer (Figure 19) that will
enable operations managers to specify their logical infrastructure and architects to verify that their application
will work within the specified deployment constraints.
Figure 19. The logical infrastructure designer will enable operations managers to specify infrastructure
requirements.
In many cases, enterprise architects and developers will favor a more code-centric view of their solution.
Visual Studio Whidbey will also include a rich class designer (Figure 20) so that even the largest software
projects can be quickly understood and designed.
83
Figure 20. The class designer provides RAD design for enterprise-critical applications.
Microsoft's application design tools will enable architects, developers, and operations managers to participate
in the envisioning phase of application development. As architects design their solutions using the Web
services designer, operations managers can impose constraints using the logical infrastructure designer.
Architects and developers can communicate easily using the application designer and class designer.
Together, these tools enable teams to enjoy better communication and greater productivity.
Configuration Management
Software Configuration Management (SCM) is a disciplined approach to managing and controlling the
evolution of software development and maintenance practices as they change over time. With SCM, enterprise
developers can make safe alterations to existing code, track changes across developers, projects, and time,
manage the build process effectively, and track project defects and issues. By providing project-oriented
software management, Microsoft Visual SourceSafe delivers integrated SCM support for developers using
Visual Studio.
In Whidbey, Microsoft will improve upon the Visual SourceSafe tools and offer programmers working in small
teams the technology they need to manage source code, as well as other files in their solution. Visual
SourceSafe will be extended to offer support for Web service and Unicode projects, helping programmers
more effectively meet the challenges of today's business. Further, programmers will enjoy improved
performance and tighter integration between Visual SourceSafe and the Visual Studio IDE.
Product Build
Historically, developers have struggled when trying to map a complicated build infrastructure into the Visual
Studio IDE. Roadblocks traditionally center around the inability to fully customize or understand what happens
when a project is built within the development environment; the failure to reproduce a build within a build lab
environment where Visual Studio is not likely to be present; and the limitations of a build system that was not
optimized to model entire products, but rather single projects.
The Whidbey release of Visual Studio will radically improve this area of software development by introducing a
new build engine called MSBuild. Key design goals for MSBuild include: delivering a file format that is welldocumented and backed up by a published XML schema definition; making the MSBuild engine an integral
part of the .NET Framework redistributable; allowing developers to customize, augment or completely redefine
the build process; and providing seamless integration with the Visual Studio Whidbey IDE.
First, MSBuild will introduce a new XML-based file format that is simple to understand and easy to extend. The
MSBuild file format will enable developers to fully describe what artifacts need to be built, as well as how they
need to be built under different configurations. In addition, the file format will enable developers to author
reusable rules which can be factored into separate files so that builds can be done consistently across different
projects within a product.
Second, MSBuild will ship as a core part of the Whidbey .NET Framework redistributable. This shift in
philosophy will allow developers to rely on the MSBuild infrastructure regardless of IDE presence and licensing
issues. In addition, by providing MSBuild class libraries as a core part of the .NET Framework, developers will
84
be able to create and debug components of a customized MSBuild process using the managed language of
their choice.
Third, MSBuild will be completely transparent with regards to how it processes and builds software. All build
steps will be explicitly expressed in the XML project file regardless of whether it was authored by hand or
auto-generated by the Visual Studio Whidbey IDE. This also means that Visual Studio no longer treats any
part of the "F5" build experience as a black box. A user can now understand, replicate, edit, remove, or
augment any part of the build process.
Finally like its predecessors, MSBuild will be fully integrated into the Visual Studio Whidbey IDE. This tight
integration will enable developers to take advantage of all the built-in productivity features Visual Studio
offers, while allowing developers to scale, customize, and adapt the Whidbey build system to their unique
infrastructure needs.
Deployment and Operations
In the last phase of the software life cycle, the completed application is placed into a production environment.
The activities in this phase involve creating deployment packages and an operations plan that covers tasks,
such as expected availability, backups, updates, and disaster recovery.
Visual Studio Whidbey, in conjunction with a variety of additional Microsoft and third-party software, including
the Enterprise Instrumentation Framework, Microsoft Operations Manager, and more, will enable
organizations to deploy and operate solutions after they are constructed and tested.
Moreover, the aforementioned Web services design tools will enable operations managers to participate more
closely with the overall development team.
Partner Enterprise Tools Support
In addition to these advances within Visual Studio, enterprise customers in the Whidbey time frame will
continue to enjoy tremendous choice from a variety of the industry's leading application life-cycle tools
vendors. With improved integration support, tools companies will be able to deliver products that offer
seamless interoperability with the rest of the Visual Studio Whidbey product. And, with a revamped Visual
Studio Industry Partner (VSIP) program, independent vendors, as well as enterprise customers can gain free
access to the APIs necessary to build life-cycle tools that are tightly coupled with the Visual Studio Whidbey
IDE. For customers, the result will be a combination of Microsoft and partner tools that make enterprise
application design, development, testing, and deployment significantly easier than before.
Top of Page
Visual Studio "Orcas" (2005)
The Whidbey release of Visual Studio and the .NET Framework will represent a significant milestone in the
Microsoft developer tools roadmap. Following the SQL Server Yukon and Visual Studio Whidbey wave of
products, the next major platform update will be the Windows operating system release code name
"Longhorn". The Whidbey release of Visual Studio and the .NET Framework will run on this landmark
operating system release, as will applications built with Visual Studio Whidbey.
In addition, Microsoft is planning a version of Visual Studio, code name "Orcas," designed to take advantage
of the features introduced in Windows Longhorn. These features include support for Longhorn advanced user
interface capabilities (code name "Avalon"), storage services (code name "WinFS"), and Web services
capabilities (code name "Indigo"). For example, Longhorn will introduce a declarative programming model
(code name "XAML"), that will complement existing programming languages and Windows Forms by
improving productivity when developing Longhorn-specific client UI.
In addition, Orcas will enable developers to take advantage of the WinFS capabilities to find, relate, and act
on information, including support for event-based actions and synchronization classes. Finally, Orcas will
deliver support for Indigo, Microsoft's next generation programming model for building Web services. Indigo
introduces a unified model for developing connected applications on the Windows platform that seamlessly
merges remote procedure calls, messaging, and remote object invocation. Future updates to this document
will include additional information about the Orcas release and feature set.
Summary
With the launch of Visual Studio .NET 2002 and the Microsoft .NET Framework 1.0, Microsoft introduced a
consistent programming model for Windows, Web, and mobile solutions, new and enhanced programming
languages, and its most integrated and powerful developer toolset ever. One year later, Visual Studio .NET
2003 and version 1.1 of the .NET Framework built on the strength of the initial release and delivered
unprecedented integration with the Windows Server 2003 operating system. Moving forward, Microsoft will
continue this trend of integrating managed code support in major product releases—first with SQL Server
Yukon and later in the Windows Longhorn operating system.
85
Over the course of this product roadmap, Microsoft plans a steady stream of innovation in both tools and
framework, offering the businesses of today and tomorrow premier tools with which to meet their evolving
business needs. Microsoft will continue its commitment to delivering productive tools that help customers take
maximum advantage of the underlying platform and achieve success while building a wide range of software
solutions.
(http://msdn.microsoft.com/vstudio/productinfo/enterprise/default.aspx )
from which the link “"Whidbey" Enterprise Tools” leads to
http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/
Roadmap to the Future
Visual Studio Enterprise Roadmap
Satisfying the application development needs of today's large-scale enterprises frequently requires complex,
highly specialized sets of tools, technologies, and design methods. To address these needs, Microsoft will work
with its life-cycle tools partners to deliver products with support for requirements gathering, software analysis
and design, application construction, configuration and change management, application testing, and software
deployment and operations. Together, Microsoft and its partners will offer teams of enterprise developers the
features they need to quickly and efficiently complete mission-critical software projects.
In the Visual Studio code name "Whidbey" time frame, enterprise architects, developers, and testers will
benefit from new Visual Studio enterprise features designed to enrich the application development life cycle.
Enterprise customers will gain a highly productive, tightly integrated suite of tools for project analysis and
design, software configuration management, product build, and deployment.
See the Future of Microsoft Developer Tools (NS see earlier)
Follow the Microsoft Developer Tools Roadmap for the latest details on the future of Visual Studio and the
Microsoft .NET Framework. Learn about groundbreaking innovations in the programming languages,
development environment, and .NET Framework class libraries.

Visual Studio code name "Whidbey" (2004). This release of Visual Studio and the Microsoft .NET
Framework will offer innovations and enhancements to the class libraries, common language runtime (CLR),
programming languages, and the integrated development environment (IDE). In addition, this product will
provide deep support for SQL Server code name "Yukon" by enabling developers to write stored procedures
using managed code.

Visual Studio code name "Orcas" (2005). This version of Visual Studio and the .NET Framework
will provide tools support for the Windows operating system, code name "Longhorn."
Modeling Languages for Distributed Applications
Learn how modeling languages in conjunction with source code based on general purpose programming
languages can reduce complexity and increase the quality of software design and implementation. This paper
introduces the idea of a family of interrelated, but individually specialized modeling languages that the
industry is calling domain-specific languages, or DSLs.
The Visual Studio Service-Oriented Application Designer
Learn about the set of Visual Studio Whidbey designers that comprise the service-oriented application
designer. This suite helps application architects and developers construct Web services-based service-oriented
applications and prepare them for deployment in their target data center.
FAQ: Visual Studio "Whidbey" Service-Oriented Application Designer
Frequently asked questions on the "Whidbey" Service-Oriented Application Designer.
86
http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/default.aspx?pull=/library/en-us/dnvsent/html/vsent_modelinglangs.asp
Modeling Languages for Distributed Applications
Keith Short, Architect, Visual Studio Enterprise Tools
Microsoft Corporation.
October 2003
Applies to:
Microsoft®Visual Studio®.NET
Microsoft ASP.NET
Summary: Learn how modeling languages can simplify the development of distributed applications. (12
printed pages)
Contents
Introduction
Using Abstraction to Reduce Complexity
Designing Connected Web Services
Models Are Development Artifacts
Generating Artifacts from Models
Organizing Domain-Specific Modeling Languages
Web Service Design and Deployment
Conclusion
Introduction
Today's developers are faced with critical business drivers requiring the development of heterogeneous,
connected solutions and the automation of business processes. Meeting business needs has always been a
staple of modern information technology, but developers today are faced with revolutionary changes in their
application platforms and tools. Indeed, developers must implement solutions using novel distributed
application platforms and architectures, such as Service Oriented Architecture (SOA) and Web services.
Together, the evolving needs of businesses and the dramatic changes in platforms and architectures as shown
in Figure 1 are enough to confound even the most seasoned development organizations.
Figure 1. Sources of complexity for developers
Of course, none of these sources of complexity are static. A concerted industry effort is evolving the Web
service platform with increased reliability, security, and other enterprise-grade requirements. But even as the
platform gains stability and completeness, developers still face the daunting task of translating increasingly
complex application requirements into SOA designs, and implementing them using available technology. While
the platform experts, programming language gurus, and interoperability standards committees have much
work to do, we are interested in the role that modeling languages can play in addressing the complexity facing
developers.
In this article, we present an argument for using modeling languages in conjunction with source code based
on general purpose programming languages to reduce the complexity of software design and implementation,
87
and to help ensure the use of best practices to reduce risk, cost and time to market, and to improve product
quality. We'll introduce the idea of a family of inter-related, but individually specialized modeling languages
the industry is calling domain-specific1 languages, or DSLs. We'll describe how such languages might be used,
and the requirements this approach to modeling drives into development environments.
Using Abstraction to Reduce Complexity
Few developers today would argue that they were somehow better off in the days of assembler programming
than they are in using modern general-purpose programming languages such as C# and Java. Higher-level
languages abstract, or hide, more implementation detail than lower-level ones, giving the developer more
coarse-grained constructs that are closer to concepts in the problem domain. They enable developers to
express their intent more rapidly and with fewer expressions. Most modern general-purpose programming
languages hide enough detail to provide a measure of platform independence, but they still require the
developer to render implementations of concepts in the problem domain using large numbers of fine-grained
constructs. In other words, while they are much higher-level than assembly language, they are still much
lower-level than they could be if the goal is to solve problems in specific domains. This gap between intent
and implementation creates complexity.
If we define languages that offer abstractions closer to problem domains, naturally the languages become
more specific to those domains and cease to be general purpose. On the flip side, because the abstractions
are more specific, the developer requires fewer constructs to describe a solution and the amount of manual
labor is reduced.
Let's take a more concrete example. In the early 1990's, developers were faced with the complexity of clientserver technology. Building efficient and effective client-server applications proved to be a difficult endeavor,
initially accessible only by the top few percent of all developers. However, within a couple of years nearly
every developer had become empowered to build efficient, effective client-server applications. What
happened?
For Windows-based client-server applications at least, two things changed. First, Microsoft®Visual
Basic®defined two key abstractions that significantly simplified the developers' task: the form and the control.
Along with a tool with which to edit these abstractions, developers could design user interfaces and express
relationships between controls and forms. The Form Designer generated code from these abstractions, and
developers wrote their business logic for events between controls and forms in clearly separated sections of
the file. Second, the Visual Basic runtime was itself extended with framework code that supported the eventbased programming model. This worked well because only modest amounts of code had to be generated to
complete the framework, keeping synchronization issues to a minimum.
Effectively, the Form Designer and its abstractions, form and control, defined a graphical language in which
higher-level concepts could be modeled. The graphical language of forms and controls allowed the developer
to focus on one specific aspect of development—client-server UI design—and ignore the complex details of
client-server communication protocols. It also made development easier by clearly showing the relationships
between UI elements that would otherwise have been difficult to discern from conventional hand-crafted code.
By tying these abstractions to the event-handler concepts in the framework, the developer clearly delineated
where this domain-specific language or DSL needed to interact with general-purpose languages used to
express business logic. As a result, developers enjoyed an exceedingly productive development environment.
Designing Connected Web Services
Today we are faced with a similar problem of complexity. It takes the top few percent of today's developers to
build a distributed application that supports value-chained business processes defined using Web services.
What are the few simple abstractions that could in a few years enable the majority of developers to produce
efficient, effective distributed applications? What kind of support must be provided for these abstractions in
underlying frameworks?
To answer these questions, let's take a look at the concerns of a developer (or an architect, perhaps) whose
task is to design the architectural structure—the "big picture" view—of services that support business
processes.

How should activities within a business process map to Web services?

What messages flow between these services?

What are the sequences of these messages?

What are the security requirements for the various services?

What services already exist that may be reused?

What are the coarse-grained software components that offer the various services?
88

What wire-level protocols should be specified in order to meet the needs of the target data center?
It's possible to analyze these concerns to define suitable abstractions and a modeling language in which they
can be expressed. This modeling language will help the developer focus on these concerns while temporarily
ignoring others. With a suitable graphical notation—boxes for services, and lines between them summarizing
message exchanges, for example—the developer can get a holistic view of the overall structure of his
application as a set of interacting Web services. Using a graphical design tool based on this new modeling
language, he can experiment with the effect on business protocols of shifting functionality from one service to
another. He can define message structures and operations on Web service ports, and so on. Other tasks such
as defining the code that acts on messages within the service components, the databases that store and
manage the information, and the internal structure of the Web service implementations, can be dealt with
separately. This graphical language might well be called a Web Service Interaction modeling language, or a
Web Service Interaction DSL—actual artifacts expressed in this language would be known as Web Service
Interaction models.
Figure 2. Multiple artifacts and fragments derived from a model
Narrowly focused, domain-specific modeling languages can be very effective at reducing the complexity
inherent in translating domain concepts into implementations. They can offer coarse-grained abstractions that
map to code based on the underlying runtime frameworks. But there's another benefit: in hand-crafted
coding, domain concepts are scattered across multiple development artifacts based on a variety of languages
and formats, forcing the developer to keep those artifacts synchronized as requirements evolve, as in Figure
2. Conversely, the meaning of any piece of the design or implementation is difficult to discern when the
developer is obliged to look at large amounts of code written in terms of fine-grained, general-purpose
primitives. Graphical languages are often more powerful than textual ones in these cases, since they generally
make it easier to see and manipulate relationships among concepts. Interactions between Web services, for
example, are much easier to see and manipulate when visualized graphically, than when scattered across
multiple source code files, schemas and configuration files.
Models Are Development Artifacts
Unlike models used merely for documentation purposes, the models that interest us are first class
development artifacts. They are just as important in the design and implementation of the software as source
code files, schemas and configuration files, in which information is expressed using languages like C#, Java or
XML. Also, they are just as important in later parts of the software life cycle as the files used to describe
configurations of artifacts, to deploy executables, to generate tests, to track defects, or to manage software
execution. The artifacts which are related to a model as shown in Figure 2 must be continuously synchronized
with one another for this to work. This is a very important requirement of a design time environment to
support higher level modeling languages: wherever information is edited, all derived and derived-from
information must be synchronized.
Table 1 shows just how much models based on domain-specific languages have in common, with source code
files based general-purpose programming languages, such as C# and Java, and how they differ.
89
Table 1. Domain-specific modeling languages vs. general purpose programming languages
Characteristic
Domain-Specific Modeling
Language
General-Purpose Programming
Language
Notation
Mostly graphical
Mostly textual
Specificity
Highly specific to narrow problem
domains, such as class interactions or
Web service contracts
Highly generic and intended to support broad
problem domains, such as general purpose
computation
Scope
Useful only for solving specific kinds of
problems in the target domain
Useful for solving almost any problem
Granularity
Offers medium- to coarse-grained
Offers fine- to medium-grained abstractions,
abstractions, from classes to
from scalar values to classes
components, Web services, assemblies,
activities and processes
Expressiveness
Highly expressive, requiring a small
number of expressions to describe or
implement a complex concept
Not highly expressive, requiring large
numbers of expressions to describe or
implement a complex concept
Translation
Generally translated either by a
generator into development artifacts or
pieces of development artifacts, such
as source code and XML, or by a
compiler into optimized executable
instructions as byte code or binary
Generally translated by a generator or
compiler into optimized executable
instructions as byte code or binary
Refactoring
Models can be refactored to improve
their structure for maintainability or
efficiency
Source code can be refactored to improve its
structure for maintainability or efficiency
Patterns
Models can be developed using
patterns that embody best practices
Source code can be developed using patterns
that embody best practices
Composition
Models can be composed from crosscutting aspects that are defined once
and applied to multiple model
elements, such as deployment policies
or security policies in a Web service
modeling language.
Source code can be composed from crosscutting aspects that are defined once and
applied at multiple source code insertion
points, such as error handling,
instrumentation code or security policies.
The key difference is the narrow focus of a domain-specific language. DSLs work well when they are designed
for subsets of a larger set of requirements (such as personalization), subsets of a larger architecture (such as
security) or subsets of a larger development process (such as Web service interconnection). A DSL offers
abstractions specific to some domain, and adds value by helping the developer solve problems in that domain
in a highly efficient manner.
Generating Artifacts from Models
With this approach, models coexist with source code and other artifacts that are related to them. They are not
seen as temporary artifacts used only in analysis and design that can be discarded after generation. Nor can
they can be seen as the sole source of all derived information. Two scenarios illustrate these points:

The developer may be required to modify the artifacts in which the generated source code has been
placed. When this happens, it may be difficult to accurately reflect those changes in the model, or to avoid
overwriting them the next time source code is generated from the model. Poor synchronization usually
forces the developer to abandon the model, since the source code must be correct.

The model may contain information that is not directly manifested in the source code. Examples
include information about relationships between classes or about definitions of business processes that
cannot be deduced from source code, even by an expert developer. Or, information in the model may be
hard to keep synchronized once it has been scattered across derived artifacts. For example, in a Web
services model, a particular configuration of security attributes may be defined as a named security policy
which is then generated into many different kinds of artifacts once the information has been translated into
source code attributes, configuration files, and statements in code, as illustrated in Figure 2. This scattering
compounds the synchronization problem.
Failure to solve these problems effectively led to the demise of early CASE technology. There are many ways
to solve them, however. For example:
90

Generate code and defend it. Generated code is a good thing since it reduces the amount of code that
needs to be written by hand. However, any generated code should be placed in inaccessible hidden regions
or separate files. An example of this approach is the Microsoft Visual Studio®Forms Editor, a graphical
modeling language for describing forms and controls, that generates code into hidden regions. Few
developers bother to look at the generated code. Hand-written code receives control via delegation from the
generated code, or inherits from the generated code to provide necessary interaction between them. Or, as
in the case of Container Managed Persistence in Enterprise Java Beans, generated code can receive control
via delegation or inheritance from hand-written code. Similarly, ASP.NET uses partial classes to put hand
written and generated code in separate files.

Provide a run-time framework to support the abstractions defined by the modeling language, and
generate framework completion code, or declarative attributes in source code, that extend and control the
framework through well-known variability points. An example is ASP.NET, which allows a Web service
modeling language to generate common language runtime (CLR) attributes to control and define Web
service implementations. Again, the interaction between hand-written code and framework code is
managed cleanly through delegation or inheritance in either direction.

Generate only code that can be managed through an API on the source code—never generate code
that would require subsequent parsing of the source code in order to maintain synchronization back to the
model. The .NET languages that support the Code Model APIs in Visual Studio offer this capability, enabling
a synchronization engine to respond to change events raised through the API at design time.
We use all of these techniques in the design-time technology that implements the domain-specific modeling
languages, and in the tools and generators that we will deliver to support them.
Organizing Domain-Specific Modeling Languages
Another alternative for translating a domain-specific modeling language into a less abstract form is to
translate into another DSL for which a translator already exists. When modeling languages are related in this
way, they may be organized using a grid as shown in Figure 3. The columns of the grid represent concerns,
while the rows represent levels of abstraction. Typically, for a given application type (such as a B2C ecommerce application), the shape and contents of the grid represent a set of models, source code files and
other artifacts that must be developed to properly address functional and non-functional requirements in the
course of building and deploying an application of that type. Similarly the path through the grid represents the
set of activities that must be performed, and the transformations between the artifacts that define the flow of
the development process.
Generally, application development is based on progressive refinement, which proceeds from the top-left
region of the grid where business requirements are captured, to the bottom-right where bits are finally loaded
on to servers in the data center. At the same time, however, it is also based on progressive abstraction, which
proceeds from the bottom-right to the top-left. The trick is to provide bidirectional synchronization or at least
bidirectional reconciliation across levels of abstraction, so that this naturally top-down and bottom-up iterative
process can converge. A path through the grid defines the best way to build a piece of an application, of the
type for which the grid was defined. It prescribes the artifacts that must be developed, and the steps that
must be performed to capture the requirements, establish the architecture, produce the implementation, and
to ensure that the application will deploy correctly.
Of course, Figure 3 is highly simplified. Each cell in the grid represents a viewpoint from which we can specify
some part of the application software. In practice each cell contains more than just DSLs—it also contains:

Refactoring patterns that can improve models based on the viewpoint

Aspect definitions that are applicable to models based on the viewpoint

Development processes used to produce models based on the viewpoint

Definitions of constraints supplied by models based on neighboring viewpoints

Frameworks that support the implementation of models based on the viewpoint

Mappings that support transformations within and between models based on the viewpoint or
neighboring viewpoints
The developer can use a model as a kind of control center for applying patterns expressed in terms of the
abstractions supported by the modeling language. For example, when using the Web Service Interaction
Designer, he might use a pattern library that offers parameterized contract and message definitions, which
can be readily applied to services in the model, or one that offers collaboration patterns, such as a service
façade (an aggregate of one or more services that provides managed pass-through of messages to a
subset of the capabilities of the underlying services). Models can also be used to specify aspects and to weave
together their implementations, much as source code is used to define and weave together aspects are in
aspect-oriented programming languages. For example, the developer might define a security policy once, and
91
then apply it to many services by group-selecting them in the model. Patterns and aspects add richness to a
modeling language, promote the use of best practices, and simplify development tasks.
Figure 3. A layered grid for classifying domain-specific modeling languages
This grid is not in itself new. What is novel is defining domain-specific modeling languages for the cells, and
mappings between and within the cells that support fully or partially automatic transformations. As we have
seen, we must use well-defined domain-specific modeling languages, not general-purpose modeling languages
designed for documentation, in order to provide this kind of automation. Given appropriate domain-specific
modeling languages and transformations, we can drive from requirements to executables using framework
completion and progressive refinement, keeping related models synchronized, or at least keeping them
reconciled. We can also drive from executables to requirements using progressive abstraction, building
frameworks, patterns, modeling languages and other reusable abstractions that will prove useful on the way
down.
Web Service Design and Deployment
As an example, let's revisit the grid from Figure 3, and zoom in to the bottom-right corner, as in Figure 4, so
we can look at the viewpoints and the relationships between them in more detail. In the figure, rectangles
represent domain-specific modeling languages, dotted lines represent refinement transformations and solid
lines represent constraints.
92
Figure 4. Part of a set of DSLs for Web service development
The figure illustrates the following:

The Business Entity DSL defines the business entity abstraction, which describes efficient, messagedriven, loosely coupled data services that map onto an object-relational framework. Examples of business
entities include Customer and Order.

The Business Process DSL defines the business activity, role and dependency abstractions, and a
taxonomy of process patterns that can be used to compose them, forming business process specifications.
An example of a business process is Enter Negotiated Order, which might use three process patterns: one
for a User Interface Process to build a shopping cart, one for a sequential process to submit the order and
perform credit checks, and one for a rule-driven process to calculate a discount.

These two DSLs map onto a Web Service DSL that describes collaborating Web services in a serviceoriented application. The Web Service DSL is used to describe how the business entities and processes are
implemented as Web services, how the messages they exchange are defined and what protocols are used
to support their interactions, using abstractions that hide the underlying details of the Web service
implementations. Predefined patterns of Web service interactions, such as service façade, service
interface, and gateway2, can be applied to ensure that the architecture of an application uses best
practices. Model aspects, such as security policies, can be defined and applied at several points in the
model—say for every operation of a group of selected service ports.

A DSL called the Logical Systems Architecture DSL for describing data center configurations. This
allows a network architect to describe a scale-invariant definition of the data center in terms of logical
servers and connections that will be deployment targets for the Web services described using the Web
Service DSL, along with the software they have installed, and their configuration settings. Standard
configurations of data centers, such as the Microsoft System Architecture patterns available from
msdn.microsoft.com can be applied to models based on this DSL.

Information from one model can be used to develop another. Examples are the interactions between
business entities and processes, and between Web services and logical servers. This last one is particularly
interesting because it can be used to design for deployment. Feeding knowledge of the deployment
infrastructure into Web service designs constrains those designs to prevent deployment problems. Similarly,
working this in reverse, if a design is to be deployed on a given logical server type, then we can validate
that the server on which it will be deployed is of the correct type, that it has the right software installed,
and that it is configured correctly. We have called this Design for Deployment (see Figure 5) as it addresses
some commonly described problems in deployment of distributed applications.
Figure 5. Design for Deployment scenario

Mappings drive transformations between models at design time. For example, we use transformations
to map the model of Web services to multiple implementation artifacts on the target platform, in the form
of classes that complete a framework, such as ASP.NET, and various configuration and policy files (see
Figure 2).
93
Conclusion
While abstraction can be used to hide platform differences, we find it much more valuable to use abstraction
to reduce complexity of translating requirements into implementations. In our treatment of model-driven
development, models become artifacts that are equally as valuable as source code is today, and never
become relegated to being merely inconsistent, out-of-date documentation. The underlying modeling
language implementation technology ensures that they will always be consistent with source code and other
artifacts where necessary. Microsoft will build tools that implement part of the grid for Web service
applications and some of the DSLs described here in the next version of Visual Studio. Partners and
competitors will be able to leverage their domain knowledge to implement DSLs using our underlying
infrastructure, which we plan to make available through our Visual Studio partner programs.
This tool-building infrastructure will make it easier to build graphical tools to edit and view models, and will
ensure that the models produced are always synchronized with source code and other artifacts that are
derived from them. Today only a handful of companies define domain-specific modeling languages or build
model-driven tools to support them. We predict that software developers and architects at SIs, ISVs and
enterprises will see the value in building specialized tools or extending those already provided, that enshrine
their best practices, patterns and pre-defined content. General purpose modeling languages, which have
limited ability to be extended or customized, won't meet the challenge; nor will infrastructure that just focuses
on abstract model structure, ignoring the user interface, the visual experience, and model interchange.
Once the metadata inherent within models is available, other development tools can make use of it. Imagine a
powerful metadata-enabled source control system (SCS) that could allow a developer to check Web services
consisting of multiple files in and out. For example, if a well-formed Web service must include certain files,
such as a WSDL contract, a server code file, an XML-based configuration file with entries that match interfaces
ports offered by the service, a metadata-enabled SCS could flag a collection of files that don't satisfy these
criteria as a malformed configuration. Imagine also how a debugger might be made more powerful once
enhanced with metadata. Or imagine how testing tools could become more focused and report their failures
more appropriately if metadata were more widely available. How could compilers be made more effective if
they could exploit widely available, more abstract metadata?
We will address these interesting topics in detail in subsequent papers, in which we'll also describe more
features of the modeling language framework and tool-building infrastructure, and our overall vision for
successive industrialization of application development.
Notes
1 In this article, we'll use the term domain in its most general sense. Domain may refer to a broad set of
problem areas such as banking applications, or manufacturing applications, or to technologies such as the
domain of all ASP.NET applications. But it may also refer to narrow areas of focus such as the security aspects
of any application, or the architecture of applications.
2 These latter two are defined in the Enterprise Solution Patterns Using Microsoft .NET, available from
Microsoft Press.
Overview of the Visual Studio "Whidbey" Service-Oriented
Application Designer
October 2003
Summary: This article describes the set of Visual Studio "Whidbey" designers that comprise the serviceoriented application designer. This suite helps application architects and developers construct Web servicesbased service-oriented applications and prepare them for deployment in their target data center. (9 printed
pages)
Applies to:
Visual Studio "Whidbey"
Contents
Introduction
Background
Common Enterprise Problems
Solutions Provided by the Service-Oriented Application Designer
Service-Oriented Application Designer Features
Conclusion
Introduction
94
The Visual Studio "Whidbey" service-oriented application designer helps application architects and developers
construct Web services-based service-oriented applications and prepare them for deployment in their target
data center. It does this in three ways: by helping application architects and developers design, construct, and
configure services and the components that consume these services; by helping infrastructure architects and
operations teams describe data center architectures including the configuration constraints, logical topology,
and policies to be imposed on applications; and by helping developers and operations teams validate each
application against the data center architecture and its constraints prior to deployment.
Note This is a preliminary document and may be changed substantially prior to final commercial release of the
software described herein.
Background
The Visual Studio "Whidbey" service-oriented application designer encompasses three important industry
trends that are reflected in several strategic initiatives at Microsoft:

Service-oriented architectures

Designing for operations

Executable designs
The service-oriented application designer is a collection of designers that simplify the process of designing and
developing applications based on service-oriented architectures. For the purpose of this paper, a service is
defined as an autonomous computing element that can interoperate in a loosely-coupled fashion with other
autonomous services or service-consuming applications using Web services protocols.
Service-Oriented Architectures
Service-oriented architectures serve as the basis for the next generation of distributed applications. The
recently announced Microsoft "Indigo" platform will provide the industry-leading implementation of serviceoriented applications. "Indigo" will build upon the SOAP and Web services support provided in the Windows
platform today and add support for a comprehensive range of transports and application topologies, enabling
secure, reliable, and durable message-based communications between services. While "Indigo" is the wave of
the future, service-oriented applications can be built today using SOAP, XML messaging, and Web services.
For more information, see the MSDN Web Services Developer Center.
Web services offer particular promise as the means to integrate heterogeneous information systems. They do
so by wrapping intrinsically autonomous systems behind a common Web services-based infrastructure to
enable access from a range of devices both inside and outside the corporate firewall. Web services offer great
promise for so-called "edge systems," enabling new business processes that tap into existing system
resources, as well as the potential to be used increasingly in the fabric of entirely new systems.
Creating highly distributed yet intrinsically de-coupled systems exacerbates many of the problems inherent in
enterprise-scale application development today.
Visualizing the application structure as an integral whole becomes increasingly difficult as the pieces are more
fragmented in a service-oriented architecture. Additional emphasis is placed on the design of interfaces
offered by services. To enable interoperability, these interfaces are message-based. Designing new messages
and ensuring conformance with existing message schemas is crucial. Helping application architects and
designers visualize and design the application as a whole is increasingly important. For more information, see
Visual Studio .NET for the Enterprise Customer.
Design for Operations
The highly distributed nature of service-oriented applications places additional stress on the process of
deploying and managing those applications in the data center. The autonomous nature of these services
means that they can potentially evolve at different rates, thereby placing more focus on the interactions that
occur between development and operations. An increasing obstacle to success is the current practice of
throwing applications "over the wall" into operations and debugging against operational environments that are
different from development environments. The Microsoft Dynamic Systems Initiative (DSI) addresses this
problem by closing the loop between architects, development teams, and operations teams. The serviceoriented application designer is the first set of tools that support this initiative with a focus on designing for
deployment. At the heart of DSI is the System Definition Model (SDM), which provides a unified model for
representing a system at the application, host, network, and hardware layers. With its unified model, it
provides the basis for application configuration to be validated against operational requirements. The first
stage of DSI emphasizes this capability, with later stages building on the same model to add deployment and
operational management tools and features.
Executable Design
95
Traditionally, application design approaches are often informal and supported by little more than a whiteboard
or using applications such as Microsoft Word and Microsoft PowerPoint for writing specifications. Even where
more formal design approaches and design tools are used, these offer only minimal integration between the
design process and the development and deployment processes. Designs are not rigorous and typically do not
specify the kinds of detail required for operational validation. After coding on a project starts, the design
documentation quickly becomes out-of-date and is often rendered irrelevant, making later maintenance or
extension difficult and more costly. Again, the introduction of service-oriented applications and the promise of
agile applications highlight these problems. Those designing complex distributed architectures increasingly
need a visual representation of the system to help them see how the many pieces come together as a whole.
New services interoperate with existing services; therefore, access to accurate interface definitions is critical.
Problems with design or configuration need to be identified early in the process to maximize the potential of
service-oriented architectures to deliver agile solutions.
Improvements are needed for integrating the design activity and development. The design process needs to
be more rigorous and precise, but without introducing unnecessary additional stages or concepts. By
introducing the appropriate abstractions, the design can be made relevant throughout the development and
deployment process. The SDM model again provides the basis for capturing rich metadata during the design
process that can be used both to generate code and to validate the design against the data center definition.
In addition, the design can be kept synchronized with the code and not treated as an abandoned artifact,
which is the case with modeling tools today. Such an executable design remains relevant throughout the life
of an application. With this approach, developers are free to work in code or through the design surfaces,
confident that the definitions expressed in one are synchronized immediately with the other. This also allows a
visual representation of existing projects that can be seamlessly integrated with new projects.
Design and Operations Validation of Service-Oriented Applications
The service-oriented application designer is built upon these three founding blocks: service-oriented
architectures, design for deployment, and executable design.
Figure 1
Service-Oriented Application Designer Workflow
Fundamentally, the service-oriented application designer consists of four designers that work in concert (see
Figure 1) to support the initiatives outlined above.

The Distributed Service Designer is used to create a visual representation of the various services and
application components that comprise a service-oriented application.

The Logical Systems Architecture Designer is used to visualize and describe the logical structure of a
data center, including the settings and constraints that define the restrictions and capabilities of the data
center.

The Subsystem Designer is used to configure components into logical subsystems for deployment.

The Subsystem Hosting Designer is used to create a virtual deployment of a subsystem into the logical
representation of the data center. This designer enables validation of application settings and configuration
against the settings and constraints of the intended deployment environment.
By supporting these strategic initiatives, the service-oriented application designer addresses many of the
common problems that software development teams encounter when creating enterprise applications.
96
Common Enterprise Problems
Some common problems when creating enterprise applications include:

Application integration

Poor communication

Deployment failures

Difficulty configuring application security

Maintenance of service-oriented applications
This section examines these problems and some of their common causes in more detail and is followed by a
section that describes solutions provided by the service-oriented application designer.
Application Integration
Enterprises typically consist of many disparate systems that have accumulated over time as departments
purchase, develop, or acquire a variety of applications. Different departments have difficulty sharing
application functionality or data between one another because the applications might use any number of
programming technologies. In addition, many enterprises pursue strategies to prevent vendor lock-in, which
results in application development teams and data center environments that employ a broad mix of
technologies and standards. Businesses demand an interoperability story; but to date, it has been hard to
provide one.
Poor Communication
In most enterprises, data centers evolve slowly and only change after considerable analysis. The application
architects that are responsible for designing an enterprise application, and the developers that are responsible
for developing it, generally have limited flexibility to modify the data center into which the application will be
deployed.
For the application to be designed, developed, and finally deployed in a given data center, data center
infrastructure and requirements must be clearly communicated to application architects and developers. This
task might be managed by having an infrastructure architect create a diagram that describes the data center
architecture. However, the infrastructure architect will likely create a diagram that represents his view of the
data center (e.g., machines, firewalls, network interface cards, and routers). The resulting diagram may be an
excellent resource for network engineers, but such diagrams are inadequate for application architects and
development teams since they lack the metadata needed for application design and development (e.g.,
security settings and host configuration information).
When application architects do possess the required information about the data center, they need the ability
to communicate this information in the context of their design to the developers implementing the application.
This is traditionally accomplished using documentation, meetings, diagrams, checklists, or e-mail. However,
these communication methods require considerable effort and coordination, and are prone to error because
ultimately each developer must decide how to apply the information.
Once the initial channels of communication are established, more effort is required to communicate changes in
the data center or the application design. Frequently, the original architectural diagrams are neglected and fall
out of sync with the code. As a result, the work and time invested in those diagrams are lost. Additional work
must then be performed to periodically verify that the code being created is still in alignment with the
intended data center.
Deployment Failures
Extensive testing in a development or testing environment can demonstrate that an application is functioning
according to design. However, until the application is deployed into the intended data center, successful
deployment is uncertain because it is impossible to faithfully replicate the data center in the development
environment.
Application deployment generally fails when the environment for which the application is designed and
developed does not exist in the data center. This results in lost time and money as rework is performed to
bring the application into compliance. In some cases, extensive architectural redesign is required.
For the large majority of enterprises, application deployment cannot be attempted on a trial and error basis in
a data center that houses other applications and mission-critical data. Instead, these enterprises use staging
environments until they are satisfied that the application is ready for deployment into the production
environment. Even with these precautions, application architects and developers need some measure of
reassurance that their application is deployable in the data center. Unfortunately, such reassurance is elusive.
Deployment failures can result in lost revenue, missed business opportunities, lost time, and increased costs.
97
Difficulty Configuring Application Security
Securing a distributed application is a time-consuming and complicated process because numerous
technologies and settings are involved that can impact the design of an application. Currently, there is no way
to represent the security configuration of the application or the security requirements of the data center while
designing the application. As a result, it is hard to ensure that security is implemented correctly.
Maintenance of Service-Oriented Applications
A high percentage of enterprise development is concerned with the maintenance and review of existing code.
Very often, those who are responsible for maintaining code are not the same developers who wrote it. For the
newly assigned developer, it is a difficult and time-consuming process to comprehend the structure of an
application and understand the relationship of the different pieces by reviewing the existing code. This can be
further complicated by the absence of current documentation and diagrams to help decipher the application's
design. Furthermore, misinterpretation of the code can lead to regression bugs, which result in increased cost
and risk.
Solutions Provided by the Service-Oriented Application Designer
The service-oriented application designer helps solve the common enterprise problems described earlier. The
solutions are presented in this section in terms of features offered by the design suite. These features are
discussed in more detail in the next section.
Integrating Applications
Using Web services, it is possible to expose the functionality and data of existing applications. Because a Web
service is accessible through a standard interface using ubiquitous protocols, Web services enable
heterogeneous systems to work together as a single web of computation. When Web services are used to
enable application interoperability, the service-oriented application designer can help application architects
and developers think through and visualize the application architecture.
Improving Communication
The service-oriented application designer enables improved communication in the following ways:

The infrastructure architect uses the Logical Systems Architecture Designer (LSAD) to capture the
metadata about the data center that is useful to the application architect and developers. With this
information, the infrastructure architect can inform and constrain the work of the development team. If the
data center already exists, the LSAD is used to define a known configuration to enable the application
architect and developers to validate their application against it. If the data center does not exist, the LSAD
can be used to describe the requirements for a new data center to support a particular application. Using
the LSAD, infrastructure architects can constrain application settings early in the life cycle, which enables
validation at design time against the known settings. This allows for early identification and resolution of
conflicts, which leads to higher probability of a successful deployment and results in reduced costs and
faster deployment.

The application architect uses the Distributed Service Designer (DSD) to experiment with service
partitioning and application design. After settling on a design, the application architect can deliver it to the
development team. The development team can generate skeleton implementations of the Web services
directly from the designer and create Visual Studio projects that they will use to implement functionality.

Application architects can also annotate designs, print them, paste them into documents, and provide
developers with a hard copy of the system specification. This greatly simplifies the task of asking a
developer to implement a service in such a way that it integrates with the work of others.

Both diagrams and code are always kept in sync. Any changes made to the interfaces in code are
automatically reflected in the design diagram and vice versa.
Validating Application Configuration for Deployment
When it is time to deploy the application in the data center, the application architect can use the Subsystem
Hosting Designer to map the application components to the data center described in the logical systems
architecture diagram. Using the Subsystem Hosting Designer, the application architect can specify both
application- and host-level settings, add constraints based on the relationships between settings, and validate
the application against those constraints. By mapping the application to the data center, the application
architect can verify that developers have met all of the constraints defined by the data center prior to
deployment. The Subsystem Hosting Designer provides feedback on any validation errors encountered, giving
the developer the opportunity to fix any violations before deployment and making it more likely that
deployment will succeed.
98
Securing the Application
The service-oriented application designer supports an add-in for configuring security that conforms to the Web
Services Enhancements extensions, and supports constraining and validating a design against those
extensions. For each host and service component relationship, implicit constraints have been described to
enable validation. Support for authoring simple constraints is also provided, allowing infrastructure architects
and application architects to define specific constraints for their organization that can be used to validate the
design of an application.
Maintaining Service-Oriented Applications
The service-oriented application designer makes it easier to understand application architectures built with
Web services. A distributed service diagram can be added to any Visual Studio "Whidbey" solution that
provides or consumes Web services to reverse-engineer an architectural view of the Web service interactions.
This can provide instant, much-needed orientation on an unfamiliar application.
Service-Oriented Application Designer Features
As outlined in the preceding sections, the service-oriented application designer addresses many issues that
enterprise organizations face today. This section describes each tool in the design suite in more detail.
The service-oriented application designer can generate code, forward- and reverse-engineer, and round-trip
code to and from design for a number of component types, such as ASP.NET Web applications. Although many
of the tools can be used independently, using them together provides the greatest benefit.

The Distributed Service Designer (DSD) provides a design surface for diagramming services,
creating components (that is, generating interfaces for services), and creating a reverse-engineered view of
code that incorporates Web services. With the DSD, application architects define communication pathways
by wiring services together. They can then experiment with the application settings and design before
generating skeleton implementations for developers to fully implement.

The Logical Systems Architecture Designer (LSAD) is used to create diagrams that represent the
logical structure of a data center for the purpose of communicating important information to the developer
about the target deployment environment. With the LSAD, an infrastructure architect can create a diagram
of interconnected hosts (software run-time environments) and specify the topology of the data center by
representing system entities such as Web servers, database servers, security zones, inbound and outbound
communication pathways, and communications endpoints. Specifying these and other details of hostspecific configuration (such as protocols and security configurations) informs and constrains application
development. The infrastructure architect can use the LSAD to define constraints on specific application
settings that are consistent with the requirements and needs of the data center. The LSAD can also use
pre-defined diagrams provided by Microsoft that describe recommended system architectures.

The Subsystem Designer (SSD) is used to develop multiple configurations of components defined in
the DSD and address application scaling issues. With the SSD, application architects can generate a
deployable configuration of application and service components. For example, application architects can use
the Subsystem Designer to configure applications to support multiple uses of the same service.

The Subsystem Hosting Designer (SHD) is used to create a virtual deployment of a subsystem into
the logical representation of the data center. It uses input from the SSD and the LSAD to form a binding.
The Subsystem Hosting Designer enables validation of application topology constraints against the target
data center. It evaluates the communication requirements of the application, and ensures that there is a
valid, compatible open pathway between bound software components and logical hosts of the data center
as defined by the LSAD. It also evaluates whether the proper protocols are supported, and validates userspecified constraints against application and host settings to ensure that they are compatible with the
requirements and needs of the target environment.
Conclusion
The service-oriented application designer is a collection of designers that simplify the process of designing and
developing applications based on service-oriented architectures.

Service-Oriented Architectures –Service-oriented architectures are expected to serve as the basis
for the next generation of distributed applications, but it is difficult to visualize their necessarily fragmented
application structure as an integral whole. Microsoft is countering this problem in two major ways: the
recently announced "Indigo" platform will provide the industry-leading implementation of service-oriented
applications and the service-oriented application designer will specifically help application architects
visualize and design applications as a whole.
99

Design for Operations – The service-oriented application designer creates diagrams to represent the
application layer and the host layer of a system. These diagrams help those who design and deploy
applications to validate an application configuration against operational requirements when the application
is first deployed and throughout its lifetime, as the services that comprise it evolve.

Executable Design – Through the unified model in the service-oriented application designer,
application and infrastructure architects capture rich metadata during the design process. This metadata
can be used both to generate code and to validate application design against the data center definition. This
model lets application architects create a more formal and rigorous design. The design stays synchronized
with the code, remaining relevant throughout the application's lifetime, which helps application architects
maintain and extend the application as needed.
The Visual Studio "Whidbey" service-oriented application designer helps enterprises successfully construct Web
services-based service-oriented applications and efficiently prepare them for deployment in the data center.
http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/whitehorsefaq.aspx
FAQ: Visual Studio "Whidbey" Service-Oriented Application
Designer
1. What is the service-oriented application designer?
The service-oriented application designer is a feature of Visual Studio Whidbey that simplifies the architecture,
design, and development of applications comprised of distributed services. The service-oriented application
designer consists of a number of tools, including the distributed services designer, which enables architects to
design their application architecture visually. Developers can work with code generated from this tool and keep
code-changes synchronized with the visual design. Additionally, the logical system architecture designer allows
infrastructure architects to visually model the data center, map the application to the data center and validate it
against the constraints of the application/data center prior to actual deployment. Reports generated from this
help document the deployment mapping.
2. What is the implication of the service-oriented application designer on your currently shipping
modeling tool, Visio?
We will continue to ship Visio modeling tools in Visual Studio Whidbey to serve our current Visio customer base.
However, most customers will require a design tool that is better suited for building service-oriented
applications and will elect to use the service-oriented application designer for building mission-critical Web
services. In addition, the service-oriented application designer enables customers to visually design their
operations infrastructure and validate that their service-oriented application will work properly in the specified
data center.
3. Can I extend the service-oriented application designer with my own functionality?
We have a simple end-user extensibility model for the first release of the service-oriented application designer.
This allows you to take any of the vanilla services or clients (such as Web Services, web applications, windows
applications, external services; external databases) on the distributed services diagram, or any host (such as
IIS, Windows, SQL) on the logical system architecture diagram, and extend it. A richer version of extensibility
would require the release of an SDK and we continue to evaluate our options in this area, but not for the initial
release.
4. Will 3rd party tools be able to use your notation in the service-oriented application designer
and/or will they be able to extend them?
Yes. Microsoft will publish an extensibility framework to help customers build value-added features for the
service-oriented application designer.
5. Is the service-oriented application designer considered an enterprise-level tool or is it meant to
for medium-sized or small-sized organizations?
The service-oriented application designer is a set of design tools fully capable of helping customers solve
problems that occur at all levels or organizations, including enterprises building mission-critical software and
services.
6. What will the service-oriented application designer do for my distributed solution in terms of
security?
The service-oriented application designer will support constraining and validating your design against the Web
Services Enhancements (WSE), IIS Security, SQL Security, and ASP.NET Security. In addition, for each host
and service component relationship, we have enabled pre-built constraints that you can use. For example, you
can ensure that an application component requiring Windows authentication will only deploy to an IIS server
that supports Windows authentication. In addition, we support the authoring of simple constraints as well as
specifying custom settings for the security requirements of your own organization. Your simple and custom
constraints can be validated by the service-oriented application designer too.
7. What languages do you support in the service-oriented application designer?
In this release, we have targeted our features at what we believe is the audience most likely to use them in
association with Web services. So, on the distributed services designer, where Web services are developed, we
100
will support Visual C++ (managed only), Visual Basic and Visual C#. We will continue to review our approach to
this based on customer feedback. Secondly, our class designer, which is clearly a core development tool, will
support all .NET languages provided by Microsoft namely Visual C#, Visual Basic, Visual J# and Visual C++.
8. I have existing code libraries that I would like to be able to use, is that possible?
Yes, if you wrap it as a Web service, you’ll see it on the design surface. All existing Visual Studio project
artifacts will continue to work in the service-oriented application designer so you can continue to build rich
applications. However, for the first version, we will only support visual Web components, database connections,
external web services and windows client applications, but that doesn’t mean you can’t have many class
libraries associated with them.
9. Do I have to hand-author all of the settings for IIS that I need to constrain against using the
service-oriented application designer?
For version 1.0 of the service-oriented application designer, we will ship a tool that allows you to import all of
your IIS settings from an IIS host. You will have to author settings for other host types however.
10. What is the Dynamic Systems Initiative?
Dynamic Systems Initiative (DSI) is a broad Microsoft and industry initiative uniting hardware, software and
service vendors around a new software architecture based on the System Definition Model (SDM). This new
architecture is becoming the focal point for how we are making product investments to dramatically simplify
and automate how our customers will develop, deploy, and operate applications and IT infrastructure. Over
time, support for the SDM will be delivered in Visual Studio, across the Windows Server System family, and in
our management tools - known as System Center.
11. What is SDM?
The System Definition Model (SDM), a part of the DSI, is a live Extensible Markup Language (XML) blueprint
that spans the IT life cycle and unifies IT operational policies with the operational requirements of applications.
It is relevant at both design time and at run time. At design time, it will be exposed through Visual Studio to
enable IT operators to capture their policies in software and developers to describe application operational
requirements. At deployment time, the SDM description of the application will enable the operating system to
automatically deploy the complete application and dynamically allocate a set of distributed server, storage, and
networking resources that the application requires. Throughout ongoing operations, the SDM also enables the
operating system to easily grow and shrink the necessary resources that are associated with a particular
application, based on changing business needs. The service-oriented application designer is an early
demonstration of Visual Studio's support for the SDM.
12. Does the service-oriented application designer support the DSI and SDM?
Yes, what you are seeing in service-oriented application designer version 1.0 is the first iteration of
Microsoft’s Dynamic Systems Initiative (DSI). There will be far more from Microsoft on this in the future.
13. Can the service-oriented application designer reflect J2EE services?
Yes, the service-oriented application designer can interoperate with existing J2EE services using the WSDL.
14. Can I get the service-oriented application designer bits at PDC or soon after via a beta program
etc.?
We are not distributing bits for service-oriented application designer at the PDC. We will make the toolset
available in a forthcoming public beta. The timing for this beta is not yet available.
15. Where can I find further information regarding the service-oriented application designer?
You can find whitepapers, demos and presentations on the service-oriented application designer on the MSDN
website – http://msdn.microsoft.com/vstudio/enterprise. We will continue to update this site with more
information on this and other enterprise technologies in Visual Studio in the coming months.
http://www.microsoft.com/presspass/press/2003/mar03/03-18dynamicsystemspr.asp
Microsoft Announces Dynamic Systems Initiative
Software Architecture Provides Cornerstone for an Industry Effort to Help
Customers Manage IT Complexity, Reduce Costs and Increase Business Agility
REDMOND, Wash. -- March 18, 2003 --Microsoft Corp. today announced the Dynamic Systems Initiative
(DSI). This initiative unifies hardware, software and service vendors around a software architecture that
enables customers to harness the power of industry-standard hardware, and brings simplicity, automation and
flexibility to IT operations. The new breed of dynamic systems enabled by this software promises to streamline
IT operations and lower costs for the enterprise datacenter and make datacenter capabilities accessible to a
much broader array of businesses. The unifying software architecture centers on a System Definition Model
(SDM) that provides a common contract between development, deployment and operations across the IT life
cycle. Microsoft will begin delivering on this initiative with Windows® Server 2003. Support for the architecture
and SDM also can be expected in future releases of the Visual Studio® developer tools, Microsoft® server
applications and management solutions.
"The Microsoft Dynamic Systems Initiative will deliver a significant improvement in simplicity, automation and
flexibility to IT systems of all sizes," said Bill Veghte, corporate vice president of the Windows Server Group at
Microsoft. "By enabling dynamic systems that address operational needs throughout the IT life cycle, we are
101
helping customers take advantage of the great economics of industry-standard hardware to capture
breakthroughs in productivity and cost savings."
The Crisis in the Datacenter
Low-cost, high-volume, industry-standard hardware components and operating systems are becoming the
foundation of the datacenter. However, software architectures and application models have not kept pace with
the rapidly evolving nature of modern distributed systems. With 70 percent of IT dollars spent on sustaining
and running systems, IT budgets are weighted toward maintaining existing capabilities rather than taking
advantage of new opportunities. Operations are an afterthought in application design today; developers don't
have an easy way to describe their application's characteristics and needs for the datacenter, and IT managers
lack the required tools to help them drive IT requirements back into development.
Designing for Operations: The System Definition Model
SDM is a live XML-based blueprint that captures and unifies the operational requirements of applications with
datacenter policies, serving as an explicit contract between development, deployment and operations across the
IT life cycle. Tools supporting SDM will give IT managers the ability to explicitly define datacenter standards
and policies for development, and will give developers the ability to encode operational requirements into their
applications at design time. In the datacenter, the operating systems support of SDM will enable IT
professionals to automatically provision and dynamically change applications along with their underlying
resources as workload or business needs change.
Delivering on the Dynamic Systems Initiative
During the mid-1990s, Microsoft Research initiated a focused effort to examine the operational challenges of
large enterprise datacenters. The result was improved software architecture, aimed at dramatically simplifying
and automating how customers develop, deploy and operate scalable systems. More than two years ago the
Microsoft Research team working on this effort was transitioned to the Windows Server core group, where the
product development effort began. The first results will be delivered with the release of Windows Server 2003.
Over the next three to five years, Microsoft will deliver incremental technology that spans the company's
product portfolio.
Capabilities in Windows Server 2003 include the following:

Automated Deployment Services. New provisioning and administration tool

Windows System Resource Manager. Dynamic systems resource management

Volume Shadow Copy Services and Virtual Disk Service. Storage virtualization

Network Load Balancing. Dynamic load-balancing for incoming traffic

Windows Server Clustering. High-availability and scalable services

Virtual Server. Virtual machine technology for consolidation and migration
An Industrywide Effort
The Dynamic Systems Initiative is backed by a growing industrywide effort, supported by companies such as
Centrata Inc., Computer Associates International Inc., Consera Software Corp., Dell Computer Corp., EDS, HP,
Opsware Inc. and Think Dynamics Inc. The SDM-based architecture will unleash new hardware innovations,
bring new capabilities to development tools, result in rich new management solutions and enable service
providers to bring leading-edge offerings to market more quickly. The SDM, already based on industry-standard
XML, is straightforward and open, enabling customers and partners to build innovative new products and
service offerings around this architecture.
About Windows Server 2003
Windows Server 2003 is a comprehensive, integrated and secure infrastructure designed to help customers
reduce costs and increase the efficiency and effectiveness of IT operations. Building on Windows 2000 family
strengths, the new server platform helps customers extend existing resources while laying the foundation for
building a new generation of connected applications that improve business productivity. More information is
available at http://www.microsoft.com/windowsserver2003/.
http://www.microsoft.com/presspass/press/2003/may03/05-06oemmomentum2003pr.asp
Microsoft Announces Growing Industry Support For Its Dynamic Systems
Initiative
Industry-Leading Vendors Commit to Supporting Automated Deployment
Services As First Step Toward Delivering Dynamic Data Centers
NEW ORLEANS -- May 6, 2003 -- Today at the 12th annual Windows® Hardware Engineering Conference
(WinHEC), Microsoft Corp. announced broadened support for its Dynamic Systems Initiative (DSI), an effort
that will dramatically simplify and automate how customers build, deploy and operate highly scalable
applications. Industry-leading hardware vendors Fujitsu Limited, Fujitsu Siemens Computers, IBM Corp., NEC
102
Corp. and Newisys Inc. are joining early DSI supporters Dell Computer Corp. and HP. These additional
hardware vendors have already begun collaboration with Microsoft through the testing and integration of
Automated Deployment Services (ADS), a powerful new server provisioning and administration tool, with their
respective server hardware platforms and deployment solutions.
Their commitment to collaborate with Microsoft on ADS and future DSI-related technologies will result in the
creation and delivery of Dynamic Data Centers (DDCs), a combination of industry-standard servers, storage
and networking hardware that is connected in a prescribed manner, and dynamically provisioned and centrally
managed by Microsoft® software. The software driving the DDC will enable customers to automatically deploy a
distributed application; provision the associated server, storage and networking resources required for that
application; and dynamically allocate resources to grow and shrink based on business and workload demands.
DDCs will enable customers to more effectively harness the power of industry-standard hardware, delivering
improved flexibility, higher hardware utilization and lower operational costs.
"Solutions that address the complexity our customers face in their IT environments can only be delivered
through the combined efforts of a strong partner ecosystem," said Bill Veghte, corporate vice president of the
Windows Server Group at Microsoft. "We look forward to continued collaboration with this growing group of
industry-leading vendors around innovative DSI technologies that bring simplicity and automation to our
customers' IT infrastructure."
Collaborative Efforts to Benefit Joint Customers Are Already Under Way
Microsoft and these hardware vendors have already begun joint DSI-related development around the System
Definition Model (SDM), the core component of the DSI software architecture that provides a common contract
among development, deployment and operations. These efforts involve ADS, which enables customers to
rapidly and automatically deploy and redeploy from one to hundreds of highly customized Microsoft Windows
Server System (TM) images across their environments in a matter of minutes. ADS uses portions of the SDM
for server provisioning, and it is through testing and integration of ADS with their server hardware and
associated server deployment solutions that hardware providers are able to deliver an improved serverdeployment experience to customers.
Fujitsu Limited will work with Microsoft to integrate Automated Deployment Services with its PRIMERGY servers
and SystemcastWizard product for the Japanese market. "Combined, these products will enable our joint
customers to dramatically simplify and automate the provisioning and administration of Windows Server (TM) in
their IT environments," said Chiaki Ito, corporate vice president of Fujitsu Limited. "Fujitsu is committed to
building long-term relationships with customers by offering infrastructure solutions that increase operational
efficiency and add value to their businesses."
NEC will focus on integrating ADS with the ESMPRO server management suite to help realize the VALUMO,
NEC's own autonomic computing concept, across the family of NEC Express servers. "Delivering customer
solutions that result in lower operational costs and increased business agility is critical to our business," said
Yasuo Iwaoka, executive general manager of the Computer Software Operations Unit at NEC. "We recognize the
important role the SDM can play in unifying our hardware, software and management solutions and look
forward to our collaboration efforts with Microsoft delivering near-term customer value."
"As a leading Intel-based hardware vendor, IBM is committed to providing customers with open and flexible
solutions that result in maximum system availability, increased productivity and lower costs," said Deepak
Advani, vice president of high-performance xSeries systems at IBM. "We feel customers will benefit as a result
of the work IBM xSeries is doing with Microsoft around ADS and the System Definition Model."
Microsoft Delivers Prescriptive Guidance for Building Dynamic Data Centers
In addition to announcing growing industry support, Microsoft today also issued a technical white paper titled
"Building a Dynamic Data Center" to assist server, storage array and networking switch vendors in developing
these innovative new solutions. The white paper provides vendors with required and recommended guidelines
around hardware design features and software components for building a DDC.
About the Dynamic Systems Initiative
The Dynamic Systems Initiative is a broad Microsoft and industry effort that unifies hardware, software and
service vendors around a new software architecture that will enable customers to harness the power of
industry-standard hardware and will dramatically simplify and automate how customers build, deploy and
operate highly scalable applications. Core to this new architecture is the System Definition Model, a live
Extensible Markup Language (XML) blueprint that provides a common software contract between development,
deployment and operations. The SDM will be supported by application development tools, operating systems,
server applications, management solutions and industry-standard hardware, resulting in a new generation of
dynamic systems.
About Windows Server 2003
Windows Server 2003 is a comprehensive, integrated and secure infrastructure designed to help customers
reduce costs and increase the efficiency and effectiveness of information technology (IT) operations. Building on
Windows 2000 family strengths, the new server platform helps customers extend existing resources while
laying the foundation for building a new generation of connected applications that improve business
productivity. Windows Server 2003 is the foundation for the Microsoft Windows Server System integrated
server infrastructure designed for building, deploying and operating agile business solutions.
103