Microsoft Server Boss Talks Tools

By eweek  |  Posted 2003-10-26

Microsoft Server Boss Talks Tools

Eric Rudder, senior vice president of servers and tools at Microsoft Corp., is responsible for Microsofts strategies on both fronts, including the Redmond, Wash., companys outreach to its developer community. Rudders influence will be apparent at this weeks Microsoft Professional Developers Conference in Los Angeles; hes responsible for applying the companys tools strategy to many of the technologies being unveiled at the show, including the upcoming Longhorn operating system; the new Whidbey version of Visual Studio .Net; and Microsofts new Web services platform, known as Indigo. Rudder spoke with eWEEK Senior Writer Darryl K. Taft in the weeks before the PDC.

How has open source affected your server and tools strategy?

I think there are lots of aspects to open source, and the one thats affected me the most profoundly is really the way community is used in open source. And the way people really can get their opinions heard, and the way people can share their work with others. And the way people can feel supported and get their questions answered. And it really has changed how we think about running the business. Literally encouraging people to participate in community, running betas on a more active basis, being more transparent in our roadmap—sharing the roadmap for Whidbey and for Orcas and for what features are going to be in what. Really giving access to technology; really, literally building community into the product so that people can communicate with their peers who are working on similar issues.

And I think thats one of the elements of open source that has dramatically affected our thinking. We should have the strongest developer community for server and tools, and on the IT side, we should have the strongest developer community—whether its a bunch of DBAs sharing scripts for SQL Server or a bunch of developers sharing tips and tricks for working with Oracle, or whatever it is. We want to have the most robust discussions, the biggest collection of samples, and the most useful library of scripts for administrators. When you think about the product offering overall, and you think about documentation, for example, as something we used to just kind of deliver and in two years youll get another set of documentation. Well, thats no longer the case. We will literally update our documentation much more frequently, based on requests, based on contributions that users have made.

At the PDC, youll see us launch our SDK, for the first time incorporating community into the SDK. So people will be able to annotate the new APIs, saying things like "This is a horrible API!" or "Oh, I love this API! Why dont more APIs follow this design pattern?" And youll be able to filter and say, "Only show me comments and annotations from MVPs or all the people that work at eWEEK," or, "Show me Darryls in particular." Were kind of linking up what the Web has used in blogging with what we want to implement in information. So maybe I could subscribe to the Taft comments on APIs, and every time you post something itll actually change how I view the SDK.

So it has deeply impacted how we think about delivering information, how we think about sharing community and working together.

When or how will Visual Studio .Net support business process management?

Well, Visual Studio today supports the designer for BizTalk, the BPEL designer, so the business process designer is in there. When BTS [BizTalk Server] 2004 ships at the end of this year, it will actually ship with a new improved designer that literally is in the Visual Studio shell. Weve shown that publicly. So we will continue to put business process designers in VS and rules designers in VS soon. So we have them now, [and] theyll get better at BTS 2004 and better still when we launch Whidbey.

Next page: Next steps for model-based programming.


-Based Programming: Next Steps">

At the Microsoft Financial Analyst Meeting in July, Bill Gates mentioned model-based programming. When will we see a step up into that?

We have model-based programming in Visual Studio today with the Visio designer. Its probably the second-most-popular modeling tool in the world. And we will take quite a leap forward in the next version, code-named Whidbey. Weve got a separate codename for some of our modeling tools, which we call Whitehorse. And basically Whitehorse will ship as part of Whidbey—as a way to think about that. And youll see integration, not just of better tools for UML modeling, but also some of the beginnings of the vision that we started to articulate around SDM [System Definition Model] and management.

So people can literally annotate, "Hey, this component needs to run outside the firewall," or, "This needs to run in the DMZ." So youll actually see that in the model itself—youll actually be able to visually overlay. Youll actually be able to design Web services graphically and do all that other stuff as well. So Im pretty excited about the substantial level of improvement people will see in Whidbey.

Can you talk a little more about Whitehorse? What exactly is in that?

Well, Whitehorse is just the codename for our next generation of modeling tools. So people will see improved modeling in the traditional capabilities that we have, but also I think the key fertile ground for innovation is around how modeling and Web services come together. And thats where youll see the innovation happen.

I know youve been working with the Object Management Group [OMG]. Is there any chance Microsoft will rejoin OMG?

I have nothing to announce now about OMG one way or the other. I think we have always been super-respectful of standards, and I think in the sense of models theres always an open architecture for importing and exporting in whatever model format that you decide.

And really, the question is less a question of what your persistence format is for the model and more a question of how you can bring better productivity to the user when you stare at all those circles and triangles and funny-shaped arrows and lines. Can you really make it easier to follow a business flow? And if you think about not just the models at design time, but models at runtime.

You know, kind of the Holy Grail is if you do this model and you think about the model and then you go to debug it; then all of a sudden, youre looking at code. And youre, like, "Well wait, I want to go follow that little arrow to this little box, not be in a debugger looking at address space zero-hex-four-nine-three and look at the three. I literally want to hit Return and have some arrow highlighted." I think theres lots of innovation for how the cycle can come together. And I think thats really the challenge to the industry in one dimension. And probably the second challenge is taking the model and either generating code or going all the way toward distributing the environment and really working together on the management infrastructure.

