Visual Studio 2004 to Speed Programming, Integration
Microsoft's 2004 plans for Visual Studio a.k.a. Whidbey include better tools for XML, data access, performance tuning and code reuse -- key areas geared to make devs more efficient programmers and better integrators. It will also support new WSE (Web Services Extensions) upgrades. For a drill-down view of Whidbey, IDN spoke with Microsoft's Ari Bixhorn, Visual Studio's Lead Product Manager.
Microsoft's 2004 plans for Visual Studio a.k.a. Whidbey include better tools, technologies and outreach -- all geared to make devs more efficient programmers and better integrators It also sports support for new WSE (Web Services Extensions) upgrades For a drill-down view of Whidbey IDN spoke with Microsoft's Ari Bixhorn, Visual Studio's Lead Product Manager
Whidbey's tools will help speed .NET devs' ability to integrate their client apps with back-end systems thanks to next-gen drag-and-drop tools for simpler code generation, debugging and configuration. Now in limited review with Microsoft partners, devs will get their first hands-on peek at the code this fall at Microsoft's Professional Developers Conference.
One of Whidbey's more important focus areas is to enable developer-centric "data access" across a variety of enterprise assets through ADO.NET. In Whidbey, data access will be enhanced through improved ADO.NET class libraries, as well as new controls and services. These enhancements center around ease of use, improved support for XML, code reuse and access to non-Microsoft databases, including Oracle, through native providers or OLE DB.
Whidbey promises three areas of revision:
- Improvements will be made to the usability of the data access object model. Tracing support will be improved for fine-grained debugging of data access components across multiple tiers into both managed and native code. Whidbey will also eliminate the gap between data manipulation and programmatic object manipulation with ObjectSpaces. Complementary to existing data models, ObjectSpaces enable the manipulation of data transparently as objects.
- New classes in ADO.NET will allow developers to isolate their code from data provider-specific information. These abstraction classes enable connections to multiple data providers with a single code base that has all the benefits of optimized, provider-specific data access code.
- Whidbey will provide increased power for performing common tasks involving access, management and manipulation of XML. Whidbey will also include support for XML-based data processing using XML Query Language (XQuery).
Whidbey's other key focus areas include:
- Programming Languages -- Microsoft will add support for each of the four languages delivered as part of Visual Studio (Visual Basic, Visual C++, Visual C# and Visual J#).
- The .NET Framework -- Whidbey will introduce enhancements across the .NET Framework class libraries to better support .NET integration with front-end and back-end assets, focusing on more powerful and agile Windows Forms-based client development, refined ASP.NET web application development, more productive ADO.NET data access, support for the latest web services standards, and expanded functionality for device-based development.
- Enterprise Development -- Whidbey will include new tools for better support of the app dev lifecycle throughout design, development and deployment. Tools will include enhanced project analysis and design, software configuration management, and support for No Touch Deployment. In addition, Whidbey will provide "deep support" for Yukon (the next version of SQL Server) to enable devs to write stored procedures using either VB or C#.
Microsoft also wants to prime the pump for even more embedded features from third parties by expanding its Visual Studio partner program. The revamped Visual Studio Industry Partner (VSIP) program now sports three membership levels to encourage participation from the smallest dev shops and ISVs, and offers free access to a VSIP SDK.
The prior VSIP program help larger partners create dev extensions Virtual Studio .NET 2003. These include: Windows Forms-based access to DB2 from IBM, change management tools from Rational Inc. and COBOL .NET for bringing COBOL programs and rules into the .NET Framework from Fujitsu. But Microsoft wants to broaden the Visual Studio .NET partner community to include smaller dev firms, consultants and even devs within enterprise IT shops.
"We absolutely want to encourage these kind of projects, and so we needed to broaden our partner programs to meet the needs of more than just the biggest companies," Microsoft general manager Marie Huwe told IDN. "Microsoft can't do all we want to for developers just on our own. It will take the partners we have now, and new ones."
The new VSIP categories are as follows:
- Affiliate -- A free membership aimed at smaller companies and academic institutions looking for access to the VSIP SDK, as well as newsgroup support from the VSIP community site.
- Alliance -- At $3,000 per year, this membership targets many component providers (including smaller ISVs and system integrators), and includes all free (Affiliate) services, as well as a 1-year subscription to MSDN and several marketing opportunities, including the chance to participate in Microsoft case studies.
- Premier -- At $10,000 per year, this includes all prior benefits, as well as rights to a special shell-only version of the Visual Studio .NET IDE, which enables partners to prep their products to ship with the Visual Studio IDE completely integrated. Under this program, members can also distribute Visual Studio .NET, license the Visual Studio Premier Partner edition, and participate in global co-marketing with Microsoft.
Part of the vision for VSIP, Huwe added, is to push Visual Studio .NET beyond the view of a traditional IDE. More libraries, components and tools are needed to help developers work and design in a lifecycle way, she noted. "Much of what is available in Whidbey, for example, can help many types of developers, large or small, contribute to this," she said.
What's Whidbey's ETA? Developers will get their first look at code at Microsoft's Professional Developers' Conference in October; beta will be available in the first half of 2004; and FCS (first customer ship) is slated for the second half of 2004.
A summary of the Whidbey road map is available at MSDN.
Inside Whidbey --
An IDN Q&A with Ari Bixhorn
Microsoft's Visual Studio's Lead Product Manager
To get a deeper perspective on Whidbey's features coming and the thinking behind them, IDN spoke with Microsoft's Ari Bixhorn, Visual Studio's Lead Product Manager.
IDN: Microsoft just released your latest version of Visual Studio. Why a road map for Visual Studio 2004 so soon?
Bixhorn: We heard loud and clear from developers that they want to hear more about what's going on inside Microsoft, especially with our own internal product planning so they can plan their own development efforts. Before I came to Microsoft, it would have been great if I knew what was coming a year down the road to help me steer my own internal dev efforts.
IDN: Where are you getting your ideas for Whidbey? Is there a lot of feedback coming in from early adopters?
Bixhorn: The Whidbey release is an entirely community-driven release. We created an unprecedented feedback loop actually before our initial release of Visual Studio 2002. So, for a year and a half, we've been asking customers what they want in future releases.
IDN: Give us a flavor of the kinds of requests you've been hearing from customers.
Bixhorn: OK, as you might expect, the requests break down by the type of developer and project they're working on, so let's look at it from the point of view of our developer communities. So, to give you a couple of snapshots:
VB developers are definitely asking for RAD (Raid Application Development). They want to use visual designers more effectively and have the tools give them more capabilities.
C# developers are more focused on the underlying code itself. They're most likely writing object-oriented components that will be used by other developers, and they're building business frameworks. They've outlined specific enhancements they want for code development and deployment.
IDN: At a higher level, where should the average developer expect to see the most changes in Visual Studio?
Bixhorn: Developer productivity is a key theme. That will take the form of enhancements to C# and VB languages, and improvement in the underlying framework. Even with all the talk about web services and other new projects and technologies, the fundamental challenges developers face are the same or similar today as they've been for the last few years.
IDN: Let's talk about web services and integration. Are developers beginning to do more of those types of projects with Visual Studio, and if so, is that changing how you look at tools and enhancements moving forward?
Bixhorn: There has been a change, with more focus on developers looking at web services, and even integration. Doing software development myself, it used to be, "Let's build an app first and then figure out how to integrate it, or deploy it to work with other applications." Web services is providing developers an inherent way to do that. One of our goals with Whidbey is to make that easier.
Bixhorn: Our Web Services Enhancements (WSE) package is a first step toward that, doing more to help web services emerge from behind the firewall to enable B2B applications.
IDN: How does WSE fit into Whidbey?
Bixhorn: WSE comprises three key web services specs important for B2B applications: WS-Security; WS-Attachments and WS-Routing Today WSE is a download from the Microsoft website. In the future, the WSE services will mostly likely be integrated into the core .NET Framework.
IDN: And what about orchestration or workflow, such as BPEL4WS? Will that be in WSE or Visual Studio?
Bixhorn: We haven't said anything publicly about BPEL in the [Whidbey] road map, but any industry standard related to web services is something we want Visual Studio to be involved in. When we incorporate new features into the core .NET Framework, they'll also surface in the IDE itself so we'll make sure we've designed support for the easy securing of web services.
IDN: So you find that developers want deeper support for web services attributes, such as WSDLs and XML? Or are developers asking for the need to know less about these and have Visual Studio provide more auto-generation and abstraction?
Bixhorn: It depends on what developer you're talking about. If you talk to a traditional VB developer, chances are they say, "I know I'm sending something across the wire, but I'm not really concerned about what it is -- all I know is that I want easy access to it.
On the other hand, a C++ developer will say, "I want to know every character and every bit being sent across the wire."
I think that even now, Visual Studio .NET and the .NET Framework provide that nice balance With our web services designer, a developer can create a web service drag in Visual Studio .NET by a drag and drop of components and tables onto a design surface, just as a VB dev would expect.
At the same time, if I want to drill down into what's going on inside a WSDL, we don't force a "black box" around that; we enable developers to get direct access to that, either through the IDE or through Visual Notepad to look directly at the XML files.
IDN: So, is the trend both?
Bixhorn: That's what we're seeing. The fact of the matter is that with our dev tools, we're targeting such a broad audience. I can have all that [coding information] abstracted away from me, if I so desire. At the same time, I can drill into it as much as I want. Even just looking at VB alone, without the other languages, we have developers doing a whole range from small, two-user Windows apps to enterprise-critical apps that need to take into account web services. In Visual Studio, we need to provide both ends of the spectrum.
In Whidbey, we'll continue to strike the balance as we've done in VS .NET 2003, and that will be the direction we'll want to go in moving forward.
IDN: During the keynote, I noted something interesting. About 90 percent of your audience raised their hands when asked who was using Visual Studio for development, but only about four to five people said they were working on web services. What do you take from that? When developers use Visual Studio, are they building web services, but just may not think of their projects that way?
Bixhorn: I think a lot of that comes from the audience we have here at VSLive. Most VB developers may consider when they use Visual Studio they're doing traditional corporate development, meaning they're building a lot of traditional Windows-based client applications. But I think we're going to see more developers implementing and building web services into their applications. Visual Studio .NET is designed to let developers rapidly deploy custom clients to back-end legacy systems.
IDN: Without using the words XML or SOAP, isn't that a web services way of thinking about front-end to back-end development?
Bixhorn: Yes, I think in a lot of ways it is. Let's go back to the challenges that developers face. As we said, integration is certainly one of them. Deployment is another. In that context, I think it may take some time for developers to realize that they can use web services not just for web applications or web-based scenarios, but also for their traditional enterprise Windows client scenarios.
IDN: Your case study of the Bank of Montreal seemed to make the case that Visual Studio could be used to provide new Windows and web front ends to legacy (non-Internet) systems. Is that project an example of what we're talking about here?
Bixhorn: If you combine the benefits of No-Touch Deployment with the ability to consume web services from client apps, I think we'll see a significant increase in the number of developers who say they're building web services using traditional Windows client applications techniques.
IDN: Is the idea that the Windows client should more easily be able to consume and otherwise integrate with back-end applications and data a key goal for Whidbey?
Bixhorn: Absolutely. Regardless of what your back end is, web services provide an ideal way to get access to that data. Web services are not at all about "rip and replace;" they're about making sure you can take advantage of your existing technology in your organization. VS .NET 2003 and the web services enhancements in Whidbey are keys to that.
IDN: Is DB2 access an example?
Bixhorn: We want to be an open platform for other companies to integrate with, and you'll see more of that in Whidbey.
IDN: What about database access?
Bixhorn: A VB developer should be able to clip out a table or some fields in a table, drag them onto the form and be able to customize the data-bound UI. One of the things in the road map is a similar model for web-based applications. In fact, I just saw a demo of this cool feature for web-based data access.
IDN: How does it go?
Bixhorn: Think about a lot of the things web application developers do today in terms of accessing data and making it readable and very usable. You have a data grid, and that data grid supports paging and sorting of that data, but the data developers have to write a lot of code to get that to work.
In Whidbey, developers are going to be able to clip out a table in the database, drag it onto a web form, have that auto-create a UI and on their SmartTag (web forms smart tag for data grid) they're going to be able to click on a link that says "Enable Paging,""Enable sorting,""Enable deleting,""Enable selecting" without having to write a single line of code. So, developers will be able to save possibly hundreds of lines of code just by using the new enhancements in the designer.
IDN: Aside from all the technology Microsoft is offering developers, we're hearing anecdotally that many developers wish they had more guidance from Microsoft. In the Java world, there are patterns and other model-based approaches. What's Microsoft's view on that larger issue of guidance and patterns?
Bixhorn: We've heard the same things. Our customers tell us, "There are a lot of great tools -- now help me figure out what my overall architecture is supposed to look like." We have the .NET Architecture Center and our patterns and practices area of our website as a direct result of that kind of reaction. We're finding that customers want to know more about our internal best practices, and so we're putting together means to share them.
IDN: How does Whidbey help accelerated back-end access?
Bixhorn: The focus for us now and moving forward is on using standards-based web services, including improving the developer experience in building web services, and ensuring they can connect to a variety of their back-end assets, whether they're from Microsoft or someone else.
IDN: Have you got a recent or coming example?
Bixhorn: Oracle is a good example of these enhancements. With Visual Studio .NET 2002, we had generic providers for back-end data access; OLE DB and optimized SQL Server. As soon as we released that version of Visual Studio .NET we heard from customers, "When am I going to get something for Oracle? So, the 2003 release of Visual Studio .NET, which shipped in April, included optimized Oracle managed provider for access data. So, just with our SQL Server-managed provider, we're using the wired protocols for talking to Oracle databases. Also, with DB2, we've done something similar. (See story.)
IDN: Is there a library of these that I download when I need them?
Bixhorn: [As] part of .NET Framework and VS .NET 2003. I go to my toolbox, I look under the data tab, I see an OLE DB-managed and SQL-managed provider, I see an Oracle provider and a ODBC-managed provider -- and we'll continue to see more.