Preview: Visual Studio 2005

But these changes go beyond giving back what Microsoft took away. The new C++ compiler back end generates highly optimized, native executables for Athlon FX, Athlon, Itanium, Opteron, Pentium, Pocket PC, and Xeon. The 64-bit code generators are essential to Windows’ enterprise growth, and Microsoft is wise to position Visual C++ as the flagship language for these performance architectures.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Getting the team together

InfoWorldreaders know how huge the universe outside the developer’s desktop is. Big, interconnected projects that involve engineers, designers, testers, managers, support personnel, and operations staff require some combination of life-cycle and project management tools. That’s where VS Team comes in. It will use design — class modeling, service-oriented application design, and logical infrastructure design — to project a cohesive, individually relevant view of the life cycle to each participant.

Microsoft’s initial release of VS Team will, as one expects from a first release, fall short of meeting vendors’ and customers’ needs. For one thing, the current design does not support the use of multiple VS Team Foundation servers. This will stymie contracted and outsourced projects as well as projects shared on a limited-trust basis with partners. Load distribution is also absent from this first release, a fact that raises questions about redundancy. Participation from remote locations will be managed through typical remote-access technology such as VPN and Windows Terminal Services.

Given these limitations, VS Team’s definition of “enterprise” may not match reality; however, VS Team could meet the needs of the great majority of midsize-to-large development projects, perhaps petering out before the scales tip to huge or gargantuan.

VS Team’s design toolset comprises three elements. Its class-modeling tool is a familiar component found in all commercial-grade IDEs. It maps the methods, encapsulated data, and interfaces used within self-contained project modules. It doesn’t lay out the cohesive solution that will eventually be deployed, which is good. Class modelers are sometimes misused for this broader purpose, a practice that inappropriately saddles developers with the design of the deployment architecture.

The second design tool in VS Team is the service-oriented application designer. Here, a typical project will come to life as a reconfigurable web of components such as .Net assemblies, COM/DCOM (Distributed COM) objects and Web services. The designer defines connections between components, with associated policies governing such details as the selection of interservice communications protocols and the enforcement of security. The interface paradigm is drag, drop, and connect; and the completed design persists in XML for consumption and modification by custom tools.

Finally, VS Team’s logical infrastructure designer reconciles service-oriented design with operational reality. This design interface maps out the deployment topology and identifies conflicts between it and the application’s architecture. For example, contrary to architectural assumptions, there may simply be no network route between one system and another. The basis for the architectural validation is the System Definition Model, which, as part of Microsoft’s Dynamic Systems Initiative, describes the structure of a group of distributed systems.