So which approach are you taking?

I dont think theyre mutually exclusive approaches.

So youre looking at the issue as a holistic thing?

Oh, I hope so. And I hope customers will agree when they see it. That is the problem. Like when you go look at the log and it says something didnt follow something. ... Can you correlate the event back to a rule? So if you look at the financial analysts and you click on that thing and it was suspended because of X, can you go back and see what X is? Does it show you this is the rule?

In the Dragonfly demo [of business-rules technology], you can literally say this rule of design or this constraint was not met, so you can go back to debug. I think were starting to be a little bit more holistic, but just like with anything else, I think as more and more people start to use these technologies well have more and more ideas on how we can be even better and we look forward to that virtual cycle of making the process better.

Next page: The challenge of vendor interoperability.

Vendor Interoperability

So do you see things coming together on some of these issues—like WS-Federation versus Liberty, and WS-Reliability versus WS-ReliableMessaging?

Rudder: Well, I hope so. I think the most important thing is that there really are vendor implementations that solve real business problems. People forget about that. If people could … Again, given the choice between a de jure standard or vendor interoperability, I think many customers would take vendor interoperability. We should never lose sight of that—that a standard really isnt a goal unto itself. You know, I think in the end we are going to end up with interoperable implementations because I think the customer pressure is going to be so great. And I think standards bodies can actually help us work through some of the vendor interop issues. And standards bodies are expert at resolving consensus issues between vendors. And again they have an important role to play and we absolutely will utilize them. So Im optimistic over time about this stuff working out. And I tend not to focus so much on the standards issue de jour and look at the larger questions on are we really going to keep this industry moving forward on Web services.

And the reason I say that is because there wont be a Web services market unless we have interoperability. Were trying to grow a new market as an industry. And the fundamental value proposition of the Web services market is interoperability. And thats what we really need to keep in mind.

So where would you say we are in terms of the maturity of Web services? Are the specs there and available that we need? And whats missing?

We typically talk about where we are in terms of three phases. The first phase was about getting a message from point A to point B. So Level One was about SOAP, about XML, about UDDI. Can I call another vendors implementation with a simple Web service? That work clearly by any account is done. People can really build systems on that.

As people started to build systems on that, they said, "Hey, we can really build systems on that!" But you know what? Its hard building systems that require security, transactions and reliable messaging. And that really is Level Two for us—taking the base framework and making sure we can build a secure, reliable, transacted Web services infrastructure. And I think were well on our way to doing that. We made fantastic progress over the last year. Who would have thought wed be able to get the industry together on WS-Security? And I think weve done it. Transactions made great progress, and reliable messaging made great progress as well. I think well finish that up. Then the core infrastructure is in place. Level Three is less about WS-X, WS-Y, WS-Z and more about vendor- and industry-specific profiles. So what does Web services mean for insurance? Or what does Web services mean for manufacturing? Or what does Web services mean for health care? And this means going back and looking at a lot of the good work done in industry-specific standards bodies and really kind of, to make up a word, "Webservicizing" it. People have done great work on schema, but they really havent factored it in relation to Web services. And we have to think about things like HiPAA or HF7 work—we need to think about how Web services impact that work is really the third level.

And there I think the technology providers like Microsoft and BEA or Oracle are more advisers to the vertical or specific domain rather than driving the ChemXML standard.

So have you done any preliminary work at Level Three? What are you doing?

We have worked with ACORD, as a good example. I think weve had good preliminary discussions with lots of groups, and now that were kind of through the Level Two stuff, I do think youll see the work accelerate in that area.

Next page: Microsofts plans for Orcas and SOAs.

Orcas and SOAs

Whats the story with Orcas [the successor to Whidbey]?

Orcas well see in the Longhorn timeframe as well. The tools philosophy is basically have a significant release of Visual Studio timed with significant platform advances. So Yukon is a significant platform advance; well have Whidbey for that. Longhorn is a significant platform advance, and well have Orcas for that.

Any specifics generically you can give on that? On Orcas?

Well certainly be fully supporting the Longhorn features. As much as theres a new storage system with WinFS, well have support for that. As much as theres a great presentation system for Avalon [the API framework for Longhorn], well make sure people can write and create Avalon applications. And with the managed framework becoming a key part of Windows well continue to enhance that as well.

Basically, its goal is to be the premier tool that developers should want to develop Longhorn applications.

Whats your vision (or Microsofts strategy) for service-oriented architectures?

I map SOA and Web services very tightly. In some sense I think about them the same way. I certainly think that how you should expose services in an SOA is via Web services. I think that the other thing thats important is how youre going to orchestrate collections of services, especially when theyre across multiple partners and you need to coordinate many of them in a single business transaction. And there it really is the orchestration efforts led by our BizTalk products. So we see SOAs taking hold in companies all the time, and I see that trend only accelerating. Thats why were investing heavily into modeling tools so people can model SOA and create the stubs and flesh out the frames.

Next page: Taking on Sun and IBM.

