VSLIve! Speaker Interview—Jay Paulus

Windows .NET Server will have a dramatic affect on development and developers. Microsoft Product Manager, Jay Paulus, will show VSLive! New York attendees how Windows .NET Server will enable the .NET vision and allow you to build better applications—faster. As a sneak preview read our interview with Jay below where he also covers how. NET integration and IIS6 will help developers create XML Web services, how integrated UDDI behind the firewall will ease deployment, security improvements and more. Register for VSLive! New York now and get your chance to learn from Jay live and in person!

Or register for any of these other VSLive! events by their Early Bird Discount deadlines and save!

Cliff Reeves, Vice President of Marketing for Windows .NET Server, has been quoted as saying that the single biggest thing in Windows .NET Server is its focus on the developer. How is that so?
It has to do with the fact that we're integrating the .NET framework into Windows .NET Server. Microsoft is moving beyond the classic idea of an application server that's always been integrated into Windows in the form of COM+ and all the application services that we put in there—IIS, Active Directory (AD), and so on. Now developers will get all the benefits the .NET framework has to offer, such as its native support for XML Web services. Windows .NET Server is an example of us delivering this new breed of application server that enables corporations to kind of move into this new world where a classic application server isn't enough, and what you need is an application server that's part of this broader vision of an application platform. This integration means that developers and system administrators who are running these Web-based applications and that kind of Web services have a fine-grained control over what the application looks like, including how it's isolated from other applications, its security context, and other factors.

You mentioned the integration aspect. Much of the integration and many of the improvements I'm aware of in Windows .NET Server are available already in service packs associated with Windows 2000 server and other products. If I already have those service packs in those products, why do I need Windows .NET Server?
We hear that question a lot. It's like hey, I could do .NET framework development on Windows today, so what's the big deal? Why is Windows .NET Server different? The answer boils down to two or three major things. Integration of the framework is a win from the integration standpoint alone. I don't need to worry about deploying it. I know that the environment is going to be there. The second major area is the integration with IIS 6, which has been rearchitected completely to utilize this new process model, and gain really fine-grained control over application isolation and application-recycling settings. You can take individual groups of applications or single applications, and put them into these application pools, where each one of pools has its own process-recycling settings. You get these isolated execution environments where you can make your application run.

That's a big deal from the developer's perspective, even though it doesn't change the development experience significantly. However, you as a developer get better performance, better reliability, and more scalability by virtue of the fact that these application pools talk directly down to a kernel-mode HTTP listener. Windows .NET Server has this native in the box is a kernel-mode HTTP listener which then hands these requests up to the applications which are running in this nice little IIS 6 environment. We're also including new UDDI services as native services in the box. So we've been talking about UDDI for awhile, which is part of the XML Web service standards stack we're all familiar with.

UDDI was originally created as a yellow pages for programmable resources. You've got the enterprise saying it would like this kind of functionality, but behind the firewall. What we did is take the actual code that runs our public node, did some performance tuning on it and integrated it to leverage that new IIS 6 process model. We also built it to leverage AD for authentication, so in addition to the standard UDDI authentication mode, you can also use integrated Windows authentication. And you can run your own UDDI services behind the firewall. This is cool for a number of reasons. This means companies can have a central place where developers can put references to and find references to other pieces of code, which results in improved reuse. That's the design time aspect. So, just from a productivity standpoint, you get better ability to design your app and use services that already exist.

From a runtime aspect, you have the ability to build more dynamic applications. For example, assume you're a financial services firm, and you want to build a trader's desk that gives traders the information they need to do their jobs. Perhaps you want that trader definition to be the most dynamic and use most current models that available. Now assume you want to update an existing model with a newer one. You could register that model in UDDI. Assuming you built the trader's definition to be dynamically clearing and looking for new model, it can use UDDI to go find this new programmable service. This means you have a standards-based way of doing that kind of service lookup.

Here's another scenario. Let's say you have a branch office, and you want to build a central reporting app that goes out and queries your branch offices to get sales data. You could use UDDI to create a central repository where you store references to every branch office. So, every time you add a new branch office to your company, you basically register it in UDDI. This means your central reporting application automatically finds out when there's a new branch office server. All you need to do as a developer is add the new office to the list of servers that you want to query for sales information. You don't need to make any changes to your central application. In effect, you get something equivalent to a late-binding Web server, a more dynamic application that uses UDDI as one of its core services. That's a pretty exciting thing.

