The upcoming release of Visual Studio .NET (code-named Whidbey) includes a set of modeling tools currently known as “Whitehorse.” Whitehorse aims to help solve common enterprise development problems with a toolset that has three facets:
- A service-oriented application designer that enables systems to be designed as a federation of connected applications and components
- A modeling tool that enables IT and network architects provide a logical description of a data center that includes the resources, connectivity, and restraints available to applications
- Tools that enable application and system designs to be validated long prior to deployment into the enterprise; validation can be performed during early architectural discussions
Part of Microsoft’s Distributed System Initiative (DSI), Whitehorse includes tools that will help manage several pain points that currently exist when developing service-oriented enterprise systems. While the current set of commonly used modeling tools tends to focus exclusively on narrow aspects of software analysis and design, the system model used by Whitehorse also gives equal weight to deployment and configuration constraints that occur in the enterprise.
The Problem with Enterprise Development Today
Many enterprises recognize the advantages that can be obtained by moving to a service-oriented architecture (SOA). Such an approach enables complex systems to be built by combining a framework of multiple, composable applications, with each application built to specifically provide an autonomous service. Although SOA enables agile and flexible systems, these features place additional pressure on IT software development and operations resources. As a system evolves, the SOA affinity for composition and reuse make management more difficult.
During development, it can be difficult to capture the precise requirements and dependencies for the various component applications in a distributed system. It’s common for processes embodied in distributed system to lack formal, detailed documentation of dependencies external to their specific application. Even if a development team follows modern processes and models its design with UML, maintaining the software used in distributed system is a difficult task. For example, if an auditing system depends on an address validation application, the nature of that dependency may not be completely formalized. Lacking a formal definition costs money (and increases risk) when the auditing system or address validation application are versioned or replaced.
Even if a development team has carefully documented external dependencies, additional risks are encountered at deployment. A frighteningly high percentage of systems fail during their initial deployments. Many development teams deploy applications with a mixture of home-built scripts and tribal knowledge.
Assuming the application is deployed, the risks and associated costs continue. If a semi-autonomous application provides services to multiple applications (or even multiple systems), what are the implications when that application is versioned? When the application is moved within the data center (or relocated to a new data center), what are the application’s exact requirements with regard to security, connectivity, and access to other resources?
These risks are often difficult to accurately assess, due to the lack of a widely adopted, formal way to share information between development and operations staff. Architects concerned with designing a network or data center generally don’t use UML deployment diagrams—rather they use modeling and design tools specific to their needs. When development and operations teams use different tools, it is very difficult to communicate in an accurate manner.
Using Whitehorse to Define a System
A core part of DSI is the System Definition Model (SDM), an XML document that follows a system throughout its life, and is kept updated as a system moves from the initial design and development stages through its lifecycle and into maintenance.
The SDM defines a system, which includes hardware and software resources. The SDM includes a means for the system to compose other systems and subsystems, expose its endpoints for communication purposes, and document its configuration requirements.
When initially created, an SDM document can be a simple, skeletal view of a system. Additional information can be added to flesh out semantics, such as server configuration information, security and connection policies, service level agreements, health models, and other information. Partners that are joining with Microsoft also will create tools that consume or manipulate SDM documents. For example, although Whitehorse does not include tools that offer all of the functionality of the UML, a partner could extend SDM to include this content.
Modeling Applications and Systems with Whitehorse
There are two primary aspects to an SDM model. One view of the system is operations-centric, and includes information about server software, allowed routes of communication, security configurations, and other data points. The software architect’s view of the system includes information about various software components, connectivity and security requirements, and other configuration data.
Whitehorse sees both views of the system as having equal importance. The reason for this quality is the idea of “Design for Operations:” creating a system design that takes into account operational constraints. This is in contrast to the current practice in many organizations, where the deployment design phase takes place near the end of the development process. When software architects can obtain an operational model early in the design process, the resulting design can take advantage of efficiencies in the operational model or data center; more importantly design decisions that are inconsistent with operational policy can be avoided. If the design requires policy to be changed, that change process can be started early—rather than waiting until deployment is imminent (or even in progress).
Systems are created by assembling a collection of applications that provide services for the system. For example, a simple system may consist of an ASP.NET Web application located on a Web server in the DMZ, that communicates via a Web service located on another server, which communicates with a third server providing database access from SQL Server or DB2. Each of the applications has different needs with regard to its runtime requirements.
There are three modeling tools included in the initial Whitehorse release:
- An application designer that is used by software architects to model service-oriented systems
- A logical data center designer that enables the description of a logical view of a data center
- A system hosting designer that is used to map models from the application designer to a logical data center
An architect who begins to design a system’s software architecture using Whitehorse can start with an existing model of a data center provided by operations architects (or staff). This model may contain servers that include typical configurations for corporate presence, Web services, data access, and other tasks. This logical view of network and server hardware provides a logical, scale-independent view of the data center that enables the initial design of the system to be created.
By using the logical model, a software architect can model a system that includes semi-autonomous applications such as Web applications, Web services, and data access. With Whitehorse, the model is always in-synch with the application code. For example, adding a method to a Web service immediately updates the model, and adding a new method (or a new Web service) to the model immediately updates your code.
The logical data center model provided by the operations staff may include models for standard building blocks such as database servers and Web application servers. If the software architect attempts to place an application at an inappropriate location, such as locating an application that requires direct file access on a Web server, Whitehorse can provide feedback that warns the architect of the problem.
More Information
After the initial introduction at the PDC last October, Microsoft has begun showing Whitehorse to wider audiences, beginning with DevDays ’04 events that are occurring throughout the country in March. More information about Whitehorse is available on the Microsoft Visual Studio Enteprise Web page at http//msdn.microsoft.com/vstudio/enterprise.
About the Author
Mickey Williams is the founder of Codev Technologies, a provider of tools and consulting for Windows Developers. He is also on the staff at .NET Experts (www.dotnetexperts.com), where he teaches the .NET Framework course. He has spoken at conferences in the USA and Europe, and has written numerous books on Windows programming including his most recent, “Microsoft Visual C#”. Mickey can be reached at mw@codevtech.com.