What About Sun and


Do you have any perception about Suns software strategy?

Youll have to ask Sun about Suns software strategy.

I was asking your perception.

I think many customers see Sun as a hardware company.

OK, let me take it a step further. At JavaOne one of the big things they touted was a Java development tool theyre coming up with called Project Rave, which is said to be a VB-like Java development environment.

Different from BEAs Workshop tool?

Well, this is supposedly very much like VB …

Like NetBeans was like VB? I think "asked and answered" is appropriate at this point. Im not going to speculate on what a competitor may or may not do. I will tell you weve worked super-hard making sure VB is the most productive tool for developers. And that as developers choose Java as their language, we think that J# is the most productive tool for Java developers. And we will be second to no one in terms of developer productivity.

How strategic is SMB to Microsoft, particularly from your perspective? IBM says thats where they have to stop Microsoft.

IBM says thats where they have to stop Microsoft. I think I said thats where we need to better serve our customers. I dont think of it as an IBM competitive thing. I wish IBM all the luck in the world, taking IBMs products and consultants and unleashing them on small business. What I talked about was that I think that we as an industry need to do a better job of building products specifically around small and medium business. And I stand by that. And I think weve done some great work with Small Business Server in that area. I think we need to show people that we need to do more than just take an enterprise product, delete a few features, cut the price a little bit and say voila heres a product for small and medium business. We really need to think about what its like to be an employee in a small and medium business when you may be the IT staff in a small and medium business.

Theres lots of ground for innovation there. Hopefully the work were doing with SBS is a watershed, and it will impact our productivity line as well. Its my goal to really catalyze the industry to really build better products for this space.

Whats your favorite enhancement in Whidbey?

You want to put me on the spot with my development team? It would have to be the return of Edit-and-Continue to VB. Thats a big deal.

Next page: Does Microsoft need standards bodies?

Who Needs Standards Bodies


I have to ask you this because you said earlier Microsoft has "respect for standards." Whats your stance on working with standards bodies? Do you see it as a necessary evil or something that you feel compelled to do?

Well, its certainly not a necessary evil. If you look at what W3C has contributed to the world by creating this asset that we call the Web, that clearly is not a necessary evil. That clearly is a great gift to humankind. So its clearly not that. So what is it?

Standards bodies have an incredibly important role to play in terms of getting vendors to cooperate, in terms of representing user concerns. Its just that theyre not the only role to play. And I think there are times when its important to make sure that vendors really interoperate. And having a published standard is a fantastic first step toward that, but sometimes there needs to be other forums, like WS-I that really does sample code or literally has a budget to put 10 machines in a room—one IBM, one Oracle, one Microsoft, one BEA … and then test those things and make sure that they really work together.

I dont know how to say it any clearer than that. There are lots of components to make sure that vendors really work together because really, standards are about helping with interoperability and making sure things can connect to other things and we can transfer documents from one format to another. And standards bodies have a super-important role to play in that. But weve had plenty of standards that havent achieved critical mass. Weve had X.400, we had X.500, and we had OSI, so clearly its not just having a standards body that brings things to critical mass or creates interoperability. There are other forces that come into play. So Ill say standards bodies are super-important and can be complemented by other processes to really get what customers want.

I think that its important to make sure that the customer has an important voice in what were doing as well, and that really thinking about how to balance between a vendors technical objective and a customers business objective is something that we can do a little bit better as an industry.

Well, the other question is why do you, rather than work within a standards body on stuff thats already in a roadmap, come up with standards or specs that compete with stuff thats already there?

I think what were trying to do is balance pragmatic time-to-market needs with de facto standards needs. And the fact of the matter is it can be difficult sometimes to work within a standards bodys framework. They have specific rules around IP or trade secrets or just specific procedural rules on how often they can meet or how many people need to meet before they can vote on something or before they can modify a spec. And specific rules on who can even see things—whether youre a member or a contributor or part of the working group or not part of the working group. And there are times when youre really trying to drive the industry forward that commercial realities have an important role to play.

And weve tried really hard to balance moving Web services forward, really keeping vendors together by doing things like interoperating with IBM, delivering products on their schedule and our schedule and a standards-body track. I think overall weve done quite a reasonable job. I mean, Web services work. They work cross-vendor. And we got SOAP done, we got XML done, we got UDDI done, were working on getting WS-Security done. And so the fact that things are drafted or put out for public review—weve typically done a spec and shared it for comments by posting it on MSDN and revised it based on feedback—then given it to a standards body. And people who have worked in a standards committee understand a little bit about design by committee versus design by other imperatives. And again its just a balancing act.

And people can criticize one part of the balancing act saying,"There are too many standards," and people can criticize the other part of the balancing act saying, "I want my product yesterday." And we try to walk that line as best we can.

What is Indigo?

Its just a codename for our next-generation Web services runtime. Were always implementing Web services technology. We have some in the base product today. Visual Studio .Net 2003 ships with WSE and well continue to enhance those toolkits. The next significant rewrite for our Web services processing pipeline is in Indigo.

And when can we expect to see that?

I think well see it in the Longhorn timeframe.

Rocket Fuel