ERIC RUDDER: Thank you for coming. I think its important to take a stand on the hard issues, so I kind of labeled my title slide
“Slide Zero.”
(Laughter.)

Before I get started, how many of you were actually at the PDC last year? If you could applaud? Its hard to see up here. (Applause.) Thats good. How many of you actually played with beta 1 or beta 2? (Applause.) Thats pretty good. And how many of you have actually written and deployed your first Web service? (Applause.) So thats pretty good. I think were going to have some fun today.

Im going to quickly recap on the three pillars that Bill touched on, XML Web services, client-server services and great user experience. Im going to spend most of my time giving a technical overview of .NET, drilling into the .NET framework, talking a little bit about performance and security and showing you how we use the framework and actually how we take and build the .NET My Services, and then Im going to actually touch on .NET features and kind of give you a sneak peek at some stuff were working on in the future.

Well, what are the three pillars? Bill clearly laid out XML Web services as a huge bet for us. Its truly our next generation app architecture and we expect it to span implementations, because obviously its built on a standard of specs, organizations and geography boundaries.

Applications are being composed of clients, servers and services, and the .NET framework, which Im going to talk about in a few minutes, delivers a unified programming model for building these next generations of solutions.

And, in fact, as you build these solutions, the solutions themselves become application networks. You actually might build a solution and then take that and expose it as a Web service, and well talk about some examples.

And finally I think its important to note that the great user experience really prevails. You know, customers buy great solutions. And in addition to being anytime, anywhere, on any device, truly exploiting the capabilities of the device to its full potential is key to building great solutions.

So the application architectural model is starting to change. As this slide shows, you can kind of see your application will start to be composed of clients, servers and services. And the .NET framework is the fabric that ties it together using XML Web services.

You know, historically weve focused on building nodes, you know, one of those little rectangles, and really now were moving to an environment where we focus on building systems. And I think in addition to thinking through how your architecture is going to change in how you build your applications and solutions, I think its important to think about the opportunities this presents to you as an ISV as well. You know, in the past ISVs have clearly sold apps, theyve sold components and I think its important to think about how youre going to sell services to other ISVs as well.

Well, Bill hinted at some of the business benefits of Web services, but I want to explicitly outline them. The first is clearly we think its best of breed business integration, and one of the things we designed Web services for was to make sure that we could really stitch together these technology islands — if you deploy into a corporation, theres clearly legacy databases, connectivity, and we made sure that the connectors are there so that Web services can fit seamlessly into an organizational environment.

The second point I want to highlight is that federation provides a consistent model, but that organizations actually control their own information and applications. I think theres actually been some confusion on this topic and people are afraid,
“Oh, if I start using services, then Microsoft is going to own all my information,”
and thats not true. When you take Windows .NET Server and you federate using open published specifications for Kerberos, you as the corporation actually control at the boundary what information stays inside and what information gets shared with others. So well give federations control points of presence as you develop your solutions.

The second set of business benefits is really that Web services are resilient, and theyre resilient in a couple of different ways. One is that their resiliency changes in implementation. Clearly this is important, because not only are we implementing Web services, but the industry ecosystem is moving to Web services as a whole. But as we upgrade, as you change how you deploy your application topology, so say that you get a lot of load and you start to add servers, clearly you want your Web service to keep functioning, and the converse is also true. You might decide you want to do server consolidation and still the Web service should continue to function. And finally its resilient to some technology choices that you make. All the work we do in the .NET framework actually gives you a choice in what transport you use and what encoding techniques you use as well.

Well, lets take a simple scenario and see how a Web service can actually be used in many different contexts. Say you build something like a quote engine. You might start out using it in a typical intranet client/server application. You know, here Ive like a call center client, so if somebody calls up, they want a quote or information about rates, you know, your client app simply calls the quote engine and you can quote the rate over the phone.

But what happens, lets say you have a mobile sales force, right? Those guys are out on laptops, theyre disconnected, theyre offline. You can actually take that same Web service and use it to build your offline mobile solution.

Well, say, you know, the business is expanding, this e-commerce stuff is great and you now actually want to gain distribution by having partners sell your products, but you want your partners to quote the right prices. So you can actually take this Web service and expose it over the Internet and publish this information, publish this application to a partner.

I think its important to think about how the Web service architecture is more than just calling services over the Internet. You know, its more than just services in the intranet. It truly is an architecture that will span many different scenarios.

Okay, well enough talking about Web services. Were at the PDC, after all. I think its kind of time to see more code. Id actually like to invite Scott Guthrie out to see how the .NET framework and tools work in action, building on some of the work that Anders did this morning. Welcome.

(Applause.)

SCOTT GUTHRIE: Thanks.

ERIC RUDDER: So what are we going to do today?

SCOTT GUTHRIE: Well, earlier this morning Anders Hejlsberg walked us through building a simple XML Web service built using ASP.NET and C# that exposed some orders data from the North Wind database. He then went ahead and built a client front-end using Windows forms that called that Web service and exposed that data.

What Im going to for the next couple of minutes is extend that scenario even further, this time building some server application front-ends that actually also call a very similar Web service and present and interact with that data. Im going to build everything in VisualStudio.net, but just to show how easy it is with ASP.NET were just going to go ahead and actually build the entire application from scratch, targeting both desktop browsers as well as mobile devices.

Im going to type in all the code in front of you, no application templates, no copy/paste. Youre going to see everything on the fly.

ERIC RUDDER: Okay. So were flying without a net here.

SCOTT GUTHRIE: Flying a little bit without a net. Which language do you want to use?

ERIC RUDDER: Well, I dont know. Its kind of an audience involvement thing. Maybe the audience could choose which language. C#, VB?

AUDIENCE: (Shouts.)

ERIC RUDDER: It sounds like VB to me, I think. (Laughter.)

SCOTT GUTHRIE: I heard C#. I heard COBOL. I heard Fortran.

ERIC RUDDER: I promise later on well get the COBOL fans their fill later on in my talk.

SCOTT GUTHRIE: Yeah, theres 25 or so languages you can use. Some of those that were mentioned are ones that I actually know, and so were just going to kick it off. What well do is well do two languages. Well do the first demo in C# and then well go ahead and a little bit later VB. It would be interesting to watch me do COBOL on stage for both you and me. (Laughter.)

But anyway lets go ahead and kick it off and then actually do it in C#.

So to set up the scenario a little bit more, were going to go ahead and hit a North Wind Web service. This is very similar to the one that Anders showed you earlier today. Ive made one modification, which is that his Web service, he had a get-data method that you could pass any arbitrary SQL data and get back, execute a result and get back some data.

What Im going to do is, I modified it slightly to make it a little bit more realistic and instead just have a get-orders method off this Web service and what I do is actually it allows me to type in a date. It will go ahead, hit the database, execute a query and return all the orders that were placed on that specific date.

So what Im going to do to begin with is go ahead and build a front end for a desktop browser app that calls that Web service and presents some simple UI for me to interact with.

So to do that were going to use VisualStudio.net. Im going to hit New Project. Were going to use C# as our language. Well select ASP.NET Web application down here and hit Okay.

This is going to go ahead and create a project template for me to use, create a blank page for me and at the same time register this application with IIS, so Im good to go. Now I have a blank page here.

So what Im going to do with this page is build some simple UI. Its all going to be HTML, which means it will work against any browser device, whether its IE, Netscape, Opera on any client offering. Theres no client smarts required.

Were going to make this the North Wind order history page, format it to look somewhat pretty.

Since I wanted to go ahead and hit total orders for a specific date, the first thing Im going to do is say,
“Hey, select a date.”
And what better way to select a date then lets drop a calendar control. It will help automate it for us.

