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
EDITORS’ UPDATE, Aug. 27, 2004
— Microsoft has announced it will target broad availability of “Longhorn” in 2006, and make key elements of the Windows WinFX developer platform in “Longhorn” available for Windows XP and Windows Server 2003. See
press release
.
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.
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 protocol-based. 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.
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.
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.
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.)
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 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.
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.
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 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.
KEVIN LISOTA: My Bat computer also doesn’t have VGA resolution. So the next device we’ve got here, this is actually the latest Pocket PC Phone Edition device. So this has 128 megs of memory on board, it’s got integrated BlueTooth support, and if I flip this guy around here, you’ll see that it also has a camera onboard, so a real powerful Pocket PC phone device.
ERIC RUDDER: That’s pretty cool.
KEVIN LISOTA: Our friends over at Dell have been doing a lot of work with their Axim line of Pocket PCs, so this guy just came out a week or so ago. This is the Dell Axim X3I. So the interesting thing here, they’ve got a real slim form factor and it’s got Wi-Fi support on board as well.
We’ve got more. The utility belt is full today.
So our friends over at Sierra Wireless have actually been doing some great work on the smart phone form factor. This is a device they call the (Voke ?) and the (Voke ?), the interesting thing here is that they’ve taken the phone form factor and they’ve built in a flip-out QWERTY keyboard for those of you who do a lot of text messaging. (Applause.)
ERIC RUDDER: Well, that’s kind of cool. You know, Bill showed, yesterday showed the two new phones, he showed the Motorola phone and one of the others, too. I tried to get Bill to come out in the bat costume to show us all the smart phone devices but for some reason I couldn’t get him to go.
E-mail on the devices is kind of amazing. I was talking to some of the engineers the other day. When we actually designed Exchange back in the day when I joined Microsoft we actually designed it for a target machine that had less CPU power and less memory than some of the machines that we’re actually showing today, which doesn’t necessarily mean we’re going to run Exchange Server on the device — (laughter) — but if you think about the amounts of processor power that Moore’s Law has delivered and where these devices are really heading in the future and the types of application that you can build on it, it’s incredible.
KEVIN LISOTA: All right, so the last device out of the utility belt here is the latest from our friends at HP. This is the iPAQ 4155. This is a great little device. It’s actually got integrated Bluetooth support. And it’s also got integrated Wi-Fi in a very, very small form factor that fits nicely in your shirt pockets. Of course, Batman doesn’t have a shirt pocket but it will fit nicely in Eric’s shirt pocket.
ERIC RUDDER: I have a shirt pocket.
KEVIN LISOTA: But I’m going to take that one back, because I really want to take that one home.
ERIC RUDDER: Really?
KEVIN LISOTA: Oh yeah. (Laughter.)
ERIC RUDDER: We’ll have to talk about that behind the stage, Batman.
KEVIN LISOTA: Thanks, Eric.
So that’s just a quick glimpse at some of the devices that have come out in just the past couple of weeks. I wanted to bring out our Boy Wonder lead program manager, Ori Amiga, who’s going to talk a little bit more about programming for these devices using Visual Studio .NET and the .NET Compact Framework. Ori? (Applause.)
ORI AMIGA: Holy developer physique, man; you’re certainly not as slim as that device. But tell me this, can I get this at this conference?
KEVIN LISOTA: Well, actually if you haven’t seen it already, the folks over at the Mobile Planet store, HP and Microsoft are sponsoring a really big discount on the latest iPAQ devices. So visit the Mobile Planet store over in the expo hall and you can get your hands on them while the supply still lasts.
ORI AMIGA: Cool. What about my smart phone developer needs? Can I get a smart phone to develop on with the Compact Framework in ROM?
KEVIN LISOTA: Yeah, actually, Ori, they’re actually selling the smart phone developer kit over there as well, so you can get a development and test device so you can trial the Compact Framework development on the smart phone.
ORI AMIGA: Sweet. Does it get any better than that?
KEVIN LISOTA: Well, if you’re one of the lucky people to attend one of the Windows Mobile sessions or a .NET Compact Framework session this week at PDC they’re actually going to be raffling off a whole bunch of V37 Viewsonic Pocket PCs as well.
ORI AMIGA: Slick. Thanks, Batman.
So what we’ve shown you today is some of the incredible rocking innovation we’re doing on the hardware side in the device space. Some of these devices with VGA, integrated camera, Bluetooth, Wi-Fi, telephony, just amazing, but the really cool thing that Eric mentioned is you can go out there today with a Pocket PC and Smartphone 2003 SDKs in your bag on the Longhorn DVD and start building managed code apps.
But what I want to do right now, Eric, I want to show you a glimpse of the future generation Windows mobile platform and how we’re going to enable you to take advantage of all these great features.
So let’s step back over here and what we have here is a prototype smart phone device. It’s running the “Whidbey” version of the Compact Framework. It’s got a camera. It’s got Bluetooth.
And one of our core tenets, our core pillars in the next release is really go focus on empowering C# and VB .NET developers to leverage virtually every aspect of the platform. We’re talking about our rich notification architecture, our Pocket Outlook namespace with access to mail, contacts, calendar, tasks, virtually all the data on the device, our XML configuration system, telephony, SMS, camera, DirectX, location, Web services and much more.
And instead of just talking about these, let’s go ahead and show you just how easy it is to build an app on this device.
We’re going to start with Visual Studio and create a new smart device project. In our case we’re going to call it our claim application to interface with the insurance back-end that you’ve seen earlier. We could target a smart phone or just as easily a Pocket PC or a generic CE device.
You’ll notice that Visual Studio allows me to quickly drag and drop controls on my form. It’s got the right size for me, 176×220 pixels. If this was a VGA device or a landscape device, the IDE adjusts automatically.
Also, only the controls that are available on this platform are showing up and so we can go ahead and drag a combo box, notice the right size for the form. I could drag a picture box on and we’ll bind that to the camera in a moment. I can set properties just like I can for a desktop app. In this case we’ll stretch the image. We can go ahead and add a label control. I can even create menus dynamically in the IDE and we’ll call this the submit menu to submit some data that we capture on the device. We can great a get image menu, which would allow us to call the camera. I can generate the event handlers for the menus automatically.
And all I have to do now is go ahead and wire up some of these controls and my app is ready to go.
So the first thing we’re going to do is create a new item store. And a new item store basically allows us to reference the contacts database on the device. That’s all we need to do now and now I can just bind this to the camera box, set the data stores to be mystore.contacts.items and that’s it, two lines of code, something that today is native to take me a couple hundred lines of code. Also I’d have to do that manually in managed code today. Two lines of code and we’re bound to the database.
The next thing we want to do — that’s pretty cool but let’s see if we can get an image from the camera. What does that take?
So I can instantiate the new camera object, one line of code. I can get an image to my picture box by doing camera.getimagefromfile. I can also create a bitmap right from that image and that’s all it takes, three lines of code and we’ll be able to get data from the camera.
So that’s pretty slick, again something you can’t really do in native code today. But what if we want to automatically get the location of the where the image was taken right on the device without any user interaction. Can we do that? Well, using our new location platform we can instantiate a new sensor. By the way, this is a pure subset of the Longhorn APIs for location. And I can ask for a location report and say s.currentlocation and let’s ask for an address support. And address support is going to return me not only my address but zip code, city, state, country, et cetera. So that’s pretty slick.
So we’ve got an image, we’ve got a database bound to a camera box, we’ve got a location report, but now I want to go off the device, talk to a Web service that’s running remotely and get some additional data, so let’s do that.
I’m going to go ahead and add a Web reference. In our case we’re going to add a reference to a weather Web service. And this is just as easy to do on a device as it is on the desktop. I’m going to go ahead and add the reference and that’s it. Now I can call it and get the data. I’m going to drag over a quick code snippet. We’re going to extract the zip code from the location report. We’re going to get the weather from the weather service and we’re going to display this on the form.
So last but not least, I want to take all this data and submit it to my claims processing system via an e-mail. So all I have to do is a new e-mail message, again a new capability on the device, something that could take you a thousand lines of code to do native, for example. I can quickly add the contact from the camera box, add the subject, add a body, add an attachment as the image and submit this to the store, and so it’s really that easy.
All I have to do now is hit F5 and we’ll switch over to our device. And now what Visual Studio is going to do is ask me what platform I want to debug on, the device or the emulator. I click deploy and now VS is going to deploy my debugger to the device, it’s going to digitally sign my applications so I can run it and debug it on the phone. It’s going to grab all my satellite DLLs so I don’t have to worry about what other dependencies I have. And it’s going to load up the execution engine, load up my apps and we’re going to be able to start debugging it.
And again this is just as easy to do on a Pocket PC in VB .NET or even in Windows CE.
Here’s our form. Naturally Bill Gates is the first contact in my address book. I’m going to go ahead and pick Eric to submit the claim to. We’re going to click the Get Image button, which is going to start up our camera control. And you can’t really see this but let’s zoom out a little bit. There’s my Bat Mobile that’s having a little bit of an accident over here with the Joker. We’re going to put that back in the podium and since I have a break point right where we’re about to retrieve location Visual Studio is going to break at this breakpoint hopefully any second now and we’re going to be able to step through the app and we’re going to be able to F10 while the code is running on the device, we’re going to talk down to the location platform on the device, get longitude, latitude, we’re going to extract the zip code. Let’s hover over that. There we are, 90015. (Applause.) Cool.
We’re going to hit F10. We’re going to talk to our weather service, given that zip code, and retrieve some additional info. We’re going to hit F5 and keep running the app and in a second or so that weather info is going to get back to us and we’re going to aggregate it all. We’re going to put it on the form, submit the claim and see that in action.
And so how many lines of code here, we probably have less than 20 meaningful lines of code to build this entire app.
Let’s go back to our phone. There is our form. There is the image. There is the address of where we are. There is the data from the weather service. When I click the submit button that e-mail is going to get created for us. It’s going to tell us the claim submitted successfully. I can now look in Outlook and we’ll wait for this mail to come in and check this out: the address, the weather and even the attached picture from the camera. (Applause.)
So to summarize this, I really want you to take a second and think about what we just did, less than ten minutes we built a smart phone app, we laid out the form, we bound it to a database on the device, talked to the camera, talked to the location services, went out to a Web service, sent an e-mail, built it, deployed it, debugged it in under ten minutes. It’s truly phenomenal; we’re very excited to enable mobile devices in this way.
Thanks very much. Thanks, Eric. (Applause.)
ERIC RUDDER: Well, that’s kind of awesome. So now we’ve seen the smart client, we’ve seen the Web client and we’ve seen what we can do with devices, again all integrated into one company running Web services as their key architecture.
We’re going to kind of switch now and talk about rather than deploying to the devices, how we take those Web services and actually deploy them to IT infrastructure. And the key initiative that Microsoft has for making it easier for developers and IT professionals to work together is called our Dynamic Systems Initiative or sometimes DSI. And at the core of it is a technology, which we call SDM, or System Definition Model. And the idea is that the folks in IT can codify their policies and then the developers can actually see on their desktop, okay, hey, I know from my application IT runs their servers this way, it requires this set of things, when I drag over we’ll actually check it on the fly. And it prevents the situation where everybody has to kind of come in on a weekend to deploy the application; developers, IT, it’s all hands on deck.
Because you can do the validation up front it enables the operations managers to specify the infrastructure constraints and it lets the developers actually validate against the infrastructure constraints without having the infrastructure set up, so they can sit in their office, they don’t need a huge cluster of servers, they understand the policy, and it allows for explicit contracts across the entire lifecycle.
The technology that we use to bring together our designers and our deployment is called “WhiteHorse” and I want to invite Rick LaPlante, who’s the general manager of that group, to come on out and show us “WhiteHorse” in action. (Applause.)
RICK LaPLANTE: Hey, good morning, Rick. Thanks a lot.
Well, so as you’ve been hearing throughout this conference, service-oriented applications are becoming more and more prevalent. And when we go out and we talk with customers who’ve actually successfully deployed this type of application, we’ve actually seen a couple of recurring best practices.
So one of them is that these customers have stopped thinking about one application or one service at a time and have really started thinking about the set of applications that are connected via Web services.
So the second thing that they’ve really focused on is they’ve tried to move as much information, as sort of Eric was talking about, as early into the design process the information about the deployment environment so that they can be used to inform the actual decision in doing the service creation.
So at Microsoft we certainly believe that tools can help customers along this path very quickly in a couple of specific ways. The first one is to make it easier for developers to create, visualize, edit the relationships between all those services. And the second is that with tools we can focus on the problems that teams face when they move these systems into the datacenters when they run into configuration and policy problems.
So, to that end, in “Whidbey” we’ve built a set of design tools, code-named “Whitehorse,” that are built on a concept that we call Design for Operation. And this concept is really focused on these specific customer pain points of building service-oriented applications and then deploying them.
So, with that, let me show you a sneak preview of just some of the designs that we’re actually going to be shipping in “Whidbey.”
So what you see here, this is our new service-oriented application designer. So today most of the modeling tools you would use, if you used them, are really a starting point or used as post-mortem documentation for your implementation.
ERIC RUDDER: I wouldn’t know. I’ve actually never documented anything before, during or after.
RICK LaPLANTE: Well, you know what? It turns out you’re not going to have to worry about that with “Whitehorse,”, Eric, because in “Whitehorse,”, the designers are actually in the implementation are kept in continuous synchronization. So that means there’s no model to get outdated and there’s certainly no step that you have to take in the end that creates some sort of documentation of your application.
In this case, this designer here is really just a view of the metadata that exists in your project system already. The metadata exists in your source code, your project system, your configuration file, the (???) files and proxies. And all of that information is visualized to help you understand your service-oriented architecture.
So let’s talk about some of the things that are on this designer, ok? Let me start out by pointing out these big boxes. These big boxes are application services. An application service is simply a piece of software that communicates with other services by sending and receiving messages.
Now, these little boxes out here on the edge, these represent end points of communication. This is really the way in which a service sends and receives messages but today they’re implemented as Web services and in “Longhorn” they can also be implemented as “Indigo” services.
So this designer supports a drag, drop and connected model of application services. And you can use it just like a white board. So I can create services, I can define messages and the methods, I can create the edit relationships between all of those things.
So what I’m showing here right now is actually a completed Woodgrove Insurance system, which includes the application that Ari and Scott had already demoed earlier. So wouldn’t it be nice to know if these application services will actually deploy in our datacenters?
So what I’m going to do is I’m going to show you how we actually go about that. So today, you know, this is a very time- and resource-consuming process, very error prone process and as you said it’s why everybody gets pagers and has to come in on the weekends.
Architects develop or design these systems and developers implement them, but whenever it comes to putting these things into deployment we always seem to run into conflicts with how our datacenter is configured. And it turns out, when we look into this problem, devs really have no idea how your datacenter is configured. You know, in many cases, they don’t even know if there’s a firewall sitting in between two services that they’ve designed. And all that information really needs to be put in front of the developer so they can make better design decisions.
So, using “Whitehorse,” we can check if the system is ready to be deployed in a three-step process. The first step is that a datacenter architect would capture the logical view of the datacenter and they do that to communicate the information back to the engineering team.
The second step is that we take that logical view of the datacenter and we integrate it directly into the development environment, which enables architects and developers to make better decisions.
And then the third step is that we validate those services that they conform to our policies.
So let me show you how we would actually use this diagram in a design phase for an IT project. And we’re going to use it to provide really the context for an application design and implementation.
So in this case, in the Woodgrove case the operations team has already completed the first two steps. They’ve created for us a logical infrastructure model and then we’ve loaded that logical infrastructure model into Visual Studio. So to validate that these services will actually deploy I’m going to place them on that diagram. And to do that, I’m going to right-click and select Create Service Bindings.”
And what you’re going to see here is a designer that you’ve probably never seen in Visual Studio before. This is actually a view of my logical datacenter. This is a diagram that was created by the Woodgrove operations staff specifically for the purpose of communicating to the engineering staff. And this diagram isn’t like the network diagrams you’ve seen before, that it sort of excludes all the gory details that don’t really influence application design.
The primary function of this is to capture and then visualize logical server types and network segments in the datacenter. This is really important, because everything on this diagram here has configurations, settings and policies, which must influence my application design.
So there’s a lot of data that’s actually represented on this diagram and I’m not going to go over it all but let me just go over a couple of points here.
So one of the things that I’ll point out is that these boxes here are what we call logical server types. Now, they’re logical because they represent one or 100 machines that are configured the same way using the same policy in my datacenter.
ERIC RUDDER: That’s great. That’ll actually work in conjunction with the management tools that we’re shipping. So if we define, “Hey, in my shop, this is the way I want to run IIS when it’s configured at the edge,” I just define that once and I can spread it across the entire cluster.
RICK LaPLANTE: Absolutely. And then we will enforce the application services that you put on that machine, conformed to that policy that you set up. And we’ll show you that in just a minute.
So the other thing that’s on here is we’ve represented things that we call zones and zones really represent either logical or physical communication boundaries between the servers and my datacenters.
So let me give you an example of how Woodgrove operations, the operations team, has used zones and server types in this example.
So, first of all, they’ve created a zone, which they call the DMZ, that illustrates the communication boundary. Now, in Woodgrove’s case, this is actually a physical network segment protected by firewalls. And we use zones to impose constraints on what protocols are allowed to come in and out. Now, in this case, the only protocol that’s allowed to come in and out of this zone is HTTP.
The other thing I’ll point out is that this is Woodgrove’s definition of a hardened IIS machine. And if I select here, I can actually see that we use server types to constrain what IIS can do by setting its metadata settings. And in this case, you notice that it’s already set up to not allow Web services to run on a hardened IIS machine. In our architecture, in our datacenter architecture we expect all Web services to either run on our application services or our data services machine and not out in the DMZ. So you’ll see how we use this information a little later.
The important thing to remember is that server types and zones are extensible. Now, Microsoft, we will ship a set of predefined configurations based on the Microsoft systems architecture guidance, but you can create your own to convey your datacenter types and then you can share it within your organization.
So remember, Eric, that this is not just a picture. Using all of the metadata about the operation, the datacenter, as well as the application services, we’re going to validate that the services that we’ve built, that their settings are compatible with the datacenter policy. So to validate, I’m going to just drop these services onto the host that would actually host them in deployment.
This is a list of all the services that were on my other designer and I’m going to drag and drop one of these onto one of the server types. And what you’ll notice here is if I try and drop it onto the hardened IIS box, it won’t actually let me drop because, as we just said, this box doesn’t allow Web services to be deployed there. So let me just put them down in a couple of places where they actually can be deployed.
Now, we notice these machines are capable of hosting Web services but we also want to know are there further problems with mismatched communications that don’t actually match the datacenter policy? And to find that out, I can right-click and select Validate. And what you’ll see is it immediately we’ve actually found another problem that would have surfaced at deployment time if we weren’t using this tool. And this problem is that this data services host here says that anything that I host must use impersonation to talk to the database and you just put a service on me that doesn’t use impersonation.
Well, the nice thing is if I double-click on this, this is something that you can fix in the configuration file but what configuration file do I actually fix it in? When I double-click on the error, I am taken directly back to the service designer and the Web service configuration of the configuration file that has the error in it. So I can simply go to the property window, change impersonation to True. That will edit the configuration file, and I can just revalidate from this diagram. So you’ll notice that we have no more errors. (Applause.)
So basically, what we have here is we now have a set of services that conform to the policies of our datacenter and are ready to deploy.
Now, what I want to point out is what you’ve just seen is really the first part of delivering Microsoft’s Dynamic Systems Initiatives vision. You will be hearing a lot more about that at the conference and over the next several months.
All of the metadata and all of the designs that I’ve shown today are persisted in the system definition model schema. And that SDM schema is core for all DSI work. That SDM schema is the same data that will be used later for deployment of these services, dynamic machine configuration and management of these services.
So within “Whitehorse,” in “Whidbey,” we focus on three things: improving design experience for service-oriented applications, helping organizations bridge the gap between application design and data center operations, and setting ourselves up for “Longhorn,” “Indigo” and the Dynamic Systems Initiative.
So thank you very much. (Applause.)
ERIC RUDDER: Thanks, Rick.
RICK LaPLANTE: Thanks, Eric.
ERIC RUDDER: That’s kind of amazing. As part of my job, I actually have the privilege of running Microsoft.com, and we get into these situations with Datacenter policy and developer productivity all the time. And having really developers understand the policy and being able to check it right there, it might seem like we saved a few minutes, but some of these scenarios actually take hours and hours and days to debug. So the fact that we can actually validate end to end through the lifecycle is an incredible boost in productivity.
You saw one of the things that we checked for in policy was actually security policy. And I want to spend a minute talking about security priorities and what we need to do as a community. We talked yesterday, especially in Bill’s keynote, about Trustworthy Computing and the principles of secure by design, secure by default, and secure in deployment.
And it really requires all of us to change our methodology for how we develop code. We need to be much more proactive during development. All of you, in your bags for the PDC materials have got this pretty thick book called “Writing Secure Applications” and I really encourage you to take some time and flip through it. There are some great chapters in there about how to build threat models and really drive secure designs in your application.
It’s important that you engage in reviews of your code. Fresh eyes on code are one of the best ways to actually perform security reviews.
And take advantage of managed code and the new security tools. And one of the promises I made is that the tools that we use internally at Microsoft to detect things like buffer overruns and heap exploits we will productize. So you’ll see in the next version of Whidbey some of the technology that we call pre-fast that we use for checking for buffer overruns. There’s enhancements to the GS Compiler flags to help with some stack-based errors. And you’ll see lots of tools coming out to help you but they only work if you use them, and my call to action for you is to make sure you take advantage of that.
Think about what features you really need to be on when your app is deployed. You’ll see us actually shipping more and more of our software with the features off by default.
Think hard about the appropriate levels of access control and run your components with the least possible privilege. We do a lot of design reviews where we see a lot of components running as admin privilege, which really can compromise the entire system if the component is compromised. And so we really want people to run at the appropriate privilege level.
And think about adding new defensive layers to your application. Some will actually take on the burden, like Scott showed you in the user management system, but there are areas probably where we can all benefit from a little bit more defensive layers using encryption or other techniques to kind of increase the security that we provide.
And think about when your application goes into deployment. A lot of times you see applications that don’t necessarily work behind a firewall for employees at home accessing applications that we build. And we see a lot of applications that aren’t as antivirus friendly as they can be. So think about how firewall and antivirus interact with your solution.
And make sure that you create security guidelines and documentation for your project and your staff as well.
Jim outlined not just the security roadmap but the entire client roadmap yesterday. I wanted to spend a minute clarifying some of the server and tools roadmaps. Bill talked about the waves of technology roadmaps and kind of now we’re in the Windows Server 2003 wave, if you will.
We have a significant enhancement coming up soon for services for UNIX. It’s incredibly helpful if you’re just interoperating with UNIX in your shop and you want the command-line utilities or you need NFS connectivity. But it’s got great developer features in it for bringing UNIX assets off of Solaris onto the Windows platform. It’s got support for the key UNIX libraries. We’ve added P-Thread support to the platform. And you can compile with the UNIX subsystem and get up and running in no time at all.
Exchange Server shipped a couple of months ago and that complements what we’re doing with Office 2003. And we’ve also introduced a new server called Live Communications Server, which provides real-time capabilities to your application. I think a lot of us are adding a lot more real-time features to our applications going forward.
In the management platform, we introduced SMS 2003, actually a few days ago. And in 2004 we’ll complement that with a product we call MOM, Microsoft Operations Manager.
At the end of this year or maybe January of next year, we’ll ship BizTalk 2004. That’s our workflow product. It kind of will anchor what we call Jupiter, which is kind of our e-commerce suite of applications. And then towards the middle or second half of 2004, you’ll see Visual Studio “Whidbey” and SQL Server “Yukon” actually be delivered. So we’ll deliver these technologies before we deliver “Longhorn.”
And, of course, we’ll have an update to Windows Server, which we’re calling “Longhorn” Server — surprise — based on the “Longhorn” technologies as well.
One of the best ways to keep apprised of our roadmaps and what’s going on and what’s in data is really to take advantage of the resources that are MSDN. For the PDC we’ve created a new site called PDC Central. You’ll find all the presentations and event materials up there. It was live kind of before we came to the PDC but we’ll continue to post information, we’ll continue to post samples. And based on your feedback we’ll keep that site kind of around.
But we expect it to really blend into the “Longhorn” dev center as we move forward, and that’s really the place to keep in touch for new content on Longhorn, new documentation updates to the SDK, the annotations and the community that we work together on as we build the platform. We’ll have editors blogging, we’ll have RSS feeds of our content out. So if you want to be updated using your blogger notification, we’re kind of in this together.
And we’ll kind of build some new sites on MSDN which we’re calling labs, which are really technology playgrounds and kind of places to play, kind of in the tradition of GotDotNet work spaces, giving people areas to share and really build a community around the next wave of platform development.
I think I’ll summarize the call to action the same way Bill and Jim really do, which is focus on the fundamentals — security, no reboots, great error messages. Think hard about building connected systems with Web services. Write your new code using the managed technologies. Take advantage of the great smart clients at the edge and build the best applications that you can. And really get involved in the community.
I think our commitment to you is really winning together by us being a respectful member of the Windows community and really all of us using it as an ongoing dialogue. We take the feedback that you guys provide at the PDC and online and TechEd and in all of our major events and minor events and coffees and user groups and (???) meetings very seriously and a lot of the features that you saw today in the demo were based on your suggestions. And the only way for us to improve our tools and our platform is to continue to get that feedback.
We promise to ship you world class tools as soon as we can, ahead of the platform, so you can fully realize your potential. We’re going to continue to work with the entire industry ecosystem to get ready for this change. If you see at the show flow and if there are press events, we already have more than 40 of our ISVs committed to updating their products to the “Whidbey” and “Longhorn” level and we’ll continue to prime the market for the next wave of opportunity.
We promise to deliver a breakthrough platform for innovation and opportunity for you.
I want to thank you for your time this morning and I want to thank you for coming to the PDC. We’ll see you later.
Thank you. (Applause.)