At VSLive!, New Application Architectures Cast an Alluring Glow

At VSLive!, New Application Architectures Cast an Alluring Glow

he semi-annual Windows developer trade show VSLive! took its turn in San Francisco this week, giving the 2,000 attendees a look at how the promise inherent in some major architectural advancements are starting to transcend theory and come to fruition on desktops. For example, smart clienttechnology was a big focus of the technical program, which, as a mobile-enabling architecture, dovetailed nicely with Microsoft’s recent efforts to push the Tablet PC device format and developers’ interests in the Ink SDK.

And, speaking of ink, Tuesday at VSLive! was dubbed Indigo Day, and the Microsoft knowledge machine bubbled forth some very solid-looking sneak peaks at this much-touted framework for service-oriented application management. During the Tuesday morning keynote, Microsoft Vice President for Tools and Servers, Eric Rudder, strayed little from this message: that Indigo will be the piece now missing from developers’ toolkits wherein nearly every type of RPC?whether it’s Web services, messaging, or COM+ components?can be easily converted into a modern, managed Web service.

While the foundation of Web services will remain unchanged, based entirely on the industry-standard SOAP and WSDL specifications, the process of buildingWeb services will be transformed for the better, according to Redmond execs. How? Indigo will leverage the simplifying power of attributes, with tens of thousands of lines of code automatically output by the framework, from one line of structured manual code. Meanwhile, messages managed under Indigo will reap the significant benefits of a common architecture, sharing APIs that provide security and reliability.

Plumbing the Depths of Indigo
Indigo shelters the various technologies used to transmit data across tiers in distributed applications today under one umbrella. RPC technologies including COM+ transacted components (enterprise services), message-oriented program components (MSMQ), WSE, and Web services can all be absorbed under Indigo, making the architectural choice for transacted communications straightforward and adding a layer of management that guarantees levels of security and reliability. Messages transmitted via .NET Remoting, which is applicable in situations where you have control over both server and client, can also be absorbed under Indigo, but requires changes to the server model, making them “a little bit trickier,” said Rudder. At least initially, developers might want to leave remoting applications out of the Indigo mix.

Using Indigo hinges on the .NET Framework’s ability to use attribute-based programming, or metadata, to accomplish defined tasks without coding them explicitly. Attributes let you change the runtime behavioral characteristics of your code without changing the domain logic code itself. These attributes cover characteristics such as security, reliable messaging, policies, and transactions.

To bring your existing messaging code under the Indigo umbrella, you’ll simply need to decorate your code with the appropriate attributes. The simple act of adding these attributes can have the effect of creating thousands of lines of code that formerly needed to be written by hand. While attributes themselves are likely to require some getting used to (many have multiple parameter declarations), they will certainly be easier than the way Web services and transacted components are written today.

However, attributes raise additional concerns about debugging and the interaction of code, attributes, and configuration settings. For example, a developer might define encryption protocols via attributes while later an administrator might specify encryption protocols via a configuration file. The question then becomes: Which takes precedence? In addition, developers need to accurately predict the outcome, in other words, they need to know what’s really going over the wire.

In a meeting with DevX, Ari Bixhorn, Microsoft’s lead product manager of Web services strategy, said that the Indigo development team is well aware of these difficulties and the delivery version of Indigo will address these concerns by limiting where you can specify such functionality to one or two of the code/attribution/configuration locations. Further, Microsoft will provide debugging tools and configuration editors that help address the problem.

A CTP (Community Technology Preview?sort of a look-but-don’t-touch-too-hard alpha release) of Indigo is promised for March (though Rudder joked that it might be “March 38th”). That CTP release will also include an updated preview of Avalon, the presentation-layer piece in Microsoft’s three-pronged plan for modernizing the Windows application architecture (see Table 1). Rudder also promised “architectural guidance” in the form of a downloadable sample application and documentation?a new version of the “Global Bank” application?that will provide hands-on field and partner information for architects and developers.

Table 1. Microsoft’s three-pronged plan for modernizing the Windows application architecture includes Avalon at the presentation layer, WinFS at the data layer, and Indigo at the communications layer.