And this is what we call an ASP.NET Server control, which means its declared in a tag, in this case the ASP calendar tag, with a run at equal server attribute. And what will happen at runtime is ASP.NET will parse this tag, create a .NET class that represents it and well have a class thats actually running and representing the calendar on the server, so that we can interact with it.

I could set styles on it using the property grid, or because Im not much of a designer, I can pull some simple styles or pre-formatted styles that someone who has design taste has actually come up with, and make it look attractive there.

So what Im going to have someone do is select a date, were going to write some code in a little bit to call a Web service. The last thing I just want to do though in terms of the UI is drop an order listing. So once I get that order data back, I want to go ahead and display it. To do that, Im just going to take the standard data grid, and also format it to look a little pretty. Make that bold. Now I have all my UI defined.

Now, the next thing is to go ahead and call that Web service. To do that, lets go ahead and actually add a reference to that Web service into my project. Its going to go off, pull down the SOAP contract for that particular Web service and import it into my app. Now, that Web service happened to be built with ASP.NET, but it could just have easily be built with any vendor that supported SOAP and open XML. Its not tied to any specific platform.

Now that Ive imported that Web service, all the remains is for me to write the code. To do that, Im just going to double click, add an event, a server-side event handler on that calendar control. Youll notice even before I type that the code is actually cleanly separated from the HTML content so that I can have my developers and my designers working together nicely.

All I need to do then now is lets go ahead and instantiate that proxy object, that Web service that we created by adding that Web reference. And Im going to go ahead and call that proxy method called
“get orders”
and again using statement completion, and I want to pass in the date that I want to get the order information for. To do that, Im just simply going to say
“Calendar one.select a date”
, return the selected date and well just go ahead and data mine this to my data grid and cause it to data mine.

Hit Save and go ahead and hit Build and lets go ahead and run this. We only added three lines of code, but now I have a simple UI page and when I select a date, it calls a Web service and finds the resulting data.

(Applause.)

It works with any browser device, because its just standard HTML being sent down.

ERIC RUDDER: Thats pretty cool, but you know I hear all this talk about supporting smart devices, and its nice to have great browser support, but show us some device support.

SCOTT GUTHRIE: Sure. So what this page is doing right now is it works against any what we call desktop browser, so anything like IE, Opera, Netscape, where you assume that the screen is going to be displayed at a fairly decent size like we have up here.

Theres a whole other class of devices that is emerging, which are mobile devices, very, very small form factors, maybe two inches by three inches in terms of screen size. And obviously something like this page isnt going to look that great on that kind of device.

The good news though is with ASP.NET we have built-in support via a set of what we call the ASP.NET Mobile Controls that are available as part of the ASP.NET Mobile Internet Toolkit. So I can go ahead and download that and it makes it really easy for me to target those types of form factors. And, in fact, we even have simple project types that you can use inside VS to target those and thats what were going to do now is build this exact same thing. Well use VB this time. I heard a few people call out VB. And Im just going to say create a new mobile application. This is going to create another ASP.NET application for me to use. Its going to predefine a page thats using the mobile ASP.NET Server Controls. And all Im going to go ahead and do now is basically build that same UI, this time targeting a small device.

Now, a couple interesting things about small devices: One is, as I mentioned earlier, they have very small screen factors. So rather than put all that information, both the calendar and the grid on this page, what Im going to go ahead and want to do is actually separate them up into two form elements on the page, one of which well use to actually collect the date, the other one well use to basically display the resulting orders.

The other thing about mobile devices is that they dont all support HTML. A lot of them support, for example, WAP WML or HDML or a variety of different sort of markup formats, which means that if I want this page to truly work with any device, I cant build HTML. The good thing is though our server control automatically encapsulates those differences for you, so I can just set this label guy on here, North Wind Orders, set the style to be a title, and then if its on an HTML device its going to output sort of a bold title-like font using, say, maybe an H1; if its on a WAP cell phone it will actually use it in the appropriate markup for that device as well.

So Im going to go ahead and drag and drop my calendar again and the list control on that second form tab, import that Web reference, that Web service, downloaded and created that proxy object for me just like before, double click and Im going to go ahead and write my event handler.

This time its in VB. Thats the proxy. Thats the new
“local host.North wind.”
Call that method just like before. In the last step, so its basically the same three lines now in VB as those ones in C#, but one additional line Im going to add is because I have those two form elements, I just need to go ahead and remember when I select a date, Im going to change the active form thats displayed to read the second form, which is the form result.

ERIC RUDDER: So even though you have multiple pages, youre actually able to keep the same code and the server understands the page scope?

SCOTT GUTHRIE: Correct, yes, absolutely.

All I need to do now is End Build and now I have a mobile app.

So lets go ahead and test it out. Im going to go ahead here and test it out on a variety of different devices. The first one Im going to use is a Pocket PC device equipped with a wireless little card here, so I can go ahead and walk around stage if I wanted to. Im going to keep it here so you can see it though. And all I need to do is hit that page. Its going to make a call to my Web Server. Its going to display the simple page. I havent formatted the calendar quite as prettily. You can do that obviously to make it a little bit cleaner.

But what I can go ahead and do now is simply select a date. Its going to pull up a listing of my orders, click on a specific order ID and its going to go ahead and actually drill into those details and actually again call that Web service and display the resulting data on the screen.

(Applause.)

So thats one particular form factor, the Pocket PC. Weve already seen a browser. Now weve seen it on a nice three inch by two inch screen.

Theres yet another type of form factor, which is even smaller, for example, a cell phone. And theres billions of them out there, millions of them out there and theyre growing every day. It would be great if I could take this exact same app and go ahead now and display it on a cell phone.

Well, the good news is if I target using ASP.NET and the mobile controls I can actually do that, and thats what I have up here right now is Im going to go ahead and run a simulator, a phone simulator built by a third party called Open Wave. And what youre seeing here is sort of the little skin that actually looks like a phone, but inside this little display its actually calling my Web server, getting back — in this case its saying its an AT & T cell phone that supports WAP, so its going to go ahead and actually display WML on this device, and its talking to my server where all my logic is actually living.

Now, the screen on this particular cell phone is very small. Its not nearly as big as the Pocket PC or a desktop. And as a result I cant actually display a calendar to select that date. So what the calendar control has done though is its smart enough to go ahead and say,
“Okay, I dont enough real estate. Instead Im going to have a UI that makes a lot more sense, which is the ability to select a date using your phone itself without having sort of a calendar paging like UI.”
I didnt have to write any code to do that. Its going to give me the option of todays date. It lets me type in a date or I can go ahead and just choose a date. This is sort of ideal where I have an up and down key, so if I dont really want to have to type something into my phone, I can just drill in here, select a date range, pick a date. It goes back to the server, calls that particular Web service, saying,
“Hey, I have three orders,”
and now I can select an order and pull up and actually see the order details on my phone.

ERIC RUDDER: Oh, thats pretty cool. And the server was doing all the make-it-right work for the client.

SCOTT GUTHRIE: Yep, the server did all the work. It doesnt require any smarts on the client, so it will work with any phone out there. Likewise for the Pocket PC, it doesnt require any smarts, as well as the desktop, so it works with any device. The total lines of code you saw up here to build the desktop app was three lines of code that you had to write and for the mobile app you only had to write four lines and now you can literally target millions of devices out there.

ERIC RUDDER: The next time Im going to make you work harder. Thanks, Scott.

SCOTT GUTHRIE: Thanks a lot.

(Applause.)

ERIC RUDDER: So I hope Scott gave you a little taste for the fact that we think ASP.NET is ready. In fact, one of the things were happy to announce is actually MSN.com will go live this week with ASP.NET technology.

Well, Scott showed how Web services could be used in many different contexts. And its important to note that we think about Web services in many different contexts as well. We focus on clearly thinking about scaling away, right, Web services spanning organizations and geographies, and this has kind of gotten most of the attention. But we also think about scaling out, right, how can you take a Web service application and just by adding machines scale the number of clients that it supports.

