eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
S. “Soma” Somasegar, Microsoft Corp.s corporate vice president of the developer division, and Paul Flessner, the companys senior vice president of server applications, are responsible for the Visual Studio 2005 tool set and SQL Server 2005 database platform, respectively.
As Microsoft moves toward a Nov. 7 launch of both products, along with BizTalk Server 2006, the two leaders sat down with eWEEK Senior Editor Darryl K. Taft to discuss the origins of the products, as well as the deep integration between them, including placing the Microsoft CLR (Common Language Runtime) at the core of both.
Code-named Whidbey and Yukon, respectively, Visual Studio 2005 and SQL Server 2005 are key deliverables for Microsoft as it prepares developers for building and deploying applications that will run in what the Redmond, Wash., company has called the “Longhorn wave.”
Longhorn was the code name for Microsofts upcoming version of Windows, which is now known as Windows Vista. Both Whidbey and Yukon fell victim to delays along the development cycle. The two executives address this, along with other issues.
Can you explain how you came up with the notion of integrating the Whidbey tool set with the Yukon database?
Somasegar: The thing that is interesting to me is [that] we sort of kept data and applications as two different entities or islands, like some people here like to call it. If you look at the developer, look at an application, the application is only as useful as the data that it can access. Likewise, the data is only as useful as an application that can manipulate the data.
So we felt at the beginning of this journey that [we should] try to bring the two worlds together. SQL Server is a … phenomenal product. Customers love that product, and the product is that much more valuable when you have an application that you write on top of SQL that leverages the data in the database.
Being able to take the CLR and wire it into SQL Server right away gives the benefits of the modern programming world to the database developers. Theyre no longer constrained by just one language, be it T-SQL [Transact-SQL] or whatever.
You literally can have developers program to the data—the data tier, I should say—based on the language that they are most familiar with as opposed to some other language that they have to go learn. Then, because its .Net, they get all the benefits of the code safety—the strong type system and the like—so that the code that you write is as safe as realistically possible. If you really want direct access to the data, you can always get that as well.
So the flexibility, the productivity, the reliability, the security—all that you typically hear from developers about moving to .Net—you get that lock, stock and barrel for the database developers for the first time in the SQL world. Thats the reason we are superexcited about this.
Have you considered shipping SQL Server Express with the framework or with Windows so that its available on every desktop?
Flessner: Express will be available pretty freely. We havent really thought about integrating it into the OS or the framework directly. Its something we could look at again going forward, but its not something weve taken on right now. Its going to be freely downloadable and available to anybody who wants it.
What do you think the next cycle of SQL Server will be like? Will it be a quick cycle?
Flessner: I dont know yet. We really are focused on getting it out.
OK. Do you think it will be a 1.0 release, or do you expect many users will hold off and wait for a follow-on or a 1.1 release?
Flessner: Again, I dont know. Weve worked hard on backward compatibility and upgrade, and weve done a lot of work in that space, so were hoping [for] an easy upgrade for customers. And there is an installed base that we believe is anxious to upgrade. So we hope the adoption rate will be pretty quick.
Next Page: Developers enhance security by eliminating native code.
Developers enhance security by
eliminating native code”>
What impact will shipping Visual Studio 2005 a little later have on “Orcas”? [Orcas is the code name for the next version of Visual Studio after Whidbey.]
Somasegar: Our business is like we talked about; there are a few key pillars that we want to get done in Orcas in terms of focus. But like Paul said about the SQL team, we … sort of [are focusing on] trying to get Whidbey done and get this great product out to customers.
What new features in Whidbey will help developers write more secure code?
Somasegar: There are a couple things. As part of the team, Visual Studio Team System, a lot of the tools that we use internally—in Windows, in SQL Server, in Visual Studio, in Office—use what I call static code analysis tools. I dont know whether you might have heard the name like Prefix, Prefast; all those tools we are packaging up, and we are making it available to our ISVs.
Flessner: These are all the tools weve used for years. Theyre hugely beneficial, and getting rid of all this native code is superimportant for buffer overflows and stuff like that. And in managed code theres a whole bunch of best practices that we build in that are just hugely important. We run stuff on the code all the time.
What impact have CTPs, or Community Technology Previews, had? You say they definitely help advance the quality, but do they also add extra time into the development process?
Flessner: The CTP sort of divides the stabilization period of the beta and allows you to amortize it over the development cycle. We have this complex branching system that all big products have, where people check in to their private branches, and then they stabilize, and then when the branches stabilize you roll it into main, and then thats your build that you release. And we do that. Weve just gotten into a rhythm where every month, month and a half, we pull these things up, we do a couple of weeks of stabilization and pop it out, and then we take off.
Somasegar: In some sense, we can argue that we are slowing down development because we are making sure that the quality of what we build stays at a fairly high level as we go along, as opposed to not knowing the state and then spending a bunch of time trying to get to a known state. So from that perspective I think the CTPs really, really help us get the right level of engineering discipline and focus into the product team.
Why did the products fall victim to so much slippage and delay in delivery?
Somasegar: First of all, we sometimes tend to underestimate the cost of integration. I think we are seeing a little bit of that. And we have two big products [for which] weve decided to have certain levels of integration between the two technologies and products.
The second thing is [that] we want to get to a certain level of quality, and if it isnt there—if its going to take me two weeks extra to get there—Im happily going to hold the product and make sure that we do the right thing.
Will database administrators feel threatened by the fact that C# and Visual Basic .Net code will be running on their servers?
Flessner: We have heard some of that. Its sort of waning a bit now, but early on it was, “Oh my God, youre taking these crazy VB guys, and youre going to let them run this code. Whats sacred? Nothing is left.”
I think people who are T-SQL experts, over time, will become experts in other things and theyll appreciate the level of innovation. But, honestly … weve put good exception handling into T-SQL. Weve made them comfortable as well.
Why are you launching BizTalk Server 2006 with Whidbey and Yukon? Whats the relationship there?
Somasegar: Its all about data. SQL [Server] stores the data, aggregates the data, analyzes the data, reports the data. Visual Studio can be used to build applications that take advantage of that data, that leverage the built-in reporting infrastructure and so forth. BizTalk uses SQL Server as the underlying message store. As more and more customers use the three products together to build applications, integrate systems and analyze business results, it makes sense to launch them together and highlight the benefits of using these products together to meet the needs of business.
BizTalk Server is based on Visual Studio .Net and gives developers the ability to integrate heterogeneous applications and orchestrate Web services in a familiar, easy-to-use interface. The Nov. 7 event and ensuing activities give us the unique opportunity to reach a wide audience keenly interested in understanding the value of using BizTalk Server, SQL [Server] and Visual Studio together.
At launch, we will offer a beta version of BizTalk Server, which will include support for the RTM [release to manufacturing] versions of SQL [Server] and Visual Studio. We are launching BizTalk Server with SQL [Server] and Visual Studio to ensure that we are as considerate as possible with the resources of our customers and partners.