Project Layer Availability
Avalon Presentation CTP in November 2004; CTP update in March; final version expected prior to Longhorn release
Indigo Communication CTP in March; final version expected prior to Longhorn release
WinFS Data No preview in sight; final version will be released after Longhorn

Click-Once Deployment and Reg-Free COM: Smart Clients Reach Fruition
While Indigo is still very much a future-looking proposition, many other proposed changes to improve application architecture are starting to bear fruit; developers at VSLive! had their choice of many technical sessions that advised how to begin really implementing “smarter” applications that can detect network awareness and cross the chasm between connectivity-dependent Web apps and stuck-in-the-mud Windows applications. Microsoft seems to be betting that the time is ripe for smart client deployment. (For a brief primer on the smart client architecture, see the sidebar “Smart Clients: The Best of Both Worlds.”)

In Visual Studio 2005, you use “Click-Once” deployment to “publish” a server-based installation package that clients can download and install with a single click. Even better, these smart clients can update themselves automatically, just like a Web application, so that deploying an updated version of an application consists of little more than publishing the updated files on the server and creating a new manifest file. The next time a user launches the smart client, it recognizes that a new version is available, and downloads and installs it automatically.

But what if your application requires a COM component or DLL? Belatedly, Microsoft has also made it possible to use ClickOnce technology to deploy applications (to Windows XP only) that require older COM components, but without modifying the registry, letting different applications use different versions of COM components simultaneously?a capability that would have largely circumvented “DLL Hell” if it had been made available several years ago. Microsoft originally termed assemblies deployed in this manner as “side-by-side assemblies,” but it’s been renamed to “Reg-Free COM.”

Moreover, smart clients use Web services to mimic the role that Web browsers played in querying and updating centralized data. In other words, smart clients eliminate the management problems that plagued the earlier rich clients.

Visual Studio Tools for Office
Microsoft also announced a new version of Visual Studio Tools for Office (VSTO, pronounced “visto” by the Redmond delegates)?and this version has grown up. While the first version provided .NET developers with easy ways to access the Office object model, this new version is nothing less than a specialized copy of Visual Studio that targets Office applications as a new “platform.” Sure, Office developers have been writing applications on top of Office for a long time but never with this level of support.

Figure 1. Excel Hosted in VSTO: The figure shows an Excel workbook hosted in the VSTO development environment. Note how the Excel workbook becomes the design surface in a VSTO project.

When you select Word or Excel as your target in VSTO, the Word document or Excel workbook appears inside Visual Studio as the design surface, just as a new Windows Forms or ASP.NET application provides a Windows Form or Web Form as a design surface (see Figure 1). You have the full range of .NET controls available in the toolbox, along with all their properties and events. VSTO also exposes Word and Excel objects as first-class .NET objects, along with Intellisense, a full set of events that you can intercept and program, and all their properties. In other words, VSTO lets you bypass much of the process of learning the complex object models of Office applications and simply use your knowledge of the .NET framework to program them. But you still have the full power of the Word or Excel application available. You can even interact with VBA code, so you can take advantage of your legacy code.

VSTO will ship as part of the Visual Studio Team System for enterprise developers, and will also be available as a standalone product and as an integrated add-on to Visual Studio Professional. When you purchase VSTO as a standalone product, you get the VB.NET and C# languages, but not Managed C++ or J#, nor do you get ASP.NET or the Compact Framework development capabilities of the Visual Studio Professional product, but other than those, you get the full power of the framework. If you later decide to purchase VS Professional, the two products integrate so that you have only one development environment rather than two separate IDEs. The same is true in reverse?if you start with VS Professional, VSTO integrates into your existing installation. In both cases, if you already have one, you’ll be able to upgrade to the other at a reduced cost.

In many ways, developing to the Office platform makes perfect sense, because Office is already a smart client. A client is really just a runtime platform that can execute code; whether you decide to make the client a browser, the .NET framework, or Office really depends on what your users already have available, and what the deployment considerations of your particular application are. Bear in mind that when you develop an application for Word or Excel, you automatically get a rich client with powerful formatting, display, charting, and printing capabilities built-in. Many applications that developers have until now written as Windows Forms or Web applications should benefit from the newly elevated status of the Office platform.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist