Back to VSLive! San Francisco Show Daily Home

	email article
	printer friendly
	more resources

Build Distributed Apps a New Way
Whitehorse uses an extensible SDM schema to help you design, build, and deploy distributed heterogeneous apps.
by Patrick Meader, Editor in Chief, Visual Studio Magazine

VSLive! San Francisco, March 25, 2004

Keith Short Architect, Microsoft's Visual Studio Enterprise Tools Group

Visual Studio Magazine's Editor in Chief Patrick Meader spoke with Microsoft's modeling maven Keith Short recently about the new Visual Studio Distributed Architecture Designer technology, code-named "Whitehorse." Whitehorse will be included in Whidbey, which is being previewed at VSLive! this week. This is Part 2 of that interview. (Read Part 1 here.)

In Part 1, Short discusses how Microsoft's product strategy differs from previous, largely unsuccessful efforts to popularize UML and other modeling tools. In Part 2, Meader asks Short why Microsoft chose not to go with a UML-based approach, the issues of using Whitehorse in heterogeneous environments, and more.

Patrick Meader: How will Whitehorse handle modeling the complexities of distributed applications? I understand it uses System Definition Model (SDM) for this.

Keith Short: That's right. SDM is an XML schema that describes distributed applications from a perspective of design, implementation, and deployment. SDM is a key element in an overarching initiative we call the Dynamic Systems Initiative (DSI), a long-range initiative spanning multiple releases of Windows moving forward. DSI will increase Windows' ability to provide a more dynamic allocation of application resources. And SDM is the key schema that underlies and threads through all these design-deployment-production scenarios.

Think of SDM as the schema behind the two kinds of diagrams we've been talking about—the distributed service designer and the logical datacenter designer. Both are specializations of this common schema, which allows us to do validation between the two.

The logical datacenter designer is all about software settings—what host software runs on which server type, what settings it has, what protocol settings you'll allow between those server types, and so on. Those settings will be extensible, and we'll provide some common definitions out of the box. For example, we'll provide definitions for configuring IIS in certain datacenters. IIS has a lot of settings, so it'll be handy to have some prepackaged bundles of settings for it.

SDM is an extensible schema. For example, the facilities on the logical datacenter enable our customers to use that extensibility to add new constraints representing things they do in their datacenters.

Similarly, on the distributed service side (the one used by the software architect), the information on each type of service is also extensible. That means our customers will be able to add new server attributes and values for them as they're doing their design. Furthermore, we think the distributed service designer will enable people to describe common structures of services and in fact promote those to be toolbox items.

For example, a company might use a particular configuration of settings that even drill down to individual aspects of WSDL [Web Services Description Language]. That company might want to freeze these settings as toolbox items. Thereafter developers can drag that service out of the toolbox, automatically installing the settings preconfigured for that kind of service. That's the kind of extensibility we expect to support from the first Whidbey release onward.