We think about scaling up our large sub systems. Paul Flessner will show some numbers for our scale up on the Unisys E7000 that are pretty impressive.

We think about scaling in on a machine, right, this is the laptop scenario where you have an application actually calling the Web service within a single box.

And, of course, we think about scaling down to devices.

So when we think about taking Web services everywhere, scale means a huge variety of challenges for us as we take this application architecture forward.

Well, weve done a lot of work to make XML Web services a reality. The truth is theres still even more work to be done. And today I am happy that we are announcing the global XML Web services architecture to help take XML Web services to the next level. This architecture provides a coherent, general purpose model for adding new advanced capabilities to XML Web services.

Today, people are having a lot of success with XML Web services, but there are still some things that are left as an exercise for the developer, for example, security, transactions, reliable messaging.

The global XML Web services architecture gives us a modular, extensible, composable way to add additional capabilities like these.

As part of the architecture, today we are posting four new specifications to our Web Site, WS Security, WS Referral, WS License and WS Routing. We intend to standardize all of these protocols just as we have the previous XML Web service specifications. The architecture also provides a common reference for future capabilities.

Lets take a look at what this looks like. At the lowest level, the Internet and the Web is great infrastructure. And with the introduction of XML, it became possible to exchange much richer semantics between organizations. And Microsoft worked with IBM and many others in the community to create SOAP and truly SOAP is as important for application level communication as TCP/IP was for networking.

It turns out just exchanging SOAP messages isnt enough. To be a viable basis for application development, we need reflection mechanisms, just like we have in modern programming languages. We work with others to describe the messaging end points in WSDL and to provide mechanisms for finding these end points. Microsoft was also a leader in defining a white pages-like mechanism, Disco or newly renamed WSDL, and a yellow pages-like mechanism, UDDI.

So this kind of box over here, this is what lets the IDE take advantage, auto generate those proxies, provide features like statement completely and directory, and theyre a key part of expanding the Web service architecture.

Since we introduced .NET, weve been talking with you to identify best practices in security, messaging and large Web service-based applications. And weve taken this feedback that youve given us, and weve actually built these mechanisms into our runtimes and servers so that you can use them broadly. In other words, weve taken on more of the responsibility for building the plumbing so that you can focus on building your business logic.

Above the Web services and these new modules that weve been working with the industry to create, were also hard at work creating infrastructure that makes it even easier for applications to work together. So reliable messaging looks at the corner cases to make sure that you dont lose information during business communications. Eventing makes it possible for Web services to alert the client when there are changes in the service. It takes away all these pooling loops that you have to do today. And finally were working to address the huge challenge of enabling transactions across organizational boundaries.

Well, again I think sometimes a demo is more exciting than looking at the PowerPoint architecture, so Id like to invite Vic Gundotra out here to show you how global Web services can help you build your applications. Hey, Vic.

(Applause.)

VIC GUNDOTRA: Thanks, Eric.

You know, XML Web services have taken the industry by storm, and its very exciting to see how system vendors like IBM, Oracle, even Sun have endorsed and are supporting the XML Web services model.

But as Eric pointed out, theres so much more we can do to move XML Web services standards forward. You know, we can and we will make that underlying infrastructure, that fabric more capable and thus it allows developers like us to build cooler apps, more functional apps on top of that.

So what Im going to do this morning is highlight some enhancements that Microsoft is working on in partnership with the industry to move that XML services standard forward through the global XML Web services architecture GXA.

Im going to focus on four areas. Im going to talk about improving performance, security, routing and finally reliable messaging. So lets talk about those for a minute.

You know, as everybody knows, the SOAP version one specification described sending SOAP packets over HTTP, and obviously HTTP is widely adopted. Its on everything, mainframes, PCs, cell phones. And thats contributed to the success of SOAP.

But, of course, there are some limitations. HTTP has some very significant performance limitations. It requires me to, for example, send binary information as text, right, I have to do base 64 encoding on the server, I have to decode it on the client. Further, I have to layer SOAP on top of HTTP. Imagine though if you could put SOAP natively over TCP or UDP and you didnt have to worry about doing the conversion from binary to text and you didnt have to do extensive parsing and buffering, well thats exactly what a new proposed standard, DIME, does.

DIME stands for Direct Internet Message Encapsulation and it provides the ability to put SOAP natively over TCP and send binary transfers without having to worry about all that parsing.

Let me give you a demonstration. What youre looking at on the machine here is a Web service that goes out and calls an image archive, and it calls that image archive and it brings down these images. You can see the SOAP request and response that Im calling out to get those images. This is using standard SOAP today. If you look down here at my SOAP response, you see where that cursor is, look at that body, so you can see that that image is being converted over to ASCII, to character. Im doing that basic before encoding, incurring the cost on both the server and the client and bringing that down and parsing, looking for the end of that stream.

But keep your eyes on the image as I enable DIME and watch what happens. You can visually see the performance jump we get right away. How did that happen? Ill show you the three things. Let me stop this.

Number one, Ive added that DIME header into my SOAP request, and then in my SOAP response youll note Im getting the binary image back as well as the payload length, so no more parsing. These simple enhancements can dramatically improve performance.

Lets talk about another area. Lets talk about security. You know, clearly youve seen in the demos, in Bills talk, in Erics talk creating a Web service has become very, very easy today. But getting a bunch of Web services to have a common mechanism to do secure access and authentication, now that can be problematic — not that its not possible; its just that everybody does it their own way. Some people use SSL; others might use something like public key X.509 certificates, and so there is no standard mechanism to provide end-to-end security.

Well, the new proposed standard called WS Security proposes to solve that problem by putting right into the SOAP packets themselves a flexible architecture that allows you to embed the security credentials.

Now, WS Security doesnt mandate a particular algorithm. If you want to use Kerberos or public key or cleartext, you can do that. In fact, let me show you here. You note that the images that were coming down had a watermark on them. Obviously thats what this Web service serves up to an anonymous user. But if youre authorized, you get those images without that watermark.

So Im going to go ahead and using WS Security Im going to type in my credentials. Im going to use a public key mechanism, and if you look at the SOAP request header, youll note that there is my WS Security header. Youll note that Im using an X.509 certificate and there embedded in the packet is my certificate, my key.

Let me switch over to use something like Passport, which as we pointed out will use Kerberos and so sure enough look at my header, change to Kerberos and there is my Kerberos ticket right within the SOAP header.

So Ill go ahead and log in and start and hopefully Ill get authenticated here. There we go. And now Im getting the images without the watermark.

So hopefully you can see how WS Security starts to provide an ability to build Web services that cross organizational and trust boundaries. Its pretty cool.

All right, let me move on to another thorny problem, and thats the problem of name resolution. Imagine for a moment that you have two Web services built by two different companies, and those Web services need to call each other. Now, imagine that, as you might expect in the real world, those two companies have their respective firewalls. Well, when you try to make that call to the other companys Web service, what happens? Well, you cant do it. The name doesnt resolve. Because of the firewalls and the network address translators on both of those companys sites, its impossible to make those things connect.

The problem is even worse for consumers. If youre trying to build a peer-to-peer consumer application, think about what you have to face. You know, you have someone at home whos got a machine, maybe connected via DSL or a cable modem. You write a Web service. You try to expose that to the outside world. What happens? Well, chances are your service provider, your cable or DSL provider has a firewall, a network translator that prevents the name of that Web service from being globally available on the Internet. Heaven forbid you have a firewall at home. Now youve got a double layer of indirection. Youve got another network address translation problem within the home or the office where that Web service is set up.

