eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In a nondescript conference room at the heart of Microsoft Corp.s campus here, 35 developers sit shoulder to shoulder and prepare for battle.
This is the Visual Studio “ship room,” and in minutes it will play host to a raucous, relentless and occasionally personal debate over the bugs remaining in the Visual Studio 2005 application development tools. Developers with underperforming modules try to maintain game faces while being hammered with questions over so-called ship stoppers—bugs that threaten to affect delivery of the product.
“We need this stuff fixed to go to RTM [release to manufacturing],” the meetings moderator barks.
Meanwhile, nearby, a more genteel, but no less critical, session is taking place among 10 developers working on SQL Server 2005. Under the guidance of Paul Flessner, Microsofts senior vice president of server applications, the group sweats the details of testing, training and security in Microsofts much-anticipated database release.
“Building software, I like to say, is a little bit like making sausage,” said Tom Rizzo, director of SQL Server product management at Microsoft. “You dont like to see what goes into it, but you like the thing at the end. Customers dont realize the amount of work that actually goes into the process of doing high-quality enterprise software.”
The flurry of activity behind the scenes at Microsoft is not without distinct purpose, officials point out. Outwardly, the company has said that while Visual Studio 2005 will deliver a second beta release, SQL Server 2005 will not see a third beta, opting instead for continued CTPs (community technology previews) of the software until it ships by years end.
The shift in beta program plans, along with the furious development campaign within, is part of Microsofts goal to deeply integrate Visual Studio 2005, also known as “Whidbey,” with SQL Server 2005, known now as “Yukon,” to give developers a seamless experience using the companys development tools to build and deploy database and other applications. Its this bottom-up integration effort that will bring users productivity gains and return on investment, Microsoft officials said. However, both products are late to market, and both are key to future core Microsoft products such as “Longhorn” (Microsofts next major Windows release) and Office 12.
The heart of the Microsoft integration strategy lies in the integration of the companys CLR (Common Language Runtime) into the SQL Server database engine, known as SQL CLR. But it doesnt stop there, Microsoft engineers said. According to Flessner and James Hamilton, SQL Server architect at Microsoft, the decision to integrate SQL Server and the Microsoft development tool set was made in late 1999, before SQL Server 2000 shipped.
“This goes back before we shipped SQL 2000,” said Hamilton. “We had a very small skunk-works project under way” to improve the tools support for the database.
“The database market never attracted the quality tool support, and so what happens, if you look at Oracle [Corp.] or IBM, the tool support is quite weak,” Hamilton said.
Anne Thomas Manes, a Boston-based analyst with Burton Group Inc., agreed that database tools are considered weak. “Its a big win to integrate the Yukon tools with Whidbey,” Manes said.
“The DB tools are decent for designing database tables, but theyre awful for developing stored procedures, triggers and user-defined functions,” Manes said. “Most DB vendors supply a proprietary stored procedure language [SQL Server Transact-SQL, Oracle PL/SQL, etc.]. More recently, the vendors have added support for standard general-purpose languages—Oracle and [IBMs] DB2 now let you build stored procedures in Java, and Yukon and the next release of DB2 will support .Net.”
“The thing youll get [from integration] is the ability to do language-independent development so that where you deploy applications becomes a run-time decision for the IT professional, not a design-time decision for the developer,” Flessner said.
Next page: Shared concurrency primitives and memory management.
Page Two
Developers will be able to use the CLR language they are familiar with—such as Visual Basic or C#—to create SQL Server 2005 applications. Developers also will be able to easily create their own user-defined functions and types, Flessner said.
“The embedding that we did with the CLR is unlike what IBM or Oracle did with their Java or with .Net,” he said. “We really wired it in process to SQL so that we wrote a hosting layer that allows good thread management [and good memory management].”
But while Microsoft is supporting its SQL CLR, the company also will continue to support and innovate around the T-SQL language developers use today to build applications for SQL Server, Flessner said. Yet, for many operations, using SQL CLR will be faster and require less code than T-SQL, he said.
The integration of Visual Studio 2005 and SQL Server 2005 means shared concurrency primitives, memory management and other resources across both platforms, according to Microsoft developers. In addition, the databases integration services interface is built on the Visual Studio shell, providing the same source code management, debugging and visualization. “As your data flows through, you can visualize in a chart or grid,” Rizzo said.
The databases management tool is built on the Visual Studio shell and introduces the color coding of Visual Studio programming in the T-SQL environment, Rizzo added.
“We felt at the beginning of this journey [we should] try to bring the two worlds together,” said S. “Soma” Somasegar, vice president of the Microsoft Developer Division. “SQL Server is a big product, and the product is 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 gives the benefits of the modern programming world to the database developers,” said Somasegar. “Theyre no longer constrained by just one language, be it T-SQL or whatever. You can have developers program to the data tier based on the language that they are most familiar with.”
Despite all the advancements and benefits in the newly integrated products, Microsoft is late to market with both, having set early goals of delivering Yukon in 2003 and Whidbey in 2004.
Rizzo calls it Microsofts big bet. “We embedded the CLR in the SQL Server,” he said. “It runs in process. Thats not easy work. We manage the memory of the CLR and the SQL Server together from the SQL Server standpoint. That level of integration between the .Net technology and SQL Server takes time.”
Next page: Security issues slow delivery schedules.
Page Three
Somasegar and Flessner both said security issues slowed delivery schedules. “We shut down for six months to do [SQL Server 2000 Service Pack 3],” Flessner said. “It flat-out had to be done; you have to protect your assets in the market. We got hit with Slammer, and it shook this building, period. It was an awakening.”
Flessner added that his team knew integrating the CLR would take time, but, he said, “we werent planning from the outset to rewrite our entire developer studio for BI [business intelligence] and the whole SQL Server management console and integrate it into Visual Studio.”
James Holt, chief technology officer of Townsend Analytics Ltd., in Chicago, a Microsoft customer and an early adopter of both Yukon and Whidbey, was in Microsofts customer lab running tests earlier this month. Holt said Townsend has been using a file-based system to store data for a key application but wants to move to a relational database such as Yukon for reliability.
“To make full use of SQL Server 2005, we need a corresponding development environment,” said Holt. “Its seamless, especially when I wrote some custom integration services pipeline code. It was pretty easy to deploy.”
Holt also said SQL Server 2005 ran 20 percent faster than SQL Server 2000 in his tests.
“The CLR is a good thing to add to SQL Server. It will allow us to replace all of our current extended stored procedures written in VB, etc., with C#/VB.Net,” said Stephen Forte, CTO of Corzen Inc., of New York. “Things that are very hard to do, like a sophisticated find and replace at the column level, can now utilize a RegEx pattern and the RegEx class from the .Net Framework.”
That said, “CLR stored procedures should be used sparingly,” Forte added. “Microsoft unleashes a lot of power with the CLR, if used properly. If not, it can slow things down.”
Meanwhile, Microsoft runs its own business on SQL Server and develops its new applications using Visual Studio 2005, said Ron Markezich, the companys CIO. “What the products are enabling us to do is really move to a service-oriented architecture away from what weve traditionally had, which is really a batch architecture,” Markezich said. “Batched data doesnt do much [good] in terms of consolidating applications and ensuring compliance.”
Initially there was some concern about how DBAs (database administrators) might take the move to make core application developers responsible for building and deploying databases via the CLR, but those concerns have diminished, Flessner said.
David Campbell, general manager for SQL Server, said Microsofts approach actually could ease tensions between developers and DBAs as DBAs “get over the hump” of the new technology. “This lets the developer, the Visual Studio customer, do some of their own work in the database in a natural way for them,” Campbell said.
Craig Symonds, general manager for Visual Studio, pointed out that in the SMB (small and midsize business) market, the DBA and developer are often the same person.
“The benefit is that developers can use the language of their choice that is more powerful and more elegant than T-SQL to write business logic,” said Mike Sax, president of Sax Software Inc., of Eugene, Ore. But, Sax asked, “what does it mean for DBAs? War. Invasion of territory. Feelings of insecurity and loss of control.”
Rizzo said that he expects the next cycle for SQL Server to be much quicker than the Yukon cycle.
Meanwhile, Hamilton said Microsoft has worked hard and spent lots of time and money hardening the SQL Server 2005 platform since the company shipped SQL Server 2000 Service Pack 3 two years ago. Last October, Microsoft put together a SQL Server attack team responsible for doing “ethical cracking,” or breaking into the companys systems with its permission. “We wanted a team that knows more about what the bad guys are doing than anyone else in the community,” Hamilton said. “These are some of the scary people you hear about, and we hired them.”