Switching gears, let's talk about security, which is a major concern with any server-oriented product in the enterprise. Microsoft has stated that it's going to concentrate more heavily on security, even at the expense of features where a conflict exists. What practical implications will this have for users, administrators, and developers, with respect to Windows .NET Server?
The most obvious thing developers will notice is that the server is locked down by default. The idea now is to make the platform secure by default, then make it easier for developers to use the security that's in the OS to build secure applications. It's not just about securing the platform. You've also got to make sure people know how to use these features in such a way that the applications they build on them are secure as well.

The platform being locked down by default has several practical implications. For example, when developers first installed the server in Windows 2000, IIS was installed as a default service. With Windows .NET Servers, developers will notice that a lot of services are turned off by default and are now activated through a server-configuration wizard that enables users to go in and turn on only the services they want. So, assume you have a server box, and you want to run a Web application server. After running this wizard, there will be no services running by default, and you won't be able to listen on Port 80 at all. To do this, you need to go in and use the wizard to choose a new role, installing IIS. But at this point, IIS is still locked down. All it will do is serve static pages, so there's very low risk. Unlocking and turning on any kind of application filter that you might want requires that you go through an unlock wizard within IIS. So, if you want index server, you need to turn that on. If you want front page server extensions, you have to turn those on. If you want it to serve ASP.NET, or ASP Pages, you have to turn on those application extensions. And so on.

How do you do this and maintain the ease-of-use your products are famous for?
The wizards help a lot. But it's also an example of a change in direction. In the past, Microsoft erred on the side of usability. I think that, by and large, the community is telling us that yes, it likes usability, but that security has to be our first concern. So, there's always some price to pay. I think that we're trying to hit the right balance in terms of making it easy for people to figure out how to turn these features back on in a safe way.

A recent Gartner report advocated that companies drop IIS because hackers target it so heavily. We're on the record that this is a silly recommendation, not least because many of the vulnerabilities exploited have patches available that network administrators simply never installed. Indeed, we think the weak link in security in many cases is the network administrator who doesn't keep current with patches. What steps has Microsoft taken to address this link in the chain? Is there anything Microsoft can do?
Yes, it comes down to creating a user interface that makes it easier for people to install patches. There's a lot of work going on around the Windows update infrastructure that is making it easier for these patches to flow down from MS into the hands of administrators. There's also this idea of the federated Windows update model, where corporations run their own Windows update server. Companies simply stage patches to this server, then run an automatic update that brings the patch down to the necessary servers. This makes it even easier for people to get the patches. But, on a fundamental level, we have to create more awareness and educate our users better. We're investing a lot of money and effort into getting that kind of knowledge into people's hands.

One more question in this vein, and we'll move on. In many ways, security is as much a political concern as it is a practical one in the sense that it might be enough to solve the major technical issues related to security. The perception of how secure your products are is almost as important as the real vulnerabilities that exist. What can Microsoft do, apart from satisfying the technical requirements security presents, to erase the skepticism about its product security, especially as it pertains to Windows .NET Server and IIS.
It's just one of those long-term things. You've just got to be good. You've got to deliver on what you say you're going to do. I don't think there's any magic bullet that let's us reverse that perception. I mean, I think people are going to be leery. If somebody has a negative perception, and you try to change it through some means other than just being trustworthy, people are going to have a tough time swallowing that. In short, people are going to start to believe it when they see it; we need to put our money where our mouth is, and that is what we are doing. And we'll continue to do that with a long-term focus. I don't think there's any kind of stunt or any security challenge that we've got out there that's going to be a magic bullet that turns the tide our way. When people get their hands on the product, and they see the work we've done around implementing better security, they'll start to come around.

At VSLive New York, you're going to speak about building, deploying and running XML Web services and applications. What does Windows .NET Server bring to the table that will make it easier for developers and organizations to implement such applications more quickly or easily?
It brings a lot of things. There's the .NET framework integration, and IIS 6 has a great new process model. IIS 6 also brings some good management capabilities, including an XML-based configuration file. This file that has good command-based utilities, as well as a UI you can use for importing and exporting small chunks of the file. This means you can import/export files easily. Combine that with the X-copy deployment nature of the .NET framework, and you get really good story for IT administrators in terms of their ability to deploy applications to a server easily. Scale that up with applications center, and you get a complete, end-to-end application-deployment story.

Jay Paulus
Jay Paulus is a Lead Product Manager for Windows .NET Server. He has been a part of Microsoft and the Windows Server team for 3 years. Jay is responsible for business analysis and setting strategy for Windows as an application server. He has more 12 years of industry experience ranging from enterprise systems integration consulting to market research and product management.