Let me illustrate that problem. Let me switch over to another machine. Okay. What Ive done is this light bulb here is connected to a machine via X.10 controller, and as you might expect, weve written a Web service on the local host that toggles that light on and off. So, in fact, Im going to flip the switch here on and off, and you can see from this local machine, Ill turn it on again, I can enable that light to turn on and off.

Im going to switch to a different machine now. This is a local machine driving that. Let me switch to a different machine and bring up that same application on this machine. So were going to make that Web service call to the other machine now and were going to toggle that light bulb on and off from the remote machine, just making a Web service call.

Okay, I got an error. Whats going on? Well, what we did was we put this machine behind the NAT, and when we made that call the name was not resolved. You cant resolve the name. And so you get an idea of the problem we face.

Well, a new standard called WS Routing and WS Referral, these two standards work in conjunction to solve this problem. What they do is they embed within the SOAP packets the handoff route. Certainly the firewall knows about the NAT. The NAT knows about my machine. And thus if we specify the appropriate hand up to the final destination, right, it could work.

So Im going to enable that header. You can see its being inserted into my SOAP request there at the top. Of course, if Im going to go through that firewall, I want to add the appropriate security header as well. And now that Ive added to my SOAP request, lets see if that light works. Lets cut it off. There you go.

(Applause.)

Now, lets keep moving on. What else can we do to the underlying infrastructure? Well, let me start cycling that light bulb. Im going to ask that light bulb to go on and off a few times, but Im going to throw a curve into it. Taking the network cable, Im going to disconnect it. Now, Ive disconnected the machine from the machine that controls the X10 controller. When I connect the network back up, what happens? I think there was a series of messages left to go. That light didnt blink ten times. Nothing happens. What happened to the rest of those messages? Well, obviously they just fell off the end of the net. Theyre lost in the ether.

Now, if you as an application developer want to solve this problem, you know, particularly if youve got messages that are far more important than turning a light bulb on and off, you have a lot of work to do. Youve got to think about how do you queue up those messages, how do you guarantee against loss, maintain ordering.

Well, WS Reliable Messaging works to solve those problems. What this does is it builds that into the underlying infrastructure and it guarantees message delivery, message order and prevents against duplication. Let me turn that on now.

Okay, you can see here right there that its blinking. Im adding that header into the SOAP request header. Ill restart that cycle and the light continues to go. In this case, Im going to disconnect, okay, just as last time. The messages have been sent. But this time watch what happens. How cool is that?

(Applause.)

DIME can give you better performance. SOAP security can start to allow you to run through organizational and trust boundaries, giving you a common model, a flexible but standardized model for end-to-end Web service and security. And finally you saw there with WS Reliable Messaging were really working to make that underlying infrastructure is robust against message loss.

Thanks, Eric.

ERIC RUDDER: Thanks, Vic. (Applause.)

So I think Vic really showed you what global XML Web services can do, and hopefully that demo also illustrated the importance of having a rich XML Web service architecture thats composable. So, for example, sometimes you need reliability but not security. Sometimes you need security but not reliability. Sometimes you need security, reliability and performance. And you as a developer get to mix and match the capabilities that you need for your Web service moving forward.

Well, lets take a deeper look inside the .NET framework, which is what we use to build these services. The key thing about the .NET framework is that it provides a unified programming model. So not only do we deliver XML Web services but we have one way to write code that spans clients, servers and services, so you dont have to learn a complete new class library every time you start to develop another part of your solutions.

The .NET framework was designed for developers and to maximize developer productivity. That means design time support is actually built into the framework itself, so we can see those fancy tools doing cool layout things and cool wizards and builders, thats all built into the framework itself. And we made sure that we focused on the hard core plumbing so that you could focus on the higher level services for your users.

The .NET framework provides for simplified deployment and maintenance. You saw some of the zero touch deploy in the first demo. Great performance and we provide an intense focus on security, and Ill talk about each of these moving forward.

Well, sometimes we think about the .NET framework as including four parts, the core presentation services, communication and data. The core technologies really span all the areas of the framework. There are things like our component model, the fact that we use XML throughout the framework, transactions and our focus on the abilities, scalability, reliability, manageability.

The component model really lets developer focus on their code, and it enables this industry of partners where you can mix and match components to help build your solutions.

XML is used everywhere. We use it for serialization. We use it to store the documentation, the data schema. We use it for configuration. Its XML through and through, not bolted on.

Security is designed into the core engine itself. We monitor every operation and we enable security enforcement at a very granular level.

Presentation, I think the key here is that we enable both rich and reach using the same model, and youve seen that in some of the demos today.

The data benefits, really the key there is that we provide the best of relational and the bets of XML while preserving transactional integrity and providing access to any data source.

And the communication benefits, clearly we focus on making Web services simple, but sometimes you actually need to hit the metal and our communication framework actually covers the full spectrum. So if you need access to raw sockets, you know, that capability is in the framework.

Well, the core of the .NET framework really is the common language runtime, or what we call the CLR. You know, fundamentally it provides for multi-language support through a common type system. It allows for the simplified deployment. It enables code access security. And fundamentally the framework and libraries are designed to make it easier to navigate, discover and leverage your existing knowledge.

The CLR is designed to completely eliminate COM plumbing, so theres no more registration, no more GUIDs, .IDL files, age results, I-unknown, Add Raf Release bugs, you know, all that goes away. (Applause.)

And finally its important to note that were actually standardizing the CLI, which is a subset of the CLR, through ECMA, and Im actually proud to announce that the technical committee is actually on track for a mid-December general assembly meeting, where well actually publish the specs.

Well, we provide for broad language support. Youve seen VB. Youve seen C#. Youve seen C++ today. Some of you may know we even announced support for the Java language targeting the .NET frameworks last week. Here are some examples using script. You could applaud for your favorite language when it hits the screen. So for people who like JScript, Perl or Python, those are all supported.

I promised wed get into some COBOL code. I dont want to drill too deeply on this. Its been a long time since I actually earned money writing COBOL code. And actually I earned more money writing RPG3. We could have a breakout session on that later. But we support RPG, Fortran, a whole bunch of business languages, even APL and Small Talk, and even some of the more experimental languages like Scheme, IFUL and Motrion.

So as Scott mentioned, we have over 25 languages that are currently under development using the .NET framework and the CLR.

And the important thing to note is that truly the greatest language minds in the world are working on .NET, both at Microsoft product teams, you know, folks like Anders Hejlsberg, Stan Lippman, whos the C++ pioneer who just joined us, Andrew Clinick, Scott Wiltamuth, Peter Golde, Eric Meyer, Greg Meredith, Chuck Mitchell, Patrick Dussud, you know, true language pioneers.

Also we have an incredibly talented staff at MSR, Microsoft Research, folks like Simon Peyton-Jones, Luca Cardelli, Dave Hansen. These are world famous scientists.

And in conjunction theyre working with the greatest minds in the industry, folks like Bertrand Meyer, Hal Abelson, Martin Oderfsky and many other scientists throughout the world.

I think the thing that they really like is that the .NET framework and CLR make it so easy to experiment with language syntax, language context, language runtime, and I expect lots of language innovation to continue to pervade the CLR and everything we do. So its nice not to have a static, fixed language that you cant change and develop around.

Okay, lets take a look at what happens when you actually write some code and how it winds its way through the CLR.

Clearly you start with source code. You pick your favorite compiler via C#, Java, VB or COBOL. And we produce something called an assembly, and the code is actually stored in a format, an intermediate language that we cleverly named MSIL — Ill let you guess what it stands for. And metadata really is one of the key architectural elements thats stored in the assembly, right?

All the stuff that was previously scattered all over the place from COM, the registry info, the type lives, theyre now in the assembly.

