The Visual Studio vision
Summary
Topics
Two weeks ago, Microsoft revealed a roadmap for its Visual Studio .Net development environment that described the capabilities of three future versions: one emphasizing mobile development; another boasting integration with a future version of SQL Server (dubbed Yukon); and a third integrating closely with Longhorn, the code name for the successor to Windows XP, due to arrive in 2004.
And last week, Microsoft announced its free Web Services Development Kit (WSDK), an extension to the .Net Framework that includes support for WS-Security, WS-Routing, and WS-Attachments. Although none of these three Web services specs has been finalized, fearless Microsoft developers can fire up Visual Studio .Net and start experimenting with them right away to raise the functionality of their applications. Final code for the WSDK will be available this fall.
While the WSDK announcement serves to remind us of the leadership role Microsoft is taking in Web services, the Visual Studio .Net roadmap signals, once again, how rigorously Microsoft is cloning the functionality of the Java juggernaut.
The first Visual Studio .Net revision--code-named Everett and characterized as a "minor revision" by lead product manager Chris Flores--will feature Microsoft's answer to Sun Microsystems' Java 2 Mobile Edition (J2ME), the .Net Compact Framework. This actually plugs a pretty major gap. Any machine that runs a .Net application requires the Framework at runtime, just as you need the Java Virtual Machine to run Java apps. As the name suggests, the Compact Framework is a subset of the full-blown Framework that should fit comfortably on mobile devices, just like J2ME.
Of course, you could run Java or .Net apps through a browser on your PDA--except that nobody has that kind of always-on wireless connectivity. Mobile apps need to run in offline mode, which is really a return to the old client-server model. Which begs the questions: How do you avoid the miserable deployment and versioning problems of old-fashioned client-server?
"We've combined the best of the Windows client with easy Web based deployment," says Flores. "So to deploy an application, you could put it up on the Web server and simply have your users point to a link, and instead of the Web browser firing up and hitting a Web page, the .Net framework will pull that down to the user's machine and install it automatically." Thereafter, users can run in offline mode--and no one has to worry about version or DLL conflicts. In addition, ASP mobile controls due in Everett will have the ability to sense the type of device making the request and send the appropriate code. Until now, only Java-based mobile application servers have provided these types of capabilities.
The next version, code named "Visual Studio for Yukon," will take advantage of the fact that Microsoft will actually be embedding the Common Language Runtime (CLR) into SQL Server sometime next year. Among other things, this will enable you to write stored procedures in other languages and have them execute as SQL queries in the database. Are you ready for Visual Basic database queries?
Before you purists out there shudder in disgust, consider a couple of points. First, database developers are a limited resource, and integrating the database into the development environment is an interesting solution to part of that problem. Second, remember this is only one example of a cumulative .Net effect: as one by one various .Net Enterprise Servers get the .Net treatment, their functionality gets exposed within Visual Studio .Net, providing an ever richer development environment.
I'm "not technical enough" (Bill Gate's ultimate insult) to evaluate the barrage of criticism from the Java camp about Microsoft's vulgar efforts to duplicate Java functionality. What I do know is that Java is hard--and the number of truly expert Java programmers is relatively small. With .Net and Visual Studio, Microsoft continues to build a rich environment accessible to all kinds of programmers.
Will the code generated by the average Visual Studio jockey look uglier than well-formed Java? Probably. But if Microsoft does a good job of maintaining a secure, managed environment for that code, do we really still care how gosh darned tight it is? Yes, the "if" in the previous sentence is a big one--there are those nagging Microsoft security concerns--but surplus processing power continues to diminish practical differences between beautiful code and so-so code that works. As it has in so many other areas, Microsoft has seen the benefits of what someone else invented and is offering its own commoditized version, along with a panoply of extra, integrated capabilities. Is that such a bad thing?
Come on, Java partisans, flame me. TalkBack below or e-mail us with your thoughts.
Talkback - Tell Us What You Think
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
