Visual Studio 2005

Visual Studio Team Architect is a suite of graphical design tools, targeted at architects and developers, to be delivered with Visual Studio 2005. It supports the Visual design and validation of connected systems. Visual Studio Team Architect is an early deliverable from the Dynamic Systems Initiative (DSI), aimed at improving the design, deployment, and management of enterprise-class distributed systems.

Design Goal: Visual Design of Connected Systems
Service-oriented or "Connected Systems" architectures serve as the basis for the next generation of distributed applications. The Microsoft Indigo platform will provide the industry-leading implementation of service-oriented applications. Indigo will build on the SOAP and Web services support provided in the Windows platform today. It will add support for a comprehensive range of transports and application topologies, enabling secure, reliable, and durable message-based communications between services. Although Indigo technology release is still well into the future, service-oriented applications can be built today, using SOAP, XML messaging, and Web services. Web services offer particular promise as the means to integrate heterogeneous information systems. They do so by wrapping intrinsically autonomous systems behind a common Web services?based infrastructure to enable access from a range of devices, both inside and outside the corporate firewall. Web services offer great promise for edge systems, enabling new business processes that tap into existing system resources. They also offer the potential to be used increasingly in the fabric of entirely new systems. Visualizing the application structure as an integral whole becomes increasingly difficult as the pieces are more fragmented in a service-oriented architecture. Additional emphasis is placed on the design of interfaces offered by services. To enable interoperability, these interfaces are message based. Designing new messages and ensuring conformance with existing message schemas is crucial. Helping application architects and designers visualize and design the application as a whole is increasingly important in service-oriented architectures.

Design Goal: Design for Operations
Whether they are distributed or not, all applications require services of the underlying platform. Too often, the burden is placed on the developer to "document/specify" application service dependencies and configuration requirements of the target deployment environment. Although many development tools focus exclusively on functional requirements of the application, the nonfunctional requirements are often the source of configuration or deployment problems, or both. On the other hand, Operations and IT organizations have a different set of development tools that cater to nonfunctional aspects of distributed system and focus on network and infrastructure design, performance monitoring, and management. The real issue is that what Operations view as part of the application, developers view as part of the infrastructure. It is this information that needs to be captured and communicated between these two groups. Consider the simple case of developing and deploying an ASP.NET Web service. Although the developers? primary concern should be the implementation of the service, they invariably have to concern themselves with security and authentication models. They also have to think about what other supporting services are required on the target environment and what parts of runtime configuration will cause the Web service to operate as desired. Operations needs to understand what protocols and services are required by the new service, and whether corporate IT policy has been followed. This disconnect leads to deployment issues, often resulting in mismatched configuration. Worse yet, it can result in a design that is incompatible with the data center, causing a large amount of the IT budget to be spent on the cost of poor quality. Although many organizations attempt to address the communication issue with documentation, design reviews, and elaborate diagrams, they simply lack the tools and the common language to effectively enforce and communicate their policies. Furthermore, these "processes" are so far removed from the actual tools that developers and operations use every day, that the process itself contributes to the problem. These groups are organizationally and functionally disconnected. They rarely collaborate proactively and often come together reactively to diagnose problems that could have been prevented early in the development cycle. Visual Studio Team Architect is a unified development environment that begins to bridge the gap between the two groups by bringing them together into the software development life cycle.

The Visual Studio Team Architect "Distributed Designers Suite"
To deliver an integrated design experience for addressing the goals of "Visual Design and Validation of Connected Systems," the design suite of tools was built using the System Definition Model (SDM) from the Dynamic Systems Initiative (DSI) as the basis for the underlying meta-model. This describes concepts of connectivity, configuration, and relationships not only for the application services, but also for the runtime environments. SDM is based on a multilayered model (applications, application hosting environments, network topology and operating Systems, and physical devices). Thus, the tools can now express relationships in terms of requirements and policies across all layers of a distributed system. Visual Studio Team Architect was also designed as an extensible platform to enable internal and external partners with the domain expertise of the application space (Web services, Web applications, data access, etc.). This is in addition to the Operation Space (runtime hosting environments, security, connectivity, configuration, etc.). Thus, they can define their own abstractions.

The resulting integration of two domains (development and operations) into a single suite of tools allows Microsoft to address these customer problems in the following ways:

• Uses a common language (expressed as SDM) to describe the design and configuration of a complete Distributed System.
• Uses abstractions such that developers and architects of many disciplines can communicate on common ground.
• Allows an architect or developer to express application requirements of the runtime environment.
• Allows operations (or application architects with knowledge of the target deployment environment requirements) to express application runtime, security, and connectivity requirements that are compatible with the policies of the target deployment environment.
• Integrated with the existing Visual Studio project system and .NET platform technologies.
• Integrated with Visual Studio Team System artifact and source code control features.
• Strategically positioned on the DSI roadmap to enable deployment and management scenarios and support for Indigo in future releases of Visual Studio Team Architect.
• A platform for extensibility to build an ISV and partner ecosystem.