Okay, so after youve done your developments and hopefully compiled without any errors, its time to do a deployment. And we basically give you three separate options for deployment. You can actually write a traditional installer and install to the global assembly cache, sometimes called the GAC. And the global assembly cache enables versioning support and so you can actually have different apps bind to different versions or the same version of the same component. So for a large solution where you might be sharing components across many different solutions, you actually might want to use the global assembly cache.

We also allow you to deploy to an application directory. Just by simply xcopying the files, you can actually deploy your Web applications. In the case of this type of solution, we actually use component sharing well use side by side.

And finally we actually allow you to install just using the browser, and here we actually use the download cache that the Internet Explorer uses. So you get the same benefits for incremental downloads that the caching and the Internet security zones are leveraged as well.

So I think its nice. Thats a case where one of the things weve tried to do as we develop .NET is take the best of Windows and the best of the Web and marry them together, and I think weve done that through installation.

Okay, well youve built your code, youve deployed it. Its time to actually take a walk through the CLR and start executing on the machine, executing your code.

So the first thing is at execution time is well actually hit the assembly loader. And the assembly loader is responsible for locating the correct version of your assembly based on the application configuration and machine policy. Administrators have a say in how these applications are deployed and what components theyll allow solutions to run with as well.

The security engine then constructs a security policy based on the enterprise settings, the machine settings and the rules in the application itself. It grants permissions based on what the assembly asks for, the evidence, and determines the security policy.

The class loader is basically what youd expect. Its the piece of the run time that literally loads the class into memory.

If necessary, we then invoke the IL to native compiler, and this is simply the piece of technology that is responsible for converting this intermediate language into native code so that we run with the best performance.

And again the developer has a choice: Compilation can either be done at install time or you can actually do it at runtime or either a method by method basis.

So your code is kind of compiled into your exe. We have the garbage collection table up.

The next key piece of the system is the code manager. And the code manager is actually the interface between the running code and the runtime system itself, so its sort of the guy in the middle that allows the runtime to safely interrupt program execution and inspect the execution stack. So it works in conjunction with the security stack to control access to native resources. It works on conjunction with the garbage collector. Since we understand the layout of objects, we know when theyre no longer needed.

The code manager works with the exception manager to provide a two-pass exception handling model. So on the first pass we actually use the code manager to walk the stack and determine who should handle the exceptions. And if there are no handlers, we pass control to the debugger without altering the state of the program. This allows for much more effective diagnosis of what happened and you can compare some other VM environments out there that have single pass exception handling models.

And finally the debug engine provides interface to external debuggers and profilers to control and monitor program execution. And these are all documented interfaces, so not only our tools but the rich partner tools use these interfaces as well.

Okay, lets finish our drill down on the .NET framework. So weve talked about the core. Presentation is kind of simple. We take Windows forms and we provide the richest framework for Windows applications. We have advanced features like visual forms in here, which we actually didnt demo today yet, automatic layout. You know, its truly a world-class forms package and I think youll really enjoy working with it.

ASP.NET is our Web forms based model. Its component based and its a page architecture and clearly I think youve seen today that the model allows rich and reach without requiring you to learn new code techniques.

And we talk about the mobile toolkit and how it enables you to target a broad range of mobile devices.

The communications services focus on providing support for ASP.NET and Web services through HTTP messages.

System.remoting is a part of our class library thats actually a full fledged object remoting system that is both transport and format independent. It allows for multiple call patterns, so if you want stateless call patterns or state full call patterns, this is full type support. Out of the box it works over TCP or HTTP. We support SOAP and binary formats. And all these things are designed so that new protocols or encoding can easily be added if you wish a sub class for some reason.

System.net is in some ways an unfortunate naming part of our class library, but its actually the part where the key network protocol stack innovation occurs. So again we support low-level socket access, support for TCP, UDP, IP multi-task, all those low level bit head things.

And it also has support for high level protocols like HTTP, NNTP, SMTP and PDP protocols can easily be added again by sub classes.

And of course system.messaging allows for reliable guarantee delivery, fully transacted.

The data part of the framework: Probably the key construct in ADO.NET is the dataset and its an in-memory buffer of related tables. You fill them from managed providers or XML. If you use managed providers, we actually will give you stream level access to data sources. And Im actually proud to say ADO.NET actually wound up being the fastest way to access SQL Server when we were done tuning all the performance.

System.XML provides great support for XSLT, XPAS, XSB and DOM2. We actually have great performance on our XSL stuff. Im actually proud to announce that we actually have the best marks on the XSLT mark bench suite, second only to XML 4.0, which we launched today, our native implementation. So were quite happy with the work that weve done in this class.

I think the key benefit really is kind of the Holy Grail of combing XML and relational together, and if you look at the work weve done with XSLT and XPAS, you know it works against either the DOM or the dataset, so we actually allow you to do XSLT transforms on relational data, which is kind of a neat benefit.

Well, we took all this great technology and we made it available on some new platforms. So one of the things Im happy to announce today is the .NET compact framework, which you have in your voluminous six-CD pack. The .NET compact framework is a compatible subset of the .NET framework for use in smart devices. The design metrics were really to provide the richest user experience, so use all the local intelligence and data that these devices provide, of course bring the great developer productivity to the framework, so you just use VisualStudio.net as you would with the regular framework and you get advantage to all the features — statement completion, the build system, everything.

And it was designed for broad device availability. So by this we mean across a variety of physical form factors, across multiple CPUs. Its got an OS portable architecture. Youll see us deliver the .NET compact framework on Pocket PC 2000 and on our next generation Pocket PC it will actually be built in.

Well, I promised Id talk about performance as one of those cross-cutting areas that actually pervades the entire .NET framework, but rather than having me just rattle off a bunch of statistics, I thought it would be fun to actually have a developer share his experience from working with the platform.

So here to share what hes learned in Scott Stanfield from Vertigo Software. (Applause.) Welcome, Scott.

SCOTT STANFIELD: Hey, Eric. How are you doing?

ERIC RUDDER: Good.

SCOTT STANFIELD: You know, Im one of those zero-based array programmers, but what I think the real argument is semicolons. I love semicolons. Theres something comforting about the way they support the end of a line like a little caboose.

Well, we do a lot of C# development in our company. We also do a lot of Java programming. And Im excited to tell you about a project that we just recently completed, where we took Suns Java Enterprise Reference Architecture. Its designed in a book called Designing Enterprise Applications, the Java 2 Platform Enterprise Edition . They have a little program called the Java Pet Store and we thought this would be a great opportunity to take this application and migrate it to C# as a way of giving the Java developers a migration path and give them something that theyre comfortable with in understanding how to do development in .NET.

So we had this book, had the time in the company, and we were already familiar with the program, so we got a couple developers together and over the course of the past five weeks — we literally just finished the project — over the course of the last five weeks we proceeded to really understand what this application is about to make sure we duplicated the functionality, but do it in a way that makes sense for .NET.

And at the end of the project we were pretty surprised at the results. Along the way we implemented an XML Web service. We also added mobile forms to it, because it was so easy to do. At the end of the project, we thought wed get an idea of the relative complexity between the .NET version and the Java version. So one of our guys wrote a little program that went through and counted all the statements, all the lines of code. And interestingly enough, our application was one-third the size of the Java program, doing the same thing, plus Web services and mobile form development.

(Applause.)

Thank you. We didnt count the semicolons. No, Im kidding.

And whats really interesting though are the numbers for the middle tier, because thats where all the real work takes place. And youll see that the numbers, weve got roughly one-eighth the amount of code.

ERIC RUDDER: Why is that? Thats a dramatic difference.

SCOTT STANFIELD: We were puzzled too, because we thought it maybe had something to do with the model view controller architecture in Java or the beamed managed persistence architecture or the fact that its just a little bit heavier architecture, but I think a lot of it has to do with the fact that we were able to take advantage of new features in XML in ASP.NET like data bound server controls, dragging and dropping them onto the surface or we also used user controls to reuse them, some of the common UIs like doing searching and product catalogues and lists. We were able to use the ASP.NET form spaced authentication.

