Over the last few months, Microsoft has been previewing bits and pieces of the next release of Visual Studio, now being called Visual Studio.NET. Each of the individual products has had its respective day in the limelight - starting with Visual Basic and followed by glimpses of the next versions of Visual FoxPro and Visual C++. All products heavily favor new server functionality and integration with COM+, and performance and scalability figure prominently. HTTP connectivity and XML are the keys to distributed applications, and according to Microsoft, VS.NET will be there to make it all simpler.
Microsoft is on an ambitious path to make Web development more accessible to the masses; and with good reason. Web development today is not exactly easy. Today's Web applications, although powerful, tend to be made up of a mish-mash of solutions and tools that rely heavily on the implementer's understanding of the technologies involved. Web development tends to combine a good many things that don't directly fall into the developer's domain, such as layout and graphics, network administration, security, server administration and fine-tuning Web servers. This is in addition to standard APIs, the intricacies of COM, database know-how and tuning, and good object and software architecture skills. Although many developers have gotten up to speed on these technologies and their interrelations, it is still far from easy to build scalable Web and Enterprise applications.
With Visual Studio.NET, Microsoft appears to be aiming at exactly these problems by trying to integrate as much of the development and architecture know-how into the development tools and the operating system.. This is more than what we see today in sharing COM components– it's at a lower level that embraces the services that the operating system provides. Tools like Web Forms, where client-side script fires server-side business rules, rely on an intricate framework that works from any tool that supports the framework. The generic term “Web Services” refers to components that rely on a set of framework guidelines outlining how clients can talk to servers to retrieve data in an organized manner. Simple Object Access Protocol (SOAP) will figure heavily in this space and provide a common interface to retrieve data over the Web. The focus will be less on building HTML-based interfaces, and more on sharing data from applications that talk to each other over the Internet.
Although Microsoft has been tight lipped about what exactly will be provided in Visual Studio.NET or how it actually works, the demos that have been shown so far are very impressive. Point and click to build Web applications with rich GUI designers that can work in any browser. That sure sounds like a better way to develop applications, but until we see how the architecture works and what code has to be written, it's a little premature to proclaim Web development nirvana.
As we write this column, the Microsoft PDC conference is just finishing up, with lots of additional details released about .NET and a preview copy given out to attendees. The MSDN Web site (http://msdn.microsoft.com) also has been updated with high level papers that describe the various new technologies.
But, because this technology is still quite a way off (Microsoft has hinted at mid 2001), it's important to remember that Microsoft is also taking a gamble with Visual Studio.NET. Much of the new technology shown is already available today in other forms. The rapid acceptance of XML, and the ability to share data using XML and HTTP, may make some of the tools in VS.NET a little late to the party. Although VS.NET without a doubt will make this process much easier, these applications are already taking off today with custom XML implementations that allow client and server applications to talk to each other. XML developers can benefit from the existing HTTP platform infrastructure and knowledge base. This issue of CoDe has two articles with generic, custom implementations for XML messaging.
VS.NET will be very closely tied to the operating system and will rely heavily on those operating system services. You won't just be running your favorite compiler or development environment - you will be running an extension of the operating system, scripted by a front-end language which has access to lower-level system and language features. Microsoft has announced the Common Language Runtime (CLR) which provides the guts for things like user interface controls, system (like API access, HTTP protocol access etc) , XML and even basic language (like string parsing) services. The operating system will also provide the administrative hooks for updating and managing code on the Web server. It sounds ideal - every development tool uses the same high-level APIs. These tight links to the operating system are both good and bad. Good, because you get much tighter integration. Bad, because there's a lot of black box code in a myriad of system DLLs residing in the operating system. A potential failure or misbehavior there cannot be debugged or fixed easily unless Microsoft provides a patch.
Don't forget that understanding Web architecture, and knowing how to build things from the ground up, are still very important skills, regardless of how easy VS.NET may make the process. To troubleshoot applications and the infrastructure, you still need to understand what's happening behind the scenes. An understanding of the architecture will serve developers well in the current environment and in any that follow. HTTP and XML are the cornerstones, so becoming proficient with them will give you more options. You can build at the low level with custom implementations, or wait it out for high-level tools like VS.NET.
About CoDe Magazine…
After the initial issue of CoDe, we received lots of feedback. CoDe Magazine obviously hit a previously unsatisfied market, and there was excitement surrounding the first issue. Because this magazine is published by people who spend most of their time developing cutting-edge applications, we received many positive comments about the content. However, software developers aren't necessarily great copy editors - a fact that has been pointed out by more than a few people, and didn't come as a complete surprise to us. For this reason, David Stevenson is doing the copy editing for CoDe Magazine, beginning with the current issue.
We also want to point out CoDe Magazine's web site (www.code-magazine.com). We are working on some exciting enhancements as part of our efforts to build a solid and professional CoDe Magazine Online Community. Perhaps we will meet online…
Rick Strahl and Markus Egger, Editors