Design Suite Features
The Application Designer (AD) provides a design surface for diagramming applications that expose services and communicate through messages. The user is able to describe these messages through communication endpoints. This is done using SOA protocols, such as SOAP, in either an Operations approach or a WSDL contract message-based approach. Prior to committing to code the user is able to visualize the design of connected applications with the communication dependencies exposed through endpoints in a graphical layout. Applications in this context are therefore autonomous units of deployment (e.g., Web application, Windows application, etc.) that run in their own process space. Therefore, the diagram visualization will not include dependent assemblies or references to projects within the solution that are not themselves "applications" by definition. The applications are implemented via a user action from the diagram that will generate the project structure and initial implementation of the contract. Then they are fully integrated with the Visual Studio project and language system. They are continually synchronized with the design surface, providing the user the choice to edit on the design surface or the code editor. Native supported application types in the Visual Studio 2005 Team Architect release are Web services, Web applications, Windows applications, external databases, external Web services, and external Biztalk services. The AD is also used to capture application configuration (e.g., Web.config and Web application configuration from IIS) that is fully synchronized by the designer. This allows the architect or developer to capture the exact configuration required by their application, while exposing the rich metadata to the constraint engine (implicit part of the tool). Thus, other designers in the suite can leverage that information to perform constraint validation, consistency checks, and generate deployment information (refer to the System Designer, Logical Datacenter Designer, and the Deployment Designer next).

The Logical Datacenter Designer (LDD) is used by architects to create diagrams that represent the logical structure of some portion of the data center. This is done to communicate important information to the developer about the target deployment environment for a particular application domain. This information is captured in the tool to validate application design and configuration requirements (refer to the Deployment Designer, next), to increase the probability of a successful deployment. The diagram itself represents an abstraction of the real environment. By design it does not capture typical "infrastructure or System Architecture" elements (e.g., firewalls, routers, switches, IP address, etc.). These are often part of the problem in communication between Operations and Development groups. Instead, the diagram focuses on capturing the application runtime hosting environments into design elements called "logical servers." The information specified in this diagram represents the types of communications allowed, the types of services enabled, and the configuration requirements of the hosting environment that affect the application design and runtime characteristics. The LDD allows the architect to specify a diagram of interconnected logical servers, specifying and/or importing settings from real servers. The topology of the data center can also be specified by representing application hosting environments, such as Web servers, database servers, application servers, security zones, and communication pathways, with specific protocols. Once the logical datacenter has been described, the user can then begin specifying policy constraints for applications that are to be hosted in this representation of the data center. For example, with this diagram, an architect can specify the ASP.NET Security requirements of the Web applications hosted on a particular IIS Web site. The user can specify the connectivity to other logical servers, such as databases and Windows services. He or she can also define logical boundaries called "zones" that represent a security, communication, or other physical barrier that an application developer would find useful in considering a distributed design. Similar to the AD where application architects can specify hosting requirements against the LD configuration, infrastructure or operations architects can specify application requirements against application configuration of the AD.

The System Designer (SD) is used by an application architect to visualize and compose applications defined in the AD, for the purpose of creating connected systems. A configured system consists of one or more applications configured for a particular deployment of that system. Systems can contain (and nest) other systems; thus allowing for the visualization and specification of large-scale service-oriented architectures. With the System Designer, application architects can describe dependencies on services provided by other systems without requiring prior knowledge of the internal structure of the applications that comprise the system being consumed. The System Designer offers a top-down design mode. Systems can be composed at a high level and then individual applications within the system can be visualized and defined (if the applications within the system are part of the solution). It also provides for the encapsulation of services exposed by applications within the system. Specifically, the architect can choose which services are directly addressable outside of the system. The System Designer can be used to address EAI and edge system scenarios where existing applications expose services through Web service protocols.

The Deployment Designer (DD) is used by architects to create a deployment configuration of a configured system. This is accomplished by first validating it against a logical representation of the data center (LDD). Next, a deployment configuration, called a deployment report, is generated and used for communicating between Operations and Development and for scripting deployments. The DD provides a graphical diagram-to-diagram binding experience from the System Diagram to the Logical Datacenter Diagram and provides visual feedback. This is done while validating that the requirements of the configured system conform to the specification of the Data Center requirements. Validation feedback is performed on a number of levels, from communication pathways, protocols, and specific configuration of the data center environment and the application configuration requirements. The Visual Studio task list integration provides a simple navigation mechanism to highlight the diagram (AD, SD, and/or LDD). It also assists the user in selecting the system that is in conflict with the policies of the data center. This provides the user with the ability to correct the configuration error before deployment and before a complete implementation. The navigation capabilities also allow the user to examine the source of the constraint definition for further insight into the problem areas. This DD is the primary communication mechanism used to visualize how a configured system is to be deployed into a similarly configured datacenter environment. The deployment report can be generated from this design surface, and the user can specify options to generate a human readable (HTML) report, which will include the diagrams as well as the deployment data. The deployment data consists of configuration settings for each application and logical server, along with a list of files to be deployed.

The Visual Studio Team Architect Extensible Platform
Visual Studio Team Architect is designed to be an extensible platform to enable third parties to leverage existing domain expertise while taking advantage of the visual design and validation features of the Distributed System Design suite. It is the first release along a roadmap for a complete unified development environment as part of Visual Studio Team System. The extensibility features offered in the Visual Studio 2005 release will allow third parties to document and model aspects of their distributed system for a more complete definition of their applications. The extensibility features will enable a third party or ISV to create their own application or logical server type. This will be complete with communication requirements, hosting requirements, configuration settings, and constraints. These new types can be easily added to the design surfaces and integrated with the native design elements provided in the first release. The metadata collected in the design experience will be available for constraint specification, as well as output in the deployment report. The Visual Studio 2005 release will not allow integration and synchronization of configuration and code artifacts into the project system for these new design artifacts. However, this capability is slated for a later release of the tool suite.

Links

20 Minute MSDN TV overview of "Visual Studio Team Architect": http://msdn.microsoft.com/msdntv/ episode.aspx?xml=episodes/en/20040129VSTUDIOAT/manifest.xml

Streaming video PDC 2003 presentation "Visual Design and Validation of Connected Systems": http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/dnvsent/html/vsts-arch.asp

Visual Studio Team Architect Overview on MSDN.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...