So at the end of the day you can see we have a lot less code with this, which is pretty surprising.

So the next step is how well does this do in the lab. Now, weve done a lot of — weve done several best practices applications where weve done benchmarking. How many of you are familiar with Fitch and Mather Stocks or Eye By Spy? (Applause.) We did those applications and we found that if you can have an architecture with the best practices with a small code size, yet at the same time have it be high performance, youve got a really winning combination, and we thought well lets take Oracle up on their 9i App server challenge. They went and took the Java Pet Store application, did some benchmarking. We replicated equivalent hardware. The blue line that you see here comes straight from the Oracle PDF, which you might not find on a Web site after I show these numbers.

What they did is they cut off the testing once the pages were coming back longer than one second. So how many users could they support with pages coming back in less than a second? Well, they peaked at about 450 users.

So we go in the lab. Lets crank it up. How many users can we support? Whats our page response time when we hit 450?

Well, I told you about zero based arrays. This number is actually 35 milliseconds. And for the very few of you that cant do long division in your head, 1,000 milliseconds divided by 35 is a very big number. Its 28, a factor of 28 times faster.

Now, were scratching our heads, and maybe its the heavy-handed EJB code in there, kind of like the slower herbivores in the Terrarium. Im not sure what it is. (Laughter.)

So we said,
“Lets let this thing rip. How far can we go until we cross the 1.0 threshold, the one second threshold?”
We got over 3,000 concurrent users. Thats six times more capacity. (Applause.) Thank you.

So how could two guys from Vertigo do this .NET development in five weeks and beat the pants off these guys? I dont understand it. So everything is fully disclosed. I encourage you guys to download the source code, see how we did it. If you want to use the design patterns that we discovered in your own applications, rest assured we think theyre pretty fast and well probably continue to tune them over time. We did not tuning of this application in the lab. We simply didnt have time. We couldnt change the code. It was locked down.

At the end of the project just last week, one of our developers, the guy had never done any .NET development before, he thanked me for giving him the opportunity to work on this project. And it reminded me of a scene from Seinfield. Theres this great scene where Elaine and Jerry are late to an airport and they want to catch a flight. And they check in and theres only two seats available. Theres one in first class and theres one in coach and Elaine is begging, please let me have the first class seat. Ive never been in first class before. And Jerry says,
“Well, then you dont know what youre missing,”
and he takes the ticket and gets on the plane. (Laughter.)

.NET is a first class development platform. If youre not programming in it now, you dont know what youre missing. I encourage you to get this code, play with the platform. If youre here today, youve made a commitment to develop on this platform. So have a good time.

(Applause.)

ERIC RUDDER: Thank you, Scott.

I think using .NET makes you the master of your own domain. (Laughter.)

Okay, lets talk about another area that like performance covers the entire framework, and thats .NET Security. And this has been a challenge for us. You know, we come from a heritage where the ecosystem wasnt geared towards all these Web service applications. PC applications in the past were generally isolated. Most servers were typically behind firewalls and never punched through and exposed. And so we had to take a step back and really think through some of the .NET security design principles.

Clearly, you know, we want to provide a secure execution environment, things like managed code, code signing and authorization. We knew we wanted to leverage proven security standards, things like Kerberos, X.509 public key infrastructure, SSL, but we knew we had to provide leadership on modular Web service security standards, specifications like XML signature, XML encryption and now our recently announced WS Security specs. But security is not just about features; its also being prepared for ongoing security updates.

Well, in the .NET framework itself we kind of break it down into a few simple questions and problems. The first is who wrote the code, right. Code signing is there and we use it with strong names and certificates to guarantee code authenticity and to prevent tampering with the code.

Then we look at how the code should be authorized, and again its flexible. You can use X.509, Kerberos or any other pluggable methods that you want for doing the authorization.

We built an industry initiative for building and maintaining these trust relationships, called the Internet Trust Network. This is the work that were doing with the industry and the ecosystem as a whole in order to federate Passport to build a secure Kerberos distributed infrastructure.

We look at what actions the code can perform, so we have an evidenced-based model, which I showed you in the CLR walkthrough. It allows the application to set policy, and also the administrator to apply policy to the code as well.

And finally we think about how is executing the code and here the .NET framework took a role-based model and so we provide APIs that are role-based for both authorization and authentication. And, of course, we have all the other things youd expect from a complete security framework, things like encryption as well.

Well, the security commitment, as I mentioned, is not a one-time thing; its an ongoing effort. And so we have the Secure Windows Initiative, which is an internal process that we use that focuses on delivering higher quality, more secure software and we perform ongoing security assessments now.

We also took a slightly different approach as we developed the .NET framework in that we worked with domain experts and partners in the field. So some of you may know Foundstone, which is a leading information system security firm. They work with the Department of Defense, the Air Force, the Big Five. Theyve published the popular book, I think its called Hacking Exposed . Its actually on Amazon.coms bestseller list. They work on the weekly security watch column for InfoWorld. And we had them do a full audit of the .NET framework, not just the architecture but also we gave them complete access to the source. And theyll actually publish their findings for you to review in November, but I just wanted to take a quote from their findings.

“Based on an extended analysis of the .NET framework, were confident in the strength of the design and confident in the resources and motivation of the .NET framework team to address security with the utmost priority as enterprise and Web computing needs continue to evolve.”

So as I said, this is some design work weve done, but were going to make sure that the .NET stuff is part of our ongoing framework and ongoing programs. So we want to provide customers with the tools and resources and support to both get secure and stay secure, and well make sure that the .NET framework is part of the stay secure commitment, make sure its part of Windows Update and all those ongoing services that keep enterprises up to date.

Well, one of the reasons that security was so important to get right was the creation of our own set of Web services, which our flagship services are called My Services. They provide great client support, as I mentioned before, that we federate at the corporate boundary. And so we started off building these services.

We started with SOAP. We added the ability to transport binary data, so we got some better performance.

We added logical service names that map the underlying implementation to route requests, so we got better scalability.

We added a way to sign and authorize messages, so we had great security.

And, of course, we added a way to do alerts, so we could make all these cool demos work.

And when we were done, we made sure that we had great .NET framework and Visual Studio support, so you can just sit in the IDE and call Passport or call any My Service, the alert service or any of the 14 that were working on.

Lets take a look at a simple example from one of the My Services. I happened to have picked My Contacts, but I could have picked any one. Its basically the same stuff youve been seeing all morning. Its just a simple SOAP message going over HTTP or maybe TCP directly. It hits the service logic. The service typically calls an XML store, in our case we have SQL Server. We use the standard routing headers, security headers, license headers, application headers. Everything from our GXA announcement is used to build My Services, right, we built our services using our architecture.

Lets actually get a better look at it than the slide. I actually want to call Mark Lucovsky out, whos the Chief Software Architect for the My Services and hell give us a demo of what this stuff is really about. Thanks, Mark.

(Applause.)

MARK LUCOVSKY: Hey, Eric, thank you.

So this zero based array thing, one based array, where does that come from? Theres only one answer and its zero. So lets put it to bed.

My name is Mark LUCOVSKY. I am the Chief Software Architect of the .NET Services project here at Microsoft. Now, in 1988 Dave Cutler and I left Digital Equipment Corporation to come to Microsoft to design and build Windows NT. Dave did the kernel and I did most of the executive and Win 32 and a lot of the user mode support, so Im a hard-core kernel guy.

About a year ago, I left the Windows organization to come work on .NET, and my friends in Windows to this day give me no end of grief. They said,
“Mark, whats gotten into you? Youre in the land of teddy bears and fluffy clouds and you allocate memory and you never free it, and theres garbage collectors. Whats that all about? Where does this actually go when you leave scope?”

I dont know. I dont know the answer. I mean, I just started writing in Java Script and you pop and I dont know where it goes.

Dave Cutler also used to give me a lot of good advice, and one of the pieces of advice he gave me is,
“Mark, if youre ever in a meeting and during the meeting somebody says the word”
schema
“just get up and run like hell, because if you stay there, youre going to get converted.”
(Laughter.)

So you can imagine how weird it is for me to be in a group where everything we do is about designing schemas, schemas for messages, schemas for data models, very strict data models and databases and stuff, so my life now is all about schemas.

So why am I here? Why did I come to the .NET group? Well, Im here because I am a total believer in XML. I believe it is the data format that is going to give us the degree of interoperability that we require and its the data format thats going to let me give to you guys a bunch of rich services that you can use, extend, transform shape and use in the right way for your applications.

I believe that XML Web services is the type of architecture that we need in order to bind these pieces of logic to one another when theyre across different networks and theyre on heterogeneous systems.

And finally I believe in the GXA initiative. I believe that we need a standard set of SOAP headers where we can use the word
“schema”
to describe what the format of the headers are and what the meaning of the headers are, and so that we can get that interoperability in areas like security and routing and reliability.

So Im a big believer in all of the work thats going on with .NET, and thats why I left Windows to come here.

So what Im going to show you with these little bits and pieces of applications is just a brief look at what happens with .NET My Services, whats really going on under the hood. And what I have is two client side applications. I have a fake Blackberry and a fake smart phone that are just simulations that make use of the .NET My Services.

So let me power these guys up. I did that myself. Thats a little timer in Java. You can do that. So I can click on the calendar and see calendar events for Mark. I can click on lists and see the list of things I have to do. I can do that for myself and I can do that for others in my group. I can shoot alerts back and forth. Now, I want you to watch closely when I do an alert. Im going to start an alert on the Blackberry, and all the alert demos that youre going to see throughout the rest of this conference are probably going to show an alert with a blue piece of toast coming up. In a cell phone youre not going to get the blue piece of toast. Were going to light up a little light in this area when we receive the alert.

So type in the alert, I send it, and the alert came through and I can see the alert and dismiss it.

Now, with XML Web services any applications that can form XML and speak the open protocols of the Internet can play. So here I can Telnet into a machine in Redmond that is running FreeBSD 4.3 release, and what Im going to do is send an alert from Redmond to a Web server running in the back and it should pop up an alert on the blue phone. And sure enough, theres the light.

But before I go in there, lets take a look at the message. And you can see heres the body of the message that I sent and this is my response. And what I have here, Ive got the alert on the screen.

So lets open one of these things up. Being a kernel guy, Im never going to go anywhere without a debugger. So let me pop this open and you can see the actual messages. Let me enumerate a calendar and you can see this is the message that I sent, the XML, and I have in here the routing header. Let me minimize that. I have the security header from GXA. And then I have my own application specific header that Ill pop out of the way. And then in the body is just an application specific message thats asking for calendar information for a particular date range.

And what I get in response to that calendar information is a set of XML nodes that describe the calendar events that I then transform onto the screen to draw this display. And all of our services work the same way, so that when I enumerate the list Im doing the same basic message, only here Im getting list information instead of calendar information.

So thats kind of a brief view of what the .NET My Services are all about, and well be talking about these throughout the day. But the point that you should understand is that this stuff is easy, fun and open. I mean, I wrote these applications, these took me all of a day or two, and most of the work was really figuring out how to position that little window on top of the skin that I have and then how to hotspot in some buttons.

So its easy. If I can build an app like this, you guys can do wonders. And clearly were big believers in XML in this set of services.

ERIC RUDDER: Thanks, Mark.

MARK LUCOVSKY: Thanks, Eric.

(Applause.)

ERIC RUDDER: Well, I want to build on something Mark said. Mark mentioned that it was fun and simple. And if you think about some of the reasons that the Internet kind of took off the way it did, I think that that really was at the heart of it, you know, it kind of made playing with computers and writing code and developing fun and simple.

You know, I think back to the first Windows program I wrote. I dont know about you guys, but I actually got a copy of Petzels book, typed it in pretty much colon for colon, character for character, and voila I had a Windows app running on the screen. And that was kind of amazing.

And then, you know, VB came out and I remember VB came out, I dropped the form, I got in, I wrote my one line, you know, message box code and, wow, I had a Windows app again, and that was a lot easier than Petzel.

And you think about writing a Web service now and the first time you write a Web service and you can just sit down with notepad, kind of write five lines of code and save the file off and voila its a Web service. And that same joy of getting something up and running and being able to experiment and being able to use it from different devices and different contexts is something that I think is important that we hold dear to us as we think about what set of products we build going forward. You know, we really want to hear your feedback. I think its important to have a little fun as we do work.

One of the things that can make coding more fun is great tools and Visual Studio I think is the best tool that weve ever built, flat out. Its rad for client, server and services. It leverages your existing skills that you already know from Visual Studio. And we have great support for building distributed solutions.

Its not just our work that makes the toolset so great. Its enhanced by partners, people like CompuWare, RationalWise. In fact, we have over 60 partners and well be launching over 124 products in the Visual Studio integrated program.

Well, Web services are here today and we want to be clear that when you get home you should start writing Web services, but we did want to spend a few minutes sharing our ideas for the future. We want to make it even easier for applications to span organizational boundaries. We want to enable dynamic application topology. Enhancements for routing and security and performance make this possible. We want to build and deploy Web services on distributed application networks, and we want to enable the next generation of tools that make it even easier to work together on projects, to test, to deploy moving forward.

I actually wanted to drill down a little bit on the dynamic application topology and talk about what we mean and talk about deploying a Web service into an operational framework that could be flexible.

So to help me do that, I actually want to invite Vic Gundotra back out on stage and hes here to give you a sneak peak of some of the future of global service architecture.

VIC GUNDOTRA: Great, thanks. Hi again.

ERIC RUDDER: Hey, Vic. Welcome back.

(Applause.)

VIC GUNDOTRA: So, you know, everyone here knows that were just about to ship VisualStudio.net and the .NET framework, and I cant tell you how excited we are that youll finally have this great tool in your hands. But even on the eve of releasing the first generation of the .NET framework, were hard at work building the next generation. And I guess I get the fun job of giving you a sneak peak into whats going on in the dev labs back in Redmond and share some of our thinking.

Obviously were hard at work thinking about the unique challenges associated with Web services development. In fact, let me show you just some of the challenges that were working on. Let me switch over here and bring up this application.

So the scenario youre looking at here is a portfolio management application built by an East Coast brokerage firm. Now, its easy to imagine that when the developer wrote the application, the entire application, that neither the developer nor the deployment folks really knew how popular this app might become. Really, you know, who can blame them. If youve ever done distributed development, you know that while you try to model behavior, until you deploy the app and you see real usage patterns, its incredibly difficult to really know. Few people have the time to go build into their application code all the necessary hooks to handle any arbitrary amount of scale.

Well, we are working in future generations of the .NET framework to provide, as Eric mentioned, dynamic application topologies, dynamic application topology. So what that means is that were going to make it very simple for the underlying .NET infrastructure, that fabric to automatically bring up servers as scale requirements dictate, to automatically have clients know what is the best available server to connect to.

And heres the kicker: We think we can do much of this without requiring additional code on the part of the developer.

Now, in this particular scenario, the East Coast company, the brokerage firm built the app and sure enough they were wildly successful. They have more clients than they expected using their tool and those clients were geographically dispersed all around the world. Now what do you do?

So you can add servers. Obviously there are latency issues. There are performance issues. You can put servers closer to your end users, to those clients. But what do you do about the code? Your code doesnt know about those servers. Youve got to go back, rewrap that application logic code, think about that new topology youre going to support.

But not this app. What were going to show you here is because its built on a future generation of the .NET framework, the dynamic application topology support that it has.

Im going to bring up my network operations control panel here and put that up in the corner. A couple things to note: Actually, let me just switch back here. If you look at the app, this is a debug version of this portfolio management tool. Youll note that the quote window, my portfolio is talking to a New York Web server, as well as my new service is talking to a New York Web server. And sure enough if you look at my network operations control, you can see that that Web server is pretty maxed out.

Now, imagine having the ability to put up servers on the West Coast. Remember, earlier we talked about new standards such as WS Security, Routing, Referral protocols that allowed us to establish code that runs through trust boundaries, organizational boundaries. Thats what weve done. Weve purchased some of those servers. Theyre being hosted. And now what Im going to do is I am going to bring up those servers. Okay, keep your eyes right here as those servers come on line.

Now, whats going to happen is were going to distribute out the news server. The news service — hopefully this will work — there we go, excellent. You see those Seattle servers come up and you can see the corresponding drop in the load on the New York server.

Well, what just happened? Well, a couple of amazing things. Number one, because the news alerts are stateless events, this future version of the .NET framework knew that it could fan them out and it went ahead to those servers and recognized that they were available resources, used them as fan out servers for those alerts.

Now, if that wasnt cool enough, did you notice the very subtle thing? Look at the app. The app dynamically connected to the appropriate server and automatically went to that Seattle server. Thats pretty cool stuff.

But lets make the scenario even a little bit more difficult. Look at the server logs, and we recognize that much of the server load is coming from Europe and theres obviously latency issues going across the Atlantic. And we want to do some load balancing, but in this case we dont just want to fan out the events to the European servers, we want to do something a little bit more complicated. We want to move and partition the application logic and move that to the European server.

Now, this is a bit tricky. Obviously you can think of the challenges. Youve got data. Youve got to package up the data, bring that data out to the European server. That includes the session state regarding each portfolio. Its associated events. Youve got to go get those running overall in the European servers. As well as you have to have those clients do this same amazing ability, which is now to know to connect out to those European servers.

So lets see what happens as I bring up those European servers. Okay, Ive initiated that call. Keep your eyes there at the bottom here as those European servers start to come up, as well as on the load on the New York server there.

Okay, there you have it. Those servers in Europe have come up and the load in New York has gone down correspondingly.

Now, obviously that took some recoding. That doesnt just happen magically. It will require the developer to go and think about how they partition their application logic, but in future versions of the .NET framework were going to provide tools and make it much more simple for you as a developer to mark which sections of your code can, in fact, be application partitioned correctly.

So youve seen span out of stateless events. Youve seen application partitioning. What about the flip side of that problem? What happens when a portion of your infrastructure goes down unexpectedly?

Well, if you notice that new server, its talking to a Seattle WS1 server. Lets shut that down. Keep your eye on the graph here. Theres a degree of latency here as we get these reports back. But if you keep your eye on that Seattle server, two things are going to happen. There we go. That one server goes down. The other Seattle server picks up that stateless event load and note that weve automatically moved over without disconnecting that client, without requiring any down time, and weve brought that up. (Applause.)

So let me just summarize here. A future version of the .NET framework is going to enable dynamic application topology. Its going to enable you to have clients that maintain connection in the face of adding servers or removing servers. It will do that for stateless events, including application partitioning, and also it will support failover.

Certainly we think these things combine up to provide you extremely dynamic application topology.

You know, our goal is to enable you as developers to focus on your business and really allow the underlying infrastructure to step up and meet the needs of your customers. Hopefully you can see with .NET weve only just begun.

Thanks, Eric.

(Applause.)

ERIC RUDDER: So a few points about dynamic application topologies. Some of this technology actually exists today, but really today its only used on the largest public dot-com sites. And I think its important to realize that theres plenty of value in thinking through some of these things in enterprise scenarios. Ill just speak from personal experience. If you take a company like Microsoft, we have literally scores of subsidiaries around the world, and we have typical line of business apps, you know, how I manage my 401(k), how I get a new cardkey, you know, what flavor of soda to order, and if youre an employee in India or in China or in South America, you know, you dont get the best application response times because those applications have to be hauled all the way back to Redmond. Well, why? Well, because its too hard for our IT department to actually fan out these applications throughout the world, and its too expensive to actually use a service provider just for some simple 401(k) app. What this architecture will let you do is make those scenarios much simpler.

Later on today Paul Flessner is actually going to show AppCenter. And AppCenter is the product that actually is used to manage these instances of dynamic application topology. So Paul is going to show you whats available today. This technology is for Web services of tomorrow.

So I think Vic convinced us that .NET has an exciting future, but its also off to a pretty exciting start, and I think we have some incredible momentum. We already have over 35 component vendors selling .NET components. Theres more than 25 ASP.NET hosters. In print, by the end of the year we should have over 150 books available on .NET. Currently four of Amazons ten best-selling programming books are on .NET. There are three new dedicated magazines.

Weve had a phenomenal effort in training. Theres over 815 institutions in the MSDN academic alliance. Thats over 15,000 faculty and 200,000 students, so I think well be touching this next generation of programmers and theyll be available in the workforce pretty soon.

There are more than 50 companies that already today are offering .NET training, and by March, which will be our official you can go in the store and buy it, we expect over 250 companies will be offering training.

Finally, a word about community. We have over 70 user groups devoted to .NET and literally hundreds of newsgroups and Web Sites devoted to this. We love reading newsgroups ourselves at Microsoft. Were all active participants in my team. I know a lot of us spend time. And we love reading not just feedback from Linux users but from Java users as well. So I hope to hear from you about your experiences and were pretty excited to get the feedback and to get the feedback loop going and to make better and better products.

Well, in summary I want to leave you with a call to action. First, make your bet on XML Web services. Its here today. Connect your services together and connect them to my services. And implement them using the new Web service protocols.

Build great solutions. Build applications that use clients, servers and services with the .NET framework and the Visual Studio tools.

Create the next generation experiences that run anytime, anywhere, on any device.

And take advantage of the capabilities offered on the target platform. You must deliver the great user experiences. You know, the lowest common denominator solution never wins, so take maximum advantage of the platform.

And finally, give us feedback. I think we really win by working together. So talk to us this week and help us make .NET even better. There are over 500 people from Microsoft around the floor and youll see us wearing our shirts. Get your PC trading cards. You kind of saw them in the app. Its a good way to meet each other. We have some trading cards too. Im sure wed be happy to lose to you. Ill give you an opaque clue for the grand puzzle. My opaque clue is androids. So if you want that signed t-shirt or that Xbox, start playing.

But more importantly than today and just the PDC, engage in the community going forward. Specifically engage in the online community of newsgroups, the list servers, the physical community of the user groups, some chats well be hosting. Share your knowledge. Get help. Give help. Give input to us on how to make a better product. Were online to listen and help. Well link to partner communities that are healthy and vibrant. I encourage you to find out more about the .NET technologies on MSDN, on the community site on Microsoft.com and on DotNet.com.

Work with us on marketing your solutions. The Windows XP co-marketing opportunities are documented below. The logo programs that we touched on in the earlier keynote are available as well.

Well, in summary, were very excited and confident about .NET, but were not overconfident. We know that developers, you folks in the audience will ultimately determine the fate of .NET. So I want to thank you for attending this years PDC.

(Applause.)

You know, I half jokingly named my talk
“Nothing but .NET”
but the truth is that at Microsoft there really is nothing but .NET. Weve bet it all on this strategy and we bet it all on working with you. We hope you believe. We hope you bet with us. Thank you.